Защита от DDoS атак типа SNMP Amplification.

Чтобы сделать свой вклад в защиту от DDoS атак типа SNMP Amplification, совсем не обязательно покупать дорогостоящее оборудование или сервис. Любой администратор сервера, доступного из интернета, может поучаствовать в столь благородном деле без дополнительных материальных вложений, используя только знания и немного времени.

SNMP Amplification DDoS

Так выглядит трафик при SNMP Amplification DDoS атаке.

DDOS атака SNMP Аmplification

Суть атаки заключается в том, чтобы инициировать многократно увеличенный ответ на SNMP-запрос. Изначально разработанные для автоматизации получения табличных данных при минимизации количества отправляемых пакетов BULK-запросы стали довольно эффективным инструментом проведения DDoS-атак в руках злоумышленников. Как гласит RFC3416, GetBulkRequest, реализованный в SNMP версии 2, предназначен для возможности запросить большой объем данных, чем и пользуются атакующие, задействуя неправильно настроенные серверы в интернете.

Если установить максимальное число возвращаемых строк в таблице 20000 и выполнить запрос в адрес неправильно настроенного сервера/устройства:

ответ выдаст приблизительно следующее:

При этом запущенный tcpdump покажет размер возвращенного пакета:

В ответ на запрос размером около 70 байт с учетом заголовков сервер возвращает ответ размером порядка 10 килобайт, то есть почти в 150 раз больше. Коэффициент усиления не фиксирован и может принимать как большее (достигая 1700 раз), так и меньшее значение, в зависимости от типа ОС и параметров конфигурации устройства. Если при формировании подобного запроса использовать подмену IP-адреса отправителя на адрес жертвы и высокую интенсивность обращений к уязвимому серверу, DDoS-атака готова.

SNMP Amplification

Причина возникновения DDoS атак

Суть уязвимости заключается, как правило, не в настройке количества отдаваемых значений на один GetBulkRequest, а в том, что значение SNMP community установлено по умолчанию: public – read-only или, что еще хуже, private – readwrite.

Протокол SNMP версий 1 и 2 основан на UDP, используется для мониторинга и управления, а в качестве аутентификационного параметра доступа к управляемому оборудованию использует значение community, которое может быть задано только для чтения (read-only) либо с возможностью записи (read-write). Зачастую в системах при активации сервиса SNMP устанавливается значение по умолчанию – public для read-only и private для read-write.

Даже если абстрагироваться от возможности использования некорректно настроенного сервера в качестве рефлектора для усиления атак SNMP, то очевидна угроза получения информации о сервере, установленном на нем ПО и его версиях при использовании значения public по умолчанию для read-only.

SNMP Amplification

Практически безграничный привилегированный доступ с правами администратора к устройству дает read-write community private. Даже если не будут производиться вредоносные изменения, интенсивные запросы с использованием протокола SNMP могут вызвать значительную нагрузку на вычислительные ресурсы опрашиваемого сервера, чем повлиять на качество предоставляемых им сервисов.

Защита от DDoS атак типа SNMP Amplification

Общие рекомендации для уязвимых к атакам с использованием подмены адреса протоколов на базе UDP предоставлены в BCP38 и RFC2827 и описаны в предыдущих статьях.

Специфические для SNMP рекомендации по обеспечению безопасности сервера либо сетевого оборудования можно разделить на такие направления:

  • Архитектурное: разрешение обработки запросов только на интерфейсах, недоступных из не доверенных сетей.
  • Смена community на более трудно-угадываемое.
  • Ограничение IP-адресов управляющих станций.
  • Ограничение ветки OID, доступной для получения/изменения по SNMP.
  • Минимизация либо отказ от использования community на чтение и запись.
  • Переход на SNMP версии 3 с использованием дополнительных параметров аутентификации и шифрования.
  • Отключение SNMP, если не используется.

Как выполнить эти действия на разных системах?

Защита от DDoS SNMP Amplification в Unix

В конфигурационном файле сервиса SNMP настраиваются следующие параметры:

Если Unix-сервер, по сути, является маршрутизатором и архитектурно имеет несколько интерфейсов, для безопасности необходимо оставить доступным по SNMP только интерфейс, доступный из доверенного сегмента, но не из интернета. Имя community для доступа задается параметром rocommunity (read-only) либо rwcommunity (read-write), также возможно задать подсеть, доступ из которой разрешен, и ветку OID, доступную для работы указанной подсети с заданными правами строки community.

Например, для того чтобы разрешить системам мониторинга из подсети 10.0.0.0/24 доступ к информации по интерфейсам (OID 1.3.6.1.2.1.2), используя строку доступа MaKe_ It_SeCuRe с правами только для чтения, конфигурационный фрагмент будет выглядеть следующим образом:

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

Но если задача состоит в том, чтобы максимально быстро обеспечить безопасность сервиса snmpd, который до этого был настроен неправильно предшественником, можно создать резервную копию snmpd.conf, в новый конфигурационный файл внести ограничения по подсети систем мониторинга и изменить community. В Debian это будет выглядеть следующим образом:

После этого доступ по SNMP к серверу будет только у подсети 10.0.0.0/24 с использованием нового community, при этом все серверы, на которых не изменено community на новое, перестанут получать ответы на запросы, как и злоумышленники.

Более безопасным будет переход на использование SNMPv3, в котором существует возможность варьирования параметров аутентификации. Кроме того, в отличие от версий 1 и 2c SNMPv3 позволяет обеспечить шифрование трафика между системой мониторинга и опрашиваемым оборудованием.

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

Соответственно, пользователь v3user получит права read-only для просмотра ветки 1.3.6.1.2.1.2 по SNMP.

Проверить корректность конфигурации можно после рестарта сервиса SNMP на сервере 192.168.10.128 командой, выполненной на клиенте:

При этом, несмотря на то что опрашиваться будет все дерево начиная с 1, сервер отдаст только разрешенную ветку 1.3.6.1.2.1.2, которая будет задана в конфигурации.

При отказе от SNMP v1/v2c в пользу SNMPv3 необходимо также удалить из конфигурационного файла фрагменты настройки, не имеющие отношение к SNMPv3.

Если же SNMP для мониторинга сервера не используется, наиболее верным решением будет удаление пакета snmpd.

Защита от DDoS SNMP Amplification на оборудовании Cisco

В Cisco IOS отсутствует возможность выбора интерфейса, который будет обрабатывать запросы SNMP. Ограничение выполняется с помощью списков доступа (access-control list, ACL). Предположим, разрешенной будет подсеть 10.0.0.0/24. Создается ACL:

который затем применяется к соответствующему community для SNMP v1/v2c, в данном примере MaKe_It_SeCuRe с правом доступа только на чтение:

Ограничение к веткам SNMP OID применяется с помощью view:

после чего к созданному view прикрепляется community:

Для того чтобы использовать SNMPv3 с необходимыми ограничениями (аутентификация и шифрование, только чтение, доступ из подсети 10.0.0.0/24 к ветке интерфейсов, обозначенной во view IFACES), необходимо создать группу (SECURE) с доступом на чтение только к OID из view IFACES и необходимостью аутентификации с шифрованием, привязав ее к созданному ранее access-list 10:

Затем добавить в группу учетную запись пользователя (v3user), задав ему пароли на аутентификацию и шифрование, а также алгоритм шифрования (в данном случае AES128):

Проверка работоспособности SNMPv3 с вышеописанными настройками производится командой:

При этом также устройством будут возвращены значения только тех веток SNMP OID, которые добавлены в соответствующее view (в данном случае IFACES).

При переходе с SNMP v1/v2c на более защищенный SNMPv3 также необходимо удаление настроек с snmpserver community.

Если принято решение не использовать SNMP для мониторинга и управления устройством под управлением Cisco IOS, отключение производится следующей командой:

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

Предположим, на сервере определены значения

Удалить их можно (и нужно) добавлением no и повторением команды из конфигурации:

Первоначальной причиной возможности использования устройства для выполнения DDoS-атаки SNMP Amplification является не уязвимость, а настройка по умолчанию SNMP community.

Наличие подобных настроек – существенная брешь в безопасности системы в связи с тем, что протокол SNMP может использоваться для управления, и настройка параметров доступа по умолчанию по степени опасности сравнима с легко-угадываемым паролем для входа по SSH.

Выполнив описанные в статье рекомендации, мы не только напрямую защитимся от атак на нашу сеть и серверы, но сделаем невозможным использование своих ресурсов для атак на других, а также минимизируем количество оснований для кричащих заголовков в прессе «Русские хакеры атаковали…».

Итого: защитить свои серверы и сеть от несанкционированного доступа с использованием протокола SNMP, уменьшить количество DDoS-атак типа SNMP Аmplification и минимизировать участие в них своего инфраструктурного сегмента можно с помощью следующих несложных действий, не требующих дополнительных финансовых вложений:

  • Управление оборудованием только из доверенного сегмента сети. Ограничение посредством привязки сервиса к определенному интерфейсу либо с помощью списков доступа.
  • Изменение значений SNMP community по умолчанию (public и private) на трудно-угадываемые.
  • Ограничение ветки OID, доступной для получения/изменения по SNMP.
  • Использование только SNMPv3 с применением дополнительных параметров аутентификации и шифрования.
  • Отключение сервиса SNMP с удалением конфигурации – в случае принятия решения о полном отказе от SNMP.

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

Рейтинг материала
[Голосов: 2 Рейтинг: 5]
11 февраля 2017, 02:02

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

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