Auteur Sujet: Abus sur serveur iperf3 public (Lu 17569 fois)

vivien · « **le:** 20 mai 2016 à 09:13:25 »

Savez-vous si il existe des logiciels qui analysent le trafic par IP sur un serveur, de façon à bloquer avec iptables les IP qui ont un trafic cumulé sur la journée > 50 Go ?
Toutes les 5 minutes, une cumul du trafic serait réalisé (quel que soit le port utilisé) et si > 50 Go, cela bloque l'IP avec /sbin/iptables -A INPUT -s xx.xx.xx.xx -j DROP. À minuit les règles sont supprimées et les compteurs ré-initialisés.

J'héberge un serveur iPerf3 public sur 3.testdebit.info
Je kill le serveur toutes les heures mais certains ont un script qui relance la connexion.

Certains ont aussi trouvé le moyen de consommer 100% d'un cœur :

L'impact sur le load average :

Optix · « **Réponse #1 le:** 20 mai 2016 à 09:47:56 »

Citation de: vivien le 20 mai 2016 à 09:13:25

Savez-vous si il existe des logiciels qui analyse le trafic par IP sur un serveur, de façon a bloquer avec iptables les IP qui ont un trafic cumulé sur la journée > 50 Go ?

Oui, IPTables lui-même. Par contre, cela nécessite une recompilation du kernel, car il faut ajouter un module/patch qui gère les quotas.

Plus d'info : http://www.netfilter.org/documentation/HOWTO/fr/netfilter-extensions-HOWTO-3.html#ss3.13

vivien · « **Réponse #2 le:** 20 mai 2016 à 12:30:12 »

Sympatrique le patch quota, mais là ce n'est pas un quota général pour le serveur, mais un quota par IP. Si j'avais un nombre limité d'IP qui discutent avec le serveur je ferais une régle par IP, mais là c'est le monde entier qui peut discuter avec le serveur
=> Comment faire pour que cela ne bloque que l'IP qui a dépassé son quota (et cela nécessite de maintenir une table avec toutes les IP qui ont été connectées avec le serveur pour additionner le trafic)

Comme nfsen, il est possible de ne pas faire l'analyse pour tous les paquets, mais 1 paquet sur 100 c'est suffisant (dans ce cas la, on divise par 100 la taille du quota par IP)

Module/patch qui gère les quotas :

Code: [Sélectionner]

Ce patch par Sam Johnston <samj@samj.net> ajoute un nouveau match qui vous permet de mettre en place des quotas. Une fois que le quota a été atteint, la règle ne matche plus.

Par exemple, si vous voulez mettre un quota de 50Megs sur les données HTTP entrantes, faites comme suit :

    # iptables -A INPUT -p tcp --dport 80 -m quota --quota 52428800 -j ACCEPT
    # iptables -A INPUT -p tcp --dport 80 -j DROP

    # iptables --list
    Chain INPUT (policy ACCEPT)
    target     prot opt source               destination         
    ACCEPT     tcp  --  anywhere             anywhere           tcp dpt:http quota: 52428800 bytes
    DROP       tcp  --  anywhere             anywhere           tcp dpt:http

BadMax · « **Réponse #3 le:** 20 mai 2016 à 14:55:19 »

Et un combo de limit et quota ? Avec limit, l'option --connlimit-mask 32 permet de sélectionner une seule IP/flux. Tu pourrais t'en servir pour faire une première sélection avant d'envoyer dans quota. Evidemment, à tester, aucune idée si ça marche aussi facilement

kgersen · « **Réponse #4 le:** 20 mai 2016 à 15:09:02 »

c'est pas possible avec tc/htb ?

sinon faut mettre un frontend devant ton iperf3 -> regardes du coté des reverse proxy et des firewall.
ou
mettre un 'truc' qui mesure la conso par IP et déclenche un script -> regardes du coté des analyseurs/superviseurs de réseau (ceux ayant la possibilité de déclencher des actions suivant des conditions).

Le probleme ici est l'aspect 'quota': on ne veut blocker/limiter le trafic vers une IP qu'apres un certain volume consommé. ca veut donc dire qu'il faut 'tracker' et sommer le volume pour chaque IP destination ce qui n'est pas simple et peut 'exploser' la mémoire du serveur.

L'alternative est d'intégré cela directement dans IPerf3...donc demander a l'auteur.

vivien · « **Réponse #5 le:** 05 juin 2016 à 16:56:15 »

Une autre solution est d'utiliser ntop pour analyser le trafic (via Libpcap) et ensuite de scripter des actions (via Lua)
=> http://www.ntop.org

Cela doit par contre avoir un impact sur les performances, même si il dois être possible de ne analyser que un paquet sur 100 pour diminuer fortement la charge. En effet avec un paquet sur 100 on est en mesure de toujours identifier les gros consommateurs et leur trafic approximatif.

kgersen · « **Réponse #6 le:** 05 juin 2016 à 18:24:23 »

y'a pas moyen de parser le log d'iperf3 (server) et calculer les totaux par ip puis de blocker celles qui dépassent avec iptables?

iperf3 a une option pour sortir en json, on peut 'piper' (|) ca dans un script qui parse le json et fait le "boulot". le probleme c'est de faire le script

kgersen · « **Réponse #7 le:** 05 juin 2016 à 23:05:02 »

j'ai regardé rapidement pour faire ca en Python.

Le 1er probleme c'est de consommer le json produit 'test par test' , pour ca il y a splitstream:

Code: [Sélectionner]

sudo apt install python-pip
pip install --upgrade pip
pip install splitstream

puis un script Python (que j’appelle "iperf3tocvs.py") comme celui-la:

Code: [Sélectionner]

import json, sys
from splitstream import splitfile

# this will yield each test as a parsed json
objs = (json.loads(jsonstr) for jsonstr in splitfile(sys.stdin, format="json", bufsize=1))
print "ip,sent,received"
for obj in objs:
    # caveat: assumes multiple streams are all from same IP so we take the 1st one
    print "%s, %d, %d" % (obj["start"]["connected"][0]["remote_host"], obj["end"]["sum_sent"]["bytes"], obj["end"]["sum_received"]["bytes"])

puis

Code: [Sélectionner]

iperf3 -s -J | python iperf3tocvs.py

devrait afficher une ligne a chaque test avec l'ip, la conso up et down

par exemple:

Code: [Sélectionner]

ip,sent,received
ip: 2a01:xxx:xxx:xxx:xx:xx, 117047296, 117040064
ip: 2a01:xxx:xxx:xxx:xx:xx, 117047296, 117042944
ip: 192.168.1.31, 118751232, 118742800
ip: 192.168.1.56, 118751232, 118751232
...

y'a plus qu'a accumuler par IP et bloquer si ca dépasse une valeur donnée (upload, download ou les 2).
on peut éventuellement rajouter une whitelist et un reset quotidien ou hebdo.

c'est un bon début, ~~je mettrais tout ca sur github demain~~. https://github.com/kgersen/iperf3protect

vivien · « **Réponse #8 le:** 06 juin 2016 à 11:44:25 »

Cela fonctionne bien.
Une idée : rajouter dans les logs la date et l'heure du test + sa durée

Pour l'installation, il faut les droits root pour installer splitstream => c'est donc sudo pip install splitstream

Code: [Sélectionner]

$ /usr/bin/sudo -u nobody /usr/bin/iperf3 -s -p 5201 -J | python iperf3tocvs.py
ip,sent,received,direction
  2a01:6e00:10:410::2, 0, 1090125204, 0
2a01:6e00:10:410::2 is over the receive cap with 1090125204
2a01:6e00:10:410::2, 0 , 1090125204 
  2a01:6e00:10:410::2, 1158050140, 0, 1
2a01:6e00:10:410::2 is over the send cap with 1158050140
2a01:6e00:10:410::2 is over the receive cap with 1090125204
2a01:6e00:10:410::2, 1158050140 , 1090125204

vivien · « **Réponse #9 le:** 06 juin 2016 à 12:10:27 »

Je souhaiterais que le script en python se lance comme iperf avec l'utilisatuer nobody, donc j'ai mis des quote autour des commandes. Quel est la bonne solution ?

L'idée est simplement depuis le lancement en crontab root, lancer iperf3 avec l'utilisateur nobody et générer des fichiers de log. régulièrement le script est de nouveau appelé a fin de killer les sessions iperf plantées. iperf3 plante soit en sortant du programme, soit en affichant a l'infini 0 octets transféré, tout en consommant 100% d'un cœur.

Code: [Sélectionner]

#!/bin/dash
/bin/sleep 10
/usr/bin/killall iperf3
/bin/sleep 0.1
if [ `ps -C iperf3 | wc -l` != "1" ]
then
  /usr/bin/killall -9 iperf3
  /bin/sleep 0.1
fi
if [ `ps -C iperf3 | wc -l` = "1" ]
then
  echo "lancement de iperf3"
  /usr/bin/sudo -u nobody "/usr/bin/iperf3 -s -p 5200 -J | python /home/vgu/scripts/iperf3tocvs.py >/home/log/iperf3/access5200 2>&1 &"
  /usr/bin/sudo -u nobody "/usr/bin/iperf3 -s -p 5201 -J | python /home/vgu/scripts/iperf3tocvs.py >/home/log/iperf3/access5201 2>&1 &"
  /usr/bin/sudo -u nobody "/usr/bin/iperf3 -s -p 5202 -J | python /home/vgu/scripts/iperf3tocvs.py >/home/log/iperf3/access5202 2>&1 &"
  /usr/bin/sudo -u nobody "/usr/bin/iperf3 -s -p 5203 -J | python /home/vgu/scripts/iperf3tocvs.py >/home/log/iperf3/access5203 2>&1 &"
  /usr/bin/sudo -u nobody "/usr/bin/iperf3 -s -p 5204 -J | python /home/vgu/scripts/iperf3tocvs.py >/home/log/iperf3/access5204 2>&1 &"
  /usr/bin/sudo -u nobody "/usr/bin/iperf3 -s -p 5205 -J | python /home/vgu/scripts/iperf3tocvs.py >/home/log/iperf3/access5205 2>&1 &"
  /usr/bin/sudo -u nobody "/usr/bin/iperf3 -s -p 5206 -J | python /home/vgu/scripts/iperf3tocvs.py >/home/log/iperf3/access5206 2>&1 &"
  /usr/bin/sudo -u nobody "/usr/bin/iperf3 -s -p 5207 -J | python /home/vgu/scripts/iperf3tocvs.py >/home/log/iperf3/access5207 2>&1 &"
  /usr/bin/sudo -u nobody "/usr/bin/iperf3 -s -p 5208 -J | python /home/vgu/scripts/iperf3tocvs.py >/home/log/iperf3/access5208 2>&1 &"
  /usr/bin/sudo -u nobody "/usr/bin/iperf3 -s -p 5209 -J | python /home/vgu/scripts/iperf3tocvs.py >/home/log/iperf3/access5209 2>&1 &"
  /usr/bin/sudo -u nobody "/usr/bin/iperf3 -s -p 5210 -J | python /home/vgu/scripts/iperf3tocvs.py >/home/log/iperf3/access5210 2>&1 &"
  echo "iperf3 ok"
fi

kgersen · « **Réponse #10 le:** 06 juin 2016 à 12:31:09 »

oula tu vas vite en besogne la, le script n'est pas encore fini et tu deplois déja...

pour le moment j'ai juste le parsing du json et l'accumulation des volumes par IP.
il manque encore les parametres de seuil, le 'pilotage' d'iptables et la whitelist (éventuellement).
une fois tout cela fait, il restera le plus compliqué: la gestion des erreurs et les cas particuliers (genre iperf qui plante).

A terme j'envisage aussi de ne plus utiliser splitstream puisqu'il requiert une installation.

Idéalement le script devrait lancer lui meme iperf3, le surveiller et le relancer si plantage mais on va faire simple dans un premier temps.

si tu veux un log, on facilement ajouter la date et l'heure de chaque test.

Quid du nettoyage d'iptables ? une IP bloquée c'est a vie ou uniquement via un déblocage manuel ?

ps: si le script tourne en nobody,je doute qu'il puisse modifier iptables. Dans ce cas faudra faire 2 scripts et transmettre les IP a bloquer a un process root. c'est peut-etre pas plus mal.

vivien · « **Réponse #11 le:** 06 juin 2016 à 13:02:36 »

Si on a accès à des log proche d'Apache2, on peut utiliser d'autres outils d'analyse de log.

Je me demande si le mieux n'est pas de se limiter à faire d'iperf un vrai serveur, avec des logs proche du format Apache et pourquoi pas gérer les plantages et blocage avec utilisation de 100% du CPU.