PacketFilter und TCP/SYN mit FIN Flag

M

MHoff

Member
Nachdem ich mich mit dem Aufsetzen einen FreeBSD Servers beschäftigt habe, interessiert mich nun PF.
Leider hab ich trotz lesens einiger Einstiegshilfen und Beispielskripten (wie aus dem WiKi des Forums hier) noch das ein oder andere Problem.

Ich habe meine Box grob mit Nessus getestet, nur bringt dieser die Warnung das TCP/SYN Pakete mit dem FIN Flag den Paketfilter umgehen können.

Nun habe ich in der rc.conf die Option tcp_drop_synfin="YES" gesetzt, scheint aber keine Wirkung zu haben (5.4-RELEASE).

Ich denke mit block Regeln in PF würde die entprechenden Pakete ausgefiltert werden, aber gibt es auch einen Weg um nur diese Pakete auszufiltern?
 
Zuletzt bearbeitet:
das schaut zwar ganz okay aus aber ...

da würd ich das mit "quick" sofort rausfeuern und eventuell schaded ein log dazu auch nicht

"block in log quick on .... "
 
quick sagt aus das das paket was auf die regel zutrifft sofort geblockt wird.
ansonsten würde das paket alle andere regelsätze noch durchlaufen bis zur letzten regel
 
PF
***********************
Laut FreeBSD-Handbuch Kapitel 24.4 ist die erste Anlaufstelle für Fragen zur PF:

http://www.openbsd.org/faq/pf/de/index.html
http://www.openbsd.org/faq/pf/index.html

Und dort steht unter:

http://www.openbsd.org/faq/pf/de/filter.html#tcpflags

schwarz auf weiss, wie man sich korrekt gegen FIN+SYN-Attacken schützt. Die einfache Wiki-PF-Beispielkonfiguration sollte demnach gegen FIN+SYN-Attacken schützen..


tcp_drop_synfin="YES"
**************************
Aus man rc.conf:
tcp_drop_synfin
(bool) Set to ``NO'' by default. Setting to ``YES'' will
cause the kernel to ignore TCP frames that have both the SYN
and FIN flags set. This prevents OS fingerprinting, but may
break some legitimate applications. This option is only
available if the kernel was built with the TCP_DROP_SYNFIN
option.
Zum Vergrößern anklicken....
 
Zuletzt bearbeitet:
ist so eine spezialbehandlung einzelner faelle nicht redundant und sollte besser generisch mit dem paketfilter erschlagen werden? zumal man da ja dann noch die option hat, zu loggen oder testweise fuer bestimmte netze auszuklammern und und und..
 
In erster Linie sollte man als Admin wissen was man erschlägt. Ob dies dann mit dem TCP Stack des OS oder dam PaketFilter geschieht is doch quasi egal, oder?

(irgend n wildes SecAdvisory aussen vor)
 
Elessar schrieb:
In erster Linie sollte man als Admin wissen was man erschlägt. Ob dies dann mit dem TCP Stack des OS oder dam PaketFilter geschieht is doch quasi egal, oder?
Zum Vergrößern anklicken....

na, mir sind generische flexible loesungen lieber als spezielle hacks fuer spezifische faelle. dass man in beiden faellen wissen sollte, was man da tut, versteht sich irgendwie von selbst.
 
Also ich weiss nicht ob ich einfach dumm bin, oder Nessus spinnt.
Egal ob die Option im Kernel setze oder mittels pf, es erscheint immer wieder diese Fehlermeldung, bzw. das Securityleck.

Ich denke nicht das ich was falsch gemacht habe, vor allem da ich zum Teil nach Tutorials gegangen bin, und ansonsten funktionieren alle Filterregeln.


:confused:
 
Schau dir den Netzwerkverkehr z.B. mit tcpdump an. Ist der einzig verlässliche Weg herauszufinden, was nessusd macht, was für eine Reaktion es darauf gibt und was für einen Report Nessus daraufhin erstellt.
 
Darum habe ich mich bisher immer gedrückt mich tiefer mit dem Netzwerkverkehr zu beschäftigen (sollte man als Systemadministrator doch besser kennen als sich selbst, oder? :D )

Werde ich das mal an in Agriff nehmen (müssen).

Vielen Dank für eure Hilfe, das Board, und die User, sind wirklich super und haben mir bisher sehr geholfen.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben