آموزش و مقالات شبکه، وب، سرور و اینترنت

آموزش‌های کلادفلر به‌زودی در این بخش قرار داده می‌شود.

برچسب: CDN

  • Oblivious DNS over HTTPS (ODoH)؛ حریم خصوصی بیشتر در DNS

    وقتی شما می‌خواید یه سایتی مثل cloudflare.com رو باز کنید، کامپیوتر شما که آدرس عددی یا همون IP اون سایت رو بلد نیست. پس یه سوال از یه سرور مخصوص به اسم DNS Resolver می‌پرسه. این سوال اینه: «هی، آدرس cloudflare.com چنده؟». اون سرور هم جواب میده و کامپیوتر شما با اون آدرس به سایت وصل میشه.

    حالا مشکل کجاست؟ در حالت عادی و قدیمی، این سوال و جواب‌ها بدون هیچ رمزنگاری و به صورت متن ساده فرستاده میشن. یعنی هر کسی وسط راه شما و اون سرور DNS باشه (مثلا شرکت اینترنتی شما یا همون ISP) می‌تونه ببینه شما دارید آدرس چه سایتی رو می‌پرسید. این یعنی هم می‌فهمن شما کی هستی (چون IP شما رو دارن) و هم می‌فهمن دنبال چه سایتی می‌گردی. این قضیه یه حفره بزرگ حریم خصوصی به حساب میاد.

    برای حل این مشکل، پروتکل‌هایی مثل DNS over HTTPS (DoH) و DNS over TLS (DoT) به وجود اومدن. کار اینا اینه که همون سوال و جواب‌ها رو رمزنگاری می‌کنن. اینجوری دیگه کسی وسط راه نمی‌تونه بفهمه شما چی می‌پرسید. خیلی هم عالیه و الان مرورگرهایی مثل فایرفاکس و سیستم‌عامل iOS ازش پشتیبانی می‌کنن.

    اما هنوز یه مسئله‌ای هست. با اینکه سوال شما رمزنگاری شده، ولی بالاخره به دست اون سرور DNS Resolver (مثلا سرور 1.1.1.1 کلاودفلر) می‌رسه. اون سرور برای اینکه بهتون جواب بده، باید سوال شما رو باز کنه. پس اون سرور هم IP شما رو می‌بینه و هم سوال شما رو. یعنی یه نهاد واحد (همون شرکت صاحب DNS Resolver) هنوز می‌تونه بفهمه که یک IP مشخص، دنبال چه سایت‌هایی بوده. درسته که شرکت‌هایی مثل کلاودفلر سیاست‌های حفظ حریم خصوصی سفت و سختی دارن و میگن این اطلاعات رو نگه نمی‌دارن، ولی بعضی‌ها ترجیح میدن به جای اعتماد به سیاست‌نامه‌ها، یه راهکار فنی داشته باشن که این امکان رو از پایه بگیره.

    ورود ODoH: راهکاری برای جدا کردن سوال از هویت

    اینجاست که Oblivious DNS over HTTPS (ODoH) وارد میدون میشه. ODoH یه استاندارد جدیده که مهندس‌هایی از شرکت‌های کلاودفلر، اپل و فستلی (Cloudflare, Apple, and Fastly) روی اون کار کردن. ایده اصلیش خیلی ساده‌ست: جدا کردن آدرس IP شما از سوالی که می‌پرسید، طوری که هیچ نهاد واحدی نتونه هر دو رو با هم ببینه.

    این پروتکل از اواخر سال ۲۰۲۰ توسط سرویس 1.1.1.1 کلاودفلر پشتیبانی میشه. حتی سرویس iCloud Private Relay اپل هم بر پایه ODoH کار می‌کنه و کلاودفلر یکی از شرکای اون‌هاست.

    ODoH چطوری کار می‌کنه؟

    برای اینکه ODoH کار کنه، دو تا بازیگر جدید بین شما (کلاینت) و اون سرور اصلی DNS (که بهش میگیم Resolver) اضافه میشن: یه پراکسی (Proxy) و یه هدف (Target).

    بذارید نقش هر کدوم رو توضیح بدم:

    1. کلاینت (Client): این همون دستگاه شماست (کامپیوتر، موبایل). قبل از اینکه سوال DNS رو بفرسته، اون رو با استفاده از کلید عمومیِ «هدف» رمزنگاری می‌کنه.
    2. پراکسی (Proxy): کلاینت شما اون بسته رمزنگاری شده رو مستقیم برای سرور DNS نمی‌فرسته. اول می‌فرستدش برای پراکسی. پراکسی مثل یه واسطه عمل می‌کنه. بسته رو از شما می‌گیره و برای «هدف» می‌فرسته. نکته مهم اینه که پراکسی هیچ دیدی به محتوای بسته شما نداره، چون رمزنگاری شده. پس نمی‌تونه سوال شما رو بخونه یا تغییرش بده. پراکسی فقط IP شما رو می‌بینه.
    3. هدف (Target): این همون سروریه که قراره به سوال شما جواب بده. بسته رمزنگاری شده رو از پراکسی تحویل می‌گیره. چون کلید خصوصی رو داره، می‌تونه بسته رو باز کنه و سوال شما رو بخونه. اما نکته مهم اینه که «هدف» دیگه IP اصلی شما رو نمی‌بینه! فقط IP پراکسی رو می‌بینه. بعد از اینکه جواب رو پیدا کرد، جواب رو هم رمزنگاری می‌کنه و پس می‌فرسته برای پراکسی.
    4. بازگشت جواب: پراکسی جواب رمزنگاری شده رو می‌گیره و برای شما می‌فرسته. شما هم با کلیدی که دارید، جواب رو باز می‌کنید.

    پس نتیجه چی میشه؟

    • پراکسی می‌دونه شما (IP شما) یه درخواستی داشتید، ولی نمی‌دونه درخواستتون چی بوده.
    • هدف می‌دونه یه درخواستی برای یه سایت مشخص اومده، ولی نمی‌دونه این درخواست از طرف کی بوده (فقط IP پراکسی رو می‌بینه).

    تا زمانی که پراکسی و هدف با هم تبانی نکنن و اطلاعاتشون رو به هم ندن، هیچ‌کس به تنهایی نمی‌تونه هم به هویت شما (IP) و هم به سوال DNS شما دسترسی داشته باشه. این یعنی حریم خصوصی شما با یه تضمین فنی حفظ میشه.

    نکته جالب اینه که کلاینت‌ها کنترل کامل روی انتخاب پراکسی و هدف دارن. یعنی شما می‌تونید هر پراکسی و هدفی که دوست دارید رو انتخاب کنید و هر وقت خواستید تغییرشون بدید.

    رمزنگاری اضافه و کلیدها از کجا میان؟

    شاید بپرسید مگه DoH خودش رمزنگاری HTTPS/TLS نداشت؟ پس این رمزنگاری اضافه برای چیه؟ سوال خوبیه. ببینید، ما اینجا دو تا اتصال TLS جدا داریم: یکی بین شما و پراکسی، و یکی بین پراکسی و هدف. اگه فقط به همون TLS اکتفا می‌کردیم، پراکسی وقتی بسته رو از شما می‌گرفت و می‌خواست برای هدف بفرسته، محتوای DNS شما براش مشخص میشد.

    برای همین ODoH یه لایه رمزنگاری اضافه از نوع کلید عمومی هیبریدی (Hybrid Public Key Encryption – HPKE) روی خود پیام DNS می‌کشه. این رمزنگاری سرتاسری بین شما و «هدف» انجام میشه و پراکسی رو کاملا دور می‌زنه.

    حالا سوال بعدی: شما کلید عمومیِ «هدف» رو از کجا پیدا می‌کنید؟ این کلید از طریق خود DNS به دست میاد. در یک رکورد خاص به اسم HTTPS resource record قرار می‌گیره و با استفاده از DNSSEC هم امنیتش تضمین میشه که کسی نتونه یه کلید جعلی به شما بده.

    شرکای ODoH چه کسانی هستن؟

    کلاودفلر برای راه‌اندازی این سرویس با چند تا شرکت پیشرو که به حریم خصوصی اهمیت میدن همکاری کرده. چون یکی از اجزای اصلی ODoH، پراکسیه، این شرکت‌ها به عنوان شرکای پراکسی فعالیت می‌کنن. بعضی از این شرکا عبارتند از: PCCW، SURF و Equinix.

    بیانیه‌هایی هم از طرف این شرکت‌ها منتشر شده:

    مایکل گلین از PCCW Global گفته: «ODoH یه مفهوم انقلابی جدیده که برای قرار دادن حریم خصوصی کاربر در مرکز همه چیز طراحی شده… این مدل برای اولین بار پراکسی کلاینت رو به طور کامل از رزولورها جدا می‌کنه».

    جوست ون دایک از SURF گفته: «ما با کلاودفلر برای پیاده‌سازی حریم خصوصی بهتر کاربر از طریق ODoH همکاری می‌کنیم. حرکت به سمت ODoH یک تغییر پارادایم واقعیه، جایی که حریم خصوصی یا آدرس IP کاربر در معرض دید هیچ ارائه‌دهنده‌ای قرار نمی‌گیره و منجر به حریم خصوصی واقعی میشه».

    آیا ODoH سرعت اینترنت رو کم می‌کنه؟

    خب هر وقت یه لایه رمزنگاری و یه واسطه (پراکسی) به یه فرآیندی اضافه میشه، اولین نگرانی بحث سرعته. کلاودفلر و همکارانش اندازه‌گیری‌های زیادی روی این موضوع انجام دادن.

    • هزینه رمزنگاری اضافه: بررسی‌ها نشون داده که خود فرآیند رمزنگاری و رمزگشایی اضافه با HPKE خیلی ناچیزه. برای ۱۰ هزار دامنه مختلف این تست انجام شده و هزینه اضافه در صدک ۹۹ کمتر از ۱ میلی‌ثانیه بوده.
    • تاثیر کلی روی سرعت: برای اینکه تاثیر کلی رو بسنجن، اومدن زمان پاسخ به کوئری‌های DNS رو در سه حالت مقایسه کردن:
    1. DoH معمولی و مستقیم
    2. ODoH (با پراکسی)
    3. DoH روی شبکه Tor (به عنوان یه راهکار دیگه برای حفظ حریم خصوصی)

    نتایج روی یه نمودار توزیع تجمعی نشون داده شد. اگه بخوایم ساده بگیم، نتایج این بود:

    نوع اتصالزمان پاسخ در ۵۰٪ مواقع (میانه)
    DoH معمولیکمتر از ۱۴۶ میلی‌ثانیه
    ODoHکمتر از ۲۲۸ میلی‌ثانیه
    DoH روی Torخیلی بیشتر (در نمودار مشخصه که کندتره)

    این اعداد میگن که در نصف مواقع، استفاده از ODoH باعث یه تاخیر کمتر از ۱۰۰ میلی‌ثانیه نسبت به DoH معمولی میشه. در مقایسه با راهکارهای حفظ حریم خصوصی دیگه مثل Tor، سرعت ODoH خیلی بهتره و زمان پاسخ رو تقریبا نصف می‌کنه. این خیلی نکته مهمیه، چون معمولا بین حریم خصوصی و سرعت یه بده‌بستان وجود داره، ولی اینجا بهبود قابل توجهی دیده میشه.

    یه نکته جالب دیگه توی این اندازه‌گیری‌ها این بود که انتخاب پراکسی و هدف با کمترین تاخیر (latency)، همیشه بهترین نتیجه رو نمیده. حتی در مواردی انتخاب پراکسی با کمترین تاخیر، عملکرد رو بدتر کرده! البته این اندازه‌گیری‌ها بیشتر در آمریکای شمالی انجام شده و باید دید در سطح جهانی عملکرد چطور خواهد بود.

    نظرات و بحث‌های مختلف در مورد ODoH

    مثل هر تکنولوژی جدید دیگه‌ای، در مورد ODoH هم بحث‌ها و نظرات متفاوتی وجود داره. بعضی از کاربرها و متخصص‌ها توی فروم‌ها و شبکه‌های اجتماعی مثل ردیت (Reddit) دیدگاه‌های جالبی مطرح کردن:

    • نگرانی در مورد اعتماد: یه عده میگن که قبلا باید به ISP خودمون اعتماد می‌کردیم، بعد با DoH باید به یه شرکت سوم مثل کلاودفلر یا گوگل اعتماد می‌کردیم، و حالا با ODoH باید هم به کلاودفلر (به عنوان هدف) و هم به یه شرکت پراکسی مثل PCCW یا Equinix اعتماد کنیم که با هم تبانی نمی‌کنن. سوال اصلی اینه که «چه کسی از نگهبانان، نگهبانی می‌کنه؟» و چطور می‌تونیم مطمئن باشیم این شرکت‌ها با هم همکاری نمی‌کنن. یه کاربری گفته: «فکر کنم بیشتر به Quad9 اعتماد دارم تا به کلاودفلر به اضافه یه پراکسی از شرکتی که اسمش رو هم نشنیدم».
    • مشاهده ترافیک توسط ISP: یه دیدگاه خیلی مهم دیگه اینه که حتی اگه شما از ODoH استفاده کنید و سوال DNS شما مخفی بمونه، ISP شما هنوز می‌تونه ببینه که شما به چه آدرس IP وصل میشید. یعنی بعد از اینکه آدرس سایت رو به صورت مخفیانه گرفتید، برای وصل شدن به اون سایت، باید یه درخواست به IP اون بفرستید. این درخواست دیگه مخفی نیست و ISP شما می‌تونه با دیدن IP مقصد بفهمه شما دارید به کدوم سایت سر می‌زنید. پس ODoH جلوی جمع‌آوری اطلاعات توسط وب‌سایت مقصد یا ISP رو به طور کامل نمی‌گیره.
    • راهکار جایگزین: بعضی‌ها معتقدن یه راهکار خصوصی‌تر اینه که کلا شرکت‌های سوم رو حذف کنیم و خودمون یه Recursive Resolver راه‌اندازی کنیم (مثلا با استفاده از نرم‌افزارهایی مثل Unbound یا BIND). اینطوری دیگه اطلاعات DNS ما دست هیچ شرکتی نمیفته.
    • آیا می‌تونم پراکسی خودم رو داشته باشم؟ یه سوال جالب این بود که «آیا می‌تونم پراکسی ODoH خودم رو راه‌اندازی کنم؟». جواب این بود که از نظر فنی بله، ولی اگه فقط شما از اون پراکسی استفاده کنید، هدف اصلی که مخفی شدن بین کلی کاربر دیگه هست از بین میره و باز هم قابل ردیابی میشید.
    • ODoH به عنوان یک استاندارد نوظهور: بعضی کاربرها هم از دیدن گزینه ODoH در تنظیمات روترهای جدید مثل Flint 2 خوشحال و متعجب شدن، چون ODoH هنوز یه استاندارد خیلی جدیده و هنوز به صورت گسترده پیاده‌سازی نشده.

    چطور می‌تونیم ODoH رو امتحان کنیم؟

    کلاودفلر کدهای مربوط به ODoH رو به صورت متن‌باز (Open Source) منتشر کرده. هم پیاده‌سازی سمت سرور و هم سمت کلاینت در زبان‌های برنامه‌نویسی راست (Rust) و گو (Go) موجوده. این یعنی هر کسی می‌تونه خودش یه سرویس ODoH راه‌اندازی کنه یا با کلاینت‌های موجود اون رو تست کنه.

    سرور 1.1.1.1 کلاودفلر هم آماده دریافت کوئری‌های ODoH روی آدرس odoh.cloudflare-dns.com هست.

    حتی می‌تونید با یه دستور ساده مثل dig مشخصات و کلید عمومی سرویس ODoH کلاودفلر رو ببینید:

    dig -t type65 +dnssec @ns1.cloudflare.com odoh.cloudflare-dns.com

    علاوه بر این، ابزارهایی مثل dnscrypt-proxy هم از ODoH پشتیبانی می‌کنن و میشه از اون‌ها برای ارسال کوئری‌های ODoH استفاده کرد.

    جزئیات فنی بیشتر برای کنجکاوها (بر اساس RFC 9230 و مستندات فنی)

    اگه دوست دارید یه کم عمیق‌تر بشیم، بیاید به جزئیات فنی پروتکل نگاهی بندازیم. این بخش بر اساس سند رسمی RFC 9230 که ODoH رو تعریف می‌کنه و مستندات فنی دیگه هست.

    ساختار پروتکل

    • سه بازیگر اصلی: همونطور که گفتیم، سه طرف داریم:
      • Oblivious Client: کلاینتی که کوئری‌ها رو به هدف می‌فرسته، اما از طریق یه پراکسی.
      • Oblivious Proxy: یه سرور HTTP که کوئری‌ها و جواب‌های رمزنگاری شده رو بین کلاینت و هدف رد و بدل می‌کنه.
      • Oblivious Target: یه سرور HTTP که کوئری‌های رمزنگاری شده رو از پراکسی می‌گیره، اون‌ها رو باز می‌کنه و جواب‌های رمزنگاری شده رو برمی‌گردونه.
    • تبادل HTTP:
      • درخواست (Request): کلاینت یه درخواست HTTP POST به آدرس پراکسی می‌فرسته. هدر Content-Type این درخواست باید application/oblivious-dns-message باشه. آدرس هدف هم توی URL درخواست به صورت متغیرهایی به اسم targethost و targetpath قرار می‌گیره.
      • پاسخ (Response): هدف هم جواب رو با همین Content-Type برای پراکسی می‌فرسته و پراکسی هم بدون تغییر اون رو به کلاینت تحویل میده.
    • قالب پیام‌ها:
      • پیام‌های ODoH (هم سوال و هم جواب) یه ساختار مشخص دارن. یه بخش اصلی به اسم dns_message دارن که خود پیام DNS توشه و یه بخش padding که برای سخت‌تر کردن تحلیل ترافیک استفاده میشه.
      • این پیام بعد از رمزنگاری داخل یه ساختار دیگه قرار می‌گیره که شامل message_type (نوع پیام: سوال یا جواب)، key_id (شناسه کلید استفاده شده) و خود encrypted_message (پیام رمزنگاری شده) هست.

    پیکربندی و مدیریت کلیدها در سیستم‌های پیشرفته (مثل BIG-IP)

    شرکت‌هایی مثل F5 که تجهیزات شبکه تولید می‌کنن، امکان پیکربندی ODoH رو روی دستگاه‌هاشون فراهم کردن. مراحل کلی این پیکربندی به این صورته:

    1. ساخت پروفایل HPKE: اول باید یه پروفایل برای رمزنگاری HPKE بسازید و الگوریتم‌های رمزنگاری (KEM, KDF, AEAD) رو مشخص کنید.
    2. ساخت کلید HPKE: بعد یه کلید بر اساس اون پروفایل ساخته میشه. این کلیدها می‌تونن به صورت خودکار در بازه‌های زمانی مشخص (مثلا هر ۳۰ روز) عوض بشن (Rollover).
    3. تعریف هدف ODoH: یه سرور مجازی به عنوان «هدف» تعریف میشه که به درخواست‌های ODoH گوش میده.
    4. پیکربندی Listener و Wide IP: در نهایت Listener ها و رکوردهای DNS مربوطه (مثل SVCB/HTTPS) تنظیم میشن تا کلاینت‌ها بتونن کلید عمومی هدف رو پیدا کنن و درخواست‌هاشون رو بفرستن.

    این سیستم‌ها حتی پیام‌های خطا و لاگ‌های مشخصی برای ODoH دارن. مثلا اگه کلیدها با هم نخونن، خطای HTTP 401 برگردونده میشه یا اگه پیام قابل رمزگشایی نباشه، خطای 400 اتفاق میفته.

    پرسش و پاسخ

    حالا بریم سراغ چند تا سوال که ممکنه براتون پیش اومده باشه.

    سوال ۱: پس ODoH همون DoH هست که فقط یه واسطه (پراکسی) بهش اضافه شده؟

    نه دقیقا. علاوه بر اضافه شدن پراکسی، یه لایه رمزنگاری اضافه هم روی خود پیام DNS کشیده میشه (با استفاده از HPKE). این رمزنگاری اضافه خیلی مهمه، چون باعث میشه خود پراکسی هم نتونه محتوای درخواست شما رو ببینه. اگه این لایه اضافه نبود، پراکسی می‌تونست هم IP شما رو ببینه و هم درخواست شما رو، و کل هدف پروتکل از بین می‌رفت.

    سوال ۲: اگه ISP من هنوز می‌تونه ببینه به چه IP وصل میشم، پس فایده ODoH چیه؟

    این نکته خیلی مهمیه. ODoH از این جلوگیری می‌کنه که یک نهاد واحد (مثل یه شرکت ارائه دهنده DNS) بتونه یه پروفایل کامل از تاریخچه وب‌گردی شما بر اساس درخواست‌های DNS بسازه. درسته که ISP شما هنوز می‌بینه به چه IP هایی وصل میشید، ولی دیگه نمی‌تونه به راحتی و با نگاه کردن به لاگ‌های DNS، لیست تمام سایت‌هایی که شما حتی فقط اسمشون رو چک کردید (ولی شاید بهشون سر نزدید) رو در بیاره. ODoH یه لایه مهم به حریم خصوصی اضافه می‌کنه، ولی یه راهکار کامل برای ناشناس بودن در اینترنت نیست.

    سوال ۳: آیا ODoH کند نیست؟

    طبق اندازه‌گیری‌های اولیه، ODoH یه مقدار کمی تاخیر نسبت به DoH معمولی داره (حدود ۸۰ تا ۱۰۰ میلی‌ثانیه در نصف مواقع). ولی در مقایسه با راهکارهای حفظ حریم خصوصی دیگه مثل استفاده از شبکه Tor برای ارسال کوئری‌های DNS، خیلی سریع‌تره. پس یه بده‌بستان منطقی بین افزایش حریم خصوصی و یه مقدار کاهش سرعت وجود داره.

    سوال ۴: من باید به کی اعتماد کنم؟ به ISP خودم یا به کلاودفلر و یه شرکت پراکسی که نمی‌شناسم؟

    این دقیقا سوال اصلیه. ایده ODoH اینه که شما مجبور نباشید به یک نفر به طور کامل اعتماد کنید. شما دارید اعتمادتون رو بین دو نهاد مجزا (پراکسی و هدف) تقسیم می‌کنید. فرض پروتکل اینه که این دو با هم همکاری و تبانی نمی‌کنن. انتخاب اینکه این مدل برای شما بهتره یا اعتماد به یک نهاد مثل ISP یا حتی راه‌اندازی سرور شخصی، یه تصمیم شخصیه و به سطح نگرانی شما از حریم خصوصی بستگی داره.

    سوال ۵: آیا من می‌تونم همین الان از ODoH استفاده کنم؟

    بله. شما می‌تونید از نرم‌افزارهایی مثل dnscrypt-proxy استفاده کنید که از ODoH پشتیبانی می‌کنن. همچنین اگه از سرویس iCloud Private Relay اپل استفاده می‌کنید، شما در حال حاضر دارید از یه تکنولوژی مبتنی بر ODoH بهره می‌برید. با گذشت زمان، انتظار میره پشتیبانی از این پروتکل در سیستم‌عامل‌ها و مرورگرهای بیشتری به صورت پیش‌فرض فعال بشه.

    منابع

    • [2] Oblivious DNS over HTTPS · Cloudflare 1.1.1.1 docs
    • [4] RFC 9230 – Oblivious DNS over HTTPS
    • [6] Oblivious DNS: Plugging the Internet’s Biggest Privacy Hole – CITP Blog
    • [8] Oblivious DoH : Enhanced DNS Privacy
    • [10] Oblivious HTTP (OHTTP) explained | Mozilla Support
    • [1] Improving DNS Privacy with Oblivious DoH in 1.1.1.1
    • [3] Configuring Oblivious DNS Over HTTP (ODoH) protocol
    • [5] Cloudflare and Apple design a new privacy-friendly DNS protocol – Oblivious DNS-over-HTTPS (ODoH) : r/pihole
    • [7] Oblivious DNS | Proceedings of the 2019 Applied Networking Research Workshop
    • [9] Oblivious DNS (ODoH) – does it work? – Routers / VPN, DNS, Leaks – GL.iNet

  • حملات DDoS چی هستن و هدفشون چیه

    حمله‌های DDoS. شاید اسمش رو شنیده باشید، به خصوص وقتی که سرورهای بازی مورد علاقه‌تون از کار میفته یا یه سایت مهم یهو از دسترس خارج میشه. خیلی‌ها فکر میکنن این یه جور هک پیچیده‌اس که یه نابغه کامپیوتر انجامش میده، اما داستان یه کم فرق میکنه. بیایید با هم قدم به قدم بریم جلو و ببینیم این حمله‌ها دقیقن چی هستن، چطوری کار میکنن و چرا مقابله باهاشون اینقدر سخته.

    فکر کنین یه بزرگراه شلوغ رو در نظر بگیرید که ماشین‌ها دارن به آرامی به سمت مقصدشون میرن. حالا یهو هزاران ماشین الکی و خالی وارد این بزرگراه میشن و کل مسیر رو میبندن. نتیجه چی میشه؟ یه ترافیک وحشتناک که اجازه نمیده ماشین‌های واقعی و مسافرهای اصلی به مقصدشون برسن. حمله DDoS دقیقن همینه، اما توی دنیای اینترنت.

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

    حمله DDoS چطوری اجرا میشه؟ ارتش زامبی‌ها وارد میشود

    برای اینکه بفهمیم این حجم از ترافیک از کجا میاد، باید با چند تا مفهوم کلیدی آشنا بشیم. حمله‌های DDoS با استفاده از شبکه‌ای از کامپیوترها و دستگاه‌های متصل به اینترنت اجرا میشن.

    • بات (Bot) یا زامبی (Zombie): اینها دستگاه‌های معمولی مثل کامپیوتر من و شما، یا حتی دستگاه‌های هوشمند مثل دوربین‌های مداربسته و یخچال‌های هوشمند (همون دستگاه‌های IoT) هستن که به بدافزار آلوده شدن. صاحب این دستگاه‌ها معمولن روحش هم خبر نداره که دستگاهش آلوده شده و داره ازش سوءاستفاده میشه.
    • بات‌نت (Botnet): وقتی یه تعداد زیادی از این بات‌ها یا زامبی‌ها تحت کنترل یک نفر (مهاجم) قرار میگیرن، یه شبکه به اسم «بات‌نت» تشکیل میدن. این بات‌نت مثل یه ارتش از دستگاه‌های آلوده‌اس که منتظر دستور فرمانده‌شون هستن.

    حالا مهاجم چیکار میکنه؟ خیلی ساده. وقتی یه بات‌نت آماده شد، مهاجم میتونه از راه دور به همه این بات‌ها دستور بده. فرض کنید هدف، سرور یه بازی آنلاینه. مهاجم به کل ارتش بات‌نتش دستور میده که همزمان شروع کنن به فرستادن درخواست به آدرس IP اون سرور.

    هر بات یه درخواست میفرسته. حالا تصور کنین صدها هزار یا حتی میلیون‌ها بات همزمان این کار رو بکنن. سرور هدف با سیلی از درخواست‌ها روبرو میشه که نمیتونه به همشون جواب بده. منابعش تموم میشه، پردازنده‌اش درگیر میشه و در نهایت یا خیلی کند میشه یا کاملن از کار میفته. اینجوری، بازیکن‌های واقعی که میخوان وارد بازی بشن، با قطعی سرویس مواجه میشن.

    یکی از بزرگترین چالش‌ها اینه که هر کدوم از این بات‌ها یه دستگاه اینترنتی واقعی و قانونیه. برای همین، تشخیص دادن ترافیک حمله از ترافیک کاربرهای واقعی خیلی سخته. انگار که توی اون مثال ترافیک، همه ماشین‌های الکی، ظاهری شبیه ماشین‌های واقعی داشته باشن.

    از کجا بفهمیم داریم مورد حمله قرار میگیریم؟

    واضح‌ترین نشونه یه حمله DDoS اینه که یه سایت یا سرویس یهویی خیلی کند میشه یا کاملن از دسترس خارج میشه. اما خب، این مشکل میتونه دلایل دیگه‌ای هم داشته باشه، مثلن اینکه یه محصول جدید عرضه شده و یه عالمه کاربر واقعی همزمان هجوم آوردن به سایت. برای همین، برای تشخیص قطعی، باید بیشتر تحقیق کرد.

    ابزارهای تحلیل ترافیک میتونن به ما کمک کنن تا بعضی از علائم کلیدی یه حمله DDoS رو تشخیص بدیم:

    • حجم ترافیک غیرعادی که به سمت یک نقطه یا آدرس IP خاص هدایت شده.
    • یه الگوی ترافیکی عجیب، مثلن ترافیک زیاد از طرف کاربرهایی که پروفایل مشابهی دارن (مثلن همه از یک منطقه جغرافیایی خاص، یا از یک نوع دستگاه خاص هستن).
    • افزایش ناگهانی و شدید ترافیک در ساعت‌های غیرمعمول روز.
    • افزایش عجیب در درخواست‌ها برای یک صفحه یا یک نقطه پایانی خاص.
    • کند شدن غیرعادی عملکرد شبکه برای مدت طولانی.

    البته علائم دیگه‌ای هم وجود داره که بسته به نوع حمله میتونن متفاوت باشن. برای اینکه انواع حمله رو بهتر بفهمیم، اول باید ببینیم یه اتصال اینترنتی چطوری کار میکنه.

    لایه‌های اتصال اینترنتی: ساختمون ۷ طبقه ما

    یه اتصال اینترنتی از چندین لایه مختلف تشکیل شده. مثل ساختن یه خونه که از پی شروع میشه و طبقه به طبقه بالا میره، هر لایه توی شبکه هم یه وظیفه خاص داره. یه مدل مفهومی برای توصیف این لایه‌ها وجود داره به اسم مدل OSI که ۷ تا لایه داره. حمله‌های DDoS میتونن لایه‌های مختلفی از این ساختمون رو هدف قرار بدن.

    حالا که با این مفهوم آشنا شدیم، بریم سراغ سه دسته اصلی حمله‌های DDoS.

    انواع حمله‌های DDoS: سه تفنگدار خرابکار

    تقریبن همه حمله‌های DDoS هدفشون یکیه‌: غرق کردن هدف با ترافیک. اما روش‌هاشون متفاوته. مهاجم‌ها میتونن از یه روش یا ترکیبی از چند روش استفاده کنن.

    ۱. حمله‌های لایه اپلیکیشن (Application Layer Attacks)

    این حمله‌ها که بهشون حمله‌های لایه ۷ هم میگن (چون لایه هفتم مدل OSI رو هدف میگیرن)، مستقیمن سراغ خود اپلیکیشن یا وبسایت میرن. هدفشون اینه که منابع سرور رو تموم کنن.

    چطوری؟ این حمله‌ها لایه‌ای رو هدف میگیرن که توش صفحات وب ساخته میشن و به درخواست‌های HTTP جواب داده میشه. برای یه کاربر، فرستادن یه درخواست HTTP (مثلن باز کردن یه صفحه وب) کار ساده و کم‌هزینه‌ایه. اما برای سرور، جواب دادن به اون درخواست میتونه پرهزینه باشه. سرور باید کلی فایل رو بارگذاری کنه، از دیتابیس اطلاعات بگیره و در نهایت یه صفحه وب کامل رو بسازه.

    حمله HTTP Flood: این یکی از رایج‌ترین حمله‌های لایه ۷ هست. مثل این میمونه که شما و هزاران نفر از دوستاتون روی کامپیوترهای مختلف، دکمه رفرش یه مرورگر رو پشت سر هم فشار بدید. سرور با سیلی از درخواست‌های HTTP مواجه میشه و در نهایت از کار میفته.

    • نسخه‌های ساده: ممکنه مهاجم با یه سری آدرس IP محدود، یه آدرس URL خاص رو هدف قرار بده.
    • نسخه‌های پیچیده: مهاجم از تعداد زیادی آدرس IP استفاده میکنه و آدرس‌های URL تصادفی رو با اطلاعات ارجاع‌دهنده (Referrer) و عامل کاربر (User Agent) تصادفی هدف قرار میده تا شناسایی‌اش سخت‌تر بشه.

    مقابله با حمله‌های لایه ۷ سخته، چون ترافیک حمله خیلی شبیه ترافیک کاربرهای واقعیه. این حمله‌ها میتونن شامل نقض پروتکل HTTP، حملات SQL Injection و Cross-Site Scripting هم باشن.

    ۲. حمله‌های پروتکلی (Protocol Attacks)

    این حمله‌ها که بهشون حمله‌های State-Exhaustion هم میگن، با مصرف بیش از حد منابع سرور یا تجهیزات شبکه مثل فایروال‌ها و لود بالانسرها، باعث قطعی سرویس میشن. این حمله‌ها از ضعف‌های لایه ۳ و ۴ پشته پروتکل استفاده میکنن تا هدف رو غیرقابل دسترس کنن.

    حمله SYN Flood: این یه مثال کلاسیک از حمله پروتکلیه. برای درکش، یه کارگر توی انبار رو تصور کنین که از جلوی فروشگاه سفارش میگیره.

    کارگر سفارش رو میگیره، میره بسته رو پیدا میکنه و منتظر تایید نهایی میمونه تا بسته رو بیاره جلو. حالا تصور کنین این کارگر کلی سفارش دیگه بدون تایید نهایی دریافت میکنه. دست‌هاش پر میشه، گیج میشه و دیگه نمیتونه بسته‌های بیشتری رو حمل کنه و سفارش‌های جدید بی‌پاسخ میمونن.

    این حمله از فرآیندی به اسم دست‌دهی سه‌مرحله‌ای (Three-way Handshake) در پروتکل TCP سوءاستفاده میکنه. وقتی دو تا کامپیوتر میخوان با هم ارتباط برقرار کنن، این فرآیند انجام میشه. مهاجم تعداد زیادی بسته TCP SYN (درخواست اولیه اتصال) با آدرس IP جعلی (Spoofed IP) به سمت هدف میفرسته.

    دستگاه هدف به هر کدوم از این درخواست‌ها جواب میده و منتظر مرحله نهایی دست‌دهی میمونه؛ مرحله‌ای که هیچوقت اتفاق نمیفته. این کار باعث میشه تمام پورت‌های سرور در حالت نیمه‌باز و اشغال‌شده باقی بمونن و منابع سرور تموم بشه. در نتیجه، کاربرهای واقعی نمیتونن به سرور وصل بشن.

    ۳. حمله‌های حجمی (Volumetric Attacks)

    هدف این دسته از حمله‌ها اینه که با مصرف کردن تمام پهنای باند موجود بین هدف و اینترنت، یه ترافیک سنگین ایجاد کنن. مقادیر عظیمی از داده با استفاده از روش‌هایی مثل تقویت (Amplification) یا با کمک یه بات‌نت به سمت هدف ارسال میشه.

    حمله DNS Amplification: این حمله مثل اینه که یه نفر به یه رستوران زنگ بزنه و بگه: «من از همه چی یکی میخوام، لطفن با من تماس بگیرید و کل سفارشم رو تکرار کنید». اما شماره‌ای که برای تماس مجدد میده، شماره تلفن قربانیه! اینجوری با یه تلاش خیلی کم، یه پاسخ خیلی طولانی و حجیم تولید میشه و برای قربانی فرستاده میشه.

    توی این حمله، مهاجم یه درخواست به یه سرور DNS باز (Open DNS Server) با یه آدرس IP جعلی (آدرس IP قربانی) میفرسته. سرور DNS هم یه پاسخ حجیم به اون آدرس IP جعلی (یعنی قربانی) میفرسته. اینجوری، مهاجم با فرستادن یه درخواست کوچیک، باعث میشه یه جواب خیلی بزرگتر به سمت قربانی ارسال بشه و پهنای باندش رو اشغال کنه.

    نگاهی عمیق‌تر به برخی از حملات خاص

    دنیای حملات DDoS خیلی متنوعه و روز به روز هم روش‌های جدیدی به وجود میاد. بیایید چند تا از این روش‌های خاص رو که اسم‌های جالبی هم دارن، با هم مرور کنیم.

    • Smurf Attack (حمله اسمورف): توی این روش، مهاجم بسته‌هایی رو به تعداد زیادی کامپیوتر توی یه شبکه میفرسته، اما آدرس فرستنده رو آدرس IP قربانی جا میزنه. همه اون کامپیوترها به اون بسته جواب میدن، اما جوابشون رو برای قربانی میفرستن. اینجوری قربانی با سیلی از جواب‌ها غرق میشه.
    • حملات Low and Slow (کم و آهسته): این حملات خیلی موذیانه هستن. به جای اینکه یهو حجم زیادی ترافیک بفرستن، ترافیک رو با سرعت خیلی کم ارسال میکنن تا توسط سیستم‌های امنیتی شناسایی نشن. حملاتی مثل Slowloris یا RUDY از این دسته‌ان. Slowloris با باز نگه داشتن تعداد زیادی اتصال HTTP و فرستادن ناقص درخواست‌ها، منابع سرور رو اشغال میکنه.
    • حمله Yo-Yo: این حمله مخصوصن سرویس‌های ابری رو هدف میگیره که از قابلیت مقیاس‌پذیری خودکار (Autoscaling) استفاده میکنن. مهاجم به طور متناوب حجم زیادی ترافیک میفرسته (که باعث میشه سرویس منابعش رو افزایش بده) و بعد ترافیک رو قطع میکنه (که باعث میشه منابع کاهش پیدا کنن). این بالا و پایین رفتن مداوم، میتونه سیستم رو مختل کنه و هزینه‌های زیادی به صاحب سرویس تحمیل کنه.
    • حمله دائمی از کار انداختن سرویس (PDoS – Permanent Denial-of-Service): این یکی از خطرناک‌ترین انواع حمله‌اس و بهش Phlashing هم میگن. هدفش اینه که به سیستم اونقدر آسیب بزنه که نیاز به تعویض یا نصب مجدد سخت‌افزار داشته باشه. مهاجم از آسیب‌پذیری‌های امنیتی دستگاه‌هایی مثل روترها یا پرینترها استفاده میکنه تا فریمور (Firmware) دستگاه رو با یه نسخه خراب یا معیوب جایگزین کنه. این کار دستگاه رو «آجر» یا Brick میکنه و کاملن غیرقابل استفاده میشه.
    • حملات چندوجهی (Multi-vector Attacks): مهاجم‌ها معمولن خیلی باهوش‌تر از این حرف‌ها هستن که فقط از یه روش استفاده کنن. توی یه حمله چندوجهی، از چندین مسیر و روش مختلف به طور همزمان برای حمله استفاده میشه. مثلن ممکنه یه حمله DNS Amplification (لایه ۳/۴) رو با یه حمله HTTP Flood (لایه ۷) ترکیب کنن. این کار تلاش‌های تیم امنیتی برای مقابله با حمله رو خیلی سخت‌تر میکنه، چون باید همزمان با چند جبهه بجنگن.
    • حمله پایدار و پیشرفته (APDoS – Advanced Persistent DoS): این نوع حمله با تهدیدهای پایدار و پیشرفته (APT) مرتبطه و خیلی پیچیده‌اس. این حملات میتونن هفته‌ها طول بکشن (طولانی‌ترین مورد ثبت شده ۳۸ روز بوده!). مهاجم‌ها در این سناریو به منابع محاسباتی و پهنای باند عظیمی دسترسی دارن و به طور تاکتیکی بین اهداف مختلف جابجا میشن تا تیم دفاعی رو گیج کنن، اما در نهایت تمرکزشون روی یه قربانی اصلیه.

    چرا کسی باید حمله DDoS انجام بده؟ انگیزه‌ها

    انگیزه‌های پشت این حملات خیلی متفاوته و میتونه از سرگرمی‌های بچه‌گانه تا جنگ‌های سایبری دولتی رو شامل بشه.

    • هکتیویسم (Hacktivism): بعضی افراد یا گروه‌ها برای بیان اعتراضشون به یه شرکت، سازمان یا دولت، به سرورهاشون حمله میکنن. هدفشون اینه که پیامی رو منتقل کنن یا توجه‌ها رو به یه موضوع خاص جلب کنن.
    • اخاذی و باج‌گیری (Extortion): این یکی از رایج‌ترین انگیزه‌هاست. مهاجم‌ها یه حمله کوچیک انجام میدن و بعد به شرکت قربانی پیام میدن که اگه مبلغی (معمولن به صورت ارز دیجیتال) پرداخت نکنن، با یه حمله خیلی بزرگتر برمیگردن. به این نوع حمله Ransom DDoS (RDoS) هم میگن.
    • رقابت تجاری: بعضی وقت‌ها یه شرکت برای اینکه رقیبش رو از میدون به در کنه، به سرویس‌های آنلاینش حمله میکنه تا در زمان‌های حساس مثل جمعه سیاه، مشتری‌ها نتونن ازش خرید کنن و به سراغ شرکت مهاجم برن.
    • انتقام شخصی: یه کارمند ناراضی یا یه مشتری عصبانی ممکنه برای انتقام گرفتن از یه شرکت، یه حمله DDoS ترتیب بده.
    • جنگ سایبری (Cyber Warfare): دولت‌ها ممکنه از حملات DDoS برای مختل کردن زیرساخت‌های حیاتی یه کشور دیگه (مثل بانک‌ها، سازمان‌های دولتی و…) استفاده کنن. این اتفاق به خصوص در زمان تنش‌های سیاسی، مثل جنگ روسیه و اوکراین، به شدت افزایش پیدا کرد.
    • سرگرمی و خرابکاری: بعضی مهاجم‌ها، به خصوص افراد کم‌سن‌وسال‌تر، صرفن برای تفریح، خودنمایی یا دیدن اینکه میتونن یه سیستم رو از کار بندازن، این کار رو میکنن.
    • پوششی برای حملات دیگه: گاهی اوقات یه حمله DDoS فقط یه ابزار برای پرت کردن حواس تیم امنیتیه. در حالی که همه دارن سعی میکنن جلوی حمله DDoS رو بگیرن، مهاجم اصلی از یه در پشتی وارد میشه و اطلاعات حساس رو میدزده یا بدافزار نصب میکنه.

    تاریخچه و رکوردهای دنیای DDoS: حمله‌هایی که فراموش نمیشن

    حمله‌های DDoS چیز جدیدی نیستن. اولین حمله شناخته‌شده در سال ۱۹۹۶ به Panix، یکی از قدیمی‌ترین ارائه‌دهندگان خدمات اینترنتی، انجام شد و اونها رو برای چند روز از کار انداخت. از اون موقع تا حالا، این حمله‌ها بزرگتر، پیچیده‌تر و پرتعدادتر شدن.

    بیایید چند تا از معروف‌ترین و بزرگترین حمله‌های تاریخ رو با هم مرور کنیم:

    سالهدفحجم/نرخ حملهنکات مهم
    ۲۰۱۳Spamhaus۳۰۰ گیگابیت بر ثانیهیکی از بزرگترین حملات زمان خودش که علیه یک سازمان ضد اسپم انجام شد.
    ۲۰۱۶وبلاگ Krebs و شرکت OVH۶۲۰ گیگابیت و ۱.۱ ترابیت بر ثانیهاولین نمایش قدرت بات‌نت Mirai که از دستگاه‌های IoT آلوده تشکیل شده بود.
    ۲۰۱۶شرکت Dyn (ارائه‌دهنده DNS)۱.۲ ترابیت بر ثانیهبزرگترین حمله بات‌نت Mirai که باعث شد سایت‌های بزرگی مثل توییتر، نتفلیکس و پی‌پال برای ساعاتی از دسترس خارج بشن.
    ۲۰۱۷گوگل۲.۵۴ ترابیت بر ثانیهاین حمله برای مدتی بزرگترین حمله ثبت‌شده در تاریخ بود که گوگل در سال ۲۰۲۰ اون رو فاش کرد.
    ۲۰۱۸GitHub۱.۳۵ ترابیت بر ثانیهیک حمله بزرگ که با استفاده از تکنیک تقویت Memcached انجام شد و نشون داد که دیگه برای حملات بزرگ لزومن به بات‌نت نیازی نیست.
    ۲۰۲۰Amazon Web Services (AWS)۲.۳ ترابیت بر ثانیهیکی از بزرگترین حملات حجمی که با استفاده از تکنیک تقویت CLDAP انجام شد.
    ۲۰۲۱یک مشتری Cloudflare۱۷.۲ میلیون درخواست بر ثانیهاین حمله از نوع لایه اپلیکیشن بود و توسط بات‌نت Mirai انجام شد.
    ۲۰۲۳چندین شرکت بزرگ۷۱ میلیون و ۳۹۸ میلیون درخواست بر ثانیهاین حملات با استفاده از یک آسیب‌پذیری جدید در پروتکل HTTP/2 به نام Rapid Reset انجام شد و رکوردهای حملات لایه اپلیکیشن رو شکست.
    ۲۰۲۴سرورهای غیررسمی Minecraft۳.۱۵ میلیارد بسته بر ثانیهیک حمله حجمی رکوردشکن از نظر تعداد بسته‌ها در ثانیه.

    این آمارها نشون میدن که مقیاس حملات DDoS به طور مداوم در حال افزایشه و مهاجم‌ها همیشه دنبال راه‌های جدیدی برای دور زدن سیستم‌های دفاعی هستن.

    چطوری با DDoS مقابله کنیم؟ استراتژی‌های دفاعی

    مهم‌ترین چالش در مقابله با یه حمله DDoS، جدا کردن ترافیک حمله از ترافیک کاربرهای واقعی هست. اگه یه فروشگاه آنلاین به خاطر عرضه یه محصول جدید کلی مشتری واقعی داشته باشه، قطع کردن کل ترافیک یه اشتباه بزرگه. اما اگه همون فروشگاه با ترافیک زیادی از طرف مهاجم‌های شناخته‌شده روبرو بشه، باید سریع اقدام کنه.

    روش‌های مختلفی برای مقابله با این حملات وجود داره:

    1. Blackhole Routing (مسیریابی به سمت سیاه‌چاله): این ساده‌ترین راهه. وقتی حمله‌ای شناسایی میشه، ارائه‌دهنده سرویس اینترنت (ISP) میتونه کل ترافیک اون آدرس IP رو به یه مسیر پوچ یا «سیاه‌چاله» هدایت کنه. این کار باعث میشه هم ترافیک مخرب و هم ترافیک قانونی دور ریخته بشن. در واقع این روش به مهاجم چیزی رو میده که میخواسته: غیرقابل دسترس کردن سرویس. پس یه راه‌حل ایده‌آل نیست.
    2. Rate Limiting (محدود کردن نرخ درخواست‌ها): این روش تعداد درخواست‌هایی که یه سرور در یه بازه زمانی مشخص قبول میکنه رو محدود میکنه. این کار برای کند کردن ربات‌های وب‌اسکرپر یا حملات brute-force خوبه، اما به تنهایی برای مقابله با یه حمله DDoS پیچیده کافی نیست. با این حال، یه جزء مفید در یه استراتژی دفاعی کامله.
    3. Web Application Firewall (WAF – فایروال اپلیکیشن وب): یه WAF بین اینترنت و سرور اصلی قرار میگیره و مثل یه پروکسی معکوس عمل میکنه. WAF میتونه با فیلتر کردن درخواست‌ها بر اساس یه سری قوانین، جلوی حملات لایه ۷ رو بگیره. یکی از مزیت‌های کلیدی WAF اینه که میشه به سرعت قوانین جدیدی رو در پاسخ به یه حمله در حال وقوع، روی اون پیاده کرد.
    4. Anycast Network Diffusion (پخش کردن ترافیک در شبکه Anycast): این یکی از موثرترین روش‌ها برای مقابله با حملات حجمی بزرگه. توی این روش، ترافیک حمله به جای اینکه به یه نقطه برسه، در سراسر یه شبکه بزرگ از سرورهای توزیع‌شده پخش میشه.

    مثل این میمونه که یه رودخونه خروشان رو به چندین کانال کوچیک‌تر تقسیم کنیم. این کار باعث میشه فشار آب پخش بشه و دیگه قدرت تخریب نداشته باشه.

    این روش، تاثیر ترافیک حمله رو اونقدر پخش و کم میکنه که قابل مدیریت بشه. شرکت‌های بزرگی مثل Cloudflare از این روش استفاده میکنن. برای مثال، شبکه Cloudflare ظرفیتی معادل ۴۰۵ ترابیت بر ثانیه داره که چندین برابر بزرگترین حمله DDoS ثبت‌شده تا به امروزه.

    1. مراکز پاک‌سازی یا Scrubbing Centers: توی این روش، کل ترافیک به سمت یه مرکز تخصصی هدایت میشه. این مرکز ترافیک بد (DDoS) رو از ترافیک خوب (کاربران واقعی) جدا میکنه و فقط ترافیک تمیز رو به سمت سرور قربانی میفرسته.

    هیچ‌کدوم از این روش‌ها به تنهایی کافی نیستن. بهترین رویکرد، یه دفاع لایه‌لایه (Defense in Depth) هست که ترکیبی از راه‌حل‌های ابری و محلی (On-premise) رو برای شناسایی و مسدود کردن انواع مختلف حملات به کار میگیره.

    چطور از اینکه بخشی از مشکل باشیم، جلوگیری کنیم؟

    یادتونه گفتیم حملات DDoS از دستگاه‌های آلوده مردم عادی استفاده میکنن؟ خب، خیلی مهمه که ما خودمون بخشی از این ارتش زامبی نباشیم. برای این کار باید امنیت دستگاه‌های متصل به اینترنتمون رو جدی بگیریم:

    • نصب و به‌روزرسانی آنتی‌ویروس: این اولین و مهم‌ترین قدمه.
    • استفاده از فایروال: فایروال رو فعال و درست تنظیم کنید تا ترافیک ورودی و خروجی رو کنترل کنه.
    • تغییر رمزهای عبور پیش‌فرض: این نکته به خصوص برای دستگاه‌های IoT مثل روتر، دوربین و… خیلی حیاتیه. اکثر این دستگاه‌ها با رمزهای عبور ساده و پیش‌فرض عرضه میشن که هکرها عاشقشونن.
    • رعایت عادات امنیتی خوب: روی لینک‌های مشکوک کلیک نکنید و نرم‌افزارها رو فقط از منابع معتبر دانلود کنید.

    پرسش و پاسخ: سوالات شما در مورد DDoS

    سوال: فرق بین حمله DoS و DDoS چیه؟
    جواب: خیلی ساده‌اس. توی حمله DoS (Denial of Service)، ترافیک مخرب فقط از یک منبع یا یه کامپیوتر میاد. این نوع حمله ساده‌تره و راحت‌تر هم میشه جلوش رو گرفت (کافیه اون یه منبع رو مسدود کنی). اما توی حمله DDoS (Distributed Denial of Service)، ترافیک از صدها، هزاران یا حتی میلیون‌ها منبع مختلف (بات‌نت) میاد. این توزیع‌شده بودن، شناسایی و مسدود کردن حمله رو خیلی خیلی سخت‌تر میکنه.

    سوال: آیا یه فایروال معمولی میتونه جلوی حمله DDoS رو بگیره؟
    جواب: به تنهایی، نه. یه فایروال مثل یه نگهبان دم در عمل میکنه و میتونه جلوی بعضی ویروس‌ها و ترافیک‌های مخرب مشخص رو بگیره. اما فایروال‌ها برای مقابله با حجم عظیم ترافیک حملات DDoS طراحی نشدن و خودشون هم میتونن تحت فشار از کار بیفتن. برای مقابله با DDoS به راه‌حل‌های تخصصی‌تری مثل WAF، مراکز پاک‌سازی و شبکه‌های Anycast نیاز داریم.

    سوال: یه حمله DDoS چقدر طول میکشه؟
    جواب: هیچ قانون مشخصی وجود نداره. یه حمله میتونه از چند ساعت تا چند روز یا حتی چند هفته طول بکشه. بعضی حملات به صورت انفجارهای کوتاه و متناوب هستن و بعضی دیگه به صورت پایدار و طولانی‌مدت ادامه پیدا میکنن.

    سوال: چرا شرکت‌های بزرگی مثل بلیزارد یا گوگل نمیتونن «فقط درستش کنن»؟
    جواب: این یه تصور اشتباه رایجه. حمله DDoS مثل یه باگ یا یه حفره امنیتی نیست که بشه با یه پچ نرم‌افزاری «درستش کرد». این یه مشکل زیرساختیه. فکر کنین یه نفر تصمیم بگیره کل خیابون‌های منتهی به دفتر شرکت شما رو با کامیون مسدود کنه. شما نمیتونید با یه «دکمه» اون کامیون‌ها رو غیب کنید. باید با پلیس و شهرداری هماهنگ کنید تا مسیرها رو باز کنن. مقابله با DDoS هم همینطوره. نیاز به زیرساخت‌های عظیم، قراردادهای گران‌قیمت با شرکت‌های امنیتی و نظارت ۲۴ ساعته داره. این یه جنگ دائمیه، نه یه مشکل که یه بار برای همیشه حل بشه.

    سوال: آیا انجام حمله DDoS غیرقانونیه؟
    جواب: بله، قطعن. در اکثر کشورهای دنیا، از جمله آمریکا و کشورهای اروپایی، انجام حملات DDoS یه جرم فدرال محسوب میشه و مجازات‌های سنگینی مثل زندان و جریمه‌های نقدی بالا داره. حتی استفاده از سرویس‌های «استرس‌تستر» یا «بوتر» برای حمله به دیگران هم غیرقانونیه.

    سوال: آیا DDoS میتونه به عنوان یه شکل از اعتراض قانونی شناخته بشه؟
    جواب: این یه بحث پیچیده‌اس. بعضی‌ها معتقدن که DDoS میتونه یه شکل از نافرمانی مدنی دیجیتال باشه، شبیه تحصن یا تظاهرات. در سال ۲۰۱۳، گروه انانیموس حتی یه دادخواست به کاخ سفید ارائه داد تا DDoS به عنوان یه شکل قانونی از اعتراض شناخته بشه. اما از نظر قانونی، چون این کار به اموال و سرویس‌های دیگران آسیب میزنه و دسترسی کاربرهای قانونی رو مختل میکنه، تقریبن در همه جای دنیا به عنوان یه فعالیت مجرمانه در نظر گرفته میشه.

    منابع

    • [2] What Is a DDoS Attack? | Microsoft Security
    • [4] What Is a DDoS Attack? How It Works, Trends, Types & Mitigation | Radware
    • [6] What Is a DDoS Attack? | Akamai
    • [8] What is a DDoS attack and why can’t Blizzard just “fix it”? : r/wowhardcore
    • [10] Five Most Famous DDoS Attacks and Then Some | A10 Networks
    • [1] What is a distributed denial-of-service (DDoS) attack? | Cloudflare
    • [3] Denial-of-service attack – Wikipedia
    • [5] What is a DDoS Attack? DDoS Meaning, Definition & Types | Fortinet
    • [7] Understanding Denial-of-Service Attacks | CISA
    • [9] What is DDoS Attack? – Types of DDoS Attacks – Check Point Software

  • DNS چیست؟ راهنمای کامل سیستم نام دامنه در اینترنت

    میخوایم در مورد DNS حرف بزنیم. فکر کن اینترنت یه شهر خیلی بزرگه و تو میخوای بری خونه دوستت. آدرس خونه دوستت رو بلدی، مثلا «خیابون آزادی، کوچه شماره ۵، پلاک ۱۰». این میشه اسم دامنه، مثل www.example.com. ولی پستچی برای رسوندن نامه به این آدرس نوشتاری یه چیزی کم داره، اون به یه کد پستی دقیق احتیاج داره، یه سری عدد مثل 192.168.1.1. این عددها همون آدرس‌های IP هستن.

    حالا DNS دقیقا کار همون اداره پستی رو میکنه که آدرس‌های نوشتاری رو به کد پستی‌های عددی تبدیل میکنه. DNS مخفف Domain Name System یا سیستم نام دامنه است. به زبان ساده، دفترچه تلفن کل اینترنته. ما آدم‌ها با اسم‌ها راحت‌تریم، مثل nytimes.com یا espn.com، ولی کامپیوترها و مرورگرها با عددها، یعنی آدرس‌های IP، کار میکنن. DNS میاد این وسط و اسم‌ها رو به عددها ترجمه میکنه تا مرورگر بتونه بفهمه باید به کجا وصل بشه و صفحه مورد نظر ما رو بیاره بالا.

    هر دستگاهی که به اینترنت وصل میشه، از گوشی هوشمندت گرفته تا لپ‌تاپ و سرورهای غول‌پیکر سایت‌های فروشگاهی، یه آدرس IP منحصر به فرد داره. این آدرس برای پیدا کردن اون دستگاه تو شبکه جهانی لازمه. بدون DNS، ما مجبور بودیم یه عالمه عدد مثل 192.168.1.1 (که مربوط به پروتکل IPv4 هست) یا حتی رشته‌های پیچیده‌تر جدید مثل 2400:cb00:2048:1::c629:d7a2 (مربوط به IPv6) رو حفظ کنیم. واقعا کار سختی میشد، نه؟ پس DNS این زحمت رو از دوش ما برداشته.

    وقتی تو آدرس یه سایت رو توی مرورگرت تایپ میکنی، یه فرایندی به اسم «تفکیک DNS» یا DNS resolution اتفاق میفته. این فرایند، اسم میزبان (hostname) مثل www.example.com رو به یه آدرس IP قابل فهم برای کامپیوتر، مثل 192.168.1.1، تبدیل میکنه. کل این ماجرا پشت صحنه اتفاق میفته و تو به عنوان کاربر، به جز وارد کردن آدرس سایت، کار دیگه‌ای انجام نمیدی.

    سفر یک درخواست DNS: از کامپیوتر تو تا قلب اینترنت

    برای اینکه بفهمیم این ترجمه چطوری انجام میشه، باید با بازیگرای اصلی این صحنه آشنا بشیم. چند نوع سرور مختلف دست به دست هم میدن تا این کار انجام بشه. بیا با هم سفر یه درخواست DNS رو مرحله به مرحله دنبال کنیم. فرض میکنیم که هیچ اطلاعاتی از قبل روی کامپیوتر یا توی شبکه ذخیره نشده (کش نشده) تا تمام مراحل رو ببینیم. معمولا این فرایند ۸ مرحله داره:

    1. شروع ماجرا از مرورگر تو: تو آدرس example.com رو توی مرورگرت میزنی و اینتر رو فشار میدی. این درخواست اول از همه به سمت یه سرور خاص به اسم DNS Recursive Resolver میره. این ریزالور معمولا توسط شرکت خدمات اینترنتی تو (ISP) فراهم میشه.
    2. صحبت ریزالور با سرور ریشه (Root Server): ریزالور مثل یه کارآگاه عمل میکنه. اول از همه میره سراغ سرور ریشه یا Root Nameserver. این سرورهای ریشه، پدر بزرگ‌های کل سیستم DNS هستن و بالای هرم قرار دارن. سرور ریشه آدرس کامل example.com رو نمیدونه، ولی میتونه کارآگاه ما رو راهنمایی کنه. بهش میگه: «من نمیدونم example.com کجاست، ولی میدونم سرورهایی که دامنه‌های .com رو مدیریت میکنن کجان. برو از اونا بپرس». و آدرس سرور TLD مربوط به .com رو بهش میده.
    3. مراجعه به سرور دامنه سطح بالا (TLD Server): حالا ریزالور میره سراغ سرور دامنه سطح بالا یا Top-Level Domain (TLD) Nameserver. این سرورها مسئول دامنه‌هایی مثل .com، .org، .net و غیره هستن. ریزالور از سرور .com میپرسه: «آدرس example.com رو داری؟» سرور TLD هم جواب میده: «نه دقیقا، ولی میدونم کدوم سرور مسئول اصلی دامنه‌های example.com هست. این آدرسش، برو از خودش بپرس». این سرور مسئول، همون سرور نام معتبر یا Authoritative Nameserver هست.
    4. رسیدن به منبع اصلی؛ سرور نام معتبر (Authoritative Nameserver): بالاخره ریزالور به آخرین ایستگاه میرسه. سرور نام معتبر، سروریه که تمام اطلاعات و رکوردهای مربوط به دامنه example.com رو توی خودش ذخیره کرده. این سرور دیگه کسی رو پاس نمیده و جواب نهایی رو داره. ریزالور ازش آدرس IP دامنه example.com رو میپرسه و این سرور، آدرس IP دقیق، مثلا 93.184.216.34، رو به ریزالور میده.
    5. بازگشت پاسخ به ریزالور: حالا که ریزالور جواب رو پیدا کرده، یعنی آدرس IP رو به دست آورده، اون رو به کامپیوتر تو برمیگردونه.
    6. تحویل آدرس IP به مرورگر: کامپیوتر تو (به طور دقیق‌تر، سیستم عاملت) این آدرس IP رو از ریزالور میگیره و به مرورگری که درخواست رو شروع کرده بود، تحویل میده.
    7. ارسال درخواست HTTP به سرور سایت: حالا مرورگر دیگه اسم دامنه رو بیخیال شده و آدرس IP رو داره. یه درخواست HTTP مستقیم به اون آدرس IP میفرسته و میگه: «سلام، لطفا محتوای صفحه example.com رو برای من بفرست».
    8. دریافت محتوای سایت: سروری که سایت example.com روی اون قرار داره (و حالا ما با آدرس IP بهش وصلیم)، محتوای صفحه وب رو برای مرورگر تو میفرسته و تو میتونی سایت رو ببینی.

    این هشت مرحله در کسری از ثانیه اتفاق میفته. البته اگه اطلاعات کش شده باشن، خیلی از این مراحل حذف میشن و سرعت کار بالاتر میره که در ادامه در موردش حرف میزنیم.

    بازیگران اصلی صحنه DNS چه کسانی هستن؟

    توی سفر بالا با چند تا اسم آشنا شدیم. بیا یه بار دیگه دقیق‌تر ببینیم هر کدوم چیکار میکنن. چهار نوع سرور اصلی توی این فرایند دخیل هستن:

    • DNS Recursive Resolver (تفکیک کننده بازگشتی): این اولین ایستگاه درخواست توئه. کارش اینه که درخواست رو از کلاینت (کامپیوتر تو) بگیره و مثل یه کارآگاه سمج، اینقدر بگرده تا جواب نهایی (آدرس IP) رو پیدا کنه. این سرور خودش جواب رو نمیدونه، ولی بلده از کی بپرسه. معمولا ISP تو این سرور رو در اختیارت میذاره.
    • Root Nameserver (سرور نام ریشه): این سرورها در راس هرم DNS قرار دارن. کارشون اینه که درخواست‌ها رو به سمت سرور TLD درست هدایت کنن. در کل دنیا ۱۳ گروه سرور ریشه وجود داره که برای پایداری اینترنت حیاتی هستن.
    • TLD Nameserver (سرور نام دامنه سطح بالا): این سرورها مسئول یه بخش خاص از دامنه‌ها هستن. مثلا یه سرور TLD برای همه دامنه‌های .com وجود داره، یکی برای همه دامنه‌های .org و همینطور الی آخر. کار این سرورها اینه که درخواست رو به سمت سرور نام معتبر (Authoritative) دامنه مورد نظر هدایت کنن.
    • Authoritative Nameserver (سرور نام معتبر): این آخرین حلقه زنجیره است. این سرور اطلاعات کامل و نهایی رکوردهای DNS یه دامنه خاص رو داره. وقتی درخواست به اینجا میرسه، جواب قطعی پیدا میشه. این سرور دیگه نیاز نداره از کس دیگه‌ای سوال بپرسه و خودش «منبع حقیقت» برای اون دامنه است.

    یه نکته مهم: گاهی اوقات ما دنبال آدرس یه زیر دامنه هستیم، مثلا blog.cloudflare.com. در این حالت، یه سرور نام دیگه هم به این زنجیره اضافه میشه که بعد از سرور نام معتبر اصلی قرار میگیره و مسئول ذخیره رکوردهای اون زیر دامنه خاص (مثلا رکورد CNAME) هست.

    تفاوت بین سرویس‌های DNS

    شاید اسم‌هایی مثل Google DNS یا OpenDNS به گوشت خورده باشه. این‌ها سرویس‌های DNS Recursive Resolver عمومی هستن. یعنی شرکت‌هایی مثل گوگل یا سیسکو (صاحب OpenDNS) یه سری سرور ریزالور قدرتمند و سریع در سراسر دنیا راه انداختن که هر کسی میتونه ازشون استفاده کنه. مثلا آدرس DNS گوگل 8.8.8.8 هست. تو میتونی تنظیمات شبکه کامپیوترت رو طوری تغییر بدی که به جای استفاده از ریزالور ISP، از این سرویس‌ها استفاده کنی.

    اما این سرویس‌ها با کاری که شرکتی مثل Cloudflare انجام میده، یه فرق اساسی دارن. کلادفلر علاوه بر ارائه ریزالور عمومی، خودش میزبان بخشی از زیرساخت‌های اصلی اینترنت هم هست. مثلا کلادفلر در میزبانی شبکه F-root که یکی از همون سرورهای ریشه اصلی اینترنه، نقش داره. این سرورهای ریشه روزانه میلیاردها درخواست اینترنتی رو مدیریت میکنن.

    انواع درخواست‌ها (Query) در دنیای DNS

    توی فرایند پیدا کردن آدرس IP، سه نوع درخواست مختلف ممکنه رد و بدل بشه:

    1. Recursive Query (درخواست بازگشتی): این همون درخواستیه که کامپیوتر تو به ریزالور میفرسته. معنیش اینه: «لطفا این آدرس رو برام پیدا کن و جواب کامل رو بهم بده. یا بگو همچین آدرسی وجود نداره. خودت همه کارها رو بکن و من منتظر جواب نهایی میمونم».
    2. Iterative Query (درخواست تکراری): این نوع درخواست بین سرورهای DNS رد و بدل میشه. مثلا وقتی ریزالور از سرور ریشه سوال میپرسه، یه درخواست تکراری میفرسته. سرور ریشه با بهترین جوابی که داره (آدرس سرور TLD) پاسخ میده و میگه: «من جواب کامل رو ندارم، ولی برو از این یکی بپرس». ریزالور این فرایند رو اینقدر تکرار میکنه تا به جواب برسه.
    3. Non-Recursive Query (درخواست غیر بازگشتی): این درخواست زمانی اتفاق میفته که سرور DNS جواب رو از قبل توی حافظه خودش (کش) داشته باشه. در این حالت دیگه نیازی به پرس و جو از بقیه سرورها نیست و مستقیم جواب رو میده.

    کش کردن (Caching): راز سرعت بالای DNS

    همونطور که گفتیم، اگه قرار بود برای هر بار باز کردن یه سایت، تمام اون ۸ مرحله طی بشه، سرعت اینترنت خیلی پایین میومد. اینجا مفهومی به اسم کش کردن وارد بازی میشه. کش کردن یعنی ذخیره موقت داده‌ها در یه جای نزدیک‌تر به کاربر تا دفعه بعدی که به اون داده‌ها نیاز بود، سریع‌تر بهشون دسترسی پیدا کنیم. اطلاعات DNS در چند جا میتونن کش بشن:

    • کش مرورگر (Browser Caching): مرورگرهای مدرن، خودشون یه حافظه پنهان برای رکوردهای DNS دارن. وقتی یه آدرس رو وارد میکنی، مرورگر اول کش خودش رو نگاه میکنه. اگه آدرس IP اونجا بود، دیگه هیچ درخواستی به بیرون نمیفرسته و مستقیم به همون IP وصل میشه. این سریع‌ترین حالت ممکنه. مثلا در مرورگر کروم میتونی با رفتن به آدرس chrome://net-internals/#dns وضعیت کش DNS مرورگرت رو ببینی.
    • کش سیستم عامل (Operating System Caching): اگه جواب توی کش مرورگر نبود، درخواست به سیستم عامل (مثلا ویندوز یا مک) میرسه. سیستم عامل هم برای خودش یه کش DNS داره که بهش میگن Stub Resolver یا DNS Client. اونجا رو هم چک میکنه. اگه جواب بود، به مرورگر برمیگردونه.
    • کش ریزالور (Recursive Resolver Caching): اگه توی کامپیوتر تو هم جوابی پیدا نشد، درخواست به سرور Recursive Resolver (همونی که معمولا مال ISP هست) فرستاده میشه. این سرور هم یه کش خیلی بزرگ و قدرتمند داره. وقتی یه بار آدرس example.com رو پیدا میکنه، اون رو توی کش خودش ذخیره میکنه. دفعه بعدی که تو یا هر کس دیگه‌ای که از همون ISP سرویس میگیره، این آدرس رو درخواست کنه، ریزالور جواب رو از کش خودش میده و دیگه نیازی به پرس و جو از سرورهای ریشه و TLD نیست.

    مدت زمان اعتبار کش چقدره؟

    هر رکورد DNS یه مقداری به اسم TTL یا Time-to-Live داره. این مقدار که به ثانیه است، مشخص میکنه که اطلاعات اون رکورد تا چه مدت میتونه توی کش بمونه. مثلا اگه TTL یه رکورد ۳۶۰۰ ثانیه باشه، یعنی بعد از یک ساعت، کش منقضی میشه و دفعه بعدی که اون آدرس درخواست بشه، سرورها باید دوباره کل فرایند پرس و جو رو از اول انجام بدن تا اطلاعات به‌روز رو بگیرن. این TTL توسط مدیر اون دامنه تنظیم میشه.

    نگاهی عمیق‌تر به تاریخچه و ساختار DNS

    ایده استفاده از یه اسم ساده به جای آدرس عددی، به دوران آرپانت (ARPANET)، یعنی جد بزرگ اینترنت امروزی، برمیگرده. اون موقع موسسه تحقیقاتی استنفورد (SRI) یه فایل متنی به اسم HOSTS.TXT داشت که اسم‌ها رو به آدرس‌های عددی کامپیوترهای شبکه نگاشت میکرد. این کار به صورت دستی انجام میشد. یعنی هر وقت یه کامپیوتر جدید به شبکه اضافه میشد، باید با مرکز اطلاعات شبکه (NIC) که توسط الیزابت فینلر مدیریت میشد، تماس میگرفتن تا اسم و آدرسش رو به صورت دستی به این فایل اضافه کنن.

    با بزرگ شدن شبکه در اوایل دهه ۱۹۸۰، مدیریت این فایل متمرکز خیلی کند و سخت شد. اینجا بود که نیاز به یه سیستم خودکار احساس شد. پل موکاپتریس (Paul Mockapetris) در سال ۱۹۸۳ در دانشگاه کالیفرниای جنوبی، سیستم نام دامنه یا DNS رو ابداع کرد. مشخصات اولیه این سیستم در نوامبر ۱۹۸۳ در مستندهایی به اسم RFC 882 و RFC 883 منتشر شد و بعدا در نوامبر ۱۹۸۷ با RFC 1034 و RFC 1035 جایگزین و تکمیل شد. این سیستم از همون ابتدا یعنی سال ۱۹۸۵، یکی از اجزای حیاتی اینترنت بوده.

    اولین پیاده‌سازی سرور نام روی سیستم عامل یونیکس هم توسط چهار تا دانشجو از دانشگاه برکلی در سال ۱۹۸۴ نوشته شد که به BIND (Berkeley Internet Name Domain) معروف شد. BIND هنوز هم یکی از پراستفاده‌ترین نرم‌افزارهای سرور DNS در دنیاست.

    ساختار درختی و سلسله مراتبی DNS

    فضای نام دامنه یه ساختار درختی داره. هر گره یا برگ توی این درخت یه «برچسب» (Label) و صفر یا چند «رکورد منبع» (Resource Record) داره. اسم کامل دامنه از به هم چسبیدن این برچسب‌ها با نقطه به دست میاد.

    • ریشه (Root): بالای این درخت یه ریشه نامرئی وجود داره که با یه نقطه خالی «.» نشون داده میشه.
    • دامنه‌های سطح بالا (TLDs): اولین سطح زیر ریشه، TLD ها هستن مثل com، org، ir و… .
    • دامنه‌های سطح دوم: این‌ها دامنه‌هایی هستن که ما ثبت میکنیم، مثل example در example.com.
    • زیردامنه‌ها (Subdomains): هر چیزی که سمت چپ دامنه سطح دوم بیاد، زیردامنه حساب میشه. مثلا www در www.example.com یه زیردامنه از example.com هست. این ساختار درختی میتونه تا ۱۲۷ سطح عمق داشته باشه.

    قوانین نامگذاری دامنه‌ها:

    • هر برچسب (قسمت بین دو نقطه) میتونه بین ۰ تا ۶۳ کاراکتر داشته باشه.
    • اسم کامل دامنه نباید از ۲۵۳ کاراکتر بیشتر بشه.
    • کاراکترهای مجاز در اسم دامنه‌ها زیرمجموعه‌ای از کاراکترهای ASCII هستن: حروف a تا z (کوچک و بزرگ)، اعداد ۰ تا ۹ و خط تیره (-). به این قانون LDH (Letters, Digits, Hyphen) هم میگن.
    • اسم دامنه‌ها به حروف کوچک و بزرگ حساس نیستن (case-insensitive).
    • برچسب‌ها نمیتونن با خط تیره شروع یا تموم بشن.
    • برای پشتیبانی از زبان‌های دیگه مثل فارسی، سیستمی به اسم IDNA (Internationalizing Domain Names in Applications) به وجود اومد که رشته‌های یونیکد رو با استفاده از الگوریتمی به اسم Punycode به کاراکترهای مجاز DNS تبدیل میکنه.

    انواع رکوردهای DNS

    پایگاه داده DNS انواع مختلفی از رکوردها رو ذخیره میکنه که هر کدوم کاربرد خاص خودشون رو دارن. مهم‌ترین‌هاشون این‌ها هستن:

    نوع رکوردنام کاملکاربرد
    AAddress Recordیه اسم دامنه رو به یه آدرس IPv4 وصل میکنه.
    AAAAIPv6 Address Recordیه اسم دامنه رو به یه آدرس IPv6 وصل میکنه.
    CNAMECanonical Name Recordیه اسم دامنه رو به یه اسم دامنه دیگه ارجاع میده (مثل یه اسم مستعار).
    MXMail Exchange Recordمشخص میکنه کدوم سرور ایمیل مسئول دریافت ایمیل‌های یه دامنه است.
    NSName Server Recordسرورهای نام معتبر (Authoritative) یه دامنه رو مشخص میکنه.
    TXTText Recordاجازه میده یه متن دلخواه رو به دامنه مرتبط کنی. برای کارهای تاییدی و امنیتی زیاد استفاده میشه.
    SOAStart of Authority Recordاطلاعات مهم مدیریتی در مورد یه ناحیه (Zone) DNS رو نگهداری میکنه.
    SRVService Recordاطلاعات مربوط به یه سرویس خاص (مثل پروتکل‌های چت) رو در یه دامنه مشخص میکنه.
    PTRPointer Recordبرعکس رکورد A کار میکنه. یه آدرس IP رو به یه اسم دامنه وصل میکنه. برای Reverse DNS Lookup استفاده میشه.
    CAACertification Authority Authorizationمشخص میکنه کدوم مرکز صدور گواهی (CA) مجازه برای یه دامنه گواهی SSL صادر کنه.

    وقتی توی یه فایل تنظیمات DNS (که بهش Zone File میگن) علامتی مثل @ میبینی، معمولا به معنی خود دامنه اصلی (Origin) هست. مثلا اگه فایل برای mydomain.com باشه، @ همون mydomain.com رو نمایندگی میکنه.

    DNS Propagation یا انتشار DNS چیست؟

    این اصطلاحیه که وقتی تغییراتی توی رکوردهای DNS دامنه خودت میدی، زیاد میشنوی. DNS Propagation به زمانی گفته میشه که طول میکشه تا تغییرات جدیدی که اعمال کردی، در تمام سرورهای DNS در سراسر جهان منتشر و به‌روز بشه.

    در واقع از نظر فنی، DNS «منتشر» نمیشه. چیزی که اتفاق میفته اینه که سرورهای DNS در سراسر دنیا، اطلاعات قدیمی رو تا زمانی که TTL اون‌ها تموم نشده، توی کش خودشون نگه میدارن. پس وقتی تو یه تغییری میدی، باید صبر کنی تا کش سرورهای مختلف در سراسر دنیا منقضی بشه و اطلاعات جدید رو از سرور معتبر تو دریافت کنن. این فرایند میتونه از چند دقیقه تا ۴۸ یا حتی ۷۲ ساعت طول بکشه.

    چرا انتشار DNS اینقدر طول میکشه؟

    • تنظیمات TTL: اگه TTL رکوردهات رو بالا تنظیم کرده باشی (مثلا ۲۴ ساعت)، سرورها تا ۲۴ ساعت اطلاعات قدیمی رو نگه میدارن و تغییراتت دیرتر دیده میشه. یه راه برای سریع‌تر کردن این فرایند اینه که چند روز قبل از اعمال تغییرات مهم، TTL رو به یه مقدار خیلی کم (مثلا ۵ دقیقه) کاهش بدی.
    • کش کردن ISP ها: شرکت‌های اینترنتی (ISP) هم برای افزایش سرعت، نتایج DNS رو به شدت کش میکنن. گاهی اوقات بعضی از ISP ها حتی به TTL تعیین شده توسط تو هم احترام نمیذارن و اطلاعات رو بیشتر از زمان مشخص شده نگه میدارن.
    • ثبت‌کننده دامنه (Registrar): اگه بخوای سرورهای نام (NS) دامنه خودت رو عوض کنی (مثلا وقتی هاستت رو عوض میکنی)، این تغییر باید در سطح سرور TLD (مثلا سرور .com) هم اعمال بشه که این خودش میتونه باعث تاخیر بشه.

    برای چک کردن وضعیت انتشار DNS دامنه خودت، میتونی از ابزارهای آنلاینی مثل whatsmydns.net استفاده کنی. این سایت‌ها از سرورهای مختلفی در سراسر دنیا به دامنه تو درخواست میفرستن و نشون میدن که هر منطقه جغرافیایی، کدوم آدرس IP رو برای دامنه تو میبینه.

    امنیت و حریم خصوصی در DNS

    سیستم DNS در ابتدا بدون در نظر گرفتن مسائل امنیتی طراحی شده بود. چون اینترنت اولیه یه شبکه کوچیک و قابل اعتماد بود. اما با عمومی شدن اینترنت، مشکلات امنیتی هم خودشون رو نشون دادن.

    حملات رایج در DNS

    • DNS Cache Poisoning (مسموم کردن کش DNS): در این حمله، هکر داده‌های جعلی رو به کش یه سرور Recursive Resolver تزریق میکنه. مثلا آدرس IP سایت بانک رو با آدرس IP سرور خودش عوض میکنه. در نتیجه، کاربرانی که از اون ریزالور استفاده میکنن، وقتی آدرس سایت بانک رو وارد میکنن، به یه سایت جعلی هدایت میشن.
    • DNS Hijacking (ربودن DNS): در این حمله، هکر تنظیمات DNS کاربر رو تغییر میده تا درخواست‌های DNS به جای سرورهای معتبر، به سرورهای مخرب تحت کنترل هکر ارسال بشن.
    • DNS Tunneling (تونل‌زنی DNS): این یه تکنیک پیشرفته است که در اون، هکرها از پروتکل DNS برای انتقال داده‌های دیگه (که ربطی به DNS ندارن) استفاده میکنن. چون ترافیک DNS معمولا توسط فایروال‌ها و سیستم‌های امنیتی به عنوان ترافیک مجاز شناخته میشه، هکرها میتونن از این کانال برای فرمان دادن به بدافزارها در یه شبکه داخلی یا خارج کردن اطلاعات حساس (Data Exfiltration) استفاده کنن.


    راهکارهای افزایش امنیت و حریم خصوصی

    برای مقابله با این تهدیدات، راهکارهای مختلفی توسعه داده شده:

    • DNSSEC (Domain Name System Security Extensions): این یه افزونه برای DNS هست که با استفاده از امضای دیجیتال، از صحت و تمامیت داده‌های DNS محافظت میکنه. DNSSEC مطمئن میشه که جوابی که از سرور DNS میگیری، در مسیر دستکاری نشده و واقعا از طرف منبع معتبر ارسال شده.
    • DNS over TLS (DoT): در این روش، ارتباط بین کامپیوتر تو و سرور DNS با استفاده از پروتکل TLS (همون پروتکلی که برای HTTPS استفاده میشه) رمزنگاری میشه. این کار جلوی شنود و دستکاری درخواست‌ها و پاسخ‌های DNS رو میگیره. سرورهای DoT معمولا روی پورت ۸۵۳ کار میکنن.
    • DNS over HTTPS (DoH): این روش هم مثل DoT، ترافیک DNS رو رمزنگاری میکنه، با این تفاوت که درخواست‌های DNS رو در قالب ترافیک HTTPS قرار میده و از پورت ۴۴۳ استفاده میکنه. چون ترافیک HTTPS خیلی رایجه، تشخیص و مسدود کردن ترافیک DoH برای مدیران شبکه سخت‌تره.
    • DNSCrypt: این هم یه پروتکل دیگه برای رمزنگاری ترافیک DNS هست که قبل از DoT و DoH وجود داشت.

    استفاده از این پروتکل‌های رمزنگاری شده، حریم خصوصی تو رو بالا میبره. چون ISP یا هر کسی که در مسیر شبکه تو قرار داره، دیگه نمیتونه ببینه که تو در حال بازدید از چه سایت‌هایی هستی (البته فقط درخواست DNS رو نمیبینن، نه خود ترافیک سایت رو).

    یه نکته جالب: وقتی DNS معنی دیگه‌ای میده!

    حواست باشه که مخفف DNS فقط برای سیستم نام دامنه استفاده نمیشه. در دنیای پزشکی و توانبخشی، DNS مخفف Dynamic Neuromuscular Stabilization یا تثبیت دینامیک عصبی-عضلانی هم هست. این یه رویکرد درمانی و توانبخشیه که بر اساس حرکت‌شناسی تکاملی، یعنی جنبه‌های عصبی و فیزیولوژیکی رشد کودک، بنا شده. هدفش اینه که الگوهای حرکتی بهینه و تکاملی رو در بدن بازسازی کنه تا فشار روی بافت‌ها کم و عملکرد به حداکثر برسه. پس اگه جایی این مخفف رو دیدی، حواست باشه که ممکنه منظورشون اینترنت و دامنه نباشه!

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

    اینجا به چند تا سوال رایج که ممکنه برات پیش اومده باشه جواب میدیم.

    سوال: DNS دقیقا چیه و چیکار میکنه؟ اگه DNS من روی ISP تنظیم شده باشه، یعنی ISP میتونه ببینه من به چه سایت‌هایی میرم؟

    جواب: همونطور که گفتیم، DNS مثل دفترچه تلفن اینترنته و اسم سایت‌ها رو به آدرس عددی (IP) تبدیل میکنه. بله، وقتی از سرور DNS پیش‌فرض ISP خودت استفاده میکنی، اون‌ها میتونن تمام درخواست‌های DNS تو رو ببینن. این یعنی میدونن که تو تلاش کردی به چه دامنه‌هایی دسترسی پیدا کنی.

    سوال: اگه DNS رو به چیزی غیر از ISP تغییر بدم، آیا ISP دیگه نمیتونه فعالیت‌های من رو ببینه؟

    جواب: اگه DNS خودت رو مثلا به Google DNS (8.8.8.8) یا Cloudflare DNS (1.1.1.1) تغییر بدی، ISP تو دیگه نمیتونه لیست درخواست‌های DNS تو رو ببینه. به جای ISP، حالا اون شرکت ارائه‌دهنده DNS (مثلا گوگل یا کلادفلر) میتونه این درخواست‌ها رو ببینه. البته این کار باعث نمیشه کل فعالیت اینترنتی تو از دید ISP مخفی بشه. اون‌ها هنوز هم میتونن ببینن که تو به کدوم آدرس‌های IP متصل میشی، حتی اگه ندونن اون IP ها مال چه دامنه‌ای هستن (البته فهمیدنش کار سختی نیست). برای رمزنگاری کامل ترافیک، باید از سرویس‌هایی مثل VPN استفاده کنی.

    سوال: بهترین DNS برای حفظ حریم خصوصی و ناشناس بودن کدومه؟

    جواب: این سوال جواب قطعی نداره و به تعریف تو از «بهترین» بستگی داره. سرویس‌هایی وجود دارن که تمرکزشون روی حریم خصوصیه و ادعا میکنن که هیچ لاگی از درخواست‌های تو ذخیره نمیکنن. خیلی از این سرویس‌ها از پروتکل‌های رمزنگاری شده مثل DoH و DoT هم پشتیبانی میکنن. موقع انتخاب، باید به سیاست‌های حفظ حریم خصوصی (Privacy Policy) اون سرویس دقت کنی. سرویس‌هایی مثل کلادفلر (1.1.1.1) و Quad9 (9.9.9.9) به عنوان گزینه‌های متمرکز بر حریم خصوصی شناخته میشن.

    سوال: آیا تغییر دادن DNS خطرناکه؟

    جواب: نه، تغییر دادن DNS به خودی خود هیچ خطر ذاتی نداره. فقط باید مطمئن بشی که از یه ارائه‌دهنده DNS معتبر و قابل اعتماد استفاده میکنی. استفاده از یه سرور DNS نامعتبر میتونه تو رو در معرض حملاتی مثل هدایت شدن به سایت‌های مخرب قرار بده.

    سوال: DNS خصوصی (Private DNS) امنیت بیشتری داره؟

    جواب: بله، DNS خصوصی میتونه امنیت بیشتری نسبت به گزینه‌های دیگه ارائه بده. گزینه‌هایی مثل DNS over TLS یا DNS over HTTPS که در تنظیمات گوشی‌های اندرویدی جدید به اسم «Private DNS» وجود دارن، با رمزنگاری کردن درخواست‌های تو، امنیت و حریم خصوصی رو افزایش میدن.

    سوال: سرویس DNS روی گوشی من (مثلا آیفون) حجم زیادی از اینترنت مصرف کرده، چرا؟

    جواب: مصرف بالای داده توسط DNS Services میتونه دلایل مختلفی داشته باشه. ممکنه یکی از اپلیکیشن‌های روی گوشیت در پس‌زمینه به طور مداوم در حال ارسال تعداد زیادی درخواست DNS باشه. این میتونه نشانه فعالیت یه برنامه مخرب، یه برنامه با تنظیمات اشتباه یا حتی یه باگ باشه. بررسی برنامه‌هایی که اخیرا نصب کردی و کنترل دسترسی اون‌ها به اینترنت در پس‌زمینه میتونه کمک‌کننده باشه.

    سوال: چطوری میتونم DNS کامپیوتر خودم رو پیدا کنم؟

    جواب: روی ویندوز، میتونی Command Prompt رو باز کنی، دستور ipconfig /all رو تایپ کنی و اینتر بزنی. در خروجی، جلوی عبارت DNS Servers میتونی آدرس سرور یا سرورهایی که کامپیوترت ازشون استفاده میکنه رو ببینی.

    منابع

    • [2] DNS Propagation Checker – Global DNS Testing Tool
    • [4] domain name system – What’s the meaning of ‘@’ in a DNS zone file? – Server Fault
    • [6] What is DNS Services and why does it use … – Apple Community
    • [8] What Is DNS Tunneling? [+ Examples & Protection Tips] – Palo Alto Networks
    • [10] What is DNS? – Columbus Chiropractor & Rehabilitation Center
    • [1] What is DNS? | How DNS works | Cloudflare
    • [3] Understanding what is DNS : r/dns
    • [5] What is DNS? – Introduction to DNS – AWS
    • [7] Domain Name System – Wikipedia
    • [9] What Is Domain Name System (DNS)? | Fortinet

  • پرداخت در ازای خزش، ایده کلادفلر که برای سایت‌ها درآمد ایجاد می‌کند

    تا حالا شده یک چیزی بسازی، کلی براش زحمت بکشی، بعد یک نفر بیاد خیلی راحت ازش استفاده کنه، باهاش کلی چیز جدید درست کنه و معروف بشه، اما حتی یک تشکر خشک و خالی هم از تو نکنه؟ خب، یه همچین داستانی چند وقتیه که توی دنیای اینترنت برای تولیدکننده‌های محتوا، از نویسنده‌های بزرگ گرفته تا اونایی که یک وبلاگ کوچیک دارن، پیش اومده. بازیگر جدید این داستان، ربات‌های هوش مصنوعیه و به نظر میرسه معامله قدیمی اینترنت دیگه جواب نمیده. حالا یک شرکت بزرگ به اسم کلاودفلر (Cloudflare) با یک ایده جدید وارد میدون شده که میخواد قوانین بازی رو عوض کنه. بیا با هم ببینیم این ماجرا از کجا شروع شد و قراره به کجا برسه.

    معامله قدیمی اینترنت: ترافیک در برابر محتوا

    برای اینکه داستان جدید رو خوب بفهمیم، اول باید برگردیم عقب و ببینیم اینترنت تا قبل از این چطوری کار میکرد. حدود سی سال پیش، دو تا دانشجوی استنفورد یک پروژه تحقیقاتی به اسم «بک‌راب» (Backrub) رو شروع کردن. اون پروژه بعدها تبدیل شد به گوگل و گوگل هم سنگ بنای یک مدل اقتصادی بزرگ رو در اینترنت گذاشت.

    یک جور معامله نانوشته بین گوگل و کسایی که محتوا تولید میکردن (مثل سایت‌های خبری، وبلاگ‌ها، فروشگاه‌ها) شکل گرفت. معامله ساده بود:

    • تولیدکننده‌های محتوا به گوگل میگفتن: «بیا، اجازه داری کل سایت من رو کپی کنی و توی نتایج جستجوت نشون بدی».
    • گوگل هم در جواب میگفت: «باشه، در عوض من هم کاربرا رو از صفحه جستجو میفرستم به سایت تو».

    اینجا بود که بازی برد-برد به نظر میرسید. صاحب سایت از اون بازدیدکننده‌ها یا همون «ترافیک» پول درمیاورد؛ یا با تبلیغات، یا با فروش اشتراک یا هر روش دیگه‌ای. گوگل هم برای اینکه این چرخه کامل بشه، یک اکوسیستم کامل درست کرد:

    • گوگل سرچ (Google Search): ترافیک رو تولید میکرد.
    • گوگل ادسنس (AdSense): ابزاری بود که به صاحب سایت کمک میکرد از اون ترافیک پول دربیاره.
    • گوگل انلیتیکس (Google Analytics): ابزاری بود که میشد باهاش همه چیز رو اندازه گرفت و تحلیل کرد.

    این سیستم دهه‌ها کار کرد و چیزی بود که اینترنت باز و آزاد رو زنده نگه داشته بود. اما حالا، این معامله داره از هم میپاشه. برای اولین بار، سهم گوگل از بازار جستجو داره کم میشه و جاش رو یک پدیده جدید گرفته: هوش مصنوعی.

    بازیگر جدید از راه میرسه: ربات‌های هوشمند و پدیده «صفر کلیک»

    با ظهور چت‌بات‌های هوش مصنوعی مثل چت‌جی‌پی‌تی (ChatGPT) و مدل‌های زبان بزرگ (LLM)، یک سری ربات جدید به اسم «خزنده» یا «کراولر» (Crawler) به اینترنت اضافه شدن. کار این ربات‌ها با ربات‌های جستجوگر قدیمی مثل گوگل فرق داره. اونا فقط سایت‌ها رو کپی نمیکنن که توی نتایج نشون بدن؛ اونا محتوای سایت‌ها رو میبلعن تا «یاد بگیرن» و مغز هوشمند خودشون رو آموزش بدن.

    نتیجه چی میشه؟ شما از هوش مصنوعی یک سوال میپرسی، اون هم با استفاده از اطلاعاتی که از هزاران سایت جمع کرده، یک جواب کامل و حاضر و آماده بهت میده. دیگه نیازی نیست روی لینکی کلیک کنی و به سایت اصلی سر بزنی. به این میگن پدیده «صفر کلیک» (zero-click).

    اینجا بود که اون معامله قدیمی به هم خورد. ربات‌های هوش مصنوعی دارن از محتوای باکیفیت روزنامه‌نگارها، نویسنده‌ها و متخصص‌ها استفاده میکنن، اما تقریبا هیچ بازدیدکننده‌ای به سایت‌های اونا برنمیگردونن. ترافیک سایت‌ها به شدت افت کرده و در نتیجه درآمدشون هم کم شده. در واقع، کار و زحمت اونا داره نسل بعدی هوش مصنوعی رو آموزش میده، بدون اینکه چیزی نصیبشون بشه.

    آمار دروغ نمیگه: یک مبادله ناعادلانه

    برای اینکه ببینی این مبادله چقدر یک‌طرفه شده، به این آمارها که شرکت کلاودفلر منتشر کرده نگاه کن. این آمارها نشون میدن که ربات‌های هوش مصنوعی چند بار یک سایت رو میخونن (خزش یا اسکرِیپ میکنن) و در ازاش چند تا بازدیدکننده به اون سایت میفرستن:

    • ده سال پیش: گوگل به ازای هر بازدیدکننده‌ای که به یک سایت میفرستاد، ۲ صفحه از اون سایت رو میخوند.
    • شش ماه پیش:
      • گوگل: به ازای هر ۱ بازدیدکننده، ۶ بار سایت رو میخوند.
      • اوپن‌ای‌آی (OpenAI): به ازای هر ۱ بازدیدکننده، ۲۵۰ بار سایت رو میخوند.
      • انتروپیک (Anthropic): به ازای هر ۱ بازدیدکننده، ۶ هزار بار سایت رو میخوند.
    • امروز:
      • گوگل: به ازای هر ۱ بازدیدکننده، ۱۸ بار سایت رو میخوند.
      • اوپن‌ای‌آی: به ازای هر ۱ بازدیدکننده، ۱,۵۰۰ بار سایت رو میخوند.
      • انتروپیک: به ازای هر ۱ بازدیدکننده، ۶۰ هزار بار سایت رو میخوند.

    یک گزارش دیگه از تک‌کرانچ (TechCrunch) هم که به داده‌های ماه ژوئن اشاره داره، این اعداد رو تایید میکنه: ربات اوپن‌ای‌آی به ازای هر یک ارجاع، ۱۷۰۰ بار سایت رو خراشیده و ربات انتروپیک ۷۳ هزار بار. روند کاملا مشخصه: هوش مصنوعی میخونه، یاد میگیره و جواب میده، اما خیلی کم پیش میاد که کاربر رو به منبع اصلی بفرسته.

    راه‌حل جدید کلاودفلر: «پرداخت به ازای خزش» (Pay per Crawl)

    کلاودفلر یک شرکت خیلی بزرگه که خدمات شبکه تحویل محتوا یا CDN ارائه میده. اگه بخوایم ساده بگیم، مثل یک دروازه‌بان و سرویس‌دهنده خیلی سریع برای حدود ۲۰ درصد کل وب‌سایت‌های دنیا عمل میکنه. سایت‌های معروفی مثل ردیت، مدیوم، شاپیفای و گاردین از خدمات این شرکت استفاده میکنن. این یعنی وقتی کلاودفلر تصمیمی بگیره، میتونه اون رو در مقیاس خیلی خیلی بزرگی اجرا کنه.

    این شرکت حالا برای حل مشکل بالا، یک راهکار جدید به اسم «پرداخت به ازای خزش» (Pay per Crawl) رو معرفی کرده. ایده اصلی اینه که به جای دو گزینه قدیمی (یا به ربات‌ها اجازه دسترسی رایگان بده یا کلا مسدودشون کن)، یک گزینه سوم روی میز میذاره: ازشون پول بگیر.

    این سیستم که فعلا در نسخه بتای خصوصی قرار داره، به صاحب سایت‌ها این قدرت رو میده که برای محتواشون قیمت تعیین کنن. به این ترتیب، یک رابطه جدید و مبتنی بر اجازه بین ناشرها و شرکت‌های هوش مصنوعی شکل میگیره.

    این سیستم چطوری کار میکنه؟

    ساز و کار فنی این ایده خیلی جالبه و روی زیرساخت‌های فعلی وب ساخته شده:

    • مسدودسازی پیش‌فرض: کلاودفلر اعلام کرده که به زودی، به طور پیش‌فرض جلوی تمام ربات‌های خزنده هوش مصنوعی رو برای سایت‌هایی که از خدماتش استفاده میکنن، میگیره. این یعنی اگه شما یک سایت جدید روی کلاودفلر راه‌اندازی کنی، ربات‌هایی مثل جی‌پی‌تی‌بات (GPTBot) دیگه نمیتونن به محتوای شما دسترسی داشته باشن، مگر اینکه خودت بهشون اجازه بدی.
    • بازار پرداخت به ازای خزش: اینجا جاییه که صاحب سایت میتونه تصمیم بگیره با ربات‌ها چیکار کنه. برای هر ربات هوش مصنوعی، سه تا انتخاب وجود داره:
      • اجازه دادن (Allow): میتونی به ربات اجازه بدی مثل قبل به صورت رایگان به محتوات دسترسی داشته باشه. در این حالت، سرور کد 200 OK رو برمیگردونه.
      • مسدود کردن (Block): میتونی کلا جلوی دسترسی ربات رو بگیری. سرور کد 403 Accessed Denied رو برمیگردونه که یعنی دسترسی ممنوعه.
      • دریافت هزینه (Charge): میتونی برای هر بار خزش یا بازدید ربات، یک قیمت مشخص کنی.
    • استفاده از کد ۴۰۲: وقتی یک ربات هوش مصنوعی میخواد به سایتی دسترسی پیدا کنه که گزینه «دریافت هزینه» رو فعال کرده، سرور سایت یک کد خیلی کم‌استفاده به اسم 402 Payment Required رو به ربات برمیگردونه. این کد به ربات میگه: «برای دیدن این محتوا باید پول پرداخت کنی». همراه این کد، اطلاعات قیمت هم فرستاده میشه.
    • پرداخت و دسترسی: حالا توپ تو زمین شرکت هوش مصنوعیه.
      • اگه ربات با پرداخت موافق باشه، یک درخواست دیگه با اطلاعات پرداخت میفرسته و بعدش محتوا رو با کد 200 OK دریافت میکنه.
      • اگه نخواد پول بده، دیگه دسترسی بهش داده نمیشه.
    • احراز هویت ربات‌ها: برای اینکه ربات‌ها نتونن هویت خودشون رو جعل کنن، کلاودفلر از امضاهای رمزنگاری شده Ed25519 استفاده میکنه. این کار مثل چک کردن کارت شناسایی رباته تا مطمئن بشن خودشه.
    • پرداخت آسان: خود کلاودفلر نقش واسطه مالی رو بازی میکنه. یعنی پول رو از شرکت‌های هوش مصنوعی میگیره و به حساب ناشرها واریز میکنه. اینطوری دیگه نیازی به قراردادهای پیچیده یا ارزهای دیجیتال نیست.

    متیو پرینس، مدیرعامل کلاودفلر، این روز رو «روز استقلال محتوا» (Content Independence Day) نامیده که در تاریخ ۱ ژوییه ۲۰۲۵ معرفی شده.

    کدام ربات‌ها مسدود میشن؟

    کلاودفلر هنوز لیست دقیقی از ربات‌هایی که مسدود میشن ارائه نکرده، اما اونها رو به سه دسته تقسیم کرده:

    • دستیار هوش مصنوعی (AI Assistant): مثل Perplexity-User و DuckAssistBot.
    • خزنده هوش مصنوعی (AI Crawler): مثل ربات گوگل بارد و ChatGPT.
    • جستجوی هوش مصنوعی (AI Search): مثل OAI-SearchBot.

    مدیرعامل کلاودفلر همچنین در شبکه اجتماعی ایکس اعلام کرده که «جمینی (Gemini) به صورت پیش‌فرض مسدود است». احتمالا صاحب سایت‌ها میتونن مشخص کنن که دقیقا کدوم ربات‌ها یا کدوم دسته‌ها رو مسدود یا مجاز کنن.

    طبق آمار خود کلاودفلر، فعال‌ترین ربات‌ها در شبکه این شرکت اینا هستن:

    • بایت‌اسپایدر (Bytespider): ربات شرکت بایت‌دنس (شرکت مادر تیک‌تاک) که از ۴۰.۴ درصد دامنه‌های تحت حفاظت کلاودفلر بازدید میکنه.
    • جی‌پی‌تی‌بات (GPTBot): ربات شرکت اوپن‌ای‌آی با ۳۵.۵ درصد بازدید.
    • کلادبات (ClaudeBot): ربات شرکت انتروپیک با ۱۱.۲ درصد بازدید.

    جالبه که جی‌پی‌تی‌بات، با اینکه از همه معروف‌تره، یکی از ربات‌هایی هست که بیشتر از بقیه در این شبکه مسدود میشه.

    واکنش‌ها به این طرح جدید چه بوده؟

    این ایده جدید کلاودفلر، مثل هر تغییر بزرگی، موافق‌ها و مخالف‌های خودش رو داره. بیا ببینیم هر گروه چی میگه.

    ناشران بزرگ: یک تغییردهنده بازی

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

    • راجر لینچ، مدیرعامل کاند نست (Condé Nast): این حرکت رو یک «تغییردهنده بازی برای ناشران» توصیف کرده که «یک استاندارد جدید برای احترام به محتوا در فضای آنلاین تعیین میکنه. وقتی شرکت‌های هوش مصنوعی دیگه نتونن هر چیزی رو که میخوان به صورت رایگان بردارن، دری به سوی نوآوری پایدار بر اساس اجازه و همکاری باز میشه.»
    • نیل ووگل از دات‌دش مردیت (Dotdash Meredith): میگه: «ما مدت‌هاست که میگیم پلتفرم‌های هوش مصنوعی باید برای استفاده از محتوای ما به ناشران و تولیدکنندگان محتوا غرامت منصفانه‌ای بپردازن. حالا میتونیم دسترسی به محتوامون رو به اون دسته از شرکای هوش مصنوعی محدود کنیم که مایل به مشارکت در ترتیبات منصفانه هستن.»
    • رن توریانو از گنت (Gannett): بر اهمیت این موضوع تاکید میکنه: «مسدود کردن برداشت غیرمجاز و استفاده از محتوای اصلی ما بدون جبران منصفانه، بسیار مهمه… ما خوش‌بینیم که فناوری کلاودفلر به مبارزه با سرقت مالکیت فکری ارزشمند کمک خواهد کرد.»
    • بیل ردی، مدیرعامل پینترست (Pinterest): توضیح میده که چطور این مدل با ماموریت اونها هماهنگه: «ما متعهد به ساختن یک زیرساخت اینترنتی سالم هستیم که در اون محتوا برای هدف مورد نظرش استفاده بشه تا تولیدکنندگان و ناشران بتونن رشد کنن.»

    ناشران بزرگی مثل تایم (TIME)، آتلانتیک (The Atlantic)، ادویک (ADWEEK)، بازفید (BuzzFeed)، فورچن (Fortune)، کورا (Quora) و استک اورفلو (Stack Overflow) هم به این طرح پیوستن.

    کسب‌وکارهای کوچک و وبلاگ‌نویس‌ها: یک شمشیر دو لبه؟

    اما برای کسب‌وکارهای کوچیک و متوسط (SMB) یا وبلاگ‌نویس‌های مستقل، قضیه کمی پیچیده‌تره. اینجا یک سوال مهم پیش میاد:

    آیا محتوای شما اونقدر ارزش داره که یک شرکت هوش مصنوعی حاضر بشه براش پول بده؟

    • برای یک خبرگزاری بزرگ، جواب احتمالا مثبته. مدل‌های هوش مصنوعی برای تولید جواب‌های دقیق به محتوای خبری نیاز دارن.
    • اما برای یک سایت کوچیک چطور؟ آیا هوش مصنوعی واقعا اونقدر به محتوای شما نیاز داره که براش هزینه کنه؟ یا میتونه اطلاعات مشابه یا حتی بهتر رو از منابع دیگه‌ای که رایگان هستن به دست بیاره؟

    این نگرانی وجود داره که این طرح، به جای کمک به کسب‌وکارهای کوچیک، بیشتر به ضررشون تموم بشه. اگه شرکت‌های هوش مصنوعی تصمیم بگیرن که برای محتوای اونها پولی پرداخت نکنن، این سایت‌ها نه تنها پولی دریافت نمیکنن، بلکه اون ذره‌ای از آگاهی از برند (brand awareness) که از طریق حضور در جواب‌های هوش مصنوعی به دست میاوردن رو هم از دست میدن و عملا نامریی میشن.

    منتقدان میگن اینکه به صاحب سایت حق انتخاب داده بشه کار درستیه، اما اینکه مسدودسازی به صورت پیش‌فرض باشه، شاید جواب درستی برای این مشکل نباشه. برای خیلی از سایت‌های کوچیک، حضور نداشتن در دنیای هوش مصنوعی میتونه به اندازه پول نگرفتن برای محتواشون خطرناک باشه.

    شرکت‌های هوش مصنوعی: راهی به سوی نوآوری مسئولانه

    از دید شرکت‌های هوش مصنوعی و تیم‌های تحقیقاتی، این بازار میتونه یک جایگزین شفاف و کم‌دردسر برای بحث‌های حقوقی پیچیده کپی‌رایت باشه. به جای اینکه به صورت بی‌رویه محتوا جمع‌آوری کنن و امیدوار باشن که کارشون تحت عنوان «استفاده منصفانه» (fair use) قانونی تلقی بشه، میتونن با یک هزینه قابل پیش‌بینی، به محتوای باکیفیت دسترسی قانونی پیدا کنن. این کار ریسک حقوقی رو کم میکنه و رابطه بهتری با جامعه تولیدکنندگان محتوا ایجاد میکنه.

    جامعه علمی: یک نگرانی مهم

    بعضی از افراد در جامعه دانشگاهی و تحقیقاتی نگرانن که مسدود کردن خزنده‌ها میتونه به تحقیقات هوش مصنوعی مشروع و غیرتجاری آسیب بزنه.

    این تغییرات چه تاثیری روی آینده جستجو و سئو داره؟

    خب، حالا که با کلیات ماجرا آشنا شدیم، بیا ببینیم این طرح جدید چه تاثیری روی دو مفهوم مهم یعنی سئو و جی‌ای‌او میذاره.

    تاثیر بر سئوی سنتی (SEO)

    اول از همه باید خیال همه رو راحت کنیم: کلاودفلر به صورت پیش‌فرض ربات‌های جستجوگر سنتی مثل گوگل‌بات (Googlebot) یا بینگ‌بات (BingBot) رو مسدود نمیکنه. تمرکز اصلی این طرح روی ربات‌های هوش مصنوعیه.

    با این حال، برای اولین بار، کلاودفلر به ناشران این امکان رو میده که اگه بخوان، حتی جلوی ربات‌های جستجوگر سنتی رو هم بگیرن یا ازشون پول بخوان. آیا ناشران این کار رو میکنن؟ احتمالا نه. مسدود کردن گوگل هنوز به معنی از دست دادن بخش بزرگی از ترافیک ارزشمنده و کمتر کسی حاضر به پرداخت چنین هزینه‌ایه.

    اما یک نکته جالب وجود داره: کلاودفلر داره تلاش میکنه (چه با مذاکره و چه از راه قانونی) گوگل رو متقاعد کنه که ربات خودش یعنی گوگل‌بات رو به دو بخش جدا تقسیم کنه:

    • یک ربات برای جستجوی سنتی.
    • یک ربات برای خزش محتوا جهت استفاده در بخش‌های هوش مصنوعی مثل AI Overviews.

    اگه این اتفاق بیفته، ناشران میتونن به ربات جستجوی سنتی اجازه دسترسی بدن، اما جلوی ربات هوش مصنوعی گوگل رو بگیرن. متخصصان سئو از چنین اتفاقی استقبال میکنن.

    تاثیر عمیق بر جی‌ای‌او (GEO)

    جی‌ای‌او (Generative Engine Optimization) یعنی بهینه‌سازی محتوا برای موتورهای تولیدکننده جواب مثل چت‌جی‌پی‌تی. تاثیر طرح «پرداخت به ازای خزش» روی جی‌ای‌او خیلی عمیق‌تر از سئوی سنتیه.

    برای اینکه این موضوع رو بفهمی، باید بدونی که مدل‌های هوش مصنوعی چطور کار میکنن. دو فرآیند اصلی وجود داره:

    • آموزش مدل (Training data): قبل از اینکه یک مدل بتونه به سوالی جواب بده، باید آموزش ببینه. در این مرحله، ربات‌ها حجم عظیمی از اطلاعات (متن، کد، عکس) رو از سراسر وب جمع‌آوری میکنن تا مدل بتونه زبان رو بفهمه و دانش پایه‌ای خودش رو در مورد دنیا شکل بده. این دانش، مثل فونداسیون یک ساختمونه.
    • بازیابی اطلاعات لحظه‌ای (Real-time information retrieval): بعد از اینکه مدل آموزش دید، میتونه برای جواب دادن به سوالات جدید، اطلاعات تازه رو از طریق ابزارهای خارجی (مثلا جستجو در بینگ) به دست بیاره. این مثل اینه که شما برای جواب دادن به یک سوال، سریع یک چیزی رو در اینترنت جستجو کنی.

    حالا ممکنه فکر کنی: «خب، اگه سایت من بینگ رو مسدود نکنه، پس چت‌جی‌پی‌تی هنوز میتونه محتوای من رو ببینه. پس مشکل چیه؟»

    اینجاست که نکته کلیدی مشخص میشه:
    آموزش، درک بنیادی مدل رو میسازه؛ جستجوی لحظه‌ای فقط اون درک رو تکمیل میکنه، نه اینکه جایگزینش بشه.

    وقتی سایت‌های بیشتری به طرح «پرداخت به ازای خزش» ملحق بشن و دسترسی ربات‌های هوش مصنوعی رو محدود کنن، سه اتفاق مهم میفته:

    • کاهش کیفیت جواب‌ها: حتی اگه هوش مصنوعی بتونه سایت تو رو از طریق بینگ ببینه، اگه در مرحله آموزش با محتوای مشابهی برخورد نکرده باشه، نمیدونه چطور اون رو تفسیر کنه یا بهش اولویت بده.
    • سوگیری به سمت منابع شناخته‌شده: مدل‌ها به منابعی که در زمان آموزش دیدن «اعتماد» بیشتری دارن. اگه محتوای تو بخشی از اون فرآیند آموزشی نبوده باشه، ممکنه در جواب‌های تولید شده نادیده گرفته بشی، فقط به این دلیل که مدل با سبک، فرمت یا اعتبار سایت تو آشنا نیست.
    • تاثیر بلندمدت بر جی‌ای‌او: هرچقدر سایت‌های بیشتری دسترسی ربات‌ها رو محدود کنن، داده‌های آموزشی کلی مدل‌ها کوچیک‌تر و محدودتر میشه. سایتی که در مرحله آموزش دیده نشده، وارد «نقشه ذهنی» مدل نمیشه، حتی اگه از نظر فنی در جستجوی لحظه‌ای قابل دسترسی باشه.

    خلاصه اینکه جی‌ای‌او فقط مربوط به دیده شدن نیست؛ مربوط به اینه که مدل هوش مصنوعی تو رو بشناسه، بهت اعتماد داشته باشه و درکت کنه. و همه اینها از مرحله آموزش شروع میشه.

    پرسش و پاسخ

    سوال: پس این طرح کلاودفلر یعنی دیگه نمیتونم از گوگل استفاده کنم؟

    جواب: نه اصلا. این طرح ربطی به استفاده شما از موتورهای جستجوی سنتی مثل گوگل یا بینگ نداره. ربات‌های این موتورهای جستجو به صورت پیش‌فرض مسدود نمیشن و شما مثل قبل میتونی ازشون استفاده کنی. این طرح بیشتر روی ربات‌هایی تمرکز داره که برای آموزش مدل‌های هوش مصنوعی مثل چت‌جی‌پی‌تی محتوا جمع میکنن.

    سوال: آیا این سیستم «پرداخت به ازای خزش» همین الان برای همه فعاله؟

    جواب: در حال حاضر، این برنامه در نسخه بتای خصوصی قرار داره. این یعنی هنوز برای همه در دسترس نیست و سایت‌ها باید برای شرکت در اون درخواست بدن (opt-in). اما برنامه کلاودفلر اینه که در آینده‌ای نامشخص، مسدودسازی ربات‌های هوش مصنوعی رو به صورت پیش‌فرض برای همه اجرا کنه.

    سوال: من یک وبلاگ کوچیک دارم. باید نگران باشم؟

    جواب: این موضوع بستگی به اهداف شما داره. از یک طرف، این طرح به شما قدرت کنترل روی محتواتون رو میده. از طرف دیگه، این ریسک وجود داره که شرکت‌های بزرگ هوش مصنوعی حاضر نشن برای محتوای شما پولی پرداخت کنن و در نتیجه، شما از دنیای جواب‌های هوش مصنوعی حذف بشی. این یک تصمیم استراتژیکه که هر صاحب سایتی باید برای خودش بگیره.

    سوال: این پرداخت‌ها چطوری انجام میشه؟ آیا پیچیده است؟

    جواب: طبق گفته کلاودفلر، خود این شرکت به عنوان واسطه عمل میکنه. یعنی پرداخت‌ها رو از شرکت‌های هوش مصنوعی جمع‌آوری و به حساب صاحبان سایت‌ها واریز میکنه. این کار باعث میشه نیازی به قراردادهای پیچیده یا استفاده از ارزهای دیجیتال نباشه و فرآیند ساده باشه.

    سوال: از کجا معلوم که یک ربات هویت خودش رو جعل نکنه و الکی بگه من ربات گوگل هستم؟

    جواب: کلاودفلر برای جلوگیری از این مشکل از سیستم‌های پیشرفته مدیریت ربات و امضاهای رمزنگاری شده به اسم Ed25519 استفاده میکنه. این فناوری‌ها کمک میکنن هویت ربات‌ها به طور دقیق تایید بشه تا جلوی جعل و تقلب گرفته بشه.

    “`

    منابع

    • [2] Cloudflare’s innovative “pay per crawl” lets publishers charge AI crawlers for content
    • [4] Just a moment…
    • [6] How Cloudflare’s Pay-Per-Crawl Marketplace Protects Publishers
    • [8] Cloudflare’s Pay Per Crawl: A turning point for SEO and GEO
    • [1] Publishers Push Back Against AI Data Scraping as Cloudflare Introduces ‘Pay per Crawl’ | Music AI
    • [3] Introducing pay per crawl: Enabling content owners to charge AI crawlers for access – Piccalilli
    • [5] The Future of Content and AI: Pay per Crawl and What’s Next – Cloudflare TV
    • [7] Legal News, Updates & Analysis | Advocate Daily
    • [9] Cloudflare’s Decision to Block AI Crawlers Could Affect Your Performance in LLMs | JumpFly Digital Marketing Blog