
dawg the hallway monitor - monitora le modifiche del sistema operativo e analizza la superficie d'attacco introdotta durante l'installazione del software
dawgmon - Dawg il Sorvegliante dei Corridoi
SOMMARIO
Il nome di questo strumento è basato su un episodio (stagione 10, episodio 10) di South Park in cui Cartman è Dawg il Sorvegliante dei Corridoi che pattuglia i corridoi della sua scuola. È uno strumento che aiuta a monitorare i cambiamenti avvenuti su un sistema basato su Linux dall'ultima esecuzione dello strumento.
Un modo per usarlo è di utilizzare qualcosa come il cronjob di esempio incluso per eseguire dawgmon a intervalli regolari e inviare via email i risultati all'amministratore di sistema. Questo può aiutare a identificare macchine su cui stanno accadendo cose losche e monitorare chi installa cosa e dove. Si prega di notare che qualsiasi backdoor seria a livello di kernel può facilmente nascondersi da questo strumento, quindi è solo uno strumento aggiuntivo nella cassetta degli attrezzi, ma non dovrebbe essere considerato affidabile per il monitoraggio completo della sicurezza delle macchine Linux. È solo un'opzione extra nella propria cassetta degli attrezzi.
L'altro modo in cui è utile è generando una baseline prima di installare un software. Poi, dopo aver installato tale software, si esegue di nuovo lo strumento e diventa facile vedere quali cambiamenti sono stati apportati al sistema. Un esempio dopo aver stabilito una baseline e poi aver installato virtualbox su una macchina potrebbe produrre qualcosa del genere:
# ./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
Quanto sopra aiuta ora a fare una revisione approfondita della sicurezza di virtualbox. I binari suid installati sono punti di ingresso ovvi e i servizi in esecuzione sono interessanti.
Un altro esempio di esecuzione che rileva correttamente l'apertura e la chiusura delle porte TCP:
# ./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
#
Lo strumento non è pensato per una precisione assoluta. Ci sono raccomandazioni molto serie di solito di non fare affidamento sull'output dei GNU core-utils come ls per l'input di uno strumento. In altre parole; raramente si dovrebbero costruire strumenti per analizzare e fare affidamento su questo tipo di output perché può cambiare continuamente. Realisticamente l'output di questi strumenti è relativamente stabile poiché molte persone e strumenti automatici già fanno affidamento sui loro output per vari scopi.
Tuttavia il compromesso per dawgmon è il seguente; avremmo bisogno di implementare molta logica per fare il monitoraggio del filesystem da soli, costruire binari complessi che includano librerie per analizzare e monitorare i dispositivi a blocchi, le interfacce di rete e quant'altro. Questo renderebbe anche lo strumento molto più complesso e meno manutenibile. Sui progetti attualmente si può aggiungere un nuovo comando, inclusa la rilevazione dei cambiamenti, in pochissimo tempo poiché lo strumento principale dawgmon si occupa già di caching, esecuzione del comando e poi fornitura dell'output precedente e corrente quando si esegue un confronto con un'implementazione del comando. Ciò significa che su progetti con vincoli di tempo si può aggiungere molto rapidamente un nuovo comando ed eseguire analisi includendo quei nuovi comandi.
Un comando può essere aggiunto semplicemente ereditando dalla classe Command. Questa classe è definita in commands/init.py. Quel file contiene anche l'elenco principale dei comandi (e l'ordine in cui vengono eseguiti quando si esegue un'analisi completa). Poi le proprietà come 'name', 'shell', 'command' e 'desc' dovranno essere impostate e due metodi 'parse()' e 'compare()' dovranno essere implementati. Sono inclusi abbastanza comandi per farsi un'idea su come implementarne e aggiungerne di nuovi.
USO
Per ottenere i migliori risultati esegui lo strumento come root. Per aiuto digita -h/--help e per informazioni sulla versione digita -v/--version.
Un'azione principale deve sempre essere specificata. Queste azioni sono: -A: analizza il sistema -C: confronta voci della cache -E: elenca i comandi disponibili -L: elenca le voci della cache
# runs an analysis
dawgmon -A
# runs an analysis but only with a few commands
dawgmon -A -e list_suids -e list_tcpudp_ports
# shows the list of available commands
dawgmon -E
# shows available cache entries for comparison
dawgmon -L
# compare old cache entry 3 with new cache entry 5
dawgmon -C 3 5
Ulteriori opzioni per aiutare con l'analisi sono:
-d: mostra output di debug -e: esegue un comando specifico (può essere usato più volte) -f: forza un'esecuzione senza avvisare sull'esecuzione come root -g: colora l'output -l: posizione del database della cache da usare -m: numero massimo di voci della cache consentite nella cache (se la cache ha più voci di questo numero, troncherà il database) -t: non mostra informazioni temporali per ogni anomalia rilevata.
Per maggiori informazioni sull'uso esegui lo strumento con -h.
LIMITAZIONI
Lo strumento analizza l'output di strumenti da riga di comando e si basa su opzioni specifiche dei GNU core-utils per alcune cose. Non c'è una ragione specifica per cui questo strumento e le implementazioni dei comandi non possano essere rapidamente portati su altri sistemi operativi come i BSD, ma al momento non viene effettuato alcun rilevamento del sistema operativo né una classificazione dei comandi basata sul supporto del sistema operativo. Questo dovrebbe essere implementato prima.
Riguardo alla ricerca di pipe, socket UNIX, file in /boot, /etc e altri, si deve notare che l'uso di -xdev passato a 'find' significa che non tutti i filesystem montati sotto la directory di partenza verranno attraversati. Ciò significa che, ad esempio, /boot sarà scansionato correttamente ma /boot/efi potrebbe non esserlo. In futuro si dovrà utilizzare un approccio più intelligente.
I timestamp quando si esegue un'analisi corrente potrebbero essere un po' confusi. Per impostazione predefinita, un timestamp per un messaggio di anomalia di avviso, normale o di debug sarà il timestamp del suo momento di generazione (come si può vedere in commands/init.py). Le anomalie vengono generate dopo che è stata eseguita una scansione completa della riga di comando. Quindi l'output su cui si basa questa rilevazione è stato generato prima e successivamente i timestamp per le singole anomalie mostrano un orario successivo a quello della scansione. Quando si confrontano voci della cache, viene utilizzato il timestamp della scansione per mostrare l'orario in cui è avvenuta la rilevazione, poiché ciò ha logicamente più senso.
INFO
Tutti i diritti riservati. Copyright (C) 2017-2019 di Anvil Ventures Inc. Per informazioni sulla licenza vedere LICENSE. Per maggiori informazioni contattare Vincent Berg [email protected]
Per trovare il codice sorgente aggiornato o per contribuire con patch visitare il seguente URL: https://github.com/anvilventures/dawgmon/