PF auf Host, lo0 und ext_if = ?

lars

lars

vom mars
Hi all,

OS = OBSD3.3
SW = ssh, fetchmail, sendmail, Netztools

1 NIC; pf läuft auf gleicher Maschine wie SW, daher kein
ext_if und int_if.

Absicht:
Ich will die Maschine von aussen per ssh erreichen können;
per fetchmail Mails abrufen und per sendmail schicken können;
mit Netztools Tests über lo0 machen können;
durch pf maximalen Schutz geniessen.

Ergebnis:
Ich kann mit ssh verbinden, mit fetchmail Mails abrufen, mit sendmail
schicken und Netztools Tests über lo0 machen.

Test:
Code: 
bash-2.05b$ sudo nmap -vv -P0 -O 192.168.1.12
Password:
No tcp, udp, or ICMP scantype specified, assuming SYN Stealth scan. 
Use -sP if you really don't want to portscan (and just want to see what hosts are up).

Starting nmap 3.30 ( [url]http://www.insecure.org/nmap/[/url] ) at 2003-09-25 18:11 CEST
Host  (192.168.1.12) appears to be up ... good.
Initiating SYN Stealth Scan against  (192.168.1.12) at 18:11
Adding open port 22/tcp
The SYN Stealth Scan took 230 seconds to scan 1644 ports.
Warning:  OS detection will be MUCH less reliable 
because we did not find at least 1 open and 1 closed TCP port
For OSScan assuming that port 22 is open and port 34067 
is closed and neither are firewalled
Interesting ports on  (192.168.1.12):
(The 1643 ports scanned but not shown below are in state: filtered)
Port       State       Service
22/tcp     open        ssh
Device type: general purpose
Running: OpenBSD 3.X
OS details: OpenBSD 3.0 SPARC with pf "scrub in all" feature
OS Fingerprint:
(None)
TCP Sequence Prediction: Class=truly random
                         Difficulty=9999999 (Good luck!)
TCP ISN Seq. Numbers: A6B17EA9 A3E51547 F46D7352 F01A31F3
IPID Sequence Generation: Randomized

Nmap run completed -- 1 IP address (1 host up) scanned in 236.312 seconds

pf.conf:
Code: 
# Normalization: reassemble fragments and resolve or reduce traffic ambiguities.
scrub in all
scrub out all

# connections and keep state, logging blocked packets.
block in log all

# pass in ssh
pass in on fxp0 proto tcp from any to fxp0 port 22 keep state

# loopback: pass in/out all and keep state
pass in on lo0 inet proto { tcp, udp, icmp } from { lo0, fxp0 } keep state
pass out on lo0 inet proto { tcp, udp, icmp } to any keep state

# fxp0: pass out all and keep state
pass out on fxp0 proto { tcp, udp, icmp } to any keep state

Alles auskommentierte habe ich hier nicht gepostet.

Frage:
Machen diese Regeln Sinn?
Wo kann ich die Regeln kürzen?

Gruss,
Lars
 
also meine pf.conf wuerde in diesem falle wie folgt aussehen:

scrub in on fxp0 all random-id
scrub out on fxp0 all random-id

antispoof for lo0
block in log on fxp0 all
pass out quick on fxp0 proto tcp from $int_ip to any modulate state
pass out quick on fxp0 proto { udp, icmp } from $int_ip to any keep state

wenn moeglich noch die ports definieren auf die er raus darf.
 
Hallo

Ich habe deine Regeln übernommen und meine Änderungen hinzugefügt.

So würde ich es anwenden, wenn ich deine Maschine warten würde:

# Normalization: reassemble fragments and resolve or reduce traffic ambiguities.
scrub in all

# connections and keep state, logging blocked packets.
block in log all

# pass in ssh
pass in quick on fxp0 inet proto tcp from any to fxp0 port ssh modulate state

# loopback: pass in/out all and keep state
pass quick on lo0 inet all

# fxp0: pass out all and keep state
pass out quick on fxp0 inet proto tcp all modulate state
pass out quick on fxp0 inet proto { udp, icmp } all keep state

So würde ich es machen :)

Gruß

CW
 
aeeehhh ja, ich vergass das pass in fuer ssh *blush*

CW macht er das keep state fuer lo0 automatisch? (bin nicht mehr so auf den neusten stand was pf.conf angeht).
 
Was haltet ihr davon?

Code: 
#	$OpenBSD: pf.conf,v 1.19 2003/03/24 01:47:28 ian Exp $
#
# See pf.conf(5) and /usr/share/pf for syntax and examples.
# Required order: options, normalization, queueing, translation, filtering.
# Macros and tables may be defined and used anywhere.
# Note that translation rules are first match while filter rules are last match.

# Normalization: reassemble fragments and resolve or reduce traffic ambiguities.
scrub in all random-id # unnötig, da pf auf gleichem host?
scrub out all random-id # unnötig, da openbsd?

# block all incoming packets but allow ssh, pass all outgoing tcp and udp
# connections and keep state, logging blocked packets.
block in log all queue std

# loopback: antispoof, pass in/out all and keep state
antispoof for lo0
pass in on lo0 inet proto { tcp, udp, icmp } from { lo0, fxp0 } keep state
pass out on lo0 inet proto { tcp, udp, icmp } to any keep state

# Caveat: Rules created by the antispoof directive interfere with packets
#     sent over loopback interfaces to local addresses.  One should pass these
#     explicitly. Habe ich im Abschnitt Antispoof von man pf.conf gesehen.

# queueing to enable incoming ssh connections under high load
queue std bandwidth 10% cbq(default)
queue ssh bandwidth 10% cbq(borrow) { ssh_interactive, ssh_bulk }
     queue  ssh_interactive priority 7
     queue  ssh_bulk priority 0
# Ist diese Regel korrekt geschrieben und reserviert bei Bedarf 10% des Traffics
# für ssh, wobei  scp und sftp niedriger priorisiert werden?
# So wie ich es verstanden habe, ist eine Default-Queue vorgeschrieben.

# pass in ssh
pass in quick on fxp0 inet proto tcp from any to fxp0 port 22 modulate state \
	queue(ssh_bulk, ssh_interactive)

# fxp0: pass out all and keep state
pass out on fxp0 inet proto tcp to any modulate state
pass out on fxp0 inet proto { udp, icmp } to any keep state

Es gibt viel zu tun...

Wie vorher, rfc.

TIA,
lars.
 
Was willst du denn mit einer Queue für blockierte Pakete?

Oder hast du mit dieser Regel beabsichtigt, die Pakete in dieser Queue etwa zu blockieren?

Das würde leider nicht so gehen.

# block all incoming packets but allow ssh, pass all outgoing tcp and udp
# connections and keep state, logging blocked packets.
block in log all queue std
Zum Vergrößern anklicken....

Das macht leider keinen Sinn, denn eine Queue ist z.B. für den Erhalt einer laufenden Verbindung gedacht und nicht für blockierte Pakete. Verbindungen werden erhalten und Pakete blockiert.

Das sind verschiedene Dinge.

Niemals wird ein Paketfilter eine Verbindung blockieren, wenn sie stattgefunden hat (es sei denn, du machst es mit pfctl oder in Verbindung z.B. mit Snort) und daher wird immer eine Verbindung eine Queue (wenn gewünscht) haben und niemals eine bestimmte Menge an blockierten Paketen. :)

Bei blockierten Paketen geht es darum, eine Verbindung erst gar nicht stattfinden zu lassen.

Daher ist deine Block-Regel mit Queue nicht passend.

Es reicht meistens ein einfaches und allgemeingültiges:

block in log on $DEINE_ETX_IF all

Schaue dir deshalb dieses mal an: http://www.openbsd.org/faq/pf/queueing.html

Und du kannst, wenn du magst, meine eigene FAQ zum Thema Paketfilter ansehen. Sie ist hier zu finden.

Zusätzlich zu deinen pass-Regeln für tcp-Protokoll würde ich noch die flags S/SA setzen. Dadurch lässt du nur bestimmte Pakete die Verbindung aufbauen.

Mehr dazu steht in den FAQs. ;)


Gruß

CW
 
Zuletzt bearbeitet:
Das macht leider keinen Sinn, denn eine Queue ist z.B. für den Erhalt einer laufenden Verbindung gedacht und nicht für blockierte Pakete. Verbindungen werden erhalten und Pakete blockiert.
Zum Vergrößern anklicken....
Ack. Das leuchtet mir schon ein.

Ich habe die man zu pf.conf angeschaut und dort habe ich das
Beispiel im Queueing-Abschnitt zum Vorbild genommen.
Da war ich voreilig, ich habe
http://www.openbsd.org/faq/pf/queueing.html
gar noch nicht angeschaut - my bad, die pf.conf lädt auch nicht, hehe.

Danke.

lars.
 
Um diesen, älteren, Thread schöner abzuschliessen,
poste ich hier mein finales pf.conf.

Dies habe ich auf meinem Notebook, funktioniert gut.

Queueing, wie oben versucht, hab ich mal weggelassen.

Code: 
# $OpenBSD: pf.conf,v 1.19 2003/03/24 01:47:28 ian Exp $
#
# See pf.conf(5) and /usr/share/pf for syntax and examples.
# Required order: options, normalization, queueing, translation, filtering.
# Macros and tables may be defined and used anywhere.
# Note that translation rules are first match while filter rules are last match.

# Macros: define common values, so they can be referenced and changed easily.
ext_if="fxp0" # replace with actual external interface name i.e., dc0

# Normalization: reassemble fragments and resolve or reduce traffic ambiguities.
scrub in all random-id
scrub out all random-id

# block all incoming packets but allow ssh, pass all outgoing tcp and udp
# connections and keep state, logging blocked packets.
block in log all

# pass in ssh
pass in quick on fxp0 inet proto tcp from any to fxp0 port 22 flags S/SA modulate state

# loopback: pass in/out all and keep state
pass in on lo0 inet proto { tcp, udp, icmp } from { lo0, fxp0 } keep state
pass out on lo0 inet proto { tcp, udp, icmp } to any keep state

# fxp0: pass out all and keep state
pass out on fxp0 inet proto tcp to any modulate state
pass out on fxp0 inet proto { udp, icmp } to any keep state

Vielleicht kann jemand was damit anfangen.
 
Original geschrieben von CW
Für das interne Loopback braucht man ja eh kein keep state ;)
Zum Vergrößern anklicken....
"keep state" ist (fast) immer gut/besser. Das processing der state table
kommt IMMER vor der evaluierung des ruleset und ist *deutlich*
schneller:
pass on lo0 keep state
Tipp des Tages ;-)
[/QUOTE]
Selbst die Jungs von OpenBSD geben es so vor: http://www.openbsd.org/faq/pf/filter.html#example
[/QUOTE]
Was eigentlich schwachfug ist, ich aender das mal mit offiziellem
Erscheinen von 3.4
 
Original geschrieben von lars
Vielleicht kann jemand was damit anfangen. [/B]
Zum Vergrößern anklicken....

Hmm, kein inet6?

Wenn doch, machst Du Dir mit den lo0 rules so keinen
unbedingten Gefallen.

Siehe auch anderes Posting. Die lo0 rules sind so unnoetig
"verbose" .. ausser da schwingt eine gewisse Paranoia wrt
chroot's mit rein, dafuer ist es dann aber auch wieder nicht
"dicht genug" ;-)
 
Nein, hab kein inet6.

lo0 hab ich wegen Spoofing-Gefahr so abgehandelt.

Aber diese Regel habe ich geschrieben anhand von
anekdotischen Infos, nicht, weil ich die, evtl. nicht bestehende,
Gefahr voll verstanden hätte und korrekt bannen könnte.

Aber es funzt.
 
Original geschrieben von double-p
"keep state" ist (fast) immer gut/besser. Das processing der state table
kommt IMMER vor der evaluierung des ruleset und ist *deutlich*
schneller:
pass on lo0 keep state
Tipp des Tages ;-)
Zum Vergrößern anklicken....

Thx!


Selbst die Jungs von OpenBSD geben es so vor: http://www.openbsd.org/faq/pf/filter.html#example

Was eigentlich schwachfug ist, ich aender das mal mit offiziellem
Erscheinen von 3.4
Zum Vergrößern anklicken....

Ab und zu mal sollte man doch "Helige Kühe" schlachten, nicht wahr ;)

Gruß

CW
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben