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

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
0
31
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  . É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  (site Web personnel) . Évalué à 5.

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

    Système - Réseau - Sécurité Open Source

    • [^] # Re: -j DROP

      Posté par  (site Web personnel) . É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  . Évalué à -2.

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

  • # C'est faux :)

    Posté par  . É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  . Évalué à 3. Dernière modification le 01/02/13 à 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  . Évalué à 1. Dernière modification le 01/02/13 à 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  . É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  . Évalué à 1.

        Ça n'explique pas pour le DROP ne donne pas le résultat escompté.

        • [^] # Re: solution trouvée

          Posté par  . É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  . É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  . É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  . É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  . É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 à ceux qui les ont postés. Nous n’en sommes pas responsables.