TCP Ungereimheiten

[FierceOne]

Hallo Forum!

Ich habe mich gerade ein wenig tiefgehender mich IPFW beschäftigt. Eben habe ich auch selber ne (stateful) Firewall startklar gemacht, die auch soweit tut was sie soll. Das einzige was ich nicht verstehe sind ein paar Pakete die am Ende in die deny Regel laufen.

Erstmal das Setup:

################ Start of IPFW rules file ###############################
# Flush out the list before we begin.
ipfw -q -f flush

# Set rules command prefix
cmd="ipfw -q add"
pif="fxp0"     # public interface name of NIC
              # facing the public Internet

#################################################################
# No restrictions on Loopback Interface
#################################################################
$cmd 00010 allow all from any to any via lo0

#################################################################
# Allow the packet through if it has previous been added to the
# the "dynamic" rules table by a allow keep-state statement.
#################################################################
$cmd 00015 check-state

#################################################################
# Interface facing Public Internet (Outbound Section)
# Interrogate session start requests originating from behind the
# firewall on the private network or from this gateway server
# destine for the public Internet.
#################################################################

$cmd 00100 allow tcp from any to any out via $pif setup keep-state
$cmd 00150 allow udp from any to any out via $pif keep-state

#################################################################
# Interface facing Public Internet (Inbound Section)
# Interrogate packets originating from the public Internet
# destine for this gateway server or the private network.
#################################################################

# Allow ICMP
$cmd 00205 allow icmp from any to me in via $pif

# Deny ident
$cmd 00215 deny tcp from any to any 113 in via $pif

# Deny all Netbios service. 137=name, 138=datagram, 139=session
# Netbios is MS/Windows sharing services.
# Block MS/Windows hosts2 name server requests 81
$cmd 00220 deny tcp from any to any 137 in via $pif
$cmd 00221 deny tcp from any to any 138 in via $pif
$cmd 00222 deny tcp from any to any 139 in via $pif
$cmd 00223 deny tcp from any to any 81 in via $pif

# Deny any late arriving packets
$cmd 00230 deny all from any to any frag in via $pif

# Deny ACK packets that did not match the dynamic rule table
$cmd 00235 deny tcp from any to any established in via $pif

# DHCP answer
$cmd 00280 allow udp from any 67 to any in via $pif keep-state

# Allow in secure FTP, Telnet, and SCP from public Internet
$cmd 00300 allow tcp from any to me 22 in via $pif setup keep-state
$cmd 00310 allow tcp from any to me 80 in via $pif setup keep-state
#$cmd 00315 allow tcp from any to me 443 in via $pif setup keep-state

# Tor
$cmd 00400 allow tcp from any to me 9001 in via $pif setup keep-state
$cmd 00410 allow tcp from any to me 9030 in via $pif setup keep-state
# Everything else is denied by default
# deny and log all packets that fell through to see what they are
$cmd 00999 deny log all from any to any

Wie man sieht ist es meine erste. Die Vorlage habe ich ausm Handbuch geholt.

Hmm ja und wenn ich das am Laufen habe, bekomme ich alle paar Sekunden Meldungen in der Art

kernel: ipfw: 999 Deny TCP meine.ip.addr:randomport irgend.eine.ip:9001 out via fxp0

Offentsichtlich ist das Tor Traffic. bzw. ein kleiner Teil dessen, der Großteil läuft sauber über den Rechner.

Was mich dabei völlig verwundert ist das Traffic der nach draussen geht. Aber Regeln 100 & 150 lassen doch alles raus?! Kann sich da jemand einen Reim drauf machen? Warum kommt es nur so extrem selten vor? Und wie kann es nach draussen gehende Pakete geben, die bei 999 hängen bleiben?!

Bis jetzt habe ich mir folgendes überlegt. SYN Pakete können es nicht sein, sonst hätte doch Regel 100 gegriffen. Wenn es Pakete einer offenen Verbindung wären, hätte eine dynamische Regel treffen müssen, also in 15. Wenn es herrenlose ACK Pakete sollten sie in 235 stecken bleiben. Daher kann müssen es Pakete einer anderen Art sein?!?!? Aber warum kommen die dann nicht jedes Mal vor??

Fragen über Fragen! Danke das ihr bis hierher gelesen habt!

Gruß!!!

 

[metro]

Hallo und guten Morgen,


was da durch Tor geroutet wird und in ipfw hängenbleibt, wirst Du wahrscheinlich erst
mittels eines packetsniffers herausbekommen können.
Die normalen ipfw Regeln sind eher gedacht für den Betrieb eines Client-Rechners
ohne die Besonderheiten eines Servers, oder, wie mit Tor, eines Routers in Betracht zu ziehen.

Tor routet halt (und das soll er ja auch), was da so kommt.

>Aber Regeln 100 & 150 lassen doch alles raus?!

>00100 allow tcp from any to any out via $pif setup keep-state

ipfw hält die Verbindung für eine bestimmte Zeit in seinem state-table. Falls aus irgendwelchen
Gründen ein Packet zu spät kommt, wird es nicht mehr erkannt.

Die Regel
>00150 allow udp from any to any out via $pif keep-state
ist für tor unrelevant, da Tor kein udp kann. (wieweit udp und keep-state mit ipfw überhaupt geht, weiß ich nicht)

Die Regel
> 00235 deny tcp from any to any established in via $pif
bezieht sich auf eingehenden Traffic.

Ich denke allerdings, das ein Grossteil deiner hängengebliebenen Packete ECN-packets sind.

gehe zu
https://ssl.scroogle.org/

suche nach 'ECN packets'.

Du kannst die Regeln entsprechend anpassen, vielleicht mit auf den user, unter dem Tor läuft, bezogenen Regeln.
Wenn es aber deiner Meinung nach problemlos läuft, lass es doch so wie es ist.

Es gibt hier übrigens einen Tor Thread, in den das denke ich, mehr gehört.


Aber auf jeden Fall gibt es keinen Grund zur Panik

Gruss Metro

 

[FierceOne]

Hallo!

Tausend Dank! Ich hatte bei 235 ganz übersehen bzw. vergessen das die Regel nur nach drinnen gilt. Wenn ich das Pendant nach draussen hinzufüge klappt es. Du hast natürlich Recht. Das sind Pakete deren dynamische Regel ausgelaufen ist. Ich habe hier einfach den Standardwert von 300 Sekunden gelassen. Naja egal, geht auf jeden Fall prima jetzt...

Über ECN habe ich versucht zu lesen, muß aber sagen das mir das dann doch ein wenig weit geht. Das verstehe ich so einfach wohl nicht mehr. Naja muß ja auch nicht....

Schöne Weihnachten!