Вступление

Зловредные попытки входа SSH все чаще появляются в логах, и в этой статье
рассказывается про использование honeypots, анализ попыток проникновения в SSH,
также даются советы как защитить свою систему.

Используем honeypots для исследования

New Zealand Honeynet Alliance - организация, занимающясяя исследованием
безопасности систем путем изучения тактик атак с применением honeypots.
Honeypots - компьютерные системы, открытые для различного рода атак, с отсутствием
видимой защиты, что помогает исследователю анализировать все попытки
злоумышленников проникнуть в систему.

(http://en.wikipedia.org/wiki/Honeypot_%28computing%29 - более подробнее можно
почитать).

Honeypot был установлен в Университете Виктории, Веллингтон для исследования
злонамеренной активности, происходящих в нем. Между обычной машиной и honeypot
не было никакого различия, однако все события логировались с помощью Honeynet
Alliance Roo honeywall, которая учитывала весь протекающий через машину траффик.
Все системные события фиксируятся на самом honeypot через собственную систему.


Система была запущена на RedHat 9 с SSH, и была свободно запущен в Сеть. После
того как в прошлых сборках был отмечен повышенный интерес к SSH, сервер был
пересобран, и теперь записывались все логины с паролями, с которыми пытались
приконнектится к SSH. Машина была выведена в сеть 11 июля 2006 а в оффлайн - 1
августа 2006, практически через месяц после запуска.

В дальнейшей конфигурации, honeypot, запущеный с 8 июня до 4 июля, был добавлен
модуль Sebek, который логирует данные злоумышленика, при малейшей опасности для
системы. Также было создано несколько аккаунтов с часто используемыми логинами и
паролями.

Анализ этого нападения, как и последующих представлен в таблицах ниже, покажет
нам как происходит нападение.

Анализ попыток логина

Здесь приведется анализ данных полученных нашим honeypot в период с 1 июля до 1
августа, на основе логов honeypot и системы. Это включает дату, время, IP адрес,
с которого происходила попытка входа, логин и пароль.


Сначала, проанализируем логины, с которых были попытки входа. Всего произошло
примерно 2741 уникальных логинов, среди которых были популярные фамилии, системные
аккаунты. Из них "ТОП-15" самых популярных показаны в таблице ниже Указаны
популярные логины, используемые системой(root, mysql), аккаунты, которые могут
находится в системе(guest, test), некоторые имена(paul).

Не вызывает удивления, что использование неправильных аккаунтов намного превышало
использование правильных. Тем не менее стоит отметить что 96,30% всех аккаунтов
которые существуют на honeypot, использовались во время атак.
.
Account Name Number of login attempts
root 1049
admin 97
test 87
guest 40
mysql 31
info 30
oracle 27
postgres 27
testing 27
webmaster 27
paul 25
web 24
user 23
tester 22
pgsql 21

Table 1. Top 15 account names among 2741 attempts.


Figure 1. Number of account names, both existing and invalid.

Дальше давайте взглянем на пароли. В целом, после анализа, злоумышленники
пытались получить доступ с более чем 2741 логином, и 3649 паролями. Не все пароли
были схожи с аккаунтами, хотя большинство были напрямую связаны с ними, использовались
различные вариации логинов, клавиатурные последовательности вроде qwerty,
комплексные пароли ( r00t or c@t@lin)

Таблица 2 показывает "ТОП-15 паролей"

Password Number of login attempts
123456 331
Password 106
Admin 47
Test 46
111111 36
12345 34
administrator 28
Linux 23
Root 22
test123 22
1234 21
123 20
Mysql 19
Apache 18
Master 18


Потом мы решили узнать кто атаковал honeypot и какую стратегию они использовали.
Всего было замечено 23 уникальных IP. Нападавшие были более менее настойчивы
получить доступ к системе, 10 из них попробовали 50 комбинаций, прежде чем
прекратить попытки, 5 были настойчивые и перепробовали 170 попыток, ну а самыми
настойчивыми оказались 8 пользователей, произведшие 1450 попыток.
В таблице 3 показано количество попыток на один IP

Number of Login Attempts Unique IP Addresses
< 50 10
50 <= x <= 200 5
> 200 8



Figure 2. Failed login attempts by source IP.


Если взглянуть поближе на стратегию взлома, нападавшие пробовали один и тот же
логин и пароль на аккаунт, к примеры test/test. Другие стратегии отличались, к
примеру, один нападающий сосредоточился на root аккаунте, пароли разбегались от
общих значений до паролей последовательного характера(e.g. root/!@#, root/123abc,
root/default).

Несколько нападавших выбрали поведение, котороя бы лучше обходила систему IDS,
ограничивая нападения несколькими попытками. Атаки стали более серьезными.
Сначала количество попыток влома резко возрастло, и в скоре мы увидели что
взломщики сконцентрировались на таком аккаунте как root. Так как атаки ставали
все серьезнее, их отражение будет более вероятным, если IDS будет более
развернутой. Можно подумать, что число успешных атак увеличилось бы с увеличением
количества попыток, и как результат увеличило бы опасность быть выявленным, но
мы не можем подтвердить это, так как наши данные не включают анализ комбинаций
логинов/паролей аккаунтов. Далее мы решили узнать как нападавшие пытались получить
доступ: руками или использовали некоторые утилиты? Если бы использовался к примеру
брутфорс, можно было бы легко узнать об этом, так как маленький промежуток времени
между попытками входа с одного IP явно указал бы на это, а сравнительно большой
промежуток напротив указал бы что взломщик пытается получить доступ самостоятельно,
то есть руками.

Таблица 3 показывает результаты

TOP-5 атакующих, вероятно использовали брутфорс, так как средний промежуток
между попытками составляет 2 - 4 секунды, со средним отклонением от диапазона
от 0.45 до 1.39 секунд Другой же атакующий вероятно сам подбирал пароли, так как
средний промежуток между попытками - 7 секунд, отклонения - 2.36 секунд.

Однако некоторое напротив, показывает что некоторые пользовались одинаковыми
словарями для подбора паролей, хотя атаки проводились с разницей в 4 дня и с
разных IP адресов.

"Успешный" вход

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

2 июля, одному из нападавших удалось проникнуть на SSH, подобрав пароль к аккаунту
Данные, полученные в результате этого взлома позволят нам дать ответы на некоторые
вопросы.

Сначала мы исследовали действия нападавшего непосредственно внутри системы.
Сразу же после получения пароля, атакующий загрузил SSH сканер, подробнее про
который можно почитать в следующей секции. Это инструмент, который поможет
идентифицировать другие SSH сервера и скомпрометировать их. Инструмент сразу же
был запущен, но из-за ограничений Roo honeywall, он не принес никакой пользы.

После начального просмотра, атакующий скачал и установил IRC бота. Это позволило
ему управлять сервером более скрытно, снизив риск быть обнаруженным в системе.
Также это позволит управлять ему другими аналогичными "зомби".

Анализируя логи IRC канала, мы увидели что большинство зомби заражено таким же
SSH сканером, как и на нашем honeypot. В течении нескольких часов, было
просканировано 4 класса B. Далее мы увидели обмен словарями для брута, аналогичные
тем, с которыми мы сталкивались на протяжении нападений на наш honeypot.

Общий анализ

Так что же мы сделали за время существования нашего honeypot? SSH это путь к
получению полного контроля над системой по зашифрованным каналам. Однако, несмотря
на довольно таки неплохую репутацию относительно безопасности, есть множество угроз
для него. Пароль - главная из угроз, показанная в этой статье. Всего лишь факт
запущенного и доступного из Интернета сервера SSH, привело к 6899 попыткам входа
в систему только за 22 дня! Это ~ 300 попыток логина в день в среднем. Некоторые
нападающие с упорством атаковали honeypot, выполняя, сотни попыток входа в сессию.

Владеющий армией только 525 IRC ботов сможет просканировать IP4 только за 1 день.
Поэтому, если у вас есть публично доступный SSH сервер, он легко может стать
жертвой атаки.

Рекомендации

Использовать /etc/hosts.allow и /etc/hosts.deny файлы для ограничения доступа
к некоторым хостам.

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

Ограничить доступ к SSH, ввести аутентификацию юзера или группы.

Переместите SSH с 22 порта на любой другой не использованый.Это затруднить
обнаружение сервиса, так как большинство bruteforce для него предполагают,
что он находится на 22 порту.


SSH также поддерживает ключи доступа. Их установка занимает не более нескольких
минут, подробнее можна прочитать в статье SSH Host Key Protection
и SSH and ssh-agent

Также хочу сказать пару слов про логины. Не стоит оставлять дефолтовые root,
user etc. так как они чаще всего подвергаются атакам. Не стоит также использовать
имена.

Нападавшие использовали различные brute force, такие как captured Scanner, QT,
и 55hb. Однако, несмотря на эти программы, минимальное время попыток входа было
примерно 2 секунды из-за искусственной задержки при неудачных попытках, которая
была включена в SSH сервер. Это обеспечивает некоторую защиту от brute force, но
задержка все равно не спасет при легких логине и пароле. Меры безопасности,
описанные выше должны быть установлены, и безопасность вашего сервера будет на
достаточно высоком уровне

Оригинал -
http://www.securityfocus.com/infocus/1876
Огромное спасибо NeMiNeM за помощь
© Christian Seifert



© перевод Robin_Hood@GFS
http://www.gfs-team.ru/?act=articles&pact=150