Pull to refresh

Comments 150

Просто монстр, история вызывает уважение.
В Инфобоксе саппорт что надо:)
Прямо детектив. Интрига, драма, крови, кишки, расчленёнка!
Для остроты сюжета не хватает еще постельных сцен.

А по теме, вышло очень интересное расследование с массой познавательной (для меня) информации.
Уж чего-чего, а потрахался ГГ изрядно, одна сплошная постельная сцена с перерывами на перекур. )
судя по состоянию автора скорее с перекурами на перерыв
Денег-то не за что просить — вот и постельная сцена :)
А я строчки после 10-й начал читать как смотрел бы фильм на китайском — действо занятное, общий смысл понимаешь, а что сказал вот этот дядя той тебе — хз ))
интересная история, а как проникли на сервер по логам узнать не удалось?
Не знаю, до этого у клиента был другой сисадмин. Возможно в этом и дело.
По поводу «другого сисадмина»:
Я часто спрашиваю как именно уволили старого сисадмина перед тем как начать менять пароли и доступ для клиента.
А ещё лучше спрашивать у самого сисадмина.
Лучше, но малореально в этих случаях.
Абсолютно ничего не понял, но эмоции испытал сильные ))
То же самое, но несколько команд вспомнил из молодости, когда увлекался.
chkrootkit`ом прогони на всякий пожарный…
И да, спасибо за довольно интересную историю.
The following error was encountered:
Connection to 187.33.4.179 Failed

The system returned:
(111) Connection refused
О спасибо! Установил прямо с репов.
Еще можно rkhunter'ом прогнать.
Общее правило таки гласит — обнаружил рутование? Ставь чистую систему и накатывай сайты с нуля.
Надо же, я так и сделал, когда пришлось, не зная правила. Интуиция, что ли?
По аналогии для винды и юзерских компов — система выдает непонятную ошибку при загрузке? Переустановите ее нафик :)
Не. Не наш метод. Особенно в случае с чужим серваком потом выяснится, что где-то валялись и работали кастомные конфиги или специально для нас собранные службы и т.п. Потом недели две отлавливать что и почему не работает или работает не так как задумано, выяснять что забыли сдернуть со старой системы…
У нормальных пакетных менеджеров всегда есть возможность проверить файлы для всех установленных пакетов. Соответственно — собираем список, думаем, восстанавливаем. Дальше обновляемся, ищем дыры или оставленные хакером бэкдоры и прочие стандартные мероприятия проводим.
А так в целом — да, переустановить проще чем напрягать мозги и искать причину засора :)
Аналогия чуть-чуть не та :) Эти подменённые файлы могут оказаться только вершиной руткита. Всё остальное может быть в ядре в виде изменённых модулей. Через ядро можно всё очень хорошо замаскировать. Опенсорс же ;)

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

Но я бы не стал переустанавливать. Если есть возможность, лучше:
— поднять запасной сервер, скопировать туда данные, запустить сервис там на другом IP
— этот оставить рабочим
— написать заяву в органы, дать IP и логин/пароль на зараженный сервер. Пусть попробуют поймать хакера, если он решит вернуться. Или можно выманить чуть-чуть сломав его спамбота.
Даже если в «органах» есть специалисты нужного уровня, таким мелким делом они заниматься не станут.
С маскировкой в ядре сталкивался. Ядро это точно такой же пакет, соответственно можно проверить его целостность. Ну и в условиях цейтнота, дополнительно тупо сравнить объем директории с модулями с эталонным пакетом, а дальше уже разбираться что новенького появилось.
Переустановка это способ все почистить, когда админу лениво включать мозги и разбираться что же натворили в системе, либо этих самых мозгов просто не хватает :)
Злоумышленник компилирует модуль под установленное ядро, помещает куда-нибудь подальше, загружает командой insmod и скрывает файл модуля с помощью скрыт(н)ого монтирования (монтирование пустого каталога поверх каталога с файлами).
И? Это невозможно отловить и вычистить?
Если модуль ядра подменяет результаты, возвращаемые системными вызовами, то это может быть очень сложно.
По-крайней мере, проверка целостности через пакетный менеджер в данном случае ничего не даст.
Проверка пакетным менеджером только один из этапов. Смысл тут в комментах все методы поиска обсуждать? Лучше уж статью накидать, если время будет.
Дальше рассуждать смысла не вижу — свою точку зрения я высказал. У некоторых личностей мои комменты вызвали баттхерт, (непонятно почему) и они минусуют все мои комменты в этом топике и срут в карму. Так что я откланиваюсь.
Накидай, коли не шутишь.
А аналогия вполне себе та. На работе уже пару раз увольнял молодёжь, которая не любит включать мозг, а решает проблемы на клиентском компе или сервере тупо реинсталлируя систему. Надо искать причину, а не рубить голову пациенту. Реинсталл — крайняя мера и ее применение должно быть мотивировано.
Бест практис при обнаружении руткита на сервере — реинсталл. Это для тех, кто как раз таки включает мозг, а не изображает из себя бэтмена.
Задача админа — обеспечение работоспособности mission critical служб на сервере. И даунтайм стремящийся к нулю. Реинсталл этому обычно не способствует. Значит это бэд практис.
А какие еще категории знаешь, кроме mission critical? По каким принципам классифицируют системы на те или иные категории? Или так, просто слово нравится?
Даунтайм, стремящийся к нулю не построить на single-сервере с приходящим админом-фрилансером, как ты понимаешь
mission critical — падение службы приводит к потере бабла. Все остальное по фигу.
По уму не построить. Но надо к этому стремиться. Далеко ходить не надо. Статья перед глазами. Задачу можно было решить без даунтайма.
Запарился из пустого в порожнее переливать. Нравится реинсталить? Пожалуйста, не держу.
Я точно так же презираю тех, кто кидается реинсталлить не подумав, для справки.
Неверно ты понимаешь mission critical. Ты грубо описал business critical.
Дык мы тогда о чем спорим то? Камень преткновения в данном случае — реинсталл.

Насчет mission critical — вики гооворит, что все правильно понимаю:
Mission critical refers to any factor of a system (equipment, process, procedure, software, etc.) whose failure will result in the failure of business operations. That is, it is critical to the organization's 'mission'.

failure of business operations -> нет бабла :) Я всего-лишь немного утрировал :)
Ох уж эта википедия. Ничего, продолжай доверять ей.
failure of business operations!=нет бабла. Это значит «нет бизнеса». Простой mission critical системы в течение [amount of time, задается индивидуально] приводит к непоправимому ущербу репутации компании и прекращению бизнеса. В некоторых случаях это отзыв лицензии на деятельность, в некоторых (если нет необходимости в compliance) просто вынос компании с рынка.
Потеря бабла — это business operational (грубо — незначительная потеря бабла, без непосредственного урона репутации) и business critical (грубо — значительная потеря бабла и серьезный ущерб репутации).
А еще есть классы office productivity и core, например. Прежде чем щеголять терминологией, нужно ее знать, я считаю.
Да знаком я с этими терминами. В случае бизнеса все эти репутации и т.п. все равно в результате выливается в потери бабла, ибо в случае бизнеса все эти высокопарные «миссии» в конечном итоге сводятся к деньгам.
Теперь знаком, да. Не благодари, это была бесплатная консультация.
Вот как странно всё получается. Всё сводится к деньгам, а на резервирование / отказоустойчивость этих самых денег нет.
Разные ситуации бывают. Бывает что есть на резервирование, а бывает что только на резервное копирование.
До первого раза, как правило.
Обычное дело, я когда в хостинге работал часто слышал от клиентов «срочно все чините, мы миллионы теряем», слышал это в основном от клиентов на 100 рублевом шаред хостинге.
> mission critical — падение службы приводит к потере бабла
Ну, ведь то что описано — не mission critical, правда? ))

По поводу реинсталла: если был рут, систему можно выкидывать. На рабочей системе уж точно пытаться что-то фиксить толку ноль. Вот дампануть образ, что-бы попытаться найти изменения и причину — ок. А сразу после этого — реинсталл. Ну или разворачивание старого образа. И параллельный поиск причины для фикса.
>Ну, ведь то что описано — не mission critical, правда?
Дословно — нет, но кто хотел, тот понял, что я имел в виду. У кого до фига свободного времени начинают цепляться к словам :(

Выкидывать систему сразу после потери девственности?
Приводить примеры из жизни, когда на живой системе приходилось выпиливать руткиты и прочую дрянь без остановки сервисов? Смысла не вижу. Я свое отношение к реинсталлу высказал. Просто надоело упоминание его как панацеи в некоторых книжках по ЗИ. Народ читает и потом применяет не думая при любом чихе.
> Владелец сервера негодует, т.к. сервер в дауне уже несколько часов
> Приводить примеры из жизни, когда на живой системе приходилось выпиливать руткиты и прочую дрянь без остановки сервисов



А по какому критерию определено, что руткитов/бэкдоров в системе больше не осталось? Чем вы версионируете все конфигурационные файлы (в т.ч. пользовательские, типа .bashrc) в системе? Есть отдельный лог сервер?
Лог-сервер, как правило, есть. Также в одной из конфигураций был сервер, на который обычным rsync'ом все бакапилось с сохранением всех логов работы. Бэкдоры были вычислены на 1-2-3. Изменения в конфигах — сравнение конфигов со старыми бакапами. Дырявые скрипты потом за вечер были найдены.
Ну и тулзы типа tripwire пока никто не отменял :)
В таком mission critical тем более лучше не пытаться починить на лету. Автор статьи это продемонстрировал в эпизоде с segfault-ами. И нервы и время и деньги клиента потратил.

Надо поднимать, настраивать из бекапов и тестировать второй сервер, а потом их свапнуть. Если это действительно mission critical, то такой сервер уже должен быть в failover кластере ;)

А потом спокойно разбираться с первым.
Автор продемонстрировал, что надо было проверить файлы, критичные для работы системы, а потом уже ребут жамкать, тем более что у него ночь была пока ждал kvm. То есть пошел по верному (на мой взгляд) пути, но допустил ошибку, из-за которой был большой простой.

Иногда дешевле бывает иметь бакапы в 2-3 точках, чем иметь в запасе кастомную железку, аренда которой может составлять не хилую долю в затратах хозяев бизнеса. Соотственно, восстановление с бакапов только в самом крайнем случае — если железка кирдыкнулась.
Как-как. Сферически да в вакууме.
А не будет достаточно вместо переустановки системы просто установить новое ядро, и перезагрузившись с ним, полностью снести подозрительное старое?
Не будет, если закладка не в ядре.
UFO just landed and posted this here
В каждом конкретном случае надо оценивать время даунтайма и стоимость этого даунтайма для работодателя.
При больших объемах восстановление с бакапа может не один день занять. Можно конечно на бакапном поднять нужные сервисы в джейле, но велика вероятность, что нам еще и на бакапный сервер дряни натолкают.
По уму надо иметь удаленный бакап базы менеджера пакетов, плюс базу типа tripwire, либо если бакап идет rsync'ом, то его логи. Ну и плюс логгирование на удаленный защищенный хост.
Бэкап, бэкап. Затем разворачиваемся с ноля, при необходимости заглядывая «как оно там было».
Задача — бакап 5 терриков, время восстановления больше суток. Каждый час даунтайма обходится работодателю в 30% з/п админа. Вопрос — через сколько часов даунтайма админ будет уволен?
У вас системный раздел и рабочие данные живут вместе? Не предусмотрено резервное копирование рабочих данных? Не делается резервное копирование настроек (хотя бы элементарное tar cjf etc.tar /etc)? Далее очевидные вещи перечислять не буду.

Не верится мне в такое, вы же опытный человек. Тем более что ваша иконка от знаменитой игры намекает на обстоятельность. Поэтому таскание терабайт представляется мне глубоко сомнительным занятием.
>У вас системный раздел и рабочие данные живут вместе?
У меня — нет. А вот на серверах, которые временами просят починить — сплошь и рядом.
Это да, сплошь и рядом. Но проблему надо решать и кто-то должен эту работу оплатить. Я предпочитаю отказаться от работы, где надо все сделать на скорую руку и тяп-ляп — потом начинаются вопросы и комментарии вида «а оно опять не работает», «недоделано» и т.д., хотя условия заранее обговаривались и все что я обещал было сделано. В общем «быстро дорого качественно — выберите два пункта» :-)
Очень часто, помощи просят люди, которым не можешь отказать :( Приходится выкручиваться, так чтобы и даунтайм стремился к нулю и проблему решить.
Не «дорого» — «дешево».
Иначе выбираю «быстро» и «качественно».
Да, разумеется должно быть «дешево», спасибо. Писал впопыхах :-)
Отвечаю на вопрос. Админ будет уволен через -1 час, как допустивший руткит.

А вот новый админ уволен за даунтайм сервера уже не будет.
Это когда своё. А клиенты-владельцы хотят экономить. Приходится убеждать страшными историями.
UFO just landed and posted this here
Жизнь показывает, что уже оказанная услуга ничегг не стоит. Хотя конечно надеюсь, что автору заплатят.
Ничего не понял, но сюжет захватывает. В конце happy end ))
Загурзились с liveusb/livecd и запустили бы debsums…
UFO just landed and posted this here
Ну сканированием clamscan /
Или как подсказали в комментариях chkrootkit
Один из методов это проверка целостности — запоминаем контрольные суммы всех важных файлов на чистой системе и периодически отслеживаем изменения. Для этого есть много инструментов, например tripwire.
UFO just landed and posted this here
Захватывающий IT детектив! Вражеский резидент был вычислен и выведен из игры, эскалации назревавшего скандала не произошло.
Но как бы там ни было, субъективно полезная информация.
Так же пострадал очень давно, лет наверное с десять назад.
Мне повезло больше, я перед перезагрузкой нашел все бинарники измененные после определенной даты и все их заменил на версии из пакетов. Предварительно собрав своё окружение из всех системных утилит в отдельную директорию и пользуясь только ей поубивав все из памяти.
Я так смотрю за десять лет подход к рутованию серверов не изменился, ничего нового не придумали…
Меня тогда поимели отснифав пароль от _телнета_ (десять лет назад, напоминаю, даже свитчей ещё не было в нашей локалке!), кто-то из соседей по сети…
Вот она кстати обратная сторона опен сурса, ещё тогда подумал я, нахлобучить систему могут так, что понять что к чему можно будет только если ты намного выше среднего разбираешся в системе, а не просто тыкаешь мышкой в Gnome. В отличие от винды, где 95% проблем решается прогоном антивируса из safe-mode.
Автор и написал о том, что вирус 2001 года =) Так что да. Как раз 10 лет.
«Кто там говорил, что нет под Linux вирусов?»

решето :)
Тогда уж «система технологических отверстий»
Вот про вирусы — как автор вообще догадался запустить проверки на вирусы линукса — до меня не доходит. Респект!
Автор достоин уважения.
Я бы наверное сдался, с надежной только на суппорт.
А я бы снял образ, снес все нах и сделал с нуля. Да, наверное дольше, но как-то спокойнее. А поковыряться потом можно было бы, спокойненько.
И на следующий день снова бы получили сервак, хакнутый через дырку в одном из скриптов сайта?
Потом снова снимать образ и ставить все с нуля? На какой итерации процесс надоест? :))
на первой, если хватит мозгов после настройки снять второй образ :)
А при чем тут дырка в скриптах сайта, м? По-твоему, ГГ быстренько сделал ревью всего кода сайта?
а. Мы вроде на «ты» не договаривались пока переходить :)
б. Это просто пример. После восстановления можно получить снова сломанный сервер. Ибо дыра может быть вообще не в системе, а юзерских скриптах, конфигах и еще куче того, что мы подтянули с бакапа.

Я считаю, что надо вычищать систему, а потом искать как забрались. То бишь не считаю реинсталл панацеей / способом решить проблему.
К чему здесь этот пример? Заметки Капитана?
Я русским по белому написал, что надо снять образ и потом по нему производить расследование. Первоочередная задача — восстановить сервис, вторая задача — провести разбор полетов с целью недопущения рецидива.
Русским по-белому было написано «снес все нах и сделал с нуля». Против снятия образа ничего не имею. :)
Очень интересно читалось. Боевик без единой постельной сцены.
… из единой постельной сцены.
> Кто там говорил, что нет под Linux вирусов?
Ну правильно, кто-то нашел эксполит (в необновленном дистрибутиве-то!), кто-то собственноручно загрузил его и настроил на правильную работу. Все как обычно. Массовых самозаражений, как раньше в винде было, нет.
Хотя, конечно, ерудну сказал. Вполне может себе бегать бот и искать необновленные сервера. Но, опять же, после обнародования уязвимости, которую залатали.
Забавно. Кто то еще использует такие допотопные руткиты.
Scripting kid на дедушкиной компашке «1001 программа для хакера» нарыл :)
интересно, что вирусняк под линуксом часто легко спалить по дате изменения файлов
буквально пара строк и чёрт его знает как действовал бы автор

а вообще конечно здорово, что победа :)
Спасибо за сообщение. Мы проанализируем инцидент для анализа действий и ответов сотрудников.
В любом случае мы проведем дополнительное обучение системных инженеров и администраторов диагностике работы дисковой подсистемы.

Отдельно отмечу, что работы по администрированию со сложно прогнозируемым результатом, как правило оцениваются в один час, и лишь после определения проблемы уточняется стоимость. В случае если определить проблему не удается дополнительные часы не оплачиваются.
Нет лучше резюме, чем такая статья. How to hire you, Master?
Ничего особенного тут нет, любой нормальный линукс-админ должен такое уметь.
Ну да, это как тот мужик, который Х лет обхаживал взлетную полосу на заброшенном аэродроме «чтоб красиво было», пока на нее не села аварийная Тушка. Не скромничайте.
Почти как в песне: «она читала жизнь как роман, а он оказался повестью»
Очень интересно читается, и главное, познавательно :)
Я наверное в такой ситуации сам бы не разобрался, пришлось бы консультироваться с более опытными знакомыми.
Это ещё хорошо когда есть к кому обратиться и кто настолько хорошо прокачан.
Самое главное узнать не удалось — каким образом взломщик получил доступ к системе, возможно дырка осталась незакрытой.
Странно, что ни кто до сих пор не спросил о системном окружении. Видимо от офигения.

Но я таки уточню, что за ОСь стояла?
debian lenny, о чем упоминается несколько раз. Первый тут: "… наложил все security обновления на Debian Lenny, включая новое ядро."
Поднимаю сетевой интерфейс, присваиваю IP, и скачиваю deb пакет mount для lenny.

Debian, смею предположить.
Опубликую ответ на комментарий мимо и в дубликате. Обращаться к BSoD'у.
>>Обращаться к BSoD'у.
Это тоже самое что и к /dev/null?
UFO just landed and posted this here
«Ведь fdisk никогда и не умел работать с программным raid.»

Что за чушь?! фдиску пофигу какое блочное устройство ему подали, если весь /dev/md0 был расформатирован под ext3, то ессесно там нет таблицы разделов, только и всего.

Не знаю как с apt, но наверняка также как с rpm там есть verify и все подмененные пакеты было бы видно в одну комманду.
Поправил под более правильную формулировку.

А насчет apt — он не умеет проверять пакеты, есть только debsums, но он по дефолту в системе не ставится, да и увы не у каждого пакета есть md5 суммы.
частично поможет
for d in /bin/*; do dpkg -S "${d}"; done
покажет все файлы из /bin/ и из каких они пакетов.

если файл «левый» то будет что-то типа
dpkg-query: no path found matching pattern /bin/bash.evil.
Еще можно настроить rkhunter, он будет мониторить, какие файлы изменились.
По хорошему, ставим Tripware, делаем снимок файлов системы на данный момент и уведомляем себя по почте обо всех изменениях в файлах.
А сколько таких историй тонут в потоке отчаяния человека, который не смог
Сразу полез смотреть профиль — не мой ли провайдер:)
Хочу объяснить, почему «вывод команды last и who не показали ничего сверхестественного». Дело в том, что они опрашивают не ядро, а смотрят данные в специальных файлах /var/log/wtmp и /var/log/btmp. Файлы эти по сути своей логи (правда бинарные).
Грамотные злоумышленники после получения рута первым делом чистят за собой следы в этих файлах. А многие администраторы и не знают, как оно работает.

Кстати, первое предложение из man last
Last searches back through the file /var/log/wtmp (or the file designated by the -f flag) and displays a list of all users logged in (and out) since that file was created.
> А многие администраторы и не знают, как оно работает.

Я сомневаюсь, что таких людей вообще можно называть администраторами.
Вы не поверите, каких замечательных людей иногда называют администраторами :) Хотя… Вы-то как раз наверное и поверите.
По-ходу чтения в голове возник образ рыбы в воде. Очевидно, автор в своей стихии.
Видимо повальный сегфолт и был результатом некорректной работы вируса.
Я тоже так думаю. Система то новая, а вирус 2001 года. Если б не сегфолты может ничего бы и не заметил. Зато теперь другим будет наука.
>> Денег еще не просил. Да и за что? Основную задачу то не выполнил =)

Дружище, ты за невыполненную задачу и не проси. Просто объясни, от какого зла ты их спас и сколько они аптайма бы потеряли еще с переустановкой всей системы. И предложи самим определить тебе вознаграждение.
Правильно! Тем более, что даже саппорт-тима все подвела к тому, что спасет только реинстал.
А автор молодца! Спас заказчика без реинстала. Так что, думаю, заказчик сам может понять какую немаленькую проделали по спасению сервера.
Еще можно дать заказчику ссылку на эту страницу )
UFO just landed and posted this here
очень хорошая история, только не понравилось окончание с клиентом. Это почему же денег не просили? Вы что же, свою работу не цените? Экзим настроить почти любой сможет, а вот исправить такую проблему — очень-очень мало людей.
Эх кармы не хватае. В общем вам +1 и «респект»!

Ну и так по мелочи, как уже советовали chkrootkit и rkhunter. Но я бы еще пошуршал по логам, мож дырка на сайтах (часто такое).
зашел на инфобокс www.infobox.ru/vps/
там ни слова про kvm
может афтор игрался где-то в другом месте? У себя дома например?
Какими средствами можно проверить систему на руткиты?
rkhunter, chkrootkit. Вот только «поздно пить боржоми», эти средства нужно заранее ставить. rkhunter собирает базу контрольных сумм и прочих параметров системных бинарников и сравнивает с ней текущую обстановку.

Проделанная работа автора вызывает уважение.
Печально только что за его труды максимум, что он получит, это, спасибо.
Сам как то давно попадал примерно в такую же ситуацию, но сервер был мой и был тоже на дебиане, какое то злополучное сходство ).
Переустанавливаю openssh-server и openssh-client.

Набрал «reboot» и тут на тебе: десятки segmentation fault. Волосы начинают седеть, руки трястись. В общем я думаю многие представляют мою ситуацию. Как говорится «если работает — не ТРОЖЬ!», но после обнаружения проникновения пришлось наложить обновления и перезагрузиться.

«А что если файлы, которые вызывают сегфолт, подмененные?». Сказано сделано.

Проверяю файлы в /bin/ и вижу следующую картину

Честно говоря, не понимают за что топику столько плюсов. Автору как Linux админу — незачёт. IMHO, ситуация более чем тривиальная. Или на Хабре нынче уже дефицит вменяемых сисадминов?
Для начала потрудились бы проверить целостность установленных пакетов через debsums — можно убить всех зайцев сразу. Когда более-менее понятно, что система неким кривым руткитом/трояном уже изрядно испорчена, и при наличии KVM (впрочем, при наличии у хостера remote boot через PXE, это даже не требуется) стоило загрузиться в сторонний ремонтный дистрибутив, подмонтировать раздел и заняться чисткой.
Теперь остаётся заменить все модифицированные файлы оригинальными. Скачиваю нужные пакеты и устанавливаю через dpkg -i *deb

aptitude reinstall?

В том, что большинство серверов, не обслуживаемых постоянным админом, апдейтятся как попало, если вообще апдейтятся хоть раз с момента установки до первого хака, нет ничего удивительного. Nobody cares.
Или на Хабре нынче уже дефицит вменяемых сисадминов?
Сам-то как думаешь? -)

Отличный пост. Читал практически открыв рот.

Да уж, читать отзыв на пост 10-летней давности то еще ощущение. С другой стороны за 10 лет в этой сфере мало что изменилось.

Отчасти понимаю вашу реакцию )

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

Пошёл читать хаб ИБ про фильтру «Самое лучшее за всё время». Очень здорово и очень интересно.

Sign up to leave a comment.

Articles