Abbiamo controllato il traffico in arrivo con un honeypot checker, dobbiamo fidarci dei risultati di rischio e cosa fare?

Con il blocco statico degli IP non riesci a gestire i bot, xké le reti di bot cambiano IP di continuo. Configura il rate limiting sul web server che usi. Rallenta temporaneamente o reindirizza alla verifica del browser chi fa più di cinque richieste al secondo verso gli endpoint del carrello e della ricerca.

Questi siti di query gratuiti di solito sono lentissimi ad aggiornare i loro database. Un indirizzo IP di un data center ripulito tre mesi fa può ancora apparire come aggressore nel sistema. Se guardi direttamente la lista e banni, perdi potenziali clienti che si connettono dalla rete mobile.

La soluzione più pratica che puoi applicare subito è alzare di un livello la sicurezza nell'interfaccia dove gestisci il dominio e mettere una verifica automatica del browser (challenge) per le richieste di scansione provenienti da paesi sospetti. L'utente reale apre la pagina, i bot di scansione semplici invece si bloccano.

L'ordine da seguire dovrebbe essere più o meno questo: 1) Cerca nei log del server un pattern comune di user-agent. 2) Aggiungi un link trappola nascosto nelle pagine a cui i motori di ricerca non devono accedere e isola per 24 ore gli indirizzi IP che ci entrano. 3) Metti un limite di richieste sulle pagine di pagamento e del carrello.

anche noi una volta in preda al panico avevamo bloccato cinquanta ip e invece era la rete dell'ufficio di un cliente che ordinava all'ingrosso ma quelli visto che il sito non si apriva avevano fatto l'ordine da un'altra parte, il blocco statico è una cosa troppo rischiosa.

Il mese scorso in una scansione simile abbiamo individuato 3.000 indirizzi IP diversi che colpivano il nostro server. Negli strumenti esterni 1.200 sembravano rischiosi, ma quando li abbiamo esaminati è emerso che solo 75 in realtà facevano scraping dei dati. Agire in base all'IP senza guardare il comportamento fa perdere tempo.

Queste richieste in arrivo sono a un livello tale da bloccare il processore del server o fanno solo confusione nei log di accesso? E poi, gli intervalli orari in cui arrivano le richieste seguono uno schema preciso o sono completamente distribuiti nell'arco della giornata?

In generale è corretto, ma manca un pezzo. Il tempo che impiegate a rilevare un problema ne determina direttamente il costo.

Lascio una nota, potrebbe servire.

Questo approccio ha un costo, di cui non si parla. Quando prendete una decisione, scrivete anche lo scenario peggiore, non solo quello migliore.

Il vero problema non è il numero, ma su cosa si basa quel numero. Correggetemi se sbaglio.

La mia domanda sarà un po' da principiante, scusate. Le persone difendono le abitudini, non i processi. La resistenza nasce da lì.

Un report di scansione automatica e un penetration test non sono la stessa cosa. Correggetemi se sbaglio.

Concordo pienamente. Se non lo rendete scritto fin dall'inizio, poi nascono discussioni.

Il mio dubbio è stato chiarito, grazie.

Argomento molto attuale. Quando prendete una decisione, scrivete anche lo scenario peggiore, non solo quello migliore.

Lascio una nota, potrebbe servire.

Non ho alcuna esperienza in materia di strumento di controllo honeypot, quindi chiedo. Da noi la cosa che faceva perdere più tempo era non sapere chi decidesse.

Se è la prima volta, inizia in piccolo, il ridimensionamento viene dopo.

Direi di non avere fretta. Un backup non testato non è un backup.

Inizia con un piccolo test, non impegnarti subito su tutto. Spero che le sia utile.

Nel nostro caso è andata così. Se ricevete tre risposte diverse su un argomento, la domanda è posta male.

I primi tre mesi vanno bene, i problemi emergono al quarto mese.

Sono d'accordo. Se rimproverate i falsi allarmi nessuno segnalerà più nulla.

Spero che le sia utile.

Nel nostro caso è andata così. Da noi la cosa che faceva perdere più tempo era non sapere chi decidesse.

Naturalmente cambia se la vostra situazione è diversa.