Control Plane و حفاظت از منابع روتر

روتر یا سوئیچ لایه ۳ شما فقط ترافیک دیگران را عبور نمی‌دهد؛ خودش هم «میزبان» است: BGP و OSPF با آن حرف می‌زنند، شما با SSH به آن وصل می‌شوید، SNMP و NTP از آن جواب می‌گیرند. همه این بسته‌ها به CPU دستگاه می‌رسند، و CPU برخلاف ASIC سخت‌افزاری ظرفیت محدودی دارد. کافی است یک کاربر بدخواه یا یک ویروس با یک ابزار ساده سیل بسته‌های UDP به سمت IP روتر بفرستد تا CPU صددرصد شود، همسایه‌های مسیریابی بیفتند و کل شبکه از اینترنت جدا شود.

راه‌حل سیسکو برای این مشکل Control Plane Policing یا CoPP است: یک سیاست QoS که جلوی ورودی CPU می‌نشیند، ترافیک را دسته‌بندی می‌کند و برای هر دسته سقف می‌گذارد؛ تا پروتکل‌های حیاتی همیشه جا داشته باشند و ترافیک مزاحم پیش از رسیدن به CPU دور ریخته شود. در این مطلب مفهوم Planeها، طراحی درست کلاس‌ها، کانفیگ کامل روی روترهای IOS و IOS XE ، رفتار متفاوت CoPP روی سوئیچ‌های Catalyst 9000 ، روش آزمایش و اشتباه‌های رایج را مرور می‌کنیم.

control plane
control plane

CoPP در یک نگاه

هدف حفاظت از CPU دستگاه در برابر DoS و تضمین جا برای پروتکل‌های حیاتی
ابزار Modular QoS CLI (MQC) : class-map ، policy-map و police
محل اعمال روی اینترفیس منطقی control-plane در جهت ورودی
روترهای IOS / IOS XE سیاست را خودتان طراحی و اعمال می‌کنید
Catalyst 9000 سیاست ثابت system-cpp-policy از پیش نصب شده؛ فقط نرخ‌ها قابل تنظیم‌اند
Nexus (NX-OS) پروفایل CoPP (مثل strict) در اولین بوت اعمال می‌شود

سه Plane در هر دستگاه شبکه

سیسکو در راهنمای Hardening دستگاه‌ها، کارکرد هر روتر و سوئیچ را به سه بخش (Plane) تقسیم می‌کند. CoPP مخصوص دومی است:

Plane چه ترافیکی کجا پردازش می‌شود ابزار حفاظت
Data Plane ترافیک کاربران که از دستگاه عبور می‌کند ASIC و سخت‌افزار (یا CEF) ACL ، uRPF ، QoS
Control Plane پروتکل‌های مسیریابی و کنترلی: BGP ، OSPF ، EIGRP ، HSRP ، ARP ، STP CPU CoPP ، احراز هویت پروتکل‌ها
Management Plane SSH ، SNMP ، NTP ، Syslog ، TACACS+ CPU ACL روی VTY ، AAA ، CoPP

ترافیک Data Plane در حالت عادی اصلاً به CPU نمی‌رسد. اما بسته‌هایی که مقصدشان خود دستگاه است، بسته‌های با TTL منقضی، ARP ، و بسته‌هایی که سخت‌افزار نمی‌تواند پردازش کند (Punt) همه به CPU می‌روند. همین مسیر همان نقطه آسیب‌پذیری است.

یک آزمایش ساده: CPU یک روتر چطور از پا درمی‌آید

ما در آزمایشگاه روی یک روتر Cisco 2811 با یک ابزار تست شبکه در دسترس، بسته‌های UDP کوچک به سمت IP خود روتر فرستادیم. با حدود ۲۸ مگابیت ترافیک، CPU روتر کاملاً اشباع و دستگاه از دسترس خارج شد. هر چه بسته‌ها کوچک‌تر و تعدادشان بیشتر باشد، بار روی CPU سنگین‌تر است، چون CPU به ازای هر بسته کار می‌کند نه به ازای هر بایت.

udp-attack
udp-attack

روترهای جدید قوی‌ترند، اما قاعده عوض نشده است: ظرفیت CPU برای بسته‌های «به مقصد خود دستگاه» همیشه چند مرتبه کمتر از ظرفیت فورواردینگ سخت‌افزاری است.

طراحی درست کلاس‌ها

اشتباه رایج این است که یک کلاس برای «همه UDP» بسازیم و نرخش را خیلی پایین بگذاریم. این کار NTP ، SNMP ، DNS ، RADIUS و حتی بعضی پروتکل‌های مسیریابی را هم خفه می‌کند. روش درست این است که ترافیک را بر اساس اهمیت دسته‌بندی کنیم، از مهم‌ترین تا بی‌ارزش:

کلاس نمونه ترافیک سیاست پیشنهادی
Undesirable پورت‌هایی که هرگز نباید به روتر برسند (Telnet از اینترنت ، SQL Slammer 1434 ، …) drop کامل
Critical / Routing BGP ، OSPF ، EIGRP ، HSRP ، BFD نرخ بالا؛ ترجیحاً فقط مانیتور (exceed هم transmit)
Management SSH از شبکه مدیریت، SNMP ، NTP ، TACACS+ ، RADIUS نرخ متوسط
Normal / ICMP ping ، traceroute ، unreachable نرخ کم
class-default هر چیز دیگری که به CPU می‌رسد نرخ کم و drop مازاد
در شروع کار، برای کلاس‌ها exceed-action transmit بگذارید و فقط شمارنده‌ها را ببینید. بعد از یکی دو هفته که الگوی واقعی ترافیک را شناختید، نرخ‌ها را تنظیم و drop را فعال کنید. CoPP با نرخ اشتباه، خودش یک DoS است.

کانفیگ کامل روی روترهای IOS و IOS XE

این نمونه برای یک روتر مرزی با BGP به ISP و مدیریت از شبکه 10.10.99.0/24 است. آدرس‌ها و نرخ‌ها را با شبکه خودتان تطبیق دهید.

! ---------- 1) ACLs ----------
ip access-list extended COPP-UNDESIRABLE
 permit udp any any eq 1434
 permit tcp any any eq telnet
ip access-list extended COPP-ROUTING
 permit tcp host 203.0.113.1 any eq bgp
 permit tcp host 203.0.113.1 eq bgp any
 permit ospf any any
 permit udp any any eq 3784
ip access-list extended COPP-MGMT
 permit tcp 10.10.99.0 0.0.0.255 any eq 22
 permit udp host 10.10.99.5 any eq snmp
 permit udp any eq ntp any eq ntp
 permit tcp host 10.10.99.50 eq tacacs any
ip access-list extended COPP-ICMP
 permit icmp any any echo
 permit icmp any any echo-reply
 permit icmp any any ttl-exceeded
 permit icmp any any unreachable
 permit icmp any any packet-too-big
!
! ---------- 2) Classes ----------
class-map match-all COPP-UNDESIRABLE
 match access-group name COPP-UNDESIRABLE
class-map match-all COPP-ROUTING
 match access-group name COPP-ROUTING
class-map match-all COPP-MGMT
 match access-group name COPP-MGMT
class-map match-all COPP-ICMP
 match access-group name COPP-ICMP
!
! ---------- 3) Policy ----------
policy-map COPP-POLICY
 class COPP-UNDESIRABLE
  drop
 class COPP-ROUTING
  police 2000000 conform-action transmit exceed-action transmit
 class COPP-MGMT
  police 1000000 conform-action transmit exceed-action drop
 class COPP-ICMP
  police 128000 conform-action transmit exceed-action drop
 class class-default
  police 256000 conform-action transmit exceed-action drop
!
! ---------- 4) Apply ----------
control-plane
 service-policy input COPP-POLICY

نکته‌های این کانفیگ:

  • ترتیب کلاس‌ها مهم است؛ بسته در اولین کلاسی که match شود می‌ماند. کلاس Undesirable اول است تا بسته‌های مزاحم زودتر دور ریخته شوند.
  • کلاس Routing عمداً exceed-action transmit دارد؛ هرگز نمی‌خواهیم همسایه BGP به‌خاطر CoPP بیفتد، فقط می‌خواهیم مصرفش را ببینیم.
  • پورت 3784 برای BFD است؛ اگر BFD ندارید حذفش کنید.
  • قبل از اعمال روی دستگاه عملیاتی، کانفیگ را روی یک دستگاه آزمایشی تست کنید و یک نشست کنسول باز داشته باشید.

Control Plane Protection (CPPr)

روی روترهای IOS می‌توانید control plane را به زیرمسیرهای دقیق‌تر هم تقسیم کنید: control-plane host (ترافیکی که مقصدش خود روتر است)، control-plane transit و control-plane cef-exception. روی زیرمسیر host ، علاوه بر policing ، سیاست‌های port-filter (بستن پورت‌های TCP/UDP بسته روی خود روتر) و queue-threshold هم ممکن است:

class-map type port-filter match-all PF-CLOSED
 match closed-ports
policy-map type port-filter PF-POLICY
 class PF-CLOSED
  drop
control-plane host
 service-policy type port-filter input PF-POLICY

این سیاست هر بسته‌ای را که به پورت بسته‌ای روی خود روتر برسد، پیش از پردازش در CPU دور می‌ریزد. نتیجه را با show control-plane host open-ports و شمارنده‌ها را با show control-plane host counters ببینید.

CoPP روی سوئیچ‌های Catalyst 9000

روی خانواده Catalyst 9000 ، CoPP فرق مهمی دارد. طبق راهنمای رسمی CoPP برای Catalyst 9300:

  • در اولین روشن شدن، سوئیچ سیاستی به نام system-cpp-policy می‌سازد و روی control-plane نصب می‌کند، با کلاس‌هایی که هر کدام به یک صف CPU نگاشت شده‌اند.
  • فقط همین سیاست روی control-plane مجاز است و قابل حذف یا جایگزینی نیست؛ فقط در جهت ورودی.
  • تنها action مجاز police است و نرخ فقط به‌صورت بسته در ثانیه (pps) تعریف می‌شود و به نزدیک‌ترین مضرب ۲۰۰ گرد می‌شود.
  • با cpp system-default همه نرخ‌ها به مقدار پیش‌فرض سیسکو برمی‌گردند.
C9300# show policy-map control-plane
C9300# show platform hardware fed switch active qos queue stats internal cpu policer
C9300(config)# policy-map system-cpp-policy
C9300(config-pmap)# class system-cpp-police-routing-control
C9300(config-pmap-c)# police rate 6000 pps

در عمل روی سوئیچ‌های کاتالیست به‌ندرت نیاز به تغییر نرخ‌ها دارید؛ کار شما بیشتر خواندن شمارنده‌هاست تا بفهمید کدام صف CPU زیر فشار است. روی سوئیچ‌های Nexus هم NX-OS در اولین بوت یک پروفایل CoPP اعمال می‌کند؛ توضیح آن را در مطلب آشنایی با سیسکو NX-OS ببینید.

بررسی و عیب‌یابی

دستور کاربرد
show policy-map control-plane شمارنده conform و exceed هر کلاس؛ مهم‌ترین دستور
show processes cpu sorted مصرف CPU و پروسس‌های پرمصرف
show processes cpu history نمودار مصرف CPU در ۶۰ ثانیه، ۶۰ دقیقه و ۷۲ ساعت
show control-plane host counters شمارنده‌های CPPr روی مسیر host
show ip bgp summary و show ip ospf neighbor اطمینان از اینکه همسایه‌ها بعد از اعمال CoPP پایدارند

اشتباه‌های رایج

  • یک کلاس برای همه UDP: NTP ، SNMP ، DNS و RADIUS هم UDP هستند و با آن خفه می‌شوند.
  • drop در کلاس Routing: در اوج ترافیک یا بعد از قطع و وصل لینک، BGP با تعداد زیادی بسته به‌روزرسانی می‌کند و همسایه می‌افتد.
  • فراموش کردن ARP: روی روترها ARP در class-default می‌افتد؛ نرخ class-default را آن‌قدر پایین نگذارید که ARP در LANهای بزرگ drop شود.
  • تست نکردن SSH از شبکه مدیریت: پیش از بستن نشست، از یک پنجره جدید وصل شوید.

پرسش‌های متداول

CoPP جای فایروال یا ACL ورودی را می‌گیرد؟
نه. ACL زیرساخت (iACL) روی اینترفیس ورودی جلوی بسته‌های ناخواسته را زودتر می‌گیرد؛ CoPP لایه دوم دفاع درست جلوی CPU است. هر دو را با هم استفاده کنید.

CoPP روی ترافیک عبوری کاربران اثر دارد؟
نه. فقط روی بسته‌هایی اثر دارد که به CPU می‌رسند.

روی سوئیچ کاتالیست 9000 می‌توانم سیاست خودم را بنویسم؟
نه؛ فقط نرخ کلاس‌های سیاست ثابت system-cpp-policy قابل تغییر است.

منابع رسمی

مطالب مرتبط: ایمن‌سازی روتر سیسکو ، سیسکو uRPF و BOGON و راه رهایی از آن.

مشاوره با AKA NET

برای طراحی CoPP ، Hardening روترهای مرزی و بررسی دلیل بالا رفتن CPU دستگاه‌های سیسکو با آکانت (AKA NET) تماس بگیرید.

تلفن: 09121308444  |  ایمیل: aka@aka.ir  |  aka.ir

2 فکر می‌کنند “Control Plane و حفاظت از منابع روتر”

  1. بازتاب: Control Plane و حفاظت از منابع روتر | مرکز آموزش یوسرور - هاست اشتراکی - سرور مجای با کیفیت

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *