redirection de ports avec pf

Le
Thomas vO
bonjour,

j'ai un serveur que je voudrai transférer petit à petit, que je p=
eux pas
vraiment toucher pour d'obscures raisons

il est en 192.168.100.10, et je ne peux pas toucher son IP. dessus, j'ai
plein de services, que je voudrais transférer (et éclater) sur d'=
autres
bécanes.

donc, je me dis que le moment est venu de tester pf en vrai. je monte
une petite machine avec openbsd, dont l'objectif est juste de récupÃ=
©rer
l'ip .10 (plus tard) et de faire du forward de port, d'abord tout sur la
même machine, puis diviser les services différents sur des machin=
es
différentes

je me retrouve donc avec le fichier de conf pf suivant :

--
set skip on lo

# interface reseau
if = "em0"

# reseaux locaux
our_networks = "{ 10.0.0.0/8, 172.30.112.0/20, 192.168.0.0/16 }"

# pour le forward des ports : machines
gw_addr = "192.168.100.13"
http_srv = "192.168.100.10"

# on laisse tout sortir, keep state
pass out all keep state

# By default, do not permit remote connections except from our networks
block in on ! lo0 from any to any
pass in on $if from $our_networks to any

#pass in quick on $if proto tcp from any to $gw_addr port 80 rdr-to $http_s=
rv port 80
#pass in quick on $if proto tcp from any to $gw_addr port 443 rdr-to $http_=
srv port 443

rdr pass on $if proto tcp to port 80 -> $http_srv port 80
rdr pass on $if proto tcp to port 443 -> $http_srv port 443
--

j'ai essayé avec les deux lignes pass commentées, sans résul=
tat ; plus
exactement, le tcpdump voit passer des choses du genre (.0.50 est mon IP) :
16:13:47.635943 192.168.0.50.31788 > 192.168.100.13.80[]
16:13:47.635989 192.168.0.50.31788 > 192.168.100.10.80[]

mais rien de plus. les lignes avec rdr font des syntax error

j'ai bien pensé à activer le net.inet.ip.forwarding, et je suis a=
vec un
OpenBSD 5.0 tout frais installé.

de ce que j'ai vu comme doc, ce genre de trucs fonctionne très bien av=
ec
du NAT, mais j'ai trouvé personne qui veut le faire comme moi, sur un
réseau à plat

quelqu'un aurait une idée pour que je puisse avancer ?

merci,

--
Mais j'aime pas Metapost, j'abhorre métapost, j'y peu rien, j'suis
allergique, ça me gratouille, dans les doigts rien que d'écrire le
nom.
-+- Olivier R. in fr.comp.text.tex -+-
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Patrick Lamaizière
Le #24427631
Thomas vO :

bonjour,



Yo,

block in on ! lo0 from any to any



Pour pas un simple "block all" ? C'est de bon ton (on bloque tout), et
tu skip lo0 de toutes façons.

...

Le problème de la redirection c'est que l'adresse destination est
changée, mais pas l'adresse source. Le serveur destinataire va répondre
au client qui n'attend pas de réponse de ce serveur (pas la même ip) et
drop le paquet. La solution c'est de nater en sortie :

Quelque chose du genre :

pass in quick inet proto tcp from any to self port XXX tag TREDIRECT
rdr-to ip_du_serveur

pass out quick tagged TREDIRECT nat-to ip_du_pf

Ainsi PF va remplacer l'adresse source par la sienne, lors de la réponse
du serveur il fait l'inverse et le client n'y voit que du feu.

Inconvénient (de taille) : le serveur voit les demandes depuis le PF et
si tu as des contrôles sur l'IP ce n'est pas top, de même pour
la tracabilité. Mais ça marche et c'est simple, je suis en train de
tester cela pour rediriger les flux DNS sortants vers nos serveurs DNS
internes (pour éviter des attaques aux niveaux des clients qui changent
l'adresse des DNS)

Une autre solution serait peut-être d'utiliser route-to pour router vers
ton nouveau serveur.

Avantage : on ne touche pas au paquet, les adresse source et destination
sont conservées.

Inconvénient : la machine serveur va voir arriver des paquets qui ne
sont pas pour elle, il faut agir au niveau du pare-feu (local) pour
rediriger les paquets. Tu trouveras des exemples pour cela dans des conf
de squid en proxy transparent.

Si tu ne peux pas où ne veux pas agir au niveau du serveur en local, il
y a peut-être la possibilité de garder l'ip du serveur, mais de l'isoler
de ton réseau en ajoutant une interface et si nécessaire une machine en
tampon et de jouer sur les routes.

lan -------(iface0)PF(iface1) (route to tampon)---- machine tampon -----
serveur

Dans ce cas tu aurais des règles du genre :
pass in iface0 from any to self port XXX route-to (iface1
ip_machine_tampon)

Ce qui veut dire que tu routes les requetes vers le port XXX vers la
machine tampon, qui doit alors router vers ton serveur. Sur ton serveur
tu n'as plus qu'à configurer une route par défaut vers tampon (et
configurer le routage de celle ci). De cette manière ça peut-être
complètement transparent ama.

On peut peut-être éviter une machine tampon en ajoutant des routes à la
main, faut regarder. Je ne sais pas comment va comporter le routage avec
des IP identiques sur deux réseaux "directly connected"

Voilà, c'est l'idée je n'ai pas du tout tester les règles.
Patrick Lamaizière
Le #24427681
supersedes, manque des mots :(

Thomas vO :

bonjour,



Yo,

block in on ! lo0 from any to any



Pourquoi pas un simple "block all" ? C'est de bon ton (on bloque tout),
et tu skip lo0 de toutes façons.

...

Le problème de la redirection c'est que l'adresse destination est
changée, mais pas l'adresse source. Le serveur destinataire va répondre
au client qui n'attend pas de réponse de ce serveur (pas la même ip) et
drop le paquet. La solution c'est de nater en sortie :

Quelque chose du genre :

pass in quick inet proto tcp from any to self port XXX tag TREDIRECT
rdr-to ip_du_serveur

pass out quick tagged TREDIRECT nat-to ip_du_pf

Ainsi PF va remplacer l'adresse source par la sienne, lors de la réponse
du serveur il fait l'inverse et le client n'y voit que du feu.

Inconvénient (de taille) : le serveur voit les demandes depuis le PF et
si tu as des contrôles sur l'IP ce n'est pas top, de même pour
la tracabilité. Mais ça marche et c'est simple, je suis en train de
tester cela pour rediriger les flux DNS sortants vers nos serveurs DNS
internes (pour éviter des attaques aux niveaux des clients qui changent
l'adresse des DNS)

Une autre solution serait peut-être d'utiliser route-to pour router vers
ton nouveau serveur.

Avantage : on ne touche pas au paquet, les adresse source et destination
sont conservées.

Inconvénient : la machine serveur va voir arriver des paquets qui ne
sont pas pour elle, il faut agir au niveau du pare-feu (local) pour
rediriger les paquets. Tu trouveras des exemples pour cela dans des conf
de squid en proxy transparent.

Si tu ne peux pas, ou ne veux pas agir au niveau du serveur en local, il
y a peut-être la possibilité de garder l'ip du serveur, mais de l'isoler
de ton réseau en ajoutant une interface et si nécessaire une machine en
tampon et de jouer sur les routes.

lan -------(iface0)PF(iface1) (route to tampon)---- machine tampon -----
serveur

Dans ce cas tu aurais des règles du genre :
pass in iface0 from any to self port XXX route-to (iface1
ip_machine_tampon)

Ce qui veut dire que tu routes les requetes vers le port XXX vers la
machine tampon, qui doit alors router vers ton serveur. Sur ton serveur
tu n'as plus qu'à configurer une route par défaut vers tampon (et
configurer le routage de celle ci). De cette manière ça peut-être
complètement transparent ama.

On peut peut-être éviter une machine tampon en ajoutant des routes à la
main, faut regarder. Je ne sais pas comment va se comporter le routage
avec des IP identiques sur deux réseaux "directly connected"

Voilà, c'est l'idée je n'ai pas du tout tester les règles.
Thomas vO
Le #24429731
bonjour,

(at) Tue, 24 Apr 2012 22:30:59 +0200,
Patrick Lamaizière
Thomas vO :
block in on ! lo0 from any to any



Pourquoi pas un simple "block all" ? C'est de bon ton (on bloque tout),
et tu skip lo0 de toutes façons.



certes.

Le problème de la redirection c'est que l'adresse destination est
changée, mais pas l'adresse source. Le serveur destinataire va rà ©pondre
au client qui n'attend pas de réponse de ce serveur (pas la mêm e ip) et
drop le paquet. La solution c'est de nater en sortie :

Quelque chose du genre :

pass in quick inet proto tcp from any to self port XXX tag TREDIRECT
rdr-to ip_du_serveur

pass out quick tagged TREDIRECT nat-to ip_du_pf

Ainsi PF va remplacer l'adresse source par la sienne, lors de la rép onse
du serveur il fait l'inverse et le client n'y voit que du feu.

[snip le reste]



ça marche nickel !

avec en plus, les explications kivontbien, merci beaucoup.

--
Avec ma terminologie, les points de contrôle ne sont pas
interpolant. D'accord ? Bon, même si vous n'êtes pas d'accord, je m'en
fous, c'est moi qui écris :-)
-+- Jean-Côme in fr.comp.text.tex -+-
Publicité
Poster une réponse
Anonyme