SYN/ACK et les paquets NEW

Certaines attaques par mystification TCP utilisent une technique appelée Sequence Number Prediction. Dans ce type d'attaque, l'attaquant mystifie certaines adresses IP d'hôtes, et essaie de prédire la suite de chiffres utilisée par l'hôte.

Regardons un cas typique de mystification TCP (TCP spoofing) par prédiction de suite de chiffres. Les joueurs : "l'attaquant" [A], tente d'envoyer des paquets à la "victime" [V], prétendant être un "autre hôte" [O].

1. [A] envoie un SYN vers [V] avec l'adresse IP source de [O].

2. [V] répond à [O] par un SYN/ACK.

3. donc [O] répondra à un SYN/ACK inconnu par RST et l'attaque sera réussie, mais nous supposons que [O] est déconnecté.

4. [A] peut maintenant parler à [V] en prétendant être [O] tant qu'il peut prédire correctement la séquence de chiffres.

Tant que nous n'envoyons pas le paquet RST au SYN/ACK inconnu à l'étape 3, nous permettons à [V] d'être attaqué, et nous mêmes seront incriminés. La courtoisie serait désormais, d'envoyer le RST à [V] de façon correcte. Si nous utilisons les règles NEW non-SYN spécifiées dans la table de règles, les paquets SYN/ACK seront supprimés. Nous aurons donc les règles suivantes dans la chaîne bad_tcp_packets, juste au-dessus des règles NEW non-SYN :

iptables -A bad_tcp_packets -p tcp --tcp-flags SYN,ACK SYN,ACK \
-m state --state NEW -j REJECT --reject-with tcp-reset
   

Une chance serait que [O] dans ce scenario soit relativement petit, mais ces règles seront sûres dans la plupart des cas. Sauf quand vous utilisez plusieurs pare-feux redondants qui prennent la suite des paquets ou des flux de chacun des autres. Dans ces cas là, certaines connexions peuvent être bloquées, même si elles sont légales. Cette règle peut aussi autoriser certains balayages de port, pour voir ce qui apparaît au niveau de notre pare-feu, mais elle ne pourra pas en dévoiler d'avantage.