[Из песочницы] Опыт работы со взломанным сервером
Хочу поделиться своим опытом начинающего системного администратора. Так уж случилось, что мой первый блин комом — это было предложение заняться инфраструктурой в одной маленькой компании. Ситуация сложная. Никакой автоматизации, все вручную и по принципу: работает — не трогай, а если не работает и никто не заметил, то считай, что работает. Предыдущий сотрудник не оставил почти никакой документации. Вот доступ к серверам, кофемашина — там, вроде всё…
Опыт первый: маленькие симптомы большой проблемы
Было решено начать с инвентаря. Всё размещено у крупного публичного оператора: по нескольку виртуальных машин на арендованный сервер с предустановленным гипервизором 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. Надеюсь, взломщик больше не пройдет. Или пройдет?
Комментарии (3)
GH0st3rs
21 декабря 2016 в 14:48
0↑
↓
Хорошая статья. Вопрос только, удалось выяснить причину взлома?21 декабря 2016 в 14:56
+2↑
↓
> Сохраняем и трём ключи ssh. Позже попросим всех пользователей генерировать новые. Сохраняем, для сравнения: чтобы особенно ленивые пользователи не могли использовать старый, возможно скомпрометированный доступЖуть какая, там-же открытые ключи, их хоть на заборе писать можно. Понятно, что удалить наверно надо, вдруг злоумышленник свои подкинул, но менять-то зачем? Как можно по имеющемуся открытому ключу что-то скомпрометировать, кроме самого себя (подложив эти ключи себе на сервер, например)?
Ну и если взлом прошел с участия рута, тут уже может быть всё бесполезно, sshd заменен на не родной с бэкдором, загружен модуль ядра с руткитом и т.д. и т.п. Обычно после этого просто делают полную переустановку, т.к. аудит всей системы дело не самое простое.
776166
21 декабря 2016 в 15:11
0↑
↓
А зачем переходить с Ubuntu на Debian, если это делается без полной переустановки всего, а простым обновлением? Или вы хотите старые сервера выкинуть, а новые поднять и переустановить?
