пятница, 14 февраля 2020 г.

Троблешутинг Cisco ASA

При очередном обновлении Cisco ASA возникла неприятная ситуация, когда трафик почему-то пошел не в свои интерфейсы, на которые были статические маршруты, естественно возник асимметричный трафик  и он стал отбрасываться. Изначально переход был с релиза 8.4(1) на 9.0(3) и затем на 9.8(4)-15. при переходе с 8.4(1)  конфигурация была автоматически адаптирована промежуточным релизом 9.0(3) и на нем работала предсказуемо. При обновлении secondary ноды c 9.0(3) до 9.8(4)-15 проблем не было, и когда роль активной передали на secondary ноду, тоже всё работало нормально штатно, но когда обновили master ноду c 9.0(3) до 9.8(4)-15 и сделали активной, то трафик перестал ходить согласно таблицы маршрутизации, что привело к тому, что почти весь трафик стал дропаться. Выглядит это примерно так:



дело оказалось, что в каком-то релизе между 9.0(3) и 9.8(4)-15  Cisco поменяла логику определения выходного интерфейса при использовании  NAT и правило вида "nat(any, outside)...." стало отправлять трафик на OUTSIDE интерфейс, не зависимо от таблицы маршрутизации, т.е. route-lookup для NAT раньше был по умолчанию для правил NAT (хотя его можно было и указать явно в конфигурации). При указании этой опции на 9.8(4)-15 трафик пошел согласно таблицы статической маршрутизации.
Для отладки Cisco ASA можно использовать следующие команды:

создадим буфер для захвата трафика между определёнными IP:

cap capin trace interface management match ip host 10.0.19.49 host 10.129.190.3

cap capout trace interface DMZ-18 match ip host 10.129.190.3 host 10.0.19.49

cap asp type asp-drop all

Смотрим капчи:
ciscoasa/admin# show cap
capture capin type raw-data interface management [Capturing - 2250 bytes]
  match icmp host 10.0.19.49 host 10.129.190.3
capture capout type raw-data interface DMZ-18 [Capturing - 2820 bytes]
  match icmp host 10.0.19.49 host 10.129.190.3
capture asp type asp-drop all [Capturing - 534 bytes]
ciscoasa/admin# show cap asp

6 packets captured

   1: 14:46:01.645535       802.3 encap packet Drop-reason: (l2_acl) FP L2 rule drop

   2: 14:46:03.645535       802.3 encap packet Drop-reason: (l2_acl) FP L2 rule drop

   3: 14:46:03.765997       802.1Q vlan#58 P7 10.129.190.4.5353 > 224.0.0.251.5353:  udp 320 Drop-reason: (acl-drop) Flow is denied by configured rule

   4: 14:46:04.895354       0.0.0.0.68 > 255.255.255.255.67:  udp 292 Drop-reason: (acl-drop) Flow is denied by configured rule

   5: 14:46:05.645504       802.3 encap packet Drop-reason: (l2_acl) FP L2 rule drop

   6: 14:46:07.645489       802.3 encap packet Drop-reason: (l2_acl) FP L2 rule drop


ciscoasa/admin# show cap capout

8 packets captured

   1: 14:46:46.298431       802.1Q vlan#58 P0 10.0.19.49 > 10.129.190.3 icmp: echo request
   2: 14:46:46.298980       802.1Q vlan#58 P0 10.129.190.3 > 10.0.19.49 icmp: echo reply
   3: 14:46:51.298904       802.1Q vlan#58 P0 10.0.19.49 > 10.129.190.3 icmp: echo request
   4: 14:46:51.299545       802.1Q vlan#58 P0 10.129.190.3 > 10.0.19.49 icmp: echo reply
   5: 14:46:56.302352       802.1Q vlan#58 P0 10.0.19.49 > 10.129.190.3 icmp: echo request
   6: 14:46:56.303008       802.1Q vlan#58 P0 10.129.190.3 > 10.0.19.49 icmp: echo reply
   7: 14:47:01.301757       802.1Q vlan#58 P0 10.0.19.49 > 10.129.190.3 icmp: echo request
   8: 14:47:01.302398       802.1Q vlan#58 P0 10.129.190.3 > 10.0.19.49 icmp: echo reply
8 packets shown


ciscoasa/admin# show cap capout trace packet-number 2

12 packets captured

   2: 14:46:46.298980       802.1Q vlan#58 P0 10.129.190.3 > 10.0.19.49 icmp: echo reply
Phase: 1
Type: CAPTURE
Subtype:
Result: ALLOW
Config:
Additional Information:
MAC Access list

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 3
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (any,outside) source static ASA-DMZ-pool ASA-DMZ-pool destination static INTERNAL_without-1-77-78 INTERNAL_without-1-77-78
Additional Information:
NAT divert to egress interface outside
Untranslate 10.0.19.49/1 to 10.0.19.49/1

Phase: 4
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group global_access global
access-list global_access extended permit icmp any4 any4 log warnings
Additional Information:

Phase: 5
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (any,outside) source static ASA-DMZ-pool ASA-DMZ-pool destination static INTERNAL_without-1-77-78 INTERNAL_without-1-77-78
Additional Information:
Static translate 10.129.190.3/0 to 10.129.190.3/0

Phase: 6
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 7
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 8
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
Additional Information:

Phase: 9
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
nat (any,outside) source static ASA-DMZ-pool ASA-DMZ-pool destination static INTERNAL_without-1-77-78 INTERNAL_without-1-77-78
Additional Information:

Phase: 10
Type: USER-STATISTICS
Subtype: user-statistics
Result: ALLOW
Config:
Additional Information:

Phase: 11
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 34202383, packet dispatched to next module

Phase: 12
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (any,outside) source static ASA-DMZ-pool ASA-DMZ-pool destination static INTERNAL_without-1-77-78 INTERNAL_without-1-77-78
Additional Information:
NAT divert to egress interface outside
Untranslate 10.0.19.49/1 to 10.0.19.49/1

Phase: 13
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group global_access global
access-list global_access extended permit icmp any4 any4 log warnings
Additional Information:

Phase: 14
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (any,outside) source static ASA-DMZ-pool ASA-DMZ-pool destination static INTERNAL_without-1-77-78 INTERNAL_without-1-77-78
Additional Information:
Static translate 10.129.190.3/0 to 10.129.190.3/0

Phase: 15
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 16
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 17
Type: SUBOPTIMAL-LOOKUP
Subtype: suboptimal next-hop
Result: ALLOW
Config:
Additional Information:
ifc selected is not same as preferred ifc
Doing route lookup again on ifc  outside

Phase: 18
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 10.0.1.32 using egress ifc  outside

Result:
input-interface: DMZ-18
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: allow

1 packet shown

На релизе 9.0(3) trace  выглядит так:


ciscoasa/admin# cap capin trace interface management match ip host 10.0.19.49  host 10.129.128.4
ciscoasa/admin# show capture capin

4 packets captured

   1: 10:27:40.850786       10.0.19.49 > 10.129.128.4: icmp: echo request
   2: 10:27:40.851274       10.129.128.4 > 10.0.19.49: icmp: echo reply
   3: 10:27:41.866150       10.0.19.49 > 10.129.128.4: icmp: echo request
   4: 10:27:41.866623       10.129.128.4 > 10.0.19.49: icmp: echo reply
4 packets shown
ciscoasa/admin# show capture capin trace packet-number 1

26 packets captured

   1: 10:27:40.850786       10.0.19.49 > 10.129.128.4: icmp: echo request
Phase: 1
Type: CAPTURE
Subtype:
Result: ALLOW
Config:
Additional Information:
MAC Access list

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 3
Type: FLOW-LOOKUP
Subtype:
Result: ALLOW
Config:
Additional Information:
Found flow with id 1846, using existing flow

Result:
Action: allow


1 packet shown

Ссылка на Cisco:
https://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/118097-configure-asa-00.html






четверг, 6 февраля 2020 г.

Настройка ограничений неприятного трафика для c6500 (sup720).

Сложилась ситуация, когда в ИТ-инфраструктуре произошла смена поколений серверов, но остались старые ядра сети, которые в свое время были флагманами. Петли генерируемые при неправильной настройки виртуальных свичей раньше не приносили больших проблем ядру - запас производительности позволял спокойно разбираться с нарушителями. Но сейчас, когда любой сервер обладает огромной мощностью и очень производительными сетевыми картами, картина изменилась - петли стали загружать CPU sup720 (cisco 6500) на 100% и страдать начинают все, при этом множественный мониторинг по SNMP, ICMP тоже повышает утилизацию, что усугубляет ситуацию.

Как меру по разгрузки ядра (уже) надо включать некое ограничение нагрузки на CPU самого ядра сети от внешних запросов.

на sup720 есть некоторые ограничения по применению механизма control-plane  (COPP)  - он не может работать с L2, т.е. ему нельзя в policy указывать L2 связанные параметры: mac, arp.
политику можно применить только если есть L3 описание трафика в class-map, а также минимальное ограничение в 32000 bit/s.

пример:
!
ip access-list extended icmp-to-core
 permit icmp any host <core ip>

ip access-list extended snmp-core
 permit udp any host <core ip> eq snmp

class-map match-all copp-icmp
  match access-group name icmp-to-core

class-map match-all copp-snmp
  match access-group name snmp-core

policy-map copp
  class copp-icmp
   police 32000 1500 1500    conform-action transmit     exceed-action drop
class copp-snmp
   police 64000 3200    conform-action transmit     exceed-action drop

control-plane
 service-policy input copp

(желательно, при добавлении в policy-map нового class-map, выключать service-policy из  control-plane, добавлять class в policy-map и затем опять включать в control-plane, т.к. производится проверка совместимости policy и control-plane, в противном случаем можно добавить в policy-map не совместимы параметр, что может привести к крешу IOS)


L2 ограничения можно установить только через mls qos:
!
mls qos
mls cef error action reset
mls qos map policed-dscp normal-burst 0 24 26 34 36 to 8
mls qos map cos-dscp 0 10 18 24 34 46 48 56
mls qos protocol ARP police 640000 6400 


И надо рассматривать включение storm-control на всех интерфейсах, т.к. риск отключить отдельный сегмент сети уже не так страшен, по сравнению с неработоспособность всей сети.