wiki:InsiaAdminSysFirewall

Sommaire

Administration système - Firewalling avec iptables

1. Routage

Un système GNU/Linux peut très facilement se comporter comme "routeur" au sens le plus simple du terme: il est capable de recevoir des paquets qui ne lui sont pas directement adressés mais qu'on lui demande explicitement de relayer. Un routeur va traditionnellement être inséré entre deux sous-réseaux:

192.168.1.xxx  <--> ROUTEUR <--> 192.168.33.xxx

Pour utiliser le routeur, il suffit de vérifier les points suivants:

  • ROUTEUR possède deux interfaces réseau, avec une adresse sur chaque sous-réseau (ex: 192.168.1.254, 192.168.33.254)
  • ROUTEUR doit accepter de relayer les paquets entre ses interfaces; sous GNU/Linux:
    # echo 1 > /proc/sys/net/ipv4/ip_forward
    # cat /proc/sys/net/ipv4/ip_forward
    1
    
  • chaque machine de chaque sous-réseau définit explicitement ROUTEUR comme sa "passerelle par défaut", en utilisant l'adresse de l'interface qu'il voit depuis son sous-réseau; par exemple sous GNU/Linux:
    bozo-net33# route add default gw 192.168.33.254
    bozo-net33# route -n
    Kernel IP routing table
    Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
    192.168.33.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
    0.0.0.0         192.168.33.254  0.0.0.0         UG    0      0        0 eth0
    

En l'absence de règles supplémentaires, ceci fonctionne "naturellement": les machines de chaque sous-réseau peuvent se contacter mutuellement en utilisant simplement leur adresse.

Note: sous Debian, il est possible de s'assurer que le relais de paquets est activé au boot en ajoutant cette ligne dans le fichier /etc/sysctl.conf:

net/ipv4/ip_forward = 1

2. Paquets et chaînes

Voici un schéma extrait du "Linux Packet Filtering Howto", rédigé par l'auteur d'iptables:

Incoming                 /     \         Outgoing
       -->[Routing ]--->|FORWARD|------->
          [Decision]     \_____/        ^
               |                        |
               v                       ____
              ___                     /    \
             /   \                  |OUTPUT|
            |INPUT|                  \____/
             \___/                      ^
               |                        |
                ----> Local Process ----

Dans le cas d'un routeur simple, seule la chaîne FORWARD nous intéresse. Si nous avions un serveur avec des processus susceptibles d'être en écoute ou d'effectuer des connexions, nous devrions également étudier les chaînes INPUT et OUTPUT.

Note: dans ce schéma on ne voit pas les chaînes PREROUTING et POSTROUTING dont on devine facilement la place.

3. Filtrage simple

Filtrer l'information qui transite sur un routeur est relativement simple: d'abord on choisit une politique par défaut (accepter ou rejeter tous les paquets ?), puis on écrit une liste de règles. On a donc deux approches pour spécifier son filtrage:

  • Tout rejeter par défaut, puis lister les seuls éléments autorisés
  • Tout accepter par défaut, puis lister les seuls éléments rejetés

On utilise traditionnellement la première approche, dont voici la séquence d'initialisation:

# iptables -P FORWARD DROP
# iptables -F FORWARD

Pour autoriser un certain type de traffic, il suffit de spécifier les critères (interface source, interface destination, IP, port, protocole, etc). On peut se contenter d'un critère ou en mettre autant que l'on veut:

# iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport http -j ACCEPT

On peut surveiller à tout moment les règles dans une chaîne et observer les paquets qui les traversent:

# iptables -nvL FORWARD

4. Filtrage à état

Le filtre simple décrit précédemment a une lacune: il manque la règle mirroir pour autoriser les paquets "remontants" HTTP (TCP est bi-directionnel). Cependant ceci nous oblige à laisser sortir tout traffic HTTP issu de notre réseau.

Enfin, dans le cas d'une connexion TCP, on attend une séquence bien précise de paquets en entrée comme en sortie. Si on est capable de maintenir la liste et l'état des "sessions" TCP, on peut rejeter tous les paquets sans relation (attaques, flood, spoof, etc).

Il existe précisément un critère pour désigner les paquets possédant un état défini:

# iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

5. NAT

NAT (Network Address Translation) désigne un mécanisme générique de ré-écriture d'adresse des paquets. Un routeur peut par exemple changer l'adresse d'un paquet IP en fin de destination sans que l'envoyeur en soit conscient (cas du DNAT).

SNAT

Le Source-NAT consiste à modifier au niveau du routeur l'adresse source des paquets qui sont émis: on s'en sert classiquement pour cacher un LAN et lui donner accès à Internet via une seule adresse IP (sur le routeur). Cette modificaiton a lieu juste avant la sortie du paquet du routeur, donc n'est pas visible pour les autres règles de filtrage:

# iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to-source 192.168.33.254

Attention: les règles de NAT s'écrivent dans une table particulière (option -t nat, à utiliser également lors de l'affichage avec iptables -t nat -nvL).

Il existe une forme particulière de SNAT très populaire sur les routeurs/modem, puisqu'elle utilise implicitement l'adresse de l'interface de sortie du routeur comme adresse source (et autorise donc les IPs dynamiques sans reconfigurer son parefeu):

# iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

DNAT

Le Destination-NAT est utilisé pour modifier l'adresse de destination. Ceci est typiquement utilisé pour rediriger du traffic entrant vers des machines d'une zone dédiée à recevoir du traffic, bien qu'elle soit derrière notre pare-feu, la DMZ.

La ré-écriture a lieu juste à l'entrée du paquet dans le routeur, donc elle est visible pour l'ensemble des filtres:

# iptables -t nat -A PREROUTING -p tcp --dport 80 -i eth1 -j DNAT --to 192.168.1.55:8080
Last modified 13 years ago Last modified on Feb 5, 2007, 5:32:32 PM

Attachments (1)

Download all attachments as: .zip