Rilevamento dell'iniezione del codice su server Web

Riepilogo. La migliore difesa contro l'iniezione di codice è impedirlo in primo luogo. In generale, una volta che il codice dannoso è entrato nel tuo sistema, non esiste un modo affidabile per rilevarlo. So che stavi chiedendo informazioni sul rilevamento, ma ti consiglio di concentrarti sulla prevenzione , non sul rilevamento.

Prevenzione. Quindi, come prevedi l'iniezione di codice? In generale, attraverso il controllo degli accessi, una buona igiene della sicurezza e processi di sviluppo del software sicuri.

• Se hai un server web, non condividerlo con altre persone. È abbastanza facile usare la virtualizzazione per fornire l'isolamento tra più inquilini. Ad esempio, se acquisti l'hosting condiviso da un servizio di hosting condiviso commerciale, utilizzeranno una qualche forma di virtualizzazione per isolare i loro clienti gli uni dagli altri. (Questo non ha nulla a che fare con l'accesso FTP e l'accesso alla shell. Fintanto che i clienti sono isolati gli uni dagli altri, non importa se il provider di hosting fornisce l'accesso alla shell o l'accesso FTP. accedi solo ai loro contenitori virtuali, e non ai tuoi.) Allo stesso modo, non condividere le tue password o chiavi di crittografia con altri.

• Esercitare pratiche di amministrazione del sistema corrette, per evitare compromessi sul server. Mantieni il tuo software completamente aggiornato e aggiornato. Utilizzare i firewall per limitare l'accesso solo ai servizi che si desidera esporre. Usa SSH con autenticazione a chiave pubblica per l'accesso remoto. Se devi utilizzare le password, assicurati di scegliere password lunghe e resistenti, non condividerle mai e inviarle solo su canali criptati.

• Esercitare buoni processi di sviluppo del software. Evita di introdurre vulnerabilità di sicurezza nel software che scrivi. Interi libri sono stati scritti su come fare per farlo, quindi non cercherò di spiegare in dettaglio qui; Lo contrassegnerò semplicemente come qualcosa di importante, per garantire che il software sia privo di vulnerabilità della sicurezza.

In parte, sono d'accordo con DW , la prevenzione è maggiore del rilevamento ma solo quando funziona. Una volta che la tua macchina è compromessa, ti prenderai a calci per non avere meccanismi di rilevamento migliori (o nessuno!) Sul posto. In generale, cerco di suddividere il mio focus su entrambi, e in alcuni punti il rilevamento può ottenere un po 'più di attenzione.

Qualcuno con il tuo profilo di rischio (proprietario di piccole imprese con provider di hosting condiviso di base, ecc.), di solito non ha la capacità di spendere tempo, denaro e sforzi o apportare le modifiche necessarie per investire pienamente in una soluzione di sicurezza. Suggerirei un approccio a 3 poli composto da prevenzione , rilevamento e ripristino .

Nota, questa non è una discussione esauriente su ognuno di questi "rebbi", ma piuttosto sono qui per far funzionare i tuoi succhi di pensiero. Mi piacerebbe sapere cosa decidi di implementare, insieme a chiunque altro!

Prevenzione

Non dedicherò molto tempo alla prevenzione, c'è solo molto da coprire. D.W. ha indicato alcuni punti di partenza nel suo post e ci sono un sacco di risorse online riguardanti la codifica sicura. Ti suggerisco di iniziare con le guide OWASP e Mozilla:

link

link

link

link

Rilevamento

Alcuni malware moderni (e intrusi) hanno la capacità di radicarsi così profondamente nelle viscere del sistema operativo della vittima che la rimozione verificabile approccia impossibile. Tuttavia, non suggerirei di mettere tutte le uova in un cesto, ad esempio, concentrandomi solo sulla prevenzione. Concentrarsi solo sulla prevenzione lascia un sacco di spazio post-compromesso che avrebbe potuto raccogliere artefatti e prove.

Gli ambienti di hosting condivisi non sono sempre i migliori per la loro personalizzazione in termini di ciò che deve accadere per un'iniziativa di sicurezza, quindi dipende molto dal fornitore. (vedi Come mantenere sicuro un server di hosting Web condiviso )

L'incidente è stato per lo più probabilmente parte di un compromesso di massa, ad es. l'iniezione SQL di un sito sul tuo host condiviso che ha portato a un compromesso con il sistema operativo. Lo script quindi cerca * .php in cui iniettarsi. Una volta infettato, il worm / attacker si sposta sul / i prossimo / i host / i. Anche se questo potrebbe non essere esattamente quello che è successo, è un caso comune, e demonizza un modello di attacco comune che è difficilmente un attacco sofisticato o un'attività impossibile da rilevare e ripulire.

A seconda di ciò che è in grado di distribuire localmente, la soluzione migliore potrebbe essere l'utilizzo di un servizio di terze parti che cerca segni di infezione, ad es.

link

link

Un'altra opzione è quella di utilizzare uno script semplice per confrontare i checksum di tutti i tuoi file e inviarti un'email quando è diversa. Potresti quindi usare git hooks per aggiornare la tua configurazione di script con i checksum "buoni" attuali. Ho avuto fortuna con script semplici come questo anche per altre cose, ad es., Controllo cert SSL, verifica intestazioni, ecc.

Recupero

Ora che hai un meccanismo di rilevamento, cosa succede quando ricevi quella temuta email alle 3 del mattino? Avere un processo chiaro sul posto ridurrà notevolmente i tempi di fermo e i capelli grigi.

Come hai citato git nella tua domanda, assumerò che tu sia un utente corrente. Ci sono alcuni buoni post su come usare Git per gestire un sito web. Consiglierei di utilizzare un processo simile a uno dettagliato in:

link

link

link

Ricorda, questo è solo il tuo codice, non necessariamente tutti i tuoi dati, ad es. database e contenuti caricati.