Pull to refresh

Comments 105

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

Рут — это хорошо, но неимоверно сложно на более или менее современном дистрибутиве. Поэтому обычно никто за получение рута и не берется.
Рут — это хорошо, но неимоверно сложно на более или менее современном дистрибутиве. Поэтому обычно никто за получение рута и не берется.

вы теоретик?
представьте ситуацю: вам нужно получить доступ к /var/www/site1. вы смогли поулчить доступ к /var/www/site2, но права расставлены правильно и выйти дальше своего каталога не выйдет. как вы будите действовать без повышения привилегий? как будите подчищать логи за собой в /var/log?
Все зависит от квалификации злоумышленника и значимости ресурса. Все сервисы имею уязвимости, и в паблик попадает порядка 10% от того, что действительно обнаруживается.
Не совсем так. В паблик попадает 95%, просто когда попадает, оказывается, что им уже давно пользовались, кто знал :)
Во второй половине прошлого года публиковался эксплоит для ядра линукса, работал практически на всех последних ядрах и дистрибутивах- позволял получить локального рута.
Так что если вы просто смогли бы загрузить что-то на сервер и запустить — повышение привилегий дело 5 минут.
Минусующие — вы хоть обоснуйте в чем я не прав…
Тем более, то что описано выше действительно было.
Не минусовал, но видимо народу коммент не понравился тем, что он был в духе капитана очевидности. Эксплоиты периодически находятся и выпускаются и не только во второй половине прошлого года и не только в паблик :) И да, очевидно, что имея эксплоит, уязвимость и возможность его запустить — можно повысить привилегии.
Это как написать «В прошлом году человека сбила машина и он попал в больницу. Так что, если вас тоже собьет машина — вы можете попасть в больницу, а то и вообще умереть».
Не совсем согласен с духом КО, ибо я опровергаю фразу про «неимоверно сложно».
Да и не все следят за тем какие эксплоиты выходят в свет и какой урон могут нанести системам.
Пофиксили же сразу. А на тот же центос секьюрити патчи постоянно выходят для старых версий
позволял получить локального рута

А какие ещё «руты» бывают? :)
Имелось ввиду — получить рута локально, а не удаленно.
UFO just landed and posted this here
на любом «современном» дистрибутиве уже есть гора проверенных рабочих локальных рут-експлойтов: paste.pro/550014 (бубунта свежустановленная и чо то там сама обновившееся). так что заиметь рута на линуксе не составляет особых проблем. ну или как минимум на «среднестатистическом» сервере с линуксом.
Командой nmap лучше проверять все порты на открытость: nmap -P0 -p 1-65505 123.123.123.123
Я думал, что по tripware уже несколько лет, как справили поминки. Пациент жив?
В современных дистрибутивах присутствует его аналог — aide.
Во многих версиях logwatch есть противный баг, когда он внезапно не учитывает год. То есть присылает отчет о файлах, которые были изменены 1-2-3 года назад.
И просьба: объедините (поставьте рядом) сброс пароля рута и проверку лишних ключей ssh. Злоумышленник может даже не трогать рутовый пароль, чтобы не палиться, а просто влепить свой ключ и ходить через него. И смена пароля ничего не даст.
Да и некто вообще пассы рута не угоняет, сплойтом повышают привеллегии, делают грязные делишки, и заметают следы.
Вы забыли еще проверить cron. Можно запускать программы оттуда в назначенное время, например, когда злоумышленник пришел домой и поужинал.
OSSEC HIDS очень неплох для контроля за сервером
Нет там контроля, ossec отвечает только за наблюдение над целостностью и поведением системы. и клиент (защищаемый) и сервер должны быть обязательно разнесены географически. Иначе от взлома это спасет не сильно.
Например, OSSEC HIDS временно блокирует IP, которые активно пытаются достучаться до SSH или до дырок в PHP скриптах.

Это не панацея, но всяко лучше ручной проверки пост-фактум.

Если есть инструменты лучше (и такие-же простые в установке/настройке) — делитесь опытом.
зачем nmap если можно netstat -an | grep -i listen?
на взломаном хосте, нельзя верить системным утилитам
суть в том, что автор сначала использует nmap, потом netstat
Полностью с вами согласен. Всегда когда появляется подозрение на взлом сервера — оповещаю пользователей о тех перерыве в удобный для всех момент, гашу его, гружусь с надежного live-cd и уже оттуда проверяю систему, меняю пароли и т.д. Выглядит как паранойя, но сам был свидетелем подмены /bin/login и sshd (собирали пароли). Если есть подозрение — верить нельзя никому и ничему. Ни netstat, ни passwd, ни какому-либо сервису.
вот она, «прелесть» опенсорса…
UFO just landed and posted this here
К сожалению, нет. Сам бы хотел… Не потому что я ярый ненавистник опенсорса, а потому что закрытый продукт сложнее пропатчить и встроить в него какую-нибудь гадость :)
Полная ерунда. См. вирусы, заражающие исполняемые файлы. Например, недавний Sality.
Понедельник, утро… не подумал. Таки да, ваша правда. =(
Спасибо за статью! Открыл для себя Logwatch.
у меня например на freebsd не стоит lsof
Ваша боль близка мне как никому. Напишите статью «Как быстро проверить FreeBSD сервер на предмет взлома», с интересом почитаю чего ещё у вас там нет
Можно и по этой статье делать, только вместо netstat -anp делать sockstat | grep "*:*"
rkhunter можно поставить из портов: cd /usr/ports/security/rkhunter && make install clean
Кстати, как верно заметили ниже, шелл может быть настроен на ожидание соединения с определённых IP, так что лучше делать sockstat | grep ":\*"
Уж переписать утилиту make и важные порты, имея рута, не должно составлять труда :). Я думаю, что, как минимум, надо отключить сервер от сети и проверять жесткий диск, если уж реально хочется проверить систему на предмет взлома, не сломав при этом ничего.
Сомнительно, что этим будут заниматься. Но, в любом случае, можно банально взять чистый make «у соседа», а перед установкой порта сделать, например, portsnap fetch update. Если есть возможность на время проверки вывести сервер из сети, то можно и Frenzy попользовать для проверки. В общем, вариантов очень много на самом деле.
В таком случае надёжнее будет не portsnap, а по старинке: csup/cvsup. В таком случае контрольные суммы чекаются и враг точно не пройдёт.
cd /usr/ports/sysutils/lsof && make install clean
мне больше нравится
make -C /usr/ports/sysutils/lsof/ install clean

или
portinstall lsof
если есть предположение что сервер скомпрометирован то пароли лучше менять не через passwd который может уже быть с закладкой
а ручками менять хеш сразу в shadow

Для такого рода проверок есть rkhunter — открытые порты, изменения в системных файлах, md5 суммы и прочее.
Кстати, если ваша система скомпрометирована — чтобы на 100% быть уверенным что вы закрыли все открытые «двери» нужно ее целиком переставить. иначе никак.
а если вам поставили ядерный руткит — как его ловить?
И кстати, смена пароля на рута не всегда вас спасет, злоумышленник при взломе может поставить патченый sshd с мастерпаролем который будет пускать его с любым логином.

Про rkhunter извиняйте, не углядел в статье.
Чтобы не поставили ядерный руткит, нужно собирать ядро без поддержки модулей, а именно — отключить «Enable Loadable Module Support» и вкомпиливать все, что нужно, прямо в bzImage.

И еще. После установки ядра через «make install» желательно удалять из /boot все (config и System.map), кроме vmlinuz.
Сами пробовали? отключить поддержку модулей… и получить нерабочий звук, USB. Удалить config и System.map и получить нерабочий dkms (а информация-то вся есть в /proc/config.gz и /proc/kallsyms).
>>>отключить поддержку модулей…
Единственный способ установки ядерного руткита — подгрузка модуля. Нет модулей — нет руткитов.

>>>и получить нерабочий звук, USB
Не забывайте, что разговор идет про сервер, а не домашний комп. Звука нет (само собой), а USB (во всяком случае, флешка и внешний винт) работает прекрасно

>>>Сами пробовали?
Уже много лет так делаю на продакшене — полет нормальный. Плюс у меня там система — Gentoo-hardened.

Для чего выпиливать из бута config — понятно, а system.map выпиливается потому, что там содержатся все адреса, используемые ядром — некоторые эксплойты первым делом проверяют его наличие.

1) dkms там не нужен — это сервер, все железо заранее известно и драйверы для всего намертво вкомпилены [*] в bzImage
2) /proc/config.gz у меня нет — всегда отключал General setup->Kernel .config support и отключал General setup->Enable access to .config through /proc/config.gz
3) /proc/kallsyms у меня тоже нет — отключал General setup->Configure standard kernel features (for small systems)

А на домашнем компе — само собой, ни чего такого не отключено (а на нем — просто Gentoo, не hardened).
> Единственный способ установки ядерного руткита — подгрузка модуля. Нет модулей — нет руткитов.
Пропатчить исходники ядра и вкомпилить руткит в ядро. Ждать перезагрузки.

> Уже много лет так делаю на продакшене — полет нормальный.
Главное чтобы это было где-то задокументировано чтобы у следующего админа не возникло вопросов.

> Для чего выпиливать из бута config — понятно
Нет, не понятно. Security via obscurity?
>>>Пропатчить исходники ядра и вкомпилить руткит в ядро. Ждать перезагрузки.

Ну, как бы, оставлять на сервере исходники ядра — нонсенс.

>>>Нет, не понятно. Security via obscurity?
Для усложнения пункта 1, плюс человек может сориентироваться по опциям ядра: heap randomization и прочее.

Лично я делаю так (я ни кому не советую так делать, просто говорю, как мне удобно и как я привык):

1) Система собирается/обновляется у меня на ноутбуке в отдельной папке под чрутом, с заточкой и make+use флагами под тот процессор и железо, что на сервере. Повседневной работе на ноутбуке не мешает, так как nice установлен в 19.

2) Создается полная копия (cp -av /from /to) в отдельную папку.

3) Из копии скриптом удаляются весь gnu toolchain (gcc, binutils, make, autotools, в общем, все, без чего невозможно скомпилировать ни одно приложение), wget, питон (на нем основан emerge), все заголовочные файлы, все gentoo-utils, и так далее.

С помощью ldd в рекурсии составляется список всех библиотек, которые не влияют на загрузку системы и от которых не зависят php и mysql. Они удаляются.

В общем, все, что может хоть как-то использоваться злоумышленником. По сути остается только самый минимум из системы, плюс php, imagemagick, и mysql.

Работоспособность проверяется в виртуальной машине.

4) Эта папка, изрядно похудевшая, загоняется в tar, а потом tar — на внешний usb винт.

5) Гружу сервер с флешки (она поставлена первым загрузочным устройством в биосе) (видеокарты там нет — флешка со слаксом настроена на запуск демона ssh автоматом), бекаплю все, что нужно, форматирую корневой раздел, распаковываю в раздел tar с сохранением всех прав у файлов (tar xvpf file), заливаю бекапы, загружаю сервер.

Все. Лично мне — очень удобно, но ни кому не советую.

Обновляю софт точно так же — обновляю образ на своем жестком диске, уродую его, тестирую, потом заливаю.

А так как я — владелец сервера, то за другого админа могу не беспокоиться.)))
> С помощью ldd в рекурсии составляется список всех библиотек, которые не влияют на загрузку системы и от которых не зависят php и mysql. Они удаляются.

И так мы оставляем за бортом все программы с плагинами, использующие dlopen().

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

В программах динамической подгрузкой плагинов пока что потребности не было — если надо расширение функционала, ни что не мешает скомпилировать отдельную программу/набор программ с измененными use флагами как пакет (банально tar), а потом его просто разархивировать на сервере.

>>>Представляю во что выливается установка обновлений безопасности в такой среде

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

Обычно все обновления безопасности/просто патчи добавляются в дерево portage довольно оперативно, и обновить систему (образ полноценной системы же хранится отдельно) — не проблема (chroot /dir, в нем: env-update && emerge --sync && emerge -uDN world).

Как раз из-за простоты мне и нравится такой подход — запускаем обновление, потом скрипт, читаем Хабр, потом просто перезаливаем систему/бекапы с внешнего винта другим скриптом.

Телодвижений ноль, все действия занимают меньше 5 минут не считая времени на сборку системы из исходников.
А похожую схему без физического доступа к серверу (и вообще он виртуальный :) ) сложно реализовать будет?
С виртуальными серверами дела не имел, но, если можно залить образ диска и загрузиться с него — наверное, да. Фиг его знает.
Не прокатит: hardened-sources, доступ к /dev/mem запрещен через GrSecurity и PaX.
А если вшили bluepill то вообще только livecd спасет…
Если стоит ядерный руткит, то ни нетстат, ни rkhunter не помогут. Т.к. будут показывать, что все ок.
Далее, если хакер откроет доступ к своим сервисам только с определенных IP, то, соответственно, не поможет и nmap.
Какое-то нубское howto если честно :)
Смотря какой руткит. rkhunter пытается найти в lkm подозрительные вещи тоже.

В остальном да, чтобы понять, что машина скомпроментированна — нужно представлять как работает система и какие методы мог использовать взломщик. Иначе, проход по пунктам такого «how to» слабоэффективен. Особенно, если на машине изначально слушала куча сервисов, о которых владелец даже не догадывался :)
ну это естественно. вот один мой сервак недавно ломанули через proftpd, как раз была уязвимость там. ни netstat ничего не показывал, ни rkhunter. правда lsof показал, то, что не показывал netstat. но сначала через nmap увидел шел, на странном порту.
вообще я все это сказал к тому, что единственный пока известный мне способ, гарантирующий очистку системы — переустановка.
А как насчет проделать всё вышеописанное, загрузив live дистрибутив? На сервере это реально?
На сервере, даже удалённом, это более чем реально. Но если tripware (точнее tripwire) или аналоги не установлены — то толку?
Сравнить все выполняемые файлы с файлами из репозитория, например.
portmap, rpc.statd и mysql слушающие в Интернет — это супер, конечно.
Почему бы мускулу не слушать? Главное права нормально настроить
Потому что, скорее всего, производственной необходимости в этом нет. И вывешивать еще один демон, без надобности, в Интернет — это не безопасно.
Если все же необходимость есть, то необходимо открыть доступ к порту только тем доверенным адресам, которые должны иметь этот доступ.
Если есть необходимость давать доступ к mysql-демону с неопределенного динамического адресного пространства, то я бы рассмотрел вариант с организацией доступа через vpn или, что скорее, пересмотрел бы дизайн решения, скорее всего в нем что-то не так.
Если вывешивают, то необходимость явно есть, по дефолту он слушает только локальные интерфейсы (по крайней мере так в Debian/Ubuntu, из сорцов не собирал, другие дистры настолько не юзал).

Сканирование, судя по всему, производилось с доверенного (домашнего или рабочего) компьютера, а значит ничего удивительного, что много портов. Например, когда я сканирую из дома свой VDS, то мне открыто порядка десятка портов, сканирую с работы или через 3G-модемы — 3 (22, 80, 8080), остальные дропаются. Несколько раз сталкивался с необходимостью срочно с произвольного адреса зайти на другие порты — заходил по ssh и временно открывал порты для текущего IP, потом закрывал (удалял разрешающие правила iptables).

Рано отправил:

Может не оптимально, но я в конце-концов не админ, а разработчик, которого перестали устраивать вечные препинания с суппортами различных shared-хостингов, то я >5% ресурсов использую и мне аккаунт блочат без уведомления, то что-нибудь из PECL/PEAR не хотят ставить, то ещё что-нибудь.
Вы слишком верите в людей :) Поверьте, чаще что-то делается, когда на то совсем нет необходимости.

В контексте этой статьи, автор предложил просканировать сервер со стороннего хоста, чтобы увидеть что торчит «наружу». Сканировать с доверенного хоста в данном случае не было смысла.

Плюс, автор сам был удивлен наличием некоторых демонов, которые оказались легитимными, но о которых он не знал. Что вызывает некоторые сомнения в возможности адекватной защиты других компонентов системы в данном конкретном случае.
Для rpm дистров есть мощное rpm -V
UFO just landed and posted this here
Буквально на днях друг просил сервер посмотреть, говорит что хетзнер залочил арендованный сервер за атаки.

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

Снес exim, и запустил find / -user exim и нашел кучу перловых IRC и спам ботов.

Кстати, rkhunter надо запускать ежедневно по крону. После инцидента он бесполезен, т.к. проверки идут относительно last state/
Да, еще один совет. Отключайте парольную аутентификацию по ssh. Ходите на сервер по rsa/dsa ключам, это и удобнее в разы и безопаснее. Ну или хотябы rootlogin отключайте.
Хорошо написано, но ни слова про jail. А если тебя сломали и всю систему имитировали в jail, то хоть до посинения меняй рутовый пароль и ищи руткиты — настоящая система всё равно остаётся «выше» и остаётся полностью в распоряжении взломщика.
Эм… но ведь можно узнать в джейле ты или нет. Так что будет понятно что произошло.
Т.е. взломщик получает рута на целевой системе, настраивает на ней какой-либо вид виртуализации, переносит весь функционал текущей машины в гостевую среду, а себе оставляет управление хост-системой? Интересный концепт. Вы встречали такое на практике?
На ум приходит аналогия с «Матрицей» :)
Тогда уж «Начало» :)
Встречал конечно, посмотрите на мою историю работы в IT. Некоторые годами не осознают, что сидят в джайле. Рядовой сотрудник саппорта хостинга точно не догадается.
Взломщику незачем тревожить владельца сервера, удалять все файлы, запускать левые процессы, и совершать прочие деструктивные действия. Машина просто тихо становится гейтом к чьим-то корпоративным данным или сетям.
Что говорит о том, что эти некоторые годами не обновляют свои системы.
Как уже сказали выше, определить находишься ли ты в jail или нет не сложно. Это же выявится и при попытке обновления. То есть такой вид атаки расчитан на людей со слабой кваликацией, которые не особо уделяют внимание тому, что происходит у них на сервере.
В этом случае, зачем утруждаться настройкой jail и переносом софта и т.д., если такие владельцы сервера с таким же успехом не заметят и обычный руткит?
это СОВСЕМ не jail, это KVM. А его выловить можно только по косвенным признакам, и это очень сложно.
Да. Я встречал. Называется bluepill (виндовый вариант — redpill). Штука очень хитрая и в удалении сложная, да и обнаружить ее черезвычайно трудно. Но и вживить в систему — тоже.
bluepill это совсем отдельная тема, конечно. В данном случае оригинальный коммент был именно про jail, что и родило во мне сомнения.
Пароль меняем не командой

# passwd

а командой

# /usr/bin/passwd
лично видел левый passwd в $PATH
Впрочем, это всё равно не поможет, если # скомпрометирован. Тут поможет только список хеш-сумм бинарников.
Главное не на сервере его хранить, а то хеши тоже перепишут.
Угу. Я однажды разбирался с таким вот поломанным сервером. Очень основательно было сломано. Клиенту после нескольких часов разбирательств посоветовали вообще его удалить целиком и с нуля переустановить. Даже никакие файлы не брать, ибо где угодно могла быть зараза.

Подменено было практически всё важное, даже какие-то левые ядерные модули были подгружены.
Странно что никто не написал раньше меня. Руткиты любят переписывать системные утилиты, чтобы лучше маскироваться. Поэтому я, когда подозреваю что мой сервак взломали, перехожу с ls, cat, netstat, ps, top и так далее на busybox ls, busybox cat, busybox netstat, busybox ps и так далее. Странно, но про busybox руткиты почему-то забывают, а он стоит на многих линуксах по умолчанию.
У меня была секретная ссылка на бинарники, которые я скачивал вгетом, они таки удобнее, чем бизибоксовые.
Выполнять любые команды из-под скомпрометированной системы бессмысленно. Есть только три действительно надёжных способа выхода из ситуации:
1. Загрузка с внешнего носителя и проверка контрольных сумм всех системных файлов.
2. Восстановление из резервной копии.
3. Переустановка с нуля.
Только надо не забывать что при каждом обновлении системных утилит нужно так-же обновлять и их контрольные суммы в отдельном файлике хранящимся уж точно не на сервере.
Не обязательно. В Debian, например, подсчёт MD5 всех файлов происходит на уровне менеджера пакетов. На другой машине тоже можно из пакетов достать список контрольных сумм.
А кто мешает руткиту заменить мд5 суммы в стандартном файле сверки — своими?
Вы на другой машине скачаете пакеты из репозитория, проверите подписи, извлечёте из этих пакетов списки контрольных сумм.
Что и следовало ожидать: виноваты не хакеры, а конфиги софта :)
Имхо, большинство атак сейчас идут не на обретение рута, а на эксплуатирование незапатченных уязвимостей софта. Безусловно, ход работы был верным, но начал бы я с проверки логов приложений, работающих с сетью. А то мы долго ищем, кто у нас обрёл рута и поставил руткиты, а дефейса-то и не видим :)
UFO just landed and posted this here
UFO just landed and posted this here
Еще может помочь сохранение логов на сторонний сервер, в случае попытки замести следы, оригинальные логи останутся в другом месте. Спасибо за комментарии, советы даже интересней чем в статье.
UFO just landed and posted this here
В вашем примере nmap не обнаружит порты с номером выше 10к, чтобы просканировать все 65 тысяч нужно писать nmap -p- что равносильно p0-6553
Sign up to leave a comment.

Articles