Sécurité avec iptables et l'option RELATED

Warning_IPTABLES.md

Problème d'ouvertue de port non désirée sur une configuration IPTABLES

Un problème de contournement des règles iptables fixées par utilisateur peut survenir avec l’utilisation de règles iptables RELATED,ESTABLISH trop générique et le chargement de helper de service non présent ou non utilisé sur la machine (exemple FTP actif, SIP, IRC …).

True fact: Mon server MariaDB s'est fait attaqué comme ça alors que le port dans l'iptable n'était pas ouvert.

---

Menu

1. Rappel
2. Description du problème
3. Résolution du problème
   1. Option 1: Supprimer les Related
   2. Option 2: Préciser les Helpers
4. Effets de bords
5. Outils

Rappel

Rappel sur l’utilisation du drapeau RELATED :

RELATED signifiant que le paquet initie une nouvelle connexion, mais qu'il est associé avec une connexion existante, comme un transfert de données FTP ou une erreur ICMP.

RELATED est associé à conntrack qui utilise différents « HELPER » pour « tracer » et « comprendre » le fonctionnement du protocole.

Description du problème

Le problème de produit lorsqu’une règle RELATED trop générique est mise en place et que les HELPER sont activés par défaut (car par défaut sur un grand nombre de distribution) :

Exemple :

• iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT (Syntaxe obsolete)
• iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT (Dernier syntaxe)

On trouve cette règle dans beaucoup de standard de configuration (y compris la documentation officiel d’Ubuntu). Cependant, cela pose un problème de sécurité, puisqu’il suffit d’envoyer un paquet de forgé spécifique pour déclencher un helper et donc de marquer une connexion comme RELATED. Un exemple du principe de contournement avec FTP (date de 2009 mais toujours valide) :

https://github.com/rtsisyk/linux-iptables-contrack-exploit

Résolution du problème

Fortement inspiré de http://home.regit.org/wp-content/uploads/2011/11/secure-conntrack-helpers.html

Option 1 : supprimer les RELATED :

Supprimer les RELATED des règles IPTABLES est radicale. Si le server n’utilise pas de protocole nécessitant l’utilisation de helper et que les règles sont trivials, la suppression de RELATED dans les règles de firewall suffit.

Exemple :

iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -p icmp -j ACCEPT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT # accept established connections
iptables -A INPUT -p tcp --dport 80 -j ACCEPT # allow access to http server
iptables -P INPUT DROP # drop other incoming connections

iptables -P OUTPUT -j ACCEPT # allow any connection from the host

Deviens :

iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -p icmp -j ACCEPT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT # accept established connections
iptables -A INPUT -p tcp --dport 80 -j ACCEPT # allow access to http server
iptables -P INPUT DROP # drop other incoming connections

iptables -P OUTPUT -j ACCEPT # allow any connection from the host

Option 2 : préciser les helpers :

Préciser les helpers utilisés pour les règles RELATED et les paramètres de ceux-ci, et ainsi limiter le spoofing d’addresse.

1. Désactiver les paramétrages par défaut

Depuis Linux 3.5, il est possible (et fortement conseillé pour les serveurs en frontal d’internet) de désactiver l’assignement automatique des helpers :

modprobe nf_conntrack nf_conntrack_helper=0

Le paramètre peut être modifier après chargement :

echo 0 > /proc/sys/net/netfilter/nf_conntrack_helper

Attention, les connections déjà associé à un helper le reste, il est donc préférable de redémarrer la machine « après » configuration persistante, ou de vider les tables avec conntrack -F.

Pour les anciens kernel, affecter le ports 0 par défaut met en place la même fonctionnalité.

modprobe nf_conntrack_$PROTO ports=0 avec proto = ftp, irc …

Avec ce paramétrage les flux suivant seront complètement désactivé en l’absence de configuration spécifique :

• ftp
• irc
• sane
• sip
• tftp

En l’absence de "ports" paramétrés, certains module ne fonctionneront plus :

• amanda
• h323
• netbios_ns
• pptp
• snmp

Si les modules ne sont pas charger par default, les règles iptables

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # accept established connections
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # accept established connections

ne s’appliquent plus théoriquement qu’au protocole icmp, il reste conseillé tous de même d’adapter ses règles de filtrage.

2. Paramétrer les « helpers » dans les règles utilisées :

Exemple : Si le servers fait des connections sip et des connections ftp actif :

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # accept established connections
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # accept established connections

ou

iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT # accept established connections
iptables -A OUPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT # accept established connections

Deviens (pour un firewall local a la machine) :

iptables -A OUTPUT -m conntrack --ctstate RELATED -m helper \
       --helper ftp -o $OUT_IFACE -p tcp \
       --dport 1024: -j ACCEPT

iptables -A INPUT -m conntrack --ctstate RELATED -m helper \
       --helper ftp -i $OUT_IFACE -p tcp \
       --dport 1024: -j ACCEPT

iptables -A OUTPUT -m conntrack --ctstate RELATED -m helper \
       --helper sip -d $IPS_RTP_SERVER -p udp -j ACCEPT

Si le serveur est server FTP actif :

iptables -A OUPUT -m conntrack --ctstate RELATED -m helper \
       --helper ftp -d $IPS_MY_FTP_SERVER -p tcp \
       --dport 1024: -j ACCEPT

Si le serveur n’est pas sur un port standard du helper (Kernel >2.6.34):

iptables -A PREROUTING -t raw -p tcp --dport 2121 \
       -d $IPS_MY_FTP_SERVER -j CT --helper ftp

Sinon cela se configure dans les paramètres du module (Kernel <2.6.34): modprobe nf_conntrack_ftp ports=21,2121

Effets de bord

le traceroute ne fonctionnera plus (si on filtre l'icmp de type 8 uniquement). Solution :

iptables -A INPUT_ICMP -p icmp --icmp-type destination-unreachable -m conntrack --ctstate RELATED -j ACCEPT
iptables -A INPUT_ICMP -p icmp --icmp-type time-exceeded -m conntrack --ctstate RELATED -j ACCEPT

Ici, pas de helper spécifique, il s'agit simplement d'une réponse provenant d'une adresses IP différente que la destination initiale du packet ICMP. Pour limiter le conntrack, le type de packet est spécifié.

Outils

Outils pour vérifier les états des connections :

/proc/net/nf_conntrack et grep

Je ne suis pas sur de comprendre cette phrase. Pourquoi les adresses IP qui répondent sont différentes des adresses IP de destination ?
il s'agit simplement d'une réponse provenant d'IP differrente que la destination
il s'agit simplement d'une réponse provenant d'adresses IP différentes que la destination

Voir également :
Avec ce paramétrage les flux suivant seront complément désactivé en l’absence de configuration spécifique :
Avec ce paramétrage les flux suivant seront complètement désactivés en l’absence de configuration spécifique :

@ZerooCool

Je ne suis pas bien sur de comprendre cette phrase d'ailleurs, pourquoi les adresses IP qui répondent sont différentes des adresses IP de destination ?

J'ai changé la phrase pour refléter qu'avec un traceroute, les réponses sont faites par les routeurs intermédiaires. Les réponses de tous les pings du traceroute sont donc fournit par des IP ne correspondant par à la destination du packet.

cf wikipedia :

Le principe de fonctionnement de Traceroute consiste à envoyer des paquets UDP (certaines versions peuvent aussi utiliser TCP ou bien ICMP ECHO Request) avec un paramètre Time-To-Live (TTL) de plus en plus grand (en commençant à 1). Chaque routeur qui reçoit un paquet IP en décrémente le TTL avant de le transmettre. Lorsque le TTL atteint 0, le routeur émet un paquet ICMP d'erreur Time to live exceeded vers la source. Traceroute découvre ainsi les routeurs de proche en proche.

J’espère que ma réponse est plus claire maintenant.
Az

Merci.

Peux tu me donner ton avis sur les règles suivantes ? Notamment sur les deux dernières.
J'ai fais ainsi, et, ma connexion FTP fonctionne, mais, si je bidouille un peu trop, je n'ai plus de connexion.
Est ce que avoir ajouté ainsi les deux dernières lignes semble correct ?

# Autoriser les connexions au serveur FTP sur le port 21.
# Une connexion FTP passive est recommandée ! Depuis le client FileZilla Edition/Paramètres/Connexion/FTP/ décocher :
# Autoriser un retour sur un autre mode de transfert en cas d'échec
-A INPUT -p tcp --dport 21 -m state --state NEW,ESTABLISHED -j ACCEPT

# Configurer Iptables pour utiliser la plage de ports passifs proposés par IANA entre 49152-65534.
# La récupération au dossier racine ne se fait pas, depuis FileZilla, si la plage de port suivante n'est pas autorisée.
-A INPUT -p tcp --dport 49152:65534 -m state --state ESTABLISHED,NEW -j ACCEPT

# Ajout de RELATED et helper. Appliqué en complément de la connexion FTP ???
# Revérifier la syntaxe et l'utilité des deux lignes suivantes, lorsque ajoutées après les deux lignes précédentes !
-A OUTPUT -m conntrack --ctstate RELATED -m helper --helper ftp -p tcp --dport 49152:65534 -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED -m helper --helper ftp -p tcp --dport 49152:65534 -j ACCEPT

Dans ton exemple, tu as iptables -P OUTPUT -j ACCEPT, n'est-ce pas plutôt iptables -P OUTPUT ACCEPT ?