Discussion :

[Invité]

Bonjour, j'ai un problème de réseaux important à résoudre pour valider une de mes matières de ma formation et je bloque sur plusieurs points. Voici ce dont je suis à peu près sûr pour ce qui est de la première question.

Comment représenter ce serveur extranet proposant un service web et mail accessibles depuis l'extérieur ? Il me semble que l'utilisation d'une zone démilitarisée (DMZ) est nécessaire mais encore je ne vois pas comment je suis censé représenter cela. L'erreur de la question suvainte n'est pas si évidente pour moi et je n'ai aucune idées des règles du filtrage qui doivent être mises en place.

Merci d'avance à ceux qui prendront le temps de me répondre

[ram-0000]

J'arrive pas à voir les images, elles sont bloquées par mon proxy. Mets les directement en attachement avec ton message, ce sera plus facile pour tout le monde.

[sevyc64]

Concernant, la question b et la grossière erreur, je ne sais pas si c'est de celle-là dont il est question, mais moi j'en voit une énorme dans l'énoncé. Ça me fait hérisser les cheveux quand je lit ça.
Elle se trouve là :

un réseau intranet privé en 193.250.1.0

[Invité]

D'après Wikipedia la classe C se termine à 223.255.255.255, pourquoi 193.250.x.x pose donc problème ?

[sevyc64]

Ben lit la totalité de la citation et reprend tes cours sur la notion de classe et d'adresses publiques/privées.

[Invité]

Voici le design que je déploierais :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
        Internet 
            ^
            |
            |80.1.2.3           pop/smtp    http
     +--------------+              |         |
     | Routeur / FW |--- DMZ --- 193.250.1.0/24
     +--------------+
            |
            |
      Réseau privé
         RFC1918
       /    |    \
      /     |     \
client1  serveur  client2
       bureautique

1) L'erreur grossière qui est faite dans l'énoncé, c'est que les clients internes et le serveur bureautique sont exposés aux menaces venant de l'Internet. Dans ce type d'architecture, les LANs et leurs ressources doivent être isolés par des espaces d'adressages RFC1918 (donc non-routables dans l'Internet) en utilisant la 3ème patte libre du routeur. Et si on voulait peaufiner, il faudrait même insérer en coupure un proxy et un point de translation de telle façon que les clients puissent accéder au net.

2) Les services pop/smtp et http devant être accessibles depuis l'Internet, il est préférable de déployer ces serveurs dans des DMZ dédiées. C'est sur ce type de "DMZ publique" qu'on place également un serveur FTP.

3) "Intranet privé" ne signifie pas nécessairement que l'espace d'adressage utilisé par les serveurs pop/smtp et http soient RFC1918. "Privé" ici s'entend dans le sens que des utilisateurs doivent être en mesure d'accéder à certaines ressources de leur propre entreprise depuis l'Internet.

4) Dans les grosses architectures, on préfère garder certaines DMZ en adresses publiques routées sur l'Internet. En effet, en raison des afflux massifs sur les serveurs, les routeurs/NAT seraient extrêmement sollicités et les performances s'en ressentiraient. Imaginez un serveur Web avec 2000 connexions en permanence, le point de translation risquerait de fumer grave en salle info

5) Je laisse à Fool1sh le soin de régler le filtrage des flux, ça devrait être immédiat.

Steph

[Invité]

Merci beaucoup pour cette précieuse aide, voilà qui rend le sujet moins mystérieux. Cependant l'adresse IP du DMZ où sont connectés les serveurs mail et http ne devrait pas être 193.250.1.251 plutôt que 193.250.1.0/24 ?

En tout cas voici mon essai en image attachée pour le filtrage.

[Invité]

Quelques précisions...

La DMZ s'appuie sur le classe C 193.250.1.0/24 et le serveur Extranet est d'adresse 193.250.1.251/24.

Ensuite il faudrait introduire un réseau interne RFC1918. Par exemple 10.0.0.0/24 avec 10.0.0.250/24 pour le serveur bureautique.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
        Internet 
            ^
            |
            |80.1.2.3
     +--------------+           
     | Routeur / FW |------- DMZ 193.250.1.0/24
     +--------------+ .254            |
            |.254              serveur Extranet
            |                  193.250.1.251/24
      Réseau  privé
       10.0.0.0/24
       /    |    \
      /     |     \
client1  serveur  client2
       bureautique
      10.0.0.250/24

Quant au filtrage, il faut revisiter tes règles...

Grosso modo, je veux permettre un accès SMTP/POP et HTTP à toute adresse IP (du réseau interne et de l'Internet). Ensuite, afin de sécuriser au maximum, je ne veux autoriser les flux Telnet/SSH qu'à partir de mon réseau interne (en y incluant les adresses IP du routeur). Enfin, je veux que mon serveur Extranet et que les clients du réseau interne puissent faire des appels DNS.

D'où les règles suivantes.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
// Permettre accès SMTP/POP et HTTP sur le serveur Extranet

    any           any       193.250.1.251     25      tcp       permit
    any           any       193.250.1.251     110     tcp       permit
    any           any       193.250.1.251     80      tcp       permit


//  Autoriser Telnet et SSH sur DMZ et routeur depuis le réseau Interne seulement
//  Dropper les autres tentatives d'accès SSH/Telnet

10.0.0.0/24       any       193.250.1.251      22      tcp      permit
10.0.0.0/24       any       193.250.1.251      23      tcp      permit
10.0.0.0/24       any       193.250.1.254      22      tcp      permit
10.0.0.0/24       any       193.250.1.254      23      tcp      permit
10.0.0.0/24       any          80.1.2.3        22      tcp      permit
10.0.0.0/24       any          80.1.2.3        23      tcp      permit
    any           any       193.250.1.251      22      tcp       deny (+log) 
    any           any       193.250.1.251      23      tcp       deny (+log) 
    any           any       193.250.1.254      22      tcp       deny (+log)    
    any           any       193.250.1.254      23      tcp       deny (+log)
    any           any          80.1.2.3        22      tcp       deny (+log)    
    any           any          80.1.2.3        23      tcp       deny (+log)  


//  Autoriser les flux DNS

10.0.0.0/24       any             any          53    tcp,udp      permit
193.250.1.251     any             any          53    tcp,udp      permit


//  Dropper tout ce qui n'est pas explicitement autorisé/interdit

    any           any             any         any    tcp,udp      deny (+log)

J'ai rajouté une action (+log) pour info... Parce que c'est une bonne habitude de logger les flux non-autorisés. Soit pour voir d'autres flux qu'on aurait éventuellement oublié, soit pour localiser les petits malins qui font de l'intrusion.

Puis en dernier lieu, je droppe et je loggue tout ce qui n'a pas été explicitement autorisé/interdit.

Steph

[sevyc64]

Je tiens à intervenir, quand même, et à revenir sur ce que j'appelle une grossière erreur, puisque cela ne semble choquer personne :

un réseau intranet privé en 193.250.1.0

193.250.1.0/24 est une adresse de réseau publique, elle existe sur internet et appartient actuellement à France Télécom.
Cette adresse ne doit pas être utilisée sur un réseau privé, même si techniquement c'est tout à fait possible.

Que je sache, même dans une DMZ, le serveur Extranet sera sur un réseau privé (puisque derrière le routeur de tête du client). Il doit donc avoir une adresse IP privée et non pas une des plages publiques. On doit donc lui attribuer une adresse en 192.168.x.x/24 (si on veut garder la classe C initiale du 193.250.1.0/24).

Juste pour imaginer, un client du notre réseau local veut accéder à un service hébergé par une machine sur internet à qui France Télécom à attribué une des adresses du réseau 193.250.1.0/24, si ce jeu d'adresse est conservé pour le réseau privé, et donc le routage correspondant mis en place, ce client ne pourra jamais accéder à ce service car il sera systématiquement redirigé sur le réseau privé, au lieu de partir sur internet. C'est une des raisons la plus importante pour laquelle il ne faut jamais utiliser d'adresses IP de plages publiques pour des réseaux interne ou privés.

[Invité]

Je tiens à intervenir, quand même, et à revenir sur ce que j'appelle une grossière erreur, puisque cela ne semble choquer personne :



193.250.1.0/24 est une adresse de réseau publique, elle existe sur internet et appartient actuellement à France Télécom.
Cette adresse ne doit pas être utilisée sur un réseau privé, même si techniquement c'est tout à fait possible.

Une DMZ peut être déployée avec des adresses publiques routables. D'ailleurs, comment faisaient nos grand-pères avant que l'on ne banalise le concept de NAT ? Concernant le bloc 193.250.1.0/24, oui, il appartient actuellement à FT mais je pense que le scenario donné par Fool1sh était fictif...

Je t'invite à jeter un coup d'oeil sur ces quelques liens :

http://www.techrepublic.com/article/...-a-dmz/5756029

spécialement le paragraphe IP Adressing Scheme

A DMZ can use either public or private IP addresses, depending on its architecture and firewall configuration.

Le lien suivant donne un exemple de config type où on pluggue des équipements directement sur un "DMZ Switch" :

http://www.skullbox.net/configureDMZnetwork.php


qui est l'équivalent de la topologie donnée ci-après :

http://www2.lancom.de/kb.nsf/1276/11...1?OpenDocument

et enfin ce White Paper de Cisco qui a rendu public ses "policies" concernant le design IP de son propre réseau :

http://www.cisco.com/web/about/cisco...ng_Policy.html

avec, page 4 :

The demilitarized zone (DMZ) is the network or networks situated between an ISP edge router and Cisco’s corporate firewalls. Public addresses must be allocated to all production networks in the DMZ. A public address must be assigned to all active interfaces on single-homed and multihomed hosts, except the loopback, to which a private address described in RFC 1918 and discussed below (“Private Addresses”) may be assigned.

Juste pour imaginer, un client du notre réseau local veut accéder à un service hébergé par une machine sur internet à qui France Télécom à attribué une des adresses du réseau 193.250.1.0/24, si ce jeu d'adresse est conservé pour le réseau privé, et donc le routage correspondant mis en place, ce client ne pourra jamais accéder à ce service car il sera systématiquement redirigé sur le réseau privé, au lieu de partir sur internet. C'est une des raisons la plus importante pour laquelle il ne faut jamais utiliser d'adresses IP de plages publiques pour des réseaux interne ou privés.

Faux problème. Parce que si une entreprise est propriétaire d'un bloc routable, son opérateur ne pourra jamais distribuer des adresses prises dans ce pool...

D'autre part, il existe des cas où une entreprise aura du mal à déployer une DMZ publique NATtée...

Je pense à certains mécanismes d'encryption et de test d'intégrité de données qui sont incompatibles avec NAT. Par exemple IPSec/ESP en mode tunnel ne pourra fonctionner qu'avec certaines fonctionnalités du point de translation NAT (IPSec pass-through). Il y a aussi certaines applications qui utilisent des initialisations de session dynamiques, comme NetMeeting et MSN Messenger, et qui requièrent également des fonctionnalités particulières (UPnP, NAT Traversal).

Pire encore, certaines entreprises utilisent des applications TCP/IP très spécifiques qui embarquent les adresses IP à l'intérieur des segments TCP pour rajouter une couche de sécurité indécelable par un hacker (applications avec des "embedded informations" pour faire du "security piggybacking").

Steph

[sevyc64]

Une DMZ peut être déployée avec des adresses publiques routables.....

J'ai lu les docs un peu en travers, j'aime pas l'anglais, mais de ce que j'en comprend (et de ce que je viens d'apprendre ces derniers mois sur le sujet), oui, une DMZ peut utiliser des adresses publiques quand ces adresses là sont dans le pool que le FAI a attribué au client. C'est à dire que les machines dans la DMZ sont directement connectées à l'ip publique du client et non pas derrière un routeur (sauf à ce que celui-ci soit configuré en bridge)
Ici ce n'est pas le cas, puisque le pool attribué est 80.1.2.3, alors que la DMZ utilise des adresses (193.250.1.0) qui sont potentiellement attribuées à d'autres clients. IP publique et DMZ sont sur 2 réseaux différents, on peut donc considéré que la DMZ est coté privé du réseau. Ou alors l'énoncé du problème est incomplet et oublie de précisé que le client, en plus de l'@ 80.1.2.3, possède aussi sur le même lien le pool 193.250.1.0/24. Mais ça, rien ne permet de le préjuger, à mon avis

Heureusement que le scénario est fictif, mais ce n'est pas une excuse pour moi. Car pour bon nombres d'étudiants, les pratiques apprises sur le plan scolaire, fussent-elles bonnes ou mauvaises, fictive ou pas, deviendront par la suite des pratiques courantes. Il en est aussi de la responsabilité des enseignants de donner dès le départ les bonnes bases. Mais est-ce peut-être justement le sujet de la question b ?

Faux problème. Parce que si une entreprise est propriétaire d'un bloc routable, son opérateur ne pourra jamais distribuer des adresses prises dans ce pool...

Oui, si l'entreprise était propriétaire du pool 193.250.1.0/24, l'opérateur ne pourrait pas distribuer des @ de ce pool à d'autres clients. Hors il semble que ce n'est pas le cas, puisque l'entreprise en question s'est vu attribuer, selon l’énoncé du problème, l'adresse 80.1.2.3, elle n'est donc, à priori, pas propriétaire du pool 193.250.1.0/24, elle ne doit donc pas, pour moi, l'utiliser de quelques manières que ce soit

[Invité]

Si l'on considère que le point à améliorer dans l'architecture est qu'il faut passer par une DMZ pour l'accès au serveur extranet (en utilisant le port libre du routeur), je pense donc que l'erreur "grossière" dont il est question est que l'adresse 193.250.1.0/24 fait partie des plages d'adresses IP publiques et donc ne doit pas être utilisée pour un pool d'adresses IP privées comme sevyc64 le fait comprendre. Je pense que cette explication me suffit, ne vous torturez pas trop l'esprit pour moi, ma formation est loin d'être focalisée sur le réseaux, je pense que vous avez pu comprendre.

En revanche j'aurais une dernière précision à demander, en admettant donc que 193.250.1.0/24 peut être utilisée sans restriction. Pourquoi choisir 2 plages différentes pour le DMZ et le réseau privé (10.0.0.0/24 et 193.250.1.0/24 dans la 2ème correction de IP_Steph) et pas tout simplement la même ?
Merci encore d'avoir pris du temps pour m'aider à résoudre ce problème !

[Invité]

une DMZ peut utiliser des adresses publiques quand ces adresses là sont dans le pool que le FAI a attribué au client

Alors supposes que je sois propriétaire d'un bloc routable et que je veuille déployer une DMZ publique sans translation, quelle est l'archi que tu préconises ?

Encore mieux... Suppose que ma DMZ est tellement critique que je veux qu'elle soit accessible au travers de 2, voire 3 FAI distincts (cas de "multihoming") ?

Ou bien mon entreprise vient de fusionner avec une autre qui se trouve sur un autre continent et j'aurai besoin de créer des flux inter-DMZ ? Il faudra bien annoncer/transporter ces blocs de façon complètement distincte de l'espace d'adressage des FAI ?

Steph

[Invité]

En revanche j'aurais une dernière précision à demander, en admettant donc que 193.250.1.0/24 peut être utilisée sans restriction.

Si je me réfère à ce que j'ai vu/fait au CNRS, dans quelques Universités, au Crédit Agricole, chez PPR, chez Cisco, chez AG2R, chez Citibank et à la NASA, oui, tu peux

Pourquoi choisir 2 plages différentes pour le DMZ et le réseau privé (10.0.0.0/24 et 193.250.1.0/24 dans la 2ème correction de IP_Steph) et pas tout simplement la même ?
Merci encore d'avoir pris du temps pour m'aider à résoudre ce problème !

Parce qu'on ne mélange pas les serviettes et les torchons

En mettant le serveur bureautique et les clients sur un réseau IP distinct, tu segmentes ce trafic qui restera local à ce réseau. Il n'y a aucun intérêt à inonder la DMZ de ces flux.

Le principe numéro 0 dès lors qu'il s'agit de monter un design autour de firewalls, c'est de localiser fonctionnellement ce qui est interne (trusted), DMZ (semi-trusted) et outside (Internet ou untrusted).

Si les clients et le serveur restent dans la DMZ, il sont potentiellement très vulnérables. C'est notamment dans les réseaux internes que réside la propriété intellectuelle d'une entreprise !

Steph