Questo è un mio tentativo
di compilare una ‘top list’ delle liste di controllo che sono state
lasciate dopo un intrusione nella quale gli intrusi provano a coprire le loro
tracce ma non fanno un buon lavoro. Per farla in breve, attualmente ci sono
un sacco di liste di controllo su un normale sistema UNIX, che possono essere
quasi tutte sopraffatte, ma con un pò di lavoro, che la maggior parte
degli intrusi evade.
1. Log file generale, normalmente
/var/log/messages o /var/adm/messages
Il primo errore che gli intrusi fanno è rimuovere i loro Ip e tutti i
messaggi sospetti da quei files, o impediscono loro di loggarli usando trojans,
ma non verificano il loro primo overflow exploit… se essi riescono ad
entrare via un mail/ftp/rpc server overflow, le possibilità sono che
il tentativo stesso di exploit sia stato loggato dal vulnerabile server prima
che esso muoia, o che abbia loggato ciò in precedenti tentativi non riusciti.
2. Logins normali
La seconda cosa che molti intrusi fanno è creare i loro propri accounts
sul sistema, o usare accounts esistenti con password insicure, per guadagnare
l’accesso al sistema via telnet, rsh, ecc.. . Che concedono loro una login
shell. Adesso, solitamente i dispositivi di login sono protetti per non mostrare
l’utente loggato via utmp e wtmp. Quello che solo i più nuovi pacchetti
trojan hanno, è il tcp wrapper backdoor. Il tcp wrapper loggherà
l’IP di chiunque si connetta a un servizio come login, se il login viene
eseguito via tcpd. Generalmente, gli intrusi nella maggior parte dei casi usano
login shells o rsh per accedere al sistema, anche dopo aver ottenuto l’accesso
root e essere diventati capaci di guadagnare il controllo con metodi più
invisibili, questo è un altro grande errore per gli intrusi.
3. wtmp logs
Allora, normalmente wtmp sarà stato cancellato e i login binari trojanati
non saranno loggati nel wtmp. Ma che dire sul daemon ftp? Beh, mai nessuno usa
trojan sull’ftp daemon, anche se scrive al wtmp senza l’aiuto del
syslog, il che significa che se un intruso trasferisce files dalla sua macchina
all’host compromesso, e l’ftp daemon è invocato, ci sarà
un ingresso con l’ip di chi si connette in wmtp.
4. .bash_history, .sh_history
se un aggressore sfrutta un buffer overflow, egli generalmente genera sh o bash.
Se le variabili HISTFILE e HISTSIZE sono impostate nell’ambiente del server
vulnerabile, o se essi eseguono una shell secondaria (solo digitando ‘sh’
dopo che si sono connessi, il che viene fatto da molte persone per ragioni qualsiasi)
essi avranno un history file nel directory dove il server vulnerabile è
morto. Inoltre sapendo il primo comando che l’intruso ha emesso, hai una
buona possibilità di avere l’hostname lì, poiché
una delle prime cose da fare è spesso collegarsi via ftp o telnet indietro
a proprio host e prendere un po’ di trojans, backdoors o altri strumenti.
5. Logs di accesso ai siti web
Questo gioca un ruolo negli scenari dove l’intruso deturpa un sito web,
o raccoglie informazioni delicate da esso. Uno dei più grandi errori
dell’intruso è non pulire mai i files di log del webserver, per
il daemon apache http questo è logs/*_log. Lì puoi trovare molto
probabilmente l’ip dell’aggressore richiedendo gli script cgi che
sai possono essere exploitabili, files che tu non hai messo (che sono stati
uploadati dall’aggressore) o frequentemente ‘/’ per vedere
se lo sfregio ha lavorato. Con i logs dei siti web tu hai anche l’opportunità
di metterli in un directory abituale, il che significa che l’aggressore
non può pulirli ‘ciecamente’, senza esaminare il sistema
più approfonditamente.
6. Coredumps
Ok, questo è un metodo piuttosto complicato, ma lavora – normalmente,
i demons avviati dallo script init SysV non fanno il coredump per default per
motivi di sicurezza (immagini delle pagine di memoria del root scritte nel corefile),
ma molte persone avviano o riavviano i server come http e bind manualmente,
e così loro occasionalmente hanno il coredump nel loro directory di lavoro
corrente quando sfruttano un exploit. Nello stato di essere exploitati, molti
servers hanno l’IP dell’intruso in memoria, il che significa che
tu puoi trovarlo in una variabile del processo di coredump lavorando un po’.
7. Servers proxy
Se hai un gateway proxy prima di tutti i tuoi host, trovare le liste di controllo
è generalmente facile. Proxies trasparenti come plug-gw o squid (che
è vulnerabile agli overflows in alcune versioni, stai attento) hanno
un log di tutte di tutte le connessioni fatte attraverso di esso, così
trovare le informazioni di cui hai bisogno è un compito facile. (Gli
aggressori possono eludere questo in molti casi usando porte non designate per
impegnare uno shell, ma non per la prima volta che essi lanciano un exploit.)
8. Logs router
Bene, i routers non loggano ogni connessione per default, poiché ciò
sarebbe semplicemente troppo, ma se hai un po’ di controllo sugli accessi
sul tuo network, potrebbe aiutarti a rintracciare un intruso. Per esempio, il
tuo router di intranet permette solo il traffico dall’interno di AS e
il DMZ AS, che consistono in servers web/mail, e nega l’accesso a tutto
il resto del traffico durante i tentativi di connessione di loggaggi. Se il
tuo router non logga ogni connessione tu potresti ancora trovare un po’
di tentativi di connessioni negate dell’intruso sul tuo network, dopo
di che egli ha deciso di compromettere un host sul DMZ per guadagnare l’accesso
da lì.
Conclusioni
Molti intrusi fanno errore o sono semplicemente chiaramente pigri, e perciò
lasciano tracce che essi non avrebbero lasciato se avessero lavorato con più
esami accurati. Questo è un chiaro vantaggio per l’amministratore
che può, nella maggior parte dei casi, usare le rimanenti liste di controllo
per rintracciare l’individuo. Comunque, non dovresti contare pienamente
su questi metodi, e né sul riconoscimento delle intrusioni basate sull’host
in generale. Nulla può rimpiazzare un NIDS dedicato o un log host, preferibilmente
con log files segnati digitalmente, per essere completamente sicuro che c’è
almeno un caso di liste di controllo che sono sicure dalle violazioni all’integrità.
