[wp-hackers] [OT] Resources for Defending Against Blog Attacks

[Sabin Iacob]

Alex Günsche wrote:
> Some good advices came from Jacob already, I think I'll also add my 2
> cents.
>
> * Set up the firewall properly. "Drop" policy for all not required
> ports. Take measures against flooding. Set up and maintain blacklists
> (although this might render useless with certain sorts of DDOS).
> Good tutorials on advanced firewall configuration:
>  - http://gentoo-wiki.com/HOWTO_Iptables_and_stateful_firewalls
>  - http://forums.gentoo.org/viewtopic-t-159710.html
> If you don't want to maintain your IPtables rulesets manually, I can
> recommend Firehol (also a CLI tool, but very easy and quick to use).
>   

 * default "drop" policy is risky (you can lock yourself out if you're 
not creful), you'll be better off with a drop rule at the end of the 
filtering chain
 * the gentoo initscripts make managing firewalls easy without other 
software; I think the Fedora/Centos init scripts do a similar job (they 
use iptables-save and iptables-restore); otherwise, you'll need some 
configuration tool (I ound the firewall managing initscripts from Suse 
horrible, for instance, and Debian has no such thing, AFAIK)

> * Fail2ban (http://www.fail2ban.org) is a good tool against DDOS
> attacks. It will automatically ban users for a certain time who violate
> your policy, and add them to a temporary blacklist.
>   

DDOS can't really be mitigated at the server level; you'll need an ISP 
that responds quickly for this (the attacker's goal is usually to fill 
your pipe, which makes filtering at the server level useless)

> * Use a dedicated mail server or service (simply set the DNS MX record
> for the other machine and let that one handle mail). This way, massive
> spam surges won't affect your main server.
>   

good suggestion... also, you may want to use tmda or a similar tool 
(whitelist-based) instead of the usual SpamAssassin / bayesian filtering 
software

> * Don't install software you don't need. I've seen people running X on a
> webserver, but even too many Apache modules can be a risk.
>   

especially avoid development tools, if using a compiled distribution

> [...]
> * As for PHP: Also use only modules you need, and use open_basedir
> restrictions. Safe Mode is rubbish, but open_basedir can really protect
> your system if there's a leak in a PHP application. (When setting up
> open_basedir restrictions, set them per vHost, and put the tmp path into
> the same folder. No global /tmp for webapps.)
>   

/me should do this, too

> * As for MySQL: Of course, no network access for MySQL. But you can also
> try to set up MySQL recourses in a fashion that a DOS attack doesn't
> render your system unusuable because of MySQL bottlenecks. If you can,
> increase the query and table caches.
>   

if you have control over the hardware you can do some more: give mysql 
its own hard drive and plenty of RAM

> * Possibly decrease logging: Heavy logging can decrease your harddisk's
> performance. Sometimes it can be better to log less. Btw, MySQL by
> default creates binlogs. They can be useful, but mostly they do nothing
> but eating harddisk space and performance, so switch them off in my.cnf.
>   

... and/or don't serve files off the same harddisk which holds the logs

> * If you're really paranoid, compile your kernel with only support for
> stuff you need, and deactivate loadable modules in the kernel
> configuration. Recent attack vectors don't use userspace rootkits, but
> kernel rootkids loaded as modules.
>   

if an attacker has root access, he can always write to /proc/kcore and 
hide anything he likes, even without modules

> * And a non-tech note, if you know these guys: Sue them.
>   

I would add:
 * use linux-vserver; it's chroot on steroids ;)