[fli4l] PF_INPUT - ein?==?utf-8?Q? paar Verständnisfragen

[Martin Dresbach]

Hallo Klaus!

Wie ich sehe, trägt dein Studium der Doku schon ein paar Früchte. :)
Sehr gut!

Nun mal zu deiner Problematik...

Vorab erst mal eine grundlegend wichtige Frage: Verwendest du bei
PF_INPUT_POLICY als Wert "DROP" bzw. "REJECT"? Solltest du das aus
irgendeinem Grund auf "ACCEPT" gesetzt haben, ändert sich nämlich
alles!

Zitat:
> Konkret geht es mir im Moment darum, fi4l so wenig löchrig wie
> möglich zu machen.

Richtig so!

Zitat:
> Da ich dabei bin, mehrere IP_NET_x aufzubauen, will ich nicht
> einfach "22 ACCEPT" nehmen, da ich nicht will, daß z.B. mein
> späteres IP_NET_3 ebenfalls Zugang auf den SSH-Dienst vom fli4l hat.

Stimmt, mit dem "22 ACCEPT" würdest du dann nämlich auch Zugriffe aus
NET_3 (bzw. JEDEM, also auch extern) zulassen.

Zitat:
> Aktuell schaut es deswegen so aus:
> PF_INPUT_N='3'
> PF_INPUT_1='IP_NET_1 ACCEPT' # meine interne NIC
> PF_INPUT_2='tmpl:samba DROP NOLOG'
> PF_INPUT_3='if:IP_NET_2_DEV:any prot:tcp 22 IP_NET_1_IPADDR ACCEPT'
> --> Regel 3 funktioniert und erlaubt mir den Zugang von extern (ja,
> ich teste das nicht von meinem LAN aus ;-) Wink auf den SSH-Dienst
> (nur) von fli4l (_2_DEV ist meine WAN-NIC). Soweit so gut.

Erklärung dazu:
Regel 1 gewährt Zugriff auf ALLE Ports des Fli, wenn die Anfrage aus
NET_1 kommt. Alle anderen Netze haben KEINEN Zugriff.
Regel 2 verweigert alle Samba-Pakete, die an den Fli gehen. Hast du
diese Regel mit Absicht erstellt? Standard ist die nämlich nicht
(ausser in der FORWARD-Chain)
Regel 3 Auch wenn diese Regel (komischer Weise) funktionieren mag, ist
sie so nicht richtig. Das "IP_NET_1_IPADDR" gehört da nicht rein.
Ansonsten stimmt es aber und führt ja auch zum gewünschten Erfolg,
nämlich Port 22 für einen EXTERNEN Zugriff zu öffnen. IP_NET_2_DEV
kannst du übrigens auch durch "dynamic" ersetzen. Damit ist dann die
pppoe-Schnittstelle gemeint.

Zitat:
> Ich verstehe "if:x:y" anhand der Doku so, daß
> a) wenn (=if) etwas
> b) an x ankommt und
> c) an y weitergeht
> dann...
> Mit was genau kann man denn nun y eigentlich ersetzen? IP_NET_3 z.B.
> geht nicht, ebensowenig eine bestimmte IP.
> Und weiter nun eben die Frage, wie ich den Zugang zum Dienst nur
> für eine bestimmte (externe) IP erlauben kann?

Grundsätzlich ist dein Verständnis da gar nicht so falsch. Das "if"
steht allerdings nicht für "wenn", sondern für "Interface". X ist die
Quelle eines Paketes, Y das Ziel. In der INPUT-Chain ist allerdings
keine Ziel-Angabe zulässig, da das Ziel ja IMMER der Fli selbst ist.
Ziele könntest du z.B. nur in der FORWARD-Chain verwenden. Deshalb
funktioniert bei dir die Regel bei der Angabe einer IP nicht mehr.
Um nun beispielsweise den SSH-Zugriff von extern und NUR von einer
festen IP kommend freizugeben würdest du also lediglich deine Regel
PF_INPUT_3 ändern. Die könnte dann ganz einfach so aussehen:
PF_INPUT_3='1.2.3.4 prot:tcp 22 ACCEPT'. 1.2.3.4 wäre dann natürlich
durch die zuzulassende IP zu ersetzen.

Zitat:
> Die Tatsache, daß ich auch von meinem IP_NET_1 drauf komme (gut so,
> natürlich), sollte an 'IP_NET_1 ACCEPT' liegen, richtig?
> Inwiefern spielt dann hierzu das via PF_INPUT_ACCEPT_DEF='yes'
> aktive 'if:lo:any ACCEPT' (noch) eine Rolle? Ist das nicht dann
> redundant (wenn man nur ein Netz hat)?

Erster Teil: Richtig!
Zweiter Teil: Diese Regel bezieht sich auf das Loopback-Interface
(if:lo). Es dient der Fli-internen Kommunikation und wird für einen
reibungslosen Betrieb benötigt. Da sich diese Regel also nicht direkt
auf NET_1 oder NET_3 bezieht, ist sie auch nicht redundant! Wenn du also
keinen wirklichen Grund hast, solltest du die Standardregeln
(PF_INPUT_ACCEPT_DEF='yes') nicht deaktivieren.

Zitat:
> Anders gefragt: gäbe es jetzt noch ein IP_NET_3, wie würde ich
> dann verhindern, daß die dort drin liegenden clients auch Zugang zu
> Port 22 auf fli4l hätten?

Das hast du schon erledigt, da du es nicht explizit erlaubst.
Vorausgesetzt, du verwendest halt für PF_INPUT_POLICY als Wert "DROP"
bzw. "REJECT".

Zitat:
> da ich mein IP_NET_3 eigentlich eher grundsätzlich (mit Ausnahmen)
> auch von innen nach aussen "dicht" machen will, insbesondere eben
> verhindern möchte, dass _3 auf _1 Zugriff hat

Die Kommunikation zwischen NET_1 und NET_3 (bzw. einzelner Clients
darus) regelst du dann sowieso nicht mehr über die INPUT-Chain, sondern
über die FORWARD-Chain.

Zitat:
> und dann mit diversen weiteren Regeln den Zugang für NET_3 zu z.B.
> DNS explizit erlauben

Ganau das macht man ja ohnehin schon, solange man für PF_INPUT_POLICY
als Wert "DROP" bzw. "REJECT" nutzt. Alles, was man dabei nicht explizit
erlaubt, ist implizit verboten!

Zitat:
> Wie könnte so eine Regel denn aussehen? So:
> PF_INPUT_x='if:IP_NET_3_DEV:any tmpl:dns IP_NET_3_IPADDR ACCEPT'?

Wenn du den DNS-Zugriff für ALLE NET_3 Clients auf den Fli erlauben
willst, würde PF_INPUT_x='IP_NET_3 tmpl:dns ACCEPT' reichen. Um den
Zugriff für nur EINEN Client aus NET_3 zu erlauben könntest du dann
PF_INPUT_x='1.2.3.4 tmpl:dns ACCEPT' verwenden, wobei hier 1.2.3.4 der
IP des Clients entspricht.

Ich hoffe ich konnte dir erst einmal weiter helfen.

Liebe Grüße,
Martin