• Halloween is coming! To celebrate the occasion, we dusted off a couple of old skins, and even created a brand new one (Pixel).
    To get into the festive spirit, install the Skins extension.
  • The new Python extension is now available. It allows customers to deploy and manage WSGI-based Python applications on their websites directly from Plesk.
  • The Plesk Mobile apps for iOS and Android and the Plesk Mobile Center extension have been deprecated, and are no longer available for new installations. In Plesk Obsidian 18.0.84, the Plesk Mobile Center extension will be removed from servers during the upgrade, and the Plesk Mobile apps will lose their server management features.
  • The Social Login extension has been deprecated and will be removed in Plesk Obsidian 18.0.84. After that, it will no longer be possible to log in to Plesk with a Google, Facebook, GitHub account, or with a passkey. Plesk usernames and passwords, as well as logging in with a WebPros Account, are not affected.

Second box Second time QMAILD user hacked QMAILD user consumes 99% CPU

M

mdowner

Guest
I had this same issue on our last box, percula-clown. So we built a new server starfish with differant passwords. I am begining to beleive the PLESK product has an exploit some place that is allowing the boxes to get hacked! There is no reason this should happen twice!

We are spamming thousands of users per second!

Everytime support dials in they give some random usless excuse but there is obvioulsy a serrioius exploit here!
 
There are 3 vectors this could be coming from:

1) You're an open relay, this can be caused through a whitelist, or through poplocking. Poplocking will whitelist an IP temporarily, and its not uncommon for users to come from proxies.

Action: Go into PSA, make sure you dont have any whitelists, and turn off poplocking. Clean your queue out with qmHandle or something like that, and then see if the spam continues.

2) They're using a compromised user account. I see this happening more and more, so look at your logs for "smtp_auth: smtp_auth: SMTP user ..." entries.

Action: clear your queue again, then watch /var/log/messages or /usr/local/psa/var/log/maillog for smtp_auth and spam. Thats going to tell you the account thats been compromised

3) Its coming through a web app. This is the vector I see about 90% of the time. A really dedicated spammer will go so far as to create their own MTA in perl, bypassing all your logs completely.

Action: clear your queue, and shut down the web server. If spam continues, then you can rule the web app as a source completely. If it does stop, then you'll need to go through each domains logs to see where the spam is coming from, or in my case, I fire up a sniffer and watch for the URL they're hitting.
 
Back
Top