Spoofing - Blocage temporaire IP [SYN]

Support Debian
#1

Bonjour à tous,

Depuis plus d’une semaine nous galérons sur un problème majeur sur notre plateforme externe (hébergée en DMZ) de messagerie. Nous travaillons sur une debian sarge 3.01 [2.4.27-2-386]. Nous avons suivi la procédure : workaround.org/articles/ispmail-sarge/ qui fonctionne parfaitement. Ce serveur de messagerie reçoit des mails en provenance d’internet (MX hébergé chez Cegetel) et de l’intranet au travers d’une passerelle. Celle-ci centralise les demandes SMTP, POPS et IMAPS qui sont envoyées vers le serveur de messagerie externe. En externe, chaque PC effectue ces demandes lui-même en utilisant un client de messagerie. Aucun problème sur les clients externes qu’ils soient Outlook ou autres.
En revanche, toutes les environ 11 minutes, le serveur de messagerie refuse les demandes en provenance de la passerelle pendant 1 minute ; en fonction du traffic intense entre la passerelle et le serveur de messagerie le délai de 11 minutes décroit et la durée de blocage passe à 2 voire 3 minutes.
Une analyse des paquets transitant entre la passerelle et le serveur de messagerie nous apprends qu’il refuse systématiquement tout le traffic IP en provenance de la passerelle (SSH, SMTP, SMTPS, POP3, POP3S, IMAP, IMAPS) seul le protocole ICMP est opérationnel. Chaque demande de SYN de la passerelle se solde par un RST ACK de la part du serveur de messagerie.
Pendant le blocage sur le serveur de messagerie, en effectuant un TCPDump nous ne voyons pas passer les demandes en provenance de la passerelle par contre celle en provenance des autres clients tout est OK.
Ce problème n’est visiblement pas au niveau applicatif (PostFix) puisqu’il répond parfaitement aux demandes externes, le filtrage s’effectue uniquement sur la passerelle qui est le concentrateur de l’ensemble des requêtes TCP du LAN (300 users).
Nous pensons que le problème ce situe au niveau de la couche réseau (/etc/network/option spoofprotect = no), les flags sysctl (rp_filter et tcp_syncookies) sont à 0. Le nombre de paquets SYN en provenance de la passerelle à un instant donné peut être relativement très important (20/s).
L’IPTable est provisoirement désactivé en policy access.

Comment activer les logs sur la fonctionnalité de spoofing de la carte réseau ?
Quelle variable doit-on modifier pour inhiber l’option de spoofing en provenance d’une adresse (par exemple la passerelle) ?

Merci pour votre aide.

#2

hello,

[quote]
Comment activer les logs sur la fonctionnalité de spoofing de la carte réseau ? [/quote]

A part les logs de base “/var/log/{kern.log, debug, auth.log}” je ne vois pas d’autres façons de remonter des infos, cependant, dans ce cas, il est preferable de travailler avec la couche reseau du kernel avec iptables.

[quote]
Quelle variable doit-on modifier pour inhiber l’option de spoofing en provenance d’une adresse (par exemple la passerelle) ? [/quote]

Je crains que tu puisses modifier une variable en terme de configuration systéme pour inhiber ta passerelle, je pense que cela ce fait aussi au niveau de la couche reseau en utilisant iptables.

#3

je te remercie pour ta réponse

j’ai beau regarder les logs (kern.log, dmsg, debug auth.log) je ne vois absoluement rien: pas warning.
Comment expliquer que ces paquets ne remontent pas dans un TCPDump?Je vois tous les paquets sauf ceux-la. J’ai mis un hub entre le serveur de messagerie et la passerelle et je les vois avec ethereal.
J’ai encore controlé les flags
cat /proc/sys/net/ipv4/conf/eth0/rp_filter
0
cat /proc/sys/net/ipv4/tcp_syncookies
0
cat /proc/sys/net/ipv4/tcp_max_syn_backlog
1024
cat /proc/sys/net/ipv4/tcp_synack_retries
5
cat /proc/sys/net/ipv4/tcp_ecn
0
cat /proc/sys/net/ipv4/tcp_abort_on_overflow
0

Vraiment, je ne vois pas pourquoi les paquets sont “ignorés”.

#4

A l’intuition: y a t il des messages de passage des interfaces en “promiscuous mode” lors des sequences de blocage ?

Autre suggestion: y a t il un paramètre “debug” quelconque disponible sur le module correspondant aux cartes réseaux, pour voir s’il n’y a pas d’infos à glaner ? (avec "modinfo ")

et plus bas niveau, il y a peut être des choses à regarder du coté de l’arp. Tu n’as pas un proxy_arp quelquepart ?

(Tout ça au pif, on est aux limites de ma compètence).

#5

Oui MattOTop,

effectivement, dans le log /var/log/messages, j’ai des alertes du kernel du style (mais visiblement elles correspondent à mes tcpdump et elles ne sont pas concomitantes avec les blocages):
localhost kernel: device eth0 entered promiscuous mode
localhost kernel: device eth0 left promiscuous mode

Quelle intuition as-tu sur le mode promiscuous, stp?

PS: Je vais activer le mode “debug” sur les cartes réseaux, nous verrons bien; mais si c’est un problème de driver (ou de cartes réseaux) le problème devrait se produire aussi pour les utilisateurs externes n’est-il pas?

#6

Pour le “promiscuous mode”, j’ai cru me rappeler qu’il y a des operations réseaux qui ne fonctionnent plus quand il est actif (j’ai recherché, mais je n’ai pas retrouvé).
Mais s’il n’est pas concommitant avec les periodes de blocage…

Pour la carte réseau et le debug, si c’est ta carte lan, par exemple, qui sature un buffer, ou provoque un overflow mal gèré sur un compteur de paquet ou quelquechose comme ça, ça n’empêche pas forcément tes deux autres interfaces internet et dmz de continuer sans problême, vois tu ?
A ce sujet, je sais que le serveur est en prod, mais ça vaudrait peut être le coup de trouver une tranche horaire ne gènant pas, et de vérifier si le problême persiste en changeant de noyau.

Bon, mais c’etait surtout pour ne pas rester sans piste de recherche, parceque je ne vois pas plus que toi d’ou peu venir le problême.

#7

Salut, perso je t’avouerai ne pas cerner completement ton probleme. Mais probablement que MattOTop a compris…
En attendant:

Tu vois des paquets de passerelle vers le serveur de messagerie mais si tu te place sur le serveur de messagerie tu ne les vois pas?

Modifier des parametres (backlog par ex) va mitiger le probleme seulement. Il faut le corriger a la source si tu veux vraimment resoudre.

#8

Exactement BorisTheButcher,
si je fais un ethereal de la ligne (pour le test j’ai mis un HUB pour capturer tous les paquets) je vois les paquets passerelle -> messagerie [SYN] et la réponse [RST ACK].
Sur le serveur de messagerie quand le blocage ne se produit pas je vois dans tcpdump tous les paquets le [SYN] en provenance de la passerelle et la réponse [SYN, ACK] nickel. Dès que le blocage a lieu, je ne vois pas la demande [SYN] de la passerelle et encore moins la réponse [RST, ACK]
Je pense que MattOTop a raison je vais devoir changer de noyau mais comme je ne comprends pas et que je suis tétu ce n’est pas gagné, surtout que j’enrage il marche nickel ce noyau à part ce blocage d’une minute tous les 11 minutes :wink:

#9

[quote=“dnuixa”]Exactement BorisTheButcher,
si je fais un ethereal de la ligne (pour le test j’ai mis un HUB pour capturer tous les paquets) je vois les paquets passerelle -> messagerie [SYN] et la réponse [RST ACK].
Sur le serveur de messagerie quand le blocage ne se produit pas je vois dans tcpdump tous les paquets le [SYN] en provenance de la passerelle et la réponse [SYN, ACK] nickel. Dès que le blocage a lieu, je ne vois pas la demande [SYN] de la passerelle et encore moins la réponse [RST, ACK]
[/quote]
Et tcpdump et ton kernel, qd tu fait ctrl-c sur tcpdump, il droppe combien de paquets? Si ton noyau est saturé ou meme les buffers de tcpdump (ou meme les deux), tu ne verra pas tous les paquets mais tu auras l’info du nombre de paquets perdus.

[quote]
Je pense que MattOTop a raison je vais devoir changer de noyau mais comme je ne comprends pas et que je suis tétu ce n’est pas gagné, surtout que j’enrage il marche nickel ce noyau à part ce blocage d’une minute tous les 11 minutes :wink:[/quote]
Oui continue sur cette piste.

Et 20 SYN par seconde, c’est ton fonctionnement normal?

#10

J’aurais pu te l’indiquer dans le post précédent : 0 packet drop sur 2000 captured !

Le problème se pose aussi la nuit et la nous sommes à moins de 1 syn/s et systématiquement au bout de 11 minutes coupure d’1 minute.

#11

hello,

N’as tu pas un soft du genre ids/ips ou autre qui bloquerait les paquets ou les bannis pendant ses 11 minutes ?

#12

détrompes toi BB je n’y vois pas trés clair non plus.
dnuixa: pour réfèrences précises sur les variables tcp du noyau, j’ai trouvé ça
ipsysctl-tutorial.frozentux.net/ … ables.html
je suis en train de reclarifier l’usage de ces flags, mais as tu testé par exemple l’activation du tcp_syncookies, pour ralentir le débit quand la charge monte, et voir si ça ne règle pas le prob ?
Je sais que le prob arrive quand la charge est petite, mais ça mange pas de pain d’essayer.
Sinon aussi, tu dis que pendant le blocage l’ICMP passe, et pas TCP, mais que donne l’udp (avec ftp, par exemple).

#13

[quote=“dnuixa”]J’aurais pu te l’indiquer dans le post précédent : 0 packet drop sur 2000 captured !
[/quote]
C’est louche ce truc. T’as bien regardé l’adresse IP destination ET l’adresse MAC hein? pas que l’adresse IP?
Parceque ce qui peut se passer c’est que le paquet arrive sur la carte réseau.
Sur celle-ci y a un filtre.
1)Si mauvaise trame (mauvais format, mauvaise entete, mauvais crc,…?) dropper.
2)Si (non_promisc && dest_mac != ma_mac) dropper. Mais là le tcpdump met la carte en promisc
Ca peut effectivement bloquer les buffers hardware de la carte ethernet sans qu’aucune couche logicelle ne soit touchée…

[quote]
Le problème se pose aussi la nuit et la nous sommes à moins de 1 syn/s et systématiquement au bout de 11 minutes coupure d’1 minute.[/quote]
Je connais 2 outils de monitoring:
atop
atsar
Tu peux essayer de les installer et monitorer avec une très grande frequence.

[quote=“MattOTop”]
A ce sujet, je sais que le serveur est en prod, mais ça vaudrait peut être le coup de trouver une tranche horaire ne gènant pas, et de vérifier si le problême persiste en changeant de noyau. [/quote]
+1 et aussi en essayant de virer le cable reseau du serveur de messagerie pendant disons… 12 minutes :slightly_smiling:

#14

tiens, j’ai trouvé un flag qui provoque un timeout de par defaut 60 secs: tcp_fin_timeout
Changes le timeout, et regardes si ça change la durée de blocage, pour voir si c’est une direction interressante.

#15

[quote]
Sinon aussi, tu dis que pendant le blocage l’ICMP passe, et pas TCP, mais que donne l’udp (avec ftp, par exemple).[/quote]
udp par ftp? euh non ftp utilise tcp.
J’avais zappé cette info.
C’est à creuser aussi… soit effectivement les buffers applicatifs pour tcp, soit les trames tcp car elles sont de grandes taille (à l’inverse d’icmp qui peut etre petit)

Sur le hub, t’aurais pas le link qui s’eteindrait toutes les 11 minutes qd meme?
Ca m’etonnerait, t’aurais des messages dans /var/log/messages.

Une 'tite carte réseau qui rend l’ame?

#16

tu es sur que ftpdata est en tcp ?
bon. Tu as un exemple d’applicatif en udp ? je n’en ai pas en tete…

#17

Je vous remercie tous les 2 de vous impliquer autant, je me sens beaucoup moins seul :unamused:
J’ai changé le variable tcp_fin_timeout, je vais controler le délai de blocage.
Pour le hub BorisTheButcher, malheureusement pas de blème coté HUB.
Je vais trouver un petit soft pour jouer en UDP

Encore merci pour votre aide.

#18

[quote=“MattOTop”]tu es sur que ftpdata est en tcp ?
[/quote]
ah certain :slightly_smiling:

[quote]
bon. Tu as un exemple d’applicatif en udp ? je n’en ai pas en tete…[/quote]

[code]grep udp /etc/services

nfs,…[/code]

#19

C’est pas ton hub qui aurait un problème, c’est ta carte réseau. Et en cas de gros problème, la carte ferait un reset donc le link s’eteindrait et donc tu le verrai sur le hub (ca m’est déja arrivé)
Enfin c’etait pour clarifier, t’as probablement capté.
A+

#20

à ce compte la, tu trouves aussi ssh comme service udp !
et par ailleurs, je n’ai pas de trace de nfs dans mon /etc/services, donc il faut le savoir :laughing: