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
_______________________________________________
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may ignore it.
Visit http://www.mimedefang.org and http://www.roaringpenguin.com
MIMEDefang mailing list [email protected]
http://lists.roaringpenguin.com/mailman/listinfo/mimedefang
