Firewall

[tinitus]

Macht es Sinn einen Rootserver nochmals mit einer Firewall gegen evtl. Probleme abzusichern?

z.B. ich weiß genau ich brauche nur ssh http u. https

Habe zwar schon viel für und wider gelesen..aber wie macht Ihr es?

G. Roland

[duergner]

IMHO macht es keinen Sinn. Firewall (Packetfilter) sind dazu da, verschiedene Netze vorneinander zu trennen und nicht einzelne Rechner. Aber wenn du eh schon viel gelesen hast, dann kennst du ja die ganzen Gründe. Also wieso frägst du dann noch? Ob du das machen willst oder nicht, musst du eh für dich selber entscheiden.

[Joe User]

http://faq.1und1.de/server/root_server/security/2.html

[tinitus]

wegen des >>eigentlich<<

frage ich....

Wollte nur wissen, ob neben der Schutzfunktion noch andere negative Effekte auftreten können?

G. Roland

[tinitus]

http://faq.1und1.de/server/root_server/security/2.html

@ Joe diesen Text kenne ich...

Ich suche Informationen jenseits der Lehrmeinung.

So eine Firewall könnte doch vor potentiellen Fehlern in Programmen (Serverdiensten) schützen?


G. Roland

[floschi]

Hm, wurde das hier bereits 1000 oder schon 2000 Mal diskutiert... -> Boardsuche, bitte.

[tally]

Meine Meinung: ich fahre keinen einzigen Rechner ohne Firewall/Paketfilter, weil richtig konfiguriert haben sie keinerlei Nachteile und können auf jeden Fall die Sicherheit erhöhen. Selbst auf meinen Workstations (egal ob MSWin oder Linux) hinter der dedizierten Firewall richte ich einen Paketfilter/Firewall ein.

Was mir in diesem Zusammenhang auch auf diesem Board nicht gefällt, ist die zum Teil missionarisch propagierte Meinung der Einsatz eines Paketfilters sei schlecht, falsch, überflüssig o.ä. Das soll doch jeder Handhaben wie er will.

tally

[dodolin]

So eine Firewall könnte doch vor potentiellen Fehlern in Programmen (Serverdiensten) schützen?

Nein. Wie sollte das denn bitteschön gehen?
Wenn ein Serverdienst läuft, muss der Port im Paketfilter ja eh freigegeben sein, also schützt da auch nix zusätzlich. Wenn der Dienst erreichbar ist, kann ein Exploit etc. voll zuschlagen, davor schützt auch kein Paketfilter.

Es KANN sehr spezielle und seltene Umstände geben, unter denen ein Paketfilter auf einem Rootserver Sinn manchen kann, aber dein obiges Szenario gehört mit Sicherheit nicht dazu, wie ich aufgezeigt habe.

Ein Paketfilter bringt IMHO genau dann etwas, wenn man ein konkretes Bedrohungsszenario hat, welches der Paketfilter _zuverlässig_ verhindern kann. (Das ist quasi auch die Lehrmeinung aus de.comp.security.firewall.)

[Joe User]

weil richtig konfiguriert

Was mir in diesem Zusammenhang auch auf diesem Board nicht gefällt, ist die zum Teil missionarisch propagierte Meinung der Einsatz eines Paketfilters sei schlecht, falsch, überflüssig o.ä.

Hmm, sehe nur ich einen Widerspruch?
Wer einen Paketfilter richtig konfigurieren kann, fragt hier nicht nach Hilfe zur Konfiguration...

[tally]

So eine Firewall könnte doch vor potentiellen Fehlern in Programmen (Serverdiensten) schützen?

Nein. Wie sollte das denn bitteschön gehen?
Wenn ein Serverdienst läuft, muss der Port im Paketfilter ja eh freigegeben sein, also schützt da auch nix zusätzlich. Wenn der Dienst erreichbar ist, kann ein Exploit etc. voll zuschlagen, davor schützt auch kein Paketfilter.
[...]

Das sehe ich aber anders. Z.B. ist eine meiner ersten Regeln folgende:

Code: Select all

$IPTABLES -A INPUT -i $DEV_INET -m state --state INVALID -j DROP

Böswillig modifizierte Pakete sollen gleich weggeschmissen werden. Wieso sollte ich testen lassen, ob der Kernel bzw. der Dienst damit zurecht kommt oder gleich im Nirvana landet?

Hmm, sehe nur ich einen Widerspruch?
Wer einen Paketfilter richtig konfigurieren kann, fragt hier nicht nach Hilfe zur Konfiguration...

Du hast die Ursprungsfrage scheinbar nicht richtig gelesen. Es wurde ja nicht nach der Konfiguration gefragt, sondern ganz allgemein ob Firewall ja/nein.

tally

[dodolin]

Böswillig modifizierte Pakete sollen gleich weggeschmissen werden. Wieso sollte ich testen lassen, ob der Kernel bzw. der Dienst damit zurecht kommt oder gleich im Nirvana landet?

Wenn ein Dienst damit ein Problem hat, dann ist er wohl auch allgemein so schlampig programmiert, dass man ihn nicht guten Gewissens an ein öffentliches Netz lassen kann.

Iptables _ist_ der Kernel, wenn der damit ein Problem hat, dann kann er das mit oder ohne iptables haben.

[tally]

Böswillig modifizierte Pakete sollen gleich weggeschmissen werden. Wieso sollte ich testen lassen, ob der Kernel bzw. der Dienst damit zurecht kommt oder gleich im Nirvana landet?

Wenn ein Dienst damit ein Problem hat, dann ist er wohl auch allgemein so schlampig programmiert, dass man ihn nicht guten Gewissens an ein öffentliches Netz lassen kann.

Interessante Einstellung. Und wie prüfst Du das vor dem produktiven Einsatz nach? Oder verläßt Du Dich auf bugtraq und wartest sozusagen bis es zu spät ist?

Iptables _ist_ der Kernel, wenn der damit ein Problem hat, dann kann er das mit oder ohne iptables haben.

Das ist schon klar. Aber ist Dir auch klar, wie so ein Paket vom Netfilter/Kernel verarbeitet wird?

tally

[dodolin]

Und wie prüfst Du das vor dem produktiven Einsatz nach?

Ich prüfe sämtliche Zeilen Sourcecode eigenhändig durch!

Aber ist Dir auch klar, wie so ein Paket vom Netfilter/Kernel verarbeitet wird?

Du wirst es uns sicher gleich erklären. Und verrate mir auch gleich noch, was das jetzt mit meiner Aussage zu tun hat, auf die du dich beziehst.

[tally]

Und wie prüfst Du das vor dem produktiven Einsatz nach?

Ich prüfe sämtliche Zeilen Sourcecode eigenhändig durch!

Aber ist Dir auch klar, wie so ein Paket vom Netfilter/Kernel verarbeitet wird?

Du wirst es uns sicher gleich erklären. Und verrate mir auch gleich noch, was das jetzt mit meiner Aussage zu tun hat, auf die du dich beziehst.

ROFL

Na, du scheinst diese Diskussion wohl nicht besonders ernst zu nehmen. Und zu deiner Frage: vereinfacht formuliert dringt ein Paket, das vom Netfilter gedroppt wird, nicht so weit in den Kernel vor, wie andere Pakete. Für Scherzbolde gibt es keine ausführlichere Erklärung von mir, wäre ja bloß Zeitverschwendung.

tally

[captaincrunch]

OK, vielleicht erklärst du's mir ja einfach mal. Bin nämlich kein Scherzbold, sondern einfach "nur" doof:

Und zu deiner Frage: vereinfacht formuliert dringt ein Paket, das vom Netfilter gedroppt wird, nicht so weit in den Kernel vor, wie andere Pakete.

Wenn der Kernel das Paket schon intus hat, ist er erst einmal relativ egal, ob er durch iptables "geschützt" ist oder nicht. Angenommen hat er es schließlich bereits, und verarbeitet es so oder so, egal, ob die Netfilter-Hooks durchlaufen werden oder nicht. Ist der Teil, der das Paket in dem Moment bearbeitet buggy, nutzen dir die Netfilter-Hooks also IMHO herzlich wenig.

Whatever: wenn ich da wirklich einfach zu blöd zu bin, lasse ich mich gerne eines Besseren belehren. ;)

[Joe User]

Hmm, sehe nur ich einen Widerspruch?
Wer einen Paketfilter richtig konfigurieren kann, fragt hier nicht nach Hilfe zur Konfiguration...

Du hast die Ursprungsfrage scheinbar nicht richtig gelesen. Es wurde ja nicht nach der Konfiguration gefragt, sondern ganz allgemein ob Firewall ja/nein.

Wenn man weiss, wie man einen Paketfilter richtig konfiguriert, dann weiss man auch, ob man einen Paketfilter einsetzen kann/will und muss diesbezüglich nicht erst (hier) nachfragen.

/me EOD, da Sinnlos...

[tally]

/me EOD, da Sinnlos...

Vollkommen richtig. Dem schließe ich mich zu 100% an.

tally

[captaincrunch]

Ach...dabei hatte ich doch ziemlich darauf gewartet, endlich durch Weisheit erhellt zu werden...

Jetzt mal ernsthaft: ich hatte eine ernstgemeinte Frage zur Diskussion gestellt. Wenn du darauf nicht antworten willst, bitteschön. Find ich nur nicht wirklich die "feine englische".

[duergner]

CC ich denk da reicht einfach dein Wissen nicht aus, um das zu fassen, was er dir sagen will. Ich bin leider auch schon ganz ganz lange ausgestiegen. :?

[captaincrunch]

CC ich denk da reicht einfach dein Wissen nicht aus

OK, das ist ja nichts neues, und damit könnte ich auch eigentlich noch ganz gut leben.

um das zu fassen, was er dir sagen will.

Genau daher hatte ich versucht nachzuhaken. Ich bin bisher immer noch der Meinung, dass der kernel Pakete mit oder ohne Netfilter-Hooks verarbeitet, aber vielleicht hat er sich ja schon mal genauer durch die Sourcen gewühlt, und kann mir sagen, dass ich mit meiner Aussage falsch liege.
Natürlich hat er insofern recht, dass mit Hilfe der Netfilter-Hooks ein paket nicht erst den gesamten hierfür nötigen Code des Kernels durchlaufen muss, aber so, wie die Aussage dort steht finde ich sie einfach ganz extrem schwammig.

[fump]

vereinfacht formuliert dringt ein Paket, das vom Netfilter gedroppt wird, nicht so weit in den Kernel vor, wie andere Pakete.

Das ist ja schön, nur was, wenn Netfilter bei lustigen Paketen ins Gras beißt und dein System mit Kernel Panic meditieren geht?

http://cve.mitre.org/cgi-bin/cvename.cg ... -2004-0816
http://cve.mitre.org/cgi-bin/cvename.cg ... -2004-0626

Du holst dir damit einen weiteren Dienst ins System den du pflegen mußt, und einen potentiellen Angriffspunkt darstellt. Wenn du das in kauf nehmen willst und dafür ein sinnvolle Anwendung siehst, dann mach es. :-)

Für Scherzbolde gibt es keine ausführlichere Erklärung von mir, wäre ja bloß Zeitverschwendung.

Schade.

#fump

[captaincrunch]

Das ist ja schön, nur was, wenn Netfilter bei lustigen Paketen ins Gras beißt und dein System mit Kernel Panic meditieren geht?

Danke. Genau das meinte ich auch...hatte leider nur keine Zeit, mir die passenden Geschichten rauszusuchen. ;)

[rootmaster]

vereinfacht formuliert dringt ein Paket, das vom Netfilter gedroppt wird, nicht so weit in den Kernel vor, wie andere Pakete.

Das ist ja schön, nur was, wenn Netfilter bei lustigen Paketen ins Gras beißt und dein System mit Kernel Panic meditieren geht?

http://cve.mitre.org/cgi-bin/cvename.cg ... -2004-0816
http://cve.mitre.org/cgi-bin/cvename.cg ... -2004-0626

Du holst dir damit einen weiteren Dienst ins System den du pflegen mußt, und einen potentiellen Angriffspunkt darstellt. Wenn du das in kauf nehmen willst und dafür ein sinnvolle Anwendung siehst, dann mach es. :-)

na und ?? das gilt für jeden code im kernel 8)

der netfilter ist eben _kein_ dienst, sondern hooks im kernel-space (wie CC richtig bemerkt hat):
den prerouting-hook für hereinkommende pakete findet man übrigens im softirq-kontext in ip_rcv(), den localin-hook in ip_local_deliver() [file: net/ipv4/ip_input.c]
natürlich kann der netfilter-code anfällig sein, aber andererseits durchlaufen gedroppte-pakete keinesfalls den ganzen kernelspace wie im falle ohne netfilter der fall sein kann.
(btw. weil das schön öfter mal an anderer stelle gefragt wurde: promisuous mode des interfaces ändert nichts daran, dass die pakete den netfilter-code durchlaufen)
rp_filter wirken übrigens schon vor den netfilter-hooks ;)

ein paketfilter ist eben erst mal ein paketfilter und keine firewall. wenn man damit etwas filtern (~schützen) will, dann kann man das an zentraler stelle tun, bevor der userspace (~dienste) erreicht wird. ob das allerdings ausreicht, um bogus code in den diensten zu schützen, kann nicht generell gesagt werden.
aber sicherheit ist ein generelles konzept, das hört weder hinter den kernelmechanismen noch vor den applikationen und diensten auf ;)

Und wie prüfst Du das vor dem produktiven Einsatz nach?

Ich prüfe sämtliche Zeilen Sourcecode eigenhändig durch!

das war jetzt aber ein scherz, oder ?? ;)

"back to the roots"

[dodolin]

das war jetzt aber ein scherz, oder ??

Es war der vorausgehenden Frage angepasst. ;)

[captaincrunch]

...und wieder mal einen ganz herzlichen Dank an rootmaster, der mich zum Glück nicht ganz doof sterben lässt. ;)