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 :
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 -+-
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
Pascal Hambourg
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 ?
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 ?
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 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 :
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 -+-
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 :
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 :
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 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 -+-
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 -+-
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 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 -+-
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 -+-
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 -+-
