Hi there,
I have posted on countless forums and posted in loads of places and no one seems to be able to help me!!
With our server, over the past month or so it seems someone keeps sending spam through it somehow, be it via a script on the server or something other back door, but it keeps filling up the mail server and messages get deleted, never arrive, or just take about 5 days to send!!
I have attached a picture of how it looks in the mail queue, you will see it basically sends it to a big list of email addresses which I pressume it would get from somewhere?!?!
At the moment I have to manually delete them from teh queue but we receive about 15 an hour of these, so it takes a long process to try and beat them
I was wondering if there was someway to prevent this, espcially as they are all being sent from the same address, anonymous@mail.dreamshock.com, if there was a way to prevent this email address sending, or just delete it if it appears.
Desperatate for any help and advice!!
Thanks
Scott Wright
Full Version: Cant prevent spam being sent
A couple of things to check Scott...
First in the Plesk -> Server -> Mail -> White List area make sure you do not have 127.0.0.1/8 in your White List. The /8 is wrong and leaves you with an open relay. It should be 127.0.0.1/32 if you want to allow scripts to send mail but close any open relays.
Also double check the Server -> Mail -> Preferences to make sure your requiring some type of Authorization in order to send mail.
Those two should take care of any Open Relay issues.
If it's a script you'll need to first track down which script is the problem child. One way to tell if it's a script or not is to look in the Mail Headers while the spam is still sitting in your queue waiting to be sent. Specifically check the UID that is trying to send the mail. If you see a UID 48 doing the sending it's probably a typical PHP mail() exploit. Alternatively, if it's a CGI/Perl script those should show up in your server logs at /var/log/httpd/suexec_log.
If you're pretty sure it's a PHP script that's not secure (eg if you're seeing a UID 48 in the mail headers) --which is the most common these days-- you can narrow down which domain is housing an unsecure script by making a small tweak to the vhost.conf file of each domain on your server. To do this you would add a line to the vhost.conf file of each domain that looks like:
Check to make sure /usr/sbin/sendmail is the correct path for your server. In the above you should also change the -fxxxx to be something that you can use to point back to each domain on your server. So one domain may be -f0001, another may be -f0211, etc. Use whatever makes it easy for you and make sure each domain has a unique -f code.
Once all of the domains have had the above line added to the vhost.conf file run /usr/local/psa/admin/sbin/websrvmng -a -v in order to start using the new configurations.
This will place an extra line in your mail headers that will allow you to view them and tell exactly which domain is responsible for sending any scripted mail from your server. Then it's just a matter of sorting out which files on the domain contain php's mail() function and either fixing it or disabling it until it is fixed by your hosting client.
Beyond that, it would probably also be wise to run both ChkRootKit and RKHunter on your server to make sure it hasn't already been exploited. You'd be surprised at how many servers out there have become owned by the spammers. If you've been rooted you've got a lot more serious problems to deal with since they've probably already created a back door for themselves.
First in the Plesk -> Server -> Mail -> White List area make sure you do not have 127.0.0.1/8 in your White List. The /8 is wrong and leaves you with an open relay. It should be 127.0.0.1/32 if you want to allow scripts to send mail but close any open relays.
Also double check the Server -> Mail -> Preferences to make sure your requiring some type of Authorization in order to send mail.
Those two should take care of any Open Relay issues.
If it's a script you'll need to first track down which script is the problem child. One way to tell if it's a script or not is to look in the Mail Headers while the spam is still sitting in your queue waiting to be sent. Specifically check the UID that is trying to send the mail. If you see a UID 48 doing the sending it's probably a typical PHP mail() exploit. Alternatively, if it's a CGI/Perl script those should show up in your server logs at /var/log/httpd/suexec_log.
If you're pretty sure it's a PHP script that's not secure (eg if you're seeing a UID 48 in the mail headers) --which is the most common these days-- you can narrow down which domain is housing an unsecure script by making a small tweak to the vhost.conf file of each domain on your server. To do this you would add a line to the vhost.conf file of each domain that looks like:
CODE
php_admin_value sendmail_path "/usr/sbin/sendmail -t -i -fxxxx"
Check to make sure /usr/sbin/sendmail is the correct path for your server. In the above you should also change the -fxxxx to be something that you can use to point back to each domain on your server. So one domain may be -f0001, another may be -f0211, etc. Use whatever makes it easy for you and make sure each domain has a unique -f code.
Once all of the domains have had the above line added to the vhost.conf file run /usr/local/psa/admin/sbin/websrvmng -a -v in order to start using the new configurations.
This will place an extra line in your mail headers that will allow you to view them and tell exactly which domain is responsible for sending any scripted mail from your server. Then it's just a matter of sorting out which files on the domain contain php's mail() function and either fixing it or disabling it until it is fixed by your hosting client.
Beyond that, it would probably also be wise to run both ChkRootKit and RKHunter on your server to make sure it hasn't already been exploited. You'd be surprised at how many servers out there have become owned by the spammers. If you've been rooted you've got a lot more serious problems to deal with since they've probably already created a back door for themselves.
QUOTE (Squire @ Apr 11 2007, 07:04 AM) 
First in the Plesk -> Server -> Mail -> White List area make sure you do not have 127.0.0.1/8 in your White List. The /8 is wrong and leaves you with an open relay. It should be 127.0.0.1/32 if you want to allow scripts to send mail but close any open relays.
I never really understood the need for this. Since ARIN never issues out 127.* ips, what is the point of changing this from 127.* being whitelisted to 127.0.0.* ? Granted I see why it would be considered more secure. However, at night I lock my door, but I do not park a tank behind it.
Sorry for going off topic!
Scott,
You may want to grab a copy of qmhandle if you are fairly proficient with the linux command line. This will allow you to remove the email by subject rather than deleting them manually from the interface.
If you can get into the queue from ssh, and find the headers for one of the emails, you may be able to firewall out the sending ip address. Unfortunately qmail has a pretty ugly method of queuing up email.
If you still are unable to figure this out, another tech modified qmhandle to allow deletion by to/from email addresses(rather than subject). This might benefit you with minimal losses of legitimate email, as legitimate email should not be sent as anonymous@...
Just as a last resort, you may also want to try:
"find / -name ?or?ail.p?"
If you find any formmail scripts, it would be in your best interest to remove them, or atleast move them.
Good luck,
James Jhurani
QUOTE
I never really understood the need for this. Since ARIN never issues out 127.* ips, what is the point of changing this from 127.* being whitelisted to 127.0.0.* ? Granted I see why it would be considered more secure. However, at night I lock my door, but I do not park a tank behind it.
Try it with one of these Plesk boxes sometime and see what happens James.
It's the subnet mask that's the problem, not just the 127 IP. /8 leaves you with a hole they can exploit. /32 closes it, but still allows your real users to set up scripted mail contact forms. I haven't looked at it in awhile, but I think even DNSReport.com will report a /8 as running an open relay, because it is. No matter what other authorization settings you may have set at the server level.
QUOTE (Squire @ Apr 12 2007, 06:17 AM)
Try it with one of these Plesk boxes sometime and see what happens James.
It's the subnet mask that's the problem, not just the 127 IP. /8 leaves you with a hole they can exploit. /32 closes it, but still allows your real users to set up scripted mail contact forms. I haven't looked at it in awhile, but I think even DNSReport.com will report a /8 as running an open relay, because it is. No matter what other authorization settings you may have set at the server level.
It's the subnet mask that's the problem, not just the 127 IP. /8 leaves you with a hole they can exploit. /32 closes it, but still allows your real users to set up scripted mail contact forms. I haven't looked at it in awhile, but I think even DNSReport.com will report a /8 as running an open relay, because it is. No matter what other authorization settings you may have set at the server level.
Indeed, I have actually seen spam domains that resolve to 127.0.0.1, and that kinda tricks your server to thinking the mail is coming from local host with some configurations. I THINK plesk fixes this problem with having an actual list of domains on the server that it will send mail from.
I thought that was just a user tweat but even on the Plesk site it tells you to put to 127.0.0.1 / 32
I cannot believe myself had it on /8 all this years and wondering how they send spam from time to time from my box.
http://kb.swsoft.com/article_22_1394_en.html
I changed this too on my server.
I cannot believe myself had it on /8 all this years and wondering how they send spam from time to time from my box.
http://kb.swsoft.com/article_22_1394_en.html
I changed this too on my server.
And the really strange part is...
One would think it would be such an easy tweak to make to have the /32 subnet mask during Plesk installation/setup. After all, something is slapping the /8 in there.
I never got why Plesk (then) and SWSoft now don't simply fix that in their setup routine.
One would think it would be such an easy tweak to make to have the /32 subnet mask during Plesk installation/setup. After all, something is slapping the /8 in there.
I never got why Plesk (then) and SWSoft now don't simply fix that in their setup routine.
QUOTE (Squire @ Apr 12 2007, 06:17 AM)
Try it with one of these Plesk boxes sometime and see what happens James.
It's the subnet mask that's the problem, not just the 127 IP. /8 leaves you with a hole they can exploit. /32 closes it, but still allows your real users to set up scripted mail contact forms. I haven't looked at it in awhile, but I think even DNSReport.com will report a /8 as running an open relay, because it is. No matter what other authorization settings you may have set at the server level.
It's the subnet mask that's the problem, not just the 127 IP. /8 leaves you with a hole they can exploit. /32 closes it, but still allows your real users to set up scripted mail contact forms. I haven't looked at it in awhile, but I think even DNSReport.com will report a /8 as running an open relay, because it is. No matter what other authorization settings you may have set at the server level.
Thats weird, I figured MTA's would check a little better than that.
I agree wholeheartedly James, one would certainly think that.
It's always been the case with Plesk/Linux boxes though. Going back as far as version 2.x I can state personally since I've been using PSA since back then and it's been there in every version. And it was something they didn't even document until the last couple of versions, which is why PSA has such a bad name out there among some portions of the hosting community. Silly when it would be such an easy fix for them to make /32 the default during setup.
It's always been the case with Plesk/Linux boxes though. Going back as far as version 2.x I can state personally since I've been using PSA since back then and it's been there in every version. And it was something they didn't even document until the last couple of versions, which is why PSA has such a bad name out there among some portions of the hosting community. Silly when it would be such an easy fix for them to make /32 the default during setup.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.