ipcop : NEW not SYN?

[michauko]

Salut,
'tite question technique, à travers un long post

Le décor :
- une école primaire ; des vieux-vieux PC (10 ans d'âge) en Windows 98, un XP récent et des Ubuntu 8 récentes (sur du matos récent - enfin, 3 ans d'âge)
- une passerelle IPCOP au milieu de ça.
- un modem/routeur comme on ne fait plus : speedtouch 510 sur une ligne wanadoo 512/128 comme on ne fait plus non plus

Le fond de l'histoire est le manque de moyens ; la bonne volonté d'un papa informaticien qui peut leur donner du matos obsolète d'entreprise ; l'accord de l'inspec. académique pour m'occuper de cette école avec la solution de filtre URL qu'ils préconisent : IPCOP + urlfilter +proxy transparent ; super ! du linux, c'est dans l'esprit des PC Ubuntu que je leur file. Let's go, je vous mets ça en place. C'est cool IPCOP

La conf :
adr. dyn. wanadoo publique<---modem/routeur speedtouch--->10.x.x.x
cablé en direct sur l'IPCOP :
10.0.0.1 <---ipcop box--->192.168.x.x
suivi des PC répartis sur quelques switchs de base ; tous en DHCP, 192.168.x.y évidememnt.
Le modem est en direct avec l'IPCOP (notez pour plus tard)

N'arrivant pas à passer le modem/routeur en simple modem pour affecter l'adresse publique directement à IPCOP, j'ai laissé tel quel et tant pis - il faut dire que je n'avais pas le password du compte wanadoo, pas facile de tout trafiquer dans ces conditions. J'ai donc 2 réseaux locaux, 2 traductions, tant pis ; c'est pas un problème je pense.
L'IPCOP est de type ROUGE/VERT - cas le plus simpliste possible.

Le problème
Une fois la passerelle IPCOP montée, l'urlfilter en place, j'ai eu un retour d'une classe : accès hypeeeer lent. Pas étonnant vu le débit de la ligne. En regardant de plus près, je suis tombé sur ça :

Code: Tout sélectionner

Nov 14 17:41:47 ecolegw kernel: NEW not SYN? IN=eth0 OUT= MAC=00:09:5b:1d:8c:9d:00:0e:a6:9f:86:1e:08:00 SRC=192.168.2.200 DST=192.168.2.1 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=33872 DF PROTO=TCP SPT=52152 DPT=3128 WINDOW=59532 RES=0x00 ACK FIN URGP=0

En cherchant, je suis tombé sur les forums d'IXUS.net, cet article : http://forums.ixus.fr/viewtopic.php?t=37115
Le problème est similaire, mais contrairement au problème sur le post précédent, je ne pense pas avoir de handshake court-circuité (car le modem est 10.x est obligatoirement derrière l'IPCOP, impossible de court-circuiter).
A noter : le problème a/avait lieu depuis des Ubuntu, des Windows 98, mais semble-t-il pas depuis les postes XP.

Ma solution - et ma question
La règle qui génère le "NEW not SYN?" dans les logs est la suivante (extrait de iptables) :

Code: Tout sélectionner

Chain BADTCP (2 references)
pkts bytes target     prot opt in     out     source               destination
    0     0 PSCAN      tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x29
    0     0 PSCAN      tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x00
    0     0 PSCAN      tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:0x3F/0x01
    0     0 PSCAN      tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:0x06/0x06
    0     0 PSCAN      tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:0x03/0x03
   41 20377 NEWNOTSYN  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:!0x17/0x02 state NEW
[....]

Chain INPUT (policy DROP 1 packets, 47 bytes)
[....]
263K  219M BADTCP     all  --  *      *       0.0.0.0/0            0.0.0.0/0
[....]

Chain NEWNOTSYN (1 references)
pkts bytes target     prot opt in     out     source               destination
   41 20377 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0           limit: avg 10/min burst 5 LOG flags 0 level 4 prefix `NEW not SYN? '
   41 20377 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0
[....]


Si j'ai bien pigé, lorsque je ne sais pourquoi, un paquet un peu louche côté tcpflags (comme expliqué dans le post mentionné ci-dessus) arrive sur IPCOP, il est droppé via cette règle => "lenteur" de l'accès web. Tu m'étonnes, le retour n'arrivait jamais...

Question : à quoi sert cette règle ? elle me semble inutile, source d'ennuis. Je m'explique - et c'est là où je voudrais votre avis
=> La chaine BADTCP est celle où IPCOP recense toutes ses règles de port scan (chaîne PSCAN), avec en plus la dernière NEWNOTSYN qui semble tomber de nulle part. En allant voir dans /etc/rc.d/rc.firewall, on y trouve sa justification - vraiment bizarre, lisez le 2è bloc de commentaires !

Code: Tout sélectionner

        # This chain will log, then DROPs packets with certain bad combinations
        # of flags might indicate a port-scan attempt (xmas, null, etc)
        /sbin/iptables -N PSCAN
        /sbin/iptables -A PSCAN -p tcp  -m limit --limit 10/minute -j LOG --log-prefix "TCP Scan? "
        [...blablabla...]
        /sbin/iptables -A PSCAN -j DROP

        # New tcp packets without SYN set - could well be an obscure type of port scan
        # that's not covered above, may just be a broken windows machine
        /sbin/iptables -N NEWNOTSYN
        /sbin/iptables -A NEWNOTSYN  -m limit --limit 10/minute -j LOG  --log-prefix "NEW not SYN? "
        /sbin/iptables -A NEWNOTSYN  -j DROP

        # Chain to contain all the rules relating to bad TCP flags
        /sbin/iptables -N BADTCP

        # Disallow packets frequently used by port-scanners
        # nmap xmas
        [... blabla ajout des chaînes PSCAN et NEWNOTSYN à BADTCP, ajout de BADTCP dans INPUT...]


Si je comprends bien, un des responsables d'IPCOP a dû voir un jour un paquet bizarrement forgé, émanant d'un Windows, et a décrété que ça craignait => on DROP. De mon côté, le cas se présente depuis un Windows 98, des Ubuntu fraîchement installées et jamais depuis XP.
Ce matin, j'ai désactivé cette règle (et la chaîne qui va avec) - j'attends le retour d'une classe pour savoir si "le web ne rame plus" puis modifier pour de bon la conf.

Alors ? utile ? pas utile ? une autre explication du problème ?
Y'a-t-il quelque chose à faire côté /proc/sys/net/ipv4/conf/*/[send|receive|accept|gnagnagna]_*

Merci de votre aide

[Gesp]

Question : à quoi sert cette règle ? elle me semble inutile, source d'ennuis

Non elle n'est pas inutile et ne devrait pas être source d'ennui même avec une machine windows.
Elle ne fait que demander le respect du protocole (il faut envoyer un syn avant que la connexion soit considérée à l'état new).

Le seul ennui qu'il y a avec une machine windows, c'est que si tu ouvre une page web (statique) dans le navigateur et la laisse ouverte sans rien faire pendant un long laps de temps (suffisament pour que les connexions tcp tombent en time-out, peut-être même mettre l'ordinateur en veille) et quand tu re-cliques sur la page, windows essaye les connexions comme si elle était encore à l'état ouvert, ce qui n'est pas nécessairement le cas et conduit à quelques NEW NOT SYN dans les logs.
Mais en l'absence de réponse, windows sait en déduire qu'il lui faut réouvrir les connexions tcp et cette basse cuisine est tranparente pour l'utilisateur.

Les problèmes de lenteur sont liés souvent à des pb de routage du type
- mauvaise autonégociation sur un des liens ethernet (sur ipcop, regarder avec ethtool ou mii-tool)
- même adressage réseau de chaque coté
ou
- red et green connecté sur le même switch (et pas dans des vlan différents)

Ou alors il s'agit d'un problème de proxy (encore une fois la consommation de mémoire du proxy est proportionnelle au nombre des objets dans le cache, donc plus le cache est gros, plus la table en mémoire des objets cachés est importante et quand elle déborde dans le swap, le système ralentit de plus en plus)

Si le problème est isolé sur une classe, c'est probablement un pb de routage ou d'autonégociation ethernet sur la machine d'une classe. Si le pb est général, cela pourrait être un pb de proxy ou d'autonégociation ethernet au niveau de la machine ipcop.

Si le swap est en cours d'utilisation quand le système ralentit ou si au reboot de l'ipcop, cela fonctionne plus vite, de grosses chances que ce soit lié au proxy (la table des objets cachés n'a pas encore eu le temps de grossir)

Que ce soient des postes W98 n'est pas terrible mais ne devrait pas causer de problèmes de surf web (mis à part le fait que windows98 et la version d'internet explorer correspondante ne sont plus maintenus, donc coté sécurité c'est plus que limite). Certainement qu'il vaudrait mieux installer Firefox (il me semble que la 2.0 s'installe sur 98) et n'utiliser que cela, histoire d'avoir un premier niveau de protection à jour en attendant de remplacer si c'est possible par une distrib linux légère pour ces postes (si l'utilisation qui en est faite le permet).

[michauko]

Merci pour l'explication du problème et l'explication du cas windows sur le sujet

Et ma belle prose pour rien (si ce n'est que le commentaire concernant cette règle est quand même louche). J'explique :
Oui, j'ai finalement vu que c'était isolé à une pièce, j'ai gentiement court-circuité tout ce que je trouvais pour le voir. Je pense finir à la hache le switch à 2 balles qui est la source de ces lenteurs.
Il est à moitié HS et au lieu de ne pas fonctionner du tout, il génère n'importe quoi. Grrrrr !!!!!!

Donc maintenant, ça y est, ça marche et je vais réactiver la règle NEWNOTSYN en surveillant un peu au début. Dommage que j'ai d'abord regardé les logs avant de soupçonner un switch...

J'espère que mon post aura au moins servi à expliquer 2/3 choses sur cette règle pour ceux qui se demanderaient

Encore merci pour les explications - content d'avoir trouvé ce forum grâce à google et "NEW not SYN?"