I sistemi honeypot servono davvero a qualcosa sul server di una piccola azienda?

Vedere decine di migliaia di richieste al giorno è assolutamente normale: sono i bot di scansione automatica che girano su tutto il web. Anche con un honeypot, quei bot finiranno nella trappola confermandovi solo una cosa che già sapete: che internet è piena di bot. Inoltre, anche per una trappola a bassa interazione, non potete tenerla sulla stessa VLAN della rete principale, dovete configurare una subnet a parte e regole di firewall severissime.

PS: è stato chiesto qui sotto, ho scritto la risposta nel secondo messaggio.

Lasciate perdere il consiglio del consulente per ora. Cambiare la porta standard, disabilitare il login via password consentendo solo le chiavi e installare un semplice tool di sicurezza per bannare temporaneamente chi sbaglia i tentativi vi azzera subito la quasi totalità delle scansioni quotidiane. Si risolve in due ore a costo zero.

L'anno scorso per curiosità abbiamo fatto girare un honeypot SSH open source su un server inutilizzato. In tre giorni ha raccolto oltre 140 mila tentativi di login e 800 varianti di username. Uno dei nostri dev passava 4 ore alla settimana solo per ripulire questi log inutili. Dopo un mese abbiamo spento tutto: non ne abbiamo ricavato una sola informazione utile per il nostro lavoro.

Il consulente vi ha detto chi controllerà i log una volta installato questo honeypot? Avete un SOC per gestire gli alert o avete intenzione di configurarlo e lasciarlo lì a prendere polvere? Se non avete stanziato un budget per analizzare i report settimanalmente, che senso ha mettere una trappola?

lascia perdere guarda nn serve a nulla. quel consulente sta solo cercando di rifilarti il solio template da grande azienda. chiudi la porta ssh all'esterno o mettila dietro una vpn e sei a posto. non ti basterebbe una vita x leggere tutti i log.

L'honeypot non è uno strumento di difesa, ma di threat intelligence e ricerca. Le aziende con centinaia di dipendenti e un proprio team di sicurezza lo usano per scoprire in anticipo nuovi vettori di attacco. Una software house di 12 persone non può permettersi il lusso operativo di profilare gli attaccanti.

La questione è chiarissima. L'honeypot non blocca gli attacchi, si limita a documentarli. Voi non avete bisogno di analizzare log, ma di blindare gli accessi. Nel momento in cui chiudete le porte verso l'esterno e passate all'autenticazione tramite chiavi, tutti questi dubbi spariranno all'istante.

Il mio dubbio è stato chiarito, grazie. Nessun processo migliora senza tracciamento, perché non sai cosa correggere.

Gli ambienti di test dimenticati diventano spesso un punto d'accesso più frequente del sistema live. Buon lavoro.

Se non ho capito male, stai dicendo che: Il vero problema non è il numero, ma su cosa si basa quel numero.

Dopo aver vissuto questa cosa il mio punto di vista è cambiato. Cercare di farlo da soli è la strada più costosa.

Cercare di farlo da soli è la strada più costosa.

Parlo dal lato opposto, io sono dalla parte dei fornitori. Un report di scansione automatica e un penetration test non sono la stessa cosa.

Buon lavoro.

Ci proverò.

Non lo sapevo.

non trascurare nulla: Un backup non testato non è un backup.

quando prendi una decisione, guarda prima quali dati hai a disposizione. insomma se scrivete qui il risultato sarà utile anche ad altri.

C'è una cosa a cui prestare attenzione. Inizia con un piccolo test, non impegnarti subito su tutto.

Lascio una nota, potrebbe servire.

Riassumo quanto detto finora. Se il percorso di notifica è lungo, la notifica non arriva; una notifica mancante significa un evento scoperto tardi.

Buon lavoro.

Bisogna procedere con ordine. comunque da noi la cosa che faceva perdere più tempo era non sapere chi decidesse.

Lascio una nota potrebbe servire.

Sosterrò l'opposto, non prendetela male. Il fatto che tutti facciano una cosa non significa che sia quella giusta.

Buon lavoro.