[Iptables] À la recherche d'informations sur --string

Support Debian
#1

Bonjour,

Je suis à la recherche d’informations à-propos du match ‘–string’ …
En fait, je me pose la question de me servir correctement de ce match pour filtrer toute requête contenant "CONNECT *.mxmail.netease.com:25"
J’ai créé une règle basique tenant compte juste de “CONNECT”, mais ce que j’aimerais savoir absolument est, s’il est possible d’avoir l’usage d’expressions régulières, tel que *, etc …

iptables -A INPUT -p tcp -m string --to 70 --algo bm --string "CONNECT " -j DROP

Voili, voilou …

netfilter.org/documentation/ … tml#ss3.18

De fait, j’ai peur que ce soit une fausse bonne idée ? non ?!

#2

D’après la page de manuel d’iptables, je n’ai pas l’impression que la correspondance string supporte les expression rationnelles ou les caractères génériques.
Quelle est la finalité de ce filtrage ?

#3

Comme je l’ai écrit dans mon premier post, Pascal, filtrer toute requête ayant ce style : "CONNECT *.mxmail.netease.com:25.

Ce sont des requêtes qui essayent d’utiliser le mod_proxy du serveur web.
Hors, si j’ai bien compris, cela n’existe pas pour nginx, n’est-ce pas ?!

Quoiqu’il en soit, lui répond avec une erreur 400 - mauvaise requête.

L’idée de base étant de le filtrer avant que cela arrive au niveau du serveur web, ni plus ni moins.
Mais là encore, c’est peut-être une fausse bonne idée !?

Comme on le lit dans le log d’accès de nginx :

Ensuite, je me dis que c’est un faux problème, puisque je réalise - là, maintenant - que les tentatives de connexion/redirections ont toutes la valeur $http_user_agent à vide, et que j’ai écris une règle dans le contexte ‘http’ de nginx pour bloquer ceux-ci quand ils sont vides - mais je suis toujours au niveau de la couche logicielle de nginx, et non pas réseau, n’est-ce pas ?!

#4

J’avai compris. Ma question était en substance : pourquoi, dans quel but ? Tu y réponds dans la suite.

[quote=“PengouinPdt”]
Ce sont des requêtes qui essayent d’utiliser le mod_proxy du serveur web.
Or, si j’ai bien compris, cela n’existe pas pour nginx, n’est-ce pas ?![/quote]
Je n’en sais rien, je ne connais pas nginx. Il semble pouvoir faire office de proxy. S’il peut fonctionner en proxy direct, il supporte la méthode CONNECT.

[quote=“PengouinPdt”]L’idée de base étant de le filtrer avant que cela arrive au niveau du serveur web, ni plus ni moins.
Mais là encore, c’est peut-être une fausse bonne idée !?[/quote]
Je pense que c’est une fausse bonne idée. Il s’agit d’un filtrage de la couche applicative (couche 7 du modèle OSI) qui devrait être réalisé au niveau de l’application et non d’un filtre de paquet. Il y a plusieurs difficultés techniques à réaliser ce type de filtrage avec un filtre de paquets comme iptables, par exemple :

  • Si le motif recherché est à cheval entre deux paquets successifs, la correspondance qui ne porte que sur des paquets individuels ne fonctionnera pas.
  • Le but est de filtrer uniquement la méthode de la requête HTTP. Or la correspondance s’appliquera aussi si le motif se trouve ailleurs dans la communication, comme ce fut nécessairement le cas quand tu as écrit ce message, créant un faux positif. Il n’est pas trivial de dire à iptables de ne regarder que dans le 3e paquet de la connexion envoyé par le client (et ce n’est même pas suffisant si le keep-alive est activé, une nouvelle requête pouvant se trouver n’importe où dans le flux de la connexion).
  • Le résultat sera que le paquet contenant le motif est bloqué. Le client peut en être averti si la règle utilise la cible REJECT au lieu de DROP, mais le serveur que tu veux protéger n’en saura rien et pour lui la connexion restera ouverte, en attente de données, occupant inutilement des ressources jusqu’au time-out.

Si ton serveur web n’est pas censé servir de proxy, il suffit d’interdire la méthode CONNECT et c’est tout.

#5

quote="PascalHambourg"
Si ton serveur web n’est pas censé servir de proxy, il suffit d’interdire la méthode CONNECT et c’est tout.[/quote]

Normalement, c’est le cas, puique j’ai la règle 444 suivante :

Merci de tes éclaircissement, et d’éclaircir ce que je présupposé !