lousek
Goto Top

DMZ - Aufteilung und Naming?

Hallo Forum,

Ich mache mir zur Zeit gerade wieder ein paar Gedanken über mein Testnetz zu Hause.
Meine Fragen sind:
A) Wie werden die Systeme am Besten aufgeteilt, um dem Vorsatz "keine direkte Verbindungen zwischen LAN und WAN" gerecht zu werden?
B) Welches Naming verwendet man in der DMZ resp. für öffentlich erreichbare Systeme?

Zur Zeit werkelt bei mir als Router ein Debian-System mit 3 NICs: WAN, DMZ und LAN.
Das WAN-Interface besitzt eine statische IP vom ISP und hat NAT (=Source-NAT) aktiviert. Durch iptables-Firewall wird standardmässig alles geblockt, was nicht explizit erlaubt wurde.
Das DMZ-Interface besitzt eine "interne" statische IP. Zugriff ins WAN ist ohne Einschränkungen möglich, Zugriff ins LAN ist durch normales Routing möglich, wird jedoch durch FW-Regeln limitiert.
Das LAN-Interface besitzt eine "interne" statische IP. Zugriff ins WAN und in die DMZ ist ohne Einschränkungen möglich (soll in Zukunft etwas restriktiver werden).

Für den Zugriff von extern auf die Systeme in der DMZ (bsp. Webserer) wird Destination-NAT / Port-Forwarding verwendet.

Nun zum A)

Aktuell laufen die Dienste WWW und Mail.
Für WWW: WAN -> Router -> Reverse Proxy (Squid) -> Router -> Webserver (Apache)
Für Mail: WAN -> Router -> Mail Gateway (ClamAV / SpamAssasin) -> Router -> Mailserver (Postfix)

Der Webserver und der Mailserver stehen also im LAN, da auf beide auch vom LAN aus zugegriffen wird (z.B. Intranet oder "Exchange").
Der Webserver greift auch auf einen DB-Server im LAN zu, der Mailserver auf einen LDAP-Server im LAN.
Mit dieser Konfiguration existiert zwar keine "direkte" Verbindung vom WAN ins LAN, aber dennoch eine indirekte.

Nun, wie teilt man diese Systeme am besten auf, unter Berücksichtigung der Komplexität sowie Sicherheit?
In einer grossen Umgebung würde man wohl ein eigener DB- sowie LDAP-Server in die DMZ stellen, und im LAN hätte man nur Server, die von aussen nicht erreicht werden müssen (z.B. Intranet).
Aber was, wenn für die extern erreichbare Webseite z.B. die Anmeldung mit dem "internen" User möglich sein soll? Oder wenn das Intranet von extern erreichbar sein soll? Oder Webmail?
Kann man mein Ansatz mit den Gateways / Proxies so gelten lassen, oder gibt es deutlich sinnvollere "Lösungen"?

Dann zum B)

Für die Systeme im LAN habe ich mir eine "Naming Convention" ausgedacht: ein 3-stelliges Prefix, eine 3-stellige Typenbezeichnung (z.B. srv für Server oder net für Netzwerk-Geräte), eine aufsteigende Nummer abhängig vom Typ und dann optional ein Kürzel als Beschreibung des Systems. Die interne Domäne ist als Beispiel aaa.local. Die externe wäre dann aaa.ch.
So heisst bsp. der Mailserver xxxsrv07ms.aaa.local oder der Fileserver xxxsrv04fs.aaa.local.
Wie ist das aber mit Systemen, die von aussen erreichbar sind? Z.B. wird ja standardmässig bei Fehlermeldungen der Servername angezeigt (Apache) oder bei Mails ist der Mailserver in den Headers ersichtlich.
Soll bsp. der Proxy in der DMZ auch xxxsrv08proxy.aaa.local heissen, oder aber proxy.aaa.ch?
Und der Webserver, der im LAN steht, aber dennoch über den Proxy von aussen erreichbar ist?

Mein Ansatz bis jetzt ist, dass die "direkt" erreichbaren Systeme (=in der DMZ) wie z.B. der Proxy oder der Mail Gateway mit "externen" Namen konfiguriert sind, also z.B. proxy.aaa.ch oder gateway.aaa.ch.
Die Namen müssen allerdings nicht zwingend von extern auflösbar sein, da es einen Besucher von www.aaa.ch nicht interessiert, dass noch der proxy.aaa.ch dazwischen hängt.
Die "indirekt" erreichbaren Systeme (=im LAN) sind mit "internen" Namen konfiguriert, also z.B. xxxsrv11web.aaa.local für den Webserver. Der Apache selbst ist jedoch so konfiguriert, dass er bei z.B. einer Fehlermeldung nicht den "internen" FQDN des Systems, sondern einen "externen" (z.B. www.aaa.ch) anzeigt. Dasselbe beim Mailserver.

Was haltet ihr davon?

Mir geht es hier nicht darum, eine "Lösung" für das "Problem" zu finden, sondern mich interessiert, wie ihr es das seht, und wie ihr das umsetzten würdet. Also eine Art Diskussion, wo auch andere sicher profitieren werden.
Auch Beispiele aus der Praxis wären interessant.

Gruss
lousek

Content-Key: 180144

Url: https://administrator.de/contentid/180144

Printed on: April 19, 2024 at 08:04 o'clock