artplanet Опубликовано 17 ноября, 2016 (изменено) · Жалоба Недавно прилетела ддос атака в 14-15Mpps syn флуда. Прилетела атака с двух провайдеров которые заведены на один бордер vs-s720-3c. на входе в 6500 собран портчанел из портов Te3/8 и 4/8 - обе платы - WS-X6708-10G-3CXL так же в шасси стоит плата WS-X6704-10G-3CXL во втором модуле. Схема как были нагружены порты во время атаки: http://owncloud.su/index.php/s/rn8iMRgMe1w2dde Вот график с одного из портов по mpps: http://owncloud.su/index.php/s/is5Sq2yUPe4JUN6 http://owncloud.su/index.php/s/WySvrOVdK5LPio0 То есть все пакеты долетели до порта и их посчитали счетчики на 6500 Далее - на обоих портах стали появлятся дропы пакетов: Input queue: 0/2000/316937210/0 (size/max/drops/flushes); Total output drops: 0 Input queue: 0/2000/315218095/0 (size/max/drops/flushes); Total output drops: 0 во время атаки фабрика выдала макс нагрузку 47% 3 0 20G 4% 47% @21:07 15Nov16 2% 22% @21:07 15Nov16 3 1 20G 2% 7% @20:21 15Nov16 1% 8% @06:00 15Nov16 4 0 20G 3% 47% @21:07 15Nov16 3% 22% @21:07 15Nov16 4 1 20G 1% 8% @17:08 13Nov16 1% 8% @17:59 15Nov16 При этом наблюдались потери пакетов которые прилетали в порт Te3/8 и улетали в порт Te3/5 - а так как стоит плата DFC - то пакеты не покидали модуль. А так же были потери пакетов из порта Te3/8 в порт Te3/1. Аналогично на 4ом модуле. Настройка портов: description Nexus switchport switchport trunk encapsulation dot1q switchport trunk allowed vlan 8,28,101,102,208-210,1069 switchport mode trunk load-interval 30 channel-group 1 mode active теперь настройка двух int vlan с который прилетела атака: interface Vlan209 ip address 87.x.y.z 255.255.255.254 ip access-group uplink in no ip redirects no ip unreachables no ip proxy-arp ip flow ingress ip route-cache policy ip policy route-map PBR-PROTECT load-interval 30 end и interface Vlan102 ip address 62.x.y.z 255.255.255.254 ip access-group uplink in no ip redirects no ip unreachables no ip proxy-arp ip flow ingress ip route-cache policy ip policy route-map PBR-PROTECT load-interval 30 end ip access-group uplink in - тут просто acl вида - deny ip 10.10.0.0 0.0.255.255 any ip policy route-map PBR-PROTECT - тут PBR роутинг на входящие пакеты - чтобы делить атаку на 4ре параллельные железки по фильтрации атаки немного слов о PBR show route-map PBR-PROTECT route-map PBR-PROTECT, deny, sequence 2 Match clauses: ip address (access-lists): NO-PBR Set clauses: Policy routing matches: 0 packets, 0 bytes route-map PBR-PROTECT, permit, sequence 100 Match clauses: ip address (access-lists): ADDOS-00 Set clauses: ip next-hop x.y.z.247 Policy routing matches: 7743855 packets, 2182511306 bytes route-map PBR-PROTECT, permit, sequence 101 Match clauses: ip address (access-lists): ADDOS-01 Set clauses: ip next-hop x.y.x.245 Policy routing matches: 5918721 packets, 1439344022 bytes первое правило говорит о том - что мы не обрабатываем пакеты на те ip которые мы не защищаем. 120 permit ip x.y.z.0 0.0.3.255 any - такого плана ACL NO-PBR но при этом при трассировке до хоста из этого блока Ip адресов были потери 8. m9-bb-po5.corbina.net 0.0% 7 2.7 4.1 2.6 12.3 3.6 9. filanco.corbina.net 0.0% 7 2.8 2.5 2.4 2.8 0.0 10. ??? 11. prov.spb.cloud-ix.net 14.3% 7 10.0 89.9 10.0 157.5 75.0 12. main.prov.ru 28.6% 7 10.1 73.1 10.1 157.6 77.5 11 - это Cisco где были дропы пакетов по графикам во время атаки нагрузка на процессор выросла на 3-4% в итоге хочется понять откуда дропы пакетов. netflow? oversubscription на модулях не может быть виноват - трафик в одной группе портов был не выше 5Gb/s Изменено 17 ноября, 2016 пользователем artplanet Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dignity Опубликовано 18 ноября, 2016 · Жалоба Я в прошлый раз уже хотел написать "что вы трупик насилуете", но не стал... Ну что вы трупик насилуете-то? Cisco 6500 - интеллектуальный коммутатор с кучей ограничений. Это не адская пакетная фабрика. Такие штуки делают force10, extreme networks, brocade. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
artplanet Опубликовано 18 ноября, 2016 (изменено) · Жалоба Я в прошлый раз уже хотел написать "что вы трупик насилуете", но не стал... Ну что вы трупик насилуете-то? Cisco 6500 - интеллектуальный коммутатор с кучей ограничений. Это не адская пакетная фабрика. Такие штуки делают force10, extreme networks, brocade. А можно по делу? Без оффтопа. К тому же Ваши железки не держат FullView. Изменено 18 ноября, 2016 пользователем artplanet Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dmvy Опубликовано 18 ноября, 2016 · Жалоба По опыту Catalyst 3550/3750 крайне не рекомендуется в PBR использовать Deny. Удалите первое правило. К тому же оно ничего не матчит, а только занимает время при обработке. У нас для FV стоит 2 Juniper MX80 (раньше вообще 1 был) и 2 Extreme X670. По две штуки только ради резерва. Атаки до 15Гбит не замечаем. Дальше уже шейпер начинает деградировать из-за неоптимальной балансировки по очередям карточек intel x520. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dignity Опубликовано 18 ноября, 2016 · Жалоба А можно по делу? Без оффтопа. К тому же Ваши железки не держат FullView. Full-view много что успешно держит, если что. Brocade MLX, MLXe, XMR, к примеру. А как многократно тут обсуждалось, FV, часто вообще нафиг не нужен... Как вариант, можно Вашу Cisco просто воткнуть в какую-нибудь VRRP-like топологию, в которой Вы будете делать failover в случае атак на модель без FV. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mikezzzz Опубликовано 18 ноября, 2016 · Жалоба Далее - на обоих портах стали появлятся дропы пакетов: Input queue: 0/2000/316937210/0 (size/max/drops/flushes); Total output drops: 0 Input queue: 0/2000/315218095/0 (size/max/drops/flushes); Total output drops: 0 а на SVI 209 и 102 счетчики не росли? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
artplanet Опубликовано 18 ноября, 2016 · Жалоба По опыту Catalyst 3550/3750 крайне не рекомендуется в PBR использовать Deny. Удалите первое правило. К тому же оно ничего не матчит, а только занимает время при обработке. У нас для FV стоит 2 Juniper MX80 (раньше вообще 1 был) и 2 Extreme X670. По две штуки только ради резерва. Атаки до 15Гбит не замечаем. Дальше уже шейпер начинает деградировать из-за неоптимальной балансировки по очередям карточек intel x520. но у нас то не 3550/3750 - а 6500 с процом vs-s720-3cxl. Но в новой схеме мы будем выносить PBR на Cisco Nexus 3064-X (железка куплена и едет, но приедет через месяц). То есть 3064-X будет подключаться к двум бордерам и анонсировать ту сеть что мы защищаем. И уже на 3064-X будет PBR. Но до этой схемы нам еще месяц жить минимум. А до этого хочется решить проблему на том оборудовании что есть. К тому же на 6500 по документациям PBR работает с максимальной скоростью. По поводу первого правила DENY - мы думали добавить в него те сети что не нужно защищать для того - чтобы внутри ACL с защитой не указывать те блоки что мы защищаем. к примеру сейчас получается следующие ACL show ip access-lists NO-PBR 100 permit ip 10.10.10.0 0.0.0.255 any (при трафике с этих IP не нужно учитывать PBR) - это служебная сеть в которой у нас коммутаторы. А на входе с аплинков стоит ACL который блокирует входящие пакеты с наших ip 110 permit ip any 90.0.0.0 0.0.3.255 тут идет блок который мы не хотим защищать А теперь внутри ACL с защитой show ip access-lists ADDOS-00 10 permit ip 0.0.0.0 255.255.255.252 0.0.0.0 0.0.0.0 show ip access-lists ADDOS-01 10 permit ip 0.0.0.1 255.255.255.252 0.0.0.0 0.0.0.0 show ip access-lists ADDOS-02 10 permit ip 0.0.0.2 255.255.255.252 0.0.0.0 0.0.0.0 show ip access-lists ADDOS-03 10 permit ip 0.0.0.3 255.255.255.252 0.0.0.0 0.0.0.0 в итоге чтобы убрать первый DENY PBR придется переделать все ACL с защитой: show ip access-lists ADDOS-00 5 deny ip 10.10.10.0 0.0.0.255 any 7 deny ip any 90.0.0.0 0.0.3.255 10 permit ip 0.0.0.0 255.255.255.252 0.0.0.0 0.0.0.0 show ip access-lists ADDOS-01 5 deny ip 10.10.10.0 0.0.0.255 any 7 deny ip any 90.0.0.0 0.0.3.255 10 permit ip 0.0.0.1 255.255.255.252 0.0.0.0 0.0.0.0 show ip access-lists ADDOS-02 5 deny ip 10.10.10.0 0.0.0.255 any 7 deny ip any 90.0.0.0 0.0.3.255 10 permit ip 0.0.0.2 255.255.255.252 0.0.0.0 0.0.0.0 show ip access-lists ADDOS-03 5 deny ip 10.10.10.0 0.0.0.255 any 7 deny ip any 90.0.0.0 0.0.3.255 10 permit ip 0.0.0.3 255.255.255.252 0.0.0.0 0.0.0.0 либо на вариант show ip access-lists ADDOS-00 5 deny ip 10.10.10.0 0.0.0.255 any 10 permit ip 0.0.0.0 255.255.255.252 150.0.0.0 0.0.1.255 show ip access-lists ADDOS-01 5 deny ip 10.10.10.0 0.0.0.255 any 10 permit ip 0.0.0.1 255.255.255.252 150.0.0.0 0.0.1.255 show ip access-lists ADDOS-02 5 deny ip 10.10.10.0 0.0.0.255 any 10 permit ip 0.0.0.2 255.255.255.252 150.0.0.0 0.0.1.255 show ip access-lists ADDOS-03 5 deny ip 10.10.10.0 0.0.0.255 any 10 permit ip 0.0.0.3 255.255.255.252 150.0.0.0 0.0.1.255 в практике блоков ipv4 без защиты намного больше. И acl будет намного больше. К тому же при установке 8 железок по защите - то придется делать больше ACL изначально у нас была схема без DENY в PBR - но в один прекрасный момент циска ругнулась что не хватает TCAM для программирования - так как сложный ACL Nov 5 22:51:18.227: %FM-2-ACL_MERGE_NUM_ACES: ACL merge aborted due to number of ACEs threshold for features on interface Vlan505 in ingress direction, traffic may be switched in software Nov 5 22:51:23.527: %FM-2-ACL_MERGE_NUM_ACES: ACL merge aborted due to number of ACEs threshold for features on interface Vlan3634 in ingress direction, traffic may be switched in software хотя превышений не было и памяти свободной было уйма. и TCAM был свободный show platform hardware capacity acl ACL/QoS TCAM Resources Key: ACLent - ACL TCAM entries, ACLmsk - ACL TCAM masks, AND - ANDOR, QoSent - QoS TCAM entries, QOSmsk - QoS TCAM masks, OR - ORAND, Lbl-in - ingress label, Lbl-eg - egress label, LOUsrc - LOU source, LOUdst - LOU destination, ADJ - ACL adjacency Module ACLent ACLmsk QoSent QoSmsk Lbl-in Lbl-eg LOUsrc LOUdst AND OR ADJ 1 1% 5% 1% 1% 1% 1% 0% 0% 0% 0% 1% 2 1% 4% 1% 1% 1% 1% 0% 0% 0% 0% 1% 3 1% 5% 1% 1% 1% 1% 0% 0% 0% 0% 1% 4 1% 5% 1% 1% 1% 1% 0% 0% 0% 0% 1% а на SVI 209 и 102 счетчики не росли? не проверил если честно - но потери были и на том трафике что прилетал через другие SVI в тех же физических портах. Но на всех этих SVI был ip flow ingress и PBR Roiting с теми же правилами. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mikezzzz Опубликовано 18 ноября, 2016 · Жалоба а CoPP есть? графики строите наверняка Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
artplanet Опубликовано 18 ноября, 2016 · Жалоба CoPP только через кактус - но ошибки на порту не снимали. только unicast packet Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mikezzzz Опубликовано 18 ноября, 2016 · Жалоба CoPP только через кактус - но ошибки на порту не снимали. только unicast packet не совсем понял Вас, на 6500 настроена Control Plane Policy? графиков по полисерам для неё не строите? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
artplanet Опубликовано 18 ноября, 2016 (изменено) · Жалоба на 6500 настроена Control Plane Policy значит я Вас не понял. Нет не стоит - не строим. Сейчас погуглим что это и попробуем поднять (config)#control-plane (config-cp)#? Control Plane configuration commands: exit Exit from control-plane configuration mode no Negate or set default values of a command service-policy Configure QOS Service Policy (config-cp)#service-policy input PBR-PROTECT Policy PBR-PROTECT does not exist error: failed to install policy map PBR-PROTECT у нас же не шейпер - а просто PBR Изменено 18 ноября, 2016 пользователем artplanet Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mikezzzz Опубликовано 18 ноября, 2016 · Жалоба на 6500 настроена Control Plane Policy значит я Вас не понял. Нет не стоит - не строим. Сейчас погуглим что это и попробуем поднять (config)#control-plane (config-cp)#? Control Plane configuration commands: exit Exit from control-plane configuration mode no Negate or set default values of a command service-policy Configure QOS Service Policy (config-cp)#service-policy input PBR-PROTECT Policy PBR-PROTECT does not exist error: failed to install policy map PBR-PROTECT у нас же не шейпер - а просто PBR я понял, просто думал может у вас настроена CoPP и какой-то трафик уходил на CPU, где и подыхал, но раз CoPP нет и роста CPU в момент DDoS не было - видимо не оно Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
artplanet Опубликовано 18 ноября, 2016 · Жалоба но раз CoPP нет и роста CPU в момент DDoS не было - видимо не оно в том то и дело - все что было на порту - это PBR И netflow а, еще есть monitor session 3 source vlan 2 - 3 , 28 , 102 , 208 - 210 , 603 rx monitor session 3 destination interface Te1/4 но трафик отправлялся в порт процессора. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mikezzzz Опубликовано 18 ноября, 2016 · Жалоба monitor session 3 source vlan 2 - 3 , 28 , 102 , 208 - 210 , 603 rx monitor session 3 destination interface Te1/4 прикольно, а тут чего? show monitor | b Egress show platform hardware capacity rewrite-engine drop show fabric errors show fabric drop Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
artplanet Опубликовано 18 ноября, 2016 · Жалоба show monitor | b Egress show platform hardware capacity rewrite-engine drop show fabric errors show fabric drop show monitor | b Egress Egress SPAN Replication State: Operational mode : Centralized Configured mode : Centralized (default) #show platform hardware capacity rewrite-engine drop slot channel packet drops total overruns ----+-------+--------------------+--------------+ 1 0 0 0 1 1 0 0 2 0 0 0 2 1 0 0 3 0 0 0 3 1 0 0 4 0 0 0 4 1 0 0 #show fabric errors Module errors: slot channel crc hbeat sync DDR sync 1 0 0 0 0 0 1 1 0 0 0 0 2 0 0 0 0 0 2 1 0 0 0 0 3 0 0 0 0 0 3 1 0 0 0 0 4 0 0 0 0 0 4 1 0 0 0 0 Fabric errors: slot channel sync buffer timeout 1 0 0 0 0 1 1 0 0 0 2 0 0 0 0 2 1 0 0 0 3 0 0 0 0 3 1 0 0 0 4 0 0 0 0 4 1 0 0 0 #show fabric drop Polling interval for drop counters and timestamp is 15 in seconds Packets dropped by fabric for different queues: slot channel Low-Q-drops High-Q-drops 1 0 19 @11:52 11Oct16 0 1 1 2 @11:52 11Oct16 0 2 0 0 0 2 1 0 0 3 0 0 0 3 1 0 0 4 0 21 @11:52 11Oct16 0 4 1 21 @11:52 11Oct16 0 правда после полного дебага проблемы 15 ноября (на сколько хватило у нас знаний) были выполнены команды clear fabric peak-utilization clear mls statistics clear counters Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
applx Опубликовано 18 ноября, 2016 (изменено) · Жалоба а сколько по вашему нужно PPS чтоб переполнить буфер порта в 200MB и начать дропать? какой был средний размер пакета SYN атаки? Изменено 18 ноября, 2016 пользователем applx Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
artplanet Опубликовано 18 ноября, 2016 · Жалоба один пакет - 40 байт. И при чем тут буфер - ведь в полку не упирались Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
artplanet Опубликовано 18 ноября, 2016 · Жалоба все же мне думается что виноват именно netflow во время атаки прилетело 16Mpps - у всех пакетов был random sorce ip и random source port. А теперь представьте что за секунду netflow должен генерировать 16 миллионов уникальных записей каждую секунду Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rover-lt Опубликовано 18 ноября, 2016 (изменено) · Жалоба один пакет - 40 байт. И при чем тут буфер - ведь в полку не упирались в полку не упирались по усредненным за 5 минут графикам. А что было на секундном, миллисекундном уровне? Изменено 18 ноября, 2016 пользователем rover-lt Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
artplanet Опубликовано 18 ноября, 2016 · Жалоба в полку не упирались по усредненным за 5 минут графикам. А что было на секундном, миллисекундном уровне? у нас графики ежеминутные. Атака была минуты 3. по графикам не упирались. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
applx Опубликовано 18 ноября, 2016 · Жалоба причем тут истощения буфера и полка? сколько по вашему надо трафика чтоб забить 200МБ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
artplanet Опубликовано 18 ноября, 2016 · Жалоба а по какой причине мог закончиться буфер? прилетело 8mpps на порт - на порту шейперов и ничего нету что бы требовало обработку пакетов. значит пакет сразу ушел в обработку. к тому же в счетчики пакетов трафик попадал - так как графики кактуса всё вывели. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
artplanet Опубликовано 18 ноября, 2016 · Жалоба Кстати - раз пакет посчитался процессором - значит пакет ушел в обработку и уже не находиться в буфере. Ведь проблема видна - прилетело по графику 16mpps - а на защиту ушло всего 10mpps - а раз пакеты считались - то они из буферов ушли в модули на обработку. Если бы был виноват буфер - то тогда бы плата не знала о его существовании и не посчитала бы его. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
applx Опубликовано 18 ноября, 2016 · Жалоба ваших 200МБ хватит на 200мс буфера при траффике в 10Гбпс от этого и посчитайте как быстро буфера просядут от DDos атаки (по ППС).обычно input / output drops на интерфейсе об этом говорят Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
artplanet Опубликовано 18 ноября, 2016 · Жалоба еще раз - буфер тут не причем. сделали некий тест - отправили тестовую атаку сами на себя. итого - в тот же модуль только в другой порт прилетело 9Mpps (без портчанелов - просто в физический порт) http://owncloud.su/index.php/s/UFzEQlyE9di3Mfl ни одного дропа - весь трафик нормально ушел на железки по защите и был отфильтрован. Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0 30 second input rate 5121262000 bits/sec, 9125122 packets/sec 30 second output rate 235600000 bits/sec, 86061 packets/sec фабрика почти так же была загружена. 3 0 20G 4% 18% @23:49 17Nov16 3% 24% @21:36 18Nov16 3 1 20G 2% 39% @21:40 18Nov16 2% 7% @21:39 18Nov16 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...