Comprendre iptables

Support Debian
#1

j’ai installé iptables façon Alexis sans trop approfondir

aujourd’hui, j’essis de comprendre un peu plus et ce n’est pas une mince affaire

voilà mon soucis :

mon fichier de configuration est celui-ci
#!/bin/sh
#####################################################################

TOUT FERMER

#####################################################################

vider les chaînes

/sbin/iptables -F

supprimer d’éventuelles chaînes personnelles :

/sbin/iptables -X

faire pointer par défaut sur DROP

/sbin/iptables -P INPUT DROP
/sbin/iptables -P OUTPUT DROP
/sbin/iptables -P FORWARD DROP

#####################################################################

REGLES GENERALES

#####################################################################

permettre le retour vers la machine des infos demandées auprès des sites web.

En l’absence de cette règle, la navigation deviendrait difficile. C’est relativement important

/sbin/iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

autorise tous ce qui sort

/sbin/iptables -A OUTPUT -o eth0 -j ACCEPT

#####################################################################

OUVRIR LES PORTS

#####################################################################

Sur la machine elle meme

/sbin/iptables -A INPUT -i lo -j ACCEPT
/sbin/iptables -A OUTPUT -o lo -j ACCEPT

je n’ai pas ouvert le port 80 (web) et portant j’y ai accès avec iceweasel
je pense que cela vient de la ligne :
/sbin/iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
qui fait mémoriser au système l’accès qu’évidemment j’avais avant de vouloir le bloquer
idem pour d’autre port comme le 27 (ftp)

pouvez m’aider à comprendre ?

#2

Salut, tient tu aura peut etre ta réponse içi:
coagul.org/article.php3?id_article=485
christian.caleca.free.fr/netfilter/iptables.htm

voili voilou… :smt001

#3

merci mais je les connaissais et même en les relisant je ne comprends toujours pas.

j’ai même ajouter :
/sbin/iptables -A INPUT -i eth0 -p TCP --dport http -j REJECT

et bien j’ai encore accès au web

si je supprime la ligne :
/sbin/iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

je n’ai plus d’accès du tout même en autorisant le port 80 ???

#4

tu as lu le tuto ds T&A ?

#5

je les connais aussi ces topics pour les avoir lu et relu.
Il n’y as pas beaucoup de différences avec ce que propose Alexis

on y retrouve
les Drop
la fameuse :
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
et les ouverture de ports

mais pourquoi quand on n’autorise pas un port, il suffit d’écrire la fameuse pour y avoir accès et sans cette fameuse, on a plus d’accès même en autorisant le port ???

certes je suis loin d’avoir compris toutes les subtilités d’iptables qui me semble être un outils puissant mais il me semble avoir respecter (copier coller) la procédure d’Alexis.

je vais essayer de faire un copier coller du fichier proposé dans T&A et voir si le problème subsiste

A tout à l’heure

#6

le fichier T&A
#!/bin/sh
iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -p icmp -j DROP
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 20 -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 21 -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
#iptables -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 631 -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 5222 -j ACCEPT

j’ai commenter la ligne concernant le port 80
et j’ai accès au web

alors que si j’ai bien compris les DROP ferment tous et qu’on autorise ensuite port par port

je ne comprends pas ?

#7

Bon… c’est pas gagné. D’ailleurs je ne sais même pas comment commencer cette réponse.

Il y a un malentendu fondamental entre nous et iptables. Nous raisonnons en termes de “connexions”, alors que les règles iptables s’appliquent à des paquets individuels. Nous disons par exemple “je veux autoriser les connexions HTTP sortantes”, alors que les règles iptables disent par exemple “accepter les paquets reçus par telle interface ayant tel protocole, port destination, adresse source…”. Heureusement, le suivi de connexion (conntrack) est là pour faire le lien entre les deux, notamment grâce à la correspondance “state”.

Pour comprendre un jeu de règles utilisant le suivi de connexion, il faut donc connaître les caractéristiques des paquets qui composent une “connexion” et comprendre comment fonctionne le suivi de connexion. Cf. par exemple http://christian.caleca.free.fr/netfilter/conntrack.htm ou http://iptables-tutorial.frozentux.net/fr/c1248.html et suivantes. Il faut aussi comprendre la structure des chaînes iptables et comment les paquets les traversent.

[quote]j’ai même ajouter :
/sbin/iptables -A INPUT -i eth0 -p TCP --dport http -j REJECT

et bien j’ai encore accès au web[/quote]
Pour se limiter à la table par défaut (filter) qui sert au filtrage, les paquets reçus traversent la chaîne INPUT, les paquets émis traversent la chaîne OUTPUT. Cette règle ne concerne donc que les paquets reçus. Or dans une connexion HTTP sortante ce sont les paquets émis, vus par la chaîne OUTPUT, qui ont le port destination 80, alors que les paquets de réponse reçus du serveur vus par la chaîne INPUT ont le port source 80.

[quote]si je supprime la ligne :
/sbin/iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

je n’ai plus d’accès du tout même en autorisant le port 80 ???[/quote]
Ah çà, si tu supprimes cette règle tu bloques l’accès à tout, et pas seulement au web. En effet cette règle accepte en entrée les paquets reçus par eth0 appartenant ou liés à une connexion connue. Cela concerne tous les paquets reçus en réponse aux paquets sortants.

Une connexion est connue par le suivi de connexion à partir du moment où le premier paquet qui crée cette connexion a été accepté. Dans ton jeu de règles initial, tous les paquets sortants sont acceptés donc toutes les connexions sortantes sont créées, et tous les paquets entrants appartenant ou liés à des connexions connues sont acceptés. En langage humain, cela implique que toutes les connexions sortantes sont autorisées. Pour bloquer les connexions HTTP sortantes, il faudrait bloquer les paquets sortants ayant pour but de créer une connexion HTTP.

Edit: et vire-moi cette #&@%! de règle “iptables -A INPUT -p icmp -j DROP” nuisible !!! :angry:

#8

alors déjà petite précision, le protocol reseaux c est très long a comprendre. donc il faut d’abors savoir comment sa marche (enfin un minimum) pour ensuite y appliquer iptables (netfilter)

par cette règle tu laisses tout sortire, donc sa ne passe plus par le drop global.

conclusion 2 méthode.

soit on autorise tout et on ferme ce qui est suspect.
soit on ferme tout et on autorise aux besoin. cette méthode est la plus sure mai aussi la plus
pénible car a chaque logiciel qui est nouveau il faut rajouter la règle.

non c’est la règle plus haut.

Quand a l’icmp il te faut pas tout fermer mai le paramétrer correctement. seulement je connait pas encore suffisamment le protocole réseaux a ce sujet.

les ping son souvant requis, mai il faut en limiter le nombre pour éviter un flood par exemple (en très gros)

bref personnellement je les autorises sur ma machine de bureau mai pas sur mon serveur.

sinon un très bon tuto:
http://www.linux-france.org/prj/inetdoc/guides/iptables-tutorial/

#9

si je commence à comprendre !
j’ai ouvert tous les ports en sortie. si j’envoie un paquet par le port 53 (ou autre), je pourrais donc avoir une entré via ce port.c’est
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
qui l’autorise

donc si je n’ai pas de serveur, il est inutile que j’ouvre le port 53 (ou autre) en entrée. Est-ce exact ?

#10

Voilà.
Attention néanmoins à ne pas confondre “serveur” (programme qui fournit un service) et programme qui accepte des connexions entrantes. Il arrive qu’un client accepte des connexions entrantes, comme en mode actif FTP par exemple (mais dans ce cas particulier c’est la règle citée en conjonction avec le module {ip,nf}_conntrack_ftp qui s’occupe de tout).

#11

merci pour tous ces renseignements

ces 2 sites m’ont beaucoup appris mais le chemin est long pour tous maîtriser.

notamment, lors d’une requête sur le web, par exemple, iptables ouvre en sortie un port différent que le 80 tandis que les entrés se font sur le port 80 . Si j’ai bien compris.
ouvrir tous les ports en sortie ne pose t’il pas un problème de sécurité et si c’est le cas, n’est-il pas possible de réduire la plage des ports de sortie à ouvrir.

#12

Non, pas exactement. Iptables lui-même n’ouvre aucun port ni en entrée ni en sortie, il ne fait qu’accepter ou bloquer des paquets en entrée ou en sortie. C’est le programme client web qui ouvre un port local généralement choisi dynamiquement entre 1024 et 65535, par exemple 12345, pour établir une connexion TCP avec un serveur web. Sur la machine cliente le port 12345 est lié (temporairement) au processus client web alors que sur la machine serveur le port 80 est lié (en permanence) au processus serveur web. Les paquets de cette connexion émis par le client ont pour port source 12345 et pour port destination 80. Inversement, les paquets de cette connexion émis par le serveur ont pour port source 80 et pour port destination 12345. La connexion TCP est identifiée de façon unique par le quadruplet {adresse client, port client, adresse serveur, port serveur}. C’est grâce à ces informations que le suivi de connexion de Netfilter peut reconnaître qu’un paquet appartient à une connexion existante et qu’une règle iptables peut l’accepter sans spécifier de port source ou destination.