Комментарии 51
Хорошая статья. Вопрос только, удалось выяснить причину взлома?
> Сохраняем и трём ключи ssh. Позже попросим всех пользователей генерировать новые. Сохраняем, для сравнения: чтобы особенно ленивые пользователи не могли использовать старый, возможно скомпрометированный доступ
Жуть какая, там-же открытые ключи, их хоть на заборе писать можно. Понятно, что удалить наверно надо, вдруг злоумышленник свои подкинул, но менять-то зачем? Как можно по имеющемуся открытому ключу что-то скомпрометировать, кроме самого себя (подложив эти ключи себе на сервер, например)?
Ну и если взлом прошел с участия рута, тут уже может быть всё бесполезно, sshd заменен на не родной с бэкдором, загружен модуль ядра с руткитом и т.д. и т.п. Обычно после этого просто делают полную переустановку, т.к. аудит всей системы дело не самое простое.
Жуть какая, там-же открытые ключи, их хоть на заборе писать можно. Понятно, что удалить наверно надо, вдруг злоумышленник свои подкинул, но менять-то зачем? Как можно по имеющемуся открытому ключу что-то скомпрометировать, кроме самого себя (подложив эти ключи себе на сервер, например)?
Ну и если взлом прошел с участия рута, тут уже может быть всё бесполезно, sshd заменен на не родной с бэкдором, загружен модуль ядра с руткитом и т.д. и т.п. Обычно после этого просто делают полную переустановку, т.к. аудит всей системы дело не самое простое.
А зачем переходить с Ubuntu на Debian, если это делается без полной переустановки всего, а простым обновлением? Или вы хотите старые сервера выкинуть, а новые поднять и переустановить?
Команды бы да не картинками бы. =)
атата, все правильно! нельзя бездумно копипастить команды из интернета. А так перенаберешь руками, может хоть задумаешься =)
и когда руками набираешь есть возможность ошибиться. И когда копипастишь тоже.
Однако перепечатать с картинки юные падаваны могут куда хуже, чем контрол копи контрол паст, ведь они всё равно будут так делать (бездумно копировать команды).
Однако перепечатать с картинки юные падаваны могут куда хуже, чем контрол копи контрол паст, ведь они всё равно будут так делать (бездумно копировать команды).
Я как-то раз помогал одному человеку, который ничего не соображал в 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». Не факт, что точно так было, но суть именно такая, в общем, ребутнул себе весь сервер :)
rm -rf /
Сохраняем, для сравнения: чтобы особенно ленивые пользователи не могли использовать старый, возможно скомпрометированный доступ
Ах ты ж хитрая этасамая!
А если серьезно, то у меня вопрос: какой метод организации ключей считается правильным™?
На данный момент у меня на дев машинке есть один ssh ключ, который я использую везде: на других дев-серверах, на гитхабе, на домашнем НАСе и т.д. И если вдруг системный администратор одной из машин, где у меня этот ключ провернет ваш фокус, то я вынужден буду сгенерировать новый ключ и пободавлять его везде в authorized_keys, что неиллюзорно добавит мне головняка.
Как надо делать? По ключу на каждую машину и хранить охапку ключей, которые прописаны в ~/.ssh/config для каждого сервера?
Я пользуюсь двумя ключами — один для серверов доступных снаружи и другой, для серверов доступных только внутри. Соответственно в случае компрометации «внешнего» ключа надо будет срочно поменять только его. А в случае компрометации «внутреннего» уровень опасности гораздо ниже, есть дополнительное время. И в обоих случаях работы меньше.
Я бы сказал охапку ключей, как например здесь. Но в действительности, все обходятся одним ключом, просто делая:
~ $ 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"
Лучше всего — использовать x509 ключи, с certificate authority, отзывом ключей и прочим блекджеком.
Я у себя сделал связку login + ssh-key из LDAP. Человек может сам себе поменять ключ в личном кабинете. Очень удобно. Ключи хранятся в одном месте, доступ до серверов сделан на основе групп
Можете попробовать SSSD.
EMC SSH — один раз настроить и больше не париться с заливкой ключей.
Во-первых, интернет от себя защищать обязательно надо.
Не только из гуманистических побуждений: ещё, скажем, чтобы ЦОД/провайдер не заметил от вас подозрительный трафик и не заблокировал от греха подальше, чтобы сети его самого уже в свою очередь не заблокировал какой-нибудь спамхаус. Ведь именно это, судя по всему, и произошло.
Канал ftp-data только кажется закрытым. В ядре есть ftp-helper, пакеты пройдут со state=RELATED. Но я на месте автора снёс бы ftp к чертям, пусть sftp пользуют (который через ssh, с теми же самыми ключами).
А зачем серверу подключаться наружу на 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-листенер, чтобы любые изменения там заведомо отсылались на внешний лог-сервер до того, как программы (возможно, уже с закладками) будут перезапущены.
Смысл тут не в том, чтобы «не переустанавливать», а чтобы узнать о проблеме оперативно, и заодно иметь достаточно информации, чтобы определить, какая была лазейка.
То же самое, серверу, как правило, нет потребности подключаться к 80 и 443, кроме отдельных адресов (обновления, внешние API).
Если сервер сломали, но рута не получили (как это бывает в подавляющем большинстве случаев), такой файерволл практически сведёт проблемы на нет.
А ещё, коллеги, tripwire и аналоги в помощь. Если сервер важный — на /etc /bin /sbin /usr/bin /usr/sbin /usr/lib и другие важные места — inotify-листенер, чтобы любые изменения там заведомо отсылались на внешний лог-сервер до того, как программы (возможно, уже с закладками) будут перезапущены.
Смысл тут не в том, чтобы «не переустанавливать», а чтобы узнать о проблеме оперативно, и заодно иметь достаточно информации, чтобы определить, какая была лазейка.
Вы правы. Но, во первых, политика iptables готовилась на скорую руку. Во вторых, сервер был забанен за исходящий трафик, а я боялся, как заметил xforce, не найденных запакованных программ, способных возобновить атаку.
В моем случае была подменена часть исполняемых файлов. Типа запускаешь cp, автоматически запускается еще один ssh сервер, поднимает тоннель наружу и ждет подключений.
Отобрал сервер обратно с третьей попытки.
Стоит поискать все файлы которые не принадлежат пакетам, сравнить версии исполняемых файлов с тем, что лежит в репозитории.
Отобрал сервер обратно с третьей попытки.
Стоит поискать все файлы которые не принадлежат пакетам, сравнить версии исполняемых файлов с тем, что лежит в репозитории.
угу dpkg --verify очень помогает. А «лишние» файлы либо переваливаются (например веб сайт, он же есть где-то «в эталоне» наверное), либо анализируются.
А вообще у вас же виртуалка, можно было снять копию для развлечений, заблочить исходящие порты (чтобы OVH не гневался), навесить скриптов слежения (по смыслу как в статье + может что-то типа snort) и ждать гостя :)
А в это время все остальные с чистой системой пусть работают.
А вообще у вас же виртуалка, можно было снять копию для развлечений, заблочить исходящие порты (чтобы OVH не гневался), навесить скриптов слежения (по смыслу как в статье + может что-то типа snort) и ждать гостя :)
А в это время все остальные с чистой системой пусть работают.
В моем случае это был вполне железный сервер на котором крутился биллинг у мелкого местного провайдера.
Простой потеря денег. Админ за месяц до того уволился, вроде добровольно.
Было не очевидно, подхватит ли он лицензию на этот самый билинг после переустановки.
Попросили спасти, удалось. Но было интересно.
Изучение логов показало что был подобран пароль SSH, установлен какой-то известный зловред, машинка использовалась для рассылки спама. При гигабитном канале и шестнадцати ядрах рассылка шла весьма эффективно. :-)
Простой потеря денег. Админ за месяц до того уволился, вроде добровольно.
Было не очевидно, подхватит ли он лицензию на этот самый билинг после переустановки.
Попросили спасти, удалось. Но было интересно.
Изучение логов показало что был подобран пароль SSH, установлен какой-то известный зловред, машинка использовалась для рассылки спама. При гигабитном канале и шестнадцати ядрах рассылка шла весьма эффективно. :-)
на rpm дистрах есть хорошая команда — rpm -Va
Можно проверить весь установленный софт.
Посмотрите аналог на убунте.
Вы просто остановили скан, но не гарантия, что закрыли все дыры на сервере. Может команда ls кроме вывода файлов у вас сейчас еще меняет рутовый пароль и шлет его взломщику.
А вообще, если по хорошему — после взлома сервер надо ставить с нуля.
Можно проверить весь установленный софт.
Посмотрите аналог на убунте.
Вы просто остановили скан, но не гарантия, что закрыли все дыры на сервере. Может команда ls кроме вывода файлов у вас сейчас еще меняет рутовый пароль и шлет его взломщику.
А вообще, если по хорошему — после взлома сервер надо ставить с нуля.
Возможно конечно подменить… но помимо того что уже сказали что систему надо в идеале переставить, если это не возможно то надо сделать так:
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. Загрузиться с 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…
Наверное можно подменить ядро, что бы когда rpm проверяет, то видит нормальные файлы, а когда происходит запуск, то запускаются вредоносные…
При таких взломах лучше переустановить всю систему полностью с нуля. Потому что вы не знаете, вдруг хакер установил еще какие то лазейки. Также могут быть незакрыты уязвимости по которым была совершена изначальная атака.
Скомпрометированный сервер можно забэкапить для анализа, но в продакшин нельзя выводить как в принципе, ни какая чистка не является панацеей, я даже не говорю про демоны с бэкдорами, банальный запуск nc по крону или любым init скриптом и все ваши танцы вокруг ssh и аутентификации бесполезны. Если взломан root, только перенос на новый сервер и его уже защищать чистка ничего не гарантирует.
Как верно подметили — взломанный сервер годиться лишь для анализа… нужно поднимать новый и запускать в прод
я как-то по неопытности на XOR.DDoS нарвался… вылечил, но все коллеги в один голос кричат что сервак следует форматнуть и по новой ставить
Debian ???? честно говоря странная аргументациям по выбору дистрибутива. Ставьте CentOS. По поводу переустановки с «нуля» — присоединяюсь к вышеизложенным рассуждениям о целесообразности поднятия «чистого» сервера — самый надёжный метод. Исследования можете потом проводить если время будет.
Как человек, имеющий 20-литний опыт в компьютерной безопасности и настройке систем, скажу, что с вероятностью в 92,8% уязвимость на сервере была специально устроена бывшим системным администратором (который вскользь упоминался в этой статье как ранее уволенный), который имел планы использовать сервер в своих целях как компенсацию за несправедливое увольнение.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Опыт работы со взломанным сервером