[Resolu] Iptables: problèmes de règles

Salut à tous,

Dans la soirée d’hier, j’ai voulu me mettre à iptables afin de mieux connaître et biensûr de sécuriser un peu plus ma machine car actuellement je n’ai aucune protection (si ce n’est linux lui-même, ça compte ? :stuck_out_tongue:), ma freebox n’est pas en mode routeur. Je pense que c’est mieux de faire appel à netfilter pour le trafic sortant en fait (dites-moi si ce n’est pas le cas).

Bref, sinon ma carte ethernet est eth2, et la freebox eth0 j’imagine, j’utilise iptables 1.3.6.0, et un noyau 2.6.18, juste au cas où c’est dit. :smt002

Donc j’ai lu quelques tutoriaux sur le sujet, j’essaye de m’inspirer de celui de ricardo “Pour les nuls”, et en même temps celui-ci: olivieraj.free.fr/fr/linux/infor … ml#III-6-2

Et même celui-là: glatozen.org/freebox.php

Le problème c’est que j’arrive à quelque chose qui fonctionne je pense, mais j’ai bien peur qu’il ne serve à rien…

Voici le script:

iptables -t filter -F


iptables -t filter -X

iptables -t filter -P INPUT DROP
iptables -t filter -P OUTPUT DROP
iptables -t filter -P FORWARD DROP

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

iptables -A OUTPUT -o lo -j ACCEPT
iptables -A INPUT  -i lo -j ACCEPT

iptables -A OUTPUT -o eth2 -m state --state NEW -j ACCEPT
iptables -A INPUT  -i eth2 -m state --state NEW -j ACCEPT
iptables -A FORWARD -i eth2 -j ACCEPT
iptables -A FORWARD -o eth2 -j ACCEPT


# HTTP (80/TCP)  et HTTPS (443/TCP)
iptables -A OUTPUT -o eth0 -p tcp --dport 80  -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp --dport 443 -j ACCEPT
iptables -A INPUT  -i eth0 -p tcp --sport 80  -j ACCEPT
iptables -A INPUT  -i eth0 -p tcp --sport 443 -j ACCEPT

Mais j’ai l’impression en gros de lui dire au début de tout refuser, puis de tout accepter avec: iptables -A OUTPUT -o eth2 -m state --state NEW -j ACCEPT iptables -A INPUT -i eth2 -m state --state NEW -j ACCEPT iptables -A FORWARD -i eth2 -j ACCEPT iptables -A FORWARD -o eth2 -j ACCEPT

Donc voilà en gros j’ai l’impression d’être toujours aussi vulnérable :confused:

J’ai une autre question également, j’ai essayé hier également de faire en sorte que nmap ne puisse plus rien voir, comme ici sur le site:

[code][intrus@pirate /]# nmap phoenix1.internet.net

Starting nmap V. 3.00 ( www.insecure.org/nmap/ )
Note: Host seems down. If it is really up, but blocking our ping probes, try -P0
Nmap run completed – 1 IP address (0 hosts up) scanned in 30 seconds[/code]

Seulement lorsque j’y arrivais, je n’avais plus accès à rien :smiley:

J’imagine que ce n’est pas bien difficile et que je passe pour un nul, mais je n’y arrive pas… P’tet que ça fait trop d’un coup pour mon petit cerveau!

En tout cas, si vous pouviez m’aider à ne serait-ce qu’à mieux comprendre parce-que de toute évidence j’ai loupé un épisode :laughing:

Merci d’avance!

Edit: ah, je viens de regarder du côté d’ifconfig, voici ce qu’il renvoie:

[code]eth2 Lien encap:Ethernet HWaddr 00:01:29:D4:7A:E4
inet adr:...** Bcast:...** Masque:255.255.255.0
adr inet6: fe80::201:29ff:fed4:7ae4/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:8106 errors:0 dropped:0 overruns:0 frame:0
TX packets:9374 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:4582920 (4.3 MiB) TX bytes:2209622 (2.1 MiB)
Interruption:19

lo Lien encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
adr inet6: ::1/128 Scope:Hôte
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:9288 errors:0 dropped:0 overruns:0 frame:0
TX packets:9288 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:390640 (381.4 KiB) TX bytes:390640 (381.4 KiB)
[/code]

hello
tuto: http://www.linux-france.org/prj/inetdoc/guides/iptables-tutorial/

[code]
iptables -A OUTPUT -o eth2 -m state --state NEW -j ACCEPT

iptables -A INPUT -i eth2 -m state --state NEW -j ACCEPT

iptables -A FORWARD -i eth2 -j ACCEPT

iptables -A FORWARD -o eth2 -j ACCEPT[/code]

la sa peut convenir a fordward derrière enfin si c’ est dirigez sur un autre pc/interface, si il y a rien, mettre a drop seulement

NEW tolère les nouvelle connections. donc en input sa ne devrai pas y être a par peut être sur le port 53.
en sortie sa doit y être par contre.

en faite tout doit être drop avec la police par defaut a drop ,puits dedans tu filtre avec

pourt output

il te manque l’icpm et l’ipv6 mai bon sa il faut creuser car sa change tout le temps.

tu peux aussi filtrer par utilisateur, ce que je fait. après tu peux t’amuser un bon moment avec iptables

je peux dire que j’ai fait le tour et c’est pas évidant,surtout avec iproute !

l’idéal c est aussi de filtrer par ip en + des port par exemple pour les mail ,voire les adresse mac en +

de cette manière tu sais exactement ce ce passe. je te conseil d’utiliser ulog (a installer) pour loguer

plutôt ce qui est par default!

si tu veux les detail en live , dans une console c’est tail -f /var/log/tonfichierlog

Bien ! :slightly_smiling:

Bien sûr ça compte. Un ami avait mis en place un serveur dédié de jeu sous Debian sans protection par iptables, malgré mes conseils. Seuls les services nécessaires étaient installés, correctement configurés et régulièrement mis à jour. La machine n’a jamais été compromise.

Ce n’est pas une mauvaise idée de filtrer aussi le trafic sortant, car en cas de compromission non root cela peut empêcher la machine d’être transformée en relais de spam ou d’attaques diverses (et avariées). Mais c’est aussi plus délicat, il faut savoir ce qu’on fait et de quoi on a besoin pour ne pas se bloquer soi-même. Par exemple même pour du simple surf web on a généralement besoin de faire des requêtes DNS, ce que ton jeu de règles ne prévoit pas.

De manière générale, avant de commencer à pisser des règles iptables il importe de définir un cahier des charge de tout ce qui doit être accepté, bloqué ou rejeté en entrée, en sortie, pour chaque interface… Ensuite il faut traduire ce cahier des charges en règles iptables, sachant qu’il est généralement exprimé en terme de “connexions” (flux bidirectionnels de paquets homogènes) alors que les règles iptables s’appliquent à des paquets individuels.

Comment ça ? Ta machine a deux interfaces ? Reliées à quoi ?

Oui, seuls les paquets dans l’état INVALID (à ne pas confondre avec les paquets invalides) sont bloqués. Toutes les connexions entrantes et sortantes sont acceptées.

Note : Si la machine ne sert pas de routeur/passerelle, pas besoin de règles dans la chaîne FORWARD.

Quant à nmap, c’est simple : si toutes les connexions entrantes sont bloquées, il ne verra rien.

Ok, merci pour le tuto, j’en ai de partout là :laughing:

Ok, non je crois pas, je laisse les règles DROP du début donc

[quote]NEW tolère les nouvelle connections. donc en input sa ne devrai pas y être a par peut être sur le port 53.
en sortie sa doit y être par contre.[/quote]

Voilà peut-être pourquoi j’ai l’impression de laisser tout passer :laughing:
Par contre pour le port 53, je peux faire une règle comme pour le port 80 ou c’est quelque chose de spécifique ?

Et ces règles, je dois les faire sur l’interface eth2 non ? J’ai mis ça sur eth0 parce-que je pensais que cela correspondait à quelque chose chez moi mais je n’en suis plus sûr…

Pour Ulog, ça me tente bien ouais, merci je regarderais ça une fois que j’aurais un script qui sera sûr :slightly_smiling:

Hum ok, mais un cahier des charges, je sais pas, je n’ai vraiment pas grand chose c’est une machine perso qui me sert a surfer et quelques petits autres trucs simples :slightly_smiling:

Non en fait elle est reliée à la freebox mais qui n’est pas en mode routeur

Donc à partir du moment où j’ouvre ne serait-ce que le port 80 avec iptables -A INPUT -i eth2 -p tcp --sport 80 -j ACCEPT, il m’est impossible de faire “le mort” ? :mrgreen:

Merci pour vos réponses :smiley:

iptables-save

donne quoi ?

C’est similaire, mais les requêtes DNS utilisent généralement UDP, et TCP seulement dans des cas particuliers.

Oui. A la limite tu peux ne pas spécifier d’interface (sauf dans les règles spécifiques à l’interface de loopback lo).

Alors il suffit d’énumérer tous ces trucs simples et leurs implications en terme de flux réseau.

En effet, et c’est même pire que ça : cette règle donne accès à tous tes ports TCP à partir du moment où l’attaquant utilise le port source 80 (vieille ruse bien connue, il y a la même en UDP avec le port 53). Ce genre de règle est à bannir absolument, ce n’est pas pour rien qu’on a inventé le suivi de connexion !

Un petit exemple de ce que pourrait être un jeu de règles simple :

# nettoyage
iptables -F
iptables -X

# politiques par défaut : on bloque tout
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

# accepte les paquets appartenant ou lies à des connexions existantes (donc deja acceptees)
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# accepte le trafic local à la machine
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A INPUT  -i lo -j ACCEPT

# connexions acceptees en sortie

# requetes DNS (53/UDP et 53/TCP)
iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 53 -j ACCEPT

# HTTP (80/TCP)  et HTTPS (443/TCP)
iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 443 -j ACCEPT

# requête ping (ICMP echo)
#iptables -A OUTPUT -p icmp --icmp-type echo-request -j ACCEPT

# connexions acceptees en entree

# (exemple)
# iptables -A INPUT -p <protocole> --dport <port> -j ACCEPT

Il y a mieux mais c’est plus cher :mrgreen: (et pas forcément beaucoup plus utile).

salut ricardo, iptables-save donne:

[code]# iptables-save

Generated by iptables-save v1.3.6 on Wed Feb 27 13:16:14 2008

*filter
:INPUT DROP [2:112]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -i eth2 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i eth2 -p tcp -m tcp --sport 80 -j ACCEPT
-A INPUT -i eth2 -p tcp -m tcp --sport 443 -j ACCEPT
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -o eth2 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -o eth2 -p tcp -m tcp --dport 80 -j ACCEPT
-A OUTPUT -o eth2 -p tcp -m tcp --dport 443 -j ACCEPT
COMMIT

Completed on Wed Feb 27 13:16:14 2008[/code]

@PascalHambourg: En effet il a l’air bien sympa ton script, et il fonctionne :stuck_out_tongue:

Du coup avec, iptables-save me donne:

[code]iptables-save

Generated by iptables-save v1.3.6 on Wed Feb 27 13:23:17 2008

*filter
:INPUT DROP [1:105]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -p udp -m udp --dport 53 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 53 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 443 -j ACCEPT
COMMIT

Completed on Wed Feb 27 13:23:17 2008

[/code]

En tout cas merci de la précision en ce qui concerne le port 80 :stuck_out_tongue:

Donc là je suis en train d’effectuer des semblants d’intrusions et sur PC Flank, j’obtiens deux bons points mais pour le Browser:

[quote]Browser privacy check
The test checked if your web browser reveals any private information while you visit Web sites. Usually such information is: the last site visited, your locale and who your Internet Service Provider is.
Danger!
While visiting web sites your browser reveals private information about you and your computer. It sends information about previous sites you have visited. It may also save special cookies on your hard drive that have the purpose of directing advertising or finding out your habits while web surfing.
Recommendation:
We advise you to get personal firewall software. If you already have a firewall program adjust it to block the distribution of such information.[/quote]

J’imagine que ce n’est pas très grave. Sinon je viens de tester sur le même site ainsi que sur ShieldsUP! et les ports sont bien “Stealth” et plus “closed”, donc ça fonctionne bien! Merci :wink:

Oui, et il va maintenant falloir que je cherche les ports qu’utilisent les petits trucs comme kopete :smiley:

en tout cas merci!

Le message exagérément alarmant du site contient une bonne part de FUD. Ce qui est décrit comme un danger potentiel est normal. De toute façon iptables ne peut rien y faire. Quant à cette mode du “stealth”, je préfère ne pas dire ce que j’en pense. Il y a des moyens de savoir qu’une machine est là même si elle ne répond à aucune sollicitation IP.

Ouais j’imagine, c’était juste histoire de constater une différence :laughing:

Par contre j’ai encore un problème… (je sais, je sais) J’ai rentré les règles pour le port FTP, et donc j’arrive à me connecter a mon ftp free.fr, seulement c’est super lent…

Par contre pas moyen d’atteindre le ftp interne de ma box HD. :confused:

Je les retournes dans tous les sens ces règles, mais pas moyen, il dit connexion réussie mais je ne vois rien :frowning: Puis un message apparaît “Impossible d’entrer dans le dossier” (sous Krusader).

Mais il y a un truc que je n’arrive pas à cerner, c’est les --dport et --sport, dans le tuto de ricardo il utilise dport pour les entrants et dans l’autre tuto le redacteur utilise --sport.

Ca va être sport… :mrgreen:

Quelles règles ?

Certains protocoles “complexes” comme FTP mettent en jeu des connexions sur des ports dynamiques et ont besoin d’une prise en charge spéciale (“helper”) pour le suivi de connexion et le NAT.
Essaie ça, ça devrait mieux marcher après :

modprobe ip_conntrack_ftp ou modprobe nf_conntrack_ftp selon les options de compilation du noyau.

–sport spécifie le port ou la plage de ports source d’un paquet.
–dport spécifie le port ou la plage de ports destination d’un paquet.

Généralement lors de la communication entre un client et un serveur, le client envoie les requêtes avec un port source quelconque et un port destination fixe selon le service (ex: HTTP=80/TCP, DNS=53/UDP ou TCP…). Le serveur répond en inversant les ports source et destination.
Lorsqu’on veut contrôler à quels service on veut donner accès aussi bien en entrée qu’en sortie, on se base sur le port destination de la requête. Le port source de la requête, on s’en fiche un peu puisqu’il est quelconque. Les ports source et destination de la réponse, on s’en fiche aussi puisque c’est le suivi de connexion qui s’en occupe (état ESTABLISHED ou RELATED).
Si un paquet TCP avec le port source 80 a l’état de suivi de connexion ESTABLISHED, c’est qu’il s’agit d’une réponse à une requête qui a été acceptée, et il convient de l’accepter aussi. L’information importante n’est pas tant le port source que l’état de suivi de connexion. En tout cas le port source seul ne suffit pas.

Bein, j’avais commencé par mettre un iptables -A OUTPUT -p tcp --dport 21 -j ACCEPT

J’ai ensuite fais pareil en input, j’ai même ouvert l’udp 21 au point où j’en étais et même le port 20, puis j’ai abandonné avec ça iptables -A OUTPUT -p udp --dport 21 -j ACCEPT iptables -A OUTPUT -p tcp --dport 21 -j ACCEPT iptables -A OUTPUT -p udp --dport 20 -j ACCEPT iptables -A OUTPUT -p tcp --dport 20 -j ACCEPT

En INPUT, même chose, j’ai essayé tout et n’importe quoi, rien à faire…

J’vais essayer le coup du mobprobe, merci :smt002

Edit: Avec ce que j’ai + la solution du mobprobe, ça fonctionne (ça a l’air en tout cas) :slightly_smiling: merci bien, c’est au poil!

Edit2: Ah bah oui ils en parlent juste après dans le tuto :laughing:

C’est en effet la seule règle nécessaire pour le FTP, à condition d’avoir chargé le module de suivi de connexion FTP. Je vois que ça commence à rentrer. :slightly_smiling:

Sans le module de suivi de connexion FTP, la seule règle qui aurait pu être utile est celle acceptant le port source 20 (ftp-data) en entrée, caractéristique d’une connexion de données FTP en mode actif :

Mais cette règle a le même gros inconvénient que celle acceptant le port source 80 en entrée : c’est une passoire qui laisse passer n’importe quelle connexion entrante à partir du moment où l’attaquant utilise le port source 20. D’où l’intérêt du module de suivi de connexion FTP, qui reconnaît et marque dans l’état RELATED le premier paquet d’une connexion de données (listage de répertoire ou transfert de fichier) liée à une connexion de contrôle FTP existante, quels que soient les ports source et destination.

Note :
Ajouter des règles au petit bonheur la chance en espérant que ça finira par marcher n’est pas la bonne méthode. Au pire, ça peut créer des gros trous dans le pare-feu. La première chose à faire est se renseigner sur le fonctionnement du protocole à laisser passer. Si ça ne suffit pas, il faut examiner les caractéristiques des paquets indûment bloqués avec un logiciel de capture réseau ou avec la cible LOG dans des règles iptables.

[quote]Note :
Ajouter des règles au petit bonheur la chance en espérant que ça finira par marcher n’est pas la bonne méthode. Au pire, ça peut créer des gros trous dans le pare-feu. La première chose à faire est se renseigner sur le fonctionnement du protocole à laisser passer. Si ça ne suffit pas, il faut examiner les caractéristiques des paquets indûment bloqués avec un logiciel de capture réseau ou avec la cible LOG dans des règles iptables.[/quote]

Ouais c’est justement ce qu’il me faut, je vais justement essayer tcpdump, j’espère que ça va le faire.

Merci :smt002