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:
Abbildung 1 |
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:
Abbildung 2 |
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:
Abbildung 3 |
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...
|