Saluts,
-edit-
[quote=“ricardo”]Tu voudras bien ajouter, en tête de ton premier message le lien vers la source sur une ligne bien visible et en rouge.
[/quote]
Avec grand plaisir.
Un partage, glané sur la toile … ici … par Philippe Latu … 
Bloquer tout trafic entre un client plus que suspect et le réseau public.
Iptstate, Conntrack & Arptables utilisation.
Pour donner suite à la présentation d’ipsate … ici.
iptstate
Il est fourni dans le paquet du même nom. Avec cet outil, on obtient un affichage top-like de la table des communications suivies par les modules de filtrage netfilter.
Il permet d’obtenir une vue complète des communications entre les postes auxquels on a affecté une adresse IP privée et les adresses IP publiques avec lesquelles ils communiquent.
On peut organiser l’affichage en cours de façon à identifier une source unique en communications avec de multiples destinations.
À l’aide de la touche “b” on fait défiler l’ordre de tri jusqu’au critère sur les adresses IP destination : DstIP.
On inverse l’ordre d’affichage à l’aide de la touche “r”.
Le but est de faire apparaître les adresses IP destination publiques sur la colonne du milieu en vis à vis de notre adresse IP source unique sur la colonne de gauche.
Ce mode opératoire nous fournit une photographie instantanée qui permet de détecter le caractère suspect du trafic en cours.
Pour aller plus loin, il faut quantifier ces communications suspectes. On utilise iptstate pour ce travail.
On passe en mode exécution unique (one-shot) et on obtient un résultat sous forme texte.
[code]# head -10 suspect-trace.txt
aa.bb.cc.204:50470 74.125.230.83:80 tcp TIME_WAIT 0:01:49
aa.bb.cc.204:50435 67.228.29.179:80 tcp TIME_WAIT 0:01:53
aa.bb.cc.204:52280 dd.ee.ff.11:53 udp 0:00:19
aa.bb.cc.204:50429 216.155.153.103:80 tcp TIME_WAIT 0:01:53
aa.bb.cc.204:50398 206.217.201.99:80 tcp TIME_WAIT 0:00:43
aa.bb.cc.204:50394 74.125.230.81:80 tcp ESTABLISHED 119:59:30
aa.bb.cc.204:50395 206.217.201.99:80 tcp TIME_WAIT 0:00:43
aa.bb.cc.204:50451 38.99.76.103:80 tcp TIME_WAIT 0:01:47
aa.bb.cc.204:49389 209.85.146.102:80 tcp ESTABLISHED 119:59:47
aa.bb.cc.204:59765 212.161.8.6:443 tcp ESTABLISHED 119:58:24
grep -c aa.bb.cc.204 suspect-trace.txt
94[/code]
La lecture du fichier suspect-trace.txt fait ressortir l’adresse IP source aa.bb.cc.204.
Le comptage des adresses IP destination en communication avec notre «client» est de 94 sur un seul prélèvement d’échantillons.
À ce stade, aucun doute n’est permis sur ce «client», nous sommes bien en présence de trafic non conforme avec la politique de sécurité de notre machine.
On essayera de traiter le «client» comme il se doit.
Le traitement le plus simple à appliquer dans notre cas consiste à bloquer tout trafic entre notre «client plus que suspect» et le réseau public.
Une petite recherche dans les journaux système montre que l’adresse IP aa.bb.cc.204 a été obtenue via un bail DHCP.
Le premier réflexe, pas forcément futé, est d’appliquer un filtrage utilisant l’adresse IP sur les chaînes INPUT et FORWARD des règles iptables.
Dans la précipitation, il ne faut pas se tromper dans l’implantation de ces nouvelles règles vis-à-vis du mécanisme de suivi des communications.
Pour de plus amples information reportez vous à l’introduction au filtrage réseau avec netfilter/iptables ici .
Avant de prendre une décision péremptoire et définitive,il est intéressant de travailler sur les entrées enregistrées dans les tables de suivi netfilter pour mesurer le niveau «d’agressivité» du trafic réseau émis par notre «client».
L’outil conntrack, encore fourni avec le paquet du même nom, permet d’intervenir sur ces entrées déjà enregistrées.
On utilise cet outil pour supprimer les enregistrements ayant pour source l’adresse IP incriminée.
# conntrack -D -s aa.bb.cc.204
tcp 6 431950 ESTABLISHED src=aa.bb.cc.204 dst=74.125.230.81 sport=50394 \
dport=80 packets=19 bytes=9507 src=74.125.230.81 dst=xx.yy.zz.2 sport=80 \
dport=50394 packets=17 bytes=14523 [ASSURED] mark=0 secmark=0 use=2
<snipped/>
tcp 6 94 TIME_WAIT src=aa.bb.cc.204 dst=76.73.68.226 sport=50441 dport=80 \
packets=6 bytes=1183 src=76.73.68.226 dst=xx.yy.zz.2 sport=80 dport=50441 \
packets=5 bytes=415 [ASSURED] mark=0 secmark=0 use=2
conntrack v0.9.14 (conntrack-tools): 142 flow entries have been deleted.
Cette fois ci on relève 142 entrées pour notre «client» que l’on trouve décidément trop bavard. Le truc ici consiste à patienter quelques secondes avant de relancer la même commande.
En effet, dans le cas d’un comportement normal, l’utilisateur perd sa connexion TCP au serveur web puis tente de rafraîchir la page ou relance son navigateur.
Ces opérations prennent du temps et ne doivent pas provoquer l’enregistrement d’un grand nombre de nouvelles entrées dans les tables netfilter.
En revanche, si une nouvelle exécution de la commande d’effacement deux seconde plus tard provoque l’effacement d’un nombre anormal d’entrées, on obtient une confirmation supplémentaire et les derniers doutes sur la nocivité du trafic observé s’estompent.
# conntrack -D -s aa.bb.cc.204
tcp 6 87 TIME_WAIT src=aa.bb.cc.204 dst=74.86.190.242 sport=50542 dport=80 \
packets=5 bytes=955 src=74.86.190.242 dst=xx.yy.zz.2 sport=80 dport=50542 \
packets=5 bytes=534 [ASSURED] mark=0 secmark=0 use=2
tcp 6 431977 ESTABLISHED src=aa.bb.cc.204 dst=77.242.194.130 sport=50536 \
dport=80 packets=4 bytes=668 src=77.242.194.130 dst=xx.yy.zz.2 sport=80 \
dport=50536 packets=4 bytes=1374 [ASSURED] mark=0 secmark=0 use=2
<snipped/>
tcp 6 85 TIME_WAIT src=aa.bb.cc.204 dst=178.162.189.15 sport=50528 dport=80 \
packets=6 bytes=999 src=178.162.189.15 dst=xx.yy.zz.2 sport=80 dport=50528 \
packets=9 bytes=8213 [ASSURED] mark=0 secmark=0 use=2
conntrack v0.9.14 (conntrack-tools): 70 flow entries have been deleted.
On passe au filtrage de l’adresse IP. On place donc deux règles qui jettent les paquets IP émis par le «client» et à destination de celui-ci dans la chaîne FORWARD.
Ces règles doivent être placées en tête de liste avant celles consacrées au suivi des communications enregistrées comme valides.
Iptables montre que les compteurs se «mettent à tourner» rapidement.
Le filtrage est donc efficace, au moins dans un premier temps.
# iptables -vL FORWARD
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- lo any anywhere anywhere
1172 78925 DROP all -- any any aa.bb.cc.204 anywhere
8 384 DROP all -- any any anywhere aa.bb.cc.204
3 180 ACCEPT icmp -- any any anywhere anywhere state ESTABLISHED
0 0 ACCEPT icmp -- any any anywhere anywhere icmp destination-unreachable state RELATED
0 0 ACCEPT icmp -- any any anywhere anywhere icmp time-exceeded state RELATED
12 1104 ACCEPT udp -- any any anywhere anywhere state RELATED,ESTABLISHED
2649 884K ACCEPT tcp -- any any anywhere anywhere tcp flags:!FIN,SYN,RST,ACK/SYN state ESTABLISHED
0 0 ACCEPT tcp -- any any anywhere anywhere tcp flags:FIN,SYN,RST,ACK/SYN state RELATED
1 60 ACCEPT icmp -- any any anywhere anywhere icmp echo-request limit: avg 5/sec burst 5 state NEW
<snipped/>
C’était sans compter sur l’esprit taquin de notre «client».Constatez avec effroi que le trafic a repris de plus belle.
Celui-ci n’avait rien trouvé de mieux à faire que de négocier un nouveau bail DHCP avec une nouvelle adresse IP différente de la précédente.
Il ne restait plus qu’à reprendre le travail en se basant sur l’adresse MAC de la source de ce trafic toujours aussi gênant.
De cette façon, quel que soit l’adresse IP le trafic serait bloqué. À la différence du cas précédent, iptables ne filtre que les adresses MAC source.
On ne peut donc utiliser qu’une seule règle de la forme suivante.
Une fois de plus les résultats semblent efficaces.
# iptables -vL FORWARD
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- lo any anywhere anywhere
1690 100K DROP all -- any any anywhere anywhere MAC 00:50:BA:2D:A5:72
12715 756K ACCEPT icmp -- any any anywhere anywhere state ESTABLISHED
11 1037 ACCEPT icmp -- any any anywhere anywhere icmp destination-unreachable state RELATED
0 0 ACCEPT icmp -- any any anywhere anywhere icmp time-exceeded state RELATED
123K 54M ACCEPT udp -- any any anywhere anywhere state RELATED,ESTABLISHED
18M 6092M ACCEPT tcp -- any any anywhere anywhere tcp flags:!FIN,SYN,RST,ACK/SYN state ESTABLISHED
0 0 ACCEPT tcp -- any any anywhere anywhere tcp flags:FIN,SYN,RST,ACK/SYN state RELATED
3203 184K ACCEPT icmp -- any any anywhere anywhere icmp echo-request limit: avg 5/sec burst 5 state NEW
<snipped/>
Comment filtrer les trames ayant pour destination l’adresse MAC incriminée ? C’est là qu’intervient l’outil arptables qui est, fourni par le paquet du même nom.
La syntaxe des règles est vraiment très voisine de celles employées avec iptables. La règle qui convient à notre «client» est de la forme suivante.
# arptables -A FORWARD --dst-mac 00:50:ba:2d:a5:72 -j DROP
Là encore, le travail n’a pas été fait en vain puisque les compteurs se sont aussi incrémentés.
# arptables -vL FORWARD
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
-j DROP -i any -o any --dst-mac 00:50:ba:2d:a5:72 , pcnt=89 -- bcnt=2492
Après ces dernières règles de filtrage, le «client» a manifestement jeté l’éponge.
Rien à ajouté !
Si ce n’est …
Je vous en serre cinq …
