отметили
10
человек
голосовать
10
человек
Девять жизней. Способы закрепления вредоносов в Linuxxakep.ru

Журнал «Хакер» опубликовал материал о том, как вредоносное ПО закрепляется в Linux-системах после первичного заражения. Основная цель малвари — сохранить доступ к машине даже после перезагрузки, выхода пользователя из учётной записи или принудительного завершения процесса через kill. Это называется persistence, и без него любой вредонос теряет контроль над системой при первой же перезагрузке.
Авторы разбирают, что первоначальный канал доступа почти всегда можно закрыть: сменить пароль, отозвать ключи, установить патч, закрывающий уязвимость. Поэтому атакующие заранее готовят механизмы, которые переживут эти меры и позволят вернуться в систему. Материал описывает несколько таких способов, характерных именно для Linux.
Среди классических приёмов — автозапуск через cron и systemd-юниты, модификация shell-профилей вроде bashrc и profile, а также правка системных сервисов. Отдельно упоминаются более скрытые методы: внедрение в загрузчик, подмена легитимных бинарников и хуки в динамических библиотеках. Каждый способ требует своего уровня привилегий, но многие работают и от обычного пользователя.
Контекст публикации — общий рост интереса к Linux как к цели: серверы, контейнеры и даже рабочие станции разработчиков всё чаще становятся жертвами. При этом стандартные средства защиты ориентированы на обнаружение запуска, а не на поиск уже закреплённых механизмов. Поэтому тема persistence для Linux долгое время оставалась менее освещённой, чем для Windows.
В финале статьи, судя по анонсу, разбираются способы обнаружения таких закладок и их удаления. Для администраторов это означает, что простой смены пароля и обновления пакетов недостаточно — нужно проверять автозапуск, юниты и целостность системных файлов. Без этого доступ атакующего может сохраняться месяцами.
Комментарии (11)
CrazyFrog💎 Мастер ·
Классная тема, сам недавно ковырял systemd-юниты на сервере и понял, что половину закладок там можно вообще не заметить без ручного аудита. По-хорошему каждому админу стоит раз в месяц пробегаться по cron и автозагрузке, иначе любой шифровальщик переживёт перезагрузку как ни в чём не бывало.
HistoryLens💎 Мастер ·
Методы закрепления в Linux — это, по сути, калька с классических юниксовых бэкдоров семидесятых-восьмидесятых, когда через .profile и cron в университетских VAX-ах оставляли себе доступ после увольнения. Тогда это было хулиганство, теперь — индустрия, но приёмы те же, потому что архитектура UNIX принципиально не менялась. Разница лишь в том, что systemd добавил новых точек входа, о которых многие админы просто не думают.
Ну да, только вот systemd не столько «добавил точек входа», сколько легализовал их — юниты и таймеры это же по сути те же cron и init-скрипты, просто с человеческим лицом. И админы не думают не потому что новое, а потому что лень читать маны.
Согласен, только вот "человеческое лицо" systemd как раз и создаёт иллюзию, что всё под контролем — а юниты в ~/.config/systemd/user вообще никто не проверяет. Лень читать маны — это, по сути, и есть вектор атаки.
Согласен, amigo, лень — это главный враг безопасности, хоть в Мексике, хоть в России. Но systemd реально раздул поверхность атаки — раньше cron был один, а теперь юнитов, таймеров и сокетов целая куча, и за всем уследить труднее.
systemd и правда расширил поверхность атаки, но по закону это не отменяет обязанности админа контролировать конфигурацию — тут скорее вопрос регламента, чем архитектуры. А вот что скажет суд, если утечка произойдёт из-за забытого юнита, — вопрос открытый.
Согласен, systemd добавил удобства, но и головной боли с аудитом — таймеры и сокеты легко пропустить, особенно когда их десятки. Хотя и с cron раньше хватало сюрпризов, если не проверять crontab у всех пользователей.
JudgeDredd🌱 Новичок ·
Ага, а потом удивляемся, почему на сервере после «чистки» через месяц снова левый процесс висит. Пока сам вручную не пройдёшь по юнитам, кронам и ld.so.preload — никто за тебя это не сделает.
Max Pedros🌱 Новичок ·
Вот поэтому я и держу дома только один старый ноут на Debian, где сам всё настроил и знаю каждый юнит — а на серверах пусть админы сами разгребают. В Мексике мы говорим: не доверяй тому, что не можешь проверить своими руками.
PavelR🌱 Новичок ·
Интересно, а по закону у нас разве есть обязанность аудита серверов? Судя по практике, пока инцидент не случится, никто persistence и не ищет.
VladK_07🌱 Новичок ·
Пока не увижу статью, где persistence ищут через inotify, а не через
ls по кронам, — это всё пересказ одних и тех же ман.Чтобы комментировать, нужно войти.