لب عملی: پیکربندی امنیت DNS به‌سبک-Cisco Umbrella از طریق تغییرمسیر Forwarding DNS

این لب عملی یک روتر را برای رهگیری هر پرس‌وجوی DNS کلاینت و تغییرمسیر آن به‌سمت یک resolver DNS امنیت-محور با استفاده از رهگیری forwarding DNS پیکربندی می‌کند، و اعمال امنیت DNS تحویل‌شده-با-ابر را بدون نیاز به تغییرات پیکربندی به‌ازای-هر-کلاینت تقریب می‌زند.

تغییرمسیر شفاف DNSResolver DNS امنیت-محوررهگیری DNS مبتنی‌بر-سیاست

~4 دقیقه مطالعه · آخرین به‌روزرسانی ۵ مهر ۱۴۰۵

هدف لب

پیکربندی یک روتر برای رهگیری پرس‌وجوهای DNS خروجی مقصدشان resolver های دلخواه و تغییرمسیر شفاف آن‌ها به‌سمت یک سرور DNS امنیت-محور تعیین‌شده، و تأیید اینکه کلاینت‌ها پاسخ‌های DNS را از resolver امنیتی دریافت می‌کنند صرف‌نظر از اینکه کدام سرور DNS اصلاً برای استفاده پیکربندی شده بودند.

هدف لب (چرا مهم است)

سرویس‌های امنیت DNS تحویل‌شده-با-ابر با گذراندن هر پرس‌وجوی DNS هر کلاینت از میان یک resolver آگاه-از-امنیت قادر به مسدودکردن دامنه‌های شناخته‌شده-مخرب پیش از تکمیل حل‌شدن کار می‌کنند. به‌جای بازپیکربندی تنظیمات DNS هر کلاینت جداگانه، رهگیری سطح-شبکه هر ترافیک DNS را شفاف در روتر تغییرمسیر می‌دهد، و همان وضعیت امنیتی را بدون لمس پیکربندی نقطه‌پایانی به دست می‌آورد.

توپولوژی لب

R1
  Gi0/0: 192.168.230.1/24 (LAN، کلاینت‌ها اینجا
                            با سرورهای DNS
                            مختلف پیکربندی شده)
  Gi0/1: 203.0.113.1/30 (WAN)

SecurityDNS: 203.0.113.53 (resolver امنیت-محور،
             دامنه‌های شناخته‌شده-مخرب را مسدود می‌کند)

PC-A با سرور DNS 8.8.8.8 پیکربندی شده (یک
resolver کاملاً متفاوت و غیر-امنیتی)

وظیفه ۱: تأیید سرور DNS پیکربندی‌شده PC-A

تأیید کن PC-A صراحتاً برای استفاده از 8.8.8.8 پیکربندی شده، نه resolver امنیتی.

وظیفه ۲: پیکربندی یک Route-Map که ترافیک DNS را تطبیق می‌دهد

یک route-map که ترافیک پورت UDP/TCP 53 از LAN را تطبیق می‌دهد بساز.

وظیفه ۳: پیکربندی PBR برای تغییرمسیر ترافیک DNS

route-map را به‌عنوان یک سیاست که ترافیک DNS منطبق‌شده را به آدرس resolver امنیتی تغییرمسیر می‌دهد، صرف‌نظر از مقصد اصلی‌اش، اعمال کن.

وظیفه ۴: تأیید تغییرمسیر شفاف پرس‌وجوهای DNS PC-A

تأیید کن پرس‌وجوهای DNS PC-A، با وجود فرستاده‌شدن به‌سمت 8.8.8.8، واقعاً توسط resolver امنیتی پاسخ داده می‌شوند.

وظیفه ۵: تأیید مسدودشدن یک پرس‌وجو برای یک دامنه شناخته‌شده-مخرب

یک دامنه که resolver امنیتی برای مسدودکردنش پیکربندی شده را پرس‌وجو کن و تأیید کن حل‌شدن شکست می‌خورد یا یک آدرس sinkhole بازمی‌گرداند، به‌جای پاسخ واقعی.

راه‌حل و تأیید

PC-A> ipconfig /all | findstr "DNS Servers"

DNS Servers: 8.8.8.8
-- تأیید‌شده PC-A صراحتاً به یک سرور DNS
-- کاملاً متفاوت و غیر-امنیتی اشاره شده

R1(config)# access-list 150 permit udp 192.168.230.0 0.0.0.255 any eq 53
R1(config)# access-list 150 permit tcp 192.168.230.0 0.0.0.255 any eq 53

R1(config)# route-map REDIRECT-DNS permit 10
R1(config-route-map)# match ip address 150
R1(config-route-map)# set ip next-hop 203.0.113.53

-- مشابه در ساختار با لب PBR پوشش‌داده‌شده
-- پیش‌تر در این مجموعه، اما اینجا به‌طور خاص
-- ترافیک پورت DNS را برای تغییرمسیر به یک
-- resolver امنیتی به‌جای یک مسیر WAN جایگزین
-- هدف می‌گیرد

R1(config)# interface gigabitethernet0/0
R1(config-if)# ip policy route-map REDIRECT-DNS

PC-A> nslookup example.com 8.8.8.8

Server: [قادر به رسیدن مستقیم به 8.8.8.8 با
         نام نیست، اما پاسخ می‌رسد]
Address: 93.184.216.34
-- PC-A باور دارد از 8.8.8.8 پرس‌وجو کرد، اما
-- پاسخ واقعاً از SecurityDNS آمد به‌دلیل
-- تغییرمسیر شفاف PBR -- پیکربندی DNS خود
-- کلاینت هرگز لمس نشد

R1# show route-map REDIRECT-DNS

route-map REDIRECT-DNS, permit, sequence 10
  Match clauses:
    ip address (access-lists): 150
  Set clauses:
    ip next-hop 203.0.113.53
  Policy routing matches: 47 packets, 4230 bytes
-- شمارنده تطبیق تأیید می‌کند ترافیک DNS واقعاً
-- تغییرمسیر داده می‌شود، نه صرفاً پیکربندی‌شده

PC-A> nslookup known-malicious-domain.test 8.8.8.8

Server: [تغییرمسیر‌شده به SecurityDNS]
*** Request failed / non-existent domain

-- سیاست مسدودسازی resolver امنیتی برای این
-- دامنه شناخته‌شده-مخرب شفاف اعمال می‌شود،
-- چون هر حل‌شدن DNS برای این کلاینت اکنون
-- واقعاً از میان SecurityDNS عبور می‌کند صرف‌نظر
-- از سرور پیکربندی‌شده خود کلاینت

نکته کلیدی

Policy-Based Routing، پیش‌تر در این مجموعه برای هدایت مسیر عمومی پوشش داده شد، به‌همان‌اندازه خوب برای اعمال وضعیت امنیت DNS در سراسر شبکه بدون لمس پیکربندی کلاینت منفرد اعمال می‌شود — تطبیق به‌طور خاص با ترافیک پورت 53 و تغییرمسیرش به‌سمت یک resolver آگاه-از-امنیت همان نتیجه عملی بازپیکربندی دستی تنظیمات DNS هر نقطه‌پایانی را به دست می‌آورد، اما به‌طور متمرکز، سازگار، و بدون وابستگی به تبعیت نقطه‌پایانی از یک تنظیم DNS اداری-پوش‌شده که یک کاربر در غیر این صورت می‌توانست برگرداند.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

لب عملی: چالش عیب‌یابی جامع نهایی CCNP (یکپارچگی BGP، DMVPN، و QoS)

این لب عملی یک شکست پیچیده چندلایه در سراسر یک توپولوژی یکپارچه BGP-روی-DMVPN ترکیب‌شده با علامت‌گذاری QoS ارائه می‌دهد، و نیازمند تشخیص سیستماتیک یک پیکربندی نادرست route reflector، یک شکست ثبت NHRP، و یک سیاست QoS نادرست‌اعمال‌شده که هم‌زمان روی همان شبکه تأثیر می‌گذارند است.

ادامه

لب عملی: پیکربندی BGP روی DMVPN

این لب عملی iBGP را به‌عنوان پروتکل مسیریابی در سراسر همان توپولوژی hub-and-spoke DMVPN استفاده‌شده در دو لب قبلی اجرا می‌کند، hub را به‌عنوان یک route reflector BGP پیکربندی می‌کند طوری‌که spoke ها مسیرهای یکدیگر را بدون یک mesh کامل iBGP یاد بگیرند، و دو مفهوم قبلاً جداگانه را در یک طراحی یکپارچه ترکیب می‌کند.

ادامه

لب عملی: پیکربندی OSPF روی DMVPN

این لب عملی OSPF را به‌عنوان پروتکل مسیریابی پویا در سراسر همان توپولوژی hub-and-spoke DMVPN اجرا می‌کند، و اینترفیس تونل را به‌عنوان یک نوع شبکه OSPF point-to-multipoint پیکربندی می‌کند تا الگوی همسایگی hub-and-spoke را به‌درستی بدون نیاز به انتخاب DR/BDR نوع شبکه broadcast مدیریت کند.

ادامه

لب عملی: پیکربندی EIGRP روی DMVPN

این لب عملی EIGRP را به‌عنوان پروتکل مسیریابی پویا در سراسر توپولوژی hub-and-spoke DMVPN ساخته‌شده در لب‌های قبلی اجرا می‌کند، و تأیید می‌کند روابط همسایه به‌درستی در سراسر تونل چندنقطه‌ای شکل می‌گیرند و مسیرها بدون نیاز به پیکربندی ایستای هر-spoke روی hub منتشر می‌شوند.

ادامه

لب عملی: پیکربندی احراز هویت MD5 در HSRP

این لب عملی احراز هویت MD5 را روی یک گروه HSRP پیکربندی می‌کند، و تأیید می‌کند دو روتر با رشته‌های احراز هویت منطبق یک رابطه active/standby معمولی تشکیل می‌دهند در حالی که یک روتر با رشته نامنطبق کاملاً از گروه مستثنی می‌شود.

ادامه

لب عملی: پیکربندی امتیازدهی سلامت به‌سبک-Assurance در Cisco DNA Center (شبیه‌سازی‌شده از طریق IP SLA و EEM)

این لب عملی نظارت IP SLA را با یک applet EEM ترکیب می‌کند تا یک بررسی سلامت ساده‌شده به‌سبک-assurance را شبیه‌سازی کند، و سلامت یک لینک را بر اساس آستانه‌های عملکرد اندازه‌گیری‌شده به‌طور خودکار طبقه‌بندی می‌کند و یک تغییر وضعیت واضح را وقتی لینک بدتر می‌شود لاگ می‌کند.

ادامه