هدف لب
پیکربندی یک روتر برای رهگیری پرسوجوهای 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 53R1(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-DNSPC-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 اداری-پوششده که یک کاربر در غیر این صورت میتوانست برگرداند.