Sul server girano processi che non riconosco, l'hosting dice 'pulite' — da dove inizio?

anche a me è successa la stessa cosa l'anno scorso, erano entrati tramite un exploit di un plugin WordPress. All'epoca ho fatto una query con wpdb avevano aggiunto un account admin nella tabella wp_users... Ho cancellato quell'admin ma c'era comunque codice shell nel file system, in realtà era un file .jpg che era un eseguibile... L'hosting ha detto che era finita...

Per trovare la webshell esegui questa query con find: find /var/www -name '*.php' -newermt '3 months ago' | xargs file | grep 'PHP script'. Filtra le richieste POST nei log di accesso, soprattutto sugli endpoint di upload file. Puoi usare WPScan per la scansione delle vulnerabilità, ma isolare la rete è fondamentale. Controlla gli URL siteurl e home nella tabella wp_options del database, potrebbero essere stati modificati.

Wow situazione brutta. Comunque sembri molto nel panico. La prima cosa da fare è davvero fare un backup poi disabilita plugin e temi uno per uno. Entra in WP admin, controlla gli utenti. Potrebbero aver creato un nuovo account admin. Poi installa un plugin di sicurezza e aggiorna WP. Se dopo un po' hai di nuovo problemi, allora contatta l'hosting.

Pensala come una revisione di cybersecurity: 1) Blocca il traffico di rete, 2) Fai uno snapshot del sistema, 3) Trova le vulnerabilità (web shell, utente db, cron job), 4) Identifica il vettore di attacco (quale plugin, quale account, quando), 5) Cancellazione e ripristino. Su WordPress di solito succede per mancanza di aggiornamenti dei plugin o password deboli. La settimana scorsa abbiamo avuto una situazione simile su un sito, la password del database in wp-config.php era hardcoded, phpmyadmin era aperto...

Mi sembra strano, l'hosting ti avvisa subito se c'è codice malevolo? L'hanno rilevato sui loro sistemi. Se riesci ancora ad accedere via SSH, significa che hai ancora accesso... Sei riuscito a entrare anche nel database? Quindi l'exploit è ancora attivo o hanno solo dimenticato la shell? Quando hai fatto l'ultimo backup? Se vuoi ripristinare, puoi farlo da un backup vecchio?

oh no, hackeraggio di wordpress..... è una cosa brutta... ma semplifica: torna all'ultimo backup e ripristina mysql e i file. poi aggiorna tutto wp. così viene pulito bene. fai controllare anche all'hosting dai.

Grazie mille, era la risposta che cercavo. Gli ambienti di test dimenticati diventano spesso un punto d'accesso più frequente del sistema live.

Correggetemi se sbaglio.

Lascio un avvertimento. Da noi la cosa che faceva perdere più tempo era non sapere chi decidesse.

Se ricevete tre risposte diverse su un argomento, la domanda è posta male. Buon lavoro.

Salvato.

Mi sono rilassato leggendo questa risposta quindi non succede solo a me. Nessun processo migliora senza tracciamento perché non sai cosa correggere.

È tutto, scusate se mi sono dilungato.

Ha ragione. Se il percorso di notifica è lungo, la notifica non arriva; una notifica mancante significa un evento scoperto tardi.

Io seguirei questa strada.

La risposta sopra ha colto l'essenza della questione. Cercare di farlo da soli è la strada più costosa.

Naturalmente cambia se la vostra situazione è diversa.

Il mio dubbio è stato chiarito, grazie.

Non lo sapevo.

Esatto, e non è nemmeno così noto. Se rimproverate i falsi allarmi, nessuno segnalerà più nulla.

Avete ragione, sono passato anch'io per la stessa strada. Se la verifica in due passaggi è attiva, una password rubata da sola non serve a nulla.

Se avete domande, scrivete, rispondo per quanto possibile.

Non ho alcuna esperienza in materia di virus sul mio server, quindi chiedo. Le modifiche ai dati di pagamento non vanno mai verificate tramite il canale di provenienza.

Sono curioso di sapere se qualcuno lo fa in modo diverso.

Ha ragione. Le persone difendono le abitudini, non i processi. La resistenza nasce da lì.

Se scrivete qui il risultato, sarà utile anche ad altri.