PF mit ftp-proxy funktioniert nicht

radiohead · 11 März 2008

Hi,

ich möchte nur Clients hinter meiner OpenBSD Firewall erlauben, FTP nach draußen zu machen. Sei es via Std FTP, aber auch über FTPS (SSL/TLS) und FTPS Implicit.

Ich habe alles so eingerichtet, wie es in der ftp-proxy manpage steht, aber es funktioniert nicht. Die Clients wollen immer eine weitere Connection via Highport öffnen, aber das soll ja nicht mehr nötig sein bei dem ftp-proxy.

Hier meine pf.conf:

Code:

ext_if="vr2"
int_if="vr0"
imac="10.0.100.1"
isp_dns="{ 213.178.66.111, 213.178.66.112 }"
lan="10.0.100.0/24"

set block-policy drop
set skip on {lo vr0}
scrub in all

nat on $ext_if from !($ext_if) -> ($ext_if:0)
nat-anchor "ftp-proxy/*"

rdr-anchor "ftp-proxy/*"
rdr pass on $int_if proto tcp from $lan to any port 21 -> 127.0.0.1 port 8021

block in all
block out log all

antispoof quick for { lo $int_if }

anchor "ftp-proxy/*"

pass out on $ext_if proto icmp
pass out proto tcp from any to any port 21
pass out on $ext_if proto { tcp, udp } from any to $isp_dns port domain keep state 
pass out on $ext_if proto tcp from any to any port { 25, 80, 143, 443, 465, 993, 5190, 5222, 5223 } keep state

Der FTP Proxy läuft auch:

Code:

proxy    17931  0.0  0.3   372   864 ??  Ss     9:08PM    0:00.02 ftp-proxy -t 300

Aber es funktionieren nicht einmal webbrowser Zugriffe auf ftp.openbsd.org. Dann kommt folgendes im tcpdump:

Code:

Mar 11 22:03:34.334769 rule 1/(match) block out on vr2: XXXX.63612 > 129.128.5.191.42555: [|tcp] (DF)
Mar 11 22:03:35.248853 rule 1/(match) block out on vr2: XXXX.50879 > 129.128.5.191.42555: [|tcp] (DF)
Mar 11 22:03:36.249337 rule 1/(match) block out on vr2: XXXX.59835 > 129.128.5.191.42555: [|tcp] (DF)
Mar 11 22:03:37.249847 rule 1/(match) block out on vr2: XXXX.64008 > 129.128.5.191.42555: [|tcp] (DF)
Mar 11 22:03:38.250454 rule 1/(match) block out on vr2: XXXX.59545 > 129.128.5.191.42555: [|tcp] (DF)

*Sheep · 12 März 2008

Deine Standardregel schlägt zu. Ich rate Dir auch das block in log all zu setzen...

*Sheep · 12 März 2008

In jedem Fall ist Deine FTP-Regel nicht ausreichend.

http://www.openbsd.org/faq/pf/de/ftp.html schrieb:
Um Verbindungen für aktives FTP zu ermöglichen, musst du die Option »-r« an ftp-proxy(8) übergeben (hierfür musstest du an den alten Proxy »-u root« benutzen).

http://board.protecus.de/t4580.htm schrieb:
Aktives FTP
Der Client startet eine Verbindungsanfrage, ausgehend von einem der loaklen Ports zwischen 1024-65535 zu dem Server-Port 21.
Für die Datenübertragung erfolgt nun eine Anfrage des Servers. er verwendet dazu den Port 20 und richtet sie an einen der Client-Ports im Bereich 1024-65535.

(Bei Paketfiltern, welche Stateful Paket Inspection (SIP) beherrschen, ist es nicht notwendig Ports auf IP-Adressen im LAN zu forwarden. SIP erkennt ftp-Verbindungen und leitet für die bestehende Verbindung die entsprechenden Ports weiter.)

Passives FTP
Der Client startet eine Verbindungsanfrage, ausgehend von einem der loaklen Ports zwischen 1024-65535 zu dem Server-Port 21.
Der Aufbau des Datenkanals erfolgt von einem der loaklen Ports zwischen 1024-65535 zu einem der Serverports zwischen 1024-65535.
Der Server baut keine (aktive) Verbindung zum Client auf.

radiohead · 12 März 2008

Und genau dieses forwarden soll man doch nicht mehr benötigen mit dem neuen ftp-proxy seit OpenBSD 3.8. Damit öffne ich mir ja ein großes Loch, welches ich intern weiterleite. Davon steht ja auch nichts in der Manpage...

radiohead · 12 März 2008

Was auch noch komisch ist, es scheinen nicht immer alle Regeln zu ziehen. Ich kann zwar mailen, das ist ja auch in meiner letzten Regel mit Port 25 abgedeckt, jedoch erscheint jetzt auch mal im tcpdump sowas:

Code:

Mar 12 09:25:47.018585 rule 0/(match) block in on vr0: 10.0.100.1.57436 > 213.178.66.102.25: [|tcp] (DF)
Mar 12 09:26:03.025963 rule 0/(match) block in on vr0: 10.0.100.1.57436 > 213.178.66.102.25: [|tcp] (DF)
Mar 12 09:26:35.040733 rule 0/(match) block in on vr0: 10.0.100.1.57436 > 213.178.66.102.25: [|tcp] (DF)

Wobei ich just in diesem Moment auch keine Mail an diesen Provider verschicke...

Das Regelwerk ist ein wenig angepasst worden. Es gibt dort jetzt ein:

pass in quick on $int_if

Steht das (DF) für default handling oder so?

radiohead · 12 März 2008

Hmm...

Auch ssh wird angeblich ge-dropped?

Code:

Mar 12 09:35:30.506543 rule 0/(match) block in on vr0: 10.0.100.1.57453 > 10.0.100.231.22: [|tcp] (DF) [tos 0x10]
Mar 12 09:35:31.306997 rule 0/(match) block in on vr0: 10.0.100.1.57449 > 10.0.100.231.22: [|tcp] (DF) [tos 0x10]
Mar 12 09:35:31.907492 rule 0/(match) block in on vr0: 10.0.100.1.57452 > 10.0.100.231.22: [|tcp] (DF) [tos 0x10]

Ich bin aber auf der Maschine drauf. Woher kommen solche Einträge? Jemand eine Idee.
Danke für eure Hilfe am frühen morgen!

Hier nochmal das gesamte neue Regelwerk:

Code:

ext_if="vr2"
int_if="vr0"

isp_dns="{ 213.178.66.111, 213.178.66.112 }"

imac="10.0.100.1"

set block-policy drop
set skip on lo 

scrub in 

nat on $ext_if from !($ext_if) -> ($ext_if)
nat-anchor "ftp-proxy/*"

rdr-anchor "ftp-proxy/*"
rdr on $int_if proto tcp from any to any port 21 -> 127.0.0.1 port 8021
rdr on $int_if proto tcp from any to any port 80 -> 127.0.0.1 port 3128

block in log 
block out log 

anchor "ftp-proxy/*"

antispoof quick for { lo $int_if }

pass in quick on $int_if

pass out on $ext_if proto icmp
pass out on $ext_if proto { tcp, udp } from any to $isp_dns port domain keep state 
pass out on $ext_if proto { tcp, udp } from any to any port ntp keep state 
pass out on $ext_if proto tcp from any to any port { 25, 80, 143, 443, 465, 993, 5190, 5222, 5223 }

PS: Das mit dem Squid redirect im transparent Modus klappt auch noch nicht, deshalb habe ich in die letzte Regel noch den Port 80 drin...

morph · 12 März 2008

SSH wird gedropped, weil du keine Regel drin hast, die es erlaubt.

DF = don't fragment bit: Die Ausgabe wird in der Regel dann erzeugt, wenn fragmentierte Pakete am pf ankommen bei denen das DF-bit gesetzt ist. Weil das eigentlich keinen Sinn macht, greift deine scrub-regel und filtert diese Pakete korrekt aus.

FTP...hier im Forum gabe es schon reichlich Diskussionen darum. Stöber einfach mal ein bissel. Vielleicht haben deine Clients kein passives FTP aktiviert :ugly:

radiohead · 12 März 2008

Aber das ssh ist doch eingehend am internen Interface...

Dafür gibt es doch die Regel:

Code:

pass in quick on $int_if

Aber da steht dann auch wieder (DF), also wird das scrub wieder ziehen...

Standard FTP funktioniert jetzt auch, ich hatte die Regel noch um Port 20 erweitert:

Code:

pass out on $ext_if proto tcp from ($ext_if) to any port { 20, 21 }

Allerdings leider kein FTP mit (SSL/TLS). Der Server läßt keine Verbindung zu, es wird auch nichts im tcpdump als dropped angezeigt...

mapet · 12 März 2008

radiohead schrieb:

Hmm...

Auch ssh wird angeblich ge-dropped?

Code:

Mar 12 09:35:30.506543 rule 0/(match) block in on vr0: 10.0.100.1.57453 > 10.0.100.231.22: [|tcp] (DF) [tos 0x10]
Mar 12 09:35:31.306997 rule 0/(match) block in on vr0: 10.0.100.1.57449 > 10.0.100.231.22: [|tcp] (DF) [tos 0x10]
Mar 12 09:35:31.907492 rule 0/(match) block in on vr0: 10.0.100.1.57452 > 10.0.100.231.22: [|tcp] (DF) [tos 0x10]

Ich bin aber auf der Maschine drauf. Woher kommen solche Einträge? Jemand eine Idee.
Danke für eure Hilfe am frühen morgen!

Hier nochmal das gesamte neue Regelwerk:

Code:

ext_if="vr2"
int_if="vr0"

isp_dns="{ 213.178.66.111, 213.178.66.112 }"

imac="10.0.100.1"

set block-policy drop
set skip on lo 

scrub in 

nat on $ext_if from !($ext_if) -> ($ext_if)
nat-anchor "ftp-proxy/*"

rdr-anchor "ftp-proxy/*"
rdr on $int_if proto tcp from any to any port 21 -> 127.0.0.1 port 8021
rdr on $int_if proto tcp from any to any port 80 -> 127.0.0.1 port 3128

block in log 
block out log 

anchor "ftp-proxy/*"

antispoof quick for { lo $int_if }

pass in quick on $int_if

pass out on $ext_if proto icmp
pass out on $ext_if proto { tcp, udp } from any to $isp_dns port domain keep state 
pass out on $ext_if proto { tcp, udp } from any to any port ntp keep state 
pass out on $ext_if proto tcp from any to any port { 25, 80, 143, 443, 465, 993, 5190, 5222, 5223 }

PS: Das mit dem Squid redirect im transparent Modus klappt auch noch nicht, deshalb habe ich in die letzte Regel noch den Port 80 drin...

das DF bedeutet, dass das paket fragmentiert wurde. "scrub in all no-df" lässt die pakete dann auch rein. ich hatte son problem auch mal, hat mich nen halben tag und ein paar hundert kilometer weg gekostet, das zu lernen

radiohead · 12 März 2008

Ja, das ist schon klar. Jedoch funktioniert ja nunmal der ssh Zugriff auf die OpenBSD Kiste. Anscheinend werden nur ab und an Pakete verworfen, aber das scheint den sshd nicht sonderlich zu stören.

Geht auf jedenfall. Jetzt funktioniert auch schön mein transparenter Squid, aber der kann im transparenten Modus ja leider kein https...

mapet · 12 März 2008

kanner nicht? wär mir neu, da ich das hier auch mal ne zeit lang in betrieb hatte.

no-df bewirkt folgendes: sobald DF-pakete gescrubbt werden sollen, werden sie verworfen/zurückgeschickt, damit sie nochmal gesendet werden. wenn der client das nun nicht macht, weil er davon nichts mitbekommt, gibts nen timeout. ssh ist da relativ unempfindlich gegen, aber es gibt anwendungen, die dann in das timeout laufen (RDP, lotus notes). das no-df verhindert eben und veranlasst das annehmen auch von diesen paketen (genaueres steht in der manpage)

PF mit ftp-proxy funktioniert nicht

radiohead

Well-Known Member

*Sheep

des Unterseepudels Kern

*Sheep

des Unterseepudels Kern

radiohead

Well-Known Member

radiohead

Well-Known Member

radiohead

Well-Known Member

morph

Well-Known Member

radiohead

Well-Known Member

mapet

Active OpenBSD User

radiohead

Well-Known Member

mapet

Active OpenBSD User

Wir schützen deine Privatsphäre