La frayeur du jour : serveur bloqué par iptables ! J'avais pourtant fait attention de bien ouvrir les ports nécessaires :

iptables -P INPUT ACCEPT
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --dport 25 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p udp --dport 123 -j ACCEPT # ntp
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -P INPUT DROP

Heureusement, la console Gandi permet d'accéder à son serveur même bloqué pour en rétablir l'accès. Ouf ! Après quelques recherches, et la lecture d'un billet de SelbyTech sur iptables, je suspecte que l'interface loopback doit être nécessaire pour SSH, Apache et cie. Voici donc finalement les règles que j'ai utilisé :

iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -p tcp --dport 25 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p udp --dport 123 -j ACCEPT # ntp
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -P INPUT DROP
iptables -P FORWARD DROP

J'en profite pour ajouter une règle de SpamCleaner, et de l'adapter à une série de requêtes tentant (sans succès) d'accéder à un site distant détectée dans les logs d'Apache :

iptables -I INPUT -p tcp --dport 80 -m string --to 70 --algo bm --string 'GET /w00tw00t.at.ISC.SANS.' -j DROP
iptables -I INPUT -p tcp --dport 80 -m string --to 70 --algo bm --string 'GET http://' -j DROP

Tout à l'air de bien fonctionner. Au final, le serveur n'aura été inaccessible que quelques minutes.