Public IP Adressen in der DMZ JA oder NEIN

In der DMZ die Public IP Adressen beibehalten


  • Umfrageteilnehmer
    7
  • Umfrage geschlossen .
trashcity

trashcity

Foren As
Ich administriere drei Firewalls und ich höre viele verschiedene Antworten

Ob man jetzt in der DMZ offizielle IP Adressen verwenden soll oder ob man die IP Adressen auf der Firewall einfach in die DMZ nated

Was spricht für Public IP Adressen in der DMZ
Und was spricht dafür wenn man IP Adressen Nated
 
Nein, weil imho es für einen ngreifer von außen schwerer ist, genatete netzwerke zu durchforsten. außerdem lassen sich genatete netze imho leichter administrieren.
 
Privatadressen in der DMZ

Ich kenne niemanden, der in der DMZ was anderes als private Adressen verwendet.
Zum einen spart es natürlich Geld, weil man nur noch eine "echte" IP-Adresse fürs Internet braucht, zum andern ist es - wie saiki schon sagte - für einen uneingeladenen Gast nicht ohne weiteres möglich, z.B. einen Mailserver 192.168.0.33 anzusprechen, weil die Adresse im Internet ungültig ist.
Umgekehrt fällt mir auch kein Grund ein, wozu man in einer DMZ richtige Adressen brauchen sollte...
 
trashcity schrieb:
Ich administriere drei Firewalls und ich höre viele verschiedene Antworten

Ob man jetzt in der DMZ offizielle IP Adressen verwenden soll oder ob man die IP Adressen auf der Firewall einfach in die DMZ nated

Was spricht für Public IP Adressen in der DMZ
Und was spricht dafür wenn man IP Adressen Nated

Wenn du einen Server in der DMZ auch aus dem LAN ansprechen musst, kommt i.d.R. eine öffentliche IP nicht in Frage, da der Großteil der Router ein Problem bekommt, wenn CLIENT aus dem LAN den SERVER in der DMZ mit einer öffentlichen IP anspricht. Wie soll die Paketweiterleitung funktionieren?

Annahme:
ROUTER:externe IP(eth1)=195.195.195.195/24, LAN IP(eth0)=192.168.1.1/24, DMZ IP(eth2)=192.168.6.1/24
SERVER in DMZ=192.168.6.10/24
CLIENT im LAN=192.168.1.50/24
Portforwarding für Port 80 nach SERVER 192.168.6.10 ist eingestellt.

Ich stelle mich jetzt mal ganz dumm und frage mich: "Maskiert ROUTER, wenn ich von innen nach innen forwarde?"
Nehmen wir weiterhin an, ich wüsste die Antwort nicht, dann muss ich beide Möglichkeiten durchspielen.
1. Fall: ROUTER maskiert nicht von innen nach innen:
Der Client adressiert die externe IP. Im Paket steht also:
Absender: 192.168.1.50
Empfänger: 195.195.195.195:80

Das Paket gelangt (logisch gesehen) zur eth1. ROUTER schickt dieses Paket nun (unsere Annahme) an den lokalen Server, wobei er die Empfaenger-Adresse auf 192.168.6.10 ändert. Auf dem Server käme also an:
Absender: 192.168.1.50 <- unverändert
Empfänger: 192.168.6.10:80 <- geändert wegen Portforwarding
Nun kann der Server antworten. Er wird die Antwort an den lokalen Rechner 192.168.1.50 schicken, denn dieser ist als Absender drin.
Der Client bekommt das Paket also direkt(!) von 192.168.6.10 und stutzt: "Ich habe den Request an "195.195.195.195" geschickt und bekomme die Antwort von 192.168.6.10?". Der Client wird daraufhin das Antwort-Paket verwerfen.

2. Fall: ROUTER maskiert auch von innen nach innen:
Der Client adressiert die externe IP. Im Paket steht also:
Absender: 192.168.1.50
Empfänger: 195.195.195.195:80
Das Paket wird wegen Portforwarding an den internen Server weitergeleitet:
Absender: 195.195.195.195 <- Masquerading
Empfänger: 192.168.6.10:80 <- Forwarding
Es wären nun also Absender und Empfänger geändert.
Der Server antwortet nun an 195.195.195.195 mit Absender 192.168.6.10, also:
Absender: 192.168.6.10
Empfänger: 195.195.195.195
ROUTER würde nun daraus machen:
Absender: 195.195.195.195 <- Masquerading
Empfänger: 195.195.195.195 <- unverändert, da extern.

Beide Probleme erkannt?
 

Ähnliche Themen

Webserver (über eigene WAN-IP-Adresse) nicht erreichbar - extern möglich

Firewall und Virenschutz

sshd an 2 ip adressen binden ABER jeweils ein anderer port

Heartbeat mehrere IP-Adressen

Problem mit Squid-Proxy Transparent + ASA 5505

Zurück
Oben