Repérer les scans lents
Repérer les scans lents jppRepérer les scans "lents" avec NtopNG.
SI vous stockez les données de flux dans une base Mysql avec une certaine durée il est possible de repérer les scans de ports, même lents, de manière simple à l'aide d'un ordre SQL simple.
Cela permet de repérer les adresses IP qui scannent très lentement pour éviter d'être repérées trop facilement, et de les bloquer avec un "ipset" bien placé dans votre pare-feu. Attention les adresses IP sont stockées dans le format interne de Mysql et il faut utiliser les fonctions "inet_aton" et "inet_ntoa".
Ici on sélectionne les IP qui ont "atteint" plus de 10 ports (sans données retournees) sur les 10 derniers jours :
select inet_ntoa(IP_SRC_ADDR) SRC,inet_ntoa(IP_DST_ADDR) DST, count(distinct L4_DST_PORT) NPORT from flowsv4 where FIRST_SWITCHED > UNIX_TIMESTAMP(DATE_SUB(now(), interval 10 day)) and IP_SRC_ADDR not between inet_aton('192.168.1.1') and inet_aton('192.168.3.255') and L4_DST_PORT < 32768 and OUT_BYTES 0 group by 1,2,4 having NPORT > 10 order by IP_SRC_ADDR; |
Ne pas oublier de ne sélectionner que les ports inférieurs à la limite sur votre système :
sudo sysctl -a 2>/dev/null | grep local_port_range
afin de ne pas bloquer de clients légitimes.
Cet ordre permet de repérer les adresses IP d'origine de scans lents sur 10 jours (ou plus si votre historique est plus long) concernant plus de 10 ports différents.
Il est très facile ensuite à partir de la liste obtenue de bloquer ces adresses en les intégrant dans un "set" exploité dans un pare-feu.
L'exécution de ce script peut être assez longue selon le nombre de rangs contenus dans la table principale malgré un index favorable sur le timestamp, mais il peut être lancé quelques fois chaque jour sans surcharge excessive.
Ici ce type de recherche est exploité "manuellement" pour tenir à jour une liste d'adresses IP à éviter, voir article spécifique ici.