Tripwire - È il teatro della sicurezza?

18

I sistemi di rilevamento delle intrusioni di tipo Tripwire presumibilmente proteggono il sistema dai rootkit, monitorando i checksum dei file binari importanti per le modifiche.

Diciamo che ho tripwire configurato per l'esecuzione notturna e l'ho installato su un nuovo sistema non rootkit.
Quindi a mezzogiorno oggi un intruso esperto installa un rootkit sul mio sistema.

Come faccio a sapere che il loro rootkit non ha sostituito il mio tripwire con un imitatore di tripwire; utilizzando un diverso insieme di chiavi pubbliche / private (e binari di autenticazione falsi) che riproduce più o meno gli ultimi file (leggibili con la chiave pubblica) per assicurarmi che non vengano modificati i checksum (essenzialmente solo la riproduzione di file di registro noti). Immagino di poter notare che la mia passphrase privata non funziona più per aprire la chiave privata; ma non penso che sarebbe così difficile lasciare che una password funzioni (o solo la prima digitata). Credo che dovrei controllare le dimensioni dei file / shasum / md5sum di tripwire con valori noti, ma sul mio sistema rootkitted tutte quelle utility potrebbero essere compromesse.

Sto osservando la documentazione dal link e non vedo come tripwire offra sicurezza extra, oltre a rendere gli sviluppatori di rootkit un po 'più difficili da eseguire (per simulare un'utilità extra configurata dall'utente).

In pratica, dubito che farei regolarmente un cd live per controllare gli hash in modo sicuro; quindi mi chiedo se fornisce sicurezza o se è solo un teatro di sicurezza.

    
posta dr jimbob 04.01.2012 - 00:16
fonte

7 risposte

16

Penso che ci sia qualcosa da dire per l'impostazione di una barra, indipendentemente da quanto sia bassa. Tripwire può essere bypassato? Sicuro. Catturerà cose che non vorresti altrimenti? Sì lo sarà.

Il problema principale che ho riscontrato in un'installazione di Tripwire è la messa a punto in cui non è falso-positivo carico al punto da ignorarlo. Se esplode ogni volta che qualcuno cambia qualcosa nella loro directory home, lo ignorerai. Se esplode ogni volta che la tua gente del web cambia il tuo sito, lo ignorerai. Se esplode ogni volta che qualcuno aggiorna un pacchetto ... lo capisci. Tuttavia, se hai un buon flusso di lavoro intorno a dove si lamenta solo quando sta accadendo qualcosa di anormale, presterai attenzione ad esso, e questo sicuramente ha un valore.

    
risposta data 04.01.2012 - 17:13
fonte
9

I tripwires sono molto utili per difendersi da rootkit userland . Le rookit di Kernelland non hanno bisogno di sostituire i binari per sovvertire il comportamento del sistema, di solito questi rootkit sono solo un modulo Kernel di Linux (LKM). Infatti, quando controlli il kernel in questo modo, qualsiasi comportamento dell'eseguibile può essere influenzato senza la necessità di modificare il proprio sé binario. (Anche se di solito non è necessario).

Kerneland rootkits per Linux sono molto rari al giorno d'oggi poiché gli sviluppatori del kernel sono pronti a correggere queste vulnerabilità. Sono sicuro che qualcuno ha un rootkit del kernel Linux di 0 giorni, ma è più probabile che si incontri un rootkit di userland in natura.

Il rootkit Linux più recente Kbeast rilasciato nel 2012 e interessa fino a Linux 2.6.32 (rilasciato nel 2009), corrente al momento della scrittura dell'ultima versione è 2.6.39. Non so quanti di voi apprezzino davvero questo evento perché l'ultimo rootkit LKM era il Eyne LKM rookit pubblicato nel 2009. Inutile dire che questi attacchi sono pochi e lontani tra loro.

    
risposta data 04.01.2012 - 02:00
fonte
7

Oltre alle risposte di Rook e Jeff, anche Tripwire e soluzioni simili hanno un valore di avviso in tempo reale. Per sovvertire un sistema Tripwire che sta anche monitorando i propri file è necessario prevenirlo durante il processo di sovversione.

Non più un semplice attacco.

Quindi, in sintesi, puoi aggirare qualsiasi controllo dato abbastanza tempo / sforzo / abilità ecc. ma Tripwire aiuta a rendere molto più difficile l'attacco.

    
risposta data 04.01.2012 - 08:38
fonte
3

Come ha detto Rook, Tripwire aiuta i compromessi degli utenti. Richiede anche che alcuni attacchi del kernel influenzino questo metodo di rilevamento, aumentando un po 'la barra. Vediamo abbondante di cases qui dove i siti web sono compromessi, ma probabilmente non interi sistemi. Tripwire fornirebbe anche un metodo di rilevamento e recupero più veloce.

I confronti offline sono i metodi di rilevamento più affidabili, ma i confronti online sono un ottimo strumento nella raccolta di elementi che ti aiutano a renderlo sicuro.

    
risposta data 04.01.2012 - 03:28
fonte
1

Come esperimento ho installato tripwire e poi installato un rootkit (KBeast) per vedere se il tripwire l'avrebbe catturato. In effetti, tripwire si lamenta:

-------------------------------------------------------------------------------
# Section: Unix File System
-------------------------------------------------------------------------------

-------------------------------------------------------------------------------
Rule Name: Other configuration files (/etc)
Severity Level: 66
-------------------------------------------------------------------------------

Modified:
"/etc"
"/etc/resolv.conf"

-------------------------------------------------------------------------------
Rule Name: Devices & Kernel information (/dev)
Severity Level: 100
-------------------------------------------------------------------------------

Modified:
"/dev/.udev/queue.bin"

Il /etc/resolv.conf modificato non è molto sospetto (è facile da controllare) ma queue.bin è ben visibile:

mhaase@debian:~$ cat /dev/.udev/queue.bin
??9/devices/pci0000:00/0000:00:11.0/0000:02:02.0/sound/card0??/devices/virtual/v
c/vcs2?/devices/virtual/vc/vcsa2???/devices/virtual/vc/vcs3?/devices/virtual/vc/
vcsa3???/devices/virtual/vc/vcs4?/devices/virtual/vc/vcsa4???/devices/virtual/vc
/vcs5?/devices/virtual/vc/vcsa5???/devices/virtual/vc/vcs6?/devices/virtual/vc/v
csa6???I/devices/pci0000:00/0000:00:10.0/host2/target2:0:0/2:0:0:0/block/sda/sda
1??/module/loop??/devices/virtual/block/loop0?/devices/virtual/bdi/7:0??/devices
/virtual/block/loop1?/devices/virtual/bdi/7:1??/devices/virtual/block/loop2?/dev
ices/virtual/bdi/7:2??/devices/virtual/block/loop3?/devices/virtual/bdi/7:3??/de
vices/virtual/block/loop4?/devices/virtual/bdi/7:4??/devices/virtual/block/loop5
?/devices/virtual/bdi/7:5??/devices/virtual/block/loop6?/devices/virtual/bdi/7:6
??/devices/virtual/block/loop7?/devices/virtual/bdi/7:7??????????/module/ipsecs_
kbeast_v1?

Questo è un avvertimento piuttosto efficace. Sono sicuro che ci sono altri rootkit che sono migliori per eludere il rilevamento, e sono sicuro che un hacker più abile potrebbe configurare KBeast per essere più evasivo, ma penso che questa sia una buona indicazione che Tripwire sicuramente complica il lavoro dell'attaccante e alza la barra almeno un po '.

    
risposta data 19.08.2012 - 18:52
fonte
0

Penso che il valore dei monitor di sicurezza sia più che parte di un processo che porta a migliori pratiche di sicurezza. Se un tripwire ti avvisa di una vera intrusione, hai già perso la partita. Lo avresti capito, prima o poi, quindi il vantaggio è marginale. D'altro canto, se un monitor ti avvisa di un attacco effettivo che ha avuto esito negativo o un falso positivo a causa di una pratica di sicurezza discutibile, sei avvisato di controllare il tuo software e migliorare le tue pratiche.

    
risposta data 07.02.2012 - 19:18
fonte
-3

La mia esperienza nell'affrontare i rootkit che compromettono la sicurezza è l'utente che la inserisce nel record di avvio principale dell'unità. Un altro equivoco che deve essere affrontato è che il firewall stesso fornisce zero sicurezza per il sistema host. Una funzione primaria dei firewall è quella di dirigere il traffico. Ciò significa che c'è una sicurezza inferiore a zero per i file che gestiscono il firewall stesso. Ricorda che ci saranno sempre backdoor e password vuote. I rootkit più intelligenti che ho visto hanno una partizione crittografata nello spazio di swap, identificata come .gvfs per la cartella. Su una macchina Windows vai alle opzioni della cartella nel pannello di controllo e seleziona Mostra cartelle e file nascosti. Vai a c: \ e controlla i file .DAT nascosti che hanno approssimativamente le stesse dimensioni del file di cache pagefile.sys.

    
risposta data 05.02.2012 - 23:53
fonte

Leggi altre domande sui tag