La password admin del pannello di controllo dell'hosting è finita nelle mani di qualcun altro, devo cambiarla subito ma non riesco a fare login

mi è successo anche a me l'altro giorno, l'hacker aveva cambiato la password del pannello. sono andato su cPanel, ho cliccato su "invia email di recupero" e sono passato oltre, è arrivata dopo 30 minuti. ma tu chiiama per telefono, prova più volte con la chat di supporto...

Se hai accesso root via SSH, puoi cambiare la password utente MySQL con l'hash della password: UPDATE mysql.user SET Password=PASSWORD('newpass') WHERE User='root'; FLUSH PRIVILEGES;. Altrimenti puoi eseguire lo script WHM API o di gestione password su cPanel. Ma se l'hacker ha già raggiunto il root, significa che il server è completamente compromesso. Controlla i log, bind.log, secure log ecc.

in questi casi l'hosting provider si muove davvero molto lentamente. però se riesci ad accedere via SSH stai un po' più tranquillo. puoi cambiare la password root. oppure fai sudo su e scrivi passwd root. ma se hanno raggiunto l'intero server significa che c'è anche malware — formatta tutto e reinstalla, così finisci.

Hai accesso SSH? Se hai accesso root: ssh root@[IP], passwd [invio], inserisci nuova password, conferma. Se hai solo accesso utente: sudo su, passwd, nuova password. Il pannello dell'hosting provider è già una cosa secondaria, ciò che conta è l'accesso al server. Se non hai alcun accesso SSH potresti dover contattare l'hosting provider per telefono. Si consiglia di controllare i log: /var/log/auth.log, /var/log/secure (sistemi Red Hat), lì c'è scritto chi ha effettuato l'accesso.

Parli un po' troppo in fretta amico solo perché la password del pannello admin è cambiata significa che tutto il server è stato compromesso? O è solo la password di cPanel? Se riesci ancora ad accedere via SSH, significa che è ancora tuo. Primo step: entra in SSH, entra in bash, diventa root. Poi vediamo...

Come avete risolto questo? Il tempo che impiegate a rilevare un problema ne determina direttamente il costo.

Se la verifica in due passaggi è attiva una password rubata da sola non serve a nulla... Sono curioso di sapere se qualcuno lo fa in modo diverso.

non lo sapevo.

Questo thread è archiviato.

Sono una piccola impresa, vi parlo dal mio punto di vista. Se rimproverate i falsi allarmi, nessuno segnalerà più nulla.

guardando al processo, il quadro cambia. i primi tre mesi vanno bene i probleim emergono al quarto mese.

è tutto scusate se mi sono dilungato.

vi spiego come si fa in pratica. avere il backup accessibile sulla stessa rete e con le stesse credenziali lo rende parte del bersaglio.

Parlo dal lato opposto, io sono dalla parte dei fornitori. Ogni punto non scritto è un punto che in futuro le due parti ricorderanno diversamente.

La maggior parte degli incidenti non inizia da una vulnerabilità, ma da una password trapelata. Naturalmente cambia se la vostra situazione è diversa.

Ho vissuto la stessa cosa due anni fa. Quando prendete una decisione, scrivete anche lo scenario peggiore, non solo quello migliore.

Salvato.

C'è una trappola qui, non posso non segnalarla. Se rimproverate i falsi allarmi, nessuno segnalerà più nulla.

Lascio una nota, potrebbe servire.

Sono emerse tre opinioni diverse, si completano a vicenda. Avere il backup accessibile sulla stessa rete e con le stesse credenziali lo rende parte del bersaglio.

Se il percorso di notifica è lungo la notifica non arriva; una notifica mancante significa un evento scoperto tardi. Questa è la mia opinione, non la scrivo come verità assoluta.

La discussione si è dispersa, la riassumo. Gli ambienti di test dimenticati diventano spesso un punto d'accesso più frequente del sistema live.

Ho lavorato a lungo su questo. Le modifiche ai dati di pagamento non vanno mai verificate tramite il canale di provenienza.

Se il percorso di notifica è lungo, la notifica non arriva; una notifica mancante significa un evento scoperto tardi. Lascio una nota, potrebbe servire.