Paramétrer un pare-feu réseau

Avant de lire cette partie du chapitre, vous devriez avoir déjà installé iptables comme décrit dans la section précédente.

Introduction à la création d'un pare-feu

L'objectif général d'un pare-feu est de protéger un ordinateur ou un réseau contre les accès malveillants.

Dans un monde parfait, tout démon et tout service sur la machine est parfaitement configuré et immunisé contre des fléaux tels que les débordements de tampon ou d'autres problèmes liés à leur sécurité. De plus, vous faites confiance aux utilisateurs qui accèdent à vos services. Dans ce monde, vous n'avez pas besoin de pare-feu.

Mais dans le monde réel, les démons peuvent être mal configurés et les exploits contre des services essentiels sont librement disponibles. Vous pouvez souhaiter choisir les services qui sont accessibles à certaines machines ou vous pourriez souhaiter limiter les machines ou les applications qui sont autorisés à y accéder depuis l'extérieur. Sinon, vous pouvez tout simplement ne pas faire confiance à certaines de vos applications ou à certains de vos utilisateurs. Vous êtes probablement connectés à Internet. Dans ce monde, un pare-feu est essentiel.

N'imaginez toutefois pas qu'un pare-feu rend redondante les mauvaises configurations, ni qu'il ôte tout risque d'une mauvaise configuration par négligence. Il n'empêche personne d'exploiter un service que vous offrez intentionnellement, mais que vous n'avez pas mis à jour récemment ou que vous n'avez pas corrigé après qu'un exploit a été publié. Bien qu'ayant un pare-feu, vous avez besoin d'avoir sur votre système des applications et des démons configurés correctement et à jour. Un pare-feu n'est pas le remède à tout, mais il devrait être une partie essentielle de votre stratégie globale de sécurité.

Signification du mot « Pare-feu »

Le mot « pare-feu » peut avoir plusieurs sens différents.

C'est un périphérique matériel ou un logiciel disponible sur le commerce (ou offert gratuitement) par des sociétés telles que Symantec qui prétend que cela sécurise un ordinateur familial ou de bureau connecté à Internet. Ce type de pare-feu est fort pertinent pour les utilisateurs qui ne savent pas comment on pourrait accéder à leur ordinateur par Internet ou comment désactiver cet accès, surtout s'ils sont toujours en ligne et connectés par des liens à connexion illimitée.

C'est un système placé entre Internet et l'intranet. Pour minimiser le risque de compromettre le pare-feu lui-même, il ne devrait en général jouer qu'un rôle—celui de protéger l'intranet. Bien que cela ne soit pas sans risques, la tâche de routage et de masquage d'IP (réécrire des en-têtes IP de paquets qu'il route depuis les clients avec des adresses privées sur Internet afin qu'elles semblent venir du pare-feu lui-même) est en général considérée comme relativement sécurisée.

C'est souvent un vieil ordinateur à la retraite et que vous avez presque oublié, qui fait du masquage ou des fonctions de routage mais qui offre des services de non pare-feu tels qu'un cache Web ou la messagerie. Cela peut être utilisé pour des réseaux familiaux, mais ce n'est pas considéré comme sécurisé en tant que machine uniquement dédiée au pare-feu car la combinaison d'un serveur et d'un routeur/pare-feu sur une machine augmente la complexité du paramétrage.

Pare-feu avec une zone démilitarisée [Pas de description supplémentaire ici]

Cette machine effectue du masquage ou du routage mais elle autorise un accès public à certaines branches de votre réseau qui, du fait des IP publiques et d'une structure physique séparée, est essentiellement un réseau séparé avec un accès direct à Internet. Les serveurs sur ce réseau sont les plus facilement accessibles, tant par Internet que depuis l'intranet. Le pare-feu protège les deux réseaux. Ce type de pare-feu a un minimum de trois interfaces réseaux.

Packetfilter

Ce type de pare-feu fait du routage et du masquage, mais il ne maintient pas un tableaux d'état de flux de communication en cours. Il est rapide mais a des capacités de blocage des paquets indésirés très limitées sans bloquer les paquets désirés.

Maintenant vous pouvez commencer à construire votre pare-feu

[Attention]

Attention

Cette introduction sur la façon de paramétrer un pare-feu n'est pas un guide complet pour sécuriser des systèmes. Le pare-feu est un sujet complexe qui exige une configuration soignée. Les scripts cités ici ne visent qu'à donner des exemples de la façon dont fonctionne un pare-feu. Ils n'ambitionnent pas de convenir à toute configuration particulière et ils peuvent ne pas offrir de protection complète contre une attaque.

Une personnalisation de ces scripts pour votre situation spécifique sera nécessaire pour avoir une configuration optimale, mais vous devriez étudier sérieusement la documentation d'iptables et la création de pare-feux en général avant de toucher quoique ce soit. Jetez un œil sur la liste de liens de lectures complémentaires à la fin de cette section pour plus de détails. Vous y trouverez une liste de liens contenant des informations rapides et complètes sur la construction de votre propre pare-feu.

Le pare-feu de démarrage principal se trouve dans le fichier /etc/systemd/scripts/iptables. Les sections ci-dessous présentent trois approches différentes qu'on peut utiliser sur un système.

[Note]

Note

Vous devriez toujours exécuter vos règles de pare-feu à partir d'un script. Cela vous assure d'être cohérent et de vous souvenir de ce que vous avez fait. Cela permet aussi de mettre des commentaires essentiels à la compréhension des règles longtemps après les avoir écrites.

Pare-feu personnel

Un pare-feu personnel est conçu pour vous permettre un accès à tous les services offerts sur Internet, mais il garde votre machine ainsi que vos données privées en sécurité.

Voici ci-dessous une version légèrement modifiée de la recommandation de Rusty Russell sur le Linux 2.4 Packet Filtering HOWTO (guide pratique sur le filtrage des paquets avec Linux 2.4). Il s'applique encore aux noyaux Linux 2.6.

install -v -dm755 /etc/systemd/scripts

cat > /etc/systemd/scripts/iptables << "EOF"
#!/bin/sh

# Begin /etc/systemd/scripts/iptables

# Insert connection-tracking modules
# (not needed if built into the kernel)
modprobe nf_conntrack
modprobe xt_LOG

# Enable broadcast echo Protection
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

# Disable Source Routed Packets
echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route
echo 0 > /proc/sys/net/ipv4/conf/default/accept_source_route

# Enable TCP SYN Cookie Protection
echo 1 > /proc/sys/net/ipv4/tcp_syncookies

# Disable ICMP Redirect Acceptance
echo 0 > /proc/sys/net/ipv4/conf/default/accept_redirects

# Do not send Redirect Messages
echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects
echo 0 > /proc/sys/net/ipv4/conf/default/send_redirects

# Drop Spoofed Packets coming in on an interface, where responses
# would result in the reply going out a different interface.
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 1 > /proc/sys/net/ipv4/conf/default/rp_filter

# Log packets with impossible addresses.
echo 1 > /proc/sys/net/ipv4/conf/all/log_martians
echo 1 > /proc/sys/net/ipv4/conf/default/log_martians

# be verbose on dynamic ip-addresses  (not needed in case of static IP)
echo 2 > /proc/sys/net/ipv4/ip_dynaddr

# disable Explicit Congestion Notification
# too many routers are still ignorant
echo 0 > /proc/sys/net/ipv4/tcp_ecn

# Set a known state
iptables -P INPUT   DROP
iptables -P FORWARD DROP
iptables -P OUTPUT  DROP

# These lines are here in case rules are already in place and the
# script is ever rerun on the fly. We want to remove all rules and
# pre-existing user defined chains before we implement new rules.
iptables -F
iptables -X
iptables -Z

iptables -t nat -F

# Allow local-only connections
iptables -A INPUT  -i lo -j ACCEPT

# Free output on any interface to any ip for any service
# (equal to -P ACCEPT)
iptables -A OUTPUT -j ACCEPT

# Permit answers on already established connections
# and permit new connections related to established ones
# (e.g. port mode ftp)
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Log everything else. What's Windows' latest exploitable vulnerability?
iptables -A INPUT -j LOG --log-prefix "FIREWALL:INPUT "

# End /etc/systemd/scripts/iptables
EOF
chmod 700 /etc/systemd/scripts/iptables

Ce script est très simple, il accepte tout le trafic venant dans votre ordinateur qui a été initié par votre ordinateur, mais tant que vous surfez simplement sur Internet, il y a peu de chances que vous dépassiez ses limites.

Si vous rencontrez souvent un certains délais pour l'accès à vos serveurs FTP, jetez un œil sur Exemple de BusyBox numéro 4.

Même si vous avez des démons ou des services en fonction sur votre système, il sera inaccessible partout sauf par l'ordinateur lui-même. Si vous voulez permettre l'accès à des services sur votre machine tels que ssh ou ping, jetez un œil sur BusyBox.

Routeur Masquerading

Un vrai pare-feu a deux interfaces, une connectée à un intranet, dans cet exemple eth0, et une connectée à Internet, ici ppp0. Pour offrir le maximum de sécurité au pare-feu lui-même, assurez-vous qu'il n'y a pas de serveurs inutiles en fonction dessus tels que X11 et al. En principe, le pare-feu lui-même ne devrait pas accéder à un service non routé (pensez à un serveur distant qui donne des réponses que fait planter un démon sur votre système, ou même pire, ceci implémente un travail par un débordement de mémoire).

install -v -dm755 /etc/systemd/scripts

cat > /etc/systemd/scripts/iptables << "EOF"
#!/bin/sh

# Begin /etc/systemd/scripts/iptables

echo
echo "You're using the example configuration for a setup of a firewall"
echo "from Beyond Linux From Scratch."
echo "This example is far from being complete, it is only meant"
echo "to be a reference."
echo "Firewall security is a complex issue, that exceeds the scope"
echo "of the configuration rules below."

echo "You can find additional information"
echo "about firewalls in Chapter 4 of the BLFS book."
echo "http://www.linuxfromscratch.org/blfs"
echo

# Insert iptables modules (not needed if built into the kernel).

modprobe nf_conntrack
modprobe nf_conntrack_ftp
modprobe xt_conntrack
modprobe xt_LOG
modprobe xt_state

# Enable broadcast echo Protection
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

# Disable Source Routed Packets
echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route

# Enable TCP SYN Cookie Protection
echo 1 > /proc/sys/net/ipv4/tcp_syncookies

# Disable ICMP Redirect Acceptance
echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects

# Don't send Redirect Messages
echo 0 > /proc/sys/net/ipv4/conf/default/send_redirects

# Drop Spoofed Packets coming in on an interface where responses
# would result in the reply going out a different interface.
echo 1 > /proc/sys/net/ipv4/conf/default/rp_filter

# Log packets with impossible addresses.
echo 1 > /proc/sys/net/ipv4/conf/all/log_martians

# Be verbose on dynamic ip-addresses  (not needed in case of static IP)
echo 2 > /proc/sys/net/ipv4/ip_dynaddr

# Disable Explicit Congestion Notification
# Too many routers are still ignorant
echo 0 > /proc/sys/net/ipv4/tcp_ecn

# Set a known state
iptables -P INPUT   DROP
iptables -P FORWARD DROP
iptables -P OUTPUT  DROP

# These lines are here in case rules are already in place and the
# script is ever rerun on the fly. We want to remove all rules and
# pre-existing user defined chains before we implement new rules.
iptables -F
iptables -X
iptables -Z

iptables -t nat -F

# Allow local connections
iptables -A INPUT  -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# Allow forwarding if the initiated on the intranet
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD ! -i ppp+ -m conntrack --ctstate NEW       -j ACCEPT

# Do masquerading
# (not needed if intranet is not using private ip-addresses)
iptables -t nat -A POSTROUTING -o ppp+ -j MASQUERADE

# Log everything for debugging
# (last of all rules, but before policy rules)
iptables -A INPUT   -j LOG --log-prefix "FIREWALL:INPUT "
iptables -A FORWARD -j LOG --log-prefix "FIREWALL:FORWARD "
iptables -A OUTPUT  -j LOG --log-prefix "FIREWALL:OUTPUT "

# Enable IP Forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward

# End /etc/systemd/scripts/iptables
EOF
chmod 700 /etc/systemd/scripts/iptables

Avec ce script, votre intranet devrait être raisonnablement sécurisé contre les attaques externes. Personne ne devrait pouvoir paramétrer de nouvelle connexion pour n'importe quel service interne et, s'il est masqué, il rend votre intranet invisible depuis Internet. En outre, votre pare-feu devrait être relativement sécurisé car il n'y a pas de services en fonction qu'un pirate pourrait attaquer.

[Note]

Note

Si l'interface par laquelle vous vous connectez à Internet ne se connecte pas par PPP, vous devrez modifier <ppp+> par le nom de l'interface (par exemple, eth1) que vous utilisez.

BusyBox

Ce scénario n'est pas très différent du Routeur Masquant, mais il offre en plus des services à votre intranet. On peut en avoir des exemples quand vous voulez administrer votre pare-feu à partir d'un autre hôte de votre Intranet ou l'utiliser en tant que proxy ou serveur DNS ou un serveur de de noms.

[Note]

Note

Faire le tour de la question du vrai concept de protéger un serveur offrant des services sur Internet va beaucoup plus loin que l'objectif de ce document. Voir les références à la fin de cette section pour plus d'informations.

Faites attention. Chaque service que vous avez activé complexifie votre configuration et rend moins sécurisé votre pare-feu. Vous êtes exposé aux risques d'une mauvaise configuration des services ou d'exécution d'un service ayant un bogue exploitable. En général, un pare-feu ne devrait exécuter aucun service supplémentaire. Voir l'introduction au Routeur Masquant pour des détails supplémentaires.

Si vous voulez ajouter des services tels que Samba en interne ou un serveurs de DNS qui n'ont pas besoin d'accéder eux-mêmes à Internet, les réglages supplémentaires sont très simples et devraient être encore acceptables du point de vue de la sécurité. Ajoutez simplement les lignes suivantes au script avant les règles de connexion.

iptables -A INPUT  -i ! ppp+  -j ACCEPT
iptables -A OUTPUT -o ! ppp+  -j ACCEPT

Si des démons tels que squid, doivent accéder eux-mêmes à Internet, vous pouvez en général ouvrir OUTPUT et restreindre INPUT.

iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -j ACCEPT

Il n'est toutefois pas conseillé de laisser OUTPUT sans restrictions. Vous perdez alors le contrôle des chevaux de Troie (trojan) qui voudraient « appeler la maison » et c'est un peu redondant si vous avez mal configuré un service pour qu'il broadcast son existence dans le monde.

Pour faire cela, vous devriez restreindre INPUT et OUTPUT sur tous les ports sauf ceux qu'il vous faut absolument ouvrir. Les ports que vous devez ouvrir dépendent de vos besoins : en général, vous les trouverez en découvrant des échecs d'accès dans vos fichiers journaux.

Jetez un œil sur les exemples suivants :

  • Squid met en cache Internet :

    iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT
    iptables -A INPUT  -p tcp --sport 80 -m conntrack --ctstate ESTABLISHED \
      -j ACCEPT
  • Votre serveur DNS effectue ses recherches à travers UDP :

    iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
  • Vous voulez pouvoir pinger votre ordinateur pour vérifier qu'il est toujours en vie :

    iptables -A INPUT  -p icmp -m icmp --icmp-type echo-request -j ACCEPT
    iptables -A OUTPUT -p icmp -m icmp --icmp-type echo-reply   -j ACCEPT
  • Si vous accédez souvent à des serveurs FTP ou que vous aimez chatter, vous pourriez remarquer certains délais car certaines implémentations de ces démons ont une fonction de recherche d'un identd sur votre système pour obtenir des noms d'utilisateur. Bien qu'il y ait très peu de dangers, le fait d'avoir un identd en fonction n'est pas recommandé car de nombreux experts en sécurité trouvent que le service donnent trop d'informations supplémentaires.

    Pour éviter ces délais, vous pourriez rejeter les requêtes avec un 'tcp-reset' :

    iptables -A INPUT  -p tcp --dport 113 -j REJECT --reject-with tcp-reset
  • Pour enregistrer et rejeter des paquets invalides (des paquets qui sont entrés après le timeout du netfilter ou certains types d'analyse de paquets), insérez ces règles au début de la chaîne :

    iptables -I INPUT 0 -p tcp -m conntrack --ctstate INVALID \
      -j LOG --log-prefix "FIREWALL:INVALID "
    iptables -I INPUT 1 -p tcp -m conntrack --ctstate INVALID -j DROP
  • Tout ce qui vient de l'extérieur ne devrait pas avoir d'adresse privée, c'est une attaque courante appelée IP-spoofing :

    iptables -A INPUT -i ppp+ -s 10.0.0.0/8     -j DROP
    iptables -A INPUT -i ppp+ -s 172.16.0.0/12  -j DROP
    iptables -A INPUT -i ppp+ -s 192.168.0.0/16 -j DROP

    Il y a d'autres adresses que vous pourriez aussi vouloir rejeter : 0.0.0.0/8, 127.0.0.0/8, 224.0.0.0/3 (multicast et expérimental), 169.254.0.0/16 (Link Local Networks, lien réseaux locaux), et 192.0.2.0/24 (réseau de test défini par IANA).

  • Si votre pare-feu est un client, vous devez autoriser ces paquets :

    iptables -A INPUT  -i ppp0 -p udp -s 0.0.0.0 --sport 67 \
       -d 255.255.255.255 --dport 68 -j ACCEPT
  • Pour simplifier le débogage et éloigner ceux qui aimeraient accéder à un service que vous avez désactivé, par erreur ou volontairement, vous pourriez REJECT ces paquets qui sont rejetés.

    Cela doit évidemment se faire directement après avoir enregistré les toutes dernières lignes avant que les paquets ne soient rejetés par les règles :

    iptables -A INPUT -j REJECT

Ce ne sont que des exemples pour vous montrer quelques possibilités du code de pare-feu de Linux. Jetez un œil sur la page de man d'iptables. Vous y trouverez beaucoup plus d'informations. Vous pouvez trouver les numéros de port qui sont nécessaires dans /etc/services, au cas où vous ne les auriez pas trouvé à partir des compte-rendu et des erreurs dans votre fichier journal.

Conclusion

En fin de compte, vous devez vous souvenir d'une chose : l'effort employé pour attaquer un système dépend de la valeur ajoutée que s'attend à y trouver un pirate. Si vous êtes responsables d'informations de valeur, vous devez passer du temps à les protéger correctement.

Informations supplémentaires

Last updated on 2016-06-05 07:57:10 +0200