همهٔ سرویسهای DNS امنیتمحور کموبیش یک وعده میدهند: دستگاههایتان را به حلکنندهٔ آنها متصل کنید تا دامنههای مخرب شناختهشده، پیش از آنکه مرورگر به آنها وصل شود، متوقف شوند. Cloudflare، Quad9، NextDNS و AdGuard هرکدام گونهای از این محافظت را ارائه میکنند؛ اما میخواستم ببینم در عمل چند بار نامهای میزبان مخرب یکسان را مسدود میکنند.
بنابراین، همان ۱۰۰ دامنهٔ بدافزاری و فیشینگ را به هر چهار سرویس دادم و پاسخهایشان را ثبت کردم. هیچیک از سایتها را باز نکردم، چیزی بارگیری نکردم و حتی نگذاشتم مرورگری به آنها نزدیک شود. این صرفاً آزمونی برای تحلیل نام در DNS بود و چهار سرویس بسیار کمتر از آنچه انتظار داشتم با یکدیگر همنظر بودند.
از بیش از ۴۱,۰۰۰ دامنه آغاز کردم و فهرست را به ۱۰۰ مورد رساندم
دامنههای ازکارافتاده آزمون امنیتی را بیش از حد آسان میکنند
پیدا کردن هزاران نشانی اینترنتی مخرب آسان بود؛ اما تبدیل آنها به آزمون DNS قابلاعتماد، پالایش بسیار بیشتری میخواست.
برای بخش بدافزار، از فایل میزبانِ فقطدامنهٔ URLhaus استفاده کردم که نامهای میزبان مرتبط با نشانیهای اینترنتی بدافزاری فعال یا افزودهشده در ۴۸ ساعت گذشته را در بر میگیرد. URLhaus همچنین برای کاهش تشخیصهای مثبت کاذب، نامهای میزبان متعلق به دامنههای فهرست Tranco Top 1M را کنار میگذارد. برای فیشینگ نیز از مجموعهدادهٔ برخط و تأییدشدهٔ PhishTank بهره گرفتم.
پس از استخراج نامهای میزبان، حذف موارد تکراری و کنار گذاشتن نشانیهای IP خام و دیگر ورودیهای نامعتبر، ۳۹۲ میزبان یکتای URLhaus و ۴۱,۵۲۲ میزبان یکتای PhishTank باقی ماند. از هر منبع ۷۵ مورد را بهطور تصادفی برگزیدم و کار را با ۱۵۰ گزینه آغاز کردم.
پیش از آزمودن هر حلکنندهٔ امنیتمحور، هر ۱۵۰ دامنه را از راه نقطهٔ پایانی معمولی و پالایشنشدهٔ DNS-over-HTTPS شرکت Cloudflare در cloudflare-dns.com/dns-query بررسی کردم. میخواستم پیش از آنکه سرویسهای پالایشگر فرصت مسدود کردن دامنهها را پیدا کنند، بدانم کدامیک هنوز بهطور عادی تحلیل نام میشوند.
نتیجهٔ این اجرای مبنا چنین بود:
- ۱۳۱ دامنه که همچنان تحلیل نام میشدند
- ۱۹ دامنه که تحلیل نام نمیشدند
- ۰ خطای پرسوجو
- ۷۴ میزبان بدافزاریِ باقیمانده
- ۵۷ میزبان فیشینگِ باقیمانده
سپس مجموعهدادهٔ نهایی را به ۱۰۰ دامنه محدود کردم که بهطور برابر شامل ۵۰ میزبان بدافزاری و ۵۰ میزبان فیشینگ بود. در آخرین بررسی مبنا، همهٔ آنها همچنان یک نشانی IPv4 برمیگرداندند.
این پاکسازی اهمیت داشت، زیرا زیرساخت ازکارافتاده میتواند همهٔ حلکنندهها را هوشمندتر از واقعیت نشان دهد. اگر نام میزبان مخربی پیشتر از DNS ناپدید شده باشد، ممکن است به نظر برسد حلکنندهٔ پالایششده آن را مسدود کرده است، حال آنکه سامانهٔ شناسایی تهدیدش هرگز چنین تصمیمی نگرفته است.
در آزمون نهایی، با استفاده از dnspython و HTTP/۲ همان ۱۰۰ پرسوجوی رکورد A را از راه DNS-over-HTTPS برای حلکنندهٔ پالایشگر بدافزار Cloudflare، سرویس Quad9، نمایهای تازه در NextDNS با تنظیمات امنیتی پیشفرض و حلکنندهٔ عمومی پیشفرض AdGuard فرستادم. درست پیش از امتیازدهی به هر نام میزبان، آن را بار دیگر با سرویس مبنای پالایشنشده بررسی کردم. هنگام اجرای چهار پرسوجوی پالایششده، هر ۱۰۰ دامنه هنوز بهدرستی تحلیل نام میشدند.
همچنین ناچار بودم تعریف «مسدود شدن» را یکسانسازی کنم، زیرا همهٔ سرویسها آن را به شیوهای مشابه گزارش نمیکنند. Cloudflare برای دامنههایی که مخرب تشخیص میداد 0.0.0.0 را برمیگرداند و NextDNS نیز در جریان آزمون من برای پرسوجوهای مسدودشدهٔ رکورد A از همین نشانی نامشخص استفاده کرد. Quad9 با NXDOMAIN و AUTHORITY: 0 مسدود شدن را نشان میداد، در حالی که AdGuard اغلب نشانی مسدودسازی 94.140.14.33 خود را برمیگرداند. اگر همهٔ پاسخهایی را که ظاهراً ناموفق بودند یکسان در نظر میگرفتم، نتیجهٔ مقایسه بهشدت منحرف میشد.
نیمهٔ فیشینگ آزمون پیچیدگی دیگری هم دارد. PhishTank نشانیهای اینترنتی مخرب را تأیید میکند، اما من آنها را به نام میزبان تبدیل کردم، زیرا پالایش DNS در سطح دامنه انجام میشود. قرار داشتن یک صفحهٔ فیشینگ روی زیرساختی اشتراکی یا بهخطرافتاده لزوماً به این معنا نیست که باید کل نام میزبان مسدود شود؛ ازاینرو، فیشینگ برای محافظتی که تنها بر DNS تکیه دارد، دستهای بهویژه دردسرساز است.
بدافزار در مقایسه با فیشینگ آسان بود
امتیازهای کلی آشفتگی پنهان را نشان نمیدهند
همان ۱۰۰ دامنه را از هر چهار حلکنندهٔ پالایششده پرسوجو کردم و در مجموع ۴۰۰ پرسوجوی امتیازدهیشدهٔ DNS برای مقایسه به دست آمد.
| ارائهدهنده | مجموع مسدودشدهها | بدافزارهای مسدودشده | فیشینگهای مسدودشده |
|---|---|---|---|
| ادگارد | 86/100 | 50/50 | 36/50 |
| کلادفلر | 85/100 | 48/50 | 37/50 |
| نکستدیاناس | 70/100 | 47/50 | 23/50 |
| کواد۹ | 68/100 | 50/50 | 18/50 |
در مجموع، ادگارد و کلادفلر تنها یک دامنه با هم فاصله داشتند؛ اما وقتی نتایج بدافزار و فیشینگ را جدا کردم، این اختلاف ناچیز دیگر چندان مهم به نظر نمیرسید.
نتایج بدافزارها تصویری نسبتاً یکدست نشان داد. ادگارد و کواد۹ هر ۵۰ میزبان بدافزاری را مسدود کردند، کلادفلر ۴۸ مورد را شناسایی کرد و نکستدیاناس جلوی ۴۷ مورد را گرفت. مهمتر اینکه هر چهار سرویس ۴۵ دامنه از ۵۰ دامنه بدافزاری را مسدود کردند و پنج دامنه باقیمانده نیز به دام سه سرویس افتادند.
نتایج فیشینگ بههیچوجه چنین یکدست نبود. کلادفلر ۳۷ میزبان از ۵۰ میزبان فیشینگ را مسدود کرد، ادگارد ۳۶ مورد را شناسایی کرد، نکستدیاناس جلوی ۲۳ مورد را گرفت و کواد۹ نیز ۱۸ مورد را مسدود کرد. هر چهار حلگر فقط هشت نام میزبان فیشینگ را مسدود کردند.
درباره بقیه موارد، توافق بهسرعت از میان رفت. یازده مورد را سه سرویس، ۲۰ مورد را دو سرویس و ۹ مورد را تنها یک سرویس مسدود کردند؛ دو مورد نیز از سد هر چهار سرویس گذشتند. به بیان دیگر، نتیجه مسدودسازی یا اجازه دسترسی برای ۴۰ نام میزبان از ۵۰ نام میزبان فیشینگ، بسته به حلگری که به درخواست پاسخ میداد متفاوت بود.
اگر محافظت در برابر فیشینگ یکی از دلایل شما برای تغییر فراهمکننده دیاناس است، باید بیش از همه به همین بخش توجه کنید. سرویسها بر سر میزبانهای بدافزاری نمونه من بسیار آسانتر به توافق رسیدند، اما درباره فیشینگ اختلاف میان حلگرها بهمراتب بیشتر بود.
من نتیجه ۱۸ از ۵۰ را دستاویزی برای این ادعای کلی نمیکنم که کواد۹ در مقابله با فیشینگ ضعیف است. این آزمایش فقط ۵۰ نام میزبان از یک منبع داده در یک مقطع زمانی مشخص را در بر میگرفت و پایگاههای داده اطلاعات تهدید نیز همزمان با پدیدارشدن، ناپدیدشدن و بازردهبندی صفحههای مخرب، پیوسته تغییر میکنند. اگر همین آزمایش را یک هفته بعد تکرار کنم، ممکن است بعضی از این اعداد بهآسانی تغییر کنند.
بخش بزرگی از زیرساخت نمونههای فیشینگ نیز مشترک بود. ۳۶ نام میزبان از مجموع ۵۰ مورد به پلتفرمهای شناختهشده میزبانی یا پراکسی، از جمله ویبلی، میزبانی فایربیس، کلادفلر پیجز، ویکس استودیو، بلاگر و چند سرویس دیگر تعلق داشتند. همین نکته تا حدی توضیح میدهد که چرا گزارشهای فیشینگ در سطح نشانی وب همیشه بهسادگی به مسدودسازی دیاناس در سطح نام میزبان تبدیل نمیشوند.
همپوشانی میان فراهمکنندگان این موضوع را روشنتر کرد. از میان ۱۰۰ دامنه، همه سرویسها ۵۳ دامنه را مسدود کردند و تنها دو دامنه از سد هر چهار سرویس گذشتند. درباره ۴۵ دامنه باقیمانده دستکم یک اختلاف وجود داشت؛ یعنی نزدیک به نیمی از این مجموعه آزمایشی که عمداً کوچک انتخاب شده بود، بسته به حلگرِ رسیدگیکننده به درخواست پاسخ متفاوتی گرفت.
حتی مجموعهای تقریباً یکسان نیز میتوانند انتخابهایی کاملاً متفاوت را پنهان کنند. ادگارد با امتیاز ۸۶ و کلادفلر با امتیاز ۸۵ کار را به پایان رساندند، اما این به آن معنا نیست که هر دو دقیقاً همان ۸۵ یا ۸۶ نام میزبان را مسدود کردهاند. منابع متفاوت اطلاعات تهدید، قواعد ردهبندی، برنامههای بهروزرسانی و سیاستهای پالایش میتوانند از مسیرهایی کاملاً متفاوت به مجموعهایی تقریباً یکسان برسند.
این آزمایش یک بخش مهم را نیز نادیده میگیرد. من سنجیدم که حلگرها هر چند وقت یکبار دامنههای مخرب شناختهشده را مسدود میکنند، نه اینکه چند بار دامنههای سالم را بهاشتباه ببندند. ممکن است سرویسی بسیار سختگیر باشد و در این آزمایش امتیازی عالی بگیرد، اما در جاهای دیگر آسیب جانبی فراوانی ایجاد کند؛ بنابراین نباید این درصدها را معیاری برای دقت کلی سرویسها دانست.
امتیازها تنها معیار انتخاب نیستند
هر حلگر را برای چه کاری انتخاب میکنم
این آزمایش بیش از آنکه مرا به این نتیجه برساند که اختلاف امتیاز ۸۶ و ۸۵ تکلیف همهچیز را روشن میکند، کنجکاوم کرد تا تفاوتهای این خدمات را بهتر بشناسم. انتخاب DNS فقط به سرعت محدود نمیشود و این نمونه نیز آنقدر کوچک و وابسته به زمان اجرای آزمایش است که نمیتوان بر پایهٔ آن چنین حکم قطعیای داد. هنگام انتخاب، توجه به تفاوتهای ذاتی این خدمات بسیار سودمندتر است.
سرورهای رایگان DNS نیز هرکدام برای کاربردهای متفاوتی ساخته شدهاند؛ بنابراین انتخاب درست تا حد زیادی به کاری بستگی دارد که واقعاً از حلکنندهٔ خود انتظار دارید.
اگر قرار بود از میان آنها یکی را انتخاب کنم، جمعبندیام این بود:
- Cloudflare، اگر پالایش ساده و بیدردسر بدافزارها و فیشینگ را با کمترین نیاز به راهاندازی میخواهید.
- Quad9، اگر حلکنندهای امنیتمحور میخواهید که تبلیغات یا دیگر محتواها را پالایش نکند.
- NextDNS، اگر میخواهید سازوکارهای حفاظتی، فهرستهای مسدودسازی، ثبت گزارشها و دیگر رفتارهای DNS را خودتان تنظیم کنید.
- AdGuard، اگر میخواهید محافظت در برابر دامنههای مخرب را همراه با مسدودسازی تبلیغات و ردیابها در سطح شبکه داشته باشید.
این نکته کمک میکند نتیجهای را که برای NextDNS گرفتم نیز بهتر ارزیابی کنیم. من نمایهای تازه را با پیکربندی امنیتی پیشفرض آن آزمودم، نه با فعالکردن همهٔ سازوکارهای حفاظتی سختگیرانهٔ موجود. افزون بر این، NextDNS در مقایسه با یک حلکنندهٔ عمومی ثابت، مانند نقطهٔ پایانی پالایش بدافزار Cloudflare، اختیار بسیار بیشتری برای تنظیم شیوهٔ پالایش در اختیارتان میگذارد.
اگر فقط امتیاز کلی ۶۸/۱۰۰ را ببینید، ممکن است دربارهٔ Quad9 نیز بهسادگی برداشت نادرستی پیدا کنید. این سرویس همهٔ نامهای میزبانِ آلوده به بدافزار را در نمونهٔ من شناسایی کرد؛ بنابراین بخش عمدهٔ امتیاز ازدسترفتهٔ آن به آزمونهای فیشینگ مربوط میشد، نه ناتوانی کلی در شناسایی زیرساختهای مخرب. همین تفاوت در اولویتها نشان میدهد که مهاجرت از Cloudflare به Quad9 ممکن است هیچ ارتباطی با سرعت خام نداشته باشد.
نتیجهٔ AdGuard نیز نکتهٔ ظریفی دارد، زیرا حلکنندهٔ عمومی پیشفرض آن تبلیغات و ردیابها را هم پالایش میکند. اگر میخواهید یک سرویس DNS چند کار را همزمان انجام دهد، این ویژگی مزیت به شمار میآید؛ اما در عین حال، مقایسهٔ مستقیم بر پایهٔ اینکه «کدام سرویس موارد بیشتری را مسدود میکند» چندان سودمند نیست. مهمتر این است که بدانید واقعاً میخواهید حلکننده چه چیزهایی را پالایش کند.
محافظت DNS، فارغ از اینکه کدام سرویس را انتخاب کنید، محدودیتهای گریزناپذیری هم دارد. ممکن است دامنهای معتبر میزبان فایلی مخرب برای بارگیری باشد، صفحهای آلوده زیر نام میزبانی قرار گرفته باشد که در حالت عادی قابل اعتماد است، یا پیوست آلودهای وارد صندوق ورودیتان شود؛ در هیچیک از این موارد، انتخاب حلکنندهٔ DNS کمکی نخواهد کرد.
خطایی پیدا کردهاید؟ آن را به نشانی info@www.makeuseof.com بفرستید تا اصلاح شود.
پاسخ پاک DNS، تضمینکنندهٔ پاکبودن سایت نیست
مهمترین نتیجه برای من این نبود که یک حلکننده چند دامنه بیشتر از دیگری مسدود کرده است؛ بلکه دریافتم حلشدن عادی یک نام میزبان، ایمنبودن آن را ثابت نمیکند. ممکن است سه ارائهدهنده دامنهای یکسان را مسدود کنند، اما چهارمی بهدلیل تفاوت در دادههای تهدیدشناسی یا سیاست پالایش خود اجازهٔ دسترسی به آن را بدهد.
DNS پالایششده میتواند پیش از آنکه مرورگر اصلاً به سایت برسد، جلوی یک اتصال مخرب را بگیرد و من نیز دقیقاً به همین دلیل از آن استفاده میکنم. بااینحال، جستوجوی موفق را فقط به معنای نبود هشدار میدانم، نه مدرکی برای قابل اعتماد بودن مقصد.
منبع: این مطلب ترجمه و بومیسازی مقالهای از MakeUseOf به قلم Oluwademilade Afolabi است. مشاهده مقاله اصلی