Bonjour =E0 tous,=0A=0AJe voudrais mettre des r=E8gles iptables afin d'auto=
riser uniquement le trafic dns et ping sur une carte et sur l'autre l'acc=
=E8s ssh, je ne suis pas tr=E8s s=FBr de mes r=E8gles donc je voudrais avoi=
r votre avis avant de les appliquer=0A=0Amerci.=0A=0AAlors voil=E0, mes deu=
x cartes r=E9seaux eth1 et eth2, eth2 =E9tant l'interface publique qui va r=
ecevoir les requ=EAtes DNS et ping et eth0 l'acc=E8s ssh =0A=0A#Politique p=
ar d=E9faut deny all=0A=0Aiptables -A INPUT -P DROP=0Aiptabels -A OUTPUT -P=
DROP=0Aiptables -A FORWARD -P DROP=0A=0A=0A#Authorisation de SSH=0A=0Aipta=
bles -A INPUT -i eth0 -p tcp --dport 22 -j ACCEPT=0Aiptables -A INPUT -m st=
ate --state RELATED,ESTABLISHED -j ACCEPT #pour =E9viter les coupures=0Aipt=
ables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT=0A=0A#author=
isation du ping=0A=0Aiptables -A INPUT -i eth1 -p icmp -j ACCEPT =0Aiptable=
s -A OUTPUT -i eth1 -p icmp -j ACCEPT=0A=0A#authorisation des requ=EAtes DN=
S=0A=0A=0Aiptables -A INPUT -i eth1-p udp --dport 53 -j ACCEPT=0Aiptables -=
A OUTPUT -i eth1 -p udp --dport 53 -j ACCEPT=0A=0AVoil=E0 =E0 peu pr=E8s, j=
e ne sais pas vraiment si c'est bon ou non n'=E9tant pas expert en la mati=
=E8re =0A=0AJ'ai aussi trouv=E9 en lisant sur le net l'utilisation des opti=
ons -t filter, est ce que c'est mieux de faire =E7a ?=0A=0AQuelle est la di=
ff=E9rence entre les r=E8gles ci-dessus et leur =E9quivalent avec -t filter=
?=0A=0A#politique par d=E9faut deny all=0A=0Aiptables -t filter -A INPUT -=
P DROP=0Aiptabels -t filter -A OUTPUT -P DROP=0Aiptables -t filter -A FORWA=
RD -P DROP=0A=0A=0A#Authorisation de SSH=0A=0Aiptables -t filter -A INPUT -=
i eth0 -p tcp --dport 22 -j ACCEPT =0Aiptables -t filter -A INPUT -m state=
--state RELATED,ESTABLISHED -j ACCEPT #pour =E9viter les coupures=0Aiptabl=
es -t filter -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT=0A=0A=
#authorisation du ping=0A=0Aiptables -A INPUT -i eth1 -p icmp -j ACCEPT =0A=
iptables -A OUTPUT -i eth1 -p icmp -j ACCEPT=0A=0A#authorisation des requ=
=EAtes DNS=0A=0A=0Aiptables -t filter -A INPUT -i eth1-p udp --dport 53 -j =
ACCEPT=0Aiptables -t filter -A OUTPUT -i eth1 -p udp --dport 53 -j ACCEPT=
=0A=0AMerci beaucoup pour votre aide.=0A=0ACdt=0A=0A=0A=0A
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/705731.75022.qm@web26307.mail.ukl.yahoo.com
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
sleepewig
Bonjour,
Je repond a ta question sur "-t filter", par defaut iptables est mise par defaut dessus donc cela change rien si tu le renseigne ou non, il faut le renseigner que si tu change de tables iptables --help --table -t table table to manipulate (default: `filter')
Si tu DROP par defaut en OUTPUT il faut ajouter des regles de sortie :
Et si tu selection par interface : "-i" pour la chaine INPUT "-o" pour OUTPUT.
Voila esperant t'avoir aide.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
Bonjour,
Je repond a ta question sur "-t filter", par defaut iptables est mise
par defaut dessus donc cela change rien si tu le renseigne ou non, il
faut le renseigner que si tu change de tables
iptables --help
--table -t table table to manipulate (default: `filter')
Si tu DROP par defaut en OUTPUT il faut ajouter des regles de sortie :
Et si tu selection par interface : "-i" pour la chaine INPUT "-o" pour
OUTPUT.
Voila esperant t'avoir aide.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/4C037AB3.4010602@gmail.com
Je repond a ta question sur "-t filter", par defaut iptables est mise par defaut dessus donc cela change rien si tu le renseigne ou non, il faut le renseigner que si tu change de tables iptables --help --table -t table table to manipulate (default: `filter')
Si tu DROP par defaut en OUTPUT il faut ajouter des regles de sortie :
PS : utiliser un logiciel comme Shorewall
<http://www.bortzmeyer.org/filtrage-avec-shorewall.html> simplifierait
quand même les choses.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/20100531193022.GA6920@sources.org
PS : utiliser un logiciel comme Shorewall <http://www.bortzmeyer.org/filtrage-avec-shorewall.html> simplifierait quand même les choses.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
Pascal Hambourg
Tahar BEN ACHOUR a écrit :
Alors voilà, mes deux cartes réseaux eth1 et eth2, eth2 étant l'interface publique qui va recevoir les requêtes DNS et ping et eth0 l'accès ssh
#Politique par défaut deny all
iptables -A INPUT -P DROP iptabels -A OUTPUT -P DROP iptables -A FORWARD -P DROP
#Authorisation de SSH
iptables -A INPUT -i eth0 -p tcp --dport 22 -j ACCEPT iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT #pour éviter les coupures
Qué coupures ? Cette règle, ainsi que la suivante, dites de "suivi de connexion", servent à ne pas se préoccuper de la suite de la connexion une fois le premier paquet accepté.
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
#authorisation du ping
Pas de "h" en français.
iptables -A INPUT -i eth1 -p icmp -j ACCEPT
Trop laxiste, ça accepte tous les ICMP et pas seulement le ping (ICMP echo). Cf. la réponse de sleepewig.
iptables -A OUTPUT -i eth1 -p icmp -j ACCEPT
Inutile, la règle de suivi de connexion s'en occupe déjà.
#authorisation des requêtes DNS
iptables -A INPUT -i eth1-p udp --dport 53 -j ACCEPT
Accepter aussi en TCP, cf. la réponse de Stéphane.
Cette règle accepte les requêtes DHCP sortantes, ce n'est pas ce qui été décrit plus haut.
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe" vers En cas de soucis, contactez EN ANGLAIS Archive: http://lists.debian.org/
Tahar BEN ACHOUR a écrit :
Alors voilà, mes deux cartes réseaux eth1 et eth2, eth2 étant
l'interface publique qui va recevoir les requêtes DNS et ping et eth0
l'accès ssh
#Politique par défaut deny all
iptables -A INPUT -P DROP
iptabels -A OUTPUT -P DROP
iptables -A FORWARD -P DROP
#Authorisation de SSH
iptables -A INPUT -i eth0 -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT #pour éviter les coupures
Qué coupures ? Cette règle, ainsi que la suivante, dites de "suivi de
connexion", servent à ne pas se préoccuper de la suite de la connexion
une fois le premier paquet accepté.
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
#authorisation du ping
Pas de "h" en français.
iptables -A INPUT -i eth1 -p icmp -j ACCEPT
Trop laxiste, ça accepte tous les ICMP et pas seulement le ping (ICMP
echo). Cf. la réponse de sleepewig.
iptables -A OUTPUT -i eth1 -p icmp -j ACCEPT
Inutile, la règle de suivi de connexion s'en occupe déjà.
#authorisation des requêtes DNS
iptables -A INPUT -i eth1-p udp --dport 53 -j ACCEPT
Accepter aussi en TCP, cf. la réponse de Stéphane.
Cette règle accepte les requêtes DHCP sortantes, ce n'est pas ce qui été
décrit plus haut.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/4C05268C.50401@plouf.fr.eu.org
Alors voilà, mes deux cartes réseaux eth1 et eth2, eth2 étant l'interface publique qui va recevoir les requêtes DNS et ping et eth0 l'accès ssh
#Politique par défaut deny all
iptables -A INPUT -P DROP iptabels -A OUTPUT -P DROP iptables -A FORWARD -P DROP
#Authorisation de SSH
iptables -A INPUT -i eth0 -p tcp --dport 22 -j ACCEPT iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT #pour éviter les coupures
Qué coupures ? Cette règle, ainsi que la suivante, dites de "suivi de connexion", servent à ne pas se préoccuper de la suite de la connexion une fois le premier paquet accepté.
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
#authorisation du ping
Pas de "h" en français.
iptables -A INPUT -i eth1 -p icmp -j ACCEPT
Trop laxiste, ça accepte tous les ICMP et pas seulement le ping (ICMP echo). Cf. la réponse de sleepewig.
iptables -A OUTPUT -i eth1 -p icmp -j ACCEPT
Inutile, la règle de suivi de connexion s'en occupe déjà.
#authorisation des requêtes DNS
iptables -A INPUT -i eth1-p udp --dport 53 -j ACCEPT
Accepter aussi en TCP, cf. la réponse de Stéphane.
Surtout pas, ça accepte n'importe quoi vers n'importe où du moment que c'est émis depuis le port 22 ! (d'accord pour utiliser ce port source il faut être root et si on est root on peut changer les règles, mais c'est pas une raison)
# et ajouter pour les requete dns iptables -A INPUT -i eth1 -p udp --sport 53 -j ACCEPT iptables -A OUTPUT -o eth1 -p udp --sport 53 -j ACCEPT
Surtout pas : jamais de règles basées uniquement sur le port source pour accepter les réponses, ce n'est pas fiable. Utiliser plutôt le suivi de connexion.
Ça ce serait pour le ping en sortie (réponse entrante), ce qui n'est pas demandé. Inutile dans le cas contraire car la règle de suivi de connexion s'en occupe déjà.
Surtout pas, ça accepte n'importe quoi vers n'importe où du moment que
c'est émis depuis le port 22 ! (d'accord pour utiliser ce port source il
faut être root et si on est root on peut changer les règles, mais c'est
pas une raison)
# et ajouter pour les requete dns
iptables -A INPUT -i eth1 -p udp --sport 53 -j ACCEPT
iptables -A OUTPUT -o eth1 -p udp --sport 53 -j ACCEPT
Surtout pas : jamais de règles basées uniquement sur le port source pour
accepter les réponses, ce n'est pas fiable. Utiliser plutôt le suivi de
connexion.
Ça ce serait pour le ping en sortie (réponse entrante), ce qui n'est pas
demandé. Inutile dans le cas contraire car la règle de suivi de
connexion s'en occupe déjà.
Ça ce serait pour le ping en sortie, ce qui n'est pas demandé.
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/4C0528A2.7090005@plouf.fr.eu.org
Surtout pas, ça accepte n'importe quoi vers n'importe où du moment que c'est émis depuis le port 22 ! (d'accord pour utiliser ce port source il faut être root et si on est root on peut changer les règles, mais c'est pas une raison)
# et ajouter pour les requete dns iptables -A INPUT -i eth1 -p udp --sport 53 -j ACCEPT iptables -A OUTPUT -o eth1 -p udp --sport 53 -j ACCEPT
Surtout pas : jamais de règles basées uniquement sur le port source pour accepter les réponses, ce n'est pas fiable. Utiliser plutôt le suivi de connexion.
Ça ce serait pour le ping en sortie (réponse entrante), ce qui n'est pas demandé. Inutile dans le cas contraire car la règle de suivi de connexion s'en occupe déjà.
