inetdoc.net

Il y a certaines fonctionnalités d'iptables qui ne sont pas très bien documentées et qui peuvent être laissées de côté par certaines personnes (y compris moi). Si vous utilisez l'état NEW, les paquets avec le bit SYN non placé traverseront votre pare-feu. Cette fonctionnalité existe car dans certains cas nous pouvons considérer qu'un paquet peut faire partie d'une connexion déjà ESTABLISHED sur, par exemple, un autre pare-feu. Cette fonctionnalité offre la possibilité d'avoir deux ou plusieurs pare-feux, et un des pare-feux peut être désactivé sans perte de données. Le pare-feu du sous-réseau peut alors être remplacé par un pare-feu secondaire. Ceci peut conduire cependant au fait que l'état NEW autorisera toute sorte de connexion TCP, sans se soucier si c'est un établissement de liaison à trois voies ou non. Pour surveiller ce problème nous ajoutons les règles suivantes à nos pare-feux dans les chaînes INPUT, OUTPUT et FORWARD.

$IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j LOG \
     --log-prefix "New not syn:"
$IPTABLES -A INPUT -p tcp ! --syn -m state --state NEW -j DROP

	Attention
	Les règles ci-dessus surveillent ce problème. C'est un comportement mal documenté du projet Netfilter/iptables qui devrait être mis en avant.

Notez qu'il existe certains problèmes avec les règles ci-dessus et les mauvaises implémentations TCP/IP de Microsoft. Ces règles peuvent provoquer dans certaines conditions que des paquets générés par des produits Microsoft soient labellisés avec l'état NEW et soient journalisés et supprimés. À ma connaissance, ça ne produit cependant pas de coupure de connexion. Le problème survient lorsque la connexion est fermée, le FIN/ACK final est envoyé, la machine d'état de Netfilter ferme la connexion et n'apparaît plus dans la table conntrack. À ce moment l'implémentation Microsoft envoie un autre paquet considéré comme NEW mais il manque le bit SYN, il est donc examiné par les règles. En d'autres termes, ne vous inquiétez pas trop à propos de cette règle, ou alors placez l'option --log-headers dans la règle et journalisez les en-têtes, ainsi vous aurez une meilleure vision de ce à quoi ressemble le paquet.

Il y a un problème plus connu avec ces règles. Si quelqu'un est connecté au pare-feu, depuis le LAN, et que vos scripts sont prévus pour s'activer lors du lancement d'une connexion PPP. Dans ce cas, quand vous démarrez une connexion PPP, la personne connectée depuis le LAN sera plus ou moins supprimée. Ceci s'applique seulement quand vous travaillez avec les codes nat et conntrack en modules, et que les modules sont chargés et déchargés chaque fois que vous lancez le script. Une autre façon de rencontrer ce problème est de lancer le script rc.firewall.txt par une connexion en telnet depuis un hôte non présent sur ce pare-feu. Pour l'ajouter simplement, connectez vous en telnet ou autre type de connexion. Démarrez la connexion en traçant les modules, ensuite chargez les règles de paquet NEW non-SYN. Enfin, le client telnet ou le démon tentera d'envoyer quelque chose. Le code du traçage de connexion ne reconnaîtra pas cette connexion comme légale car il n'a pas vu les paquets dans aucune direction auparavant, ainsi il n'y aura aucun bit SYN de placé car ce n'est pas le premier paquet de la connexion. Ce paquet sera examiné avec les règles, journalisé et ensuite supprimé.