Anfängerfragen

[jcd]

Hallo,

wie in meinem ersten Beitrag schon erwähnt, arbeite ich mich gerade in die Server Administration ein, und habe mir dafür ein kleines Testsystem zusammengebaut.

Nun sind beim Installieren, Konfigurieren, Manpages Lesen und intensiven Googeln ein paar Fragen aufgetaucht, für die ich keine Antworten finden konnte.

Wenn ihr das lieber in einem Thread haben wollt, dann ruhig den Beitrag verschieben/löschen und ich setze das in den anderen Thread ?

Ich denke da werden auch noch ein paar mehr Fragen auftauchen, und es wär nett wenn ihr mich da jeweils in die richtige Richtung schuppsen könntet, und wenns nur ein Link ist.

Vielleicht erstmal zum Gesamtkonzept:

Benötigt wird ein Server für das Java-Spiel Minecraft, ein LAMP, und ein Teamspeak. Der LAMP soll maximal ein CMS alla Drupal und ein Forum alla phpBB befeuern.

Als OS kommt momentan ein Debian 6.0.1a mit OpenVZ Kernel zum Einsatz.
Der Fokus liegt recht stark auf Sicherheit, ich möchte da die Risiken minimieren.

Da fangen die Fragen auch schon an:

- Ist es sinnvoll eine Java-Anwendung (mitsamt Java) in eine VZ zu packen ?

- Inwieweit ist es sinnvoll, das LAMP auf verschiedene VZs aufzuteilen ? Macht es Sinn den Mysql vom Http Server zu trennen ?

- Ich weiß wie ich jeder OpenVZ eine IP zuordne, und habe es mit iptables auch hinbekommen, die entsprechenden Ports weiterzuleiten. Bei Http funktioniert das problemlos, bei FTP musste ich dem Client die Port-Range zuteilen, was für einen Client der öffentlich erreichbar sein soll, ja nicht so günstig ist. Ist der Weg über iptables überhaupt der richtige ? Wie sieht das mit der Netzwerkstruktur später in einem Rechenzentrum aus ?
Hier bräuchte ich mal eine Orientierung, wie man das am Besten löst.

[jcd]

Danke für die Antwort, das hilft schon mal weiter.

Ich glaube nicht, das die Webseite allzu stark frequentiert wird. Die Last auf dem HTTP/MYSQL dürfte sich als ziemlich in Grenzen halten. Die Webseite ist nur Beiwerk für den Minecraft-Server.
Die Trennung war primär auf Sicherheit ausgerichtet.

An Betriebssystemen habe ich mir bisher folgendes angeschaut:

Ubuntu 10.04 LTS server
Debian 6.0.1a
FreeBSD

Ubuntu stellt keine Pakete für OpenVZ bereit, Debian schon. Das Jail-Konzept von BSD las sich anfangs nett, Debian und Ubuntu machten es aber erheblich leichter, sich mit dem System zu beschäftigen, während BSD früh Steine in den Weg legte. Vielleicht war die Beschäftigung mit BSD aber auch etwas zu halbherzig.

Ich kann nicht beurteilen, wo einzelne OSe Vor- und Nachteile bezüglich Sicherheit haben. Ich wäre aber sehr an einer sinnvollen Diskussion, bzw Informationen interessiert.

Ich war der Ansicht, Debian, Ubuntu, BSD, CentOS und vielleicht noch OpenSUSE haben eine gewisse Verbreitung als Server-OS und sind deswegen dafür geeignet.

Ich hätte ja mal behauptet, das Minecraft (bzw das Java, das es benötigt) sowie ein kleines Webportal und Teamspeak sind recht "geringe" Funktionsanforderungen, die sich auf nahezu jedem OS realisieren lassen.

Da auch recht wenig (ein paar Tage) Erfahrung mit Unix Systemen vorhanden ist, bin ich da noch völlig flexibel.

Debian/Ubuntu hat bei uns bisher den besten Eindruck bezüglich Beherrschbarkeit hinterlassen, auch ist die Doku Online recht gut, nur mit den MAN Pages verbleiben doch öfters Fragezeichen.

Ich würde mich freuen wenn man das ausdiskutieren könnte.

[Joe User]

Minecraft soll wohl sehr RAM-hungrig sein, daher musst Du ihm ordentlich RAM zuweisen. Zudem ist JAVA derzeit das begehrteste Ziel für die bösen Buben, weshalb das sicherheitstechnisch in einen eigenen OpenVZ-Gast gehört und keine direkte Verbindung zu den anderen Gästen haben sollte. Auch Gameserver gehören allgein zu den beliebteren Zielen, also musst Du hier mit geziehlten und erfolgreichen Attacken rechnen. Daher den Gameserver bitte nur betreiben, wenn Du Dir zu 100% sicher bist, was Du da tust.

LAMP kann ruhig in einem einzelnen Gast betrieben werden, denn der Webserver (die Scripte) benötigt ohnehin Zugriff auf den MySQLd und somit ergibt eine Trennung sicherheitstechnisch keinen Vorteil. Für die Performance würde eine Trennung, dann allerdings auf zwei physikalisch getrennte Server, ab einer gewissen Grösse Sinn machen, aber diese Grösse wirst Du relativ sicher nicht erreichen.

Die einzelnen Bestandteile des LAMP müssen natürlich individuell auf die jeweiligen Bedürfnisse und verfügbaren Ressourcen angepasst werden, aber an dem Punkt bist Du derzeit noch nicht angekommen.

[jcd]

Erfahrungen bezüglich Minecraft-Performance bestehen schon, lokaler Server mit 6 Spielern und einigen Plugins nimmt bei mittelgroßer Map gleich mal 400MB RAM in Beschlag. Beim Root peile ich später 8GB RAM an, und davon dürfte nur wenig dem OS/HTTP zum Opfer fallen, also sollten Minecraft noch einige GB zur Verfügung stehen.

Überlegungen, einen gemanagten Gameserver zu mieten fanden statt. Das wurde verworfen, nicht aus Kostengründen, sondern wegen der fehlenden Flexibilität die unser Spielkonzept so nicht erlauben würde.

Ich gebe sofort zu, das ich noch recht wenig Ahnung von der Materie habe. Aber irgendwo muss man ja mal anfangen, also der Versuch erstmal alles auf dem Testsystem aufzubauen und kennenzulernen.
Ob das dann reicht um einen Root zu betreuen, muss man dann entscheiden.
Ganz alleine auf weiter Flur bin ich auch nicht, um den Server würden sich später mindestens 2, eventuell 3 Personen kümmern. Die sind zwar im Moment auch nicht erfahrener als ich, bringen aber teils solidere Linux und IT Grundlagen mit, und wir sind zu zweit bzw zu dritt dabei, uns parallel einzuarbeiten. Zu zweit ließen sich auch viele Probleme mit dem Testsystem schneller finden.
Zudem möchte ich später nicht alleine für den Root verantwortlich sein, das lässt die Zeit ja auch nicht immer zu.

Das es nicht viel nützt den Mysql auszulagern, war mir fast klar. Dann wird das der Einfachheit halber auch nicht gemacht.

Was mich im Moment beschäftigt: Macht es Sinn auf Debian zu setzen ?
Wäre ein anderes OS deutlich besser geeignet ?
Ich habe hierzu schon mehrfach Google bemüht, allerdings findet sich da zur Not jede Meinung.

Was mich auch noch interessieren würde:

Wie gestaltet man eine Attacke auf ein System, z.B. ein Debian, auf dem nur ein gut abgesicherter sshd läuft ? Der sshd lässt sich ja ziemlich gut absichern, zumindest habe ich mehrfach gelesen, das ein gut abgesicherter sshd im Gegensatz zu einem http Server ein zu vernachlässigendes Risiko darstellt.
Müsste man da nicht schon auf dem Niveau eines TCP/IP Stacks unterwegs sein, um einen Angriff abseits des SSH Ports anzubringen ?

Wie sehen aktuell Sicherheitsprobleme bei Java aus ? Hat da jemand einen Link o.Ä. für mich ?
Sehe ich das richtig, das man dann quasi versucht, Exploits in der Java-Anwendung (Minecraft) zu finden ?

[jcd]

Für mich klingt das so, als ob man diese Erfahrungen erst nach längerem Betrieb und viel Fluchen machen kann. Du bist auch der Erste, von dem ich das so höre. Ich bin froh darüber !

Werden wir doch mal konkreter: Welches OS bietet sich für die gegebende Situation an ?
Noch stellt ein Wechsel keinen großen Verlust dar, und wäre leicht zu machen.

[Joe User]

Zunächst sei erstmal klargestellt, dass auch Debian für den Einsatz als Server-OS durchaus (noch) akzeptabel sicher und performant ist. Das meiner Meinung nach grösste Problem bei Debian (und somit auch für alle darauf basierenden Distros wie etwa Ubuntu) ist, dass der Fokus dort seit einiger Zeit klar auf dem Desktop-Einsatz liegt. Dadurch werden die für den Servereinsatz benötigten Pakete mangels Man-Power zwangsweise etwas vernachlässigt. Zudem sind die verantwortlichen Entwickler bei Debian leider zum Teil zu unerfahren und produzieren so teils eklatante Fehler. Das wäre an sich gar nicht mal so schlimm, aber die Debian-Entwickler halten sich fast alle leider für etwas Besseres und nehmen berechtigte Kritik von aussen allzu oft als persönlichen Angriff und reagieren dann bockig und lernresistent.
Eines der besten Beispiele dafür ist etwa das standardmässig gesetzte "AddDefaultCharset" in der Apache-Config unter Debian. Dass das falsch und für manche (datenbankbasierte) Anwendungen fatal ist, wurde den zuständigen Debian-Entwicklern schon vor der offiziellen Einführung von Apache 2.0 in Debian unter Anderem von den Apache-Entwicklern deutlich mitgeteilt. Geändert wurde das bis heute nicht und so fallen einige Webanwendungen unter Debians Apache noch heute auf die Nase. Bei PHP und ein paar anderen Paketen gibt es vergleichbare oder schlimmere Fehler. Besonders schlimm waren Debians Fehler bei openSSH und Exim, welche damals zu tausenden gekaperten Servern führten (nachzulesen in nahezu jedem IT-Newsmagazin).
So, genug zu Debian, sonst versau ich mir noch den Tag ;)

openSSH ist, sofern man ausschliesslich Pub-Key-Auth verwendet, für den 0815-Serverbetreiber wirklich zu vernachlässigen.

Bei Java werden sowohl die Anwendungen, als auch Java selbst gerne und erfolgreich angegriffen. Daher muss man hier besonders vorsichtig sein und jegliche Updates umgehend einspielen. Auf einem Server ist es im vergleich zu Desktops zwar minimal schwerer Java anzugreifen, aber oft trotzdem einfach genug, zumal Oracle nicht alle bekannten Löcher gestopft hat.

Allgemein ist ein Server vergleichbar mit einem Neugeborenen: Man darf Beide nie allein lassen und muss sich permanent um sie kümmern.

[rudelgurke]

Weiß nicht wie eure Kostenrelation aussieht, vielleicht ist es auch möglich den Minecraft Server seperat anzumieten, dafür kann man beim Server dann etwas sparen und muss sich keinen Boliden hinstellen.
Zum OS oder der Distro - erstmal dass nehmen was man kennt. Hatte selbst schon Windows empfohlen allein aus dem Grund dass man genügend Zeit damit verbringt die Services einzurichten, abzusichern und - naja - alles was dazugehört. Kommen dann noch fundamentale Dinge dazu wie Slackware's PAM Abwesenheit, Debians Art Dinge anders als bei SuSe einzurichten wird langsam die Zeit eng.
Und wenn ihr mehrere Personen seid die auf den Server Zugriff haben, unbedingt vorher absprechen wer was wie macht - sonst gibt es nur Ärger und Streit.

[jcd]

Nach einem umfangreichen Brainstorming haben wir beschlossen, erstmal bei Debian zu bleiben.

Gibt es Seiten, wo Konfigurationsprobleme bzw allgemeine Probleme/Sicherheitslücken von Debian zentral behandelt werden ?

Wir sind ja sicher nicht die ersten, die vor diesen Problemen stehen.

Oder kann man die kritischen Punkte der aktuellen Version kurz auf einen Punkt bringen ?


Was noch sehr helfen würde, wäre eine Aufklärung bezüglich den OpenVZ Umgebungen und dem Netzwerk. Wie organisiert man das grundlegend, welche Technik/Programme nutzt man hier üblicherweise ? Das OpenVZ Wiki schweigt sich hierzu leider aus.

EDIT:

Nachtrag, wir haben uns nochmal Gedanken gemacht. Da OpenVZ auf dem Debian gerade so schön läuft: Wir benötigen auf dem Debian-Host ja nur einen einzigen Dienst: sshd.
Alle anderen Dienste laufen sowieso in OpenVZ Containern. Für LAMP kämen dann ja auch sofort wieder andere Distributionen in betracht:

http://wiki.openvz.org/Download/template/precreated

Wäre eine davon besser als LAMP oder Java/Minecraft VZ geeignet ? Ich denke da z.B. an das Ubuntu, was dann auch von der Bedienung für uns zum Debian keine radikale Umstellung wäre.

[daemotron]

Moin jcd,

erstmal Willkommen im RootForum (falls das noch keiner gesagt haben sollte ).

Vieles wurde ja schon gesagt, eines wollte ich noch nachreichen: Bei Java-basierten Anwendungen bist Du mit Linux derzeit etwas besser versorgt als mit FreeBSD, daher ist Debian durchaus keine schlechte Wahl (ich persönlich hätte vielleicht CentOS vorgezogen, aber das ist letztlich Geschmackssache - und das von mir, der hier die BSD-Seuche erst ins Forum eingeschleppt hat :-o ).

Gibt es Seiten, wo Konfigurationsprobleme bzw allgemeine Probleme/Sicherheitslücken von Debian zentral behandelt werden ?

Grundsätzlich würde ich empfehlen, die Mailingliste debian-security-announce zu abonnieren und zu verfolgen. Das ist eine read-only Mailingliste, auf der sämtliche bekannt gewordenen Sicherheitsprobleme von Debian-Paketen angekündigt werden. Manchmal erfolgen diese Ankündigungen nicht so zeitnah, wie sie eigentlich sollten (das Problem hat nahezu jede Distribution), daher würde ich auch empfehlen, den Feed der National Vulnerability Database mit in den Feedreader zu packen.

Konfigurationsprobleme sind fast immer generisch, d. h. Du wirst hier im Forum sicherlich Hilfe bekommen, wenn mal was klemmt (und Debian-User gib's hier auch).

Was noch sehr helfen würde, wäre eine Aufklärung bezüglich den OpenVZ Umgebungen und dem Netzwerk. Wie organisiert man das grundlegend, welche Technik/Programme nutzt man hier üblicherweise ? Das OpenVZ Wiki schweigt sich hierzu leider aus.

Mit OpenVZ habe ich schon sehr lange nicht mehr gearbeitet, aber grob gesagt gibt es zwei Möglichkeiten: Entweder, man weist jedem Gast eine öffentliche IP zu und verdonnert den Host, Pakete für diese IPs (oder Subnetze) zu forwarden (bei Linux war das AFAIK irgendein sysctl, der gesetzt werden musste), oder man gibt den Gästen private IPs (192.168.0.0/24, 172.16.0.0/16, 10.0.0.0/8) und lässt den Host als NAT-Router arbeiten. Welche von beiden Alternativen man wählt, hängt in erster Linie davon ab, wie sich die Anzahl der Gäste zur Anzahl verfügbarer öffentlicher IPs verhält. Sind genügend öffentliche IPs vorhanden, kann man sich den Zirkus mit iptables für NAT/MASQ sparen.

HTH
Daemotron

[daemotron]

Für LAMP kämen dann ja auch sofort wieder andere Distributionen in betracht:

http://wiki.openvz.org/Download/template/precreated

Wäre eine davon besser als LAMP oder Java/Minecraft VZ geeignet ? Ich denke da z.B. an das Ubuntu, was dann auch von der Bedienung für uns zum Debian keine radikale Umstellung wäre.

Funktionieren würden alle, allerdings würde ich ein paar der vorgeschlagenen Distributionen ausschließen:

• Debian 5 ist veraltet und wird irgendwann auch aus dem Support genommen. Wenn Debian, dann 6.
• Fedora ist stark Desktop-lastig und die Entwicklerspielwiese für Red Hat. Daher passieren hier öfter mal unvorhergesehene Dinge, die man auf einem Server lieber nicht haben möchte. Ist halt eine Distribution für Entwickler; Linus selbst setzt sie z. B. auf seinem Rechner ein.
• Wenn Ubuntu, dann würde ich zu 10.4 greifen - das ist eine LTS-Version, die noch bis 2013 unterstützt wird.
• CentOS 4 ist uralt (wenngleich noch supported) - hier würde ich mindestens 5 nehmen, oder besser noch auf 6 warten (müsste demnächst erscheinen). CentOS ist generell eine gute Wahl für Server (ist im Prinzip identisch mit Red Hat Enterprise Linux), aber man darf nicht auf Bleeding Edge Versionen angewiesen sein (keine Ahnung, wie das bei Minecraft ist).

[Roger Wilco]

CentOS 4 ist uralt (wenngleich noch supported) - hier würde ich mindestens 5 nehmen, oder besser noch auf 6 warten (müsste demnächst erscheinen).

Für CentOS 6.0 oder 6.1 würde ich derzeit nicht die Luft anhalten. Eher würde ich - falls es ein RHEL Klon werden soll - auf Scientific Linux ausweichen.

[jcd]

Danke für die umfangreiche Antwort und die freundliche Begrüßung im Forum :)

So langsam formt sich ein Bild, aber es hat noch Lücken.

Du schreibst, man bekommt sicher Hilfe im Forum wenn es klemmt - genau da sehe ich aber das Problem. Die meisten Dinge funktionieren ja doch schon auf Anhieb, sind aber vielleicht unsicher Konfiguriert, ohne das ich das weiß. Und wenn das in der Man-Page, im Wiki oder einem HowTo nicht steht, wird das vermutlich übersehen, und wir haben eine Sicherheitslücke von der Niemand weiß.

Die Frage wäre: Sind die angesprochenen Kritikpunkte von Debian bei Ubuntu weniger stark verbreitet ? Ansonsten hätte das Ubuntu ja keinen Vorteil gegenüber dem Debian als LAMP oder Java VZ.

Nochmal eine kurze Frage zu OpenVZ: Ist das für unsere Konfiguration überhaupt ein vernünftiger Weg ? Oder gäbe es da auch Ansätze zur Verbesserung ?

Mir ist natürlich klar, das ein Profi wohl fast jedes OS für unsere Zwecke konfigurieren könnte. Mir geht es nur darum, mit welchem OS uns das mit begrenztem Wissen und Erfahrung am besten gelingt.

[papabaer]

Nun, da will ich auch mal was dazu senfen.

Ubuntu gegen Debian auf einem Server abzuwägen macht wenig Sinn. Ubuntu ist Debian mit bunten Gimmicks für den Desktop, sehr viele Softwarepakete für den Server sind einfach übernommen, wenn es Anpassungen gab, dann halbherzig. Daher würde ich auf Servern immer zu Debian tendieren.

Grundsätzlich würde ich eine Distribution mit a) langen Release-Zyklen und sicheren Upgrade-Pfaden wählen, weil du sonst deinen Server alle zwei Jahre neu aufsetzen darfst. Das wären CentOS, Debian (,SLES, RHEL) oder BSDs oder b) Rolling Releases nutzen. Da kommt für eine Produktiv-Umgebung nur Gentoo in Frage (Arch Linux ist auf einem Server zu heiß gestrickt). Alles Andere (fedora, ubuntu, OpenSuse, ...) würde ich als Spielzeug und Bastelecke verbuchen.

So lange man nur Linuxe virtualisieren will, halte ich OpenVZ für die einfachste und sinnvollste Lösung. Das Zeugs erklärt sich quasi selbst und skaliert verdammt gut. Soll es eine Para-/Vollvirtualisierung werden, würde ich mir XEN, oder noch eher KVM anschauen.

Die Trennung in LAMP-Stack und Java-Gedöns wurde schon angesprochen.

Ein Punkt der noch nicht angesprochen wurde ist der LAMP-Stack. LAMP ist DIE Standard-Kombination auf Servern und damit auch das Angriffsziel. PHP ist sicherheitstechnisch aus verschiedenen Gründen ein übles Teil und so Sachen wie Drupal oder irgendwelche Foren verschlimmern die Situation zusätzlich. Es ist sehr leicht, PHP zu programmieren aber es ist richtig schwer, PHP gut und sicher zu programmieren. Das führt zu vielen fiesen Sicherheitslücken in PHP-Code.

Ich würde daher mal nachsehen, was es sonst noch so für Web-Software gibt, die nicht PHP heißt. Ich finde für kleine Seiten z.B. refinery in Rails ganz nett.

Die Sache mit der Sicherheit ist der Pferdefuß der ganzen Geschichte. Du hast die Grundproblematik ja selber schon erkannt:

Die meisten Dinge funktionieren ja doch schon auf Anhieb, sind aber vielleicht unsicher Konfiguriert, ohne das ich das weiß. Und wenn das in der Man-Page, im Wiki oder einem HowTo nicht steht, wird das vermutlich übersehen, und wir haben eine Sicherheitslücke von der Niemand weiß.

Der einzige Weg, das Dilemma zu umgehen ist nun einmal, das nötige KnowHow und die Erfahrung zu haben, die möglichen Lücken zu kennen und eben nicht zu übersehen. Genau diesen Punkt vergessen viele Leute, die sich mal eben nen Root-Server mieten und denken: "es läuft ja irgendwie, alles gut"

Das Ziel dir zu Hause ein Linux hinzustellen muss also nicht nur sein, dass du das alles einmal installierst und es läuft, sondern darüber hinaus, dass du auch lernst, wie man das ganze von Außen zerlegen könnte und wie du dich dagegen wehren kannst. Das wiederum geht nur mit einem wirklichen Verständnis über die Dinge, die da in den Tiefen von Linux passieren.

[Joe User]

Drupal wird unter Anderem vom Weissen Haus eingesetzt und die Patches direkt an Upstream durchgereicht, somit ist Drupal sicherheitstechnisch auf einem akzeptablen Level.
phpBB3 wurde unter Anderem von Stefan Esser einem ausführlichen Audit unterzogen und ist daher ebenfalls auf einem höheren sicherheitstechnischen Level anzusiedeln. Zudem kann ich phpBB3 auch aus eigener Erfahrung empfehlen, da ich es für das RootForum seit Version 3.0.0 produktiv einsetze.

PHP an sich kann man auch ausreichend sicher konfigurieren, insbesondere wenn einem die auszuführenden Apps bekannt sind. Das Problem sind hier hauptsächlich die Linux-Distributoren ohne Rolling-Release, da sie die sicherheitstechnischen Patchsets nur schwer identifizieren und backporten können, denn diese werden (wie auch beim Linux-Kernel) nur selten als solche deklariert. Aus diesem Grund setze ich persönlich nur noch Rolling-Release-OSs (FreeBSD und Gentoo) auf den von mir betreuten Webservern ein.

Fazit: PHP ist nicht sicherer oder unsicherer als andere Scriptsprachen, man muss es halt nur richtig konfigurieren und auf dem aktuellen Stand halten. Den schwarzen Peter haben hier eindeutig die Binary-Distributoren, da sie zwangsweise beim Backporten wichtige Patchsets übersehen.


Beim Rest stimme ich Dir zu ;)