Virus di phishing trovato sul server

Per prima cosa: tu devi (insisto, devi ) cancella il tuo disco rigido e reinstalla da zero. Qualsiasi utente malintenzionato o semplice virus che possa ottenere l'accesso come root su un sistema non si fermerà sicuramente dopo aver aggiunto una cartella. È molto probabile che una o più backdoor siano state installate, in varie utilità di sistema e / o nel kernel stesso, in modi che non sarete in grado di rilevare dalla macchina stessa. Quindi salva i file di dati, reinstalla il sistema e copia i file solo dopo una verifica (in particolare i file di origine PHP).

Una connessione SSL / TLS inizia con un primo messaggio inviato dal client e inizia con un'intestazione i cui primi tre byte avranno il valore 0x16, 0x03 e 0x01, in quell'ordine (supponendo che il client implementa TLS 1.0 , che è il caso più comune). Le tue linee di log sembrano come se qualcuno avesse provato a connettersi al tuo server HTTP come se fosse un server HTTPS - e il tuo server, incapace di dare un senso ai byte inviati dal client, ha risposto con un messaggio di errore HTTP appropriato (che probabilmente il client non capiva neanche, dal momento che stava cercando di stabilire una connessione TLS, non di scambiare messaggi HTTP). Questo è probabilmente innocuo e molto probabilmente completamente estraneo al tuo problema di intrusione.

Per evitare ulteriori intrusioni, è necessario utilizzare solo software privo di bug, il che non è possibile con l'attuale tecnologia terrestre. Il più vicino è possibile per mantenere aggiornato il sistema con le note correzioni di sicurezza; dovresti controllare gli aggiornamenti di sicurezza su base giornaliera (con Debian, si tratta di apt-get update && apt-get dist-upgrade ).

dal mio punto di vista questa sarebbe una soluzione su tre fronti. In realtà, la soluzione è una parolaccia da usare ... la "mitigazione" è molto più applicabile. Prima di tutto sono d'accordo con @Thomas Pornin e dico che è necessario cancellare il sistema. Dopo questo passaggio, i tre poli sono i seguenti:

1. Controlla il sistema per le modifiche al filesystem. Un'ottima opzione qui è tripwire . Questo strumento deve prima essere eseguito su un sistema pulito (completamente nuovo, l'installazione fresca è la migliore) per ottenere una linea di base. Quindi, in base a un processo cron, i file specificati sul sistema verranno controllati per le modifiche.
2. Controlla i log di sistema. In questo modo sarai in grado di seguire la traccia cartacea alla fonte nel futuro. Il modo migliore per farlo è tramite una soluzione SIEM (ad esempio OSSIM )
3. Monitora i possibili vettori di attacco. Utilizzare una sorta di scanner di vulnerabilità. Questo ti indurrà all'apertura che potrebbe consentire attacchi. Una possibile soluzione è nessus .

Therare molte soluzioni per tutti questi strumenti. Alcuni altri aspetti da osservare sono i monitor di rete e i profiler come nagios e OrionNPM che può essere utilizzato per un po 'più di analisi. Non sono sicuro delle capacità di avviso di Orion, ma suppongo che potrebbe avvisare se ci sono connessioni sospette, nuovi host di rete, attacchi denial of service o qualsiasi evento per cui vorresti creare un profilo.

Questo sembra un sacco di lavoro se hai una piccola operazione, ma può essere di grande aiuto. Penso che tutto ma orionNPM sono soluzioni gratuite (o una versione legale gratuita può essere trovata).

Se si dispone di dati o servizi preziosi su cui altri si affidano, per quanto mi riguarda, tutte queste pratiche fanno parte della due diligence del gestore patrimoniale (o responsabile della sicurezza, amministratore o chiunque si occupi della sua sicurezza ).

Tieni presente che questa risposta riguarda gli strumenti che potresti aver utilizzato o che potrebbero essere utilizzati in futuro per aiutare a prevenire questo tipo di attacco. Tieni a mente anche le best practice .... rimanendo aggiornato, utilizzando canali di comunicazione sicuri, utilizzando password complesse, controllando strettamente le autorizzazioni degli account, limitando le risorse degli utenti connessi, ecc ....

PS è provocatorio nei repository di ubuntu apt-get, così come lo scanner di vulnerabilità openVAS (ma ho avuto problemi nel tentativo di implementare openVAS).

Un file di proprietà di root:root non è un problema. Di fatto, se si riscontrano problemi con la defezione della propria applicazione Web, eseguire una chown root:root -R /var/www impedirà all'applicazione compromessa di modificare le autorizzazioni sul file. Fare un chmod -R 555 . /var/www insieme alla proprietà di root è una grande idea. Queste autorizzazioni renderanno impossibile a un virus basato su PHP di deturpare la tua applicazione web.

Sebbene la radice del problema sia la presenza di vulnerabilità nella tua applicazione web. È probabile che tu usi una vecchia applicazione o una libreria che è vulnerabile ad attaccare .