ersetzen gut iptable-rules eine firewall ... irgendwie macht doch eine fw auch nix anderes als iptables...
Wenn es eine Application-Firewall ist, dann filtert sie nicht nur Empfänger/Absendeadressen, Ports und TCP/UDP/ICMP usw., sondern kann auch bedingt tatsächlichen Inhalt von Packeten filtern. Letzteres dient um bestimmte Daten auf Application-Ebene zu filtern um so Dienste richtig zu identifizieren und zu Filterln. TCP 80 muss nicht zwangsläufig HTTP sein.
Auch wenn die Hersteller das immer in der Vordergrund stellen, ist dies kein Ersatz für ein richtiges Instrusion Detection System. Jedoch haben alle verfügbaren IDS auf dem Markt ihre Schwächen, da sie entweder auf reiner Mustererkennung arbeiben (z.B. snort) oder nicht genügend Attacken erkennen oder anderwertig ausgetrickst werden bzw. eine sehr hohe Anzahl von False Postives erzeugen. Ein modernes System, welches das Beste aus allen Welten zusammenführt befinden sich in der frühen Entwicklungsphase und wird unter eine leicht abgewandelten Mozilla-License verfügbar sein. Wann? Wenn es fertig ist ;-)
In jedem Fall ist eine Application-Layer Firewall zum Filtern von Diensten statt einem reinen Packet-Filtering vorzuziehen. Reines Packetfiltering lässt sich oft durch diverse TCP-Segment-Boundary Tricks überlisten. Allerdings muss man dafür wirklich Ahnung haben. Die Script-Kiddies können so was nicht und es sind auch keine derartigen Fertiglösungen im Umlauf. 90% aller Hacks basieren auf Exploits. So ist am allerwichtigesten immer alle Sicherheitslücken zu stopfen, wenn du deine DMZ-Architektur geplant hast, um die Kommunikationspfade zwischen internen und externen Netzen zu steuern. Das von mir angesprochene System im Entwicklungsstadium übernimmt auch die Analyse von Exploits und kann sie auf Wunsch im gesamten Netz auf Aufforderung oder automatisch stopfen, wann immer sie auftreten... und einiges mehr...
Wichtig: Eine Firewall Maschine soll immer dediziert sein, dass heist keine weiteren Dienste darauf, wie z.B. Webserver oder dergleichen. Sowas gehört in die DMZ.
Ansonsten:
- alle Dienste, die von aussen ansprechbar sein sollen bzw. direkt mit der Außenwelt kommunizieren kommen in die DMZ.
- Alle internen Clients, die mit der Außenwelt kommunizieren müssen, tun dies über Proxies in der DMZ.
- Das externe Gateway schützt die DMZ vor ungewolltem Traffic und legt fest wie die Außenwelt mit der DMZ kommuniziert.
- Das internet Gateway schützt das interne Netz vor ungewolltem Traffic und legt fest wie DMZ und internes Netz kommunizieren. Auf diese Weise baut man auch die Zwangsproxies.
- DNS is ein Sonderfall. Du setzt einen in die DMZ, der für die Außenwelt die Namensauflösung übernimmst. Intern setzt du noch einen auf, der dies für das interne Netz tut. Auf die Weise kommt die Außenwelt niemals an interne Namen heran und die interne Namesauflösung läuft wie gewünscht (mehr dazu findest du im Netz unter dem Thema "internal and external Namespace")
- Beim Einsatz von NAT, hast du vereinfacht gesagt, keine direkte Kommunikation zwischen der Außenwelt und Clients hinter der NAT, weil du ja viele Clients über eine IP-Adresse Huckepack mit in die Außenwelt nimmst. Die NAT betreibt bei bestimmten Diensten dann das von dir genannte Port-Forwarding. Beispiel: Erhält dein externes Gateway eine Anfrage auf Port 80, schickt die das Packet z.B. an den WWW Server in deiner DMZ, bekommt von dem die Antwort zurück und schickt sie an den Anfragenden zurück. Generell ist NAT eigentlich weniger ein Sicherheitsmechanismus sondern mehr eine Technologie, damit man weniger öffentliche IP Adressen benötigt. Hast du mehrere öffentliche IP-Adressen solltest du diese auch für die Server in der DMZ nutzen. Für das interne Netz ist dies eigentlich egal, da dort auch kein Portforwarding nötig sein sollte bzw. keine direkte Kommunikation mit der Aussenwelt stattfindet. So ist eingeltich auch gar kein NAT notwendig ist. Dein intenes Gateway weiss ja, wie es mit den privaten Addressen umgehen soll bzw. sie routen muss. Der Rest findet im optimalen Falle nur über Proxies statt. NAT benötigst du höchsten für die Server in der DMZ, wenn du zuwenig öffentliche IP-Adressen hast. Ausnahme natürlich, wenn du Dienste im internen Netz benötigst, für die du keine Proxy-Lösung bauen kannst. Für so einen Fall würde ich aber eine Terminal-Server-Lösung in die DMZ setzen. Oh weh jetzt wird's kompliziert :?
Wenn es weitere umfangreiche Kommunikation z.B. mit Einwahlknoten und der gleichen gibt, empfiehlt es sich, die Architektur weiter zu unterteilen und bei mehreren Anschlüssen zum Internet gar ein Routing Netzwerk aufzubauen. Aber das führt jetzt alles was sehr weit.
Hoffe, dies hat dir erstmal weitergeholfen bzw. dir die Möglichkeiten für eine saubere, kontrollierte und skalierbare Architektur aufgezeigt.
