Le software (3) contrôle d'accès

Ce petit article présente la partie protection du réseau réalisée avec "iptables".
L'accès Internet est partiellement filtré par le routeur ADSL qui ne nous redirige "que" certains ports (qu'il faut bien paramétrer sur le routeur sans cela notre système sera sourd et muet !).
Il nous faut assurer :
L'autorisation d'entrée pour les entrées dont le serveur a besoin (ports SMTP, POP et IMAP,WebMail par exemple)
L'autorisation de sortie pour les activités prévues (SMTP, polling de serveurs POP, IMAP ...)
Le reste doit être impitoyablement rejeté --> les différentes tables de "iptables" seront positonnées à "DROP" par défaut, tout est donc purement et simplement ignoré, notre script commence donc par fixer la politique par défaut à "DROP" :

iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

Il faut ensuite créer trois "tables utilisateur" spécifiques à chacune de ces trois tables :

iptables -X NOUVIN
iptables -X NOUVOUT
iptables -X NOUVWARD

Dans chacune de ces "tables" nous allons pouvoir insérer nos autorisations sous la forme suivante (exemple très partiel) :

iptables -A NOUVIN  -p tcp --dport 110        -j ACCEPT
iptables -A NOUV    -p tcp --dport 143        -j ACCEPT
iptables -A NOU     -p tcp --dport 25         -j ACCEPT

pour autoriser en entrée les ports 25 (SMTP), 110 (POP), 143 (IMAP). On procède de même pour les autres "tables", pas exemple "NOUVOUT" (exemple partiel) :

iptables -A NOUVOUT  -p tcp --dport 22        -j ACCEPT
iptables -A NOUVOUT  -p tcp --dport 25        -j ACCEPT

Pour autoriser la sortie des ports 22 (ssh) et 25 (SMTP).

Pour le "FORWARD" il ne faut autoriser que les ports nécessaire aux autres machines et surtout interdire les ports des partages WIndows (137 à 139 et 445 par exemple, tant en TCP qu'en UDP) qui n'ont rien à faire sur internet et ont tout à craindre d'entrées depuis internet sur ces même ports.

Il faut ensuite rédiger les règles minimales (pour des raisons de performance essentiellement) pour chacune des tables (INPUT, OUTPUT, FORWARD) en s'insipirant du modèle ci-dessous :

iptables -I INPUT  -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT  -m state --state NEW                 -j NOUVIN
iptables -A INPUT  -m state --state INVALID             -j DROP

1. les trames déjà reconnues sont acceptées sans autre analyse
   
2. les trames "nouvelles" sont transmises à la table d'analyse utilisateur, ici "NOUVIN" pour la partie INPUT, cela serait "NOUVOUT" pour la partie OUTPUT.
   
3. les trames invalides sont purement et simplement droppées
   

La machine effectue en plus du "masquerading" pour les machines du réseau interne, il faut donc un paragraphe consacré à ce phénomène :

iptables -t nat -A POSTROUTING -o wlan0 -s 192.168.1.0/24 -d ! 10.0.0.0/24 -j MASQUERADE

WLAN0 est mon interface de sortie vers Internet

Il est par ailleurs intéressant/nécessaire de savoir ce que notre parefeu a "trappé" en ajoutant en fin de chacune des tables "standard" une ligne qui "logue" les résidus.

iptables -A INPUT -m limit --limit 6/h --limit-burst 1  -j LOG --log-tcp-options --log-prefix ' BOUT_DE_INPUT '

Cette option permet de loguer tout ce qui a été refusé en "INPUT", mais limite le volume à 6 par heure afin de ne pas saturer le log sur un ennui quelconque. D'autre part cela est très utile en phase de démarrage d'aller voir le log (kern.log ou syslog) pour mieux comprendre ce qui ne va pas, "pourquoi je n'accède plus a internet depuis mon poste ?".

Cette machine assure aussi les rôles de :

• DNS cache
• Serveur DHCP
• Serveur NTP

pour tout le réseau interne il faut donc aussi gérer les ports 53 pour le DNS (interfaces interne et externe), 123 pour le NTP (interfaces interne et externe) ainsi que les ports spécifiques au DHCP (interface interne seulement).
Ce script fait toutes ces opérations et est donc déclenché par l'accès du serveur au niveau 3 (fixé dans l'inittab et nécessaire à Zimbra).
Tout ceci à l'air de fonctionner car les paramètres nécessaires ont été repris quasiment tels quels de l'ancien serveur.

Les liaisons vers l'intérieur du réseau sont autorisées assez largement pour les deux sous réseaux gérés car les différents logiciels utilisent une multitude de ports :

1. 22 pour le ssh
2. 80 pour le web
3. 110 pour le POP
4. 143 pour IMAP
5. 489 pour l'annuaire interne LDAP
6. 631 pour CUPS
7.  j'en passe et des meilleurs,
   

mais il est bon de contrôler au maximum ce qui se passe sur le réseau. Dans un premier temps la possibiliter de "loguer" ce qui est rejeté paut aider à affiner les règles. Je vais peut-être installer "SNORT" pour analyser un peu mieux le traffic et NTOP pour quantifier un peu les choses.