grundsätliche Frage zu pf und einfache Regeln zum Blockieren des Internetzugangs

[pbtraveller]

Hi,

wollte auf meinem Router (Freebsd 8.1-RELEASE) ein paar Firewall-Regeln aufsetzen und hierfür pf benutzen.

Der Router ist mit vr0 am ADSL-Modem angeschlossen und vr1-vr3 sowie wlan0 bilden bridge0.

Der Router ist für das NAT zuständig und soll außerdem den Zugriff aufs WAN (surfen im Netz etc.) von einem host, der über vr2 angeschlossen ist, untersagen. Der Zugriff auf diesen Rechner von anderen Rechnern im LAN soll aber möglich bleiben.

Ich habe also folgedes in meine /etc/pf.conf eingetragen:

###############
extif = "tun0"
intif = "bridge0"

host1 = "{192.168.1.8}"
host2 = "{192.168.1.6}"

table <darfnichtraus> { $host1 $host2}
table <nichtintern> {!192.168.1.0/24}


nat on $extif from $intif:network to any -> ($extif)

block drop out log quick on $extif from <darfnichtraus> to <nichtintern>

#################################

Für einen Augenblick schien es zu funktioniert. Jetzt aber kann ich von host2 weiter im Netz surfen, E-Mails verschicken etc.

Was mach ich falsch?

Noch eine grundsätzliche Frage. Nach meiner Vorstellung könnte ich das obige theoretisch dadurch erreichen, dass ich entweder den ausgehenden Verkehr auf $extif blocke, der von host2 kommt und ins WAN will (wie im obigen Beispiel versucht), oder den eingehenden Verkehr auf $intif, der von host2 kommt und ins WAN geht oder habe ich hier etwas nicht verstanden? Eigentlich dürfte das doch, insbesondere wenn ich die Regel mit "quick" verwende, keinen Unterschied machen.

Danke für Eure Hilfe!

Gruß

pbtraveller

[gnrp]

Hi,

Was mach ich falsch?

Noch eine grundsätzliche Frage. Nach meiner Vorstellung könnte ich das obige theoretisch dadurch erreichen, dass ich entweder den ausgehenden Verkehr auf $extif blocke, der von host2 kommt und ins WAN will (wie im obigen Beispiel versucht), oder den eingehenden Verkehr auf $intif, der von host2 kommt und ins WAN geht oder habe ich hier etwas nicht verstanden? Eigentlich dürfte das doch, insbesondere wenn ich die Regel mit "quick" verwende, keinen Unterschied machen.

ich würde einfach mal ins blaue schießen und vermuten, dass genau das der Fehler ist.
Auf deinem externen Interface hast du die Adresse schon genattet, d.h. pf sieht nicht mehr die interne Adresse, sondern nur noch die des externen Interfaces. Deswegen würde ich mal deinen zweiten Vorschlag ausprobieren, Traffic auf dem internen Interface zu blocken.

gnrp

[pbtraveller]

Daran scheint es nicht zu liegen. Mit folgender Regel habe ich auch Zugriff auf das WAN

block in quick on $intif from <darfnichtraus> to <nichtintern>

Gruß

pbtraveller

[mark05]

hi

also lass das quick im block weg sonst matched keine regel mehr

ansonsnten solltest du lieber "andersrum" arbeien

block on $intif all

pass quick on $lanif proto tcp from <darfraus> to any port 80 keep state

holger

[pbtraveller]

Um ehrlich zu sein, verstehe ich nicht, was es bringen soll, quick zu entfernen. "quick" führt nach meinem Verständnis doch nur dazu, dass nach dem match nicht weitere Regeln abgearbeitet werden, es eben bei diesem block bleibt und das soll es ja auch (mal abgesehen davon, dass es gerade von der nat regel abgesehen, die einzige ist)! Habe es auch ausprobiert, es bringt tatsächlich nichts.

Hatte natürlich vor, es später andersrum zu machen, allerdings brauche ich dafür mehr Zeit, die ich gerade nicht habe.

Sonstige Ideen an was das liegen könnte? Danke und Gruß

pbtraveller

[mark05]

quick bedeutet das pf sofort auf hoert das packet weiter zu verarbeiten wenn eine regel matched.

und block ist nu mal eine regel.

siehe man pf.conf quick

quick If a packet matches a rule which has the quick option set, this
rule is considered the last matching rule, and evaluation of sub-
sequent rules is skipped.

und das anders rum ist im zweifel weniger aufwendig als alles im einzelnen zu verbieten.
und ein pass quick on wan_if proto tcp from (wan_if) to any port {80,443,22,23,143,993,465} keep state


find ich nicht als aufwendig.


holger

[pbtraveller]

Zitat von mark05

quick bedeutet das pf sofort auf hoert das packet weiter zu verarbeiten wenn eine regel matched.

und block ist nu mal eine regel.

Eben drum!! Das hab ich ja gesagt! Deshalb müssten die Pakete von host2 ins Netz ja auch eigentlich durch diese Regel geblockt werden und dann ist Schluß, ergo es muss an etwas anderem haken!

Trotzdem danke!

pbtraveller

[pbtraveller]

Habe herausgefunden, woran es liegt! Die Regel darf am Ende keine Tabelle haben. Zudem müsste die Tabelle <nichtintern> ohnehin wie folgt aussehen: table <nichtintern> {0.0.0.0/24, !192.168.1.0/24}. Anyway, mit !$lan am Ende funktioniert es!

Gruß
pbtraveller

[pbtraveller]

oh Gott, ich bin doch schon zu müde. Es liegt natürlich nicht daran, dass am Ende keine Tabelle stehen darf. Diese war nur falsch und muss table <nichtintern> {0.0.0.0/0, !192.168.1.0/24} heißen...