Skip to content
KitploitKITPLOIT
ToolsBlog
Einreichen
ToolsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

··Feeds·Kontakt·Datenschutz·© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
dawgmon — dawg the hallway monitor - überwacht Änderungen am Betriebssystem und analysiert die eingeführte Angriffsfläche bei der Installation von Software | Kitploit
Tools/GitHubGitHub/anvilsecure/dawgmon
DefensivwerkzeugeSchwachstellenanalyseKonfigurationsprüfungIncident Response
GitHubanvilsecure/dawgmon

dawgmon

dawg the hallway monitor - überwacht Änderungen am Betriebssystem und analysiert die eingeführte Angriffsfläche bei der Installation von Software

Repository anzeigen
55849vor 6 JahrenVon Kitploit geprüft

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Webseite
Teilen

dawgmon - Dawg, der Flurüberwacher

ZUSAMMENFASSUNG

Der Name dieses Tools basiert auf einer Episode (Staffel 10, Folge 10) von South Park, in der Cartman als Dawg, der Flurüberwacher, die Flure seiner Schule patrouilliert. Es ist ein Tool, das dabei hilft, Änderungen zu überwachen, die seit der letzten Ausführung des Tools auf einem Linux-basierten System stattgefunden haben.

Eine Möglichkeit, es zu verwenden, besteht darin, etwas wie den mitgelieferten Cronjob zu nutzen, um dawgmon in regelmäßigen Abständen auszuführen und die Ergebnisse per E-Mail an den Systemadministrator zu senden. Dies kann dabei helfen, Maschinen zu identifizieren, auf denen üble Dinge passieren, und zu überwachen, wer was wo installiert. Bitte beachten Sie, dass ernsthafte Kernel-Backdoors sich leicht vor diesem Tool verstecken können – es ist daher nur ein weiteres Werkzeug im Arsenal, aber es sollte nicht für die vollständige Sicherheitsüberwachung von Linux-Maschinen verwendet werden. Es ist nur eine zusätzliche Option im Werkzeugkasten.

Die andere Art, wie es nützlich ist, ist die Erstellung einer Basislinie vor der Installation einer Software. Nach der Installation dieser Software führt man das Tool erneut aus und kann dann leicht sehen, welche Änderungen am System vorgenommen wurden. Ein Beispiel nach der Erstellung einer Basislinie und der Installation von VirtualBox auf einer Maschine könnte etwa so aussehen:

root@kitploit:~
# ./dawgmon -gfA
1 change detected (0 warnings)            
+ systemd property NNames changed from 259 to 261
# apt install virtualbox-5.1
[...]
# ./dawgmon -gfA
33 changes detected (0 warnings)          
+ size of file /etc/group changed from 937 to 954
+ file /etc/group got modified on 2017-09-14 19:29:51.804811 +0200
+ size of file /etc/group- changed from 934 to 937
+ file /etc/group- got modified on 2017-09-14 19:29:14.000000 +0200
+ file /etc/gshadow got modified on 2017-09-14 19:29:51.812811 +0200
+ size of file /etc/gshadow- changed from 777 to 794
+ size of file /etc/mailcap changed from 40777 to 41063
+ file /etc/mailcap got modified on 2017-09-14 19:29:51.632812 +0200
+ file /etc/systemd/system/multi-user.target.wants/vboxautostart-service.service got created (owner=root, group=root, perm=lrwxrwxrwx, size=49)
+ file /etc/systemd/system/multi-user.target.wants/vboxballoonctrl-service.service got created (owner=root, group=root, perm=lrwxrwxrwx, size=51)
+ file /etc/systemd/system/multi-user.target.wants/vboxdrv.service got created (owner=root, group=root, perm=lrwxrwxrwx, size=35)
+ file /etc/systemd/system/multi-user.target.wants/vboxweb-service.service got created (owner=root, group=root, perm=lrwxrwxrwx, size=43)
+ file /etc/udev/rules.d/60-vboxdrv.rules got created (owner=root, group=root, perm=-rw-r--r--, size=747)
+ group vboxusers added
+ package virtualbox-5.1 is to be installed
+ suid binary /usr/lib/virtualbox/VBoxHeadless got created (owner=root, group=root, perm=-r-s--x--x, size=158304)
+ suid binary /usr/lib/virtualbox/VBoxNetAdpCtl got created (owner=root, group=root, perm=-r-s--x--x, size=23144)
+ suid binary /usr/lib/virtualbox/VBoxNetDHCP got created (owner=root, group=root, perm=-r-s--x--x, size=158304)
+ suid binary /usr/lib/virtualbox/VBoxNetNAT got created (owner=root, group=root, perm=-r-s--x--x, size=158304)
+ suid binary /usr/lib/virtualbox/VBoxSDL got created (owner=root, group=root, perm=-r-s--x--x, size=158296)
+ suid binary /usr/lib/virtualbox/VBoxVolInfo got created (owner=root, group=root, perm=-r-s--x--x, size=10472)
+ suid binary /usr/lib/virtualbox/VirtualBox got created (owner=root, group=root, perm=-r-s--x--x, size=158304)
+ i-node for listening UNIX socket /run/systemd/private changed from 3428734 to 3452848
+ systemd property NInstalledJobs changed from 8392199 to 3238035463
+ systemd property NNames changed from 261 to 263
+ systemd unit file vboxautostart-service.service added
+ systemd unit file vboxballoonctrl-service.service added
+ systemd unit file vboxdrv.service added
+ systemd unit file vboxweb-service.service added
+ systemd unit 'vboxautostart-service.service' added
+ systemd unit 'vboxballoonctrl-service.service' added
+ systemd unit 'vboxdrv.service' added
+ systemd unit 'vboxweb-service.service' added

Das Obige hilft dabei, eine gründliche Sicherheitsüberprüfung von VirtualBox durchzuführen. Die installierten SUID-Binärdateien sind offensichtliche Angriffspunkte, und die laufenden Dienste sind interessant.

Ein weiteres Beispiel, das korrekt das Öffnen und Schließen von TCP-Ports erkennt:

root@kitploit:~
# ./dawgmon -gfA
0 changes detected (0 warnings)           
# nc -l -p 4455 &
[1] 12489
# ./dawgmon -gfA
1 change detected (0 warnings)            
+ port 4455 tcp opened
# fg
nc -l -p 4455
^C
# ./dawgmon -gfA
1 change detected (0 warnings)            
+ port 4455 tcp closed
# 

Das Tool ist nicht für absolute Genauigkeit gedacht. Es gibt ernsthafte Empfehlungen, sich normalerweise nicht auf die Ausgabe von GNU core-utils wie ls als Tool-Eingabe zu verlassen. Mit anderen Worten: Man sollte selten Tools bauen, die diese Art von Ausgabe parsen und sich darauf verlassen, da sie sich jederzeit ändern kann. Realistisch betrachtet ist die Ausgabe dieser Tools relativ stabil, da viele Menschen und automatische Tools sich bereits für alle möglichen Zwecke auf ihre Ausgaben verlassen.

Der Kompromiss für dawgmon ist jedoch folgender: Wir müssten viel Logik selbst implementieren, um das Dateisystem zu überwachen, komplexe Binärdateien erstellen, die Bibliotheken zum Parsen und Überwachen von Blockgeräten, Netzwerkschnittstellen und mehr enthalten. Dies würde das Tool weitaus komplexer und weniger wartbar machen. Bei aktuellen Projekten kann man in sehr kurzer Zeit einen neuen Befehl inklusive Änderungserkennung hinzufügen, da das Haupttool dawgmon bereits das Caching, die Ausführung des Befehls und die Bereitstellung der vorherigen und aktuellen Ausgabe beim Ausführen eines Vergleichs mit einer Befehlsimplementierung übernimmt. Das bedeutet, dass man in zeitlich begrenzten Projekten sehr schnell einen neuen Befehl hinzufügen und Analysen einschließlich dieser neuen Befehle durchführen kann.

Ein Befehl kann hinzugefügt werden, indem einfach von der Command-Klasse geerbt wird. Diese Klasse ist in commands/__init__.py definiert. Diese Datei enthält auch die Hauptliste der Befehle (und die Reihenfolge, in der sie bei einer vollständigen Analyse ausgeführt werden). Dann müssen die Eigenschaften wie name, shell, command und desc gesetzt und zwei Methoden parse() und compare() implementiert werden. Es sind genügend Befehle enthalten, um eine gute Vorstellung davon zu bekommen, wie man neue implementiert und hinzufügt.

VERWENDUNG

Für beste Ergebnisse führen Sie das Tool als root aus. Für Hilfe geben Sie -h/--help ein, für Versionsinformationen -v/--version.

Eine Hauptaktion muss immer angegeben werden. Diese Aktionen sind:

  • -A: System analysieren
  • -C: Cache-Einträge vergleichen
  • -E: Verfügbare Befehle auflisten
  • -L: Cache-Einträge auflisten
root@kitploit:~
# führt eine Analyse durch
dawgmon -A

# führt eine Analyse durch, jedoch nur mit wenigen Befehlen
dawgmon -A -e list_suids -e list_tcpudp_ports

# zeigt die Liste der verfügbaren Befehle
dawgmon -E

# zeigt verfügbare Cache-Einträge für den Vergleich
dawgmon -L

# vergleicht alten Cache-Eintrag 3 mit neuem Cache-Eintrag 5
dawgmon -C 3 5

Weitere Optionen zur Unterstützung der Analyse sind:

  • -d: Debug-Ausgabe anzeigen
  • -e: Einen bestimmten Befehl ausführen (kann mehrfach verwendet werden)
  • -f: Ausführung erzwingen, ohne Warnung, dass root erforderlich ist
  • -g: Ausgabe farblich hervorheben
  • -l: Speicherort der Datenbank-Cache-Datei
  • -m: Maximale Anzahl von Cache-Einträgen, die im Cache erlaubt sind (wenn der Cache mehr Einträge als diese Anzahl hat, wird die Datenbank abgeschnitten)
  • -t: Keine Zeitstempelinformationen pro erkannte Anomalie ausgeben

Weitere Verwendungsinformationen erhalten Sie, wenn Sie das Tool mit -h ausführen.

EINSCHRÄNKUNGEN

Das Tool parst die Ausgabe von Befehlszeilentools und verlässt sich für einige Teile auf GNU core-utils-spezifische Optionen. Es gibt keinen spezifischen Grund, warum dieses Tool und die Befehlsimplementierungen nicht schnell auf andere Betriebssysteme wie die BSDs portiert werden könnten, aber derzeit findet keine Betriebssystemerkennung statt, noch wird eine Klassifizierung der Befehle basierend auf Betriebssystemunterstützung durchgeführt. Das müsste zuerst implementiert werden.

Bezüglich der Suche nach Pipes, UNIX-Sockets, Dateien in /boot, /etc und mehr ist zu beachten, dass die Verwendung von -xdev bei find bedeutet, dass nicht alle unter dem Startverzeichnis eingehängten Dateisysteme durchlaufen werden. Das bedeutet, dass beispielsweise /boot ordnungsgemäß gescannt wird, /boot/efi jedoch möglicherweise nicht. Hier müsste in Zukunft ein intelligenterer Ansatz verwendet werden.

Die Zeitstempel bei einer aktuellen Analyse können etwas verwirrend sein. Standardmäßig ist ein Zeitstempel für eine Warn-, Normal- oder Debug-Anomalie-Nachricht der Zeitstempel ihres Erstellungszeitpunkts (wie in commands/__init__.py zu sehen). Die Anomalien werden generiert, nachdem ein vollständiger Befehlszeilenscan abgeschlossen wurde. Die Ausgabe, auf der diese Erkennung basiert, wurde also früher erstellt, und anschließend zeigen die Zeitstempel für einzelne Anomalien eine Zeit nach dem Scanzeitpunkt an. Beim Vergleich von Cache-Einträgen wird der Zeitstempel des Scans verwendet, um die Zeit auszugeben, zu der die Erkennung stattfand, da dies logisch einfach sinnvoller ist.

ÜBER

Alle Rechte vorbehalten. Copyright (C) 2017-2019 by Anvil Ventures Inc. Lizenzinformationen finden Sie in LICENSE. Für weitere Informationen kontaktieren Sie Vincent Berg [email protected]

Den aktualisierten Quellcode finden Sie oder um Patches beizutragen, besuchen Sie die folgende URL: https://github.com/anvilventures/dawgmon/

Tool herunterladen