Блокування за access_log, легкий спосіб прострелити ногу або усунення конкурентів

Черговий приклад, як легко прострелити собі ногу, на цей раз «перестаратися» при захисті сайту.
Імен як завжди не називаю, однак історія показова як така, тобто як приклад, як не треба «захищати» свої сервера. Ех кажеш їм, говориш — а все без толку.

Впала відвідуваність сайту, не зовсім щоб зовсім, але досить помітно. Дивилися логи, аналітику пошукачів і т. д. і т. п. Все ніби нормально, і хто приходить, той навіть не йде відразу.
Але не буду ходити навколо, та близько — проаналізувавши логи банів по IP з'ясувалася одна закономірність — за короткий час в бан потрапляло величезна кількість IP-адрес. Всі поголовно з однієї причини — нібито як botsearch. Отротированные логи за останній місяць теж жахали своїми розмірами і навіть заглядати туди не треба було, і так все ясно. Тобто сталося наступне: купа клієнтів просто не могла потрапити на сайт.
На питання «що-то міняли десь з місяць тому?» було отримано негативну відповідь.

Не буду втомлювати тут детективним чтивом, після недовгих пошуків — картина маслом. Якийсь прямий конкурент цього сайту посприяв «витоку» клієнтів, або вірніше організував цю «дивну невідвідуваність».

Опис сценарію «атаки»:
  • є популярний сайт «mysite», де включили блокування скануючих ботів access;
  • інший, можливо порівняти популярний, сайт «othersite» (наприклад, прямий конкурент «mysite» з тієї ж цільової аудиторією), робить якимось чином на своїй сторінці прихований include (наприклад в прихованому фреймі), де викликає наприклад 3-і URL-адреси «mysite», відповідних шуканим для фільтра цього блокування.
  • будь візит потенційних клієнтів спочатку на сторінку «othersite», практично гарантує їм неможливість потім потрапити на сайт «mysite». Тобто N раз натиснувши десь на сторінці «othersite» — браузер користувача робить N*3 «невдалих» виклику для сайту «mysite», що призводить до блокування IP користувача (за досягнення maxretry).
  • як результат, для цього клієнта сайт «mysite» буде недоступний (його IP-адреса був забанений)
До речі блокування тут здійснювалася не за access_log, а з-за високої завантаженості серверів, безпосередньо з веб-сервера. Висловлюючись мовою nginx, в локейшен, відпрацьовує 404 і іже з ними помилки, був увіткнутий постпроцесор, фоново сповіщає сервіс блокування за IP-адресою, після фільтрації певними регулярними виразами за урл. Ну типу nginx-botsearch фільтра fail2ban, але без стомлюючого распарзивания логів (що часто дуже накладно).

Однак тим же самим чином можна вистрілити собі в ногу, наприклад, просто активувавши в fail2ban деякі jail, використовують такі фільтри як "nginx-botsearch", "apache-botsearch" або безліч інших фільтрів, натравливаемых на access log веб-сервера, у величезній кількості курсують в інтернеті для «захисту» від ботів. Ось наприклад, черговий такий фільтр, очікує пул-реквестом в fail2ban. І таких сотні та описів до них ще більше.

Але повернемося до самої атаці. Що примітно, швидше за все ці нехороші люди найняли когось із blackhat-ів (ну не самі ж вони до цього дійшли) ймовірно для злому сайту конкурентів. Можливо потрібна була база клієнтів, або шукали спосіб для кращого ддоса, та хіба мало чого ще. Ну а ті, виявивши таку «захист» від дурня, вже певно продали їм кілька URL або ж сам include, як просту можливість «усунути конкурента». У будь-якому випадку, ймовірність, що така практика вже масово не взята на озброєння, відмінна від нуля.

Домисли — домислами, проте факт «атаки» і який-ніякої шкоди наявності.
Тому будьте пильні і включайте вже голову. Ну або кличте знайомого ресерчера…

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.