[gull] Représentation DMZ, vos avis.

[Félix Hauri]

Salut Marc,

> Mais tu as installé un firewall, avec 3 interfaces réseau?
Oui, dans les fait, il faut considérer, sur mon dessin, la partie
rouge ET grise clair comme faisant partie physiquement du firewall/routeur.

(Je vais mettre des bulles avec du hover, sur mon dessin!)


> Mettre réellement deux firewalls peut avoir parfois un avantage, genre
> deux firewalls de constructeurs différents, n'auront pas forcément les
> mêmes bugs. Mais cela complique la gestion, donc c'est rare à ma
> connaissance aujourd'hui.
Oui, j'ai plusieurs clients qui font ce genre de choses.

> > n'y a que très peu de règle de firewall qui concernent la DMZ! Essentiellement
> > de redirections dnat. Et surtout, je n'appèlerais pas ça un mur de feu. )
> 
> Il se peut (il se doit?) que les règles soient plus ouvertes depuis
> l'interne que depuis Internet.  Et que le DMZ ne puisse pas de sa propre
> initiative entrer dans le réseau interne (uniquement répondre à des
> requêtes -- statefull / connection tracking).
> 
> A ce sujet, il faut faire attention au NAT/PAT et aux trous automatiques
> dans le firewall: dans certains cas, il est possible de convaincre les
> machines internes de faire des requêtes qui vont trop ouvrir.  Ou des
> attaques liées à des changements rapides d'adresses IP externes/internes
> sur le DNS.
Oui, aussi!


> Et vu que tu as mis un honeypot dans ton DMZ, il faut, si l'objectif
> est de n'avoir que des alarmes rares, bloquer l'accès au honeypot depuis
> Internet, mais autoriser depuis les autres machines du DMZ, voire du
> réseau interne. Quand ça sonnera, c'est qu'une machine du DMZ ou du
> réseau interne aura été piratée.  Alternative: ton honeypot sert
> à bloquer des adresses IP (avec éventuel report à AbuseIPdb p.ex. [1]),
> dans ce cas, oui, le laisser totalement ouvert. Mais alors je ne le
> mettrais pas dans le "même" DMZ et je le bétonnerais autour, pour
> éviter qu'en cas de bug dans l'honeypot des attaques transitives
> (déplacement latéral) soient possibles.  Donc une 4e interface
> réseau (réelle ou virtuelle).
Oui, le dessin est très simplifié, mais la DMZ est ``partitionnée''!


> Ou tu peux aussi mettre ton pot de miel dans le réseau interne,
> ça détectera une attaque arrivée dans le réseau interne.
Oui, bien vû!

> > Je pense au contraire que DMZ signifie que cette zone n'est pas protégée
> > et donc exposée.
> 
> a) certains services sont ouverts, mais surveillés
>       exemple: réception SMTP d'e-mail
> 
> b) d'autres sont réservés au réseau interne
> 
>       exemple: modification du serveur web externe
> 
> c) d'autres sont fermés et accessibles uniquement d'un réseau
>    d'administration, voire uniquement de la console dans les
>    cas paranoïaques (attention au déni de service ...)
> 
>       exemple: interface d'administration (y.c. SSH)
Je pense reprendre ton explication soignée pour mettre dans les bulles!
(Avec ton accord!)

> En ce qui me concerne, p.ex., dans le DMZ et le réseau interne j'ai
> une détection d'intrusion en plus (IDS Suricata) d'analyse centralisée
> des logs.

> En conclusion, je préfère le schéma à 2 firewalls, en général, ou
> éventuellement un firewall à 3, voire 4 interfaces (réseau admin).

D'accord, il va falloir que je sois plus détaillé et plus générique
dans non dessin:
  La partie grise et la partie rouge constitue le système de protection
  de l'ensemble. Elle peut être constituée physiquement au minimum d'un
  seul appareil pourvu de 3 ports, deux appareils distincts ou même une
  architecture plus complexe.

> 
> [1] https://www.abuseipdb.com/user/42539
>     il y a du vrai (parsing centralisé de logs, IDS) et du
>     honeypot
Intéressant, joli, bravo!


-- 
 Félix Hauri  -  <felix at f-hauri.ch>  -  http://www.f-hauri.ch