artplanet Posted January 6, 2017 Решили посмотреть что такое 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 пакетов - он их скидывает на коллектор и дальше новая запись. Но это мысли в слух Кто что может рассказать - почему как то не понятно всё суммируется ? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
s.lobanov Posted January 6, 2017 Так это же и есть суть сэмплирования. Смотрится не каждый пакет, а каждый N-ый пакет, в вашем случае каждый 4096ой, т.е. одиночный пинг не попадёт в потоки *flow с большой долей вероятности Вообще, в современных реалиях, netflow имеет смысл снимать с stateful фаерволов/nat-ов, потому что там всё равно хранится информация о потоках трафика, а все эти сэмплированные netflow со свитчей, ну хз, разве что в контексте каких-нибудь ntp dos атак интересны Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
artplanet Posted January 6, 2017 (edited) понятно - но тут у нас интерес в том - что в последнее время наши клиенты стали ддосить наших же клиентов. То есть берут виртуалку и с нее просто флудят на соседний сервер в стойке - так как защиту со внешнего мира пробить не могут. поэтому и смотрим в сторону того - что может хоть как то снять статистику для анализа. в принципе такой вариант в полне подойдет для анализа ддосеров. Edited January 6, 2017 by artplanet Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Дегтярев Илья Posted January 7, 2017 Ну так засовывайте разных клиентов в разные VLAN и межклиентский трафик тоже через DDoS фильтры пропускайте. Статистически между разными клиентами трафика быть много не должно, т.к. для обоих нахожение в одной стойке должно быть случайностью. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
artplanet Posted January 7, 2017 (edited) Ну так засовывайте разных клиентов в разные VLAN и межклиентский трафик тоже через DDoS фильтры пропускайте. Статистически между разными клиентами трафика быть много не должно, т.к. для обоих нахожение в одной стойке должно быть случайностью. Такое делать - себя не уважать. Столько подводных камней будет. А трафик между клиентами у нас большой - до 1Gb/s доходит. Проще сразу заблочить клиента - через 5-10 минут как он начал фигней страдать. заблокировать ему услугу. А деньги которые он потратил на аренду такой услуги перекинуть жертве. Edited January 7, 2017 by artplanet Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
s.lobanov Posted January 7, 2017 Такое делать - себя не уважать. Столько подводных камней будет. Да ладно, все нормальные операторы так делают (не дают L2-видимости между клиентами) и отлично оно работает Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
andryas Posted January 7, 2017 В чём проблема пустить всё через шеститонник, включив на нём local-proxy-arp + private-vlan и сегментировав сеть на свитчах "доступа" ? Локального трафика, я так понимаю, там мизер. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
artplanet Posted January 9, 2017 Да ладно, все нормальные операторы так делают (не дают L2-видимости между клиентами) и отлично оно работает у нас тоже нету - везде стоит ip unnamered - и на каждый дедик свой int vlan. все сервера терминируются прямо на cisco l3 которая стоит в стойке. Сейчас это Cisco 3560E/3750E. ткамов хватает за глаза. а локальный трафик не маленький - до 1Gb/s доходит. Поэтому самый простой вариант - через 5-10 минут после того как один клиент начал ддосить второго нашего клиента - просто блокировать услугу тому - кто ддосит. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...