Strumento per catturare informazioni sensibili da linee di comando [chiuso]

Sui sistemi Linux, tutte queste informazioni sono disponibili tramite l'interfaccia proc e, in quanto tale, sono abbastanza facilmente programmabili. Come esempio di lavoro (proveniente da un sistema RHEL6) diamo un'occhiata al processo rsyslog.

[user@node1 ~]$ ps aux | grep rsyslog
root      1105  0.0  0.0 248680  1460 ?        Sl   May29   0:42 /sbin/rsyslogd -i /var/run/syslogd.pid -c 4
user     26440  0.0  0.0 103236   824 pts/4    S+   11:38   0:00 grep rsyslog

Bene, quindi il pid è 1105, abbastanza facile. Poiché il sistema proc memorizza i processi nel formato di /proc/<pid> , vediamo quali dati vengono presentati.

[user@node1 ~]$ ls -l /proc/1105
ls: cannot read symbolic link /proc/1105/cwd: Permission denied
ls: cannot read symbolic link /proc/1105/root: Permission denied
ls: cannot read symbolic link /proc/1105/exe: Permission denied
total 0
dr-xr-xr-x. 2 root root 0 Jun 15 11:39 attr
-rw-r--r--. 1 root root 0 Jun 15 11:39 autogroup
-r--------. 1 root root 0 Jun 15 11:39 auxv
-r--r--r--. 1 root root 0 Jun 15 11:39 cgroup
--w-------. 1 root root 0 Jun 15 11:39 clear_refs
-r--r--r--. 1 root root 0 Jun 15 11:35 cmdline
-rw-r--r--. 1 root root 0 Jun 15 11:39 coredump_filter
-r--r--r--. 1 root root 0 Jun 15 11:39 cpuset
lrwxrwxrwx. 1 root root 0 Jun 15 11:39 cwd
-r--------. 1 root root 0 Jun 15 11:39 environ
lrwxrwxrwx. 1 root root 0 Jun 15 11:39 exe
dr-x------. 2 root root 0 Jun 15 11:39 fd
dr-x------. 2 root root 0 Jun 15 11:39 fdinfo
-r--------. 1 root root 0 Jun 15 11:39 io
-rw-------. 1 root root 0 Jun 15 11:39 limits
-rw-r--r--. 1 root root 0 Jun 15 11:39 loginuid
-r--r--r--. 1 root root 0 Jun 15 11:39 maps
-rw-------. 1 root root 0 Jun 15 11:39 mem
-r--r--r--. 1 root root 0 Jun 15 11:39 mountinfo
-r--r--r--. 1 root root 0 Jun 15 11:39 mounts
-r--------. 1 root root 0 Jun 15 11:39 mountstats
dr-xr-xr-x. 6 root root 0 Jun 15 11:39 net
-r--r--r--. 1 root root 0 Jun 15 11:39 numa_maps
-rw-r--r--. 1 root root 0 Jun 15 11:39 oom_adj
-r--r--r--. 1 root root 0 Jun 15 11:39 oom_score
-rw-r--r--. 1 root root 0 Jun 15 11:39 oom_score_adj
-r--r--r--. 1 root root 0 Jun 15 11:39 pagemap
-r--r--r--. 1 root root 0 Jun 15 11:39 personality
lrwxrwxrwx. 1 root root 0 Jun 15 11:39 root
-rw-r--r--. 1 root root 0 Jun 15 11:39 sched
-r--r--r--. 1 root root 0 Jun 15 11:39 schedstat
-r--r--r--. 1 root root 0 Jun 15 11:39 sessionid
-r--r--r--. 1 root root 0 Jun 15 11:39 smaps
-r--r--r--. 1 root root 0 Jun 15 11:39 stack
-r--r--r--. 1 root root 0 Jun 15 11:35 stat
-r--r--r--. 1 root root 0 Jun 15 11:39 statm
-r--r--r--. 1 root root 0 Jun 15 11:35 status
-r--r--r--. 1 root root 0 Jun 15 11:39 syscall
dr-xr-xr-x. 6 root root 0 Jun 15 11:39 task
-r--r--r--. 1 root root 0 Jun 15 11:39 wchan

Lo sto facendo come un utente normale, quindi alcune informazioni non sono disponibili. Un grosso problema, perché quello che vogliamo veramente è che ci sia un file chiamato cmdline .

[user@node1 ~]$ cat /proc/1105/cmdline
/sbin/rsyslogd-i/var/run/syslogd.pid-c4[user@node1 ~]$

Gli argomenti sembrano fatti funzionare insieme. Infatti, sono separati da caratteri nulli. Si otterrà una visualizzazione più amichevole trasformando i caratteri nulli in nuove righe (ma si noti che si eliminerà la distinzione tra separazioni tra argomenti e righe nuove effettive in un argomento):

[user@node1 ~]$ tr '
for p in /proc/[0-9]*/cmdline; do
  …
done
' '\n' </proc/1105/cmdline; echo
/sbin/rsyslogd
-i
/var/run/syslogd.pid
-c
4
[user@node1 ~]$

Certo, questo veramente non ci dà nulla oltre a ciò che abbiamo ottenuto dall'output di ps. Tuttavia, a seconda di ciò che vuoi, potrebbe essere più facilmente programmabile. Ad esempio, se volessimo lavorare esclusivamente in bash, potremmo usare questa struttura per iterare su tutti i processi:

[user@node2 ~]$ ps aux | grep mysql
user     7974  0.0  0.1 157116  2732 pts/0    S+   11:47   0:00 mysql -u root -px xxxxxxxxxx database
[user@node2 ~]$ cat /proc/7974/cmdline
mysql-uroot-pxxxxxxxxxxxdashboard[user@node2 ~]$

Quindi usalo come elenco file per l'elaborazione.

Se invece sei in Perl, esiste un modulo chiamato Proc :: ProcessTable che interroga il sistema proc ed espone le stesse informazioni di un oggetto.

Tutto ciò che viene detto, se si desidera cercare password sulla riga di comando, a volte può essere deluso. Alcune applicazioni in qualche modo funzionano per mascherarlo, ad esempio MySQL:

[user@node1 ~]$ ps aux | grep rsyslog
root      1105  0.0  0.0 248680  1460 ?        Sl   May29   0:42 /sbin/rsyslogd -i /var/run/syslogd.pid -c 4
user     26440  0.0  0.0 103236   824 pts/4    S+   11:38   0:00 grep rsyslog

Questo è il tipo di compito che gli umani fanno molto meglio delle macchine. E con ciò intendo riconoscimento di schemi. Potresti provare a scrivere uno script che chiama continuamente ps (eliminando il comando e quindi ordinando i duplicati con sort -u) e quindi rivedere l'output in un secondo momento. Tuttavia, tieni presente che ora persiste i dati che hai già identificato come potenzialmente sensibili. Assicurati che le sue autorizzazioni siano corrette o che siano archiviate in un formato crittografato. Controlla periodicamente fino a quando non ti senti a tuo agio con gli utenti e poi abbandona lo script per ridurre i costi di manutenzione.

Tornando al tuo ipotetico strumento, il numero di falsi positivi che genererebbe sarebbe sbalorditivo a meno che le password fossero già note a questo. In tal caso, dal momento che ora condividi informazioni riservate tra gli utenti, aumenti il rischio di non diminuirlo.

Un metodo per ridurre questi falsi positivi è rendere lo script il più semplice possibile. Ad esempio, limita solo i comandi comuni con argomenti coerenti che richiedono l'immissione di password sulla riga di comando. Anche in questo caso, lo scripting della shell può diventare così complesso da ottenere una serie di falsi negativi e positivi. Il meglio che puoi fare è espressioni regolari e sarà un incubo da implementare. Ciò significa che il valore di tale strumento diminuisce, specialmente se si considerano i costi di manutenzione. Penso che ci siano probabilmente cose migliori che un amministratore potrebbe fare con il loro tempo.

Inoltre, questo è un approccio reazionario alla sicurezza e non preventivo. Forse c'è un modo nel tuo sistema per impedire agli utenti di vedere le informazioni sui processi di altri utenti? Questo è probabilmente altamente improbabile, ma potrebbe essere la domanda migliore da porre.

Si noti inoltre che questa informazione finisce anche per entrare nel file di cronologia dell'utente, essenzialmente persistendo nella divulgazione. Il controllo delle autorizzazioni / proprietà di quei file potrebbe essere un compito utile. Stessa cosa con i log che potrebbero contenere password o altre informazioni sensibili. Inoltre alcune applicazioni come mysql potrebbero registrare la cronologia dei comandi.

L'automazione di tali processi è davvero un compito banale, una volta che sai cosa vuoi ottenere.

Supponendo che i tuoi sistemi siano Linux box, gli script di bash / python / perl possono essere facilmente scritti per eseguire comandi e analizzare i risultati. Tali script potrebbero anche confrontare le differenze tra le uscite giorno per giorno. Gli script possono essere impostati per l'esecuzione regolare tramite l'uso di cron jobs.

L'utilità dei risultati dipenderà dalla persona che la monitora / interpreta.

Lo stesso potrebbe presumibilmente essere fatto per le finestre con script batch (non troppo sicuro).

Hum, sai come penso a questa domanda. Non sono così sicuro di quanto sarebbe banale questo compito. Vuoi informazioni su ciascuna immagine, presumibilmente vuoi anche informazioni su istanze di breve durata.

Quindi se vuoi tutte queste informazioni potresti parlare di usare la piattaforma di filtro di Windows e qualcosa come epoll per Posix in modo da poter ottenere tutte le notifiche di I / O degli eventi.

Quindi è necessario un modo per mantenere questi dati e trasportarli in un repository centrale dove può aggregare questi dati per il consumo. Questo sarebbe un sacco di dati, richiederebbe molta potenza per fare l'analisi dal vivo. Probabilmente dovresti dipendere da un processo / soluzione come un ETL o Map / Reduce prima di poter dare un senso a questo. Ovviamente potresti semplicemente inviarlo a un server syslog e passarlo a mano, credo che ti travolgerebbe rapidamente.

Supponiamo invece di poter eseguire l'elaborazione e il filtraggio localmente sulla macchina e di esportare solo in corrispondenza di corrispondenze positive di syslog / server di aggregazione.

Non conosco uno strumento che funzioni in modo specifico, forse se hai installato un prodotto AV / HIPS che ti consente di scrivere una regola personalizzata, potresti magari avvicinarti. Un'applicazione personalizzata da zero sarebbe un progetto salutare per un singolo sviluppatore, probabilmente divertente.

Guardare regolarmente la lista dei processi non è molto affidabile. Qualsiasi metodo di campionamento è altamente probabile che manchi di processi di breve durata che un attaccante più mirato che non ha paura di utilizzare temporaneamente molte risorse della CPU potrebbe catturare.

Utilizza i meccanismi di registrazione esistenti del tuo sistema operativo. Anche se si sceglie il campionamento perché la registrazione sistematica è troppo costosa, campionare per (diciamo) un minuto intero di tanto in tanto (preferibilmente nei momenti in cui le cose accadono).

Ad esempio, in Linux, utilizzare il sottosistema di controllo ( auditd ) per registrare tutte le chiamate alla chiamata di sistema execve . Vedi Registrazione dei comandi di Linux? per una panoramica generale e Esempio semplice di configurazione auditd per un how-to. Si noti che sotto Linux, gli argomenti di un processo sono pubblicamente leggibili (eccetto che con alcune impostazioni di sicurezza restrittive con SELinux o ambienti simili ad alta sicurezza), ma le variabili d'ambiente possono essere viste solo da altri processi eseguiti dallo stesso utente. Per avere un'idea di cosa è pubblico e cosa no, esegui ls /proc/1 .