Outbound mail filtering on large mail / web server farms - just an idea or two that I have

Sun Nov 20 15:18:08 UTC 2005

On 11/20/05, Suresh Ramasubramanian <ops.lists at gmail.com> wrote:
> When you aggregate all .forward email out through a single box, stuff
> that's slipping through your filters starts to stick out like a sore
> thumb when you analyze the mail queues on that box, so you can tune
> your inbound filters better.  Quite a useful thing to do, really.

I originally wrote this lot below as boilerplate for large webhosting
providers that find themselves with several racks full of pizzabox
colos running a web control panel like ensim or cpanel so that the
people actually operating the colos may not have too much clue .. and
these places are typically riddled with lots and lots of exploitable
cgi / php scripts that are broken into and used to send spam using
injection / xss etc holes ..

Some of the ideas here might well apply to what I was talking about in
this thread as well - the two kind of tie in together

Comments welcome

regards
srs

------------------------------------------

First and most important thing to do - Please set your webserver up so that it
uses suexec / phpsuexec to make sure perl and php scripts run as the uid/gid
of the the user rather than the webserver's uid/gid like nobody or www-data.

Never mind if your webhosting software like ensim or plesk inserts headers
showing the spammer's uid/gid, path of the calling script etc - serves as a
useful backup, and is especially useful when you are searching your logs for
cgi scripts that that spammers upload onto your server and then use to proxy
their spam from another server through your IP [so your IP shows up in our
logs as sending spam, rather than the spammer's actual IP]

I'd also strongly suggest something like this if you can manage it

1. Block port 25 outbound on all your webservers.  Port 25 inbound as well if
you happen to have a mailserver infrastructure for your users thats separate
from the webservers they are on, rather than MX'ing your users domains onto
the webserver they're hosted on.

2. Set your exim local installs to smarthost through a separate, filtered
cluster of servers (spamassassin + bogofilter or something like that -
possibly DCC for bulk email detection as well). Smarthosting - see
http://www.hserus.net/exim.html

For extra points you could do smtp auth on the filtered smarthost as well, to
help you jump on issues faster. Set it up so the user's local uid/gid gets
used to auth to the remote exim box .. centralized ldap or mysql userdb does
the trick for that.

That way spammers cant spam out direct through cgis - but peoples
normal email and script generated traffic goes out just fine through
your filtered
gateways.

-------------------------------------------