[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Régles iptables et ftp



Salut,

David Hannequin a écrit :
> 
> J'ai un serveur ftp debian sarge derrière un firewall.
> Internet ---------- Firewall ------------- Serveur ftp
> 
> Je souhaite faire fonctionner iptables sur le serveur ftp. J'ai donc 
> écrit le script suivant :
> 
> #!/bin/bash
> modprobe ip_conntrack_ftp
> 
> echo "On vide toutes les régles."
> iptables -F
> iptables -X
> iptables -Z
> 
> echo "On bloque tout par défaut"
> iptables -P INPUT DROP
> iptables -P OUTPUT DROP
> iptables -P FORWARD DROP
> 
> echo "On  autorise le trafic E/S sur l'interface de loopback"
> iptables -A INPUT -i lo -j ACCEPT
> iptables -A OUTPUT -o lo -j ACCEPT
> 
> echo "On autorise le trafic en sortie de eth0"
> iptables -A OUTPUT -o eth0 -j ACCEPT

C'est un choix. Qui a ses avantages et ses inconvénients.

> echo "On autorise le traffic en entrée de eth0 si il est déjà connu"
> iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
> 
> echo "On autorise le protocole FTP"
> iptables -A INPUT -i eth0 -p tcp --dport 21 -m state --state 
> NEW,ESTABLISHED -j ACCEPT

ESTABLISHED n'est pas nécessaire : le cas est déjà couvert par la règle 
précédente.

Réponse courte : ce qui précède est suffisant, tu peux supprimer tout ce 
qui suit.

Réponse longue :

> iptables -A OUTPUT -o eth0 -p tcp --sport 21 -m state --state 
> ESTABLISHED -j ACCEPT

Déjà couvert par une règle précédente qui accepte tout en sortie.

> iptables -A INPUT -i eth0 -p tcp --dport 20 -m state --state 
> ESTABLISHED,RELATED -j ACCEPT

Inutile à deux titres :
- déjà couvert par une règle précédente qui accepte tout le trafic 
ESTABLISHED ou RELATED en entrée ;
- la connexion utilisant le port source 20 (ftp-data) est sortante, 
l'état RELATED est visible en sortie, pas en entrée.

> iptables -A OUTPUT -o eth0 -p tcp --sport 20 -m state --state 
> ESTABLISHED -j ACCEPT

Déjà couvert par une règle précédente qui accepte tout en sortie.

> iptables -A INPUT -i eth0 -p tcp --dport 1024:65535 -m state --state 
> ESTABLISHED,RELATED -j ACCEPT

Déjà couvert par une règle précédente qui accepte tout le trafic 
ESTABLISHED ou RELATED en entrée.

> iptables -A OUTPUT -o eth0 -p tcp --sport 1024:65535 -m state --state 
> ESTABLISHED -j ACCEPT

Déjà couvert par une règle précédente qui accepte tout en sortie.

> Est ce que vous pouvez me dire ce que vous en pensez ?

Manque des règles pour :
- accepter le ping en entrée (ICMP echo-request, état NEW) ;
- rejeter (cible REJECT) le trafic valide entrant non désiré.

Je réponds aussi à Marc PERRUDIN qui a écrit :
>
> Si tu utilise le module state, ftp necessite seulement 2 regles:
> 
> echo "On autorise le protocole FTP"
> iptables -A INPUT -i eth0 -p tcp --dport 21 -m state --state
> NEW,ESTABLISHED,RELATED -j ACCEPT
> iptables -A OUTPUT -o eth0 -p tcp --sport 21 -m state --state
> ESTABLISHED,RELATED -j ACCEPT

Pas suffisant : ces deux règles ne traitent que les connexions de 
contrôle, pas les connexions de données. D'autre part, dans ces deux 
règles, RELATED est inutile. Un paquet d'une connexion de contrôle n'a 
aucune raison d'être vu dans cet état.

> C'est d'ailleurs l'interet de ce module, il permet de ne pas etre obligé
> d'ouvrir tous les ports au dessus de 1024 et le ftp-data entrant en
> permanence.

> Le module ip_conntrack_ftp
> permet d'eviter d'avoir des ports ouverts en permanence, le module se
> charge d'ouvrir seulement les ports utilisés et uniquement pendant
> qu'ils sont utilisés.

C'est faux. ip_conntrack_ftp ne fait que mettre dans l'état RELATED le 
premier paquet d'une connexion FTP de données. Il reste nécessaire 
qu'une règle accepte explicitement ce paquet. Typiquement celle-ci qu'on 
trouve souvent en tête de script :

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

On peut raffiner selon l'état, l'interface, le protocole, le port, mais 
c'est l'idée. Par exemple je n'accepte pas tous les types ICMP RELATED 
venant de l'extérieur.

Détail utile : la reconnaissance des connexions de données FTP par 
ip_conntrack_ftp ne marche que s'il peut lire le contenu de la connexion 
de contrôle, donc si celui-ci est en clair (pas de chiffrement TLS/SSL).

> Un des interets de cette facon de fonctionner est d'eviter qu'en cas
> d'attaque réussi sur le système, le pirate puisse tranquillement mettre
> des demons en ecoutent sur les ports ouverts, il doit obligatoirement
> obtenir des privileges élevés (root) pour pouvoir faire ce genre d'action.

Bof bof. Etant donné que le filtrage en sortie est souvent beaucoup plus 
laxiste qu'en entrée, la mode est plutôt aux chevaux de Troie et autres 
véroles qui téléphonent maison en établissant eux-même une connexion 
sortante vers un service contrôlé par son maître au lieu d'écouter sur 
un port. Exemple : zombie IRC qui attend les ordres sur un canal IRC 
discret.

Je réponds aussi à Thierry B qui a écrit :
>
> Il ne serait pas préférable du coté ftp, d'ouvrir seulement quelques
> ports du genre 50000-50002, et de paramétrer le serveur ftp pour qu'il
> utilise ces ports ci?

Non, ou alors seulement si on n'a pas le choix : firewall ou NAT pas 
"FTP-friendly", chiffrement SSL/TLS de la connexion de contrôle...

> Ou justement l'interet ip_conntrack_ftp c'est de ne pas fixer de plages,
> comme ca on est tranquille au niveau de la limite du nombre de
> transferts simultanés en mode ftp passif ?
Exactement. Même chose pour un client FTP en mode actif.

Attention : les connexions de données ne servent pas uniquement aux 
transferts de fichiers mais aussi au listage des répertoires.



Reply to: