Parefeu + bridge + filtre

Support Debian
#1

Bonjour,
je suis un petit nouveau sur le forum. je me débrouille pas trop mal en général avec debian/raspbian (je collectionne les PI depuis un an -c’est fou ce qu’on peut s’amuser avec!) et je suis avec un os qui me casse les dents:
:030 .
voila:

wan <—> livebox <–nat–> (ip1:xx)PI(ip1:xx) <---->(ip2:xx)debian(samba)

je voudrais construire “iptables rule set” qui sera ds la PI et qui ferait:

  • n’accepte du TCP que sur ip1:xx et DROP le reste (ça je sais faire pas de soucis)
  • si la requette HTTP qui vient du wan et arrive sur ip1:xx est de la forme monsite/MOTCLE/yyyy alors FORWARD sur ip2:xx par la même interface réseau (ip1)
  • si le GET ne contient pas le mot clé MOTCLE alors DROP (le MOTCLE est fixe)
    et là je cale depuis 15 jours avec -recent, -string , etc. :119

à votre bon coeur ! je me désespère… :017

si je trouve de mon coté, je posterai la solution, ça peut servir…

#2

Je ne comprends pas. Que représente la double flèche notée “nat” ?
Pourquoi y a-t-il la même ip1:xx des deux côtés de PI ?

  1. Tu veux dire DNAT au lieu de FORWARD.
  2. Ce n’est pas possible. Toutes les opérations de NAT appliquées à une connexion se décident lors du passage du premier paquet. On ne peut plus changer en cours de route sinon cela casserait la connexion. Or le premier paquet d’une connexion HTTP ne contient pas l’URL.
    Une solution est de faire la redirection par un reverse proxy HTTP.

C’est faisable avec la correspondance string dans la chaîne qui va bien. Si la connexion a été redirigée, ce sera dans la chaîne FORWARD. Mais ce n’est pas propre : la connexion déjà établie va être silencieusement coupée sans qu’aucun des deux côtés (client et serveur) n’en soit averti.

PS : où est le bridge mentionné dans le titre ?

#3

Grand merci pour prendre ma question !
je comprends que je suis trop dans mon sujet et du coup j’en oubli d’être vraiment précis, je vais essayer de me corriger.

[quote=“PascalHambourg”]Je ne comprends pas. Que représente la double flèche notée “nat” ?
Pourquoi y a-t-il la même ip1:xx des deux côtés de PI ?[/quote]
Le NAT est fait par la LB vers trois ports:

  • 2 vers le NAS (1 OpenVPN + 1 PPTP)
  • 1 vers le PI (celui que j’ai voulu représenter avec ma double flèche) ip1:xx
    Le PI n’a qu’un seul NIC et qu’une seule IP

[quote=“PascalHambourg”]1) Tu veux dire DNAT au lieu de FORWARD.
2) Ce n’est pas possible. Toutes les opérations de NAT appliquées à une connexion se décident lors du passage du premier paquet. On ne peut plus changer en cours de route sinon cela casserait la connexion. Or le premier paquet d’une connexion HTTP ne contient pas l’URL.
Une solution est de faire la redirection par un reverse proxy HTTP.[/quote]
Oui c’est bien là que j’ai mon problème, ce que je voudrais c’est:

Quand le PI (ip1:xx) reçoit monsite:xx/MOTCLE/??? il “FWD” ou “re NAT” la requette sur ip2:XX (du coup par le même NIC puisqu’il n’en a qu’un)

Quand le PI (ip1:xx) reçoit monsite:xx[/???/???/] sans MOTCLE bien placé alors il DROP

l’idée que j’ai est d’utiliser le rule set du script ci-dessous (il fonctionne pour le DROP je cherche à l’adapter pour “FWD” or “re-NAT”):

#!/bin/bash

création de notre chaîne w00t :

iptables -N w00t

redirige les paquets TCP sur notre chaîne :

iptables -A INPUT -p tcp -j w00t

recherche du premier SYN et création de la liste :

iptables -A w00t -m recent -p tcp --syn --dport 80 --set

recherche du paquet SYN,ACK et mise à jour la liste :

iptables -A w00t -m recent -p tcp --tcp-flags PSH,SYN,ACK SYN,ACK --sport 80 --update

recherche du paquet ACK et mise à jour la liste

iptables -A w00t -m recent -p tcp --tcp-flags PSH,SYN,ACK ACK --dport 80 --update

recherche de la signature de DFind dans le prenier PSH+ACK.

Si elle est présente, on DROP.

On supprime la liste pour ne pas filtrer les paquets suivants

iptables -A w00t -m recent -p tcp --tcp-flags PSH,ACK PSH,ACK --dport 80 --remove
-m string --to 70 --algo bm --string “GET /w00tw00t.at.ISC.SANS.” -j DROP

et c’est là que cale lamentablement :think:

#4

Je répète : iptables ne permet pas de rediriger une connexion déjà établie. Imagine le topo : la nouvelle destination voit débarquer un segment TCP sans avoir établi la poignée de main initiale. Elle va le jeter sans autre forme de procès.

Au passage, je ne vois pas l’intérêt de la correspondance “recent” dans ton filtrage.

#5

C’est grace à cette correspondance je pense pouvoir filtrer.

je laisse passer (en re-NAT) vers ip2:xx pour la connection et le handcheck se passe bien entre le client et le serveur cible (ip2) et jusqu’à ce que le paquet qui contient le MOTCLE passe, s’il passe on continue, si’il n’est pas là je DROP au niveau du PI

c’est impossible ?

#6

C’est-à-dire ? Qu’apporte la correspondance “recent” à ton filtrage ?

C’est faisable, mais ce n’est pas ce que tu écrivais avant.

Pour la redirection :

Ne pas oublier d’activer le forwarding IP (ip_forward=1) évidemment.
Pour le blocage, on fait l’hypothèse raisonnable que le GET et le motif cherché dans le chemin de l’URL sont dans le même segment. Ce n’est pas forcément vrai, rien n’empêche l’émetteur de transmettre le GET sur deux segments consécutifs mais c’est peu probable. J’ai repris ta correspondance string telle quelle. On marque le paquet s’il contient “GET” et on le bloque s’il ne contient pas le motif.

iptables -t mangle -A FORWARD -d ip2 -p tcp --dport p2 -m string --to 70 --algo bm --string "GET /" -j MARK --set-mark 1 iptables -t mangle -A FORWARD -m mark --mark 1 -m string --to 70 --algo bm ! --string "GET /w00tw00t.at.ISC.SANS." -j DROP
Il reste un dernier point à traiter : le routage triangulaire. Si on ne fait rien, le serveur à l’adresse ip2 va envoyer ses paquets de réponse directement au routeur par défaut du LAN, pas au PI à l’adresse ip1. Ces paquets vont donc arriver au routeur avec l’adresse source ip2 et le routeur ne les reconnaîtra pas comme des réponses aux paquets qu’il a transmis à l’adresse ip1. Ses réactions peuvent varier mais le résultat sera le même : ça ne marchera pas.

Il y a deux solutions possibles :

  • Une règle iptables SNAT sur les paquets redirigés vers le serveur ip2, afin que ce dernier lui renvoie les réponses. Avantage : simple. Inconvénient : le serveur ip2 ne voit pas l’adresse source originelle remplacée par ip1.

  • Sur le serveur ip2, forcer le routage des paquets de réponse via ip1. Cela peut être en définissant ip1 comme passerelle par défaut pour le serveur au lieu du routeur, et tous les paquets destinés à l’extérieur passeront par le PI. Ou bien en faisant un routage spécifique des paquets ayant ce port source. Pour un système Linux, ça se fait avec [mono]iptables -j MARK[/mono] et [mono]ip rule[/mono]+[mono]ip route[/mono].

Dans les deux cas, il y a un risque que le PI envoie des paquets ICMP “redirect” pour dire au serveur d’envoyer ces paquets directement au routeur. Si cela se produit, il faudra soit désactiver (par sysctl) ou bloquer (par iptables) l’envoi d’ICMP redirect sur le PI, soit désactiver ou bloquer la réception d’ICMP redirect sur le serveur.

Un reverse proxy serait beaucoup plus fiable et sans ces inconvénients…

#7

Merci Beaucoup,

La manip que tu as décrite fonctionne impec, les requêtes HTTP passent grâce au MOTCLE et les autres tombent, c’est super !

par contre je ne sais pourquoi, mais quand la requête pointe sur un fichier (à downloader) là ça coince, il ne se passe rien coté client.
Je vais chercher à comprendre coté serveur car je ne suis vraiment pas familier des manips mise en cause dans les downloads - je pensait naivement que c’était du tcp basique sans autre procès.

merci beaucoup vraiment !

#8

Le téléchargement d’un fichier par HTTP n’est pas fondamentalement différent de celui d’une page HTML. Cela passe aussi une requête GET ou POST. Si c’est une requête GET dont le chemin de l’URL ne contient pas le motif, elle est bloquée par tes règles.

#9

j’ai dégainé wireshark. ça a l’air de bien de passer dans les deux sens, mais il y a des “protocole IPA” avec des “malformed packet” qui viennent du client, je vais essayer avec un autre client…

Après essai avec un autre client non GSM, c’est idem. Http ok mais pas le download. Je cherche a comprendre avec wirehark.

#10

bon j’ai finalement réussi à ce que ça fonctionne:

  • avec les iptables
  • et aussi avec nginx comme reverse proxy

pour le même genre de manip, je conseille quand même nginx qui est très facile à paramétrer. Pascal a bien raison !!!

merci beaucoup !!!