IT-Academy Logo
Sign Up Login Help
Home - Betriebssysteme - Linux - Allgemeines - Linux härten



Linux härten

Anhand einer Red Hat 6.0 Installation wird erklärt, wie man sein System gegen Angriffe von außen schützen kann.


Autor: Jochen Berner (jberner)
Datum: 14-06-2002, 08:29:50
Referenzen: http://www.enteract.com/~lspitz/linux.html (der englische Originaltext)
Schwierigkeit: Fortgeschrittene
Ansichten: 13355x
Rating: 0.5 (2x bewertet)

Hinweis:

Für den hier dargestellte Inhalt ist nicht der Betreiber der Plattform, sondern der jeweilige Autor verantwortlich.
Falls Sie Missbrauch vermuten, bitten wir Sie, uns unter missbrauch@it-academy.cc zu kontaktieren.

[Druckansicht] [Als E-Mail senden] [Kommentar verfassen]



Übersicht

Unternehmen auf der ganzen Welt akzeptieren Linux als Plattform für ihre Produktivsysteme. Indem sie sich an das Internet anbinden um Dienste anzubieten werden sie gleichzeitig zum Ziel. Damit man solche Systeme schützen kann, behandelt dieser Artikel die Grundlagen der Sicherung eines Linuxsystems. Die verwendeten Beispiele basieren auf Red Hat 6.0, sollten sich aber auf die meisten Distributionen übertragen lassen.

Installation

Der beste Punkt, um mit dem Härten eines Systems zu beginnen ist ganz am Anfang: während der Betriebssysteminstallation. Da es hier um die Firewall geht, sollte man keiner bestehenden Installation trauen, sondern mit einer sauberen Neuinstallation beginnen, deren Integrität man garantieren kann.

Stellen Sie das System in ein isoliertes Netzwerk. Zu keiner Zeit sollte man das ungeschützte System an ein aktives Netz oder gar das Internet anbinden und es so einer möglichen Kompromittierung aussetzen. Ich selbst habe Systeme gesehen, die innerhalb von 15 Minuten nach Anschluß an das Internet gescannt und "gerootet" wurden. Um wichtige Dateien und Patches zu bekommen, braucht man eine zweite Maschine, die als Puffer dient. Diese zweite Maschine holt die Dateien aus dem Internet um dann anschließend an das isolierte "Konfigurationsnetz" angeschlossen zu werden um die Dateien zur Verfügung zu stellen oder sie auf eine CD zu brennen.

Nachdem man die zukünftige Linuxmaschine in ein isoliertes Netz gestellt hat kann man beginnen. Der erste Schritt ist die Auswahl des Betriebssystempaketes. Bei RH 6.0 hat man drei Möglichkeiten: Workstation, Server oder Angepaßt (Voreinstellung). Ich empfehle hier die angepaßte Installation, da sie es erlaubt auszuwählen, welche Dienste installiert werden und wie die Festplatten partitioniert werden. Die Grundidee ist, nur das Minimum zu installieren, das man braucht um maximale Effizienz zu behalten. Je weniger Software installiert wird, desto weniger potentielle Sicherheitlücken entstehen. Das heisst: wenn sie keinen RealAudio oder News-Server brauchen, installieren sie ihn nicht. Man sollte sicherstellen, daß das Online-Handbuch mit installiert wird. Unabhängig von der Installationsvariante würde ich die man-pages und die HOWTOs mitinstallieren. Ich finde sie sehr nützlich und sie bringen nur wenig Gefahren mit sich.

Während der Installation wird man aufgefordert, sein System zu partitionieren. Ich mache root immer so groß wie möglich und packe alles andere dann da hinein um Platzproblemen in der Zukunft zu entgehen. Wir brauchen aber trotzdem mehrere Partitionen um das root-Laufwerk zu schützen. Wenn wir die root-Partition nutzen um dort Daten wie Logs oder Mails abzulegen und sie dadurch volläuft, würden wir einen denial-of-service verursachen und möglicherweise das System abstürzen lassen.

Deswegen empfehle ich immer eine separate Partition für /var, wohin die Systemlogs und Mails geschrieben werden. Indem man /var isoliert, verhindert man, das die root-Partition vollgeschrieben wird. Meiner Erfahrung nach sind 400 MB genug für /var (wenn sehr viele mails anfallen kann man sie entsprechend vergrößern). Man könnte auch eine besondere Partition für einige Applikationen anlegen, besonders wenn diese umfangreiche Logs erzeugen. Wenn auf dem System nicht vertrauenswürdige Benutzer existieren, sollte man evtl. ein extra /home Verzeichnis anlegen, damit diese Nutzer nicht die / Partition vollschreiben können. Für einen Standalone-Server könnte die Partitionierung wie folgt aussehen:

/ - alles andere
/var - 400 MB
swap - normalerweise nehme ich hier 256MB (bzw. RAM*2)

Nachdem das System nach der Installation neu gestartet hat, sollte man unbedingt die empfohlenen Sicherheitspatches einspielen. Für Red Hat findet man sie unter http://www.redhat.com/apps/support/updates.html. Patches sind extrem wichtig um ein System zu härten und sollten immer auf dem aktuellen Stand gehalten werden. BUGTRAQ (http://securityfocus.com/forums/bugtraq/faq.html#0.3.1) oder Red Hats watch-list (http://www.redhat.com/corp/support/errata/) ist eine exzellente Quelle um hier auf dem Laufenden zu bleiben. Ohne diese Updates ist das System leicht zu kompromittieren. Um an die Patches zu kommen sollte unbedingt die Puffermaschine verwendet werden. Für Red Hat kann man, nachdem man das rpm-Archiv heruntergeladen hat, das System einfach mit folgender Syntax aktualisieren (hier das Beispiel für das wu-ftpd Sicherheitsupdate):

rpm -Uvh wu-ftpd-2.6.0-14.6x.i386.rpm

Bei Systemen, die bereits online sind, kann man per ftp das rpm-Archiv herunterladen und gleichzeitig installieren. Dafür dient diese Syntax:

rpm -Uvh ftp://updates.redhat.com/6.1/i386/wu-ftpd-2.6.0-14.6x.i386.rpm

Um die Patches zu verwalten, empfehle ich das Tool autorpm (http://www.kaybee.org/~kirk). Dieses Befehlszeilenuitility untersucht, welche .rpms aktualisert werden müssen, lädt diese von Red Hats Webseite herunter und installiert sie automatisch (sofern gewünscht). Das Tool ist extrem anpassungsfähig und einfach zu benutzen. Das beste daran ist, das es per cron startbar ist. Das Dateisystem kann also z.B. jede Nacht untersucht werden und per e-mail wird dann mitgeteilt, daß man sein System aktualisieren muß.

Dienste eliminieren

Nach der Installation aller Pakete und Patches und dem Neustart des Systems sind wir jetzt bereit das Betriebssystem zu härten. Härten besteht im wesentlichen darin, Dienste abzuschalten, Logging hinzuzufügen, verschiedene Dateien zu bearbeiten und TCP-Wrapper zu implementieren. Beginnen werden wir mit dem Abschalten von Diensten.

Linux ist standardmäßig ein mächtiges Betriebssystem, das viele nützliche Dienste anbietet. Die meisten davon werden aber nicht gebraucht und stellen ein potentielles Risiko für eine Firewall dar. Der erste Ansatzpunkt ist /etc/inetd.conf. Diese Datei legt fest, auf welche Dienste der /usr/sbin/inetd Daemon lauscht. Im Ursprungszustand ist /etc/inetd.conf für eine Vielzahl von Diensten konfiguriert, brauchen werden wir aber nur zwei: ftp und telnet. Eine Beispieldatei mit entsprechend auskommentierten Diensten liegt unter http://www.enteract.com/~lspitz/lx_example.html#A.

Das Auskommentieren ist sehr wichtig, da viele der durch inetd gestarteten Prozesse ernste Bedrohungen darstellen. Überprüfen was man auskommentiert hat kann man mit folgendem Kommando (es zeigt alle Dienste an, die aktiv gelassen wurden):

#grep -v "^#" /etc/inetd.conf

Der nächste Ansatzpunkt sind .rc Skripte. Diese Skripte bestimmen, welche Dienste durch den init-Prozess gestartet werden. Bei RedHat findet man diese Skripte in /etc/rc.d/rc3.d (oder /etc/rc.d/rc5.d wenn automatisch eine GUI wie Gnome oder KDE gestartet wird). Um ein Skript am Starten zu hindern, ersetzt man einfach das groß geschriebene S am Anfang durch ein kleines. Auf diese Weise kann man das Skript einfach wieder in den Startvorgang einbinden, indem man das kleine gegen ein großes S ersetzt. Oder, wenn man das lieber hat, kann man auf der Kommandozeile einfach /usr/sbin/setup eingeben, danach "System services" wählen (wie das in deutschen Version von RedHat heißt weiß ich leider nicht. Anm. des Übers.). Hier kann man jetzt festlegen, welche Dienste während des Hochfahrens gestartet werden. Eine andere Möglichkeit ist "chkconfig", das mit den meisten Distributionen ausgeliefert wird. Die folgenden Startskripte können standardmäßig installiert werden, sind aber nicht kritisch für den Betrieb des Systems. Wenn man sie nicht braucht, sollte man sie abschalten. Die Zahlen in den Namen legen die Reihenfolge der Abarbeitung fest (niedrige zuerst, hohe zuletzt) und können sich je nach Distribution und Version unterscheiden. Skripte, die mit einem K anstatt eines S beginnen, werden genutzt um bereits laufende Prozesse zu beenden.

S05apmd (Nur nötig bei Laptops)
S10xntpd (Network time protocol)
S11portmap (Wird von rpc Diensten wie NIS oder NFS benötigt)
S15sound (Soundkarteneinstellungen)
S15netfs (Der NFS-Client, wird benötigt um Dateisysteme von einem NFS-Server zu mounten)
S20rstatd (Man sollte versuchen auf die "r" Dienste ganz zu verzichten, da sie remote Usern zu viele Informationen preisgeben)
S20rusersd
S20rwhod
S20rwalld
S20bootparamd (Für diskless clients, dieser angreifbare Dienst wird wahrscheinlich nicht benötigt)
S25squid (Proxy server)
S34yppasswdd (Benötigt, wenn die Maschine ein NIS Server ist, ein extrem verwundbarer Dienst)
S35ypserv (siehe S34yppaswdd)
S35dhcpd (Startet den dhcp server daemon)
S40atd (Wird vom "at" Dienst benutzt. Ähnlich wie "cron", aber nicht zwingend für das System erforderlich)
S45pcmcia (Nur nötig bei Laptops)
S50snmpd (SNMP daemon, kann remote Usern detaillierte Informationen über das System geben)
S55named (DNS server. Wenn DNS genutzt werden soll, sollte man die neueste Version von BIND verwenden, http://www.isc.org/bind.html)
S55routed (RIP: abschalten, es sei denn, man braucht es *WIRKLICH*)
S60lpd (Druckdienste)
S60mars-nwe (Netware Datei- und Druckserver)
S60nfs (Benötigt für den NFS Server, abschalten außer es ist *WIRKLICH ABSOLUT ZWINGEND* notwendig ihn einzusetzen.).
S72amd (AutoMount daemon, wird benutzt um remote Dateisysteme zu mounten)
S75gated (wird benutzt, um andere Routingprotokolle wie OSPF einzusetzen)
S80sendmail (man kann auch ohne dieses Skript immer noch emails senden, man kann nur keine empfangen oder weiterleiten)
S85httpd (Apache webserver, ich würde empfehlen, auf die aktuellste Version umzustellen)
S87ypbind (nötig, wenn man ein NIS-Client ist)
S90xfs (X font Server)
S95innd (News Server)
S99linuxconf (wird genutzt, um Linuxsysteme per Browser von irgendwo konfigurieren zu können. Der Traum eines jeden "bösen Jungen" :) )

Um zu sehen, wie viele Dienste laufen, bevor man die Startskripte ändert, kann man folgenden Befehl eingeben:

ps aux | wc -l

Nachdem man mit der Anpassung der Skripte fertig ist, kann man das Kommando erneut eingeben und sich ansehen, wie die Zahl abgenommen hat. Je weniger läuft, desto besser. Außerdem sollte man feststellen, welche Dienste noch laufen:

netstat -na --ip

Logging und Tuning

Nachdem wir nun so viele Dienste wie möglich abgeschaltet haben, möchten wir das Logging aktivieren. Alle Systemlogs liegen in /var/log. Standardmäßig hat Linux eine hervorragende Logfunktion, außer für ftp. Man hat nun zwei Möglichkeiten ftp mitzuloggen: entweder man editiert diese /etc/ftpaccess oder die Datei /etc/inetd.conf. Ich bevorzuge /etc/inetd.conf, da es einfacher (d.h. schwerer zu vermasseln :) ) ist. Ändern Sie /etc/inetd.conf wie folgt, um komplettes Logging für alle ftp-Sitzungen einzuschalten.

ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd -l -L -i -o

--- Auszug aus den man pages ---

wird die -l Option genutzt, wird jede ftp-Sitzung im syslog protokolliert
wird das -L flag gesetzt, werden bei Aufruf des ftp-Servers alle USER-Befehle mitprotokolliert. Das bedeutet auch, das, wenn ein Benutzer versehentlich statt seines Usernamens sein Paßwort eingegeben hat, dieses mitgeloggt wird!
wird die -i Option genutzt, werden alle Dateien, die der ftpd(8) Server empfängt, in der Datei xferlog(5) mitprotokolliert
wird die -o Option genutzt, werden alle Dateien, die der ftpd(8) Server übertragen hat, in der Datei xferlog(5) mitprotokolliert

--- snip snip ---

Es folgt ein wenig Feintuning. Das erste was wir tun wollen, ist die Datei /etc/passwd zu sichern (das ist die Benutzer"datenbank", in der die Benutzerkonten und -paßwörter abgelegt sind). Dazu stellen wir zuerst sicher, das unser System die Datei /etc/shadow verwendet. Das stellt sicher, das die Paßwörter in verschlüsselter Form in einer Datei gespeichert werden, auf die nur root Zugriff hat. Dies schützt die Paßwörter vor einfachem Zugriff und geknacktwerden (eine der ersten Schwachstellen, nach denen Hacker suchen). Verschlüsselte Paßwörter sind seit RH 6.0 Standard, aber eine Prüfung schadet in keinem Fall. Alles was man tun muß, ist das folgende Kommando als root einzugeben.

pwconv

Dieser Befehl konvertiert automatisch alle Paßwörter in die Datei /etc/shadow. Von allen Schritten, um ein System zu sichern, ist dies wahrscheinlich einer der wichtigsten.

Der zweite schritt besteht darin, die meisten Systemkonten aus der /etc/passwd zu entfernen. Linux stellt diese Konten für verschiedene Systemdienste zur Verfügung, die evtl. nicht gebraucht werden. Werden die Konten nicht gebraucht, sollte man sie entfernen. Je mehr Benutzer man hat, um so einfacher ist es, Zugriff auf ein System zu bekommen. Ein Beispiel ist der "news" Account. Wenn nntp, ein Newsserver, nicht genutzt wird, ist dieser Benutzer überflüssig (nicht vergessen, auch /etc/cron.hourly anzupassen, da dieser den Benutzer "news" sucht). Man sollte auch sichergehen, das der "ftp"-Benutzer für anonyme ftp-Sitzungen genutzt wird.

--- Auzug aus den man pages ---

ftpd authentifiziert Benutzer anhand von vier Regeln.

...
4) Ist der Benutzername "anonymous" oder "ftp", muß ein anonymer ftp-Account in der Paßwortdatei vorhanden sein (user "ftp"). In diesem Fall ist es dem Benutzer gestattet, sich ohne Paßwort anzumelden.

--- snip snip snip ---

Hier eine Beispieldatei /etc/passwd:

root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:
daemon:x:2:2:daemon:/sbin:
adm:x:3:4:adm:/var/adm:
lp:x:4:7:lp:/var/spool/lpd:
mail:x:8:12:mail:/var/spool/mail:
uucp:x:10:14:uucp:/var/spool/uucp:
nobody:x:99:99:Nobody:/:

Beachten Sie, das anstelle eines Paßworts nur ein x aufgeführt wird. Die verschlüsselten Paßwörter sind infolge des pwconv Befehls sicher in der Datei /etc/passwd aufbewahrt.

Jetzt wird die Datei /etc/ftpusers angepaßt (Beispiel siehe unten). Jeder Benutzer, der in dieser Datei aufgeführt wird, kann sich NICHT per ftp mit dem System verbinden. Diese Anpassung verbietet es gängigen Systemaccounts wie root oder bin ftp-Sitzungen aufzubauen. Bei Linux existiert diese Datei standardmäßig. Stellen sie sicher, das root auf jeden Fall in ihr steht, da root nie in der Lage sein sollte, sich per ftp mit dem System zu verbinden. Stellen sie außerdem sicher, das Benutzer die einen ftp-Zugang benötigen, NICHT in dieser Datei stehen.

Beispiel für eine /etc/ftpusers Datei

root
bin
daemon
adm
lp
mail
uucp
nobody

Vergewissern sie sich, daß root nicht per telnet auf das System kommt. Das zwingt Benutzer sich unter ihrem eigenen Namen anzumelden und dann per su zu root zu werden. Die Datei /etc/securetty listet auf, mit welchen ttys sich root verbinden kann. Lassen sie nur tty1,tty2 usw. in dieser Datei um root logins auf lokale Terminals zu beschränken. ttyp1,ttyp2 usw. sind Pseudoterminals, die es root erlauben, sich von remote anzumelden.

Beispiel für eine /etc/securetty Datei:

tty1
tty2
tty3
tty4
ttyp1 -- > Achtung, dieser Eintrag erlaubt erlaubt es einem remote Benutzer sich als root anzumelden. Normalerweise wird man solch einen Eintrag NICHT wollen.

Als letztes erzeugen sie die Datei /etc/issues. Diese ASCII-Datei wird bei jedem Telnet login angezeigt. Wenn man den gleichen Text dauerhaft verwenden möchte, muß man das Startskript /etc/rc.d/init.d/S99local anpassen. Linux erzeugt sonst bei jedem Neustart eine neue /etc/issue Datei.

Verbindungen mit dem Server

Für diejenigen, die per Fernadministration arbeiten ist es wichtig, einen sicheren und kontrollierten Weg für die Verbindung zum Server zu haben. Oft braucht man zur Administration oder den Upload von Dateien einen Zugriff über das Netz: dieser Zugriff muß gesichert werden. Zwei Möglichkeiten sollen im folgenden diskutiert werden: ssh und TCP Wrapper.

Ich bevorzuge ssh, da es jede Kommunikation zwischen mir und der Firewall verschlüsselt. TCP-Wrapper schützen den Netzverkehr NICHT gegen Sniffer. Benutzer können immer noch jeden Tastendruck (inklusive Paßwörter) im Netz abfangen. Wenn Sie sich Sorgen über Benutzer machen, die ihre Kommunikation mit der Firewall belauschen, dann ersetzen Sie telnet/ftp durch ssh. ssh verschlüsselt jede Kommunikation mit der Firewall und erlaubt so das Hochladen von Dateien und die Administration auf eine sichere Art und Weise. ssh ähnelt TCP-Wrappern insofern, als es seine eigenen Protokollorierungsfunktionen besitzt und einschränken kann, welche Systeme sich mit ihm verbinden können. Mehr Informationen über ssh und das Programm selber inklusive Sourcecode für Clients und den Serverdaemon findet man unter http://www.ssh.org/download.html. Ich empfehle die Verwendung der Version 1.2.7, da die Versionen 2.x eine einschränkende Lizenz haben. Eine andere Variante ist Openssh (http://www.openssh.com)

TCP-Wrapper können zwar nicht verschlüsseln, sind aber in der Lage zu protokollieren und zu kontrollieren wer Zugriff auf das System hat. Es handelt sich hier um ein Programm, das sich um die inetd Dienste wie telnet und ftp "herumlegt". Mit einem TCP-Wrapper startet das System den Wrapper für eingehende Verbindungen über inetd, protokolliert alle Versuche und überprüft sie anhand einer Zugriffskontrolliste. Wenn der Zugriff berechtigt erfolgt, übergibt der Wrapper die Verbindung an das entsprechende Programm wie z.B. telnet. Wird die Verbindung durch die Zugriffskontrolliste abgelehnt, dann wird die Verbindung gekappt. Glücklicherweise für uns Linux-Nutzer ist bereits ein TCP-Wrapper installiert. Das einzige was noch zu tun ist, ist die Dateien /etc/hosts.allow und /etc/hosts.deny zu editieren. Diese Dateien legen fest, wer auf unser System zugreifen kann und wer nicht. TCP-Wrapper erlauben es uns auch nette Dinge zu tun, wie z.B. Banner oder zusaätzliche Programme wie z.B. safe_finger zu starten. Die Syntax ist ziemlich simpel. Die IP-Adressen oder Netzwerke denen Verbindungen gestattet werden sollen, werden in die /etc/hosts.allow eingetragen. IP-Adressen oder Netzwerke denen keine Verbindungsaufnahme gestattet werden soll, werden in die /etc/hosts.deny aufgenommen. Standardmäßig erlaubt Linux den Verbindungen von jedem System aus, also wird man um das Editieren dieser beiden Dateien nicht herumkommen. Zwei Emfehlungen für den Einsatz von TCP-Wrappern:

1) IP-Adressen statt System- oder Domänennamen verwenden
2) in /etc/hosts.deny jeden Zugriff verbieten und dann selektiv in der /etc/hosts.allow wieder freigeben

Beispiele, wie die Dateien aussehen können findet man hier: http://www.enteract.com/~lspitz/lx_example#F. Mehr Einsatzmöglichkeiten von TCP-Wrappern findet man in dem Whitepaper "Intrusion Detection" (http://www.enteract.com/~lspitz/ids.html)

Für die wahren Paranoiker

Ich halte die oben beschriebenen Maßnahmen für absolut notwendig. Durch das Abarbeiten der obigen Schritte haben Sie die Sicherheit ihres Systems sehr verbessert. Unglücklicherweise ist ihr System nicht zu 100% sicher, noch wird es dieses jemals sein. Also habe ich für die echten Paranoiker einige zusätzliche Maßnahmen ausgearbeitet.

Als erstes werden wir die Gruppe wheel erstellen. Diese Gruppe besteht aus ausgewählten Personen, die mächtige Kommandos wie z.B. /usr/bin/su ausführen können. Durch Beschränkung der Personengruppe, die diese Kommandos ausführen kann, steigert man die Systemsicherheit. Um die Gruppe zu erstellen, laden Sie /etc/group in den vi, tragen sie die Gruppe "wheel" ein and fügen sie die Systemadministratoren in die Gruppe ein. Anschließend suchen sie die kritischen Systemprogramme, wie z.B. /bin/su ändern die Besitzergruppe zu wheel und die Berechtigungen auf "nur durch Besitzer und Gruppe ausführbar" (stellen sie sicher, das bei besonderen Programmen das suid oder guid Bit unverändert bleibt). Für /bin/su sähe das folgendermaßen aus:

/bin/chgrp wheel /bin/su
/bin/chmod 4750 /bin/su

Als zweites werden wir die Dateien .rhosts, .netrc und /etc/hosts.equiv sperren. Die r-Befehle nutzen diese Dateien um auf Systeme zuzugreifen. Um sie sperren, benutzen sie den touch-Befehl für jede der Dateien und setzen sie anschließend die Berechtigungen auf 0. Auf diese Weise kann niemand die Dateien erstellen oder verändern. Die Befehle sehen z.B. so aus:

/bin/touch /root/.rhosts /root/.netrc /etc/hosts.equiv
/bin/chmod 0 /root/.rhosts /root/.netrc /etc/hosts.equiv

Als drittes stellen wir ein, das /etc/shadow MD5 hashes statt der crypt(3) Funktion zum Verschlüsseln benutzt. Das erschwert das Cracken des Paßwortfiles erheblich. Erreicht wird dies durch Anpassen der entsprechenden PAM-Module. PAM (Pluggable Authentication Modules) ist eine Sammlung von shared libraries die es einem ermöglichen festzulegen, wie Anwendungen Benutzer authentifizieren. Mehr über PAM erfährt man hier: ftp://ftp.us.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam.html.

In den alten Tagen mußte man die PAM-Module händisch ändern, damit sie MD5 hashes verwendeten. Wer jedoch RedHat 6.0 oder später verwendet kann dies mit dem setup-Tool erledigen. Einfach auf der Kommandozeile "setup" eingeben und anschließend "authentication configuration" (wie das in deutschen Version von RedHat heißt weiß ich leider nicht. Anm. des Übers.) wählen. Hier lassen sich nun MD5 hashes einstellen. Diese werden jedoch erst wirksam, wenn der Benutzer sein Kennwort das nächste mal eingibt. Für diejenigen die das setup-Tool nicht zur Verfügung haben (oder RedHat 5.2 oder früher verwenden) bleibt aber immer noch die Möglichkeit die Module von Hand zu ändern (www.enteract.com/~lspitz/lx_example#G).

Für bash Nutzer: ich bin kein großer Fan der .bash_history Datei. Ich möchte nicht das jemand (auch nicht root) meine eingebenen Befehle nachlesen kann. Also exportiere ich in meinem .bash_profile den folgenden Eintrag:

HISTFILESIZE=0

Das bedeutet, daß nichts in meine .bash_history Datei geschrieben wird. Alles andere bleibt erhalten, nur die eingegebenen Befehle werden nicht auf die Festplatte geschrieben.

Als letztes bleibt noch, das System vor physikalischem Zugriff zu schützen. Dies geschieht hauptsächlich durch das Setzen eines BIOS-Paßworts. Man kann auch das System während des Bootens durch ein Paßwort schützen, indem man /etc/lilo.conf entsprechend konfiguriert (password=xxx, wobei xxx das Paßwort ist). Allerdings sollte man nicht vergessen, das es keine zuverlässige Methode gibt sein System zu schützen wenn jemand physikalisch Zugriff darauf hat.

IPChains

Keine Abhandlung über die Sicherheit von Linux wäre ohne das Thema IPChains vollständig. IPChains ist eine Paketfilter-Software, die mit dem 2.2.x (oder später) Kernel mitgeliefert wird. Wenn man RedHat 6.0 oder später einsetzt, hat man es als Teil des Installationspaketes. IPChains ähnelt den Cisco Access Control Lists, es kontrolliert welche Pakete in das System hinein und herauskommen können. Obwohl es primär als Firewall benutzt wird kann man es auch verwenden um die eigene standalone Linux-Maschine zu härten. Um das zu erreichen weise ich IPChains an, nur von mir ausgelöste TCP-Verbindungenzu erlauben. Sollte jemand versuchen, TCP-Verbindungen zu mir aufzubauen, so werden diese abgelehnt. Da IPChains nicht "stateful" arbeitet, erlaube ich alle ICMP und UDP Verbindungen. Als letztes protokolliere ich alle abgelehnten Verbindungsversuche, um zu erfahren ob da draußen jemand ungezogen war :). Broadcast/Multicast Verkehr wird verworfen, aber nicht protokolliert, da sonst die Systemlogs schnell volliefen. Eine einfache IPChains Konfiguration um ein standalone System zu sichern würde also so ähnlich aussehen:

bash# ipchains -L
Chain input (policy DENY):
target prot opt source destination ports
DENY all ------ 0.0.0.0 anywhere n/a
DENY all ------ anywhere 255.255.255.255 n/a
DENY all ------ anywhere BASE-ADDRESS.MCAST.NET/8 n/a
ACCEPT tcp !y---- anywhere anywhere any -> any
ACCEPT udp ----l- anywhere anywhere any -> any
ACCEPT icmp ----l- anywhere anywhere any -> any
DENY all ----l- anywhere anywhere n/a
Chain forward (policy ACCEPT):
Chain output (policy ACCEPT):

Die Konfigurationsdateien für diese Konfiguration findet man hier: www.enteract.com/~lspitz/lx_example#H.

Mehr über den Einsatz von IPChains als Firewall oder für ein standalone System erfährt man hier: metalab.unc.edu/pub/Linux/docs/HOWTO/IPCHAINS-HOWTO

Schlussfolgerung

Wir haben einige der grundlegenden Schritte kennengelernt mit denen man eine Linux Installation härten kann. Der Schlüssel zu einem sicheren System liegt darin, nur die minimale Software zu installieren und einen schichtweisen Schutz (z.B. mit TCP-Wrappern) zu implementieren. Es gibt noch viele weitere Möglichkeiten die man hat, z.B. tripwire (ftp.cerias.purdue.edu/pub/tools/unix/ids/tripwire (überwacht Veränderungen an Systemprogrammen) und swatch (http://www.enteract.com/~lspitz/swatch.html ;automatische Überwachung von Protokolldateien und Auslösen von Alarmen). Ich würde neuen Linux-Nutzern empfehlen sich Bastille Linux (http://www.bastille-linux.org) anzusehen. Es ist ein PERL Skript das Schritt für Schritt eine neue Linuxinstallation sichern kann. Bedenken Sie das kein System 100% sicher ist. Mit den beschriebenen Maßnahmen können sie jedoch das Risiko von Sicherheitsproblemen erheblich reduzieren.

Anmerkungen des Übersetzers

Der original englischsprachige Artikel ist zu finden unter http://www.enteract.com/~lspitz/linux.html. Da ich kein professioneller Übersetzer bin, können sich durchaus Unklarheiten und falsche (hoffentlich nicht sinnenstellende) Übersetzungen eingeschlichen haben. Korrekturen oder Vorschläge oder sonstiges bitte an Jochen_Berner@hotmail.com.



Psyrius
Senior Member
Beitrag vom:
28-01-2004, 10:48:32

Schade das es geklaut ist

Das finde ich echt erbärmlich denn COPY PASTE kann selbst ein DAU!!! :D
Dieser Artikel sieht aus als wäre er komplett von
"http://www.technik4netzwerk.de/Linux%20haerten.htm"
inklusive der Überschrift geklaut.
Eine frechheit die den sinn dieser seite verfehlt und anderen ehrlicheren Usern gegenüber auch nicht fair ist :(

-----------------------------------------------------
Why? Hmm, well why not!


[back to top]



Userdaten
User nicht eingeloggt

Gesamtranking
Werbung
Datenbankstand
Autoren:04511
Artikel:00815
Glossar:04116
News:13565
Userbeiträge:16552
Queueeinträge:06248
News Umfrage
Ihre Anforderungen an ein Online-Zeiterfassungs-Produkt?
Mobile Nutzung möglich (Ipone, Android)
Externe API Schnittstelle/Plugins dritter
Zeiterfassung meiner Mitarbeiter
Exportieren in CSV/XLS
Siehe Kommentar



[Results] | [Archiv] Votes: 1158
Comments: 0