Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 150
Просто монстр, история вызывает уважение.
Прямо детектив. Интрига, драма, крови, кишки, расчленёнка!
Для остроты сюжета не хватает еще постельных сцен.
А по теме, вышло очень интересное расследование с массой познавательной (для меня) информации.
А по теме, вышло очень интересное расследование с массой познавательной (для меня) информации.
Уж чего-чего, а потрахался ГГ изрядно, одна сплошная постельная сцена с перерывами на перекур. )
Денег-то не за что просить — вот и постельная сцена :)
А я строчки после 10-й начал читать как смотрел бы фильм на китайском — действо занятное, общий смысл понимаешь, а что сказал вот этот дядя той тебе — хз ))
сюжет захватывающий :D
интересная история, а как проникли на сервер по логам узнать не удалось?
Абсолютно ничего не понял, но эмоции испытал сильные ))
chkrootkit`ом прогони на всякий пожарный…
И да, спасибо за довольно интересную историю.
И да, спасибо за довольно интересную историю.
The following error was encountered:
Connection to 187.33.4.179 Failed
The system returned:
(111) Connection refused
Connection to 187.33.4.179 Failed
The system returned:
(111) Connection refused
Пардон, нашел в mirrors:
www.spenneberg.org/chkrootkit-mirror/files/chkrootkit.tar.gz
www.spenneberg.org/chkrootkit-mirror/files/chkrootkit.tar.gz
В дебиане есть пакетик под ленни
ftp.ru.debian.org/debian/pool/main/c/chkrootkit/chkrootkit_0.48-8_i386.deb
или амд64 ftp.ru.debian.org/debian/pool/main/c/chkrootkit/chkrootkit_0.48-8_amd64.deb
ftp.ru.debian.org/debian/pool/main/c/chkrootkit/chkrootkit_0.48-8_i386.deb
или амд64 ftp.ru.debian.org/debian/pool/main/c/chkrootkit/chkrootkit_0.48-8_amd64.deb
Общее правило таки гласит — обнаружил рутование? Ставь чистую систему и накатывай сайты с нуля.
По аналогии для винды и юзерских компов — система выдает непонятную ошибку при загрузке? Переустановите ее нафик :)
Не. Не наш метод. Особенно в случае с чужим серваком потом выяснится, что где-то валялись и работали кастомные конфиги или специально для нас собранные службы и т.п. Потом недели две отлавливать что и почему не работает или работает не так как задумано, выяснять что забыли сдернуть со старой системы…
У нормальных пакетных менеджеров всегда есть возможность проверить файлы для всех установленных пакетов. Соответственно — собираем список, думаем, восстанавливаем. Дальше обновляемся, ищем дыры или оставленные хакером бэкдоры и прочие стандартные мероприятия проводим.
А так в целом — да, переустановить проще чем напрягать мозги и искать причину засора :)
Не. Не наш метод. Особенно в случае с чужим серваком потом выяснится, что где-то валялись и работали кастомные конфиги или специально для нас собранные службы и т.п. Потом недели две отлавливать что и почему не работает или работает не так как задумано, выяснять что забыли сдернуть со старой системы…
У нормальных пакетных менеджеров всегда есть возможность проверить файлы для всех установленных пакетов. Соответственно — собираем список, думаем, восстанавливаем. Дальше обновляемся, ищем дыры или оставленные хакером бэкдоры и прочие стандартные мероприятия проводим.
А так в целом — да, переустановить проще чем напрягать мозги и искать причину засора :)
Аналогия чуть-чуть не та :) Эти подменённые файлы могут оказаться только вершиной руткита. Всё остальное может быть в ядре в виде изменённых модулей. Через ядро можно всё очень хорошо замаскировать. Опенсорс же ;)
Вполне возможно, что там их два. Простой руткит, чтобы нашли и успокоились, и настоящий в ядре. Поэтому переустановка — это верный способ всё точно почистить.
Но я бы не стал переустанавливать. Если есть возможность, лучше:
— поднять запасной сервер, скопировать туда данные, запустить сервис там на другом IP
— этот оставить рабочим
— написать заяву в органы, дать IP и логин/пароль на зараженный сервер. Пусть попробуют поймать хакера, если он решит вернуться. Или можно выманить чуть-чуть сломав его спамбота.
Вполне возможно, что там их два. Простой руткит, чтобы нашли и успокоились, и настоящий в ядре. Поэтому переустановка — это верный способ всё точно почистить.
Но я бы не стал переустанавливать. Если есть возможность, лучше:
— поднять запасной сервер, скопировать туда данные, запустить сервис там на другом IP
— этот оставить рабочим
— написать заяву в органы, дать IP и логин/пароль на зараженный сервер. Пусть попробуют поймать хакера, если он решит вернуться. Или можно выманить чуть-чуть сломав его спамбота.
Даже если в «органах» есть специалисты нужного уровня, таким мелким делом они заниматься не станут.
С маскировкой в ядре сталкивался. Ядро это точно такой же пакет, соответственно можно проверить его целостность. Ну и в условиях цейтнота, дополнительно тупо сравнить объем директории с модулями с эталонным пакетом, а дальше уже разбираться что новенького появилось.
Переустановка это способ все почистить, когда админу лениво включать мозги и разбираться что же натворили в системе, либо этих самых мозгов просто не хватает :)
Переустановка это способ все почистить, когда админу лениво включать мозги и разбираться что же натворили в системе, либо этих самых мозгов просто не хватает :)
Злоумышленник компилирует модуль под установленное ядро, помещает куда-нибудь подальше, загружает командой insmod и скрывает файл модуля с помощью скрыт(н)ого монтирования (монтирование пустого каталога поверх каталога с файлами).
И? Это невозможно отловить и вычистить?
Если модуль ядра подменяет результаты, возвращаемые системными вызовами, то это может быть очень сложно.
По-крайней мере, проверка целостности через пакетный менеджер в данном случае ничего не даст.
Проверка пакетным менеджером только один из этапов. Смысл тут в комментах все методы поиска обсуждать? Лучше уж статью накидать, если время будет.
Дальше рассуждать смысла не вижу — свою точку зрения я высказал. У некоторых личностей мои комменты вызвали баттхерт, (непонятно почему) и они минусуют все мои комменты в этом топике и срут в карму. Так что я откланиваюсь.
Дальше рассуждать смысла не вижу — свою точку зрения я высказал. У некоторых личностей мои комменты вызвали баттхерт, (непонятно почему) и они минусуют все мои комменты в этом топике и срут в карму. Так что я откланиваюсь.
А аналогия вполне себе та. На работе уже пару раз увольнял молодёжь, которая не любит включать мозг, а решает проблемы на клиентском компе или сервере тупо реинсталлируя систему. Надо искать причину, а не рубить голову пациенту. Реинсталл — крайняя мера и ее применение должно быть мотивировано.
Бест практис при обнаружении руткита на сервере — реинсталл. Это для тех, кто как раз таки включает мозг, а не изображает из себя бэтмена.
Задача админа — обеспечение работоспособности mission critical служб на сервере. И даунтайм стремящийся к нулю. Реинсталл этому обычно не способствует. Значит это бэд практис.
А какие еще категории знаешь, кроме mission critical? По каким принципам классифицируют системы на те или иные категории? Или так, просто слово нравится?
Даунтайм, стремящийся к нулю не построить на single-сервере с приходящим админом-фрилансером, как ты понимаешь
Даунтайм, стремящийся к нулю не построить на single-сервере с приходящим админом-фрилансером, как ты понимаешь
mission critical — падение службы приводит к потере бабла. Все остальное по фигу.
По уму не построить. Но надо к этому стремиться. Далеко ходить не надо. Статья перед глазами. Задачу можно было решить без даунтайма.
Запарился из пустого в порожнее переливать. Нравится реинсталить? Пожалуйста, не держу.
По уму не построить. Но надо к этому стремиться. Далеко ходить не надо. Статья перед глазами. Задачу можно было решить без даунтайма.
Запарился из пустого в порожнее переливать. Нравится реинсталить? Пожалуйста, не держу.
Я точно так же презираю тех, кто кидается реинсталлить не подумав, для справки.
Неверно ты понимаешь mission critical. Ты грубо описал business 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 -> нет бабла :) Я всего-лишь немного утрировал :)
Насчет 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, например. Прежде чем щеголять терминологией, нужно ее знать, я считаю.
failure of business operations!=нет бабла. Это значит «нет бизнеса». Простой mission critical системы в течение [amount of time, задается индивидуально] приводит к непоправимому ущербу репутации компании и прекращению бизнеса. В некоторых случаях это отзыв лицензии на деятельность, в некоторых (если нет необходимости в compliance) просто вынос компании с рынка.
Потеря бабла — это business operational (грубо — незначительная потеря бабла, без непосредственного урона репутации) и business critical (грубо — значительная потеря бабла и серьезный ущерб репутации).
А еще есть классы office productivity и core, например. Прежде чем щеголять терминологией, нужно ее знать, я считаю.
Да знаком я с этими терминами. В случае бизнеса все эти репутации и т.п. все равно в результате выливается в потери бабла, ибо в случае бизнеса все эти высокопарные «миссии» в конечном итоге сводятся к деньгам.
Теперь знаком, да. Не благодари, это была бесплатная консультация.
Вот как странно всё получается. Всё сводится к деньгам, а на резервирование / отказоустойчивость этих самых денег нет.
Разные ситуации бывают. Бывает что есть на резервирование, а бывает что только на резервное копирование.
До первого раза, как правило.
Обычное дело, я когда в хостинге работал часто слышал от клиентов «срочно все чините, мы миллионы теряем», слышал это в основном от клиентов на 100 рублевом шаред хостинге.
> mission critical — падение службы приводит к потере бабла
Ну, ведь то что описано — не mission critical, правда? ))
По поводу реинсталла: если был рут, систему можно выкидывать. На рабочей системе уж точно пытаться что-то фиксить толку ноль. Вот дампануть образ, что-бы попытаться найти изменения и причину — ок. А сразу после этого — реинсталл. Ну или разворачивание старого образа. И параллельный поиск причины для фикса.
Ну, ведь то что описано — не mission critical, правда? ))
По поводу реинсталла: если был рут, систему можно выкидывать. На рабочей системе уж точно пытаться что-то фиксить толку ноль. Вот дампануть образ, что-бы попытаться найти изменения и причину — ок. А сразу после этого — реинсталл. Ну или разворачивание старого образа. И параллельный поиск причины для фикса.
>Ну, ведь то что описано — не mission critical, правда?
Дословно — нет, но кто хотел, тот понял, что я имел в виду. У кого до фига свободного времени начинают цепляться к словам :(
Выкидывать систему сразу после потери девственности?
Приводить примеры из жизни, когда на живой системе приходилось выпиливать руткиты и прочую дрянь без остановки сервисов? Смысла не вижу. Я свое отношение к реинсталлу высказал. Просто надоело упоминание его как панацеи в некоторых книжках по ЗИ. Народ читает и потом применяет не думая при любом чихе.
Дословно — нет, но кто хотел, тот понял, что я имел в виду. У кого до фига свободного времени начинают цепляться к словам :(
Выкидывать систему сразу после потери девственности?
Приводить примеры из жизни, когда на живой системе приходилось выпиливать руткиты и прочую дрянь без остановки сервисов? Смысла не вижу. Я свое отношение к реинсталлу высказал. Просто надоело упоминание его как панацеи в некоторых книжках по ЗИ. Народ читает и потом применяет не думая при любом чихе.
> Владелец сервера негодует, т.к. сервер в дауне уже несколько часов
> Приводить примеры из жизни, когда на живой системе приходилось выпиливать руткиты и прочую дрянь без остановки сервисов
…
А по какому критерию определено, что руткитов/бэкдоров в системе больше не осталось? Чем вы версионируете все конфигурационные файлы (в т.ч. пользовательские, типа .bashrc) в системе? Есть отдельный лог сервер?
> Приводить примеры из жизни, когда на живой системе приходилось выпиливать руткиты и прочую дрянь без остановки сервисов
…
А по какому критерию определено, что руткитов/бэкдоров в системе больше не осталось? Чем вы версионируете все конфигурационные файлы (в т.ч. пользовательские, типа .bashrc) в системе? Есть отдельный лог сервер?
Лог-сервер, как правило, есть. Также в одной из конфигураций был сервер, на который обычным rsync'ом все бакапилось с сохранением всех логов работы. Бэкдоры были вычислены на 1-2-3. Изменения в конфигах — сравнение конфигов со старыми бакапами. Дырявые скрипты потом за вечер были найдены.
Ну и тулзы типа tripwire пока никто не отменял :)
Ну и тулзы типа tripwire пока никто не отменял :)
В таком mission critical тем более лучше не пытаться починить на лету. Автор статьи это продемонстрировал в эпизоде с segfault-ами. И нервы и время и деньги клиента потратил.
Надо поднимать, настраивать из бекапов и тестировать второй сервер, а потом их свапнуть. Если это действительно mission critical, то такой сервер уже должен быть в failover кластере ;)
А потом спокойно разбираться с первым.
Надо поднимать, настраивать из бекапов и тестировать второй сервер, а потом их свапнуть. Если это действительно mission critical, то такой сервер уже должен быть в failover кластере ;)
А потом спокойно разбираться с первым.
Автор продемонстрировал, что надо было проверить файлы, критичные для работы системы, а потом уже ребут жамкать, тем более что у него ночь была пока ждал kvm. То есть пошел по верному (на мой взгляд) пути, но допустил ошибку, из-за которой был большой простой.
Иногда дешевле бывает иметь бакапы в 2-3 точках, чем иметь в запасе кастомную железку, аренда которой может составлять не хилую долю в затратах хозяев бизнеса. Соотственно, восстановление с бакапов только в самом крайнем случае — если железка кирдыкнулась.
Иногда дешевле бывает иметь бакапы в 2-3 точках, чем иметь в запасе кастомную железку, аренда которой может составлять не хилую долю в затратах хозяев бизнеса. Соотственно, восстановление с бакапов только в самом крайнем случае — если железка кирдыкнулась.
Как-как. Сферически да в вакууме.
А не будет достаточно вместо переустановки системы просто установить новое ядро, и перезагрузившись с ним, полностью снести подозрительное старое?
В каждом конкретном случае надо оценивать время даунтайма и стоимость этого даунтайма для работодателя.
При больших объемах восстановление с бакапа может не один день занять. Можно конечно на бакапном поднять нужные сервисы в джейле, но велика вероятность, что нам еще и на бакапный сервер дряни натолкают.
По уму надо иметь удаленный бакап базы менеджера пакетов, плюс базу типа tripwire, либо если бакап идет rsync'ом, то его логи. Ну и плюс логгирование на удаленный защищенный хост.
При больших объемах восстановление с бакапа может не один день занять. Можно конечно на бакапном поднять нужные сервисы в джейле, но велика вероятность, что нам еще и на бакапный сервер дряни натолкают.
По уму надо иметь удаленный бакап базы менеджера пакетов, плюс базу типа tripwire, либо если бакап идет rsync'ом, то его логи. Ну и плюс логгирование на удаленный защищенный хост.
Бэкап, бэкап. Затем разворачиваемся с ноля, при необходимости заглядывая «как оно там было».
Задача — бакап 5 терриков, время восстановления больше суток. Каждый час даунтайма обходится работодателю в 30% з/п админа. Вопрос — через сколько часов даунтайма админ будет уволен?
У вас системный раздел и рабочие данные живут вместе? Не предусмотрено резервное копирование рабочих данных? Не делается резервное копирование настроек (хотя бы элементарное tar cjf etc.tar /etc)? Далее очевидные вещи перечислять не буду.
Не верится мне в такое, вы же опытный человек. Тем более что ваша иконка от знаменитой игры намекает на обстоятельность. Поэтому таскание терабайт представляется мне глубоко сомнительным занятием.
Не верится мне в такое, вы же опытный человек. Тем более что ваша иконка от знаменитой игры намекает на обстоятельность. Поэтому таскание терабайт представляется мне глубоко сомнительным занятием.
>У вас системный раздел и рабочие данные живут вместе?
У меня — нет. А вот на серверах, которые временами просят починить — сплошь и рядом.
У меня — нет. А вот на серверах, которые временами просят починить — сплошь и рядом.
Это да, сплошь и рядом. Но проблему надо решать и кто-то должен эту работу оплатить. Я предпочитаю отказаться от работы, где надо все сделать на скорую руку и тяп-ляп — потом начинаются вопросы и комментарии вида «а оно опять не работает», «недоделано» и т.д., хотя условия заранее обговаривались и все что я обещал было сделано. В общем «быстро дорого качественно — выберите два пункта» :-)
Отвечаю на вопрос. Админ будет уволен через -1 час, как допустивший руткит.
А вот новый админ уволен за даунтайм сервера уже не будет.
А вот новый админ уволен за даунтайм сервера уже не будет.
Это когда своё. А клиенты-владельцы хотят экономить. Приходится убеждать страшными историями.
Cool story, bro!
Ничего не понял, но сюжет захватывает. В конце happy end ))
Загурзились с liveusb/livecd и запустили бы debsums…
Класс!
Захватывающий IT детектив! Вражеский резидент был вычислен и выведен из игры, эскалации назревавшего скандала не произошло.
Но как бы там ни было, субъективно полезная информация.
Но как бы там ни было, субъективно полезная информация.
Так же пострадал очень давно, лет наверное с десять назад.
Мне повезло больше, я перед перезагрузкой нашел все бинарники измененные после определенной даты и все их заменил на версии из пакетов. Предварительно собрав своё окружение из всех системных утилит в отдельную директорию и пользуясь только ей поубивав все из памяти.
Я так смотрю за десять лет подход к рутованию серверов не изменился, ничего нового не придумали…
Меня тогда поимели отснифав пароль от _телнета_ (десять лет назад, напоминаю, даже свитчей ещё не было в нашей локалке!), кто-то из соседей по сети…
Вот она кстати обратная сторона опен сурса, ещё тогда подумал я, нахлобучить систему могут так, что понять что к чему можно будет только если ты намного выше среднего разбираешся в системе, а не просто тыкаешь мышкой в Gnome. В отличие от винды, где 95% проблем решается прогоном антивируса из safe-mode.
Мне повезло больше, я перед перезагрузкой нашел все бинарники измененные после определенной даты и все их заменил на версии из пакетов. Предварительно собрав своё окружение из всех системных утилит в отдельную директорию и пользуясь только ей поубивав все из памяти.
Я так смотрю за десять лет подход к рутованию серверов не изменился, ничего нового не придумали…
Меня тогда поимели отснифав пароль от _телнета_ (десять лет назад, напоминаю, даже свитчей ещё не было в нашей локалке!), кто-то из соседей по сети…
Вот она кстати обратная сторона опен сурса, ещё тогда подумал я, нахлобучить систему могут так, что понять что к чему можно будет только если ты намного выше среднего разбираешся в системе, а не просто тыкаешь мышкой в Gnome. В отличие от винды, где 95% проблем решается прогоном антивируса из safe-mode.
«Кто там говорил, что нет под Linux вирусов?»
решето :)
Автор достоин уважения.
Я бы наверное сдался, с надежной только на суппорт.
Я бы наверное сдался, с надежной только на суппорт.
А я бы снял образ, снес все нах и сделал с нуля. Да, наверное дольше, но как-то спокойнее. А поковыряться потом можно было бы, спокойненько.
И на следующий день снова бы получили сервак, хакнутый через дырку в одном из скриптов сайта?
Потом снова снимать образ и ставить все с нуля? На какой итерации процесс надоест? :))
Потом снова снимать образ и ставить все с нуля? На какой итерации процесс надоест? :))
на первой, если хватит мозгов после настройки снять второй образ :)
А при чем тут дырка в скриптах сайта, м? По-твоему, ГГ быстренько сделал ревью всего кода сайта?
а. Мы вроде на «ты» не договаривались пока переходить :)
б. Это просто пример. После восстановления можно получить снова сломанный сервер. Ибо дыра может быть вообще не в системе, а юзерских скриптах, конфигах и еще куче того, что мы подтянули с бакапа.
Я считаю, что надо вычищать систему, а потом искать как забрались. То бишь не считаю реинсталл панацеей / способом решить проблему.
б. Это просто пример. После восстановления можно получить снова сломанный сервер. Ибо дыра может быть вообще не в системе, а юзерских скриптах, конфигах и еще куче того, что мы подтянули с бакапа.
Я считаю, что надо вычищать систему, а потом искать как забрались. То бишь не считаю реинсталл панацеей / способом решить проблему.
Очень интересно читалось. Боевик без единой постельной сцены.
> Кто там говорил, что нет под Linux вирусов?
Ну правильно, кто-то нашел эксполит (в необновленном дистрибутиве-то!), кто-то собственноручно загрузил его и настроил на правильную работу. Все как обычно. Массовых самозаражений, как раньше в винде было, нет.
Ну правильно, кто-то нашел эксполит (в необновленном дистрибутиве-то!), кто-то собственноручно загрузил его и настроил на правильную работу. Все как обычно. Массовых самозаражений, как раньше в винде было, нет.
Забавно. Кто то еще использует такие допотопные руткиты.
интересно, что вирусняк под линуксом часто легко спалить по дате изменения файлов
буквально пара строк и чёрт его знает как действовал бы автор
а вообще конечно здорово, что победа :)
буквально пара строк и чёрт его знает как действовал бы автор
а вообще конечно здорово, что победа :)
Спасибо за сообщение. Мы проанализируем инцидент для анализа действий и ответов сотрудников.
В любом случае мы проведем дополнительное обучение системных инженеров и администраторов диагностике работы дисковой подсистемы.
Отдельно отмечу, что работы по администрированию со сложно прогнозируемым результатом, как правило оцениваются в один час, и лишь после определения проблемы уточняется стоимость. В случае если определить проблему не удается дополнительные часы не оплачиваются.
В любом случае мы проведем дополнительное обучение системных инженеров и администраторов диагностике работы дисковой подсистемы.
Отдельно отмечу, что работы по администрированию со сложно прогнозируемым результатом, как правило оцениваются в один час, и лишь после определения проблемы уточняется стоимость. В случае если определить проблему не удается дополнительные часы не оплачиваются.
Нет лучше резюме, чем такая статья. How to hire you, Master?
Почти как в песне: «она читала жизнь как роман, а он оказался повестью»
Очень интересно читается, и главное, познавательно :)
Я наверное в такой ситуации сам бы не разобрался, пришлось бы консультироваться с более опытными знакомыми.
Я наверное в такой ситуации сам бы не разобрался, пришлось бы консультироваться с более опытными знакомыми.
Самое главное узнать не удалось — каким образом взломщик получил доступ к системе, возможно дырка осталась незакрытой.
Странно, что ни кто до сих пор не спросил о системном окружении. Видимо от офигения.
Но я таки уточню, что за ОСь стояла?
Но я таки уточню, что за ОСь стояла?
Поднимаю сетевой интерфейс, присваиваю IP, и скачиваю deb пакет mount для lenny.
Debian, смею предположить.
Debian, смею предположить.
«Ведь fdisk никогда и не умел работать с программным raid.»
Что за чушь?! фдиску пофигу какое блочное устройство ему подали, если весь /dev/md0 был расформатирован под ext3, то ессесно там нет таблицы разделов, только и всего.
Не знаю как с apt, но наверняка также как с rpm там есть verify и все подмененные пакеты было бы видно в одну комманду.
Что за чушь?! фдиску пофигу какое блочное устройство ему подали, если весь /dev/md0 был расформатирован под ext3, то ессесно там нет таблицы разделов, только и всего.
Не знаю как с apt, но наверняка также как с rpm там есть verify и все подмененные пакеты было бы видно в одну комманду.
Еще можно настроить 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.
Грамотные злоумышленники после получения рута первым делом чистят за собой следы в этих файлах. А многие администраторы и не знают, как оно работает.
Кстати, первое предложение из 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.
По-ходу чтения в голове возник образ рыбы в воде. Очевидно, автор в своей стихии.
у нас тоже был руткит на MX'е из-за вот этого бага www.securityfocus.com/bid/45308
Мне кажется это оно blog.sesse.net/blog/tech/2011-11-15-21-44_ebury_a_new_ssh_trojan.html
Видимо повальный сегфолт и был результатом некорректной работы вируса.
>> Денег еще не просил. Да и за что? Основную задачу то не выполнил =)
Дружище, ты за невыполненную задачу и не проси. Просто объясни, от какого зла ты их спас и сколько они аптайма бы потеряли еще с переустановкой всей системы. И предложи самим определить тебе вознаграждение.
Дружище, ты за невыполненную задачу и не проси. Просто объясни, от какого зла ты их спас и сколько они аптайма бы потеряли еще с переустановкой всей системы. И предложи самим определить тебе вознаграждение.
очень хорошая история, только не понравилось окончание с клиентом. Это почему же денег не просили? Вы что же, свою работу не цените? Экзим настроить почти любой сможет, а вот исправить такую проблему — очень-очень мало людей.
Эх кармы не хватае. В общем вам +1 и «респект»!
Ну и так по мелочи, как уже советовали chkrootkit и rkhunter. Но я бы еще пошуршал по логам, мож дырка на сайтах (часто такое).
Ну и так по мелочи, как уже советовали chkrootkit и rkhunter. Но я бы еще пошуршал по логам, мож дырка на сайтах (часто такое).
Скандалы, интриги, расследования…
зашел на инфобокс www.infobox.ru/vps/
там ни слова про kvm
может афтор игрался где-то в другом месте? У себя дома например?
там ни слова про kvm
может афтор игрался где-то в другом месте? У себя дома например?
Ты смотришь аренду виртуальных серверов.
help.infobox.ru/32-14#x1232
help.infobox.ru/32-14#x1232
Какими средствами можно проверить систему на руткиты?
Проделанная работа автора вызывает уважение.
Печально только что за его труды максимум, что он получит, это, спасибо.
Сам как то давно попадал примерно в такую же ситуацию, но сервер был мой и был тоже на дебиане, какое то злополучное сходство ).
Печально только что за его труды максимум, что он получит, это, спасибо.
Сам как то давно попадал примерно в такую же ситуацию, но сервер был мой и был тоже на дебиане, какое то злополучное сходство ).
Переустанавливаю openssh-server и openssh-client.
Набрал «reboot» и тут на тебе: десятки segmentation fault. Волосы начинают седеть, руки трястись. В общем я думаю многие представляют мою ситуацию. Как говорится «если работает — не ТРОЖЬ!», но после обнаружения проникновения пришлось наложить обновления и перезагрузиться.
«А что если файлы, которые вызывают сегфолт, подмененные?». Сказано сделано.
Проверяю файлы в /bin/ и вижу следующую картину
Честно говоря, не понимают за что топику столько плюсов. Автору как Linux админу — незачёт. IMHO, ситуация более чем тривиальная. Или на Хабре нынче уже дефицит вменяемых сисадминов?
Для начала потрудились бы проверить целостность установленных пакетов через debsums — можно убить всех зайцев сразу. Когда более-менее понятно, что система неким кривым руткитом/трояном уже изрядно испорчена, и при наличии KVM (впрочем, при наличии у хостера remote boot через PXE, это даже не требуется) стоило загрузиться в сторонний ремонтный дистрибутив, подмонтировать раздел и заняться чисткой.
Теперь остаётся заменить все модифицированные файлы оригинальными. Скачиваю нужные пакеты и устанавливаю через dpkg -i *deb
aptitude reinstall?
В том, что большинство серверов, не обслуживаемых постоянным админом, апдейтятся как попало, если вообще апдейтятся хоть раз с момента установки до первого хака, нет ничего удивительного. Nobody cares.
Отличный пост. Читал практически открыв рот.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Нифига себе сходил за хлебушком, или история одного взлома