RootForum Community

hallo, mitlerweile habe ich gesehen, dass es grsecurity.net gibt, um seinen Server sicher zu halten, aber ich hätte da ein paar Fragen an die Personen, die das damit schon machen:

- Patcht man damit alle bekannten Sicherheitslücken in verschiedenen Programmen, oder nur den Kernel?
- Was mache ich da mit meinem rootserver L von puretec, da habe ich ja nicht die Kernel-Sourcen oder zumindest kennte ich die Konfiguration nicht (.config), um die Kernel-Sourcen zu patchen und um danach einen, für mein System, lauffähigen Kernel zu kompilieren?
- Habe gelesen, dass ein Patch auch durchaus schwierigkeiten machen kann.
- Wisst Ihr, ob puretec immer einen neuen, sicheren Kernel zur Verfügung stellen, oder ist das noch immer der gleiche?

Wie geht Ihr denn so vor, auch speziell auf den Rootserver-L bezogen, um eure Maschinen sicher zu halten?

Ich habe ehrlich gesagt angst, am laufenden System rumzuschrauben, aber andererseits sind mir Sicherheitslücken auch unangenehm.

Gibt es irgendwo eine Liste, welche Programme man unbedingt updaten sollte?

Wäre für eure Tips und Erfahrungswerte recht dankbar.

Patcht man damit alle bekannten Sicherheitslücken in verschiedenen Programmen, oder nur den Kernel?

Letzteres. Aber damit kann man manche Sicherheitslücken in verschiedenen Programmen vermeiden.

Was mache ich da mit meinem rootserver L von puretec, da habe ich ja nicht die Kernel-Sourcen oder zumindest kennte ich die Konfiguration nicht (.config), um die Kernel-Sourcen zu patchen und um danach einen, für mein System, lauffähigen Kernel zu kompilieren?

Warum sollte es die Sourcen nicht geben? Schonmal auf dem Update-Server nachgeschaut? Ich persönlich habe keinen Rootserver, denke aber, dass es den Kernelsource schon irgendwo geben wird...

Habe gelesen, dass ein Patch auch durchaus schwierigkeiten machen kann.

Klar.

Wisst Ihr, ob puretec immer einen neuen, sicheren Kernel zur Verfügung stellen, oder ist das noch immer der gleiche?

Keine Ahnung. Kommt drauf an: Wenn das der Standard SuSE Kernel ist, dann wird es sooft Updates geben, wie SuSE welche bereitstellt. Wenn es ein von 1&1 noch zusätzlich gepatchter Kernel ist, bist du auf 1&1 angewiesen. Keine Ahnung, wie die das handhaben. Das würde ich an deiner Stelle mal den Support fragen.

Wie geht Ihr denn so vor, auch speziell auf den Rootserver-L bezogen, um eure Maschinen sicher zu halten?

Keine Dienste starten, die nicht benötigt werden. Die benötigten Dienste entsprechend absichern und sämtliche Pakete zeitnah updaten, sobald etwas bekannt wird. Hierzu kann es nützlich sein, gängige Security-Listen zu abonnieren. Ich persönlich denke, dass grsecurity nicht unbedingt nötig ist und würde das daher nicht verwenden.

Gibt es irgendwo eine Liste, welche Programme man unbedingt updaten sollte?

Alle, für die es Updates gibt.

OK, dann will ich doch auch mal meinen Senf dazu abgeben :

Patcht man damit alle bekannten Sicherheitslücken in verschiedenen Programmen, oder nur den Kernel?

Du patcht damit ausschließlich den Kernel. Die richtigen Optionen vorausgesetzt, hilft der GRSecurity aber, dass bei entdeckten Sicherheitslücken, die z.B. darauf basieren, dass der Stack für einen Exploit ausgenutzt wird dieses fehlschlagen, sofern du das Teil korrekt konfiguriert hast.

Was mache ich da mit meinem rootserver L von puretec, da habe ich ja nicht die Kernel-Sourcen oder zumindest kennte ich die Konfiguration nicht (.config), um die Kernel-Sourcen zu patchen und um danach einen, für mein System, lauffähigen Kernel zu kompilieren?

Wie dodolin schon sagte, liegen die Kernel-Sourcen auf update.pureserver.info. Alternativ kannst du mal hier schauen : http://www.rootforum.org/faq/index.php? ... =010&id=81
Wenn du doch selbst kompilieren willst, helfen dir ein paar Threads aus "Linux und spezielle Distris" weiter, da habe ich z.B. einmal mit Treo darüber diskutiert ...

Habe gelesen, dass ein Patch auch durchaus schwierigkeiten machen kann.

Kennst du den Spruch mit dem Duschvorhang (KANN schimmeln, muss aber nicht) ? Natürlich KANN ein Patch Schwierigkeiten machen, beim GRSecurity kann ich dir aber sagen, dass ich 4 Kisten damit seit Wochen und Monaten problemlos laufen habe.

Wisst Ihr, ob puretec immer einen neuen, sicheren Kernel zur Verfügung stellen, oder ist das noch immer der gleiche?

Puretec ist IMHO auf die Updates von SuSE angewiesen, d.h. wenn (wie letzlich noch) eine Sicherheitslücke im Kernel bekannt wird, wird Puretec den von SuSE gepatchten Update-Kernel rausbringen.
Dieser verschafft dir aber immer noch nicht die Sicherheit, die dir der GRSecurity geben würde.

Wie geht Ihr denn so vor, auch speziell auf den Rootserver-L bezogen, um eure Maschinen sicher zu halten?

Wie schon von dodolin gesagt keine Dienste laufen lassen, die man nicht braucht, Security-Listen verfolgen, und asap bei Sicherheitslücken updaten.
Im Gegensatz zu dodolin halte ich den GRSecurity aber für eine weitere Maßnahme, die einen ruhiger schlafen lassen kann, da sie Angreifern das Leben um einiges schwerer machen kann (natürlich nur, wenn das Teil richtig konfiguriert ist).

Gibt es irgendwo eine Liste, welche Programme man unbedingt updaten sollte?

Klar. Sofern du SuSE einsetzt, trag dich in die entsprechenden Security-Mailinglisten ein.

velo wrote:Was mache ich da mit meinem rootserver L von puretec, da habe ich ja nicht die Kernel-Sourcen oder zumindest kennte ich die Konfiguration nicht (.config), um die Kernel-Sourcen zu patchen und um danach einen, für mein System, lauffähigen Kernel zu kompilieren?

guck mal in /boot/ - dort liegen bei viele Distros auch die Config..

guck mal in /boot/ - dort liegen bei viele Distros auch die Config..

OK, bloss sind die meisten um zig Module und Funktionen aufgebläht, die kein Mensch (auf dem Server) jemals brauchen wird ...

wenn dich das stört, solltest du sowieso einen eigenen Kernel benutzen..

wenn dich das stört, solltest du sowieso einen eigenen Kernel benutzen..

Mache ich eigentlich grundsätzlich ...

Die Frage, die sich mir bei dem ganzen ohnehin stellt ist, ob der (ohnehin schon) heftig gepatchte SuSE-Kernel GRSecurity überhaupt frisst ...

Im Gegensatz zu dodolin halte ich den GRSecurity aber für eine weitere Maßnahme, die einen ruhiger schlafen lassen kann, da sie Angreifern das Leben um einiges schwerer machen kann (natürlich nur, wenn das Teil richtig konfiguriert ist).

Ich wollte ja auch keine Grundsatzdiskussion lostreten und ich stimme dir durchaus zu, dass GRSecurity eine weitere Massnahme ist, um einen Rechner abzusichern. Die Idee und das Konzept dahinter sind ja gut, das bezweifle ich nicht. Insofern hast du meine Aussage wohl etwas missverstanden, denn wie gesagt, ich kann dir bei obiger Aussage 100% zustimmen. Deshalb ist "im Gegensatz zu dodolin" irgendwie nicht korrekt. :)

Nur kann ich auch ohne das ruhig schlafen, da nur solche User einen Shell-Account bekommen, denen ich vertraue und bei meinen Diensten verlasse ich mich drauf, dass nach einem bekanntgewordenen Bug ziemlich fix ein Patch rauskommt.

Dann kommt bei mir eben noch dazu, dass ich ungerne am Kernel rumpatche, weil ich mich damit nicht so sehr auskenne.

Also nichts gegen GRSecurity allgemein, passt halt nur nicht unbedingt in mein Konzept.

Also nichts gegen GRSecurity allgemein, passt halt nur nicht unbedingt in mein Konzept.

Ach so ... na dann ist ja (mal wieder) gut, dass wir drüber gesprochen haben ...

Ich persönlich halte eine ganze Menge von GRSecurity. Es bietet nicht nur nette kleine "Spielereien" für Netzwerkgeschichten, und erhähte Sicherheit vor Buffer Overflows, sondern man kann auch mit dem ACL-System die Kiste verdammt dicht machen. Es muss schließlich kein "regulärer" Shell-User auf deiner Kiste sein ...

dodolin wrote: und bei meinen Diensten verlasse ich mich drauf, dass nach einem bekanntgewordenen Bug ziemlich fix ein Patch rauskommt.

Dein Vertrauen in Ehren, allerdings bleibt "Patchen" eine rein reaktive Massnahme: Ein potentieller Angreifer hat so stets einen Zeitvorteil. Proaktive Strategien sind also nötig, und hier bietet grsecurity gute Ansätze.

Viele Grüße,
Daniel Bradler

Daniel Bradler wrote: Dein Vertrauen in Ehren, allerdings bleibt "Patchen" eine rein reaktive Massnahme: Ein potentieller Angreifer hat so stets einen Zeitvorteil. Proaktive Strategien sind also nötig, und hier bietet grsecurity gute Ansätze.

Viele Grüße,
Daniel Bradler

Ganu. In Bugtraq berichtete neulich jemand, dass er trotz "ohne ptrace Patch" (aber mit grsecurity) den Fehler nicht hat ausnutzen können.

Allesnicht so einfach

klar im gr patsch kannst du ja sagen denie ptrace
das habe ich gemacht und gestern habe ich alle 4 exploits getestet. und es geht.

Apr 16 01:34:09 <host> kernel: grsec: more denied ptraces, logging disabled for 30 seconds

Noch eine Anmerkung zur Ursprungsfrage:

1&1 verwendet die original Sourcen des 2.4.20 Kernels. Die .config müsste wie bereits erwähnt in /boot liegen. Ansonsten ist sie auch im Paket auf dem Update-Server enthalten.