erschienen in LinuxEnterprise 8/2001, Software & Support Verlag, Frankfurt a.M.
Linux genießt zu Recht einen guten Ruf als sicheres Betriebssystem. Auf diesen Lorbeeren können sich Netzwerkadministratoren allerdings nicht ausruhen. Konfigurations- und Softwarefehler werden schnell zum Einfallstor für ungebetenen Besuch. Dies gilt natürlich besonders für Internet-Server und Unternehmensnetze. Aber auch kleine und mittlere Unternehmen werden immer öfter zum Ziel, seit eine DSL-Standleitung erschwinglich geworden ist. Diese Serie zeigt, wie sich jeder wirksamer vor Schäden durch Hacker und Script Kiddies schützen kann.
Im ersten Teil dieser Serie wurden einfachere Eingriffe in das Linux-System beschrieben. Die Besitzer einer SuSE-Distribution können die meisten der dort beschriebenen Arbeitsschritte mit dem von Marc Heuse entwickelten Perl-Skript harden_suseautomatisieren. Für die Redhat-Distribution gibt es das von VA Linux und vom SANS-Institute gesponsorte Bastille-Linux. Diese Skripten vereinfachen zwar die Arbeit, allerdings verpasst man so die Gelegenheit, mehr über das Linux-System zu erfahren. Diese Kenntnisse kommen einem spätestens beim nächsten Eindringlingsalarm zugute. In diesem zweiten Teil werden Netzwerkdienste und Kernel-Modifikationen behandelt.
Eine Reihe von Netzwerkdiensten werden nicht ständig benötigt. Es hätte im Hinblick auf die Rechnerressourcen nur wenig Sinn, für jeden dieser Dienste einen eigenen Dämon laufen zu lassen. Diese Aufgabe übernehmen die Superserver.
Der verbreitetste Super-Server ist inetd. Diese Tatsache hat teilweise historische Gründe: Ursprünglich war er Teil des Berkley-UNIX 4.3 (BSD). inetd stammt also aus einer frühen, eher ruhigen Ära des Internets. Als Standardausstattung der meisten Linux-Distributionen istinetdfür den Einsatz auf Standalone-Systemen oder kleinen, wenig frequentierten Servern sicher ausreichend. Allerdings reagiert er auf plötzlich auftretende, zahlreiche Verbindungswünsche nur sehr zögernd. Lädt beispielsweise eine größere Anzahl von diskless Clients seine Boot-Images gleichzeitig mit Hilfe des vom inetdgestarteten Dienstes TFTP (Trivial File Transfer Protocol) von einem Server, bleibt Zeit für eine längere Kaffeepause. Unter Dauerlast, beispielsweise auf einem FTP-Server, wirdinetdsogar rigide: Zu viele Verbindungswünsche innerhalb einer Minute werden mit einer zehnminütigen Zwangspause für den betroffenen Dienst beantwortet. Dabei geht er trotzdem gar nicht zimperlich mit den Ressourcen seines Wirts um und belegt sehr schnell den gesamten Speicher.inetdist also das ideale Ziel für DOS-Angriffe. Dies ließe sich verhindern, wenn die Zahl der neu gestarteten Prozesse begrenzbar wäre. Als wenn dies noch nicht genug wäre, hatinetd noch eine weitere, sehr gravierende Schwäche: Auf einem Server mit mehreren Netzwerkkarten (multihomed server) lauscht er an allen zur Verfügung stehenden Ethernet-Interfaces einschließlich des loopback. Mechanismen zur Zugriffskontrolle oder sogar logging gibt es auch nicht. Diese Löcher lassen sich zwar mit Wietse Venemas TCP-Wrappertcpdteilweise stopfen, aber die vielen Designschwächen stehen dem professionellen Einsatz im Wege. Zum Glück gibt es Alternativen.
| Was ist ein Super-Server? |
|---|
|
Netzwerkdienste, wie beipielsweise FTP und TELNET, werden durch Daemons bereitgestellt. Eine einfache Lösung wäre es, diesen Programmen den Verbindungsaufbau zum entfernten Host selbst zu überlassen. Trifft ein Verbindungswunsch ein, startet er einfach einen Kind-Prozess (child), übergibt ihm die Verbindung und kehrt selbst in den Wartezustand zurück. Dieser Vorgang wird als Spawning bezeichnet und bedingt eine ganze Serie von rechenintensiven Systemaufrufen an den Kernel. Der Apache versucht diesen Aufwand zu minimieren, indem er sofort beim Programmstart eine vorher frei definierbare Zahl von Daemons startet. Beide Verfahren haben einen hohen Speicherplatzbedarf, weshalb sie sich nur für verhältnismäßig wenige, gleichzeitige Verbindungen eignen. Ein Super-Server übernimmt anstelle der Daemons den Verbindungsaufbau. Er wartet an definierten Ports auf Verbindungswünsche und startet gegebenenfalls den jeweiligen Server-Prozess, der die weitere Verbindung übernimmt. Danach kehrt der Super-Server in die "Warteposition" zurück und der Vorgang kann von neuem beginnen. |
Eine Alternative ist xinetd, der eXtended InterNET Daemon. Er will die Lücken schließen, die inetdund der TCP-Wrapper hinterlassen. Auch xinetdüberwacht Verbindungen durch Zugriffskontroll-Mechanismen. Dazu benutzt er intern die Library libwrap und die bereits von TCP-Wrapper bekannten Dateien /etc/hosts.allow und /etc/hosts.deny, die zuerst immer allen Rechnern den Zugang verwehren sollten:
ALL: ALL@ALL
Dann wird die fest angezogene Schraube in /etc/hosts.allow wieder etwas gelockert, damit etwa lokale Rechner Zugriff bekommen:
ALL: 192.168.0.
Dies ist auch schon die einzige Gemeinsamkeit der beiden Super-Server. xinetd verwendet seine eigene Konfigurationsdatei /etc/xinetd.conf, die vollkommen anders als /etc/inetd.conf aufgebaut ist und sich eher an die C- oder bind-Syntax anlehnt. Mit dem Konvertierungs-Werkzeug xconv.pl kann eine bereits existierende inetd.conf in eine xinetd.conf umgewandelt werden. Die vielen neuen Möglichkeiten lassen sich aber so nicht nutzen. Eine davon ist die freie Zuordnung von IP-Adressen oder Zugriffsrechten zu bestimmten Diensten. In dem folgenden Beispiel handelt es sich um einen kleinen Kommunikationsserver mit der IP-Adresse 192.168.0.1, der den Dienst FTP nur im internen Netz zur Verfügung stellen soll:
defaults
{
log_type = SYSLOG auth
log_on_success = HOST PID USERID DURATION EXIT
log_on_failure = HOST USERID RECORD
disabled = servers services xadmin
no_access = 0.0.0.0/0
}
service ftp
{
socket_type = stream
wait = no
user = root
server = /usr/sbin/in.ftpd
server_args = -l
instances = 5
access_times = 7:00-21:00
nice = 15
only_from = 192.168.0.0/24
bind = 192.168.0.1
}
Der Parameter only_from verhindert den Verbindungsaufbau aus jedem anderen als dem angegebenen Netz. Zur Sicherheit wurde im Abschnittdefaults als Standard-Policy jeder Zugriff mit no_accessunterbunden. Ist wederonly_fromnochno_access definiert, kann der Service von jedermann benutzt werden. In den Genuss des FTP-Service kommen maximal fünf Anwender in der Zeit von 7-21 Uhr. Um den strapazierten Server etwas zu schonen, wird dem Service mit Hilfe von nice nur eine niedrige Priorität eingeräumt. Der interne FTP-Dienst wird zusätzlich mit bindan die interne IP-Adresse des Servers gebunden und bleibt damit der Außenwelt an der externen Schnittstelle verborgen.
Den gefürchteten dDOS-Angriffen hat xinetd die Fähigkeit zur Beschränkung der Anzahl neu gestarteter Server entgegen zu setzen. Der Wert kann entweder global oder auf Service-Ebene mit dem Parameter instances beeinflusst werden. Er sollte immer angegeben werden, weil sonst unbegrenzt viele Server gestartet werden können.
Der xinetd verfügt über die drei internen Dienste servers, services, und xadmin, die Informationen über laufende Server, Dienste, Protokolle und ihren Port zur Verfügung stellen und deshalb ein potenzielles Sicherheitsrisiko darstellen. Unglücklicherweise sind sie von Hause aus vollkommen ungeschützt, lassen sich aber wie gezeigt mit disabledentschärfen.
Wer xinetd nun gleich installieren möchte, sollte sich die aktuellsten RPM-Pakete oder Sourcen von www.xinetd.org laden. In jüngster Zeit wurde nämlich ein Buffer-Overflow-Bug bekannt, der mit der Version 2.3.0 behoben wird.
Eine im positiven Sinne kompromisslose Philosophie verfolgt der Autor dieser Software Dan Bernstein, der durch den Mailserver QMAIL bekannt wurde. Er bezeichnet das UNIX Client Server Program Interface oder UCSPI als ein aus Werkzeugen bestehendes, protokollunabhängiges Framework. Bisher gibt es nur die beiden Tools tcpserver und tcpclient, die der UNIX-Philosophie folgend Shell-Variablen zur Kommunikation mit der Systemumgebung benutzen und sich auch für individuelle Lösungen in Shell- oder Perl-Skripten eignen.
tcpserver wartet wie *inetd auf eingehende Verbindungen und startet für jede neue Verbindung genau wie die anderen Superserver eine beliebige Anwendung. Bei einem Maximum von 40 Verbindungen wehrt er weitere Verbindungswünsche ab, wenn nicht ein höherer Grenzwert angegeben wurde. Natürlich verfügt auch tcpserver mittcprules über eine Zugriffskontrolle ähnlich den TCP-Wrappers. Allerdings verwendet Bernstein dafür keine einfache sequenzielle Datei, sondern die Hash-Datenbankcdb, mit der auch Tausende von Hosteinträgen in Sekundenbruchteilen durchsucht werden. Im "Werkzeugkasten" findet sich zusätzlich tcprulescheck zum Überprüfen der Regeln und das Logging-Werkzeugrecordio, welches auch auf cdbbasiert. Es ist nötig, noch eine neue Syntax zu erlernen, weiltcpserver ein Kommandozeilen-Programm und deshalb angenehm vertraut ist:
tcpserver -v -u 503 -g 192.168.0.1 smtp /var/qmail/bin/qmail-smtpd &
Mit den Parametern -u und -g übernimmt tcpserverunmittelbar nach seinem Start die angegebenen User- und Group-ID. Es sind nur SMTP-Verbindungen zur IP-Adresse 192.168.0.1 möglich. Für eine neue Verbindung wird jeweils das Programm qmail-smtpd gestartet. Der beste Platz für dentcpserver ist ein Startup-Skript in /etc/rc.d. Insgesamt erscheint tcpserver durch seine Flexibilität und Leistungsfähigkeit als das Werkzeug der Wahl für Service-Provider. Obwohl die Software schon länger professionell eingesetzt wird, sind bis dato keine Sicherheitsprobleme bekannt geworden.
Die neueren SuSE-Distributionen werden mit dem Paketsecumod ausgeliefert. Es enthält eine Reihe von Verbesserungen, die sich am berühmten Kernel-Patch von Solar Designer orientieren. Im Gegensatz zu diesem ist für secumod kein Rekompilieren des Kernels nötig. Das Modul kann wie gewohnt jederzeit geladen und jederzeit entladen werden. Diese Bequemlichkeit bezahlt der Anwender mit dem Verzicht auf einige Features, die sich einfach nicht in einem Loadable Kernel Modul programmieren lassen. Immerhin arbeitet secumod mit jedem Kernel ab 2.2.11 einschließlich der Kernel 2.4.X.
Angriffe bauen immer auf Informationen auf, die ein System oder seine Benutzer während des laufenden Betriebs gewollt oder ungewollt Dritten zugänglich machen. Deshalb unterbindetsecumod den Befehl strace, mit dem sich Prozesse bis ins Detail beobachten lassen. Das Pseudo-Dateisystem procfs enthält viele nützliche Informationen, die durchsecumod nur noch der Superuser anzeigen kann. Auch im restlichen Dateisystem kann die Bewegungsfreiheit der Anwender eingeschränkt werden. Mit TPE oder Trusted Path Execution können nur noch Programme innerhalb eines vertrauenswürdigen Dateipfades ausgeführt werden. Im folgenden Beispiel ist anfänglich nur dem Superuser das Ausführen von Programmen gestattet. Erst mit dem secutool bekommen auch Anwender diese Möglichkeit ausschliesslich innerhalb des Pfades /usr/bin und allen Unterverzeichnissen:
modprobe secumod texec=1
secutool A /usr/bin
Das Erstellen von Hardlinks auf nicht dem Benutzer gehörenden Dateien wird vollkommen unterbunden. Symbolische Links müssen zum jeweiligen Prozess oder zum Superuser gehören, um verfolgt zu werden. Gleiches gilt für Pipes. Die Benutzung von Raw-Devices wie /dev/hd* oder /dev/sd* ist überhaupt nicht mehr möglich, weil ein Angreifer mit ihrer Hilfe Dateien durchsuchen und manipulieren könnte. Selbst eingeschmuggelten Stealth-Modulen, die mit lsmod nicht anzeigbar sind, kommt secumod auf die Schliche. Diese Module sind auf Manipulationen der Systemaufruf-Tabelle angewiesen, die durch einen Vergleich aufgedeckt werden.
Bisher haben gewöhnliche Anwender unter den Einschränkungen zu Gunsten von mehr Sicherheit leiden müssen. Aber auch der Superuser root kann in die Schranken gewiesen werden. Das Mittel dazu heißt Capability Bounds Setting und ist eine globale Variable im Linux-Kernel. Sie kann diese Werte annehmen:
Und so wird das Modul für das Capability Bounds Setting geladen:
modprobe secumod capbits=strict
Nur durch das Logging erfahren wir von möglichen Verletzungen der mit secumod aufgestellten Regeln. Ein vollständiger Aufruf für eine Firewall kann so aussehen:
insmod secumod capbits=strict texec=1 procfs=1 hardlink=1 symlink=1 trace=1 /
systable=1 socket=1 rawdisk=1 pipe=1 logging=1 persist=1
Der letze Parameter persist wurde bisher nicht besprochen. Er verhindert ein Entladen des ganzen Moduls und sollte nur sehr vorsichtig eingesetzt werden.
Der von Solar Designer entwickelte Patch verbessert wiesecumod die Systemsicherheit, funktioniert aber nur mit den Kernels 2.0.39 und 2.2.19. Die Unterstützung des Kernel 2.4.X ist geplant. Über die Funktionen von secumod hinaus bietet der Openwall-Patch einen gewissen Schutz vor einem Buffer-Overflow. Die meisten Angriffe dieser Art machen es sich zunutze, dass Programmfunktionen ihre Rücksprungadresse auf dem Stack ablegen. Dort kann sie mit einer neuen Adresse überschrieben werden, an der der Angreifer sein Programm abgelegt hat. Openwall verhindert diesen Angriff durch einen Schreibschutz für den Stack. Jeden Angriff durch Buffer-Overflows kann aber auch dieser Patch nicht abwehren, da es noch komplexere Möglichkeiten gibt.
| Kernel-Konfiguration |
|---|
|
Ohne Veränderung der Kernel-Sourcen können eine Reihe von Betriebssystem-Parametern dynamisch beeinflußt werden, um primitive DOS-Angriffe zu erschweren. Die Werte hängen natürlich von der Anwendung des jeweiligen Rechners ab und müssen entsprechend angepasst werden. In jedem Fall empfiehlt sich ein eher konservatives Vorgehen. Wenn man eine globale Wirksamkeit wünscht, ist der beste Platz für diese Änderungen die Datei /etc/profile: # Core Dumps in jedem Fall verhindern |
| Netzwerk-Konfiguration |
|---|
|
Für mehr Sicherheit kann dank des procfs auch die Netzwerkkonfiguration während der Laufzeit auf einfache Weise geändert werden. Die folgenden Shell-Befehle sollten unmittelbar nach dem Start des Netzwerks ausgeführt werden. Sie werden deshalb als Startup-Skript im Verzeichnis /etc/init.d untergebracht. #!/bin/bash |
Im letzten Teil dieser Artikelserie geht es um das Erkennen von Angriffen. Es gibt eine Reihe von sehr leistungsfähigen Werkzeugen, die das erleichtern.
http://cr.yp.to/ucspi-tcp.html
http://www.suse.de/~marc/harden_suse.html