Linux Server mit Debian 7 GNU/Linux
Das umfassende Praxis-Handbuch
Aktuell für die Version Debian 7 (Wheezy)
Eric Amberg
Eric Amberg
In diesem letzten Teil (Gratulation, Sie sind bereits auf der Zielgeraden!) geht es um die Absicherung unseres Servers. Sie haben im Laufe dieses Lehrgangs viele Serverdienste kennen gelernt und an vielen Stellen habe ich Sie bereits auf mögliche Sicherheitsrisiken hingewiesen. Der nun folgende Teil soll Ihnen helfen, Ihren Server rundum möglichst sicher aufzusetzen und zu konfigurieren. Dabei sollten Sie allerdings eins stets berücksichtigen:
IT-Security ist kein Status, den man irgendwann einmal erreicht, sondern ein stetig laufender und nie endender Prozess. Kaum haben Sie ein Sicherheitsloch gestopft, öffnet sich ein neues. Als Administrator läuft man den Ereignissen fast zwangsläufig ständig hinterher.
Eine der größten Schwierigkeiten ist die Informationsbeschaffung. Ein gründlicher und sicherheitsbewusster Administrator könnte einen Großteil seiner Zeit damit verbringen, Sicherheitsmeldungen zu studieren und nach Sicherheitslücken zu suchen, die sein eigenes System betreffen.
Meine Empfehlung hierzu lautet: Abonnieren Sie zwei oder drei einschlägige Newsletter und lesen Sie regelmäßig zwei bis drei aktuelle Seiten im Internet. Machen Sie sich nicht verrückt und beschränken Sie sich auf die Informationen, die Ihre eigenen Systeme betreffen – nur wenn Sie die Zeit dazu haben, sollten Sie sich mit anderen Security-Meldungen auseinandersetzen.
Hier eine Auswahl, die Sie sich einmal genauer ansehen sollten:
www.bsi.de – Website des Bundesministeriums für Sicherheit in der Informationstechnik. Unter http://www.bsi.de/certbund/infodienst/kurzinfo.htm können Sie eine Kurzinfo-Mailingliste abonnieren. Sie erhalten mehrmals täglich aktuelle Informationen über Sicherheitslöcher. Sehr empfehlenswert.
www.heise.de – Website des Heise-Verlags, der sowohl die Zeitschrift C’t als auch die iX herausbringt. Enthält eine Security-Seite (http://www.heise.de/security) und einen Security-Newsletter mit einer wöchentlichen Zusammenfassung aller Security-relevanten Nachrichten unter http://www.heise.de/bin/newsletter/listinfo/heisec-summary.
www.securityfocus.com – Diese Website betreibt das bekannte Security-Forum Bugtraq unter http://www.securityfocus.com/archive/1. Hier werden oftmals sehr detailliert Sicherheitslücken und deren Exploits aufgezeigt und diskutiert. Die Site enthält auch einen wöchentlichen Newsletter unter http://www.securityfocus.com/newsletters.
Websites verschiedener Antivirenhersteller, zum Beispiel www.symantec.de, www.mcafee.de, www.sophos.de usw.
Zusätzlich finden Sie auf den Webpräsenzen Ihres Betriebssystems, zum Beispiel www.debian.org/security, sicherheitsrelevante Meldungen bezüglich der eigenen Distribution.
Sie werden im nächsten Kapitel konkrete Vorschläge erhalten, welche Dinge Sie tun und welche Sie besser nicht tun sollten. Hier möchte ich Ihnen zunächst einige allgemeine Ratschläge geben, die für jedes Serversystem gelten:
Installieren Sie auf Ihrem Server nur das Nötigste, um Ihren Server zu betreiben. Lassen Sie keine unnötigen Dienste oder Subsysteme laufen. Jeder Dienst stellt eine potenzielle Sicherheitslücke dar.
Konfigurieren Sie auch die einzelnen Dienste so, dass möglichst wenig Angriffsfläche übrig bleibt. Aktivieren Sie keine Features, die Sie nicht benötigen. So können Sie zum Beispiel das Login per SSH für root unterbinden. Ein normaler Benutzer tut es auch, der sich anschließend per su in root verwandelt.
Vergeben Sie überall nur so viele Rechte wie nötig und so wenig, wie möglich.
Sichern Sie Ihren Server durch Firewalls, Intrusion-Detection-Systeme, Backups und durch einen geeigneten (logischen sowie physikalischen) Standort ab. Die Vorteile eines Servers in einer DMZ habe ich Ihnen bereits ausgiebig erläutert.
Sorgen Sie dafür, dass Ihr Server und seine Dienste immer auf dem aktuellen Patch-Stand sind – Security-Löcher werden oftmals schnell mit Updates und Patchs geschlossen.
Führen Sie Ihre Dienste – wann immer möglich – innerhalb einer Change-Root-Umgebung aus. Das Ausbrechen aus einem chroot ist sehr schwierig.
Führen Sie regelmäßig Security-Audits durch, indem Sie einen Security-Scanner, zum Beispiel Nessus, auf Ihren Server ansetzen. Sie können sich noch so gut absichern, erst ein Angriff zeigt, wie stark Ihre Mauern wirklich sind.
Betreiben Sie das Vier-Augen-Prinzip: Lassen Sie eine vertrauenswürdige Person, die mit der Materie vertraut ist, Ihre Sicherheitsmaßnahmen checken! Vier Augen sehen mehr als zwei. In großen Unternehmen übernehmen interne und externe Security-Auditoren diese Aufgabe.
Ich spreche hier ständig über Schwachstellen und Sicherheitslöcher – aber was genau verbirgt sich denn dahinter? Welchen Bedrohungen müssen wir uns stellen? Wo sind die klassischen »Sollbruchstellen«? Eine vollständige Auflistung dürfte schwierig oder gar unmöglich sein – die wichtigsten Angriffe stelle ich Ihnen im Folgenden vor. Doch zunächst möchte ich mit Ihnen über Security-Grundsätze sprechen.
Die Informationssicherheit – oder internationaler: IT-Security – verfolgt drei Hauptziele:
Die vorhandenen Daten dürfen nur von autorisierten Personen eingesehen werden. Dazu gehört auch der Schutz von personenbezogenen Daten bzw. der Anonymität.
Der Zugriff auf die Daten muss jederzeit innerhalb eines vereinbarten Zeitrahmens möglich sein. Dies schließt auch eine Wiederherstellungszeit im Rahmen eines Desaster-Recoverys (siehe Kapitel 40 Desaster Recovery) ein.
Die Daten dürfen nicht unbemerkt verändert werden. Es muss sichergestellt werden, dass die Manipulation von Daten, das Hinzufügen, Verändern oder Löschen, nur von autorisierten Personen vorgenommen werden können.
Darüber hinaus ist ein weiteres Ziel die Authentizität – dies beinhaltet die Sicherstellung der Identität einer Person, mit der Informationen ausgetauscht werden. Dies spielt insbesondere bei allen Finanzangelegenheiten wie Geldtransaktionen, größeren Aufträgen etc. eine Rolle. Die Authentizität spielt bei Transaktionen eine erhebliche Rolle, ich zähle sie daher als viertes Ziel hinzu.
Ist das für Sie zu banal? Interessanterweise können Sie aber tatsächlich alle Security-relevanten Vorfälle in einem der vier Hauptziele wiederfinden. Betrachten wir ein paar Beispiele:
Ein Hacker hat es geschafft, in ein Datenbanksystem einzudringen und Kundendaten auszuspähen – hier wurde die Vertraulichkeit verletzt.
Einem Wurm ist es gelungen, wichtige Dateien auf einem Server zu zerstören. Die Dateien enthielten Buchhaltungsdaten, aufgrund derer die Bilanz zu erstellen ist – in diesem Fall ist die Verfügbarkeit der Daten gefährdet.
Einem gekündigten und unzufriedenen Mitarbeiter gelingt es, die Zahlen in einem Angebotsschreiben für einen Großauftrag derart zu verfälschen, dass der Auftrag an ein anderes Unternehmen geht – ein klarer Fall von Verletzung der Integrität.
Eine Bank erhält Buchungsaufträge von einer Person, die über Phishing-Mails PINs und TANs von anderen Leuten erschlichen hat – hier versagt die Sicherstellung der Authentizität des Kommunikationspartners.
Diese Beispiele verdeutlichen den Zusammenhang zwischen Security-Incidents (Incident = Ereignis, Vorfall) und den Security-Zielen. Doch lassen Sie uns nun einen Blick auf die Bedrohungen werfen, denen unsere EDV-Systeme ausgesetzt sind.
Wie bereits erwähnt, ist die folgende Auflistung keineswegs vollständig. Sie dient lediglich dazu, wichtige und immer wiederkehrende Einbruchstechniken und Sollbruchstellen aufzuzeigen. Wir können zwischen lokalen und Netzwerkangriffen unterscheiden:
Hierunter fallen alle Angriffe, die von einem Benutzer, der direkt vor dem betreffenden System sitzt, ausgehen. Grundsätzlich gibt es keine lokale Sicherheit! Hat ein Angreifer physischen Zugriff auf ein System, ist es nicht möglich, einen Einbruch zu 100 % zu verhindern.
Daher kommt dem Serverstandort und dessen Absicherung auch eine hohe Bedeutung zu. Die Mitarbeiter größerer Rechenzentren tragen Waffen, der Zugang wird häufig nur über duale Authentifikationssysteme realisiert – neben dem Ausweis müssen die Zugangsberechtigten Ihre Identität über biometrische Systeme (Fingerabdruck, Retinascan etc.) nachweisen.
Typische lokale Angriffe sind:
Bruteforce-Attacken auf Passwörter: Kommt ein Angreifer zum Beispiel in den Besitz der Passwort-Datei (/etc/shadow), kann er durch Ausprobieren aller möglichen Kombinationen früher oder später alle Passwörter herausfinden.
Privilegieneskalation: Hat ein Angreifer nicht privilegierten Zugriff auf ein System, kann er in bestimmten Fällen durch Ausnutzen bestimmter Sicherheitslöcher bzw. fehlender Absicherungen seine Privilegien u.U. bis auf Root-Rechte erweitern.
Pufferüberläufe: Viele Programme sind unsauber programmiert und enthalten Fehler in der Überprüfung von Benutzereingaben. Durch entsprechend manipulierte Eingaben können unter Umständen Shells oder andere Programme gestartet werden, die mit den Rechten des fehlerhaften Programms laufen – viele Programme laufen unter root ...
Zerstörung von Daten: Ob Sie es glauben oder nicht: dies passiert (absichtlich) relativ selten – und zwar aus einem einfachen Grund: wenn ein Angreifer schon die Möglichkeit hat, lokal auf das System zuzugreifen, ist es viel interessanter, Daten auszuspähen, zu stehlen oder zu manipulieren, als sie zu zerstören.
Kommen wir nun zu den Netzwerk- oder Remote-Angriffen:
Ein Angreifer, der über das Netzwerk in ein System eindringen will, muss noch ganz andere Hürden nehmen als ein lokaler Angreifer. Aber wer sagt eigentlich, dass ein Remote-Angriff auf ein Eindringen abzielt? Siehe unsere erste Kategorie:
Denial-of-Service-Attacke (DoS): Das Ziel eines solchen Angriffs ist es, ein System lahmzulegen, es unbenutzbar zu machen. Dazu muss der betreffende Dienst entweder überlastet oder mit bestimmten falschen Daten gefüttert werden. Hierbei hat der Angreifer allerdings in der Regel nur einen temporären Erfolg, da sich eine DoS-Attacke nicht endlos aufrechterhalten lässt. Da viele Systeme heutzutage eine sehr große Netzwerklast ertragen können und mit entsprechenden Schutzmaßnahmen versehen wurden, wird DoS oftmals auf DDoS erweitert, dem Distributed Denial-of-Service-Angriff, bei dem viele Rechner mit Internetzugang für einen DoS-Angriff missbraucht werden – in der Regel ohne Wissen der jeweiligen Eigentümer. Dies geschieht häufig durch Würmer oder Trojaner auf den betroffenen Systemen, die den Angriff automatisiert zu einem bestimmten Zeitpunkt starten.
Reconnaissance-Attacke: Hierbei handelt es sich eigentlich nicht um einen Angriff im eigentlichen Sinne. Vielmehr geht es um die Aufklärung (engl. reconnaissance) von Netzwerkstrukturen. Mittels bestimmter Techniken (TCP-Scan, Portscan, Fingerprinting etc.) versucht ein Angreifer herauszubekommen, wie das betreffende Netzwerk aufgebaut ist und wo die Schwachstellen sind.
Remote-Exploit: Der Traum jedes Angreifers – eine Schwachstelle in einem von außen erreichbaren System durch einen so genannten Exploit (ein Stückchen Code oder eine Technik zum Ausnutzen der Schwachstelle) infiltrieren und sich somit Zugang zu dem betreffenden System verschaffen. In Kombination mit anderen Techniken, zum Beispiel Privilegieneskalation, kann der Angreifer auch unter ungünstigen Bedingungen volle Kontrolle über einen Server erhalten.
Viren, Würmer und Trojaner: Der Übergang ist fließend, viele Schädlinge haben heutzutage schon Eigenschaften aller drei »Gattungen«. Ihnen gemein ist, dass sie über verschiedene Wege per Netzwerkkommunikation auf bestimmte Rechner und Server gelangen und dort automatisiert ihre Schadensfunktion entfalten. Zwar sind sie auf Linux-Systemen bei weitem noch nicht so stark verbreitet wie unter Windows, dennoch sollten Sie die Gefahr für Ihre Systeme nicht unterschätzen, zumal Linux-Server häufig in Windows-Client-Netzwerken ihren Dienst tun. Schädlinge werden inzwischen übrigens hauptsächlich über infizierte Webseiten übertragen und nicht mehr per E-Mail.
Spoofing: Kein selbstständiger Angriff, sondern ein Hilfsmittel zum Angriff. Es wird zum Beispiel eine vertrauenswürdige IP-Adresse aus dem LAN vorgetäuscht, um durch eine Firewall oder einen lokalen IP-Filter zu kommen. Schutz bieten hier Antispoofing-Maßnahmen wie ich Sie Ihnen in Kapitel 36 Linux als Netzwerk-Firewall vorgestellt habe. Oftmals wird auch versucht, über die Loopback-Adresse 127.0.0.1 das Ziel auszutricksen. Fast jedes Serversystem ist darauf angewiesen, dass es mit sich selbst über 127.0.0.1 kommunizieren kann. Daher haben die wenigsten Systeme einen lokalen Filter auf dieser IP-Adresse.
Root-Kits: Die so genannten Root-Kits sind häufig erst Teil 2 eines erfolgreichen Angriffs. Es handelt sich um Software, die dazu geeignet ist, sich vor dem System selbst unsichtbar zu machen und vollkommen unbemerkt bestimmte Funktionen auszuführen. Dabei kann es sich um Keylogging (Mitschnitt der Tastatureingabe), versenden von Systemlogs oder anderen Dateien oder – sehr beliebt – dem Öffnen von so genannten Backdoors handeln. Backdoors sind Hintertüren auf dem System, sprich Ports, über die der Angreifer eine Shell auf dem System öffnen kann. So kann ein Angreifer im ungünstigsten Fall einen Server über lange Zeit unter seiner Kontrolle behalten, ohne dass der Administrator irgendetwas davon bemerkt. Root-Kits aufzuspüren ist eine ganz eigene Wissenschaft.
Genug Angst gemacht 
. Dabei möchte ich es hier bewenden lassen. Wie gesagt: es handelt sich weder um eine komplette Aufzählung noch um die einzig mögliche Gliederung von Angriffen.
Was jetzt jedoch viel wichtiger ist: Wie können Sie sich gegen die böse Welt da draußen wappnen und ihren armen, kleinen und unschuldigen Server schützen? Die Antwort darauf geben Ihnen die nächsten Kapitel.
Wir werden uns zunächst mit der allgemeinen Härtung des Betriebssystems und der wichtigsten Dienste beschäftigen, bevor ich Ihnen einige Instrumente zur Einbruchserkennung und -analyse vorstelle. Schließlich wird es im letzten Kapitel dieses Buches um das Thema Desaster Recovery gehen, also um die effiziente Wiederherstellung Ihrer Systeme nach dem K-Fall – wie immer der auch aussehen mag.
Herzlich willkommen zum vierten Teil unseres Lehrgangs! Sie haben nun schon ein solides Wissen über die System- und Netzwerkadministration erwerben können – doch es warten weitere spannende Themen auf Sie!
In diesem Teil werden wir einen Blick auf Linux als Gateway werfen. Dabei spielt das Routing natürlich eine zentrale Rolle, da ein Gateway immer in mindestens zwei Subnetzen zu Hause ist. Darüber hinaus hat ein Gateway oftmals zusätzliche Funktionen, wie zum Beispiel als Proxy, DNS-Server und nicht zuletzt als Netzwerk-Firewall.
Nachdem Sie nun einen funktionierenden Backoffice-Server im LAN des Architekturbüros Windschief aufgebaut und einen Root-Server für Internetanwendungen erstellt haben, möchten Sie nun den 30-Euro-DSL-Router gegen ein vollwertiges Linux-Gateway-System ersetzen. Seit geraumer Zeit leben Sie mit den Nachteilen dieses Gerätes, die aus der geringen Einflussnahme resultieren, die Sie auf die Funktionalität der Box haben. Das hat schon öfter zu längeren Debugging-Sessions geführt, während derer Sie sich wünschten, ein detaillierteres Logfile oder auch einen Paketsniffer zu haben.
Folgende Vorteile versprechen Sie sich davon:
bessere Kontrolle über die Routing- und Gateway-Funktionen
aussagefähigere Logfiles und einfacheres Debugging, da Sie zum Beispiel auch Paketsniffer einsetzen können
zusätzliche Funktionen wie zum Beispiel Proxydienste
einfache Integration einer oder mehrerer DMZ(s)
durch den Einsatz von iptables eine genaue Kontrolle über den Kommunikationsfluss
bei Bedarf Aufbau von VPNs zu Geschäftspartnern
Für die genannten Vorteile nehmen Sie gern in Kauf, dass es wesentlich aufwändiger ist, ein solches, auf Linux basierendes, Gateway-System aufzubauen, als eine kleine DSL-Box zu konfigurieren. Außerdem entstehen – je nach Hardware – höhere Stromkosten, die allerdings durch den geringeren Aufwand bei der Eingrenzung von Kommunikationsproblemen mitunter schnell wieder mehr als ausgeglichen werden. Somit können die TCO, die Total Cost of Ownership – also die Gesamtkosten eines Systems über seinen gesamten Lebenszyklus – durch ein eigenes Linux-Gateway niedriger ausfallen als der Einsatz eines 30-Euro-Routers.
Wie auch immer: Sie statten Ihrem Chef, Herrn Windschief, einen Besuch ab und unterbreiten ihm Ihren Vorschlag. Wie nicht anders zu erwarten, gibt er Ihnen grünes Licht, da er inzwischen volles Vertrauen zu Ihnen hat. Bevor Sie das System im Architekturbüro implementieren, wollen Sie die Komponenten jedoch zunächst unter Laborbedingungen ausgiebig testen.
Sie können die meisten Szenarien mit einem Client und einem Linux-Server nachbilden. Jedoch ist für den Aufbau einer DMZ mindestens noch ein dritter Rechner erforderlich. Für einen Test von »außen« sind sogar vier Computer nötig.
Da wir in diesem Teil über Routing sprechen, benötigt das Linux-Gateway pro angeschlossenes Netzwerksegment eine Netzwerkkarte. Bei vollem Ausbau inklusive DMZ also drei an der Zahl. Die Luxusvariante des Labors stellt sich dann in der Grundform folgendermaßen dar:
Abb. T.1: Laborumgebung für das Linux-Gateway
Da ich Ihnen auch zeigen werde, wie Sie einen Internetanschluss per DSL realisieren können, benötigen Sie hierfür noch ein DSL-Modem, wenn Sie diese Szenarien praktisch nachvollziehen können.
Wir werden das Lab also im Einzelfall an unsere Bedürfnisse anpassen. Was die Client-Betriebssysteme angeht, so gehe ich zwar von Windows XP aus, jedoch können Sie hier auch jedes andere Betriebssystem nutzen, das über entsprechende Netzwerk-Clients (Browser, E-Mail-Programm etc.) verfügt.
Natürlich steht zunächst die Routing-Funktionalität von Linux auf dem Programm. Die Routing-Konfiguration ist in kleinen Netzwerken recht simpel, kann jedoch in einer größeren Infrastruktur Ausmaße annehmen, die sich ein Außenstehender kaum vorstellen kann. Wir sprechen von Tausenden von Routen, die über Routing-Protokolle ausgetauscht werden. Allerdings werde ich das Thema des dynamischen Routings mittels Routing-Protokollen nur streifen, da dies sonst den Rahmen dieses Lehrgangs sprengen würde. Stattdessen werde ich Ihnen die Grundlagen des statischen Routings unter Linux nahe bringen.
Im Rahmen der Grundkonfiguration beschäftigen wir uns auch mit der Anbindung an das Internet über ISDN und DSL, da dies sicherlich ein häufiger Anwendungsfall sein wird. Dabei werde ich nicht so stark auf ISDN eingehen, da diese Technologie in der heutigen Zeit allenfalls als Notfall-Backup-Lösung dienen sollte – der Durchsatz von maximal 128 KBit ist einfach zu gering.
Zu einem (internen) Router gehört in vielen Fällen auch eine Netzwerk-Firewall – auf einem Gateway, das das Internet vom LAN oder einer DMZ trennt, ist sie obligatorisch. Demnach werden wir uns auch diesem Thema widmen, wobei wir die bereits vorhandenen Kenntnisse aus dem dritten Teil des Buches erweitern werden. Dabei werden wir auch ein etwas ausgereifteres Firewall-Skript erstellen.
Darüber hinaus wollen wir aber auch einen Blick auf typische Gateway-Dienste wie zum Beispiel DNS-Caching-Server, Squid Proxyserver und DynDNS-Dienste werfen. In diesem Zusammenhang zeige ich Ihnen, wie Sie ein Home-Netzwerk mit einer DMZ aufbauen können, in der Sie verschiedene Dienste anbieten können. Dieses Prinzip wird in dieser Form auch in professionellen Netzwerken angewandt, so dass die beschriebenen Konzepte in den meisten Fällen eins-zu-eins übernommen werden können.
Am Ende steht ein Gateway-System, das in den meisten kleineren Umgebungen gute Dienste leisten kann. Mit entsprechendem Tuning ist Linux allerdings durchaus in der Lage, mit einem kommerziellen Oberklasse-Gateway mitzuhalten.
Willkommen zum dritten Teil dieses Buches! Wir verlagern nun unsere Wirkungsstätte von der Arbeit an einem Unternehmensserver auf die Administration eines so genannten Root-Servers.
Der Begriff »Root-Server« ist eigentlich irreführend und bezeichnet in erster Linie einen der 13 Hauptserver von DNS. Unter einem Root-Server in unserem Sinne wird ein dedizierter oder virtueller Server verstanden, der einem Kunden zur Verfügung gestellt wird. Dieser Server wird in einem Rechenzentrum professionell untergebracht und hardwaremäßig gewartet.
Der Begriff »Root-Server« kommt daher, dass der Kunde nicht nur auf Teile, also bestimmte Dienste des Servers, sondern auf den gesamten Server Administrationszugriff (also root-Rechte) hat. Der Vorteil ist, dass der Kunde selbst bestimmen kann, welchem Zweck der Server zugeführt werden soll: Web-, FTP-, Mail-, Datenbank- oder Spieleserver etc.
Neben den dedizierten Servern, bei denen tatsächlich ein physischer Server vollständig vermietet wird, werden inzwischen vermehrt so genannte VServer angeboten, virtuelle Root-Server. Dabei teilen sich mehrere Root-Server eine physische Hardware und laufen als virtuelle Instanzen auf einem Hostsystem, zum Beispiel unter Virtuozzo, VMWare oder ESXServer. Dies ist in der Regel preisgünstiger, jedoch auch mit gewissen Kompromissen hinsichtlich der Leistungsfähigkeit der Hardware verbunden.
Die Administration seitens des Kunden läuft grundsätzlich remote, also per Fernwartung, ab – in der Regel per SSH. Kaum ein Kunde bekommt seinen angemieteten Server jemals zu Gesicht.
Herr Windschief bittet Sie um ein Gespräch. Nach der erfolgreichen Inbetriebnahme des Intranets möchte er Ihnen nun auch die Betreuung der Webpräsenz des Architekturbüros Windschief anvertrauen. Darüber hinaus hätte er noch einige Geschäftspartner, vor denen er mit der Zuverlässigkeit seines Administrators – Ihnen – geprahlt hat. Diese wären auch daran interessiert, ihre Websites bei Ihnen hosten (also auf Ihrem Webserver betreiben) zu lassen. Außerdem hätte er ohnehin gern alles in einer Hand – und zwar in Ihrer. Im Zusammenhang damit könnte man doch vielleicht auch eine Möglichkeit finden, größere Datenmengen zwischen dem Architekturbüro und seinen Geschäftspartnern zu transportieren – E-Mail-Postfächer sind da ja meistens beschränkt ...
Mit Stolz in der Brust schlagen Sie ihm sogleich vor, einen Root-Server anzumieten, mit dem sich ein professionelles Webhosting weitgehend selbstständig und äußerst variabel realisieren ließe. Auch der Datentransfer wäre auf diese Art möglich, ohne einen Server im Unternehmensnetzwerk dafür entblößen zu müssen. Selbst E-Mail könnte man so sehr variabel handhaben. Herr Windschief ist begeistert und lässt Ihnen freie Hand.
... kaum sind Sie aus dem Büro des Chefs heraus, holt Sie die Realität wieder ein, und Sie malen sich die vielen Überstunden aus, die Ihnen durch dieses neue Projekt sicher wieder bevorstehen. Bevor Sie sich an die Arbeit machen, denken Sie noch: »Ich sollte mit ihm bei Gelegenheit mal über eine Gehaltserhöhung sprechen ...«.
Die Konfiguration Ihres Labs ist einfach: Wir benötigen schlicht einen Client und einen Server. Für bestimmte Kapitel, insbesondere die Kapitel, die sich mit dem Thema E-Mail befassen, gehe ich von einem Windows-Client mit Standardsoftware (MS Outlook) aus, da dies sicherlich der Häufigkeitsfall ist. Jedoch sollte es kein Problem darstellen, clientseitig eine andere E-Mail-Software zu nutzen, da die Protokolle genormt und in vielen Mail-Clients enthalten sind.
Typische Dienste auf einem Root-Server sind insbesondere Web-, Mail-, DNS- und FTP-Dienste. Darüber hinaus ist es in diesem Umfeld wichtig, eine geeignete Schutzmauer in Form einer Firewall aufzubauen.
Im folgenden Kapitel gehe ich noch einmal auf den Apache Webserver ein. Bisher haben Sie Ihren Webserver in einer sicheren Umgebung im Firmennetzwerk betrieben. Jetzt geht es darum, ihn »Internet-fest« zu machen. Neben den virtuellen Hosts, die eine Möglichkeit darstellen, mehrere Webpräsenzen von einem einzigen Server zu hosten, also zu beherbergen, gibt es noch andere Punkte, die bei einem produktiven und unter Umständen stark frequentierten Webserver zu beachten sind.
Anschließend beschäftigen wir uns mit dem Thema DNS. Das Domain Name System ist gewissermaßen der Leim, der das Internet zusammenhält. Dadurch ist es uns möglich, im Browser einen sprechenden Namen statt einer IP-Adresse anzugeben. Das Konzept und die Konfiguration von DNS bzw. DNS-Servern ist ebenso essenziell wie anspruchsvoll – ein Kapitel, das Sie auf keinen Fall überspringen sollten!
Nach wie vor ist E-Mail die wichtigste Anwendung im Internet. Zugleich ist die Konfiguration eines funktionierenden Mail-Servers oft die größte Herausforderung, der ein Administrator im Laufe seiner Karriere gegenübersteht. Es dauert einige Zeit, bis die bisweilen etwas zickig reagierenden Mail-Server so reagieren, wie man sich das wünscht. Dafür sind sie – wenn sie erst einmal laufen – meist so stabil wie ein Panzer!
Um Ihnen an dieser Stelle den Weg zu ebnen, habe ich gleich zwei Kapitel vorgesehen, die Ihnen die Konfiguration von E-Mail-Servern inkl. Spam- und Virenschutz sowie POP3- oder IMAP-Servern erläutern. Dabei werden wir aus didaktischen Gründen in Kapitel 31 Lokaler E-Mail-Server mit Content-Filter noch einmal einen Exkurs in das lokale Netz machen, um die Basics zu erarbeiten.
Im Anschluss daran werde ich Ihnen zeigen, wie Sie einen Mail-Server so konfigurieren, dass er gefahrlos in den Wind – sprich: ins Internet gestellt werden kann. Die größte Herausforderung an dieser Stelle ist, kein offenes Relay zu produzieren, also einen Mail-Server, der von nicht autorisierter Seite Mails annimmt und weiterleitet. Hierzu beschäftigen wir uns mit SMTP-Authentifizierung.
Das letzte Kapitel in diesem Teil beschäftigt sich mit iptables als Personal-Firewall. Sollten Sie einen Server betreiben, der – in welcher Form auch immer – vom Internet aus erreichbar ist, kommen Sie um eine Firewall nicht herum. Personal-Firewalls schützen im Gegensatz zu Netzwerkfirewalls nur einen einzelnen Rechner. Im 4. Teil werde ich Ihnen darauf aufbauend zeigen, wie Sie eine Netzwerkfirewall mit iptables konfigurieren können.
Ab jetzt geht es voll in die Praxis! Bisher haben wir die Grundlagen der allgemeinen Systemadministration besprochen. Sie haben das (Debian-)Linux-System und Ihren Administrator-Werkzeugkasten kennen gelernt und haben schon einige Erfahrung als Systemadministrator sammeln können. In den letzten Kapiteln haben wir Ihren Linux-Server netzwerkfähig gemacht. Nun wird es Zeit, den Server nutzbringend in Ihrem Netzwerk einzusetzen – als Mittel zum Zweck und nicht mehr als Selbstzweck.
In Ihrem Unternehmen, dem Architekturbüro Windschief, wurden kürzlich drei neue Mitarbeiter angestellt: eine Sekretärin und zwei neue Architekten. Damit zählt das Unternehmen nun 12 Mitarbeiter. Wie eingangs erwähnt, sind Sie der System- und Netzwerkadministrator des Betriebs. Bisher sind die PCs der Mitarbeiter zwar miteinander vernetzt, aber als Peer-to-Peer-Netzwerk organisiert, das heißt, es gibt keine zentrale Organisation oder Datenhaltung – alle Workstations sind gleichberechtigt. Der Chef, Herr Windschief, hat sich nach einem Beratungsgespräch mit Ihnen dazu entschlossen, das EDV-System auf ein Client-Server-Netzwerk umzustellen:
Sie haben Herrn Windschief davon überzeugen können, dass das Betriebssystem Linux alles mitbringt, was ein Unternehmensserver benötigt. Zunächst soll ein zentraler Server auf Debian-Basis mit Basiskonfiguration erstellt werden. Anschließend werden wir verschiedene Serverdienste einrichten, die in einem lokalen Netz typischerweise genutzt werden. Dazu zählen:
DHCP (Dynamic Host Configuration Protocol – dynamische Zuweisung von IP-Konfigurationen für Clients)
NFS (Network File System – Dateizugriff für Linux-Clients)
CUPS (Common Unix Printing Service – Druckdienste für Linux-Clients)
Samba (SMB – Datei- und Druckserver für Windows-Clients)
Domain-Controller (Linux als Domänen-Controller für Windows-Clients)
MySQL (Aufbau eines relationalen Datenbankmanagementsystems)
Apache (der Webserver – Aufbau eines Intranets)
Klingt spannend? Ist es auch! Aber eins nach dem anderen. Schließlich wurde Rom auch nicht an einem einzigen Tag erbaut. Also nehmen wir uns einen Dienst nach dem anderen vor, um zu sehen, wie er installiert, konfiguriert und getuned wird – und welche Stolperfallen existieren, die wir vielleicht umgehen können.
Zurzeit ist alles in einem einfachen Peer-to-Peer-Netzwerk angeordnet – soweit es die Windows-Rechner angeht. Allerdings gibt es noch zwei Linux-Rechner, die im Moment noch nicht mit den Windows-Rechnern kommunizieren, sondern als Stand-Alone-PCs ihren Dienst verrichten.
Das Ganze stellt sich also folgendermaßen dar:
Abb. T.1: Ausgangskonfiguration des Netzwerks
Wie Sie sehen, gibt es bisher keine zentrale Instanz, die eine – wie auch immer geartete – Verwaltungsfunktion übernimmt (außer Ihnen in der Funktion des Administrators). »Okay!«, werden Sie vielleicht denken, »Aber warum sollten wir das ändern?« Danke für die Vorlage! Hier kann ich Ihnen gleich einige Gründe nennen:
Ab einer bestimmten Größe wird ein Peer-to-Peer-Netzwerk schwer zu administrieren, da die Ressourcen auf jedem einzelnen Rechner verwaltet werden müssen – das bedeutet viel Aufwand für den armen Administrator. Man spricht von einer Grenze von ca. 10 Workstations. Meines Erachtens macht es aber aus den weiter unten genannten Gründen durchaus Sinn, auch bei weniger Clients bereits einen Server zu installieren.
Eine zentrale Verwaltung ermöglicht die Konfiguration bestimmter Ressourcen auf einem zentralen Rechner – Server genannt. Damit müssen eben nicht alle Clients einzeln konfiguriert werden. Das beinhaltet zum Beispiel die IP-Konfiguration und Datei- und Druckdienste.
Eine zentrale Datenhaltung ermöglicht eine einfache Backup-Strategie, da nur die Daten vom Server gesichert werden müssen – nicht von den Clients.
Einige Dienste können nur zentral angeboten werden, wie zum Beispiel das Intranet. Ein Webserver auf jedem Client macht nun wirklich keinen Sinn. Auch ein relationales Datenbanksystem auf jedem Client ist unsinnig. Greifen mehrere Clients auf ein und dieselbe Ressource zu, macht ein Server grundsätzlich Sinn.
Überzeugt? Noch nicht ganz? Na dann lassen Sie uns doch gleich mal einen Blick auf den ersten Serverdienst DHCP werfen und schauen, was dieser Dienst für unsere Clients bereitstellt.
Moment! Haben wir da nicht noch etwas vergessen? In der Einleitung habe ich damit geprahlt, dass dies ein praktisches Lehrbuch sei und Sie aufgefordert, jeden Schritt und jede Übung praktisch nachzuvollziehen – allerdings an einem Übungsrechner!
|
Ich empfehle Ihnen nachdrücklich, Ihr neues Wissen nicht in einer Praxisumgebung zu erproben, sondern zunächst in einer Laborumgebung, Lab genannt. Ein verantwortungsbewusster Administrator wird größere Konfigurationsänderungen an einem Server oder dem Netzwerk immer zunächst im Lab ausgiebig testen, bevor diese in die Produktivumgebung eingebracht werden. |
Natürlich ist es unter normalen Umständen nicht notwendig, das Produktivnetzwerk exakt nachzubilden. Es reicht, wenn alle wesentlichen Komponenten modellhaft nachgebildet sind. Alle Windows-Clients innerhalb unseres Netzwerks können also durch einen einzigen Client dargestellt werden, ebenso wie die Linux-Rechner. Haben Sie in der Praxis einen hochwertigen Server mit zwei Prozessoren und 2 GB RAM, können Sie diesen im Lab durch einen einfachen Rechner ersetzen, da dieser nicht unter Last steht. Es reicht, wenn die Rechner die Mindesthardware-Anforderungen für die jeweilige Plattform (hier also unser Debian-Linux) erfüllen. Werfen wir also einen Blick auf unser Lab.
Wir verwenden das Subnetz 192.168.1.0/24, da dieses auch im Praxis-LAN eingesetzt wird. Dabei erhält der Debian-Server die IP-Adresse 192.168.1.1 und die Clients 192.168.1.100 und 192.168.1.101. Als Client können Sie einen beliebigen Windows-Computer verwenden, ich gehe hier von Windows XP und Windows 7 aus. Die Windows-Systeme verhalten sich (bis auf wenige Ausnahmen) aber alle vergleichbar.
Außerdem haben wir im Produktionsnetzwerk noch zwei Linux-Rechner, die wir auch darstellen wollen, indem wir einen Linux-PC konfigurieren und in unser Lab einbinden. Haben Sie nur zwei PCs zur Verfügung, können Sie auf dem Client ein Dualboot-System mit Windows und Linux aufsetzen und je nach Bedarf das passende Betriebssystem booten. Im Fall einer virtuellen Umgebung ist das wechselseitige Starten zweier Gastsysteme ohnehin kein Problem.
Welche Linux-Distribution und -Version Sie verwenden, ist clientseitig egal. Wir haben kaum Anforderungen an den Client, daher erfüllen fast alle – auch die älteren – Distributionen unsere Kriterien. Installieren Sie einfach Ihr Lieblings-Linux oder eines, mit dem Sie bereits ein wenig Erfahrung gesammelt haben, zum Beispiel SuSE oder Red Hat.
Abb. T.1: Laborumgebung für den Backoffice-Server
Dies gilt natürlich grundsätzlich auch für den Server. Zwar gehe ich hier auf Debian GNU/Linux Wheezy ein, doch sind die Netzwerkdienste zu einem großen Teil distributionsunabhängig. Sie werden also ebenso wie bei den Grundlagen auch bei den Netzwerkdiensten einen Nutzen aus diesem Buch ziehen können, auch wenn Sie eine andere Distribution verwenden. Besonderheiten bei der Installation oder Konfiguration sind meistens überschaubar und schnell zu erfassen.
Im ersten Teil dieses Buches zeige ich Ihnen die Grundlagen der Linux-Systemadministration. Bis auf die Debian-spezifischen Kapitel 1 bis 3, sind die anderen Kapitel dieses Teils zum größten Teil allgemeingültig, also auch auf andere Linux-Distributionen anwendbar. Sie lernen hier zunächst einmal Ihr Serversystem kennen, erfahren, wie der Linux-Systemstart funktioniert und wie Sie ihn beeinflussen können und lernen, wie Sie Benutzer und Rechte verwalten.
Anschließend lernen Sie Ihren Admin-Werkzeugkasten kennen. Die Basis-Schnittstelle zwischen dem Linux-System und dem Benutzer ist die Shell. Unter Linux wird standardmäßig die Bash (Bourne Again Shell) genutzt. Die so unscheinbare Eingabezeile ist unglaublich leistungsfähig und verfügt sogar über eine eigene Shellskript-Sprache. Ich zeige Ihnen, wie Sie die Bash optimal nutzen können.
Im Gegensatz zum Integrationskonzept von Windowsanwendungen setzt Linux auf das Konzept hochspezialisierter kleiner Werkzeuge, die entsprechend miteinander kombiniert werden können, um das gewünschte Ergebnis zu erzielen. Das macht in der Regel mehr Arbeit, lässt aber in puncto Flexibilität Windows weit hinter sich. Die wichtigsten Kommandozeilen-Werkzeuge stelle ich Ihnen vor.
Anschließend wird es Zeit, sich der bereits angesprochenen Shellskript-Sprache zu widmen. Fast alle Konfigurationsskripts von Linux sind in der Shellskript-Sprache geschrieben, so dass es zum Standard-Repertoire eines Linux-Administrators gehört, zumindest Grundkenntnisse in der Shellskript-Programmierung zu besitzen.
Bisher haben Sie Ihrem System gesagt, was SIE wollen – nun schauen wir mal, was Ihnen das System zu sagen hat! Ihr System kommuniziert mit Ihnen über zwei Wege:
Die Standardausgabe, in der Regel der Bildschirm. Hier erhalten Sie Meldungen, die die einzelnen Programme ausgeben und diverse Systeminformationen. Jedoch bei Weitem nicht jeder Vorgang wird auf der Standardausgabe ausgegeben – das würde Sie als Benutzer auch binnen weniger Sitzungen an den Rand eines Nervenzusammenbruchs bringen. Um das zu verhindern, bietet Linux eine weitere Kommunikationsschnittstelle:
Die Logdateien. Das zentrale System zur Organisation und Verwaltung von Logmeldungen heißt Syslog. Mit dessen Hilfe können der Linux-Kernel, Programme und Dienste ihre Fehler- oder Statusinformationen in beliebige Logdateien schreiben.
Oftmals vernachlässigen Systembetreuer Ihre Logdateien, dabei geben diese dem Leser jede Menge Informationen über den Status des Betriebssystems und der Dienste und Programme. Ich zeige Ihnen, wie Sie die Logdateien optimal zur Fehleranalyse nutzen können und wie Sie mit Log-Rotation dafür sorgen, dass keine der Logdateien aus den Nähten platzt.
Anschließend begeben wir uns in das Zentrum von Linux – dem Linux-Kernel. Zwar bieten die Standard-Kernel der einzelnen Distributionen in der Regel schon die am häufigsten genutzten Features, jedoch ist es in Einzelfällen immer wieder notwendig, einen angepassten Kernel zu erstellen. Sie werden lernen, wie Sie einen eigenen Kernel kompilieren können.
Auch wenn wir in der Regel auf der Konsole arbeiten werden, so möchte ich Ihnen zumindest eine Einführung in das X-Window-System (kurz: X) anbieten, das eine grafische Benutzeroberfläche für Linux-Systeme anbietet. Mit KDE und GNOME gibt es sehr ausgereifte Desktop-Manager mit vielen integrierten Applikationen, so dass Windows-Benutzer sich hier recht schnell heimisch fühlen dürften. Unter dem Aspekt eines Serversystems ist X in der Regel allerdings nicht erforderlich bzw. aufgrund des Ressourcenhungers nicht erwünscht. In manchen Szenarien ist X jedoch eine echte Hilfe, so dass Sie in jedem Fall Grundkenntnisse über die Installation und Konfiguration haben sollten.
Die letzten drei Kapitel dieses umfangreichen ersten Teils beschäftigen sich mit den Netzwerkgrundlagen und der Einrichtung Ihres Servers zur Nutzung im Netzwerk. Hierzu werden wir auch einen SSH-Server installieren, damit Sie Ihren Server zukünftig per SSH fernwarten (remote administrieren) können.
In den folgenden Teilen dieses Buches geht es dann ausschließlich um die Netzwerkdienste, die aus einem Linux-System einen Linux-Server machen. Doch eines nach dem anderen – lassen Sie uns erst einmal laufen üben, bevor wir fliegen lernen ... ja, ja, ich weiß, der Spruch ist abgedroschen! Er hat aber dennoch seine Gültigkeit.
Also dann, lassen Sie uns einsteigen in das spannende Abenteuer »Linux-Server«!
Bibliografische Information der Deutschen Nationalbibliothek
Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über <http://dnb.d-nb.de> abrufbar.
ISBN 978-3-8266-8202-5
1. Auflage 2014
www.mitp.de
E-Mail: kundenbetreuung@hjr-verlag.de
Telefon: +49 6221 / 489 -555
Telefax: +49 6221 / 489 -410
© 2014 mitp, eine Marke der Verlagsgruppe Hüthig Jehle Rehm GmbH Heidelberg, München, Landsberg, Frechen, Hamburg
Dieses Werk, einschließlich aller seiner Teile, ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlages unzulässig und strafbar. Dies gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen.
Lektorat: Sabine Schulz
Sprachkorrektorat: Petra Heubach-Erdmann
electronic publication: III-satz, Husby, www.drei-satz.de
Coverbild: © sergios – fotolia.de
Dieses Ebook verwendet das ePub-Format und ist optimiert für die Nutzung mit dem iBooks-reader auf dem iPad von Apple. Bei der Verwendung anderer Reader kann es zu Darstellungsproblemen kommen.
Der Verlag räumt Ihnen mit dem Kauf des ebooks das Recht ein, die Inhalte im Rahmen des geltenden Urheberrechts zu nutzen. Dieses Werk, einschließlich aller seiner Teile, ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheherrechtsgesetzes ist ohne Zustimmung des Verlages unzulässig und strafbar. Dies gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und Einspeicherung und Verarbeitung in elektronischen Systemen.
Der Verlag schützt seine ebooks vor Missbrauch des Urheberrechts durch ein digitales Rechtemanagement. Bei Kauf im Webshop des Verlages werden die ebooks mit einem nicht sichtbaren digitalen Wasserzeichen individuell pro Nutzer signiert.
Bei Kauf in anderen ebook-Webshops erfolgt die Signatur durch die Shopbetreiber. Angaben zu diesem DRM finden Sie auf den Seiten der jeweiligen Anbieter.
