5. Shorewall en entreprise : Traçabilité, documentation des règles, revues d’audit, journalisation

Reading Time: 3 minutes

Table of Contents

1. Traçabilité

Garder toutes les versions et l’historique des changements de configuration. Shorewall étant basé sur des fichiers texte, il suffit d’utiliser git.
De plus, vous pouvez déclencher un git commit à chaque modification dans /etc/shorewall.

cd /etc/shorewall/
git init .
git add *
git status
git config --global user.email "you@example.com"
git config --global user.name "Your Name"
git commit -am 'Commit initial'

Afin de s’assurer qu’un commit soit bien effectué à chaque changement, il faut l’automatiser.
Si vous utilisez Vim ou Neovim, ajoutez au /etc/vim/vimrc.local :

:autocmd BufWritePost /etc/shorewall/* !cd /etc/shorewall && \
    git commit -am "Vim auto-commit by user $(who am i | awk '{print $1}')"

Un « git commit » sera exécuté à chaque édition avec Vim dans le répertoire /etc/shorewall
who am i displays shows the original user name.

who am i différence avec whoami

root@Z690:~# whoami
root
root@Z690:~# who am i
pivert   pts/8        2023-05-20 00:38 (:0)

Utilisez les commandes standard git pour voyager dans votre historique (et celui de vos collègues). Vous pouvez en plus programmer des git commit via cron.

2. Documentation des règles

Chaque règle ou groupe de règle doivent être documentés sans quoi vous ne vous y retrouverez plus, même si vous êtes le seul à modifier les règles.

Shorewall autorise les commentaires partout. Idéalement :

Utilisez principalement la directive ?COMMENT devant chaque bloc de règles. Le commentaire sera en plus affiché par les commandes
- shorewall show
- shorewall dump
Commentez les règles individuellement en fin de ligne, par exemple avec le numéro de ticket et/ou la date.

Exemple

?COMMENT Temporary and test rules                                                                                                             
ACCEPT          fw                      net:85.93.242.84                                          # DoH  (#445322)                                                   
ACCEPT          loc:192.168.22.24       phone:192.168.111.10                                      # PBX  (#653224)                                               
ACCEPT          loc:192.168.22.34       phone:192.168.111.10                                      # PBX                                                                                  
Web(ACCEPT)     swarm                   dmz:192.168.232.141     tcp     80                                                                     
# Web(ACCEPT)   es                      net:64.120.127.130                                        # Decommissioned (2022-10-29)

?COMMENT apt-proxy
ACCEPT          dmz10,dns,es    swarm                   tcp 3142                                  # Apt-cacher-ng 

?COMMENT RKE2                                                                                                                          
ACCEPT          rke2            pve                     tcp 6789,6800-7300,8086                   # Ceph & PVE GUI

?COMMENT Traefik to Grafana & Prometheus                                                                                               
ACCEPT          swarm           loc:192.168.22.47       tcp 3000,9090,9091                        # Grafana & Prometheus

?COMMENT

3. Revues d’audit

Avec un fichier bien documenté, vous pourrez déjà faire pas mal de revues à partir du fichier.
La commande shorewall dump est toujours très utile, y compris pour des revues. Certains auditeurs ont des outils adaptés à iptables qui pourront prendre quasiment directement la sortie de shorewall dump, et bénéficier des commentaires donnés par les directives ?COMMENT

4. Journalisation

La journalisation est essentielle à un firewall. Quand vous devrez faire face à une suspicion d’intrusion ou d’exfiltration de donnée, la garantie d’avoir des logs de qualité, sur une longue période et non falsifiés est essentielle.

Par défaut, les logs sont intégrés à syslog, et vous avez donc un historique efficace de quelques semaines à quelques mois. Mais ils sont modifiables. Donc il vous faudra aller plus loin :

Intégration d’une partie de logs dans un outil de SIEM (security event information management) tels que Splunk, Graylog, ELK, etc… En particulier certains DROP et les REJECTS.
Améliorez vos logs shorewall avec l’utilisation de l’action LOG (c.f. shorewall-logging documentation)
Il n’est pas recommandé d’envoyer tout dans le SIEM. Si un SIEM est excellent pour détecter des «patterns», faire de la corrélation et déclencher des actions ou des alertes, c’est généralement une mauvaise solution de centralisation logs :
- Le volume de logs et donc les coûts de stockage sur une longue période peuvent exploser
- Une fois dans un SIEM ou une DB, vous ne pourrez plus utiliser les commandes shell standard et pratiques pour analyser vos logs telles que grep, wc, sed, …
Idéalement, redirigez les logs vers un système dédié et non falsifiable (WORM). C’est un vrai challenge. Idéalement :
- Un administrateur système, pas même vous ne doit pouvoir modifier ces logs.
- Ligne par ligne au lieu de fichier par fichier.
- Ça implique également un système de cache dans les serveurs source, de manière que les logs soient retransmis s’il y a une interruption de réseau ou du service de logs.
Exemple de solution technique: Filebeat + ELK, OpenAFS.

Vous l’avez compris, il y a toutes les fonctionnalités nécessaires dans Shorewall. Pour ce qui est de la journalisation, c’est toujours un compromis entre coût et sécurité.

Contactez-moi si vous êtes face à une problématique complexe.

Dans le prochain et dernier article de la série Shorewall, nos aborderons la haute disponibilité, et implicitement la maintenabilité du système et de Shorewall.

Pivert's Blog