Jump to content

Velius

Expert Member
  • Gesamte Inhalte

    5.644
  • Registriert seit

  • Letzter Besuch

Beiträge erstellt von Velius

  1. 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

  2. @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

  3. Falls es interessieren sollte, hier noch ein paar Details zu meinen Ausführungen:

     

    Firewall Engine (Firewall Packet Engine)

    The Firewall Engine is a kernel-mode driver. (The driver name is fweng. The file name is fweng.sys). The Firewall Engine driver is called whenever network traffic arrives or leaves an ISA Server network interface and modifies it if necessary. No network traffic is sent if the Firewall Engine driver does not allow it.

     

    Note The Firewall Engine driver is the root of the firewall dependency tree. Stopping the Firewall Engine driver (by using net stop fweng /y at the command prompt) also stops the other firewall components, which opens the computer to all network traffic. In contrast, stopping the Firewall service (by using net stop fwsrv at the command prompt) places the ISA Server computer in lockdown mode and allows only a limited set of protocols to and from the ISA Server computer itself.

     

    The Firewall Engine driver hooks into the Windows networking protocol stack at two places. The first place is at a point early in packet processing, after the Internet Protocol security (IPsec) driver, but before any reassembly is done. This can be considered as a filter layer between layer 2 (Media Access Control) and layer 3 (Network). This hook into the Windows networking stack allows ISA Server 2006 to inspect traffic before it gets to the first layer (Network or layer 3) of the operating system’s TCP/IP protocol stack. Because of this low-level hook into the Windows networking stack, the driver protects the Windows TCP/IP protocol stack from attack.

     

     

    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.

  4. wir haben offensichtlich unterschiedliche Ansätze - ich schieb das jetzt einfach mal auf das Umfeld in dem wir arbeiten. Über Details können wir uns ja mal bei nem Bier unterhalten ;)

     

     

    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

  5. @Velius: Wie gesagt, ich sehe da auch nur potentielle Sicherheitsprobleme - bekannt sind mir keine. Durch die Tatsache, dass so viel auf der Maschine läuft würde ich das Risiko aber nicht eingehen und in meinem Umfeld auch nicht einsetzen. Die stärken vom ISA liegen da meiner Meinung nach an der inneren FW - dort kann man die zusätzlichen Funktionen gebrauchen und das Risiko ist deutlich geringer.

     

    ... wenn der ISA mal auf nem 2008 core läuft, dann schaue ich mir das ganze noch mal an ;)

     

    Gruß

     

    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!;)

  6. @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:

  7. 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.

  8. Na ja, die Specs sagen da schon was dazu:

     

    VPN Functionality: Two hundred (200) dedicated VPN tunnels, Manual key and Internet Key Exchange Security Association (IKE SA) assignment with pre-shared key and RSA/DSA signatures, key life and IKE lifetime time settings, perfect forward secrecy (Diffie- Hellman groups 1 and 2 and Oakley support), operating modes (Main, Aggressive, Quick), fully qualified domain name (FQDN) support for dynamic IP address VPN connections.

     

    ...nur, wie man das konfiguriert ist eine andere Frage.

  9. Greife ich aber von einem Client (10.0.0.x) auf den Standtort klappt nix - wars***einlich weil die Standorte das gleiche Netzwerk haben.

     

    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

  10. Richtig. Anders würde das ganze Szenario doch sowieso nicht funktionieren.

     

    Gruß Jens

     

    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:

×
×
  • Neu erstellen...