Серверне проміжне ПЗ, яке зупиняє підроблені краулери перед досягненням вашої програми

Конвеєр запитів у веб-додатку — це елегантна річ. Запит надходить на веб-сервер, проходить через стек проміжного ПЗ, досягає контролера та повертає відповідь. Кожне проміжне ПЗ у стеку має можливість перевірити запит, змінити його, передати далі або повністю відхилити. Така архітектура ідеально підходить для впровадження виявлення ботів, оскільки перевірка відбувається до того, як запит торкнеться будь-якої логіки програми. Підроблений краулер, який видає себе за Googlebot, виявляється та блокується на рівні проміжного ПЗ, і контролер навіть не дізнається про існування запиту. Жодних циклів процесора, витрачених на рендеринг сторінки. Жодних запитів до бази даних. Жодних записів у кеш. Підроблений бот зупиняється біля дверей, а ресурси сервера, які були б витрачені, зберігаються для законних відвідувачів.

Мотивацією для розробки цього проміжного ПЗ була конкретна та дорогоцінна проблема. Велика програма споживала пропускну здатність та ресурси сервера зі швидкостями, які не відповідали її фактичній базі користувачів. Журнали доступу виявили масивні обсяги запитів від агентів користувачів, які видають себе за Googlebot, Bingbot та різні інші законні краулери. Розслідування підтвердило, що більшість із них були підробленими, походячи з хмарних хостинг-провайдерів, а не від пошукових машин, які вони видавали себе за. Кожен підроблений запит витрачав ті ж ресурси сервера, що й реальний: той же час виконання PHP, ті ж запити до бази даних, те ж розподілення пам'яті, ту ж пропускну здатність для відповіді. Помножено на тисячі підроблених запитів на годину, вартість була істотною. Рішення проміжного ПЗ було розроблене для усунення цих витрат шляхом перехоплення підроблених краулерів до того, як вони витратять будь-які ресурси програми.

Реалізація дотримується прямого та простого шаблону, який будь-який розробник зворотної частини може адаптувати. Проміжне ПЗ перехоплює кожний вхідний запит, перевіряє, чи рядок агента користувача відповідає відомому шаблону краулера пошукової машини, і якщо так, перевіряє IP-адресу запиту з відомою інфраструктурою краулера за допомогою API виявлення ботів. Запити, які видають себе за краулери, але не проходять перевірку, блокуються з відповіддю 403. Запити, які проходять перевірку, або що не видають себе за краулери, продовжують свій шлях через стек проміжного ПЗ нормально. Вся перевірка додає мінімальну затримку, оскільки результати перевірки кешуються за IP-адресою, що означає, що кожна унікальна IP перевіряється тільки один раз.

Логіка рішення, яка стоїть за блокуванням на рівні проміжного ПЗ

Вибір блокування на рівні проміжного ПЗ, а не на рівні веб-сервера (Nginx або Apache) або на рівні програми (у межах контролерів), є свідомим архітектурним рішенням із конкретними компромісами. Блокування на рівні веб-сервера — це найефективніший варіант з точки зору споживання ресурсів, оскільки запит ніколи не досягає PHP. Однак налаштування веб-сервера для виявлення ботів зазвичай передбачає статичні чорні списки IP або просту відповідність агентів користувачів, жоден із яких не забезпечує динамічну, керовану API перевірку, необхідну для точного розрізнення реальних краулерів від підроблених. Ведення статичного чорного списку мільйонів IP-адрес є непрактичним, а відповідність агентів користувачів самої по собі не може перевірити ідентичність, оскільки агенти користувачів легко підробляються.

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

Рівень проміжного ПЗ знаходиться в оптимальній точці конвеєра. Він виконується перед обробкою сеансу, перед автентифікацією, перед проміжним ПЗ для конкретних маршрутів і, звичайно, перед будь-якою логікою контролера. Але він має доступ до повного об'єкта запиту, включаючи заголовки, IP-адреси та параметри запиту, що означає, що він може виконувати витончену логіку верифікації, а не просто відповідність шаблонів. Проміжне ПЗ може викликати зовнішній API, результати кешу, застосовувати умовну логіку на основі заявленої ідентичності та реєструвати результати верифікації для аналізу. Така комбінація ефективності та гнучкості робить проміжне ПЗ природним місцем для виявлення ботів у веб-додатку.

Стратегія кешування особливо важлива для продуктивності. Без кешування, кожен запит від заявленого краулера вимагав би викликання API для перевірки IP-адреси. Навіть при швидкому API це додало б затримку до кожного запиту. Рішення полягає в кешуванні результатів верифікації, ключовані IP-адресою, зі строком дії кількох годин або навіть цілого дня. Краулери пошукових машин працюють зі стабільних діапазонів IP, які рідко змінюються, тому кешований результат верифікації залишається дійсним протягом тривалого часу. Коли надходить запит від заявленого Googlebot, проміжне ПЗ спочатку перевіряє кеш. Якщо IP була перевірена як законна у межах періоду кешування, запит дозволяється проходити негайно. Якщо IP була перевірена як підроблена, вона блокується негайно. Тільки IP-адреси в першому разі вимагають фактичного виклику API, а після цього початкового виклику результат обслуговується з кешу з незначною затримкою.

Що відбувається з запитами, які блокуються

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

Відповідь на заблокований запит також може бути більш нюансованою, ніж повсюдна 403. Деякі реалізації повертають 429 (Too Many Requests), щоб приховати той факт, що бота було виявлено, що ускладнює для оператора бота коригування його підходу. Інші повертають 200 з порожнім тілом, що витрачає мінімальну пропускну здатність, одночасно запобігаючи боту дізнатися, що він був виявлений. Більш агресивні підходи повертають 403 з повідомленням, що вказує на те, що перевірка краулера не вдалася, що є прозорим, але дає операторам ботів інформацію про механізм виявлення. Вибір залежить від філософії оператора сайту щодо прозорості та операційної безпеки.

Для ботів, які видають себе за краулери, але насправді є законними сервісами, які неправильно використовують рядки агентів користувачів пошукових машин, блокування може бути більш руйнівним, ніж передбачалося. Деякі інструменти моніторингу SEO, наприклад, використовують рядки агентів, подібні до Googlebot, для імітації того, як Google бачить сторінку. Ці інструменти не пройдуть перевірку, оскільки вони не є Google, навіть якщо їх мета законна з точки зору оператора сайту. Проміжне ПЗ може задовольнити це, ведучи білий список відомих діапазонів IP для надійних сторонніх сервісів, або застосовуючи верифікацію тільки до конкретних шаблонів агентів, ігноруючи інші. Гнучкість підходу проміжного ПЗ дозволяє цей вид нюансованої політики без необхідності змін у конфігурації веб-сервера або коду програми.

Синхронна та асинхронна верифікація

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

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

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

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

Вимірюваний вплив блокування біля дверей

Результати впровадження проміжного ПЗ для виявлення ботів видимі майже негайно в метриках сервера. Найбільш драматична зміна — у споживанні пропускної здатності. Підроблені краулери запитують повні HTML-сторінки, включаючи всі активи, на які посилаються у відповіді. Кожен заблокований запит економить пропускну здатність, яка була б використана для передачі повної відповіді, яка для насичених контентом сторінок може становити десятки або сотні кілобайтів на запит. На тисячах заблокованих запитів на годину економія пропускної здатності накопичується в значне скорочення витрат, особливо для програм, розміщених у провайдерів, які виконують платежі за гігабайт передачі.

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

Час відповіді для законних відвідувачів поліпшується як прямий наслідок зменшення навантаження на сервер. Веб-сервер, який обробляє п'ятисот запитів на секунду, триста з яких — підроблені боти, має менше пропускної здатності, доступної для двохсот реальних відвідувачів, ніж сервер, який обробляє лише двісті запитів на секунду, всі з яких є законними. Проміжне ПЗ не просто економить ресурси на заблокованих запитах. Це поліпшує якість послуг для кожного запиту, який проходить, оскільки сервер має більше пропускної здатності, доступної для реальної роботи.

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