Iptables, le pare feu selon linux

Iptables est le plus puissant des pare-feu applicatif. Son rôle est intimement lié à la survie de votre serveur sur Internet !
 
Il est inclus avec toute distribution Fedora.
 
Ayant travaillé chez ZyXEL, un pare-feu se configure comme ceci :
 

  1. On ne touche jamais aux règles génériques
  2. On bloque tout le trafic entrant
  3. Et on autorise des paquets bien spécifiques, au cas par cas

 
Nous allons nous connecter sur Webmin afin de le configurer. Ouvrez un navigateur et accéder à :
 

  • https://127.0.0.1:10000 (si vous êtes sur votre serveur)
  • https://iplocal.de.votre.serveur (si vous êtes sur votre réseau local)
  • https://ippublique.de.votre.serveur (si vous êtes sur Internet, à condition d’avoir forwarder le port 10000 en TCP sur votre routeur en amont)

 
Dans Webmin, Iptables se situe dans Réseau et Linux Firewall.
 
Les règles génériques sont :
 

 
On distingue bien la règle qui bloque tout par défaut, celle qui indique Refuse. On autorise toutes les connexions de l’interface Lo (Loopback, soit même), on accepte le PING (ICMP) et enfin on accepte les paquets ayant une connexion RELATED & ESTABLISHED.
 
Définition : La notion de connexion est moyennement importante, par défaut mettez NEW.
 

  • NEW : signifie que le paquet a démarré ou démarrera une nouvelle connexion
  • ETSABLISHED : signifie que le paquet est lié à une connexion déjà établie
  • RELATED : signifie que le paquet est associé une connexion existante et qu’il démarre une nouvelle connexion
  • INVALID : signifie que le paquet n’est associé à aucun flux

 
Je vous conseille ce magnifique didacticiel sur Iptables.
 
Pour bien configurer son pare-feu il est nécessaire de connaitre les principaux ports de connexion : www.frameip.com
 
Nous allons commencer la configuration d’une règle. Par exemple le port 22, qui est réservé au service SSH.
 
Tout d’abord, il faut rediriger les ports d’écoute de vos services sur le routeur en amont. Moi mon routeur c’est ma freebox.
 
Je me connecte sur mon interface de gestion :
 

 

  • Port : 22 (le port d’écoute de SSH)
  • Protocole : TCP, car SSH utilise le protocole SSH !
  • Destination : L’adresse IP local de votre serveur; moi c’est 192.168.0.10
  • Port : 22 (utile si vous désirez faire du PAT, c’est à dire si port d’entré n’est pas le même que le port de sorti)

 
Et on ajoute ! Mais la Freebox vous demande de redémarrer pour que les modifications soient prises en compte.
 
Ca c’est fait ! Reste plus qu’à autoriser les connexions sur Fedora !
 
Revenez sur Webmin, dans Iptables, Paquets Entrants, ajouter une règle (en bas de la page)
 

 
On arrive ici :
 

 
Nous allons remplir notre première règle, vous allez voir cette règle n’est pas douloureuse ^^
 

  1. Commentaire : Donnez lui un nom (SSH, FTP, etc…)
  2. Action à effectuer : Accepter, Jeter ou refuser.
  3. Adresse source : Adresse IP qui va se connecter sur le serveur
  4. Interface d’entrée : Par défaut ETH0
  5. Protocole réseau : TCP ou UDP
  6. Port TCP ou UDP de destination : Le port concerné
  7. Statut des connexions : New, Established, etc…

 
Ce sont les 7 points importants à connaitre.
 
Différence entre Accepter, Jeter et Refuser :
 

  • Si vous mettez Accepter, le paquet va traverser le pare-feu.
  • En revanche si vous mettez Jeter, le serveur n’informera pas l’expéditeur que le paquet est jeté, donc perdu. Très pratique pour les hack ^^
  • Pour le cas Refuser, le serveur va envoyer une réponse à l’expéditeur.

 
Pour ma part je mets toujours Jeter !
 
Pourquoi filtrer l’IP source ?
 
Cela permet d’accéder de façon ultra sécurisée à votre serveur. Si vous ne connaissez pas votre adresse IP, vous allez voir ce que les bots sont capables de faire. Le mieux est de sécuriser l’IP source. Pour ma part j’ai mis l’adresse IP de ma Freebox, qui fait office de passerelle.
 
Pourquoi ne pas mettre l’IP de mon pc ? Tout simplement parce que la Freebox fait du NAT sur le réseau local, c’est à dire qu’elle masque les IP locales et remplace l’en-tête du paquet IP par son adresse à elle. Si vous êtes perdus, c’est assez complexe car tous les routeurs n’agissent pas de la sorte ! Mais merci ZyXEL, j’ai appris plein de bonnes choses.
 
Pourquoi le port TCP ou UDP est de destination ?
 
Tout simplement parce que votre serveur est à la fin du processus, et que Linux intègre par défaut le PAT.
 
Exemple : J’ai deux machines Linux sur mon réseau local, et je veux les administrer tous les 2 par SSH. Or SSH n’a qu’un seul port, le 22 !
 
Comme je ne peux que rediriger qu’un port, sur une interface physique à la fois je vais devoir faire du PAT. Sur l’un je vais laisser le port 22, l’autre je vais mettre le port 222. Mais ça c’est le port source, le port destination ne change pas, ce sera le 22 pour tous les 2 !
 
D’où dans notre règle de toujours spécifier le port TCP ou UDP de destination.
 
Go pour notre règle SSH :
 

  1. Commentaire : SSH
  2. Action à effectuer : Accepter
  3. Adresse source : 192.168.0.254 (ma passerelle), mettez ici une adresse IP qui va se connecter ou laisser rien 🙁
  4. Interface d’entrée : Par défaut ETH0
  5. Protocole réseau : TCP, car le protocole SSH est TCP
  6. Port TCP ou UDP de destination : 22 en TCP
  7. Statut des connexions : New et Established

 
Cliquer sur Créer !
 
Et enfin sur Appliquer la configuration.
 
Sinon vous pouvez la faire en ligne de commande, voici la marche à suivre :
 

# nano /etc/sysconfig/iptables

 
et ajouter cette règle ci après : « OUTPUT ACCEPT : »
 

-A INPUT -p tcp -m tcp -m state -s 192.168.0.254/32 -i eth0 –dport 22 –state NEW -j ACCEPT

 
Faites un CTRL+O et redémarrez le service IPTABLES
 
Pour finir, Samba. Il utilise différents ports : (inutile de rediriger les ports sur votre routeur, car un partage samba c’est que sur le réseau local)
 

  • Port Netbios : 137,138 en UDP
  • Port Netbios : 139 en TCP
  • Port Microsoft : 445 en TCP et UDP

 

 
Ce qui est bien avec IPtables c’est qu’on peut lui mettre le masque de sous réseau, d’ou mon 192.168.0.0/24. J’autorise tout mon réseau local à voir mon partage Samba. Mais ils ne peuvent pas tous se connecter, et oui avec Samba j’ai autorisé quelques IP à se connecter ^^
 
Astuce : Si vous avez qu’une seule IP, vous pouvez adjoindre le /32 à la fin.
 
Et voilà nous avons fini avec une partie « sommaire » du réseau, il n’y a rien de sorcier il suffit juste d’avoir la logique !
 
Et comme tout Firewall qui se respecte, Fedora lit les règles dans l’ordre, si la règle ne le concerne pas, il passe à la suivante et ainsi de suite jusqu’à trouver celle qui interdit tout. Donc y’a forcément une règle qui le concerne !
 
Reste plus qu’à mettre en service IPtables, soit par :
 

 
N’oublier pas de l’activer au démarrage ^^
 
Avant de conclure nous allons loguer les paquets forward, ce qui est indispensable pour comprendre les erreurs.
 
Dans IPTABLES l’astuce consiste à créer une règle LOG avant la règle concernée. Pourquoi ? Afin qu’elle soit lue avant la « vraie règle »
 
Prenons l’exemple de notre règle SSH :
 

  1. Par Webmin : Placer votre curseur sur la règle que vous désirez loguer. Et cliquer ici :
  2. Cela permet d’ajouter une règle avant la règle concernée, de façon à ce qu’elle soit lue en premier. Dans action à effectuer sélectionner Log Packet au lieu d’accepter et enfin renseigner le champs Paramètres additionnels en bas par : –log-prefix « forward »
  3. Sinon vous avez l’option ligne de commande. Éditez le fichier IPTABLES, disponible dans /etc/sysconfig. Ajoutez ceci après « OUTPUT ACCEPT : » et avant votre règle pour le port 22 si c’est bien elle que vous voulez loguer.

 

-A INPUT -p tcp -m tcp -m state -s 192.168.0.254/32 –dport 22 –state NEW -j LOG  –log-prefix « forward »

 
Faites un CTRL+O et un service iptables restart
 
Reste plus qu’à signifier 2 choses à Syslog pour séparer les logs IPTABLES du KERNEL. Hé oui par défaut les logs du kernel sont dans /var/log/messages.
 
Nous allons les mettre dans /var/log/iptables.
 

# nano /etc/rsyslog.conf

 

#### RULES ####

# Log all kernel messages to the console.
# Logging much else clutters up the screen.
kern.=warning -/var/log/iptables
kern.*;kern.!=warning -/var/log/kernel

# Log anything (except mail) of level info or higher.
# Don’t log private authentication messages!
*.info;mail.none;authpriv.none;cron.none;kern.=warning.none /var/log/messages

 
Renseigner les champs :
 

  1. kern.=warning cela envoie les logs warning du kernel dans le fichier iptables
  2. kern.!=warning, cela enlève les logs warning du kernel dans le fichier kernel
  3. kern.=warning.none enlève les logs warning du kernel dans le fichier messages

 
Redémarrez le service rsyslog et éditez les fichiers de log pour constater le tout.
 

Jan 24 21:54:34 samn0 kernel: forwardIN=eth0 OUT= SRC=192.168.0.254 DST=192.168.0.241 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=2075 DF PROTO=TCP SPT=49460 DPT=22 WINDOW=8192 RES=0x00 SYN URGP=0

 
Et si on se faisait un petit serveur FTP ?

Laisser un commentaire

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.