Атака на SSH методом подбора паролей (SSH Brute-Force)

Если вы запустили сервис SSH, доступ к которому возможен из Интернет (обычное дело), вы наверняка наблюдали подобные записи в своих журналах аутентификации:

Sep 26 03:12:34 skapet sshd[25771]: Failed password for root from 200.72.41.31 port 40992 ssh2

Sep 26 03:12:34 skapet sshd[5279]: Failed password for root from 200.72.41.31 port 40992 ssh2

Sep 26 03:12:35 skapet sshd[5279]: Received disconnect from 200.72.41.31: 11: Bye Bye Sep 26 03:12:44 skapet sshd[29635]: Invalid user admin from 200.72.41.31

Sep 26 03:12:44 skapet sshd[24703]: input_userauth_request: invalid user admin

Sep 26 03:12:44 skapet sshd[24703]: Failed password for invalid user admin from 200.72.41.31 port 41484 ssh2

Sep 26 03:12:44 skapet sshd[29635]: Failed password for invalid user admin from 200.72.41.31 port 41484 ssh2

Sep 26 03:12:45 skapet sshd[24703]: Connection closed by 200.72.41.31

Sep 26 03:13:10 skapet sshd[11459]: Failed password for root from 200.72.41.31 port 43344 ssh2

Sep 26 03:13:10 skapet sshd[7635]: Failed password for root from 200.72.41.31 port 43344 ssh2

Sep 26 03:13:10 skapet sshd[11459]: Received disconnect from 200.72.41.31: 11: Bye Bye Sep 26 03:13:15 skapet sshd[31357]: Invalid user admin from 200.72.41.31

Sep 26 03:13:15 skapet sshd[10543]: input_userauth_request: invalid user admin

Sep 26 03:13:15 skapet sshd[10543]: Failed password for invalid user admin from 200.72.41.31 port 43811 ssh2

Sep 26 03:13:15 skapet sshd[31357]: Failed password for invalid user admin from 200.72.41.31 port 43811 ssh2

Sep 26 03:13:15 skapet sshd[10543]: Received disconnect from 200.72.41.31: 11: Bye Bye Sep 26 03:13:25 skapet sshd[6526]: Connection closed by 200.72.41.31

Именно так выглядит атака перебором паролей, более известная как brute-force. Кто-то или что-то, пытается с помощью грубой силы подобрать имя пользователя и пароль для входа в вашу систему. Простейшей реакцией станет написание правила в pf.conf, которое будет блокировать весь доступ. Однако, это приведёт к ряду проблем, первой из которых

станет вопрос – как предоставить доступ к сервису легитимным пользователям. Настройка sshd принимает только аутентификацию основанную на ключе, однако это скорее всего не остановит попыток получения доступа. Вы можете рассмотреть вопрос о переводе сервиса на другой порт, но существует вероятность, что те кто сканировал порт 22, с таким же упехом обнаружат и порт 22222.

(Практика показывает, что смена порта SSH на порт из верхнего диапазона, в значительной мере сокращает  число попыток несанкционированого доступа, хотя, конечно не исключает их. Применяя этот способ в качество одной из мер предосторожности можно добиться некоторых успехов – п.п.).

Начиная с OpenBSD 3.7, PF предлагает несколько более элегантное  решение  данной проблемы.

Настройка адаптивного брандмауэра                                      Для  предотвращения атак подбором паролей, вы можете написать  правила  пропуска таким  образом, чтобы  они  поддерживали определённые  ограничения на возможности подключающихся хостов.  На  всякий  случай,  вам  следует  направлять нарушителей  в таблицу адресов, для которой запрещён весь доступ или некоторые виды доступа. Можно даже указать блокирование всех подключений от машин перекрывших свои лимиты. Для включения  этой  функции,  создайте  таблицу  добавив  следующую  строку   в   файл

конфигурации перед правилами фильтрации:

table <bruteforce> persist

Затем, в начале набора правил блокируем брутфорс, как показано ниже:

block quick from <bruteforce>

Наконец добавим пропускающее правило:

pass inet proto tcp to $localnet port $tcp_services keep state (max-src-conn 100, max-src-conn-rate  15/5, overload

<bruteforce> flush global)

Это  правило  очень  похоже  на  те  которые  мы  видели  в  более  ранних  примерах. Интересная   часть   его   контекста,   заключённая   в   скобки,    называется   опциями отслеживания состояний:

•     max-src-conn – число одновременных соединений позволенных от одного хоста. В данном примере установлено в 100. Вы можете установить значение больше или меньше в зависимости от параметров вашей сети.

•     max-src-conn-rate  –  число  новых подключений позволеных от  одного  любого хоста.  Зесь  установлено  в  15  соединений  за  5  секунд,  записанное  как  15/5. Выберите значение соответствующее вашей установке.

•     overload <bruteforce> – означает, что адрес любого хоста, который  превысил текущие лимиты будет добавлен в таблицу bruteforce. Соответственно, наш набор правил блокирует весь трафик с адресов  попадающих в эту таблицу. Как только хост превышает любой из этих лимитов и попадает в таблицу перегрузки, правило перестаёт   сопоставлять  трафик   с   этим   хостом.   Убедитесь,   что   перегрузка обрабатывается только правилом блокировки по умолчанию или аналогичным.

•     flush global – сообщает, что когда хост достигает лимита, все состояния для его соединений  уничтожаются  (сбрасываются).  Опция   global  означает,  что  мера применяется и для состояний созданных для трафика этого хоста которые так же соответствовали другим правилам пропуска.

Как  вы  понимаете, эффект от  этого небольшого дополнения набора  правил  весьма драматичен. После нескольких попыток подбора пароля,  адрес  хоста производившего брутфорс попадает в таблицу bruteforce. А это, в  свою очередь, означает, что все его существующие  соединения   уничтожаются   (сбрасываются),  а  любые  новые  попытки соединения будут заблокированы, скорее всего постоянно. Таким образом вы только что создали адаптивный брандмауэр, который автоматически настраивается на условия вашей среды и самостоятельно воздействует на нежелательную активность.


Замечание

Наши адаптивные правила действуют только для защиты от традиционных и простых попыток подбора паролей. Рапределённые попытки подбора производящиеся с низкой интенсивностью, факт применения которых был впервые зафиксирован в 2008 году (известные среди прочих под названием The Hail Mary Cloud) не проявляют аналогичной активности и не будут соответствовать параметрам данных правил.

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

pass quick proto { tcp, udp } to port ssh \

keep state (max-src-conn 15, max-src-conn-rate 5/3, \ overload <bruteforce> flush global)

Вам  придётся  самостоятельно  найти  необходимые  параметры  подходящие  к  вашей ситуации, обратившись  к соответствующим  man-страницам и  руководству  PF (смотрите приложение А).

Замечание

Помните, что данные примеры правил предназначены для иллюстрирования работы, а в поддержка сервисов вашей сети может потребовать значительной переработки правил. Установка слишком низкого уровня количества одновременных соединений или скорости соединий может привести к блокированию законного трафика и созданию внутреннего источника отказа обслуживания, в случае, если конфигурация включает множество узлов находящихся за общим шлюзом NAT.

Опции   отслеживания   состояний   и   механизм   перегрузки   не   следует   применять исключительно к сервису  SSH, а блокирование  всего  трафика  атакующего не всегда полезно. Например можно использовать следующее правило:

pass proto { tcp, udp } to port $mail_services keep state (max 1500, max-src-conn 100)

Здесь, max определяет максимальное число состояний, которые могут быть созданы для каждого правила  (или  ряда  правил,  в   зависимости  от  того  как  расширяется макрос

$mail_services)  без  перегрузки  для  защиты  почтового  или  web  сервиса  с  приёмом большего числа соединений чем то которое он может обработать. С  таким правилом,

значение max определяет максимальное число состояний, которые будут  созданы для

каждого   результирующего   правила.   Как   только   будет   достигнут   предел,   новые соединения не будут разрешаться вплоть до завершения существующих.

Альтернативно, можно удалить ограничение max и добавить в  правила часть overload, и назначить атакующим очередь с минимальным выделением полосы пропускания (смотрите

обсуждение настройке очередей ALTQ в главе 7).

Некоторые сайты используют overload для реализации многоуровневой  системы, где хосты  попадающие  под  правило   overload  направляются   на   одну  или  несколько

промежуточных "испытательных" таблиц для специальной обработки. Это  может быть

полезно при работе с web содержимым, и позволит  не блокировать трафик от  хостов в таблице перегрузки непосредственно,  а направлять  все  HTTP запросы  от  этих узлов  на определённые web-страницы (как мы видели в примере authpf в конце Главы 4).

Очистка таблиц с помощью pfctl                                              Используя правила overload описаные в  предыдущем разделе, вы получили адаптивный брандмауэр, который автоматически определает нежелательное поведение и добаляет IP адреса  нарушителей  в   таблицы.  Просмотр  журналов  и  таблиц  может  быть  весёлым занятием,   однако,   поскольку  правила   только   добавляют   данные   в    таблицы   мы сталкиваемся со следующей задачей: поддержание актуальности таблиц.

Когда вы  запускаете конфигурацию с адаптивным  набором правил,  через  некоторое время вы обнаруживаете, что одни IP адреса, недавно заблокированные из-за брутфорса,

в   настоящее  являются  вполне  легальными  для  работы  с  вашей  сетью1.  Если  ваши

адаптивные  правила  собираю  много  трафика,  вы  можете  обнаружить,  что  таблицы перегрузки быстро разрастаются и занимают много места. Решение  данной проблемы заключается в   создание записей срока истечения таблиц  (expire) – необходимых для удаления записей на которые небыло ссылок за  определённое время.  В OpenBSD 4.1 инструмент pfctl приобрёл способность создавать в таблице записи expire основываясь на

статистических параметрах времени,  таких как последний сброс2. (Практически  во  всех случаях,  время  сброса  равно  времени  добавления  записи  в   таблицу).  Используется ключевое слово expire и возраст записи таблицы, указываемый в секундах. Например:

$ sudo pfctl -t bruteforce -T expire 86400

Эта команда удалит записи таблицы bruteforce для которых статистика сброса превысила 86400 секунд (24 часа).

Замечание

Выбор значения 24 часа в качестве времени истечения – величина довольно произвольная. Вы должны  выбирать значение которое вам наиболее подходит, величину соответствующую разумному времени обнаружения и устранения проблемы. Если у вас присутствуют адаптивные правила, будет хорошей мыслью создать запись  cron, для периодического выполнения очистки таблиц используя команду указанную выше. Это позволит содержать таблицы в актуальном состоянии.

Источник: Книга о PF, by Peter N.M. Hansteen, Перевод выполнил Михайлов Алексей aka iboxjo

Похожие посты:

Вы можете оставить комментарий, или ссылку на Ваш сайт.

Оставить комментарий