Комментарии 72
Удалось ли собрать информацию о том как ботнет попал на сервер?
К сожалению, нет. Все логи оказались затертыми, .bash_history пустой, но, с большой вероятностью, просто сбрутили пароль рута. Был установлен очень слабый пароль.
Да, основной способ распространения — подбор паролей доступа по ssh.
Причем пароль был не просто очень слабый, а вероятно — словарный.
Причем пароль был не просто очень слабый, а вероятно — словарный.
На многих системах удалённый вход root'ом по ssh закрыт (PermitRootLogin no) как раз от таких поползновений. Думаю, есть смысл включить такой блок если он не был включен с самого начала.
Если критичен root'овский шел, то можно выделить пользователя, который может переключаться на root через «su -» или просто пользоваться sudo.
Если критичен root'овский шел, то можно выделить пользователя, который может переключаться на root через «su -» или просто пользоваться sudo.
Уже пароль сменили, fail2ban поставили, сертификаты сделали.
На моем сервере логин от имени рута разрешен потому, что иногда приходится либо пробрасывать привилегированные порты через ssh, либо строить ssh-vpn (который через -w). Вроде можно как-то это разрешить и не от рута, но я заморачиваться не стал.
На моем сервере логин от имени рута разрешен потому, что иногда приходится либо пробрасывать привилегированные порты через ssh, либо строить ssh-vpn (который через -w). Вроде можно как-то это разрешить и не от рута, но я заморачиваться не стал.
А я слишком noob чтобы было как то по другому… Теперь то действительно сертификаты и подумываю через Yubico сделать авторизацию.
s/no/without-password/
Каждый сам решает для себя, но я считаю что root'у незачем иметь возможность напрямую заходить удалённо. Только через su или даже лучше sudo.
Пока у вас полтора хоста — да. Когда их тысячи — нет. Поэтому сразу нужно привыкать к хорошему.
Надо не «привыкать», а строить систему под конкретные цели. Универсальных решений нет.
И под тысячи хостов можно сделать автоматический вход root'а без открытия его снаружи если задаваться такой целью. Всё зависит от целей и уровня принимаемого риска и паранои.
И под тысячи хостов можно сделать автоматический вход root'а без открытия его снаружи если задаваться такой целью. Всё зависит от целей и уровня принимаемого риска и паранои.
Вопрос чайника: а в чём проблема командой при входе прописать «sudo bash»?
Теоретически вы тогда тоже root, но при этом юзаете свой пароль и например свой же RSA ключ на ssh. Если их уведут (изменят и т.д.) — остается возможность зайти под «реальным» root и поправить ситуацию. А так уровень ущерба в случае чего хоть root-м, хоть sodoer-ом — одинаков.
PS. «sudo -s» звучит чуть более кошерно…
PS. «sudo -s» звучит чуть более кошерно…
При чем тут универсальные решения? КОгда есть решение А, которое ничем не отличается от B, но при этом масштабируется, то выбор очевиден. Даже для админов локалхоста, которые «строят под конкретные цели».
Какие логи проверялись? Уверены, что все? линукс много куда пришет при логине
Что у него со временем модификации? Могли обнулить. Хотя, и дату отмотать тоже. Но если обнуляли неграмотно (удаление файла и создание нового пустого) — можно попробовать восстановить
.bash_history пустой
Что у него со временем модификации? Могли обнулить. Хотя, и дату отмотать тоже. Но если обнуляли неграмотно (удаление файла и создание нового пустого) — можно попробовать восстановить
Посмотрите cron-скрипт.
Спасибо, скрипт глянул. В связи с чем возникли мысли:
1. Последовательность работы с .bash_history согласно файлу cron:
Т.о. файл сначала удаляется, потом создаётся новый с таким же именем и уж после этого затирается. Значит, чисто теоретически первоначально существовавший до работы cron .bash_history можно восстановить
2. auth.log — затирается
а вот auth.log.1- не затриается. там может быть что-то полезное, хоть и не особо свежее
3. нет удаления syslog.log, в котором можно найти информацию, например, о том как давно зловредный cron скрипт выполнялся
1. Последовательность работы с .bash_history согласно файлу cron:
*/1 * * * * rm -rf /root/.bash_history
*/1 * * * * touch /root/.bash_history
*/1 * * * * history -r
*/1 * * * * cd /root > .bash_history
Т.о. файл сначала удаляется, потом создаётся новый с таким же именем и уж после этого затирается. Значит, чисто теоретически первоначально существовавший до работы cron .bash_history можно восстановить
2. auth.log — затирается
*/1 * * * * cd /var/log > auth.log
а вот auth.log.1- не затриается. там может быть что-то полезное, хоть и не особо свежее
3. нет удаления syslog.log, в котором можно найти информацию, например, о том как давно зловредный cron скрипт выполнялся
Загляните в crontab. который скрыт в одном из спойлеров в статье. Там видно, как эти логи перезатираются, и какие именно.
Был такой же сервер, с теми же файлами, пароль рута подобран перебором, управление происходило с китайских адресов. При анализе бинарников единственное что удалось понять, что ботнет используется для ddos атак
феерично! :)
Чем, простите, декодируются?
В моем случае, это были 121.12.110.96:10991, которые элементарно декодируются:
Чем, простите, декодируются?
Увлекательно!
И спасибо за rpm -Va
И спасибо за rpm -Va
Этого вовсе недостаточно, если стоит руткит правильно, то rpm -Va вам ничего не покажет(md5sum может показывать md5 оригинального файла, а по факту файл будет несколько другим), эту команду нужно выполнять, загрузившись с repair диска, на котором все системные утилиты заведо не скомпроментированы и не подгружено левых модулей ядра. К слову об этом довольно интересно и подробно рассказывают на курсах RHCE.
Безусловно, руткит может все перехватывать как в юзер-ленде (если это LD_PRELOAD руткит), так и в ядре (если модуль), но согласитесь, в моем случае процессы и открытые соединения не скрывались, так что я не безосновательно полагаю, что руткита нет.
При том, что он подгружал модуль ядра?
Да. Модуль ядра отсутствовал.
Его с файловой системы можно и удалить после загрузки, например. Или скрыть, если это модуль руткита.
Вы правы, но сервер перезагружали после чистки, так что особо нет оснований полагать, что если он был, он мог как-то остаться.
Перезагрузка сервера ничего не гарантирует. Руткиту достаточно скрывать свой модуль на файловой системе и пересобрать initramfs, добавив себя в качестве модуля, загружаемого по умолчанию. Без проверки из нескомпроментированного окружения (rescue livecd) убедиться в отсутствии руткита невозможно.
Любой безопасник скажет, что в случае компрометации root'a систему нужно переустановить, потому что нет ни одного способа наверняка убедиться, что она действительно чистая.
Конечно, можно понадеяться на авось и что раз всё так незамаскировано, то значит больше ничего не осталось. Мы же не будем предполагать, что на это и был расчёт (:
Конечно, можно понадеяться на авось и что раз всё так незамаскировано, то значит больше ничего не осталось. Мы же не будем предполагать, что на это и был расчёт (:
Безусловно. Первое, о чем я подумал и предложил lfatal1ty — переустановка системы.
Для меня просто это очень большая проблема если честно. Само собой факт того что это НУЖНО сделать я понимаю, однако проявляла себя зараза открыто, и в случае повторения выявить будет легко, тогда и снесу систему.
А если файлы подменялись вместе с пакетом, их содержащим, то и загрузка с диска не поможет и rpm -Va не найдет проблем.
достаточно выполнить: «rpm -Va»Для
# apt-get install debsums
debsums --silent
«Хмм, ладно», подумал я. Полез в root'овский crontab:
==============
Ох. Размером он был 183КБ, 4036 строчек.
1. crontab -l | grep -v "^#"
2. Profit!
crontab -l | grep -vE "^#|^$" тогда уж, но похоже там без комментов хватало строк
Спасибо! Именно этим и ценно любое сообщество ;-)
Там в командах не было решеток, поэтому сработало даже просто:
grep -v '#" /var/spool/cron/root
grep -v '#" /var/spool/cron/root
Ну могло и не сработать) Поэтому вариант выше самый корректный.
Раз уж зашла речь о различных вариациях, то я добавлю свою, может кому и пригодится:
crontab -l | grep "^[^#]"
crontab -l | grep "^[^#]"
НЛО прилетело и опубликовало эту надпись здесь
Ну вот, у линуксоидов всегда Билл Гейтс виноват :)
А если серьезно, то интересная статья. Кстати, "домашний роутер [...] грузит канал под гигабит" — роскошно живете.
А если серьезно, то интересная статья. Кстати, "домашний роутер [...] грузит канал под гигабит" — роскошно живете.
Это означает, что никакие системные файлы не были изменены. Т.к. процессы в системе не были скрыты, я предположил, что никаких руткитов здесь не использовалось и можно с некоторой уверенностью сказать, что система чистаКстати, проверте права и владения (owner) в системных папках, ну и конфиги nginx (апача, пхп и т.д.) — я видел уже такие зараженые сервера, где www-data хитрым китайцем был разрешен write-доступ к некоторым папкам в /etc, дальше upload через веб-морду, дальше думаю понятно — через некоторое время систему снова приходилось «лечить».
Причем как туда изначально залезли выяснил случайно (китаец хоть и потер логи, но в бэкапе на другом сервере все осталось). Каким-то образом был слит пароль и ключ от ssh для пользователя, который был sudoer. Самое интересное, что ssh открывался только по стуку, который видимо тоже слили — т.ч. появились мысли, что сперва заразили виндовую машину-клиент, а потом только сервер. Юзер потом признался, что переустановил винду, т.к. работать на ней стало просто невозможно (вероятно upstream забивался логгерами полностью).
У меня как-то был случай: уехал я на два дня из дому, а роутер с DD-WRT оставил включенным. Приезжаю, лезу в админку, а там в разделе про использование сети написано, что роутер за двое суток наотдавал под 900 ГБ.
DD-WRT была последняя, пароли достаточно сложные, с цифрами и спецсимволами.
Самое интересное, что я зашел в личный кабинет у провайдера, а там этих 900 ГБ не было.
Вот до сих пор для меня загадка, что это было.
DD-WRT была последняя, пароли достаточно сложные, с цифрами и спецсимволами.
Самое интересное, что я зашел в личный кабинет у провайдера, а там этих 900 ГБ не было.
Вот до сих пор для меня загадка, что это было.
Это была локалка, думается. Возможно, кто-то чего-то брутфорсил во внутренней сети. Тера за два дня — это что-то под 5MB/сек. Весело оно порезвилось.
А у меня 1.2 «Тера» за 5 часов наулетало…
Это в обе стороны (up/down)? И чем оно так, интересно?
Просто, делал тут как-то не так давно нагрузочный тест на гигабитном канале, один на один, multithreaded, причем неслабое железо. Так вот, upstream быстрее 300-350 МБит/сек никак не поднимался (причем downstream пакет был в два-три раза короче).
А у вас 530МБит/сек…
Просто, делал тут как-то не так давно нагрузочный тест на гигабитном канале, один на один, multithreaded, причем неслабое железо. Так вот, upstream быстрее 300-350 МБит/сек никак не поднимался (причем downstream пакет был в два-три раза короче).
А у вас 530МБит/сек…
это только up. Оно вообще не качало…
Нууу, у меня тариф 250Мбит… Я перед тем как со 100 на него переходить попросил админов провайдера поднять iperf дабы скорость тупо до провайдера померять. Показывало 980-990Мбит как бы.
Нууу, у меня тариф 250Мбит… Я перед тем как со 100 на него переходить попросил админов провайдера поднять iperf дабы скорость тупо до провайдера померять. Показывало 980-990Мбит как бы.
> 300-350 Мбитс
Близко к производительности винта. Тест точно был независим от диска?
Близко к производительности винта. Тест точно был независим от диска?
Навело на мысль, что, возможно, это какие-то локальные сокеты через loopback?
Если я правильно понял, здесь необходим некоторый «ликбез»:
- Не считая наличия своего «дескриптора» в файловой системе, unix (local) сокеты не завязаны на диск.
- loopback работает только для локальных нужд и не позволяет что-то выставить наружу, по сути — позволяет сделать из обычных сетевых сокетов альтернативу unix сокетам.
И еще кто-то говорит, что жанр детектива умирает.
И после этого нам надо продолжать верить, что «под линукс вирусов не бывает»? :)
Если кому-то интересно, я сделал трекер БиллГейтса
github.com/ValdikSS/billgates-botnet-tracker
А еще нашел обновленную версию, там добавилось 2 модуля и немного изменился процесс заражения.
И еще, оказывается, это кросс-платформенный ботнет. Windows-версия тоже имеется.
github.com/ValdikSS/billgates-botnet-tracker
А еще нашел обновленную версию, там добавилось 2 модуля и немного изменился процесс заражения.
И еще, оказывается, это кросс-платформенный ботнет. Windows-версия тоже имеется.
А мне вот всегда было интересно
Почему практически все вирусы называются типа dhsjask.exe или klsdkcxt.exe + грузят CPU на все 100%.
Если назвать его скажем системной библиотекой и элементарно поставить sleep в цикле, на машине он прожил бы намного дольше.
Почему практически все вирусы называются типа dhsjask.exe или klsdkcxt.exe + грузят CPU на все 100%.
Если назвать его скажем системной библиотекой и элементарно поставить sleep в цикле, на машине он прожил бы намного дольше.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Исследуем Linux Botnet «BillGates»