Не так давно при подключении защиты от DDoS- и ботовых атак для крупной компании из e-commerce мы выявили существенную автоматизированную активность из подсетей одной немаленькой кредитной организации. Получалось так, что некий банк фактически атаковал нашего клиента, периодически посылая множество запросов к его сервисам. Избыточная нагрузка в пиковые моменты на серверы клиента была ощутимой. К недоступности или заметной деградации работы сайта и мобильного приложения клиента это не приводило лишь за счет наличия большого запаса мощностей.
Как показал дальнейший совместный разбор с клиентом, причина этой «вредоносной» активности — не хакеры, не сотрудники-вредители в том самом банке, и не конкуренты, а проявление элементарной невнимательности и неорганизованности при создании и поддержке автоматизации. Ну а периодические атаки — и не атаки вовсе, а просто забытая полтора года назад прожорливая и удивительно живучая автоматизация. Не сказать чтобы мы были очень удивлены: схожий по природе трафик в той или иной степени встречается у каждой третьей компании, которой мы подключаем наше решение по защите от ботов или DDoS-атак на прикладном уровне.
Дело в том, что одним из этапов подключения ресурса к защите от широкого спектра нелегитимной активности является «обучение» нашего решения клиентскому трафику. Специалисты анализируют пришедший за несколько дней трафик, разбивают его по группам. Группа «браузерного» трафика, как правило, самая понятная и предсказуемая: при помощи стандартных браузеров («Яндекс Браузер», Chrome, Firefox и других) пользователи отправляют запросы на сервисы наших клиентов. Группа клиентских мобильных приложений известна самой компании, на чьем трафике обучается антибот, и потому также хорошо выделяема.
С автоматизированной активностью дела обстоят несколько сложнее — она бывает легитимной и нелегитимной. Пример заведомо легитимной автоматизации — запросы от поисковых систем. Но кроме нее остается иная автоматизация, выглядящая в простейшем случае как постоянный или периодически появляющийся трафик из известной хостинговой подсети, отправляющий большое количество однотипных запросов. Дело в том, что на крупных и средних сервисах, как правило, существует и полезная автоматизация. Когда для разных целей и задач в рамках партнерских взаимоотношений со сторонними сервисами или даже внутри различных сервисов одной группы компаний, боты запрашивают информацию.
Фактически при обучении трафику нового сервиса наши специалисты участвуют в процессе ревизии всей имеющейся автоматизации: выделяются параметры автоматизации — подсети-источники трафика, типы агентов, вызываемые методы характера нагрузки. А после инженеры со стороны клиентов должны сказать: «Это наша автоматизация, пропускаем», либо «Режем». И на практике в каждом третьем случае помимо ожидаемого «Да, это наш Zabbix» и «Это точно ботоводы», представители IT-подразделения заказчика отвечают: «В старую тормозящую версию API почему-то ходит наш сервис, от которого мы давно отказались, и создает дополнительную нагрузку». Или даже так: «Это, похоже, настраивала команда, которая давно ушла, зачем оно крутится и какая от этого польза — непонятно, давайте пока разметим как подозрительный, а после ревизии примем решение, что с этим делать». И почти у каждого крупного игрока мы сталкиваемся с ситуацией, когда инженеры не без удивления констатируют: «Да, это, похоже, наши партнеры, но что-то они слишком сильно нас грузят, мы так не договаривались, пойдем с ними решать».
Забытые ботнеты не так безобидны, как может показаться на первый взгляд. Зачастую живучими оказываются запросы, которые не грузили сервис, в котором «обитали» тысячи пользователей, но которые теперь сильно тормозят систему, помнящую миллионы клиентов, товаров, транзакций и иных сущностей. И потребляет эта автоматизация вычислительные ресурсы годами. В отдельных случаях некогда полезная, а после ставшая неактуальной, но продолжавшая жить автоматизация, составляла до 30% в общем объеме трафика, а это уже серьезная нагрузка на серверы. И чем крупнее сервис, чем дольше он живет, и чем больше у него кооперации с сервисами иных команд и компаний, — тем выше шанс встретить у него «забытую» автоматизацию.
По опыту могу сказать: если сервис был запущен три–четыре года назад, им пользуются десятки тысяч уникальных пользователей в неделю, и есть кооперация с партнерскими сервисами, то подобная неучтенная автоматизация находится почти всегда, и не в единственном экземпляре. А если IT-команда менялась, и не раз, то могут встречаться такие вот кейсы, как с нашим клиентом из e-commerce, когда так и не удалось установить, когда и кем было решено настроить взаимодействие с тем самым банком-партнером, но отключение спустя три недели разбирательств не повлияло ни на что, — лишь снизило нагрузку.
Природа появления «забытой» автоматизации — отсутствие учета и размытые границы ответственности, помноженные на разумный принцип «зачем ломать то, что работает». До поры с этим можно жить, закрывая проблемы покупкой дополнительных мощностей, — зачастую это проще и дешевле. Но все же, если периодически не наводить порядок в сервисах и не выделять ресурсы на ревизию и инвентаризацию, груз технического долга может стать неприемлемым. Как показывает практика, после того как под действием внутренних или внешних обстоятельств порядок на ресурсе все-таки наводится, сервис начинает «дышать» свободнее — пропадают ошибки в мониторингах, снижается нагрузка на серверы, улучшается время отклика.
Мнение редакции может не совпадать с точкой зрения автора