[artplanet]

Решили посмотреть что такое sflow и немного удивились.

В тестовый nexus подключили один сервер и начали с него пинговать гугол и паралельно с внешнего ресурса стали пинговать наш сервер. Пинги постоянные - 1 пакет в секунду запрос - 1 ответ

И разумеется стали смотреть что прилетает в коллектор и были немного удивлены.

sflow sampling-rate : 4096
sflow max-sampled-size : 128
sflow counter-poll-interval : 10
sflow max-datagram-size : 1400
sflow data-source interface Ethernet1/2

 

и в отчетах за 30 минут видим:

nfdump -R nfcapd.201701061418 'proto icmp'
Date first seen          Duration Proto      Src IP Addr:Port          Dst IP Addr:Port   Packets    Bytes Flows
2017-01-06 14:20:41.486     0.000 ICMP      TEST_SERV_IP:8     ->          8.8.8.8:0.0       5120   522240     1
2017-01-06 14:22:21.195     0.000 ICMP     EXTER_SERV_IP:8     ->     TEST_SERV_IP:0.0       5120   399360     1
2017-01-06 14:38:08.158     0.000 ICMP      TEST_SERV_IP:0     ->    EXTER_SERV_IP:0.0       4096   319488     1
2017-01-06 14:49:48.170     0.000 ICMP      TEST_SERV_IP:8     ->          8.8.8.8:0.0       4096   434176     1
2017-01-06 14:55:39.054     0.000 ICMP           8.8.8.8:0     ->     TEST_SERV_IP:0.0       4096   417792     1
2017-01-06 15:01:56.296     0.000 ICMP     EXTER_SERV_IP:8     ->     TEST_SERV_IP:0.0       4096   335872     1
2017-01-06 15:03:29.127     0.000 ICMP           8.8.8.8:0     ->     TEST_SERV_IP:0.0       4096   417792     1
2017-01-06 15:13:53.477     0.000 ICMP           8.8.8.8:0     ->     TEST_SERV_IP:0.0       4096   417792     1
2017-01-06 15:19:56.047     0.000 ICMP      TEST_SERV_IP:8     ->          8.8.8.8:0.0       4096   417792     1

 

первые две записи имеют 5120 пакетов - так как вначале у нас стояло - sflow sampling-rate : 5120

 

Походу nexus группирует данные в 4096 пакетов и отправляет их на коллектор

стали тестировать дальше - и запустили тестовую ддос атаку на свой же хост и что же мы увидели:

Date first seen          Duration Proto      Src IP Addr:Port      Dst IP Addr:Port    Packets  Bytes    Flows
2017-01-06 14:29:41.505     0.000 TCP      209.88.182.10:17462 ->  185.97.255.55:80      4096   262144     1
2017-01-06 14:29:41.505     0.000 TCP     13.156.104.145:17684 ->  185.97.255.55:80      4096   262144     1
2017-01-06 14:29:41.505     0.000 TCP     173.223.72.193:26286 ->  185.97.255.55:80      4096   262144     1
2017-01-06 14:29:41.505     0.000 TCP     153.154.200.81:27963 ->  185.97.255.55:80      4096   262144     1
2017-01-06 14:29:41.505     0.000 TCP     49.120.126.127:29246 ->  185.97.255.55:80      4096   262144     1
2017-01-06 14:29:41.505     0.000 TCP      209.25.10.153:31499 ->  185.97.255.55:80      4096   262144     1
2017-01-06 14:29:41.505     0.000 TCP      156.37.160.85:39942 ->  185.97.255.55:80      4096   262144     1

 

но во время атаки не могло быть физически 4096 пакетов с одного и того же src ip:src port - там был полный рендом.

Пока что подозрение что sflow смотрит на какой dst ip:dst port идет пакет с какого физического порта и дальше все пакеты которые совпадают с этим условием начинают суммироваться. Набирается 4096 пакетов - он их скидывает на коллектор и дальше новая запись.

Но это мысли в слух

 

Кто что может рассказать - почему как то не понятно всё суммируется ?

[s.lobanov]

Так это же и есть суть сэмплирования. Смотрится не каждый пакет, а каждый N-ый пакет, в вашем случае каждый 4096ой, т.е. одиночный пинг не попадёт в потоки *flow с большой долей вероятности

 

Вообще, в современных реалиях, netflow имеет смысл снимать с stateful фаерволов/nat-ов, потому что там всё равно хранится информация о потоках трафика, а все эти сэмплированные netflow со свитчей, ну хз, разве что в контексте каких-нибудь ntp dos атак интересны

[artplanet]

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

поэтому и смотрим в сторону того - что может хоть как то снять статистику для анализа.

в принципе такой вариант в полне подойдет для анализа ддосеров.

Edited January 6, 2017 by artplanet

[Дегтярев Илья]

Ну так засовывайте разных клиентов в разные VLAN и межклиентский трафик тоже через DDoS фильтры пропускайте.

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

[artplanet]

Ну так засовывайте разных клиентов в разные VLAN и межклиентский трафик тоже через DDoS фильтры пропускайте.

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

 

Такое делать - себя не уважать. Столько подводных камней будет. А трафик между клиентами у нас большой - до 1Gb/s доходит.

Проще сразу заблочить клиента - через 5-10 минут как он начал фигней страдать. заблокировать ему услугу. А деньги которые он потратил на аренду такой услуги перекинуть жертве.

Edited January 7, 2017 by artplanet

[s.lobanov]

Такое делать - себя не уважать. Столько подводных камней будет.

 

Да ладно, все нормальные операторы так делают (не дают L2-видимости между клиентами) и отлично оно работает

[andryas]

В чём проблема пустить всё через шеститонник, включив на нём local-proxy-arp + private-vlan и сегментировав сеть на свитчах "доступа" ?

Локального трафика, я так понимаю, там мизер.

[artplanet]

Да ладно, все нормальные операторы так делают (не дают L2-видимости между клиентами) и отлично оно работает

 

 

у нас тоже нету - везде стоит ip unnamered - и на каждый дедик свой int vlan. все сервера терминируются прямо на cisco l3 которая стоит в стойке. Сейчас это Cisco 3560E/3750E. ткамов хватает за глаза.

а локальный трафик не маленький - до 1Gb/s доходит.

Поэтому самый простой вариант - через 5-10 минут после того как один клиент начал ддосить второго нашего клиента - просто блокировать услугу тому - кто ддосит.