دسترسی کاربران در برابر امنیت تهاجمی در معماری Anubis

اگر برای محافظت از داده‌های وب‌سایت خود روی یک دیوار آتش متن‌باز حساب کرده‌اید، احتمالاً امنیت شما کمتر از آن چیزی است که تصور می‌کنید. آزمایش‌های فشار (Stress Tests) انجام شده در ۲۲ ژوئن ۲۰۲۶ نشان داد که سامانه Anubis، یک دیوار آتش وب مخصوص هوش مصنوعی، در بسیاری از سناریوهای واقعی، اجازه دسترسی به درخواست‌های خودکار ساده را بدون فعال کردن هیچ‌گونه چالشی می‌دهد. این موضوع یک پرسش اساسی را ایجاد می‌کند: چرا دیواری که برای محافظت از منابع بالادستی در برابر خزنده‌های هوش مصنوعی طراحی شده، مکرراً به ترافیک حاصل از کتابخانه‌های رایج استخراج داده (Scraping) اجازه ورود می‌دهد؟

زمینه و اکوسیستم

دفاع از وب‌سایت‌ها در سطح سازمانی معمولاً در اختیار غول‌هایی مثل Cloudflare، DataDome، Akamai، Kasada، Human Security یا PerimeterX است که هزینه‌های گزافی دارند. در مقابل، Anubis یک لایه‌ی سبک و میزبانی شخصی (Self-hosting) است. این ابزار برای جوامع کوچک‌تر طراحی شده تا با استفاده از چالش‌های محاسباتی برای فیلتر کردن بات‌ها، از منابع خود در برابر حجم عظیم ترافیک خزنده‌های هوش مصنوعی محافظت کنند. هدف Anubis این است که با ارائه چالش‌ها پیش از اجازه دسترسی به منابع بالادستی، از «روح اتصال شما» محافظت کند.

این ابزار اغلب به عنوان یک «گزینه‌ی هسته‌ای» توصیف می‌شود؛ چراکه تنظیمات تهاجمی آن می‌تواند نه تنها بات‌های مخرب، بلکه حتی استخراج‌کننده‌های کوچک‌تر و خزنده‌های مفید، مانند خزنده‌های آرشیو اینترنت (Internet Archive)، را نیز مسدود کند. برخلاف ابزارهای سازمانی، Anubis بر سادگی و میزبانی شخصی تمرکز دارد تا به جوامع کوچک کمک کند تا در برابر سیل ترافیک AI Crawler مقاومت کنند. در همین راستا، ابزارهایی مانند Firecrawl برای تبدیل وب‌سایت‌ها به منابع داده‌ای قابل فهم برای مدل‌ها توسعه یافته‌اند که نحوه تبدیل وب‌سایت‌ها به دیتابیس Markdown را در مدل Hermes به تفصیل بررسی کرده‌ایم.

طبق گزارش منتشر شده در وب‌سایت dev.to، یک پژوهشگر سه هدف زنده شامل source.puri.sm/public، bugs.winehq.org و scioly.org را بررسی کرد. هدف از این آزمایش این بود که مشخص شود آیا ابزارهای استاندارد می‌توانند دفاعات این دیوار آتش را از طریق یک آدرس IP واحد تحریک کنند یا خیر. در این بررسی، عواملی مانند تحلیل سرعت (Velocity Analysis) و امتیازدهی بر اساس اعتبار (Reputation Scoring) مورد سنجش قرار گرفتند.

جزئیات و توالی آزمایش‌ها

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

• آزمایش اول: درخواست‌های ساده (Plain Requests): در این مرحله از کتابخانه Requests پایتون بدون استفاده از مرورگر، بدون جاوا اسکریپت و بدون هدرهای خاص استفاده شد. ۲۰ درخواست متوالی به سایت bugs.winehq.org ارسال گردید. با وجود انتظار برای دریافت خطای ۴۰۳ (Forbidden) یا ۴۲۹ (Too Many Requests)، تمام درخواست‌ها با وضعیت ۲۰۰ OK پاسخ داده شدند.
• آزمایش دوم: ترافیک هم‌زمان (Concurrent Traffic): برای تست اینکه آیا محدودیت‌های نرخ (Rate Limits) پس از رسیدن به یک آستانه خاص فعال می‌شوند یا خیر، پژوهشگر از aiohttp (AsyncIO) برای تولید ۱۰۰ درخواست هم‌زمان استفاده کرد. نتیجه این بود که ۱۰۰ پاسخ موفقیت‌آمیز دریافت شد و هیچ مسدودی رخ نداد. اگرچه برخی درخواست‌ها زمان بیشتری بردند، اما همگی در نهایت با موفقیت کامل شدند.
• آزمایش سوم: سلنیوم (Selenium): پژوهشگر ابزار سلنیوم را اجرا کرد که پیام معروف «Chrome is being controlled by automated test software» را نمایش می‌داد. این پیام سیگنالی است که بسیاری از فروشندگان ضد-بات به‌طور فعال رصد می‌کنند، اما در Anubis، این مورد منجر به دسترسی عادی به صفحه شد و هیچ شکست یا چالشی در مسیر مشاهده نشد.
• آزمایش چهارم: پلی-رایت (Playwright): با استفاده از Playwright برای ایجاد یک محیط مرورگر واقع‌گرایانه‌تر، پژوهشگر مجدداً مشاهده کرد که صفحات با موفقیت بارگذاری می‌شوند و هیچ اقدام اجرایی یا مسدودی از سوی سیستم صورت نمی‌گیرد.
• آزمایش پنجم: Playwright MCP: در آخرین تست با استفاده از Playwright MCP نیز نتیجه موفقیت‌آمیز بود. چالش Anubis با موفقیت تکمیل شد و دسترسی به منابع granted گردید.

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

تحلیل نتایج

این دستاورد لزوماً به معنای خراب بودن نرم‌افزار نیست، بلکه شکاف بین قابلیت‌های ابزار و پیکربندی استقرار (Deployment Configuration) را برجسته می‌کند. پژوهشگر پنج توضیح احتمالی برای این پاسخ‌های ۲۰۰ OK ارائه داد:

۱. پیکربندی محافظه‌کارانه: مدیران سایت‌ها ممکن است دسترسی را در اولویت قرار داده باشند و تنظیمات را تسهیل کرده باشند تا کاربران واقعی مسدود نشوند.
۲. تکمیل موفقیت‌آمیز چالش: ممکن است ابزارهای اتوماسیون توانسته باشند فرآیند چالش را بدون تحریک نظارت‌های اضافی، با موفقیت به پایان برسانند.
۳. آستانه‌های اجرای سخت‌گیرانه: احتمال دارد Anubis برای ارتقای سطح دفاع، به حجم ترافیک بسیار بیشتر، پنجره‌های مشاهده طولانی‌تر یا الگوهای رفتاری متفاوتی نیاز داشته باشد.
۴. شکاف‌های پیکربندی: یک لایه‌ی حفاظتی تنها به اندازه‌ی قوانینی مؤثر است که توسط مدیر سیستم بر روی آن اعمال شده است.
۵. زمینه‌های بهبود: به عنوان یک پروژه متن‌باز، Anubis احتمالاً به بازخوردهای جامعه‌ی کاربران نیاز دارد تا این موارد خاص (Edge Cases) را شناسایی و رفع کند.

برای توسعه‌دهندگان و مدیران سایت‌ها، این نتایج به این معناست که رویکرد «تنظیم کن و فراموش کن» در امنیت متن‌باز ریسک بالایی دارد. اثربخشی Anubis کاملاً به قوانینی وابسته است که مدیر سیستم اعمال می‌کند.

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

گام‌های بعدی در پژوهش

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

• اثرانگشت‌های TLS (TLS fingerprints)
• ناهنجاری‌های هدر (Header anomalies)
• محدودیت‌های دقیق هم‌زمانی (Concurrency limits)
• مقایسه‌ی استخراج داده مبتنی بر درخواست در برابر اتوماسیون مرورگر
• تحلیل رفتاری و اعتبار IP

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

گام بعدی شما

• اگر از Anubis استفاده می‌کنید، قوانین مسدودسازی را با ابزارهای Playwright تست کنید تا نقاط ضعف پیکربندی خود را بیابید.
• برای بررسی اثرانگشت‌های TLS و ناهنجاری‌های هدر (Header)، محیط‌های Sandbox ایزوله بسازید.
• وزن دادن به اعتبار IP را در تنظیمات امنیتی خود بازنگری کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.