[Résolu] Quelle regle pour autorisser la sortie vers le WAN

titofe

Merci,

Comme tu le vois, il y a une incompréhension de ma part au niveau des Rules.

Corrige moi si je me trompe.

Quand je veux donner accès un PC/Serveur d'une Zone qu'on nommera 'LAN' vers une autre qu'on nommera 'DMZ', je mettrais dans destination 'DMZ subnet' pour lui donnez accès à toute la 'DMZ'.
Par contre si je ne veux lui donner accès qu'à un seul PC/Serveur de cette zone dite DMZ, j'utiliserais dans destination 'Single host or alias' et rentrerais l'IP du PC/Serveur en question.
Pour moi là tout est claire, par contre je ne vois pas comme utilisé la destination 'DMZ address', pour faire simple je ne comprend pas son utilisation?

Peut tu m'expliquer?

Cdt,

Titofe

jdh

Quand je veux donner accès un PC/Serveur d'une Zone qu'on nommera 'LAN' vers une autre qu'on nommera 'DMZ', je mettrais dans destination 'DMZ subnet' pour lui donnez accès à toute la 'DMZ'.
=> C'est correct. J'ajoute que le mieux est d'utiliser un alias (même s'il n'y a pas de raison de changer un serveur d'adresse).
De plus cette règle est créée dans l'onglet correspondant à l'interface "source" !

Utilisation de "DMZ address" (plutôt "WAN address") : c'est une syntaxe pour indiquer l'adresse de l'interface.
Par exemple, si je veux autoriser que, depuis Internet,on puisse pinguer le firewall, j'écrirais :
dans l'onglet WAN, une règle Pass pour le protocole ICMP type echo request (type 8), source : any, destination : Wan address

titofe

Maintenant que tu me le dit, il est clair que 'DMZ address' ressemble beaucoup à 'Adresse de la DMZ' (je rappel que je suis mauvais en anglais … :-)

Ok, grasse à toi je n'ai plus de doute sur ce que je pensais et j'ai compris ce que je ne savais pas.

Par contre ce que je n'arrive toujours pas à comprendre, c'est comment ne donner accès qu'au 'WEB' à ma 'DMZ externe'.

MA 'DMZ externe' sans aucune Rules d'établi ne donne accès à rien, donc tout est bloquer.

Si je voulais lui donner accès à une autre 'DMZ' je ferais comme cela:

Proto * / Source 'DMZ_Externe' / Port * / Destination 'DMZ' / Port * / Gateway * / Shedule

Et elle aurrai accès à toute la 'DMZ' donc PC, Serveur, etc. qui si trouve et rien d'autre.

Maintenant si je veux lui établir la même règle mais que pour le WEB:

Proto * / Source 'DMZ_Externe' / Port * / Destination !?! / Port * / Gateway * / Shedule

Comme on peut le voir je ne vois pas ce que je doit lui mettre comme destination, car dans les destination par défaut j'en ai aucune me proposant le WEB.

Je me trompes?

Donc j'ai bien compris ou pas quand je dit qu'il faut créer une règle avec tout qui passe et après créer autant de règle que besoin pour bloquer tout le reste (Je pense quand créant un alias avec les réseaux à bloquer devrais faire l'affaire) afin de n'avoir accès qu'au WEB?, ou il y a un truc que je n'ai vraiment pas compris.

Cdt,

Titofe

jdh

Il y a encore beaucoup d'incompréhension (et de fautes d'orthographe : grasse dans les alpes-maritimes ?)

Comme avec iptables, on ne s'intéresse qu'à l'initialisation du flux !

Pour un serveur web en DMZ, il faut 2 choses :

une règle NAT (pour changer l'ip destination = la WAN Address vers l'ip du serveur interne),
une règle Rules (pour autoriser le flux lui-même).

Il se trouve que quand on créé la règle NAT, la règle Rules est créé aussi.
Mais si on modifie la règle NAT, il faut soi-même modifier la règle Rules !

La règle NAT sera quelque chose comme
Interface : WAN / External address : interface address / Protocol : tcp / external port : http / nat ip : (alias srv en dmz) / local port : http / Description : w2d acces web sur srv

La règle Rules sera dans l'onglet WAN (puisque c'est l'interface d'arrivée) :
Action : pass / Interface : WAN / Protocol : tcp / Source : any / Destination : (alias srv en dmz) / Destination port : http / Description : NAT w2d acces web sur srv

titofe

@jdh:

Il y a encore beaucoup d'incompréhension (et de fautes d'orthographe : grasse dans les alpes-maritimes ?)

:-\

Merci jdh pour toute ces information et le temps que tu donne à lire et à répondre à mes message.

Je viens de lire et relire les règles que tu viens de m'indiquez et je me demande si on parle de la même chose, quand je lis les règles que tu ma donnez en exemple, je vois un accès du monde extérieur (WEB, Internet) vers le Serveur en Zone DMZ.

Mais moi je veux faire l'inverse, je veux que le Serveur puisse allez sur le (WEB, Internet).

Je vais essayer de donnez un exemple plus concret.

Dans mon exemple j'ai une 'DMZ_Interne' cette DMZ accueil un 'Proxy' qui sert à donner un accès au WEB pour les PCs du 'LAN'.
Donc les besoin de ce 'Proxy' est seulement de pouvoir accéder au WEB et à rien d'autre.
On est bien d'accord que la 'DMZ_Interne' à par défaut aucun accès ni au WAN, ni au LAN, ni à la DMZ_Interne.

En indiquant comme règle:

Proto * / Source Proxy / Port * / Destination * / Port * / Gateway * / Schedule

Je donnerais accès au WAN , mais aussi au LAN et à la DMZ_Interne.
Mais je ne veux donnez accès qu'au WEB.

Si j'avais voulu donnez accès à un PC du LAN j'aurai mi comme Destination Alias_du_PC
Si j'avais voulu donnez accès à un Serveur du Web j'aurai mi comme Destination Alias_du_Serveur
Si j'avais voulu donnez accès au LAN j'aurai mi comme Destination LAN Subnet,

Mais si je veux donnez accès au Web en entier je mais quoi dans Destination?

jdh

Oops ! J'ai compris l'inverse !

Une règle Rules dans l'onglet DMZ qui devrait fonctionner :
Action : Pass / Interface : DMZ / Protocol : tcp / Source : (alias du srv) / Destination : any / Destination port : http / Description : d2a sortie web de srv

la destination est any puisque cela recouvre tout. Bien préciser le port de destination et par * qui signifie aussi any.

Attention toutefois :
1- il faudrait aussi ajouter un accès dns parce qu'en principe on commence par résoudre le nom
2- cela donne aussi accès à n'importe quel serveur web dans le LAN : au besoin ajouter une règle d'interdiction avec "Destination : LAN subnet"

Tu notes que, de même, que je normalise la façon de nommer les alias, je me discipline en ajoutant une description du type :

d2a sortie web de srv : d2a = DMZ to (2) ANY

De même l2w, d2l, w2d, … ce qui facilite la lecture.

titofe

@jdh:

Oops ! J'ai compris l'inverse !

Tu est complètement pardonner, je répondais avec des pincette car comme je te l'ai fait comprendre je n'étais pas sur de moi et j'avais peur de n'avoir réellement rien compris, ce qui me fessais peur :-\ :)

Donc pour résumer, si on veux donner un accès entier au WEB et à rien d'autre pour le Serveur ce trouvant dans la DMZ, il faut lui donnez accès à tout puis lui restreindre le reste.
A l'inverse, si je voulais lui donner accès au LAN, je lui donne tous simplement comme destination 'LAN Subnet'.

titofe

Voici donc la règle que j'ai utiliser pour autoriser un accès total à une DMZ au WEB:

J'ai créer un Alias avec toute les classes de réseaux privée:

10.0.0.0 /8 Classe A
172.16.0.0 /12 Classe B
192.168.0.0 /16 Classe C

Que j'ai nommer 'IP_Privee'

Après je créer un règle qui autorise le serveur en question à tout:

Pass / Proto * / Source 'Serveur' / Port * / Destination * / Port * / Gateway * / Schedule /

Cette règle autorise l'accès à toute destination (WAN, LAN, DMZ, Etc.) et protocole pour le 'Serveur'
Cette règle est générique, elle ne fait aucun filtrage du Serveur vers l'extérieur, il faudra donc l'adapter selon vos besoins.

En suite je rajoute par dessus cette règle une nouvelle qui interdis tout accès au réseaux privée:

Block / Proto * / Source 'DMZ' / Port * / Destination 'IP_Privee' / Port * / Gateway * / Schedule /

Cette règle refuse tout accès aux réseaux privée à partir de la 'DMZ'.

Cdt,

Titofe

jdh

Je ne comprends pas bien cette complexité.

Premièrement, on créé une règle d'accès en précisant protocole et port.
Deuxièmement, on créé, si besoin, un règle d'interdiction pour "LAN subnet" (directement).

A noter que, normalement, le cas exposé n'a pas beaucoup de sens :

un serveur web en DMZ est plutôt accédé depuis Internet,
s'il s'agit de gérer la mise à jour comme par exemple un Debian qui utilise apt-get sous http, on veillera à plutôt utiliser le proxy.

titofe

@jdh:

Je ne comprends pas bien cette complexité.

Je n'ai pas trouver plus simple et il ai vrai que cela m'étonne, d'où mes questions.

@jdh:

Premièrement, on créé une règle d'accès en précisant protocole et port.

Complètement d'accord avec toi, mon exemple a étais simplifier pour ne traiter que de la sortie de la DMZ vers le WEB.

@jdh:

Deuxièmement, on créé, si besoin, un règle d'interdiction pour "LAN subnet" (directement).

La regle Block 'LAN subnet' est à créer que si la règle laisser tout passer (Pass Any) à étais créer.
Je ne sais pas pour les autres mes moi je n'ai pas que le LAN comme réseau, j'ai plusieurs vlam et réseaux distants, d'où la règle qui bloque les plages d'adressage IP définies par la RFC 1918 dit "réseau privée".

@jdh:

A noter que, normalement, le cas exposé n'a pas beaucoup de sens :

un serveur web en DMZ est plutôt accédé depuis Internet,

Complètement d'accord et pour allez jusqu'au bout le serveur en question est un Serveur Mail donc du SMTP/IMAP que je n'ai pas encore ouvert sur l'exterieur.

@jdh:

s'il s'agit de gérer la mise à jour comme par exemple un Debian qui utilise apt-get sous http, on veillera à plutôt utiliser le proxy.

Je n'y ai pas penser pour le proxy, il ai vrai que pour le HTTP (80) cela ne devrais pas poser de problème, par contre comment fait tu pour les protocole NTP (UDP/123), POP (TCP/110) et DNS (UDP/53), j'utilise actuellement SMEServer comme serveur Mail et il y a encore 2 ports que je ne sais pas encore à quoi il serve : 208.83.136.12:2703/208.83.137.115:2703 et 66.250.40.33:24441.

De tout façon la règle que j'ai établie il faut bien la mettre quelle que part, car sinon comme fait tu pour donner accès au protocole HTTP au proxy et pas aux autres réseaux (LAN, DMZ, Réseau Distant (OpenVPN), etc.)
Tu le dit toi même avec la règle:
@jdh:

Action : Pass / Interface : DMZ / Protocol : tcp / Source : (alias du srv) / Destination : any / Destination port : http / Description : d2a sortie web de srv

que cela donne accès au LAN, mais ce que tu oublie de dire, c'est que cela donne accès à tout les autres réseau en place sur PfSense.

En espérant avoir étais claire et je reste dans l'attente de te relire.

Cdt,

Titofe

jdh

Tant qu'à faire, plutôt que créer des alias rfc1918, je créerai un alias "mes réseaux locaux" spécifiquement avec un nom clair comme "lansociete". (toujours faciliter la lecture visuelle !)

A chaque fois qu'il est possible, il faut utiliser un proxy : http, https, ftp -> Squid (sur machine dédiée), ntp -> sur pfSense qui servira TOUS les serveurs locaux.

Pour un serveur SME en DMZ, il sera accédé de l'extérieur en :

http/https/ftp : site web à destination public,
smtp : attention à l'ip fixe et au reversedns normalement nécessaire,
A l'inverse, il sera à l'initiative de :
pop3 : si les boites réelles sont chez un hébergeur (ce que je préconise en dessous d'une 30aine de boites),
smtp : vers le smtp du FAI forcément !
http/ftp : pour se mettre à jour mais, de préférence, via le proxy local,
ntp : vers pfSense.

Toutes ces informations (à adapter si j'en oublie : je suis loin d'être spécialiste de SME) doivent permettre d'écrire les règles nécessaires : de façon absolue, il ne faut ouvrir que ce qui est utile, pas plus !

Donc il n'y a finalement que peu de flux à définir. (J'ignore le rôle de 2703/? ou 24441/? : rien de standard, donc pas d'autorisation !)

(Je pense qu'on a été assez complet ?)

titofe

Merci pour toute ces informations.

Par rapport à SMEserver, pour ce que je m'en sers tous y est, à savoir aussi qu'il est en "Server Only".

Titofe

titofe

Comme tu a ouvert une parenthèse sur la sécurité du Serveur Mail jdh, j'en profite pour avoir ton ou vos ;) avis sur une securité accrus sur les ouvertures extérieure, je pensais ne pas ouvrir SMTP et utiliser ceux de SFR (Ces pour des téléphones portables), pour IMAP utiliser ssl.

Il y aurai autre chose?