Salut,
Derrière mon firewall (iptables) j'ai un serveur ftp (proftpd), sur lequel
je peut me connecter, mais ne peut plus rentrer en mode passif !
Les régles iptables n'ont pas changer de l'ancien serveur au nouveau. Cela
fonctionnait bien avant.
Voici les régles.
#FTP ********************************************
[...]
Je vais être obliger de sortir le firewall et là, je frémis !
Salut,
Derrière mon firewall (iptables) j'ai un serveur ftp (proftpd), sur lequel
je peut me connecter, mais ne peut plus rentrer en mode passif !
Les régles iptables n'ont pas changer de l'ancien serveur au nouveau. Cela
fonctionnait bien avant.
Voici les régles.
#FTP ********************************************
[...]
Je vais être obliger de sortir le firewall et là, je frémis !
Salut,
Derrière mon firewall (iptables) j'ai un serveur ftp (proftpd), sur lequel
je peut me connecter, mais ne peut plus rentrer en mode passif !
Les régles iptables n'ont pas changer de l'ancien serveur au nouveau. Cela
fonctionnait bien avant.
Voici les régles.
#FTP ********************************************
[...]
Je vais être obliger de sortir le firewall et là, je frémis !
Le FTP étant un protocole applicatif spécial, il nécéssite sous Linux
l'utilisation d'un module de suivi de connexion, ip_conntrack_ftp, pour que
les connexions FTP soient filtrées correctement par le firewall.
Il faut donc charger ce module :
modprobe ip_conntrack_ftp
grmbl ! ip_conntrack est chargé au démarrage, pas ip_conntrack_ftp !
Les régles iptables n'ont pas changer de l'ancien serveur au nouveau. Cela
fonctionnait bien avant.
Voici les régles.
#FTP ********************************************
[...]
Je ne vais pas commenter vos règles, disons que d'une manière générale elles
sont redondantes et trop nombreuses pour être efficace.
Le filtrage des connexions FTP en entrée devrait se résumer à une règle
principale et à une autre règle commune à l'ensemble des éventuelles autres
règles :
iptables -A INPUT -i ppp0 -p tcp --dport 21 -m state --state NEW -j ACCEPT
iptables -A INPUT -i ppp0 -m state --state RELATED,ESTABLISHED -j ACCEPT
Le filtrage en sortie dans le cas où la politique est de ne rien autoriser
(iptables -P OUTPUT DROP) :
iptables -A OUTPUT -o ppp0 -p tcp --sport 21 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -o ppp0 -m state --state RELATED,ESTABLISHED -j ACCEPT
Oui, l'iptables, c'est du clair/obscurt pour moi. Ou je mis suit pas assez
Je vais être obliger de sortir le firewall et là, je frémis !
Mais non, faut pas tant craindre d'être attaqué. :)
Une attaque sur l'apache par jour (en essayant une attaque IIS),10
Le FTP étant un protocole applicatif spécial, il nécéssite sous Linux
l'utilisation d'un module de suivi de connexion, ip_conntrack_ftp, pour que
les connexions FTP soient filtrées correctement par le firewall.
Il faut donc charger ce module :
modprobe ip_conntrack_ftp
grmbl ! ip_conntrack est chargé au démarrage, pas ip_conntrack_ftp !
Les régles iptables n'ont pas changer de l'ancien serveur au nouveau. Cela
fonctionnait bien avant.
Voici les régles.
#FTP ********************************************
[...]
Je ne vais pas commenter vos règles, disons que d'une manière générale elles
sont redondantes et trop nombreuses pour être efficace.
Le filtrage des connexions FTP en entrée devrait se résumer à une règle
principale et à une autre règle commune à l'ensemble des éventuelles autres
règles :
iptables -A INPUT -i ppp0 -p tcp --dport 21 -m state --state NEW -j ACCEPT
iptables -A INPUT -i ppp0 -m state --state RELATED,ESTABLISHED -j ACCEPT
Le filtrage en sortie dans le cas où la politique est de ne rien autoriser
(iptables -P OUTPUT DROP) :
iptables -A OUTPUT -o ppp0 -p tcp --sport 21 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -o ppp0 -m state --state RELATED,ESTABLISHED -j ACCEPT
Oui, l'iptables, c'est du clair/obscurt pour moi. Ou je mis suit pas assez
Je vais être obliger de sortir le firewall et là, je frémis !
Mais non, faut pas tant craindre d'être attaqué. :)
Une attaque sur l'apache par jour (en essayant une attaque IIS),10
Le FTP étant un protocole applicatif spécial, il nécéssite sous Linux
l'utilisation d'un module de suivi de connexion, ip_conntrack_ftp, pour que
les connexions FTP soient filtrées correctement par le firewall.
Il faut donc charger ce module :
modprobe ip_conntrack_ftp
grmbl ! ip_conntrack est chargé au démarrage, pas ip_conntrack_ftp !
Les régles iptables n'ont pas changer de l'ancien serveur au nouveau. Cela
fonctionnait bien avant.
Voici les régles.
#FTP ********************************************
[...]
Je ne vais pas commenter vos règles, disons que d'une manière générale elles
sont redondantes et trop nombreuses pour être efficace.
Le filtrage des connexions FTP en entrée devrait se résumer à une règle
principale et à une autre règle commune à l'ensemble des éventuelles autres
règles :
iptables -A INPUT -i ppp0 -p tcp --dport 21 -m state --state NEW -j ACCEPT
iptables -A INPUT -i ppp0 -m state --state RELATED,ESTABLISHED -j ACCEPT
Le filtrage en sortie dans le cas où la politique est de ne rien autoriser
(iptables -P OUTPUT DROP) :
iptables -A OUTPUT -o ppp0 -p tcp --sport 21 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -o ppp0 -m state --state RELATED,ESTABLISHED -j ACCEPT
Oui, l'iptables, c'est du clair/obscurt pour moi. Ou je mis suit pas assez
Je vais être obliger de sortir le firewall et là, je frémis !
Mais non, faut pas tant craindre d'être attaqué. :)
Une attaque sur l'apache par jour (en essayant une attaque IIS),10
iptables -A INPUT -i ppp0 -p tcp --dport 21 -m state --state NEW -j ACCEPT
iptables -A INPUT -i ppp0 -m state --state RELATED,ESTABLISHED -j ACCEPT
Le filtrage en sortie dans le cas où la politique est de ne rien autoriser
(iptables -P OUTPUT DROP) :
iptables -A OUTPUT -o ppp0 -p tcp --sport 21 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -o ppp0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i ppp0 -p tcp --dport 21 -m state --state NEW -j ACCEPT
iptables -A INPUT -i ppp0 -m state --state RELATED,ESTABLISHED -j ACCEPT
Le filtrage en sortie dans le cas où la politique est de ne rien autoriser
(iptables -P OUTPUT DROP) :
iptables -A OUTPUT -o ppp0 -p tcp --sport 21 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -o ppp0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i ppp0 -p tcp --dport 21 -m state --state NEW -j ACCEPT
iptables -A INPUT -i ppp0 -m state --state RELATED,ESTABLISHED -j ACCEPT
Le filtrage en sortie dans le cas où la politique est de ne rien autoriser
(iptables -P OUTPUT DROP) :
iptables -A OUTPUT -o ppp0 -p tcp --sport 21 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -o ppp0 -m state --state RELATED,ESTABLISHED -j ACCEPT
B'jour,
je m'incruste dans la discussion parce que je suis en train de
peaufiner mes propres règles iptables.iptables -A INPUT -i ppp0 -p tcp --dport 21 -m state --state NEW -j
ACCEPT
iptables -A INPUT -i ppp0 -m state --state RELATED,ESTABLISHED -j
ACCEPT
Que pensez-vous de l'ajout d'un --syn sur la première règle ?
Aussi, j'aurais tendance à inverser l'ordre des deux règles parce que la
seconde a beaucoup plus de chance de "matcher" que la première : un seul
paquet NEW par session FTP, un RELATED par transfert et plein
d'ESTABLISHED.
Est-ce que ça aurait réellement une influence sur les performances ?
Le filtrage en sortie dans le cas où la politique est de ne rien
autoriser (iptables -P OUTPUT DROP) :
iptables -A OUTPUT -o ppp0 -p tcp --sport 21 -m state --state NEW -j
ACCEPT
Cette règle est-elle bien utile ?
B'jour,
je m'incruste dans la discussion parce que je suis en train de
peaufiner mes propres règles iptables.
iptables -A INPUT -i ppp0 -p tcp --dport 21 -m state --state NEW -j
ACCEPT
iptables -A INPUT -i ppp0 -m state --state RELATED,ESTABLISHED -j
ACCEPT
Que pensez-vous de l'ajout d'un --syn sur la première règle ?
Aussi, j'aurais tendance à inverser l'ordre des deux règles parce que la
seconde a beaucoup plus de chance de "matcher" que la première : un seul
paquet NEW par session FTP, un RELATED par transfert et plein
d'ESTABLISHED.
Est-ce que ça aurait réellement une influence sur les performances ?
Le filtrage en sortie dans le cas où la politique est de ne rien
autoriser (iptables -P OUTPUT DROP) :
iptables -A OUTPUT -o ppp0 -p tcp --sport 21 -m state --state NEW -j
ACCEPT
Cette règle est-elle bien utile ?
B'jour,
je m'incruste dans la discussion parce que je suis en train de
peaufiner mes propres règles iptables.iptables -A INPUT -i ppp0 -p tcp --dport 21 -m state --state NEW -j
ACCEPT
iptables -A INPUT -i ppp0 -m state --state RELATED,ESTABLISHED -j
ACCEPT
Que pensez-vous de l'ajout d'un --syn sur la première règle ?
Aussi, j'aurais tendance à inverser l'ordre des deux règles parce que la
seconde a beaucoup plus de chance de "matcher" que la première : un seul
paquet NEW par session FTP, un RELATED par transfert et plein
d'ESTABLISHED.
Est-ce que ça aurait réellement une influence sur les performances ?
Le filtrage en sortie dans le cas où la politique est de ne rien
autoriser (iptables -P OUTPUT DROP) :
iptables -A OUTPUT -o ppp0 -p tcp --sport 21 -m state --state NEW -j
ACCEPT
Cette règle est-elle bien utile ?
Oui, vous avez entièrement raison et alors que j'essaye toujours d'optimiser
mes règles iptables et de les placer au mieux, je n'avais jamais pensé à
mieux placer la règle qui matchent les paquets ESTABLISHED et RELATED.
Est-ce que ça aurait réellement une influence sur les performances ?
En théorie oui comme vous l'avez démontré, mais en pratique cela dépend bien
sûr du nombre de règles et aussi du débit, des performances de la machine,
etc. Il serait intéressant un jour, car c'est une question qui revient
souvent, de faire une série de tests sur les performances de telle ou telle
règle et les ressources consommées.
Oui, vous avez entièrement raison et alors que j'essaye toujours d'optimiser
mes règles iptables et de les placer au mieux, je n'avais jamais pensé à
mieux placer la règle qui matchent les paquets ESTABLISHED et RELATED.
Est-ce que ça aurait réellement une influence sur les performances ?
En théorie oui comme vous l'avez démontré, mais en pratique cela dépend bien
sûr du nombre de règles et aussi du débit, des performances de la machine,
etc. Il serait intéressant un jour, car c'est une question qui revient
souvent, de faire une série de tests sur les performances de telle ou telle
règle et les ressources consommées.
Oui, vous avez entièrement raison et alors que j'essaye toujours d'optimiser
mes règles iptables et de les placer au mieux, je n'avais jamais pensé à
mieux placer la règle qui matchent les paquets ESTABLISHED et RELATED.
Est-ce que ça aurait réellement une influence sur les performances ?
En théorie oui comme vous l'avez démontré, mais en pratique cela dépend bien
sûr du nombre de règles et aussi du débit, des performances de la machine,
etc. Il serait intéressant un jour, car c'est une question qui revient
souvent, de faire une série de tests sur les performances de telle ou telle
règle et les ressources consommées.
TiChou wrote:
Oui, vous avez entièrement raison et alors que j'essaye toujours
d'optimiser mes règles iptables et de les placer au mieux, je n'avais
jamais pensé à mieux placer la règle qui matchent les paquets ESTABLISHED
et RELATED.
Il doit être plus logique pour l'esprit humain de placer cette règle en
fin de liste à la suite des règles autorisant l'établissement des
connexions. Et je crains qu'un script dans lequel les règles sont
placées dans un ordre optimal pour la vitesse de traitement soit assez
peu lisible.
Est-ce que ça aurait réellement une influence sur les performances ?
En théorie oui comme vous l'avez démontré, mais en pratique cela dépend
bien sûr du nombre de règles et aussi du débit, des performances de la
machine, etc. Il serait intéressant un jour, car c'est une question qui
revient souvent, de faire une série de tests sur les performances de
telle ou telle règle et les ressources consommées.
Je demande, parce que la machine qui me sert de routeur est actuellement
un Pentium 100 sur laquelle tourne un noyau 2.2 avec ipchains (la
nouvelle version que je prépare avec votre aide n'est pas encore prête)
qui ne sert que du routage NAT avec un petit nombre de règles ipchains
pour une ligne ADSL 512/128 en PPPoE. Avant, c'était un 486DX-33 qui
jouait ce rôle, et je pensais que c'était largement suffisant pour cette
tâche dans la mesure où l'occupation CPU restait modeste. Or depuis le
changement de matériel j'ai gagné plusieurs millisecondes de latence. A
moins que le remplacement des cartes réseau (3C509 -> 3C509B et NE2000
ISA -> NE2000 PCI) y soit aussi pour quelque chose. Comme le futur
noyau 2.4 sera plus lourd à gérer et comme ce routeur assurera des
fonctions supplémentaires (serveur SSH et VPN), l'idée d'optimiser le
traitement des paquets me paraît ne pas être à négliger. Des avis ?
D'autre part, je vois le plus souvent dans la même règle l'acceptation
des paquets ESTABLISHED et RELATED. Or les paquets RELATED peuvent
contenir diverses choses, comme des messages ICMP, qui, il me semble,
nécessitent un filtrage un peu plus serré. Aussi j'aurais tendance à
séparer le traitement des deux états. Le traitement des paquets
ESTABLISHED, normalement les plus fréquents, resterait en début de
chaîne pour l'efficacité et le traitement des paquets RELATED se
trouverait plus bas avec celui des NEW, après les règles de filtrage des
trucs indésirables pour la sécurité. Cela ne pénaliserait pas les
performances puisque ces paquet sont normalement rares. Qu'en
pensez-vous ?
TiChou wrote:
Oui, vous avez entièrement raison et alors que j'essaye toujours
d'optimiser mes règles iptables et de les placer au mieux, je n'avais
jamais pensé à mieux placer la règle qui matchent les paquets ESTABLISHED
et RELATED.
Il doit être plus logique pour l'esprit humain de placer cette règle en
fin de liste à la suite des règles autorisant l'établissement des
connexions. Et je crains qu'un script dans lequel les règles sont
placées dans un ordre optimal pour la vitesse de traitement soit assez
peu lisible.
Est-ce que ça aurait réellement une influence sur les performances ?
En théorie oui comme vous l'avez démontré, mais en pratique cela dépend
bien sûr du nombre de règles et aussi du débit, des performances de la
machine, etc. Il serait intéressant un jour, car c'est une question qui
revient souvent, de faire une série de tests sur les performances de
telle ou telle règle et les ressources consommées.
Je demande, parce que la machine qui me sert de routeur est actuellement
un Pentium 100 sur laquelle tourne un noyau 2.2 avec ipchains (la
nouvelle version que je prépare avec votre aide n'est pas encore prête)
qui ne sert que du routage NAT avec un petit nombre de règles ipchains
pour une ligne ADSL 512/128 en PPPoE. Avant, c'était un 486DX-33 qui
jouait ce rôle, et je pensais que c'était largement suffisant pour cette
tâche dans la mesure où l'occupation CPU restait modeste. Or depuis le
changement de matériel j'ai gagné plusieurs millisecondes de latence. A
moins que le remplacement des cartes réseau (3C509 -> 3C509B et NE2000
ISA -> NE2000 PCI) y soit aussi pour quelque chose. Comme le futur
noyau 2.4 sera plus lourd à gérer et comme ce routeur assurera des
fonctions supplémentaires (serveur SSH et VPN), l'idée d'optimiser le
traitement des paquets me paraît ne pas être à négliger. Des avis ?
D'autre part, je vois le plus souvent dans la même règle l'acceptation
des paquets ESTABLISHED et RELATED. Or les paquets RELATED peuvent
contenir diverses choses, comme des messages ICMP, qui, il me semble,
nécessitent un filtrage un peu plus serré. Aussi j'aurais tendance à
séparer le traitement des deux états. Le traitement des paquets
ESTABLISHED, normalement les plus fréquents, resterait en début de
chaîne pour l'efficacité et le traitement des paquets RELATED se
trouverait plus bas avec celui des NEW, après les règles de filtrage des
trucs indésirables pour la sécurité. Cela ne pénaliserait pas les
performances puisque ces paquet sont normalement rares. Qu'en
pensez-vous ?
TiChou wrote:
Oui, vous avez entièrement raison et alors que j'essaye toujours
d'optimiser mes règles iptables et de les placer au mieux, je n'avais
jamais pensé à mieux placer la règle qui matchent les paquets ESTABLISHED
et RELATED.
Il doit être plus logique pour l'esprit humain de placer cette règle en
fin de liste à la suite des règles autorisant l'établissement des
connexions. Et je crains qu'un script dans lequel les règles sont
placées dans un ordre optimal pour la vitesse de traitement soit assez
peu lisible.
Est-ce que ça aurait réellement une influence sur les performances ?
En théorie oui comme vous l'avez démontré, mais en pratique cela dépend
bien sûr du nombre de règles et aussi du débit, des performances de la
machine, etc. Il serait intéressant un jour, car c'est une question qui
revient souvent, de faire une série de tests sur les performances de
telle ou telle règle et les ressources consommées.
Je demande, parce que la machine qui me sert de routeur est actuellement
un Pentium 100 sur laquelle tourne un noyau 2.2 avec ipchains (la
nouvelle version que je prépare avec votre aide n'est pas encore prête)
qui ne sert que du routage NAT avec un petit nombre de règles ipchains
pour une ligne ADSL 512/128 en PPPoE. Avant, c'était un 486DX-33 qui
jouait ce rôle, et je pensais que c'était largement suffisant pour cette
tâche dans la mesure où l'occupation CPU restait modeste. Or depuis le
changement de matériel j'ai gagné plusieurs millisecondes de latence. A
moins que le remplacement des cartes réseau (3C509 -> 3C509B et NE2000
ISA -> NE2000 PCI) y soit aussi pour quelque chose. Comme le futur
noyau 2.4 sera plus lourd à gérer et comme ce routeur assurera des
fonctions supplémentaires (serveur SSH et VPN), l'idée d'optimiser le
traitement des paquets me paraît ne pas être à négliger. Des avis ?
D'autre part, je vois le plus souvent dans la même règle l'acceptation
des paquets ESTABLISHED et RELATED. Or les paquets RELATED peuvent
contenir diverses choses, comme des messages ICMP, qui, il me semble,
nécessitent un filtrage un peu plus serré. Aussi j'aurais tendance à
séparer le traitement des deux états. Le traitement des paquets
ESTABLISHED, normalement les plus fréquents, resterait en début de
chaîne pour l'efficacité et le traitement des paquets RELATED se
trouverait plus bas avec celui des NEW, après les règles de filtrage des
trucs indésirables pour la sécurité. Cela ne pénaliserait pas les
performances puisque ces paquet sont normalement rares. Qu'en
pensez-vous ?
En ce qui concerne le routage et le traitement des paquets pour le
firewall, je conseille fortement de créer de nouvelles chaines
| D'autre part, je vois le plus souvent dans la même règle l'acceptation
| des paquets ESTABLISHED et RELATED. Or les paquets RELATED peuvent
| contenir diverses choses, comme des messages ICMP, qui, il me semble,
Dans ce cas tu filtres ICMP avant dans une chaine spécifique à tes
souhaits :)
| nécessitent un filtrage un peu plus serré. Aussi j'aurais tendance à
| séparer le traitement des deux états. Le traitement des paquets
| ESTABLISHED, normalement les plus fréquents, resterait en début de
| chaîne pour l'efficacité et le traitement des paquets RELATED se
| trouverait plus bas avec celui des NEW, après les règles de filtrage des
| trucs indésirables pour la sécurité. Cela ne pénaliserait pas les
| performances puisque ces paquet sont normalement rares. Qu'en
| pensez-vous ?
Bof. Pas utile.
En ce qui concerne le routage et le traitement des paquets pour le
firewall, je conseille fortement de créer de nouvelles chaines
| D'autre part, je vois le plus souvent dans la même règle l'acceptation
| des paquets ESTABLISHED et RELATED. Or les paquets RELATED peuvent
| contenir diverses choses, comme des messages ICMP, qui, il me semble,
Dans ce cas tu filtres ICMP avant dans une chaine spécifique à tes
souhaits :)
| nécessitent un filtrage un peu plus serré. Aussi j'aurais tendance à
| séparer le traitement des deux états. Le traitement des paquets
| ESTABLISHED, normalement les plus fréquents, resterait en début de
| chaîne pour l'efficacité et le traitement des paquets RELATED se
| trouverait plus bas avec celui des NEW, après les règles de filtrage des
| trucs indésirables pour la sécurité. Cela ne pénaliserait pas les
| performances puisque ces paquet sont normalement rares. Qu'en
| pensez-vous ?
Bof. Pas utile.
En ce qui concerne le routage et le traitement des paquets pour le
firewall, je conseille fortement de créer de nouvelles chaines
| D'autre part, je vois le plus souvent dans la même règle l'acceptation
| des paquets ESTABLISHED et RELATED. Or les paquets RELATED peuvent
| contenir diverses choses, comme des messages ICMP, qui, il me semble,
Dans ce cas tu filtres ICMP avant dans une chaine spécifique à tes
souhaits :)
| nécessitent un filtrage un peu plus serré. Aussi j'aurais tendance à
| séparer le traitement des deux états. Le traitement des paquets
| ESTABLISHED, normalement les plus fréquents, resterait en début de
| chaîne pour l'efficacité et le traitement des paquets RELATED se
| trouverait plus bas avec celui des NEW, après les règles de filtrage des
| trucs indésirables pour la sécurité. Cela ne pénaliserait pas les
| performances puisque ces paquet sont normalement rares. Qu'en
| pensez-vous ?
Bof. Pas utile.
Pour faire simple, l'organisation la plus efficace est lorsque tu
as moins de chaînes (à un niveau particulier) que de règles dans
chacune d'elles.
| > | D'autre part, je vois le plus souvent dans la même règle l'acceptation
| > | des paquets ESTABLISHED et RELATED. Or les paquets RELATED peuvent
| > | contenir diverses choses, comme des messages ICMP, qui, il me semble,
| >
| > Dans ce cas tu filtres ICMP avant dans une chaine spécifique à tes
| > souhaits :)
|
| Vi, mais du coup ça rajoute des règles inutiles avant le traitement des
| paquets ESTABLISHED.
Pourquoi inutile ?
Pour faire simple, l'organisation la plus efficace est lorsque tu
as moins de chaînes (à un niveau particulier) que de règles dans
chacune d'elles.
| > | D'autre part, je vois le plus souvent dans la même règle l'acceptation
| > | des paquets ESTABLISHED et RELATED. Or les paquets RELATED peuvent
| > | contenir diverses choses, comme des messages ICMP, qui, il me semble,
| >
| > Dans ce cas tu filtres ICMP avant dans une chaine spécifique à tes
| > souhaits :)
|
| Vi, mais du coup ça rajoute des règles inutiles avant le traitement des
| paquets ESTABLISHED.
Pourquoi inutile ?
Pour faire simple, l'organisation la plus efficace est lorsque tu
as moins de chaînes (à un niveau particulier) que de règles dans
chacune d'elles.
| > | D'autre part, je vois le plus souvent dans la même règle l'acceptation
| > | des paquets ESTABLISHED et RELATED. Or les paquets RELATED peuvent
| > | contenir diverses choses, comme des messages ICMP, qui, il me semble,
| >
| > Dans ce cas tu filtres ICMP avant dans une chaine spécifique à tes
| > souhaits :)
|
| Vi, mais du coup ça rajoute des règles inutiles avant le traitement des
| paquets ESTABLISHED.
Pourquoi inutile ?
