Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Linux Autres OS Linux iptables fait planter mes browsers

iptables fait planter mes browsers

13 réponses
Avatar
Fauberteau Frédéric
Grace à l'aide de TiCHou, j'ai pu comprendre les bases d'iptables. J'ai
donc mis un script qui me ferme et m'autorise certains ports à l'aide
d'iptables.
Bref, le problème est que cela bloque Mozilla (dès que je veux saisir
qqc dans le fenêtre Mozilla, il freeze) et je ne peux plus charger
Konqueror ...
J'ai réduit le script, mais cela se produit, même avec seulement ceci :

#!/bin/sh
#
# Script de démarrage du firewall

echo 1 > /proc/sys/net/ipv4/ip_forward

# Bloquer le spoofing
[ -f /proc/sys/net/ipv4/conf/all/rp_filter ] \
&& echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter

# Chargement des modules
modprobe ip_tables
modprobe iptable_filter
modprobe iptable_nat
modprobe ip_nat_ftp
modprobe ip_nat_irc

# Nettoyage des règles
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -Z
iptables -t nat -Z

# Cible par défaut (rejet)
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

Avez-vous une explications à cela ?
Merci d'avance.
Signaler un problème avec ce contenu

3 réponses

Supprimer
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
1 2
Avatar
TiChou
Dans le message <news:c7lh3c$9nf$,
*marmotte* tapota sur f.c.o.l.configuration :

Voilà la version courte (mon rapport de projet remis au prof, qui est
beaucoup plus light que mon rapport version complète, que je termine).
Ainsi que le lien vers un script d'exemple de configuration de firewall.

perso.wanadoo.fr/-marmotte-/tutoriel/Rapport_TER_2004_court.pdf
perso.wanadoo.fr/-marmotte-/tutoriel/firewall.sh

Bonne lecture, je suis ouvert à toute modification (que j'effectuerai
fin mai, car j'ai mes partiels)

# activation de l'anti-spoofing d'IP
if [ -e /proc/sys/net/ipv4/conf/all/rp_filter ]
then
for f in /proc/sys/net/ipv4/conf/*/rp_filter
do
echo 1 > $f
done
fi


La « ligne » suivante suffit :

[ -f /proc/sys/net/ipv4/conf/all/rp_filter ]
&& echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter

################################################
## définit les polices par défaut des tables ##
################################################



[...]

Les puristes que nous sommes vous diront de définir votre politique par
défaut au tout début de votre script afin d'empêcher tout éventuel paquet de
traverser votre firewall avant que celui-ci soit complètement défini.

$IPTABLES -t filter -A INPUT -i $LOOP -j ACCEPT
$IPTABLES -t filter -A OUTPUT -o $LOOP -j ACCEPT


<mode puriste>

iptables -t filter -A INPUT -i lo -s 127.0.0.0/8 -j ACCEPT
iptables -t filter -A OUTPUT -o lo -d 127.0.0.0/8 -j ACCEPT

</mode>

$IPTABLES -t filter -A INPUT -i $LAN -j ACCEPT
$IPTABLES -t filter -A OUTPUT -o $LAN -j ACCEPT


Idem, on pourrait limiter aux adresses IP du réseau LAN.

$IPTABLES -t filter -A FORWARD -i $LAN -o $NET -m state --state
NEW,ESTABLISHED,RELATED -j LOG_ACCEPT
$IPTABLES -t filter -A FORWARD -i $NET -o $LAN -m state --state
ESTABLISHED,RELATED -j LOG_ACCEPT


D'une manière générale, il n'est utile de logger que les nouvelles
connexions, donc les paquets qui ont l'état NEW. Logger les autres types de
paquets n'a pas vraiment d'intérêt et de plus, comme ils représentent la
majorité des paquets du trafic d'une connexion, ils vont saturer le système
de log le rendant difficilement exploitable.
Donc :

iptables -A FORWARD -i $LAN -o $NET -m state --state NEW -j LOG_ACCEPT
iptables -A FORWARD -i $LAN -o $NET
-m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i $NET -o $LAN
-m state --state ESTABLISHED,RELATED -j ACCEPT

$IPTABLES -t filter -A OUTPUT -o $NET -m state --state
NEW,ESTABLISHED,RELATED -j LOG_ACCEPT
$IPTABLES -t filter -A INPUT -i $NET -m state --state
ESTABLISHED,RELATED -j LOG_ACCEPT


[1] De même :

iptables -A OUTPUT -o $NET -m state --state NEW -j LOG_ACCEPT
iptables -A OUTPUT -o $NET
-m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i $NET
-m state --state ESTABLISHED,RELATED -j ACCEPT

$IPTABLES -t filter -A OUTPUT -o $NET -p udp --sport 1024: --dport 53 -m
state --state ! INVALID -j DNS_LOG_ACCEPT
$IPTABLES -t filter -A OUTPUT -o $NET -p tcp --sport 1024: --dport 53 -m
state --state ! INVALID -j DNS_LOG_ACCEPT


iptables -A OUTPUT -o $NET -p udp --sport 1024: --dport 53
-m state --state NEW -j DNS_LOG_ACCEPT
iptables -A OUTPUT -o $NET -p tcp --sport 1024: --dport 53
--syn -m state --state NEW -j DNS_LOG_ACCEPT

A noter l'option '--syn' sur les connexions TCP.

$IPTABLES -t filter -A INPUT -i $NET -p udp --sport 53 --dport 1024:
-m state --state RELATED,ESTABLISHED -j DNS_LOG_ACCEPT
$IPTABLES -t filter -A INPUT -i $NET -p tcp --sport 53 --dport 1024:
-m state --state RELATED,ESTABLISHED -j DNS_LOG_ACCEPT


Ces règles sont redondantes avec vos précédentes règles (voir [1] plus
haut), ne seront jamais traversées par un paquet et sont inutiles. A
supprimer donc.

$IPTABLES -t filter -A OUTPUT -o $NET -p tcp --sport 1024:
--destination 193.252.22.109 --dport 25 -m state --state ! INVALID
-j SMTP_LOG_ACCEPT


iptables -A OUTPUT -o $NET -p tcp --sport 1024: -d 193.252.22.109
--dport 25 --syn -m state --state NEW -j SMTP_LOG_ACCEPT

$IPTABLES -t filter -A INPUT -i $NET -p tcp -s 193.252.22.109 --sport 25
--dport 1024: -m state --state RELATED,ESTABLISHED -j SMTP_LOG_ACCEPT


Idem, règle redondante avec [1]. A supprimer donc.

$IPTABLES -t filter -A INPUT -p tcp --dport 22 -i $NET -j SSH_LOG_ACCEPT


iptables -A INPUT -i $NET -p tcp --dport 22
--syn -m match --state NEW -j SSH_LOG_ACCEPT

$IPTABLES -t filter -A OUTPUT -p tcp --sport 22 -o $NET -j SSH_LOG_ACCEPT


Règle redondante avec [1]. A supprimer donc.

iptables -A INPUT -p tcp --dport 80 -j HTTP_LOG_ACCEPT
iptables -A OUTPUT -p tcp --sport 80 -j HTTP_LOG_ACCEPT


De même, ces deux règles se résument en cette seule règle :

iptables -A INPUT -i $NET -p tcp --dport 80
--syn -m match --state NEW -j HTTP_LOG_ACCEPT

$IPTABLES -A INPUT -p icmp -m state --state RELATED -j ICMP_LOG_ACCEPT


[2] De nouveau règle redondante et qui ne sera donc jamais traversée. La
règle ne loggera donc jamais les paquets quelle cible. Il serait alors
judicieux de placer cette règle juste avant les règles [1] si vous souhaitez
garder une trace dans vos logs des messages icmp « utiles ».

# on enregistre aussi les tentatives de PING
# si on veut limiter le nombre de PING à 6 minutes,on active l'option
ci-dessous
#$IPTABLES -A INPUT -p icmp -m state --state NEW -m limit
--limit 6/min -j PING_LOG_ACCEPT
$IPTABLES -A INPUT -p icmp -m state --state NEW -j PING_LOG_DROP


Deux choses.
Vous ne précisez pas dans votre règle le type de message icmp qu'il faut
cibler, ici l'icmp echo (ping) et donc vous ciblez tous les types d'icmp.
Ensuite bloquer l'icmp echo c'est « mal ©® » et inutile. Ce n'est pas
respecter les RFC, c'est contraignant pour les administrateurs réseaux et
surtout ce n'est pas ça qui vous permettra de vous cacher sur Internet.
Par contre limiter le nombre de requête icmp echo est effectivement une
bonne chose pour se prémunir des dénis de service auxquels l'icmp est
sensible. On peut aussi jouer sur la taille des requêtes.
En résumé je préconise la règle suivante :

iptables -A INPUT -i $NET -p icmp --icmp-type echo-request
-m length --length 0:92
-m limit --limit 60/minute -j PING_LOG_ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -j PING_LOG_DROP

$IPTABLES -A INPUT -p icmp -m state --state ! RELATED -j ICMP_LOG_DROP


Les icmp RELATED ont déjà été traités par [2] il est donc inutile de cibler
la règle en fonction de l'état RELATED.

iptables -A INPUT -p icmp -j ICMP_LOG_DROP

$IPTABLES -t filter -A INPUT -i $NET -m state --state NEW,INVALID
-j LOG_DROP


Même remarque, à ce stade tous les paquets à l'état ESTABLISHED ou RELATED
ont été traités par les règles [1], ils ne peut donc rester que les paquets
NEW non autorisés ou les paquets INVALID.

iptables -A INPUT -i $NET -j LOG_DROP

Et concernant vos logs, il serait utile aussi de les limiter afin d'éviter,
en cas de déni de service, que le système de log sollicite fortement les
ressources machines et que le déni de service visant généralement la bande
passante de la machine se transforme en déni de service général de la
machine.

En espérant que mes commentaires vous seront utiles et en espérant aussi que
je n'aurais commis aucune erreur de syntaxe ou d'appréciation.

--
TiChou

Avatar
marmotte
Dans le message <news:c7lh3c$9nf$,
*marmotte* tapota sur f.c.o.l.configuration :


# activation de l'anti-spoofing d'IP
if [ -e /proc/sys/net/ipv4/conf/all/rp_filter ]
then
for f in /proc/sys/net/ipv4/conf/*/rp_filter
do
echo 1 > $f
done
fi



La « ligne » suivante suffit :

[ -f /proc/sys/net/ipv4/conf/all/rp_filter ]
&& echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter

Oui, mais avouez que pour un débutant, il ne pigera rien. Et ce n'est

pas le but recherché.



################################################
## définit les polices par défaut des tables ##
################################################
Les puristes que nous sommes vous diront de définir votre politique par

défaut au tout début de votre script afin d'empêcher tout éventuel paquet de
traverser votre firewall avant que celui-ci soit complètement défini.
Exact, je crée mes tables avant la politique par défaut, il faudrait

faire l'inverse.
Je vais donc changer ça.



$IPTABLES -t filter -A INPUT -i $LOOP -j ACCEPT
$IPTABLES -t filter -A OUTPUT -o $LOOP -j ACCEPT



<mode puriste>

iptables -t filter -A INPUT -i lo -s 127.0.0.0/8 -j ACCEPT
iptables -t filter -A OUTPUT -o lo -d 127.0.0.0/8 -j ACCEPT

</mode>
Là j'avoue que je ne comprends pas. Tout ce qui sort de lo a pour ip

127.x.y.z, donc ta restriction à la source 127.0.0.0/8 me paraît redondante.
J'aimerais bien plus d'explication quand à l'utilité de cette méthode.



$IPTABLES -t filter -A INPUT -i $LAN -j ACCEPT
$IPTABLES -t filter -A OUTPUT -o $LAN -j ACCEPT



Idem, on pourrait limiter aux adresses IP du réseau LAN.
Effectivement oui, pour une plus grande sécurité de son réseau local.

Mais dans un usage domestique, je n'ai pas jugé cela utile.




$IPTABLES -t filter -A FORWARD -i $LAN -o $NET -m state --state
NEW,ESTABLISHED,RELATED -j LOG_ACCEPT
$IPTABLES -t filter -A FORWARD -i $NET -o $LAN -m state --state
ESTABLISHED,RELATED -j LOG_ACCEPT



D'une manière générale, il n'est utile de logger que les nouvelles
connexions, donc les paquets qui ont l'état NEW. Logger les autres types de
paquets n'a pas vraiment d'intérêt et de plus, comme ils représentent la
majorité des paquets du trafic d'une connexion, ils vont saturer le système
de log le rendant difficilement exploitable.
C'est vrai, mais c'était dans le cadre de le but de montrer tout le

suivi de la connexion dans les logs.
En pratique, aucun intérêt, bien évidemment. J'aurai dû le préciser et
le mettre en commentaire (ce que je ferai pour le rapport long).



[1] De même :
Idem


$IPTABLES -t filter -A OUTPUT -o $NET -p udp --sport 1024: --dport 53 -m
state --state ! INVALID -j DNS_LOG_ACCEPT
$IPTABLES -t filter -A OUTPUT -o $NET -p tcp --sport 1024: --dport 53 -m
state --state ! INVALID -j DNS_LOG_ACCEPT



iptables -A OUTPUT -o $NET -p udp --sport 1024: --dport 53
-m state --state NEW -j DNS_LOG_ACCEPT
iptables -A OUTPUT -o $NET -p tcp --sport 1024: --dport 53
--syn -m state --state NEW -j DNS_LOG_ACCEPT

A noter l'option '--syn' sur les connexions TCP.
Pas mal le coup de l'option --syn, j'y ai pas pensé (manque d'habitude

je pense).




$IPTABLES -t filter -A INPUT -i $NET -p udp --sport 53 --dport 1024:
-m state --state RELATED,ESTABLISHED -j DNS_LOG_ACCEPT
$IPTABLES -t filter -A INPUT -i $NET -p tcp --sport 53 --dport 1024:
-m state --state RELATED,ESTABLISHED -j DNS_LOG_ACCEPT



Ces règles sont redondantes avec vos précédentes règles (voir [1] plus
haut), ne seront jamais traversées par un paquet et sont inutiles. A
supprimer donc.
Exact encore une fois, elles doivent venir avant [1], je modifierai donc.





$IPTABLES -t filter -A OUTPUT -o $NET -p tcp --sport 1024:
--destination 193.252.22.109 --dport 25 -m state --state ! INVALID
-j SMTP_LOG_ACCEPT



iptables -A OUTPUT -o $NET -p tcp --sport 1024: -d 193.252.22.109
--dport 25 --syn -m state --state NEW -j SMTP_LOG_ACCEPT


$IPTABLES -t filter -A INPUT -i $NET -p tcp -s 193.252.22.109 --sport 25
--dport 1024: -m state --state RELATED,ESTABLISHED -j SMTP_LOG_ACCEPT



Idem, règle redondante avec [1]. A supprimer donc.
Je déplacerai, pour éviter la redondance.




$IPTABLES -t filter -A INPUT -p tcp --dport 22 -i $NET -j SSH_LOG_ACCEPT



iptables -A INPUT -i $NET -p tcp --dport 22
--syn -m match --state NEW -j SSH_LOG_ACCEPT


$IPTABLES -t filter -A OUTPUT -p tcp --sport 22 -o $NET -j SSH_LOG_ACCEPT



Règle redondante avec [1]. A supprimer donc.
J'ai dans mes log des SSH_LOG_ACCEPT, mais j'ais pas fait gaffe à

l'origine de la connexion.
Vous avez une fois de plus raison !




iptables -A INPUT -p tcp --dport 80 -j HTTP_LOG_ACCEPT
iptables -A OUTPUT -p tcp --sport 80 -j HTTP_LOG_ACCEPT



De même, ces deux règles se résument en cette seule règle :

iptables -A INPUT -i $NET -p tcp --dport 80
--syn -m match --state NEW -j HTTP_LOG_ACCEPT


Effectivement, inutile de préciser la sortie HTTP, car elle sera
effectué avec le suivie de connexion (connexion ESTABLISHED), mais
j'avais précisé pour l'exemple.




$IPTABLES -A INPUT -p icmp -m state --state RELATED -j ICMP_LOG_ACCEPT



[2] De nouveau règle redondante et qui ne sera donc jamais traversée. La
règle ne loggera donc jamais les paquets quelle cible. Il serait alors
judicieux de placer cette règle juste avant les règles [1] si vous souhaitez
garder une trace dans vos logs des messages icmp « utiles ».


J'ai du pain sur la planche, je vais rectifier cela !


# on enregistre aussi les tentatives de PING
# si on veut limiter le nombre de PING à 6 minutes,on active l'option
ci-dessous
#$IPTABLES -A INPUT -p icmp -m state --state NEW -m limit
--limit 6/min -j PING_LOG_ACCEPT
$IPTABLES -A INPUT -p icmp -m state --state NEW -j PING_LOG_DROP



Deux choses.
Vous ne précisez pas dans votre règle le type de message icmp qu'il faut
cibler, ici l'icmp echo (ping) et donc vous ciblez tous les types d'icmp.
Ensuite bloquer l'icmp echo c'est « mal ©® » et inutile. Ce n'est pas
respecter les RFC, c'est contraignant pour les administrateurs réseaux et
surtout ce n'est pas ça qui vous permettra de vous cacher sur Internet.
J'avais pris pour exemple l'admin de la fac qui interdit tout (même SSH).

Donc mauvais exemple, changer d'exemple.


Par contre limiter le nombre de requête icmp echo est effectivement une
bonne chose pour se prémunir des dénis de service auxquels l'icmp est
sensible. On peut aussi jouer sur la taille des requêtes.
En résumé je préconise la règle suivante :

iptables -A INPUT -i $NET -p icmp --icmp-type echo-request
-m length --length 0:92
-m limit --limit 60/minute -j PING_LOG_ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -j PING_LOG_DROP


$IPTABLES -A INPUT -p icmp -m state --state ! RELATED -j ICMP_LOG_DROP



Les icmp RELATED ont déjà été traités par [2] il est donc inutile de cibler
la règle en fonction de l'état RELATED.

iptables -A INPUT -p icmp -j ICMP_LOG_DROP


$IPTABLES -t filter -A INPUT -i $NET -m state --state NEW,INVALID
-j LOG_DROP



Même remarque, à ce stade tous les paquets à l'état ESTABLISHED ou RELATED
ont été traités par les règles [1], ils ne peut donc rester que les paquets
NEW non autorisés ou les paquets INVALID.

iptables -A INPUT -i $NET -j LOG_DROP

je préfère me répéter pour une question de compéhension. De plus, ça ne

gêne en rien le filtrage, donc je laisserai.
Je rappelle que mon but est que le fichier soit accessible par un débutant.



Et concernant vos logs, il serait utile aussi de les limiter afin d'éviter,
en cas de déni de service, que le système de log sollicite fortement les
ressources machines et que le déni de service visant généralement la bande
passante de la machine se transforme en déni de service général de la
machine.

En espérant que mes commentaires vous seront utiles et en espérant aussi que
je n'aurais commis aucune erreur de syntaxe ou d'appréciation.

Vos commentaires sont d'une très grande utilité.

Je vais modifier mon fichier en conséquence.
Un grand merci à vous !

--
Linuxement,

marmotte
JID:
GPG fingerprint: 3A12 BB75 447F 6F6F FE53 C2B3 C398 3331 A277 95C6


PS: Enlevez _les_doigts_du_nez_ pour me répondre


Avatar
TiChou
Dans le message <news:c7o277$3k3$,
*marmotte* tapota sur f.c.o.l.configuration :

# activation de l'anti-spoofing d'IP
if [ -e /proc/sys/net/ipv4/conf/all/rp_filter ]
then
for f in /proc/sys/net/ipv4/conf/*/rp_filter
do
echo 1 > $f
done
fi


La « ligne » suivante suffit :

[ -f /proc/sys/net/ipv4/conf/all/rp_filter ]
&& echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter

Oui, mais avouez que pour un débutant, il ne pigera rien. Et ce n'est

pas le but recherché.


Il ne s'agissait pas d'une remarque sur la syntaxe « if then » mais sur la
façon d'obtenir le résultat. Mon bout de code ne fait pas la même chose que
le votre. Je reprends mon bout de code avec une syntaxe « if then » si vous
préférez :

if [ -f /proc/sys/net/ipv4/conf/all/rp_filter ]
then
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
fi

Quant à la syntaxe que j'avais employé, elle n'avait rien de compliqué et je
doute que votre script s'adresse à des débutants et quand bien même je doute
de toute manière qu'il comprenne exactement ce qui est fait ici.

$IPTABLES -t filter -A INPUT -i $LOOP -j ACCEPT
$IPTABLES -t filter -A OUTPUT -o $LOOP -j ACCEPT


<mode puriste>

iptables -t filter -A INPUT -i lo -s 127.0.0.0/8 -j ACCEPT
iptables -t filter -A OUTPUT -o lo -d 127.0.0.0/8 -j ACCEPT

</mode>
Là j'avoue que je ne comprends pas. Tout ce qui sort de lo a pour ip

127.x.y.z,


Tout ce qui sort de lo devrait effectivement avoir pour adresse IP une IP du
bloc 127.0.0.0/8.

donc ta restriction à la source 127.0.0.0/8 me paraît redondante.


Elle ne l'est pas en pratique.

J'aimerais bien plus d'explication quand à l'utilité de cette
méthode.


Un programme mal conçu ou une mauvaise règle NAT peut très bien tenter de
faire du trafic sur l'interface lo avec des adresses IP non prévues pour
celle-ci.
D'ailleurs, une petite recherche sur les archives d'Usenet ou sur Google
vous montreront des personnes s'intérogeant sur des logs de trafic sur
l'interface lo avec des adresses IP publiques.

$IPTABLES -t filter -A INPUT -i $NET -p udp --sport 53 --dport 1024:
-m state --state RELATED,ESTABLISHED -j DNS_LOG_ACCEPT
$IPTABLES -t filter -A INPUT -i $NET -p tcp --sport 53 --dport 1024:
-m state --state RELATED,ESTABLISHED -j DNS_LOG_ACCEPT


Ces règles sont redondantes avec vos précédentes règles (voir [1] plus
haut), ne seront jamais traversées par un paquet et sont inutiles. A
supprimer donc.
Exact encore une fois, elles doivent venir avant [1], je modifierai donc.



Non, c'est inutile de les placer avant (tout comme pour les règles
suivantes). Les règles en [1] suffisent. A moins que vous teniez absolument
de logger cette partie de trafic et séparément des autres logs. Mais je
pense alors qu'il serait plus judicieux de laisser cette tache au système de
log, avec ,par exemple, un bon parser.
Ou alors se contenter de simples règles comme la suivante :

iptables -A OUTPUT -p proto --dport service -j ULOG --ulog-prefix pref

$IPTABLES -t filter -A INPUT -i $NET -m state --state NEW,INVALID
-j LOG_DROP


Même remarque, à ce stade tous les paquets à l'état ESTABLISHED ou
RELATED ont été traités par les règles [1], ils ne peut donc rester que
les paquets NEW non autorisés ou les paquets INVALID.
iptables -A INPUT -i $NET -j LOG_DROP
je préfère me répéter pour une question de compéhension. De plus, ça ne

gêne en rien le filtrage, donc je laisserai.
Je rappelle que mon but est que le fichier soit accessible par un
débutant.


Attention malgré tout que c'est induire en erreur la personne en faisant
croire que d'écrire cette règle de cette manière va apporter quelque chose
de plus dans le fonctionnement et ça laisse croire en plus que c'est la
bonne manière de faire alors que ça ne l'est pas.
Sans parler du fait que la règle est plus demandeuse de ressource. A
l'échelle d'une règle, c'est non mesurable. Mais quand on répète le même
schéma de règle sur un firewall composé d'une centaine voir d'un millier de
règles avec un trafic assez conséquent, on voit vite la différence
d'efficacité avec une règle bien écrite et cohérente.
Je pense qu'il est plus important de s'attacher sur l'efficacité et la
cohérence d'une règle que sur sa forme et son apparence à être sois disant
plus compréhensible.
De plus il est important d'avoir les bonnes méthodes de faire les choses le
plus tôt possible avant de prendre de mauvaises habitudes. C'est chose
courante en informatique.

Un grand merci à vous !


Avec plaisir.

--
TiChou



1 2