Velius

Der RID-Master ist online?

Klar, eine DMZ hat ihren Nutzen nur in der Sicherheit, that's it (ok, vielleicht noch um die Broadcast Domäne einzugrenzen, aber das ist nur ein natürlicher Nebeneffekt davon).

Nein, eben nicht. NAT hat technisch gesehen mit Port-, bzw. Application-Filtering rein gar nichts zu tun. Also, wenn du eine DMZ mit öffentlichen Adressen einer mit privaten Adressen gegenüber stellst gibt's es primär zwei Vorteile: - Du verbrauchst weniger öffentliche IP Adressen beim privaten Modell und eventuell zahlst du weniger bei deinem ISP - Du bist flexibler im gestalten deines Adress-Raumes, da du bei IP Knapheit nicht immer zuerst den ISP zu Hilfe nehmen musst. Alles klar? cheers;) Velius

Hi ...äh? Ein DC installiert soweiso nicht automatisch DHCP, wenn schon dann eher DNS. cheers Velius

@eXOs Du kannst schon eine DMZ mit öffentlichen IPs bereitstellen, macht aber IMHO relativ wenig Sinn da der verschleiss an öffenltichen IPs höher ist (mindestens ein /30 Subnetz für Firewall <-> Internet Router des ISPs + zusätzliches Firewall Interface <-> 'beliebiges' öffentliches Subnetz für DMZ). Ausserdem schauen die meisten ISP darauf, das in einem vernünftigen Rahmen zu halten der der öffenltiche Adressraum ist begrenzt. Auch das von Marka erwähnte 'Port-Forwarding' ist eigentlich nicht's anderes als ein Port-NAT (auch NAPT genannt). - Internet <-> Firewall IP + z.B. HTTP Port (80) <-> DMZ Host 1 - Internet <-> Firewall IP + z.B. SMTP Port (25) <-> DMZ Host 2 cheers Velius

Ganz ehrlich? Nie.:D ;) cheers Velius

Ich hab mir sagen lassen, dass das ginge (> 3000er Serie oder so ähnlich), kann es aber selbst nicht bestätigen.

Thanks!:thumb1:

Falls es interessieren sollte, hier noch ein paar Details zu meinen Ausführungen: ISA Server 2006 Firewall Core Aus meiner Erfahrung kann ich aber sagen, dass man bei deaktiviertem Firewall Dienst (lockdown mode) gar nichts mehr ging - gut möglich, dass noch Layer2 (Arp/MAC) Funktionaltiät da war.

Gut zu wissen - dachte doch noch, das müsse D-Link sein....:D

Na das mit dem 'Müll' war stark überspitzt formuliert, sollte aber den Teil der Firewall und des Rulesets hervorheben. Egal was auf der Kiste läuft, im Regelfall verhält es sich so, wie das Ruleset es erlaubt - default wird bei ISA z.B. alles auf und von localhost geblockt (ausser 'Ausgehend' die selektierten Anwendungen - AD bei Integration, usw.). Also nix mit unnötigen Diensten und Anfälligkeiten. Und alles andere sind Fehler (buffer-overflows, etc.), welche dazu führen, dass sich das Ding von aussen komplett verriegelt... Ich komm aus dem Healthcare Sektor - glaub's mir, da knausert man auch nicht gerade mit regulatorischen Anforderungen, würde das aber gerne mal bei Gelegenheit und 'nem Bier weiter vertiefen.:D

@PeterPanAK47 Ohne Maske und ohne genau zu wissen wie der Netgear VPN Client arbeitet sagt das nicht viel aus - ich wollte dich mit meinen Ausführungen nur in die richtige Richtung schubsen.:wink2:

Check Point, Aventail machen das mit virtuellen Interfacen und virtuellen IP Adressen - und einer Topologie (man könnte es auch Routing Tabelle nennen) die dem Zielnetz entspricht:D

Wird er nicht IMHO - Core ist für DNS, DHCP, ADDS usw. konzipiert, auch IIS soweit ich weiss - bei EX2007 ist bereits schon schluss. Ausserdem, egal wie sehr du den ISA härtest oder nicht härtest, der Kern der Geschichte ist der Firewall Dienst (die eigentliche Firewall), und da kann noch so viel Müll auf dem W2K3 Server laufen - solange du nicht am Dienst vorbei kommst und das Rule-Set nicht vermurkst ist seh ich wenigstens remote keine Chance an dem Ding vorbei zu kommen. Nimm dir schon mal vorher die Zeit zum reinschauen, es lohnt sich!;)

@Johannes Bzgl ISA: Da tust du aber MS unrecht - ist nicht mein Lieblingsprodukt (hat aber andere Gründe), hinsichtlich Sicherheit aber doch sehr, sehr solide. Warum? - Kaum oder keine (zumindest ISA 2006) Exploits oder Lücken vorhanden/bekannt. - Versucht man den Firewall Dienst zu beenden verrigelt sich das Ding erbahrmungslos und ohne Wiederkehr - jeglicher Netzwerkverkehr ist dann Sense. Da ist ein Kernel-Level Treiber der den Stack dicht macht. Ich hab mir so mal aus Lust & Laune und etwas Spieltrieb 'ne komplette ISA 2004 installation zerschossen. Sogar Recovery Console und Treiber deaktivieren/aktivieren brachten nix - und ich war Admin und hatte lokalen Zugriff, wohlgemerkt! Es gäbe das sicher noch ein paar andere Beispiele für - aber ich denke das ist doch eher was der in der Rubrik 'Vorurteil' und 'schlechtes Image' von Seiten MS & Sicherheit. cheers Velius P.S.: An jeder FW gibt's was zu härten, glaub's mir. Wer sich auf den Hersteller und eine 'Hardware' Firewall (was es schlicht nicht gibt) verlässt, na ja....:wink2:

Man könnte auch temporär eine GPO mit Erhöhung der Rechte auf die Registry Keys mitgeben, in welche der User schreiben können sollte....

Nö, nicht solange du während der Lease-time den ausgeschlossenen Bereich bewarst. Nach ablauf der lease-time kannst du diesen dann aufheben. cheers Velius

Also, es ist so... Wenn der VPN Client sowas wie split-tunneling kennt oder so etwas ähnliches, jedoch kein virtuelles Interface (und Topologie) hat, dann hält er Anfragen für besipielsweise 10.0.0.0/24, wenn sich dieser auch in genau diesem Netz irgendwoanders auf der Welt aufhält, für lokal, und nicht wie erwarte für remote. Die Anfrage wird dann in's lokale Netz anstatt in das entfernte (über VPN) gesannt. Wenn es der PPTP oder L2TP CLient von MS ist besipielsweise, dann sind nur Verbindungen in das entfernte Netz (über VPN) möglich - das lokale Netz 'sieht' er im Prinzip gar nicht mehr. Es kommt ganz auf die Netz-ID des Quell- und Zielnetzes an. Ist die gleich und der erste Punkt deines Clients ist gegeben dann klappt's nicht. Es ist auch Möglich, dass das virtuelle Interface und/oder die Topologie deines VPN Clients fehlkonfiguriert sind, und deswegen sein Ziel nicht erreicht.

Na ja, die Specs sagen da schon was dazu: ...nur, wie man das konfiguriert ist eine andere Frage.

Du, ich glaub mit dem Ding kannst du das knicken - ich find nichtmal 'ne Vernünftige technische Doku dazu.:( :wink2:

So ähnlich - du machst dann sowas wie ein VPN Transfernetz: Sagen wir mal 10.250.0.0/24 ist dann das virtuelle VPN Netz, und 10.0.0.0/16 ist dein LAN.... Solange sie sich nicht überschneiden geht das.

Kann mich mal kurz schlau machen wenn du möchtest:suspect: :D

Das ist genau so - Entweder durch den VPN Server (NetGEAR?) eine virtuelle Range ausserhalb der benutzten Ranges zuteilen lassen, oder dem Zielnetz etwas weniger geläufiges verpassen wie 172.16.0.0/12 oder so ähnlich. cheers Velius

Natürlich geht das auch anders. Mit regelmäsigem Clonen besipielsweise, sollte beim Server direct attached storage verwendet werden - liegt die System-Partition auf dem SAN und der Server hat 'nen Fiber Channel Boot-Controller ist das zugegebenermasen überflüssig. Du weisst aber, dass das vom-SAN-booten eine etwas heikle sache ist....:wink2:

@JClasen Kann es sein, dass du die Boot-, bzw. System-Partition des jeweiligen Servers auf's SAN legen möchtest - na dann sieht's IMHO etwas anders aus mit den Lizenzen...