Port-Veröffentlichung und Firewall-Regeln ...

[gadrecs]

Hallo zusammen,

wir haben folgendes Szenario:

In einer Filiale steht für 3 Rechner ein eigener 1611er, der nur dazu da ist, einen auf einem dieser Rechner laufenden SSH-Server zu veröffentlichen.
Wir haben nun diesen Router so konfiguriert, dass der Port 22 auf die entsprechende interne IP geforwarded wird.

So weit so prima, geht auch alles zu ererichen (per Filezilla mit ssh kein Problem).
Was wir nun gerne noch hätten ist dann leider das, was nicht funktioniert:

Eine Firewall_Regel, welche es nur bestimmten externen IPs erlaubt diese SSH-Veröffentlichung zu benutzen (also das z.b. nur die IP 123.123.123.123 sich diesen Port nehmen und benutzen kann, sonst keiner.

Wir haben nun mit den Firewall-Regeln gespielt und folgendes festgestellt:

1) DENY_ALL regel: kein Connect möglich
2) keine Regel: Connect von JEDER ext. station möglich

und jetzt wirds dubios:

3) Allow Port 22 kommend von a.b.c.d danach Deny_all : kein connect.

Kann es sein, das bei Port-Forwarding die Firewall nicht greift ?

oder haben wir einen Denkfehler ? Kann mir jemand ein Filter-Set für die Firewall posten, wie es sein sollte ?

Vielen Dank im Voraus !

Grüße aus München,

Markus

[filou]

Hallo Markus,

Sollte eigentlich funktionieren, wenn du...

Quellstation: 123.123.123.123
Zielstation: SSH-Server-IP
Zielport: 22
sofort weiterleiten

eingestellt hast.

Lass dir gegebenenfalls die Meldungen der ALLOW_SSH und DENY_ALL per SNMP an den Lanmonitor ausgeben. Damit siehst du zeitnah, wo etwas hakt.

[Elektrolurch]

Hallo,
hast Du vielleicht ein Häkchen gesetzt bei 'Weitere Regeln beachten, nachdem diese Regel zutrifft'?
Dann deaktiviere das mal.
Hat mir auch mal einen Strich durch meine Architektur gemacht; vielleicht kann ja mal einer der Spezialisten erklären, was es mit dieser Option auf sich hat?
Gruß

[backslash]

Hi Elektrolurch

vielleicht kann ja mal einer der Spezialisten erklären, was es mit dieser Option auf sich hat?

normalerweise wird die Regelliste "von oben nach unten" abgearbeitet und sobald eine Regel matcht, werden die in der Regel definierten Aktionen ausgeführt (Accekt, Drop, Reject, Midestbandbreite, Maximalbandbreite, etc.)

Nun gibt es aber Konstellationen, in denen man mit einer Regel nicht auskommt: z.B. User x soll im Internet eine Mindestbandbreite 100 kBit haben *und* alle User im Netz (also auch User x) sollen im Internet gemeinsam nicht mehr als 1 MBit nutzen (damit noch genug für das VPN übrig bleibt...).

Das kann man nur mit zwei verketteten Regeln erschlagen:

Code: Alles auswählen

Name:    USERX
Quelle:  IP von User x
Ziel:    alle Stationen
Dienste: alle Dienste
Aktion:  Übertragen
Qos:     Mindestbandbreite 100kBit, global

[x] weitere Regeln beachten


Name:    ALLUSER
Quelle:  alle Stationen im likalen Netz
Ziel:    alle Stationen
Dienste: alle Dienste
Aktion:  Übertragen
         Trigger: 1000 kBit/s, global: verwerfen

[ ] weitere Regeln beachten

hier matchen auf Pakete von User 1 beide Regeln und es werden alle Aktionen der beiden Regeln ausgeführt.


Wenn jetzt in der zweiten Regel das Häkchen wieder gesetzt wäre, würde die nächste matchende Regel gesucht. Wenn das dann die Deny-All Regel ist, wird auch deren Aktion (zurückweisen) ausgeführt - und da zurückweisen "stärker" ist als übertragen, würde das Paket auch tatsächlich zurückgewiesen...

Gruß
Backslash

[Elektrolurch]

Hallo backslash,

vielen Dank für die Erklärung.

Ich habe das Problem einander widersprechender Regeln bisher nur durch deren Anordnung zu lösen versucht.
Also priorisiere ich z. B. ALLOW_INET vor DENY_ALL, ohne das Häkchen zu setzen.
Mit gesetztem Häkchen müsste ich also die Reihenfolge dieser beiden Regeln vertauschen.

Also wird nach dem Matchen einer Regel ohne Häkchen das Paket nicht weiter gefiltert; Eine QoS-Regel nach ALLOW_INET wäre also wirkungslos....

Habe ich das nun richtig verstanden?

Gruß vom Elektrolurch.

[backslash]

Hi Elektrolurch

Ich habe das Problem einander widersprechender Regeln bisher nur durch deren Anordnung zu lösen versucht.

einander wiedersprechende Regeln sind auch nur durch ihre Reihenfolge sinnvoll anzuordnen...

Also priorisiere ich z. B. ALLOW_INET vor DENY_ALL, ohne das Häkchen zu setzen.

gerade in diesem Fall ist das auch die einzige Möglichkeit.

Mit gesetztem Häkchen müsste ich also die Reihenfolge dieser beiden Regeln vertauschen.

Dann würden die Pakete wieder verworfen, weil eine "Reject" oder "Drop" Aktion (die nun ja "oben" steht) immer stärker ist als eine "Accept" Aktion..

Also wird nach dem Matchen einer Regel ohne Häkchen das Paket nicht weiter gefiltert;

richtig. Ohne das Häkchen bricht die Bearbeitung an dieser Stelle ab.

Eine QoS-Regel nach ALLOW_INET wäre also wirkungslos....

exakt. Die müßte vorher stehen.

Gruß
Backslash

[Elektrolurch]

Vielen Dank für die ausführliche Aufklärung! Ich werde wohl mal meine Regelliste überarbeiten und alles explizit testen müssen...

Gruß vom Elektrolurch