Gestisco un piccolo sito aziendale. Ho controllato i log per la prima volta in modo approfondito e sono rimasto shockato.
Ci sono migliaia di richieste al giorno verso indirizzi come /wp-admin, /.env, /phpmyadmin, /.git/config. Sul nostro sito non c'è nemmeno WordPress.
È un attacco mirato contro di noi o succede a tutti? Cosa dovrei fare?
Prima di tutto, state tranquilli: non è un attacco mirato contro di voi, è il rumore di fondo che riceve qualsiasi indirizzo esposto su internet. I bot automatici scansionano continuamente tutti gli intervalli di IP e provano gli indirizzi delle vulnerabilità note. Non sanno cosa sia il vostro sito e non gliene frega niente.
Ora passo alla parte scettica, perché dire "normale" non significa dire "irrilevante". Fate questa distinzione:
Rumore automatico: richieste che restituiscono 404 verso indirizzi casuali, da IP diversi, con pattern ripetitivi. Questi sono solo rumore.
Cosa tenere d'occhio: i tentativi verso i vostri indirizzi che esistono davvero. Tentativi di password consecutivi sulla pagina di login, tentativi di accesso al pannello di amministrazione, manipolazioni dei parametri. Questo significa che qualcuno ha davvero guardato il vostro sito.
Cosa fare, in ordine di importanza: non lasciate il pannello di amministrazione pubblico, impostate un rate limit sui tentativi di login, tenete aggiornati i software, fate i backup e testateli ripristinandoli.
L'ultimo punto è quello che viene saltato di più. Un backup non testato non è un backup.
Faccio un'aggiunta tecnica dal punto di vista SOC.
Cercare di bloccare completamente questo tipo di rumore (come mettere in blacklist ogni IP) è solitamente uno sforzo inutile. Gli IP cambiano continuamente, la lista si gonfia e un giorno bloccate i vostri stessi utenti.
Invece, filtrate il rumore per poter vedere gli eventi reali. Metodo pratico: scrivete le richieste che restituiscono 404 su un canale separato, lasciate nel flusso di log principale solo quelle che restituiscono 200 e 500. Tenete anche un contatore separato per i tentativi di login falliti.
Come regola di allerta, consiglio questa: molti tentativi di login falliti in breve tempo da una singola fonte. Questo è il pattern che si distingue davvero dal rumore e richiede intervento.
Non dimenticate anche questo: gli incidenti reali più comuni iniziano non con forzature esterne, ma con l'accesso tramite password trapelate. Quindi, oltre a guardare i log, è importante attivare la verifica in due passaggi.
Faccio una domanda: dite di aver controllato questi log per la prima volta in modo approfondito. Ma quanto indietro potete guardare?
Il problema è questo: su molti server la durata di conservazione dei log è breve per impostazione predefinita. Chiunque voglia guardare indietro quando succede un incidente sbatte contro lo stesso muro: i log non ci sono.
Come persona che vuole prove concrete, consiglio specifico: controllate la vostra durata di conservazione dei log e portatela ad almeno novanta giorni. Il costo dello spazio è basso, il valore in caso di incidente è enorme. Inoltre, tenete i log non solo sul server stesso, ma anche altrove; se il server viene compromesso, la prima cosa che viene cancellata sono i log.
Vi do un numero dal punto di vista dell'hosting, non una stima, è il pattern che vediamo regolarmente dal nostro pannello.
Anche un nome a dominio appena aperto, mai promosso, senza link da nessuna parte, inizia a ricevere questo tipo di tentativi automatici entro la prima settimana. La ragione è semplice: i registri di trasparenza dei certificati sono pubblici, i nuovi nomi a dominio possono essere visti anche lì.
Quindi non esiste una situazione di sicurezza del tipo "il mio sito è piccolo, nessuno lo conosce". Essere piccoli non vi rende invisibili, riduce solo la probabilità di attacchi mirati.
Sono uno studente, vorrei fare una domanda, scusate se sembra stupida.
Perché questi browser cercano il file /.env? Cioè, cosa c'è dentro di così prezioso?
Assolutamente no, è una domanda molto pertinente.
Il file .env è un file di testo che contiene le configurazioni dell'applicazione (environment, cioè variabili d'ambiente). Di solito contiene l'indirizzo e la password del database, le chiavi dei servizi di terze parti e la chiave di crittografia delle sessioni.
Per un attaccante, questo file significa trovare la chiave invece di forzare la porta. Ecco perché i browser lo provano per primi; il costo è una singola richiesta, il guadagno è tutto.
Normalmente questo file dovrebbe trovarsi fuori dalla cartella servita dal web server. Con un'installazione errata rimane dentro la cartella public ed è leggibile dal browser. La stessa logica vale per /.git/config: se il repository del progetto viene pubblicato per errore, è possibile scaricare l'intero codice sorgente.
Verificare è molto semplice: prova a scrivere /.env nel tuo indirizzo. Se ricevi un 404 non c'è problema, se vedi il contenuto chiudilo subito e cambia tutte le chiavi in quel file. Chiudere non basta, si presume che siano state compromesse.
Aggiungiamo una nota come team Doki, perché questo thread riassume bene un argomento spesso richiesto.
Anche noi vediamo la situazione descritta sopra: ogni asset esposto su internet viene scansionato, anche se non dichiarato. Per questo motivo, ai nostri clienti consigliamo innanzitutto di fare un inventario degli asset — quali domini, quali sottodomini, quali server sono davvero nostri e quali sono ancora attivi e dimenticati.
Nella pratica, la porta aperta più frequente che incontriamo sono gli ambienti di test dimenticati. Il sistema live è ben protetto, ma un server di prova aperto due anni fa continua a puntare allo stesso database.
I contenuti condivisi qui sono a scopo informativo generale; vi consigliamo di far effettuare una valutazione con ambito definito per il vostro sistema.
Guardando al processo, il quadro cambia. Se la verifica in due passaggi è attiva, una password rubata da sola non serve a nulla.
Se la verifica in due passaggi è attiva, una password rubata da sola non serve a nulla. Se scrivete qui il risultato, sarà utile anche ad altri.
Sono d'accordo, anzi vorrei sottolinearlo. Se il percorso di notifica è lungo, la notifica non arriva; una notifica mancante significa un evento scoperto tardi.
Sono curioso di sapere se qualcuno lo fa in modo diverso.
C'è un punto che mi incuriosisce. Le decisioni affrettate diventano decisioni da correggere sei mesi dopo.
Buon lavoro.
Breve riassunto per i nuovi arrivati: Più è difficile tornare indietro su una decisione, più lentamente dovreste prenderla.
Ogni punto non scritto è un punto che in futuro le due parti ricorderanno diversamente. Buon lavoro.
Grazie per averlo scritto, è proprio così. Se permessi e ambito non sono scritti, quel test non deve iniziare.
Questa è la mia opinione, non la scrivo come verità assoluta.
Ho lavorato a lungo su questo. Gran parte del tempo perso si accumula nelle pratiche in attesa di approvazione.
L'errore commesso da log è generalmente reversibile ma costoso. Spero che le sia utile.
Come avete risolto questo? Cercare di farlo da soli è la strada più costosa.
L'errore commesso da log è generalmente reversibile ma costoso. Questa è la mia opinione non la scrivo come verità assoluta.