[IPTABLES] Questions

Support Debian
#1

Bonjour,

Voila je suis débutante en admin sys (bien grand mot), et j’ai quelques questions a propos des IPTABLES.

Voici déjà les infos de mon système :

Linux (none) 3.2.0-4-amd64 #1 SMP Debian 3.2.60-1+deb7u3 x86_64 GNU/Linux

Le fichier d’iptables, vraiment très basique :

[code]sudo iptables -t filter -F
sudo iptables -t filter -X

sudo iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

sudo iptables -t filter -A INPUT -i lo -j ACCEPT
sudo iptables -t filter -A OUTPUT -o lo -j ACCEPT

sudo iptables -t filter -A INPUT -p tcp --dport XXXX -j ACCEPT
sudo iptables -t filter -A OUTPUT -p tcp --dport XXXX -j ACCEPT

sudo iptables -t filter -A INPUT -p icmp -j ACCEPT
sudo iptables -t filter -A OUTPUT -p icmp -j ACCEPT

sudo iptables -t filter -A INPUT -p tcp --dport 53 -j ACCEPT
sudo iptables -t filter -A INPUT -p udp --dport 53 -j ACCEPT
sudo iptables -t filter -A OUTPUT -p tcp --dport 53 -j ACCEPT
sudo iptables -t filter -A OUTPUT -p udp --dport 53 -j ACCEPT

sudo iptables -t filter -A OUTPUT -p udp --dport 123 -j ACCEPT

sudo iptables -t filter -P INPUT DROP
sudo iptables -t filter -P FORWARD DROP
sudo iptables -t filter -P OUTPUT DROP[/code]

Voici mes questions :

  • J’ai été obligé de mettre mes règles DROP a la fin du script. Si elle était en début de fichier, tout était bloqué. Pourtant, je vois fréquemment sur le net que ses règles sont mises en premier dans les scripts (IPTABLES lit le fichier au fur et a mesure). Est-ce que cela pose un problème ?

  • J’ai fait un nmap d’une machine distante, et tous mes ports sont filtered, le 53 close, et XXXX (SSH) est constamment OPEN, même si je ne suis pas co dessus. Nmap ne devrait pas déduire qu’il est en filtered ?

Merci.

#2

Ce ne sont pas des règles mais les politiques par défaut des chaînes. [mono]-A[/mono] != [mono]-P[/mono]. Contrairement aux règles, l’ordre de définition des politiques par défaut n’a aucune influence sur le résultat final. Le seul impact est sur la séquence des événements lors de l’exécution du script. Si on met les politiques à DROP à la fin du script, on laisse potentiellement un trou, un intervalle de temps pendant l’exécution du script ou rien n’est filtré.

Qu’entends-tu par “tout était bloqué” ? Dans quelles circonstances ?

Le script n’est pas lu par iptables mais par un interpréteur de commandes (bash, dash…) qui exécute chaque commande séquentiellement. Si tu veux créer un fichier lu directement par iptables (plus rapide), il faut utiliser [mono]iptables-save[/mono] et [mono]iptables-restore[/mono].

Ce qui signifie qu’aucun service n’écoute dessus (pas de serveur DNS sur la machine) et donc tu peux supprimer les règles INPUT pour ce port.

Non. “open”, ça signifie en fait ouvert en écoute, et non qu’une connexion est déjà établie avec ce port.

Accessoirement, je trouve suspect que les mêmes ports soient autorisés en entrée et en sortie. Cela signifierait que la machine héberge des services et est susceptible de se connecter aux mêmes services sur d’autres machines.

Autre remarque : sudo dans un script, c’est, comment dire… bof.

#3

Bonsoir,

Déjà merci pour ta réponse. Je vais essaye de répondre point par point tout ce que tu m’as dit.

En ce qui concerne les politique, merci de l’info. Mais le soucis c’est que si je mettais ces dernières en tout début du script, je ne pouvais plus accéder a mon serveur, même via SSH.

Pour l’instant je suis en phase de test, j’utiliserais plus tard iptables-save et iptables restore.

Je n’ai pas encore active le DNS, et je compte rajoute des règles en ce qui concerne les autres services de ma machine (Serveur web, GIT, etc…).

De ce coté la, je ne comprends pas bien. Si j’ouvre en entrée et en sortie, c’est pour que la communications se fassent. Il faut bien que les ports soient ouverts dans les deux sens, non ?

Je sais bien pour le sudo, c’est juste pour des tests pour le moment.

Merci encore pour ta reponse.

#4

[quote=“MissJane”]
En ce qui concerne les politique, merci de l’info. Mais le soucis c’est que si je mettais ces dernières en tout début du script, je ne pouvais plus accéder a mon serveur, même via SSH.[/quote]
Comment le script était-il exécuté ? Si c’est à distance dans une session SSH et sudo demande de saisir le mot de passe en plein milieu, c’est normal que ça bloque. Il faut exécuter ce genre de script d’un trait, de façon non interactive.

Non. Lorsqu’une machine se connecte au port X d’un serveur distant, elle n’utilise pas le port X local mais un autre port aléatoire. Les règles de suivi de connexion (avec ESTABLISHED) servent à reconnaître les paquets appartenant à des connexion existantes, et notamment les paquets de réponse, sans devoir se soucier du port source ou destination.

#5

Bonsoir.

Ok pour le script, merci.

Donc si je comprends bien, j’ai juste a ouvrir les ports en entrée, les connections resteront établies même si les ports de sorties sont fermés ?

Merci.

#6

Il faut ouvrir en entrée (INPUT) les ports pour lesquels ta machine est serveur. Et en sortie (OUTPUT) ceux pour lesquels elle est cliente.

#7

Pour éviter de me couper moi-même la connexion, j’utilise un script qui ressemble à cela :

[code]#!/bin/bash

Script de mise en place du firewall

Pour que le script ne s’interrompe pas quand on se coupe soi-même la connexion

trap false SIGHUP

On nettoie les tables et les policy par defaut

iptables -t filter -F OUTPUT
iptables -t filter -P OUTPUT ACCEPT
iptables -t filter -F INPUT
iptables -t filter -P INPUT ACCEPT

Connexions sortantes

iptables -t filter -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

ICMP

iptables -t filter -A OUTPUT --protocol icmp -j ACCEPT

DNS

iptables -t filter -A OUTPUT --protocol udp --destination-port 53 -j ACCEPT
iptables -t filter -A OUTPUT --protocol tcp --destination-port 53 -j ACCEPT

HTTP, pour les MAJ de Debian

iptables -t filter -A OUTPUT --protocol tcp --destination-port 80 -j ACCEPT

NTP

iptables -t filter -A OUTPUT --protocol udp --destination-port 123 -j ACCEPT

SMTP

iptables -t filter -A OUTPUT --protocol tcp --destination-port 25 -j ACCEPT

iptables -t filter -A OUTPUT --out-interface eth0 -j DROP

Connexions entrantes

iptables -t filter -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

ICMP

iptables -t filter -A INPUT --protocol icmp -j ACCEPT

SSH

iptables -t filter -A INPUT --protocol tcp --destination-port 22 -j ACCEPT

iptables -t filter -A INPUT --in-interface eth0 -j DROP

[/code]
[mono]trap false SIGHUP[/mono] permet à ce que le script ne soit pas interrompu par le signal HUP, qui se produit quand le shell pense que le terminal a raccroché.
Et le fait de ne pas utiliser les policy/politiques par défaut me permet d’autoriser le traffic (dont mon propre accès SSH) avant de l’interdire.

Et malgré ces deux précautions, la boulette arrive encore de temps en temps.

En ce qui concerne sudo, on l’utilise avec [mono]sudo ./monscript.bash[/mono] pour exécuter un script du répertoire courant ou encore avec [mono]sudo -i[/mono] pour ouvrir un shell tout beau, tout propre (mais pas top question sécurité).

–
AnonymousCoward

#8

Je ne vois pas l’avantage de tes règles DROP finales par rapport à des politiques par défaut à DROP. Tu peux aussi appliquer les politiques DROP à la fin du script. Par contre je vois un inconvénient : si tu veux rajouter une règle à la volée sans recharger tout le script, tu es obligé de l’insérer avant la règle DROP. Avec une politique, on n’a pas cette contrainte, il suffit d’ajouter la règle à la fin de la chaîne.

#9

J’ai toujours trouvé moche le truc des politiques par défaut, dans iptables. Cela ne fonctionne pas sur les chaînes que l’on peut ajouter et on ne peut pas s’en servir pour faire un jump/goto vers une autre chaîne.

D’ailleurs, cela n’existe plus avec nftables. :smiley:

Mais bon, les goûts et les couleurs…

–
AnonymousCoward