Forum Linux.débutant iptables string match ne fonctionne pas

Posté par ratw3 le 31 janvier 2013 à 16:38. Licence CC By‑SA.

Étiquettes : aucune

jan.

2013

Bonjour,
J'essaye de fermer le port en connexion entrante/sortante si certaines chaines de caractère sont détectés.

Cela ne fonctionne pas… je ne comprend pas pourquoi, si l'un de vous a une idée je suis prenneur.

~# iptables -A INPUT -m string --string "test" -j DROP  --algo bm
~# nc -l 3456

(sur un autre terminal)

~$ telnet 192.168.152.134 3456
Trying 192.168.152.134...
Connected to 192.168.152.134.
Escape character is '^]'.
test

ddddd

La connexion ne se ferme pas après la chaine test et la chaine ddddd s'affiche bien sur le terminal…

Je ne vois pas ce qui ne fonctionne pas.

Merci d avance pour votre aide.

# plouf

Posté par chaispaquichui le 31 janvier 2013 à 16:46. Évalué à 1.

Totalement à pouf : parce que ton telnet envoie les lettres une à une et non par le string complet en une fois ?
# -j DROP

Posté par nono14 (site web personnel) le 31 janvier 2013 à 17:34. Évalué à 5.

ça droppe le paquet, pas la connexion je pense.

Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités
- [^] # Re: -j DROP
  
  Posté par Sébastien Maccagnoni (site web personnel) le 31 janvier 2013 à 18:47. Évalué à 1.
  
  C'est possible.
  
  ratw3 : de l'autre côté, c'est quoi qui est en écoute ?
  Si tu fais un test avec "nc -l -p " en écoute, vois-tu la chaîne "test" arriver à destination ?
# T'es obligé de crier comme ça ?

Posté par totof2000 le 31 janvier 2013 à 19:20. Évalué à -2.

EST-CE QUE JE CRIE, MOI ????
- [^] # Re: T'es obligé de crier comme ça ?
  
  Posté par NeoX le 31 janvier 2013 à 20:32. Évalué à 3.
  
  j'ai corrigé son post,
  c'est les # du shell en debut de ligne qui genere un titre
  merci qui, merci markdown
# C'est faux :)

Posté par ratw3 le 01 février 2013 à 09:59. Évalué à 1.

Bonjour,

Non les caractüres ne sont pas envoyés 1 a 1 entre le telnet et netcat.
En effet il n'apparaissent dans netcat qu'une fois avoir appuyé sur "Return"

Donc à mon sens le probleme ne vient pas de la.

De même j ai également testé pour bloquer une connexion SSH sur un port non autorisé (en sortie)
(via la string "OpenSSH") ca ne fonctionne pas, le packet n'est pas droppé et la connexion nest pas bloquée, j ai fais ce test sur Ubuntu et CentOS même résultat.

Qu en pensez vous ?
- [^] # Re: C'est faux :)
  
  Posté par NeoX le 01 février 2013 à 13:20. Évalué à 3. Dernière modification le 01 février 2013 à 13:23.
  
  qu'il va falloir jouer du wireshark pour aller voir comment se passer une ouverture de session, et si la chaine "OpenSSH" passe bien dans les paquets
  
  en plus tu ne dis pas à iptables de fermer la connexion mais simplement de dropper le paquet.
  
  donc au pire si ca marche,
  - ta connexion reste ouverte (dddd passe bien)
  - mais tu ne vois jamais arriver test
# solution trouvée

Posté par ratw3 le 01 février 2013 à 17:51. Évalué à 1. Dernière modification le 01 février 2013 à 22:01.
Pour ceux qui cherchent :)
```
iptables -A INPUT -p tcp --sport 443 --tcp-flags ACK ACK -m string --string "OpenSSH" -j REJECT --reject-with tcp-reset --algo bm
```
Dans le cas présent ca filtre une connexion SSH encapsulée dans un proxy SQUID et Pan ! :D
- [^] # Re: solution trouvée
  
  Posté par NeoX le 01 février 2013 à 22:02. Évalué à 2.
  
  à noter que ce qui change par rapport à ta ligne precedente c'est surtout
  
  -j REJECT --reject-with tcp-reset
  - [^] # Re: solution trouvée
    
    Posté par Kerro le 02 février 2013 à 02:36. Évalué à 1.
    
    Ça n'explique pas pour le DROP ne donne pas le résultat escompté.
    - [^] # Re: solution trouvée
      
      Posté par reno le 02 février 2013 à 13:01. Évalué à 1.
      
      DROPer un paquet dans une connection TCP: je me pose une question la regle du firewall elle va être jouée avant ou après le ACK?
      Autrement il y aurait un retry non?
      
      Bref un bon coup de Wirshark s'impose..
    - [^] # Re: solution trouvée
      
      Posté par NeoX le 02 février 2013 à 13:11. Évalué à 2.
      
      parce qu'autant que je sache, dans sa ligne avec DROP il ne faisait que dropper le paquet,
      il ne disait pas de faire un reset de la connexion (d'ailleurs est-ce possible de faire un drop avec un reset ?)
      - [^] # Re: solution trouvée
        
        Posté par Kerro le 03 février 2013 à 14:11. Évalué à 2.
        
        Ça n'explique rien.
        Si paquet ne passe pas, pourquoi a-t'on les données à l'autre bout ?
        Il peut être renvoyé 1000 fois, il sera droppé 1000 fois.
        
        [^] # Re: solution trouvée
        
        Posté par NeoX le 03 février 2013 à 14:24. Évalué à 2.
        
        il ne dit pas que le paquet "test" passe,
        il dit juste
        
        La connexion ne se ferme pas après la chaine test
        et la chaine ddddd s'affiche bien sur le terminal…
        
        ce qui correspond bien à un drop du paquet qui contient "test"
        mais un laisse passer sur "ddddd"
        
        [^] # Re: solution trouvée
        
        Posté par ratw3 le 04 février 2013 à 16:13. Évalué à 1.
        
        Je confirme le paquet avec le -j DROP na jamais ötö droppö en quoique ce soit… (puisqu il apparait des deux coté netcat/telnet)

Suivre le flux des commentaires

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

EST-CE QUE JE CRIE, MOI ????