Re: Que pensez vous de mes regles iptables
Le lun 18/11/2002 à 20:32, Jeremie Koenig a écrit :
> On Mon, Nov 18, 2002 at 05:31:04PM +0100, Nicolas C. wrote:
> > ...
> > - Bloquer les ICMP
> Attention, ca rend parfois le diagnostic de certaines erreurs plus
> difficile.
> > # Pas de ICMP
> > echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all
> > echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
> La, tu te contentes de dire a ton kernel de ne pas repondre aux ping. Si
> tu veux _vraiement_ filtrer tous les paquets icmp, utilise une regle
> iptables.
Je déconseille le filtre abusif de l'ICMP. Ca ne protège en rien d'un
éventuel flood: c'est faire l'autruche, mais le problème sera toujours
là et ta ligne complètement par terre...
Donc, autant permettre à ton fournisseur (voire tes potes) de pouvoir
accéder à ta machine via ICMP. La commande ping est la première utilisée
pour savoir si un hôte est présent ou pas.
> > # Vidage d'anciennes règles
> > iptables -F
> > iptables -t nat -F
> A ce stade, tu devrais aussi positionner les policies (iptables -P), cad
> le comportement par defaut, si aucune regle n'est trouvee pour un paquet
> donne.
Normalement, il vaut mieux faire l'inverse: par défaut, tout interdire
voire, rejetter (DROP ou REJECT), puis autoriser ce que tu veux.
Mais si par défaut, tu restes en ACCEPT, toutes les autres règles en
ACCEPT sont redondantes et finalement bien inutiles...
> > iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
> > iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
> Je ne suis pas un pro en flags tcp, mais la aussi il me semble que c'est
> abusif.
Je trouve aussi: on sent le script récupéré sur le Net, là...
Plutôt que mettre des règles dont on ne comprends pas le sens,
il vaut mieux les écrire soi-même au fur et à mesure.
> > # Paquets correspondants à une connexion
> > iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> > iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> Generalement, je ne fais pas ca de cette maniere (j'utilise --syn, mais
> c'est pas forcemment mieux.)
C'est une bonne règle. Attention, si tu mets DROP par défaut "en live",
commence tout de suite par celle-ci ou dis adieu à ta connexion ssh...
> > # enlever le firewalling pour edonkey
> > iptables -A INPUT -p tcp --dport 4662 -j ACCEPT
> Il faut faire la meme chose pour le port 113 (ident), et eventuellement
> utiliser un serveur ident (paquet pidentd, par exemple).
Pour ce qui est de l'ident, je conseille de l'ouvrir en local et
d'utiliser oidentd dans le cadre d'un réseau masqué.
Quant à edonkey, non seulement je ne cautionne pas ce genre d'outils,
mais je doute que laisser les connexions sur le port 4662 suffise...
Ce genre d'outils utilise un panel de ports plutôt large habituellement.
> > # upload en DCC
> > iptables -I INPUT -m state --state RELATED -j ACCEPT
> Je pense que ca marche, mais je n'ai jamais utilise ca.
Elle ne suffirait pas et de toutes manières, tu n'en as pas besoin pour
faire fonctionner DCC et mode actif du FTP, voir plus bas.
> Attention egalement pour les requetes DNS udp, s'il y en a.
> Pour le DCC, ta regle est probablement adaptee.
Je ne pense pas, les DCC sont particuliers, tout comme le mode actif du
FTP. Pour palier à cela, il faut utiliser des modules noyau pour faisant
partie d'iptables. Sans eux, tes connexions seront vouées à l'échec.
> Une derniere remarque : si tu n'as rien de tres complique qui tourne,
> desactiver tous les services inutiles (desinstaller les serveurs et
> jeter un oeuil dans /etc/inetd.conf) peut etre tout aussi efficace.
Pour paraphraser Alan Cox: "Si tu ne sais pas à quoi ça te sert, tu n'en
as probablement pas besoin."
--
Raphaël Bordet
surcouf@linuxfr.net
Reply to: