Rilevamento automatico di un server Web compromesso

Esistono numerosi processi locali che guarderanno i file e le directory per eventuali modifiche, scritture, eliminazioni e accessi. Quando si verificano questi eventi, il processo crea un registro eventi tramite syslog. Questo può accadere in un secondo.

Se le voci di syslog vengono inviate a un server remoto (come dovrebbero essere) si avranno quasi istantaneamente allarmi alle modifiche dei file, senza la possibilità di "ingannare" nulla, senza alcun traffico web "non necessario".

Ci sono software preconfezionati per fare questo, o possono anche essere fatti usando script personalizzati (il software preconfezionato e testato tende a essere migliore).

Question 1:- assuming the polling interval is acceptable, is this a strong enough defense? Could the malicious code fool the polling code?

No, non è una difesa abbastanza strong. Sì, il codice dannoso può identificare il server / servizio di polling tramite IP, User Agent, ecc. E fornire il file pulito all'agente di polling mentre continua a offrire file dannosi ad altri. Certo, puoi provare a prevenire il rilevamento modificando regolarmente gli IP e gli agenti utente dell'agente, ma anche il codice dannoso può adattarsi per rilevare la tua modifica.

Pur servendo contenuti diversi in base al cliente è di per sé una cosa banale da fare, il fatto che l'hacker sappia che tale salvaguardia è in atto non è banale (è più simile a una sicurezza attraverso l'oscurità). Il modo in cui un utente malintenzionato può sapere di tale salvaguardia è quando conosce la propria architettura (minaccia interna) o se si attraversano i cicli di compromesso di > fix- > abbastanza a lungo da consentirgli di limitare la causa del rilevamento dei compromessi. / p>

Question 2:- Is there a better way to reduce the window of risk other than reducing the polling interval, which creates unnecessary traffic.

Il modo migliore per ridurre il rischio è di avere difesa in profondità :

• Avere strumenti di integrità dei file basati su host come tripwire per guardare i file in questione.
  • La sconfitta di questa difesa richiede un compromesso dell'host
• A seconda della sensibilità dei file e del livello di paranoia, configura gli strumenti di distribuzione per ricostruire i tuoi file ogni ora.
  • La sconfitta di questa difesa richiederà un compromesso di rete.
• Monitoraggio remoto dei tuoi file come descritto.
  • Sconfiggere questa difesa richiede 1.) compromissione della macchina remota o 2.) sufficiente conoscenza / ricognizione del tuo sistema.
• Distribuire strumenti di rilevamento / prevenzione delle intrusioni basati su host come snort , fail2ban , denyhosts per rilevare l'intrusione.
  • La sconfitta di questa difesa richiede un attacco che non crea molto rumore nei file di registro e / o elude il rilevamento basato sulla firma, ad es. difetti del livello applicativo.
• Distribuire un firewall per applicazioni Web es. ModSecurity per rilevare anomalie a livello di applicazione.
  • Per sconfiggerlo è necessario un attacco di livello inferiore che dovrebbe essere rilevato in modo ideale nel punto sopracitato.

Anche se tutte le misure di cui sopra non possono garantire la sicurezza, tuttavia riducono la superficie di attacco e rendono difficile un compromesso riuscito e non rilevato.

Per quanto riguarda la domanda 1, sarebbe facile per il codice dannoso ingannare il codice di polling. Come esempio, un sacco di malware PHP esamina le stringhe degli User Agent e restituisce 404 codici a Google, Bing, Yahoo e altri. Sarebbe quasi altrettanto facile tenere traccia degli indirizzi IP che fanno richieste ripetitive e spoofarli. Dato un avversario dedicato, l'intera cosa si trasformerebbe in una corsa agli armamenti - chi può scrivere i test più sottili per l'autenticità contro chi può falsificare i test sottili per l'autenticità. Questo non vuol dire che si verificherà una tale corsa agli armamenti, o che personalmente non puoi vincere una tale corsa agli armamenti, ma piuttosto, in generale, codice dannoso e codice di test fallace.

Penso che il tuo problema sia strettamente correlato alla difficoltà di monitorare semplicemente un servizio sulla rete. Anche qualcosa come una chiamata a una procedura remota o un'interfaccia REST può essere difficile da monitorare correttamente di fronte a bizzarri bug. Avendo provato questo in passato, posso assicurarti che finisci in una "corsa agli armamenti" contro i bug più strani e più strani.