Nur Frage: Warum weniger offene Dateien und ...?

Hallo Leute !

Ich habe vor ein paar Tagen meine Linuxfirewall gegen OpenBSD 3.5 ausgetauscht.
Nach einem Problem, welches auf die Anleitung nach der ich vorgegangen war zurückzuführen ist, bin ich nun ziemlich begeistert.Ich fühlte mich direkt heimisch!

Der Speed ist toll und die Wiedereinwahl klappt jetzt auch sehr zuverlässig.
Ich kann die Benchmarkergebnisse von Fefe nicht nachvollziehen, nachdem OpenBSD in vielen Dingen lahm sein soll.Mir erscheint OpenBSD sehr performant (Ftp von Linux auf vsftpd auf dem OpenBSD im Lan 10,3 MB mit billigen Realteks und gleichzeitigem Overnet mit max. 500 Verbindungen ...)

Wäre toll, wenn mir jemand zwei Fragen beantworten könnte, wobei Nummer 1 viel wichtiger ist:

1.Bei meinem Firewallskript unter Linux mit Kernel 2.6.x und den Iptables meldeten mir Portscanner von Webseiten, daß meine Firewall bis auf einen Port 'stealth' ist, d.h. die angefragten Ports wie nicht sichtbar erscheinen.Bei OpenBSD zeigt mir die Seite bei jedem Port 'blocked' an.Kennt jemand ein gutes HowTo zu Pf, damit ich die Ports auch 'stealth' bekomme ?

2.Eigentlich nur interessehalber (bin sogar froh drüber):
Seit ich die OpenBSD Firewall laufen habe, hat sich die Anzahl der offenen Dateien auf dem Linuxrechner beim Filesharing (Emule/Overnet) stark verringert.Mit der Linuxfirewall mußte ich die Anzahl der erlaubten offenen Files von 1024 auf 4096 erhöhen, weils oft mehr als 2500 wurden.Mit der OpenBSD Firewall rennt es und ich habe auf dem Clientrechner (Linux) nur noch etwas über 100 offene Dateien beim Filesharing auf.Mich wundert es, daß der Wechsel der Firewall so einen Einfluß auf die Workstation hat.Vielleicht kennt sich jemand so gut aus, daß er eine Antwort hat.


Nach diesem HowTo bin ich vorgegangen:
http://www.fmi.uni-passau.de/~grafj/openbsd/3.5/
(So habe ich auch fast 1:1 meine pf.conf)


Danke für eure Mühe,
Heiko
:)
 
WAAARGH
Fefe hat keinen Benchmark gemacht, sondern lediglich die Skalierbarkeit einiger syscalls gemessen. Daraus laesst sich daraus nur im degenerierten Fall ein Rueckschluss auf die Real-World-Performanz ziehen...

1. Du _willst_ "blocked" Ports haben. Die "stealth" Ports sind ein Unding und da koennte ich den Admin fuer teeren und federn. Ein "stealth"-Port ist der _beste_ Hinweis darauf, dass ueberhaupt ein Paketfilter laeuft!

Falls das alles Bahnhof ist, dann lese dich bitte mal in IP ein, vor allem TCP-Handshakes und was passiert, wenn der Socket nicht antwortet bzw. mit RST antwortet.

2. ??
Evtl. sind die idle-Timeouts fuer NAT-Verbindungen bei pf niedriger als bei netfilter?
 
MrFixit schrieb:
1. Du _willst_ "blocked" Ports haben. Die "stealth" Ports sind ein Unding und da koennte ich den Admin fuer teeren und federn. Ein "stealth"-Port ist der _beste_ Hinweis darauf, dass ueberhaupt ein Paketfilter laeuft!

Falls das alles Bahnhof ist, dann lese dich bitte mal in IP ein, vor allem TCP-Handshakes und was passiert, wenn der Socket nicht antwortet bzw. mit RST antwortet.

Hmmm.Ist es nicht eindeutiger, wenn ein Angreifer ein ACK zurückbekommt, statt sein Paket ins Nirvana laufen zu lassen ? Bremst es nicht zusätzlich seinen Scan aus ?
Kann ja sein, daß ich falsch liege.War nur bis jetzt der festen Überzeugung, daß 'verstecken' statt 'blocken' besser sei.

MrFixit schrieb:
2. ??
Evtl. sind die idle-Timeouts fuer NAT-Verbindungen bei pf niedriger als bei netfilter?

Das kann sein.Gute Idee.Da war doch mal was, daß unter Linux (im Default) Connections 1/2 oder sogar 1 Stunde gehalten wird.Wenns unter OpenBSD schneller geschlossen wird, würde es das erklären.

Ich werde mal die Werte von sysctl vergleichen.Vielleicht sind die Kernelbezeichnungen für TCP/IP Settings unter OpenBSD und Linux gleich oder ähnlich.


Vielen Dank für Deinen Tip !
:)
Heiko
 
DerRotePirat schrieb:
Hmmm.Ist es nicht eindeutiger, wenn ein Angreifer ein ACK zurückbekommt, statt sein Paket ins Nirvana laufen zu lassen ? Bremst es nicht zusätzlich seinen Scan aus ?
Es ist einfach nur nervig, da auch legitime Anfragen bis zum Timeout warten muessen.
Kann ja sein, daß ich falsch liege.War nur bis jetzt der festen Überzeugung, daß 'verstecken' statt 'blocken' besser sei.
Wie gesagt, das "stealth" verraet ueberdeutlich, dass da ein Paketfilter am Werk ist. Das koennte einen Angreifer aufmerksam machen.

Und ausserdem: Verstecken spielt man im Kindergarten. Die "Sicherheit" eines Netzes kannst du dadurch nicht verbessern (im Gegenteil!)
 
eigentlich ist es wurst, weil ob das ding jetzt einen drop, stealth, sneaky, ninja oder return macht, man erkennt ja trozdem die fw. wirklich stealth waere sie ja nur wenns eine fw im bridge mode waere afaik (uh ah ich sollte den krempel nochmal auffrischen *vergesslich*).
 
kith schrieb:
eigentlich ist es wurst, weil ob das ding jetzt einen drop, stealth, sneaky, ninja oder return macht, man erkennt ja trozdem die fw. wirklich stealth waere sie ja nur wenns eine fw im bridge mode waere afaik (uh ah ich sollte den krempel nochmal auffrischen *vergesslich*).
Also ohne Ip routen zwischen Internet und intern.
Mal sehen. Ich lasse es erst mal laufen und beobachte was sich so tut.
 
MrFixit schrieb:
Und ausserdem: Verstecken spielt man im Kindergarten. Die "Sicherheit" eines Netzes kannst du dadurch nicht verbessern (im Gegenteil!)
Da hast Du auch wieder Recht. :)
Ich sollte mit dem "Secure by default" (ist doch der Spruch unter OpenBSD) etwas
relaxter sein.Sicherer als die Linuxfirewall (vorher) dürfte es bestimmt sein.
 
Kann ja sein, daß ich falsch liege.War nur bis jetzt der festen Überzeugung, daß 'verstecken' statt 'blocken' besser sei.

Vielleicht ist der Beitrag aus de.comp.security.firewall FAQ was für dich:

,----[ http://www.iks-jena.de/mitarb/lutz/usenet/Firewall.html ]
|
| Ist REJECT oder DENY sinnvoller?
|
| Als REJECT bezeichnet man die aktive
| Ablehnung einer Verbindungsanfrage mit einem ICMP Paket vom Inhalt "Der Admin
| hat's verboten" oder "Dienst nicht verfügbar".
|
| Als DENY bezeichnet man das kommentarlose Wegwerfen der Verbindungsanfrage.
| Damit läuft der Anfragende in einen Timeout.
|
| Admins, die sich über Script Kiddies ärgern, glauben oft, diese durch DENY
| aufhalten zu können. Dies ist jedoch falsch. Es ist problemlos möglich, viele
| tausend Scans gleichzeitig zu starten und so auf alle Timeout gleichzeitig zu
| warten. Ein Scanner wird so nicht gebremst. Andererseits bremst man mit DENY
| alle legitimen Nutzer und Server massiv aus. Das betrifft insbesondere die
| ident Anfragen.
|
| Ident dient dazu, dem Admin eines ordentlich gepflegten Systems eine
| Hilfestellung bei der Identifizierung seiner, sich daneben benehmenden Nutzer
| zu geben. DENY für ident bewirkt nur, daß diese Hilfestellungen bei anderen
| Servern nicht mehr aufgezeichnet werden. Wenn Du als Schutzpatron für Spammer
| und Scriptkiddies auftreten willst, nimm DENY.
|
| Sieh das Ganze doch so, wie in einer offenen Beziehung: Es ist besser
| seinem Partner direkt zu sagen, daß man über ein bestimmtes Thema nicht
| sprechen möchte (REJECT): Der Partner weiß sofort, was Sache ist und und kann
| dann ohne Zeitverzögerung seine Entscheidung darüber treffen, ob er die
| Beziehung fortsetzen möchte oder nicht.
|
| Geht man auf ein Thema allerdings gar nicht ein (DENY) und stellt die Ohren
| auf Durchzug, kostet das a) einem selber Zeit dem Geschwafel des Partners
| zuzuhören und b) dem Partner ebenfalls Zeit; er möchte nämlich ein für ihn
| wichtiges Thema/Problem loswerden, und hätte das dann ja wohl besser woanders
| getan.
|
| Ein anderes Beispiel aus dem Leben: Du gehst durch die Einkaufstraße deiner
| Stadt, und irgendein "Penner" quatscht dich an, und will 'nen Euro. Hier könnte
| man sagen "Ach ne, habe selbst kein Geld" (REJECT) oder einfach die
| fortgesetzte Bettelei ertragen.
`----
 
unlink schrieb:
Vielleicht ist der Beitrag aus de.comp.security.firewall FAQ was für dich:

,----[ http://www.iks-jena.de/mitarb/lutz/usenet/Firewall.html ]
|
| Ist REJECT oder DENY sinnvoller?
|
| Als REJECT bezeichnet man die aktive
| Ablehnung einer Verbindungsanfrage mit einem ICMP Paket vom Inhalt "Der Admin
| hat's verboten" oder "Dienst nicht verfügbar".
|
|........
|.....
|..
`----

Danke für den guten Link und die Erklärungen.Über deinen Link habe ich auch einen weiteren sehr guten zum Abfragen von Abkürzugen gefunden:
http://www.chemie.de/tools/acronym.php3
Ist auch für sämtliche Computerabkürzungen (nicht nur Chemie).

Ihr liegt wohl richtig.Ich verwerfe den Wunsch mit dem 'stealth'.Gut möglich, daß durch das unsaubere Handling der FW die Probleme mit einigen wenigen Servern auftraten.
Ein Beispiel war 'Tecchannel'.Ein Kollege (mit Windows) wollte die Seite bei mir aufrufen und da der Seitenaufbau ca. 47 Sekunden dauerte, sagte dieser sofort es läge am Browser.

Tecchannel war mit einigen anderen Seiten, die Probleme unter Linux machen
auf meiner Liste, die ich nach dem Wechsel sofort ausprobiert habe.
Jetzt mit der OpenBSD FW öffnet sich Tecchannel in 2-3 Sekunden !
Ich muß ihm das jetzt nochmal zeigen. Hehe.
 
Zurück
Oben