j'ai installé hping3 sur une lenny. Mon serveur est firewallé avec iptables,
j'autorise tout en sortie.
Par contre quand j'exécute la commande suivante :
$ sudo /usr/sbin/hping3 -V 192.168.0.1 -p 21
using eth0, addr: 192.168.0.2, MTU: 1500
HPING 192.168.0.1 (eth0 192.168.0.2): NO FLAGS are set, 40 headers + 0 data
bytes
[send_ip] sendto: Operation not permitted
Voici le log de l'iptables :
Jul 23 11:35:12 monhost kernel: [2990025.691301] [FW-DROP] IN= OUT=eth0
SRC2.168.0.2 DST2.168.0.1 LEN@ TOS=0x00 PREC=0x00 TTLd
IDÂ…99 PROTO=TCP SPT55 DPT! WINDOWQ2 RES=0x00 URGP=0 UID=0 GID=0
j'ai installé hping3 sur une lenny. Mon serveur est firewallé avec iptables,
j'autorise tout en sortie.
Par contre quand j'exécute la commande suivante :
$ sudo /usr/sbin/hping3 -V 192.168.0.1 -p 21
using eth0, addr: 192.168.0.2, MTU: 1500
HPING 192.168.0.1 (eth0 192.168.0.2): NO FLAGS are set, 40 headers + 0 data
bytes
[send_ip] sendto: Operation not permitted
Voici le log de l'iptables :
Jul 23 11:35:12 monhost kernel: [2990025.691301] [FW-DROP] IN= OUT=eth0
SRC2.168.0.2 DST2.168.0.1 LEN@ TOS=0x00 PREC=0x00 TTLd
IDÂ…99 PROTO=TCP SPT55 DPT! WINDOWQ2 RES=0x00 URGP=0 UID=0 GID=0
j'ai installé hping3 sur une lenny. Mon serveur est firewallé avec iptables,
j'autorise tout en sortie.
Par contre quand j'exécute la commande suivante :
$ sudo /usr/sbin/hping3 -V 192.168.0.1 -p 21
using eth0, addr: 192.168.0.2, MTU: 1500
HPING 192.168.0.1 (eth0 192.168.0.2): NO FLAGS are set, 40 headers + 0 data
bytes
[send_ip] sendto: Operation not permitted
Voici le log de l'iptables :
Jul 23 11:35:12 monhost kernel: [2990025.691301] [FW-DROP] IN= OUT=eth0
SRC2.168.0.2 DST2.168.0.1 LEN@ TOS=0x00 PREC=0x00 TTLd
IDÂ…99 PROTO=TCP SPT55 DPT! WINDOWQ2 RES=0x00 URGP=0 UID=0 GID=0
Salut,
Hugo Deprez a écrit :j'ai installé hping3 sur une lenny. Mon serveur est firewallé avec
iptables,
j'autorise tout en sortie.
Par contre quand j'exécute la commande suivante :
$ sudo /usr/sbin/hping3 -V 192.168.0.1 -p 21
using eth0, addr: 192.168.0.2, MTU: 1500
HPING 192.168.0.1 (eth0 192.168.0.2): NO FLAGS are set, 40 headers + 0
data
bytes
[send_ip] sendto: Operation not permitted
Voici le log de l'iptables :
Jul 23 11:35:12 monhost kernel: [2990025.691301] [FW-DROP] IN= OUT=e th0
SRC2.168.0.2 DST2.168.0.1 LEN@ TOS=0x00 PREC=0x00 TTL d
ID…99 PROTO=TCP SPT55 DPT! WINDOWQ2 RES=0x00 URGP =0 UID=0 GID=0
Visiblement cette commande envoie un paquet TCP sans aucu flag (notamment
SYN), donc le suivi de connexion de netfilter le classe probablement dans
l'état INVALID. Il faudrait regarder s'il n'y a pas une règle iptable s dans
OUTPUT ou une chaîne utilisateur appelée depuis là qui bloque les p aquets
sortants dans l'état INVALID (ce qui serait assez logique quand on fait du
filtrage à état puisqu'une éventuelle réponse reçue serait forc ément classée
INVALID elle aussi et bloquée).
--
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/
Salut,
Hugo Deprez a écrit :
j'ai installé hping3 sur une lenny. Mon serveur est firewallé avec
iptables,
j'autorise tout en sortie.
Par contre quand j'exécute la commande suivante :
$ sudo /usr/sbin/hping3 -V 192.168.0.1 -p 21
using eth0, addr: 192.168.0.2, MTU: 1500
HPING 192.168.0.1 (eth0 192.168.0.2): NO FLAGS are set, 40 headers + 0
data
bytes
[send_ip] sendto: Operation not permitted
Voici le log de l'iptables :
Jul 23 11:35:12 monhost kernel: [2990025.691301] [FW-DROP] IN= OUT=e th0
SRC=192.168.0.2 DST=192.168.0.1 LEN=40 TOS=0x00 PREC=0x00 TTL =64
ID=8599 PROTO=TCP SPT=1655 DPT=21 WINDOW=512 RES=0x00 URGP =0 UID=0 GID=0
Visiblement cette commande envoie un paquet TCP sans aucu flag (notamment
SYN), donc le suivi de connexion de netfilter le classe probablement dans
l'état INVALID. Il faudrait regarder s'il n'y a pas une règle iptable s dans
OUTPUT ou une chaîne utilisateur appelée depuis là qui bloque les p aquets
sortants dans l'état INVALID (ce qui serait assez logique quand on fait du
filtrage à état puisqu'une éventuelle réponse reçue serait forc ément classée
INVALID elle aussi et bloquée).
--
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/4C49B837.3080503@plouf.fr.eu.org
Salut,
Hugo Deprez a écrit :j'ai installé hping3 sur une lenny. Mon serveur est firewallé avec
iptables,
j'autorise tout en sortie.
Par contre quand j'exécute la commande suivante :
$ sudo /usr/sbin/hping3 -V 192.168.0.1 -p 21
using eth0, addr: 192.168.0.2, MTU: 1500
HPING 192.168.0.1 (eth0 192.168.0.2): NO FLAGS are set, 40 headers + 0
data
bytes
[send_ip] sendto: Operation not permitted
Voici le log de l'iptables :
Jul 23 11:35:12 monhost kernel: [2990025.691301] [FW-DROP] IN= OUT=e th0
SRC2.168.0.2 DST2.168.0.1 LEN@ TOS=0x00 PREC=0x00 TTL d
ID…99 PROTO=TCP SPT55 DPT! WINDOWQ2 RES=0x00 URGP =0 UID=0 GID=0
Visiblement cette commande envoie un paquet TCP sans aucu flag (notamment
SYN), donc le suivi de connexion de netfilter le classe probablement dans
l'état INVALID. Il faudrait regarder s'il n'y a pas une règle iptable s dans
OUTPUT ou une chaîne utilisateur appelée depuis là qui bloque les p aquets
sortants dans l'état INVALID (ce qui serait assez logique quand on fait du
filtrage à état puisqu'une éventuelle réponse reçue serait forc ément classée
INVALID elle aussi et bloquée).
--
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/
merci pour la réponse, j'ai une règle de type ACCEPT source any destination
any.
Elle semble fonctionnelle, et je pensais qu'elle prendrait le dessus sur les
autres règles déjà présentes. Ce ne serait pas le cas ?
voici ma table OUTPUT :
LOGDROP tcp -- anywhere anywhere tcp
flags:FIN,SYN,RST,PSH,ACK,URG/FIN,SYN,RST,PSH,ACK,URG
LOGDROP tcp -- anywhere anywhere tcp
flags:FIN,SYN,RST,PSH,ACK,URG/FIN,SYN,RST,ACK,URG
LOGDROP tcp -- anywhere anywhere tcp
flags:FIN,SYN,RST,PSH,ACK,URG/NONE
merci pour la réponse, j'ai une règle de type ACCEPT source any destination
any.
Elle semble fonctionnelle, et je pensais qu'elle prendrait le dessus sur les
autres règles déjà présentes. Ce ne serait pas le cas ?
voici ma table OUTPUT :
LOGDROP tcp -- anywhere anywhere tcp
flags:FIN,SYN,RST,PSH,ACK,URG/FIN,SYN,RST,PSH,ACK,URG
LOGDROP tcp -- anywhere anywhere tcp
flags:FIN,SYN,RST,PSH,ACK,URG/FIN,SYN,RST,ACK,URG
LOGDROP tcp -- anywhere anywhere tcp
flags:FIN,SYN,RST,PSH,ACK,URG/NONE
merci pour la réponse, j'ai une règle de type ACCEPT source any destination
any.
Elle semble fonctionnelle, et je pensais qu'elle prendrait le dessus sur les
autres règles déjà présentes. Ce ne serait pas le cas ?
voici ma table OUTPUT :
LOGDROP tcp -- anywhere anywhere tcp
flags:FIN,SYN,RST,PSH,ACK,URG/FIN,SYN,RST,PSH,ACK,URG
LOGDROP tcp -- anywhere anywhere tcp
flags:FIN,SYN,RST,PSH,ACK,URG/FIN,SYN,RST,ACK,URG
LOGDROP tcp -- anywhere anywhere tcp
flags:FIN,SYN,RST,PSH,ACK,URG/NONE
Hugo Deprez a écrit :merci pour la réponse, j'ai une règle de type ACCEPT source any
destination
any.
Elle semble fonctionnelle, et je pensais qu'elle prendrait le dessus sur
les
autres règles déjà présentes. Ce ne serait pas le cas ?
voici ma table OUTPUT :
Note : je trouve que le format de sortie d'iptables -L n'est pas très
lisible, je préfère celui d'iptables-save.
LOGDROP tcp -- anywhere anywhere tcpflags:FIN,SYN,RST,PSH,ACK,URG/FIN,SYN,RST,PSH,ACK,URG
LOGDROP tcp -- anywhere anywhere tcp
flags:FIN,SYN,RST,PSH,ACK,URG/FIN,SYN,RST,ACK,URG
Note : ces deux règles pourraient être fusionnées en
flags:FIN,SYN,RST,ACK,URG/FIN,SYN,RST,ACK,URG
LOGDROP tcp -- anywhere anywhere tcpflags:FIN,SYN,RST,PSH,ACK,URG/NONE
C'est cette règle qui attrape le paquet TCP sans flag émis par hping3 . Il
n'est donc pas bloqué sur son état de suivi de connexion comme je l'a vais
d'abord pensé mais sur la valeur de ses flags TCP.
Accessoirement, quel est le but d'envoyer un paquet TCP sans flag, qui se ra
forcément écarté par le destinataire ? Ne faudrait-il pas fournir à hping3
les options pour émettre un paquet valide ?
Windows répond parfois à ce genre de paquets.
Hugo Deprez a écrit :
merci pour la réponse, j'ai une règle de type ACCEPT source any
destination
any.
Elle semble fonctionnelle, et je pensais qu'elle prendrait le dessus sur
les
autres règles déjà présentes. Ce ne serait pas le cas ?
voici ma table OUTPUT :
Note : je trouve que le format de sortie d'iptables -L n'est pas très
lisible, je préfère celui d'iptables-save.
LOGDROP tcp -- anywhere anywhere tcp
flags:FIN,SYN,RST,PSH,ACK,URG/FIN,SYN,RST,PSH,ACK,URG
LOGDROP tcp -- anywhere anywhere tcp
flags:FIN,SYN,RST,PSH,ACK,URG/FIN,SYN,RST,ACK,URG
Note : ces deux règles pourraient être fusionnées en
flags:FIN,SYN,RST,ACK,URG/FIN,SYN,RST,ACK,URG
LOGDROP tcp -- anywhere anywhere tcp
flags:FIN,SYN,RST,PSH,ACK,URG/NONE
C'est cette règle qui attrape le paquet TCP sans flag émis par hping3 . Il
n'est donc pas bloqué sur son état de suivi de connexion comme je l'a vais
d'abord pensé mais sur la valeur de ses flags TCP.
Accessoirement, quel est le but d'envoyer un paquet TCP sans flag, qui se ra
forcément écarté par le destinataire ? Ne faudrait-il pas fournir à hping3
les options pour émettre un paquet valide ?
Windows répond parfois à ce genre de paquets.
Hugo Deprez a écrit :merci pour la réponse, j'ai une règle de type ACCEPT source any
destination
any.
Elle semble fonctionnelle, et je pensais qu'elle prendrait le dessus sur
les
autres règles déjà présentes. Ce ne serait pas le cas ?
voici ma table OUTPUT :
Note : je trouve que le format de sortie d'iptables -L n'est pas très
lisible, je préfère celui d'iptables-save.
LOGDROP tcp -- anywhere anywhere tcpflags:FIN,SYN,RST,PSH,ACK,URG/FIN,SYN,RST,PSH,ACK,URG
LOGDROP tcp -- anywhere anywhere tcp
flags:FIN,SYN,RST,PSH,ACK,URG/FIN,SYN,RST,ACK,URG
Note : ces deux règles pourraient être fusionnées en
flags:FIN,SYN,RST,ACK,URG/FIN,SYN,RST,ACK,URG
LOGDROP tcp -- anywhere anywhere tcpflags:FIN,SYN,RST,PSH,ACK,URG/NONE
C'est cette règle qui attrape le paquet TCP sans flag émis par hping3 . Il
n'est donc pas bloqué sur son état de suivi de connexion comme je l'a vais
d'abord pensé mais sur la valeur de ses flags TCP.
Accessoirement, quel est le but d'envoyer un paquet TCP sans flag, qui se ra
forcément écarté par le destinataire ? Ne faudrait-il pas fournir à hping3
les options pour émettre un paquet valide ?
Windows répond parfois à ce genre de paquets.
Le 23 juillet 2010 18:15, Pascal Hambourg a
écrit :
Hugo Deprez a écrit :merci pour la réponse, j'ai une règle de type ACCEPT source any
destination
any.
Elle semble fonctionnelle, et je pensais qu'elle prendrait le dessus su r
les
autres règles déjà présentes. Ce ne serait pas le cas ?
voici ma table OUTPUT :
Note : je trouve que le format de sortie d'iptables -L n'est pas très
lisible, je préfère celui d'iptables-save.
LOGDROP tcp -- anywhere anywhere tcpflags:FIN,SYN,RST,PSH,ACK,URG/FIN,SYN,RST,PSH,ACK,URG
LOGDROP tcp -- anywhere anywhere tcp
flags:FIN,SYN,RST,PSH,ACK,URG/FIN,SYN,RST,ACK,URG
Note : ces deux règles pourraient être fusionnées en
flags:FIN,SYN,RST,ACK,URG/FIN,SYN,RST,ACK,URG
LOGDROP tcp -- anywhere anywhere tcpflags:FIN,SYN,RST,PSH,ACK,URG/NONE
C'est cette règle qui attrape le paquet TCP sans flag émis par hping 3. Il
n'est donc pas bloqué sur son état de suivi de connexion comme je l' avais
d'abord pensé mais sur la valeur de ses flags TCP.
Effectivement.
Si tu ne veux pas t'émbêter, il peut être judicieux de n'effectuer ce genre
de filtrage qu'en entrée. Mais en cas de scan nmap par exemple, tu aura s des
retours dropés.
Accessoirement, quel est le but d'envoyer un paquet TCP sans flag, qui
sera forcément écarté par le destinataire ? Ne faudrait-il pas fou rnir à
hping3 les options pour émettre un paquet valide ?
Windows répond parfois à ce genre de paquets.
Pour ce qui est des paquets invalides, voici un exemple:
iptables -t filter -A INPUT -m state --state INVALID -j DROP
Le 23 juillet 2010 18:15, Pascal Hambourg <pascal.mail@plouf.fr.eu.org> a
écrit :
Hugo Deprez a écrit :
merci pour la réponse, j'ai une règle de type ACCEPT source any
destination
any.
Elle semble fonctionnelle, et je pensais qu'elle prendrait le dessus su r
les
autres règles déjà présentes. Ce ne serait pas le cas ?
voici ma table OUTPUT :
Note : je trouve que le format de sortie d'iptables -L n'est pas très
lisible, je préfère celui d'iptables-save.
LOGDROP tcp -- anywhere anywhere tcp
flags:FIN,SYN,RST,PSH,ACK,URG/FIN,SYN,RST,PSH,ACK,URG
LOGDROP tcp -- anywhere anywhere tcp
flags:FIN,SYN,RST,PSH,ACK,URG/FIN,SYN,RST,ACK,URG
Note : ces deux règles pourraient être fusionnées en
flags:FIN,SYN,RST,ACK,URG/FIN,SYN,RST,ACK,URG
LOGDROP tcp -- anywhere anywhere tcp
flags:FIN,SYN,RST,PSH,ACK,URG/NONE
C'est cette règle qui attrape le paquet TCP sans flag émis par hping 3. Il
n'est donc pas bloqué sur son état de suivi de connexion comme je l' avais
d'abord pensé mais sur la valeur de ses flags TCP.
Effectivement.
Si tu ne veux pas t'émbêter, il peut être judicieux de n'effectuer ce genre
de filtrage qu'en entrée. Mais en cas de scan nmap par exemple, tu aura s des
retours dropés.
Accessoirement, quel est le but d'envoyer un paquet TCP sans flag, qui
sera forcément écarté par le destinataire ? Ne faudrait-il pas fou rnir à
hping3 les options pour émettre un paquet valide ?
Windows répond parfois à ce genre de paquets.
Pour ce qui est des paquets invalides, voici un exemple:
iptables -t filter -A INPUT -m state --state INVALID -j DROP
Le 23 juillet 2010 18:15, Pascal Hambourg a
écrit :
Hugo Deprez a écrit :merci pour la réponse, j'ai une règle de type ACCEPT source any
destination
any.
Elle semble fonctionnelle, et je pensais qu'elle prendrait le dessus su r
les
autres règles déjà présentes. Ce ne serait pas le cas ?
voici ma table OUTPUT :
Note : je trouve que le format de sortie d'iptables -L n'est pas très
lisible, je préfère celui d'iptables-save.
LOGDROP tcp -- anywhere anywhere tcpflags:FIN,SYN,RST,PSH,ACK,URG/FIN,SYN,RST,PSH,ACK,URG
LOGDROP tcp -- anywhere anywhere tcp
flags:FIN,SYN,RST,PSH,ACK,URG/FIN,SYN,RST,ACK,URG
Note : ces deux règles pourraient être fusionnées en
flags:FIN,SYN,RST,ACK,URG/FIN,SYN,RST,ACK,URG
LOGDROP tcp -- anywhere anywhere tcpflags:FIN,SYN,RST,PSH,ACK,URG/NONE
C'est cette règle qui attrape le paquet TCP sans flag émis par hping 3. Il
n'est donc pas bloqué sur son état de suivi de connexion comme je l' avais
d'abord pensé mais sur la valeur de ses flags TCP.
Effectivement.
Si tu ne veux pas t'émbêter, il peut être judicieux de n'effectuer ce genre
de filtrage qu'en entrée. Mais en cas de scan nmap par exemple, tu aura s des
retours dropés.
Accessoirement, quel est le but d'envoyer un paquet TCP sans flag, qui
sera forcément écarté par le destinataire ? Ne faudrait-il pas fou rnir à
hping3 les options pour émettre un paquet valide ?
Windows répond parfois à ce genre de paquets.
Pour ce qui est des paquets invalides, voici un exemple:
iptables -t filter -A INPUT -m state --state INVALID -j DROP
Par contre ce que je ne saisis pas c'est pourquoi iptables, malgré ma règle
-A OUTPUT -s 192.16.0.1/32 -j LOGACCEPT
il applique la règle
-A OUTPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j LOGDROP
Es-ce que c'est le fait que cette dernière soit avant la règle LOGACCEPT ?
Par contre ce que je ne saisis pas c'est pourquoi iptables, malgré ma règle
-A OUTPUT -s 192.16.0.1/32 -j LOGACCEPT
il applique la règle
-A OUTPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j LOGDROP
Es-ce que c'est le fait que cette dernière soit avant la règle LOGACCEPT ?
Par contre ce que je ne saisis pas c'est pourquoi iptables, malgré ma règle
-A OUTPUT -s 192.16.0.1/32 -j LOGACCEPT
il applique la règle
-A OUTPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j LOGDROP
Es-ce que c'est le fait que cette dernière soit avant la règle LOGACCEPT ?
Par contre ce que je ne saisis pas c'est pourquoi iptables, malgré ma règle
-A OUTPUT -s 192.16.0.1/32 -j LOGACCEPT
il applique la règle
-A OUTPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j LOGDROP
Es-ce que c'est le fait que cette dernière soit avant la règle LOGACCEPT ?
Par contre ce que je ne saisis pas c'est pourquoi iptables, malgré ma règle
-A OUTPUT -s 192.16.0.1/32 -j LOGACCEPT
il applique la règle
-A OUTPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j LOGDROP
Es-ce que c'est le fait que cette dernière soit avant la règle LOGACCEPT ?
Par contre ce que je ne saisis pas c'est pourquoi iptables, malgré ma règle
-A OUTPUT -s 192.16.0.1/32 -j LOGACCEPT
il applique la règle
-A OUTPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j LOGDROP
Es-ce que c'est le fait que cette dernière soit avant la règle LOGACCEPT ?
Hugo Deprez a écrit :Par contre ce que je ne saisis pas c'est pourquoi iptables, malgré m a
règle
-A OUTPUT -s 192.16.0.1/32 -j LOGACCEPT
il applique la règle
-A OUTPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j
LOGDROP
Es-ce que c'est le fait que cette dernière soit avant la règle LOGA CCEPT
?
Tu peux utiliser la commande "iptables -L -v" pour voir les compteurs
associés aux règles. Cela te permettra de connaître les règles qu i sont
utilisées.
--
======================== ======================
| FRÉDÉRIC MASSOT |
| http://www.juliana-multimedia.com |
| mailto: |
======================== ==Þbian=GNU/Linux===
--
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/
Hugo Deprez a écrit :
Par contre ce que je ne saisis pas c'est pourquoi iptables, malgré m a
règle
-A OUTPUT -s 192.16.0.1/32 -j LOGACCEPT
il applique la règle
-A OUTPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j
LOGDROP
Es-ce que c'est le fait que cette dernière soit avant la règle LOGA CCEPT
?
Tu peux utiliser la commande "iptables -L -v" pour voir les compteurs
associés aux règles. Cela te permettra de connaître les règles qu i sont
utilisées.
--
======================== ======================
| FRÉDÉRIC MASSOT |
| http://www.juliana-multimedia.com |
| mailto:frederic@juliana-multimedia.com |
======================== ===Debian=GNU/Linux===
--
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/4C4E2B40.5030608@juliana-multimedia.com
Hugo Deprez a écrit :Par contre ce que je ne saisis pas c'est pourquoi iptables, malgré m a
règle
-A OUTPUT -s 192.16.0.1/32 -j LOGACCEPT
il applique la règle
-A OUTPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j
LOGDROP
Es-ce que c'est le fait que cette dernière soit avant la règle LOGA CCEPT
?
Tu peux utiliser la commande "iptables -L -v" pour voir les compteurs
associés aux règles. Cela te permettra de connaître les règles qu i sont
utilisées.
--
======================== ======================
| FRÉDÉRIC MASSOT |
| http://www.juliana-multimedia.com |
| mailto: |
======================== ==Þbian=GNU/Linux===
--
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/