RootForum Community

Hi,

ich habe eine Frage an die Experten unter euch, was den Aufbau eines kleinen Netzwerkes angeht.
Das DMZ ist wegen zusätzlicher Sicherheit installiert worden (ein Hacker müsste erst GW1 dann GW2 hacken um zugriff auf das Intranet zu erhalten.

Beide Gateways sind auf NAT (von innen nach aussen) konfiguriert und haben eine Firewall am laufen die keine offenen ports nach aussen hin hat.

Momentan läuft ein Webserver auf "Gateway1" (in der FW von GW1 ist auch der 80er erlaubt...).

Irgendwie ist mir aber der Webserver auf dem GW1 ein Dorn im Auge... Daher wollte ich den Webserver entweder an das DMZ oder gar an das Intranet hängen. Bei der Konfiguration der Firewall ist mir dann ein netter Satz aufgefallen, dass es ein Sicherheitsrisiko darstellt portforwarding zu verwenden. Es würde eben port 80 auf den Webserver im DMZ oder Intranet geroutet werden... Soweit ich mich erinnern kann ist portforwarding doch auch genau für diesen zweck gedacht??

Was meint ihr? so lassen wie es ist oder webserver ins DMZ oder Webserver in Intranet?

bye
Darky

p.s.

des weiteren wäre ich sehr an einem howto oder guide interessiert der sich mit dem Aufbau von netzwerken beschäftigt. Ich hab mal tldp nachgesehen, habe dort aber nur was über die netzwerkkonfiguration auf einem Einzelrechner nicht jedoch etwas mit bezug auf die konfiguration einer ganzen Netztopologie gefunden...

Ein solcher Webserver gehört natürlich (wie du schon ricjtig vermutet hattest) in die DMZ, das ganze per Port-Forwarding (wie es sich gehört ...)

ok thx für die antwort.

was ich auch noch fragen wollte:

ersetzen gut iptable-rules eine firewall ... irgendwie macht doch eine fw auch nix anderes als iptables...

bye
Darky

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.

Hi,

wow das hat glaube ich erst einmal fast alle Fragen beantwortet - vielen Dank!

Leider ist es hier tatsächlich nicht ganz einfach sämtlichen traffic (intern nach extern) über proxies zu lenken... Bei http, ftp ist es noch verhältnismässig leicht. Bei IRC fällt mir auf anhieb nur noch socks als lösung ein. Wenn ich mp3 streams mit winamp empfangen möchte sieht es schon sehr schwierig aus. Die leute hier im internen Netz sollen doch noch gewisse Freiheiten haben... :-)

Du sprichst das Thema Einwahlserver an - ist auch sehr interessant, da für die Zukunft ein VPN Zugangsserver geplant ist. Wo würde dieser normalerweise plaziert werden? ins interne netz, damit man wenn man sich eingewählt hat, auch zugriff auf alle internen fileserver etc hat, oder in die dmz, und das interne gateway mit einer rule versehen das den vpn server nach intern durchroutet?

bye
Darky

Socks Proxy ist schon mal richtig, aber auch der hat natürlich seine Grenzen, wie du richtig erkannt hast. Nur hat das natürlich in einem "sicheren" Netz nichts zu suchen. Ist aber letzendlich deine Entscheidung, was du als vertretbar zulässt. Solange die Anzahl der Dienste überschaubar ist, solle es kein Problem geben, da du ja weisst, worauf du besonders achten musst.

Vesuch halt alles möglichst über Proxies zu machen, damit du fest definierte Kommunikationspfade hast. Und wenn du besonderen Traffic durchlassen willst, dann bitte nicht mit ANY, sondern auf den IP-Bereich für deine Clients. Die internen Server sollten keinen Grund haben mit der Aussenwelt zu kommunizieren (höchstens mit der DMZ). Ã?ber DHCP ja kein Problem, da die Clients ja einen anderen Bereich als die Serve verwenden können.

Mailserver wären auch ein schönes Beispiel für eine gute Firewall-Architektur: In die DMZ packst du eine reines SMTP Frontend, das nur Mails von der Welt entgegennimmt und versendet. Der vollwertige Mail-Server steht im internen Netz. SMTP darf dann nur der interne zum externen machen. Der interne ist entsprechend konfiguriert, dass er den externen als SMTP-Forwarder (von mir aus auch "Relay" verwendet). Liesse sich gut mit dem externen DNS auf einer Maschine kombinieren.

Für VPN Implemenattionen gibt es mehrere Lösungen:
Du kannst sie im internen Netz betreiben und am internen Gateway die Ports des VPNs zum VPN Server durchlassen. Das ist dann der Betrieb hinter einer Firewall. Da der Verkehr dann aber ins Netz gelangt, bevor er den Server erreicht, rate ich davon ab, sonst kann man die berühmten Segment-Boundary-Tricks anwenden kann. Es gilt immer die Regel, keine direkte Kommunikation mit ANY vom internen Netz aus. Das ist ja bei einem VPN der Fall, da du nicht weisst mit welcher IP die Benuter kommen werden.

Nur in die DMZ geht nicht, da ja der Verkehr irgendwo reinkommen und im internen Netz wieder rauskommen muss. Ist das VPN nur in der DMZ, hat es ja keine Chance den Verkehr ins interne Netz zu schicken. Du müsstest dann wieder viele sensitive Dienste vom VPN direkt mit Rechern im internen Netz kommunizieren lassen. Dann hast du wieder unverschlüsselten internen Verkehr in der DMZ und würdest deine Firewall-Architektur selbst aushebeln. Hat jemand deinen WWW-Sever gehacked, sitzt er da genuesslich rum und horcht den Datenverkehr ab oder betreibt eine Man-In-The-Middle-Attacke.

Deswegen gibt es diese Lösung: Betrieb parallel zu einer Firewall bzw, besser gesagt zum Packet bzw. Application Filtering. In diesem Szenario hat das VPN einen Anschluss in der DMZ und einen Anschluß im internen Netz. Sprich das VPN ist der alternative Weg ins interne Netz für authentifizierte Benutzer mit verschlüsseltem gebündeltem Traffic. Und dafür brauchst du nur eine zusätzliche Netzwerkkarte...

Bei der zweiten Lösung darf das VPN natürlich auch auf dem internen Gateway sein, da es sich nur um eine andere Variante von zu filterndem Datenverkehr handelt. Anstatt IP, Port und Protokoll gilt dann authentifizierter Benutzer als Regel. Und was du dann welchen Benutzern wieder erlaubst kannst du auf Benutzerebene - wie gewohnt - regeln, da der Benutzer ja authentifiziert ist und du nicht mit IP-Adressen und so hantierst. Mit der Kombination Screening-Router und VPN haben wir direkt auch von einer möglichen Server-Konsolidierung gebrauch gemacht ohne das die Sicherheit in irgendeiner Form darunter leidet. Von mir aus kannst du auch noch einen RAS Dienst dazunehmen. Aber wenn du nen VPN hast, machst RAS eh keinen Sinn mehr und erzeugt nur horrende Kosten.

PS: Wie wärs mit verschieben ins Security-Forum, liebe Moderatoren?

scythe42 wrote:PS: Wie wärs mit verschieben ins Security-Forum, liebe Moderatoren?

Schon passiert ;)

hi,

die loesung den vpn-server direkt auf das interne gateway zu installieren ist natuerlich _genial_ ... ok dann werd ich das alles ma so ins auge fassen, und bedanke mich für die wirklich hilfreichen Informationen!

bye
Darky