Веб-сервисы для широкой публики: по сути, надежной защиты от атакующих не существует

Здравствуйте, я бездарность.

В последнее время атак стало заметно больше, поэтому попробую немного порассуждать на эту тему.

Надежной защиты от атак со стороны HTTP-клиентов не существует

Для начала рассмотрим разные способы защиты.

IP-адреса

С IPv6 всё было бы хорошо, но в среде CGNAT нескольким пользователям назначается общий IPv4-адрес, из-за чего пострадают и те, кто не является целью атаки.
Кроме того, менять IP-адреса довольно легко. В последнее время стало обычным делом устраивать DDoS-атаки, используя тысячи IP-адресов, предоставленных дешёвыми VPS в США — стране с большим количеством IP-адресов, которые часто применяют для атак, — или китайскими облачными платформами. Даже блокировка на уровне номера AS не решает проблему: если ваш сервис работает в Китае, блокировка IP-адресов китайских облачных платформ не будет полноценным решением, да и китайских пользователей жалко.
В целом облачные платформы в Китае очень часто используются злоумышленниками из других стран, поэтому я не считаю, что их можно безоговорочно блокировать.

В принципе, я считаю, что если сервис относится к Всемирной паутине и хотя бы один человек получает от него удовольствие, то не стоит безоговорочно его блокировать.
Я и сам время от времени смотрю видео на BiliBili, а также пользуюсь американскими сервисами.

User-Agent

В общем, этот способ никуда не годится. Я считаю, что оценивать сами заголовки запроса как способ ограничения доступа почти бессмысленно, поэтому особо нечего добавить.
Подделать их можно как угодно, так что блокировать запросы, опираясь лишь на UA, нельзя.
Можно, например, полностью блокировать запросы, которые представляются googlebot в UA, если их обратный DNS-хост не относится к *.googlebot.com или *.google.com, как я сейчас делаю на этом сайте. Но такую проверку нужно реализовать самостоятельно или выяснить, есть ли что-то подобное на стороне CDN. Кроме того, хотя Google официально утверждает именно это, на самом деле Google отправляет немало настоящих ботов с хостов, которые при обратном DNS-поиске не относятся ни к одному из этих доменов, поэтому полагаться только на такую проверку нельзя.

Кстати, даже на такой никчёмный сайт, как этот, пытаются заходить, выдавая себя за Googlebot. Вот список:
Отчёт fail2ban — поддельные Googlebot

Блокировка по странам

В качестве временной меры после атаки это может сработать, но для постоянной защиты смысла в этом нет — причина та же, что и в случае с блокировкой по IP-адресам, поэтому не буду её повторять.
Однако для сервиса, ориентированного только на местную аудиторию, это может быть полезно.

Отпечаток TLS

Отпечаток TLS тоже довольно легко подделать.
Достаточно встроить в HTTP-клиент ту же криптографическую библиотеку, что используется в браузере, и можно подделать браузерный отпечаток.
Нельзя сказать, что этот метод совершенно бесполезен, но, например, если легитимный бот отправляет запросы с той же криптографической библиотекой, его можно ошибочно заблокировать.
Поскольку высок риск совпадения отпечатка с отпечатками множества HTTP-клиентов, оценивать его однозначно нельзя.
Поэтому отпечаток может быть одним из критериев проверки; он может быть полезен в сочетании с другими правилами, но не как единственное условие.

Cloudflare Challenge / PoW Challenge

Cloudflare Challenge можно легко обойти даже без безголового браузера.
Не знаю, как обстоят дела с Anubis, но с точки зрения UX он не очень хорош: он требует вычислений на стороне клиента и заметно раздражает при переходе между страницами.
В некотором смысле он может обеспечить дополнительную защиту в сочетании с JS Challenge. В последнее время всё больше форумов с утечками внедряют собственные PoW Challenge, поэтому вопрос в том, где именно его применять. Если речь идёт о защите от DoS, то использование PoW Challenge на уровне приложения — не лучший вариант. Но если ограничить его применение подходящими сценариями, возможно, удастся реализовать защиту на стороне фронтенда, по возможности не ухудшая UX.

Платный доступ

Платный доступ подходит лишь для ограниченного числа сервисов, поэтому пропущу этот пункт.

Кэширование HTTP

Я сомневался, стоит ли вообще включать этот пункт в статью, но всё же включил.
Если говорить о доступности Origin, кэширование на CDN может быть полезно, например, для GET-запросов, но мне кажется, что сейчас это и так внедрено повсюду.
Не стоит рассматривать кэширование как защиту. Оно полезно для улучшения пользовательского опыта, а также для снижения нагрузки при массовых запросах, вызванных ответами с ошибками. Поэтому его, скорее, стоит использовать для повышения производительности без влияния на приложение.

Ограничение частоты запросов

В разных сервисах сам key может заметно различаться, поэтому, похоже, стоит внимательно изучить правила реализации. Если говорить только о Nginx, ограничивать запросы можно по общему трафику, URI, IP-адресу или сочетанию этих критериев, поэтому с точки зрения защиты от DoS это может быть полезно.

Так что же делать?

Думаю, остаётся лишь разделить защиту на несколько уровней и применять сочетание условий.
Сейчас я размышляю о том, чтобы добавить список разрешённых AS Number для трёх надёжных облачных провайдеров и краулеров социальных сетей, а для остальных установить более строгие ограничения.
А ещё можно блокировать явно подозрительные шаблоны запросов, характерные для атакующих:

• IP-адреса, с которых сканируют .env и подобные файлы

• Те, кто представляется googlebot, но явно им не является

• Те, кто отправляет невозможные запросы вроде POST/PUT и прочего

• Те, кто отправляет бессмысленные запросы на пути вроде /login или другие адреса, где можно создать сессию

В таких случаях, может, сразу блокировать? Честно говоря, дешёвые VPS часто используют для злоупотреблений, и мне хочется блокировать их все разом. Но я и сам нередко поднимаю VPN-сервер на дешёвом VPS и просматриваю сайты с его выходного IP-адреса, так что это, наверное, было бы чрезмерно. Хотя для некоторых сервисов такой подход, возможно, вполне подойдёт.

Кроме того, в последнее время критиковали снятие отпечатков по аудиоустройствам, но я считаю, что на практике это полезно, и блокировать запросы, если такой отпечаток не удалось обнаружить, вполне разумно. Хотя рано или поздно и этот способ, наверное, научатся обходить…
Возможно, в будущем для определения пользовательских устройств начнут комплексно использовать отпечатки GPU, аудиоотпечатки и другие подобные методы.