1. Shorewall – Configuration de base en quelques minutes

Reading Time: 5 minutes

Shorewall est un des meilleurs firewall. Mais avec la foule de fonctionnalités qu’il propose, la documentation peut en rebuter plus d’un. Il est pourtant aussi bien adapté à de très petites configurations comme à des réseaux complexes.

Voici le premier d’une série de 6 articles :

Shorewall – Configuration de base en quelques minutes
Shorewall – Routeur internet
Shorewall – QoS & Traffic shaping pour améliorer les performances réseau
Shorewall – Configurations avancées
Shorewall – En entreprise : Haute disponibilité, sauvegarde & restauration
Shorewall – En entreprise : Traçabilité, documentation des règles, revues d’audit, journalisation

Shorewall est un outil de gestion de règles réseau intégrés au kernel Linux tels que iptables (Netfilter) et tc (Traffic Classifer). En d’autre termes, shorewall n’a pas à “tourner” en permanence sur le host, il ne s’exécute que lors de modifications de règles ou au démarrage.
Ce premier article se veut le plus simple possible, et nous allons uniquement utiliser les règles de filtrage pour le host local, ce qui correspond aux deux «tables» «filter» en vert des chaînes «INPUT» et «OUTPUT» dans le diagramme suivant.

Les points forts de Shorewall

Inclus dans la plupart des distributions Linux pour serveur et station de travail. Également disponibles sur certains routeurs domestiques sur OpenWRT.
Configuration structurée basée sur des fichiers textes. C’est un gros avantage en entreprise car :
- On peut enregistrer et suivre toute l’évolution des règles avec des outils existants tels que Git, et répondre aux besoins d’audit et de conformité.
- On peut sauvegarder et répliquer les versions de configuration sur plusieurs nœuds, pour de la haute disponibilité ou pour de la sauvegarde.
- Permet des modifications “batch” facilement, avec des scripts, un éditeur texte avancé ou avec des outils de déploiement et d’automatisation tels que Ansible / Git.
- Autorise les commentaires pour chaque règle partout dans le fichier.
Permet de configurer finement des règles de QoS / Traffic shaping (article suivant)
Les commandes de bases permettent de valider la configuration, ou de tester une configuration temporairement. Exemples :

shorewall check
shorewall try /etc/shorewall 60s

Mais d’abord il faut l’installer

sudo apt-get install shorewall shorewall-doc

Vous pouvez utiliser soit la documentation en ligne, soit installer shorewall-doc.

Le workflow de la configuration de Shorewall :

Nommer les zones : /etc/shorewall/zones
Lier les interfaces réseau à leur zone : /etc/shorewall/interfaces
Dégrossir avec les règles de base entre zones : /etc/shorewall/policy
Affiner avec les règles spécifiques : /etc/shorewall/rules

root@pivert-VirtualBox:~# shorewall check
Checking using Shorewall 5.2.3.4...
Processing /etc/shorewall/params ...
Processing /etc/shorewall/shorewall.conf...
Loading Modules...
   ERROR: The 'zones' file does not exist or has zero size /usr/share/shorewall/helpers (EOF)

La commande shorewall check est une des plus précieuses, à lancer après chaque changement de configuration. Ici, elle donne le résultat attendu, car nous n’avons pas encore défini de zones (première étape).

Le cas simple : une station de travail Linux (une interface réseau)

Copiez les 4 fichiers de modèle correspondant aux 4 étapes de configuration :

cp -i /usr/share/doc/shorewall/examples/one-interface/{zones,interfaces,policy,rules} /etc/shorewall/

1. Les zones

Le fichier /etc/shorewall/zones par défaut est suffisant.

root@pivert-VirtualBox:~# awk '/^######/,0' /etc/shorewall/zones
###############################################################################
#ZONE   TYPE    OPTIONS                 IN                      OUT
#                                       OPTIONS                 OPTIONS
fw      firewall
net     ipv4

net représente l’extérieur
fw représente la machine elle-même.

2. Les interfaces

Affichez la route par défaut pour en déduire l’interface de sortie (dev)

root@pivert-VirtualBox:~# ip route list default
default via 192.168.232.1 dev enp0s3 proto dhcp metric 100

L’interface de sortie (la principale) est enp0s3 dans cet exemple et a été configurée par DHCP.
Il faut adapter le nom de l’interface physique de l’exemple (eth0) avec le nom de l’interface de sortie (enp0s3).
Dans notre exemple, ça donne :

root@pivert-VirtualBox:~# awk '/^######/,0' /etc/shorewall/interfaces 
###############################################################################
?FORMAT 2
###############################################################################
#ZONE   INTERFACE       OPTIONS
net     NET_IF          dhcp,tcpflags,logmartians,nosmurfs,sourceroute=0,physical=enp0s3

Et voilà, le firewall est déjà configuré. Si vous êtes directement connecté à l’interface graphique de la machine, vous pouvez vérifier la configuration et lancer le firewall.

shorewall check && shorewall start

Vous pouvez également le lancer de manière temporaire

shorewall check && shorewall try /etc/shorewall/ 60s

3. Le fichier policy

root@pivert-VirtualBox:~# awk '/^######/,0' /etc/shorewall/policy 
###############################################################################
#SOURCE DEST            POLICY          LOGLEVEL        RATE    CONNLIMIT
$FW     net             ACCEPT
net     all             DROP            $LOG_LEVEL
# The FOLLOWING POLICY MUST BE LAST
all     all             REJECT          $LOG_LEVEL

Les règles de base sont parfaites. La dernière ligne (REJECT) ne sera jamais atteinte vu que nous n’avons pas d’autres zones que net et fw. La variable $FW contient le nom de la zone allouée au firewall dans le fichier zones, soit fw.

4. Le fichier de règles fines (rules)

La section « RELATED » a un ACCEPT implicite. Toutes les sections sont vides, sauf la plus importante « NEW » à laquelle nous pourrions ajouter quelques règles (à la fin).

Si vous êtes dans un réseau local :

Vous pouvez accepter les paquets ICMP, mais uniquement depuis votre réseau local, pour permettre le ping.
Si vous avez un serveur ssh sur le port 22 et un serveur web sur le port 8080 que vous voulez accéder depuis une autre station, vous désirerez les accepter.
Vous préférez l’action REJECT à DROP, mais exclusivement depuis votre réseau local. Avec REJECT, le pare-feu va émettre une notification ICMP “Connection refused” au lieu d’ignorer silencieusement le paquet.

Voici un exemple du fichier rules avec les trois modifications. La seconde utilise une macro. Les macros peuvent être listées et visualisées dans /usr/share/shorewall/macro*

root@pivert-VirtualBox:~# awk '/^######/,0' /etc/shorewall/rules 
######################################################################################################################################################################################################
#ACTION         SOURCE          DEST            PROTO   DEST    SOURCE          ORIGINAL        RATE            USER/   MARK CONNLIMIT        TIME            HEADERS         SWITCH          HELPER
#                                                       PORT    PORT(S)         DEST            LIMIT           GROUP
?SECTION ALL
?SECTION ESTABLISHED
?SECTION RELATED
?SECTION INVALID
?SECTION UNTRACKED
?SECTION NEW

# Drop packets in the INVALID state

Invalid(DROP)  net              $FW             tcp

# Drop Ping from the "bad" net zone.. and prevent your log from being flooded..

Ping(DROP)      net             $FW

# Permit all ICMP traffic FROM the firewall TO the net zone

ACCEPT          $FW             net             icmp

# Custom rules
Ping(ACCEPT)    net:192.168.232.0/24    $FW
ACCEPT          net:192.168.232.0/24    $FW     tcp     22,8080
REJECT          net:192.168.232.0/24    $FW

Pour valider la configuration et redémarrer (le shorewall check est implicite au restart) :

shorewall restart

Tests et logs

Dans un autre terminal, surveillez les logs avec une de ces commandes

tail -f /var/log/syslog
tail -f /var/log/syslog | grep -iE 'reject|drop'

Vérifiez que votre machine n’est plus pingable depuis une machine distante. Les «DROP» doivent se trouver dans le log.
Utilisez shorewall dump, cette commande sert à afficher toutes les règles, et les compteurs de volume et de paquets pour chacune. Cette commande est également utile lorsqu’on demande de l’aide dans les forums. Vous allez réaliser que shorewall a déjà créé beaucoup de règles de protection ou de classification par défaut.
Si shorewall dump donne trop d’informations, vous pouvez toujours utiliser iptables directement pour afficher les compteurs d’une table en particulier.

iptables -nv -L --line-numbers
iptables -nv -L -t nat  # pour afficher la table de NAT/Masquerading, mais elle n'est pas (encore) utilisée dans cette configuration simple.

Vous vous rendrez compte que Shorewall crée plusieurs chaines plus petites, qui sont toutes appelées “en cascade” à partir de d’une des chaines principales. Dans notre cas, il s’agit surtout de la chaine “INPUT” de la table par défaut (filter).

Allons un peu plus loin

Activer le lancement automatique au boot

systemctl enable shorewall

shorewall ipcalc, un outil simple et pratique

~$ shorewall ipcalc 10.10.200.0/23
   CIDR=10.10.200.0/23
   NETMASK=255.255.254.0
   NETWORK=10.10.200.0
   BROADCAST=10.10.201.255

Les règles pour un VPN

Si vous utilisez un VPN depuis votre station, la session VPN démarrera sans doute, mais aucun trafic ne pourra utiliser le VPN tant qu’il n’a pas été défini au niveau du pare-feu. Il faut donc aller au travers des 4 étapes, pour ajouter la zone, l’interface, une policy éventuelle et des règles éventuelles.

Considerons que le VPN démarre une interface locale de type tun0 ou tun1. On peut utiliser le wildcard tun+ :

root@pivert-VirtualBox:~# tail -n1 /etc/shorewall/{zones,interfaces}
==> /etc/shorewall/zones <==
vpn     ipv4

==> /etc/shorewall/interfaces <==
vpn     tun+

Et voici les 6 dernières lignes du fichier policy (Il n’y a pas de règles fines dans rules)

root@pivert-VirtualBox:~# tail -n6 /etc/shorewall/policy 
#SOURCE DEST            POLICY          LOGLEVEL        RATE    CONNLIMIT
$FW     net             ACCEPT
$FW     vpn             ACCEPT
net     all             DROP            $LOG_LEVEL
# The FOLLOWING POLICY MUST BE LAST
all     all             REJECT          $LOG_LEVEL

Ensuite

J’espère que cet article vous a permis de configurer ce fantastique outil qu’est Shorewall.

Dans le prochain article, nous verrons le QoS qui permet de classifier et de réordonner les paquets avant l’envoi sur le réseau, et donc d’améliorer sensiblement la performance de navigation ou permettre les appels VoIP/SIP/Videoconférences ou du jeux interactif même sur une ligne surchargée.

Pivert's Blog