Règles iptables trop imperméable

Pator75 · Le 12/09/2014, à 11:06

pires57 a écrit :

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

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

bruno · Le 12/09/2014, à 11:15

@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.

Dernière modification par bruno (Le 12/09/2014, à 16:02)

Pator75 · Le 12/09/2014, à 11:18

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 · Le 12/09/2014, à 11:24

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 · Le 12/09/2014, à 11:48

bruno a écrit :

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.

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 · Le 12/09/2014, à 13:02

Inutile voir néfaste.

Pator75 · Le 12/09/2014, à 13:20

Haleth a écrit :

Inutile 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 · Le 12/09/2014, à 13:21

@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_ · Le 12/09/2014, à 15:06

@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 · Le 12/09/2014, à 15:37

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

Dernière modification par Haleth (Le 12/09/2014, à 15:39)

Pator75 · Le 12/09/2014, à 16:02

_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 · Le 12/09/2014, à 16:03

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_ · Le 15/09/2014, à 10:09

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 · Le 12/10/2014, à 16:36

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/130netfi … 0_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 · Le 12/10/2014, à 16:53

"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é"

Dernière modification par Pator75 (Le 12/10/2014, à 16:58)

Haleth · Le 12/10/2014, à 17:25

UFW renvoie du RST.

Linux envoie, par défaut, le reset.

Philippeditlegros · Le 12/10/2014, à 17:25

Merci.

Philippeditlegros · Le 12/10/2014, à 17:26

Haleth a écrit :

UFW renvoie du RST.
Linux envoie, par défaut, le reset.

Bonjour, peut-on changer cette valeur par défaut quelque part svp ?

Haleth · Le 12/10/2014, à 17:30

Tu peux la changer avec iptables (ou ufw / gufw etc).

Comprends bien que le reset est le comportement logique : tu cherches à joindre une personne, elle n'existe pas, je te le fait savoir en te jetant.

Philippeditlegros · Le 12/10/2014, à 17:32

Haleth a écrit :

Tu peux la changer avec iptables (ou ufw / gufw etc).

Avec iptables aussi ? Ce serait une commande qui ressemblerait à quoi svp ??

Pator75 · Le 12/10/2014, à 17:33

Haleth a écrit :

UFW renvoie du RST.
Linux envoie, par défaut, le reset.

Ben oui, mais justement, vu qu'il n'y a eu, dans les connexions que j'ai surveillées, aucune demande initiale vers les IP qui envoient du scan FIN, UFW ne devrait pas.

Il me semble que Shorewall traite le problème, vu sur Mageia.

Dernière modification par Pator75 (Le 12/10/2014, à 17:34)

Haleth · Le 12/10/2014, à 17:33

blablabla
iptables -P INPUT DROP

Pator75 · Le 12/10/2014, à 17:36

Haleth a écrit :

Tu peux la changer avec iptables (ou ufw / gufw etc).
Comprends bien que le reset est le comportement logique : tu cherches à joindre une personne, elle n'existe pas, je te le fait savoir en te jetant.

Non, on envoie du SYN, pas du FIN d'emblée.

Philippeditlegros · Le 12/10/2014, à 17:41

Pator75 a écrit :

Il me semble que Shorewall traite le problème, vu sur Mageia.

Ca m'intéresse si vous retrouvez à peu près où c'est svp, je reviens de google mais il y a trop de choses, je n'arrive pas à trier, était-ce sur Mageia forum svp ?

Philippeditlegros · Le 12/10/2014, à 17:42

Haleth a écrit :

blablabla
iptables -P INPUT DROP

Ca suffit ? Pator dit que non je crois.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#26 Le 12/09/2014, à 11:06

Re : Règles iptables trop imperméable

#27 Le 12/09/2014, à 11:15

Re : Règles iptables trop imperméable

#28 Le 12/09/2014, à 11:18

Re : Règles iptables trop imperméable

#29 Le 12/09/2014, à 11:24

Re : Règles iptables trop imperméable

#30 Le 12/09/2014, à 11:48

Re : Règles iptables trop imperméable

#31 Le 12/09/2014, à 13:02

Re : Règles iptables trop imperméable

#32 Le 12/09/2014, à 13:20

Re : Règles iptables trop imperméable

#33 Le 12/09/2014, à 13:21

Re : Règles iptables trop imperméable

#34 Le 12/09/2014, à 15:06

Re : Règles iptables trop imperméable

#35 Le 12/09/2014, à 15:37

Re : Règles iptables trop imperméable

#36 Le 12/09/2014, à 16:02

Re : Règles iptables trop imperméable

#37 Le 12/09/2014, à 16:03

Re : Règles iptables trop imperméable

#38 Le 15/09/2014, à 10:09

Re : Règles iptables trop imperméable

#39 Le 12/10/2014, à 16:36

Re : Règles iptables trop imperméable

#40 Le 12/10/2014, à 16:53

Re : Règles iptables trop imperméable

#41 Le 12/10/2014, à 17:25

Re : Règles iptables trop imperméable

#42 Le 12/10/2014, à 17:25

Re : Règles iptables trop imperméable

#43 Le 12/10/2014, à 17:26

Re : Règles iptables trop imperméable

#44 Le 12/10/2014, à 17:30

Re : Règles iptables trop imperméable

#45 Le 12/10/2014, à 17:32

Re : Règles iptables trop imperméable

#46 Le 12/10/2014, à 17:33

Re : Règles iptables trop imperméable

#47 Le 12/10/2014, à 17:33

Re : Règles iptables trop imperméable

#48 Le 12/10/2014, à 17:36

Re : Règles iptables trop imperméable

#49 Le 12/10/2014, à 17:41

Re : Règles iptables trop imperméable

#50 Le 12/10/2014, à 17:42

Re : Règles iptables trop imperméable

Pied de page des forums