OKyHb Опубликовано 1 июня, 2013 · Жалоба За последних 2 недели на на некоторых наших абонентов уже раз пять прилетало по несколько гигабит DDOS трафика. Проблема зачастила, надо что-то решать. Особенности нашей сети - белые ip адреса, для большого к-ва абонентов скорость не ограничивается (на скорости порта - 100Mb). В последних случаях из мира на какой-нить один абонентский ip прилетало по ~3Gb udp трафика. Для 10G аплинков не страшно, а вот дальше этот трафик забивал 1G линки на свичах - и начинали старадать абоненты всей ветки. Основная часть такого трафика - фрагментированные udp пакеты большого размера с разных src ip. Скриншот из wireshark для наглядности: Пока просто прописывали /32 маршрут в null, чтоб не страдали остальные абоненты. Но это всё вручную и долго. Поэтому интересует опыт коллег, как с этим бороться. 1. Можно ли безболезненно вырезать такой трафик при помощи ACL? (к примеру "deny udp any any fragments") Какой полезный полезный трафик при этом пострадает? 2. Если полностью вырезать нельзя, может стоит ограничить fragmented udp через service-policy до приемлемых значений? (к примеру, 50Mb для 10G аплинка) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 1 июня, 2013 · Жалоба Похоже, опять жопорукие разрабы юторрента накосячили... Пробуйте резать ютп. Думаю полегчает. Подробнее - тут. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
MMM Опубликовано 1 июня, 2013 · Жалоба Подзабыл матчасть.. у udp frag присутсвует номер порта? Если присуствует, то можно по диапазону портов фильтровать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
MMM Опубликовано 1 июня, 2013 · Жалоба Похожее рядом Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dmvy Опубликовано 2 июня, 2013 · Жалоба +1 на днях словили подобный ddos. Более 6гбит и порядка 1мегапакета. Смотрел исходящий трафик абонента - торрент клиент запущен не был. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 2 июня, 2013 · Жалоба Проще IP засовывать в БГП блэкхоле. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
stepyourlifegameup Опубликовано 3 июня, 2013 · Жалоба Проще IP засовывать в БГП блэкхоле. Человек хочет автоматизировать и делать это быстро. Далеко не у всех аплинков есть подобный инструмент и все равно заворачивать в null будут по письму/звонку. На своем бордере топик стартер это и так реализовывает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 3 июня, 2013 · Жалоба Проще IP засовывать в БГП блэкхоле. Человек хочет автоматизировать и делать это быстро. Далеко не у всех аплинков есть подобный инструмент и все равно заворачивать в null будут по письму/звонку. На своем бордере топик стартер это и так реализовывает. Значит, пинать аплинков, чтоб тоже сооружали BGP blackhole. Кстати, какая автоматизация в определении ДДоС? Все равно ручками определяешь целевой IP и/или сервис, пытаешься выявить источники и соорудить фильтры... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SeroeKrevedko Опубликовано 25 марта, 2016 (изменено) · Жалоба Вообще cisco советует вот здесь https://www.cisco.com/c/en/us/support/docs/ip/access-lists/13608-21.html в начале каждой acl делать следующее: deny tcp any any fragments deny udp any any fragments deny icmp any any fragments deny ip any any fragments ТС так никто и не ответил, кто-то использует подобные конструкции, и к чему это может привести? Фрагментированные пакеты в сети должны ходить ведь, а все проблемы создают не-инициализированные фрагменты. Изменено 25 марта, 2016 пользователем SeroeKrevedko Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
uxcr Опубликовано 25 марта, 2016 · Жалоба Особенности нашей сети - белые ip адреса, для большого к-ва абонентов скорость не ограничивается Значит нужно исправить эту "особенность". Можно прикладывать подорожник в виде блэкхола на роутере, где происходит переход 10G->1G, но лучше починить дизайн. Кстати блэкхол не обязательно означает перераздачу анонса аплинкам, просто сервант будет анализировать flow и закидывать по bgp на роутер атакуемые айпишники для блокировки. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Danila Опубликовано 25 марта, 2016 · Жалоба Откопали же вы стюардессу. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Butch3r Опубликовано 25 марта, 2016 · Жалоба Вообще cisco советует вот здесь https://www.cisco.com/c/en/us/support/docs/ip/access-lists/13608-21.html в начале каждой acl делать следующее: deny tcp any any fragments deny udp any any fragments deny icmp any any fragments deny ip any any fragments ТС так никто и не ответил, кто-то использует подобные конструкции, и к чему это может привести? Фрагментированные пакеты в сети должны ходить ведь, а все проблемы создают не-инициализированные фрагменты. мы такой дени не используем, стоит начать? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SeroeKrevedko Опубликовано 25 марта, 2016 · Жалоба мы такой дени не используем, стоит начать? нас сегодня ночью ддосили, суммарно наверно на 15 Гб, udp. Большинство пакетов - не инициализированные фрагменты. Вот я и хотел уточнить у коллег по опыту использования данных правил. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Telesis Опубликовано 25 марта, 2016 · Жалоба а это не для защиты CPU? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SeroeKrevedko Опубликовано 25 марта, 2016 · Жалоба а это не для защиты CPU? вот отрывок из приведённой ввыше ссылки: The filter process for fragmented IP packets can pose a challenge to security devices. This is because the Layer 4 information that is used in order to filter TCP and UDP packets is only present in the initial fragment. Cisco IOS software uses a specific method in order to check non-initial fragments against configured access lists. Cisco IOS software evaluates these non-initial fragments against the ACL and ignores any Layer 4 filtering information. This causes non-initial fragments to be evaluated solely on the Layer 3 portion of any configured ACE. In this example configuration, if a TCP packet destined to 192.168.1.1 on port 22 is fragmented in transit, the initial fragment is dropped as expected by the second ACE based on the Layer 4 information within the packet. However, all remaining (non-initial) fragments are allowed by the first ACE based completely on the Layer 3 information in the packet and ACE. This scenario is shown in this configuration: ! ip access-list extended ACL-FRAGMENT-EXAMPLE permit tcp any host 192.168.1.1 eq 80 deny tcp any host 192.168.1.1 eq 22 !> Due to the nonintuitive nature of fragment handling, IP fragments are often inadvertently permitted by ACLs. Fragmentation is also often used in attempts to evade detection by intrusion detection systems. It is for these reasons that IP fragments are often used in attacks, and why they must be explicitly filtered at the top of any configured iACLs. This example ACL includes comprehensive filtering of IP fragments. The functionality from this example must be used in conjunction with the functionality of the previous examples. ! ip access-list extended ACL-INFRASTRUCTURE-IN ! !--- Deny IP fragments using protocol-specific ACEs to aid in !--- classification of attack traffic ! deny tcp any any fragments deny udp any any fragments deny icmp any any fragments deny ip any any fragments ! !--- Deny all other IP traffic to any network device ! deny ip any <infrastructure-address-space> <mask> ! !--- Permit transit traffic ! permit ip any any ! Refer to Access Control Lists and IP Fragments for more information about how ACL handles fragmented IP packets. Если кратко, то так как Layer 4 информация находится только в initial fragment, то фильтры, основанные на TCP и UDP будут работать только на эти initial fragment. Например: ip access-list extended ACL-FRAGMENT-EXAMPLE permit tcp any host 192.168.1.1 eq 80 deny tcp any host 192.168.1.1 eq 22 таким акссесс листом будут дропаться только начальные фрагменты на основе Layer 4, все остальные будут пропускаться. Это с сайта циски. Хотя это по идее это должно больше относиться к udp, так как tcp сессия просто не поднимется. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
g3fox Опубликовано 25 марта, 2016 · Жалоба А вас точно udp frag долбят? Вы это как увидели? Сейчас очень доступно amplification. Нас именно им долбят пару раз в месяц по пол часа. До 10 Гбит/с лишнего трафика прилетает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SeroeKrevedko Опубликовано 28 марта, 2016 (изменено) · Жалоба А вас точно udp frag долбят? Вы это как увидели? Сейчас очень доступно amplification. Нас именно им долбят пару раз в месяц по пол часа. До 10 Гбит/с лишнего трафика прилетает. Львиная доля трафика это пакеты без Layer 4 информации. Хотя наверно Вы правы и это просто часть фрагментированного трафика от dns amplififcation. Вы как выходите из положения, блекхол? Изменено 28 марта, 2016 пользователем SeroeKrevedko Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Telesis Опубликовано 28 марта, 2016 (изменено) · Жалоба Все же наверно повторюсь, хорошо ли читали?? Introduction This document contains information to help you secure your Cisco IOS® system devices, which increases the overall security of your network. Structured around the three planes into which functions of a network device can be categorized, this document provides an overview of each included feature and references to related documentation. The three functional planes of a network - the management plane, control plane, and data plane - each provide different functionality that needs to be protected. Management Plane - The management plane manages traffic that is sent to the Cisco IOS device and is made up of applications and protocols such as Secure Shell (SSH) and Simple Network Management Protocol (SNMP). Control Plane - The control plane of a network device processes the traffic that is paramount to maintain the functionality of the network infrastructure. The control plane consists of applications and protocols between network devices, which includes the Border Gateway Protocol (BGP), as well as the Interior Gateway Protocols (IGPs) such as the Enhanced Interior Gateway Routing Protocol (EIGRP) and Open Shortest Path First (OSPF). Data Plane - The data plane forwards data through a network device. The data plane does not include traffic that is sent to the local Cisco IOS device. Поэтому вешать на клиента не годится. в начале каждой acl делать следующее: deny tcp any any fragments deny udp any any fragments deny icmp any any fragments deny ip any any fragments Изменено 28 марта, 2016 пользователем Telesis Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SeroeKrevedko Опубликовано 28 марта, 2016 · Жалоба Все же наверно повторюсь, хорошо ли читали?? Данные правила относятся именно к data plane Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Telesis Опубликовано 28 марта, 2016 · Жалоба Все же наверно повторюсь, хорошо ли читали?? Данные правила относятся именно к data plane Хотите сказать, используете то что выше? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SeroeKrevedko Опубликовано 28 марта, 2016 · Жалоба Хотите сказать, используете то что выше? я хотел узнать, использует ли кто-то такие конструкции и к чему это может провести. Вот циска утверждает что проблемы могут быть в редких случаях: "Under rare circumstances, a valid session might require fragmentation and therefore be filtered if a deny fragment statement exists in the ACL. Conditions that might lead to fragmentation include the use of digital certificates for ISAKMP authentication and the use of IPSec NAT Traversal." В моём понимании это может привести к проблемам при передаче больших файлов, но про это упоминаний нет. Спросить мне не у кого, поэтому я пошёл искать правду на форум. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
OKyHb Опубликовано 28 марта, 2016 · Жалоба Мы использовали ограничение fragmented UDP на Data plane - до 50Mbps (это на 10G линке от алинков). Вроде никто не жаловался. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
g3fox Опубликовано 28 марта, 2016 · Жалоба Львиная доля трафика это пакеты без Layer 4 информации. Хотя наверно Вы правы и это просто часть фрагментированного трафика от dns amplififcation. Вы как выходите из положения, блекхол? Когда успеваем среагировать - да, блэкхол. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...