Пользователь
47,3
рейтинг
15 ноября 2011 в 21:24

Разработка → Нифига себе сходил за хлебушком, или история одного взлома

Всё началось с того, что ко мне (как к фрилансеру) обратились за помощью и попросили настроить exim4 так, чтобы почтовая рассылка не попадала в спам. Даже заботливо ссылку прислали на замечательную статью.

Работы на пару часиков включая обновление DNS, но не тут то было. Залогинившись под рутом я включил свой любимый screen по привычке командой screen -x и лицезрел прелюбопытнейшее действо в любимой многими папке /dev/shm. Злоумышленник не удосужился прикрыть сессию screen, либо всё еще работал в ней. И тут начинается квест:

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



wget http://ravenul.zzl.org/it/noi/up/8.txt
mv 8.txt list.txt
php lol.php
php lol.php
netstat -an | grep :22
w
rm -rf list.txt
w
rm -rf .x
netstat -an | grep :22


Судя по всему рассылал спам и запускал некий файл ".x" (или это была папка?), а еще проверял ssh соединение. Там же лежал архив с php скриптом lol.php, который я к сожалению забыл сохранить.

Вывод команды last и who не показали ничего сверхестественного, root сессий за месяц не было, что и подтвердил владелец сервера. Однако…
$ lsof -ni | grep ssh

показал established соединение с IP 172.190.125.14, которое я тут же прибил.

Обратил внимание на /usr/sbin/sshd
ls -la /usr/sbin/sshd
-rwxr-xr-x 1 root root 320724 Oct 11 23:29 /usr/sbin/sshd

Рядом с sshd валялся sshd0
ls -la /usr/sbin/sshd0
-rwxr-xr-x 1 root root 757356 Jul 31  2010 /usr/sbin/sshd0


Удаление файла ни к чему ни привело:
rm -f /usr/sbin/sshd
rm: cannot remove `/usr/sbin/sshd': Operation not permitted


Идем дальше
lsattr /usr/sbin/sshd
-u--ia------------- /usr/sbin/sshd
chattr -aui /usr/sbin/sshd
rm /usr/sbin/sshd
lsattr /usr/bin/* | grep -v -- '-------------------'
-u--ia------------- /usr/bin/ssh
chattr -aui /usr/bin/ssh
rm /usr/bin/ssh


Переустанавливаю openssh-server и openssh-client. Вроде всё хорошо, угрозы нет, больше ничего подозрительного не нашлось. Решил заодно обновить систему, да и tzdata старый был (привет Медведеву!). Проверил /etc/apt/sources.list и /etc/apt/sources.d. Все файлы в порядке, никаких левых строк, даты не менялись с год. И после apt-get update наложил все security обновления на Debian Lenny, включая новое ядро. Ну что. Нужно перезагружаться. Попросил на всякий случай KVM (как оказалось не зря) и начал ждать.

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

Короче говоря взял себя в руки, начал изучать в чем дело и загрузился в single user. Команда mount каждый раз при вызове вызывает segmentation fault, даже без параметров. Файловая система readonly, сделать ничего нельзя. /etc/fstab в порядке, df тоже работает. Команда date почему-то тоже сегфолтится. Запустил проверку диска (софтварный raid1) fsck.ext3 /dev/md0 — всё в порядке, никаких отклонений. В чем же дело? Тут я начинаю думать, что систему положил я, т.к. обновил пакет tzdata, который как раз таки связан со временем. И тут рвется DSL соединение с моим провайдером… Ребутаю модем — соединение поднимается, ну и славненько!

Владелец сервера негодует, т.к. сервер в дауне уже несколько часов, и решает написать тикет в суппорт «Инфобокса». Я же на измене, продолжаю ковыряться в системе. Самым вменяемым решением мне кажется перезагрузить машину и загрузиться с liveusb, чтобы диск был RW, а далее по обстоятельствам. Начал дебажить mount возможными на данный момент способами. gdb установлен не был, был лишь ldd, который ничего серьезного не показал и export LD_DEBUG=all, который тоже ничего сверхестественного не выявил. Сегфолт тупо начинался после инициализации всех библиотек. Тут KVM мне говорит, что его отключили. Ясно, суппорт подбежал. Ушел от ноутбука и начал думать дальше…

Пока стоял и дышал свежим воздухом, ко мне в голову забежал очень образованный таракан и сказал «А что если файлы, которые вызывают сегфолт, подмененные?». Сказано сделано. Жду что скажет клиент насчет тикета суппорту. Через несколько минут он пересылает мне ответ суппорта:

Повреждена таблица разделов, экспресс-методами восстановить ее не представляется возможным.

Если хотите, мы можем привлечь наших системных администраторов (стоимость работ составляет 870 рублей в час) для восстановления.

Либо же Вы можете это сделать самостоятельно. В таком случае рекомендуем воспользоваться Gpart (http://packages.debian.org/ru/sid/gpart)


Хрена себе подумал я… Говорю клиенту, что не может такого быть, т.к. fsck произвел проверку диска и никаких нарушений в файловой системе не выявил. Клиент пишет ответ суппорту, а в это время возвращается доступ к KVM, где я вижу всё те же тщетные попытки вызвать mount, hdparm, который в системе не установлен, и работа с fdisk.

Последняя же вывела ни что иное как:
$ fdisk -l
 
Disk /dev/sda: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x000f0571
 
   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1       18480   148440568+  fd  Linux raid autodetect
/dev/sda2           18481       19457     7847752+  fd  Linux raid autodetect
 
Disk /dev/sdb: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00000000
 
   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *           1       18480   148440568+  fd  Linux raid autodetect
/dev/sdb2           18481       19457     7847752+  fd  Linux raid autodetect
 
Disk /dev/md0: 152.0 GB, 152003018752 bytes
2 heads, 4 sectors/track, 37110112 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
Disk identifier: 0x00000000
 
Disk /dev/md0 doesn't contain a valid partition table
 
Disk /dev/md1: 8036 MB, 8036024320 bytes
2 heads, 4 sectors/track, 1961920 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
Disk identifier: 0x00000000
 
Disk /dev/md1 doesn'
t contain a valid partition table


Вот на основе последних Disk /dev/md0 doesn't contain a valid partition table суппорт и выяснил, что проблема то оказывается в таблице разделов. Действительно, как я раньше не догадался. Ведь fdisk никогда не видел таблицы разделов программного raid. Отписываю все мои мысли клиенту и начинаю разрабатывать коварный план того самого таракана. Представляю чем бы закончилась эпопея суппорта и сколько бы она заняла, согласись клиент на их помощь. Да и сумму подсчитать не сложно.

Смотрю на дату изменения /bin/mount — время последней загрузки сервера. Перезагружаюсь, опять проверяю дату — время последней загрузки сервера. Странно. Значит что-то при загрузке модифицирует этот файл и с этим «что-то» нужно что-то делать.

/tmp — в readonly. Чтобы загрузить файл на сервер, нужна файловая система с правом записи. Вспоминаю о /dev/shm. Поднимаю сетевой интерфейс, присваиваю IP, и скачиваю deb пакет mount для lenny. Распаковываю, запускаю — вуаля! Работает! Перемонтирую файловую систему, теперь она RW. Дело пошло!

Проверяю файлы в /bin/ и вижу следующую картину:
ls -latr /bin
-rwxr-xr-x  1 root root  96408 Nov 15 18:11 vdir
-rwxr-xr-x  1 root root  30896 Nov 15 18:11 pwd
-rwxr-xr-x  1 root root  30712 Nov 15 18:11 ping6
-rwxr-xr-x  1 root root  24252 Nov 15 18:11 nc.traditional
-rwxr-xr-x  1 root root   8612 Nov 15 18:11 mountpoint
-rwxr-xr-x  1 root root  68208 Nov 15 18:11 mount
-rwxr-xr-x  1 root root  32244 Nov 15 18:11 mknod
-rwxr-xr-x  1 root root  39144 Nov 15 18:11 loadkeys
-rwxr-xr-x  1 root root  17244 Nov 15 18:11 kill
-rwxr-xr-x  1 root root   9764 Nov 15 18:11 fgconsole
-rwxr-xr-x  1 root root  26216 Nov 15 18:11 false
-rwxr-xr-x  1 root root   8524 Nov 15 18:11 dmesg
-rwxr-xr-x  1 root root  96408 Nov 15 18:11 dir
-rwxr-xr-x  1 root root  51988 Nov 15 18:11 dd
-rwxr-xr-x  1 root root  59148 Nov 15 18:11 date
-rwxr-xr-x  1 root root  49440 Nov 15 18:11 chgrp
-rwxr-xr-x  1 root root  30956 Nov 15 18:11 cat
-rwxr-xr-x  1 root root  12252 Nov 15 18:11 bzip2recover


Причем дата изменения файлов меняется каждые 3 минуты и 10 секунд. Начинаю просматривать crontab'ы, ничего не нахожу. Отловить lsof'ом какой процесс изменяет файлы не получается. Вывожу ps auxww и вижу, что висит некий процесс cat /sys/class/net/lo/operstate

Скачиваю пакет с утилитой kill, переименовываю файл /bin/cat в /bin/cat_ и прибиваю процесс. Файлы перестают модифиццироваться. Победа. Теперь остаётся заменить все модифицированные файлы оригинальными. Скачиваю нужные пакеты и устанавливаю через dpkg -i *deb, предварительно проверив дату создания самого dpkg. После всех сделанных замен, скрестя пальцы, ввожу reboot и наблюдаю за окном KVM. Загрузка проходит успешно, сайт работает. Далее провожу сканирование скопированных мною зараженных файлов с помощью clamav и обнаруживаю Linux.RST.B-1 FOUND. Кто там говорил, что нет под Linux вирусов? Кстати 2001 года вирус

Сканирование sshd и ssh ни к чему не приводят. Видимо это просто модифицированные ssh и sshd. Первый скорее всего отсылает логин и пароль при успешном подключении к серверу, второй скорее всего пускает на сервер всех с определенным паролем. Сейчас копать эти файлы нет сил, но желающие могут их скачать и покопаться: zalil.ru/32063611

P.S. Если в командах что-то не так, то прошу прощения, многие из них писал на память. Настраивать exim4 тоже отпало желание. Денег еще не просил. Да и за что? Основную задачу то не выполнил =)
P.P.S. Привет Infobox'у!
@kay
карма
178,0
рейтинг 47,3
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (147)

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

      А по теме, вышло очень интересное расследование с массой познавательной (для меня) информации.
      • +83
        Уж чего-чего, а потрахался ГГ изрядно, одна сплошная постельная сцена с перерывами на перекур. )
        • +4
          судя по состоянию автора скорее с перекурами на перерыв
      • +3
        Денег-то не за что просить — вот и постельная сцена :)
      • –1
        А я строчки после 10-й начал читать как смотрел бы фильм на китайском — действо занятное, общий смысл понимаешь, а что сказал вот этот дядя той тебе — хз ))
    • +1
      сюжет захватывающий :D
  • +7
    интересная история, а как проникли на сервер по логам узнать не удалось?
    • +6
      Не знаю, до этого у клиента был другой сисадмин. Возможно в этом и дело.
      • +6
        По поводу «другого сисадмина»:
        Я часто спрашиваю как именно уволили старого сисадмина перед тем как начать менять пароли и доступ для клиента.
        • +1
          А ещё лучше спрашивать у самого сисадмина.
          • 0
            Лучше, но малореально в этих случаях.
  • +155
    Абсолютно ничего не понял, но эмоции испытал сильные ))
    • +2
      То же самое, но несколько команд вспомнил из молодости, когда увлекался.
  • +6
    chkrootkit`ом прогони на всякий пожарный…
    И да, спасибо за довольно интересную историю.
  • +86
    Общее правило таки гласит — обнаружил рутование? Ставь чистую систему и накатывай сайты с нуля.
    • +7
      Надо же, я так и сделал, когда пришлось, не зная правила. Интуиция, что ли?
      • +35
        Здравый смысл.
    • +8
      По аналогии для винды и юзерских компов — система выдает непонятную ошибку при загрузке? Переустановите ее нафик :)
      Не. Не наш метод. Особенно в случае с чужим серваком потом выяснится, что где-то валялись и работали кастомные конфиги или специально для нас собранные службы и т.п. Потом недели две отлавливать что и почему не работает или работает не так как задумано, выяснять что забыли сдернуть со старой системы…
      У нормальных пакетных менеджеров всегда есть возможность проверить файлы для всех установленных пакетов. Соответственно — собираем список, думаем, восстанавливаем. Дальше обновляемся, ищем дыры или оставленные хакером бэкдоры и прочие стандартные мероприятия проводим.
      А так в целом — да, переустановить проще чем напрягать мозги и искать причину засора :)
      • +8
        Аналогия чуть-чуть не та :) Эти подменённые файлы могут оказаться только вершиной руткита. Всё остальное может быть в ядре в виде изменённых модулей. Через ядро можно всё очень хорошо замаскировать. Опенсорс же ;)

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

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

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

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

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



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

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

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

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

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

            А вот новый админ уволен за даунтайм сервера уже не будет.
    • +2
      Это когда своё. А клиенты-владельцы хотят экономить. Приходится убеждать страшными историями.
  • НЛО прилетело и опубликовало эту надпись здесь
    • +1
      Жизнь показывает, что уже оказанная услуга ничегг не стоит. Хотя конечно надеюсь, что автору заплатят.
  • –1
    Cool story, bro!

  • +4
    Ничего не понял, но сюжет захватывает. В конце happy end ))
  • +26
    Загурзились с liveusb/livecd и запустили бы debsums…
  • 0
    Класс!
  • +1
    Захватывающая история! Вопрос к гуру — если я арендую ВПС, и понимаю систему минимально на уровне «установить nginx по мануалу, настроить все что надо через ISP Manager», как проще всего проверить есть ли на сервере какая-то зараза, или нет?
    • +4
      Ну сканированием clamscan /
      Или как подсказали в комментариях chkrootkit
    • +1
      Один из методов это проверка целостности — запоминаем контрольные суммы всех важных файлов на чистой системе и периодически отслеживаем изменения. Для этого есть много инструментов, например tripwire.
  • НЛО прилетело и опубликовало эту надпись здесь
  • +3
    Захватывающий IT детектив! Вражеский резидент был вычислен и выведен из игры, эскалации назревавшего скандала не произошло.
    Но как бы там ни было, субъективно полезная информация.
  • +2
    Так же пострадал очень давно, лет наверное с десять назад.
    Мне повезло больше, я перед перезагрузкой нашел все бинарники измененные после определенной даты и все их заменил на версии из пакетов. Предварительно собрав своё окружение из всех системных утилит в отдельную директорию и пользуясь только ей поубивав все из памяти.
    Я так смотрю за десять лет подход к рутованию серверов не изменился, ничего нового не придумали…
    Меня тогда поимели отснифав пароль от _телнета_ (десять лет назад, напоминаю, даже свитчей ещё не было в нашей локалке!), кто-то из соседей по сети…
    Вот она кстати обратная сторона опен сурса, ещё тогда подумал я, нахлобучить систему могут так, что понять что к чему можно будет только если ты намного выше среднего разбираешся в системе, а не просто тыкаешь мышкой в Gnome. В отличие от винды, где 95% проблем решается прогоном антивируса из safe-mode.
    • 0
      Автор и написал о том, что вирус 2001 года =) Так что да. Как раз 10 лет.
  • +33
    «Кто там говорил, что нет под Linux вирусов?»

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

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

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

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

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

    Debian, смею предположить.
    • +9
      Опубликую ответ на комментарий мимо и в дубликате. Обращаться к BSoD'у.
      • 0
        >>Обращаться к BSoD'у.
        Это тоже самое что и к /dev/null?
  • 0
    История отличная, хоть я и мало понял :) Печально то, что зачастую такой сервис и саппорт почти везде, и за это хотят неплохие деньги :(
  • 0
    «Ведь fdisk никогда и не умел работать с программным raid.»

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

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

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

        если файл «левый» то будет что-то типа
        dpkg-query: no path found matching pattern /bin/bash.evil.
  • 0
    Еще можно настроить rkhunter, он будет мониторить, какие файлы изменились.
  • 0
    По хорошему, ставим Tripware, делаем снимок файлов системы на данный момент и уведомляем себя по почте обо всех изменениях в файлах.
  • 0
    А сколько таких историй тонут в потоке отчаяния человека, который не смог
  • 0
    Сразу полез смотреть профиль — не мой ли провайдер:)
  • 0
    Хочу объяснить, почему «вывод команды 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.
    • –1
      > А многие администраторы и не знают, как оно работает.

      Я сомневаюсь, что таких людей вообще можно называть администраторами.
      • 0
        Вы не поверите, каких замечательных людей иногда называют администраторами :) Хотя… Вы-то как раз наверное и поверите.
  • +1
    По-ходу чтения в голове возник образ рыбы в воде. Очевидно, автор в своей стихии.
  • 0
    у нас тоже был руткит на MX'е из-за вот этого бага www.securityfocus.com/bid/45308
  • 0
  • 0
    Видимо повальный сегфолт и был результатом некорректной работы вируса.
    • 0
      Я тоже так думаю. Система то новая, а вирус 2001 года. Если б не сегфолты может ничего бы и не заметил. Зато теперь другим будет наука.
  • +3
    >> Денег еще не просил. Да и за что? Основную задачу то не выполнил =)

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

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

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

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

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

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

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

    aptitude reinstall?

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

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