Script Iptables

Support Debian
#1

Bonjour, je ne suis pas expert en réseau, mais si vous pouvez me donner des conseils sur le script, ça serai chouette :’) Je l’utilise sur un laptop en réseau public avec des DNS externe public comme FDN.

###### Start Initialisation ######
#### Program $IPv4/$IPv6 
IP='/sbin/iptables'
IP6='/sbin/ip6tables'
y='YES'
n='NO'
#
### Clear tables . -F all. -X users.
if $IP -t filter -F && $IP -t filter -X && $IP6 -t filter -F && $IP6 -t filter -X
then
    echo - Tables clear     :     [$y]
else
    echo - Tables clean     :         [$n]
fi
#
### Forbidden all connection in/out
if $IP -t filter -P INPUT DROP && $IP -t filter -P FORWARD DROP && $IP -t filter -P OUTPUT DROP && $IP6 -t filter -P INPUT DROP && $IP6 -t filter -P FORWARD DROP && $IP6 -t filter -P OUTPUT DROP
then
    echo - Close all In/Out        :     [$y]
else 
    echo - Close all In/Out     :    [$n]
fi
#
### Allow connection already established
if $IP -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT && $IP -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
then
    echo - Connection Established     :     [$y]
else
    echo - Connection Established    :     [$n]
fi
#
### Localhost
if $IP -t filter -A OUTPUT -o lo -j ACCEPT && $IP -t filter -A INPUT -i lo -j ACCEPT
then
    echo - Localhost     :     [$y]
else
    echo - Localhost     :      [$n]
    
fi 
#
###### End Inialisation ######
##### Start Regles ######
#
### ICMP (ping, traceroute)
if $IP -A OUTPUT -p icmp -j ACCEPT && $IP -A OUTPUT -p udp -m udp --dport 33434:33523 -j ACCEPT
then 
    echo - ICMP     :     [$y]
else
    echo - ICMP     :    [$n]
fi
#
### WHOIS
if $IP -A OUTPUT -p tcp --dport 43 -j ACCEPT
then 
    echo - WHOIS     :    [$y]
else
    echo - WHOIS     :     [$n]
fi
### DNS
if $IP -t filter -A OUTPUT -p udp --dport 53 -j ACCEPT
then
    echo - DNS     :     [$y]
else 
    echo - DNS    :     [$n]
fi
### HTTPS
if $IP -t filter -A OUTPUT -p tcp --dport 443 -j ACCEPT
then
    echo - HTTPS     :     [$y]
else
    echo - HTTPS    :     [$n]
fi
#
### HTTP
if $IP -t filter -A OUTPUT -p tcp --dport 80 -j ACCEPT
then
    echo - HTTP     :     [$y]
else
    echo - HTTP     :      [$n]
fi
####### End Regles #######
#2

Apparament, il aurait un problème avec le drapeau --state RELATED.

Source : https://gist.github.com/azlux/6a70bd38bb7c525ab26efe7e3a7ea8ac

#3

Observations sur le script :

En fait d’IPv6, il se limite à bloquer tout trafic IPv6. Je recommanderais d’au moins accepter le trafic IPv6 local sur l’interface de loopback comme pour le trafic IPv4, pour éviter le risque de dysfonctionnement de certaines applications.

### Allow connection already established
En fait ces règles ne font pas qu’autoriser les paquets appartenant aux connexions établies (ESTABLISHED) mais également les paquets liés aux connexions existantes (RELATED). J’y reviendrai plus loin.

### ICMP (ping, traceroute)
De la confusion dans ce commentaire, comme souvent.
Le protocole ICMP ne se limite pas au ping, il y a bien d’autres types de paquets ICMP. Certains types sont indispensables, d’autres utiles, d’autres facultatifs et d’autres potentiellement dangereux. Quant au traceroute, celui de Linux envoie par défaut des paquets UDP et non ICMP ; la seconde règle spécifie le protocole UDP qui n’a rien à voir avec ICMP.

### DNS
Tu n’autorises que le protocole UDP mais certaines requêtes DNS peuvent nécessiter l’emploi du protocole TCP au lieu d’UDP, toujours sur le port 53. Mais c’est assez rare dans le cas d’un poste client.

Cet état est appliqué aux paquets liés à une “connexion” existante (au sens du suivi de connexion de Netfilter). Cela concerne essentiellement deux types de paquets :

  • les paquets ICMP de type message d’erreur ;
  • des paquets de certains protocoles “complexes” mettant en oeuvre plusieurs connexions comme FTP, PPTP ou SIP qui seraient autrement vus comme NEW.

Dans les messages d’erreur ICMP, certains types sont indispensables car ils signalent des erreurs lors de la transmission d’autres paquets : destination-unreachable, time-exceeded, parameter-problem. D’autres sont jugés potentiellement dangereux : redirect (qui peut servir à rediriger les paquets envoyés à une destination donnée), source-quench (qui peut servir à réduire le débit de transmission vers une destination donnée).

L’autre catégorie de paquets ne peut recevoir l’état RELATED que si un “helper” (assistant) pour le suivi de connexion du protocole complexe concerné est chargé et actif. C’est l’objet de l’article que tu pointes. Par défaut aucun helper n’est chargé, et aucun des protocoles autorisés par les règles de ton script n’est un protocole complexe ayant un helper.

Originellement, une fois chargé, un helper surveillait automatiquement toutes les connexions primaires du protocole concerné (exemple : port TCP 21 pour le protocole FTP) afin de déterminer les caractéristiques des éventuels paquets devant être classés dans l’état RELATED. Cette affectation automatique peut causer des problèmes de sécurité en faisant classer comme RELATED des paquets qui ne le devraient pas. A partir du noyau 3.5, une option a été ajoutée pour activer ou désactiver cette affectation automatique, et activée par défaut pour préserver le comportement originel. A partir du noyau 4.7, (donc dans la future Debian stable, Stretch), cette option est désactivée par défaut. Donc même si on charge des helpers, par défaut ils ne surveillent aucune connexion et ne classent aucun paquet dans l’état RELATED. Pour cela il faut activer l’option d’affectation automatique ou ajouter des règles iptables d’affectation explicite avec la cible CT.