Dati di recupero VPS brutalizzati ora disponibili. Considerazioni? [chiuso]

Inizierò con cosa fare con il tuo sistema attuale:

1. Entra e fai un backup di tutto.
2. A meno che tu non possa dimostrare le perdite maggiori ($ 10k +), non inizierei nemmeno a pensare di coinvolgere le forze dell'ordine. Hanno le mani piene e, dati i modelli attuali su Internet, è molto probabile che il tuo colpevole sia in un paese diverso da quello che sei. Nessuno sta andando a fare un processo di estradizione per i siti di Wordpress compromessi. (Scusa, so che è difficile da ascoltare, ma è la realtà.)
3. Masterizza il server corrente a terra.
4. Considera compromessa ogni password del tuo vecchio server.

Ora, come si costruisce un nuovo server per evitare che ciò accada di nuovo? Ho intenzione di fare alcune ipotesi sulla base di ciò che hai scritto nel tuo post:

• Installazioni multiple di Wordpress.
• mod_php su Apache
• cPanel / WHM

Ecco alcuni consigli:

1. Ottieni il tuo nuovo server.
2. Fai una nuova installazione delle tue applicazioni e configura password / credenziali forti che non hanno niente da fare con le tue vecchie.
3. Configura SELinux per limitare il più possibile l'esposizione di ogni sito.
4. Fai attenzione ai plugin di wordpress che installi. Hanno un track record di sicurezza molto peggiore rispetto a wordpress core.
5. Assicurati che le directory che sono scrivibili dal webserver siano mai che interpretano i file come PHP.
6. Utilizza l'autenticazione a 2 fattori per tutto ciò che puoi.
   • CPanel
   • SSH

Senza poter fare digital forensics sul tuo sistema, è difficile saperlo con certezza, ma ho intenzione di uscire su un arto e indovinare cosa è successo:

1. L'attaccante esegue lo scanner alla ricerca di installazioni Wordpress vulnerabili.
2. L'attaccante trova Wordpress vulnerabile sul tuo server. Ottiene RCE come server web.
3. Salva gli hash delle password per i database di wordpress.
4. Elimina gli hash della password, uno dei quali corrisponde a una password WHM / CPanel.
5. Entra in CPanel. Forse come amministratore, o forse la versione di CPanel aveva un bug che consente l'escalation dei privilegi per l'amministrazione.

Parli della paura di ritorsioni e dell'attaccante che ti insegue ancora e ancora. A meno che non sia personale (una vendetta di qualche tipo), non me ne preoccuperei. Gli aggressori come questo passeranno al loro prossimo host compromesso. Non dargli un'altra possibilità.

La risposta di David ha fornito alcuni consigli eccellenti (che consiglio vivamente di seguire). Concentrerò invece la mia risposta sulle tue paure specifiche nella speranza di alleviarli.

What I wish to accomplish is to acquire as much information about the hacker as possible. I want to download my legacy backups. I want to get in and out as soon as possible.

Dici di voler ottenere più informazioni possibili su questa persona. Questo potrebbe non essere pratico se usassero qualsiasi forma di anonimato. Il post-break in analisi è ancora importante, ovviamente. Il primo passo sarebbe quello di fare un backup completo del disco. Se non hai già spento il sistema da quando è stato compromesso, potresti anche essere in grado di scattare un'istantanea della memoria sul sistema, rendendo possibile eseguire analisi forensi successive. La memoria conterrà molte più informazioni sull'attaccante in quanto non possono controllare in modo affidabile ciò che rimane in memoria, mentre è molto facile impedire che informazioni importanti vengano salvate nella memoria persistente. Per questo motivo, è probabile che non sarai in grado di ottenere i log disattivati a meno che non esistessero già e venissero successivamente eliminati.

My precautions are to stay behind a killswitched vpn and spend as little time there as possible.

Esistono numerosi metodi che gli hacker possono utilizzare per ottenere l'IP originale dietro una VPN, a causa dell'architettura delle VPN. Sarebbe preferibile utilizzare Tor o una rete di anonimato simile. Trascorrere il minor tempo possibile potrebbe non essere consigliabile in quanto potresti perdere qualcosa di importante. Rimanere un po 'più a lungo non aumenta la possibilità che tu venga rilevato. L'hacker potrebbe anche pensare che tu sia un altro hacker che ha fatto irruzione utilizzando la stessa vulnerabilità. Se ti notano, le probabilità sono indipendentemente da chi pensano di essere, semplicemente ti disconnettono dal server.

I registri SSH sul lato server, tra gli altri, probabilmente contengono comunque il tuo indirizzo di casa.

Is there any way to somehow recover these disabled logs? What else should I be looking at if the goal is to compile enough data to turn this guy into the authorities?

Se i log erano disabilitati , probabilmente non puoi recuperarli. Se fossero ancora scritti ma semplicemente cancellati, potresti essere in grado di recuperarli dallo spazio non allocato del filesystem. A meno che il sistema non si sia spento dopo il compromesso e tu sia in grado di eseguire un'istantanea completa della memoria del sistema, è improbabile che tu possa recuperare le informazioni che sono state fornite nei log.

Come David ha già menzionato, probabilmente non si otterrà molto dal coinvolgimento delle forze dell'ordine. Il meglio che puoi ottenere da ottenere queste informazioni è sapere di più su come l'hacker ha fatto irruzione, rendendo possibile per te chiudere il buco che hanno sfruttato ed evitarlo in futuro.

My fear is that, even with a re-imaged server and all the hardening I'm capable of, this guy knows my site domains and will likely attack again. I suppose this should be a separate question, but should I prepare myself for having to altogether give up my domains due to his skill level? Id hate to do it, but I fear he will do all he can to wreck the server and sites again, then proceed as before to destroying my home network and all devices.

Onestamente, non devi preoccuparti di ritorsioni. Sei solo una garanzia casuale delle loro attività, non una vittima attentamente selezionata. Probabilmente non ricorderanno nemmeno il tuo dominio in una settimana. Naturalmente queste sono generalizzazioni, e se hai un nemico reale con una vendetta personale contro di te, le cose sono un po 'diverse. Ci sono alcune possibili classificazioni che possono adattarsi al tuo aggressore:

• Curioso : un hacker che entra in un sito perché è curioso o desidera migliorare le proprie capacità di hacking lo farà spesso con scarso riguardo per i risultati delle sue azioni, ma sono non fuori per prenderti. Se li blocchi, potrebbero voler trovare un modo per rientrare, ma probabilmente non saranno arrabbiati. Potrebbero persino vederlo come una sfida.

• Criminale - Un hacker puramente criminale ha qualcosa da guadagnare attaccando i server, come denaro o risorse digitali. Non perderanno tempo con la vendetta. Questi aggressori sono come l'acqua. Cercano il percorso di minor resistenza.

• Automatico - È molto probabile che nessuna persona abbia attaccato il tuo sito. Un'impresa criminale vuole massimizzare i profitti, quindi per essere più efficienti, spesso automatizzano gli attacchi. Uno script può cercare su internet servizi vulnerabili e attaccarli. Dopo l'irruzione, farà il loro sporco lavoro e tenterà di stabilire la persistenza. Non puoi fare arrabbiare uno script.

• Script kiddie - Uno script kiddie è un giovane hacker che pensa di sapere tutto. Sono più propensi a cercare vendetta perché possono prendere l'atto di recuperare il tuo server come personale. Non hanno le competenze necessarie per fare danni reali alla rete domestica. Il peggio che possono fare è tentare di farti DDoS. Non preoccuparti per loro.

• nemico personale : se hai un nemico reale con una vendetta personale contro di te, devi preoccuparti di più. Dato che non hai fornito alcuna indicazione sul fatto, suppongo che non lo sia.

È probabile che i suoi livelli di abilità non siano così alti come pensi. Entrare in un sito Wordpress e aggiungere una backdoor non richiede un professionista. In quanto tale, non mi preoccuperei di eliminare i tuoi domini. È assolutamente possibile proteggere da questo hacker usando il consiglio dato in un'altra risposta. Non appena il sito di qualcun altro è più vulnerabile del tuo, un hacker si muove.

In questo caso non sai come l'hacker è stato in grado di entrare, quindi hai ragione ad essere preoccupato che la stessa cosa succederà di nuovo anche se si esegue una reinstallazione completa. Per risolvere questo problema, è necessario configurare il sistema per la registrazione remota. Un computer separato dedicato salva i log di sistema che non possono essere manomessi. È necessario configurare il registro di accesso del server Web per inviare una copia in tempo reale al server di registrazione e qualsiasi altra informazione relativa alla sicurezza, oltre al normale registro di sistema. I registri devono essere separati in modo che se uno diventa troppo grande e debba essere tagliato in modo tale da non influenzare gli altri.

Non sai come sono entrati. Il tuo computer potrebbe essere compromesso e la password potrebbe essere stata intercettata. Qualcuno al provider VPS avrebbe potuto accedervi, o qualcuno che affittasse un altro VPS al tuo fianco avrebbe potuto sfruttare qualcosa. Supponendo che queste cose non siano accadute, il passo successivo potrebbe essere quello di assicurarsi che tutto ciò che è vulnerabile sia aggiornato sulla nuova installazione, e quindi configurare il software di sicurezza come SELinux. Assicurati che le violazioni dei criteri SELinux siano inviate al server di registrazione remoto.

My precautions are to stay behind a killswitched vpn and spend as little time there as possible.

Questo è infosec voodoo. Supponendo che tu sia dietro un router con PAT, l'hacker non avrà alcun modo di riconnettervi. In effetti, la VPN crea un tunnel attraverso il livello PAT, quindi stai aumentando la tua esposizione usandolo! (Sebbene il criterio VPN possa impedire connessioni in entrata.)

Il rischio molto maggiore è che se l'utente malintenzionato ha ancora accesso al sistema compromesso, digitare la password è pericoloso, ad esempio l'accesso interattivo SSH o la password sudo potrebbero essere rubati da un utente root sul sistema compromesso. Se si dispone dell'autenticazione della chiave pubblica configurata, è consigliabile utilizzarla a condizione che non si utilizzi sudo, tuttavia consultare la nota seguente sui backup ...

La procedura migliore è rimuovere il disco rigido dalla macchina compromessa e analizzarlo in modo forense su una macchina separata (un professionista usa un forensic write blocker ) in modo che l'attaccante non abbia capacità di interferire.

Come cliente VPS, non hai capacità di farlo da solo. A meno che il tuo fornitore non sia disposto a farlo per te (improbabile dal momento che potrebbe disturbare altri inquilini sullo stesso hardware), è meglio eliminare il VPS e partire da zero.

Hopefully I can get what I need from backups and [snip]

I backup dovrebbero sempre essere archiviati su un sistema separato. Se i tuoi unici backup sono archiviati nel servizio compromesso, allora ti sei messo in una posizione molto brutta. Se devi digitare una password per accedere ai backup, l'utente malintenzionato può rubare la tua password.

Anche se non è necessario digitare una password (ad esempio l'autenticazione della chiave pubblica), si ripristinano i dati che sono già stati violati. Se l'utente malintenzionato ha installato una backdoor in precedenza, quella backdoor verrebbe salvata nei backup e si finirebbe per ripristinare quella backdoor sul nuovo server! O se l'autore dell'attacco ha utilizzato altri mezzi per compromettere il sistema, l'autore dell'attacco potrebbe aver inserito una backdoor nei backup per poter riottenere l'accesso dopo la nuova immagine.

Is there any way to somehow recover these disabled logs?

Sì, è possibile recuperare i dati del registro cancellati utilizzando l'analisi forense, ma per i motivi sopra indicati, è improbabile che questa sia un'opzione disponibile per te.

In alternativa, il tuo provider potrebbe avere dei registri su quali indirizzi IP si collegano ai loro sistemi, e potrebbero essere disposti a condividerli con te se lo chiedi gentilmente.

My fear is that, even with a re-imaged server and all the hardening I'm capable of, this guy knows my site domains and will likely attack again.

Non sono sicuro di cosa intendi per "domini". Puoi mantenere il tuo account di hosting e i nomi di dominio esistenti, supponendo che la tua password sia stata reimpostata su qualcosa di sicuro.

Lo scenario più probabile è che tu sia stato compromesso a causa di una vulnerabilità non corretta in WordPress o uno dei tuoi plugin (o codice personalizzato se ne hai scritto qualcuno tu stesso). Per evitare un futuro compromesso, è necessario iniziare da zero (non utilizzare un backup dei dati) e assicurarsi che tutte le applicazioni e i plugin siano la versione più recente. Disabilita tutti i plugin di cui non hai assolutamente bisogno.

Sembra che potresti essere un po 'sopra la tua testa. Gestisci software complesso da solo e non sai come si è verificato il precedente compromesso. Forse dovresti spostare il tuo sito su un provider che offre migliori patch e sicurezza, come l'hosting tramite WordPress.com, in modo che la responsabilità non sia al 100% su di te.

La maggior parte dei provider di hosting mette a disposizione una piccola immagine del sistema operativo (lo scopo è facilitare l'installazione iniziale del sistema operativo quando un client richiede un sistema operativo personalizzato o correggere errori che impediscono l'avvio del sistema operativo, in genere chiamato "sistema di ripristino" o qualcosa del genere) che puoi avviare e accedere al VPS compromesso senza mai lanciare alcun malware che gli aggressori potrebbero aver messo lì. Devi solo montare i tuoi volumi, copiare tutti i dati necessari ed esaminarli a tuo piacimento.

Se non puoi farlo, la tua unica preoccupazione è di non concedere agli attaccanti ulteriori vettori di attacco. Non collegare SSH ad altre macchine da quella compromessa, assicurarsi di non utilizzare l'inoltro dell'agente SSH, l'inoltro X11 e simili. Basta tarare i file interessanti e quindi scpare il file tar dal tuo computer locale. Oppure fai qualcosa come ssh -C root@compromised-host cat /dev/the-root-device >compromised-root-dev.img se sai cosa fare con l'immagine allora.

O forse basta chiedere al provider di hosting di creare un'immagine del filesystem e inviarla in qualche modo (il che equivarrebbe alla stessa procedura con cui ho iniziato).

Is there any way to somehow recover these disabled logs?

Sì.

Se l'intera macchina virtuale è tua (e non la stai condividendo con qualcun altro), ottieni un backup dell'intera macchina virtuale. Fallo immediatamente. Ciò includerà tutti i registri della tua macchina.

Chiedete anche a Bluehost i registri rilevanti che possono fornire. Fatelo immediatamente in modo che non perdano i registri. (Molti luoghi cancellano i log nel tempo, quindi assicurati che qualcuno sappia di conservare i log che si ritiene siano potenzialmente interessanti.)

Quindi concentrati su come rendere operativa una macchina sicura. (Come menziona BlueHost, questo probabilmente implica un ricarico del sistema operativo.) Assicurati che i tuoi dati siano al sicuro. (ad esempio, se i tuoi dati includono informazioni sugli account e includono un account che l'utente malintenzionato utilizza per ottenere l'accesso, ciò non è sicuro). Chiedi a quella macchina sicura di utilizzare i dati sicuri che ritieni importanti. Fai tutto ciò il più rapidamente possibile.

What else should I be looking at if the goal is to compile enough data to turn this guy into the authorities?

Da dove viene questo attaccante? Chi è questo aggressore?

Come osserva la foresta, è improbabile che alle "autorità" importi molto. È probabile che tu possa essere stato attaccato da qualche altra macchina compromessa. Pertanto, la persona che possiede quella macchina è anche una vittima, e il tentativo di attaccare legalmente quella persona probabilmente non gioverebbe molto a nessuno. Quello che devi fare è ottenere la persona che ha veramente iniziato l'attacco. Sfortunatamente, con diversi metodi di reindirizzamento possibili, molti attaccanti non sono tracciabili in modo accettabile.

My fear is that, even with a re-imaged server and all the hardening I'm capable of, this guy knows my site domains and will likely attack again.

Yup. Questa è una preoccupazione. Finché la persona non viene fermata, c'è un tale potenziale. Spero che tu abbia più successo nel prevenire i prossimi attacchi. L'educazione continua e gli sforzi dovrebbero portarti a quel punto, si spera prima o poi. Nel frattempo, assicurati di avere backup validi e accessibili e di dormire bene la notte, sapendo che puoi ripristinare dal backup.

I suppose this should be a separate question, but should I prepare myself for having to altogether give up my domains due to his skill level?

No. Non arrenderti.

Id hate to do it, but I fear he will do all he can to wreck the server and sites again,

Ciò potrebbe accadere se non si protegge il server con maggior successo. Cerca di passare del tempo a farlo. Inoltre, assicurati di avere dei buoni backup. Non fidarti solo di Bluehost. Non sto cercando di dire niente di male su Bluehost. Sto dicendo, non fidarti solo di una soluzione di backup, specialmente se si prevedono problemi.

then proceed as before to destroying my home network and all devices.

Oh, ora è semplicemente terribile. Perché danneggiare una macchina virtuale remota, eseguire su un sito di hosting professionale, influire sulla rete domestica? Ci sono alcuni importanti problemi di sicurezza in questo caso.

Is this even worth it? He's capable of far worse than what he did and I am in fear of retaliation.

Ottieni i backup del tuo sito web.
Ottieni backup di dati importanti sulla rete domestica.

Se fai un buon lavoro, allora anche se il furto finirà per essere possibile (una copia delle informazioni riservate potrebbe essere rubata), puoi ancora recuperare.

Basta ottenere un'immagine del drive del web server. È improbabile che il montaggio su una macchina virtuale fresca possa causare rischi significativi. Il codice dall'unità montata non deve essere eseguito, puoi leggere i dati a tuo piacimento.

Non è sicuramente sicuro connettersi a una macchina compromessa con un protocollo di accesso remoto. Mentre i server sono più costantemente disponibili per essere compromessi, è possibile sfruttare il software client connesso a un server malevolo (se esiste un exploit).

Il tentativo di ripristinare il contenuto Web dal contenuto dell'unità montata è probabilmente sconsigliato. Le modifiche ai file di codice possono essere abbastanza nascoste e difficili da trovare. Usando PHP, possono facilmente fornire una backdoor alla tua prossima macchina VPS ...

Le informazioni nel database SQL potrebbero essere modificate per contenere codice per attaccare i visitatori del tuo sito web.

Se vuoi davvero indurire il tuo sito sbarazzati di WordPress. Meravigliosi elementi vengono generati con generatori di siti statici (Gatsby, Jekyll, ecc ...)

Come alcune informazioni a cui allude qui - se hai usato queste credenziali compromesse ovunque altrimenti devi cambiare le tue password. Preferibilmente, dovresti usare un buon strumento come Keepass o Lastpass che ti consente di proteggere un numero qualsiasi di password forti, generate e casuali, e devi solo ricordare la passphrase principale.