14.3. Überwachung: Vorbeugung, Entdeckung, Abschreckung
Monitoring ist aus mehreren Gründen ein integraler Bestandteil jeder Sicherheitsrichtlinie. Unter anderem deshalb, weil das Ziel der Absicherung gewöhnlich nicht darauf beschränkt ist, die Vertraulichkeit der Daten sicherzustellen, sondern auch vorsieht, dass die Verfügbarkeit der Dienste gewährleistet ist. Es ist daher unerlässlich, zu überprüfen, ob alles wie vorgesehen funktioniert und rechtzeitig jedes abweichende Verhalten und jede Änderung in der Qualität der erbrachten Leistungen zu erkennen. Monitoring hilft dabei Einbruchsversuche zu entdecken und darauf schnell zu reagieren, bevor sie ernste Folgen haben. Dieser Abschnitt gibt einen Überblick über einige Hilfsprogramme, die zur Überwachung verschiedener Aspekte eines Debian-Systems eingesetzt werden können. Damit vervollständigt er
Abschnitt 12.4, „Überwachung“.
14.3.1. Protokolle mit logcheck verfolgen
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 wird in /etc/logcheck/logcheck.logfiles gespeichert; die Standardeinstellungen eignen sich gut, solange die Datei /etc/rsyslog.conf nicht vollständig verändert worden ist.
logcheck kann in drei mehr oder weniger detaillierten Modi laufen: Paranoid, Server und Arbeitsplatzrechner. Der erste ist sehr ausführlich und sollte wohl eher auf besondere Server, wie zum Beispiel Firewalls, beschränkt bleiben. Der zweite (voreingestellte) Modus wird für die meisten Server empfohlen. Der letzte ist für Arbeitsplatzrechner bestimmt und ist noch knapper (er unterdrückt mehr Meldungen).
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 stapelweise lange uninteressante E-Mails empfangen möchte. Da das Verfahren zur Auswahl der Meldungen recht kompliziert ist, ist es notwendig - wenn auch schwierig - die Datei /usr/share/doc/logcheck-database/README.logcheck-database.gz durchzulesen.
Die eingesetzten 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).
Ein Systemvorfall wird immer angezeigt, es sei denn, eine Regel in einem der Verzeichnisse des Typs /etc/logcheck/ignore.d.{paranoid,server,arbeitsplatzrechner}/ 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.
14.3.2. Aktivitäten überwachen
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.
Wenn das System überlastet zu sein scheint, ist top ein großartiges Instrument, um zu sehen, welche Prozesse um die Prozessorzeit konkurrieren oder zu viel 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 Programm ist, das durch eine Schwachstelle in einer Web-Anwendung auf dem System installiert wurde und ausgeführt wird.
top ist ein sehr flexibles Hilfsprogramm und seine Handbuchseite beschreibt ausführlich, wie seine Anzeige individuell eingerichtet und an persönliche Bedürfnisse und Gewohnheiten angepasst werden kann.
Das grafische Hilfsprogramm gnome-system-monitor ist top ähnlich und bietet etwa die gleichen Leistungsmerkmale.
Prozessorauslastung, Netzwerkverkehr und freier Plattenplatz sind Informationen, die sich ständig ändern. Es ist häufig nützlich, den Verlauf ihrer Entwicklung festzuhalten, um genau feststellen zu können, wie der Rechner genutzt wird.
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 -switche.
Dieses Buch behandelt Munin ausführlich als Teil von
Kapitel 12: „Erweiterte Verwaltung“ (siehe
Abschnitt 12.4.1, „Munin einrichten“). Debian stellt ebenfalls ein ähnliches Hilfsprogramm bereit:
cacti. Sein Einsatz ist etwas komplizierter, da es ausschließlich auf SNMP beruht. Obwohl es eine Web-Schnittstelle hat, benötigen das Verständnis der Konzepte, die für die Konfigurierung verwendet werden, noch einige Anstrengungen. Die Lektüre der HTML-Dokumentation (
/usr/share/doc/cacti/html/Table-of-Contents.html) ist daher als Voraussetzung anzusehen.
14.3.3. Eindringen vermeiden
Angreifer versuchen, durch das Erraten von Passwörtern Zugang zu Servern zu erhalten, weshalb immer starke Passwörter verwendet werden müssen. Auch dann sollten Sie Maßnahmen gegen Brute-Force-Angriffe ergreifen. Ein Brute-Force-Angriff ist der Versuch, sich durch mehrfache Anmeldeversuche in kurzer Zeit in ein unautorisiertes Softwaresystem einzuloggen.
Die beste Methode, einen Brute-Force-Angriff zu stoppen, besteht darin, die Anzahl der Anmeldeversuche, die den gleichen Ursprung haben, zu begrenzen, in der Regel durch vorübergehendes Verbieten einer IP-Adresse.
Fail2Ban ist eine Intrusion Prevention Software-Suite, die so konfiguriert werden kann, dass sie jeden Dienst überwacht, der Anmeldeversuche in eine Protokolldatei schreibt. Sie ist im Paket fail2ban zu finden.
Fail2Ban wird über ein einfaches Protokoll per fail2ban-client konfiguriert, das auch Konfigurationsdateien liest und entsprechende Konfigurationsbefehle an den Server, fail2ban-server, sendet. Er verfügt über vier Konfigurationsdateitypen, die alle in /etc/fail2ban gespeichert sind:
fail2ban.conf. Globale Konfiguration (wie z.B. Protokollierung).
filter.d/*.conf. Filter, die angeben, wie Authentifizierungsfehler erkannt werden können. Das Debian-Paket enthält bereits Filter für viele gängige Programme.
action.d/*.conf. Aktionen zur Definition der Befehle zum Sperren und Entsperren von IP-Adressen.
jail.conf. Hier werden jails, die Kombinationen von Filtern und Aktionen, definiert.
Werfen wir einen Blick auf die Konfiguration von sshd in /etc/fail2ban/jail.conf, um besser zu verstehen, wie Fail2Ban funktioniert...
[...]
[DEFAULT]
[...]
bantime = 10m
[...]
maxretry = 5
[...]
[sshd]
port = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
Fail2Ban prüft auf fehlgeschlagene Login-Versuche für sshd unter Verwendung regulärer Python-Ausdrücke, die in /etc/fail2ban/filters.d/sshd.conf definiert sind, in der Protokolldatei von sshd, die in der Variable sshd_log in der Datei /etc/fail2ban/paths_common.conf definiert ist. Wenn Fail2Ban fünf fehlgeschlagene Anmeldeversuche hintereinander erkennt, verbannt es die IP-Adresse, von der diese Versuche ausgegangen sind.
Fail2Ban ist ein sehr einfacher und effektiver Weg, um sich gegen die häufigsten Brute-Force-Angriffe zu schützen, aber es kann nicht vor verteilten Brute-Force-Angriffen schützen, d.h. wenn ein Angreifer eine große Anzahl von Rechnern nutzt, die über das Internet verteilt sind.
Eine gute Möglichkeit, zusätzlichen Schutz gegen verteilte Brute-Force-Angriffe zu bieten, besteht darin, die Anmeldezeit nach jedem fehlgeschlagenen Versuch künstlich zu verlängern.
14.3.4. Änderungen erkennen
Sobald das System installiert und konfiguriert ist, gibt es, abgesehen von Sicherheitsupgrades, für die meisten Dateien und Verzeichnisse in der Regel keinen Grund mehr, sich weiterzuentwickeln, Daten ausgenommen. Es ist daher interessant, sich zu vergewissern, dass sich die Dateien tatsächlich nicht ändern: Jede unerwartete Änderung wäre daher eine Untersuchung wert. In diesem Abschnitt werden einige Werkzeuge vorgestellt, die in der Lage sind, Dateien zu überwachen und den Administrator zu warnen, wenn eine unerwartete Änderung eintritt (oder einfach, um solche Änderungen aufzulisten).
14.3.4.1. Pakete mit logcheck prüfen
dpkg --verify (oder dpkg -V) ist ein interessantes Tool, weil es herausfindet welche installierten Dateien (möglicherweise von einem Angreifer) modifiziert wurden aber dies sollte man nicht für bare Münze nehmen. Um seine Arbeit zu verrichten, bezieht es sich auf Prüfsummen i der dpkg eigenen Datenbank welche auf der lokalen Festplatte liegt (man findet sie unter /var/lib/dpkg/info/package.md5sums). Ein gründlicher Angreifer wird diese Dateien also mit den neuen Prüfsummen der manipulierten Dateien aktualisieren.
Das Ausführen von dpkg -V überprüft alle installierten Pakete und gibt eine Zeile pro Datei mit fehlgeschlagenem Test aus. Das Ausgabeformat ist das gleiche wie das von rpm -V, wobei jedes Zeichen einem Test auf bestimmte Metadaten entspricht. Leider speichert dpkg die für die meisten Tests benötigten Metadaten nicht und gibt daher Fragezeichen aus. Derzeit kann nur der Prüfsummentest eine "5" für das dritte Zeichen ergeben (wenn er fehlschlägt).
# dpkg -V
??5?????? /lib/systemd/system/ssh.service
??5?????? c /etc/libvirt/qemu/networks/default.xml
??5?????? c /etc/lvm/lvm.conf
??5?????? c /etc/salt/roster
Im obigen Beispiel meldet dpkg an der Servicedatei von SSH eine Änderung, die der Administrator an der gepackten Datei vorgenommen hat, anstatt einen entsprechenden /etc/system/system/ssh.service Override zu verwenden (der unter /etc gespeichert würde, so wie jede Änderung einer Konfiguration sein sollte). Außerdem werden mehrere Konfigurationsdateien (gekennzeichnet durch den Buchstaben "c" im zweiten Feld) aufgelistet, die korrekt geändert wurden.
14.3.4.2. Pakete auditieren: debsums und seine Grenzen
debsums ist der Vorgänger von dpkg -V und damit meist veraltet. Es hat die gleichen Einschränkungen wie dpkg. Glücklicherweise können einige der Einschränkungen umgangen werden (während dpkg keine ähnlichen Workarounds bietet).
Weil man den Daten auf der Festplatte nicht trauen kann, ermöglicht debsums Prüfungen basierend auf .deb Dateien anstatt sich auf die dpkg Datenbank zu verlassen. Um gesicherte .deb Dateien für alle installierten Pakete herunterzuladen können wir uns auf die von APT beglaubigten Downloads verlassen. Diese Aktion kann sehr langsam und langwierig sein und sollte daher als proaktive Technik in Betracht gezogen werden und nicht regelmäßig verwendet werden.
# apt-get --reinstall -d install `grep-status -e 'Status: install ok installed' -n -s Package`
[ ... ]
# debsums -p /var/cache/apt/archives --generate=all
Man beachte, dass in diesem Beispiel der Befehl grep-status aus dem Paket grep-dctrl verwendet wird, das nicht standardmäßig installiert ist.
debsums kann häufig als Cronjob-Einstellung CRON_CHECK in /etc/default/debsums ausgeführt werden. Um bestimmte Dateien außerhalb des /etc-Verzeichnisses zu ignorieren, die absichtlich geändert wurden oder erwartet wird, dass sie sich ändern (wie /usr/share/misc/pci.ids), können Sie sie zu /etc/debsums-ignore hinzufügen.
14.3.4.3. Dateien überwachen: AIDE
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.db) abgespeichert, die relevante Informationen über alle Dateien des Systems enthält (Fingerabdrücke, Berechtigungen, Zeitstempel und so weiter). Diese Datenbank wird erstmals mit dem Befehl aideinit initialisiert; sie wird dann täglich (mit dem Skript /etc/cron.daily/aide) genutzt, um nachzuprüfen, dass 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.
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 waren, kann sie als Ersatz für die Referenzdatenbank verwendet werden.
14.3.5. Eindringen entdecken (IDS/NIDS)
suricata (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 in verschiedenen Dateien unter
/var/log/suricata protokolliert. Es gibt Hilfsprogramme von Drittanbietern (Kibana/logstash) mit denen man die gesammelten Daten besser durchsuchen kann.
Die Konfiguration von suricata beinhaltet die Überprüfung und Bearbeitung von /etc/suricata/suricata-debian.yaml, was sehr lang daueren kann, da jeder Parameter reichlich kommentiert wird. Eine minimale Konfiguration erfordert die Beschreibung des Adressbereichs, den das lokale Netzwerk abdeckt (Parameter HOME_NET). In der Praxis bedeutet dies der Umfang aller möglichen Angriffsziele. Aber um das Beste daraus zu machen, muss man es vollständig lesen und an die örtlichen Gegebenheiten anpassen.
Außerdem sollten Sie /etc/default/suricata bearbeiten, um die Netzwerkschnittstelle für die Überwachung zu definieren und das Initskript zu aktivieren (durch Setzen von RUN=yes). Sie können auch LISTENMODE=pcap setzen, da die Standardeinstellung LISTENMODE=nfqueue eine weitere Konfiguration erfordert, um korrekt zu funktionieren (die netfilter-Firewall muss so konfiguriert sein, dass sie Pakete an eine von Suricata verwaltete User Space-Warteschlange über das NFQUEUE Ziel durchreicht).
Suricata muss einen Satz an Monitoring-Regeln erstellen, um bösartiges Verhalten zu entdecken: Man findet solche Regeln im snort-rules-default Paket. Snort ist historisch die Referenz im IDS-Ökosystem und suricata kann die Regelsätze, die für Snort geschrieben wurden, weiterverwenden.
Wahlweise kann auch oinkmaster (im Paket selben Namens) genutzt werden um Snort Regelsätze von externen Quellen zu beziehen.
