web-dev-qa-db-fra.com

Est-il sûr de désactiver le suivi des connexions dans iptables?

En lisant sur NOTRACK cible de la table raw dans iptables, j'ai rencontré un article suggérant que pour certains trafics, vous pouviez (ou même deviez) désactiver le suivi de connexion. Les deux exemples étaient: (1) toutes sortes de paquets routés et (2) si vous avez un serveur Web ou d'autres services qui consomment des ressources, vous devez également désactiver le suivi de connexion pour ce service. Je n'ai pas de serveur Web, mais j'ai des clients p2p. Voici les règles standard pour le suivi des connexions:

iptables -t filter -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -t filter -A INPUT -m conntrack --ctstate INVALID -j DROP
iptables -t filter -A INPUT -p udp -m conntrack --ctstate NEW -j udp
iptables -t filter -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j tcp

et dans les chaînes udp et tcp j'ouvre le port pour un client torrent en utilisant:

iptables -t filter -A udp -p udp --dport 33333 -m conntrack --ctstate NEW -j ACCEPT
iptables -t filter -A tcp -p tcp --dport 33333 -m conntrack --ctstate NEW -j ACCEPT

Lorsque je vérifie les entrées conntrack:

# cat /proc/net/nf_conntrack | wc -l
3569

Maintenant, l'option serait de définir NOTRACK dans raw table pour ce type de trafic, par exemple:

iptables -t raw -A notrack_in -p udp --dport 33333 -j NOTRACK
iptables -t raw -A notrack_in -p udp --dport 33333 -j ACCEPT
iptables -t raw -A notrack_in -p tcp --dport 33333 -j NOTRACK
iptables -t raw -A notrack_in -p tcp --dport 33333 -j ACCEPT

et il a également besoin de deux règles dans la table de filtrage:

iptables -t filter -A INPUT -p udp --dport 33333 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 33333 -j ACCEPT

Après cette opération, le nombre d'entrées dans /proc/net/nf_conntrack est tombé à 150-200 et il n'y a pas de ligne avec le port 33333.

Ma question est la suivante: est-il sûr de désactiver le suivi des connexions? Cela nécessiterait-il d'ajouter des règles à iptables? Quels sont les avantages et les inconvénients de cette solution?

linuxfirewallsiptables
12
Mikhail Morfikov

La réponse courte

En règle générale, vous n'aurez besoin du suivi des connexions que pour les connexions sortantes. Si un périphérique local établit une connexion à Internet, le pare-feu enregistre que cette IP et ce port spécifiques ont tenté d'établir une connexion avec l'autre IP et le port.

Ainsi, lorsque la réponse d'Internet arrive, le pare-feu sait le laisser passer, car il a déjà vu un paquet sortant. S'il n'y avait pas de suivi de connexion en place, vous devrez placer des règles explicites quant à l'endroit où ou où un paquet peut voyager (par exemple, autorisez tous les paquets du port 80 de google.com). Il est facile de voir que cela compliquerait les règles du pare-feu.

La réponse longue

Il n'y a que des différences subtiles entre les deux solutions si elles sont utilisées pour les connexions entrantes. Une différence est sur quel système se produit la charge CPU de vérification des paquets. Si vous avez un ordinateur/routeur/pare-feu dédié (appelé pare-feu à partir d'ici), avec le suivi de connexion activé, cet appareil vérifiera au moins la plausibilité d'un paquet. Cela libérera le serveur d'applications (le serveur recevant les paquets) de le faire.

La plausibilité fait référence au fait que le paquet provient de l'hôte attendu et du port attendu dans le cas d'UDP, et en plus du numéro de séquence dans le cas de TCP.

Habituellement, la validation ne peut se produire qu'à l'intérieur de la couche application, car la validité ne peut être garantie qu'en fonction du protocole de l'application elle-même.

Ces hypothèses ont trois conséquences:

  • La charge CPU et réseau est déplacée vers le "Edge" du réseau en cas de suivi d'état. Cela signifie que (généralement) le premier appareil de votre réseau effectuera une inspection de base du paquet, avant de le transmettre au réseau local, gardant ainsi votre interne réseau propre et la charge sur le pare-feu.
  • Le serveur d'applications n'aura qu'à se soucier de la validité du paquet, c'est-à-dire si les données à l'intérieur du paquet sont conformes au protocole attendu.
  • Cela pourrait ouvrir la possibilité de dépasser une connexion UDP, selon le protocole. Si l'application n'a aucun moyen (ou aucun moyen fiable) d'authentifier l'expéditeur d'un paquet, elle accepterait la charge utile correcte à partir de n'importe quelle adresse IP. Par exemple, dans une transmission de données, il serait possible d'envoyer des ordures au récepteur, si le paquet UDP réussit la validation.

Néanmoins, la pratique courante (sauf dans les environnements à haute sécurité) consiste à utiliser le suivi de connexion (général) uniquement pour les connexions sortantes, afin de ne pas avoir à autoriser explicitement chaque serveur Internet à répondre à une demande du réseau local. Dans le cas des connexions entrantes, vous autorisez généralement vraiment juste le port (défini) à être accessible (-A INPUT -p tcp --dport 80 -j ACCEPT). Cela s'appliquerait aux nouvelles connexions, mais s'appliquerait également aux connexions existantes, en évitant la surcharge, pour garder une trace de la connexion. De même, vous ne transférez que des paquets vers un port de destination spécifique vers un serveur d'applications à l'intérieur de votre réseau local.

suivi des connexions spécifiques à l'application

Il y a un cas que je n'ai pas encore mentionné et c'est le suivi de connexion spécifique à l'application. Pour quelques protocoles (ftp, irc, tftp, amanda, sip et éventuellement d'autres, voir http://www.iptables.info/en/connection-state.html#COMPLEXPROTOCOLS par exemple) il peut y avoir être des modules iptables spéciaux pour permettre un suivi avancé de la connexion. Par exemple, en FTP, vous ouvririez une connexion du client au serveur sur le port 21, appelée connexion de contrôle, qui devrait être ouverte dans le pare-feu par des moyens normaux. À l'intérieur de ce canal, le client et le serveur définissent ensuite une deuxième connexion où les données brutes du fichier seront envoyées. Habituellement, cette connexion est établie du serveur au client (en mode ACTIF). Ce port local et distant est apparemment aléatoire, il est donc impossible de le définir dans un fichier de configuration de pare-feu statique. S'il y avait un pare-feu avec iptables sur le réseau du client, il refuserait cette connexion, car il n'y a aucune ancienne association. Avec le suivi de connexion spécifique à l'application, le module examinerait le contenu du paquet pour voir si un tel accord a été conclu et le pare-feu autoriserait une nouvelle connexion entrante sur le port convenu, même s'il n'y avait pas de connexion auparavant.

13
Spacy