Эта статья приняла участие в "Проект «Звезда раскопок»”, чтобы выиграть творческий подарочный пакет и бросить вызов творческим поощрительным деньгам.
Некоторое время назад компания Tencent Cloud занималась деятельностью, на C я купил легкий сервер и развернул свой собственный сайт.
Все работает гладко.
Пока однажды утром я, как всегда, не открыл свой веб-сайт и не обнаружил, что веб-сайт не может быть открыт.
Поэтому я провел серию исследований.
1. Проверьте журнал
Первое, что приходит в голову, это зайти на сервер и посмотреть логи нештатных логинов.
Молодец, я обнаружил, что сервер не может войти!
1) сервер входа VNC
Первая мысль должна бытьпароль логинвыключен.
Поэтому я использовал VNC для входа в фоновом режиме Tencent Cloud.
Если вы не можете войти удаленно через клиентский SSH, вы можете войти на сервер через вход VNC.
2) Просмотрите файл sshd_config
просмотрено/etc/ssh/sshd_configПосле прочтения файла было обнаружено, что он был изменен:
PasswordAuthentication no # указывает, что вход с паролем запрещен
Вход по паролю отключен, необходимо войти в систему с помощью используемого закрытого ключа.
Сначала измените на yes, затем перезапустите sshd
systemctl restart sshd
3) Повторно войти через терминал
После модификации используйте инструмент терминала, чтобы снова войти в систему локально, потому что инструмент входа в систему VNC слишком сложен в использовании.
Обнаружено, что можно войти.
Проверятьauthorized_keysдокумент
vi /root/.ssh/authorized_keys
Молодец, не говори о коде!
Добавил пару ключей на свой сервер:
4) Просмотр журнала входа
- Используйте команды last и history для просмотра журнала входа в систему и журнала операций.
last #Просмотреть все зарегистрированные ips
history #Просмотреть запись команды операции
Неудивительно, что ненормального IP-адреса нет.Если он действительно вошел в систему, вероятность удаления журнала входа в систему также очень высока.
- Проверьте это еще раз с помощью команды lastb:
lastb # используется для вывода информации о пользователях, которым не удалось войти в систему
Рисунок 1
Рисунок II
lastbИнтерпретация результатов:
第一列：用户名
第二列：终端位置
第三列：登录ip或者内核
第四列：开始时间
第五列：结束时间（still login in 还未退出 down 直到正常关机 crash 直到强制关机）
第六列：持续时间
Приведенные выше результаты показывают, что серверНасильственная вброс учетных данных.
IP должен передаваться через прокси.На второй картинке собеседник напрямую использует root в качестве имени пользователя, чтобы постоянно втыкаться в базу данных.Похоже, он нашел правильное имя пользователя.Наконец-то он действительно залогинился и изменил мою пару ключей .
Проверьте IP:
IP-адрес из-за границы, трудно найти местоположение, и это также может быть IP-адрес прокси.
2. Найдите троянский файл
1) Используйте верхнюю команду, чтобы посмотреть
нормальныйtopКоманда вообще не может отобразить троянский процесс, вроде нормально, т.к.topКоманда, скорее всего, была изменена злоумышленником:
Обычная высшая команда
2) команда BusyBox
бегать
busybox topВы можете увидеть скрытые процессы, потребляющие процессор, оригинальныеtopОн был изменен и не может отображать процесс вируса, он должен быть вbusyboxвыполнить в
Загрузите инструмент устранения неполадок, предоставленный Tencent Cloud.busybox,
[root@VM-8-8-centos ~]# wget https://tao-1257166515.cos.ap-chengdu.myqcloud.com/busybox
--2020-12-14 15:12:59-- https://tao-1257166515.cos.ap-chengdu.myqcloud.com/busybox
Resolving tao-1257166515.cos.ap-chengdu.myqcloud.com (tao-1257166515.cos.ap-chengdu.myqcloud.com)... 132.232.176.6, 132.232.176.7, 139.155.60.205, ...
Connecting to tao-1257166515.cos.ap-chengdu.myqcloud.com (tao-1257166515.cos.ap-chengdu.myqcloud.com)|132.232.176.6|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1001112 (978K) [application/octet-stream]
Saving to: ‘busybox.1’
100%[======================================>] 1,001,112 1.36MB/s in 0.7s
[root@VM-8-8-centos ~]# cp busybox /usr/bin/
[root@VM-8-8-centos ~]# busybox top
-bash: /usr/bin/busybox: Permission denied
[root@VM-8-8-centos ~]# cd /usr/bin/
[root@VM-8-8-centos bin]# chmod 777 /usr/bin/busybox
[root@VM-8-8-centos ~]# busybox top
Пойманный троянский файл:
верхняя команда busybox
Из приведенного выше видно, что загрузка ЦП достигла почти 100%, и майнинг не вызывает сомнений.
Наконец, после долгого изучения технологии Tencent Cloud, я нашел следующие троянские файлы и каталоги:
/tmp/.X25-unix/.rsync/c/tsm64
/tmp/.X25-unix/.rsync/c/tsm32
/tmp/.X25-unix/.rsync/a/kswapd0
/usr/bin/systemd-network
/usr/bin/kswaped
Наконец, заблокируйте имя этого процесса майнинга.pamdicks, затем убейте троянский процесс, а затем удалите троянский файл, все должно быть в порядке.
Если вы не введете полное имя,ls、ll、lsattrКоманда просмотра файлов вообще не будет отображать этот троянский файл:
Файл троянца не может быть отображен, требуется полное имя
Перед удалением посмотрим, что из себя представляет процесс майнинга:
ls -lh /proc/5445/fd
top -H -p 5445
Этот процесс pamdicks имеет 6 дочерних потоков:
В итоге проследили до бинарного файла, который задел за рамки знаний и его нельзя было открыть, так что просто удалите его.
3. Удалить троянские файлы
1) Изменить авторизованные_ключи
первыйauthorized_keysОткрытый ключ файла удаляется. когда я выполняюrmкоманду, злоумышленник взял мойauthorized_keysфайл добавлен+iблокировка, удаление не разрешено, так что грустно:
chattr +i /etc/authorized_keys
Указывает, что файл нельзя удалить, изменить или переместить.
На самом деле не говорите о коде, поставьте мой серверchattrКоманда также была удалена,Сервер взломан, удалитеchattrКоманды являются обычными операциями.
Я действительно не могу найти команду chattr:
только вручнуюchattrположить его обратно,centosПроцесс установки:
yum install e2fsprogs
Успешная установка:
[root@VM-8-8-centos run]# which chattr
/usr/bin/chattr
пустойauthorized_keysдокумент:
[root@VM-8-8-centos .ssh]# chattr -i authorized_keys
[root@VM-8-8-centos .ssh]# echo > authorized_keys
[root@VM-8-8-centos .ssh]# cat authorized_keys
2) Выполните команду rm, чтобы удалить троянский файл.
Убейте и удалите найденные троянские файлы:
[root@VM-8-8-centos .ssh]# kill -9 5445
[root@VM-8-8-centos .ssh]# chattr -i /usr/bin/pamdicks
[root@VM-8-8-centos .ssh]# rm /usr/bin/pamdicks
rm: remove regular file ‘/usr/bin/pamdicks’? y
[root@VM-8-8-centos .ssh]# rm /tmp/.X25-unix/.rsync/c/lib/64/tsm
rm: remove regular file ‘/tmp/.X25-unix/.rsync/c/lib/64/tsm’? y
После его удаления загрузка ЦП упала:
После очистки троянского файла, наконец, отключите вход с паролем на сервер и вместо этого используйте сгенерированную пару ключей для входа.
Сделайте паузу.
4. Найдите источник атаки — Redis
Через несколько дней, когда я открыл Redis, я обнаружил, что в Redis есть странные значения ключей.
Раньше не замечал этой проблемы.
Редис взломан
Беспечный! Redis имеет открытый порт и пароль не установлен.
Хотя я не понимаю, как эта цепочка вещей внедряется в мой сервер. но этоcrackitКлючи странные.
В сети была найдена следующая информация:
Уязвимость Redis Crackit:
Хакер получает удаленный доступ к службе Redis, очищает базу данных Redis и записывает свой собственный открытый ключ входа в систему ssh, а затем создает резервную копию базы данных Redis как /root/.ssh/autotrized_keys.
Это успешно записывает ваш собственный открытый ключ в autotrized_keys ssh и напрямую входит на взломанный хост как root без пароля.
То есть очень вероятно, что мой сервер не был залогинен с помощью перебора учетных данных, а был атакован с использованием Redis в качестве точки входа.
Используйте верхнюю команду, чтобы посмотреть, я иду! Троянский файл снова наверху, похоже, значение ключа этого Redis не подчищено, и троянский файл будет продолжать загружаться и выполняться:
kswapd0 замаскированный троян
Этот kswapd0 несколько знаком.
Высокий уровень использования kswapd0 связан с нехваткой физической памяти.Операции раздела подкачки и подкачки памяти используются для обмена данными, что приводит к высокой загрузке ЦП.
но,этоkswapd0Это трюк, но за ним стоит команда запуска троянского файла/tmp/.x25-unix/.rsynckswapd0
Таким образом, этот Redis не был разрешен, и злоумышленник продолжит использовать вашу уязвимость Redis для вторжения на ваш сервер в следующий раз.
В прямом смыслеkswapd0Процесс выглядит следующим образом:
Это нормальный kswapd0
Чтобы воспроизвести этот процесс, я выполнил команду для значения Redis:
[root@VM-8-8-centos ~]# ping d.powerofwish.com
PING d.powerofwish.com (193.160.32.164) 56(84) bytes of data.
скачать этоpm.shскрипт, откройте этот скрипт:
Вы можете видеть, что этот сценарий sh загружает png-файл и предоставляет права на выполнение.
Я также напрямую загрузил файл png, дал разрешение и выполнил,./png
Увидите, что есть замаскированный bin-скрипт, сначала удалите его, а потом пропишите в/usr/binсодержание.
Затем продолжайте чистить~ В течение периодаchattrкоманда удалена,authorized_keysфайл был изменен
Наконец, это должно быть выполнено/usr/bin/kswapedЭтот скрипт запускает майнинг.
Затем используйте top, чтобы проверить процессор, и он мгновенно взлетает почти до 100%.
Взгляните на упаковку:
tcpdump -i eth0 '((not port 45695) and (not host 127.0.0.1) and (not host 183.60.83.19))'
нашел это104.27.129.57Один из них — узел CDN в США, следуйте по пути и экспортируйте захваченный пакет в WirteShark, чтобы увидеть:
Красная часть — это исходный IP-адрес и операция другой стороны, запрашивающая базу данных (порт 3306).
Также возможно, что мой сервер является просто узлом DDoS-атаки. Поэтому для обеспечения безопасности сети необходимо своевременно бороться с троянскими файлами.
Распределенная атака типа «отказ в обслуживании» (англ. Distributed Denial of Service, сокращенно DDoS) относится к тому, что несколько злоумышленников в разных местах запускают атаки на одну или несколько целей одновременно, или один злоумышленник контролирует несколько машин, расположенных в разных местах. эти машины, чтобы атаковать жертву одновременно. Поскольку источник атаки распределен в разных местах, этот тип атаки называется распределенной атакой типа «отказ в обслуживании», и злоумышленников может быть несколько.
Схематическая диаграмма DDoS-атаки
5. Профилактика
Основная причина атаки на сервер заключается в том, что слишком много открытых сетевых портов, особенно Redis6789, MySQL3306, а пароль сервера слишком прост.
Меры предосторожности:
1) Сервер
путем изменения/etc/ssh/sshd_configдокумент
-
Отключить вход по паролю, разрешить вход только по паре ключей
-
Измените порт ssh по умолчанию, чтобы предотвратить взлом учетных данных путем грубой силы.
-
Отключить прямой вход в учетную запись root, открыть доступ по определенному IP-адресу
как:
#只允许用户、IP访问
AllowUsers aliyun test@192.168.1.1,root@192.168.*
# 拒绝 zhangsan、aliyun 帐户通过 SSH 登录系统
DenyUsers zhangsan aliyun
#使用秘钥登录
AuthorizedKeysFile .ssh/authorized_keys
PubkeyAuthentication yes
RSAAuthentication yes
#禁用密码登录
PasswordAuthentication no
2) Применение
-
Redis разрешает только локальный доступ, измените порт по умолчанию, не раскрывайте все IP-адреса, Redis по умолчанию
bind 127.0.0.1по причине -
MySQL открывает доступ только к необходимым IP-адресам
-
Установить правила доступа брандмауэра для портов
Если вы хотите быть в большей безопасности, вы можете использовать машину-трамплин и машину-бастион для доступа.
3) Резервное копирование
Регулярно создавайте резервные копии данных и регулярно создавайте резервные копии моментальных снимков.