Non ti succederà? :DDDDDDD
Gestendo più di 300 siti web, di tanto in tanto mi si presentano varie emergenze. A volte sono piuttosto accesi, ma spesso si tratta di una banalità assoluta. Se, come me, siete stati tentati dalla programmazione in passato e sapete anche che la programmazione è una sofferenza, sarete sicuramente d'accordo con me.
Quando un'applicazione web diventa popolare, diventa un bersaglio allettante per gli hacker. Di solito la loro motivazione non è quella di far crollare l'intero sito web, al contrario. In effetti, gli hacker vogliono che voi, in qualità di amministratori del server, ne siate completamente all'oscuro. Un buon hacker aspetta per mesi, sorvegliando il server web e ottenendo la cosa più preziosa: i vostri dati.
Per proteggere i vostri utenti, è indispensabile criptare tutti i dati e disporre di più livelli di protezione. Per le password, utilizzare una delle funzioni lente come Bcrypt + salt, Argon2, PBKDF2 o Scrypt. Michal Spacek ha già scritto su security rating, e lo ringrazio per aver arricchito l'articolo. Il proprietario di un sito deve insistere sull'hashing corretto delle password quando discute con un programmatore. Altrimenti, vi metterete a piangere, proprio come molti altri prima di voi che si sono illusi che la cosa non li riguardasse.
Ho notato che quando un server Web raggiunge una certa soglia di traffico (nella Repubblica Ceca, si tratta di circa 50+ visitatori al giorno), inizia a ricevere una serie di attacchi dal nulla. Per non rendere le cose facili, l'attaccante ha sempre un vantaggio, perché può scegliere quale parte dell'infrastruttura iniziare ad attaccare e voi - in quanto proprietari del server web - dovete riconoscerlo in tempo, difendervi e prepararvi al meglio per la prossima volta.
Quanti attacchi vi sono stati rivolti nell'ultimo mese, ad esempio? Lo sai esattamente? Quanti ne ha difesi? Qualcun altro ha accesso al vostro server?
E se qualcuno vi stesse attaccando in questo momento? E ora... e ora anche...?
Purtroppo non esiste un modo univoco per riconoscere un attacco. Ma ci sono strumenti che possono darvi un vantaggio significativo.
Quello che ha funzionato meglio per me ultimamente:
In effetti, anche le grandi aziende commettono errori, anche su cose banali come l'attacco XSS (cross-site scripting).
La questione non è se qualcuno violerà mai il vostro sito web. Il problema è quando accadrà e se sarete abbastanza preparati per affrontarlo. Forse un hacker ha avuto accesso al vostro server per mesi e voi non lo sapete (ancora).
Quando si scopre il lavoro dell'hacker, di solito è troppo tardi e l'hacker ha fatto tutto quello che doveva fare. È molto probabile che abbia piazzato del malware su tutto il server e che abbia un controllo almeno parziale della macchina.
Si tratta di un problema di tipo caotico e bisogna agire in fretta.
Poiché questa è l'ultima fase dell'attacco, personalmente consiglio di scollegare completamente il server Web da Internet e iniziare a capire gradualmente cosa è successo. Inoltre, non sapremo mai esattamente se il server nasconde qualcos'altro. L'attaccante ha sempre un vantaggio significativo.
Se decidiamo di rimettere l'ultimo backup funzionante sul server, aiuteremo molto l'attaccante. Sa già come entrare nel vostro server e non c'è nulla che gli impedisca di farlo di nuovo tra qualche ora. Inoltre, il backup probabilmente contiene malware o qualche altro tipo di virus.
Sebbene sia un'opzione molto impopolare tra i miei clienti, personalmente consiglio sempre di eliminare completamente i siti WordPress o qualsiasi sistema che il cliente non aggiorna e che presenta molte minacce alla sicurezza. Ad esempio, se ospitate 30 siti su un server che hanno più di 2 anni, è praticamente garantito che almeno uno di essi contenga una qualche forma di vulnerabilità.
Se non capite il problema, è meglio che contattiate subito uno specialista adatto, che abbia una conoscenza approfondita del vostro problema e che capisca le cose in un contesto ampio.
**Nota etica
Se gestite un sito web per un cliente che ha avuto un incidente di sicurezza, è vostra responsabilità informarlo. In caso di fuga di dati (come le password, ma spesso anche molto di più), è necessario informare gli utenti finali che la loro password è di dominio pubblico e che devono cambiarla ovunque. Se utilizzate una funzione di hashing lenta (ad esempio, Bcrypt + sale), renderete molto più difficile per un aggressore decifrare le password (purtroppo, Le password di Bcrypt possono essere decifrate). Se desiderate ricevere regolarmente informazioni sull'eventuale fuga del vostro account, vi consiglio di registrarvi su Have i been pwned?. Per ulteriori informazioni su violazione della sicurezza, visitare il sito Web di OOOO.
Negli ultimi sei mesi ho finito di leggere il libro [Atomic Habits] (https://www.melvil.cz/kniha-atomove-navyky/), che mi ha aperto gli occhi. Descrive un processo di miglioramento incrementale dell'1% ogni giorno, che a lungo termine farà molto.
Poiché vengo contattato da aziende e individui in varie fasi di indebitamento tecnologico, vorrei riassumere le cose peggiori:
noindex
e nofollow
per evitare di essere indicizzate da Google. I contenuti sensibili che i vostri concorrenti non devono conoscere devono essere protetti da password.Le vulnerabilità sono molte di più e i problemi variano da progetto a progetto. Se dovete fare una rapida verifica del server, vi consiglio di usare Maldet e poi di assumere uno specialista adatto che vi aiuti a fare una verifica completa del sito, e non solo per motivi di sicurezza.
Gli ingegneri della sicurezza sono come la plastica nell'oceano: per sempre. Abituatevi.
Avrete anche notato che la natura utilizza quasi sempre il principio di reazione. Ciò significa che qualcosa accade in un particolare ambiente e gli organismi circostanti reagiscono ad esso in modi diversi. Questo approccio presenta molti vantaggi, ma un enorme svantaggio: rimarrete sempre indietro.
In qualità di pensatori (progettisti, sviluppatori, consulenti) avete un grande vantaggio, che è quello di essere perseguibili, cioè di conoscere in anticipo una certa parte dei grandi rischi e di evitare attivamente che si verifichino. Forse non riuscirete mai a prevenire tutti gli errori, ma potete almeno attenuarne le conseguenze o creare meccanismi di controllo che rilevino i problemi in anticipo, in modo da avere il tempo di reagire.
La maggior parte degli attacchi avviene in un lungo periodo di tempo e, se si registra, di solito si ha abbastanza tempo per rilevare il problema.
Jan Barášek Více o autorovi
Autor článku pracuje jako seniorní vývojář a software architekt v Praze. Navrhuje a spravuje velké webové aplikace, které znáte a používáte. Od roku 2009 nabral bohaté zkušenosti, které tímto webem předává dál.
Rád vám pomůžu:
Články píše Jan Barášek © 2009-2024 | Kontakt | Mapa webu
Status | Aktualizováno: ... | it