Auteur Sujet: Comment protéger un serveur IPerf des attaques ? (Lu 6806 fois)

vivien · « **le:** 18 février 2015 à 09:41:13 »

Comment protéger un serveur IPerf public des attaques ?

J'héberge un serveur iperf public (3.testdebit.info)

Avant-Hier j'ai eu le droit a une allocation brutale et très courte de 6 Go de ram sur mon serveur iperf qui a 4 Go de ram, entraînant 2 Go de swap.

Hier, j'ai eu le droit à 24 Go de mémoire "committed" par Iperf, et à un cœur à 100% pour iperf.

Bref, j'ai l'impression que iperf est vraiment pas fait pour tourner sur un serveur public exposé à l'Internet.

Pensez vous à un moyen simple pour limiter sa consommation mémoire (en le killant si il consomme trop, j'ai un crontab qui toutes les minutes le relance si il s'est tué, ce qui arrive)

mikmak · « **Réponse #1 le:** 18 février 2015 à 09:58:40 »

clairement,
perso je dois le restart régulierement parce que le process s'est vautré ...
(j'ai aussi un restart auto en daily + restart auto si le process tombe)

y a des chances que iperf3 aille mieux mais bon ... patience ....

après c'est un service gratuit, ca marche quand ca marche , voilà

le pire qu'il m'ait fait c'est de continuer à répondre mais avec des perfs totalement moisies, ca c pas très cool par contre

Mik

BadMax · « **Réponse #2 le:** 18 février 2015 à 10:10:17 »

Peut être jouer avec l'option '-l' ?

reno31 · « **Réponse #3 le:** 18 février 2015 à 11:55:44 »

Creer un utilisateur qui n'a pas le droit d'allouer trop de mémoire ?
http://unix.stackexchange.com/questions/34334/how-to-create-a-user-with-limited-ram-usage

vivien · « **Réponse #4 le:** 03 mars 2015 à 11:26:11 »

J'ai arrêté le redémarrage tous les 6h de iperf pour pouvoir faire des capture d'écran.

Voici ce que donne htop :

Les définitions :
VIRT -- Image virtuelle (Ko) La quantité totale de mémoire virtuelle utilisée par la tâche, à savoir l’ensemble des codes, données, bibliothèques partagées et pages qui ont été transférées sur l’espace d’échange (« swap »). VIRT = SWAP + RES.

RES -- Taille résidente (Ko) La mémoire physique « non swappée » qu’une tâche a utilisée. RES = CODE + DATA.

SHR -- Taille mémoire partagée (Ko) La quantité de mémoire partagé utilisée par une tâche. Elle reflète simplement la quantité de mémoire qui peut être potentiellement partagée avec d’autres processus.

TIME -- Temps CPU Le temps CPU total utilisé par la tâche depuis son lancement. Quand le « mode Cumulatif » est Actif, chaque processus est listé avec le temps cpu que lui et ses fils tués ont utilisé. => Le temps CPU est le même pour iperf et la commande "top" que ce soit en mode Cumulatif ou non. Dans la copie d'écran ci-dessous le mode cumulatif n'est pas utilisé :

Voici ce que donne top :

# free -m total used free shared buffers cached Mem: 3934 3762 171 1756 69 2535 -/+ buffers/cache: 1157 2776 Swap: 3814 112 3702 # ps aux | grep iperf root 9432 0.0 0.0 11780 932 pts/0 S+ 11:26 0:00 grep --color=auto iperf root 17521 0.0 0.0 64972 1716 ? S mars02 0:00 /usr/bin/sudo -u nobody /usr/bin/iperf -s nobody 17522 5.5 18.2 44719360 735076 ? Sl mars02 54:23 /usr/bin/iperf -s

vivien · « **Réponse #5 le:** 03 mars 2015 à 11:44:32 »

Voici les stats de Munin :
(le serveur fait aussi serveur web et SpeedTest)

La mémoire :

Le réseau avec un transfert à 1 Gb/s sur 5 minutes avec iperf qui aplatit tout (qui fait gonfler l'utilisation mémoire à 10 Go en virtuel)

Le firewall voit aussi de nombreux petits paquets à 100 Mb/s en in. Leur arrivée est régulière. Le redémarrage est lié au kill / restart d'IPerf que je fais toutes les 6h (et là je l'ai désactivé d'où le fait que cela ne reprend pas car iperf est planté)

Il y a apache sur ce serveur mais ce n'est pas lui qui est attaqué.

Nombre d’accès par seconde :

Consommation réseau d'Apache2 :

almorel · « **Réponse #6 le:** 03 novembre 2015 à 22:31:53 »

Bonsoir,

Mon premier post sur ce forum et j'en profite pour remercier la fibre.info pour ces informations, news et de ses serveurs iperf3 que j'utilise assez régulièrement.

Juste une petite suggestion pour le confinement du (ou des) processus iperf3 sur vos serveurs, le cgroup Linux peut vous permettre de limiter les ressources allouées à iperf3. Avez vous déjà essayé de les confiner ?

Cordialement,

vivien · « **Réponse #7 le:** 03 novembre 2015 à 22:45:12 »

Bienvenue,

Ce problème de saturation mémoire concernait iperf2.

iperf3 n'a pas ce problème là. Par contre la limitation à un client par serveur iperf, nécessite d'en ouvrir plusieurs. Avant je killait très régulièrement iperf3, mais un petit malin a mis un script qui redémarre dés la connexion terminée, donc avoir plusieurs process est nécessaire.

J'ai par contre bloqué l'UDP, qui est par défaut ouvert comme TCP avec iperf3.

l'UDP d'iperf3 a complètement été revu et a une sorte de pseudo fenêtre TCP au dessus d'UDP : les performances décroivent avec l'augmentation de la latence.

Je recommande encore Iperf2 pour l'UDP mais là je trouve un peu osé de mettre un serveur ouvert au public, c'est facile de faire du DDOS avec un serveur iperf2.

Si j’exclue la partie UDP, je suis vraiment satisfait et enthousiastes par les performances et nouvelles fonctionnalités d'iPerf3. Il permet même de voir l'utilisation CPU (uniquement en sortie Json avec l'option -J) ce qui est pratique si on se demande si le CPU a bridé les débits.