Защита от DDoS подручными средствами. Часть 2. NTP Amplification

Сводка недоступна. Нажмите эту ссылку, чтобы открыть запись.

Защита от DDoS подручными средствами. Часть 1. DNS Amplification

По согласованию с редакцией журнала публикую свою статью "Защита от DDoS подручными средствами. Часть 1. DNS Amplification" из майского (2016) выпуска журнала "Системный администратор".

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

Рассмотрим DDoS-атаки типа "усиление"(amplification) с использованием сервиса DNS.

EPICBANANA exploit for Cisco firewalls: checklist and fix

The article in Cisco blog with the EXTRABACON description has also information about EPICBANANA exploit executed via CLI.
Vulnerable devices list is much less that SNMP one and it consists of ASA 5500 series, ASA 5500-x series, PIX and FWSM.
Exploit is able to cause a denial if service condition or arbitrary code execution by invoking certain invalid commands in an affected device. But an attacker must:

• Know ASA interface IP-address with ssh or telnet permission.
• Know login and password.
• Connect to the box from trusted IP-address.

So, it is not very hard-to-protect situation but this bug is also a bug.

EXTRABACON SNMP-exploit for Cisco firewalls - diagnostics, workaround and fix

There are lot of discussions about Shadow Brokers' published exploits NSA for a last time. But the situation became interesting when Cisco alerted to the information posted with exploits confirmation.

Cisco blog contains article about Shadow Brokers' exploits. It provides some clarity in the context of danger: to fear ot not to fear, who must be afraid of this, what is the topic of the fair and how to fear.
Additional thank to Maxim Zimovets (Cisco lvl80 engineer) for emergency analysis and vendor-side conclusion.

CLI-эксплоит EPICBANANA для Cisco - лекарство и проверка на будущее

В той же статье цискиного блога, где рассказывается об SNMP-эксплоите EXTRABACON, есть разъяснения на тему эксплоита EPICBANANA, который исполняется через CLI.

Список уязвимых устройств гораздо меньший: ASA серий 5500 и 5500-X, PIX и FWSM.

Суть уязвимости заключается в возможности вызвать отказ в обслуживании устройства либо исполнить произвольный код посредством отправки нескольких неправильных команд на скомпрометированное устройство. Но для этого хакер должен:

• Знать IP-адрес интерфейса, на который разрешен управляющий доступ по telnet либо SSH.
• Знать логин-пароль к устройству. 
• Подключиться с разрешенного в конфигурации IP-адреса для управления.

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

SNMP-эксплоит EXTRABACON для Cisco - диагностика, заплатки и лечение

Наверное, в последнее время о продаваемых эксплоитах им. АНБ не говорил только ленивый. Но когда циска подтвердила, что таки да, 2 из них реально рабочие - стало совсем интересно. Конечно, об этом было и в новостях сесуритулаба, и на других ресурсах.

В цискином блоге есть статья о Shadow Broker'ских эксплоитах, вносящая ясность о том, стоит ли бояться, кому стоит бояться, чего бояться и как бояться. Похоже, моя заметка будет наполовину содрана с нее, но да простят меня мои читатели (все 5 или аж 6) за отсутствие количества авторских изюминок до стадии кекса. 

Ну и, конечно, отдельное спасибо инженеру Максиму Зимовцу из Cisco за оперативный анализ, в каких случаях и кому надо бояться.

NPTv6 (IPv6 NAT 6to6) security

Как я уже писал ранее, IPv6 разрабатывался с целью обеспечения всех нуждающихся IP-адресами. Естественно, в этом случае необходимость NAT на фоне концепции полной прозрачности адресации и общей математической эйфории "каждому юзеру по провайдерскому диапазону" смотрится довольно блекло. Это потом, когда возникает необходимость "спрятать" от Интернета IPv6-адрес интерфейса управления электростанцией, телеком-инфраструктурой, или ПК генерального директора - становится понятно, что старый добрый NAT 4to4 - не рудимент древней адресации, а вполне себе неплохой инструмент сетевой безопасности. Кроме того, процесс миграции всей сети на IPv6 - тоже не очень тривиальная задача. Необходимо обеспечить поддержку IPv6 на уровнях:

• Клиента;
• Сервера;
• Сети L3-доступа;
• Всех промежуточных сетевых устройств;
• А чтобы пользователь меньше всего почувствовал, то еще и в DNS (AAAA-записи, RFC3596).

Так что, как ни крути, а NAT пригодится.

IPv6 security: NAT или не NAT?

Довольно интересную посмотрел презентацию по безопасности IPv6, описанную на конференции в Сингапуре SGNOG3 под названием Security in an IPv6 World: Myths and Reality

Несмотря на большое количество реально полезной информации, на одном из слайдов как "миф" указано то, что реализация IPv6 без NAT понижает уровень безопасности, а как "реальность" - то, что вас спасет stateful firewall, в то время как NAT может даже понизить уровень безопасности.

Собственно, это уже предмет для дискуссии.

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

Например, возьмем firewall. Казалось бы, его наличе делает мир лучше и безопаснее. Меняем в определенном сетевом участке маршрутизатор на stateful firewall - и считаем, что мир стал сказкой, теперь ничего не страшно. При этом ни правил анти-спуфинга, ни ACL не настраиваем. Только функции firewall по умолчанию. Именно это ложное ощущение защищенности без определенных действий и является тем фактором, который в итоге только вредит, хотя изначальная цель была противоположной. Равно как если человеку дать пистолет для самозащиты - пользы от него не будет, если он стрелять не умеет или не может психологически. Только хуже станет.