Je cherche actuellement à alleger mes logs d'iptables (1.2.7a sur noyau
2.4.18 recompilé, mandrake 8.1) des alertes classiques, courantes, ou sans
interet.
(j'utilise déjà le "limit" pour les logs existants).
Mais pendant ma clarification des -j LOG dans mon script iptables, je me
suis heurté a un problème de compréhension vis a vis de "-m state INVALID".
En effet, j'utilise le suivi de connexion et tout ce qui ne fait pas parti
d'une connexion en cours poursuit son chemin dans les regles de filtrage en
dessous jusqu'a temps de recontrer une qui lui correspond.
Cependant, lors de la lecture de how-to a propos d'iptables, l'etat INVALID
est défini comme l'etat d'un paquet qui ne fait parti d'aucune connexion en
cours, j'ai d'ailleurs des INVALID de loggués, mais comment se fait il alors
que tous les paquets qui ne font pas parti de connxions existantes (toutes
les alertes) ne sont pas considérées comme INVALID ?
Par ex, un cas classique d'un paquet UDP envoyés vers le port 137, il est
bien loggué et DROP par la règle correspondante, mais pourtant ne serait il
pas dans l'etat INVALID ?
Voici sommairement la structure :
----------------------
ESTABLISHED, RELATED => ACCEPT
INVALID => DROP
règles de filtrages
---------------------
Si quelqu'un pouvait m'aider a mieux comprendre cet etat, je l'en remercie
d'avance.
Le suivi de connexion est largement documenté, mais l'etat INVALID l'est
beaucoup moins.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Cedric Blancher
Dans sa prose, Guillaume Kaddouch nous ecrivait :
(j'utilise déjà le "limit" pour les logs existants). Mais pendant ma clarification des -j LOG dans mon script iptables, je me suis heurté a un problème de compréhension vis a vis de "-m state INVALID". En effet, j'utilise le suivi de connexion et tout ce qui ne fait pas parti d'une connexion en cours poursuit son chemin dans les regles de filtrage en dessous jusqu'a temps de recontrer une qui lui correspond. Cependant, lors de la lecture de how-to a propos d'iptables, l'etat INVALID est défini comme l'etat d'un paquet qui ne fait parti d'aucune connexion en cours,
Non. Relire la documentation.
Un paquet avec l'état INVALID est un paquet dont le kernel n'arrive pas à déterminer l'état (paquet mal formé, problème de mémoire, etc.). Un paquet qui n'appartient à aucune connexion est un paquet NEW. Il existe un autre cas de paquets INVALID. Ce sont les erreurs ICMP que le kernel n'arrive pas à associer à un flux existant.
Il existe un patch pour TCP (tcp-no-pickup) qui permet d'affecter l'état INVALID à un paquet TCP avec le bit ACK ne faisant pas partie d'une connexion. Ce comportement est critiqué, et discuté, mais je ne sais pas si ça avance. Le plus simple serait d'avoir une entrée dans le sysctl qui permette de passer d'un mode de gestion à l'autre.
j'ai d'ailleurs des INVALID de loggués, mais comment se fait il alors que tous les paquets qui ne font pas parti de connxions existantes (toutes les alertes) ne sont pas considérées comme INVALID ?
Cf. ci dessus.
Par ex, un cas classique d'un paquet UDP envoyés vers le port 137, il est bien loggué et DROP par la règle correspondante, mais pourtant ne serait il pas dans l'etat INVALID ?
Netfilter est un filtre de _paquets_. De fait, il ignore les spécificités des protocoles applicatifs (sauf cas particuliers pour les helpers). Dans la mesure où UDP est un protocole non connecté, quelle raison pourrait faire que, du point de vue réseau (on s'arrête au niveau 4), on décide qu'un paquet soit INVALID plutôt que NEW ?
Bref, il ne faut pas confondre "état" au sens de Netfilter, et "état de la connexion" au sens de TCP.
-- BOFH excuse #97:
Small animal kamikaze attack on power supplies
Dans sa prose, Guillaume Kaddouch nous ecrivait :
(j'utilise déjà le "limit" pour les logs existants). Mais pendant ma
clarification des -j LOG dans mon script iptables, je me suis heurté a
un problème de compréhension vis a vis de "-m state INVALID". En
effet, j'utilise le suivi de connexion et tout ce qui ne fait pas parti
d'une connexion en cours poursuit son chemin dans les regles de filtrage
en dessous jusqu'a temps de recontrer une qui lui correspond. Cependant,
lors de la lecture de how-to a propos d'iptables, l'etat INVALID est
défini comme l'etat d'un paquet qui ne fait parti d'aucune connexion en
cours,
Non. Relire la documentation.
Un paquet avec l'état INVALID est un paquet dont le kernel n'arrive pas
à déterminer l'état (paquet mal formé, problème de mémoire, etc.).
Un paquet qui n'appartient à aucune connexion est un paquet NEW. Il
existe un autre cas de paquets INVALID. Ce sont les erreurs ICMP que le
kernel n'arrive pas à associer à un flux existant.
Il existe un patch pour TCP (tcp-no-pickup) qui permet d'affecter l'état
INVALID à un paquet TCP avec le bit ACK ne faisant pas partie d'une
connexion. Ce comportement est critiqué, et discuté, mais je ne sais pas
si ça avance. Le plus simple serait d'avoir une entrée dans le sysctl qui
permette de passer d'un mode de gestion à l'autre.
j'ai d'ailleurs des INVALID de loggués, mais comment se fait il alors
que tous les paquets qui ne font pas parti de connxions existantes
(toutes les alertes) ne sont pas considérées comme INVALID ?
Cf. ci dessus.
Par ex, un cas classique d'un paquet UDP envoyés vers le port 137, il
est bien loggué et DROP par la règle correspondante, mais pourtant ne
serait il pas dans l'etat INVALID ?
Netfilter est un filtre de _paquets_. De fait, il ignore les
spécificités des protocoles applicatifs (sauf cas particuliers pour les
helpers). Dans la mesure où UDP est un protocole non connecté, quelle
raison pourrait faire que, du point de vue réseau (on s'arrête au niveau
4), on décide qu'un paquet soit INVALID plutôt que NEW ?
Bref, il ne faut pas confondre "état" au sens de Netfilter, et "état de
la connexion" au sens de TCP.
(j'utilise déjà le "limit" pour les logs existants). Mais pendant ma clarification des -j LOG dans mon script iptables, je me suis heurté a un problème de compréhension vis a vis de "-m state INVALID". En effet, j'utilise le suivi de connexion et tout ce qui ne fait pas parti d'une connexion en cours poursuit son chemin dans les regles de filtrage en dessous jusqu'a temps de recontrer une qui lui correspond. Cependant, lors de la lecture de how-to a propos d'iptables, l'etat INVALID est défini comme l'etat d'un paquet qui ne fait parti d'aucune connexion en cours,
Non. Relire la documentation.
Un paquet avec l'état INVALID est un paquet dont le kernel n'arrive pas à déterminer l'état (paquet mal formé, problème de mémoire, etc.). Un paquet qui n'appartient à aucune connexion est un paquet NEW. Il existe un autre cas de paquets INVALID. Ce sont les erreurs ICMP que le kernel n'arrive pas à associer à un flux existant.
Il existe un patch pour TCP (tcp-no-pickup) qui permet d'affecter l'état INVALID à un paquet TCP avec le bit ACK ne faisant pas partie d'une connexion. Ce comportement est critiqué, et discuté, mais je ne sais pas si ça avance. Le plus simple serait d'avoir une entrée dans le sysctl qui permette de passer d'un mode de gestion à l'autre.
j'ai d'ailleurs des INVALID de loggués, mais comment se fait il alors que tous les paquets qui ne font pas parti de connxions existantes (toutes les alertes) ne sont pas considérées comme INVALID ?
Cf. ci dessus.
Par ex, un cas classique d'un paquet UDP envoyés vers le port 137, il est bien loggué et DROP par la règle correspondante, mais pourtant ne serait il pas dans l'etat INVALID ?
Netfilter est un filtre de _paquets_. De fait, il ignore les spécificités des protocoles applicatifs (sauf cas particuliers pour les helpers). Dans la mesure où UDP est un protocole non connecté, quelle raison pourrait faire que, du point de vue réseau (on s'arrête au niveau 4), on décide qu'un paquet soit INVALID plutôt que NEW ?
Bref, il ne faut pas confondre "état" au sens de Netfilter, et "état de la connexion" au sens de TCP.
-- BOFH excuse #97:
Small animal kamikaze attack on power supplies
Cedric Blancher
Dans sa prose, Cedric Blancher nous ecrivait :
Dans sa prose, Guillaume Kaddouch nous ecrivait :
Cependant, lors de la lecture de how-to a propos d'iptables, l'etat INVALID est défini comme l'etat d'un paquet qui ne fait parti d'aucune connexion en cours, Non. Relire la documentation.
Réponse un peu hâtive de ma part, mea culpa.
Si on retrouve cette erreur d'interprétation courante dans pas mal de tutoriaux, HOWTO et autres documentations non officiels, il n'est carrément pas normale de la retrouver dans la page de man iptables.8 :
state This module, when combined with connection tracking, allows access to the connection tracking state for this packet.
--state state Where state is a comma separated list of the connection states to match. Possible states are INVALID meaning that the packet is associated with no known connection, ESTABLISHED meaning that the packet is associated with a connection which has seen packets in both directions, NEW meaning that the packet has started a new connec- tion, or otherwise associated with a connection which has not seen packets in both directions, and RELATED meaning that the packet is starting a new connection, but is associated with an existing connection, such as an FTP data transfer, or an ICMP error.
Un rapport de "bug" est posté, ça devrait être corrigé ;)
-- BOFH excuse #44:
bank holiday - system operating credits not recharged
Dans sa prose, Cedric Blancher nous ecrivait :
Dans sa prose, Guillaume Kaddouch nous ecrivait :
Cependant, lors de la lecture de how-to a propos d'iptables, l'etat
INVALID est défini comme l'etat d'un paquet qui ne fait parti d'aucune
connexion en cours,
Non. Relire la documentation.
Réponse un peu hâtive de ma part, mea culpa.
Si on retrouve cette erreur d'interprétation courante dans pas mal de
tutoriaux, HOWTO et autres documentations non officiels, il n'est
carrément pas normale de la retrouver dans la page de man iptables.8 :
state
This module, when combined with connection tracking, allows
access to the connection tracking state for this packet.
--state state
Where state is a comma separated list of the connection
states to match. Possible states are INVALID meaning
that the packet is associated with no known connection,
ESTABLISHED meaning that the packet is associated with a
connection which has seen packets in both directions,
NEW meaning that the packet has started a new connec-
tion, or otherwise associated with a connection which
has not seen packets in both directions, and RELATED
meaning that the packet is starting a new connection,
but is associated with an existing connection, such as
an FTP data transfer, or an ICMP error.
Un rapport de "bug" est posté, ça devrait être corrigé ;)
--
BOFH excuse #44:
bank holiday - system operating credits not recharged
Cependant, lors de la lecture de how-to a propos d'iptables, l'etat INVALID est défini comme l'etat d'un paquet qui ne fait parti d'aucune connexion en cours, Non. Relire la documentation.
Réponse un peu hâtive de ma part, mea culpa.
Si on retrouve cette erreur d'interprétation courante dans pas mal de tutoriaux, HOWTO et autres documentations non officiels, il n'est carrément pas normale de la retrouver dans la page de man iptables.8 :
state This module, when combined with connection tracking, allows access to the connection tracking state for this packet.
--state state Where state is a comma separated list of the connection states to match. Possible states are INVALID meaning that the packet is associated with no known connection, ESTABLISHED meaning that the packet is associated with a connection which has seen packets in both directions, NEW meaning that the packet has started a new connec- tion, or otherwise associated with a connection which has not seen packets in both directions, and RELATED meaning that the packet is starting a new connection, but is associated with an existing connection, such as an FTP data transfer, or an ICMP error.
Un rapport de "bug" est posté, ça devrait être corrigé ;)
-- BOFH excuse #44:
bank holiday - system operating credits not recharged
Guillaume Kaddouch
Éclairé ?
Totalement! et je t'en remercie, au moins je sais que je n'ai pas affaire à une attaque malicieuse par tunelling contre moi ;) (et oui quand on ne comprend pas quelque chose on imagine tous les scénarios).
Merci de tes efforts pour définir l'etat INVALID et expliquer ces logs. Au moins désormais je comprend ces 12% de logs ;-D
Amicalement,
Guillaume.
Éclairé ?
Totalement! et je t'en remercie, au moins je sais que je n'ai pas affaire à
une attaque malicieuse par tunelling contre moi ;) (et oui quand on ne
comprend pas quelque chose on imagine tous les scénarios).
Merci de tes efforts pour définir l'etat INVALID et expliquer ces logs.
Au moins désormais je comprend ces 12% de logs ;-D
Totalement! et je t'en remercie, au moins je sais que je n'ai pas affaire à une attaque malicieuse par tunelling contre moi ;) (et oui quand on ne comprend pas quelque chose on imagine tous les scénarios).
Merci de tes efforts pour définir l'etat INVALID et expliquer ces logs. Au moins désormais je comprend ces 12% de logs ;-D
Amicalement,
Guillaume.
Cedric Blancher
Dans sa prose, Guillaume Kaddouch nous ecrivait :
au moins je sais que je n'ai pas affaire à une attaque malicieuse par tunelling contre moi ;)
Note bien que je n'ai pas dit cela.
L'utilisation de paquets ICMP non valides est une technique utilisable pour permettre à des backdoors basées sur de l'injection/capture de trames de communiquer puisqu'ils sont jetés silencieusement par la pile IP cible. Il en va de même des paquets TCP manifestement en dehors de la fenêtre TCP. La backdoor récupère ses infos en les noyant dans des flux valides sans pour autant perturber ces flux. Un véritable cauchemar pour les firewalls et les IDS.
D'où l'intérêt de disposer d'un moteur d'état efficace et puissant sur ses outils de sécurité.
-- BC> les règles (évitez le terme de lois qui est seulement juridique) Comme la loi de la pesanteur et celle de l'emmerdement maximum, deux lois dont vous représentez la synthèse : vous êtes lourd et chiant. -+- FF in http://neuneu.mine.nu : Dura crétinex sed neuneutex.
Dans sa prose, Guillaume Kaddouch nous ecrivait :
au moins je sais que je n'ai pas affaire à une attaque malicieuse par
tunelling contre moi ;)
Note bien que je n'ai pas dit cela.
L'utilisation de paquets ICMP non valides est une technique utilisable
pour permettre à des backdoors basées sur de l'injection/capture de trames
de communiquer puisqu'ils sont jetés silencieusement par la pile IP cible.
Il en va de même des paquets TCP manifestement en dehors de la fenêtre
TCP. La backdoor récupère ses infos en les noyant dans des flux valides
sans pour autant perturber ces flux. Un véritable cauchemar pour les
firewalls et les IDS.
D'où l'intérêt de disposer d'un moteur d'état efficace et puissant sur ses
outils de sécurité.
--
BC> les règles (évitez le terme de lois qui est seulement juridique)
Comme la loi de la pesanteur et celle de l'emmerdement maximum, deux
lois dont vous représentez la synthèse : vous êtes lourd et chiant.
-+- FF in http://neuneu.mine.nu : Dura crétinex sed neuneutex.
au moins je sais que je n'ai pas affaire à une attaque malicieuse par tunelling contre moi ;)
Note bien que je n'ai pas dit cela.
L'utilisation de paquets ICMP non valides est une technique utilisable pour permettre à des backdoors basées sur de l'injection/capture de trames de communiquer puisqu'ils sont jetés silencieusement par la pile IP cible. Il en va de même des paquets TCP manifestement en dehors de la fenêtre TCP. La backdoor récupère ses infos en les noyant dans des flux valides sans pour autant perturber ces flux. Un véritable cauchemar pour les firewalls et les IDS.
D'où l'intérêt de disposer d'un moteur d'état efficace et puissant sur ses outils de sécurité.
-- BC> les règles (évitez le terme de lois qui est seulement juridique) Comme la loi de la pesanteur et celle de l'emmerdement maximum, deux lois dont vous représentez la synthèse : vous êtes lourd et chiant. -+- FF in http://neuneu.mine.nu : Dura crétinex sed neuneutex.
