Iptable
ohector
Messages postés
89
Date d'inscription
Statut
Membre
Dernière intervention
-
yahya14 Messages postés 4 Date d'inscription Statut Membre Dernière intervention -
yahya14 Messages postés 4 Date d'inscription Statut Membre Dernière intervention -
bonjour
Qui peux m'expliquer terme par terme et avec des mots tres simple cette chaine!!
iptables –A INPUT –m state –-state RELATED, ESTABLISHED –j ACCEPT
merci
Qui peux m'expliquer terme par terme et avec des mots tres simple cette chaine!!
iptables –A INPUT –m state –-state RELATED, ESTABLISHED –j ACCEPT
merci
9 réponses
En passant timidement, je précise qu'on a fait un petit tuto là-dessus :-)
http://www.commentcamarche.net/faq/sujet-1317-%5BLinux%5D-Installation-d%27un-Firewall
http://www.commentcamarche.net/faq/sujet-1317-%5BLinux%5D-Installation-d%27un-Firewall
Salut :
-A input : ajouter dans la liste des règles "input" :
Permettre aux trames réseaux (ou paquets)
-m state –-state RELATED, ESTABLISHED :
dont l'état est RELATED ou ESTABLISHED
-j ACCEPT
d'atteindre la cible 'ACCEPT' => donc de passer au travers du filtre input
Pour plus de précisions :
un état ESTABLISHED correspond à une trame réseau associée à une connexion
ouverte (donc autorisée)
un état RELATED correspond à une trame réseau établissant une nouvelle
connexion en rapport avec une connexion déja établie. Cela peut servir pour
faire du ftp actif par exemple.
A+, crabs
-A input : ajouter dans la liste des règles "input" :
Permettre aux trames réseaux (ou paquets)
-m state –-state RELATED, ESTABLISHED :
dont l'état est RELATED ou ESTABLISHED
-j ACCEPT
d'atteindre la cible 'ACCEPT' => donc de passer au travers du filtre input
Pour plus de précisions :
un état ESTABLISHED correspond à une trame réseau associée à une connexion
ouverte (donc autorisée)
un état RELATED correspond à une trame réseau établissant une nouvelle
connexion en rapport avec une connexion déja établie. Cela peut servir pour
faire du ftp actif par exemple.
A+, crabs
merci beaucoup , ca devient un peu plus clair
Et -m state –-state c'est quoi les trois termes?
as tu un exemple concret pour ESTABLISHED et RELATED?
merci beaucoup
Et -m state –-state c'est quoi les trois termes?
as tu un exemple concret pour ESTABLISHED et RELATED?
merci beaucoup
Salut :)
Un petit exemple, le ftp (comme l'a indiqué crabs) :
#ton serveur ftp écoute sur le port 21 de la carte réseau eth0
# On s'occupe de la premiere connexion sur le port 21
#on laisse les gens initier une connexion sur notre serveur ftp et on laisse en sortie tout ce qui est établi avec le serveur ftp.
#on s'occupe de la seconde connexion sur le port 20 (pour du ftp actif), il s'agit de la connexion pour le transfert de fichier.
#on laisse le serveur initier une connexion avec son port 20 vers les clients et en entrée on laisse passer ce qui est établi.
Regarde les deux lignes : NEW (INPUT dport 21) est remplacé par RELATED (OUTPUT sport 20).
Effectivement on créé une NOUVELLE connexion avec le port 20, mais elle dépend de la premiere connexion établie sur le port 21. C'est pourquoi iptables a besoin de savoir que c'est une connexion relative à une autre connexion existante (donc établie).
@+
Un petit exemple, le ftp (comme l'a indiqué crabs) :
#ton serveur ftp écoute sur le port 21 de la carte réseau eth0
# On s'occupe de la premiere connexion sur le port 21
#on laisse les gens initier une connexion sur notre serveur ftp et on laisse en sortie tout ce qui est établi avec le serveur ftp.
iptables -A INPUT -i eth0 -p tcp --dport 21 -m state --state NEW,ESTABLISHED -j ACCEPT iptables -A OUTPUT -o eth0 -p tcp --sport 21 -m state --state ESTABLISHED -j ACCEPT
#on s'occupe de la seconde connexion sur le port 20 (pour du ftp actif), il s'agit de la connexion pour le transfert de fichier.
#on laisse le serveur initier une connexion avec son port 20 vers les clients et en entrée on laisse passer ce qui est établi.
iptables -A INPUT -i eth0 -p tcp --dport 20 -m state --state ESTABLISHED -j ACCEPT iptables -A OUTPUT -o eth0 -p tcp --sport 20 -m state --state RELATED,ESTABLISHED -j ACCEPT
Regarde les deux lignes : NEW (INPUT dport 21) est remplacé par RELATED (OUTPUT sport 20).
Effectivement on créé une NOUVELLE connexion avec le port 20, mais elle dépend de la premiere connexion établie sur le port 21. C'est pourquoi iptables a besoin de savoir que c'est une connexion relative à une autre connexion existante (donc établie).
@+
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
-m state --state
-m : préciser qu'un élément du paquet doit verifier une règle (m pour match)
state : ce qu'il faut vérifier c'est l'état du paquet
--state valeur1,valeur2,... qui peut avoir comme valeur valeur1 ou valeur2 ou ...
Bonsoir,
Dans la commande iptables on a aussi les options étendues.
Ces options sont gérées par de modules qui sont chargés implicitement via l'option -p ou explicitement via -m nom_module.
Parmi les options étendues du module TCP et UDP on trouve
--sport, --source-port - spécifie le port source ou un domaine des ports
--dport, --destination-port -spécifie le port de destination ou un domaine des ports
Ex:
1.
Permetre l'access sur ton PC (192.168.0.1) à ton serveur WEB au PC (192.168.1.1)
2.
Permetre l'access sur ton PC (192.168.0.1) à ton serveur FTP au PC (192.168.1.1)
Dans la commande iptables on a aussi les options étendues.
Ces options sont gérées par de modules qui sont chargés implicitement via l'option -p ou explicitement via -m nom_module.
Parmi les options étendues du module TCP et UDP on trouve
--sport, --source-port - spécifie le port source ou un domaine des ports
--dport, --destination-port -spécifie le port de destination ou un domaine des ports
Ex:
1.
Permetre l'access sur ton PC (192.168.0.1) à ton serveur WEB au PC (192.168.1.1)
iptables -A INPUT -i eth0 -p tcp -s 192.168.1.1 -d 192.168.0.1 --dport 80 -j ACCEPT
2.
Permetre l'access sur ton PC (192.168.0.1) à ton serveur FTP au PC (192.168.1.1)
iptables -A INPUT -i eth0 -p tcp -s 192.168.1.1 -d 192.168.0.1 --dport 20:21 -j ACCEPT
Cela dépend de la liste de règles (table) qui est impactée :
Il faut identifier pour la trame traitée par la règle l'émetteur et le recepteur.
Un règle traite un trame dans le sens émetteur vers récepteur
le sport est le port de la source : l'émetteur
le dport est le port de la destination : récepteur
Donc pour le sport, dans une chaine INPUT c'est la machine distante, dans une
chaine OUTPUT c'est la machine locale.
Il faut identifier pour la trame traitée par la règle l'émetteur et le recepteur.
Un règle traite un trame dans le sens émetteur vers récepteur
le sport est le port de la source : l'émetteur
le dport est le port de la destination : récepteur
Donc pour le sport, dans une chaine INPUT c'est la machine distante, dans une
chaine OUTPUT c'est la machine locale.
je me permets de poster une nouvelle question dans ce fil car elle relève assez de ce qui y est abordé je crois
le problème: dcc send
quand un client est connecté à un serveur irc (sur le port 6667 du serveur typiquement) et qu'il souhaite lancer un transfert de fichier vers un autre client, de ce que j'ai observé, il envoie un paquet au serveur irc, avec dans ses données le port sur lequel il va attendre le SYN de l'autre client (destinataire du fichier)
Le serveur informe le destinataire acceptant le transfert que l'expéditeur attend sa connexion sur le port en question
Le destinataire envoie alors un SYN sur le port en question de l'expéditeur
si bien que puisque l'expéditeur dialoguait avec le serveur irc d'IP xxx.xxx.xxx.xxx et qu'il reçoit un SYN du destinataire, d'IP, lui, yyy.yyy.yyy.yyy sur un port variable, RELATED et ESTABLISHED ne reconnaissent pas le paquet, il faut un NEW pour qu'il passe (ce qui revient à dire, INPUT -m state --state NEW,RELATED,ESTABLISHED -s 0/0 -d 0/0 -j ACCEPT, autant dire la porte grande ouverte).
Or, d'une part je me demande si ip_conntrack_irc n'est pas censé justement savoir déterminer le RELATED dans ce contexte (auquel cas chez moi il chôme, puisqu'il est chargé), d'autre part, je me demande dans quelle mesure il est possible, puisque c'est bien l'expéditeur qui propose le port qui va recevoir le SYN, de faire en sorte que pendant un laps de temps, il attende sur ce port une connexion entrante (ce qui implique de trouver ledit port dans les données du paquet expédié au serveur IRC)
Ceux d'entre vous qui font fonctionner dcc send derrière iptables, quelle est leur règle qui le permet?
Peut-être que mon module ip_conntrack_irc fait la gueule :(
je précise qu'iptables je n'y suis que depuis hier. Jusque là, j'utilisais ipchains (et j'en étais très satisfait, si ce n'est les problèmes de service ftp et de dcc send, pour lesquels j'ai pensé que le conntrack pourrait suffire. C'est ce fil qui m'a donné envie de sauter le pas d'ailleurs)
merci
le problème: dcc send
quand un client est connecté à un serveur irc (sur le port 6667 du serveur typiquement) et qu'il souhaite lancer un transfert de fichier vers un autre client, de ce que j'ai observé, il envoie un paquet au serveur irc, avec dans ses données le port sur lequel il va attendre le SYN de l'autre client (destinataire du fichier)
Le serveur informe le destinataire acceptant le transfert que l'expéditeur attend sa connexion sur le port en question
Le destinataire envoie alors un SYN sur le port en question de l'expéditeur
si bien que puisque l'expéditeur dialoguait avec le serveur irc d'IP xxx.xxx.xxx.xxx et qu'il reçoit un SYN du destinataire, d'IP, lui, yyy.yyy.yyy.yyy sur un port variable, RELATED et ESTABLISHED ne reconnaissent pas le paquet, il faut un NEW pour qu'il passe (ce qui revient à dire, INPUT -m state --state NEW,RELATED,ESTABLISHED -s 0/0 -d 0/0 -j ACCEPT, autant dire la porte grande ouverte).
Or, d'une part je me demande si ip_conntrack_irc n'est pas censé justement savoir déterminer le RELATED dans ce contexte (auquel cas chez moi il chôme, puisqu'il est chargé), d'autre part, je me demande dans quelle mesure il est possible, puisque c'est bien l'expéditeur qui propose le port qui va recevoir le SYN, de faire en sorte que pendant un laps de temps, il attende sur ce port une connexion entrante (ce qui implique de trouver ledit port dans les données du paquet expédié au serveur IRC)
Ceux d'entre vous qui font fonctionner dcc send derrière iptables, quelle est leur règle qui le permet?
Peut-être que mon module ip_conntrack_irc fait la gueule :(
je précise qu'iptables je n'y suis que depuis hier. Jusque là, j'utilisais ipchains (et j'en étais très satisfait, si ce n'est les problèmes de service ftp et de dcc send, pour lesquels j'ai pensé que le conntrack pourrait suffire. C'est ce fil qui m'a donné envie de sauter le pas d'ailleurs)
merci
A tout hasard, s'il y a un port 6667 pour irc, n'y a t'il pas un port annexe pour le tranfert de fichier avec dcc?
Sinon, à ce propos j'ai trouvé ceci, ce serait une option à décocher:
http://www.faqs.org/docs/iptables/mircdcc.html
Sinon, à ce propos j'ai trouvé ceci, ce serait une option à décocher:
http://www.faqs.org/docs/iptables/mircdcc.html
ben niveau client IRC, rien qui permette de le fixer (mais je vais un peu compulser les sources, y a des trucs pas toujours documentés) et à l'observation, a priori non. Par exemple de ce que j'ai observé aujourd'hui, quand j'essaye de lancer un transfert, mon poste envoie un paquet au serveur IRC dont des données sont du genre "DCC SEND nom_fichier série_de_chiffres port bidule" où le port en l'occurrence était toujours au dessus de 33000 et variable à chaque essais
si netfilter pouvait "extraire" ce numéro de port des données et l'ouvrir pendant un laps de temps, çe serait chouette. Mais je sais pas faire (je sais même pas si c'est possible)
si netfilter pouvait "extraire" ce numéro de port des données et l'ouvrir pendant un laps de temps, çe serait chouette. Mais je sais pas faire (je sais même pas si c'est possible)
Normalement ya pas de soucis, ip_conntrack_irc et ça roule.
https://lists.netfilter.org/pipermail/netfilter/2001-November/028039.html
Ce serait possible de voir tes commandes iptables?
https://lists.netfilter.org/pipermail/netfilter/2001-November/028039.html
Ce serait possible de voir tes commandes iptables?
voui bien sûr
je précise que ça ne tourne que depuis hier, pour le moment je suis en politique ACCEPT avec un dégommeur de --syn à la fin mais je vais faire des ajustements. A ce propos c'est justement ce dégommeur de --syn qui me bloque (évidemment) les dcc send
DYNIP c'est moi (c'est remplacé par mon ip dynamique par le script qui charge les règles)
de plus, ce poste sert aussi de passerelle pour un autre mais cet autre est presque toujours éteint, donc en attendant de m'être acclimaté à iptables FORWARD est DROP
chris c'est l'autre poste (presque toujours éteint)
c'est sûrement pas très propre mais je tournais depuis plusieurs années avec ces règles sous ipchains (à la syntaxe près, et FORWARD bien sûr, et la règle à états en moins)
je précise que ça ne tourne que depuis hier, pour le moment je suis en politique ACCEPT avec un dégommeur de --syn à la fin mais je vais faire des ajustements. A ce propos c'est justement ce dégommeur de --syn qui me bloque (évidemment) les dcc send
DYNIP c'est moi (c'est remplacé par mon ip dynamique par le script qui charge les règles)
de plus, ce poste sert aussi de passerelle pour un autre mais cet autre est presque toujours éteint, donc en attendant de m'être acclimaté à iptables FORWARD est DROP
chris c'est l'autre poste (presque toujours éteint)
c'est sûrement pas très propre mais je tournais depuis plusieurs années avec ces règles sous ipchains (à la syntaxe près, et FORWARD bien sûr, et la règle à états en moins)
-t filter -P INPUT ACCEPT -t filter -P FORWARD DROP -t filter -P OUTPUT ACCEPT -t filter -A INPUT -s ! DYNIP -d DYNIP -i ppp0 -p icmp -m icmp --icmp-type 8 -j DROP -t filter -A INPUT -s pop.free.fr -d DYNIP -i ppp0 -p udp -j ACCEPT -t filter -A INPUT -s ftp.proxad.net -d DYNIP -i ppp0 -p udp -j ACCEPT -t filter -A INPUT -s pop.neuf.fr -d DYNIP -i ppp0 -p udp -j ACCEPT -t filter -A INPUT -s nist1.datum.com -d DYNIP -i ppp0 -p udp -j ACCEPT -t filter -A INPUT -d DYNIP -i ppp0 -p udp -m udp --sport 53 -j ACCEPT -t filter -A INPUT -s irc.efnet.fr -d DYNIP -i ppp0 -p tcp -m tcp --dport 113 -j ACCEPT -t filter -A INPUT -s chris -d DYNIP -i ! ppp0 -j ACCEPT -t filter -A INPUT -s ! DYNIP -d DYNIP -i ppp0 -p udp -j DROP -t filter -A INPUT -s ! DYNIP -d DYNIP -i ppp0 -p tcp -m tcp --dport 25 -j ACCEPT -t filter -A INPUT -m state --state RELATED,ESTABLISHED -p tcp -j ACCEPT -t filter -A INPUT -s ! DYNIP -d DYNIP -i ppp0 -p tcp -m tcp --tcp-flags SYN,RST,ACK SYN -j DROP -t filter -A OUTPUT -d 216.73.80.0/20 -j REJECT --reject-with icmp-port-unreachable -t filter -A OUTPUT -s DYNIP -p tcp -j ACCEPT -t filter -A OUTPUT -s DYNIP -d ! DYNIP -p icmp -m icmp --icmp-type 0 -j DROP -t filter -A OUTPUT -s DYNIP -d ! DYNIP -p icmp -m icmp --icmp-type 3 -j DROP
Dès fois malheureusemnt dès fois heureusement, pas tout le monde aime chercher et lire les tutos ( moi je préfere de lire la documentation avant de poser la question).
Même avec un simple man iptables on avait la reponse.
A+
Bon week-end,
lami20j
C'est le brouillard total au début, il vaut mieux commencer par un tuto.
D'ailleurs pour ça les how-to de netfilter sont etonamment bien foutus...
En ce cas je suis d'accord avec toi.