Le Blog Utux

HTTP 200 GET /

Récit d'une attaque portmap

Rédigé par uTux 3 commentaires

Tout a commencé avec des problèmes de lenteur sur notre connexion à internet au bureau. Un petit tour dans l'interface d'administration de la Freebox a montré une utilisation importante de la bande passante en upload même la nuit lorsque toutes les stations de travail sont éteintes. Heureusement derrière la Freebox il y a un routeur sous Linux par lequel tout le trafic passe, nous avons donc des outils plus poussés pour analyser ce qui transite.

iptraf a montré que le trafic n'était pas émis depuis une station de travail mais était généré en local (par le routeur lui-même) : était-il compromis ? Présence d'un rootkit ? Une petite vérification des processus avec ps et top semble indiquer que non, rien d'anormal. J'ai également vérifié à coup de md5sum que les binaires bash, ps, w, who, top n'avaient pas été altérés (en comparant avec une version sauvegardée il y a 1 mois).

Donc le routeur génère le trafic mais ne semble pas compromis, d'où vient donc le problème ? Sortons l'artillerie lourde : tcpdump. On sniffe 10secondes de trafic puis on récupère notre fichier pour l'ouvrir dans wireshark, c'est plus simple à lire. L'analyse montre un trafic composé exclusivement de paquets UDP / protocole Portmap. Une petite recherche rapide sur Google "high portmap trafic" me mène vers des articles d'Aout 2015 détaillant une forme de ddos basée sur portmap. C'est un ddos par amplification, c'est à dire que nous recevons des requêtes forgées qui font que nous générons ensuite des attaques vers d'autres serveurs. Or il se trouve que suite à un lourd historique (dette technique) la configuration du pare-feu était incorrecte et le port 111/UDP (portmap) du routeur était accessible depuis internet. La fermeture de ce port a mis fin aux attaques.

tcpdump / wireshark sont les meilleurs amis du sysadmin, et j'ai découvert également iptraf qui permet d'avoir une vue d'ensemble du trafic ce qui permet d'établir un premier diagnostic. Un pare-feu bien configuré est indispensable car même si des services ne sont pas utilisés ou sont censés répondre uniquement en local, des failles sont toujours possibles.

3 commentaires

#1  - fmr a dit :

Intéressant cette histoire de vérif des binaires bash, ps, w, who, top... Aurais tu de la doc sur la méthodologie?
Pas facile de trouver par quoi commencer un audit rapide sur linux, mise à part les rkhunter et consort...

Répondre
#2  - uTux a dit :

@fmr : On m'a toujours dit "quand ton serveur est compromis, tu ne peux plus faire confiance aux binaires qui sont dessus". Donc je fais des md5sum entre certains binaires du serveur (ex: md5sum /bin/ps) et je compare le résultat avec le md5sum des binaires d'un serveur identique. Ou alors je m'appuie sur une sauvegarde ancienne du serveur depuis laquelle j’extrais les binaires afin de calculer leur md5sum.

Répondre
#3  - Fmr a dit :

Oui logique, merci

Répondre

Écrire un commentaire

Quelle est le quatrième caractère du mot xea34u ?