21 декабря 2016 в 14:36

Опыт работы со взломанным сервером из песочницы



Хочу поделиться своим опытом начинающего системного администратора. Так уж случилось, что мой первый блин комом — это было предложение заняться инфраструктурой в одной маленькой компании. Ситуация сложная. Никакой автоматизации, все вручную и по принципу: работает — не трогай, а если не работает и никто не заметил, то считай, что работает. Предыдущий сотрудник не оставил почти никакой документации. Вот доступ к серверам, кофемашина — там, вроде всё…

Опыт первый: маленькие симптомы большой проблемы


Было решено начать с инвентаря. Всё размещено у крупного публичного оператора: по нескольку виртуальных машин на арендованный сервер с предустановленным гипервизором Xen:


Эксперты могут со мной не согласится, но я нахожу KVM гораздо удобнее Xen для элементарной виртуализации инфраструктуры маленьких предприятий. Xen может привлечь тех, кто предпочитает графический интерфейс управления. Но, к сожалению, возможности данного графического интерфейса довольно ограниченны, а интерфейс управления командной строки Xen сильно уступает по своей простоте KVM/QEMU в случае, если надо зайти за рамки стандартных манипуляций виртуальных машин. Но похоже, что данный вопрос не особо волновал моего предшественника, управлявшего системами с наименьшим приложением усилий. Как оказалось, всё было установлено по умолчанию, а именно: сервера работали на устаревшей Ubuntu 12.4 LTS, вместо привычных для таких целей Debian.



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



Тут следует сказать, что любой сисадмин, в душе, должен быть немного детектив. Нужно уметь замечать малейшие аномалии, за которыми могут скрываться большие проблемы. В данном случае мое внимание привлекли странные файлы с привилегией root. “Наверное нас хакнули”, пожал плечами коллега, не приняв мое беспокойство всерьез. Простых подозрений было недостаточно, и мы решили пока ничего особенного не делать. Архивируем подозрительные файлы, меняем пароль пользователя и продолжаем инвентарь.

Опыт второй: не злите злых хакеров


А если разозлили, то готовьтесь к последствиям.

“Что-то с сервером…”, наверное одно из самых неприятных сообщений, которое может получить системный администратор по пути на работу. Особенно, если речь идёт о новой работе. Ускоряя шаг, проверяем ситуацию с телефона:


Придя на работу, натыкаемся на комитет из взволнованных сотрудников. Ситуация критическая. Сервер недоступен, но доступен его гипервизор через Xen. Становится ясно, что сервер работает, но полностью утеряна связь с Интернет:



Значит, проблема в маршрутизации. Лезем к оператору:



Заодно находим саму проблему:



Ну, теперь уж точно: сомнений нет — нас взломали! И похоже, что взломщик, огорченный нашей предыдущей интервенцией, решил, раз его обнаружили — терять уже нечего и использовал наш сервер для сетевой атаки. Ладно, зато теперь мне разрешат настроить всё по-своему.

Первым делом — файрвол:



Далее, меняем всем пароли:



Сохраняем и трём ключи ssh. Позже попросим всех пользователей генерировать новые. Сохраняем, для сравнения: чтобы особенно ленивые пользователи не могли использовать старый, возможно скомпрометированный доступ:



И, кстати, больше никакого доступа с паролем: только ключи ssh!

Теперь нас никто не застанет врасплох. Устанавливаем слежку за теми, кто входит в систему. Для этого добавляем в /etc/pam.d/sshd исполнение простого скрипта нотификации (loginlog):



А также подглядываем за ключами:



Hу и под конец, можно установить auditd — это демон, способный отслеживать всё, что происходит на сервере. Для этого достаточно двух строк в /etc/audit/audit.rules:



На сегодня всё. Пишем сотрудникам о том, что в городе новый шериф об изменениях по соображениям безопасности. А завтра постараемся внедрить Nagios или даже начать переезд на Debian. Надеюсь, взломщик больше не пройдет. Или пройдет?
Andrej Silin @asilin
карма
16,0
рейтинг 0,0
Системный администратор
Самое читаемое Администрирование

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

  • +5
    Хорошая статья. Вопрос только, удалось выяснить причину взлома?
    • 0
      К сожалению, нет. Но я решил поискать уроки кибер-безопасности для повышения квалификации.
      • НЛО прилетело и опубликовало эту надпись здесь
  • +12
    > Сохраняем и трём ключи ssh. Позже попросим всех пользователей генерировать новые. Сохраняем, для сравнения: чтобы особенно ленивые пользователи не могли использовать старый, возможно скомпрометированный доступ

    Жуть какая, там-же открытые ключи, их хоть на заборе писать можно. Понятно, что удалить наверно надо, вдруг злоумышленник свои подкинул, но менять-то зачем? Как можно по имеющемуся открытому ключу что-то скомпрометировать, кроме самого себя (подложив эти ключи себе на сервер, например)?

    Ну и если взлом прошел с участия рута, тут уже может быть всё бесполезно, sshd заменен на не родной с бэкдором, загружен модуль ядра с руткитом и т.д. и т.п. Обычно после этого просто делают полную переустановку, т.к. аудит всей системы дело не самое простое.
    • +1
      Было подозрение, что использовался приватный ключ одного из сотрудников и я попросил всех генерировать новые пары приватный/публичный ключ.
  • 0
    А зачем переходить с Ubuntu на Debian, если это делается без полной переустановки всего, а простым обновлением? Или вы хотите старые сервера выкинуть, а новые поднять и переустановить?
  • +2
    Команды бы да не картинками бы. =)
    • +7

      атата, все правильно! нельзя бездумно копипастить команды из интернета. А так перенаберешь руками, может хоть задумаешься =)

      • +1
        и когда руками набираешь есть возможность ошибиться. И когда копипастишь тоже.

        Однако перепечатать с картинки юные падаваны могут куда хуже, чем контрол копи контрол паст, ведь они всё равно будут так делать (бездумно копировать команды).
        • +3
          Я как-то раз помогал одному человеку, который ничего не соображал в Linux, подсказывая команды. Долго не мог понять, почему у него не работает, оказалось, что он втихаря исправлял то, что считал у меня опечатками. Например, на сервере был лог ошибок scanerr.txt (от слов «scan errors»), я прошу его показать мне вывод «cat scanerr.txt», он говорит, что файл не найден, а уже потом выясняется, что он ввёл не «cat scanerr.txt», а «cat scanner.txt» — и ещё оправдывался, мол, «правильно же scanner». Однажды у него случилось что-то с MySQL, мне было ужасно лень разбираться, к тому же, я забыл, что у него за дистрибутив. Я ему говорю: «в зависимости от дистрибутива и его версии, либо service mysql[d] restart, либо systemctl restart mysql[d]». Через некоторое время он мне на радостях пишет: «то, что ты написал, не подошло, но методом тыка я понял, как это сделать — reboot mysql». Не факт, что точно так было, но суть именно такая, в общем, ребутнул себе весь сервер :)
    • +1
      rm -rf /
      • +1
        «Защита сервера от любого взлома. С гарантией»
      • +1
        --no-preserve-root ^_^
  • +1
    Сохраняем, для сравнения: чтобы особенно ленивые пользователи не могли использовать старый, возможно скомпрометированный доступ

    Ах ты ж хитрая этасамая!


    А если серьезно, то у меня вопрос: какой метод организации ключей считается правильным™?
    На данный момент у меня на дев машинке есть один ssh ключ, который я использую везде: на других дев-серверах, на гитхабе, на домашнем НАСе и т.д. И если вдруг системный администратор одной из машин, где у меня этот ключ провернет ваш фокус, то я вынужден буду сгенерировать новый ключ и пободавлять его везде в authorized_keys, что неиллюзорно добавит мне головняка.
    Как надо делать? По ключу на каждую машину и хранить охапку ключей, которые прописаны в ~/.ssh/config для каждого сервера?

    • 0
      Я пользуюсь двумя ключами — один для серверов доступных снаружи и другой, для серверов доступных только внутри. Соответственно в случае компрометации «внешнего» ключа надо будет срочно поменять только его. А в случае компрометации «внутреннего» уровень опасности гораздо ниже, есть дополнительное время. И в обоих случаях работы меньше.
    • +1
      Я бы сказал охапку ключей, как например здесь. Но в действительности, все обходятся одним ключом, просто делая:

      ~ $ ssh-keygen -t rsa
      ~ $ cat .ssh/id_rsa.pub | ssh artyom@prod.mycompany.com  "cat >> .ssh/authorized_keys"
      ~ $ cat .ssh/id_rsa.pub | ssh artyom@test.mycompany.com  "cat >> .ssh/authorized_keys"
      ~ $ cat .ssh/id_rsa.pub | ssh artyom@docs.mycompany.com "cat >> .ssh/authorized_keys"
      

      • +6

        А вы знаете, есть такая программа — ssh-copy-id...

        • –3

          Вечный гемор с которой


          # ssh-copy-id 
          Could not open a connection to your authentication agent.
          no keys found
          
          • 0

            Ни разу не было геморроя. Научитесь читать маны и заодно узнаете про ssh-agent и команду ssh-add.

    • +1
      Лучше всего — использовать x509 ключи, с certificate authority, отзывом ключей и прочим блекджеком.
    • 0
      Я у себя сделал связку login + ssh-key из LDAP. Человек может сам себе поменять ключ в личном кабинете. Очень удобно. Ключи хранятся в одном месте, доступ до серверов сделан на основе групп
    • 0
      Можете попробовать SSSD.
    • 0
      EMC SSH — один раз настроить и больше не париться с заливкой ключей.
  • НЛО прилетело и опубликовало эту надпись здесь
    • +6

      Во-первых, интернет от себя защищать обязательно надо.


      Не только из гуманистических побуждений: ещё, скажем, чтобы ЦОД/провайдер не заметил от вас подозрительный трафик и не заблокировал от греха подальше, чтобы сети его самого уже в свою очередь не заблокировал какой-нибудь спамхаус. Ведь именно это, судя по всему, и произошло.


      Канал ftp-data только кажется закрытым. В ядре есть ftp-helper, пакеты пройдут со state=RELATED. Но я на месте автора снёс бы ftp к чертям, пусть sftp пользуют (который через ssh, с теми же самыми ключами).

      • НЛО прилетело и опубликовало эту надпись здесь
        • 0
          А зачем серверу подключаться наружу на 25-й порт (если на этом сервере не MTA)? Для передачи почты MTA нужно использовать 587 (smtp submission) + starttls либо 465 (smtps submission). Да, я за то, чтобы любая передача почты проходила через MTA и с аутентификацией.

          То же самое, серверу, как правило, нет потребности подключаться к 80 и 443, кроме отдельных адресов (обновления, внешние API).

          Если сервер сломали, но рута не получили (как это бывает в подавляющем большинстве случаев), такой файерволл практически сведёт проблемы на нет.

          А ещё, коллеги, tripwire и аналоги в помощь. Если сервер важный — на /etc /bin /sbin /usr/bin /usr/sbin /usr/lib и другие важные места — inotify-листенер, чтобы любые изменения там заведомо отсылались на внешний лог-сервер до того, как программы (возможно, уже с закладками) будут перезапущены.

          Смысл тут не в том, чтобы «не переустанавливать», а чтобы узнать о проблеме оперативно, и заодно иметь достаточно информации, чтобы определить, какая была лазейка.
    • +3
      Вы правы. Но, во первых, политика iptables готовилась на скорую руку. Во вторых, сервер был забанен за исходящий трафик, а я боялся, как заметил xforce, не найденных запакованных программ, способных возобновить атаку.
      • 0
        На предмет шеллов, работающих по 80 порту исследования проводили? Был опыт управления машиной по такой схеме. www-data добавлялся в sudo. Скрипт — прослойка между вебом и консолью стостоял из 1 строки
        • 0
          Спасибо, очень хороший совет на будущее. В тот момент, я об этом не подумал. Однако, на том сервере, Apache использовался исключительно как фронтальный диспетчер (через ProxyPass) на инстанции Tomcat.
          • +1
            Замените на nginx — быстрее, легче, надежднее.
  • +1
    В моем случае была подменена часть исполняемых файлов. Типа запускаешь cp, автоматически запускается еще один ssh сервер, поднимает тоннель наружу и ждет подключений.

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

    Стоит поискать все файлы которые не принадлежат пакетам, сравнить версии исполняемых файлов с тем, что лежит в репозитории.
    • 0
      угу dpkg --verify очень помогает. А «лишние» файлы либо переваливаются (например веб сайт, он же есть где-то «в эталоне» наверное), либо анализируются.

      А вообще у вас же виртуалка, можно было снять копию для развлечений, заблочить исходящие порты (чтобы OVH не гневался), навесить скриптов слежения (по смыслу как в статье + может что-то типа snort) и ждать гостя :)

      А в это время все остальные с чистой системой пусть работают.
      • 0
        В моем случае это был вполне железный сервер на котором крутился биллинг у мелкого местного провайдера.
        Простой потеря денег. Админ за месяц до того уволился, вроде добровольно.

        Было не очевидно, подхватит ли он лицензию на этот самый билинг после переустановки.
        Попросили спасти, удалось. Но было интересно.

        Изучение логов показало что был подобран пароль SSH, установлен какой-то известный зловред, машинка использовалась для рассылки спама. При гигабитном канале и шестнадцати ядрах рассылка шла весьма эффективно. :-)
  • 0
    на rpm дистрах есть хорошая команда — rpm -Va
    Можно проверить весь установленный софт.

    Посмотрите аналог на убунте.

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

    А вообще, если по хорошему — после взлома сервер надо ставить с нуля.
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        Возможно конечно подменить… но помимо того что уже сказали что систему надо в идеале переставить, если это не возможно то надо сделать так:
        1. Загрузиться с live-cd потом выполнить
        rpm --root /mnt/hacked_system_root_directory -Va

        2. Если видно что файлы(binary/lib) изменены, то переустановить пакет:
        rpm --root /mnt/hacked_system_root_directory -qf /пусть_до_измененного_файла_вместе_с_именем_файла
        rpm --root /mnt/hacked_system_root_directory -ivh --force имя-пакета.rpm

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

        Если много что надо так менять имеет смысл использовать yumdownloader + yum --installroot=/mnt/hacked_system_root_directory localinstall package1 package2…

      • –1
        Наверное можно подменить ядро, что бы когда rpm проверяет, то видит нормальные файлы, а когда происходит запуск, то запускаются вредоносные…
  • +1
    При таких взломах лучше переустановить всю систему полностью с нуля. Потому что вы не знаете, вдруг хакер установил еще какие то лазейки. Также могут быть незакрыты уязвимости по которым была совершена изначальная атака.
  • +6
    Как бы вы ни вычищали скомпрометированный сервер его нельзя считать на 100% вылеченным, только полная переустановка помогает.
  • +4
    Скомпрометированный сервер можно забэкапить для анализа, но в продакшин нельзя выводить как в принципе, ни какая чистка не является панацеей, я даже не говорю про демоны с бэкдорами, банальный запуск nc по крону или любым init скриптом и все ваши танцы вокруг ssh и аутентификации бесполезны. Если взломан root, только перенос на новый сервер и его уже защищать чистка ничего не гарантирует.
    • 0
      Согласен. Полностью вычистить заразу практически невозможно хотя бы из-за незнания того, что было затронуто. Можно, конечно, делать иногда полный бэкап системы, это, думаю, поможет.
      • 0
        Так вроди виртуалка, можно снапшоты делать раз в неделю + полный бэкап раз в месяц. В случае компрометации, подняли копию из последнего бэкапа без закладок, сделали diff систем, сравнили что изменилось, нашли все что было залито за время между бэкапами, попытались воссоздать атаку.
  • +1
    Рекомендую проверить систему rkhunter, Lynis и поискать скрытые процессы через unhide. Так же стоит посмотреть в сторону маленькой библиотеки snoopy (Snoopy Logger).
  • +1
    Как верно подметили — взломанный сервер годиться лишь для анализа… нужно поднимать новый и запускать в прод
  • 0
    При взломе сервера я бы лично взял все точно никак не зараженные данные, а потом начисто бы переустановил все и принял бы меры для предотвращения дальнейших атак. Жестоко, но все-таки тогда точно можно быть уверенным, что ничего опасного не осталось. На время переустановки можно, если этот сервер держит какой-либо сайт либо сервис, вывесить табличку «у нас технические проблемы, уходите отсюда».
    • +1
      Согласен. Это принципиальное решение, но лучше все-таки снести все и настроить хорошую защиту, чем пытаться что-то чистить. И такие потери времени работы сервера явно стоят дальнейших возможных сбоев, разборок или даже полного бана со стороны оператора
  • 0
    я как-то по неопытности на XOR.DDoS нарвался… вылечил, но все коллеги в один голос кричат что сервак следует форматнуть и по новой ставить
  • –1
    Debian ???? честно говоря странная аргументациям по выбору дистрибутива. Ставьте CentOS. По поводу переустановки с «нуля» — присоединяюсь к вышеизложенным рассуждениям о целесообразности поднятия «чистого» сервера — самый надёжный метод. Исследования можете потом проводить если время будет.
  • +1
    Как человек, имеющий 20-литний опыт в компьютерной безопасности и настройке систем, скажу, что с вероятностью в 92,8% уязвимость на сервере была специально устроена бывшим системным администратором (который вскользь упоминался в этой статье как ранее уволенный), который имел планы использовать сервер в своих целях как компенсацию за несправедливое увольнение.

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