Beispiel-Aufbau eines kleinen Firmen-Netzwerks &

Allgemeines zur Sicherheit in Netzwerken

Warum Linux?

Vielen Linux-Administratoren ist schon seit langem klar: das Thema Sicherheit ist eines der umfangreichsten und wichtigsten im Umgang mit dem freien Betriebssystem und sollte vor allem von (wenn auch kleinen) Firmen keinesfalls stiefmütterlich behandelt werden. Schließlich entscheidet man sich mit Linux auch oder gerade für den Leitgedanken der Sicherheit - wenn denn das System richtig administriert wird und ein gutes Sicherheitskonzept für das gesamte Netzwerk ausgearbeitet wurde.

Einige Windows-Jünger werden jetzt fragen, warum das denn nicht auch mit ihrem Lieblings-"take-it-easy"-Betriebssystem geht. Antwort: Linux ist als freies Unix-Derivat einfach besser, weil:

• Linux und alle seine GPL-Tools existieren als Open-Source! So bleiben auf Dauer keine Programmierfehler unentdeckt.

• So suspekte und sicherheitsgefährdende Elemente wie VBA, ActiveX oder Makroviren machen Linux nicht zu schaffen.

• Viren und Trojaner haben aufgrund der übersichtlichen Prozessstruktur, der Benutzerrechte und der Systemüberwachungstools keine Chance.

• LKMs (Loadable Kernel Modules) und andere ungebetene Gäste können sich nicht im System einnisten, ohne mit einem der vielfältigen Tools erkannt zu werden.

• Mit der übersichtlichen Konfiguration (ohne kryptische Registry) bleiben auch die Details des Rechnerstarts nicht im Verborgenen.

• Wenn ein Bug ausfindig gemacht wurde, stehen Updates für Programme unter Linux schnell bereit.

• Administrationsprogramme stehen bei den meisten Distributionen in einer üppigen Fülle zur Verfügung. So können auch unsichere Rechner blitzschnell secure gemacht werden.

• Hängende Prozesse können unter Linux ohne Speicherverlust beendet und fehlerfrei neu gestartet werden.

• Linux lässt sich übersichtlich konfigurieren und bleibt im laufenden Betrieb stabil.

• Stabilität bedeutet Datensicherheit - hier schlägt Linux auch Windows NT um Längen!

• Ressourcen werden unter Linux besser genutzt als bei jedem anderen Betriebssystem - nicht nur Windows, auch der Urklotz Unix wird in dieser Hinsicht geschlagen...

• Mit finanziellen Vorteilen will ich hier gar nicht erst anfangen - diese sind offensichtlich, auch wenn dies ein gewisser Bill gern bestreitet *g*.

Und so weiter und sofort. Viele Vorteile von Linux sind erst im Detail erkennbar, der größte ist aber doch, dass man bei Linux noch weiß, was hinter den Kulissen des Betriebssystems abläuft und dass man beim Thema Sicherheit nicht von seinem eigenen System geschlagen wird. Deswegen Linux! Doch Linux hat nicht nur Vorteile. Die größten Nachteile sind wohl immernoch die teilweise umständliche Konfiguration des Systems und der Einsatz im Desktop-Bereich, wo es sich noch nicht so richtig durchsetzen kann, auch wenn die letzten Jahre in dieser Hinsicht schon eine positive Tendenz erkennen lassen. Vor allem gibt es auch noch Probleme mit der Einbindung einzelner und vor allem exotischer Hardwarekomponenten, wobei die meisten Schwierigkeiten mit der Tatsache einhergehen, dass Hardwaretreiber nur für bestimmte Kernel und manchmal nur für bestimmte Distributionsversionen (die teils gepatchte Kernel enthalten) angeboten werden und somit kaum kompatibel sind. Läuft das System jedoch erst einmal fehlerfrei, so kann es in Hinsicht auf Funktionalität und Ausstattung kaum noch von einem anderen Betriebssystem geschlagen werden. Die von Windows angebotenen Klicki-Bunti-Mausi-Tools kann man da einfach nur noch unter Ulk verbuchen.

Qual der Wahl - die Distribution

Doch Linux ist nicht gleich Linux. Jede Distribution hat ihre Vor- und Nachteile. Welche ist also die beste in Hinsicht auf Sicherheit?! Die Antwort darauf ist eine subjektive Auslegungssache; beherrscht man ein bestimmtes System, so kann man es zweifelsohne sicher machen. Auch hier steckt der Teufel im Detail. Die Faktoren, die die Sicherheit einer bestimmten Distribution beeinflussen, sind nicht etwa die einzelnen Serverprogramme - diese können individuell auch durch andere Versionen ersetzt werden. Die Faktoren sind hingegen, wie die Distribution Informationen über das System bereitstellt, wie sicher das Laden des Systems erfolgt, welche Module standardmäßig geladen werden oder auch welche lokalen Programme enthalten sind, die nur von dieser Distribution z.B. für die Administration des Systems bereit gestellt werden (yast bei SuSE, dselect bei debian, drakconf bei Mandrake etc.). Allgemein und objektiv betrachtet ist eine abgehärtete Distribution ohne viel Schnickschnack wie Debian GNU/Linux oder Slackware die beste Wahl für den Einsatz auf Serversystemen, hier müssen allerdings einige Abstriche in Bezug auf standardmäßige Konfigurationstools und Komfort gemacht werden. Andersherum ist es bei SuSE, Mandrake oder RedHat. Diese Distributionen sind zwar nicht so stabil und ressourcensparend wie Debian oder Slackware, können aber durchaus als ausreichend sicher angesehen werden und beinhalten einfache und komfortable Konfigurationstools (z.B. yast oder sax2 bei SuSE), die es vor allem für den Einsatz im Desktop-Bereich oder als Administrationsstation rechtfertigen...

Die Grundsteine der IT-Sicherheit

Soviel zum Einstieg. Wir gehen jetzt einmal davon aus, dass eine Linux-Distribution ordnungsgemäß installiert wurde (Anleitungen dazu gibt's in jedem besseren Linux-Buch, weiterhin sind etliche Tutorials im Netz zu finden...). Ein wichtiger Aspekt ist zunächst einmal, dass man sich angewöhnen sollte, soviel wie möglich nicht als root, sondern als normaler Benutzer zu erledigen. Wird ein laufender Prozess gehackt, kann ein Angreifer dadurch nicht so einfach root-Rechte erhalten und weitere Schäden anrichten. Als Root sollte man sich nur für administrative Aufgaben einloggen.

An einem Server ist es weiterhin enorm wichtig, dass nur die Serverdienste laufen, die auch unbedingt zur Verfügung gestellt werden müssen. Wichtig ist dabei das Motto: so wenig wie möglich, so viel wie nötig! Nicht alle Dienste, die auf den ersten Blick benötigt werden, braucht man am Ende dann auch. Vor allem die r-Services (rcp, rlogin, rsh etc.) sollten abgeschaltet werden, da sie kein Passwort für einen Login verlangen, sondern darauf ausgelegt sind, vertrauenswürdige Rechner zuzulassen - und dies stellt in Tagen des IP-Spoofings ein leichtsinniges Risiko dar. Mit wenigeren Services und guten Firrewall-Policies verringert sich auch die Gefahr eines Denial-of-Service-Angriffes, welcher dem System erheblichen Schaden zufügen könnte. Vor allem sollte man auch vorsichtig mit unsicheren Protokollen wie Telnet, SMTP, SNMP oder FTP umgehen. Deren unverschlüsselte Verbindung beinhaltet ein großes Risikopotential, da Passwörter durch eingeschleuste Sniffer schnell und einfach ausgespäht werden können. Man sollte hingegen Protokolle wie SSH (anstelle von TELNET) bzw. SFTP / SCP (anstatt FTP) verwenden, die mit verschlüsselten Verbindungen agieren oder zumindest die Restriktionen bei SNMP und anderen Protokollen höher setzen. Und bitte: auch wenn in letzter Zeit WLANs immer beliebter werden, so ist es doch allgemein bekannt, dass sie gegen Tools wie AirSnort nicht ausreichend Schutz bieten. Man sollte also wenn möglich immer mit konventionellen Kabel-Netzwerken arbeiten.

Schutz vor externen Angreifern

Ebenfalls empfindlich sollte man mit der Vergabe von Benutzer- bzw. Gruppenrechten umgehen. Ein Benutzer sollte in seiner Arbeit nicht eingeschränkt werden, er sollte aber auch nicht zu viele Privilegien erhalten und erst recht nicht in die Administration des Systems eingreifen dürfen. Das wäre ein fataler Fehler. Ein Administrator muss sicher darauf bedacht sein, dass die Anbindung an das Internet mit seinen mehreren Millionen Rechnern ein großes Gefahrenpotential beinhaltet und dass es auf dieser Welt mehr als einen Cracker und zigtausende Skript-Kinder gibt, die ganze Klasse-B- oder auch -A-Netzwerke auf der Suche nach verwundbaren Rechnern abscannen. Dementsprechend sollte auch eine Firewall auf mindestens Paketfilter-Ebene das lokale Netzwerk logisch vom Internet abtrennen, um auf dieser Basis schon einmal den größten Traffic von Breitband-Scans abfangen zu können. Eine gute Hilfe dabei ist auch der Linux-Standard-Daemon scanlogd, der Scans erkennt und automatisch in die Datei /var/log/warn einträgt. Um die Rechner dies- und jenseits der Firewall vorsorglich vor Viren oder auch Spam aus dem Internet, aber auch aus dem lokalen Netz zu schützen, ist es zudem empfehlenswert, auf der Firewall einen Mailfilter zu installieren, der unerwünschte Contents filtert und die Mails mittels eines Virenscanners auf gefährliche Daten überprüft.

Ob es sich bei der Firewall um einen einfachen PC oder um spezialisierte Hardware handelt, kommt größtenteils auf den Datentransfer an, der zwischen beiden Seiten anfällt. Muss die Bandbreite erhöht werden, so sollte auf Hardware-Firewalls zurückgegriffen werden.

Wichtig ist, dass Dienste wie LDAP oder SNMP vom Internet heraus nicht erreicht werden und Internet-Rechner keine Anfragen an die Workstations im LAN stellen dürfen, so dass empfindliche Daten geschützt bleiben. Dies lässt sich vornehmlich damit erreichen, dass die Dateien /etc/hosts.allow bzw. /etc/hosts.deny die entsprechenden Einträge erhalten, so dass nur bestimmte Rechner bestimmte Dienste abrufen können. IP-Spoofing sollte dabei nicht vergessen werden, die Maßnahme stellt aber zumindest einen ersten wichtigen Schritt dar und sollte auf allen Rechnern des LANs durchgeführt werden.

Vertrauen ist gut, Netzsicherheit besser...

Doch die Angreifer kommen meistens eben nicht aus dem Internet. Eine Studie hat gezeigt, dass über 90% der Angriffe und Einbrüche von Rechnern im lokalen Netz ausgehen. Seien es rachesüchtige Mitarbeiter, gelangweilte Beamte oder neugierige Skript-"Kinder" - die Statistik zeigt, dass man das lokale Netz eben auch in besonderer Art und Weise schützen sollte. So ist eine Abtrennung von Server- und Workstation-Bereich unumgänglich. Hierein spielt auch noch ein anderer Faktor: zu der logischen Sicherheit kommt auch noch die physikalische Sicherheit. Der Zugang zu Switches, Servern und Admin-Stations sollte auch nur den Administratoren gewährt werden - normale Mitarbeiter sollten davon ausgeschlossen bleiben. Vor allem auch sollte man Angestellte, die man vielleicht schon über Jahre hinweg persönlich kennt, nicht bevorzugen, nur um ihnen ein wenig mehr Komfort zukommen zu lassen. Angreifer operieren versteckt und präsentieren sich meistens nicht in der Öffentlichkeit (die wenigen, die dies tun, sind entweder selbstverliebte Egoisten oder aber Skript-Kinder, die mal etwas Medienluft schnuppern wollen), also ist Vorsicht geboten. Genau hier sollte auch noch einmal die Vergabe von Benutzerrechten zur Sprache kommen: wie schon bei den Services gilt das Motto: so wenig wie möglich, so viel wie nötig! Und nicht immer benötigt ein Benutzer höhere Rechte, nur um seiner Arbeit nachgehen zu können. Eine kleine Änderung bei den Dateirechten genügt oft schon; wenn das nicht hilft, kommt man mit einer restriktiven Vergabe von sudo-Rechten meist weiter. Webmaster haben oftmals die dumme Angewohnheit, gleich nach root-Rechten zu schreien, nur um Dateien auf dem Server zu speichern, den Webserver konfigurieren und diesen neustarten zu können. Auch hier reicht der sinnvolle Einsatz von sudo und ftp (bzw. sftp) aus, mit einem ssh-Tunnel gänge das sogar verschlüsselt.

Beim Thema Schutz vor internen Angreifern gibt es noch einige Punkte zu beachten. Z.B. ist der gezielte Einsatz eines Virenscanners nicht nur auf der Firewall, sondern auf jedem Workstation- und Server-Rechner des LANs nicht nur sinnvoll, sondern weitgehend notwendig, um nicht von ungebetenen Gästen heimgesucht zu werden (am allermeisten hängt dies allerdings vom eingesetzten Betriebssystem ab; da Linux noch nicht zu 100% reif für den Desktop ist, wird man vielleicht doch lieber auf eine neuere Windows-Version setzen - die Chancen für eine Änderung in diesem Bereich noch innerhalb des nächsten Jahres stehen allerdings nicht schlecht!). Ebenso sollten nicht wahllos viele Pakete auf den Rechnern installiert werden, da sich die Gefahr, dass ein Programm einen Bug enthält, der zu root-Rechten führt, proportional mit der Anzahl installierter Pakete erhöht. Ein Angreifer, der einen Account auf dem entsprechenden System hat, könnte so leicht das gesamte Netz infiltrieren. Ebenfalls sollte eine weitere Gefahr nicht unterschätzt werden: Sniffer! Sie stellen nach wie vor ein großes Problem bei der internen Netzsicherheit dar und werden nicht nur von einschlägigen Rootkits gern dazu verwendet, um über das Netzwerk Daten und Passwörter abzufangen. Nicht nur Hubs sind dabei eine Gefahrenquelle; wie mittlerweile bekannt sein dürfte, können auch einige Switches durch ARP-Spoofing dazu gebracht werden, ihre Daten als Broadcast an alle angebundenen Rechner zu versenden, wodurch ein Sniffer agieren kann. Um dem Einhalt zu gebieten, sollte ein Tool eingesetzt werden, welches die Rechner, deren Netzwerkkarten im sniffer-typischen promiscious mode laufen, ausfindig macht und den Admin alarmiert bzw. diese Rechner automatisch sperrt.

Demilitarisierung

Die logische Sicherheit zwischen Serverbereich und Workstations sollte dadurch sicher gestellt werden, dass man die Server in einer DMZ (DeMilitarisierte Zone) unterbringt. Dabei kommt wiederum ein Rechner (ein so genannter Bastion-Host) zum Einsatz, in welchen die von der ersten Firewall schon gefilterten Daten einfließen und von dem dann zudem noch die Daten des lokalen Arbeitsbereiches gefiltert und ausgewertet werden. Dies macht klar, dass dieser Rechner sozusagen die Schnittstelle aller drei Bereiche darstellt und der Traffic enorm werden kann. Deswegen war es auch notwendig, die Internet-Daten schon einmal vorzusortieren, damit DoS-Angriffe oder Scan-Attacken auf diesen lokalen Knotenpunkt des Netzwerks keine Chance haben. Bei dem Bastion-Host sollte es sich zudem um einen schnellen, einfach aber sinnvoll strukturierten Rechner handeln, auf dem ein light-weight Linux-System (Debian GNU/Linux) mit einer minimalen Anzahl installierter Softwarepakete läuft. Schnelle Netzwerkkarten, viel RAM und möglichst mehrere CPUs können ebenfalls dazu beitragen, dass dieser Rechner alle Aufgaben eines Knotenpunktes des Netzwerks übernehmen kann.

Der eben beschriebene Netzwerkaufbau lässt sich nun also wie folgt darstellen:

Um die Bandbreite zwischen Internet und Server-Bereich möglichst hoch zu halten, wäre es allerdings am produktivsten, für die Server, die die Internetservices bereitstellen, einen eigenen Anschluss zum Netz zu legen, welcher komplett abgetrennt ist vom LAN. Das größte Problem dabei ist die Kostenfrage, die ein zusätzlicher Internetzugang verursacht; auch kleinere Firmen haben -und vor allem in Zeiten der Konjunkturflaute- oft nicht den nötigen Geldbetrag übrig, der eine solche Lösung finanzieren könnte. Ein Kompromiss wäre, den File- und den Mailserver des LANs vom anderen Serverbereich abzutrennen, da über diese wohl der meiste lokale Netz-Traffic läuft. Die folgende Grafik zeigt diese Lösung:

Das geeignete Konzept hängt allerdings auch davon ab, worin die Schwerpunkte der Firma liegen. Liegen sie mehr auf dem Anbieten und Vermarkten von Webservices, ist eine Trennung von Internet und lokalem Bereich aufgrund der benötigten Bandbreite fast unumgänglich. Liegen sie mehr auf der Funktionalität und Sicherheit des LANs und sollen Webservices eher sekundär bereitgestellt werden, können beide Bereiche auch zusammen fallen - die logische und physikalische Trennung sollte allerdings nicht vergessen werden.

Administration des Netzes

Das Problem, was nun besteht ist, dass dieses Netz auch sicher administriert werden will, ohne dass der Administrator immer an jeden Server laufen und Änderungen lokal vornehmen muss. Ein Admin-Rechner muss also her! Bei dem ersten Netzwerkaufbau mit vereinter Internet-/LAN-Server-Struktur stellt sich das Ganze ziemlich einfach dar:

Wie man unschwer erkennen kann, ist die Admin-Station direkt an den Serverbereich gekoppelt. Mit der richtigen (ssh-) Konfiguration können so auch Bastion-Host und Firewall sicher administriert werden. So könnte man Einstellungen treffen, dass nur die IP-Adresse der Admin-Station auf die Server und die Firewalls Zugriff haben darf. Zu bedenken wäre allerdings, dass ein zusätzlicher ssh-Zugriff auf die Firewall und den Bastion-Host ein weiteres potentielles Risiko für die Sicherheit des Netzwerks darstellt. Vor allem sollte man nicht davon ausgehen, dass wirklich auch nur Rechnern mit zugriffsberechtigten IP-Adressen der Zugang zu den konfigurierten SSH-Servern gewährt wird. Stichwort: IP-Spoofing! Genau deswegen sollte auch "bekannten" Rechnern nicht bedingungslos vertraut werden. Ein ssh-Key mit einer Schlüssellänge von 2048 Bit sowie eine starke Passphrase sollten das Mindeste sein, um den Zugang abzusichern. Will man ganz auf Nummer sicher gehen, sollte man die Firewall und den Bastion-Host dann doch lieber lokal administrieren. Wichtig ist auch, die Zugangspasswörter seiner Benutzer auf Sicherheit zu überprüfen, was Komplexität und Originalität betrifft. Es sollten nur alphanummerische Passwörter mit mehr als 8 Ziffern/Buchstaben verwendet werden dürfen, zudem sollten die Passwörter regelmäßig gegen andere und dem vorigen Passwort unähnliche Passwörter ersetzt werden. Ein im Hintergrund laufendes crack hat bei der Einhaltung von Passwortrichtlinien auch noch keinem geschadet,  Man sollte allerdings vorsichtig sein, was das Auditing des eigenen Netzes betrifft. Programme wie nessus, saint oder eben auch crack, die das interne Netz und den lokalen Rechner auf Sicherheitslücken überprüfen, sind zwar nicht verboten, wandern aufgrund ihrer Aktivitäten aber auf einem schmalen Grat zwischen Legalität und Illegalität und sollten daher nur in Absprache mit dem Firmenchef oder besonders vorsichtig eingesetzt werden. Gesetze zu diesem Thema sind zu allgemein gehalten, als dass sie einem Administrator das Auditing des eigenen Netzes erlauben würden, ganz im Gegenteil: das Zugangskontrolldienste-Schutzgesetz (ZKDSG) stellt nicht nur jede Umgehung eines Zugangsschutzes unter Strafe, sondern auch den Versuch dessen. Dies macht einen Punkt im Arbeitsvertrag des Administrators schon fast unverzichtbar, der beinhaltet, dass Auditing des lokalen Netzwerkes ausdrücklich genehmigt wird. Damit ist man auf der sicheren Seite und der Arbeitgeber kann einem nun mehr wenig anhaben.

Weiter im Text: auf die Admin-Station sollte niemand Zugriff haben und Backups sowie Checksummen sollten regelmäßig erstellt und mit älteren Versionen verglichen werden, um Änderungen an systemrelevanten Dateien sofort erkennen zu können. Wichtig: alle zu speichernden Daten der Backups und Checksummen sollten verschlüsselt oder auf ein schreibgeschütztes Medium überspielt werden, so dass sie nicht von jedem gelesen oder schlimmer noch verändert werden können. Auch wenn man denkt, das eigene Netz sei sicher und regelmäßig Updates aller installierten Pakete durchführt (vor allem bei Remote-Anwendungen), sollte man sich nicht faul auf die Haut legen (aber ich denke, ein Administrator dürfte sowieso nicht dazu kommen) und sich die Mühe machen, stetig an der Verbesserung "seines" Netzes zu arbeiten.

Logging für Fortgeschrittene

Unter dem Aspekt, dass man auch seinem eigenen Rechner nicht trauen kann und darf, fällt auch die Idee des Einsatzes eines separaten Logging-Rechners (siehe obere Abbildung). Gelangen Angreifer (sei es durch Fehler in lokalen Programmen und in Serveranwendungen, die ein Angreifer ausnutzt, noch bevor der Admin Updates einspielen konnte oder aber auch durch Fehler in der Administration) einmal in ein System, so werden sie diesen Eingang das nächste Mal sicher nicht mehr benutzen, sondern Rootkits einspielen, die ihnen Hintertüren öffnen, durch welche sie das nächste Mal in den Rechner eindringen können und systemrelevante Programme verändern, so dass ihre Aktivitäten verborgen bleiben.

Beispiel: ein Angreifer gelangt in ein System, installiert ein Rootkit, welches einen Trojaner installiert, der über ein LKM gestartet wird. Über diesen Trojaner kann er immer wieder ins System gelangen, doch würde der ungebetene Gast sicher recht schnell entdeckt werden. Nicht so, wenn die Programme, die Daten über den Trojaner ausgeben, modifiziert werden. Wichtige Standardanwendungen sind dabei z.B. ls bzw. ll, die den Trojaner als Datei verraten würden, ps bzw. pstree, die ihn als Prozess verraten könnten, netstat bzw. nmap, die ihn als remote-Anwendung denunzierten oder aber auch lsmod, welches das Modul anzeigt, das den Trojaner lädt (gute LKMs können sich davor aber auch selber schützen, indem sie die Tabelle der eingebundenen Module verändern). Zudem wird der Angreifer (oder auch das Rootkit) die Logging-Dateien verändern, seine Spuren verwischen...

Für einen Administrator stellt sich nun natürlich die Frage, wie er diesem Treiben Einhalt gebieten kann. Fakt ist, dass er keinem seiner Rechner vertrauen kann, da er davon ausgehen muss, dass das System, über das er relevante Daten beziehen will, verändert worden sein könnte (auch ein sehr interessantes Thema von Seiten des Rechts aus - wenn ein Rechner gehackt wurde, wie will ein Admin dann beweisen, dass die Log-Dateien, die Aussagen dazu machen, nicht verändert wurden?). Lösungen dafür sind wie sooft unter Linux sehr vielfältig (und das ist gut so, da es ein Angreifer um so schwerer hat, wenn er sich mit unbekannten Tools auseinander setzen muss und der Admin damit einen wichtigen Zeitvorteil herausholen kann). Tools gegen Rootkits oder die Veränderung der Prozesstabelle gibt es einige, zudem helfen wie o.a. Checksummen und Backups bei Systemwiederherstellung und Ausfindigmachen von unerwünschten Änderungen. Richtig konfiguriert, bietet syslog als Standard-Log-Daemon eines Linux-Systems ebenfalls viele Möglichkeiten, ein System sicher zu überwachen. So z.B. können Logs anstatt lokal auch auf einem beliebig anzugebenden Host (Log-Server) abgespeichert werden, wenn auf diesem der syslog-Daemon so eingestellt ist, dass er Daten von dem entsprechenden Rechner empfangen kann. Wird der Log-Server entsprechend abgesichert, so dass ein Angreifer kaum eine Chance hat und auch nicht durch dasselbe Loch wie auf dem zuvor geknackten Rechner eindringen kann, erhält ein Admin damit ein zuverlässiges Logging-System. Allerdings muss man beachten, dass bei dem Standard-syslog die Logs unverschlüsselt über das Netz wandern. Dies kann ein Angreifer ausnutzen, indem er aktiv in die Verbindung eingreift und die Daten manipuliert. Doch Linux wäre nicht Linux, wenn es nicht auch hierfür Lösungen gebe. syslog-ng ist z.B. solch eine - mit einer verschlüsselten Verbindung, wie sie hier aufgebaut wird, wird es für einen Hacker doch "relativ" schwer, eine Verbindung zu hijacken.

Der Log-Server kann durch seine separierte Stellung auch sehr gut dafür verwendet werden, um für die Überwachung der Server und Firewall-Rechner verantwortlich zu zeichnen. Mit SNMP, den entsprechenden Tools wie scotty, netsaint, MRTG, Big Brother und auch nmap sowie einer ausgeklügelten crontab-Liste können alle Rechner im Netz überprüft und Ausfälle bei einzelnen Systemen sofort dem Admin gemeldet werden. Mit einem ssh-Tunnel über den Bastion-Host kann der Admin auch sicher auf diesen Log-Server zugreifen und relevante Statistiken abrufen. Ebenfalls auf diesem System sollte ein Tool zum Aufspüren von Sniffern eingesetzt werden, welches nicht unerheblich zur Netzsicherheit beitragen kann. Alles in allem steht einem geregelten Ablauf innerhalb des Netzes so nichts im Wege.

Aber was ist damit...

Bei der Netzwerkarchitektur, die als Alternative zu der Verbindung LAN-/Internet-Server besprochen wurde (Abbildung 2), sieht der Einsatz von Admin-Station und Log-Server schon anders aus. Da es zwei getrennte Server-Bereiche gibt, muss mit deren Installation vorsichtig und logisch umgegangen werden. So sollte man keine direkte Verbindung der beiden Rechner zum lokalen und dem Internet-Serverbereich etablieren, wie Abbildung 4 verdeutlicht.

Abbildung 4

Die Probleme, die mit dieser Architektur entstehen würden, sind offensichtlich: knackt ein lokaler Angreifer einen Server im internen Netz oder dringt ein Unruhestifter in einen der Internet-Server ein, so hat er aufgrund fehlender Firewall automatisch leichteres Spiel beim Eindringen in den jeweils anderen vermeintlich abgetrennten Serverbereich und zusätzlich auch auf den Admin- und Logging-Rechner. Somit kann man diese "Lösung" wohl nicht als sehr sicher ansehen.

Ein Netz mit zwei getrennten Serverbereichen verursacht ja von Haus aus schon ein Mehr an Administrationsaufwand. Die optimal sichere Lösung wäre im vorliegenden Fall, zwei Admin-Stations und zwei Logging-Rechner einzusetzen, die jeweils für einen der beiden Teilnetze eingesetzt werden. Dies verursacht allerdings noch mehr Administrationsaufgaben, die ein Admin allein nur schwer bewältigen kann. Es sollte also nicht davor zurück geschreckt werden, noch einen zweiten Administrator einzusetzen, der einem ein wenig Arbeit abnehmen kann. Neben den beiden neuen Rechnern stellt allerdings auch ein Zweit-Administrator einen zusätzlichen Kostenfaktor dar, der von kleineren Firmen nicht unterschätzt werden sollte und vielleicht nicht finanziert werden kann.

Eine bessere Lösung? Ich muss ehrlich eingestehen, dass mir keine eingefallen ist (vielleicht fehlt es mir auch noch an Erfahrung, wer weiß). Meine Lösung würde einen Kompromiss zwischen Sicherheit und Kosten darstellen, der z.B. bei Abbildung 4 in einem PC am Knotenpunkt zwischen Internet- und LAN-Server-Bereich bestehen könnte, welcher Abfragen zwischen den Servern und Admin-Stations regelt.

Fazit

IT-Sicherheit ist ein viel zu komplexes Thema, als dass man es hier auch nur in einem Bruchteil seiner Fülle darstellen könnte. Wichtig für einen Administrator ist, dass er für sein Netz und die Rechner darin ein komplexes und auf die individuelle Situation abgestimmtes Sicherheitskonzept entwickelt, welches ein Spagat zwischen Kosten, Sicherheit und Administrierbarkeit vollbringt. Dieser Text sollte ein paar Anregungen geben, er erhebt allerdings keinesfalls den Anspruch auf Vollständigkeit oder Korrektheit. Wichtig zu sehen ist, dass dem Administrator mit Linux und seinen vielfältigen Tools ein komplexes Werkzeug in die Hand gegeben wird, welches -richtig konfiguriert- alle Aufgaben eines Netzwerkservers oder auch eines normalen Netzwerkrechners mit Sicherheit übernehmen kann. Stabilität, Ressourcenmanagement, Hochverfügbarkeit und eben auch Sicherheit sind nur einige der Aspekte, warum man sich anstatt anderer Betriebssysteme (vor allem von gewissen Firmen aus Redmond) für die Zukunft - für Linux entscheiden sollte...

(c) 2003 by RTC, www.linux-related.de
Dieses Dokument unterliegt der GNU Free Documentation License