Pensavamo di mettere un honeypot sul server — serve a qualcosa in una piccola impresa, ci sono rischi?

L'honeypot non è uno strumento di difesa, ma di intelligence. Lo usano le grandi organizzazioni per studiare le tecniche di attacco. A livello di PMI, monitorare bot casuali che cercano di intrufolarsi non porta alcun beneficio commerciale o tecnico all'azienda. Dedicate il vostro tempo alle patch di sicurezza e a una buona disciplina di backup.

Quei 40 mila tentativi sono quasi sicuramente semplici bot di brute force che scansionano la rete a caso. Non trattandosi nemmeno di un attacco mirato mettersi a piazzare un honeypot per guardare i log è come dare fuoco al pagliaio per cercare un ago. Con una configurazione di rete errata rendereste il server principale un bersaglio facile.

Il vostro dev ci ha messo entusiasmo ma non serve a nulla. Spostate la porta SSH dalla 22 a una a cinque cifre a caso, disattivate l'accesso con password lasciando solo l'obbligo della chiave SSH e installate fail2ban sul server. Quei 40 mila tentativi scenderanno a zero in un giorno e vi togliete il pensiero.

L'anno scorso per curiosità ne abbiamo messo uno a bassa interazione su un IP separato. In una settimana ha registrato 180 mila IP. I primi tre giorni lo guardavamo con entusiasmo, poi nessuno ha più aperto i log. Oltre ad aggiungere 450 TL al mese di costi server non è servito a niente, dopo due mesi l'abbiamo spento.

ma l'attaccante che ci caca pensa davvero di aver bucato il server? comunque cioè per renderlo credibile bisogna metterci dentro finti dati dei clienti o cose del genere?

ci avevamo provato pure noi una volta il file di log è esploso riempiendo il disco e a metà notte il database principale è andato giù. boh x me lasciate proprio perdere le misure di sicurezza standard bastano e avanzano.

Se il team insiste comunque per installarlo, seguite tassativamente queste regole: 1) Non ospitate assolutamente la trappola sulla stessa rete locale del server principale, usate un VPS completamente isolato. 2) Non consentite mai connessioni in uscita, evitate che il server venga usato come zombie per attaccare terzi. 3) Configurate la rotazione giornaliera dei log per non esaurire lo spazio su disco.

In sintesi: i sistemi esca sono pensati per team di sicurezza strutturati che analizzano attacchi mirati. Per un piccolo e-commerce significano solo rischi inutili e overhead operativo. Cambiare la porta e passare all'autenticazione a chiavi risolverà del tutto il problema.

La discussione si è dispersa, la riassumo. Inizia con un piccolo test, non impegnarti subito su tutto.

Buon lavoro.

Sono d'accordo.

Dopo aver vissuto questa cosa il mio punto di vista è cambiato. Più è difficile tornare indietro su una decisione più lentamente dovreste prenderla.

Questa è la mia opinione, non la scrivo come verità assoluta.

Lascio un avvertimento. onestamente la maggior parte degli incidenti non inizia da una vulnerabilità, ma da una password trapelata.

Questa è la mia opinione, non la scrivo come verità assoluta.

Sono della stessa opinione. Quando prendi una decisione, guarda prima quali dati hai a disposizione.

Confermato dall'esperienza.

Il mio dubbio è stato chiarito, grazie.

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

Il vero problema non è il numero, ma su cosa si basa quel numero. Buon lavoro.

Sono passato da qui, vi racconto. L'errore commesso da cos'è un sistema honeypot è generalmente reversibile ma costoso.

ho lavorato a lungo su questo. quando prendi una decisione guarda prima qali dati hai a disposizione.

gli ambienti di test dimenticati diventano spesso un punto d'accesso più frequente del siistema live.

Sono d'accordo. Se è la prima volta inizia in piccolo, il ridimensionamento viene dopo.

Spero che le sia utile.