iptables/netfilter et etat INVALID

Le
Eric Belhomme
Bonjour,

J'ai un problème avec un firewall sous Linux (Debian Squeeze, noyau
2.6.32-5 amd64) :

eth0 sur le LAN,
eth1 sur une DMZ1,
eth2 sur une DMZ2,
eth3 sur une DMZ3,
eth4 sur avec des IP publiques en /29

Le sympt$ome constaté : énormément de paquets droppés pour cause d'état
"INVALID" dans la conntrack.

Voici le début de mes règles de filtrage :

Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
213399 63765385 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
202 8175 log_drop all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID
[]
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
2165157 1173316396 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
602 34060 log_drop all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID
[]
Chain OUTPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0
274699 261862826 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 log_drop all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID
[]
Chain log_drop (3 references)
pkts bytes target prot opt in out source destination
804 42235 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 prefix `Drop invalid: '
804 42235 DROP all -- * * 0.0.0.0/0 0.0.0.0/0


La config de mon Interface Ethernet :
ip addr ls dev eth4
5: eth4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 100
link/ether 00:1b:21:d0:a0:d9 brd ff:ff:ff:ff:ff:ff
inet 192.168.25.210/29 brd 192.168.25.215 scope global eth4
inet 192.168.25.211/29 scope global secondary eth4
inet 192.168.25.212/29 scope global secondary eth4
inet 192.168.25.213/29 scope global secondary eth4
inet6 fe80::21b:21ff:fed0:a0d9/64 scope link
valid_lft forever preferred_lft forever

- rp_filter est à 0 pour toutes les interfaces
- accept_source_route est à 0 pour toutes les interfaces
- log_martian est à 1 pour toutes les interfaces

La table nat comprend pas mal de SNAT et de DNAT entre les adresse IP publiques et des serveurs sur les différentes DMZ :

Chain PREROUTING (policy ACCEPT 95012 packets, 6075003 bytes)
pkts bytes target prot opt in out source destination
1 60 DNAT tcp -- eth4 * 0.0.0.0/0 192.168.25.211 tcp dpt:5222 to:192.168.33.10
0 0 DNAT tcp -- eth4 * 0.0.0.0/0 192.168.25.211 tcp dpt:5223 to:192.168.33.10
73 4128 DNAT tcp -- eth4 * 0.0.0.0/0 192.168.25.212 tcp dpt:25 to:192.168.33.12
9 573 DNAT tcp -- eth4 * 0.0.0.0/0 192.168.25.212 tcp dpt:587 to:192.168.33.12
46 2836 DNAT tcp -- eth4 * 0.0.0.0/0 192.168.25.212 tcp dpt:993 to:192.168.33.12
1 60 DNAT tcp -- eth4 * 0.0.0.0/0 192.168.25.212 tcp dpt:995 to:192.168.33.12

Chain POSTROUTING (policy ACCEPT 11622 packets, 726067 bytes)
pkts bytes target prot opt in out source destination
0 0 SNAT udp -- * eth4 192.168.34.10 0.0.0.0/0 udp dpt:5060 to:192.168.25.213
0 0 SNAT tcp -- * eth4 192.168.34.10 0.0.0.0/0 tcp dpt:5060 to:192.168.25.213
0 0 SNAT tcp -- * eth4 192.168.33.12 0.0.0.0/0 tcp dpt:995 to:192.168.25.212
0 0 SNAT tcp -- * eth4 192.168.33.12 0.0.0.0/0 tcp dpt:993 to:192.168.25.212
0 0 SNAT tcp -- * eth4 192.168.33.12 0.0.0.0/0 tcp dpt:587 to:192.168.25.212
4027 241620 SNAT tcp -- * eth4 192.168.33.12 0.0.0.0/0 tcp dpt:25 to:192.168.25.212
56239 3374874 SNAT all -- * eth4 10.0.0.0/16 0.0.0.0/0 to:192.168.25.210

la conntrack tourne autour de 4000 cnx actives, la machine est un bi-xeon
à 2.8GHz, 4G de RAM, son load average ne dépasse pas 0.5, toutes les
interfaces réseau sont des Intel Gigabit (2x 82541GI, 4x 82546GB)

Je soupçonne mon setup sur l'interface eth4 d'être la cause de ces problèmes
de paquets INVALID, mais je ne sais pas comment déverminer cela, etant donné
que le noyau ne m'indique pas *pourquoi* il considère le paquet comme INVALID !

Une suggestion ?

Merci

--
Rico
L'homme est le seul mâle qui batte sa femelle;
il est donc le plus brutal des mâles;
À moins que, de toutes les femelles,
la femme soit la plus insupportable.
-+- Georges Courteline -+-
Publicité
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Pascal Hambourg
Le #24409101
Salut,

Eric Belhomme a écrit :

Je soupçonne mon setup sur l'interface eth4 d'être la cause de ces problèmes
de paquets INVALID, mais je ne sais pas comment déverminer cela, etant donné
que le noyau ne m'indique pas *pourquoi* il considère le paquet comme INVALID !

Une suggestion ?



Tu pourrais donner des échantillons de log de ces paquets ?
Eric Belhomme
Le #24409751
Le Mon, 16 Apr 2012 22:21:22 +0200, Pascal Hambourg a écrit :

Salut,

Eric Belhomme a écrit :

Je soupçonne mon setup sur l'interface eth4 d'être la cause de ces
problèmes de paquets INVALID, mais je ne sais pas comment déverminer
cela, etant donné que le noyau ne m'indique pas *pourquoi* il considère
le paquet comme INVALID !

Une suggestion ?



Tu pourrais donner des échantillons de log de ces paquets ?



Ca peut concerner toute connexion par ailleurs déjà établie, et d'un coup
je vais avoir droit à ça :

Apr 17 10:18:01 icare kernel: [2216794.996771] Drop invalid: IN=eth0 OUT=eth4 SRC2.16.67.61 DST!7.163.21.34 LENR TOS=0x00 PREC=0x00 TTLb IDI429 DF PROTO=TCP SPTX207 DPT€ WINDOWF RES=0x00 ACK FIN URGP=0
Apr 17 10:18:01 icare kernel: [2216794.996793] Drop invalid: IN=eth0 OUT=eth4 SRC2.16.67.61 DST!7.163.21.34 LENR TOS=0x00 PREC=0x00 TTLb ID0855 DF PROTO=TCP SPTX204 DPT€ WINDOWF RES=0x00 ACK FIN URGP=0

et bien entendu, conntrack n'a à ce moment plus trace de la connexion...
Y a-t-il un moyen de monitorer les évènements de conntrack ?

Bien entendu, HTTP est autorisé à passer le F/W...


--
Rico
Les femmes seront l'égal de l'homme le jour où elles accepteront d'être
chauves et de trouver ça distingué.
-+- Coluche -+-
Eric Belhomme
Le #24412991
Le Tue, 17 Apr 2012 22:11:49 +0200, Joe the Shmoe a écrit :


Juste pour faire avancer le schmilblick : ce sont des paquets de
fermeture de session (ACK+FIN). Est-il envisageable que le client
(172.16.67.61) se comporte de façon non standard :
- pile TCP/IP windows buggée qui ré-émet le paquet plusieurs fois -
tentative de déni de service (le FIN n'a pas été envoyé par le serveur)



en face, c'est du Linux (Debian Squeeze, avec un noyo standard 2.6.32),
pas de filtrage, une bête interface gigabit, configuré en DHCP

vu qu'on est en adressage privé je suppose que ce doit être possible de
vérifier le poste client (il n'est pas de l'autre côté d'Internet par
exemple), quitte à y utiliser un wireshark pour avoir un autre point de
vue.



pas eu le temps de faire de capture... je vais tenter ça demain, mais
comme ces paquets invalides viennent d'un peu partout, ça va pas être
coton...

Je ne vois pas comment le statut "INVALID" peut découler d'une mauvaise
configuration de netfilter... ?




Ben moi non plus, mais pourtant...

--
Rico
Plus je connais les hommes, plus j'aime les femmes
-+- Frédéric Dard -+-
Eric Belhomme
Le #24412981
Le Wed, 18 Apr 2012 00:41:28 +0200, Pascal Hambourg a écrit :


Comme l'a écrit Joe, ce sont des fermetures de connexion. Peut-être des
doublons.
A part ça, y a-t-il des symptômes fonctionnels ?




Des connexions coupées sans raisons. C'est particulièrement visible sur
IMAP.

--
Rico
Il n'est probablement pas de révélation plus terrible
que l'instant ou vous découvrez que votre père est homme...
fait de chair.
-+- Frank Herbert, Dune -+-
Publicité
Suivre les réponses
Poster une réponse
Anonyme