News: This forum is now permanently frozen.
Pages: [1]
Topic: Firewall und Routing der m0n0wall richtig konfigurieren?!  (Read 5242 times)
« on: February 23, 2013, 18:11:56 »
Bratfisch *
Posts: 4

Hallo zusammen, ich bin dabei ein Gastnetz für unsere Ferienwohnung aufzubauen. Zur Hilfe habe ich mir dafür das Tutoral von administrator.de genommen. Leider ist dort nicht richtig erklärt wie ich die Firewall und das Routing richtig einstelle.

Folgende Konfiguration ist vorhanden:

Als Hardware dient ein ALIX Mainboard 2D13 mit der aktuellen m0nowall Software drauf.

Nezte sind folgende eingestellt:

LAN: 192.168.1.X Soll für das Private Hausnetz dienen
WAN: 192.165.0.X Hier vor hängt eine Fritzbox die der m0n0wall per DHCP eine IP vergibt.
DMZ: 10.0.0.X Soll das Gastnetz werden mit CP login

Das CP Portal ist eingerichtet und funktioniert wunderbar mit Voucher Codes

Was ich aber einfach nicht hin bekomme ist die vernünftige Routing bzw. Firewall Verwaltung. Bisher sind nur zwei Regeln in der Firewall für das LAN und den DMZ eingetragen nämlich diese das sie alles dürfen, was ich aber nicht möchte. Momentan können die Gäste auf die Rechner im LAN Netz zugreifen und auf alles was in dem WAN Netz hängt.

Ich hätte gerne das das LAN und das DMZ Netz getrennt voneinander sind und das DMZ Netz "nur" in das Internet gehen kann.

Wie realisiere ich das?

Danke schon mal für die Hilfe.

Gruß Bratfisch

« Reply #1 on: February 26, 2013, 22:24:16 »
terrano74 *
Posts: 8

Also..., wenn du nicht möchtest, das die DMZ-Rechner auf dein LAN zugreifen dürfen, dann musst du das der Firewall in Form einer Regel genau so mitteilen. Du gehst in den Rules auf Interface DMZ und erstellst dort eine neue Regel.
Action: Block
Interface: DMZ
Protokoll: any
Source: DMZ subnet
Destination: LAN subnet
Und das wars schon. Damit blockt die Firewall jeglichen Traffic aus dem DMZ-Netz in das LAN. Wenn du das umgekehrt genauso willst, dann erstellst du im Bereich LAN die selbe Regel nur mit vertauschten Source und Destination. Alles zu erlauben ist eigentlich auch nicht wirklich sinnvoll. Dann kann man sich auch ne Firewall sparen. Ich würde weitere Regeln festlegen. Eine umfangreiche BestPractise wirst du aber nicht so bekommen, da die Rules doch stark von deiner Umgebung und den verwendeten Programmen abhängen. Nur soviel: Im Gastnetz habe ich nur ICMP, 80 und 443 nach draußen geöffnet. Grundsätzlich: Je mehr du verbietest, desto sicherer wird das Ganze aber umso mehr musst du dich auch mit der Materie auskennen, um spezielle Ausnahmen zu definieren.
Warum hast du vor der Monowall noch ne Fritzbox? Ein einfaches Modem genügt in den meisten Fällen. Die Monowall kann sich selbst über PPOE einwählen. Ist nur ein weiter PointOfFailure. Wink
« Reply #2 on: February 27, 2013, 14:59:21 »
Bratfisch *
Posts: 4

Hallo terrano74,

danke schon mal für die Hilfe mit dem Netz. Das hatte ich die Tage schon selber hin bekommen und es tuts auch. Habe dann noch etwas weiter rumgespielt, leider bekomme ich es nicht hin die m0n0wall direkt zu blockieren aus dem DMZ Netz. Ich habe folgendes gemacht:

eine Blockregel vom DMZ Netz auf die Statische IP der m0n0wall in diesem Fall 10.0.0.1. Hierbei habe ich alles geblockt.
In zwei weiteren Regel habe ich den DNS Port und den 8000 Port auf die m0n0wall freigegeben.
Tuts aber leider nicht. Damit wollte ich verhindern, dass man aus dem DMZ Netz auf die HTTP Seite der m0n0wall kommt.

Nur ICMP, 80 und 443 reicht das? Könnten die Gäste damit dann Mails empfangen, ICQ, Skype etc. nutzen ohne die Ports extra umstellen zu müssen?

Fritzbox brauche ich noch, weil dort die ISDN Telefonanlage mit dran angeschlossen ist zwecks FAX Empfang über ISDN und Versenden per Mail.

« Reply #3 on: March 04, 2013, 22:05:47 »
terrano74 *
Posts: 8

Das wird so nicht funktionieren. Firewallregeln können immer nur zwischen Netzen arbeiten. Innerhalb eines Subnetzes gibt es keine Firewallregeln. Eine Firewall kann ja nur den Traffic bearbeiten, der durch sie hindurch geht. Innerhalb des Netzsegments (alle Knoten mit der IP 10.0.0.x) können aber die Rechner direkt miteinander kommunizieren, ohne das Gateway anzusprechen. Daher kann dieser Traffic auch nicht durch Regeln eingeschränkt werden. Eine Funktion, die Management-IP der monowall auf nur ein Interface festzunageln habe ich leider bisher noch nicht gefunden. Ist in meinen Augen auch eine Funktion, die alle professionellen Systeme haben, hier aber noch fehlt. Du kannst also die monowall nur durch ein sicheres Passwort schützen. Benenne den Usernamen "admin" um in irgendwas anderes, zBsp "heinbloed" oder ... - dir fällt da schon was ein Grin. Und das Passwort kryptisch und mindestens 10-12 Zeichen. Wenn du dann jemanden in deiner DMZ hast, der das knackt, hast du - glaube ich - noch ganz andere Probleme.

Bei deinen ganzen Regeln musst du beachten, das die Blockregel immer die letzte Regel in der Liste ist. Die Firewall nimmt immer ein Paket und arbeitet damit die Liste der Regeln von oben nach unten ab. Die erste Regel, die matcht, wird dann auf das Paket angewendet. Deshalb beginnt man möglichst immer mit den Pass-Regeln für die Ports, bei denen der höchste Traffic erwartet wird. Vereinfacht sieht das dann so aus:
Pass 80
Pass 443
Pass 21
Pass ICMP
Block All
Wenn jetzt eine FTP-Paket kommt, dann würde die 3. Regel matchen und das Paket wird durchgelassen. Kommt aber ein RDP-Paket (3389), dann findet die Firewall keine Passregel und wendet die Blockregel an. Das Paket wird abgewiesen.
Deine Regeln für 80 und 443 erlauben den Usern halt zu surfen und Webmail zu machen. Sollen sie auch mit richtigen Mailclients arbeiten können, so must du SMTP, POP3 und IMAP zzgl. deren Secure-Ports freigeben. Und damit die ganzen Messenger richtig funktionieren, wird empfohlen auch die Ports ab 1024 aufwärts freizugeben. (https://support.skype.com/de/faq/FA148/welche-ports-mussen-offen-sein-damit-skype-fur-windows-verwendet-werden-kann)
Du siehst, je mehr du zuziehst, desto mehr musst du dich mit den einzelnen Anwendungen beschäftigen, die dann noch funktionieren sollen. Wink
« Reply #4 on: March 05, 2013, 13:39:51 »
Bratfisch *
Posts: 4

Hm ok einleuchtend ist das, aber warum haben die das dann auf administrator.de so beschrieben?

https://www.administrator.de/wissen/wlan-oder-lan-gastnetz-einrichten-mit-einem-captive-portal-hotspot-funktion-91413.html

Da steht unter anderem:

"Du verlagerst das Webinterface auf einen anderen Port. Es gibt aber eine andere und bessere Möglichkeit:
Wenn man im Advanced Menü die "Antilockout-Regel" abschaltet, kann man den Zugang per Firewall für das Gast-Netz blocken.
Bei sämtlichen Captive Portal-Installationen, die ich mit m0n0wall bisher gemacht habe, habe ich wie folgt gearbeitet:

    Antilockout-Rule deaktiviert
    sämtlichen Traffic auf den Router geblockt
    TCP/UDP 53 auf den Router erlaubt
    TCP 8000 (Captive-Portal-Port) auf den Router erlaubt

Damit kommt man nicht an das Webinterface dran, egal wie sehr man sucht und es funktioniert trotzdem alles."


Wenn das klappen würde wäre ja cool...
« Reply #5 on: March 05, 2013, 17:43:29 »
Lennart Grahl ***
Posts: 153

Es ist durchaus möglich, den Zugang auf das Webinterface für ein bestimmtes Interface zu sperren. Dafür braucht man nicht einmal die "anti-lockout rule" zu deaktivieren, solange das für das Webinterface zu sperrende Netzwerk nicht "LAN" ist.
Es stimmt zwar, dass m0n0wall keinen Einfluss auf Traffic innerhalb eines Subnetzes hat, jedoch wirken trotzdem die Firewallregeln für sämtliche Pakete, die m0n0wall selbst betrifft (und somit auch der Zugang auf das Webinterface).

Noch eine Anmerkung für terrano74: Man braucht keine "Block all"-Regel zu erstellen, da bei m0n0wall generell alles geblockt wird, was nicht explizit erlaubt ist.

Bei Firewall-Regeln immer daran denken, dass die Regeln von oben nach unten gelesen werden. Sobald eine Regel zutrifft, wird diese ausgeführt. Der Rest der Liste wird nicht mehr beachtet. Somit lässt sich für dein Beispiel folgendes machen (192.168.87.1 ist die IP von m0n0wall):
Klick mich!

Einige Anmerkungen hierzu:
  • Wichtig ist, zu wissen, dass eingehende Pakete nur für das in der Regel eingestellte Interface zutreffen. Somit kann man sich bei Block-Regeln die Benennung der Quelle (Source) oft sparen, jedoch nicht bei Pass-Regeln.
  • Block-Regeln weise ich keine Quelle (Source) zu, da diese Regeln auch für Clients mit manuell eingestellter IP-Adresse, aus einem anderen Subnetz, gelten sollen.
  • Pass-Regeln weise ich eine Quelle (Source) zu, damit diese Regeln ausschließlich für das dafür zugewiesene Subnetz gelten.
  • Die erste Regel verhindert den Zugriff auf das Webinterface und muss vor der dritten Regel stehen, hätte aber auch hinter der zweiten Regel stehen können.

Trotz des Beispiels, möchte ich abschließend noch anmerken, dass ich es für wenig sinnvoll halte, die nach außen nutzbaren Ports der Gastzugänge zu reduzieren. Wer Blödsinn machen möchte, kriegt das auch über Port 80 hin. Die normalen Gäste werden sich nur darüber ärgern, dass sie viele ihrer Programme nicht nutzen können.
« Last Edit: March 05, 2013, 17:50:34 by Lennart Grahl »
« Reply #6 on: March 06, 2013, 02:36:57 »
terrano74 *
Posts: 8

Hallo Lennart,
vielen Dank für deinen Hinweiß. Ich bin das mit der Blockrule so von anderen Systemen gewohnt und habe das Schema ohne weiter zu hinterfragen hier übernommen.
Auf die Idee mit der ersten Blockrule für das Management-Interface bin ich auch gerade gekommen und wollte das noch nachtragen. Manchmal sieht man den Wald... Bei Barracuda (womit ich hauptsächlich zu tun habe) ist es so geregelt, das eine Box eine Management-IP hat, die nicht der IP des Gateways für die Clients entspricht, da Management und Firewall und... einzelne Dienste mit individuell konfigurierbaren IPs sind. Die ManagementIP legen wir dann immer in ein VLAN, an das die normalen Clients nicht ran kommen. An der Stelle liegt der mono nur ein anderes Konzept zu Grunde. Ich muss halt etwas umdenken Smiley. Damit hat sich natürlich auch mein einer Featurerequest erledigt.
Also vielen Dank schon mal von meiner Seite für deine Ergänzungen.
VG
Micha
« Reply #7 on: March 16, 2013, 16:45:08 »
Bratfisch *
Posts: 4

Hallo Lennart Grahl,

genau diese Erklärung habe ich gesucht!!! Vielen Dank dafür.  Smiley
Ist das so einleuchtend was du da erklärt hast das ich es nirgends gefunden habe?

Jetzt klappt es auf jeden Fall so wie ich es wollte.

Gruß Heiko
 
Pages: [1]
 
 
Powered by SMF 1.1.20 | SMF © 2013, Simple Machines