règles iptables contre un flood

Support Debian
#1

Bonjour,

J’utilise tcpdump pour avoir des infos sur le trafic ce qui donne ça:

00:00:40.283608 IP (tos 0x0, ttl 111, id 49690, offset 0, flags [none], proto UDP (17), length 32) 144.43.76.219.4144 > ip: UDP, length 4 0x0000: 4500 0020 c21a 0000 6f11 1a1e 902b 4cdb E.......o....+L. 0x0010: ------ 000c c12f 0870 ac49 .....0.(.../.p.I 0x0020: 0000 0000 0000 0000 0000 2664 94d4 ..........&d.. 00:00:40.283618 IP (tos 0x0, ttl 111, id 3998, offset 0, flags [none], proto UDP (17), length 32) 2.111.24.152.15506 > ip: UDP, length 4 0x0000: 4500 0020 0f9e 0000 6f11 8e9a 026f 1898 E.......o....o.. 0x0010: ------ 0a28 000c 56cd 0870 ac49 ....<..(..V..p.I 0x0020: 0000 0000 0000 0000 0000 cf20 c7dd .............. 00:00:40.283628 IP (tos 0x0, ttl 111, id 2894, offset 0, flags [none], proto UDP (17), length 32) 70.165.165.149.2071 > ip: UDP, length 4 0x0000: 4500 0020 0b4e 0000 6f11 c1b6 46a5 a595 E....N..o...F... 0x0010: ------ 000c ba14 0870 ac49 .......(.....p.I 0x0020: 0000 0000 0000 0000 0000 0000 0000 .............. 00:00:40.283639 IP (tos 0x0, ttl 111, id 50448, offset 0, flags [none], proto UDP (17), length 32) 199.213.150.49.46897 > ip: UDP, length 4 0x0000: 4500 0020 c510 0000 6f11 9627 c7d5 9631 E.......o..'...1 0x0010: ------ 000c 992d 0870 ac49 .....1.(...-.p.I 0x0020: 0000 0000 0000 0000 0000 b164 af2d ...........d.-

je voudrais bloquer ce flood, non pas les ips car ils sont toujours différents mais en fonction du paquet qui est toujours le même comme:
-I INPUT -p udp -m length --length 32 -j DROP mais ça peut gêner les utilisateurs du programme donc je pensais à un truc comme iptables -t filter -I INPUT -p udp -m ttl --ttl-eq 111 -m length --length 32 -j DROP mais ça peut changer, … enfin un truc pour ce paquet précis.

Merci.

#2

Quel programme ?
Quel est l’effet concret du flood ? Si c’est seulement une saturation de la voie descendante de la connexion réseau, alors le filtrage n’y changera rien car quand le flood arrive sur ta machine le mal est déjà fait. Un filtrage n’aura d’effet que sur une surcharge du système (ce qui est possible avec de très petits paquets comme dans ton cas), en évitant que celui-ci consacre trop de ressources à traiter ces paquets.

0x0000, 0x0010… sont les offsets en hexadécimal du début de chaque ligne de contenu du paquet. tcpdump indique que la taille de ces paquets UDP/IP est des 32 octets, soit 20 pour l’en-tête IP, 8 pour l’en-tête UDP et 4 pour les données, ce qui est assez peu. 0x0020 = 32 en décimal. Si les tous les paquets légitimes ont des offsets de 0x0030 (48 en décimal) et plus, c’est que leur taille est supérieure à 32. La taille pourrait donc être un critère discriminant pertinant, en ajoutant le port destination s’il est toujours le même.

#3

oui ce n’est pas une saturation sinon je n’aurai pas demandé de l’aide connaissant un peu le principe.
Ce flood arrive sur une application et je voudrai donc le bloquer.

20+8+4 = 32 oui, c’est ce que j’ai indiqué dans le iptables et non 4.

J’ai mieux regardé et en faite le client a bien pour se connecter un UDP, length 4 ce qui est problématique sinon j’aurai bloqué ce lenght…

Comment bloquer un paquet, toujours le même avec une signature spécifique? je peux changer de commande tcpdump pour avoir d’autres infos peut être?

#4

S’il y a un motif spécifique dans les paquets du flood qu’on ne retrouve pas dans les paquets légitimes, tu peux utiliser la correspondance “string” pour le reconnaître, voire la correspondance “u32”, plus complexe mais plus puissante.

#5

oui mais j’aurai besoin d’un œil averti pour voir sil y a des motifs spécifiques, sil faut d’autres logs tcpdump que je peux fournir ou une commande précise pour avoir ces informations je suis tout ouïe.

#6

Pour cela il faudrait aussi des échantillons de paquets légitimes de même taille pour voir ce qui les différencie des paquets du flood.

#7

ok voici, avec les ips retiré ( sous “ip” et ------ ):

[code]00:43:13.546088 IP (tos 0x0, ttl 107, id 3053, offset 0, flags [none], proto UDP (17), length 32)
ip > ip: UDP, length 4
0x0000: 4500 0020 0bed 0000 6b11 124b c500 da06 E…k…K…
0x0010: ------ 000c 46be 842b 279f …(…F…+’.
0x0020: 0000 0000 0000 0000 0000 0000 0000 …

00:43:14.366774 IP (tos 0x0, ttl 111, id 17560, offset 0, flags [none], proto UDP (17), length 32)
ip > ip: UDP, length 4
0x0000: 4500 0020 4498 0000 6f11 fb62 699d 0fa7 E…D…o…bi…
0x0010: ------ 000c 32f0 c02b 2674 …K.(…2…+&t
0x0020: 0000 0000 0000 0000 0000 b7d3 11bf …

00:43:14.561093 IP (tos 0x0, ttl 114, id 26571, offset 0, flags [none], proto UDP (17), length 32)
ip > ip: UDP, length 4
0x0000: 4500 0020 67cb 0000 7211 9491 575a 6288 E…g…r…WZb.
0x0010: ------ 000c 22e0 002b a8b6 …{.(…"…+…
0x0020: 0000 0000 0000 0000 0000 4fa3 be61 …O…a

00:43:14.810889 IP (tos 0x0, ttl 117, id 18753, offset 0, flags [none], proto UDP (17), length 32)
ip > ip: UDP, length 4
0x0000: 4500 0020 4941 0000 7511 db6e 5d1a 3175 E…IA…u…n].1u
0x0010: ------ 000c 8b38 482b 1fd0 …(…8H+…
0x0020: 0000 0000 0000 0000 0000 8f2d 61e5 …-a[/code]

#8

Apparemment les données de la charge utile UDP des paquets du flood contiennent toujours “0870 ac49” alors qu’elles sont différentes pour les paquets légitimes. Tu peux essayer d’ajouter [mono]-m string --algo bm --from 28 --hex-string 0870ac49[/mono] à ta règle de filtrage.

#9

merci de l’aide je vais voir ça sinon from 28 ça veut dire quoi? d’un flux upd? on ne prend pas en considération le “length”?

#10

Cf. man iptables.
Ça veut dire de ne chercher le motif qu’à partir de l’offset 28, qui correspond au début du champ de données d’un datagramme UDP. Au cas où le motif recherché se retrouve par hasard dans l’en-tête IP ou UDP d’un paquet légitime (1 chance sur 153 millions si je calcule bien).

#11

ok merci je vais tester ça mais j’ai ajouté “||” sinon ça fonctionne pas.

mais je vois que certains ont aussi ce nombre, j’ai mis des motifs croisés pour aider mais ce n’est pas possible avec tcpdump d’avoir d’autres infos? une signature vraiment unique? OU je pense que c’est le mieux limiter cette règle à 10 connections par seconde ( si l’ip est déjà considéré en +1 le laisser ) et le reste si c’est > à 10 drop, mais je sais pas la forme sil faut drop ou accept.

#12

Où as-tu dû rajouter “||” ?

Certains quoi ?
Tcpdump ne fait qu’afficher les paquets émis ou reçus et leur contenu, ce n’est pas lui qui va trouver une signature tout seul ni dire si un paquet est légitime ou une attaque.

Je ne comprends pas ce que tu veux dire à partir de la parenthèse.

#13

–hex-string |0870ac49| ici sans c’est seulement pour “string”, ça fonctionne mieux.

Pour tcpdump c’était pour savoir sil y avait d’autres commandes plus précises sur le paquet, je sais bien que ça ne va pas trouver une signature tout seul.

Pour la meilleur règle possible, comme il y a des falses positives c’est de mettre:

-I INPUT -p udp -m ttl --ttl-eq 111 -m string --algo bm --from 28 --hex-string 0870ac49 + dire de laisser quand même passer ce contenu mais à 10 paquets ou 10 ips par seconde ( je sais pas si c’est possible le top c’est 10 ips, ainsi un ip déjà compté puisse faire autant de requête).

J’ai testé -I INPUT -p udp -m ttl --ttl-eq 111 -m string --algo bm --from 28 --hex-string 0870ac49 -m limit --limit 10/second -j ACCEPT ou drop mais soit ça bloque tout ou rien.

Pareil laisse tout passer -I INPUT -p udp -m ttl --ttl-eq 111 -m string --algo bm --from 28 --hex-string 0870ac49 -m recent --set --I INPUT -p udp -m ttl --ttl-eq 111 -m string --algo bm --from 28 --hex-string 0870ac49 -m recent --update --seconds 2 --hitcount 20 -j DROP

j’ai plus d’idée

#14

N’ayant jamais utilisé l’option [mono]–hex-string[/mono], j’ignorais qu’il fallait encadrer les séquences en hexadécimal avec des ||, d’autant plus que cela ne figure pas dans la page de manuel ni l’aide en ligne d’iptables.

Je ne vois pas ce qu’il peut y avoir de plus précis qu’afficher le contenu complet des paquets octet par octet. Si cela ne suffit pas pour trouver un motif unique aux paquets malveillants, voire s’il n’existe pas de motif unique, je ne vois pas quoi faire de plus.

[mono]-m limit[/mono] n’aidera guère ici : d’après la capture de tcpdum, les paquets du flood sont espacés de 10 µs donc cela fait un débit de 100000 paquets/s. Comprends bien qu’une limitation à 10/s a pour effet de bloquer quasiment tous les paquets, y compris les paquets légitimes qui sont beaucoup plus rares.

Quant à [mono]recent[/mono], cela n’aidera pas non plus si l’adresse source des paquets du flood est usurpée et aléatoire. Dans le cas contraire, il faut déterminer l’ordre de grandeur du nombre d’adresses sources différentes afin de dimensionner correctement lle nombre d’adresses mémorisées, qui est de 100 par défaut. Si c’est insuffisant les adresses les plus récentes feront oublier les plus anciennes.

#15

ok merci de l’aide apportée.