4. Shorewall – Configurations avancées

Shorewall permet des configurations très avancées. Quand on multiplie les interfaces, les zones et les règles, il faut bien s’organiser, et idéalement documenter chaque règle.

Les règles stoppedrules

Les règles de /etc/shorewall/stoppedrules (anciennement routestopped) sont chargées lorsque Shorewall est à l’arrêt. C’est grâce à ces règles que vous pouvez vous assurer de ne pas couper votre accès au firewall lorsque qu’il se bloque ou que vous avez chargé des règles invalides. Il s’agit donc d’une configuration minimale, sécurisée qui sera activée en cas de problème, avec des règles suffisantes pour pouvoir vous permettre de résoudre l’incident. Elles sont très importantes. Ce fichier est indépendant des autres, et ne prends que des interfaces et des IPs. Exemple si vos machines d’administration sont dans le réseau 192.168.10.0/24 via l’interface eth1 et que vous serveurs DNS internes sont en 192.168.11.0/24 via eth2 :

###############################################################################                                                        
#ACTION         SOURCE                  DEST                    PROTO   DEST    SOURCE                                                 
#                                                                       PORT(S) PORT(S)                                                
#                                                                                                                                      
ACCEPT  eth1:192.168.10.0/24            $FW                     tcp     22                                                  
ACCEPT  eth1:192.168.10.0/24            eth2:192.168.11.0/24    udp     53
ACCEPT  eth1:192.168.10.0/24            eth2:192.168.11.0/24    tcp     22
ACCEPT  -                               $FW                     icmp

Puisque Shorewall valide sa configuration avant chaque redémarrage, pourquoi avons-nous besoin des stoppedrules ?

Il y a malgré tout certains cas où Shorewall peut se bloquer, et en conséquence se stopper et activer les stoppedrules. Quelques exemples

Vous avez changé la configuration sans la valider ou la recharger et le serveur Shorewall est redémarré.
La configuration est valide, mais il manque des modules pour que Shorewall puisse démarrer. Par exemple, vous avez configuré des règles « SWITCH » (ci-dessous), sans installer le paquet de modules supplémentaires xtables-addons-common.
Vous avez stoppé Shorewall avec shorewall stop (à ne pas confondre avec shorewall clear qui efface toutes les règles)
Dans une configuration en cluster, vous avez stoppé Shorewall pour le mettre à jour

Les macros et les plages d’adresses IP

Exemple

On va voir comment on peut transformer les 18 règles suivantes pour les simplifier et structurer au mieux afin d’améliorer la lisibilité et la gestion.

La configuration originale

# Fichier rules
?COMMENT Web servers to SQL Servers
ACCEPT    dmz:192.168.100.21   loc:192.168.5.6  tcp 1433 
ACCEPT    dmz:192.168.100.31   loc:192.168.5.6  tcp 1433 
ACCEPT    dmz:192.168.100.41   loc:192.168.5.6  tcp 1433 
ACCEPT    dmz:192.168.100.21   loc:192.168.5.7  tcp 1433 
ACCEPT    dmz:192.168.100.31   loc:192.168.5.7  tcp 1433 
ACCEPT    dmz:192.168.100.41   loc:192.168.5.7  tcp 1433 
ACCEPT    dmz:192.168.100.21   loc:192.168.5.8  tcp 1433 
ACCEPT    dmz:192.168.100.31   loc:192.168.5.8  tcp 1433 
ACCEPT    dmz:192.168.100.41   loc:192.168.5.8  tcp 1433 
?COMMENT Web servers to SQL Servers (UDP)
ACCEPT    dmz:192.168.100.21   loc:192.168.5.6  udp 1434 
ACCEPT    dmz:192.168.100.31   loc:192.168.5.6  udp 1434 
ACCEPT    dmz:192.168.100.41   loc:192.168.5.6  udp 1434 
ACCEPT    dmz:192.168.100.21   loc:192.168.5.7  udp 1434 
ACCEPT    dmz:192.168.100.31   loc:192.168.5.7  udp 1434 
ACCEPT    dmz:192.168.100.41   loc:192.168.5.7  udp 1434 
ACCEPT    dmz:192.168.100.21   loc:192.168.5.8  udp 1434 
ACCEPT    dmz:192.168.100.31   loc:192.168.5.8  udp 1434 
ACCEPT    dmz:192.168.100.41   loc:192.168.5.8  udp 1434

On peut simplifier tout en se limitant au fichier `rules`

On remarque que les SQL Servers ont des IP qui se suivent. On peut donc écrire 192.168.5.6-192.168.5.8
Les ports étant différents sur UDP et TCP, on ne peut pas les grouper. Mais on peut utiliser une macro : /usr/share/shorewall/macro.MSSQL

Première simplification :

# Fichier rules
?COMMENT Web servers to SQL Servers
MSSQL(ACCEPT)    dmz:192.168.100.21   loc:192.168.5.6-192.168.5.8
MSSQL(ACCEPT)    dmz:192.168.100.31   loc:192.168.5.6-192.168.5.8
MSSQL(ACCEPT)    dmz:192.168.100.41   loc:192.168.5.6-192.168.5.8

C’est déjà nettement plus lisible.

Vous pouvez écrire vos propres macros en utilisant le canevas /usr/share/shorewall/macro.template, et les placer dans /etc/shorewall/

On aurait pu rassembler les trois règles en séparant les 3 IP par une virgule, mais ça rallonge fort la ligne et diminue la lisibilité, car on doit décaler toutes les colonnes. Pour rassembler des IP distinctes, l’utilisation des sous-zones est souvent plus efficace.

Les sous-zones

Les sous-zones sont très pratiques et permettent de simplifier la configuration de Shorewall.
On peut créer des sous-zones pour des sous réseaux de zones principales, ou pour des groupes d’IPs.

Les sous-zones sont utilisées comme des zones. Il y a principalement 2 contraintes :

La sous-zone n’hérite pas des règles de la zone parente. Il faut penser à les ajouter.
Une sous-zone ne peut être définie qu’après la définition de la zone dans le fichier /etc/shorewall/zones (l’ordre compte).

Supposons que la dmz se trouve sur l’interface eth3 et que le réseau loc se trouve sur l’interface eth2⁣ :

# Fichier zones (à la fin du fichier, au moins après les définitions de zone dmz et loc)
dmz:webserver    ipv4
loc:sqlserver    ipv4
# Fichier hosts
dmz:webserver    eth3:192.168.100.21,192.168.100.31,192.168.100.41
loc:sqlserver    eth2:192.168.5.6-192.168.5.8
# Fichier rules
MSSQL(ACCEPT)    web                  sqlserver

Nous n’avons plus qu’une seule règle dans le fichier rules, et c’est bien plus lisible.

Remarque : Lorsque l’on crée une sous-zone, les règles du fichier policy ne s’appliquent pas aux sous-zones. D’un point de vue sécurité, c’est très bien. Si on veut les conserver, il faut donc répéter la règle pour la sous-zone.

Étendons le «use case»

Maintenant que nous avons réduit nos 18 lignes de départ en une seule grâce à des sous-zones (=groupes), nous pouvons étendre le cas d’usage :

Les serveurs SQLServer doivent accéder aux 2 serveurs Active Directory dans la zone loc (192.168.6.2, 192.168.6.3)
Les serveurs Web doivent accéder aux 3 serveurs DNS externes dans la zone net (192.168.76.66, 192.168.86.66, 192.168.96.66)
Tous les serveurs doivent accéder aux 2 serveurs proxy, dans la zone net (192.168.66.66, 192.168.67.66) – net est connecté à l’interface eth1

# Fichier zones (à la fin du fichier, au au moins après les définitions de zone dmz et loc)
dmz:webserver           ipv4
loc:sqlserver           ipv4
loc:activedirectory     ipv4
net:dns                 ipv4
net:proxy               ipv4
# Fichier hosts
dmz:webserver           eth3:192.168.100.21,192.168.100.31,192.168.100.41
loc:sqlserver           eth2:192.168.5.6-192.168.5.8
loc:activedirectory     eth2:192.168.6.2,192.168.6.3
net:dns                 eth1:192.168.76.66,192.168.86.66,192.168.96.66
net:proxy               eth1:192.168.66.66,192.168.67.66
# Fichier rules
MSSQL(ACCEPT)           web                  sqlserver
ActiveDir(ACCEPT)       sqlserver            activedirectory
DNS(ACCEPT)             webserver            dns
Squid(ACCEPT)           sqlserver,webserver  proxy

Quelle lisibilité !
Il nous aurait fallu plus de 50 lignes pour avoir l’équivalent de ces quatre règles dans le fichier /etc/shorewall/rules sans les macros et surtout sans les sous-zones.

Les conditions avancées

Imaginons que

les serveurs web se mettent à jour automatiquement tous les jeudis matin
les mise à jour des serveurs SQL sont lancées manuellement, et on préfère que le proxy soit désactivé le reste du temps

Les plages horaires

Squid(ACCEPT)           webserver            proxy - - - - - - - - utc&timestart=08:00&timestop=12:00&weekdays=Thu

La fonction « SWITCH » pour activer ou désactiver des règles dynamiquement

Cette fonction permet d’activer ou de désactiver une règle dynamiquement, sans avoir à modifier la configuration ou relancer Shorewall.
Pour utiliser cette fonctionnalité sous Ubuntu, vous devez installer le paquet xtables-addons-common.

Squid(ACCEPT)           sqlserver  proxy            dot - - - - - - - - - - proxy4sqlserver

Il suffit alors d’écrire un 1 ou un 0 dans /proc/net/nf_condition/proxy4sqlserver pour activer ou désactiver la règle

echo -n 1 > /proc/net/nf_condition/proxy4sqlserver # Active la règle
echo -n 0 > /proc/net/nf_condition/proxy4sqlserver # Désactive la règle

Shorewall dépend de `iptables`

Les fonctionnalités dans Shorewall sont donc directement liés aux modules disponibles :

ls /lib/modules/$(uname -r)/kernel/net/netfilter/

Sous Ubuntu par exemple, le module nf_condition est manquant, ce qui signifie qu’on ne peut utiliser la fonction « SWITCH » dans /etc/shorewall/rules
Pour pouvoir l’utiliser, Ubuntu fourni un paquet avec des modules additionnels :

apt install xtables-addons-common

Lister les modules chargés :

cat /proc/net/ip_tables_matches

Conclusion

Vous l’aurez compris, il y a énormément d’options. Le but n’est pas de les lister toutes. Vous trouverez plus d’informations dans le man shorewall-rules et les autres manuels shorewall-*

Pivert's Blog