Ho rilevato alcuni tentativi di sondare la sicurezza del mio sito. Devo inserire nella blacklist il loro indirizzo IP? Quali sono le considerazioni o i compromessi da utilizzare nel decidere quando bloccare il loro indirizzo IP e quando no?
Di norma, i rendimenti su questo tipo di difesa sono quasi pari a zero. Ci sono delle eccezioni, ma anche in questo caso questa tecnica può offrire solo una piccola quantità di sicurezza.
Estensive scansioni di vulnerabilità di host scelti a caso offrono ritorni estremamente bassi sulle risorse di scansione. Invece, gli attaccanti di successo generalmente scelgono una delle seguenti due opzioni per aumentare le loro probabilità:
Verifica un numero molto piccolo di vulnerabilità su un numero elevato di host
Ciò include password errate per servizi comuni come SSH, POP3, cPanel, Wordpress, Joomla e simili. Se la tua password di root è "root" o la password dell'amministratore del tuo sito è "admin", puoi aspettarti di rimanere catturato in una di queste reti derivate in modo sorprendentemente rapido.
A partire da una singola vulnerabilità nota, utilizza una tecnica di ricerca per restringere l'elenco di destinazione solo alle vittime più probabili.
Di solito questo inizia su uno dei database di vulnerabilità comuni. Trova un candidato recente e identifica una stringa che sarebbe comune sugli host vulnerabili. Questa è spesso una linea "Powered by" o un link di accesso o un pattern URL specifico. Quindi, utilizzando il suo motore di ricerca preferito, recupera un elenco di siti che seguono tale modello.
Il punto importante è che in nessuno di questi casi l'attaccante effettua più di alcuni tentativi su un determinato sito. O hanno successo immediatamente o si spostano.
Questo non vuol dire che non vedrai l'occasionale attaccante persistente. C'è sempre qualche individuo erratamente ottimista che esegue Nessus contro un / 16, ma tali attacchi sono per loro stessa natura auto-limitanti e molto raramente di successo, dal momento che la stragrande maggioranza degli attacchi si rivolge a software che un dato server non 'anche correre.
Potrebbe un tale attacco avere successo? Sì. Accade mai? Mi occupo in media di diversi server compromessi al giorno, e finora non ho ancora visto nemmeno uno proveniente da scansioni a spettro completo nessus . Ma la probabilità non è esattamente zero. E nel mondo degli attacchi casuali, le statistiche e le probabilità contano molto.
L'eccezione è quando l'attacco è non casuale. Se si esegue un sito di alto valore o visibilità elevata, si attirano molti attacchi diretti contro tu in particolare. Siti come Facebook, Twitter, Hotmail, ecc., Vedono una quantità straordinaria di traffico di attacco. Se gestisci questo tipo di sito, probabilmente prendi molto sul serio la sicurezza e non stai cercando consigli.
Una nota sull'iniezione SQL: questo tipo di attacco richiede un po 'di perfezionamento; dopo aver catturato un messaggio di errore SQL in una scansione rapida, un utente malintenzionato può inviare diverse dozzine di query a un determinato server per ottenere i bit centrati correttamente. Quindi, teoricamente, una risposta di tipo clamp-down potrebbe prevenire un simile attacco ... ma probabilmente no, dal momento che probabilmente tornerà con un IP diverso. Dal momento che è già allertato sul tuo server, non sarà scoraggiato da una lista nera. Un consiglio migliore è di non eseguire software scadente. Non ci sono scuse per utilizzare query non parametrizzate oggi.
Argomenti a favore della lista nera: potrebbe anche rendere più difficile la vita dell'attaccante. Anche se questa non è una difesa strong, potrebbe dare un po 'di tempo addizionale per indagare sull'attacco e creare difese più forti.
Argomenti contro la lista nera: negli indirizzi IP dinamici, la loro blacklist può finire col bloccare altri utenti benigni. Potresti non sapere mai che stai bloccando altri utenti benigni o che potrebbe portare a errori difficili da diagnosticare in futuro. Inoltre, esiste una potenziale complessità di configurazione nella gestione di una lista nera.
Se l'attaccante sta tentando di interrompere il sito sovraccaricandolo (per montare un attacco denial-of-service), il blocco dell'indirizzo IP potrebbe essere la risposta giusta. Un blocco temporaneo potrebbe essere sufficiente.
Se l'attaccante sta solo sondando o scansionando, sarei meno incline a inserire nella lista nera il loro indirizzo IP, ma puoi tenere conto dei compromessi in ogni situazione e prendere una decisione informata su ciò che ha più senso.
Dipende ovviamente da ciò che fa il tuo sito, il lato negativo degli IP di blocco (potresti bloccare inavvertitamente i veri clienti non attaccanti), e il rischio che qualcosa possa essere compromesso (è probabile che alcuni utenti abbiano password indefinibili sito?)
I blocchi a breve termine sembrano perfettamente ragionevoli e variano da 5 minuti a un giorno. Ciò potrebbe consentire a un utente malintenzionato di provare ~ 1000 tentativi al giorno, contro un ~ 1000 al secondo in un attacco online. Certo, devi essere sicuro di non bloccare utenti legittimi che hanno dimenticato la loro password.
Personalmente, ad esempio, blocco vaste gamme di indirizzi IP dalla Cina / Russia su un sito web che gestisco per un'azienda locale. Ho osservato che il server ssh per il sito Web aveva un paio di migliaia di accessi tentati con nomi utente inesistenti. Mentre non erano vicini a indovinare il mio nome utente, per non parlare del mio passphrase casuale ad alta entropia, non ero a mio agio con i tentativi e quindi nessuna ragione per lasciarli continuare. Così ho installato fail2ban con impostazioni libere (cinque login falliti = 30 minuti di divieto, whitelist per i miei IP statici - quindi posso ancora accedere se necessario - anch'io accedo al 95% del tempo con una chiave RSA quindi un singolo accesso fallito è raro). Ho anche cambiato la porta ssh da 22, sì questa è solo sicurezza da oscurità che è facilmente sconfitta da una scansione delle porte (anche se potrei installare un honeypot per questo, ma non lo fece), ma va bene se la sua parte di difesa-in- profondità. L'implementazione di queste modifiche ha portato il numero di attacchi a scendere a zero nel mese scorso (a partire dal momento in cui i registri sono passati).
Modifica: questa risposta non considera la forzatura brute di accesso, ma attacca solo i tentativi di sfruttare le vulnerabilità del sistema. Ovviamente mi sembra legittimo vietare temporaneamente un IP che tenta 30 accessi in 5 minuti. / Modificare.
Se non hai un sistema automatico in grado di controllare e bloccare le richieste, non vietare gli indirizzi IP che tentano di hackerare il tuo servizio. Se li blocchi, non possono fare più richieste e non saprai se c'è una perdita . Gli attacchi stanno accadendo giorno e notte, e il più delle volte, non si sta guardando il registro mentre si tenta un attacco. Blocca un attacco ora, e un giorno qualcun altro troverà la falla.
Naturalmente, bloccare gli IP di attacco è una misura precauzionale che aiuterà la tua sicurezza. Non è una vera sicurezza, ma potrebbe solo proteggere un attacco dandoti un preavviso tempestivo.
L'esecuzione di questo in modo automatico potrebbe avere un vantaggio quando si restituisce una risposta predefinita (come una risposta HTTP-200) in modo che gli strumenti automatici non rileveranno il blocco. Se continua a registrare le richieste , puoi in seguito verificare se uno qualsiasi dei tentativi sarebbe andato a buon fine.
Ci sono alcuni problemi con questo però:
In generale, non bloccherò alcun tentativo di attacco. Potrebbero esserci situazioni in cui questa è una buona idea (forse in ambienti ad alta sicurezza, come una banca o un sito Web con milioni di visitatori), ma in generale non penso che possa essere di grande aiuto, o potrebbe anche darti un falso senso di sicurezza.
L'unica eccezione è un attacco DoS. Qui non c'è alcun rischio per la sicurezza, l'unica cosa che viene sfruttata è il tempo di elaborazione o la larghezza di banda, quindi non c'è motivo per non bloccarlo. Anche se in questo caso, solo temporaneamente ratelimit o divieto: questi attacchi sono probabilmente fatti da una botnet, quindi ti fanno bloccare l'IP dell'utente.
Vorrei monitorare la situazione un po 'di più prima di passare alla lista nera di un IP, anche temporaneamente. Oltre ai cons menzionati da D.W., non penso che un serio tentativo di attaccare il tuo sito possa impiegare lo stesso IP più di un paio di volte; dopotutto non è molto difficile spoofarlo. Se, tuttavia, dopo un breve periodo di monitoraggio, dovessi osservare le ripetute sonde provenienti da quell'indirizzo IP specifico, prenderei sicuramente in considerazione la possibilità di bloccarlo.
Un'altra cosa che potrei essere alla ricerca è la natura delle sonde. Se la gamma di IP in violazione condividono tutte le caratteristiche comuni in una determinata finestra di tempo, ci sono buone probabilità che siano state create dallo stesso aggressore.
Infine, se gli attacchi persistessero e / o avessi avuto un po 'di tempo libero, tenterei di farmi un'idea di ciò che l'hacker vede ripetendo personalmente le sonde. Per lo meno, otterrei maggiori informazioni sulla sicurezza del mio sito.
Questo è un compromesso "dipende".
1 - qual è la priorità dell'accessibilità rispetto all'ostruzione degli attaccanti?
Per ogni blocco, si desidera determinare se si sta bloccando l'utilizzo legittimo e gli autori di attacchi. Ad esempio, se l'IP proviene dai tuoi clienti e una delle loro macchine è stata hackerata per eseguirti la scansione, potresti voler avvisare il cliente e lavorare con il proprio team di sicurezza piuttosto che sparare il tuo piede.
2 - qual è l'impatto?
Hai i protocolli utili che espongono la tua rete spenta? Cosa può vedere l'attaccante quando ti scansiona? Scansionarsi su base regolare è una buona pratica, in modo che tu possa sapere a cosa sei vulnerabile. Se hai bloccato le cose abbastanza bene, il tuo rischio qui è minore.
Inoltre - quale danno sta facendo la scansione? Sta rallentando l'uso legittimo?
3 - qual è la natura del rischio? Qual è la tua capacità di gestirlo?
Classici tipici: disponibilità, compromissione di risorse o informazioni, reputazione dell'organizzazione. Cosa puoi perdere dalla scansione della porta, cosa puoi perdere se trova qualcosa e con quale frequenza si verifica?
E qual è il tuo personale e la tua capacità di affrontarlo? In alcune reti, inserire un blocco è semplice e veloce, in altri richiede un grado significativo di due diligence. Se lo inserisci in modo errato, qual è il danno?
La cosa più ragionevole adesso è seguire quella scansione e assicurarsi che l'aggressore non abbia trovato nulla di vulnerabile nella tua applicazione. In secondo luogo dovresti controllare quell'IP. Bloccare l'indirizzo IP di qualcuno non è sempre la soluzione migliore. L'autore dell'attacco potrebbe essere nascosto dietro il NAT. Quindi se condivide il suo IP con molti utenti diversi, perderai i visitatori (anche loro saranno bloccati). La scansione potrebbe anche essere avviata dalla vittima innocente (il suo PC potrebbe far parte della botnet). Tuttavia dovresti assicurarti che:
Suggerisco un approccio diverso al problema piuttosto che vietare gli indirizzi IP o fail2ban, che possono essere fragili e inefficaci. Invece, ti consiglio di cambiare la configurazione del tuo server web in modo che tutte le richieste a nomi di server sconosciuti o posizioni restituiscano 404. Ho scritto su questa tecnica per nginx qui:
Se hai visitatori fastidiosi, scrapers del sito o spammer, potresti trovare utile impedire a questi utenti di accedere ai contenuti del tuo sito web. Puoi bloccare i cattivi visitatori per indirizzo IP o blocchi di indirizzi IP usando un file .htaccess.
Ulteriori informazioni su alcuni esempi utili: link
Leggi altre domande sui tag network threat-mitigation