Vorwort zur 2. Auflage Zielsetzung und Planung... 13

Transkript

1

2 Inhalt Vorwort zur 2. Auflage Zielsetzung und Planung Planung Einsatzzweck des Servers Besondere Anforderungen Risiko-Management Serverhardware Zertifizierte Hard- und Software Dimensionierung des Servers Ein kleiner Rundgang durch Linux Unix Linux Die richtige Distribution Ubuntu Gentoo Linux Auswahl der passenden Distribution Installation und Konfiguration Einige Detailfragen Partitionierung Welches Dateisystem ist das richtige? RAID Installation oder 64 Bit? Gentoo Ubuntu Feintuning Paketmanagement einrichten Konfiguration von OpenSSH Benutzer anlegen Konfiguration der Bash Umask Systemhärtung Inventur benötigter Dienste Systemstart Ubuntu

3 Inhalt Systemstart Gentoo Abspecken Netzwerkdienste kontrollieren Berechtigungen prüfen Virenschutz Host-Firewall Grafisches Helferlein: Firewall Builder Arbeiten mit dem Firewall Builder IDS-Systeme Aktive Abwehr von Angriffen Fail2ban Denyhosts Rechtliches ISO Dokumentation Änderungsverwaltung Protokollierung und Monitoring Detaillierte Härtungsmaßnahmen Serverdienste Apache Installation Konfiguration mod_rewrite SSL SSL mit Ubuntu SSL mit Gentoo PHP Tuning Härtung Datenbanken MySQL PostgreSQL Apache Tomcat Installation und Konfiguration »mod_jk«Zusammenarbeit mit dem Webserver Grundlegende Absicherung Jabber Installation unter Ubuntu Installation unter Gentoo

4 Inhalt Benutzerverwaltung und Client-Konfiguration Sicher Chatten mit OTR Ejabberd mit eigenem SSL-Zertifikat Ein eigenes offizielles SSL-Zertifikat Mailversand Dateitransfer FTPS SCP und SFTP Optimierung und Monitoring Monitoring SNMP MRTG Cacti Nagios Webserver-Statistiken Optimierung apachetop mytop sysstat pidstat Festplattenstatus Hochverfügbarkeit Virtualisierung Xen das Konzept Xen unter Ubuntu Xen unter Gentoo Sicherheit Der Linux-Cluster Heartbeat Installation und Konfiguration Szenarien Verteilte Datenhaltung DRBD Installation Konfiguration Integration mit Heartbeat

5 Inhalt 7 Serverwartung Tools Landscape Patch-Management Patch-Management mit Ubuntu Patch-Management mit Gentoo Schwierigkeiten beim Patch-Management Den Überblick behalten Rechtliches Zusammenfassung Index

6 Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen. Der Anhalter 1 Zielsetzung und Planung In diesem Kapitel werden die grundlegenden Fragen erörtert, mit denen Sie sich auseinandersetzen sollten, bevor Sie einen Server betreiben können. Dies betrifft den Einsatzzweck Ihres Servers, das Abschätzen der Risiken sowie die geeignetste Hardware und Linux-Distribution. Abgerundet wird das Kapitel durch eine kleine Entwicklungsgeschichte von Linux. 1.1 Planung Es gibt viele Gründe, einen eigenen Server zu betreiben. Manche Menschen treibt die pure Lust an der Materie, andere wahrscheinlich die meisten verfolgen einen bestimmten Zweck. Im privaten Bereich kann das die Veröffentlichung einer eigenen Website sein, für die ein Standardpaket bei einem der einschlägigen Webhoster nicht geeignet ist, oder der Betrieb eines Chatservers oder eines Spieleservers. In Firmen wird der Betrieb eines eigenen Servers häufig aus Kosten- und Sicherheitsgründen erwogen. Standardangebote von Providern sind meist nur für Privatkunden ausgelegt und kommerzielle Angebote entsprechend kostspielig. Hinzu kommt, dass nicht jede Firma ihre sensiblen Daten auf Systemen ablegen möchte, auf die andere Personen die Administratoren des Providers Zugriff haben. Gründe für den Betrieb eines eigenen Servers gibt es also viele leider auch mindestens genauso viele Fußangeln. Dieses Buch soll Ihnen helfen, bekannte Fußangeln zu vermeiden, und Sie in die Lage versetzen, einen eigenen Server zu planen, zu installieren und sicher zu betreiben. Es behandelt ausschließlich die Einrichtung und den Betrieb von Servern mit Linux. Auf einen generischeren Ansatz, der auch echte Unix-Systeme wie FreeBSD oder OpenBSD umfasst, habe ich bewusst verzichtet. Zum einen führt ein generischer Ansatz immer zu einer weniger detaillierten Beschreibung der einzelnen Themen, zum anderen sind 13

7 1 Zielsetzung und Planung sich dank des POSIX-Standards auf Unix basierende Betriebssysteme und Linux in der Regel so ähnlich, dass im Einzelfall die mit Linux gelernten Techniken einfach auf Unix-basierte Betriebssysteme transferiert werden können. Die Anhänger der reinen Lehre bzw. der freien Software bezeichnen Linux als GNU/Linux, da es also der Kernel selbst in der Regel nur im Zusammenspiel mit einer großen Anzahl von GNU-Tools zu gebrauchen ist. In diesem Buch werde ich pragmatisch und unpolitisch die Bezeichnung Linux ohne Zusatz verwenden. Puristen mögen mir dies nachsehen. Darüber hinaus meine ich mit Linux wirklich nur Linux und nicht Unix. Obgleich häufig in denselben Topf geworfen, sind Linux und Unix zwei verschiedene Dinge. Linux sieht aus wie Unix, fühlt sich an wie Unix,»schmeckt«wahrscheinlich auch wie Unix, ist aber kein Unix. Als Unix werden die Betriebssysteme bezeichnet, die wirklich organische Nachkommen des Ur-Unix sind. Dies sind insbesondere die verschiedenen BSD-Varianten, Solaris, Mac OS X, HP-UX und AIX. Alle diese Systeme können auf eine gemeinsame Codebasis zurückgeführt werden. 1 Linux hingegen wurde Anfang der 90er Jahre»aus dem Nichts«erschaffen, ohne Verwendung von Unix- Code. Näheres hierzu erläutert Abschnitt 1.3,»Ein kleiner Rundgang durch Linux« Einsatzzweck des Servers Wie bei den meisten Dingen im Leben werden die wichtigsten Entscheidungen für den Betrieb eines Servers vor der Installation getroffen. Am Anfang wird eine Überlegung zu Sinn und Zweck des Servers stehen. Daran anschließen sollte sich die Erstellung einer (in der Praxis wahrscheinlich mehr oder weniger) klar formulierten Liste von Anforderungen. Zu diesem Zeitpunkt ist es weniger wichtig, sich in technischen Details der Betriebssystem- und Dienste-Installation zu ergehen, als vielmehr Rahmenbedingungen für die Themen abzustecken, die sich im Nachhinein nur mit erhöhtem Aufwand ändern lassen. Dies umfasst insbesondere die Auswahl und Dimensionierung der Hardware, die Auswahl eines geeigneten Standortes (Provider) für den Server und die klare Formulierung der Anforderungen an Verfügbarkeit und Schutzbedarf des Systems. Als Hilfestellung können Sie die folgende Frageliste verwenden. Sie erhebt keinen Anspruch auf Vollständigkeit dazu sind die individuellen Anforderungen einfach zu unterschiedlich, deckt aber die vier wichtigsten Punkte Performance, Speicherbedarf, Verfügbarkeit und Schutzbedarf ab. Welche Dienste soll der Server anbieten? Wie viele Benutzer werden gleichzeitig auf dem Server arbeiten?

8 Planung 1.1 Wie hoch ist der Schutzbedarf des Servers? Welche Arten von Daten sollen auf dem Server verarbeitet werden? Wie groß ist das zu erwartende Datenvolumen auf dem Server? Wie groß ist das über die Internetanbindung zu erwartende Datenübertragungsvolumen? In welchem Ausmaß wird sich das Datenvolumen im Zeitraum x voraussichtlich ändern? Wie hoch soll die Verfügbarkeit des Systems sein? Wie schnell muss das System nach einem Ausfall wiederhergestellt sein? Wie sollen die Daten des Servers gesichert werden? Sind regulatorische Vorgaben einzuhalten (z. B. PCI DSS bei der Verarbeitung von Kreditkartendaten)? Besondere Anforderungen Risiko-Management Aus der vorstehenden Liste können sich besondere bzw. erhöhte Anforderungen an ein System ergeben, beispielsweise hinsichtlich der Verfügbarkeit. Soll die Erreichbarkeit eines Servers weder durch geplante (Wartung) noch durch ungeplante Ereignisse (Angriff, Defekt, Fehler etc.) beeinträchtigt werden, kommt man nicht umhin, besondere Vorkehrungen zu treffen und mit technischen Mitteln Redundanz herzustellen. Solche erhöhten Anforderungen bestehen insbesondere bei kommerziell genutzten Systemen. Eine Firma beispielsweise kann sich heutzutage kaum mehr den Ausfall ihres Mailservers erlauben. In Abhängigkeit von der gewünschten Verfügbarkeit kann dies auf verschiedene Arten realisiert werden. Um Ereignisse wie Stromausfall oder den Ausfall einer Netzwerkverbindung aufzufangen, reicht ein Server mit doppelten Netzteilen und zwei Netzwerkkarten. Die Netzteile müssen dann allerdings auch an getrennte Stromversorgungen angeschlossen werden, was einen erhöhten Aufwand nicht nur für den Server, sondern auch für die Infrastruktur bedeutet, in der der Server betrieben werden soll. Dasselbe gilt für eine redundante Netzwerkanbindung. Eine Netzwerkkarte allein reicht nicht, um Redundanz herzustellen, das würde nur den Ausfall der anderen Netzwerkkarte im Server ausgleichen. In der Regel werden redundante Netzwerkanbindungen verwendet, um Fehler in der gesamten Netzwerkinfrastruktur aufzufangen. Das bedeutet, dass eben diese Infrastruktur auch redundant aufgebaut sein muss, von allen lokal verwendeten Netzwerkgeräten (Switch, Hub, Router, Gateway etc.) bis hin zur Internetanbindung. 15

9 1 Zielsetzung und Planung Vor dem Hintergrund, dass das Herbeiführen einer größtmöglichen Redundanz, die alle erdenklichen Ereignisse abdeckt, nahezu unmöglich ist, da die Kosten dafür sehr schnell in einen unwirtschaftlichen Bereich steigen, sollte vor dem Formulieren von Maßnahmen für besondere Anforderungen immer erst eine Risikoabschätzung durchgeführt werden. Im professionellen Umfeld eines Information Security Management Systems (ISMS), das durch die ISO-Norm beschrieben wird und auf das im Laufe des Buches noch häufiger verwiesen wird, wird dieser Prozess als Risiko-Management bezeichnet und stellt die Grundlage aller Maßnahmen dar, mit denen Informationssicherheit gewährleistet werden soll. Die grundsätzliche Idee eines Risiko-Managements ist, dass wirkungsvolle Maßnahmen zur Vermeidung oder Minimierung von Risiken nur dann möglich sind, wenn die entsprechenden Risiken bekannt sind. Daher steht am Anfang eines Risiko-Managements das Erfassen möglicher Risiken. Die im Rahmen dieser Erfassung betrachteten Risiken müssen natürlich in einem Zusammenhang mit den zu betrachtenden Systemen und den damit verbundenen relevanten Prozessen stehen. Für einen geschäftlich genutzten Server wären dies in erster Linie die Geschäftsprozesse, die auf das Funktionieren des Servers angewiesen sind. Dient ein Webserver z. B. nur dazu, um die Website einer Firma auszuspielen, ohne dass über diese Website E-Commerce läuft oder anderweitig direkter Umsatz generiert wird, ist der Ausfall des Servers zwar ärgerlich, weil (potentielle) Kunden für die Zeit des Ausfalls keine Möglichkeit zum Zugriff auf benötigte Informationen haben. Fällt hingegen ein Webserver aus, auf dem ein Online-Shop läuft, hat das unmittelbare finanzielle Auswirkungen. Mögliche zu betrachtende Risiken, die für einen Server im Internet unabhängig von seiner Wichtigkeit für Geschäftsprozesse bestehen, sind beispielsweise Angriffe auf Netzwerk- oder Applikationsebene. Geeignete Maßnahmen zur Behandlung dieser Risiken wären eine zeitgemäße Härtung des Systems und die Verwendung sicherer Applikationen. Im Bereich der Verfügbarkeit eines Systems bestehen zahlreiche Risiken, die zu einer Nichtverfügbarkeit des Servers und damit der von diesem Server angebotenen Dienste führen können: Stromausfall Ausfall der Internetanbindung Hardwaredefekt Ausfall des Rechenzentrums Softwarefehler 16

10 Planung 1.1 Fehlbedienung etc. Eine rein technische Betrachtungsweise dieser Risiken würde leicht zu Gegenmaßnahmen führen, die zwar effektiv, vermutlich aber nicht besonders effizient sind. Effizienz drückt sich beim Risiko-Management dadurch aus, dass die Ausgaben für Maßnahmen gegenüber dem wirtschaftlichen Schaden, der sich aus den Risiken ergeben kann, abgewogen werden müssen. Das bedeutet, dass zum einen die Wahrscheinlichkeit eines Risikos und zum anderen die möglichen finanziellen Auswirkungen betrachtet werden müssen, die durch den Eintritt des Risikos entstehen können. Dieser Betrachtung müssen die Kosten für die Behandlung des Risikos gegenübergestellt werden. Es gibt vier Möglichkeiten, ein Risiko angemessen zu behandeln: geeignete Maßnahmen treffen, um das Risiko zu minimieren das Risiko akzeptieren das Risiko vermeiden die Verantwortung an Dritte übertragen Der Ausfall einer Festplatte z. B. kommt statistisch gesehen wahrscheinlich häufiger vor als der Brand in einem Rechenzentrum. Aus diesem Grund ist es empfehlenswert, einen Server mit einem RAID-System zu betreiben, so dass der Ausfall einer Festplatte nicht zum Ausfall des gesamten Servers führt. Hinzu kommt, dass die Kosten für ein RAID-System heutzutage zu vernachlässigen sind. Ergo: Eine kostengünstige, effiziente Risikobehandlung durch Einführung einer geeigneten Maßnahme. Ist die Wichtigkeit des Servers nicht so hoch, dass die Verwendung eines RAID- Systems notwendig ist z. B. weil der Server nur als Testsystem verwendet wird, dessen Ausfall keine Auswirkungen auf den Geschäftsbetrieb hätte, kann das Risiko des Festplattenausfalls akzeptiert werden. Das bedeutet, dass der Server ohne RAID-System verwendet wird und im Fall eines Festplattendefektes das System neu eingerichtet wird. Für die dritte Möglichkeit, das Vermeiden eines Risikos, lässt sich im Zusammenhang mit dem Festplattenschaden keine Analogie finden, denn ein Server, der zur Risikominimierung ohne Festplatte betrieben wird, ist kaum praktikabel. Ein passendes Beispiel ist jedoch das Risiko eines Ausfalls durch Fehlbedienung. Eine Fehlbedienung kann z. B. vorliegen, wenn ein Benutzer dauerhaft mit Root-Rechten arbeitet. Um dieses Risiko zu vermeiden, kann das Arbeiten mit solchen Rechten durch entsprechende Vorgaben und Richtlinien verboten werden. 17

11 1 Zielsetzung und Planung Nicht jedes Risiko kann minimiert, vermieden oder akzeptiert werden. In einem solchen Fall besteht die angemessene Behandlung darin, das Risiko an Dritte zu übertragen. Dies kann durch Abschließen einer Versicherung geschehen, mit der die finanziellen Auswirkungen eines Ereignisses minimiert werden, oder durch Abschließen geeigneter Service Level Agreements z. B. mit dem Provider, bei dem das System gehostet wird. Ein Risiko-Management versetzt Sie in die Lage, einen objektiven Überblick über notwendige Maßnahmen zu bekommen, die für den sicheren Betrieb eines Servers (oder einer Infrastruktur) notwendig sind. Denn eins ist sicher: Fragen Sie einen Administrator nach Maßnahmen zur Behandlung eines Risikos, werden Sie mit sehr hoher Wahrscheinlichkeit als Antwort eine technisch brillante Lösung bekommen, die aber kaum zu finanzieren ist. Fragen Sie hingegen Ihren Controller, wird Ihnen dieser eine finanziell überaus attraktive Lösung anbieten, die aber technisch vollkommen ungeeignet ist. Ein konsequent durchgeführtes Risiko- Management vereint beide Positionen die klassische Win-win-Situation. 1.2 Serverhardware In den letzten Jahren ist die Hardwareunterstützung von Linux so gut geworden, dass es bei Verwendung gängiger Hardware kaum noch Probleme gibt, Linux ans Laufen zu bringen. Probleme bereiten vereinzelt noch Multimediageräte oder Beschleunigerfunktionen von Grafikkarten, wohingegen sich die Beschaffung von Hardware für den Servereinsatz nicht mehr als sehr schwierig erweist. Es gibt zahlreiche Datenbanken im Netz, bei denen man sich zum Teil distributionsspezifisch über die Unterstützung von Hardware durch Linux informieren kann. Einige der bekannten Hardwaredatenbanken sind die folgenden: URL Distribution Novell Ubuntu opensuse Debian Tabelle 1.1 Hardwaredatenbanken im Internet 18

12 Ein kleiner Rundgang durch Linux Zertifizierte Hard- und Software Abschnitt 1.3,»Ein kleiner Rundgang durch Linux«, enthält einige Tipps und Hinweise zur Auswahl einer geeigneten Linux-Distribution für den eigenen Server. Es kann allerdings sein, dass man sich als Benutzer die zum Einsatz kommende Distribution nicht immer aussuchen kann. Viele Hosting-Provider bieten beispielsweise nur einige wenige Distributionen an, häufig Debian und opensuse. In einem solchen Fall fällt die Wahl nicht schwer, letzten Endes kann der persönliche Geschmack entscheiden. Schwieriger wird es, wenn die einzusetzende Soft- oder Hardware eine konkrete Distribution voraussetzt. Bestimmte Hardwarehersteller leisten beispielsweise nur dann Support im Rahmen eines Wartungsvertrages, wenn ein für die betreffende Hardware zertifiziertes Betriebssystem eingesetzt wird. Falls Sie also planen, Serverhardware einzusetzen, für die ein Wartungsvertrag abgeschlossen werden soll, sollten Sie genau prüfen, ob dieser Wartungsvertrag vom eingesetzten Betriebssystem abhängig ist. Für die Distribution Ubuntu finden Sie eine Liste der zertifizierten Hardware auf der Webseite Dimensionierung des Servers Computerhardware ist heutzutage so leistungsfähig geworden, dass es sich für einen dedizierten Server kaum mehr lohnt, umfangreiche Planungen zur Dimensionierung der Hardware anzustellen. Desktop-PCs kommen mittlerweile mit Mehrfachkern-Prozessoren und Festplatten in Terabyte-Größe daher, und selbst Notebooks vom Lebensmitteldiscounter verfügen über eine RAM-Ausstattung, die vor wenigen Jahren noch so manchen Serveradministrator vor Neid hätte erblassen lassen. Lenken Sie Ihr Augenmerk daher weniger auf die Leistungsparameter als auf Punkte wie einfache Wartbarkeit, Hotplug-Festplatten und ausreichend Platz für zusätzliche Hardware (RAID-Controller, Festplatten, Speichererweiterungen etc.). 1.3 Ein kleiner Rundgang durch Linux Die Geschichte von Linux beginnt 1991 in Finnland, wo sich der mittlerweile hinlänglich bekannte Student Linus Torvalds zum privaten Gebrauch eine Terminalemulation für den Zugriff auf das Netzwerk der Universität programmierte. Zunächst als Fingerübung zum Kennenlernen seiner neuen Hardware (Intel 386) 19

13 1 Zielsetzung und Planung gedacht, entwickelte sich aus dem Terminalprogramm immer mehr ein eigenes Betriebssystem. Um seine Entwicklung anderen Studenten zugänglich zu machen, veröffentlichte Torvalds am in der Usenet-Gruppe comp.os.minix das folgende legendäre Posting: Hello everybody out there using minix - I m doing a (free) operating system (just a hobby, won t be big and professional like gnu) for 386(486) AT clones. This has been brewing since april, and is starting to get ready. I d like any feedback on things people like/dislike in minix, as my OS resembles it somewhat (same physical layout of the file-system (due to practical reasons) among other things). I ve currently ported bash(1.08) and gcc(1.40), and things seem to work. This implies that I ll get something practical within a few months, and I d like to know what features most people would want. Any suggestions are welcome, but I won t promise I ll implement them :-) Linus (torva...@kruuna.helsinki.fi) PS. Yes it s free of any minix code, and it has a multi-threaded fs. It is NOT protable (uses 386 task switching etc), and it probably never will support anything other than AT-harddisks, as that s all I have :-(. Die Vision am Ende des Postings (»not protable«(sic!) und»keine Unterstützung von anderen als AT-Festplatten«) zeigt, dass Torvalds zum damaligen Zeitpunkt genauso wenig Visionär war wie andere Größen der IT. Die Verwendung der Gruppe comp.os.minix und der Verweis darauf, dass sein Projekt keinen Minix-Code enthält, rührt daher, dass damals Minix ein gängiges Lehr-Betriebssystem an Universitäten war. Vom bekannten Professor Andrew S. Tanenbaum entwickelt, war Minix ein Unix-ähnliches Betriebssystem für den Lehrbetrieb Unix Unix, das Urviech unter den Betriebssystemen, wurde Anfang der 70er Jahre von Ken Thompson in den Bell Labs geschrieben. Unics, wie das Betriebssystem zunächst hieß, war Nachfolger bzw. ein naher Verwandter von Multics, einem Betriebssystem für Großrechner, das in den 60er Jahren entwickelt wurde. 20

14 Ein kleiner Rundgang durch Linux 1.3 Ursprünglich in Assembler programmiert und damit so gut wie nicht portabel, wurde Unix kurz nach seinem Erscheinen in der Sprache C neu programmiert. Seither sind Unix und C untrennbar miteinander verbunden. Aus Unix haben sich im Laufe der Zeit viele Derivate abgeleitet, z. B. die verschiedenen BSD- Unices, Mac OS X, Solaris, HP-Unix und AIX. Dass Unix in den 80er Jahren unter eine kommerzielle Lizenz gestellt wurde und seitdem nicht mehr kostenlos erhältlich war, bedeutete insbesondere für den Lehrbetrieb einen großen Rückschritt. Die Folge waren Projekte, mit denen Studenten und Interessierte Zugang zu Unix-ähnlichen Systemen erhalten sollten, wie das Betriebssystem Minix oder auch das GNU-Projekt von Richard Stallmann, ohne das Linux sich nie in dem Maße verbreitet hätte, wie es heute der Fall ist. Als Linus Torvalds sein Linux-Projekt vom Terminalprogramm zum Betriebssystem erweiterte, stand bei der Gestaltung der Benutzerschnittstelle Unix Pate, also die Arbeit mit einer Shell, die Verwendung und Verkettung kleiner, spezialisierter Tools zu komplexen Werkzeugen und später dann die grafische Oberfläche X. Zahlreiche Unix-Tools wurden und werden durch das GNU-Projekt portiert oder neu implementiert, so dass Linux sehr schnell wie ein echtes Unix aussah. Dabei ist es aber wichtig, zu wissen, dass nur solche Betriebssysteme den Namen Unix tragen (dürfen), deren Codebasis sich direkt auf das Ur-Unix zurückführen lässt. Linux hat keine gemeinsame Codebasis mit Unix, sondern wurde von Unix unabhängig komplett eigenständig programmiert und ist daher kein Unix. Bekannt ist in diesem Zusammenhang der von der Firma SCO angezettelte siebenjährige Rechtsstreit, mit dem bewiesen werden sollte, dass Linux unrechtmäßig Unix- Quellcode enthält, an denen SCO die Rechte hält. Der Prozess ist zu Ungunsten von SCO eingestellt worden Linux ist Unix-frei Linux Linux war anfangs lediglich ein für den Endanwender eher uninteressanter Betriebssystemkern, der die Funktionen eines Betriebssystems erfüllte, also insbesondere die Kommunikation mit der Rechnerhardware erledigte, aber auch nicht mehr. Mit dem von Torvalds zur Freigabe bereits portierten Compiler und der Bash konnte man sich zwar eigene Programme übersetzen, all das, was man heute unter Linux versteht, war aber noch Zukunftsmusik. Daher entwickelten sich sehr schnell so genannte Linux-Distributionen. Eine Linux-Distribution fasst den Betriebssystemkern, also Linux, mit einer mehr oder weniger großen Zahl von Anwendungsprogrammen und Werkzeugen zusammen. Der Anwender muss sich seine Programme also nicht selber besor- 21

15 1 Zielsetzung und Planung gen oder programmieren, sondern er installiert sich eine Linux-Distribution und hat damit einen arbeitsfähigen Rechner. Eine der gängigen Linux-Distributionen entspricht dem Lieferumfang eines Betriebssystems wie Windows oder Mac OS X. Programme, wie z. B. Shells, X, Browser, Mail-Clients und Server-Daemons sind Bestandteil einer Linux-Distribution und haben mit dem Linux-Kernel selber nichts zu tun. Sehr schnell wurde die Bezeichnung Linux als Synonym für Linux-Distributionen verwendet, und wenn die Rede von Linux ist, ist in der Regel eine Linux-Distribution gemeint. Da Linux-Distributionen zu großen Teilen GNU-Software enthalten, wurde insbesondere von Richard Stallmann die Bezeichnung GNU/Linux favorisiert. Die in diesem Buch verwendete Bezeichnung entspricht der von Linus Torvalds favorisierten: Linux sowohl für den Kernel als auch für eine Distribution. Der Linux-Kernel unterliegt der GNU General Public License und ist damit Open Source. Die Kontrolle über Veränderungen an der offiziellen Kernelversion, stets erhältlich unter liegt bei Linus Torvalds. Durch die Quelloffenheit steht es jedem frei, eigene Veränderungen am Kernel vorzunehmen, die dann unter Umständen nicht in den offiziellen Kernel einfließen. Distributoren passen den Kernel häufig für ihre Distributionen an. So hat SuSE als erster großer Distributor das ReiserFS-Dateisystem in den SuSE-Kernel integriert, bevor es in den offiziellen Kernel aufgenommen wurde. Die Nummerierung des Kernels folgte eine Zeitlang dem Schema, dass die offiziell freigegebene Version eine gerade Nummer hatte, z. B. 1.2, und die nächste Entwicklerversion eine ungerade, also 1.3. Seit dem Kernel 2.6 ist diese Art der Nummerierung aufgehoben, und es lässt sich aus der Versionsnummer keine tiefergehende Information mehr auslesen. Bei der Verwendung einer fertigen Distribution ist die Auseinandersetzung mit dem Kernel ohnehin selten vonnöten. Insbesondere ist die Verwendung des offiziellen Kernels von nur selten notwendig und verursacht stets eine Menge Handarbeit, um notwendige Anpassungen an die jeweilige Distribution durchzuführen. Mindestens muss der Sourcecode des Kernels geladen und die Konfiguration des Kernels durchgeführt werden, bevor der Kernel dann kompiliert werden kann. Kommt man bei der Verwendung von Linux in Bereiche, in denen der offizielle Kernel dem jeweiligen Distributionskernel vorzuziehen ist, sollte man von der Verwendung einer vorgefertigten Distribution ohnehin Abstand nehmen. Parallel mit dem Kernel entstanden zahlreiche Linux-Distributionen. Die Zahl geht mittlerweile in die Hunderte. Abbildung 1.1 zeigt die Entwicklung der größ- 22

16 Die richtige Distribution 1.4 ten Distributionen parallel zum Kernel und die Vererbung unter den verschiedenen Distributionen. Abbildung 1.1 Entwicklung von Kernel und großen Distributionen 1.4 Die richtige Distribution Es gibt mittlerweile eine nahezu unüberschaubare Anzahl von Linux-Distributionen. Die Website eine Seite mit Rankings und Informationen zu verschiedenen Linux-Distributionen, ist eine gute Informationsquelle. Die große Anzahl der Distributionen rührt daher, dass es verschiedene Distributionen für spezielle Einsatzgebiete gibt. Für einen Server, der nicht nur zum Ausprobieren einer Linux-Distribution betrieben werden soll, empfiehlt es sich, eine der»großen«distributionen zu verwenden. Distrowatch führt diese als»major Distributions«in einer Top-Ten-Liste

17 Index A a2enmod 179 Abhängigkeiten 363 Absicherung 291 ACCEPT 117 AccessFileName 160 ACK 116 AdBlock Plus 396 Adium 300 AIX 14 alias 91 Allow 162 AllowOverride 163, 173, 225 AMD IOMMU 418 AMD64 59 Änderungsverwaltung 142 Angriff 15 Apache 146, 148, 281 APACHE_OPTS 369 apachetop 402 APT 70, 474 apt-get 73, 75, 474 autoclean 75 autoremove 75 check 75 clean 75 dist-upgrade 75 install 75 purge 75 remove 75 source 75 update 75 upgrade 75 ARP-Cache 432 AT&T-Unix 96 atime 41 Atomicity 261 Ausfall 15 Ausfallzeit 416 Auswahl 29 auth 439 auto_failback 444 Autojoin 432 B backports 71 Backup 254 badblocks 49 Bash 88 Basic Regular Expression 179 bcast 436 Benutzer 87 Benutzerdaten 34 Berechtigungen 111 Betriebssystem 217 blkid 50 Blockdevice 446 Blockgröße 37 Bochs 417 BSD 14 BSI 479 C CA 64, 189 CAcert 309 Cache 224 Cacti 350 Catalina 286 CERT 486 cfg_dir 370 cfgmaker 347 CFLAGS 67, 80 CGI 175 Chain 117 ChallengeResponseAuthentication 84 Chat 292 chmod 93 chown 113 chroot 329 Citrix 417 Cluster 430 Cluster-IP 432 com2sec 336 commercial 72 common 449 Common Name 190 Community-String

18 Index comp.os.minix 20 compression 438 compression_threshold 438 Consistency 261 console 426 Contacts 376 CRITICAL 363 ctime 41 D Dateigröße 41 Dateisystem 35, 37, 38, 50 Datenbanksicherheit 245 Datenblock 44 Datensicherheit 458 Datenübertragungsvolumen 15 Datenvolumen 15 deadtime 438 Debian 18, 19, 24, 32 debootstrap 423 debugfs 49 DefaultType 162 Defekt 15 degr-wfc-timeout 452 Deny 162 Denyhosts 138 depend 102 destination port 118 DFN 64 Dimensionierung 19 Distribution 23 Distrowatch 23 DNS 225 DNS-Zugriff 225 DocumentRoot 38, 172 Dokumentation 141 Dom0 420 Domain0 420 DomainU 420 Domäne 420 DomU 420, 427 dpkg 76, 480 DRBD 446 drbdadmn 454 drbddisk 457 DROP 117 dumpe2fs 45, 49 Durability 262 E e2fsck 45, 49 e2fsprogs 49 e2fsprogs 49 e2image 50 e2label 50 ebuilds 78 EDITOR 91 Ejabberd 295, 299, 306, 312, 316 ELF 30 EMC 417 emerge 481 equery 482 Erreichbarkeit 361 ErrorLog 164 Exabyte 51 export 91 ext2 39 ext3 39 ext4 39, 50 Extend 51 F Fail2ban 135 Failback 444 Fedora 24 Fehler 15 Feintuning 69 Festplatten 19, 49 Festplatten-I/O 223 FHS 33 filefrag 50 Fileserver 44, 95 Filesystem Hierarchy Standard 33 FILTER 117 find 112 findfs 50 Firefox 396 Firewall Builder 121 Forking 149, 150 FORWARD 117 FQDN 190 Fragmentierung 48 FreeBSD 13 fsck.ext2 49 e2fsprogs 49 fsck.ext

19 Index FTP 362 FTPS 315 Full Mode 48 fwbuilder 121 G Gast 418 genkernel 447 Gentoo 24, 27, 31, 60, 80 gentoolkit 482 GET 334 GETBULK 334 GETNEXT 334 GID 41 global 449 GNU Privacy Guard 61 GNU/Linux 14 GNU-Tools 14 Google Analytics 396 GPG 61 Gratuitous ARP 432 groupadd 88 Guest 418 Güte 361 Gutsy 71 H Hard State Change 380 Hardlinks 41, 42 Hardware 18, 217 Hardware-RAID 54 Hardy 71, 422 Härtung 228 Härtungsmaßnahmen 143 Hash 61 Heap 30 Heartbeat 430 Heartbeat2 434 HISTSIZE 91 Hochverfügbarkeit 415 Host 362, 418 virtueller 170 HostbasedAuthentication 84 Host-Firewall 115 Hostgroup 375 HostnameLookups 163 HP-UX 14 HTTP 119, 229 HTTP_PROXY 91 HTTPS 119 I IA64 59 id 88 IDS-System 132, 143 IgnoreRhosts 84 Image-Datei 62 Indexes 173 Indexmaker 342 Informationssicherheit 16 Init 96 initdead 438 Inode 41 INPUT 117 Installation 33, 60 Intel VT 418 Intrusion-Detection 132 Inventur 96 iostat 405, 406 iptables 116, 117 IRIX 40 ISMS 16 ISO ISO ISO , 488 ISO Isolation 262 IVW 395 J Jabber 292, 362 Java 282 JFS 40 Journal 38, 47 Journaling 38 K Kapazität 57 KDE 27 KeepAlive 156, 437 KeepAliveTimeout 156 Kernel 22 Kernel-Update 416,

20 Index Keyserver 64 Knoppix 24 Konfiguration 33 Kryptographie 196 Kubuntu 27 L LAMP 145 Landscape 460 Lebenszyklus 37 libc 30 Linus 19 Linux 21 Linux Standard Base 30 Linux-HA 430 Linux-Kernel 40 Listen 169, 171 LockFile 155 Logdatei 34 logfacility 436 LogFormat 164 Logging 180 Logical Volume Managers 36 Logstrom 396 LSB 30 LTS 25 LVM 36, 37, 447 lwp-request 181 M Mac OS X 14 Mailversand 312 Main 72 Maintainer 62 Mandriva 24 MANGLE 117 Manpage 38 MaxKeepAliveRequests 156 MaxRequestsPerChild 158 MaxSpareServers 157 MaxSpareThreads 159 md5 439 Metadaten 42 Meta-Distribution 27 Metapakete 76 Metasploit 478 Metazeichen 184 mfks.ext3 45 MIB 334 MIB Browser 336 Microsoft 417 Minix 20, 39 MinSpareServers 157 MinSpareThreads 159 mirror 424 Mirroring 56 mke2fs 49 mkfs.ext2 50 mkfs.ext3 50 mklost+found 50 mod_jk 284 mod_rewrite 178 mod_ssl 187 Module 178 Monitoring 36, 142, 333 moo 70 Moore, H. D. 478 MRTG 333, 340 mtime 41 Multics 20 Multithreading 149, 150 Multiverse 72 MySQL 201, 231 mytop 404 N Nagios 333, 360 nagios_group 370 nagios_user 370 NameVirtualHost 171 NAS 446 NAT 117 NCSA 147 Netcraft 147 netstat 111 Netzwerkdienste 110 Netzwerkproblem 422 Neustart 416 nmap 116 Node 431 node 436 Novell 18 Novell SUSE 24 NRPE 361,