Jump to content
Калькуляторы

Cisco vs-s720-10g-3cxl + rspan

Решили заняться мониторингом - почему и какой трафик идет на обработку в процессор. Особенно во время ддос атак на наших клиентов

 

во время атак

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, а не ушли на сервер, до которого железка знает маршрут.

Share this post


Link to post
Share on other sites

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 - пакеты не идут на процессор

Edited by artful

Share this post


Link to post
Share on other sites

убираю эту строчку из ACL - пакеты не идут на процессор

а 185.97.254.35 это хто? сама циска или очередной хост?

нетфлоу на аплинке включен?

а no ip unreach на аплинке есть?

Share this post


Link to post
Share on other sites

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 не должен добавлять трафика в процессор

Share this post


Link to post
Share on other sites

и анричибл, и flow ingress

но помойму добавление строчки в acl не должен добавлять трафика в процессор

 

скорее всего наличие no ip unreachables не влияет на логику punted packets, только на отправку ICMP.

 

посмотрите значение mls rate-limit unicast ip icmp unreachable acl-drop, при желании выставить его в 0, после чего проверить в тех же условиях

Share this post


Link to post
Share on other sites

данный параметр влияет на 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

Share this post


Link to post
Share on other sites

данный параметр влияет на 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

Share this post


Link to post
Share on other sites

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)

Share this post


Link to post
Share on other sites

У меня вот это было под ддосом, когда арп протухал:

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.

Share this post


Link to post
Share on other sites

это не 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 сети и везде есть маки.

Share this post


Link to post
Share on other sites

какой софт и суп?

под рукой нет консоли, но по cef можно глянуть какие заголовки(ethtype,dstmac, srcmac) подготовлены для данного nexthop, show adj xxxx detail или что-то подобное, покажите вывод

Share this post


Link to post
Share on other sites

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 иосе всего хватает.

Share this post


Link to post
Share on other sites

Join the conversation

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

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.