Компания Cloudflare предупредила (https://blog.cloudflare.com/ssdp-100gbps/) об увеличении интенсивности применения протокола SSDP (Simple Service Discovery Protocol), используемого в системах с поддержкой UPnP, в качестве усилителя трафика при проведении DDoS-атак. Cloudflare обращает внимание на практику оставления доступа к 1900 UDP-порту, который позволяет при обработке некоторых запросов, формировать ответы, по размеру многократно превышающие запрос, чем пользуются организаторы DDoS-атак.Смысл атаки с использованием усилителя трафика сводится к тому, что запросы с участвующих в DDoS-атаке компьютеров направляются не напрямую на систему жертвы, а через промежуточный усилитель трафика, путем отправки UDP-пакетов с подставным обратным адресом жертвы (спуфинг). SSDP позволяет в 7 раз приумножить число используемых в атаке пакетов и в 20 раз приумножить трафик. Для сравнения коэффициент усиления для NTP составляет 556 раз, DNS - 28-54, RIPv2 - 21, SNMPv2 - 6. Имея современный сервер с подключением 10 Gbps и используя SSDP как усилитель, c учётом необходимости проведения спуфинга, можно сформировать поток на уровне 43 миллионов пакетов в секунду с трафиком в 112 гигабит в секунду.
Сетевой UDP-порт 1900 применяется протоколами SSDP и UPnP для обнаружения новых устройств в локальной сети. В качестве одного из методов обнаружения поддерживается M-SEARCH, подразумевающий отправку
multicast-запросов по адресу 239.255.255.250. Все устройства, принимающие соединения на данном multicast-IP, получив запрос M-SEARCH с заголовком "ssdp:all", в ответ сообщают информацию о себе,
uuid, тип сервера и URL Web API. Проблема заключается в том, что подобные запросы не ограничиваются локальной сетью, обрабатываются при поступлении на обычный (unicast) IP и используют протокол UDP, позволяющий выполнить спуфинг (указать фиктивный обратный IP-адрес). В итоге, в ответ на один пакет с запросом, UPnP-устройство отправляет 8 пакетов с информацией.
Пользователям и администраторам рекомендуется обеспечить блокировку доступа к сетевому UDP-порту 1900 из внешних сетей. Наибольшее число участвовавших в атаках систем с открытым портом 1900 отмечается в Китае (439126), России (135783, в top10 операторов через которые выполняется усиление трафика фигурируют Вымпелком/Билайн и ЭР Телеком/Дом.ru), Аргентине (74825), США (51222) и республике Тайвань (41353). Сетевым операторам рекомендуется настроить фильтры для блокирования спуфинга. Проверить свою систему на предмет возможности её применения в качестве усилителя трафика можно через web-сервис Bad UPnP (https://badupnp.benjojo.co.uk/).
Рейтинг идентификаторов устройств, участвовавших в атаке в качестве усилителей трафика:- 12863 Ubuntu/7.10 UPnP/1.0 miniupnpd/1.0
- 11544 ASUSTeK UPnP/1.0 MiniUPnPd/1.4
- 10827 miniupnpd/1.0 UPnP/1.0
- 8070 Linux UPnP/1.0 Huawei-ATP-IGD
- 7941 TBS/R2 UPnP/1.0 MiniUPnPd/1.4
- 7546 Net-OS 5.xx UPnP/1.0
- 6043 LINUX-2.6 UPnP/1.0 MiniUPnPd/1.5
- 5482 Ubuntu/lucid UPnP/1.0 MiniUPnPd/1.4
- 4720 AirTies/ASP 1.0 UPnP/1.0 miniupnpd/1.0
- 4667 Linux/2.6.30.9, UPnP/1.0, Portable SDK for UPnP devices/1.6.6
- 3334 Fedora/10 UPnP/1.0 MiniUPnPd/1.4
- 2044 miniupnpd/1.5 UPnP/1.0
- 1325 Linux/2.6.21.5, UPnP/1.0, Portable SDK for UPnP devices/1.6.6
- 843 Allegro-Software-RomUpnp/4.07 UPnP/1.0 IGD/1.00
- 776 Upnp/1.0 UPnP/1.0 IGD/1.00
- 675 Unspecified, UPnP/1.0, Unspecified
- 648 WNR2000v5 UPnP/1.0 miniupnpd/1.0
- 562 MIPS LINUX/2.4 UPnP/1.0 miniupnpd/1.0
- 518 Fedora/8 UPnP/1.0 miniupnpd/1.0
- 372 Tenda UPnP/1.0 miniupnpd/1.0
- 346 Ubuntu/10.10 UPnP/1.0 miniupnpd/1.0
- 330 MF60/1.0 UPnP/1.0 miniupnpd/1.0URL: https://blog.cloudflare.com/ssdp-100gbps/
Новость: https://www.opennet.ru/opennews/art.shtml?num=46780
Удобна штука upnp, но последние новости как-то не радуют.
Обычно пользовался когда временно нужен доступ мимо впн к spice серверу с авторизацией.
upnpc -a 192.168.1.102 5900 5900 tcp
Надо будет в моём SSDPd добавить крутилку чтобы задавать TTL для ответов.
Где они столько убунту 7.10 откопали? Восстание зомби?
это эмуляторы убунты в десятом мастдае
В miniupnpd разве эта проблема не решается настройкой secure_mode=yes (выставленной в openwrt по умолчанию) при которой ответы будут отправляться только на адрес с которого пришел запрос и только в том случае если перенаправление запрашивалось на тот же адрес с которого пришел запрос?
И зачем вообще upnp вещать на интерфейс смотрящий во внешнею сеть?
"только на адрес с которого пришел запрос"
Вот туда и отправляется. Аж целых 7 пакетов."во внешнею сеть"
По-умолчанию, как обычно.
Из новости:
> Проблема заключается в том, что подобные запросы не ограничиваются локальной сетью, обрабатываются при поступлении на обычный (unicast) IP и используют протокол UDP, позволяющий выполнить спуфинг (указать фиктивный обратный IP-адрес).Так ведь вроде как смысл атаки как раз в том чтобы слать ответы на фиктивный обратный IP-адрес. Если слать на адрес отправителя запроса то ddosить будут сами себя.
Отправитель может подставить в IP заголовке в поле source address вместо своего адрес жертвы. На этом основаны все атаки с умножителями, как впрочем и большинство других.
но как они это делают? ведь чтобы незаметно подставлять чужие адреса нужно быть подключеным к магистральному роутеру, причем на условиях транзита (другие просто не примут пакеты с чужими ип).
> но как они это делают? ведь чтобы незаметно подставлять чужие адреса нужно быть подключеным к магистральному роутеру, причем на условиях транзита (другие просто не примут пакеты с чужими ип).Так для них по барабану, какой src стоит
>> но как они это делают? ведь чтобы незаметно подставлять чужие адреса нужно быть подключеным к магистральному роутеру, причем на условиях транзита (другие просто не примут пакеты с чужими ип).
> Так для них по барабану, какой src стоитчто-то я сомневаюсь что админы магистралов таким способом "подрабатывают". скорее всего админы некоторых дц не осилили фильтрацию :)
Как ты будешь фильтровать udp-спуфинг?
Речь о фильтрации не входящего udp-спуфинга, а исходящего. Каждый конечный ISP знает сетки, которые на него роутятся, а значит и все ip адресса, которые могут стоять в source address поле IP пакетов, которые он выпускает в мир. Добавив фильтрацию на своих внешних роутерах, он может зарезать все пакеты, которые в качестве source указывают ip, не "принадлежащий" ISP. Если все так сделают, то спуфинг будет возможным только в пределах ISP. В реальности же сплошь и рядом ISP, как "домашние", так и в датацентрах, не делают такую фильтрацию.
С сервера я могу посылать пакеты на произвольный адрес, а не только внутри сети ISP
Суть предлагаемой вашим собеседником фильтрации, проверка поля Source IP, а не Destination IP, поэтому не важно куда вы шлёте пакет, он всё равно пройдёт через маршрутизатор оператора и там может быть подвержен фильтрации.Но, в реальности так делают не все, по разным причинам без спорно, где-то техническим, а где-то административным.
Существование RFC 2827, как и разного рода руководств по внедрению Unicast Reverse Path Forwarding в сетях, не означает, что каждый сетевой инженер, применяет данные рекомендации и более того, в ряде случаев применение strict uRPF вообще не возможно.Каждая автономная система, вольна сама устанавливать свои собственные правила и политики, относительно фильтрации или невмешательства в транзитный трафик или порождаемый данной AS трафик. В идеальном мире, каждый оператор должен реализовать BCP 38 и не только его, а и например Remote Triggered Blackhole Filtering RFC 5635, через BGP communities. Но, мы живём в несовершенном мире, где не всегда лучшие практики становятся беспрекословно выполняемым условием.
> и не только его, а и например Remote Triggered Blackhole Filtering
> RFC 5635, через BGP communities. Но, мы живём в несовершенном мире,а вот это как раз после первого хорошего ddos'а на "любимого" клиента само образуется ;-)
Особенно если инженер где-то не у консоли в тот момент окажется, а клиент правильно опишет менеджеру, кто козел и почему.
> причем на условиях транзита (другие просто не примут пакеты с чужими ип).с разморозкой. 1996й год давно прошел, никто уже не вешает фильтры на каждый клиентский порт. Хомянеттеры не в счет, с них много не наддосишь. Хотя я и хомянеттеров никогда не фильтровал, нахрен не нужен геморрой себе на жопу своими же руками.
А в свете "мигрирующих" v4 блоков уже и фильтрация bgp благополучно пошла лесом (да и была-то она почти только в области деятельности ripe, остальные тоже давно забили... э... даже, пожалуй, предположу не столько ripe, сколько трех стран с кодом +7)
Всегда когда покупал какой-нибудь роутер, сразу отключал UPnP и открывал порты вручную. Всегда эта фича казалась жуткой уявзимостью. Ведь любая прога может легко открыть порт для коннектов извне без моего ведома, то есть, по сути, прогонять через мой комп несанкцианированный мною трафик.
Отключаю службу UPnP. Не представляю, зачем она нужна. Это ДЫРА.
Тогда и бзд тоже выключи
А Тайвань уже не Китай?
ха-ха, смищно
Всем привет!Как обычно - рекомендую наш open source инструмент, https://github.com/pavel-odintsov/fastnetmon SSDP умеем уже почти два года.
Кроме этого, можем порекомендовать магистрального провайдера RasCom, так как они позволяют применять BGP Flow Spec и отсекать подобный паразитный трафик до того, как он дойдет до вашего оборудования.
Народ, а есть ли хоть какой-то смысл держать включённым UPnP на роутере, если я сижу за провайдерским натом?
Если IP белый есть, то да.