Auf einen Blick 1 Einführung... 15 2 Erste Schritte... 29 3 Wichtige Serverdienste... 115 4 Verwaltung und Administration... 241 5 Server absichern... 325 6 Vserver für Linux... 391 7 Der eigene Server... 405 8 Bürokratisches... 415 A Anhang... 440
Inhalt 1 Einführung 15 1.1 Vorwort... 15 1.1.1 Danksagung... 16 1.2 Arbeitsvoraussetzungen... 16 1.3 Historie zu UNIX, BSD und Linux... 17 1.3.1 Bemühungen zur Standardisierung von UNIX... 17 1.3.2 Entwicklung freier UNIX-Derivate... 18 1.4 Welches System ist für mich das richtige?... 20 1.4.1 Vor- und Nachteile der verschiedenen Systeme... 20 1.4.2 Wartung und Pflege... 21 1.4.3 Saubere Installation... 22 1.4.4 Hardware-Unterstützung... 23 1.4.5 Dokumentation, Mailinglisten und Support... 23 1.4.6 Notfallsystem... 24 1.4.7 Resümee... 25 1.4.8 Bezugsmöglichkeiten... 26 2 Erste Schritte 29 2.1 Vorbereitungen und Hinweise zur Installation... 29 2.1.1 Hinweise zu benötigten Partitionen... 29 2.1.2 Das richtige Filesystem... 31 2.1.3 Installation von Debian 3.0r1... 32 2.1.4 Alternativen zu dselect für die Installation offizieller Debian-Pakete... 36 2.1.5 Installation von SuSE 8.1... 38 2.1.6 Red Hat... 40 2.1.7 RPM die Paketverwaltung von Red Hat und SuSE... 44 2.1.8 OpenBSD... 45 2.1.9 So helfen Sie lahmen IDE-Festplatten auf die Sprünge (DMA-Modus)... 48 2.2 Einführung in die UNIX-Welt... 49 2.3 Wichtige Systemprogramme in der Übersicht... 51 2.3.1 Crashkurs-Grundbefehle (cd, ls, mkdir, rm, cp, mv, cat, tail, head und echo)... 52 2.3.2 Dateigrößen und Zahlensysteme... 56 2.3.3 Die Editoren vi(m) und pico... 57 Inhalt 5
2.3.4 Das Einmaleins der administrativen Befehle (su, find, locate, grep, ps, top, kill, du)... 61 2.3.5 Hard- und Softlinks (ln)... 69 2.3.6 Informationen zu Logins (finger, lastlog)... 71 2.3.7 Netstat kennt alle lauschenden und kommunizierenden Prozesse... 72 2.3.8 Partitionen richtig mounten (mount, umount)... 73 2.3.9 Das UNIX-Rechtesystem (chmod, chown, chgrp)... 75 2.3.10 User-Verwaltung (useradd, userdel, usermod, groupadd, groupdel)... 79 2.3.11 sudo... 81 2.4 Shell-Crashkurs... 82 2.4.1 Automatische Dateinamenerweiterung... 82 2.4.2 Befehlshistorie... 83 2.4.3 Cursor-Befehle... 84 2.4.4 Umleitung von Ein- und Ausgabe... 84 2.4.5 Ausführung als Hintergrundprozess... 86 2.4.6 Befehlsverknüpfungen... 87 2.4.7 Setzen von Umgebungsvariablen... 88 2.4.8 Definition von Aliasen für Befehle... 88 2.5 Der Bootloader... 89 2.5.1 LILO Generic Bootloader for Linux... 89 2.5.2 Boot (OpenBSD) und Bootable-Flag (fdisk)... 91 2.6 Netzwerkeinstellungen und Konfiguration... 92 2.6.1 Konfiguration eines Netzwerk-Interface unter Linux... 93 2.6.2 Konfiguration eines Netzwerk-Interface unter OpenBSD... 96 2.6.3 Konfiguration eines Nameservers (unter Linux und OpenBSD).. 98 2.7 Manuelles Installieren (Kompilieren) von Programmen... 98 2.7.1 Sollen Installationspfade angepasst werden?... 99 2.7.2 Sicherheitsaspekte... 101 2.7.3 Überprüfen der Vertrauenswürdigkeit von Programmpaketen... 101 2.7.4 Deinstallation... 103 2.8 Startskripte... 104 2.8.1 Linux... 104 2.8.2 OpenBSD... 106 2.9 Der eigene Kernel... 106 2.9.1 Linux... 107 2.9.2 OpenBSD... 111 3 Wichtige Serverdienste 115 3.1 OpenSSH... 115 3.1.1 Konfiguration... 115 3.1.2 Betrieb... 118 3.1.3 User-Home-Verzeichnis chrooten... 120 6 Inhalt
3.2 Domain Name Server System... 123 3.2.1 Grundkonfiguration... 125 3.2.2 Testlauf... 127 3.2.3 Bind im harten Server-Einsatz... 128 3.2.4 Domains registrieren und KK-Anträge... 131 3.2.5 Wann lohnt sich der eigene Nameserver?... 132 3.3 Apache... 133 3.3.1 Installation... 135 3.3.2 Grundkonfiguration... 141 3.3.3 Default Server und virtuelle Hosts... 144 3.3.4 Verzeichnis- und Datei-Optionen... 145 3.3.5 Hostbasierter Zugriffsschutz... 153 3.3.6 User-spezifischer Zugriffsschutz... 153 3.3.7 Secure Socket Layer... 156 3.3.8 Anpassung von serverseitigen Fehlermeldungen... 159 3.3.9 Logfile-Erstellung und -Auswertung... 160 3.3.10 PHP... 169 3.3.11 CGI für Perl, PHP, Python und Co.... 174 3.3.12 Apache enthält Sicherheitslücken!... 179 3.4 Tomcat... 180 3.4.1 Installation... 181 3.4.2 Grundkonfiguration... 183 3.4.3 Absicherung von Tomcat... 185 3.4.4 Tomcat-Seiten über Apache ausliefern... 187 3.5 MySQL... 188 3.5.1 Absicherung... 189 3.5.2 Administration... 190 3.5.3 Logging... 195 3.5.4 phpmyadmin... 196 3.6 Mailserver... 197 3.6.1 Postfix... 198 3.6.2 Courier-IMAP... 221 3.6.3 Das PHP-WebInterface-SquirrelMail... 224 3.7 FTP-Server... 225 3.7.1 Installation von ProFTPD mit MySQL-Support... 226 3.7.2 Konfiguration von ProFTPD... 227 3.7.3 Vorbereiten der MySQL-Datenbank... 232 3.7.4 Erzeugen von FTP-Accounts... 232 3.7.5 Testen der FTP-Installation... 234 3.7.6 Fehlerteufel... 234 3.7.7 Freischalten eines FTP-Zugangs mit Einmalpasswörtern über Perl... 235 3.7.8 Traffic-Auswertung... 236 3.7.9 xferlog... 238 Inhalt 7
4 Verwaltung und Administration 241 4.1 Automatische Jobsteuerung... 241 4.1.1 Cron-Jobs... 242 4.2 Syslogd... 244 4.2.1 Ein einfaches Beispiel... 245 4.2.2 Das Priority-Konzept... 246 4.2.3 Kombinationen von Facility und Priority in der Praxis... 247 4.2.4 Zugriffsrechte der Logdateien... 249 4.3 Logfiles verwalten... 249 4.3.1 Logrotate (Linux)... 250 4.3.2 Newsyslog (OpenBSD)... 252 4.3.3 Archivierte Logfiles mit mpack versenden... 253 4.4 Systemzeit... 254 4.4.1 Automatisierte Korrektur der Systemzeit... 254 4.5 Systemüberwachung... 255 4.5.1 Traffic-Analyse... 256 4.5.2 Überwachung von CPU, Load, RAM und verfügbarer Bandbreite... 259 4.6 Speicherplatz mit Quotas beschränken... 269 4.6.1 Partition für Quotas vorbereiten... 270 4.6.2 Quotas erstellen und verwalten... 270 4.6.3 Quotas im Betrieb: Übersicht und automatisierte Infomails... 271 4.7 Automation... 272 4.7.1 Einführung in die Shell-Programmierung... 273 4.7.2 Einführung in die Perl-Programmierung... 280 4.7.3 Abschließende Anmerkungen und Skriptübersicht... 294 4.8 Backup... 295 4.8.1 Welche Daten sind zu sichern?... 295 4.8.2 Wie häufig ist zu sichern?... 296 4.8.3 Wohin ist zu sichern?... 296 4.8.4 Womit ist zu sichern?... 297 4.8.5 Backup der Nutzdaten mit rsync... 298 4.8.6 Voll-Backup mit tar... 300 4.9 Stress-Tests... 302 4.9.1 Mit Stress Arbeitsspeicher entziehen und CPU/Load-Belastung erhöhen... 303 4.9.2 Apache under Siege... 304 4.10 Ressourcen beschränken... 305 4.10.1 Ressourcen unter Linux über PAM nutzerbezogen beschränken 306 4.10.2 Ressourcen unter OpenBSD nutzerbezogen einschränken... 307 4.11 Loadbalancing... 308 4.12 Hochverfügbarkeit... 309 8 Inhalt
4.13 Festplatte prüfen... 311 4.13.1 Debian und SuSE zur Reparatur Read-Only starten... 312 4.13.2 Read-Only-Start von Red Hat und OpenBSD?... 313 4.13.3 S.M.A.R.T... 313 4.14 Das Rettungssystem... 314 4.14.1 Ein Linux-Rettungssystem auf CD-ROM... 315 4.15 Raid-Systeme... 318 4.16 Vorstellung verschiedener Admintools... 319 5 Server absichern 325 5.1 Vorbemerkung... 325 5.2 Einspielen von Security-Updates... 326 5.3 Paketfilter... 331 5.3.1 TCP... 332 5.3.2 UDP... 332 5.3.3 ICMP... 332 5.3.4 Vorgehensweise... 333 5.3.5 Syntax und Definition von Regeln... 334 5.3.6 Logging zur Regelerstellung nutzen... 337 5.3.7 SSH... 339 5.3.8 http(s)... 340 5.3.9 FTP... 341 5.3.10 Mailserver... 344 5.3.11 auth/ident... 345 5.3.12 DNS... 345 5.3.13 Timeserver... 347 5.3.14 Fragmentation Needed and Don't Fragment was Set... 347 5.3.15 Ping... 348 5.3.16 Parameter Problem... 349 5.3.17 Unsinnige Pakete verwerfen... 349 5.3.18 Welche Pakete sollten geloggt werden?... 350 5.3.19 Paketfilter-Regeln nach dem Booten automatisiert laden... 351 5.4 Systrace... 351 5.4.1 Installation... 352 5.4.2 Regelerstellung und Betrieb... 353 5.4.3 Stolperfallen... 356 5.4.4 Logging... 356 5.5 Chroot... 357 5.5.1 Chroot als Admintool... 358 5.6 Feinabstimmung... 358 5.6.1 Inetd abschalten... 358 5.6.2 Der TCP-Wrapper... 359 5.6.3 Zugriffsrechte... 359 5.6.4 Bastille und harden-suse... 360 5.6.5 Informationen zu /proc, insmod und dem Ptrace-Bug (Linux)... 361 Inhalt 9
5.7 Nessus... 362 5.7.1 Vorbereitungen... 363 5.7.2 Nutzung... 363 5.7.3 Fehlalarm ist keine Seltenheit... 365 5.8 nmap... 365 5.8.1 Die wichtigsten Funktionen... 366 5.9 Portscans erkennen... 367 5.10 Integritätsprüfung mit AIDE... 368 5.10.1 Vorbereitungen Initialisieren und Erstellen der AIDE-Datenbank... 368 5.10.2 Überprüfung der Systemintegrität... 370 5.10.3 Sicherheitshinweise... 371 5.11 Das Intrusion-Detection-System Snort... 372 5.11.1 Installation und Aktualisierungen... 372 5.11.2 Betrieb... 373 5.12 Absichern von Logfiles... 374 5.12.1 Automatisierte Sicherung über ssh... 375 5.12.2 Automatisierte Sicherung per E-Mail... 375 5.13 Logfile-Analyse... 376 5.13.1 Automatisierte Warnmeldungen via Logsurfer... 376 5.13.2 Analyseberichte mit Logcheck erstellen... 382 5.14 Sicherheitsinformationen beziehen... 385 5.15 Verhalten beim Supergau... 385 5.15.1 Rechtliche Maßnahmen?... 387 6 Vserver für Linux 391 6.1 Sinn und Zweck... 391 6.2 Installation... 393 6.3 Einrichten einer virtuellen Umgebung... 393 6.3.1 Programme des Basis-Systems parallel in Vserver-Umgebungen betreiben... 396 6.3.2 Verwenden und Optimieren von Vserver-Umgebungen... 397 6.3.3 Bind... 399 6.3.4 Systemneustart innerhalb einer Vserver-Umgebung... 399 6.3.5 Die v-befehlsversionen... 399 6.3.6 vrpm und vunify für RPM-basierte Vserver... 400 7 Der eigene Server 405 7.1 Wahl des richtigen Vertragspartners... 407 7.2 Vorgehensweise nach Bereitstellung eines Servers... 410 7.2.1 Absicherung eines vom Dienstleister vorinstallierten Systems... 411 10 Inhalt
8 Bürokratisches 415 8.1 Gesetzliche Regelungen für den Betrieb einer Website... 417 8.1.1 Pflichtangaben... 417 8.1.2 Problematik externer Links... 421 8.1.3 Betrieb eines Gästebuchs oder Forums... 422 8.1.4 Newsletter... 423 8.1.5 Das Domain-Recht... 424 8.2 Rechtliche Absicherungen gegenüber Kunden... 425 8.2.1 Inhalte von Internet-Seiten... 426 8.2.2 Registrierung eines Domain-Namens... 427 8.2.3 Pflichten des Kunden... 429 8.2.4 Datenschutzfragen beim Betrieb eines Webservers... 430 8.2.5 Haftungsbeschränkung und technische Einschränkungen... 433 8.2.6 Abschließende Hinweise und Tipps zu AGB... 435 8.2.7 Datenschutz und Logfiles... 435 8.2.8 Vorsicht bei Auskunftsersuchen und Durchsuchungen... 436 8.2.9 Ernennung eines Datenschutzbeauftragten... 437 8.3 Rechtliche Hinweise und Verfahrensfragen zur Registrierung von Domain-Adressen... 437 8.4 Fällt das Datenschutzrecht für den Zwang zur personenbezogenen Vorratsdatenspeicherung?... 439 A Anhang 440 A.1 Glossar... 440 A.2 Bibliografie... 445 A.3 Linkliste... 446 Index 448 Inhalt 11
1 Einführung 1.1 Vorwort... 15 1.2 Arbeitsvoraussetzungen... 16 1.3 Historie zu UNIX, BSD und Linux... 17 1.4 Welches System ist für mich das richtige?... 20 13
1 Einführung Free software is a matter of freedom: people should be free to use software in all the ways that are socially useful. Software differs from material objects such as chairs, sandwiches, and gasoline in that it can be copied and changed much more easily. These possibilities make software as useful as it is; we believe software users should be able to make use of them. (Richard Stallman Free Software Foundation) 1.1 Vorwort Die Vielzahl an unterschiedlichen UNIX-Derivaten macht es unmöglich, auf jedes einzelne System detailliert einzugehen. Dennoch werden Sie das benötigte Wissen erlernen, um exotischere oder kommerzielle UNIX-Derivate als Webserver betreiben zu können. Dies ist möglich, da viele grundsätzliche UNIX-Befehle wie cat, echo oder kill auf jedem System vorhanden sind und die Administration von Apache oder dem Mailserver Postfix ebenfalls überall identisch ist. Davon abgesehen werde ich neben OpenBSD auch auf die wichtigsten Linux- Distributionen Debian, RedHat und SuSE eingehen und gegebenenfalls auf die Besonderheiten bei der Installation der vorgestellten Programme oder beim Einspielen von System-Updates hinweisen. Der Aufbau und Betrieb eines eigenen Webservers ist eine komplexe Thematik und mit hoher Verantwortung verbunden. Schlecht gesicherte Server sind für Angreifer leicht zu finden und ebenso schnell für illegale Attacken gegen andere Rechner zu missbrauchen sowie als FTP-Server für Raubkopien, pornografische Videos oder andere fragwürdige Zwecke. Selbst wenn Ihnen durch den zusätzlichen Datentransfer keine weiteren Gebühren berechnet werden sollten, müssen Sie sich für abgelegte Dateien oder Angriffe verantworten. Sie müssen eventuell sogar vor Gericht schlüssig darlegen, dass Sie selbst Opfer eines Angriffs wurden und Ihr Server von einer dritten Person missbraucht worden ist. Die sichere Konfiguration der einzelnen Dienste Ihres Webservers ist deshalb ein zentrales Thema dieses Buches. Wenn Sie noch keine Erfahrungen mit UNIX-Derivaten sammeln konnten, sollten Sie vor Inbetriebnahme eines eigenen Servers dieses Buch in Ruhe durcharbeiten. Wenn Sie bereits mehr Erfahrung besitzen, sollten Sie bei Zeitdruck zumindest einen Blick in die Kapitel 4, Einführung 15
Verwaltung und Administration, und Kapitel 5, Server absichern, werfen, bevor ihr eigener Server ans Netz geht. Weiterhin ist die Automation von Wartungs- und Überwachungsarbeiten ein wichtiges Thema. Allerdings sind viele Aufgaben nicht ohne rudimentäre Programmierkenntnisse und kleine eigene Skripte lösbar. Deshalb werden Sie ab und zu auf Shell- und Perl-Skripte stoßen, um zum Beispiel automatisiert Statistiken zu erstellen oder FTP-Zugänge freizuschalten. Falls Sie noch keinerlei Programmiererfahrung sammeln konnten, finden Sie im Abschnitt 4.7, Automation, eine Einführung in die Shell- und Perl-Programmierung, die es Ihnen ermöglichen wird, die Beispielskripte geschickt zu kombinieren und für die eigenen Bedürfnisse zu erweitern. Häufig ist es sinnvoll, das Anlegen eines neuen Benutzers mit einem FTP-Account und einer passenden Subdomain für den Apache zu kombinieren. 1.1.1 Danksagung Meine Linux- und BSD-Kenntnisse konnte ich über Man- und Infopages, Howtos, Websites sowie über Mailinglisten, Zeitschriften und aus Büchern erwerben. Insbesondere danke ich dem Java-Programmierer Oliver Rettig (http://www.orat.de) für seine Detailhinweise zu Tomcat und Rechtsanwalt Holger Scheel (http://www.ra-scheel.de) für die Prüfung und Korrekturhinweise zu den Kapiteln 8, 8.1, 8.2 sowie 8.4. Der ProFTPD-Experte Stefan Onken (http://www.proftpd.de) half mir mit einigen hilfreichen E-Mails zum Thema ProFTPD und MySQL auf die Sprünge. 1.2 Arbeitsvoraussetzungen Für realistische Tests sind zwei Computer unerlässlich, nämlich ein Rechner mit Pentium-Prozessor, mindestens 3GB Festplatte und 64MB RAM als Server-Testsystem, sowie ein weiterer Computer mit ähnlichen Leistungsdaten, der gerne auch ein Laptop sein darf, um über ein lokales Netzwerk (zwei 10Mbit-Ethernetkarten und ein günstiger Hub reichen bereits aus) unter»realistischen«bedingungen Paketfilter oder Web- und Nameserver testen zu können. Wer wenig Platz auf seinem Schreibtisch hat oder die Kosten für einen zweiten Monitor, Tastatur und Maus scheut, sollte zu einem Digital-Switch greifen. Ich habe gute Erfahrungen mit dem Master View KVM Switch ATEN CS-172 gemacht. Sicher sind auch andere digitale Switch-Boxen empfehlenswert. Von den wesentlich billigeren analogen Umschaltern sollten Sie wegen ihrer schlechten Signalqualität und der daraus resultierenden schwammigen Monitordarstellung jedoch Abstand nehmen. 16 Einführung
1.3 Historie zu UNIX, BSD und Linux An der Entwicklung von UNIX war neben großen Firmen (insbesondere AT&T) und Universitäten wie Berkeley (Kalifornien) ebenfalls das Militär (beispielsweise durch die Entwicklung von wichtigen Kommunikationsprotokollen durch ARPA siehe Glossar) wesentlich beteiligt. Der offizielle Startschuss fiel in den 1960er Jahren durch die Zusammenarbeit von Bell Telephone Laboratories und General Electric Company bei der Entwicklung des Betriebssystems Multics. Obwohl die Zusammenarbeit noch vor dem Erreichen der gesetzten Ziele beendet wurde, war der erste Schritt in der UNIX-Entwicklung getan. Einige der beteiligten Entwickler (insbesondere Ken Thompson und Dennis Ritchie) erarbeiteten einen Filesystem- und Prozess-Subsystem-Entwurf, der nach seiner Überarbeitung in C offiziell das Licht der Welt erblickte. AT&T (durch Aufspaltung in die so genannten Baby-Bells entstanden) war es aufgrund des Consent Decree von 1956 nicht erlaubt, Computer-Produkte zu vermarkten. Deshalb wurde beschlossen, den Quellcode von System 7 an Universitäten zu verteilen. Zum damaligen Zeitpunkt war es übrigens ohnehin unüblich, für Software Geld zu verlangen. Software war kostenlos und frei (meist sogar im Quellcode) verfügbar. Geld wurde lediglich mit dem Verkauf von Hardware verdient. Das Design von UNIX fand großen Anklang. In der Folge entstanden»freie«entwicklungen, wie die der Berkeley University in Kalifornien (Berkeley Software Distribution kurz BSD genannt), neben den kommerziellen Betriebssystemen System 7/III/V (AT&T), Xenix (SCO), AIX (IBM), HP-UX (Hewlett Packard) und SunOS/Solaris (Sun Microsystems) sowie Sinix (Siemens). 1.3.1 Bemühungen zur Standardisierung von UNIX Der Wildwuchs»freier«und kommerzieller Systeme führte zur Gründung des X/Open-Zusammenschlusses von Computerherstellern, unabhängigen Software-Häusern und dem IEEE (Institute of Electrical and Electronics Engineers). Das Ziel bestand darin, eine gemeinsame Basis für den UNIX-Markt zu erarbeiten. Zu den größten Erfolgen zählte neben dem X/Open Portability Guide, in dem unter anderem die wichtigsten Kommandos und Kernelemente für UNIX festgelegt sind (siehe: http://www.unix-systems.org/version3/), vor allem die Registrierung des Markennamens UNIX. Nun mussten Hersteller, die ein UNIX-Derivat entwickelten, das Betriebssystem von X/Open (selbstverständlich kostenpflichtig) überprüfen lassen, um den Namen UNIX in der Produktbezeichnung verwenden zu dürfen. Historie zu UNIX, BSD und Linux 17
Das eigentliche Ziel, den Wildwuchs der UNIX-Systeme auf einen gemeinsamen Nenner zu bringen, konnte so natürlich nicht erreicht werden. Dennoch beeinflussten sich die verschiedenen UNIX-Varianten (ob BSD-orientiert oder System 7/III/V basierend) gegenseitig sehr stark und orientierten sich nicht ausschließlich an grundsätzlichen Konzeptionsfragen. 1.3.2 Entwicklung freier UNIX-Derivate Die fortschreitende Kommerzialisierung von Software führte letztendlich 1984 zur Gründung des GNU-Projekts und der Free-Software-Foundation (FSF) durch Richard Stallmann. Ziel war die Erstellung eines für jeden offenen und frei zugänglichen Systems (selbst BSD war nur für Universitäten kostenlos und im Quellcode verfügbar). Aus dem GNU-Projekt entstanden wichtige Kernelemente freier UNIX-Derivate, wie beispielsweise der gcc-compiler oder die bash. Allerdings ist der HURD-Kernel bis heute noch nicht in einer»für den harten Einsatz gedachten Version«verfügbar. Dennoch legte das GNU-Projekt einen wichtigen Grundstein und half Linus Torvalds 1991 bei der Entwicklung von Linux. Linus entschloss sich jedoch nicht zur Entwicklung von Linux, um das GNU- Projekt zu einem»vollständigen Betriebssystem«werden zu lassen, sondern weil er mit dem (damals kommerziellen) System-V Derivat MINIX unzufrieden war. Heute ist MINIX unter http://www.cs.vu.nl/~ast/getting_minix.html übrigens kostenlos erhältlich. Die FSF und alle Freunde des GNU-Projekts weisen darauf hin, dass Linux genau genommen GNU/Linux genannt werden müsste, da Linus in erster Linie den Kernel selbst schrieb und die Anwendungs-Software des Betriebssystems überwiegend aus freien Codes des GNU-Projektes zusammensetzte. Parallel zu GNU/Linux erblickte das 386BSD-Projekt von Bill Jolitz das Licht der Welt. Die Veröffentlichung des Quellcodes im Internet führte (später) zur Gründung der Free- und NetBSD-Projekte. Doch zuvor rief die Veröffentlichung des Quellcodes die Rechtsabteilung von AT&T mit einer Klage gegen die Berkeley Universität auf den Plan. Da die Universität nachweisen konnte, dass der Code bereits (fast) vollständig neu geschrieben worden war, endete das Verfahren mit einem Vergleich. Dennoch hielt die Klage die Entwicklung freier BSD-Derivaten weiter auf, da sämtliche ursprüngliche Codezeilen (die verbliebenen»at&t-fragmente«) entfernt werden mussten. Gleichzeitig wuchs die Popularität von Linux in rasanten Schritten. Firmen»entdeckten«Linux als Geschäftsmodell die ersten Distributionen entstan- 18 Einführung
den. Die Zahl der verschiedenen Distributionen wuchs stetig an und führte durch unterschiedliche Paketverwaltungen und Dateisystemstrukturen letztendlich zur Gründung der Linux Standard Base (LSB: http://www.linuxbase.org/spec/) und des Filesystems Hierarchy Standard (FHS: http://www.pathname.com/fhs/). Die Übernahme dieser Standards steht jedem frei und ist lediglich in Teilen möglich. Dennoch haben große Distributoren wie SuSE und Red Hat die Standards nahezu vollständig in ihre neuesten Versionen übernommen. Selbst bei Distributionen, die»nicht standardkonform«sind, halten sich die Unterschiede in Grenzen. Meist liegen Konfigurations- und Programmdateien lediglich in»exotischeren«verzeichnissen. Dank find, locate und grep stellen diese kleinen Besonderheiten für den erfahrenen Administrator kein wirkliches Hindernis dar. Im Gegensatz zu Linux, das förmlich in einem Distributions-Wildwuchs endete, sind die freien BSD-Varianten überschaubar. Diskrepanzen zwischen Theo De Raadt (einem der Gründungsmitglieder von NetBSD) und NetBSD motivierten Theo 1997 zur Entwicklung von OpenBSD. Darwin ist der jüngste BSD-Spross und wurde von Apple 1999 ohne die grafische Benutzeroberfläche (und die dazugehörigen Bibliotheken) von MacOS X veröffentlicht. Interessant ist, dass in diesem Zusammenhang nicht von BSD-Distributionen gesprochen wird. Tatsächlich handelt es sich um eigenständige Entwicklungen und nicht um lediglich kleinere Erweiterungen, wie beispielsweise einem Installationsprogramm, einem Paketmanager, Verwaltungstools oder Änderungen an der Verzeichnisstruktur. Wer sich weiter Gedanken darüber macht, wird jedoch feststellen, dass diese Unterschiede in gewissem Maße Haarspaltereien sind. Auf der einen Seite bringen sich Distributoren in die Kernel- und Treiberentwicklung ein und legen ihren»linux-varianten«oft eigene Kernel mit mehr oder weniger sinnvollen Patches bei. Auf der anderen Seite werden auch BSD-Systeme überwiegend aus»fertiger, externer«software wie Apache, Bind, Postfix oder OpenSSH»zusammengestellt«. Eine Übersicht der wichtigsten Linux und freien BSD-Systeme bietet die Tabelle 1.1. Eine Sonderstellung nimmt neben Knoppix auch Linux from Scratch ein. Knoppix kann auf Festplatte installiert werden, eignet sich jedoch ebenfalls als Rettungssystem, da es vollständig von der CD bootet. Für Linux from Scratch wurden hingegen lediglich grundlegende Elemente vorbereitet hier darf der Linux-Experte sich sein eigenes System von Grund auf (from Scratch) selbst aufbauen. Historie zu UNIX, BSD und Linux 19
Linux Homepage Start Debian http://www.debian.org 1993 Gentoo http://www.gentoo.org 2001 Knoppix (Linux auf 1CD-Rom) http://www.knopper.net/knoppix/ 2000 Linux from Scratch http://www.linuxfromscratch.org 1998 Mandrake http://www.mandrakelinux.com/de/ 1998 Owl (Fokussierung auf Sicherheit) http://www.openwall.com/owl/de/ 2002 Red Hat http://www.red Hat.de 1994 Slackware http://www.slackware.org 1993 SuSE http://www.suse.de 1993 TrustedLinux (TrustedDebian) http://www.trustedlinux.org 2002 BSD Homepage Start Darwin http://developer.apple.com/darwin/ 1999 FreeBSD http://www.de.freebsd.org/de/ 1993 NetBSD http://www.netbsd.org/de/ 1994 OpenBSD http://www.openbsd.org/de/ 1997 Tabelle 1.1 Die wichtigsten freien-unix Derivate in der Übersicht 1.4 Welches System ist für mich das richtige? Diese Frage lässt sich nur schwer beantworten. Meist werden Sie auf die Standardinstallation Ihres Dienstleisters angewiesen sein, da nur wenige Dienstleister ein beliebiges UNIX-Derivat auf Wunsch installieren oder mehrere Systeme zur Wahl stellen. Eine manuelle (Neu-)Installation über ein Rettungssystem ist in der Regel nicht möglich. Sofern Sie keinen eigenen Server erwerben und Rack-Einheiten mieten (Housing), werden Sie die Wahl des Dienstleisters eher an Kriterien wie Preis, Hardware oder Service und nicht aufgrund des vorinstallierten UNIX- Derivats treffen. Weitere Hinweise zur Wahl des richtigen Dienstleisters und Leistungspakets finden Sie in Kapitel 7, Der eigene Server. 1.4.1 Vor- und Nachteile der verschiedenen Systeme Im Folgenden möchte ich auf die Unterschiede zwischen den in Deutschland für dedizierte Server am häufigsten eingesetzten Linux-Systemen (SuSE, Red Hat, Debian) und OpenBSD (das stellvertretend für die freien BSD-Systeme im Buch behandelt wird) eingehen. 20 Einführung
Tatsächlich spielt es keine allzu große Rolle, ob Sie sich für ein BSD-System oder eine Linux-Distribution entscheiden. OpenBSD besitzt den Ruf, größtmögliche Sicherheit und Stabilität zu gewährleisten. In den letzten sieben Jahren wurde lediglich eine (von außen erreichbare Sicherheitslücke) in der Standardinstallation entdeckt. So toll das im ersten Moment auch klingen mag: Die Sicherheit unter OpenBSD ist wie bei Linux in erster Linie von der sauberen Konfiguration der installierten Software und dem regelmäßigen Einspielen von Sicherheits-Updates abhängig. Ein Sicherheitsloch im Mail- oder FTP-Server wirkt sich bei OpenBSD ebenso gravierend wie unter Linux aus. Etwas anders liegt der Fall hinsichtlich der Stabilität. SuSE und Red Hat legen seit einiger Zeit größeren Wert auf aktuellste Software-Pakete. Dies ist gut für das Marketing, aber häufig schlecht für die Systemstabilität. Allerdings sind auf einem abgespeckten SuSE- oder Red Hat-System-Abstürze so gut wie nie zu verzeichnen. Ein sauber konfiguriertes Serversystem, das lediglich die in diesem Buch beschriebenen Programme nutzt, sollte unabhängig vom genutzten Betriebssystem überhaupt nicht abstürzen. 1.4.2 Wartung und Pflege Wer freie Hand bei der Wahl des Betriebssystems hat, sollte die verschiedenen Ansätze zur Pflege und Wartung der UNIX-Derivate beachten. Insbesondere wenn mehr als ein Server zu pflegen ist, wird die verlässliche, schnelle und einfache Pflege zu einem wichtigen Kriterium. Debian liegt hier ganz klar vorn: Es kann nicht nur über zwei Befehle bequem mit den neuesten Sicherheits-Updates bereichert werden auch ein System- Update von potato zu woody ist ebenso unkompliziert und sogar im laufenden Betrieb ohne eine»saubere Neuinstallation«möglich. Es ist davon auszugehen, dass in kommenden Updates auf die langwierige und umständliche Neuinstallation verzichtet und ein Debian-System ohne aufwändige Wartungsarbeiten ein ganzes Server-Leben lang betrieben werden kann. Bei anderen Systemen ist dies ganz und gar nicht selbstverständlich. Zwar kann ein OpenBSD-System auch im laufenden Betrieb aktualisiert werden (lediglich ein Neustart ist nach dem Kompilieren der Quellen notwendig). Allerdings ist die Verfahrensweise bisher alles andere als trivial. Wenn auch nur»eine Kleinigkeit«schief geht, kann es passieren, dass der Rechner beim nächsten Neustart nicht mehr zur Verfügung steht. Das Einspielen von Sicherheits-Updates ist für zusätzlich installierte Pakete simpel, aber das Patchen von Systemgrundkomponenten ist leider ausschließlich manuell und mit nachträglicher Kompilierung des Programms möglich (siehe Kapitel 5.2, Einspielen von Security- Updates). Welches System ist für mich das richtige? 21
Bei SuSE steht mit you eine komfortable Möglichkeit zum Einspielen von Sicherheits-Updates zur Verfügung, die Bedienung des Tools ist jedoch gewöhnungsbedürftig. Red Hat kann ebenfalls mit dem allerdings kostenpflichtigen Up2Date aufwarten. Das Versions-Upgrade bei SuSE und Red Hat ist allerdings problematisch. Updates sind hier wenig empfehlenswert und haben grundsätzlich lediglich dann»hohe Aussicht auf Erfolg«, wenn zur nächst höheren Versionsnummer gesprungen wird und nicht etwa selbst kompilierte Programme ins System eingebunden wurden. Da Sie kaum zweimal im Jahr Ihr System von einer Version zur nächsten upgraden werden, empfiehlt sich bei Red Hat und SuSE eher die Neuinstallation des Systems. Letzteres wird immer dann notwendig, wenn Sicherheits-Updates zu der von Ihnen genutzten Version nicht weiter zur Verfügung gestellt werden. Bei SuSE beträgt die Pflege derzeit ca. drei und bei Red Hat ca. 1,5 Jahre. 1.4.3 Saubere Installation Ein weiteres für Einsteiger wichtiges Kriterium ist die Installation. SuSE und Red Hat werden mit komfortablen Installationsprogrammen geliefert. Dennoch ist das Verkleinern einer bestehenden Windows-Partition lediglich mit dem Installationsprogramm von SuSE schnell und ohne Fachkenntnisse möglich. Allerdings sollten Sie unmittelbar vor dem Verkleinern einer Windows-Partition das im Ordner Zubehör Systemprogramme des Startmenüs versteckte Programm Defragmentierung nutzen. Auf einem Server sollten grundsätzlich nur tatsächlich benötigte Programme und Pakete laufen. Dies vereinfacht das Einspielen von Sicherheits-Updates und verbraucht zudem nicht unnötig Festplattenkapazitäten. Wer unter Zeitdruck steht oder als Einsteiger nicht sicher ist, welche Systemkomponenten auszuwählen sind, wird sich über ein sauberes Minimalsystem freuen. Die Installationsgrößen der Minimalsysteme sprechen für sich: Debian 3.0.r1: 100 MB OpenBSD 3.2: 160 MB SuSE 8.1: 270 MB Red Hat 8.0: 321 MB Allerdings wurde bei Debian auf Ausführung von tasksel und dselect verzichtet. Bereits vorselektierte dselect-einträge bleiben jedoch erhalten und müssen gegebenenfalls nachträglich abgewählt werden, wenn Sie dselect zur Auflösung von Paketabhängigkeiten nutzen möchten. 22 Einführung
OpenBSD ist kleiner als es den Anschein haben mag. Das System wird bereits nahezu vollständig installiert: ssh, apache, sendmail und Bind gehören zur Grundausstattung. Andererseits kann sich dies nachteilig auswirken: Die saubere, manuelle Deinstallation von Bind (übrigens in Version 4 vorinstalliert), sendmail oder apache ist alles andere trivial, da die Komponenten nicht als Pakete eingebunden wurden, sondern zum Basis-System zählen. Bei SuSE und Red Hat sind ebenfalls einige Dienste zu deinstallieren. Wer unter SuSE bei der Installation auf die Überschrift Software klickt, kann diesen Schritt glücklicherweise vorwegnehmen und die Pakete noch vor der Installation abwählen. Dies ist ebenfalls unter Red Hat möglich das Installationsprogramm bietet unmittelbar vor der eigentlichen Installation die Möglichkeit, Pakete und Programmgruppen gezielt aus- und abzuwählen. 1.4.4 Hardware-Unterstützung Wer ein Windows-Desktopsystem oder einen Laptop erworben hat, kann sich über die volle Hardware-Unterstützung bereits eingebauter Netzwerkkarten nicht sicher sein. Selbst unter Linux finden sich immer wieder Karten, die Probleme bereiten und eventuell nicht eingebunden werden können. Deshalb sollten Sie bereits vor dem Kauf von Hardware nachsehen, ob Ihr Betriebssystem den benötigten Treiber enthält. Die Palette unterstützter Hardware ist bei OpenBSD nicht ganz so umfangreich wie bei NetBSD. Falls Sie ein BSD-System einsetzen möchten, aber Ihre Hardware nicht in vollem Umfang unterstützt wird, empfiehlt sich ein Blick auf die Hardware-Datenbank von NetBSD: http://www.netbsd.org/ports/. System SuSE Red Hat Debian OpenBSD Hardware-Datenbank http://hardwaredb.suse.de http://hardware.red Hat.com Leider keine SuSE DB mitnutzen http://www.openbsd.org/de/plat.html Tabelle 1.2 Die Hardware-Datenbanken klären, ob Sie bereits vorhandene Komponenten mit dem System Ihrer Wahl nutzen können. 1.4.5 Dokumentation, Mailinglisten und Support Wenn Sie noch keine Erfahrungen mit UNIX-Derivaten sammeln konnten, ist der Support ein wichtiges Thema. Für alle BSD-Systeme sind hilfreiche Mailinglisten vorhanden, über die Sie kostenlos Hilfestellung durch andere Nutzer Welches System ist für mich das richtige? 23
erhalten können. Allerdings sollten Sie der englischen Sprache mächtig sein. Ähnlich sieht die Situation bei Linux aus; lediglich SuSE und Debian bieten deutschsprachige Mailinglisten an. Darüber hinaus wird ein kostenpflichtiger und oft sehr professioneller Support von vielen UNIX-, Linux- und BSD-Systemhäusern angeboten. SuSE und Red Hat bieten Firmenkunden ebenfalls kostenpflichtigen Support an. Für Einsteiger ist die Dokumentation ein weiteres wichtiges Kriterium. Wirklich geeignet sind jedoch nur die Handbücher von SuSE (leider nur in der BoxVersion erhältlich) und Debian (über http://www.openoffice.de/linux/buch/ kostenlos beziehbar). FreeBSD kann zusammen mit dem Buch»FreeBSD 4. Installieren, Konfigurieren, Administrieren«von Mike Feldmeier erworben werden. Die Dokumentationen zu OpenBSD und NetBSD sind weniger einsteigerfreundlich. 1.4.6 Notfallsystem Obwohl Linux als auch BSD-Systeme höchst stabil arbeiten, könnten Sie eines Tages mit ernsten Problemen konfrontiert werden. Lediglich ein gut vorbereitetes Notfallsystem wird es Ihnen ermöglichen, die notwendigen Reparaturarbeiten Zeit und Nerven schonend zu erledigen und die sonst entstehenden Zusatzkosten für einen Support vor Ort durch Ihren Dienstleister einzusparen. Wenn Sie Pech haben, installiert der kostenpflichtige Support lediglich ein Standardsystem auf die Server-Festplatte auf und kümmert sich weder um eventuell ungesicherte Daten noch um die tatsächlichen Probleme Ihres Systems. Ein kleines Notfallsystem ist auf einer ausgelagerten Partition zwar schnell und unter jedem System installierbar, bietet jedoch keine große Sicherheit. Obwohl Reparaturarbeiten an den Hauptpartitionen über das Notfallsystem möglich sind, wären Sie bei einem Angriff nicht davor sicher, dass das Notfallsystem ebenfalls kompromittiert wird. Insbesondere beim Einsatz von AIDE (siehe Kapitel 5.10, Integritätsprüfung mit AIDE) oder Tripwire ist es von großem Vorteil, unter Linux über lilo (siehe Kapitel 2.5.1, LILO Generic Boot Loader for Linux) beim nächsten Reboot von der CD-ROM das Notfallsystem zu starten. Leider ist dies unter OpenBSD so nicht möglich. Die CD muss hier bootbar sein, das heißt, das System kann nicht im CD-Player verbleiben, sondern muss bei Bedarf manuell vom Dienstleister eingelegt werden. Weitere Informationen zu diesem Thema finden Sie in Kapitel 4.14, Das Rettungssystem. 24 Einführung