Sicherheitskonzept eines Dedizierten Servers, Debian

Lesenswerte Artikel, Anleitungen und Diskussionen
kevink
Posts: 11
Joined: 2006-11-18 23:12

Sicherheitskonzept eines Dedizierten Servers, Debian

Post by kevink » 2006-11-18 23:47

Hallo,

Ich möchte gerne meinen Root-Server (Hetzner) soweit wie Möglich sicher machen.
Auf diesem Server läuft nur Apache, PHPMyAdmin und MySQL in keiner chroot Umgebung.

Ich habe 5 zusätzliche IP´s, wo Ich nur die jeweilig benötigten Dienste darauf binde.
Systemdienste laufen über eine nicht errechenbare (ipcalc) IP.

Firewall habe ich keine an.

Nun die Frage: Wer kann mir noch Tips geben, wie Ich die Kiste soweit sichermache?
Firewall und chroot lese Ich mich noch ein, aber sonst?

Könnt Ihr mir ein paar Programme empfehlen, die das System regelmäßig auf Sichereitslücken überprüfen und einen benachrichtigen?

Könnt Ihr ein Buch oder eine Seite zum Thema Sicherheit empfehlen?

Habt Ihr sonst noch Tips?

Und wie sieht meist solch ein Sicherheitskonzept aus?

Danke :)!

Gruß Kevin

flo
RSAC
Posts: 2297
Joined: 2002-07-28 13:02
Location: Berlin

Re: Sicherheitskonzept eines Dedizierten Servers, Debian

Post by flo » 2006-11-19 00:17

War doch erst gestern etwas sehr lesenswertes im Smalltalk:

http://www.rootforum.org/forum/viewtopic.php?t=43519

flo.

User avatar
nyxus
RSAC
Posts: 697
Joined: 2002-09-13 08:41
Location: Lübeck

Re: Sicherheitskonzept eines Dedizierten Servers, Debian

Post by nyxus » 2006-11-19 00:48

kevink wrote:Systemdienste laufen über eine nicht errechenbare (ipcalc) IP.
Was ist für Dich eine nicht errechenbare IP und welche Dienste meinst Du damit genau?

User avatar
daemotron
Administrator
Administrator
Posts: 2800
Joined: 2004-01-21 17:44

Re: Sicherheitskonzept eines Dedizierten Servers, Debian

Post by daemotron » 2006-11-19 12:00

kevink wrote:Und wie sieht meist solch ein Sicherheitskonzept aus?
Das hängt in erster Linie davon ab, was Du auf dem Server hosten willst. Mach Dir mal vorab eine Liste, auf der Du Dir folgende Fragen beantwortest:
  • Welche Dienste sollen auf dem Server von außen erreichbar sein (z. B. http, https, smtp etc.)?
  • Welcher Personenkreis erhält zu den einzelnen Diensten Zugriff?
  • Wie ist die Vertrauenswürdigkeit dieser Personenkreise einzuschätzen?
  • Wirkungsbeziehungen: wie wirkt sich die Kompromittierung oder der Ausfall eines Dienstes auf die übrigen Dienste aus?
  • Welche wirtschaftlichen bzw. juristischen Auswirkungen kann eine Kompromittierung für Dich nach sich ziehen?
  • Welche Ausfallzeiten sind akzeptabel (z. B. aus SLA)?
Ich will das ganze mal an einem Beispiel verdeutlichen und die obige Liste anhand eines Primitiv-Beispiels abarbeiten:
  • Als Dienst lässt Du nur einen Webserver (http) und OpenSSH laufen.
  • Auf den httpd haben natürlich alle Internet-Nutzer Zugriff ("world"). Bei SSH ist das zunächst auch mal so, als einziger autorisierter Nutzer kommst aber nur Du selbst in Frage.
  • "World" ist grundsätzlich nicht vertrauenswürdig, Du selbst traust Dir wohl hoffentlich.
  • Eine Kompromittierung des http-Dienstes gibt einem Angreifer zunächst mal die Möglichkeit, mit den Rechten des HTTPd-Users auf das System zuzugreifen. Welchen Schaden er damit anrichten kann, hängt in erster Linie von der "inneren Sicherheit" Deines Systems ab. Ein Ausfall des HTTP-Dienstes wirkt sich aber in dem Szenario nicht auf andere Dienste aus.
    Eine Kompromittierung des SSH-Dienstes ermöglicht es dem Angreifer, Shell-Zugriff zu erlangen, im schlimmsten Fall sogar Root-Rechte. Damit ist die Kiste dann wohl vollends kompromittiert, und alle laufenden Dienste sind betroffen.
  • In beiden Fällen kann eine Kompromittierung enorme Folgen für Dich haben. Missbraucht der Angreifer Deinen http-Server, um illegale Downloads anzubieten, drohen Dir umfassende juristische und wirtschaftliche Konsequenzen (Stichworte: Urheberrecht, Verbreitung pornographischer Schriften, Verbreitung verfassungsfeindlicher Schriften, Volksverhetzung, ... die Liste kann beliebig fortgesetzt werden).
  • Jetzt wird es spannend. Denn aus diesem Punkt heraus entscheidet es sich, wie Du bei einem erfolgreichen Angriff verfährst (auch das gehört IMHO zu einem Sicherheitskonzept). Wenn Du nur für Dich selbst hostest, kannst Du eine längere Downtime in kauf nehmen. Anders sieht es aus, wenn Du Kunden hostest, denen Du vielleicht sogar eine gewisse Verfügbarkeit der Dienste per Vertrag garantierst (Stichwort: Service Level Agreements).
Aus dieser Liste kannst Du jetzt in etwa ableiten, welche Maßnahmen Du mindestens ergreifen musst, um Deinen Server einigermaßen ruhigen Gewissens betreiben zu können.

Zunächst einmal zu den Diensten:
  • Aufgrund seiner zentralen Einwirkung auf das Gesamtsystem muss SSH entsprechend abgedichtet werden, am besten mit Public Key Authentifizierung. Wer mag, kann auch noch den Port verlegen oder Portknocking einsetzen.
  • Beim http hilft erst mal eine vernünftige Konfiguration. Wer allerdings dynamische Seiten (egal ob PHP, ASP, Perl oder JSP) hostet, sollte sich überlegen, ob neben einer restriktiven Konfiguration noch ein Reverse Proxy vorgeschaltet wird, der nach Angriffsmustern fahndet und diese blockiert, bevor sie den eigentlichen Webserver erreichen.
Aus der Betrachtung der Auswirkungen kannst Du bereits ablesen, dass unabhängig vom Hosting-Szenario (egal ob kommerziell oder private Nutzung) eine Umfassende Absicherung vor feindlicher Übernahme unumgänglich ist. Spannend ist also jetzt die Frage, wie gehst Du damit um, wenn ein Angreifer Erfolg hatte und die erste Hürde (den Dienst selbst) geknackt hat?

Im Falle des SSH-Daemons hast Du aufgrund seiner zentralen Einwirkung auf den gesamten Server grundsätzlich nie eine Wahl - Du musst die Kiste umgehend vom Netz nehmen und komplett neu aufsetzen.

Etwas differenzierter sieht es beim Webserver aus. Hast Du den Webserver als normalen Dienst laufen, musst Du auch hier mit dem schlimmsten rechnen und die Kiste neu aufsetzen. Hier kommt jetzt aber das Thema Downtime ins Spiel. Wenn Du Kunden hast, werden die wohl kaum glücklich sein, wenn ihre Seiten stundenlang vom Netz sind. Neben Vertragsstrafen (SLA) können auch noch Schadenersatzforderungen drohen.

Da der kompromittierte Server nicht einfach unverändert weiterlaufen darf, musst Du in Deinem Konzept eine Möglichkeit berücksichtigen, in einem solchen Fall kundenfreundlich reagieren zu können. Bausteine können hier sein:
  • Abschottung der Kundenumgebungen voneinander. Dadurch wirkt sich eine kompromittierte Umgebung nicht gleich auf die anderen Kunden aus. Stichwort: BSD-Jails, GRSecurity, RSBAC. Reines Linux-chroot ist übrigens ein unzureichender Schutz, da leicht aufzubrechen.
  • Abschottung der einzelnen Dienste voneinander. Hierdurch werden die oben beschriebenen Wechselwirkungen der Dienste aufeinander reduziert (sinnvoll, wenn neben http noch ein Datenbankserver, FTP oder Mail-Dienste ins Spiel kommen). Stichwörter: wie oben, zusätzlich noch Virtualisierung (Xen, OpenVZ, VServer).
  • Bereithalten eines Ersatz-Servers (hot standby), auf den Du bei Bedarf die Kundenumgebungen oder einzelbe Dienste kurzfristig verschieben kannst. So kannst Du wenigstens für nicht kompromittierte Kunden oder Dienste den Betrieb aufrecht erhalten. Allerdings benötigst Du dafür i. d. R. mindestens drei Server: Produktiv-System, Standby-System und Dienste-Proxy, der im Bedarfsfall auf den Ersatzserver umleitet
Wie Du siehst, stellen unterschiedliche Szenarien äußerst unterschiedliche Anforderungen an ein Sicherheitskonzpet (ich nenne es eigentlich lieber Betriebskonzept...) - und natürlich auch an den Geldbeutel. Für den Betrieb der privaten Homepage wird man sich wohl kaum ein Hot-Standby-System leisten wollen und nimmt lieber ein paar Stunden Downtime in Kauf - wohingegen bei zahlenden Kunden dieser Posten einfach auf der Betriebskostenseite verbucht und bei der Preiskalkulation berücksichtigt werden kann...

User avatar
nyxus
RSAC
Posts: 697
Joined: 2002-09-13 08:41
Location: Lübeck

Re: Sicherheitskonzept eines Dedizierten Servers, Debian

Post by nyxus » 2006-11-19 12:38

Sehr guter Text jfreund, IMHO ist er Wert irgendwo "gepinnt" zu werden.
Aber bei einem Punkt bin ich mir sicher, daß Du den eigentlich doch anders meinst:
jfreund wrote:[*]"World" ist grundsätzlich nicht vertrauenswürdig, Du selbst traust Dir wohl hoffentlich.
Sich selbst zu trauen ist natürlich das schlechteste was man machen kann. Denn genau das ist ja der Grund, dass man normalerweise unter einem nicht-root-User arbeitet. Und das man sich manchmal zu sehr traut ist auch ein Grund, dass es hier einen für den Aussenstehenden lustigen Thread gibt, in dem manche (für die es natürlich alles anderes als lustig war) von ihren Missgeschicken berichten.

User avatar
daemotron
Administrator
Administrator
Posts: 2800
Joined: 2004-01-21 17:44

Re: Sicherheitskonzept eines Dedizierten Servers, Debian

Post by daemotron » 2006-11-19 13:08

Nyxus wrote:Aber bei einem Punkt bin ich mir sicher, daß Du den eigentlich doch anders meinst
:oops: Du hast mich ertappt. Das Thema "Berechtigungskonzept" ist natürlich ein integraler Bestandteil einer Sicherheitsstrategie... Ich wollte eigentlich nur damit zum Ausdruck bringen, dass ich einem User nur die Rechte zugestehen darf, bei denen ich im so weit traue, dass er damit keinen Unsinn macht (z. B. sollte ich jemand, dem ich SMTP-Berechtigung gebe, soweit trauen können, dass er damit keinen Spam versendet). Aber wie so oft im Leben gilt auch hier: Vertrauen ist gut, Kontrolle ist besser :wink:

kevink
Posts: 11
Joined: 2006-11-18 23:12

Re: Sicherheitskonzept eines Dedizierten Servers, Debian

Post by kevink » 2006-11-19 13:56

Hi,

Danke für die Antworten, speziell danke an jfreund.

Ich werde mir das mal ausarbeiten, und das dann dem Linux Profi in unserem geschäft vorlegen, der das am besten noch absegnet.

@Nyxus:
Das ist die ServerIP. Die 5 anderen laufen in einem extra Netz, und stehen nicht in Verbindung mit der Server IP.

Danke :).

Gruß Kevin

User avatar
nyxus
RSAC
Posts: 697
Joined: 2002-09-13 08:41
Location: Lübeck

Re: Sicherheitskonzept eines Dedizierten Servers, Debian

Post by nyxus » 2006-11-19 16:58

kevink wrote:@Nyxus:
Das ist die ServerIP. Die 5 anderen laufen in einem extra Netz, und stehen nicht in Verbindung mit der Server IP.
Alles klar, aber das hat natürlich nichts mit Security zu tun sobald Du mit einer von diesen 5 IPs Dienste anbietest. Denn dann ist auch sofort klar (errechenbar ;-) ) welche 4 weiteren IPs Du hast. (Und auch wenn diese nicht errechenbar wären könnte man darauf keine Sicherheit begründen).