# default policy : DROP
iptables -P INPUT DROP
iptables -P OUTPUT DROP
# on accepte les paquets relatifs aux connexions deja ouvertes
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# j'accepte le ping (mais ne sais pas comment en limiter le nombre)
iptables -p icmp --icmp-type <ping> -j ACCEPT
# accepte tout ce qui concerne l'interface loopback
iptables -A INPUT -i lo -m state --state NEW -j ACCEPT
iptables -A OUTPUT -o lo -m state --state NEW -j ACCEPT
# accepte tout ce qui provient de l'adresse xx.xx.xx.xx
#iptables -A INPUT -i eth0 -s xx.xx.xx.xx -j ACCEPT
Dans le message <news:, *Matthieu Moy* tapota sur f.c.o.l.configuration :
Je suis un peu parano, je mets DROP sans pitié ni hésitation
Le gain en sécurité est faible, et l'emmerdement des utilisateurs bien plus grand en DROP-ant les paquets en général. Sur une machine perso, c'est pas bien grave, mais quand c'est un firewall avec plusieurs utilisateurs derrière, c'est quand même très chiant d'essayer de se connecter à quelque chose sans y arriver alors qu'on aurait pu avoir un message d'erreur clair disant que c'est interdit.
Entièrement d'accord sur le principe, sauf qu'ici il s'agissait de filtrer des paquets invalides (mal formés, corrompus, parasites) donc le choix entre DROP ou REJECT mérite peut être un autre point de vue.
-- Sébastien Monbrun aka TiChou
Dans le message <news:vpqven6amz7.fsf@rechasse.imag.fr>,
*Matthieu Moy* tapota sur f.c.o.l.configuration :
Je suis un peu parano, je mets DROP sans pitié ni hésitation
Le gain en sécurité est faible, et l'emmerdement des utilisateurs bien
plus grand en DROP-ant les paquets en général. Sur une machine perso,
c'est pas bien grave, mais quand c'est un firewall avec plusieurs
utilisateurs derrière, c'est quand même très chiant d'essayer de se
connecter à quelque chose sans y arriver alors qu'on aurait pu avoir
un message d'erreur clair disant que c'est interdit.
Entièrement d'accord sur le principe, sauf qu'ici il s'agissait de filtrer
des paquets invalides (mal formés, corrompus, parasites) donc le choix entre
DROP ou REJECT mérite peut être un autre point de vue.
Dans le message <news:, *Matthieu Moy* tapota sur f.c.o.l.configuration :
Je suis un peu parano, je mets DROP sans pitié ni hésitation
Le gain en sécurité est faible, et l'emmerdement des utilisateurs bien plus grand en DROP-ant les paquets en général. Sur une machine perso, c'est pas bien grave, mais quand c'est un firewall avec plusieurs utilisateurs derrière, c'est quand même très chiant d'essayer de se connecter à quelque chose sans y arriver alors qu'on aurait pu avoir un message d'erreur clair disant que c'est interdit.
Entièrement d'accord sur le principe, sauf qu'ici il s'agissait de filtrer des paquets invalides (mal formés, corrompus, parasites) donc le choix entre DROP ou REJECT mérite peut être un autre point de vue.
-- Sébastien Monbrun aka TiChou
Jack H.
Le Fri, 29 Sep 2006 14:14:36 +0200, Matthieu Moy a écrit:
"Jack H." writes:
Je suis un peu parano, je mets DROP sans pitié ni hésitation
Le gain en sécurité est faible, et l'emmerdement des utilisateurs bien plus grand en DROP-ant les paquets en général. Sur une machine perso, c'est pas bien grave, mais quand c'est un firewall avec plusieurs utilisateurs derrière, c'est quand même très chiant d'essayer de se connecter à quelque chose sans y arriver alors qu'on aurait pu avoir un message d'erreur clair disant que c'est interdit.
Ce ne sont pas des "paquets en général" mais des paquets mal formés. Tu en
connais beaucoup, toi, des utilisateurs "normaux" qui se connectent à ta machine en envoyant des requêtes invalides? De plus il vaut mieux masquer sa présence en cas d'intrusion (je te l'accorde, le risque ici est plutôt faible puisqu'il y a de fortes chances pour que l'intrus sache déjà que quelque chose répond à cette adresse IP autrement il perd son temps, d'ailleurs c'est le but ;-) -- Jack H. "Suivi ad-hoc..."
Le Fri, 29 Sep 2006 14:14:36 +0200, Matthieu Moy
<MatthieuNOSPAM.Moy@imag.fr.invalid> a écrit:
"Jack H." <jack@bbpfrance.homelinux.org> writes:
Je suis un peu parano, je mets DROP sans pitié ni hésitation
Le gain en sécurité est faible, et l'emmerdement des utilisateurs bien
plus grand en DROP-ant les paquets en général. Sur une machine perso,
c'est pas bien grave, mais quand c'est un firewall avec plusieurs
utilisateurs derrière, c'est quand même très chiant d'essayer de se
connecter à quelque chose sans y arriver alors qu'on aurait pu avoir
un message d'erreur clair disant que c'est interdit.
Ce ne sont pas des "paquets en général" mais des paquets mal formés. Tu en
connais beaucoup, toi, des utilisateurs "normaux" qui se connectent à ta
machine en envoyant des requêtes invalides?
De plus il vaut mieux masquer sa présence en cas d'intrusion (je te
l'accorde, le risque ici est plutôt faible puisqu'il y a de fortes chances
pour que l'intrus sache déjà que quelque chose répond à cette adresse IP
autrement il perd son temps, d'ailleurs c'est le but ;-)
--
Jack H.
"Suivi ad-hoc..."
Le Fri, 29 Sep 2006 14:14:36 +0200, Matthieu Moy a écrit:
"Jack H." writes:
Je suis un peu parano, je mets DROP sans pitié ni hésitation
Le gain en sécurité est faible, et l'emmerdement des utilisateurs bien plus grand en DROP-ant les paquets en général. Sur une machine perso, c'est pas bien grave, mais quand c'est un firewall avec plusieurs utilisateurs derrière, c'est quand même très chiant d'essayer de se connecter à quelque chose sans y arriver alors qu'on aurait pu avoir un message d'erreur clair disant que c'est interdit.
Ce ne sont pas des "paquets en général" mais des paquets mal formés. Tu en
connais beaucoup, toi, des utilisateurs "normaux" qui se connectent à ta machine en envoyant des requêtes invalides? De plus il vaut mieux masquer sa présence en cas d'intrusion (je te l'accorde, le risque ici est plutôt faible puisqu'il y a de fortes chances pour que l'intrus sache déjà que quelque chose répond à cette adresse IP autrement il perd son temps, d'ailleurs c'est le but ;-) -- Jack H. "Suivi ad-hoc..."
Matthieu Moy
Sébastien Monbrun aka TiChou writes:
Entièrement d'accord sur le principe, sauf qu'ici il s'agissait de filtrer des paquets invalides (mal formés, corrompus, parasites) donc le choix entre DROP ou REJECT mérite peut être un autre point de vue.
Oups, bon, la prochaine fois, je lirais le message avant de répondre alors ;-).
Entièrement d'accord sur le principe, sauf qu'ici il s'agissait de
filtrer des paquets invalides (mal formés, corrompus, parasites) donc
le choix entre DROP ou REJECT mérite peut être un autre point de
vue.
Oups, bon, la prochaine fois, je lirais le message avant de répondre
alors ;-).
Entièrement d'accord sur le principe, sauf qu'ici il s'agissait de filtrer des paquets invalides (mal formés, corrompus, parasites) donc le choix entre DROP ou REJECT mérite peut être un autre point de vue.
Oups, bon, la prochaine fois, je lirais le message avant de répondre alors ;-).
-- Matthieu
Pascal Hambourg
Je suis un peu parano, je mets DROP sans pitié ni hésitation
Le gain en sécurité est faible, et l'emmerdement des utilisateurs bien plus grand en DROP-ant les paquets en général.
Je suis d'accord en général, mais mon interrogation ne portait que sur les paquets TCP dans l'état INVALID. Les paquets TCP SYN dans l'état NEW indésirables sont bien sûr traités par REJECT avec émission d'un TCP RST.
Avant l'application du patch tcp-window-tracking (inclus dans le patch-o-matic de Netfilter, et en standard dans le noyau depuis la version 2.6.9), la question n'était pas cruciale car il n'y avait pas de véritable suivi d'état TCP dans Netfilter. En particulier il n'y avait pas de suivi des numéros de séquence ni de vérification du "3-way handshake" (traduction bienvenue). Avec ce patch, un paquet TCP ne respectant pas la séquence est considéré dans l'état INVALID. Mais un tel paquet peut provenir aussi bien d'une ancienne connexion à moitié fermée que d'une tentative de spoofing. Dans le premier cas, REJECT serait préférable pour avertir la source, mais dans le deuxième cas il pourrait provoquer la fermeture intempestive d'une connexion valide. Je ne sais que penser...
Je suis un peu parano, je mets DROP sans pitié ni hésitation
Le gain en sécurité est faible, et l'emmerdement des utilisateurs bien
plus grand en DROP-ant les paquets en général.
Je suis d'accord en général, mais mon interrogation ne portait que sur
les paquets TCP dans l'état INVALID. Les paquets TCP SYN dans l'état NEW
indésirables sont bien sûr traités par REJECT avec émission d'un TCP RST.
Avant l'application du patch tcp-window-tracking (inclus dans le
patch-o-matic de Netfilter, et en standard dans le noyau depuis la
version 2.6.9), la question n'était pas cruciale car il n'y avait pas de
véritable suivi d'état TCP dans Netfilter. En particulier il n'y avait
pas de suivi des numéros de séquence ni de vérification du "3-way
handshake" (traduction bienvenue). Avec ce patch, un paquet TCP ne
respectant pas la séquence est considéré dans l'état INVALID. Mais un
tel paquet peut provenir aussi bien d'une ancienne connexion à moitié
fermée que d'une tentative de spoofing. Dans le premier cas, REJECT
serait préférable pour avertir la source, mais dans le deuxième cas il
pourrait provoquer la fermeture intempestive d'une connexion valide.
Je ne sais que penser...
Je suis un peu parano, je mets DROP sans pitié ni hésitation
Le gain en sécurité est faible, et l'emmerdement des utilisateurs bien plus grand en DROP-ant les paquets en général.
Je suis d'accord en général, mais mon interrogation ne portait que sur les paquets TCP dans l'état INVALID. Les paquets TCP SYN dans l'état NEW indésirables sont bien sûr traités par REJECT avec émission d'un TCP RST.
Avant l'application du patch tcp-window-tracking (inclus dans le patch-o-matic de Netfilter, et en standard dans le noyau depuis la version 2.6.9), la question n'était pas cruciale car il n'y avait pas de véritable suivi d'état TCP dans Netfilter. En particulier il n'y avait pas de suivi des numéros de séquence ni de vérification du "3-way handshake" (traduction bienvenue). Avec ce patch, un paquet TCP ne respectant pas la séquence est considéré dans l'état INVALID. Mais un tel paquet peut provenir aussi bien d'une ancienne connexion à moitié fermée que d'une tentative de spoofing. Dans le premier cas, REJECT serait préférable pour avertir la source, mais dans le deuxième cas il pourrait provoquer la fermeture intempestive d'une connexion valide. Je ne sais que penser...
Pascal Hambourg
filtrer des paquets invalides (mal formés, corrompus, parasites)
Je pense qu'une précision s'impose (pas pour toi mais pour d'autres éventuellement). L'état INVALID ne signifie pas qu'un paquet est malformé, corrompu, etc. mais que le suivi d'état de connexion de Netfilter est incapable de l'associer à une connexion. Ça peut être le cas de paquets parfaitement formés et légitimes.
filtrer des paquets invalides (mal formés, corrompus, parasites)
Je pense qu'une précision s'impose (pas pour toi mais pour d'autres
éventuellement). L'état INVALID ne signifie pas qu'un paquet est
malformé, corrompu, etc. mais que le suivi d'état de connexion de
Netfilter est incapable de l'associer à une connexion. Ça peut être le
cas de paquets parfaitement formés et légitimes.
filtrer des paquets invalides (mal formés, corrompus, parasites)
Je pense qu'une précision s'impose (pas pour toi mais pour d'autres éventuellement). L'état INVALID ne signifie pas qu'un paquet est malformé, corrompu, etc. mais que le suivi d'état de connexion de Netfilter est incapable de l'associer à une connexion. Ça peut être le cas de paquets parfaitement formés et légitimes.
Lesnews
houla ...
"Pascal Hambourg" a écrit dans le message de news: efj6ch$1hi0$
Je suis un peu parano, je mets DROP sans pitié ni hésitation
Le gain en sécurité est faible, et l'emmerdement des utilisateurs bien plus grand en DROP-ant les paquets en général.
Je suis d'accord en général, mais mon interrogation ne portait que sur les paquets TCP dans l'état INVALID. Les paquets TCP SYN dans l'état NEW indésirables sont bien sûr traités par REJECT avec émission d'un TCP RST.
Avant l'application du patch tcp-window-tracking (inclus dans le patch-o-matic de Netfilter, et en standard dans le noyau depuis la version 2.6.9), la question n'était pas cruciale car il n'y avait pas de véritable suivi d'état TCP dans Netfilter. En particulier il n'y avait pas de suivi des numéros de séquence ni de vérification du "3-way handshake" (traduction bienvenue). Avec ce patch, un paquet TCP ne respectant pas la séquence est considéré dans l'état INVALID. Mais un tel paquet peut provenir aussi bien d'une ancienne connexion à moitié fermée que d'une tentative de spoofing. Dans le premier cas, REJECT serait préférable pour avertir la source, mais dans le deuxième cas il pourrait provoquer la fermeture intempestive d'une connexion valide. Je ne sais que penser...
houla ...
"Pascal Hambourg" <boite-a-spam@plouf.fr.eu.org> a écrit dans le message de
news: efj6ch$1hi0$1@biggoron.nerim.net...
Je suis un peu parano, je mets DROP sans pitié ni hésitation
Le gain en sécurité est faible, et l'emmerdement des utilisateurs bien
plus grand en DROP-ant les paquets en général.
Je suis d'accord en général, mais mon interrogation ne portait que sur les
paquets TCP dans l'état INVALID. Les paquets TCP SYN dans l'état NEW
indésirables sont bien sûr traités par REJECT avec émission d'un TCP RST.
Avant l'application du patch tcp-window-tracking (inclus dans le
patch-o-matic de Netfilter, et en standard dans le noyau depuis la version
2.6.9), la question n'était pas cruciale car il n'y avait pas de véritable
suivi d'état TCP dans Netfilter. En particulier il n'y avait pas de suivi
des numéros de séquence ni de vérification du "3-way handshake"
(traduction bienvenue). Avec ce patch, un paquet TCP ne respectant pas la
séquence est considéré dans l'état INVALID. Mais un tel paquet peut
provenir aussi bien d'une ancienne connexion à moitié fermée que d'une
tentative de spoofing. Dans le premier cas, REJECT serait préférable pour
avertir la source, mais dans le deuxième cas il pourrait provoquer la
fermeture intempestive d'une connexion valide.
Je ne sais que penser...
"Pascal Hambourg" a écrit dans le message de news: efj6ch$1hi0$
Je suis un peu parano, je mets DROP sans pitié ni hésitation
Le gain en sécurité est faible, et l'emmerdement des utilisateurs bien plus grand en DROP-ant les paquets en général.
Je suis d'accord en général, mais mon interrogation ne portait que sur les paquets TCP dans l'état INVALID. Les paquets TCP SYN dans l'état NEW indésirables sont bien sûr traités par REJECT avec émission d'un TCP RST.
Avant l'application du patch tcp-window-tracking (inclus dans le patch-o-matic de Netfilter, et en standard dans le noyau depuis la version 2.6.9), la question n'était pas cruciale car il n'y avait pas de véritable suivi d'état TCP dans Netfilter. En particulier il n'y avait pas de suivi des numéros de séquence ni de vérification du "3-way handshake" (traduction bienvenue). Avec ce patch, un paquet TCP ne respectant pas la séquence est considéré dans l'état INVALID. Mais un tel paquet peut provenir aussi bien d'une ancienne connexion à moitié fermée que d'une tentative de spoofing. Dans le premier cas, REJECT serait préférable pour avertir la source, mais dans le deuxième cas il pourrait provoquer la fermeture intempestive d'une connexion valide. Je ne sais que penser...
