Перейти к содержимому
Калькуляторы

sflow - и вся магия с ним

Решили посмотреть что такое 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 пакетов - он их скидывает на коллектор и дальше новая запись.

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

 

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

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


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

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

 

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

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


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

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

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

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

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

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


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

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

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

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


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

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

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

 

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

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

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

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


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

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

 

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

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


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

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

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

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


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

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

 

 

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

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

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

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


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

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.