Syntaxe iptables

[Drylaw]

Bonjour à tous,

je suis actuellement en train de mettre en place une passerelle sous Debian Lenny. J’en suis pour le moment au stade de la configuration du parefeu avec netfilter. Je pense avoir largement compris son fonctionnement mais je me pose néanmoins certaines questions concernant la syntaxe. Je vais prendre pour exemple le cas suivant :

iptables -A INPUT -p tcp --dport ssh -i ppp0 -j ACCEPT iptables -A OUTPUT -p tcp --sport ssh -o ppp0 -j ACCEPT

Ces règles permettent la connexion au port SSH sur notre serveur. Pas de problème l’état du segment n’étant pas indiqué, j’imagine que tous les états sont pris en compte, autrement dit les règles ci-dessous sont exactement les mêmes que celles ci-dessus:

iptables -A INPUT -p tcp --dport ssh -i ppp0 -m state --state NEW,RELATED,ESTABLISHED(etc…) -j ACCEPT
iptables -A OUTPUT -p tcp --sport ssh -o ppp0 -m state --state NEW,RELATED,ESTABLISHED(etc…) -j ACCEPT

Cette règle permet à la machine de contacter un serveur smtp en excluant l’état du segment TCP en INVALID. Faut-il systématiquement inclure ce paramètre pour ce genre de règle et est-ce véritablement dangereux de ne pas l’inclure. Si on décide de ne pas exclure cet état, la règle ci-dessous coïncide t-elle avec ce qui est souhaité :
iptables -A OUTPUT -o ppp0 -p tcp --sport 1024: --dport 25 -j ACCEPT

Tout simplement accepter tous les états des segments tcp.

Dernière chose concernant le NAT source, il est possible d’utiliser la syntaxe -SNAT avec l’ip utilisé et la syntaxe avec masquerade sans préciser l’ip. Y a-t-il des situations pour laquelle il faudrait utiliser l’une et pas l’autre et de manière générale laquelle est la plus utilisée?

Merci d’avance pour votre aide, n’hésitez pas à poster si vous avez besoin d’informations supplémentaires, il s’agit uniquement de savoir si mon raisonnement est le bon ou non.

[PascalHambourg]

Ces règles permettent la connexion au port SSH sur notre serveur.

Oui, mais pas seulement : elles permettent aussi au serveur SSH de se connecter à n’importe quoi en TCP via l’interface ppp0. C’est l’inconvénient de se baser sur le port source sans tenir compte de l’état de connexion.

autrement dit les règles ci-dessous sont exactement les mêmes que celles ci-dessus

Le résultat est le même mais les règles sont différentes. Autant alléger les règles des correspondances inutiles du genre -s 0.0.0.0/0, --sport 0:65535…

Cette règle permet à la machine de contacter un serveur smtp en excluant l’état du segment TCP en INVALID.

Mais ne permet pas au serveur de répondre.

Faut-il systématiquement inclure ce paramètre pour ce genre de règle et est-ce véritablement dangereux de ne pas l’inclure.

Cela dépend de l’objectif du jeu de règles. Une règle seule ne veut pas dire grand chose, un jeu de règles doit être un ensemble cohérent. Par exemple si on n’accepte en entrée que les paquets dans l’état ESTABLISHED ou RELATED, il n’y a pas grand intérêt à accepter en sortie les paquets dans l’état INVALID car une réponse à un tel paquet sera dans l’état INVALID et donc bloquée. D’autre part les règles de NAT ne s’appliquent pas aux paquets dans l’état INVALID, donc il vaut mieux bloquer ces paquets en présence de NAT sous peine de voir “fuir” les adresses internes vers l’extérieur.

Dernière chose concernant le NAT source, il est possible d’utiliser la syntaxe -SNAT avec l’ip utilisé et la syntaxe avec masquerade sans préciser l’ip. Y a-t-il des situations pour laquelle il faudrait utiliser l’une et pas l’autre et de manière générale laquelle est la plus utilisée?

SNAT est plus adapté si l’adresse est fixe (elle peut être dynamique et fixe) et connue, ou pour NATer avec une adresse autre que l’adresse de l’interface. MASQUERADE est plus adapté pour NATer avec l’adresse de l’interface si elle est variable ou inconnue. Il y a eu des cas où MASQUERADE ne marchait pas toujours bien avec les règles de routage avancé, mais il me semble que c’est corrigé dans les noyaux actuels.