Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

Redirection de paquets TCP + masquerade

NothusJG

Bonjour à tous,

Je teste pour l'entraînement et apprentissage, quelques notions avec ip route + iptables. Problème : en plus d'être coincé dans mes recherches, je pense que je n'ai pas les "bons termes" (et/ou la bonne approche) pour la recherche. Si une bonne âme pouvait m'aiguiller...

J'ai deux postes sur le réseaux, tous deux sous Ubuntu (server + desktop) :
- le serveur (192.168.1.43) dispose d'une instance MariaDB dont l'écoute n'est qu'en local (127.0.0.1) sur le port 3306
- le client (192.168.1.30) doit y accéder par un autre port (admettons 3307) : le serveur doit donc récupérer la demande et faire les opérations réseaux de routage.

Pour me faciliter la vie (parce que le dépit m'a rapidement pris...), plutôt de passer par MariaDB, j'ai temporairement pris une instance Web avec Python :

python -m http.server

... qui écoute sur le port 8000 et toute interface. Le principe est le même que précédemment, mais la console me renvoie les requêtes...

Pour l'instant, j'ai ceci concernant Python - avec ce que j'en comprends :

$ iptables -t nat -A PREROUTING -i enp0s3 -p tcp --dport 80 -j REDIRECT --to-port 8000
# ---> je redirige mes paquets reçus du port 80 vers le port 8000 en TCP 

$ iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -j MASQUERADE	
# ---> la "masquarade" pour les IP qui arrive (prenant l'IP de la machine qui traite la demande) 

$ iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -j SNAT --to-source 192.168.1.43
# ---> le postrouting qui "transforme" l'IP de source (celle d'où vient le paquet) par l'adresse de la machine qui traite la demande

... en oubliant pas d'activer :

sysctl -w net.ipv4.conf.enp0s3.route_localnet=1

Lorsque du client je demande http://192.168.1.43:80 tout va bien : l'instant en écoute de Python sur le serveur reçoit sur le port 8000 les paquets et l'échange se fait.

MAIS Python reçoit les paquets avec l'IP du client. Donc si je veux par exemple, faire la même chose avec MariaDB (mon client SQL sur ma machine client), j'ai un refus car le transfert ne se fait pas vers localhost.

Mon souhait en résumé :
[center]

CLIENT : envoie une demande sur le port XXX de l'IP A
SERVEUR : reçoit une demande sur le port XXX de l'IP A
SERVEUR : traite la demande avec ses tables, et modifie la demande du port XXX vers YYY et de l'IP A vers son IP 127.0.0.1 (sur l'interface qui va bien ?)
SERVEUR : le logiciel qui a bindé sur 127.0.0.1:YYY reçoit la demande, la traite, envoie une réponse
SERVEUR : la réponse est remise avec l'IP d'origine de la demande
CLIENT : reçoit la réponse

[/center]

J'imagine bien que je ne dois être très clair, j'en suis désolé...

Toute piste, explication ou solution vous honorera de ma gratitude éternelle (c'est peu je sais... 😉)

Bonne fin d'après-midi,

Julien.

bruno

Bonjour,

Je ne vais vraiment répondre à la question mais indiquer ce qui me semble aberrant dans ta demande 😉
Tes deux machines sont sur le même sous-réseau privé : 192.168.1.43 et 192.168.1.30. Elle peuvent donc communiquer directement entre elles, nul besoin de routage ou de règles DNAT/SNAT/MAsquerade compliquées avec iptables.

127.0.0.1 comme toute adresse de la plage 127.0.0.0/8 est réservé à l'interface de bouclage (lo). Lorsqu'un service n'est en écoute que sur l'interface de bouclage (127.0.0.1) c'est justement pour le rendre inaccessible de extérieur. Si un service doit être accessible depuis une autre machine du réseau il faut et il suffit de le mettre en écoute sur une interface autre que 127.0.0.1 (lo). Par exemple dans le cas de ton serveur MariaDB, il suffit de modifier la configuration de MariaDB pour qu'il soit en écoute sur 192.168.1.43 et de configurer des utilisateurs mysql pour qu'il soient autorisés à se connecter depuis une autre adresse que localhost.

NothusJG

Bonjour Bruno,

Merci beaucoup de ton message. Oui effectivement, ça paraît aberrant. J'entends bien pour l'interface de bouclage, et c'est d'ailleurs le fond de ma question : peut-on contourner ?

Pour détailler le "pourquoi" : laisser MariaDB en écoute local, et utiliser des règles de routage pour autoriser ou non l'accès au binding. Cela évite de toucher à la config de MariaDB et de redémarrer l'applicatif... Surtout dans le cas où tu supervises un parc de machines virtuelles type cluster où l'environnement évolue beaucoup (pour l'exercice).

De ce que j'en comprends, mon "problème" (s'il a une solution ?) serait de """router""" / transférer les paquet entre mon interface Ethernet (enp0s3) et le local (lo) ? Possitble (via l'OS ou un applicatif quelconque) ? Où suis-je encore à côté de la plaque ?

bruno

À ma connaissance tu ne peux pas router des paquets entre une adresse 127.0.0.0/8 et une autre plage et je pense que ce serait une grosse faille de sécuirté si c'était possible. D'après la RFC 1122 ces adresses ne doivent jamais être utilisées en dehors de la machine locale :

RFC 1122 a écrit (g) { 127, <any> }

Internal host loopback address. Addresses of this form
MUST NOT appear outside a host.

Maintenant l'interface de bouclage, bien que virtuelle, est une interface comme les autres. On peut donc lui ajouter des IP dans la plage 192.168.1.0/24 par exemple. Mais cela ne résoudra pas ton problème puisque MariaDB est en écoute sur 127.0.0.1 ce qui le rend inaccessible de l'extérieur et c'est fait pour (bis).

NothusJG a écritPour détailler le "pourquoi" : laisser MariaDB en écoute local, et utiliser des règles de routage pour autoriser ou non l'accès au binding. Cela évite de toucher à la config de MariaDB et de redémarrer l'applicatif... Surtout dans le cas où tu supervises un parc de machines virtuelles type cluster où l'environnement évolue beaucoup (pour l'exercice).

Faire les modifications que j'ai indiqué est bien plus simple que des bidouillages sur la configuration réseau et le routage qui de toute façon ne fonctionneront pas. De toute façon si MariaDB tourne dans une machine virtuelle (ou un conteneur) il est déjà accessible de l'extérieur, sinon je ne vois pas l'interêt…

DonutMan75

Bonsoir,
effectivement comme dit Bruno le plus simple aurait été de modifier la configuration de MariaDB.
Une solution possible si on s'interdit cela et qu'on veut tout de même que les utilisateurs sur 192.168.1.30 aient accès au serveur MariaDB sur 192.168.1.43, serait d'utiliser ssh et le port forwarding.
Voici un lien qui explique cela : https://www.ssh.com/ssh/tunneling/example

Bonne soirée,

Donut

NothusJG

Merci de vos retours ! Oui le plus simple c'est la modification de MariaDB, mais j'aime tester pour mieux comprendre 🙂

Pour SSH, j'ai trouvé la solution entre temps, et je teste ce weekend.

Dans l'attente, j'ai trouvé ceci (où il y a d'ailleurs la solution SSH), la solution de 'Vame' :
https://unix.stackexchange.com/questions/156495/ip-forwarding-to-remotely-connect-to-a-socket-listening-to-localhost-only

... En soi j'ai ma requête qui va au bon endroit : c'est déjà ça.

Bruno merci pour la référence (RFC 1122), je vais l'étudier. Tu as raison, je pense que c'est une mauvaise idée en terme de sécurité.

Encore merci.

Bonne journée à vous.

NothusJG

Note pour d'éventuelles personnes qui tomberaient sur cette page lors d'une recherche.

Pourquoi est-ce une très mauvaise idée en terme de sécurité, comme déjà indiqué par Bruno et DonutMan75...

Même en soi le forward simple vers l'adresse de localhost depuis un réseaux privé est problèmatique, car cela implique sans le dire ouvertement dans la configuration, le changement """discret""" (du moins si on le sait pas) d'une configuration au niveau du kernel :

net.ipv4.conf.enp0s3.route_localnet

... à la valeur 1.

Or :

In essence it tells the kernel not to treat local routing for as a danger and refuse it. As long as net.ipv4.ip_forward is 0 you shouldn't need to change route_localnet. In most cases you only need this when you do some PREROUTING and/or FORWARD with iptables.

https://security.stackexchange.com/a/137603

Voir aussi : log_martian dans le même registre (enregistrer les paquets "martiens").

En testant (variation de la valeur), on s'aperçoit bien que la remise à 0 de ce paramètre, bloque le forward même s'il est déclaré autorisé par ailleurs (car on reste dans le cas cité, sur des classes d'IP privées) :

root@ubuntu-pam:/home/julien# sysctl -w net.ipv4.conf.enp0s3.route_localnet=0
net.ipv4.conf.enp0s3.route_localnet = 0
root@ubuntu-pam:/home/julien# sysctl -w net.ipv4.conf.enp0s3.route_localnet=1
net.ipv4.conf.enp0s3.route_localnet = 1

Si une machine arrive à obtenir une adresse locale ou en usurper une, l'impact sera immédiat et la machine extrêmement vulnérable. A ne faire donc, qu'avec une connaissance parfaite des risques et l’impossibilité de toute autre solution...

bruno

Nous sommes d'accord 😉
Je précise que la doc du noyau indique :

https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt a écritroute_localnet - BOOLEAN
Do not consider loopback addresses as martian source or destination
while routing. This enables the use of 127/8 for local routing purposes.
default FALSE

C'est justement parce que l'on a une connaissance parfaite des risques qu'il ne faut jamais l'activer. Cela rend potentiellement accessible de l'extérieur tous les services qui sont en écoute sur l'interface de bouclage : gestion des imprimantes (cups), cache DNS local (dnsmasq, systemd-resolved) etc.

Je ne vois aucun cas d'usage de cette option et AMHA il y a toujours une autre solution.