GNU/Linux >> Linux Esercitazione >  >> Linux

Strano SSH, sicurezza del server, potrei essere stato violato

Soluzione 1:

La firma ClamAV per Unix.Trojan.Mirai-5607459-1 è decisamente troppo ampia, quindi è probabile che sia un falso positivo, come notato da J Rock e cayleaf.

Ad esempio, qualsiasi file con tutte le seguenti proprietà corrisponderà alla firma:

  • è un file ELF;
  • contiene la stringa "watchdog" esattamente due volte;
  • contiene la stringa "/proc/self" almeno una volta;
  • contiene la stringa "busybox" almeno una volta.

(L'intera firma è un po' più complicata, ma le condizioni di cui sopra sono sufficienti per una corrispondenza.)

Ad esempio, puoi creare un file di questo tipo con:

$ echo 'main() {printf("watchdog watchdog /proc/self busybox");}' > innocent.c
$ gcc -o innocent innocent.c
$ clamscan --no-summary innocent
innocent: Unix.Trojan.Mirai-5607459-1 FOUND

Qualsiasi build busybox (su Linux) di solito corrisponde alle quattro proprietà che ho elencato sopra. È ovviamente un file ELF e conterrà sicuramente la stringa "busybox" molte volte. Esegue "/proc/self/exe" per eseguire determinate applet. Infine, "watchdog" ricorre due volte:una volta come nome dell'applet e una volta all'interno della stringa "/var/run/watchdog.pid".

Soluzione 2:

Come J Rock, penso che questo sia un falso positivo. Ho avuto la stessa esperienza.

Ho ricevuto un allarme da 6 server diversi, disparati e geograficamente separati in un breve lasso di tempo. 4 di questi server esistevano solo su una rete privata. L'unica cosa che avevano in comune era un recente aggiornamento di daily.cld.

Quindi, dopo aver verificato senza successo alcune delle tipiche euristiche di questo trojan, ho avviato una scatola vagabonda con la mia nota linea di base pulita e ho eseguito freshclam. Questo ha afferrato

"daily.cld è aggiornato (versione:22950, ​​sigs:1465879, f-level:63,builder:neo)"

Un successivo clamav /bin/busybox ha restituito lo stesso avviso "/bin/busybox Unix.Trojan.Mirai-5607459-1 FOUND" sui server originali.

Infine, per buona misura, ho anche realizzato una scatola vagabonda dalla scatola ufficiale di Ubuntu e ho anche ottenuto lo stesso "/bin/busybox Unix.Trojan.Mirai-5607459-1 FOUND" (Nota, ho dovuto aumentare la memoria su questa scatola vagabonda dai suoi 512 MB predefiniti o clamscan fallito con 'killed')

Output completo dalla nuova scatola vagabonda di Ubuntu 14.04.5.

[email protected]:~# freshclam
ClamAV update process started at Fri Jan 27 03:28:30 2017
main.cvd is up to date (version: 57, sigs: 4218790, f-level: 60, builder: amishhammer)
daily.cvd is up to date (version: 22950, sigs: 1465879, f-level: 63, builder: neo)
bytecode.cvd is up to date (version: 290, sigs: 55, f-level: 63, builder: neo)
[email protected]:~# clamscan /bin/busybox
/bin/busybox: Unix.Trojan.Mirai-5607459-1 FOUND

----------- SCAN SUMMARY -----------
Known viruses: 5679215
Engine version: 0.99.2
Scanned directories: 0
Scanned files: 1
Infected files: 1
Data scanned: 1.84 MB
Data read: 1.83 MB (ratio 1.01:1)
Time: 7.556 sec (0 m 7 s)
[email protected]:~#

Quindi, credo anche che questo sia probabilmente un falso positivo.

Dirò, rkhunter non dammi il riferimento:"/usr/bin/lwp-request Warning", quindi forse PhysiOS Quantum ha più di un problema.

EDIT:ho appena notato che non ho mai detto esplicitamente che tutti questi server sono Ubuntu 14.04. Altre versioni possono variare?

Soluzione 3:

Questo è apparso oggi anche per me nella mia scansione ClamAV per /bin/busybox. Mi chiedo se il database aggiornato ha un errore.

Soluzione 4:

Ho provato ad accedere tramite SSH e non accettava la mia password. L'accesso root è disabilitato, quindi sono andato in soccorso e ho attivato l'accesso root e sono stato in grado di accedere come root. Come root, ho provato a cambiare la password dell'account interessato con la stessa password con cui avevo provato ad accedere in precedenza, passwd ha risposto con "password invariata". Ho quindi cambiato la password in qualcos'altro e sono riuscito ad accedere, quindi ho cambiato la password con quella originale e sono stato nuovamente in grado di accedere.

Sembra una password scaduta. L'impostazione della password (con successo) da parte di root reimposta l'orologio di scadenza della password. Potresti controlla /var/log/secure (o qualunque sia l'equivalente di Ubuntu) e scopri perché la tua password è stata rifiutata.


Linux
  1. Ssh:script di shell per l'accesso a un server Ssh?

  2. Come eseguire Ssh su un server utilizzando un altro server??

  3. Come reimpostare la password dell'amministratore di Plesk utilizzando SSH in Linux Server?

  4. Non è sicuro avere un utente ansible con sudo senza password?

  5. Nome utente e password nella riga di comando con sshfs

Best practice per la sicurezza di OpenSSH

Tunneling e proxy SSH

Server SSH

Come eseguire l'SSH sul server tramite Linux

Reimposta una password del server

Abilita l'accesso tramite password per SSH su Amazon Linux AMI