iptables et l'option d'etat "INVALID"

Le
Guillaume Kaddouch
Bonjour,

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.

Merci.

Guillaume.
  • Partager ce contenu :
Vos réponses
Trier par : date / pertinence
Cedric Blancher
Le #388577
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

Cedric Blancher
Le #388576
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


Guillaume Kaddouch
Le #388575
É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.

Cedric Blancher
Le #388574
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.

Poster une réponse
Anonyme