Комментарии 29
Такое чувство, что уже видел эту статью, именно в переводе, а так же возмущение по поводу nft, что он "всё равно круче"
Хм...
Интересу ради, а PF_RING не пробовали? В режиме Zero-Copy он вроде умеет обрабатывать 10 Gbit/s на ядро. Ну и 100 Gbit/s карточки умеет и BPF-like фильтр на них.
А почему про такой вариант не упомянули?
Есть вариант ещё эффективнее — просто выдернуть кабель :)
Это значит DDOS атака сработала, пусть и таким неожиданным способом))
А вот до этого «выбрасывать всё подряд» — это типа не сработала?
Тут описана не атака, при которой нагружается целевое приложение (типа тяжелых POST-запросов к выдаче статистики за 100 лет) — от такой атаки cloudflare не особо поможет, только выдача токенов на стороне приложения и rate limiting.
Атакующий в сценарии статьи просто забивает канал целевого сервера кучей мелких запросов, полностью съедая ресурсы сервера на обработку («это нам? это не нам, выбросить») этих ненужных пакетов. В таком случае cloudflare сможет на своих мощных серверах отбросить большую часть мусорного трафика, пропустив только полезные пакеты, чем они и занимаются. Разница между сервером cloudflare и вашим сервером в ширине канала и доступной вычислительной мощности.
Атакующий в сценарии статьи просто забивает канал целевого сервера кучей мелких запросов, полностью съедая ресурсы сервера на обработку («это нам? это не нам, выбросить») этих ненужных пакетов. В таком случае cloudflare сможет на своих мощных серверах отбросить большую часть мусорного трафика, пропустив только полезные пакеты, чем они и занимаются. Разница между сервером cloudflare и вашим сервером в ширине канала и доступной вычислительной мощности.
Насколько я знаю у cloudfare есть защита для случаев с атакой на уровень приложения. Хотя конечно от непродуманной архитектуры приложения это не поможет. Но у меня в свою очередь есть другой вопрос. В каких случаях udp трафик можно полностью выбросить. Ведь насколько я понимаю, я не эксперт в этой области, защита на уровне iptables работает с счётчиками по ip адресам, а в udp адрес легко подделывается. То есть насколько можно убрать весь udp трафик без ущерба для работы сервера и приложения?
Если приложение не ожидает UDP, то можно смело выбрасывать его целиком. Но атакующий тогда может перейти на SYN-флуд по известному порту приложения, и т.к. у TCP адрес отправителя подделывается также легко, как и у UDP (хоть и установить подключение не удастся), общий принцип защиты останется прежним. Тут еще не показано, но скорее всего, Cloudflare может видеть номер AS, от которой пришли пакеты, что добавляет информации для фильтров.
А можете подробнее рассказать про подмену IP-адресов?
Мне всегда казалось, что в Интернете подменить свой IP-адрес не так-то просто, потому что если использовать IP, принадлежащий другой автономной системе, то внешний BGP-маршрутизатор просто отбросит такой пакет как некорректный.
Конечно, в сети наверняка есть системы, где такая фильтрация не настроена — но я всё же надеюсь, что их не так много (особенно среди магистральных провайдеров). Или я неправ?
Мне всегда казалось, что в Интернете подменить свой IP-адрес не так-то просто, потому что если использовать IP, принадлежащий другой автономной системе, то внешний BGP-маршрутизатор просто отбросит такой пакет как некорректный.
Конечно, в сети наверняка есть системы, где такая фильтрация не настроена — но я всё же надеюсь, что их не так много (особенно среди магистральных провайдеров). Или я неправ?
Возможно, я не понял мысли mwizard, но советую познакомиться с атаками на усиление (amplification), в которых как раз айпишник подменяется.
А, тогда да. Я почему-то подумал именно про чистый IP spoofing. Спасибо!
Я имел в виду чистый IP spoofing, т.к. в посте рассматривалась фильтрация конкретно кучи мусорных UDP, и предложение apapacy по выбрасыванию UDP в принципе, без сравнения адреса отправителя.
Найти умножитель это хорошо, но в случае с TCP невозможно (т.к. не получится закончить 3-way handshake, т.к. SYN ACK придет не на тот адрес). Если же уязвимые сервисы отвечают по UDP (как обычно и происходит), но для целевого узла на cloudflare настроено «выбрасывать весь UDP не глядя», то атака захлебнется даже без выяснения всех уязвимых подсетей.
Найти умножитель это хорошо, но в случае с TCP невозможно (т.к. не получится закончить 3-way handshake, т.к. SYN ACK придет не на тот адрес). Если же уязвимые сервисы отвечают по UDP (как обычно и происходит), но для целевого узла на cloudflare настроено «выбрасывать весь UDP не глядя», то атака захлебнется даже без выяснения всех уязвимых подсетей.
К сожалению, мне особо нечего рассказать конкретно про BGP, т.к. на таком уровне никогда не приходилось работать, и знания мои по данной теме исключительно теоретические. Впрочем, если вы правы, и пограничные роутеры выбрасывают исходящие пакеты с некорректными адресами отправителя, то было бы логично предположить, что любые IP-пакеты с некорректными адресами отправителя будут выброшены, независимо от того, что используется поверх — UDP, TCP или любой другой протокол. Если же атакующий знает, через какую AS идут наружу его пакеты, он может безнаказанно представляться любым адресом из анонсируемых этой AS префиксов.
Автоматически граничный маршрутизатор пакеты с поддельными адресами резать не будет, только если соответствующим фильтром не озаботился администратор. Не знаю, как сейчас, но в середине 2000-х ни РТКомм, ни ТТК таких фильтров на наших точках подключения не держали. Фильтровали только префиксы BGP, получаемые от клиента (то есть пакет с поддельным адресом отправить вовне получится, а вот прикинуться этим адресом для других, чтобы получать ответные пакеты — нет). Не думаю, что сейчас ситуация заметно изменилась: объёмы трафика выросли значительно, и никто просто так загружать магистральное оборудование фильтрами не будет. Другое дело — точки подключения конечных клиентов к провайдерам: там вероятность словить фильтр намного выше.
Все же водящие udp нужны для получения информации с DNS сервера.
Я при случае добавлю себе такие строки
Тем более что сегодня пыталсяы кто-то забить канал пакетами. Я током не успе разобраться какими. Возможно как раз upd т.к. посе атак на 7-й уровень это наиболее дешевый способ атак с учетом имеющихся мультиплиакторов запросов. (Это собственно сами DNS сервра используемые злоумышленниками и окрытый порт какой-то хипстерской базы данных не вспомню какой точно)
Я при случае добавлю себе такие строки
/sbin/iptables -A INPUT -p udp -m limit --limit 1/s --limit-burst 1000 --dport 53 -j ACCEPT
/sbin/iptables -A INPUT -p udp -m udp --dport 0:32767 -j DROP
Тем более что сегодня пыталсяы кто-то забить канал пакетами. Я током не успе разобраться какими. Возможно как раз upd т.к. посе атак на 7-й уровень это наиболее дешевый способ атак с учетом имеющихся мультиплиакторов запросов. (Это собственно сами DNS сервра используемые злоумышленниками и окрытый порт какой-то хипстерской базы данных не вспомню какой точно)
Остальные характеристики сервера не так важны, потому что мы хотим акцентировать внимание на ограничениях системы, а не железа.
Как мне кажется, в переводе пропущено значащее слово (см. подчеркнутое слово в приведенном ниже отрывке).
The hardware details aren't too important, since the tests are prepared to show the operating system, not hardware, limitations.
Возможно, я что-то не так понял?
Здравствуйте. Я не сильно в этом разбираюсь, поэтому спрашиваю из любопытства: получается что вы отбиваете пакеты с одного адреса, я правильно понял? А что будет если будет много хаотично меняющихся адресов?
Правильно ли я понимаю, что от ДДОС атак нет спасенья? То есть в любом случае канал будет забит пакетами.
Правильно ли я понимаю, что от ДДОС атак нет спасенья? То есть в любом случае канал будет забит пакетами.
В первую очередь отмечу, что это не авторская статья, а только перевод.
Но ответить на ваш вопрос я всё же могу. В самом начале статьи, где рассказывается про генерацию трафика так же приведён небольшой пример:
То есть у пакетов можно найти общий критерий: отправитель из подсети 198.18.0.0/16, протокол UDP и маленький размер пакета (вот тут 16 байт).
Так что нет, отбиваются пакеты с диапазона адресов, и только определённые пакеты.
Если спасение от DDoS-атак — зависит от силы атаки.
Но ответить на ваш вопрос я всё же могу. В самом начале статьи, где рассказывается про генерацию трафика так же приведён небольшой пример:
$ tcpdump -ni vlan100 -c 10 -t udp and dst port 1234
IP 198.18.40.55.32059 > 198.18.0.12.1234: UDP, length 16
IP 198.18.51.16.30852 > 198.18.0.12.1234: UDP, length 16
IP 198.18.35.51.61823 > 198.18.0.12.1234: UDP, length 16
IP 198.18.44.42.30344 > 198.18.0.12.1234: UDP, length 16
IP 198.18.106.227.38592 > 198.18.0.12.1234: UDP, length 16
IP 198.18.48.67.19533 > 198.18.0.12.1234: UDP, length 16
IP 198.18.49.38.40566 > 198.18.0.12.1234: UDP, length 16
IP 198.18.50.73.22989 > 198.18.0.12.1234: UDP, length 16
IP 198.18.43.204.37895 > 198.18.0.12.1234: UDP, length 16
IP 198.18.104.128.1543 > 198.18.0.12.1234: UDP, length 16
То есть у пакетов можно найти общий критерий: отправитель из подсети 198.18.0.0/16, протокол UDP и маленький размер пакета (вот тут 16 байт).
Так что нет, отбиваются пакеты с диапазона адресов, и только определённые пакеты.
Если спасение от DDoS-атак — зависит от силы атаки.
KPTI против Meltdown, оно не защитит от Spectre.
— A ты знаешь что значит 1488?
— Ха, конечно! 14.88 Mpps это максимальный пакетрейт через 10G интерфейс!
Если использовать DPDK, то можно получить гораздо большую производительность, потому что не нужно будет протаскивать данные из сети через ядро. Довольно легко утилизировать всю пропускную способность 10G мелкими пакетами, а на более старших сетевушках выходит более 20 Mpps на ядро.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Как отбрасывать 10 миллионов пакетов в секунду