Что делать если сервер взломан и подменили ssh сервер?

Бывает 🙂 И у меня было в жизни много раз. Подключаешься к серверу — и тут странное ошибко, мол сигнатура сервера изменилась, ну или со временем обнаруживаешь странности в работе… Что делать? Для начала нужно успокоится, и неспешно все исправить. На всеобъемлемость и объективность не претендую. Сам не раз боролся с такими проблемами, увы, всех дырок до происшествия не залатаешь. Решение проблемы следует разбить на два этапа, которые мы рассмотрим на примере ОС Linux — моей любимице. Для избежания путаницы, сразу оговорюсь что я давно использую Debian, и мой опыт больше связан именно с этой системой, хотя и во всех других дистрибутивах Linux’а отличия от Debian в основном сводятся в прикладном ПО, и в подходах к организацию слаженной работы системы. Короче говоря — хоть я работаю и под дебьяном — во всех других системах все, фактически, точно так же :_)

Этап первый — закрываем несанкционированный доступ

. Первым делом — отрезаем доступ к серверу, дабы злоумышленник не смог внедриться в систему еще глубже. Если есть возможность — отключайте его от сетей — и внутренней и внешней. Еще лучше — грузитесь с CD, тогда Вы будете уверены в работоспособности всех основных системных утилит, которые возможно были заменены на троянские аналоги.
Если возможности отключить выходы наружу нет — закрывайте выход наружу всего, кроме самого необходимого (например веб-сервера). Сделать это проще всего имея под рукой заранее приготовленный скриптик фаервола, который отрежет все, кроме критичных портов — 80, 21 или чего у Вас там. Но не стоит забывать, что многие взломы приходят не через уровень портов и протоколов, а через уровень приложений. Проще говоря — используются уязвимости или ошибки в конкретных версиях ПО — например того же WEB или FTP-сервера.  А чаще всего используют ошибки и уязвимости в коде Вашего сайта — дырой могут быть определенные версии интерпретаторов PHP, Perl или просто безграмотно написанный код. К слову к таким дырка ведет и чрезмерная сложность проектов, которые часто встречаются в наши дни. Где никто просто не в состоянии отследить все возможные дырки подходящие злоумышленникам… Такие уязвимости фаерволом не закрыть. Но что-то меня понесло. Вернемся к нашему случаю подмены SSH.

После того как фаерволом Вы обрезеали доступ всем, кроме себя любимого — можно собраться с мыслями. В данный момент злоумышленник скорее всего (но далеко не факт) не имеет доступа к Вашему серверу. И Вы покойно можете почистить его от следов чужого присутствия.

Если Вы заходили на пораженную машину не с консоли а через SSH — почти наверняка Ваши пароли уже известны злоумышленнику. И вполне вероятно что в системе сидит бэкдор, троян, кейлогер или липовый интерпретатор команд (sh, bash или что у Вас там). Начнем с простого. С изучения логов. Если злоумышленник профан, или банально бот — то логи будут на месте, и Вы сможете отследить кто и как заходил в систему. Например можно выполнить команду last для обнаружения левых учетных записей. Есть что-то подозрительное в именах пользователей или других системных событиях? Подозрительные учетки созданы недавно и висят в конце файлов passwd и shadow? Одной проблемой меньше, это отличный след.

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

Далее простенькой командой смотрим изменения в системе за те дни, что прошли с момента взлома системы. Ну например Вы обнаружили что хак был 10 дней назад. Выполняем find / -type f -mtime -10 — это покажет все файлы, которые были изменены за прошедшие 10 дней. Да, на живой машине или продакшн сервере лишнего будет очень много, но проверить нужно все. Особенно обратите внимание на вновь созданные файлы, и на изменения в директориях /etc и *bin/. В первой могли править системные конфиги, а во вторые могли напихать троянов и подменить демоны — в том числе и SSH. Ага — вот и видим что SSH подсунули. Заливаем новый, или точно такой же с бэкапа. Лучше новый (обновленный) — на случай уязвимости в самом SSH-сервере. Рестартуем демон — для всех этих операций лучше иметь непосредственный доступ к консоли. Логинимся в систему. Меняем пароль root и\или все пароли пользователей, особенно те, которые имеют право на sudo.

Если и на других серверах были эти же пользователи и пароли — меняем сразу.

Так же проверяем все конфигурационные файлы, которые были изменены в этот 10-ти дневный период. Удаляем все что могли засунуть нам в систему, и не забудьте проверить файлы старта системы (rc. init. и так далее в зависимости от системы). К вышеперечисленным методам обнаружения — добавьте еще netstat. Эта утилита позволит обнаружить лишние открытые порты. Тут важно с чем-нить системным не перепутать 🙂 иначе будете искать черного кота в черной комнате.

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

Этап второй — ищем и устраняем уязвимость

, с помощью которой скомпрометировали систему. Тут все не так просто. Дыра может быть в чем угодно, и что бы найти ее следы — необходима предварительная настройка безопасности системы. Благо в современные дистрибутивы уже интегрирован целый ряд security-систем. И разновидностей их довольно много, тут уж надо знакомиться с мануалами, how-to’шками или сообществом пользователей и разработчиков. И по этой же причине удобно выбирать популярное ПО. Даже несмотря на то что именно популярность стает причиной большего риска для взлома, ведь популярные дистрибутив, FTP, SSH, WEB, CMS ломать буду намного чаще чем малоизвестные. Но с другой стороны при популярности продукта Вы получаете и некую гарантию того, что уязвимости будут быстро обнародованы и устранены. Одна голова хорошо, а пару миллионов — явно лучше.
Снова к делу. В случае с нашей подменой SSH-сервера, нужно определится кто и как работал. Часто сервера ломают не хакеры, а боты. В таком случае — все очень просто. Как и настоящие злоумышленники боты используют два основных способа проникновения в систему — использование уязвимости конкретного ПО (путем реализации эксплойта), или подбором пароля к тому или иному сервису.

Рекомендации в таких случаях стандартны. В обоих случаях — необходимо ограничить доступ только тем кому он положен. То есть всегда реализовывайте философию «запрещено всем, кому не разрешено». В случае использования дырки в ПО — обновите ПО, или залатайте дырку самостоятельно. Ну а в случае подбора пароля — смените все пароли, найдите человека со слабым паролем (которого забрутфорсили) и дайте ему по рогам. Ну или найти иную утечку паролей. Пользователи часто пишут свои пароли на листиках, дискетках, блокнотах, записывают их в мобильные телефоны или хранят в почте. Такие действия нужно пресекать на корню, ведь давно известно что биоинженеринг — самый простой способ проникнуть в любую «идеально» защищенную систему.

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

Тут совет только один — переносить на другую систему (ну или ставить с нуля), предварительно прибив первопричину подозреваемой уязвимости (дырка в определенной версии какого-то софта, открытые порты, слабые пароли и так далее). В противном случае — Вы никогда не сможете быть больше уверены в целостной работы такой системы. Но не стоит сразу же бросаться за учебники по безопасности своих систем — умные ребята которые могут побороть стандартную ззащиту вряд ли заинтересуются конкретно Вашим сервером.

Запись опубликована в рубрике Статьи с метками , , , , , , , , , , , , , . Добавьте в закладки постоянную ссылку.

1 комментарий: Что делать если сервер взломан и подменили ssh сервер?

  1. Slant говорит:

    Коментарий параноика:

    Когда я еще только начинал сам админить, и запустил первый свой сервер с доступом из интернет, был сначала очень горд. Ну еще бы. Первая же железка. И вот спустя пару недель я заглянул в логи доступа. Вот тут-то у меня волосы резко зашевелились, когда я обнаружил СКОЛЬКО за сутки народу, в среднем, интересуется вопросом «а что это у нас тут на 22-ом порту живет? А может оно нам тоже пригодится?». 🙂
    В общем, мне резко поплохело, и восьмизначный пароль как-то резко перестал казаться достаточной мерой. Полез читать доки — и вычитал, что есть такой хороший способ — авторизация по ключу. Тоже не панацея, т.к. как раз в то время нашли недоработку в механизме генерации ключей (и быстро запатчили), но! Все же нормальный ключ подобрать как-то заметно сложнее чем любой адекватной длинны (для частого использования) пароль. Но тут я увлекся, и начал вообще составлять список технических средств усиления безопасности. Мои собственные выводы:

    1.Если SSH смотрит наружу — доступ только по ключу. Пусть сервер вообще не пускает никого без ключа. Да, это менее удобно, зато куда надежнее. Да и кейлогеры менее страшны — ключ редко используется более чем на одном сервере (его то не нужно запоминать!), а вот пароли частенько, из лени, используют сразу на многих.
    2. Порт с 22-го можно и поменять. Все ботам сложнее будет.
    3. Если сервер наружу смотрит не только SSH-ем, а и чем-то еще — лучше бы его в DMZ посадить. И пробросить к нему только те порты, на которых работает нужная снаружи служба.
    4. Служба которая наружу общается — ну не должна быть от рута запущена и все тут. Не умеет сама — сажать в виртуалку, но не допускать чтобы она могла делать хоть что-то, кроме своих прямых обязанностей, даже в принципе.
    5. В виртуалку, вообще любой внешний сервис сажать неплохо, жаль — не всегда возможно из соображений производительности.
    6. Если позволяет специфика, фаервол можно настроить так, чтобы он разрешал только N новых сессий к определенному порту с одного IP в час. Здорово осложнит брутфорсерам жизнь. Главное потом самому пароль не забыть, а то как с пинкодом будет — три попытки и иди разблокировать… 🙂
    7. Это уже слегка извращением отдает, но иногда я делаю так: Наружу смотрит не SSH а только OpenVPN. Чтобы приконектится к серверу, надо сначала подключится к VPN, и только потом зайти через SSH на внутренний интерфейс. Правда в таком случае я уже ключ не использую — OpenVPN со своими сертификатами это те же самое, только в профиль. 🙂 Правда используется такой вариант у меня там, где VPN сам по себе нужен — для доступа к удаленной сети.
    8. Общее правило. Чем более нетипичные у системы параметры доступа, тем больше ботов-брутфорсеров идут лесом. Главное, чтобы не мешало основные функции исполнять.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *