Вступление Зловредные попытки входа 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 адрес, с которого происходила попытка входа, логин и пароль. Code: 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. 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
Robin_Hood, NeMiNeM, звиняйте, но зря переводили, т.к. статья г. Что мы можем из нее узнать? Что абсолютно все unix-серверы находятся под постоянным брутом? Это известно всем, для этого достаточно один раз посмотреть на secure-логи, любого дедика. Популярные пароли? Так это самая распространенная тема на любом форуме. Как усилить защиту openssh? Для этого достаточно мануала. При этом непонятно: Как установка IRC-бот снизит риск быть обнаруженным в системе. Это вообще не для моего недалекого ума. Как идентифицировать? Как скомпрометировать? Какие ограничения? Такое многообещающие название и такое г.
ув. DisturbeR давай по порядку. если мы посмотрим те же логи, то увидим что большинство логинов root и ничего с этим не поделать. honeywall это чтото типо firewall, с некоторыми ограничениями. он не дает хекеру возможности пройти дальше, чем того требуется во время, как в этом примере, исследования. дальше: что в основном делает народ при получени SSH? либо пытается порутать сервак, либо просто их собирает, для разных целей. в данном случае он хотел найти другие SSH. что еще непонятно?
Спасибо за уважение. Все бы так. Проанализировав АТАКИ (ударение на множественном числе), можно сказать, что все действия современных хакеров (при попытки компрометации SSH-серверов) сводятся к банальному брутфорсу с использованием паролей типа: qwerty, root. admin, root и т.п. Но существует и тенденции к профессиональному росту злоумышленников. Некоторые хакеры, вместо того чтобы использовать ручной подбор паролей, применяют автоматизированные брут-программы и более сложные пароли, такие r00t, c@t@lin и т.д. После удачного входа в систему злоумышленник, устанавливает SSH-сканер, управляемый через ИРК (чтоб быть более незаметным в системе) и продолжает черное дело по компрометации SSH-серверов. Можно ли это назвать анализом, статьей, исследованием? Не нужно переводить такие статьи, просто обратись ко мне и я накатаю в том же духе атаки на ICQ, FTP, SMPT и др. (нужное подчеркнуть) Пока группы радикально настроенных хакерсонов с матом, бубном и ПРОМТ’ом в зубах пытаются продраться через технический буржуинский язык, вы переводите такое г. Стыдно батенька, стыдно….
весь ваш зло***ий брут уйдет в небытие если поставить ограничение по ип. что в конце статьи и написано, не понимаю зачем там остальные буквы.
Статья практически полностью переведена Робин Гудом. Так буквально помог с 2-3 фразами. Я думаю Robin_Hood решил переводить именно статью этой тематики, потому что таких не много на форуме. Пускай будет, пускай люди читают) для общего развития) Нужно уважать старания человека.
Элементарное ограничение по IP на ssh порт (и вообще на все порты использующие аутефикацию типа пароль логин) и большая часть кулхацкеров идет лесом. Статья мало кому может понадобиться.
Статья отличная, наконец-то провели какой-то комплексный анализ по данному направлению. На практике всё именно так и есть, дважды убедился Начиная со списка наиболее употребимых логинов и заканчивая действиями злоумышленника Всё в статье замечательно, спасибо переводчикам, но не хватает конкретных рекомендаций, опробованных, проверенных и реально работающих. Поэтому надеюсь на активность в теме и дельное обсуждение. Кривое решение.. Частые командировки сотрудников отдела и уже не подходит и для атакующей стороны смена IP-адреса не большая проблема В туже топку.. Эти 2 рекомендации дублируют друг друга. Без комментариев =) Я не считаю это обязательным, да и эффект вряд ли будет. Сканирование изначально общедоступного сервера ещё труднее запретить или как-тол контролировать. Возможно, если баннер sshd ещё сменить, суммарно получится какой-то толк. В топку. Вечные флешки, дискеты.. А уехал, оставил случайно машину и настроенный PuTTy.. Потом смена.. А если сотрудник не одни имел доступ.. В общем, канитель ещё та. Кто и как решает эту проблему?? Сюда же думаю логично отнести проблему перебора паролей и по другим службам, в частности FTP, POP3. Сам вот смотрю в сторону sshguard. Пока что не ставил, но настройка там минимальная. Принцип простой.. Пять неудачных аутентификаций и несчастный юзер может курить 4 минуты.. Ещё пять неудачных аутентификаций... ну что поделать, не телепат.. теперь пусть пару часиков перекуривает. Думаю адекватно. Но опять-таки, это только SSH.
Интересная статья мне понравилась. Хотелось бы про это поподробнее почитать. ps кто найдет хорошую статейку без разговоров получит +8
oO Строчка: в /etc/ssh/sshd.conf намного уменшит шансы злоумышленника Можно ограничить по одному новому соединению за минуту двумя простыми правилами фаера: (для других служб аналогично) и прикрутить denyhosts/sshguard (это для тех кто не любит возится с фаером)
Это само собой как бы, специфика такая у нас. С iptables интересно, но у меня в системе его нет. Я не совсем понял как он будет себя вести в случае паралельных сессий с разных IP. _Pantera_, столкнулся на одном серваке, было дело.. Сканирую сервер, порт левый открытый и баннер выдаёт psyBNC 2.3.2.. Долго не мог понять откуда запускается.. Оказалось что через крон и ещё имя процесса маскируется под httpd. Злоумышленник забыл удалить архив откуда он это всё разворачивал, так что если кому интересно, могу выложить, там все попутные утилиты. Потом по логам прошерстил, по SSH был успешный брут. Пароль сменил. Вроде больше ничего не обнаружилось.
Статья действительно неплохая, мне понравилась Конечно не плохо, но если представить что количество аккаунтов растет то в табу релесов заносить ip адреса дело неблагодарное: Code: iptables -A INPUT -p TCP -s ! *.*.*.* --dport 22 -j DROP Вроде так, не помню сейчас тк пользуюсь pf: Code: 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 адреса атакующих через нетстат и затем заносящих в табу фаервола Бесмыслено. Даже если поменять директиву port в /etc/ssh/ssh_config то это все равно не затруднит. Все равно nmap найдет отпечаток ssh демона ну а за гидрой дело не стоит Согласен, лучше всего осущевствлять аунтефикацию по паблик/приват ключам нежели по паролю это действительно поможет + повысить таймаут при попытках ввода пароля P.S при попытках брута передаеться юзер агент? /думаю нет но все таки спрашиваю
Pantera, все сводится к тому, что управление производится через обычные nix команды, т.е ты пишешь боту чтонибудь наподобие !exec id, бот возвращает твои права в системе. Готовых ботов очень много, но вот насчет беспалевности этого варианта можно поспорить.
