Règles iptables

Support Debian
#1

Bonjour,

Voici mon script iptables:

 ## On flush iptables.
     
    iptables -F
     
    ## On supprime toutes les chaînes utilisateurs.
     
    iptables -X
     
    ## On drop tout le trafic entrant.
     
    iptables -P INPUT DROP
     
    ## On drop tout le trafic sortant.
     
    iptables -P OUTPUT DROP
     
    ## On drop le forward.
     
    iptables -P FORWARD DROP
     
    ## On drop les scans XMAS et NULL.
     
    iptables -A INPUT -p tcp --tcp-flags FIN,URG,PSH FIN,URG,PSH -j DROP
     
    iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
     
    iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
     
    iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
     
    ## Dropper silencieusement tous les paquets broadcastés.
     
    iptables -A INPUT -m pkttype --pkt-type broadcast -j DROP
     
    ## Permettre à une connexion ouverte de recevoir du trafic en entrée.
     
    iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT
     
    ## Permettre à une connexion ouverte de recevoir du trafic en sortie.
     
    iptables -A OUTPUT -m state ! --state INVALID -j ACCEPT
     
    ## On accepte la boucle locale en entrée.
     
    iptables -I INPUT -i lo -j ACCEPT
     
    ## On log les paquets en entrée.
     
    iptables -A INPUT -j LOG
     
    ## On log les paquets forward.
     
    iptables -A FORWARD -j LOG 

# fLOOD ou déni de service 
iptables -A FORWARD -p tcp --syn -m limit --limit 1/second -j ACCEPT 
iptables -A FORWARD -p udp -m limit --limit 1/second -j ACCEPT 
iptables -A FORWARD -p icmp --icmp-type echo-request -m limit --limit 1/second -j ACCEPT 

#Scan de ports 
iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j ACCEPT

Lorsque je le teste avec nmap, j’ai les ports 80/tcp et 52869/tcp ouverts.
J’ai aussi fait plusieurs fois le test des ports sur zebulon.fr et les résultats du scan sont souvent différents. Une fois, j’ai 3 ports ouverts, une autre, j’en ai 2. Une autre fois, j’ai pratiquement tous les ports en stealth et l’autre fois, c’est tout le contraire, pratiquement tout est fermé mais pas en stealth.

Compliments,

#2

Il y a une question ?
Quelle est le rôle de cette machine, et sa position dans le réseau ?

#3

Bonjour,

Mon texte sous-entendait une question. Il m’étonne que vous ne l’ayez compris!!!:wink:
Ma question était celle-ci: les résultats du scan sur zebulon.fr ne sont jamais identiques et le logiciel nmap m’avertit que les ports 80 et 52869 sont ouverts. Dois-je m’en inquiéter?

J’ai un routeur et je me connecte parfois aux WIFI gratuits à l’extérieur. Je n’ai pas de serveur et je n’utilise pas l’IPV6. Je ne me sers de mon pc que pour surfer.

Salutations,

#4

Je ne prête pas attention aux sous-entendus ni à ce qui peut être ambigu ou sujet à interprétation dans les discussions technniques. Ces trucs sont bons pour la littérature ou la politique, pas pour la technique.

Si le scan de zebulon.fr est effectué alors que la machine est derrière un routeur NAT, alors c’est le routeur qui est la cible du scan et pas ta machine. La variation des résultats vient probablement du fait que la cible limite l’envoi des réponses aux paquets du scan, et que les paquets auxquels elle répond varient à chaque scan. En l’absence de réponse pour un port, le scanner considère le port “stealth”.

Depuis quelle machine nmap est-il exécuté et de quel type de scan s’agit-il ? Si c’est un scan TCP SYN (par défaut) exécuté depuis la machine cible elle-même, alors ton jeu de règles iptables laisse passer.

2 J'aime
#5

Bonjour,

Je suis effectivement derrière un routeur NAT.

La commande du scan que j’ai réalisée depuis la machine cible elle-même est celle-ci:

nmap -v ip_de_la_machine

J’ai essayé de savoir quels processus se cachaient derrière les ports 80/tcp et 52869/tcp en tapant ces commandes en root:

netstat -ltnp | grep ":80.*LISTEN"
netstat -ltnp | grep ":52869.*LISTEN"

Mais celles-ci n’ont donné aucune réponse.

Salutations,

#6

Quand une commande filtrée par grep ne retourne rien, on recommence sans le grep au cas où on se serait trompé dans le motif de recherche. netstat -lt ne peut retourner que des sockets dans l’état LISTEN, donc inutile compliquer l’expression pour filtrer dessus.

“ip_de_la_machine” représente bien l’adresse IP privée de la machine affichée par ip addr ou /sbin/ifconfig et non l’adresse IP publique visible de l’extérieur qui est en fait l’adresse IP du routeur ? Car dans le second cas, c’est le routeur que tu scannes, mais de l’intérieur.

1 J'aime
#7

Bonjour,

En fait, je m’étais trompé, je n’avais pas réalisé le scan nmap avec mon adresse privée!!
J’ai donc refait le scan et celui-ci m’a indiqué que j’avais 1 port ouvert et plusieurs ports fermés mais non stealth.

PORT     STATE  SERVICE
21/tcp   closed ftp
25/tcp   open   smtp
110/tcp  closed pop3
135/tcp  closed msrpc
199/tcp  closed smux
554/tcp  closed rtsp
587/tcp  closed submission
3306/tcp closed mysql
5900/tcp closed vnc
8080/tcp closed http-proxy

Voici le processus qui se cachait derrière le port ouvert:
sudo netstat -ltnp | grep ":25.LISTEN"
tcp 0 0 0.0.0.0:25 0.0.0.0: LISTEN 1616/master
tcp6 0 0 :::25 :::* LISTEN 1616/master

sudo netstat -lt 
Connexions Internet actives (seulement serveurs)
Proto Recv-Q Send-Q Adresse locale          Adresse distante        Etat           
tcp        0      0 localhost:9119          *:*                     LISTEN     
tcp        0      0 pauline:domain          *:*                     LISTEN     
tcp        0      0 localhost:domain        *:*                     LISTEN     
tcp        0      0 *:smtp                  *:*                     LISTEN        
tcp        0      0 localhost:8123          *:*                     LISTEN     
tcp6       0      0 [::]:smtp               [::]:*                  LISTEN  

sudo netstat -ltnp ":25.*LISTEN"
Connexions Internet actives (seulement serveurs)
Proto Recv-Q Send-Q Adresse locale          Adresse distante        Etat       PID/Program name     
tcp        0      0 127.0.0.1:9119          0.0.0.0:*               LISTEN      872/privoxy     
tcp        0      0 127.0.1.1:53            0.0.0.0:*               LISTEN      1449/dnsmasq    
tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      1134/dnsmasq    
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      1616/master            
tcp        0      0 127.0.0.1:8123          0.0.0.0:*               LISTEN      1094/polipo     
tcp6       0      0 :::25                   :::*                    LISTEN      1616/master

J’ai modifié la configuration de mon script iptables comme ceci:

#Réinitialiser les règles
iptables -F
iptables -X

# Dropper les scans XMAS et NULL.
iptables -A INPUT -p tcp --tcp-flags FIN,URG,PSH FIN,URG,PSH -j DROP
iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP

# Dropper silencieusement tous les paquets broadcastés.
iptables -A INPUT -m pkttype --pkt-type broadcast -j DROP

# Permettre tout le traffic loopback (lo0) traffic et bloquer tout le traffic vers 127/8 qui n'utilise pas lo0
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT ! -i lo -d 127.0.0.1/8 -j REJECT

#Permettre à une connexion déjà ouverte de recevoir du trafic : 
iptables -A INPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT

#Permettre à une connexion ouverte de recevoir du trafic en sortie.
iptables -A OUTPUT -m state ! --state INVALID -j ACCEPT

# Permettre ping
# Supprimer -m icmp --icmp-type 8 de cette ligne pour autoriser toutes les sortes d'icmp:
iptables -A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT


# log iptables 
iptables -A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7

# Rejeter tout le reste
iptables -A INPUT -j REJECT
iptables -A FORWARD -j REJECT

# fLOOD ou déni de service 
iptables -A FORWARD -p tcp --syn -m limit --limit 1/second -j ACCEPT 
iptables -A FORWARD -p udp -m limit --limit 1/second -j ACCEPT 
iptables -A FORWARD -p icmp --icmp-type echo-request -m limit --limit 1/second -j ACCEPT 

#Scan de ports 
iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j ACCEPT

Et maintenant, je n’ai plus de port ouvert mais j’ai toujours plusieurs ports fermés mais pas invisibles:
PORT STATE SERVICE
22/tcp closed ssh
110/tcp closed pop3
199/tcp closed smux
256/tcp closed fw1-secureremote
445/tcp closed microsoft-ds
993/tcp closed imaps
1723/tcp closed pptp
3306/tcp closed mysql
3389/tcp closed ms-wbt-server
8080/tcp closed http-proxy

Comment les mettre en stealth?

Cordialement,

#8

Quoiqu’il arrive, pour le protocole TCP, il n’y a aucune possibilité de furtivité / stealth.

En effet :

  • Soit un port est ouvert et donc indiqué “open”.
  • Soit il est fermé (après réception en réponse d’un paquet avec le flag RST) donc “closed”.
  • Soit il ne répond pas et est indiqué par Nmap comme étant “filtered”.

Nan, parce-que en fait, dans ce que tu nous montres, tu as oublié la ligne du genre :
Not shown: 65533 filtered ports

Mais, j’insiste, “filtered” ≠ stealth.

De toutes les manières, le résultat de la commande nmap que tu nous donnes, manifestement, ne concerne pas ta machine. Si c’était bien ta machine, la règle iptables -A INPUT -j REJECT renverrait des paquets ICMP avec l’erreur port-unreachable et Nmap indiquerait les ports en tant que “filtered”.

Cela pourrait s’expliquer si tu étais connecté chez Free avec du SNAT A+P . Il faudrait alors demander une adresse IPv4 fixe dédiée à ton usage propre.

Cela pourrait également s’expliquer si la machine à l’origine du scan avec Nmap était elle aussi dotée d’un pare-feu qui interférerait dans les résultats.

–
AnonymousCoward

#9

Je pense que c’est le démon SMTP de postfix (serveur de mail).

netstat montre que ta machine écoute aussi sur d’autres ports, mais uniquement sur des adresses de loopback 127.*, donc un scan de l’adresse LAN ne les trouvera pas.

Je t’ai déjà répondu que si tu fais le scan depuis la machine elle-même, les règles iptables, et notamment celle-ci :

# Permettre tout le traffic loopback (lo0) traffic et bloquer tout le traffic vers 127/8 qui n'utilise pas lo0
iptables -A INPUT -i lo -j ACCEPT

laissent passer tous les paquets sur l’interface de loopback envoyés de la machine à elle-même. Les règles précédentent ne bloquent que les paquets invalides de types de scan TCP particuliers, pas les paquets normaux d’un scan TCP de type SYN (type par défaut).

Si tu veux tester l’efficacité de tes règles, il faut le faire depuis une autre machine sur le même réseau local et qui n’a pas de règles iptables.

Par contre, je ne comprends pas pourquoi les ports “closed” ci-dessus sont affichés alors que tous les ports scannés à l’exception du port 25 devraient être “closed”. Aucune règle de ce jeu ne bloque un scan SYN sur l’interface de loopback, donc aucun port ne devrait être “filtered”. Je viens de le tester sur ma machine.

#10

Tiens donc ? Et la différence entre REJECT et DROP ?

C’est ce dernier cas (ce que fait la cible DROP d’iptables) qui correspond à “stealth”. Mais tu as oublié un cas :

  • Soit un pare-feu répond avec un message d’erreur ICMP (ce que fait la cible REJECT d’iptables) et le port est indiqué par nmap comme étant “filtered” aussi.

Pour différencier les différentes causes de l’état “filtered”, on peut ajouter l’option --reason à la commande nmap.

Pas si le scan est effectué depuis la machine elle-même.
En fait tu connaissais ce 4e cas mais tu ne l’as pas listé avec les autres…

#11

Bonsoir,

J’ai remanié le script et il est réglé “normalement” pour se connecter à internet indépendamment, sans réseau local. De serveur, je n’en ai pas. Tout ce que je veux, c’est pouvoir me connecter à internet chez moi (à mon routeur) et à des WiFi gratuits tout en étant bien protégée et invisible sur le réseau.

Voici le script:

    iptables -t filter -F
    iptables -t filter -X
    iptables -t filter -P INPUT DROP
    iptables -t filter -P FORWARD DROP
    iptables -t filter -P OUTPUT DROP
    iptables -t filter -A INPUT -o lo -s 0.0.0.0/0 -d 0.0.0.0/0 -j ACCEPT
    iptables -t filter -A OUPUT -o lo -s 0.0.0.0/0 -d 0.0.0.0/0 -j ACCEPT
    iptables -A OUTPUT -p icmp -m conntrack --ctstate NEW,ESTABLISHED,RELATED -j ACCEPT
    #la règle suivante ne fonctionne pas (je n'ai plus de connection internet). Pouvez-vous m'en donner la raison et si vous le voulez bien la modifier?
    iptables -A INPUT --protocol tcp --tcp-flags ALL SYN,ACK -j DROP
###

   ` iptables -A INPUT -m pkttype --pkt-type broadcast -j DROP`
    modprobe ip-conntrack
    iptables -t filter -A INPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT
    iptables -t filter -A OUTPUT -m state ! --state INVALID -j ACCEPT
    # ouverture d'un port (ex: 110)
    iptables -t filter -A INPUT -s 192.168.0.0/24 --dport 110 -j ACCEPT
    iptables -t filter -A INPUT -s 192.168.0.0/24 --sport 110 -j ACCEPT
    # log iptables 
    iptables -A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7
    ## Je ne dois pas mettre les règles suivantes puisque je n'ai pas de serveur. Est-ce exact?

    iptables -A FORWARD -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT
    # fLOOD ou déni de service 
    iptables -A FORWARD -p tcp --syn -m limit --limit 1/second -j ACCEPT 
    iptables -A FORWARD -p udp -m limit --limit 1/second -j ACCEPT 
    iptables -A FORWARD -p icmp --icmp-type echo-request -m limit --limit 1/second -j ACCEPT 
    #Scan de ports 
    iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j ACCEPT

Que pensez-vous du script?
D’après certaines personnes, on doit créer un chaîne définie, appelée "filter"pour pouvoir utiliser “-t filter”. Quelle chaîne dois-je alors ajouter?
Pourriez-vous m’aider à corriger les problèmes car je suis un peu perdue en lisant toutes les informations contradictoires sur le web?

Merci.

#12

Euhhh, y’a quelqu’un pour lui dire que c’est un “doux rêve” ?!

J’ai le sentiment que vous ne comprenez pas pleinement comment fonctionne les couches réseaux.

Plus simplement :

iptables -t filter -A OUPUT -o lo -j ACCEPT

Mais comme tu l’exprimes …

Il me semble vraiment nécessaire de partir sur des bases saines … et de consulter notre post à-propos d’iptables, publié dans notre forum “Trucs & Astuces”.
Et, @PascalHambourg est bien mieux “placé” pour vous indiquer de la lecture de référence, à-propos des réseaux.

#13

Présent ! (pour la partie “invisible”)

Quand on se connecte à une box ou à un réseau wifi, il y a toujours un réseau local. Le seul cas où on peut dire qu’il n’y a pas de réseau local, c’est avec une connexion de type “dial-up” point à point utilisant le protocole PPP à travers un simple modem.

iptables -t filter -A INPUT -o lo -s 0.0.0.0/0 -d 0.0.0.0/0 -j ACCEPT

Règle invalide : l’option -o (pour spécifier l’interface de sortie) est invalide dans la chaîne INPUT, fort logiquement. Utiliser -i pour spécifier l’interface d’entrée.

#la règle suivante ne fonctionne pas (je n'ai plus de connection internet). Pouvez-vous m'en donner la raison et si vous le voulez bien la modifier?
iptables -A INPUT --protocol tcp --tcp-flags ALL SYN,ACK -j DROP

Elle bloque les paquets TCP entrants qui ont uniquement les drapeaux SYN et ACK activés. Or cette configuration correspond au premier paquet de réponse renvoyé par un serveur pour accepter une demande de connexion. Si on le bloque, on bloque l’établissement de la connexion.
Quel était le but de cette règle ?

iptables -t filter -A INPUT -s 192.168.0.0/24 --dport 110 -j ACCEPT
iptables -t filter -A INPUT -s 192.168.0.0/24 --sport 110 -j ACCEPT

Je croyais qu’il n’y avait pas de réseau local. A quoi servent ces règles alors, puisque ces adresses sont typiquement utilisées sur un réseau local ?

La chaîne FORWARD n’a rien à voir avec le fonctionnement en serveur de la machine mais avec le fonctionnement en routeur. Si ip_forward=0 (fonctionnement non routeur), alors elle n’est pas utilisée et peu importe les règles qu’elle contient.

1 J'aime
#14

J’avais même pas vu, au petit matin … il faut espérer que c’est une faute de doigt !

Exactement !
Je vais chipoter : par tout service, utilisant le protocol TCP, sur toute machine connecté à un réseau. En fait, il vous faut comprendre que c’est là, le fonctionnement du protocol TCP.

La machine, normalement, envoie une première demande de connexion, ayant le drapeau SYN, à un service basé sur le protocole TCP - par exemple, un service web, sur le port 80.
Le service correspondant lui renvoie un drapeau SYN+ACK, pour lui dire qu’il accepte la communication …
Puis, la première machine envoie, en confirmation, un drapeau ACK .
C’est la fameuse “poignée à 3 mains”.

Donc, bloquer SYN/ACK est une inepsie, si on veut pouvoir communiquer sur un réseau.
Puisque la machine doit recevoir en entrée les réponses à ses demandes de communication sur le protocole TCP.

De la raison de la règle “maintenir une connexion établie” que vous avez sur le “tutoriel de base” que nous proposons …

Et, idem, pour la sortie qui en a aussi besoin.

#15

Bonsoir,

Merci de me libérer de mes doux rêves! Les règles ne peuvent être connues que si on nous les apprend. Malheureusement, toutes les explications sont floues sur Internet.

Si je décide quand même de créer des règles iptables spécifiques pour me connecter à mon réseau local personnel, puis-je faire de même pour un réseau local d’un WiFi gratuit? Est-ce un risque de sécurité?

Exemple: ouverture du port 110

Chez moi, j’aurais:

iptables -t filter -A INPUT -s 192.168.0.0/24 --dport 110 -j ACCEPT
iptables -t filter -A INPUT -s 192.168.0.0/24 --sport 110 -j ACCEPT

Pour le WiFi gratuit, est-ce risqué d’avoir ce genre de règles? Ne devrais-je pas plutôt avoir:

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

Merci.

#16

Avez vous lu notre “tutoriel” ?

Et, floues … avez-vous lu la très bonne documentation de l’inet.

#17

Que veux-tu dire exactement par “me connecter à mon réseau local” ? Accéder à des services sur des machines du réseau local ? Offrir des services à des machines du réseau local ?
Toute règle qui autorise des communications dans un environnement non protégé est potentiellement un risque de sécurité.

La première règle permet aux machines du sous-réseau 192.168.0.0/24 d’accéder à un serveur POP3 qui tourne sur la machine.
La seconde leur permet d’accéder à n’importe quel port TCP de la machine du moment qu’elles utilisent le port source 110. Mauvaise idée.

La règle dans INPUT est encore plus permissive que la précédente puisqu’elle n’est pas limitée au sous-réseau 192.168.0.0/24.
La seconde permet à la machine d’accéder à un serveur POP3 distant, mais elle est redondante puisqu’il y a déjà dans le script une règle qui accepte les paquets sortants qui ont un état de connexion valide :
iptables -t filter -A OUTPUT -m state ! --state INVALID -j ACCEPT

1 J'aime
#18

Bonsoir,

Merci.
Je comprends mieux pour ce qui est du réseau local.

Maintenant je ne veux ni me connecter à des PCs ni que des PCs puissent se connecter à ma machine.
Mais je veux que mon pc puisse utiliser le logiciel bittorrent, je dois ouvrir le port 6881 tcp, non?
Quelle règle dois-je inscrire pour que seul mon pc puisse accéder au port 6881tcp?

Je sais que je ne cesse de poser des questions mais j’ai envie d’apprendre.:slight_smile:

#19

Tu te rends compte que ces deux demandes sont contradictoires ? Je ne connais pas en détail le fonctionnement de BitTorrent ni son utilisation de ce port 6881, mais c’est un logiciel de peer-to-peer, dont le principe est précisément de se connecter à d’autres PC et de recevoir des connexions d’autres PC.

#20

Se poser des question et avoir envie d’apprendre, c’est très bien …
Par contre, permettez-moi d’en douter - de par le fait qu’apparemment vous n’avez lu aucun des liens que je vous ai fournis, n’est-ce pas !?

Personnellement, j’abandonne et vous souhaite bon courage.