Forums Linux Autres OS Linux Debian

hping3 avec iptables

Le
Hugo Deprez Avatar par défaut
--0016e6d971082406b4048c0efd57
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Bonjour,


j'ai installé hping3 sur une lenny. Mon serveur est firewallé avec ipta=
bles,
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
SRC=192.168.0.2 DST=192.168.0.1 LEN=40 TOS=0x00 PREC=0x00 TTL=6=
4
ID=8599 PROTO=TCP SPT=1655 DPT=21 WINDOW=512 RES=0x00 URGP=0 =
UID=0 GID=0


Le paquet est dropé. J'ai teste avec iptables désactivé ça fonction=
ne.
Par contre quand j'active mes règles firewall et que je fais un iptables =
-t
filter -P OUTPUT ACCEPT, le paquet est toujours dropé.

Je ne connais pas trop le fonctionnement de Hping3, peut-être essaye-t-il=
de
faire quelque chose en particulier ?


Si vous avez des pistes je suis preneur.

Merci

--0016e6d971082406b4048c0efd57
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Bonjour,<br><br><br>j&#39;ai installé hping3 sur une lenny. Mon serveur e=
st firewallé avec iptables, j&#39;autorise tout en sortie.<br>Par contre =
quand j&#39;exécute la commande suivante :<br><br>$ sudo  /usr/sbin/hpi=
ng3 -V 192.168.0.1 -p 21<br>

using eth0, addr: 192.168.0.2, MTU: 1500<br>
HPING 192.168.0.1 (eth0 192.168.0.2): NO FLAGS are set, 40 headers + 0 data=
bytes<br>
[send_ip] sendto: Operation not permitted<br><br><br>Voici le log de l&#39;=
iptables :<br><br>Jul 23 11:35:12 monhost kernel: [2990025.691301] [FW-DROP=
] IN= OUT=eth0<br>SRC=192.168.0.2 DST=192.168.0.1 LEN=40 TOS=0x=
00 PREC=0x00 TTL=64<br>
ID=8599 PROTO=TCP SPT=1655 DPT=21 WINDOW=512 RES=0x00 URGP=0 =
UID=0 GID=0<br><br><br>Le paquet est dropé. J&#39;ai teste avec iptab=
les désactivé ça fonctionne.<br>Par contre quand j&#39;active mes r=
ègles firewall et que je fais un iptables -t filter -P OUTPUT ACCEPT, le =
paquet est toujours dropé.<br>
<br>Je ne connais pas trop le fonctionnement de Hping3, peut-être essaye-=
t-il de faire quelque chose en particulier ?<br><br><br>Si vous avez des pi=
stes je suis preneur.<br><br>Merci<br><br><br><br><br><br><br>

--0016e6d971082406b4048c0efd57--

--
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/AANLkTik+ekw9WaTYZcBTvjYeCaswYB7fZMFdJNWfVWem@mail.gmail.com
Vos réponses
Trier par : date / pertinence
Pascal Hambourg Avatar par défaut
Le #22387791
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=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



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 iptables dans OUTPUT ou une chaîne utilisateur appelée depuis
là qui bloque les paquets 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/
Répondre en citant
Hugo Deprez Avatar par défaut
Le #22387781
--0015175df034ea95a8048c101d4f
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Bonjour,

merci pour la réponse, j'ai une règle de type ACCEPT source any destina tion
any.
Elle semble fonctionnelle, et je pensais qu'elle prendrait le dessus sur le s
autres règles déjà présentes. Ce ne serait pas le cas ?


voici ma table OUTPUT :

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
LOGDROP tcp -- anywhere anywhere tcp
flags:FIN,SYN,RST,PSH,ACK,URG/FIN,PSH,URG
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
LOGDROP tcp -- anywhere anywhere tcp
flags:SYN,RST/SYN,RST
LOGDROP tcp -- anywhere anywhere tcp
flags:FIN,SYN/FIN,SYN
LOGACCEPT all -- anywhere anywhere
LOGACCEPT all -- anywhere anywhere state
RELATED,ESTABLISHED
LOGACCEPT tcp -- monserver.mondomaine.fr server2.mondomaine.fr tcp
dpt:8140
LOGACCEPT tcp -- monserver.mondomaine.fr server.mondomaine.fr tcp
dpt:ldap
[...]
LOGACCEPT all -- monserver.mondomaine.fr anywhere
LOGDROP all -- anywhere anywhere

Quel commande sur iptables permet de traiter/qualifier les paquets 'INVALID '
?

D'avance merci

Hugo

2010/7/23 Pascal Hambourg
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/





--0015175df034ea95a8048c101d4f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Bonjour, <br><br>voici ma table OUTPUT :<br><br>Chain OUTPUT (policy ACCEPT)<br>targ et     prot opt source               de stination<br>LOGDROP    tcp  --  anywhere              anywhere            tcp flags:FIN,SYN,RS T,PSH,ACK,URG/FIN,PSH,URG<br>
LOGDROP    tcp  --  anywhere             anywhere            tcp flags:FIN,SYN,RST,PSH,ACK,URG /FIN,SYN,RST,PSH,ACK,URG<br>LOGDROP    tcp  --  anywhere              anywhere            tcp f lags:FIN,SYN,RST,PSH,ACK,URG/FIN,SYN,RST,ACK,URG<br>
LOGDROP    tcp  --  anywhere             anywhere            tcp flags:FIN,SYN,RST,PSH,ACK,URG /NONE<br>LOGDROP    tcp  --  anywhere              anywhere            tcp flags:SYN,RST/SYN,R ST<br>LOGDROP    tcp  --  anywhere              anywhere            tcp flags:FIN,SYN/FIN,SYN< br>
LOGACCEPT  all  --  anywhere             anyw here LOGACCEPT  tcp  --  LOGDROP    all  --  anywhere             anywhere <br>
Hugo Deprez a écrit :<div class="im"><br>
<br>
j&#39;ai installé hping3 sur une lenny. Mon serveur est firewallé avec iptables,<br>
j&#39;autorise tout en sortie.<br>
Par contre quand j&#39;exécute la commande suivante :<br>
<br>
$ sudo  /usr/sbin/hping3 -V 192.168.0.1 -p 21<br>
using eth0, addr: 192.168.0.2, MTU: 1500<br>
HPING 192.168.0.1 (eth0 192.168.0.2): NO FLAGS are set, 40 headers + 0 data <br>
bytes<br>
[send_ip] sendto: Operation not permitted<br>
<br>
Voici le log de l&#39;iptables :<br>
<br>
Jul 23 11:35:12 monhost kernel: [2990025.691301] [FW-DROP] IN= OUT=eth0 <br>
SRC2.168.0.2 DST2.168.0.1 LEN@ TOS=0x00 PREC=0x00 TTL=6 4<br>
ID…99 PROTO=TCP SPT55 DPT! WINDOWQ2 RES=0x00 URGP=0 UID=0 GID=0<br>
</blockquote>
<br></div>
Visiblement cette commande envoie un paquet TCP sans aucu flag (notamment S YN), donc le suivi de connexion de netfilter le classe probablement dans l& #39;état INVALID. Il faudrait regarder s&#39;il n&#39;y a pas une règle iptables dans OUTPUT ou une chaîne utilisateur appelée depuis là qui bloque les paquets sortants dans l&#39;état INVALID (ce qui serait assez logique quand on fait du filtrage à état puisqu&#39;une éventuelle r éponse reçue serait forcément classée INVALID elle aussi et bloqu ée).<br>
<font color="#888888">
<br>
<br>
-- <br>
Lisez la FAQ de la liste avant de poser une question :<br>
<br>
Pour vous DESABONNER, envoyez un message avec comme objet &quot;unsubscribe &quot;<br>
vers En cas de soucis, contactez EN ANGLAIS Archive: <br>
</font></blockquote></div><br>

--0015175df034ea95a8048c101d4f--

--
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/
Répondre en citant
Pascal Hambourg Avatar par défaut
Le #22387871
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'avais d'abord pensé mais sur la valeur de ses flags TCP.

Accessoirement, quel est le but d'envoyer un paquet TCP sans flag, qui
sera forcément écarté par le destinataire ? Ne faudrait-il pas fournir à
hping3 les options pour émettre un paquet valide ?


--
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/
Répondre en citant
Cornichon Avatar par défaut
Le #22387971
--0015175df0346466d4048c107740
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Le 23 juillet 2010 18:15, Pascal Hambourg é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 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.




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 auras des
retours dropés.



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.




Pour ce qui est des paquets invalides, voici un exemple:
iptables -t filter -A INPUT -m state --state INVALID -j DROP

--0015175df0346466d4048c107740
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Hugo Deprez a écrit :<div class="im"><br>
<br>
merci pour la réponse, j&#39;ai une règle de type ACCEPT source any des tination<br>
any.<br>
Elle semble fonctionnelle, et je pensais qu&#39;elle prendrait le dessus su r les<br>
autres règles déjà présentes. Ce ne serait pas le cas ?<br>
<br>
voici ma table OUTPUT :<br>
</blockquote>
<br></div>
Note : je trouve que le format de sortie d&#39;iptables -L n&#39;est pas tr ès lisible, je préfère celui d&#39;iptables-save.
<div class="im"><br>
<br>
LOGDROP    tcp  --  anywhere             anywhere            tcp<br>
flags:FIN,SYN,RST,PSH,ACK,URG/FIN,SYN,RST,PSH,ACK,URG<br>
LOGDROP    tcp  --  anywhere             anywhere            tcp<br>
flags:FIN,SYN,RST,PSH,ACK,URG/FIN,SYN,RST,ACK,URG<br>
</blockquote>
<br></div>
Note : ces deux règles pourraient être fusionnées en flags:FIN,SYN,RS T,ACK,URG/FIN,SYN,RST,ACK,URG<div class="im"><br>
<br>
LOGDROP    tcp  --  anywhere             anywhere            tcp<br>
flags:FIN,SYN,RST,PSH,ACK,URG/NONE<br>
</blockquote>
<br></div>
C&#39;est cette règle qui attrape le paquet TCP sans flag émis par hpin g3. Il n&#39;est donc pas bloqué sur son état de suivi de connexion com me je l&#39;avais d&#39;abord pensé mais sur la valeur de ses flags TCP.< br></blockquote>



<br>
Accessoirement, quel est le but d&#39;envoyer un paquet TCP sans flag, qui sera forcément écarté par le destinataire ? Ne faudrait-il pas fourni r à hping3 les options pour émettre un paquet valide ?<div class="im" ><br></div>


</div>

--0015175df0346466d4048c107740--

--
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/
Répondre en citant
Hugo Deprez Avatar par défaut
Le #22396521
--0015174c33fa63467f048c45b6a9
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Bonjour,

merci pour votre réponse ! je comprends mieux.

Je ne connais pas encore très bien hping, je trouve ça un peu étrange comme
comportement. Je vais étudier le man page.

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 LOGACCEP T ?

D'avance merci,


2010/7/23 Cornichon


Le 23 juillet 2010 18:15, Pascal Hambourg é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






--0015174c33fa63467f048c45b6a9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Bonjour,
Hugo Deprez a écrit :<div><br>
<br>
merci pour la réponse, j&#39;ai une règle de type ACCEPT source any des tination<br>
any.<br>
Elle semble fonctionnelle, et je pensais qu&#39;elle prendrait le dessus su r les<br>
autres règles déjà présentes. Ce ne serait pas le cas ?<br>
<br>
voici ma table OUTPUT :<br>
</blockquote>
<br></div>
Note : je trouve que le format de sortie d&#39;iptables -L n&#39;est pas tr ès lisible, je préfère celui d&#39;iptables-save.

<div><br>
<br>
LOGDROP    tcp  --  anywhere             anywhere            tcp<br>
flags:FIN,SYN,RST,PSH,ACK,URG/FIN,SYN,RST,PSH,ACK,URG<br>
LOGDROP    tcp  --  anywhere             anywhere            tcp<br>
flags:FIN,SYN,RST,PSH,ACK,URG/FIN,SYN,RST,ACK,URG<br>
</blockquote>
<br></div>
Note : ces deux règles pourraient être fusionnées en flags:FIN,SYN,RS T,ACK,URG/FIN,SYN,RST,ACK,URG<div><br>
<br>
LOGDROP    tcp  --  anywhere             anywhere            tcp<br>
flags:FIN,SYN,RST,PSH,ACK,URG/NONE<br>
</blockquote>
<br></div>
C&#39;est cette règle qui attrape le paquet TCP sans flag émis par hpin g3. Il n&#39;est donc pas bloqué sur son état de suivi de connexion com me je l&#39;avais d&#39;abord pensé mais sur la valeur de ses flags TCP.< br></blockquote>




<br>
Accessoirement, quel est le but d&#39;envoyer un paquet TCP sans flag, qui sera forcément écarté par le destinataire ? Ne faudrait-il pas fourni r à hping3 les options pour émettre un paquet valide ?<div><br></div>

<br></div>

</div>
</blockquote></div><br>

--0015174c33fa63467f048c45b6a9--

--
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/AANLkTim=
Répondre en citant
Pascal Hambourg Avatar par défaut
Le #22401281
Hugo Deprez a écrit :

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 ?



Oui, l'ordre des règles compte.


--
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/
Répondre en citant
Frederic MASSOT Avatar par défaut
Le #22401831
Hugo Deprez a écrit :

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 ?





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 qui 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/
Répondre en citant
Hugo Deprez Avatar par défaut
Le #22420331
--00032555b6461e5982048c99dc97
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Merci à vous pour toutes ces informations utiles.

Hugo

2010/7/27 Frederic MASSOT
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/





--00032555b6461e5982048c99dc97
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Merci à vous pour toutes  ces informations utiles.
<br>
Par contre ce que je ne saisis pas c&#39;est  pourquoi iptables, malgré ma règle<br>
<br>
-A OUTPUT -s <br>
il applique la règle<br>
<br>
-A OUTPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j LOGDROP <br>
<br>
Es-ce que c&#39;est le fait que cette dernière soit avant la règle LOGA CCEPT ?<br>
</blockquote></blockquote>
<br></div>
Tu peux utiliser la commande &quot;iptables -L -v&quot; pour voir les compt eurs associés aux règles. Cela te permettra de connaître les règles qui sont utilisées.<br>
<br>
<br>
-- <br>
========================= =====================<br>
|              FRÉDÉRIC MASSOT               |<br>
|     |   mailto: ========================= =Þbian=GNU/Linux===<div class="im"><br>
<br>
-- <br>
Lisez la FAQ de la liste avant de poser une question :<br>
<br>
Pour vous DESABONNER, envoyez un message avec comme objet &quot;unsubscribe &quot;<br>
vers En cas de soucis, contactez EN ANGLAIS Archive: <br>
</blockquote></div><br>

--00032555b6461e5982048c99dc97--

--
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/AANLkTinE=X9cbZz4yXqYcf__m_f-v2L+
Répondre en citant
Publicité
Poster une réponse
Anonyme Avatar par défaut