Fino a che punto posso fare scansioni della superficie di attacco in autonomia con strumenti open source?

Quando fate scansioni attive dovete fare molta attenzione al rate limit. Se lanciate una scansione che spara centinaia di pacchetti al secondo, i sistemi IDS/IPS del data center isoleranno automaticamente il vostro server. Conviene sempre eseguire le scansioni su un singolo thread e impostare un delay tra una richiesta e l'altra.

Con gli strumenti open source vedi solo se la porta è aperta o meno. Questi tool non ti dicono come possano essere sottratti i dati dietro quella porta né se la combinazione di due servizi diversi crei una falla. Bisogna evitare di cullarsi in un falso senso di sicurezza.

L'anno scorso ho fatto girare uno scanner open source simile sul nostro server a Berlino. Un'ora dopo abbiamo ricevuto un avviso di attività malevola dall'hosting provider e ci hanno sospeso il traffico del server. Finché non abbiamo chiarito la situazione siamo rimasti con i sistemi down per mezza giornata.

Come primo passo iniziate con tool di ricognizione passiva. Senza inviare nemmeno un pacchetto a nessun server solo dai registri pubblici su internet potete beccare decine di sottodomini dimenticati e vecchie pagine di test. Sistemate prima quelli.

vi consiglio di non lanciare scansioni aggressive senza avvisare prima il data center e far mettere in whitelist i vostri ip altrimenti poi vi tocca impazzire col reparto abuse.

I server che usate sono dedicati interamente a voi o macchine cloud condivise? Negli ambienti condivisi le regole sono molto più rigide per via del rischio di impattare sugli altri clienti nello stesso blocco IP.

Anche se si tratta di roba vostra per scansioni attive di vulnerabilità a livello di rete non fate nulla senza una notifica formale al vostro data center.

Racconto la mia esperienza. La risposta varia molto in base al settore, non esiste una regola generale.

Non abbiate paura di chiedere, chi non chiede paga sempre di più. È tutto, scusate se mi sono dilungato.

Vorrei fare una domanda. Avere il backup accessibile sulla stessa rete e con le stesse credenziali lo rende parte del bersaglio.

Non lo sapevo. La risposta varia molto in base al settore, non esiste una regola generale.

Sono nella stessa situazione, per questo chiedo. L'errore commesso da superficie di attacco open source è generalmente reversibile ma costoso.

Io seguirei questa strada.

Bisogna procedere con ordine. La sicurezza non è assoluta; significa rendere l'attacco non conveniente.

Le modifiche ai dati di pagamento non vanno mai verificate tramite il canale di provenienza. È tutto, scusate se mi sono dilungato.

Su questo punto non sono d'accordo. Avere il backup accessibile sulla stessa rete e con le stesse credenziali lo rende parte del bersaglio.

Quando prendete una decisione, scrivete anche lo scenario peggiore, non solo quello migliore. Confermato dall'esperienza.

Assolutamente... onestamente se devo aggiungere qualcosa: Se permessi e ambito non sono scritti, quel test non deve iniziare.

Se non ho capito male, stai dicendo che: L'errore commesso da superficie di attacco open source è generalmente reversibile ma costoso.

Corretto.

Riassumo l'argomento perché sono state date diverse risposte. La sicurezza non è assoluta; significa rendere l'attacco non conveniente.

Confermato dall'esperienza.

Nel nostro caso è andata così. La maggior parte degli incidenti non inizia da una vulnerabilità, ma da una password trapelata.

Naturalmente cambia se la vostra situazione è diversa.