[Mimedefang] OT: Don't let this happen to you

Atanas atanas at asd.aplus.net
Thu Feb 16 14:50:55 EST 2006


In a large scale environment with lots of websites with untrusted 
content, trying to identify what exactly spammers can abuse and block it 
via mod_rewrite or mod_security rules seems to be just a waste of time.

The best workaround I have found and already use for the past few years 
is a sendmail log monitoring script that shuts down web sites 
immediately (notifying both parties - the web site owner and the shared 
server administrator) in case a web site starts sending suspicious 
amounts of outgoing emails for a given period of time.

In order to properly identify the real sender in the sendmail logs, I 
explicitly forbid users (via kernel firewall rules) to speak SMTP, so 
the only way left for PHP and other CGI scripts is to pipe emails 
through the sendmail binary, which gets run with the privileges of the 
invoking script (in my case with user privileges) and the user gets 
appropriately logged by sendmail.

Such a technique however requires running all untrusted scripts with 
untrusted (i.e. user) privileges, e.g. via suexec or other wrappers.

Running PHP as CGI on busy web servers is kind of slow, so I'm running 
it through a modified version of mod_fastcgi that forks dynamic 
PHP-fastcgi workers on demand and runs them with the privileges of the 
script owner. The PHP-fastcgi approach has some really nice advantages 
when compared to mod_php:
- apache children could be left alone to serve mostly static content, no 
mod_php messing around, eating resources and core dumping children;
- the number of fastcgi workers can be limited per user/website, so a 
single website can no longer bring a shared server to its knees when 
abused (e.g. with tons of runaway (mod_)PHP instances)
- it runs as fast as mod_php, allows using PHP optimizers, accelerators, 
etc.; it's kind of self-balanced configuration - the fastcgi process 
manager kills the least used PHP workers, so less intensive websites get 
a CGI like performance, while the really loaded ones work at full speed 
as their workers are left in memory most of the time;
- allows having different PHP configurations (php.ini) per user, and 
even running different PHP versions (like PHP4 or PHP5) depending on the 
user's choice.

Regards,
Atanas



More information about the MIMEDefang mailing list