artful Опубликовано 2 марта, 2016 · Жалоба Решили заняться мониторингом - почему и какой трафик идет на обработку в процессор. Особенно во время ддос атак на наших клиентов во время атак show ibc brief Interface information: Interface IBC0/0(idb 0x487C4588) Hardware is Mistral IBC (revision 5) 5 minute rx rate 667000 bits/sec, 1234 packets/sec 5 minute tx rate 46000 bits/sec, 24 packets/sec Сделали rspan всего трафика который идет на обработку процессора. monitor session 1 type local-tx source cpu rp tx destination interface Gi3/3 ! и сразу возник вопрос, почему некоторый ICMP трафик направляется в процессор, например под атакой был наш сервер с Ip 185.97.254.23, тип атаки был ntp flood tcpdump с порта Gi3/3 показал следующее: 12:50:59.146840 IP 159.93.65.186 > 185.97.254.23: ICMP 159.93.65.186 udp port 123 unreachable, length 36 12:50:59.150211 IP 82.85.191.202 > 185.97.254.23: ICMP 82.85.191.202 udp port 123 unreachable, length 36 12:50:59.156708 IP 64.201.244.139 > 185.97.254.23: ICMP 64.201.244.139 udp port 123 unreachable, length 36 12:50:59.159458 IP 82.85.191.202 > 185.97.254.23: ICMP 82.85.191.202 udp port 123 unreachable, length 36 12:50:59.166828 IP 103.23.168.9 > 185.97.254.23: ICMP 103.23.168.9 udp port 123 unreachable, length 36 12:50:59.170201 IP 83.149.210.250 > 185.97.254.23: ICMP 83.149.210.250 udp port 123 unreachable, length 44 12:50:59.179070 IP 115.134.96.120 > 185.97.254.23: ICMP 115.134.96.120 udp port 123 unreachable, length 44 при этом железка знает маршрут до данного ip: show ip route 185.97.254.23 Routing entry for 185.97.254.23/32 Known via "ospf 600", distance 110, metric 20, type extern 2, forward metric 1 Redistributing via ospf 603 Advertised by ospf 603 subnets то что 32 маска не обращайте внимание Так что тут вопрос, почему эти icmp пакеты пошли на обработку в cisco, а не ушли на сервер, до которого железка знает маршрут. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rdntw Опубликовано 2 марта, 2016 · Жалоба ip redirect\unreacheble\proxy arp Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
artful Опубликовано 2 марта, 2016 · Жалоба на всех int vlan прописано no ip redirects no ip unreachables no ip proxy-arp Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DejaVu Опубликовано 2 марта, 2016 · Жалоба А в CEF маршрут есть? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
artful Опубликовано 3 марта, 2016 (изменено) · Жалоба show ip cef 185.97.254.23 185.97.254.23/32 nexthop 80.87.207.109 Vlan601 конечно есть кстати, заметил одну особенность. Сейчас например с Ip 193.124.181.252 прилетает около 100.000 пакетов в секунду флуда. Чтобы не нагружать защиту - повесил ACL на аплинк: 7 deny ip host 193.124.181.252 any 9999 permit ip any any и после этого на процессор стали приходить пакеты: 03:19:12.676624 IP 193.124.181.252.65341 > 185.97.254.35.28015: UDP, length 32 03:19:12.691990 IP 193.124.181.252.65295 > 185.97.254.35.28015: UDP, length 32 03:19:12.696862 IP 193.124.181.252.65301 > 185.97.254.35.28015: UDP, length 32 03:19:12.706607 IP 193.124.181.252.50132 > 185.97.254.35.28015: UDP, length 32 03:19:12.716726 IP 193.124.181.252.65307 > 185.97.254.35.28015: UDP, length 32 03:19:12.726721 IP 193.124.181.252.50132 > 185.97.254.35.28015: UDP, length 32 03:19:12.736715 IP 193.124.181.252.50132 > 185.97.254.35.28015: UDP, length 32 03:19:12.746710 IP 193.124.181.252.65307 > 185.97.254.35.28015: UDP, length 32 03:19:12.756704 IP 193.124.181.252.50132 > 185.97.254.35.28015: UDP, length 32 03:19:12.766701 IP 193.124.181.252.65307 > 185.97.254.35.28015: UDP, length 32 03:19:12.776818 IP 193.124.181.252.65307 > 185.97.254.35.28015: UDP, length 32 03:19:12.786812 IP 193.124.181.252.65295 > 185.97.254.35.28015: UDP, length 32 03:19:12.796807 IP 193.124.181.252.65295 > 185.97.254.35.28015: UDP, length 32 03:19:12.806801 IP 193.124.181.252.62055 > 185.97.254.35.28015: UDP, length 32 03:19:12.816921 IP 193.124.181.252.62055 > 185.97.254.35.28015: UDP, length 32 03:19:12.826915 IP 193.124.181.252.62055 > 185.97.254.35.28015: UDP, length 32 03:19:12.836909 IP 193.124.181.252.62055 > 185.97.254.35.28015: UDP, length 32 03:19:12.846905 IP 193.124.181.252.65295 > 185.97.254.35.28015: UDP, length 32 03:19:12.856899 IP 193.124.181.252.65295 > 185.97.254.35.28015: UDP, length 32 03:19:12.866895 IP 193.124.181.252.65331 > 185.97.254.35.28015: UDP, length 32 03:19:12.877013 IP 193.124.181.252.65331 > 185.97.254.35.28015: UDP, length 32 03:19:12.887008 IP 193.124.181.252.51915 > 185.97.254.35.28015: UDP, length 32 убираю эту строчку из ACL - пакеты не идут на процессор Изменено 3 марта, 2016 пользователем artful Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mikezzzz Опубликовано 3 марта, 2016 · Жалоба убираю эту строчку из ACL - пакеты не идут на процессор а 185.97.254.35 это хто? сама циска или очередной хост? нетфлоу на аплинке включен? а no ip unreach на аплинке есть? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
artful Опубликовано 3 марта, 2016 · Жалоба 185.97.254.35 - это очередной хост, cisco знает до него маршрут. Он так же есть и в таблице маршрутизации и в cef на всех аплинках стоит конфиг ip access-group uplink in no ip redirects no ip unreachables no ip proxy-arp ip flow ingress ip route-cache policy и анричибл, и flow ingress но помойму добавление строчки в acl не должен добавлять трафика в процессор Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mikezzzz Опубликовано 4 марта, 2016 · Жалоба и анричибл, и flow ingress но помойму добавление строчки в acl не должен добавлять трафика в процессор скорее всего наличие no ip unreachables не влияет на логику punted packets, только на отправку ICMP. посмотрите значение mls rate-limit unicast ip icmp unreachable acl-drop, при желании выставить его в 0, после чего проверить в тех же условиях Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
artful Опубликовано 4 марта, 2016 · Жалоба данный параметр влияет на icmp, а у меня на процессор уходят UDP пакеты 03:19:12.866895 IP 193.124.181.252.65331 > 185.97.254.35.28015: UDP, length 32 03:19:12.877013 IP 193.124.181.252.65331 > 185.97.254.35.28015: UDP, length 32 03:19:12.887008 IP 193.124.181.252.51915 > 185.97.254.35.28015: UDP, length 32 при условии что в ACL была добавлена строчка 7 deny ip host 193.124.181.252 any Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Smoke Опубликовано 4 марта, 2016 · Жалоба ACL Numbered или Named ? - помню что Cisco для обработки ACL на PFC просили использовать Named ACL Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mikezzzz Опубликовано 4 марта, 2016 · Жалоба данный параметр влияет на icmp, а у меня на процессор уходят UDP пакеты да? ну буду знать теперь ICMP Unreachable (Unicast Only) In an ICMP unreachable attack, a device is flooded with a large number of packets that contain a destination address that is unreachable from the flooded device (in this case, the RP). The ICMP unreachable rate limiter allows you to rate limit the packets that are sent to the RP containing unreachable addresses. This example shows how to rate limit the packets that are sent to the RP because of an ACL drop to 10000 pps and a burst of 100: Router(config)# mls rate-limit unicast ip icmp unreachable acl-drop 10000 100 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
uxcr Опубликовано 4 марта, 2016 (изменено) · Жалоба mls cef glean тоже неплохо включить rate-limit Изменено 4 марта, 2016 пользователем uxcr Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
artful Опубликовано 4 марта, 2016 · Жалоба ACL Numbered или Named ? - помню что Cisco для обработки ACL на PFC просили использовать Named ACL show ip access-lists uplink Господа, вопрос изначально не в том - как ограничить трафик на процессор, а почему он вообще идет на процессор из ACL. Ведь суть ACL - дропнуть пакеты. Или может там трафик передается на процессор для счетчиков по которым пишется сколько было дропов при команде show ip access-list 7 deny ip host 193.124.181.252 any (1017489 matches) вот для (1017489 matches) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 4 марта, 2016 · Жалоба может там остаётся ttl=1 и поэтому трафик уходит на cpu, чтоб ответить Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
uxcr Опубликовано 4 марта, 2016 · Жалоба У меня вот это было под ддосом, когда арп протухал: The FIB glean rate limiter does not limit ARP traffic, but provides the capability to rate limit traffic that requires address resolution (ARP) and requires that it be sent to the MSFC. This situation occurs when traffic enters a port and contains the destination of a host on a subnet that is locally connected to the MSFC, but no ARP entry exists for that destination host. In this case, because the MAC address of the destination host will not be answered by any host on the directly connected subnet that is unknown, the “glean” adjacency is hit and the traffic is sent directly to the MSFC for ARP resolution. This rate limiter limits the possibility of an attacker overloading the CPU with such ARP requests. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
artful Опубликовано 5 марта, 2016 · Жалоба это не TTL 01:11:08.201760 IP (tos 0x0, ttl 118, id 7782, offset 0, flags [none], proto UDP (17), length 147) 31.180.140.18.0 > 185.97.254.96.20480: truncated-udplength 0 01:11:08.410769 IP (tos 0x0, ttl 119, id 2248, offset 0, flags [none], proto UDP (17), length 148) 85.174.75.186.0 > 185.97.254.76.20480: truncated-udplength 0 01:11:08.521208 IP (tos 0x0, ttl 118, id 7838, offset 0, flags [none], proto UDP (17), length 39) 31.180.140.18.0 > 185.97.254.96.20480: truncated-udplength 0 01:11:08.577428 IP (tos 0x0, ttl 119, id 2272, offset 0, flags [none], proto UDP (17), length 39) 85.174.75.186.0 > 185.97.254.76.20480: truncated-udplength 0 01:11:08.741336 IP (tos 0x0, ttl 118, id 1126, offset 0, flags [none], proto UDP (17), length 39) 85.173.214.110.0 > 185.97.254.19.20480: truncated-udplength 0 01:11:08.869015 IP (tos 0x0, ttl 119, id 2307, offset 0, flags [none], proto UDP (17), length 39) 85.174.75.186.0 > 185.97.254.76.20480: truncated-udplength 0 01:11:09.127624 IP (tos 0x0, ttl 117, id 9333, offset 0, flags [none], proto UDP (17), length 146) 85.174.99.198.0 > 185.97.254.73.20480: truncated-udplength 0 01:11:09.462688 IP (tos 0x0, ttl 55, id 31184, offset 0, flags [none], proto UDP (17), length 42) 85.174.75.186.0 > 185.97.254.76.20480: truncated-udplength 0 это опять чутка снифа с трафика который на процессор был отправлен. arp тоже не причем. На бордере не терминирую сети клиентов - там только /31 сети и везде есть маки. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rdntw Опубликовано 6 марта, 2016 · Жалоба какой софт и суп? под рукой нет консоли, но по cef можно глянуть какие заголовки(ethtype,dstmac, srcmac) подготовлены для данного nexthop, show adj xxxx detail или что-то подобное, покажите вывод Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
artful Опубликовано 7 марта, 2016 · Жалоба VO.bb#show ip route 185.97.254.96 Routing entry for 185.97.254.96/32 Known via "ospf 600", distance 110, metric 20, type extern 2, forward metric 1 Redistributing via ospf 603 Advertised by ospf 603 subnets Last update from 80.87.207.109 on Vlan601, 1d11h ago Routing Descriptor Blocks: * 80.87.207.109, from 80.87.207.109, 1d11h ago, via Vlan601 Route metric is 20, traffic share count is 1 VO.bb#show adjacency 185.97.254.96 detail Protocol Interface Address VO.bb# софт s72033-adventerprisek9_wan-mz.122-33.SXJ10.bin 15 ios стоял раньше - отказались в пользу 12 из за того что памяти на 3 BGP Full view и 1 сессию ipv6 не хватает на IOS 15. а на 12 еще 182 мегабайт свободно. Точнее памяти хватало - но свободно было 20мегабайт. И новые телнет сессити не создавались. С конфигом 1 в 1 на 12 иосе всего хватает. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
