What are some ways to prevent spam from leaving your servers should a hosting account get compromised?
Have a bunch of clients on a server with cpanel but wondering if there was a way to just prevent a chance if an account was compromised.
When I meant compromised I meant, a client signs up or a client account and gets hacked and his account is used for spam.
couldn't you setup some type of filter/blacklist terms in exim or spamassassin which would block/stop mail going out if it matched that?
Don't get compromised. Seriously.
Monitor your traffic. You'll understand what's normal and be able to recognize abnormal traffic.
Shut down unnecessary daemons. If the server isn't supposed to send mail, don't run sendmail or postfix.
Restrict SSH access and/or assign SSH a non-standard port (e.g. don't use the default port 22). If you need to use port 22, then augment with a service like DenyHosts to track and stop inbound SSH bot authentication attempts.
Use or enforce strong passwords for yourself and your customers.
Oh, and this: Fighting Spam - What can I do as an: Email Administrator, Domain Owner, or User?
The easiest thing to do would be to block outgoing connections to Port 25 until a client "requests" that it be unblocked for their IP. There really shouldn't be anyone running a mail server from a CPanel hosting site in the first place (if they're generating e-mail that's "sent" by another server, then it should sent to that server on port 587 per RFC and has been that way since 1998).
I really wish more providers had your level of consideration, even if you don't block Destination Port 25 traffic. We appreciate the thought, and would appreciate the firewall even more.
You're running a web hosting provider, which by its nature means your clients are going to be running untrusted and often insecure code.
Aside from the things you should already be doing to secure the server generally, consider:
Run malware scans against client data using a tool such as maldet. Keep your definitions up to date.
Only allow outgoing SMTP traffic to your local mail server, where you can log and exercise some control over outgoing mail. Add an outbound firewall rule that prevents anything but your mail server from connecting to port 25 on remote hosts. An example rule could be:
iptables -I OUTPUT -m owner ! --uid-owner EXIM_USER -p tcp --dport 25 -j DROP
(Authenticated SMTP traffic to a customer's third party mail server, such as Gmail, will run on port 587 and be unaffected by this.)
If none of the servers that you use require outgoing mail, I would put a ticket in with your host and ask them to block port 25 inbound and outbound for the systems. ewwhite has the right idea - if one of your systems is completely compromised, there is nothing you can do on that system to prevent it from becoming a spam zombie or equally undesirable things. You can, however, intervene one step further up the chain.
As well as a comprehensive defence strategy, keeping up your updates, restricting your access, and all of the other best-practices that ewwhite mentions, I suggest taking the principle of least privilege up a level to the host, or to the network provider. If the machines are never going to need to send mail, make it so they really can't.
I will echo ewwhite's advice, as well as the suggestion to drop all SMTP traffic from other than your mailhost at your firewall, from Micheal Hampton.
Another suggestion is to set up a traffic snoop on your client's apps for outbound SMTP. Their web servers should not be generating mail, so if they DO, you want to see what it's about - perhaps you can glean some insight into the original source. Other things to perhaps try:
If you know your client's IP block, you can capture telnet, remote desktop (3389) and SSH traffic to the web host and filter out their IP block from the results. This should give you an idea if anyone is controlling the host other than them.
Another type of traffic to snoop is IRC, since this protocol is widely used as a command-and-control net for zombie computers. Or simply drop the IRC ports at your firewall the same way you dropped SMTP.
Another possible vector for malware is via torrents. If your client's web server is opening torrent connections, it may be in use as a torrent distribution node as well as an email spam source. If your clients haven't requested this as a supported service, you can then either drop it at the firewall, or kill the services on the host.
The ultimate solution, once you've backed up what you need to search out the takeover vector (or if there's no real push to find out what happened), you can simply kill the VM or reimage the server, and then restore the client's apps and data from a prior backup. They might have issues with this... but, it's one of the costs of running unsecured code.
install CSF (ConfigServer firewall)
