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

[K. Dreier]

Hallo Martin,

sensationell, super Input! 

mad-one schrieb am So, 25 Januar 2015 14:08
> Wie ich sehe, trägt dein Studium der Doku schon ein paar Früchte.
> :) Sehr gut!

Naja, es heisst ja immer: wer lesen kann, ist klar im Vorteil. Aber: man
muß es dann halt auch noch verstehen...  :d 

Zitat:
> 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!

Standard: REJECT.

Zitat:
> 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.

Eben, und das soll - zumindest für mein zukünftiges Setup - gerade
nicht der Fall sein.

Zitat:
> 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)

Steht so in der base.txt, wenn auch via dem Standard N='1' nicht aktiv.
Hab halt meine weiteren Regeln einfach als 3 usw bezeichnet, weswegen
nun 2 mit drin ist. Soll ich das löschen?

Zitat:
> 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.

Hab ich dahingehend aus der Doku: "if:br0:any tmpl:dns @xbox
IP_NET_1_IPADDR ACCEPT".

Zitat:
> 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.

Sowohl
PF_INPUT_x='if:dynamic:any prot:tcp 22 ACCEPT'
als auch
PF_INPUT_x='dynamic prot:tcp 22 ACCEPT'
wie auch 
PF_INPUT_x='prot:tcp dynamic 22 ACCEPT'
gibt einen Fehler?

Zitat:
> 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.

Hätte ich mal einen Kaffee mehr trinken sollen. Macht absolut Sinn!

Zitat:
> 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.

Fehlermeldung beim build?

Zitat:
> Zitat:
> > 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)?
> 
> 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!

Alles klar.

Zitat:
> 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".

Ok, das heißt aber, daß dafür dann auf keinen Fall
PF_INPUT_x='IP_NET_3' gesetzt sein darf, richtig?

Zitat:
> 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.

Logik: weil fli4l sozusagen (via "REJECT") eine Mauer zwischen 1 und 3
gebaut hat, die man nur mit einer Leiter ("FORWARD") überwinden kann,
richtig?
Wenn ich also bei mir NET_1 _auf_ NET_3 unbeschränkten Zugriff erlauben
will, aber nicht umgekehrt, dann muss es noch das haben:
PF_FORWARD_x='IP_NET_1 IP_NET_3 ACCEPT'. Oder?

Zitat:
> Zitat:
> > Zugang für NET_3 zu z.B. DNS
> 
> 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.

Perfekt, das ist jetzt logisch, wenn man es mal verstanden hat.  :) 
Jetzt muß ich konkret das allerdings noch testen. Noch fehlt mir die
Hardware.

Zitat:
> Ich hoffe ich konnte dir erst einmal weiter helfen.

Definitiv!

Gruß
Klaus