Firewall / Rootserver sichern

[int25]

Moin, moin,

nachdem wir darangegangen sind, verschiedene Serverdienste mit SSL-Connects zu sichern, stellt sich die Frage, wie denn der Server selbst zu sichern ist.

Welchen Ersatz gibt es fuer den Einsatz zb. von IP-Tables & Co, die an den Kernel gebunden sind und deshalb auf einem Rootserver nicht einzusetzen sind ?

Welche Vorgehensweise gibt es, mit der ich Sicherheitsluecken des Systems aufspuere, ohne dass ich mir nun jedes einzelne Stueck Software anschauen muss, das auf dem Server laeuft ?
Und wie kann ich ggf. Luecken (offene Ports usw.) abdichten ?

Gibt es moeglicherweise ein Rootserver-Sicherheits-FAQ, das die moeglichen Angriffspunkte und Massnahmen auflistet, anstatt das ich mir 78698 einzelne Postings und Dokus zu Gemuete fuehren oder 25 Semester Informatik studieren muss, um die noetigen Infos zu haben ?

(habe bereits den FAQ von Lutz Donnerhacke zur Kenntnis genommen, der aber zum speziellen Thema Rootserver wenig hilfreich ist)





PS:.Bitte an Diejenigen, die gelangweilt diese Fragen zum 123. Mal zur Kenntnis nehmen, ihre Langeweile nicht dafür zu nutzen, hier zusätzlichen Traffic zu verursachen, ausser durch zielführende Antworten).

[t0x1c]

tag,

Welchen Ersatz gibt es fuer den Einsatz zb. von IP-Tables & Co, die an den Kernel gebunden sind und deshalb auf einem Rootserver nicht einzusetzen sind ?

Ach so, eine root-Server Distribution hat also keinen Kernel? ;)

Welche Vorgehensweise gibt es, mit der ich Sicherheitsluecken des Systems aufspuere, ohne dass ich mir nun jedes einzelne Stueck Software anschauen muss, das auf dem Server laeuft ?
Und wie kann ich ggf. Luecken (offene Ports usw.) abdichten ?

Falsche Einstellung..
Man soll nich "gucken was läuft und das dann beenden" sondern "gucken was man braucht un dass dann starten weil von hause aus nix läuft" - ich weiß aber nicht wie SuSE das handhabt. ;)

und "lücken (offene Ports)" sind auch nichts anderes als Prozesse, die auf einem Port lauschen. Startest du diesen Prozess nicht, lauscht auch nix auf dem Port. Genaugenommen ist jeder offener Port ein Sicherheitsrisiko, denn keine Software ist perfekt und hat dementsprechend nicht wenige Sicherheitslücken. Du kannst aber Mailinglisten (bugtraq etc.) lesen, um eine gefundene Sicherheitslücke in einem Prozess zu "stopfen".

Gibt es moeglicherweise ein Rootserver-Sicherheits-FAQ, das die moeglichen Angriffspunkte und Massnahmen auflistet, anstatt das ich mir 78698 einzelne Postings und Dokus zu Gemuete fuehren oder 25 Semester Informatik studieren muss, um die noetigen Infos zu haben ?

Da gibts nen Tool.. Nennt sich brain ;)

Ne mal im Ernst, die Naivheit einiger Admins ist die größte aller zu behebenden Schwachstellen. Sie kommen in ein Forum in dem sich (teilweise sehr erfahrene Admins) darüber unterhalten wie man Sicherheitslücke #345335 Stopfen könnte, und erwarten eine komplette Anleitung zum absichern des Servers.

[flo]

...
ich weiß aber nicht wie SuSE das handhabt. ;)

anders ... glaub mir ;-)

flo.

[int25]

Ach so, eine root-Server Distribution hat also keinen Kernel?

m.W. (und nach Auskunft meines ISPs) habe ich keinen Zugriff auf den Kernel und die Firewallregeln, so das die Nutzung von IP-Tables entfällt.


Im Ã?brigen: was spräche dagegen, dass es eine Liste / eine Ã?bersicht gibt über standardmäßige Dienste / Server und ihre einschlägigen Sicherheitsprobleme ?
zB: Apache, ssh, FTPd, ircd und dergleichen ? wird ja nicht jeder hunderte von Schwachstellen haben.
Wenn ich stattdessen Google dazu befrage, werde ich mit 100000 Postings zugeschüttet, die entweder nicht aktuell oder alle redundant sind, also eine Infomüllquote von über 99%.
Und vielleicht kommen wir doch noch einmal im Informationszeitalter an ?!

[t0x1c]

tag,

m.W. (und nach Auskunft meines ISPs) habe ich keinen Zugriff auf den Kernel und die Firewallregeln, so das die Nutzung von IP-Tables entfällt.

Hättest Du geschrieben was für eine Art von Server (Managed?) Du verwendest ließe sich eine Lösung eventuell leichter finden. ;)
Du könntest deinen Provider z.B. ganz lieP darum bitten, das er iptables in den Kernel kompiliert/als ladbares Modul bereitstellt, denn um die Filterregeln zu definieren brauchst Du keinen Zugang zum Kernel.

Im Ã?brigen: was spräche dagegen, dass es eine Liste / eine Ã?bersicht gibt über standardmäßige Dienste / Server und ihre einschlägigen Sicherheitsprobleme ?
zB: Apache, ssh, FTPd, ircd und dergleichen ? wird ja nicht jeder hunderte von Schwachstellen haben.

http://www.cert.org/advisories/ bzw. http://cert.uni-stuttgart.de/os/gnu/

Wenn ich stattdessen Google dazu befrage, werde ich mit 100000 Postings zugeschüttet, die entweder nicht aktuell oder alle redundant sind, also eine Infomüllquote von über 99%.
Und vielleicht kommen wir doch noch einmal im Informationszeitalter an ?!

Du denkst viel zu global.. Schonmal die Suchfunktion hier im Forum ausprobiert? ;)

[int25]

Du könntest deinen Provider z.B. ganz lieP darum bitten, das er iptables in den Kernel kompiliert/als ladbares Modul bereitstellt, denn um die Filterregeln zu definieren brauchst Du keinen Zugang zum Kernel.

Handelt sich um einen geshareten Root-Server auf dem alle m.W. mit demselben Kernel unterwegs sind und ist ein debian.
Wenn ich mit dem iptables-Modul meine eigenen Firewallregeln einsetzen kann, könnte das weiterhelfen.

Inwieweit sind ansonsten Tools wie nessus u.dergl. zum Testen der Serversicherheit / zum Scannen geeignet ?
Welche brauchbaren Instrumente kann ich hier einsetzen ?

[t0x1c]

tag,

Welche brauchbaren Instrumente kann ich hier einsetzen ?

Es gibt zwar Tools wie nessus, chrootkit etc. die Dir etwas Arbeit abnehmen, das wichtigste ist aber Regelmäßig die Log-Files zu lesen. Das System aktuell halten. Jede kleine unnormale Traffic-Schwankung kritisch zu hinterfragen.

Benutze am besten mal die Boardsuche, da findest du haufenweise Beispiele.

[captaincrunch]

habe bereits den FAQ von Lutz Donnerhacke zur Kenntnis genommen, der aber zum speziellen Thema Rootserver wenig hilfreich ist

Wie kommst du zu diesem Schluss? Nur, weil er "Rootserver" nicht explizit erwähnt, heißt das noch lange nicht, dass die FAQ nicht auch für diese gelten.

[int25]

Moin, moin,

habe bereits den FAQ von Lutz Donnerhacke zur Kenntnis genommen, der aber zum speziellen Thema Rootserver wenig hilfreich ist

Wie kommst du zu diesem Schluss? Nur, weil er "Rootserver" nicht explizit erwähnt, heißt das noch lange nicht, dass die FAQ nicht auch für diese gelten.

Ich wollte damit nichts gegen den FAQ oder gegen Lutz Donnerhacke gesagt haben, und nehme meine Einschätzung zum Teil wieder zurueck:
ich hatte diese bezogen auf vroot-server, die insoweit gehandicapt sind, als sie sich Firewallregeln und Kernel teilen muessen und nicht individuell anpassen koennen.
Auch seine Hinweise zu Windows, Personal Firewalls u.dergl. haben mit diesem Thema ja wenig zu tun.

Das Problem scheint m.E., dass die Sicherheitsprobleme dieser vrootserver noch ein zu frisches Thema sind zu dem bisher zu wenig Erfahrung besteht.. Hinzu kommet womöglich, dass man sich damit "zwischen den Stühlen" wiederfindet:

die einen, die Admins "echter" Rootserver haben für diese Variante nur einen mitleidigen Blick, weil den Nutzern wesentliche Adminzugriffe (eben auf Kernel und Firewall) vorenthalten bleiben und sie das Ganze vermutlich als "Spielkram" betrachten.

die anderen, die sich auf ein "managed Webhosting" beschraenken, halten sich die Probleme eines vrootservers so vom Leib.

Trotzdem ist / bleibt ein vhosting m.E. eine interessante Alternative zu "echten" Rootservern, die sich nur für entsprechende kommerzielle Projekte lohnen, die die Betriebskosten abwerfen, und dem "Sandkasten" des konventionellen Webhostings, wo man sich alle naselang an den vom ISP gesetzten Grenzen stoesst, der den Daumen auf vielen Optionen hat, die einen Server erst interessant machen.

Bleibt zu hoffen, dass für die zunehmende Zahl der vroothost-Nutzer auch passende Lösungen für die einschlägigen Sicherheitsprobleme entwickelt werden, in Anbetracht der Situation, dass iptables hier versagt.

[oxygen]

Was genau hat iptables mit Sicherheit zu tun? Wenn dich hier durch gewühlt hättest, wüsstest du das iptables der falsche Ansatz ist. Aber nochmal kurz: iptables hat nur eine Daseinsberechtigung, und zwar auf einem Router. Weder auf einem Client noch einem Server macht es Sinn. Außer vielleicht zur Traffic Erfassung. Aber Schutz erreicht man mit iptables nicht.

[captaincrunch]

Auch seine Hinweise zu Windows, Personal Firewalls u.dergl. haben mit diesem Thema ja wenig zu tun.

Doch, denn genau eine solche "Personal Firewall" möchtest du auf deiner Kiste aufziehen, wobei es gar keine Rolle spielt, ob das ein v-, root- oder managed-Server ist.

[Joe User]

...
ich weiß aber nicht wie SuSE das handhabt. ;)

anders ... glaub mir ;-)

Was ist an einem laufendem SSHd auszusetzen?