Перейти к содержимому
Local
USD

как бороться с DoS на сеть провайдера?

Рекомендованные сообщения

активно досят мои ір 

тсп/удп

заяву в  кибер уже написал

кто как наблюдает/борется?

у меня софт бджп на никсе

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

blackhole? 

Магистралы не хотят помогать? 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В нульроут отправляйте у провадера черз комьюнити.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

магистрали просят ір конкретние, или ето не хотят помогать?

 

как диагностировать конкретние іп ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

flowspec в идеале, netflow, jflow или sampling на крайний случай

Изменено пользователем LV10

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
3 часа назад, LV10 сказал:

flowspec в идеале, netflow, jflow или sampling на крайний случай

 

спасибо 

 

пробую: https://forums.freebsd.org/threads/49724/

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
3 часа назад, USD сказал:

магистрали просят ір конкретние, или ето не хотят помогать?

 

как диагностировать конкретние іп ?

Так будет просто охренительно большой список ИПшек, и он тебе ничем не поможет. 

 

Кстати ты уверен, что это тебя ддосят, а не ты кого-то? :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
31 минуту назад, tkapluk сказал:

Так будет просто охренительно большой список ИПшек, и он тебе ничем не поможет. 

 

Кстати ты уверен, что это тебя ддосят, а не ты кого-то? :)

1. В блекхол кидают свои іп а не чужие

2. Абсолютно, походу конкуренти развлекаются.

И спасибо по существу мне ответили више.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

При синк-флуде рандомными ойпи помогает нулроут на адрес атакуемого.  Но не на долго :))))

 

Вот примеры для атак (нейротерорризма):

 

1. DoS Land

hping3 -V -c 13666 -d 120 -S -w 32 -p 0 -s 80 --flood --rand-source VICTIM_IP_ADDRESS

 

Вот это, пожалуй, самая жестяковая атака для пионернета. Если запустить в несколько потоков ( в конце команды & и так несколько копий команд), ляжет все где бутылочные горшлыки. Все, что софвтово обрабатывает пакеты умрет на широком канале вверх по трассе :). Источник атаки можно отследить по графикам "вниз". IP атакующего не виден.  А если с разных мест, и в договорняке... уууу... жесть. 

Как бороться с этой нечестью ? :) Пфф.. только сообща :)

 

2. Smurf DoS

 

hping3 -1 --flood -a VICTIM_IP BROADCAST_ADDRESS

Тут все просто. Сканим сетку жертвы (например Angry IP Scanner), вычисляем бродкасты и лупим по ним. К примеру сеть 192.168.1.0/24, бродкаст 192.168.1.255. Лупим по нему, а он, в свою очередь отвечает арп-ами. Если комбинировать эти атаки настойчиво, то атакуемый последние волосы на жопе вырвет от злости.

 

Есть еще куча всяких рецептов по взлому, ловли на живца и тд.

Что не ясно - спрашивайте. И давайте делится опытом.

Всем удачи :)

 

 

 

Изменено пользователем loki
  • Like 2

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
10 часов назад, loki сказал:

1. DoS Land

hping3 -V -c 13666 -d 120 -S -w 32 -p 0 -s 80 --flood --rand-source VICTIM_IP_ADDRESS

 

Вот это, пожалуй, самая жестяковая атака для пионернета. Если запустить в несколько потоков ( в конце команды & и так несколько копий команд), ляжет все где бутылочные горшлыки. Все, что софвтово обрабатывает пакеты умрет на широком канале вверх по трассе :). Источник атаки можно отследить по графикам "вниз". IP атакующего не виден.  А если с разных мест, и в договорняке... уууу... жесть. 

Как бороться с этой нечестью ? :) Пфф.. только сообща

Для этого многие ДЦ и провайдеры режут спуфинг. Нужно еще поискать, откуда можно провести атаку.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Обколются своей марихуаной, а потом я*** друг друга в с****!

ОБСТАВЯЦА СВАИМИ СУФТРУТЕРАМИ А ПАТОМ ПЫШУТЬ ДРУХ ДРУХУ ПАМАХИТЕ НА ФОРУМИ

НУЖНА СТАВИТЬ ЦИСКА АСР И БИГИПИ ФЛОУСПЕК С АПЛИНКАМИ БУДУВАТЬ!

 

:)

  • Haha 1

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Это если в двух слова, на самом деле защиты строятся посерьезней

Типы DDoS-атак
https://ddos-guard.net/ru/terminology
 
Защита от хакерских атак с помощью ipfw
https://www.opennet.ru/base/sec/ipfw_antihack.txt.html

На бордеры

# Запрет X-сканирования:
add 1001 reject log tcp from any to any tcpflags fin, syn, rst, psh, ack, urg
# Запрет N-сканирования:
add 1002 reject log tcp from any to any tcpflags !fin, !syn, !rst, !psh, !ack, !urg
# Запрет FIN-сканирования:
add 1003 reject log tcp from any to any not established tcpflags fin
# Защита от спуфинга
add 1004 deny log ip from any to any not verrevpath in

На сервисы

# Ограничение числа одновременных соединений:
add 1005 allow ip  from any to any  setup limit src-addr 10

  • Like 3

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

подскажите, а кто какое ставить ограничение на  число одновременных соединений: ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Если свой почтовик и конектятся клиентом, то нужно учитывать что клиент удерживает открытую сесию на каждый ящик, тут может и 20 быть и 100.

Для чужих 10 с головой.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
7 часов назад, masters сказал:

Для этого многие ДЦ и провайдеры режут спуфинг. Нужно еще поискать, откуда можно провести атаку.

И много таких провайдеров по Украине? Кто у себя настроил uRPF?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

маленький пример

Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:55619 from 109.93.80.142:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:22968 from 178.223.40.201:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:27886 from 85.27.176.147:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:55619 from 109.93.80.142:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:27886 from 85.27.176.147:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:22968 from 178.223.40.201:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:27886 from 85.27.176.147:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:55619 from 109.93.80.142:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:27886 from 85.27.176.147:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:27886 from 85.27.176.147:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:55619 from 109.93.80.142:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:55619 from 109.93.80.142:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:27886 from 85.27.176.147:53
Jan 26 20:40:32 XxXxX last message repeated 2 times
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:55619 from 109.93.80.142:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:27886 from 85.27.176.147:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:27886 from 85.27.176.147:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:55619 from 109.93.80.142:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:60344 from 87.97.71.125:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:55619 from 109.93.80.142:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:55619 from 109.93.80.142:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:16202 from 108.61.182.21:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:55619 from 109.93.80.142:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:55619 from 109.93.80.142:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:9986 from 46.219.23.67:53
Jan 26 20:40:32 XxXxX last message repeated 8 times
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:60344 from 87.97.71.125:53
Jan 26 20:40:32 XxXxX last message repeated 2 times
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:9986 from 46.219.23.67:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:60344 from 87.97.71.125:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:60344 from 87.97.71.125:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:9986 from 46.219.23.67:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:60344 from 87.97.71.125:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:9986 from 46.219.23.67:53
Jan 26 20:40:32 XxXxX last message repeated 2 times
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:2163 from 122.129.105.169:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:12860 from 91.90.72.181:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:12860 from 91.90.72.181:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:9986 from 46.219.23.67:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:12860 from 91.90.72.181:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:12860 from 91.90.72.181:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:9986 from 46.219.23.67:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:12860 from 91.90.72.181:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:12860 from 91.90.72.181:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:60344 from 87.97.71.125:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:60344 from 87.97.71.125:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:12860 from 91.90.72.181:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:12860 from 91.90.72.181:53

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну похоже на dns amplification attack.

А что такое XxXxX? Это один IP или разные или что?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
28 минут назад, USD сказал:

маленький пример

Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:55619 from 109.93.80.142:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:22968 from 178.223.40.201:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:27886 from 85.27.176.147:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:55619 from 109.93.80.142:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:27886 from 85.27.176.147:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:22968 from 178.223.40.201:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:27886 from 85.27.176.147:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:55619 from 109.93.80.142:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:27886 from 85.27.176.147:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:27886 from 85.27.176.147:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:55619 from 109.93.80.142:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:55619 from 109.93.80.142:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:27886 from 85.27.176.147:53
Jan 26 20:40:32 XxXxX last message repeated 2 times
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:55619 from 109.93.80.142:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:27886 from 85.27.176.147:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:27886 from 85.27.176.147:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:55619 from 109.93.80.142:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:60344 from 87.97.71.125:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:55619 from 109.93.80.142:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:55619 from 109.93.80.142:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:16202 from 108.61.182.21:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:55619 from 109.93.80.142:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:55619 from 109.93.80.142:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:9986 from 46.219.23.67:53
Jan 26 20:40:32 XxXxX last message repeated 8 times
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:60344 from 87.97.71.125:53
Jan 26 20:40:32 XxXxX last message repeated 2 times
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:9986 from 46.219.23.67:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:60344 from 87.97.71.125:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:60344 from 87.97.71.125:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:9986 from 46.219.23.67:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:60344 from 87.97.71.125:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:9986 from 46.219.23.67:53
Jan 26 20:40:32 XxXxX last message repeated 2 times
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:2163 from 122.129.105.169:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:12860 from 91.90.72.181:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:12860 from 91.90.72.181:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:9986 from 46.219.23.67:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:12860 from 91.90.72.181:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:12860 from 91.90.72.181:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:9986 from 46.219.23.67:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:12860 from 91.90.72.181:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:12860 from 91.90.72.181:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:60344 from 87.97.71.125:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:60344 from 87.97.71.125:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:12860 from 91.90.72.181:53
Jan 26 20:40:32 XxXxX kernel: Connection attempt to UDP XxXxX:12860 from 91.90.72.181:53

http://whiteglasses.livejournal.com/109620.html

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
1 час назад, ttttt сказал:

А что такое XxXxX? Это один IP или разные или что?

Название хоста и его айпи. 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
6 часов назад, pavlabor сказал:

Это если в двух слова, на самом деле защиты строятся посерьезней

Типы DDoS-атак
https://ddos-guard.net/ru/terminology
 
Защита от хакерских атак с помощью ipfw
https://www.opennet.ru/base/sec/ipfw_antihack.txt.html

На бордеры

# Запрет X-сканирования:
add 1001 reject log tcp from any to any tcpflags fin, syn, rst, psh, ack, urg
# Запрет N-сканирования:
add 1002 reject log tcp from any to any tcpflags !fin, !syn, !rst, !psh, !ack, !urg
# Запрет FIN-сканирования:
add 1003 reject log tcp from any to any not established tcpflags fin
# Защита от спуфинга
add 1004 deny log ip from any to any not verrevpath in

На сервисы

# Ограничение числа одновременных соединений:
add 1005 allow ip  from any to any  setup limit src-addr 10

 

 

До 3.14зды твоя теория ))).   Когда к тебе летит 1лям пакетов на 300 Мбитной ширине, то твой фаер сходит с ума  Спорим ? :)))) Твой копипастный пример с реальностью ничего общего не имеет. А на 10G полоске, нагенерить вообще такую кучу можно...

Изменено пользователем loki

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
2 часа назад, foreverok сказал:

И много таких провайдеров по Украине? Кто у себя настроил uRPF?

Те у кого руки и мозги с правильного места, и которые думают напред готовы отразить. Остальные 90% ляжут от любой детской шалости.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
31 минуту назад, ttttt сказал:

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

Чем меньше размер пакета и больше их ряд, тем хуже софтроутеру . Все ж можно руками задать. То просто пример.

Главное, найти открытый сокет от которого можно "просить" ответ :).  Поверь, больше 90% провайдеров уязвимы к примитивным и детским атакам. Все благодаря широким каналам и  теоретикам-админам.

Ааа магистралам вообще пох. Они не готовы раскошелиться на дорогие Л7 железки.

Назовите магистралов которые могут защитить ? :) И сколько это будет стоить.

 

 

Изменено пользователем loki

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
10 часов назад, masters сказал:

Для этого многие ДЦ и провайдеры режут спуфинг. Нужно еще поискать, откуда можно провести атаку.

Ой не смешите меня. Как эту режут ? Контролируют каждый открытый сокет на адресах  своих клиентов ? )))

Атаку произвести можно из кучи мест. В общем это. Пионервойны наступили, или не ))))?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
41 минуту назад, loki сказал:

Ой не смешите меня. Как эту режут ? Контролируют каждый открытый сокет на адресах  своих клиентов ? )))

Атаку произвести можно из кучи мест. В общем это. Пионервойны наступили, или не ))))?

Большинство нормальных магистралов не пропускают трафик от ип не анонсированные в райпе.

Этот простой прием режет 90% спуфинга.

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

Если ты внимательно прочитаешь то что я написал, то ты увидишь что это не мои рекомендации, приложены урлы где можно прочитать статьи полностью.

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

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас

  • Сейчас на странице   0 пользователей

    Нет пользователей, просматривающих эту страницу.

  • Похожие публикации

    • Автор: bot
      Тестирование Linux на DROP сетевых пакетов. Разные методы и их эффективность. Тесты синтетические, но от этого не становятся менее интересными. Пример от Cloudflare.
       
      Для иллюстрации производительности методов будут продемонстрированы некоторые цифры. Тесты синтетические, т.е. не на реальной сети с реальными пользователями и трафиком, так что не воспринимайте цифры слишком серьезно. Будет использоваться один из Intel серверов c 10Gbps сетевым интерфейсом. Детали железа не особо важны, т.к. тесты будут показывать вопросы, связанные с операционкой, а не с ограничениями по железу.
       
      Что происходит при тестировании:
      передача большого количества мелких UDP пакетов, достигая уровня в 14Mpps этот трафик направляется на единственный CPU на сервере измеряется количество пакетов, обработанных ядром на этом CPU  
      Мы не пытаемся максимизировать ни скорость приложения в юзерспейсе (userspace), ни количество пакетов. Вместо этого мы пытаемся показать узкие места самого ядра.
       
      Синтетический трафик пытается максимально нагрузить conntrack - используется рандомный IP адрес источника и порт. Tcpducmp будет выглядеть примерно следующим образом:
      $ 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 На другой стороне все пакеты будут направлены на одну очередь прерываний (RX), т.е. на один CPU. Делается это через ethtool:
      ethtool -N ext0 flow-type udp4 dst-ip 198.18.0.12 dst-port 1234 action 2  
      Оценочное тестирование всегда довольно сложное. Когда мы готовили тесты, мы обнаружили, что любые активные сырые сокеты (raw socket) сильно влияют на производительность. Это вполне очевидно, но легко не учесть. Перед тестами убедитесь, что у вас не запущен, к примеру, tcpdump.
      $ ss -A raw,packet_raw -l -p|cat Netid State Recv-Q Send-Q Local Address:Port p_raw UNCONN 525157 0 *:vlan100 users:(("tcpdump",pid=23683,fd=3))  
      В конце концов мы отключили Intel Turbo Boost:
      echo 1 | sudo tee /sys/devices/system/cpu/intel_pstate/no_turbo Это классная функция, и увеличивает производительность по крайней мере на 20%, но она также очень сильно влияет на разброс показаний при замерах. Со включенным бустом разброс достигал +-1.5%. С выключенным - 0.25%.
       

       

      1. Отброс/DROP пакетов в приложении

      Начинаем с доставки пакетов к приложению и отбрасывании их уже с помощью него. Чтобы убедиться, что файервол не влияет на это делаем так:
      iptables -I PREROUTING -t mangle -d 198.18.0.12 -p udp --dport 1234 -j ACCEPT iptables -I PREROUTING -t raw -d 198.18.0.12 -p udp --dport 1234 -j ACCEPT iptables -I INPUT -t filter -d 198.18.0.12 -p udp --dport 1234 -j ACCEPT Код приложения - обычный цикл, который получает данные и сразу же их отбрасывает (в юзерспейсе):
      s = socket.socket(AF_INET, SOCK_DGRAM) s.bind(("0.0.0.0", 1234)) while True: s.recvmmsg([...]) Код приложения: https://github.com/cloudflare/cloudflare-blog/blob/master/2018-07-dropping-packets/recvmmsg-loop.c
      $ ./dropping-packets/recvmmsg-loop packets=171261 bytes=1940176 Тут мы получаем жалкие 175kpps:
      $ mmwatch 'ethtool -S ext0|grep rx_2' rx2_packets: 174.0k/s Железо нам дает 14Mpps, но мы не можем обработать это ядром на одном CPU с одной очередью прерываний. mpstat это подтверждает:
      $ watch 'mpstat -u -I SUM -P ALL 1 1|egrep -v Aver' 01:32:05 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle 01:32:06 PM 0 0.00 0.00 0.00 2.94 0.00 3.92 0.00 0.00 0.00 93.14 01:32:06 PM 1 2.17 0.00 27.17 0.00 0.00 0.00 0.00 0.00 0.00 70.65 01:32:06 PM 2 0.00 0.00 0.00 0.00 0.00 100.00 0.00 0.00 0.00 0.00 01:32:06 PM 3 0.95 0.00 1.90 0.95 0.00 3.81 0.00 0.00 0.00 92.38 Как видите, код приложения не является узким местом, используя 27% системы + 2% юзерспейса на CPU #1, в то время как SOFTIRQ на CPU #2 сжирает 100% ресурсов.
      Кстати, использовать recvmmsg(2) довольно важно в наши пост-Спектровые дни (Spectre + Meltdown все же помнят?). Системные вызовы теперь требуют больше ресурсов. Мы используем ядро 4.14 с KPTI и retpolines:
      $ tail -n +1 /sys/devices/system/cpu/vulnerabilities/* ==> /sys/devices/system/cpu/vulnerabilities/meltdown <== Mitigation: PTI ==> /sys/devices/system/cpu/vulnerabilities/spectre_v1 <== Mitigation: __user pointer sanitization ==> /sys/devices/system/cpu/vulnerabilities/spectre_v2 <== Mitigation: Full generic retpoline, IBPB, IBRS_FW  
       
      2. Отключение conntrack

      Мы специально выбрали рандомные IP адреса и порты при тестировании для того чтобы нагрузить conntrack. Это можно проверить, посмотрев на заполненность conntrack таблицы:
      $ conntrack -C 2095202 $ sysctl net.netfilter.nf_conntrack_max net.netfilter.nf_conntrack_max = 2097152 И, конечно же, conntrack будет кричать в dmesg:
      [4029612.456673] nf_conntrack: nf_conntrack: table full, dropping packet [4029612.465787] nf_conntrack: nf_conntrack: table full, dropping packet [4029617.175957] net_ratelimit: 5731 callbacks suppressed Для ускорения наших тестов, давайте его отключим:
      iptables -t raw -I PREROUTING -d 198.18.0.12 -p udp -m udp --dport 1234 -j NOTRACK Запускаем тест:
      $ ./dropping-packets/recvmmsg-loop packets=331008 bytes=5296128 Теперь наше приложение получает 333kpps вместо 175kpps.
      P.S. с SO_BUSY_POLL можно добиться 470kpps, но об этом в другой раз.
       
       
      3. BPF дропание на сокете

      Далее мы подумали - зачем этот трафик вообще нужен на юзерспейсе? Мы можем с помощью setsockopt(SO_ATTACH_FILTER) присоединить классический BPF фильтр к SOCK_DGRAM сокету и отбрасывать пакеты на уровне ядра (kernel space).
      Код: https://github.com/cloudflare/cloudflare-blog/blob/master/2018-07-dropping-packets/bpf-drop.c
       
      Тест:
      $ ./bpf-drop packets=0 bytes=0 С таким подходом (у классического BPF схожая производительность с eBPF) у нас получилось 512kpps. При этом экономится CPU, т.к. не нужно дергать приложение в юзерспейсе.
       

      4. DROP с помощью iptables после роутинга

      В качестве следующего теста мы решили отбрасывать пакеты в цепочке INPUT в iptables:
      iptables -I INPUT -d 198.18.0.12 -p udp --dport 1234 -j DROP Conntrack отключен в предыдущем правиле. Эти два правила в файерволе дали нам 608kpps.
      $ mmwatch 'iptables -L -v -n -x | head' Chain INPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 605.9k/s 26.7m/s DROP udp -- * * 0.0.0.0/0 198.18.0.12 udp dpt:1234  

      5. DROP с помощью iptables в таблице PREROUTING

      Т.е. отбрасываем пакеты пока они не попали в роутинг:
      iptables -I PREROUTING -t raw -d 198.18.0.12 -p udp --dport 1234 -j DROP Получаем 1.688mpps
      Довольно существенный прирост при использовании таблички "raw".
      Не совсем понятно почему такой прирост, возможно потому, что у нас сложный роутинг или баг в настройке сервера.
       

      6. DROP с помощью nftables перед conntrack

      Т.к. iptables доживает свои дни, то теперь можно пользоваться nftables.
      Видео, объясняющее почему nftrack лучше: https://www.youtube.com/watch?v=9Zr8XqdET1c
      nft add table netdev filter nft -- add chain netdev filter input { type filter hook ingress device vlan100 priority -500 \; policy accept \; } nft add rule netdev filter input ip daddr 198.18.0.0/24 udp dport 1234 counter drop nft add rule netdev filter input ip6 daddr fd00::/64 udp dport 1234 counter drop Счетчики можно пронаблюдать так:
      $ mmwatch 'nft --handle list chain netdev filter input' table netdev filter { chain input { type filter hook ingress device vlan100 priority -500; policy accept; ip daddr 198.18.0.0/24 udp dport 1234 counter packets 1.6m/s bytes 69.6m/s drop # handle 2 ip6 daddr fd00::/64 udp dport 1234 counter packets 0 bytes 0 drop # handle 3 } } Получили 1.53mpps. Это немного медленнее iptables, хотя должно быть наоборот. В любом случае nftables рулит.
       

      7. Отбрасывание пакетов в tc ingress

      Неожиданным фактом стало то, что tc (traffic control) ingress обрабатывается перед PREROUTING. Т.е. можно управлять трафиком еще раньше.
      Синтаксис довольно неудобный, поэтому рекомендуется использовать скрипт: https://github.com/netoptimizer/network-testing/blob/master/bin/tc_ingress_drop.sh
      tc qdisc add dev vlan100 ingress tc filter add dev vlan100 parent ffff: prio 4 protocol ip u32 match ip protocol 17 0xff match ip dport 1234 0xffff match ip dst 198.18.0.0/24 flowid 1:1 action drop tc filter add dev vlan100 parent ffff: protocol ipv6 u32 match ip6 dport 1234 0xffff match ip6 dst fd00::/64 flowid 1:1 action drop проверяем:
      $ mmwatch 'tc -s filter show dev vlan100 ingress' filter parent ffff: protocol ip pref 4 u32 filter parent ffff: protocol ip pref 4 u32 fh 800: ht divisor 1 filter parent ffff: protocol ip pref 4 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:1 (rule hit 1.8m/s success 1.8m/s) match 00110000/00ff0000 at 8 (success 1.8m/s ) match 000004d2/0000ffff at 20 (success 1.8m/s ) match c612000c/ffffffff at 16 (success 1.8m/s ) action order 1: gact action drop random type none pass val 0 index 1 ref 1 bind 1 installed 1.0/s sec Action statistics: Sent 79.7m/s bytes 1.8m/s pkt (dropped 1.8m/s, overlimits 0 requeues 0) backlog 0b 0p requeues 0 Получили 1.8mppps на одном CPU.
       

      8. XDP_DROP

      https://prototype-kernel.readthedocs.io/en/latest/networking/XDP/
      С помощью XDP - eXpress Data Path мы можем запустить eBPF код прямо в сетевом драйвере. Т.е. перед тем как skbuff выделяет память.
       
      Обычно в XDP две части:
      eBPF код, загруженный в ядро юзерспейсный загрузчик, который загружает код в нужную сетевую карту и управляет им  
      Написание загрузчика довольно трудное занятие, поэтому мы решили воспользоваться новой iproute2 фичей:
      ip link set dev ext0 xdp obj xdp-drop-ebpf.o https://cilium.readthedocs.io/en/latest/bpf/#iproute2
      Исходник программы: https://github.com/cloudflare/cloudflare-blog/blob/master/2018-07-dropping-packets/xdp-drop-ebpf.c
      Программа парсит IP пакеты и ищет заданные параметры: IP транспорт, UDP протокол, сеть, порт:
      if (h_proto == htons(ETH_P_IP)) { if (iph->protocol == IPPROTO_UDP && (htonl(iph->daddr) & 0xFFFFFF00) == 0xC6120000 // 198.18.0.0/24 && udph->dest == htons(1234)) { return XDP_DROP; } } XDP программа должна быть скомпилена с современным clang, который умеет делать BPF байткод. После этого загружаем и проверяем XDP программу:
      $ ip link show dev ext0 4: ext0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 xdp qdisc fq state UP mode DEFAULT group default qlen 1000 link/ether 24:8a:07:8a:59:8e brd ff:ff:ff:ff:ff:ff prog/xdp id 5 tag aedc195cc0471f51 jited И смотрим цифры в статистике интерфейса (ethtool -S)
      $ mmwatch 'ethtool -S ext0|egrep "rx"|egrep -v ": 0"|egrep -v "cache|csum"' rx_out_of_buffer: 4.4m/s rx_xdp_drop: 10.1m/s rx2_xdp_drop: 10.1m/s Итого получаем 10Mpps на одном CPU.
       

       

       
      Источник: cloudflare
    • Автор: bot
      Крупнейшие web-ресурсы России и Европы подверглись высокоскоростным DDoS-атакам

      Скорость атак достигала нескольких сотен гигабит в секунду.

      Исследователи безопасности из компании Qrator Labs зафиксировали серию высокоскоростных DDoS-атак на ряд крупнейших web-ресурсов России и Европы.

      Как следует из пресс-релиза компании, с 23 по 27 февраля 2018 года по всей Европе прокатилась волна высокоскоростных DDoS-атак, с использованием техники амплификации на основе memcache (программное обеспечение, реализующее сервис кэширования данных в оперативной памяти на основе хеш-таблицы). Особенностью данной техники является отправка множества поддельных UDP-пакетов в единицу времени от широкого диапазона IP-адресов.

      По словам исследователей, уязвимости в memcache существуют по меньшей мере с 2014 года, однако их наиболее активная эксплуатация пришлась на 2018 год. В частности, в ночь с 25 на 26 февраля эксперты зафиксировали серию memcache амплифицированных DDoS-атак на множество ресурсов по всему интернету, включая несколько крупнейших сетевых ресурсов России. В числе атакованных указана платежная система QIWI, подтвердившая факт успешно нейтрализованной атаки полосой 480 Гбит/сек UDP трафика по своим ресурсам от скомпрометированных memcache амплификаторов.

      Как выяснили специалисты, источниками атак были несколько интернет-провайдеров и хостеров, в том числе крупный провайдер OVH.

      «Современные техники осуществления DDoS-атак не стоят на месте. Все чаще мы фиксируем появление новых «брешей» в инфраструктуре интернета, которыми с успехом пользуются злоумышленники для реализации нападений. Атаки с использованием memcache, скорость которых достигала нескольких сотен Гб/с, стали тому подтверждением. Уязвимых memcache ресурсов в интернете огромное количество, и мы настоятельно рекомендуем техническим специалистам производить корректную настройку memcache, не забывая об установках по умолчанию. Это поможет избежать прослушивания всего UDP-трафика, отправляемого на сервер, и снизить вероятность проведения DDoS-атак», - отметил генеральный директор Qrator Labs Александр Лямин.
       
      Источник: securitylab
    • Автор: bot
      Крупнейшние провайдеры Украины получили интересное уведомление об атаке на их сети, если они откажутся платить
      Кто-то, кто называет себя Armada Collective, разослал письма крупнейшим провайдерам Украины с требованием заплатить им 10 BTC до определенной даты.

      В случае неполучения средств до этой даты, Armada Collective угрожает произвести атаку на оборудование компании. И сервисы компаний будут недоступны вплоть до оплаты. Но каждый день сумма оплаты будет повышаться на 10 BTC.

      "Наши атаки очень мощные - иногда более 1Tbps. И мы обходим Cloudflare и другие сервисы защиты. Поэтому, никакая дешевая защита не поможет. Предотвратите это, заплатив всего-лишь 10 BTC на указанный кошелек. Не отвечайте, мы не прочтем. Заплатите и мы узнаем, что это вы. И ВЫ НИКОГДА О НАС БОЛЬШЕ НЕ УСЛЫШИТЕ! Биткоин анонимен, никто не узнает, что вы сотрудничали." © Armada Collective
       



      Источник: local
    • Автор: ikuferu
      Компания "Бест" 3 год ·   
      15 та 16 січня 2017 року на мережу Компанії Бест було здійснено ряд хакерських DDOS атак, через що було порушено працездатність мережі і тимчасово виведено з ладу маршрутизуюче обладнання ядра мережі. Користувачі відчували погіршення якості Інтернет сервісу у період з 22 до 24 години, була відсутня маршрутизація з частиною мережі Інтернет (здебільшого світовий сегмент), сумарний час погіршення сервісу склав близько 4 годин, атаки здійснювалися у час найбільшого навантаження на мережу у неділю та понеділок.
       
       
       
    • Автор: S-D
      Здравствуйте.
       
      На продажу есть 3шт Juniper Netscreen 5200.
      Сетевой экран отлично зарекомендовавший себя для предотвращения всевозможных типов DDoS/DoS атак, фильтрации сетевых аномалий а также хороший IDP.
       
      NS-5200-CHA NS-5000-M 5000-8G 500$   NS-5200-CHA NS-5000-MGT3 NS-5000-8G2-G4-TX (8x SFP-T J45 в комплекте) 1500$   NS-5200-CHA NS-5000-MGT3 (новый в упаковке) NS-5000-8G2-G4 (новый в упаковке) 1500$
×