Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Règles iptables trop imperméable

nam1962

@pires, pour un serveur je comprends, mais pour un desktop ?

pires57

de quel post tu parles nam? je suppose de mon premier sur ce topic? si c'est pour apprendre cela peut toujours être intéressant bien qu'il n'y aura aucune utilité étant donnée que la box intégre déja son firewall, on est tout a fait d'accord

Pator75

pires57 a écritNon Pator75 tout dépend de ta manière de le configurer, si tu mets un drop au début suivit d'un accept sur le port 80 il n'y auras que ce port d'autorisé.

Salut,

Un DROP suivi d'un ACCEPT et plus rien ne passe? il me manque des infos là, ça me semble clairement une erreur de conception, tous les firewalls non Iptables ne fonctionnent pas comme ça.

Pator75

"J'aime mettre tout en DROP et ensuite mettre des ACCEPT".

Je ne comprends pas le sens des règles d'Iptables, pourtant le nouveau GUFW permet de modifier son ordre, peut être que le sens est de bas en haut pour la priorité.

"Quelles étaient tes règles exactes avec GUFW stp ? Que chacun puisse le reproduire chez lui merci, merci aussi d'indiquer comment tu avais mis le "journal complet" comme tu l'appelles. Car je n'ai jamais remarqué cela avec mes règles brutes via iptables, je le répète."

GUFW je ne modifie que les règles ICMP, je ne garde que "destination inaccessible", pour le journal tu vas (de mémoire) dans édition > préférences.

pires57

Si tu drop tout les port mais que tu viens mettre une règle accept sur le port 80 seul ce port sera autorisé, c'est pas compliqué a comprendre

Pator75

pires57 a écritSi tu drop tout les port mais que tu viens mettre une règle accept sur le port 80 seul ce port sera autorisé, c'est pas compliqué a comprendre

Pour moi, c'est toi qui ne comprends pas, n'en parlons plus.

bruno

@Pator75 : c'est parce que (apparemment) tu ne comprends pas le fonctionnement d'iptables. Les règles sont appliqués les unes après les autres, dans l'ordre, de la première à la dernière.
Donc on commence par tout bloquer (DROP sur tout ce qui entre) et on autorise ensuite un service, une ip, un bvloc d'ip, etc.

EDIT: je me rend compte que ce que j'ai écrit n'est pas clair : les règles sont appliquées dans l'ordre où elles ont été placées, la dernière règle prenant toujours le pas sur la précédente.

Pator75

bruno a écrit@Pator75 : c'est parce que (apparemment) tu ne comprends pas le fonctionnement d'iptables. Les règles sont appliqués les unes après les autres, dans l'ordre, de la première à la dernière.

Je sais, c'est pour ça que j'en parle.

bruno

C'est un principe de base en matière de sécurité, et cela n'a rien de spécifique à iptables : on commence par tout interdire et on autorise ensuite au coup par coup, jamais l'inverse.

Pator75

bruno a écritC'est un principe de base en matière de sécurité, et cela n'a rien de spécifique à iptables : on commence par tout interdire et on autorise ensuite au coup par coup, jamais l'inverse.

Non, ailleurs que chez Iptables, on commence par autoriser, limiter, ou bloquer, puis on fait une règle "bloque le reste" placée à la fin.

Haleth

Inutile voir néfaste.

Pator75

Haleth a écritInutile voir néfaste.

Merci pour la réponse, mais pas d'accord, la vraie réponse est dans Iptables, quelles sont les différences avec du filtrage réseau Windows? j'ai commencé par chercher, pour l'instant je ne vois rien, chez Linux on peut trouver de l'info au niveau des hooks sur le noyau, mais chez Windows tintin, ça ne va pas être facile pour trouver ce qui diffère, pour moi, chez Iptables, un flux doit commencer par les règles du bas et remonter la pile, ce qui explique les DROP en premier.

bruno

@Pator75: où ça ailleurs que chez iptables ? Parce que des pare-feux qui fonctionnent à l'inverse de la logique la plus élémentaire je n'en ai jamais vu, ni sous Linux, ni sous BSD, ni ailleurs.

_Raum_

@bruno:
Alors non ce n'est pas tout à fait exact... Pator non plus n'a pas raison 🙂

La première règle que l'on trouve en général dans un script de pare feu est la configuration de "la politique" de la chaîne.

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

C'est une politique, pas une "règle". Il s'agit d'un principe restrictif : "tout est interdit sauf ce qui est explicitement autorisé".

Ensuite, on ajoute des règles pour autoriser.

La dernière règle que l'on trouve souvent dans les scripts ne sert qu'à des fins de logs.... mais on pourrait la supprimer, cela ne changerait rien à la politique liée à la chaîne. On la met à la fin car le pare feu passe toutes les règles jusqu'à en trouver une qui fonctionne... donc si tu veux logguer toutes les tentatives, eh bien tu mets ça en dernier... pour pas bloquer des trafics légitimes.

Haleth

Ce qui est inutile, voire néfaste, est cette configuration d'iptables, telle que décrite dans ce post.

Si tu te trouve derrière une box, la mise en place d'iptable et inutile

Faux.
La vérité est plus proche, pour 95% des gens, de ceci:

La mise en place d'iptable et inutile

Pator75

_Raum_ a écrit C'est une politique, pas une "règle". Il s'agit d'un principe restrictif : "tout est interdit sauf ce qui est explicitement autorisé".
Ensuite, on ajoute des règles pour autoriser.
La dernière règle que l'on trouve souvent dans les scripts ne sert qu'à des fins de logs.... mais on pourrait la supprimer, cela ne changerait rien à la politique liée à la chaîne. On la met à la fin car le pare feu passe toutes les règles jusqu'à en trouver une qui fonctionne... donc si tu veux logguer toutes les tentatives, eh bien tu mets ça en dernier... pour pas bloquer des trafics légitimes.

Salut, moi je n'ai pas parlé de politiques, mais de listes de règles (IN OUT...) par rapport à ce qu'a avancé Fruits,

"Je n'aime pas mettre tout en ACCEPT et ensuite faire mes règles avec des DROP"
Mais il voulait dire ça :
"J'aime mettre tout en DROP et ensuite mettre des ACCEPT".

UbNeBe

Je suis tout à fait d'accord avec toi _Raum_

Pour moi la politique correspond à :
. si le paquet que tu traites n'est validé par aucune règle
. => alors tu DROP (ou ACCEPT) ce paquet (en fonction de la politique choisie).

Oui, je sais, il m'arrive de parler à Netfilter comme à un ami, même si c'est un peu cavalier 😃

C'est flagrant lorsqu'à la fin il y a du log : tu ne retrouves que ce qui a été bloqué (pour une politique de DROP bien sûr). Je l'ai constaté d'autant plus que lorsque mes règles étaient tellement restrictives que rien ne passait et que tout se retrouvait dans le log. Ce qui prouve que Netfilter lit les règles de haut en bas !

@fruitsecrases :
Je veux bien ton iptables pdf 😉 Dis moi comment procéder.
Merci pour toute cette lecture (je n'ai pas encore fini).

@_Raum_ :
Où et comment log tu tes paquets bloqués ? Dans syslog ?

_Raum_

Euh alors en fait ça me sort sur la console et dans le fichier local syslog, pour un usage à la maison, ça me va.

J'utilise Firewall Builder puor gérer mes règles que je pousse en ssh depuis cet outil.

Philippeditlegros

Pator75 a écrit
fruitsecrases a écrit
UbNeBe a écrit Par contre mettre un DROP après des ACCEPT je trouve ça nul, ça pourrait laisser des paquets passés qui aurait pu être bloqués si l'ordre avait été mieux établi.
Je viens de donner le lien dans une autre discussion, mais il pourrait aussi t'intéresser car les réglages de pare-feu Iptables qu'il applique sont celles que tu aimes, tout en DROP et ensuite des trucs en ACCEPT, à plus :
http://irp.nain-t.net/doku.php/130netfilter:060_iptables

Salut,

Pas tout suivi, surtout qu'Iptables ne m'intéresse pas trop pour l'instant, mais à propos de "Par contre mettre un DROP après des ACCEPT je trouve ça nul", je pense qu'il faut aussi expliquer, et ce n'est pas uniquement propre à Iptables, qu'il y a un sens dans les règles, en général c'est de haut en bas, donc la première est acceptée si ACCEPT, les suivantes dans le même cas aussi, et une dernière règle bloque tout le reste, ça me semble important à comprendre, et surtout plus sûr, mettre les DROP en premier il faut être sûr de ne rien oublier.

Pour les règles XMAS, je pense que tu veux parler du scan TCP FIN, etc... qui allume NMAP comme un sapin de Noël, fais ta règle, mais l'ayant testé sous Ubuntu avec GUFW où j'ai remarqué du filtrage de drapeaux, ça passe quand même (Google, Amazon), par contre sous Windows j'ai eu hier une attaque de ce type bloquée par mon pare feu, peut être une petite faiblesse de Linux à ce niveau, mentionnée d'ailleurs chez NMAP dans la rubrique "scan de ports".

Bpnjour Pator75. Je suis la conversation mais n'ai aps compris cette histoire de drapeaux ? Est-ce à dire que même avec les règles IPtables qui bloquent les flags (XMAS, NULL) sur INPUT, Google et Amazon arrivent quand même à passer ???

Pator75

"Bpnjour Pator75. Je suis la conversation mais n'ai aps compris cette histoire de drapeaux ? Est-ce à dire que même avec les règles IPtables qui bloquent les flags (XMAS, NULL) sur INPUT, Google et Amazon arrivent quand même à passer ???"

Salut,

Moi, d'après mes observations, sous Ubuntu ça passe, puisqu'UFW renvoie du RST.

"L'avantage principal de ces types de scans est qu'ils peuvent furtivement traverser certains pare-feux ou routeurs filtrants sans état de connexion (non-statefull). Un autre avantage est qu'ils sont même un peu plus furtifs que le scan SYN. N'y comptez pas trop dessus cependant -- la plupart des IDS modernes sont configurés pour les détecter. L'inconvénient majeur est que tous les systèmes ne respectent pas la RFC 793 à la lettre. Plusieurs systèmes renvoient des RST aux paquets quelque soit l'état du port de destination, qu'il soit ouvert ou pas. Ceci fait que tous les ports sont considérés commefermé. Les plus connus des systèmes qui ont ce comportement sont Microsoft Windows, plusieurs équipements Cisco, BSDI et IBM OS/400. Ce type de scan fonctionne cependant très bien contre la plupart des systèmes basés sur UNIX. Un autre désagrément de ce type de scan et qu'ils ne peuvent pas distinguer les ports ouvertsde certains autres qui sont filtrés, vous laissant face à un laconique ouvert|filtré"

« Page précédente Page suivante »