komisches PF verhalten bei sftp

P

plepps

Active Member
Hallo,

habe diese Anfrage schonmal auf der OpenBSD Mailingliste gepostet, aber keine Antwort bekommen. Vielleicht liest ja hier jemand mit, der eine idee dazu hat:

Habe eine OpenBSD 4.6 Firewall, welche eine sftp verbindung von A nach B erlauben soll

SRC IP: 10.100.106.58
DST IP: xxx.xxx.126.244
DST Port: 7400/tcp


Das pflog dazu:
Code: 
Mar 16 20:36:39.570280 rule 201/(match) pass in on em0: 10.100.106.58.35286 > xxx.xxx.126.244.7400: S 3090744159:3090744159(0) win 5840 <mss 1460,sackOK,timestamp 4134057806[|tcp]> (DF) 
Mar 16 20:36:39.570292 rule 201/(match) pass out on em4:10.100.106.58.35286 > xxx.xxx.126.244.7400: S 3090744159:3090744159(0) win 5840 <mss 1460,sackOK,timestamp 4134057806[|tcp]> (DF) 
Mar 16 20:37:14.677912 rule 244/(match) block in on em0:10.100.106.58.35286 > xxx.xxx.126.244.7400: P 3090746972:3090747004(32) ack 3225125621 win 224 <nop,nop,timestamp 4134092914 1713395> (DF) [tos 0x8] 
Mar 16 20:37:14.916504 rule 244/(match) block in on em0:10.100.106.58.35286 > xxx.xxx.126.244.7400: P 0:32(32) ack 1 win 224 <nop,nop,timestamp 4134093152 1713395> (DF) [tos 0x8] 
Mar 16 20:37:15.392461 rule 244/(match) block in on em0:10.100.106.58.35286 > xxx.xxx.126.244.7400: P 0:32(32) ack 1 win 224 <nop,nop,timestamp 4134093628 1713395> (DF) [tos 0x8]
komisch ist, das die ersten Packete durchkommen, dann wird geblockt - verstehe ich nicht....

hier mal die rules dazu:
Code: 
@201 pass log quick inet proto tcp from <tbl.r76.s:3> to <tbl.r41.d:4> port = 7400 flags S/SA keep state label "RULE 76 -- ACCEPT "
  [ Evaluations: 13948     Packets: 390       Bytes: 300416      States:0     ]
  [ Inserted: uid 0 pid 4296 State Creations: 12    ]

@244 block return-icmp(port-unr) log quick inet all label "deny_rest"
  [ Evaluations: 28108654  Packets: 28108654  Bytes: 15763202122 States: 0     ]
  [ Inserted: uid 0 pid 4296 State Creations: 0     ]


table <tbl.r41.d> { xxx.xxx.126.246 , xxx.xxx.126.244 , xxx.xxx.105.194 , xxx.xxx.126.245 }
table <tbl.r76.s> { 10.100.102.30 , 10.100.106.58 , 10.100.107.58 }

hat jemand eine Idee dazu?

cheers,
tom
 
die ganze pf.conf kann ich nicht posten, aber ich bastel am wochenende mal eine, wo nur die regeln für die verbindung drinn sind und teste es mit der und poste die dann ggf. hier.

thx
tom
 
mark05 schrieb:
hi
geht es um ssh sftp oder um ssl ftp ?
holger
Zum Vergrößern anklicken....

sftp und auch nur sftp macht ärger, es gehen auch noch ssl ftp sachen über die kiste wie auch ssh, damit gibts keinen stress.

komisch ist, das die sftp verbindung manchmal garnicht geht, im falle wie hier geschildert, klappt der connect, auch ein ls ging noch, dann war schluss und pflog schrieb das "block".

ich verstehs einfach nicht ... :(

tom
 
Probier’ mal, die Reihenfolge der beiden Regeln zu ändern oder das »quick« aus der zweiten Regel rauszumachen. Bei pf wird die letzte passende Regel angewendet; es ist gut möglich, daß »keep state« nicht funktioniert, wenn danach noch eine block-Regel mit »quick«-Keyword kommt.
 
waki87 schrieb:
Probier’ mal, die Reihenfolge der beiden Regeln zu ändern oder das »quick« aus der zweiten Regel rauszumachen. Bei pf wird die letzte passende Regel angewendet; es ist gut möglich, daß »keep state« nicht funktioniert, wenn danach noch eine block-Regel mit »quick«-Keyword kommt.
Zum Vergrößern anklicken....

aber warum ausgerechnet nur bei der einen?
da sind kanpp 150 änliche davor und keine macht stress?

tom
 
Da müßte ich jetzt ins Blaue hinein schießen, da ich die anderen Regeln natürlich nicht kenne. Ich würde im Allgemeinen aber auch erst »block«- und dann »pass«-Regeln reinschreiben und mir das »quick« dann jeweils sparen.
 
Warum erzeugst du die States nicht Interfacegebunden?

So wie es aussieht erzeugst du für eine Connection 4 States. 2 auf em0 und 2 auf em4.

Die Reihenfolge deines Regelwerks finde ich auch ein wenig merkwürdig. So schreibt man das vielleicht bei Cisco oder Checkpoint, weil die beiden first-match Firewalls sind. PF ist aber last-match...da solltest du vielleicht mal ganz grundsätzlich drüber nachdenken.
 
morph schrieb:
Warum erzeugst du die States nicht Interfacegebunden?

So wie es aussieht erzeugst du für eine Connection 4 States. 2 auf em0 und 2 auf em4.

Die Reihenfolge deines Regelwerks finde ich auch ein wenig merkwürdig. So schreibt man das vielleicht bei Cisco oder Checkpoint, weil die beiden first-match Firewalls sind. PF ist aber last-match...da solltest du vielleicht mal ganz grundsätzlich drüber nachdenken.
Zum Vergrößern anklicken....

die Regeln erzeugt der fwbuilder - bitte jetzt kein flamewar, was den nutzen dieses tools angeht, es ist einfach übersichtlicher und bislang laufen alle meine kisten seid 3 jahren damit tadelos.

nach etwas suchen hab ich jetzt noch rausgefunden, das das mit dem openbsd 4.6 und dessen pf zu tun haben muss, nehme ich 4.4 geht das alles wunderbar.

werd am sonntag mal weiter testen und berichten.

tom
 
so, ich habe mal reichlich getestet. Es liegt definitiv am pf, oder meiner config.
Mit abgeschalteten pf, klappt die sftp verbindung.

Auch spielt es keine Rolle, ob ich nun am anfang alles blocke und auf das quick verzichte, oder wie es der fwbuilder macht "in-order-stop-when-match" nutze.
Die kiste lässt ein paar pakete durch, dann blockt sie.

Code: 
set loginterface em0
set optimization aggressive

block in log all
block out log all
block in inet6 all

pass on em1 proto pfsync
pass on { em0, em2, em3, em4, em5 } proto carp keep state

table <tbl.r2.d> { xxx.xxx.126.246 , xxx.xxx.126.244 , xxx.xxx.105.194 , xxx.xxx.126.245 }
table <tbl.r2.s> { 10.100.102.30 , 10.100.106.58 , 10.100.107.58 }

pass  log  on lo0 inet  from any  to any keep state  label "RULE 0 -- ACCEPT "
.............
pass  log  inet proto tcp  from <tbl.r2.s>  to <tbl.r2.d> port 7400 label "RULE 2 -- ACCEPT "
.............
............
............
block return-rst  inet proto tcp  from any  to any port 113  label "RULE 106 -- REJECT "

ich versteh es einfach nicht. :(

cheers,
tom
 
Hast du schon einmal versucht das set optimization aggressive herauszunehmen?
Das könnte eine Ursache sein. Das führt manchmal zu ganz doofen Problem. Ich nutze es deshalb nicht!

Er beendet zu früh die Verbindung, schließt den Port, wird entsprechend geblockt ...

(ist das mit dem Loopback gewollt?!)
 
k_e_x schrieb:
Hast du schon einmal versucht das set optimization aggressive herauszunehmen?
Das könnte eine Ursache sein. Das führt manchmal zu ganz doofen Problem. Ich nutze es deshalb nicht!

Er beendet zu früh die Verbindung, schließt den Port, wird entsprechend geblockt ...

(ist das mit dem Loopback gewollt?!)
Zum Vergrößern anklicken....

ok - das ist nen versuch wert - ich teste es mal.

und was meinst du wegens des loopback - ist vom fw builder so erzeugt, ok, könnte auch ein "set skip on lo" nehmen.

danke,
tom
 
hi

kern aenderung bei pf zwischen 4.4 und 4.6 sind geringfuegig ( oberflaechlich gesehen ) unter der haube um so mehr.

scrub muss angepasst werden da da sich der syntax veraendert hat
ansonsten kann man die regeln 1:1 uebernehmen von 4.4 auf 4.6

wer fwbuilder nutzt ist selber schuld ...... das ding haengt immer eine bis
2 versionen hinter der aktuellen pf version hinterher und selbst dann
kann es immer noch nicht alles.

holger
 
mark05 schrieb:
wer fwbuilder nutzt ist selber schuld ...... das ding haengt immer eine bis
2 versionen hinter der aktuellen pf version hinterher und selbst dann
kann es immer noch nicht alles.
holger
Zum Vergrößern anklicken....

keine frage, da magst du ja auch recht haben - nur hat mein problem nix mit dem fwbuilder zu tun - selbst wenn ich eine pf conforme conf von hand erstelle, klappt die verbindung nicht, insofern ist das ding aussen vor.

tom
 
k_e_x schrieb:
Ich nehme an, dass das Problem geloest ist?
Zum Vergrößern anklicken....

hi,

leider noch nicht - nur muss ich wieder bis samstag warten, um weiter zu forschen. Aber da ist was im argen.
hab mitlerweile festgestellt, das es nicht nur seltsamkeiten mit der einen sftp verbindung gibt, auch der zugriff aus der dmz auf den internen mailserver klappt nicht so richtig.
macht man nen telnet auf dessen port 25 geht der mal erfolgreich durch, oder aber hängt - beides mal kommt im pflog, das die pass regel greift und gehen tuts dennoch nicht.
unterm strich werd ich am we jetzt mal nen OS downgrade machen und es mal damit versuchen - vor der umstellung auf 4.6 lief ja eigentlich alles.

ich werde auf jeden fall berichten.

tom
 
Ich würde hier immer noch auf einen scrub Fehler tippen. Ich verwende PF zwar nur unter FreeBSD, aber scrub vergessen hat bei mir immer zu Paketverlusten geführt.
 
Kamikaze schrieb:
Ich würde hier immer noch auf einen scrub Fehler tippen. Ich verwende PF zwar nur unter FreeBSD, aber scrub vergessen hat bei mir immer zu Paketverlusten geführt.
Zum Vergrößern anklicken....

also früher hatte ich immer das hier drinn:
Code: 
scrub in all
scrub out all random-id

aber bei der 4.6 meckert er das an, deswegen hab ichs im moment so drinnen:
Code: 
match in all scrub (random-id reassemble tcp)

tom
 
so - es mailt wieder - schuld war reproduzierbar die "reassemble tcp" option.

bleibt noch das sftp - mehr dazu nach dem Wochenende.

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