S'il y a bien une chose qu'il faut savoir, c'est qu'un serveur dédié est, dès sa connexion au réseau, attaqué en permanence, il est donc nécessaire de bien savoir s'en protéger afin de garder un serveur opérationnel (le pirate partagera rarement votre serveur avec vous), de limiter les ressources consommées (à cause du brute force par exemple) et de garder des logs propres : chaque erreur étant loguée, une long série de tentative feront grossir vos logs, ce qui rendra ces derniers plus difficiles à analyser.

La liste des attaques qui suit est purement informative et en rien exhaustive, si toutefois j'ai oublié de signaler un type d'attaque très courant, je me ferrais une joie de le rajouter.

A la base : virer les gêneurs

Il existe malheureusement sur le web de nombreux scripts mis à disposition qui permettent de rechercher des failles sur les serveurs dédiés. Ces scripts, peu efficaces, vont toutefois devenir très envahissant, il est donc d'usage de bannir ces utilisateurs, notamment au moyen de fail2ban.

Comme tout le monde le sait, un serveur dédié s'administre depuis la console SSH, qui utilise habituellement le port 22. De nombreux scripts étant conçus pour interroger le serveur sur ce port et s'en donner à coeur joie, il suffit de changer le port d'utilisation de SSH (par exemple 2222) pour ralentir les attaques. Toutefois en complément, pour contrer les scripts intelligents, il est utile de désactiver la possibilité de se logguer en root, et de passer par un autre utilisateur bénéficiant des droits root, qui lui même aura un mot de passe assez complexe. Avec cela vous êtes déjà un peu plus tranquille contre ce genre d'attaque.

La base de toute protection est d'avoir les moyens de se défendre, il vous faut pour cela un firwall : sous Linux, iptables n'est plus à présenter, ainsi qu'un système pour détecter et bannir automatiquement les tentatives de hack, j'ai nommé fail2ban. Dans un premier temps configurer iptables pour ne laisser ouvert que les ports nécessaires est une bonne chose (tutoriel sur la configuration d'iptables), ensuite il suffit de configurer fail2ban pour bannir les adresses ip qui sont considérées comme nuisibles grâce à des regex.

Un premier script de hack très connu, n'est pas très dangereux mais quand la moitié des lignes de log sont de sa faute, autant le virer. J'ai nommé les scripts w00tw00t qui laissent une trace de ce format dans les logs :

client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)

Une regex dans fail2ban détectant ce type de chaine aura vite fait de soulager vos logs. nous avons ensuite les scripts qui cherchent désespérément des répertoires classiques, afin de trouver ensuite un script avec des failles potentielles, ce qui donne dans les logs :

File does not exist: /var/www/horde File does not exist: /var/www/horde2 File does not exist: /var/www/horde3 File does not exist: /var/www/horde-3.0.5 File does not exist: /var/www/horde-3.0.6 File does not exist: /var/www/horde-3.0.7 File does not exist: /var/www/horde-3.0.8 File does not exist: /var/www/horde-3.0.9 File does not exist: /var/www/mail File does not exist: /var/www/email File does not exist: /var/www/webmail File does not exist: /var/www/newmail File does not exist: /var/www/mails File does not exist: /var/www/mailz

Là encore une regex dans fail2ban aura vite fait de faire le ménage, attention toutefois à exclure les répertoires où se trouvent vos sites web, sous peine de bannir tout visiteur tombant sur une erreur 404.

Interdire l'accès panels d'administration

Vos scripts étant installés (Wordpress, Dotclear, phpBB, PHPMyadmin, etc), il est nécessaire de restreindre l'accès à leur panel d'admin à votre seule personne (et aux personnes habilitées) grâce à un .htaccess qui évitera alors à un script auto de s'acharner sur le login de phpMyadmin. Avec un .htaccess les erreurs de login sont détectables par fail2ban, sont bannir les ips est un jeu d'enfant. Veillez aussi à toujours garder vos scripts à jour, une faille découverte dans ces CMS est très vite exploitée.

Ne pas se transformer en serveur de spam

Si vous avez installé sur votre serveur dédié un serveur de mail (Postfix pour ne pas le citer), vous êtes une cible très intéressante pour les pirates car si vous avez mal configuré votre serveur smtp, vous alors servir de relais pour l'envoi de spams. Et ce genre de problème est très facile à détecter :

• Soit votre serveur rame affreusement, l'envoi de mail en masse étant très lourd et le pirate ne se privant pas d'utiliser votre serveur jusque dans ses retranchements (y'en a même qui vont jusqu'à la saturation de mémoire).
• Soit votre serveur dédié est tout simplement coupé par votre hébergeur pour résoudre le problème du spam, mais là les problèmes commencent pour vous.

En revanche si votre serveur mail est bien configuré, vous aurez juste affaire à des tests et des tentatives plus ou moins régulières de ce style :

NOQUEUE: reject: RCPT from unknown[77.232.1.125]: 554 5.7.1 <sunnoes@yahoo.com>: Relay access denied; from=<smtp2001soho@yahoo.com> to=<sunnoes@yahoo.com> proto=SMTP helo=<91.121.151.111>

Une regex fail2ban permet alors de virer cet opportun qui sous-estime vos capacités :

failregex = reject: (?:RCPT|VRFY) from [a-zA-Z.0-9-]*.(?P<host>[0-9.]*).: (?:.*Relay access denied|554 Service unavailable; Client host S* blocked using|(?:Sender|Recipient) address rejected)

La liste est loin d'êtres exhaustive mais avec tout ça vous avez déjà de quoi vous protéger.