Forum Linux.noyau iptables sur 2.6.9 un peu trop statefull à mon goût

Posté par fasthm le 07 décembre 2006 à 10:53.

Étiquettes :

déc.

2006

Bonjour,

que voilà une bien étrange situation, sur une RHEL4 en noyau 2.6.9
(bon, en fait une scientific linux SL4.3, c'est-à-dire une RHEL4 recompilée) :

- un client A boote, et winbind se connecte à un serveur LDAP B,
- tout fonctionne,
- le client A reboote et la connexion à B échoue lamentablement,
- je relance presque aussitôt winbind sur A, échec de la connexion,
- j'attends quelques minutes, relance winbind, et la connexion se fait.

Explication (mais pas solution) :
- premier démarrage,
- la connexion winbind est la première connexion tcp établie par A,
- le port source est tcp:32770,
- iptables sur le serveur mémorise cette connexion comme active,
- tout fonctionne,
- A redémarre,
- winbind est toujours la première connexion tcp établie par A,
- elle utilise encore (et systématiquement) le port source 32770
(ça me surprend beaucoup, je pensais qu'il y avait un peu
d'aléa dans le choix du port source),
- iptables sur B reçoit donc un SYN venant de A,
- B reconnait ce SYN comme faisant partie de la connexion
établie par A lors de son précédent boot (la session a persisté),
- B renvoie un ACK, et pas un SYN/ACK,
- A reçoit donc un ACK, son iptables se dit "mais c'est quoi ce paquet
pourri qui ne correspond à rien ?" et le jette,
- en conséquence de quoi la connexion échoue.

Bref, c'est un peu déconnant tout ça.

Donc mon problème, c'est : que faire de tout ça ?
Pourquoi toujours le port 32770 comme premier port ?
Pourquoi B associe t'il l'initiation de la seconde connexion à la première connexion ?

# une hypothese

Posté par NeoX le 07 décembre 2006 à 12:58. Évalué à 1.

1°) Donc mon problème, c'est : que faire de tout ça ?
2°) Pourquoi toujours le port 32770 comme premier port ?
3°) Pourquoi B associe t'il l'initiation de la seconde connexion à la première connexion ?

pour le 3°)
B n'a pas vu que A etait deconnecté (timeout ou autre)
du coup quand A se reconnecte, B lui repond "merci tu etais deja connecté" et A ne comprend pas le message car pour lui c'est la premiere connexion.
- [^] # Re: une hypothese
  
  Posté par Toto le 07 décembre 2006 à 16:47. Évalué à 1.
  
  Une solution pour corriger ce probleme serait d'interdire les demande de connexion sur une connexion deja existante, et si un paquet SYN arrive, dire a l'hote de fermer la connexion.
  De mémoire (pas touché a iptables depuis qq tps) ca donnerais un truc dans ce genre
  
  iptables -A INPUT -m state --state ESTABLISHED,RELATED -j REJECT --reject-with tcp-reset
  
  Apres faut voir si wondbind va relancer une demande de connexion apres..
  - [^] # Re: une hypothese
    
    Posté par dbontemps le 07 décembre 2006 à 17:06. Évalué à 1.
    
    la règle me semble suspecte : elle risque de tout rejeter alors qu'il ne faudrait rejeter que les demandes de nouvelles connexions. Il me semble qu'il faut rajouter -p tcp --syn (ou qqc d'approchant)
    
    iptables -A INPUT -p tcp --syn -m state --state ESTABLISHED,RELATED -j REJECT --reject-with tcp-reset
    - [^] # Re: une hypothese
      
      Posté par Toto le 07 décembre 2006 à 17:15. Évalué à 1.
      
      oui effectivement, j'ai oublié le -p tcp --syn (a vouloir aller trop vite, on se retrouve a tout couper ;))
      
      Apres il faut bien entendu l'adapter a l'exsitant en ajouant le filtrage source / destination etc.
      
      Sinon, pour les autres question, j'ai pas trop de réponse, et c'est vrai que toujours utiliser le meme port source me parait etrange
  - [^] # Re: une hypothese
    
    Posté par fasthm le 07 décembre 2006 à 17:39. Évalué à 2.
    
    Dans les faits, avec la correction suggéré dans le commentaire ci-dessous,
    j'obtiendrai le résultat que j'ai déjà : fermeture de la connexion de winbind.
    
    Et bien entendu, winbind ne retente pas la connexion.
    
    Mais en fait je me dis que je ferai mieux de me pencher sur un moyen de
    relancer winbind tant que ça échoue, plutot que de m'acharner sur iptables.
    La gent féminine, pas la "gente", pas de "e" ! La gent féminine ! Et ça se prononce comme "gens". Pas "jante".
    - [^] # Re: une hypothese
      
      Posté par fasthm le 07 décembre 2006 à 17:40. Évalué à 2.
      
      Heu, pas ci-dessous, mais au dessus (ajouter le SYN).
      La gent féminine, pas la "gente", pas de "e" ! La gent féminine ! Et ça se prononce comme "gens". Pas "jante".
- [^] # Re: une hypothese
  
  Posté par fasthm le 07 décembre 2006 à 17:35. Évalué à 2.
  
  Tout à fait d'accord avec ton explication, ce qui me chagrine c'est que je pensais
  que le firewall utilisait plus de paramètres que (machine source, port source) pour
  décréter qu'un paquet appartient à une connexion existante.
  
  En fait (mais je n'ai rien sous la main pour vérifier là tout de suite), il utilise peut
  être la tcp window pour vérifier que le paquet est bien dedans... mais comme
  une unique connexion ldap c'est très peu de traffic, ça doit tomber dedans à
  chaque fois.
  
  Bref, je suis bien coincé... que faire, ouvrir un certain nombre de connexions
  tcp bidons pour mettre un peu de hasard dans tout ça ? Pour une méthode de
  goret, ça c'est une méthode de goret :-)
  La gent féminine, pas la "gente", pas de "e" ! La gent féminine ! Et ça se prononce comme "gens". Pas "jante".

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.