Mes règles iptables sont elles optimales ?

Nicolas Cavigneaux wrote in message
<pan.2004.09.22.09.02.16.144669@altern.org>:

# Régles par défaut
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

Ça a été discuté plusieurs fois ici : la politique DROP est une mauvaise
idée, et peut causer des problèmes et du gaspillage, aussi bien
localement que pour des tiers. La bonne politique à choisir est REJECT,
sauf cas extrêmement particuliers.

Dans le message <news:pan.2004.09.22.09.02.16.144669@altern.org>,
*Nicolas Cavigneaux* tapota sur f.c.o.l.configuration :

bonjour le groupe,

Bonjour l'usenaute,

j'ai chez moi une machine qui me sert de serveur, j'y ai installé
iptables pour pouvoir contrôler les possibilités d'accès et
d'utilisation des services disponibles. Cette machine héberge un serveur
web, un serveur ftp, un serveur ssh et un serveur smtp. Cette machine se
connecte également aux réseaux Donkey, Gnutella 2 et DirectConnect.
Depuis cette machine j'utilise également GnomeMeeting. De plus cette
machine doit être entièrement disponible aux autres machines du réseaux
local (192.168.2.0/24) et leur servir de passerelle vers tous les services
extérieurs.

Sachant que je fais totalement confiance aux utilisateurs du réseau
local, je voudrais savoir si les règles iptables suivantes sont
adéquates à mon utilisation et optimales. Autre problème, bizarrement
personne n'arrive à me contacter sur gnomemeeting, mais je peux les
contacter. Est-ce que cela peut venir d'un oubli dans mes règles iptables
?

# Mon script iptables
# Vidage d'anciennes règles
iptables -F
iptables -t nat -F

Il faut penser aussi à supprimer les éventuelles chaînes utilisateurs dans
les différentes tables :

iptables -t filter -X
iptables -t nat -X

# Régles par défaut
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

À placer de préférence en tête du script. Attention aux politiques par
défaut à DROP. Il faut penser à autoriser le trafic utile, comme par exemple
certains types d'icmp.
Il manque la politique par défaut des chaînes de la table nat que l'on peut
définir à ACCEPT :

iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P OUTPUT ACCEPT
iptables -t nat -P POSTROUTING ACCEPT

# Boucle locale
iptables -A INPUT -i lo -j ACCEPT

# Réseau local
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -A INPUT -s 192.168.2.0/24 -j ACCEPT
iptables -A FORWARD -s 192.168.2.0/24 -j ACCEPT
iptables -A FORWARD -d 192.168.2.0/24 -j ACCEPT

Il serait utile de préciser les interfaces dans ces règles, afin de mieux
filtrer le spoofing. On peut aussi ne laisser passer que les paquets valides
venant d'Internet et à destination des machines locales.

iptables -A INPUT -i eth0 -s 192.168.2.0/24 -j ACCEPT
iptables -A FORWARD -i eth0 -o ppp0 -s 192.168.2.0/24 -j ACCEPT
iptables -A FORWARD -i ppp0 -o eth0 -d 192.168.2.0/24
-m state --state ESTABLISHED,RELATED -j ACCEPT

(je suppose ici que l'interface sur laquelle est accessible vos machines
locales est eth0)

iptables -A POSTROUTING -t nat -o ppp0 -j MASQUERADE

Il est préférable de limiter le mécanisme de masquerade aux paquets
d'adresse IP source 192.168.2.0/24 :

iptables -t nat -A POSTROUTING -o ppp0 -s 192.168.2.0/24 -j MASQUERADE

Si votre connexion Internet dispose d'une adresse IP fixe, il vaut mieux
alors remplacer la précédente règle par une règle de NAT :

iptables -t nat -A POSTROUTING -o ppp0 -s 192.168.2.0/24
-j SNAT --to 213.41.146.213

(je suppose ici que votre adresse IP fixe est 213.41.146.213)

# Paquets correspondants à une connexion
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

#### Facilités ####
#
# autorise la connexion au port 113 en tcp
iptables -A INPUT -p tcp --dport 113 --syn -j ACCEPT

Je vous conseille d'utiliser le matche state afin de n'autoriser réellement
que les paquets « nouvelle connexion ».

iptables -A INPUT -p tcp --dport 113 --syn -m state --state NEW -j ACCEPT

# Pour GnomeMeeting (1720,30000:30010,5000:5007), Donkey (4662,4666),
# Gnutella 2 (6346), DirectConnect (4444)
iptables -A INPUT -p tcp -m multiport --dport 1720,4444,4662,6346 -j
ACCEPT
iptables -A INPUT -p tcp --dport 30000:30010 -j ACCEPT
iptables -A INPUT -p udp --dport 5000:5007 -j ACCEPT
iptables -A INPUT -p udp --dport 4666 -j ACCEPT

De même ici.

iptables -A INPUT -p tcp -m multiport --dport 1720,4444,4662,6346
--syn -m state --state NEW -j ACCEPT
iptables -A INPUT -p tcp --dport 30000:30010 --syn -m state --state NEW
-j ACCEPT
iptables -A INPUT -p udp --dport 5000:5007 -m state --state NEW -j ACCEPT
iptables -A INPUT -p udp --dport 4666 -m state --state NEW -j ACCEPT

#### Pour les serveurs ####
#
# Pour le serveur FTP, SSH, SMTP et HTTP
iptables -A INPUT -p tcp -m multiport --dport 21,22,25,80 --syn -j ACCEPT

iptables -A INPUT -p tcp -m multiport --dport 21,22,25,80
--syn -m state --state NEW -j ACCEPT

Voici pour les quelques corrections. Mais il manque certaines choses.
L'autorisation (limitée en taille et en nombre) du trafic icmp echo (ping)
et destination unreachable (traceroute) qui est toujours utile pour
diagnostiquer les problèmes d'accès à votre machine et qu'il est inutile
d'ignorer en pensant que cela permettrait de cacher votre machine
d'Internet, et le rejet « propre » des connexions que l'on refuse.

iptables -A INPUT -i ppp0 -p icmp --icmp-type echo-request
-m length --length 0:92
-m limit --limit 60/minute -j ACCEPT
iptables -A INPUT -i ppp0 -p icmp --icmp-type destination-unreachable
-m limit --limit 5/minute -j ACCEPT

iptables -A INPUT -i ppp0 -m limit --limit 60/minute -j REJECT

iptables -A INPUT -i ppp0 -j DROP

On pourrait affiner encore plus la façon dont on rejette les paquets en
fonction de la destination (passerelle ou machines locales) -> net-unreach,
du protocole -> proto-unreach, etc.

Merci pour votre lecture et votre aide.

De rien et en n'espérant n'avoir rien oublié.

--
TiChou

Nicolas George wrote:

# Régles par défaut
iptables -P INPUT DROP
iptables -P FORWARD DROP

Ça a été discuté plusieurs fois ici : la politique DROP est une mauvaise
idée, et peut causer des problèmes et du gaspillage, aussi bien
localement que pour des tiers. La bonne politique à choisir est REJECT,
sauf cas extrêmement particuliers.

C'est bien gentil tout ça, mais REJECT n'est pas valide en tant que
politique par défaut. Donc on n'a pas trop le choix.