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à.