Хочу поделиться своим опытом начинающего системного администратора. Так уж случилось, что мой первый блин комом — это было предложение заняться инфраструктурой в одной маленькой компании. Ситуация сложная. Никакой автоматизации, все вручную и по принципу: работает — не трогай, а если не работает и никто не заметил, то считай, что работает. Предыдущий сотрудник не оставил почти никакой документации. Вот доступ к серверам, кофемашина — там, вроде всё…
Опыт первый: маленькие симптомы большой проблемы
Было решено начать с инвентаря. Всё размещено у крупного публичного оператора: по нескольку виртуальных машин на арендованный сервер с предустановленным гипервизором 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:
На сегодня всё. Пишем сотрудникам
Комментарии (51)
xforce
21.12.2016 14:56+12> Сохраняем и трём ключи ssh. Позже попросим всех пользователей генерировать новые. Сохраняем, для сравнения: чтобы особенно ленивые пользователи не могли использовать старый, возможно скомпрометированный доступ
Жуть какая, там-же открытые ключи, их хоть на заборе писать можно. Понятно, что удалить наверно надо, вдруг злоумышленник свои подкинул, но менять-то зачем? Как можно по имеющемуся открытому ключу что-то скомпрометировать, кроме самого себя (подложив эти ключи себе на сервер, например)?
Ну и если взлом прошел с участия рута, тут уже может быть всё бесполезно, sshd заменен на не родной с бэкдором, загружен модуль ядра с руткитом и т.д. и т.п. Обычно после этого просто делают полную переустановку, т.к. аудит всей системы дело не самое простое.
asilin
21.12.2016 15:53+1Было подозрение, что использовался приватный ключ одного из сотрудников и я попросил всех генерировать новые пары приватный/публичный ключ.
776166
21.12.2016 15:11А зачем переходить с Ubuntu на Debian, если это делается без полной переустановки всего, а простым обновлением? Или вы хотите старые сервера выкинуть, а новые поднять и переустановить?
ifaustrue
21.12.2016 16:32+2Команды бы да не картинками бы. =)
Dreyk
21.12.2016 16:32+7атата, все правильно! нельзя бездумно копипастить команды из интернета. А так перенаберешь руками, может хоть задумаешься =)
ifaustrue
21.12.2016 16:41+1и когда руками набираешь есть возможность ошибиться. И когда копипастишь тоже.
Однако перепечатать с картинки юные падаваны могут куда хуже, чем контрол копи контрол паст, ведь они всё равно будут так делать (бездумно копировать команды).
WST
21.12.2016 18:28+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». Не факт, что точно так было, но суть именно такая, в общем, ребутнул себе весь сервер :)
Dreyk
21.12.2016 16:32+1Сохраняем, для сравнения: чтобы особенно ленивые пользователи не могли использовать старый, возможно скомпрометированный доступ
Ах ты ж хитрая этасамая!
А если серьезно, то у меня вопрос: какой метод организации ключей считается правильным™?
На данный момент у меня на дев машинке есть один ssh ключ, который я использую везде: на других дев-серверах, на гитхабе, на домашнем НАСе и т.д. И если вдруг системный администратор одной из машин, где у меня этот ключ провернет ваш фокус, то я вынужден буду сгенерировать новый ключ и пободавлять его везде в authorized_keys, что неиллюзорно добавит мне головняка.
Как надо делать? По ключу на каждую машину и хранить охапку ключей, которые прописаны в ~/.ssh/config для каждого сервера?Antonto
21.12.2016 16:50Я пользуюсь двумя ключами — один для серверов доступных снаружи и другой, для серверов доступных только внутри. Соответственно в случае компрометации «внешнего» ключа надо будет срочно поменять только его. А в случае компрометации «внутреннего» уровень опасности гораздо ниже, есть дополнительное время. И в обоих случаях работы меньше.
asilin
21.12.2016 16:53+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"
merlin-vrn
21.12.2016 17:02+6А вы знаете, есть такая программа — ssh-copy-id...
equand
21.12.2016 18:39-3Вечный гемор с которой
# ssh-copy-id Could not open a connection to your authentication agent. no keys foundmerlin-vrn
23.12.2016 10:21Ни разу не было геморроя. Научитесь читать маны и заодно узнаете про ssh-agent и команду ssh-add.
Saffron
22.12.2016 14:50+1Лучше всего — использовать x509 ключи, с certificate authority, отзывом ключей и прочим блекджеком.
nspickiy
23.12.2016 13:08Я у себя сделал связку login + ssh-key из LDAP. Человек может сам себе поменять ключ в личном кабинете. Очень удобно. Ключи хранятся в одном месте, доступ до серверов сделан на основе групп
NLO
21.12.2016 16:47НЛО прилетело и опубликовало эту надпись здесь
merlin-vrn
21.12.2016 17:01+6Во-первых, интернет от себя защищать обязательно надо.
Не только из гуманистических побуждений: ещё, скажем, чтобы ЦОД/провайдер не заметил от вас подозрительный трафик и не заблокировал от греха подальше, чтобы сети его самого уже в свою очередь не заблокировал какой-нибудь спамхаус. Ведь именно это, судя по всему, и произошло.
Канал ftp-data только кажется закрытым. В ядре есть ftp-helper, пакеты пройдут со state=RELATED. Но я на месте автора снёс бы ftp к чертям, пусть sftp пользуют (который через ssh, с теми же самыми ключами).
NLO
21.12.2016 19:18НЛО прилетело и опубликовало эту надпись здесь
merlin-vrn
23.12.2016 10:27А зачем серверу подключаться наружу на 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-листенер, чтобы любые изменения там заведомо отсылались на внешний лог-сервер до того, как программы (возможно, уже с закладками) будут перезапущены.
Смысл тут не в том, чтобы «не переустанавливать», а чтобы узнать о проблеме оперативно, и заодно иметь достаточно информации, чтобы определить, какая была лазейка.
asilin
21.12.2016 17:02+3Вы правы. Но, во первых, политика iptables готовилась на скорую руку. Во вторых, сервер был забанен за исходящий трафик, а я боялся, как заметил xforce, не найденных запакованных программ, способных возобновить атаку.
ilyaplot
21.12.2016 17:58На предмет шеллов, работающих по 80 порту исследования проводили? Был опыт управления машиной по такой схеме. www-data добавлялся в sudo. Скрипт — прослойка между вебом и консолью стостоял из 1 строки
Iv8
21.12.2016 19:36+1В моем случае была подменена часть исполняемых файлов. Типа запускаешь cp, автоматически запускается еще один ssh сервер, поднимает тоннель наружу и ждет подключений.
Отобрал сервер обратно с третьей попытки.
Стоит поискать все файлы которые не принадлежат пакетам, сравнить версии исполняемых файлов с тем, что лежит в репозитории.Solopov
21.12.2016 21:58угу dpkg --verify очень помогает. А «лишние» файлы либо переваливаются (например веб сайт, он же есть где-то «в эталоне» наверное), либо анализируются.
А вообще у вас же виртуалка, можно было снять копию для развлечений, заблочить исходящие порты (чтобы OVH не гневался), навесить скриптов слежения (по смыслу как в статье + может что-то типа snort) и ждать гостя :)
А в это время все остальные с чистой системой пусть работают.Iv8
21.12.2016 23:46В моем случае это был вполне железный сервер на котором крутился биллинг у мелкого местного провайдера.
Простой потеря денег. Админ за месяц до того уволился, вроде добровольно.
Было не очевидно, подхватит ли он лицензию на этот самый билинг после переустановки.
Попросили спасти, удалось. Но было интересно.
Изучение логов показало что был подобран пароль SSH, установлен какой-то известный зловред, машинка использовалась для рассылки спама. При гигабитном канале и шестнадцати ядрах рассылка шла весьма эффективно. :-)
martin74ua
21.12.2016 20:33на rpm дистрах есть хорошая команда — rpm -Va
Можно проверить весь установленный софт.
Посмотрите аналог на убунте.
Вы просто остановили скан, но не гарантия, что закрыли все дыры на сервере. Может команда ls кроме вывода файлов у вас сейчас еще меняет рутовый пароль и шлет его взломщику.
А вообще, если по хорошему — после взлома сервер надо ставить с нуля.
sleeply4cat
21.12.2016 23:58Неужели невозможно подменить пакетный менеждер?
evdanil
22.12.2016 08:01Возможно конечно подменить… но помимо того что уже сказали что систему надо в идеале переставить, если это не возможно то надо сделать так:
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…
dim2r
28.12.2016 12:31Наверное можно подменить ядро, что бы когда rpm проверяет, то видит нормальные файлы, а когда происходит запуск, то запускаются вредоносные…
esudnik
21.12.2016 21:01+1При таких взломах лучше переустановить всю систему полностью с нуля. Потому что вы не знаете, вдруг хакер установил еще какие то лазейки. Также могут быть незакрыты уязвимости по которым была совершена изначальная атака.
ibKpoxa
21.12.2016 22:40+6Как бы вы ни вычищали скомпрометированный сервер его нельзя считать на 100% вылеченным, только полная переустановка помогает.
RicoX
22.12.2016 09:46+4Скомпрометированный сервер можно забэкапить для анализа, но в продакшин нельзя выводить как в принципе, ни какая чистка не является панацеей, я даже не говорю про демоны с бэкдорами, банальный запуск nc по крону или любым init скриптом и все ваши танцы вокруг ssh и аутентификации бесполезны. Если взломан root, только перенос на новый сервер и его уже защищать чистка ничего не гарантирует.
catnikita255
22.12.2016 16:22Согласен. Полностью вычистить заразу практически невозможно хотя бы из-за незнания того, что было затронуто. Можно, конечно, делать иногда полный бэкап системы, это, думаю, поможет.
RicoX
22.12.2016 19:58Так вроди виртуалка, можно снапшоты делать раз в неделю + полный бэкап раз в месяц. В случае компрометации, подняли копию из последнего бэкапа без закладок, сделали diff систем, сравнили что изменилось, нашли все что было залито за время между бэкапами, попытались воссоздать атаку.
Hissing_Bridge
22.12.2016 12:22+1Рекомендую проверить систему rkhunter, Lynis и поискать скрытые процессы через unhide. Так же стоит посмотреть в сторону маленькой библиотеки snoopy (Snoopy Logger).
Alexey_Shalin
22.12.2016 12:22+1Как верно подметили — взломанный сервер годиться лишь для анализа… нужно поднимать новый и запускать в прод
catnikita255
22.12.2016 16:20При взломе сервера я бы лично взял все точно никак не зараженные данные, а потом начисто бы переустановил все и принял бы меры для предотвращения дальнейших атак. Жестоко, но все-таки тогда точно можно быть уверенным, что ничего опасного не осталось. На время переустановки можно, если этот сервер держит какой-либо сайт либо сервис, вывесить табличку «у нас технические проблемы, уходите отсюда».
fn112
23.12.2016 02:19+1Согласен. Это принципиальное решение, но лучше все-таки снести все и настроить хорошую защиту, чем пытаться что-то чистить. И такие потери времени работы сервера явно стоят дальнейших возможных сбоев, разборок или даже полного бана со стороны оператора
13werwolf13
23.12.2016 13:10я как-то по неопытности на XOR.DDoS нарвался… вылечил, но все коллеги в один голос кричат что сервак следует форматнуть и по новой ставить
swatchel
25.12.2016 04:18-1Debian ???? честно говоря странная аргументациям по выбору дистрибутива. Ставьте CentOS. По поводу переустановки с «нуля» — присоединяюсь к вышеизложенным рассуждениям о целесообразности поднятия «чистого» сервера — самый надёжный метод. Исследования можете потом проводить если время будет.
lilalilay
29.12.2016 17:49+1Как человек, имеющий 20-литний опыт в компьютерной безопасности и настройке систем, скажу, что с вероятностью в 92,8% уязвимость на сервере была специально устроена бывшим системным администратором (который вскользь упоминался в этой статье как ранее уволенный), который имел планы использовать сервер в своих целях как компенсацию за несправедливое увольнение.
GH0st3rs
Хорошая статья. Вопрос только, удалось выяснить причину взлома?
asilin
К сожалению, нет. Но я решил поискать уроки кибер-безопасности для повышения квалификации.
NLO
НЛО прилетело и опубликовало эту надпись здесь