Anubis AI Scraper Firewall: Зупиніть ботів, захистіть свій веб-сайт, зменшіть витрати на хостинг

Чому менші публічні сайти зараз звертають увагу на Anubis

Якщо ви керуєте публічним сайтом документації, блогом, форумом або невеликою веб-програмою, проблема не завжди приходить з драматичним простоєм. Частіше вона з’являється як постійний потік автоматизованого трафіку, схожого на браузерний. Ці запити постійно витягують контент і змушують ваш origin виконувати роботу для відвідувачів, які насправді не є відвідувачами. Сайт може залишатися в мережі, але CPU час витрачається, ефективність кешу падає, а запити до origin зростають для неправильної аудиторії. З часом терпіння операторів закінчується разом з ними.

Такий тиск має значення для різних читачів з різних причин.

• Розробники відчувають його як марну роботу backend.
• Самостійні хостери відчувають його як втрату контролю над публічним входом.
• Бізнес і оператори сайтів відчувають його як вищі витрати на хостинг, менш стабільну продуктивність і гіршу якість роботи для справжніх відвідувачів, коли фоновий шум зростає.

Ключова зміна проста: тиск скрейпінгу більше не є проблемою лише для компаній гіпермасштабу. Менші публічні сайти також можуть його відчути.

Тому Anubis став цікавим. Це зосереджений фронтальний шар для людей, які хочуть зробити зловживаючий доступ дорожчим, не претендуючи на те, що вони купують повноцінну платформу безпеки. Ця стаття — обґрунтоване пояснення. Вона охоплює те, що таке Anubis, як він працює, яку цінність він пропонує, і коли він підходить.

Швидкі ключові терміни перед початком

Вам не потрібна велика лексика, щоб слідувати решті цієї статті, але кілька термінів допомагають зберегти пояснення чистим. Мета тут не в тому, щоб побудувати гігантський словник безпеки. Це для того, щоб переконатися, що пізніші розділи не здаються складнішими, ніж вони є насправді.

Що насправді являє собою Anubis — і чим він не є

Anubis — це відкритий вихідний код AI скребка-брандмауер. Точніше кажучи, це зворотний проксі проти скребків, який розташовується перед веб-сайтом або веб-додатком. Він вирішує, чи повинен вхідний трафік пройти, бути перевіреним або заблокованим до того, як джерело виконає дорогу роботу. З точки зору стека розташування просте:

visitor -> Anubis -> origin site/app

Саме це розташування — вся суть. Anubis захищає вищестоящі ресурси, розташовуючи рівень прийняття рішень на передньому вході.

Найпростіший спосіб розібратися в його ролі — порівняти його з рівнями, які люди найчастіше плутають з ним. Таблиця нижче — це практична версія питання Anubis vs WAF.

Ось чому це особливо актуально для операторів, які контролюють свій власний стек. Якщо ви запускаєте публічні робочі навантаження на VPS або виділеному сервері за власним зворотним проксі, Anubis легко розташувати подумки:

• він стає ще однією контрольною точкою, контрольованою оператором, перед джерелом.
• Він природно підходить для людей, які хочуть мати більше впливу на поведінку маршруту та трафік, подібний до браузера.
• Він також підходить для операторів, які хочуть керувати надійними винятками самостійно замість того, щоб передавати всю проблему керованому продукту на краю.

📝 Примітка: Anubis — це не класичний WAF, не CDN і не повна служба DDoS. Це сфокусована контрольна точка зворотного проксі, призначена для захисту вищестоящих ресурсів від тиску скребків.

Не менш важливо, що багатьом сайтам він взагалі не потрібен. Це речення повинно залишатися прямим, тому що це правда. Anubis корисний, коли тиск скребків реальний і оператор хоче сфокусований рівень на передньому вході. Це не те, що кожен публічний веб-сайт повинен встановити просто тому, що назва містить слово “брандмауер”.

Як працює Anubis, крок за кроком

На найпростішому рівні Anubis діє як передні ворота з пунктом збору мита. Запит приходить, Anubis отримує першу можливість, а джерело чекає позаду. Якщо запит виглядає добре за активною політикою, він може рухатися далі. Якщо він відповідає суворішому шляху, він може бути перевірений перед тим, як реальний сайт або додаток виконає більше роботи.

Потік запитів виглядає так:

visitor request
    ↓
Anubis
    ├─ allow straight through
    ├─ deny
    └─ challenge when policy says so
            ↓
   client solves proof of work
            ↓
   Anubis verifies cheaply
            ↓
temporary signed badge cookie
            ↓
     origin site/app

Важливою деталлю є те, що Anubis керується політикою. Вхідні запити перевіряються за правилами, які можуть ALLOW, DENY, CHALLENGE або WEIGH їх. Простою мовою, ворота можуть щось пропустити, відхилити, потребувати додаткових зусиль або збільшити його оцінку підозри перед остаточним рішенням. Це також причина, чому вводить в оману представляти Anubis як «перевіряти кожен запит назавжди». Невідповідний трафік може бути пропущений, тоді як трафік, схожий на браузер, або трафік з вищою підозрою можна обробляти більш агресивно.

📝 Примітка: Anubis — це не одна велика жорстко закодована сторінка перевірки. Він слідує правилам політики, і не кожен запит потрібно перевіряти, щоб інструмент виконував свою роботу.

Коли використовується перевірка, основна ідея — доказ роботи. Думайте про це як про невелике мито. Клієнт повинен виконати скромну кількість обчислень перед тим, як пройти, тоді як Anubis повинен лише дешево перевірити результат. Для одного звичайного відвідувача ця додаткова робота зазвичай становить лише невелику незручність. Для скребка, який намагається повторити процес на великих обсягах трафіку, економіка починає змінюватися. Мета не в тому, щоб зробити скребання математично неможливим. Мета — припинити робити це дешевим і безтертьовим.

Як тільки відвідувач пройде, Anubis може видати підписаний пропускний файл cookie. Найпростіший спосіб уявити цей файл cookie — як тимчасовий значок відвідувача. Відвідувач уже пройшов ворота, тому йому не потрібно платити мито знову на кожному завантаженні сторінки. Це зменшує повторну тертя для законного перегляду, одночасно утримуючи контрольно-пропускний пункт перед джерелом. Значок тимчасовий навмисне: він допомагає системі пам’ятати, що клієнт нещодавно пройшов, без перетворення одного успіху на постійну довіру.

Сучасні політики Anubis також можуть бути більш нюансованими, ніж плоский розподіл пропуску або перевірки. Зважування запитів дозволяє правилам додавати або видаляти підозру, щоб різні пороги могли запустити легше або сильніше обробку. Довірені винятки, безпечні шляхи та відома автоматизація можуть обробляються інакше від загального трафіку, схожого на браузер. Деякі розгортання також повторно перевіряють трафік час від часу замість припущення, що більш ранній пропуск повинен тривати вічно. Цей шар налаштування важливий, але основна ментальна модель все ще залишається тими ж передніми воротами плюс пункт збору мита.

Останній нюанс варто мати на увазі: проходження перевірки не доводить, що відвідувач є людиною. Це доводить, що клієнт пройшов налаштовані ворота. Деякі розгортання також можуть використовувати режими перевірки без JavaScript, але основна історія Anubis все ще залишається доказом роботи плюс тимчасовий пропуск. Як тільки ви це побачите таким чином, практична цінність стає набагато легше оцінити.

Що Anubis може зробити для вас на практиці

Практична цінність Anubis полягає не в магічній класифікації ботів. Це зміна витрат. Якщо великомасштабний скрейпінг повинен виконувати більше роботи на воротах, ваше походження робить менше непотрібної роботи позаду. Це може означати менше марних запитів до походження та менше безглуздої обробки на бекенді. Це також може залишити більше місця для реальних відвідувачів, коли зловмисний трафік починає тиснути на сайт.

Це найбільше важливо на веб-сайтах та додатках, де вміст є публічним і легко піддається повторному цілеванню.

• Портали документації
• блоги, форуми
• панелі керування
• самостійно розміщені веб-інструменти
• невеликі фронтенди SaaS
• інтерфейси коду або веб

Динамічні сторінки та ресурси бекенду отримують особливу користь, оскільки вони часто коштують більше для обслуговування, ніж статичний ресурс. Навіть коли сайт не “впав”, зменшення непотрібної роботи на передній двері може захистити чутливість там, де користувачі це відчувають.

Інший спосіб сформулювати користь – це простір для дихання. Цей простір для дихання проявляється конкретними способами: менше непотрібних пробуджень додатків, менше турбулентності кешу та менше моментів, коли законні користувачі відчувають уповільнення, хоча технічно нічого не зламано. Anubis не робить сервер швидшим сам по собі; він зменшує, як часто низькоцінний трафік отримує повний хід на бекенді.

Існує також перевага контролю. За допомогою Anubis оператор може формувати поведінку замість того, щоб ставитися до кожного запиту однаково.

• Деякі маршрути можуть бути легко доступні.
• Деякі надійні боти або шляхи автоматизації можуть бути внесені до списку дозволів.
• Деякий трафік, подібний до браузера, можна викликати більш агресивно.

Це справжня операційна перемога: не містична здатність знати, хто хороший або поганий, а практичний набір рішень щодо обробки трафіку, які відповідають тому, як сайт повинен використовуватися.

Для читачів, які вже уявляють це в термінах хостингу, розміщення є простим. Якщо ви запускаєте публічні сервіси за Nginx або Caddy на VPS або виділеному сервері AlexHost, це зазвичай означає розміщення Anubis перед шляхом додатка, яким ви вже керуєте, щоб загальний веб-трафік фільтрувався до того, як він пробудить бекенд. Решта стека залишається незмінною; різниця полягає в тому, що ваше походження більше не обробляє кожен запит однаково.

Обмеження та компроміси, які вам потрібно знати

Найшвидший спосіб неправильно зрозуміти Anubis — прочитати “firewall” і припустити повний захист. Інструмент має вужчу роль. Він не виправляє вразливий код і не закриває відкриті сервіси. Він не поглинає насичену вхідну лінію і не замінює WAF, CDN або DDoS сервіс. Якщо ваша основна проблема знаходиться на одному з цих рівнів, Anubis — це не те, що її вирішує.

Він також не змушує цілеспрямовану автоматизацію зникнути. Розширені браузери без інтерфейсу можуть запускати JavaScript. Вони також можуть зберігати cookies, повторювати запити та виконувати роботу. Умова успіху просто інша: скрейпінг стає дорожчим, менш зручним і менш м’яким для сторони зловмисника, ніж раніше.

⚠️ Попередження: Доступ без JS — це зона компромісу. Поточна документація Anubis включає опцію без JS metarefresh, але вона не є стандартним шляхом і вона менш дискримінуюча, тому її слід розглядати як компроміс сумісності, а не як основну історію захисту.

Цей компроміс важливий, тому що деякі законні відвідувачі використовують посилені налаштування приватності або навмисно обмежені браузери. Шлях виклику на основі JavaScript може розчарувати їх навіть коли вони нічого зловмисного не роблять. Опція без JS допомагає в деяких випадках. Але вона також послаблює історію дискримінації, тому що сучасні скрейпери вже можуть діяти як справжні браузери. Іншими словами, доступність і тертя потрібно оцінювати чесно, а не замахуватися на них.

Виявлення та автоматизація створюють другий компроміс:

• Пошукові системи та архівні боти можуть потребувати внесення в білий список.
• Канали, моніторинг та інша законна автоматизація можуть потребувати більш ретельної обробки політики.

Якщо ви будете неуважні, ви можете зробити ваш сайт складнішим для індексування або архівування. Ви також можете зробити його складнішим для інтеграції з інструментами, які насправді корисні. Це не робить Anubis поганим інструментом. Це означає, що оператор повинен вирішити, який трафік заслуговує легкого шляху, а який — складнішого.

І іноді найчистіша відповідь — пропустити його. Сайт хобі з низькою експозицією або внутрішній сервіс можуть отримати більше тертя, ніж користі від додавання Anubis. Те саме може бути правдою для команди, яка вже задоволена керованою платформою на краю. Це також застосовується, коли справжня проблема — небезпечний код додатку або насичена вхідна пропускна здатність. Якщо проблема знаходиться в іншому місці, додавання шлюзу скрейпера просто створює додаткову складність навколо неправильного вузька.

Коли Anubis має сенс — і коли це надмірно

Anubis має найбільше сенсу, коли одночасно виконуються три умови:

1. 🌍🔓 сервіс є публічним
2. 🤖⚠️ тиск скрейперів достатньо реальний, щоб бути операційно дратівливим
3. 🔄🖥️ оператор хоче контролювати рівень зворотного проксі на передній лінії

Публічна документація, форуми, блоги, самостійно розміщені додатки та невеликі SaaS поверхні — сильні приклади. Вони відкривають контент публічно, але все ще залежать від ресурсів походження, які варто захищати.

Рішення стає легшим, коли ви зводите його до кількох типових ситуацій:

Найкращий варіант також передбачає готовність оператора. Anubis концептуально простий, але він все ще додає володіння політикою на рівні проксі. Хтось повинен вирішити, що повинно пройти легко, а що повинно бути оскаржено. Вони також повинні вирішити, які боти або канали варто винятку, і скільки тертя аудиторія витримає. Якщо ніхто в команді не хоче приймати ці рішення, технічно релевантний рівень все ще може стати операційним беспорядком.

Середня категорія важлива, тому що багато реальних середовищ за своєю природою мають шари. Якщо тиск скрейперів — лише одна частина картини, Anubis все ще може заслужити місце, але йому потрібна лише одна робота: відсіяти дорогий трафік, подібний до браузера, перш ніж він досягне додатку. Інші контролі все ще виконують свої завдання — безпечне кодування, фільтрування, що розуміє додатки, розподіл трафіку та захист у масштабі мережі.

💡 Порада:Простіший тест такий: якщо трафік скрейперів не створює вимірюваного операційного опору, Anubis, ймовірно, не є рівнем, який змінює результат. Те ж саме справедливо, якщо ваш реальний біль походить від вразливого коду або насичення вище за течією. Якщо вартість скрейперів справді з’являється у ваших журналах та поведінці хоста, то це стає розумним, зосередженим інструментом для розгляду.

Anubis — це зосереджений рівень, який вирішує реальні проблеми

Якщо повернутися до вихідного сценарію, справжня привабливість Anubis стає зрозумілою. Це для публічного сайту, який не падає спектакулярно, але тихо поглинає витрати скрейпера день за днем. У цій ситуації Anubis варто розуміти, тому що він надає вам зворотний проксі-рівень, який може сповільнити зловживаючий доступ, перш ніж джерело продовжить за це платити.

Стійкий висновок простий: Anubis підвищує вартість великомасштабного скрейпингу та допомагає захистити ресурси джерела, але він все ще належить до більш широкого, реалістичного стека захисту. Якщо ви контролюєте свій власний VPS, виділений сервер або шлях зворотного проксі, навчання того, де такий рівень підходить, зазвичай легше, перш ніж тиск скрейпера стане тим, що змушує поставити питання.