pf: Return trotz folgender pass-Regel

[Reks30]

Hallo,

ich habe ein Problem an meinem OpenBSD-Router auf welches ich zufällig durch einen Test mit tcpdump stieß:

tcpdump hat mir gezeigt, das auf einem internen Interface auf dem ich auch von Innen filtere die Firewall auch dann ICMP Port unreachable Pakete sendet, wenn danach eigentlich eine pass-Regel die Verbindung erlaubt. Das sieht so aus das ich auf diesem Interface erst als Defaultregel folgendes verwende:

block return in log on $ifdmz all

Danach kommt aber z. B. folgende Regel:

pass in on $ifdmz proto udp from any port 68 to any port 67

Der Router arbeitet für dieses Netz auch als DHCP-Server, daher sollen DHCP-Pakete immer durchgelassen werden. Was nun wirklich passiert ist laut tcpdump: Wenn ein DHCP-Request eingeht wird dieses wie gewünscht durchgelassen. Nun wird zuerst ein ICMP Port unreachable Paket zurückgesendet und dann danach die eigentliche Antwort vom DHCP-Server. Bei anderen erlaubten Netzwerkverkehr wie etwa HTTP passiert dies nicht. Könnte das daran liegen das DHCP Broadcasts verwendet? Wie kann ich das abstellen ohne generell Returns abzustellen (auf internen Interfaces finde ich eine Antwort der Firewall bei nichterlauben besser als ein verwerfen des Pakets ohne Antwort).

Gruß
Reks30

 

[MrFixit]

Hmm, sicher, dass DHCP/BOOTP-Anfragen von port 68 kommen?

Was meldet pflog0 denn _genau_? Also tcpdump -ni pflog0 -ttts0

 

[Reks30]

Hmm, sicher, dass DHCP/BOOTP-Anfragen von port 68 kommen?

Ja, das steht ja bei tcpdump auch so drin, steht außerdem auch in der /etc/services.

Was meldet pflog0 denn _genau_? Also tcpdump -ni pflog0 -ttts0

Da ich die Pakete aufgezeichnet habe (übrigens nicht auf pflog0, sondern direkt am Interface um wirklich alle und nicht nur die geloggten mitzubekommen) wandle ich den Befehl mal ab in:

tcpdump -ttt -nr wiipkts

Das dabei relevante Ergebnis:

Dec 28 16:37:17.015777 192.168.3.101.68 > 192.168.3.1.67: xid:0xabc6e832 C:192.168.3.101 vend-rfc1048 DHCP:REQUEST CID:1.0.25.253.77.143.225 HN:"Wii" PR:SM+DG+NS+DN+BR+SR
Dec 28 16:37:17.015973 192.168.3.1 > 192.168.3.101: icmp: 192.168.3.1 udp port 67 unreachable
Dec 28 16:37:17.018257 192.168.3.1.67 > 192.168.3.101.68: xid:0xabc6e832 C:192.168.3.101 Y:192.168.3.101 S:192.168.3.1 vend-rfc1048 DHCP:ACK SID:192.168.3.1 LT:43200 SM:255.255.255.0 DG:192.168.3.1 NS:192.168.3.1,192.168.0.20 DN:"maroufi" [tos 0x10]

Gruß
Reks30

 

[oenone]

Da ich die Pakete aufgezeichnet habe (übrigens nicht auf pflog0, sondern direkt am Interface um wirklich alle und nicht nur die geloggten mitzubekommen) wandle ich den Befehl mal ab in:

pflog0 zeigt dir zusätzlich an, warum es geblockt wurde...

 

[Reks30]

pflog0 zeigt dir zusätzlich an, warum es geblockt wurde...

OK, dann probier ich es nochmal auf pflog0, das dauert dann allerdings etwas. Melde mich dann nochmal.

Gruß
Reks30

 

[Reks30]

An pflog0 zeigt sich gar nichts, da werden die DHCP-Pakete gar nicht geloggt. Insofern dürfte eigentlich nicht die block Regel ausschlaggebend für die ICMP Port unreachable Pakete sein, da diese ja eine "log" Anweisung enthält, nur was denn dann?

Oder anders gefragt: Warum sendet der Rechner eine derartige (falsche) icmp-Nachricht, wo der Port doch erreichbar ist und antwortet unmittelbar darauf dann ja auch noch korrekt mit einer DHCP-Antwort?

Gruß
Reks30

 

[metro]

icmp type 3 = icmp unreachable
icmp (sub/message) code 3 = port unreachable

icmp unreachable heißt nicht nur *ist nicht erreichbar'.
icmp type 3 wird auch dazu benutzt fragmentierungen unter Routern oder Maschinen
auszuhandeln.
wahrscheinlich sendet deine Maschine ein icmp type 3 (icmp-unreachable)/ message code 4 (don't fragment) um die grössstmöglichre MTU zu erkennen.
Danach sendet der Router korrekterweise seine Antwort.

Hilfreich: man icmp

 

[Reks30]

wahrscheinlich sendet deine Maschine ein icmp type 3 (icmp-unreachable)/ message code 4 (don't fragment) um die grössstmöglichre MTU zu erkennen.

Nein es ist definitiv ein Port unreachable also type 3 code 3, das zeigt ja auch der oben gezeigte Ausschnitt von tcpdump:

Dec 28 16:37:17.015973 192.168.3.1 > 192.168.3.101: icmp: 192.168.3.1 udp port 67 unreachable

Hier heißt es eindeutig udp Port 67 unreachable. Übrigens mich wundert auch warum netstat den Port 67 UDP nicht als lauschend zeigt, obwohl der DHCP korrekt arbeitet.

Gruß
Reks30

 

[metro]

Erst lesen, dann schreiben.
Ich weiß nicht, wieweit sich obsd und fbsd(bei mir) bootpd unterscheiden, dürfte aber unerheblich sein.
man bootpd(8) sagt,
Aber pf hat wohl mit dem unreachable nichts zu tun, glaube ich.

mode of operation is referred to as "inetd mode" and causes bootpd
     (or bootpgw) to be started only when a boot request arrives.

das könnte erklären, warun da nix auf udp 67 lauscht.
Theoretisch könnte das schon dafür genügen, das der network-stack ein unreachable schickt.
Das Zweite ist der eigentliche Request:

...(schnipp)  ... CID:1.0.25.253.77.143.225 HN:"Wii" PR:[B]SM+DG+NS+DN+BR+SR[/B]
der mit 
DHCP:ACK SID:192.168.3.1 LT:43200 SM:255.255.255.0 DG:192.168.3.1 NS:192.168.3.1,192.168.0.20 DN:"maroufi" [tos 0x10]

beantwortet wird.
da fehlen BR+SR
Nun werden nicht nur geschlossene Poerts sondern auch nicht vorhandene Services auf einem ansonsten offenen Udp Port mit port unreachable beantwortet.
Auch ne Möglichkeit.

Desgleichen ist es möglich, daß gar kein bootpd läuft (und 'nur' ein dhcpd),
dann kann u.U auch der fehlende Service auf dem offenen Port ein port unreachable generieren.
Ist aber mehr oder weniger geraten

Gruss

Metro

 

[Reks30]

Ich weiß nicht, wieweit sich obsd und fbsd(bei mir) bootpd unterscheiden, dürfte aber unerheblich sein.

Nö, offensichtlich gibt es da einen großen Unterschied, denn ich habe so etwas wie bootpd nicht. Es gibt kein man bootpd (man: no entry for bootpd in the manual.) und es gibt auch kein Binary bootpd. Ich verwende denn dhcpd der bei OpenBSD dabei ist. In OpenBSD ist der ISC-DHCPD Bestandteil des Basissystems.

Das Zweite ist der eigentliche Request:

...(schnipp)  ... CID:1.0.25.253.77.143.225 HN:"Wii" PR:[B]SM+DG+NS+DN+BR+SR[/B]
der mit 
DHCP:ACK SID:192.168.3.1 LT:43200 SM:255.255.255.0 DG:192.168.3.1 NS:192.168.3.1,192.168.0.20 DN:"maroufi" [tos 0x10]

beantwortet wird.
da fehlen BR+SR
Nun werden nicht nur geschlossene Poerts sondern auch nicht vorhandene Services auf einem ansonsten offenen Udp Port mit port unreachable beantwortet.

Was sind denn BR und SR?

Desgleichen ist es möglich, daß gar kein bootpd läuft (und 'nur' ein dhcpd),

Ist ja auch der Fall (siehe oben), nur das eben der dhcpd auf udp Port 67 lauscht (oder lauschen sollte) und von dorther auch Antworten schickt, nur eben nicht in netstat auftaucht.

Gruß
Reks30

 

[metro]

>Was sind denn BR und SR?

tcpdunp übersetzt 'broadcast' zu BR und 'static route' zu SR

Gruß
Metro

 

[Reks30]

>Was sind denn BR und SR?

tcpdunp übersetzt 'broadcast' zu BR und 'static route' zu SR

Na dann ist das ja OK: eine statische Route gibt es nicht und Broadcastadresse habe ich in meiner dhcpd.conf nicht angegeben, aber die errechnet sich jeder Client anhand von zugewiesener IP und Netzwerkmaske ja ohnehin.

Gruß
Reks30