Qualcuno che ha formato con me posso dirti Sono davvero grande di essere in grado di leggere il tuo rileva. Anche se abbiamo un sacco di dispositivi di sicurezza che cercano di descrivere accuratamente quello che credono di vedere sul filo, sono programmati dagli esseri umani e gli esseri umani commettono errori. Cercate di automatizzare il processo e gli errori diventano aggravato. Anche Cisco ha fatto marcia indietro un po 'sulle loro affermazioni grandiose di quello che una rete di auto difesa è realmente capace. Niente sostituisce con un analista esperto revisione dei risultati.

Buon aiuto è difficile da trovare

Naturalmente la parola chiave in questo ultimo commento è abile. Ho avuto a che fare con un sacco di gente di sicurezza anziani che non hanno mai visto una decodifica di un pacchetto IP, per non parlare posso dire che una sessione di legit IP dovrebbe essere simile. Uno dei problemi è quando abbiamo bisogno di formazione che di solito girare per i venditori. I venditori tendono a concentrarsi sulle loro GUI bella, non ciò che sta succedendo dietro le quinte.

In una vita precedente ho posseduto un ISP e aveva alcune segnalazioni di abuso molto divertente presentato. Uno dei miei preferiti è stato un amministratore di reporting che uno dei miei sistemi di era "l'invio di pacchetti ICMP ostile" a uno dei suoi sistemi. Quando ho rivisto il mio log, ho notato che uno dei miei router era infatti l'invio di messaggi ICMP irraggiungibile lui ospite. Ciò accade ogni volta suo ospite sondato la porta RPC di un indirizzo IP che non era in uso. Ho risposto e spiegato che se il suo sistema consisterebbe semplicemente termina l'esame per inesistenti i sistemi, il mio router si fermerebbe dicendogli l'host è off-line.

Un altro admin (a piuttosto grande, azienda ben nota mi permetto di aggiungere) mi ha informato che uno dei miei sistemi lo stava attaccando con Code Red via e-mail. Se vi ricordate Code Red, solo attaccato i server Web IIS via HTTP. La "attacchi" in questione erano gli utenti iscritti ad una mailing list. La gente parlava di come scrivere firme intrusione buona per catturare correttamente Code Red. Se questo non fosse abbastanza ironico, il payload del decodificare mi ha mandato come prova ha spiegato che gli attacchi erano solo HTTP based. Se questo torsione non è ancora sufficiente per farvi ridere, in seguito ammise che era quello del popolo iscritti a tale elenco.

Più le cose cambiano più rimangono le stesse

Il mio hosting Mostro host provider (una filiale di Host Blu) ha messo un filtro al posto bloccando tutti gli accessi al SANS Institute server di posta (SysAdmin, Audit, Network, Security Institute, offre corsi di formazione sicurezza informatica), L' Internet Storm Center (diario giornaliero delle minacce alla sicurezza Internet) e DShield (un sistema di allerta precoce per le minacce di Internet). Ho contattato il supporto e hanno confermato che stanno filtrando i siti. Non sono riuscito a scoprire perché oltre "a causa di attività sospette".

So che la gente che mantengono il SANS e server Dshield. Sono dure persone nucleo di sicurezza con un indizio grave. Quando ho firmato con il mio fornitore di hosting mi ha colpito con il livello di conoscenza della loro personale di supporto. Ultimamente però, ho trovato loro di essere carente anche nelle basi. Mentre io sto a sinistra per indovinare che cosa effettivamente causato il divieto, io sono incline a pensare che qualcuno a mostro Host (Host o forse blu) ha visto un avviso, ma non hanno le capacità per capire proprio un falso positivo.

La comunicazione è una strada a doppio senso

Host blu sostiene 1,5 milioni di siti ospitati in tutte le loro partecipazioni. Così ora hanno 1,5 milioni di clienti che non possono:

• Ricevere avvisi in tempo reale il blocco di IP di malintenzionati
• Ricevi le valutazioni sulle minacce attuali di Internet
• Ricevere informazioni su cosa sta succedendo nel settore della sicurezza

Così, mentre tenta di proteggere se stessi è una cosa positiva, l'attuazione ha avuto un effetto negativo sulla sicurezza dei loro clienti.

Come verificare un rilevamento

Quindi cerchiamo di tirare fuori qualcosa di positivo di tutto questo e di individuare la procedura corretta per verificare un avviso di protezione. In primo luogo abbiamo bisogno di iniziare con una buona marcia. Non fanno così anche in considerazione un rilevamento delle intrusioni o sistema di prevenzione che non include:

• L'accesso alla lingua firma
• Piena di decodificare i pacchetti sospetti

Senza queste caratteristiche si sono riprese al buio.

Fase 1: Comprendere l'attacco

Quando un allarme viene attivato, assicurarsi di aver compreso il meccanismo di attacco. Quali porte o servizi va a finire dopo? Ci sono firme note? Se l'attacco il nome di Google, seguita dalle parole chiave "falso positivo" e "spoofing", fa niente venire?

Fase 2: Comprendere il vostro sistema di intrusione

Nessun prodotto di sicurezza è perfetto. Tutti hanno debolezze o limitazioni. Il vostro sistema di intrusion mantenere lo stato? Se è così, è tutto il tempo o solo qualche volta? Ha convalida correttamente i campi CRC? Come si gestire il traffico frammentato? E 'noto per generare falsi positivi? Se è così, sono i falsi positivi limitata a determinate firme o protocolli, o è tutto il tempo?

Fase 3: Sanity controllare l'avviso

A volte i falsi positivi possono essere eliminati dalla limitata quantità di informazioni presentate in un avviso. Per esempio ha la pretesa di allarme di avere rilevato un attacco HTTP provenienti da TCP/80 invece di andare ad esso? Se è così, c'è un problema evidente con la firma generando l'allarme.

Fase 4: Verificare la firma

Alcune firme sono scritte in modo molto specifico in modo che ci sono poche possibilità di un falso positivo. Alcuni sono più generale, comunque, quindi la sua possibilità di avere falsi positivi cadono fuori. Rivedere la firma che ha generato l'avviso e fare una chiamata in giudizio. La firma controllare 3-4 condizioni diverse o dieci o più? Ovviamente i parametri più stiamo verificando, la meno probabile che stiamo per avere un falso positivo.

Fase 5: Controllare la decodifica

Se si capisce il motivo dell'attacco, si dovrebbe già avere una aspettativa di quello che sarà nel decodificare attacco. Il pacchetto all'altezza delle vostre aspettative? Ho visto un sacco di falsi positivi generati da persone che leggono informazioni su un sito Web che descrive un attacco basato HTTP. Questi sono facili da distinguere a causa della ulteriore HTML, agente corretta e campi referrer, ecc In breve, se il pacchetto non corrisponde a una nota di decodificare il vero attacco, capire perché.

Fase 6: ricerca la fonte

Ho sempre prendere il tempo per essere sicuro di capire chi è seduto dietro l'indirizzo IP di origine. A volte questo può andare un lungo cammino verso l'individuazione se posso fidarmi l'avviso. Mi viene in mente un amico che ha vietato una serie di indirizzi IP suo sistema intrusione aveva identificato come ostile. Poco dopo ha iniziato a notare che alcune parti di Internet non erano più raggiungibili. Si scopre che qualcuno falsificato una serie di attacchi provenienti da indirizzi IP dei root name server . Se avesse avuto il tempo di cercare gli indirizzi IP primo, certamente non li avrebbe bloccati.

Executive Summary

Blocco note per essere gli indirizzi IP ostili può certamente essere utile alla sicurezza, ma deve essere attuato con cautela. Al centro di qualsiasi sistema di sicurezza di rete deve essere un esperto di sicurezza esperto con buon senso. Se tale componente non è presente, l'intera struttura possa crollare come un castello di carte.

Aggiornamento: Dal momento che questo distacco che ho trovato che il mostro Host (Host Blu) sta bloccando l'accesso a uno o più Cisco server pure. Indovina la lista continua ...