I am compiling an article on Spamming from shared webservers. This is basically to help sys-admins to detect the source of spam. Article'll contain steps for detection and recovery .... but NOT prevention.
I have got situations like , a user creates a PHP script that read the mail addresses stored in Mysql database to send out mass mails. Also had vulnerabilities like FormMail being misused.
If there are any sys-admins out there , who encountered such spammers ... can you help me by describing the situation and also the steps you used to detect the culprit . I would be really obliged, if you could contribute s'thing for my article.
I've seen a lot of this. The two you mentioned are of course the most prevalent, but I've seen the following as well:
1. Users running SMTP servers on VPS systems and using them as relay points.
2. Users running spam applications via shell command line interfaces, but disguising the running process as something very harmless (just an argv change).
N. Users setting the "From" address on an outbound message to the target user and sending the message to an account that doesn't exist.
There's an unlimited number of ways to spam people, *especially* if you have your access to a remote shell.
The only way I've ever been able to truly get it under control is to set shared hosting systems up to relay to a central mail-relay farm. That mail farm in turn runs anti-spam checks on the message *before* relaying it out to the world. For instance, perhaps we'll run Bayesian probability scans on a message one of our own customers is trying to send. If it happens to score too high, we won't even relay it on. It gets handled as an abuse incident. Since each user has their own unique user-id on each web server, it's possible to easily trace the original sender of the message back via identd checks even if the headers are forged.
Also, if possible, keep your mail servers separate from your web servers and do not allow shell access to your mail servers. If someone *does* spam out of a web server - and it will happen - you're in a world of hurt if that system winds up on a few RBLs and it's acting as your mail server as well.
Of course, that mail server should ALSO relay through the central mail farm, and it's outbound messages should be scanned as well. Be tough on it. Use different outbound addresses for web-generated mail and "mail system" generated mail.
To further combat... offer some third party "email marketing" service to your customers. They'll be less likely to spam out of your systems if they can pay you $5 a month more to use some third-party online marketing service. If anyone gets blacklisted, it's that third party spam shop and NOT your customers.
(One of these days, I need to get back into hosting!)
McJeff215, Thanks for the detailed post. You have a very good technical know-how . You should get back into hosting. .. :-)
Since each user has their own unique user-id on each web server,
What happens if its using a php script , and the user-id is shown as that of apache. This happens , usually with some vulnerability in a user script .. How do you figure out which script is being used to spam ?
I spent a lot of time running CGI scripts and whatnot as the web-server user. I found that the speed increase you get via mod(perl|php|python) simply isn't worth loosing the tracking. Run 'em as binaries. There are things you can do to make them feel like modules to your end users.
For that reason, I'd recommend *always* running suExec and wrapping your CGI scripts. Not only does it allow for easier tracking, it's more secure when configured correctly and will directly result in fewer technical support contacts.
Once you're running everything on a site under a common UID #, you're in good shape.