PDA

Просмотр полной версии : Анализ Атак на Ssh(Перевод)


Robin_Hood
27.04.2007, 16:33
Вступление

Зловредные попытки входа 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 адрес,
с которого происходила попытка входа, логин и пароль.



Jul 13 09:37:59 basta sshd[22308]: PW-ATTEMPT: fritz
Jul 13 09:37:59 basta sshd[22308]: Failed password for root from 10.0.160.14
port 39529 ssh2
Jul 13 09:38:02 basta sshd[22310]: Illegal user fatacunike from 10.0.160.14
Jul 13 09:38:02 basta sshd[22310]: PW-ATTEMPT: fatacunike
Jul 13 09:38:02 basta sshd[22310]: Failed password for illegal user fatacunike
from 10.0.160.14 port 40444 ssh2



Сначала, проанализируем логины, с которых были попытки входа. Всего произошло
примерно 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.

http://www.gfs-team.ru/pictures/malicious-ssh-figure1.jpg
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


http://www.gfs-team.ru/pictures/malicious-ssh-figure2.jpg
Figure 2. Failed login attempts by source IP.


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

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

Таблица 3 показывает результаты
http://www.gfs-team.ru/pictures/malicious-ssh-figure3.jpg
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

DisturbeR
27.04.2007, 18:18
Robin_Hood, NeMiNeM, звиняйте, но зря переводили, т.к. статья г.
Что мы можем из нее узнать?
Что абсолютно все unix-серверы находятся под постоянным брутом? Это известно всем, для этого достаточно один раз посмотреть на secure-логи, любого дедика.
Популярные пароли? Так это самая распространенная тема на любом форуме.
Как усилить защиту openssh? Для этого достаточно мануала.

При этом непонятно:
Как установка IRC-бот снизит риск быть обнаруженным в системе.


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


Это вообще не для моего недалекого ума. Как идентифицировать? Как скомпрометировать? Какие ограничения?

Такое многообещающие название и такое г.

Robin_Hood
27.04.2007, 18:31
ув. DisturbeR
давай по порядку.
если мы посмотрим те же логи, то увидим что большинство логинов root и ничего с этим не поделать.

honeywall это чтото типо firewall, с некоторыми ограничениями. он не дает хекеру возможности пройти дальше, чем того требуется во время, как в этом примере, исследования.

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

что еще непонятно?

DisturbeR
27.04.2007, 20:09
ув. DisturbeR
Спасибо за уважение. Все бы так.


Проанализировав АТАКИ (ударение на множественном числе), можно сказать, что все действия современных хакеров (при попытки компрометации SSH-серверов) сводятся к банальному брутфорсу с использованием паролей типа: qwerty, root. admin, root и т.п. Но существует и тенденции к профессиональному росту злоумышленников. Некоторые хакеры, вместо того чтобы использовать ручной подбор паролей, применяют автоматизированные брут-программы и более сложные пароли, такие r00t, c@t@lin и т.д.
После удачного входа в систему злоумышленник, устанавливает SSH-сканер, управляемый через ИРК (чтоб быть более незаметным в системе) и продолжает черное дело по компрометации SSH-серверов.

Можно ли это назвать анализом, статьей, исследованием? Не нужно переводить такие статьи, просто обратись ко мне и я накатаю в том же духе атаки на ICQ, FTP, SMPT и др. (нужное подчеркнуть)
Пока группы радикально настроенных хакерсонов с матом, бубном и ПРОМТ’ом в зубах пытаются продраться через технический буржуинский язык, вы переводите такое г.
Стыдно батенька, стыдно….

что еще непонятно?

При этом непонятно:
Как установка IRC-бот снизит риск быть обнаруженным в системе.

GreenBear
27.04.2007, 21:12
весь ваш зло***ий брут уйдет в небытие если поставить ограничение по ип.
что в конце статьи и написано, не понимаю зачем там остальные буквы.

Robin_Hood
27.04.2007, 21:15
а остальные буквы просто показывают печальную статистику=)

GreenBear
27.04.2007, 21:22
для кого печальная, для кого наоборот =)

NeMiNeM
27.04.2007, 21:31
Robin_Hood, NeMiNeM, звиняйте, но зря переводили, т.к. статья г.

Статья практически полностью переведена Робин Гудом. Так буквально помог с 2-3 фразами.

Я думаю Robin_Hood решил переводить именно статью этой тематики, потому что таких не много на форуме. Пускай будет, пускай люди читают) для общего развития) Нужно уважать старания человека.

VelloRibbo
08.06.2007, 12:02
Элементарное ограничение по IP на ssh порт (и вообще на все порты использующие аутефикацию типа пароль логин) и большая часть кулхацкеров идет лесом. Статья мало кому может понадобиться.

Dronga
14.06.2007, 17:03
Статья отличная, наконец-то провели какой-то комплексный анализ по данному направлению. На практике всё именно так и есть, дважды убедился ;) Начиная со списка наиболее употребимых логинов и заканчивая действиями злоумышленника ;)

Всё в статье замечательно, спасибо переводчикам, но не хватает конкретных рекомендаций, опробованных, проверенных и реально работающих. Поэтому надеюсь на активность в теме и дельное обсуждение.Использовать /etc/hosts.allow и /etc/hosts.deny файлы для ограничения доступаКривое решение.. Частые командировки сотрудников отдела и уже не подходит и для атакующей стороны смена IP-адреса не большая проблема
Установить файрволл для того чтобы ограничить доступ к SSH только для
определенных машин. Это особенно необходимо, если администратирование
производится удаленноВ туже топку.. Эти 2 рекомендации дублируют друг друга.
Ограничить доступ к SSH, ввести аутентификацию юзера или группы.Без комментариев =)
Переместите SSH с 22 порта на любой другой не использованый.Это затруднить
обнаружение сервиса, так как большинство bruteforce для него предполагают,
что он находится на 22 порту. Я не считаю это обязательным, да и эффект вряд ли будет. Сканирование изначально общедоступного сервера ещё труднее запретить или как-тол контролировать. Возможно, если баннер sshd ещё сменить, суммарно получится какой-то толк.
SSH также поддерживает ключи доступа. Их установка занимает не более нескольких
минут, подробнее можна прочитать в статье SSH Host Key Protection
и SSH and ssh-agentВ топку. Вечные флешки, дискеты.. А уехал, оставил случайно машину и настроенный PuTTy.. Потом смена.. А если сотрудник не одни имел доступ.. В общем, канитель ещё та.

Кто и как решает эту проблему?? Сюда же думаю логично отнести проблему перебора паролей и по другим службам, в частности FTP, POP3.

Сам вот смотрю в сторону sshguard. Пока что не ставил, но настройка там минимальная. Принцип простой.. Пять неудачных аутентификаций и несчастный юзер может курить 4 минуты.. Ещё пять неудачных аутентификаций... ну что поделать, не телепат.. теперь пусть пару часиков перекуривает. Думаю адекватно. Но опять-таки, это только SSH.

_Pantera_
14.06.2007, 20:08
Интересная статья мне понравилась.

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

Хотелось бы про это поподробнее почитать.
ps кто найдет хорошую статейку без разговоров получит +8

Deem3n®
15.06.2007, 09:59
Ограничить доступ к SSH, ввести аутентификацию юзера или группы.Без комментариев =)oO
Строчка:AllowUsers user1 user2 в /etc/ssh/sshd.conf намного уменшит шансы злоумышленника

Кто и как решает эту проблему?? Сюда же думаю логично отнести проблему перебора паролей и по другим службам, в частности FTP, POP3.Можно ограничить по одному новому соединению за минуту двумя простыми правилами фаера:
iptables -A INPUT -p tcp -m state --syn --state NEW --dport 22 -m limit --limit 1/minute --limit-burst 1 -j ACCEPT
iptables -A INPUT -p tcp -m state --syn --state NEW --dport 22 -j DROP(для других служб аналогично)
и прикрутить denyhosts/sshguard (это для тех кто не любит возится с фаером)

Dronga
15.06.2007, 13:23
AllowUsers user1 user2Это само собой как бы, специфика такая у нас.

С iptables интересно, но у меня в системе его нет. Я не совсем понял как он будет себя вести в случае паралельных сессий с разных IP.

_Pantera_, столкнулся на одном серваке, было дело.. Сканирую сервер, порт левый открытый и баннер выдаёт psyBNC 2.3.2.. Долго не мог понять откуда запускается.. Оказалось что через крон и ещё имя процесса маскируется под httpd. Злоумышленник забыл удалить архив откуда он это всё разворачивал, так что если кому интересно, могу выложить, там все попутные утилиты. Потом по логам прошерстил, по SSH был успешный брут. Пароль сменил. Вроде больше ничего не обнаружилось.

Robįŋ Guδ
25.06.2007, 18:00
Статья действительно неплохая, мне понравилась
Установить файрволл для того чтобы ограничить доступ к SSH только для
определенных машин. Это особенно необходимо, если администратирование
производится удаленно
Конечно не плохо, но если представить что количество аккаунтов растет то в табу релесов заносить ip адреса дело неблагодарное:
iptables -A INPUT -p TCP -s ! *.*.*.* --dport 22 -j DROP
Вроде так, не помню сейчас тк пользуюсь pf:
pass on $ext_if inet proto tcp from any to $ext_if port ssh keep state \
(max-src-conn 10, max-src-conn-rate 5/60, overload <blah> flush)
block on $ext_if inet proto tcp from <blah> to $ext_if port ssh \
probability 65%
Также можно набросать перловый скрипт определяющий ip адреса атакующих через нетстат и затем заносящих в табу фаервола
Переместите SSH с 22 порта на любой другой не использованый.Это затруднить
обнаружение сервиса, так как большинство bruteforce для него предполагают,
что он находится на 22 порту.
Бесмыслено. Даже если поменять директиву port в /etc/ssh/ssh_config то это все равно не затруднит. Все равно nmap найдет отпечаток ssh демона ну а за гидрой дело не стоит
SSH также поддерживает ключи доступа. Их установка занимает не более нескольких
минут, подробнее можна прочитать в статье SSH Host Key Protection
и SSH and ssh-agent
Согласен, лучше всего осущевствлять аунтефикацию по паблик/приват ключам нежели по паролю это действительно поможет + повысить таймаут при попытках ввода пароля

P.S при попытках брута передаеться юзер агент? /думаю нет но все таки спрашиваю

NApoleonchik
06.07.2007, 14:15
Действительно подоборка топ15 паролей верна - испробована на деле

Ni0x
06.07.2007, 16:30
Pantera, все сводится к тому, что управление производится через обычные nix команды, т.е ты пишешь боту чтонибудь наподобие !exec id, бот возвращает твои права в системе. Готовых ботов очень много, но вот насчет беспалевности этого варианта можно поспорить.