Я работаю над веб-службой, которая может стать целью атаки типа «отказ в обслуживании». У нас есть некоторые средства защиты от атак типа «SYN flood». Но есть и другие атаки на наш сервис «на уровне приложения», когда злонамеренный / сломанный клиент может неоднократно инструктировать веб-сервис о выполнении дорогостоящих задач.
Мы можем идентифицировать этих злоумышленников на уровне приложений, то есть в наших серверных процессах. Как только наш процесс обнаружил оскорбительное клиентское соединение, мы хотели бы снизить уровень обслуживания этого клиента.
Наивным методом было бы завершить TCP-соединение с помощью close(2), shutdown(2), или похожие. Но затем клиент может немедленно переподключиться (до предела подключений в секунду, установленного для смягчения SYN-флуда), и это переподключение обходится нам дорого из-за рукопожатий TLS и других затрат на установку подключения. Мы ищем способ на некоторое время остановить взаимодействие клиента с нашей службой, но чистое завершение TCP-соединения этого не делает.
Однако, если бы наш процесс смог прервать TCP-соединение нечисто, злоумышленник будет задержан на некоторое время перед повторным подключением, что обеспечит период «охлаждения». Под "нечистым завершением" я подразумеваю закрытие TCP-соединения (обе половины полнодуплексного режима) на стороне сервера без отправки FIN пакет, чтобы уведомить клиента о завершении и без отправки каких-либо дополнительных пакетов, относящихся к этому соединению. Это задержит клиента, пока клиент считает, что соединение все еще находится в ESTABLISHED состояние (которое в Linux составляет 13-30 минут).
Однако я не вижу возможности для процесса UNIX / Linux нечисто завершить TCP-соединение. close(2), shutdown(2) и тому подобное, все, кажется, полностью завершают соединение и не предоставляют никаких вариантов для нечистого завершения.
Существует ли в UNIX / Linux возможность немедленного, нечистого завершения TCP-соединения в качестве защиты от атак DOS?
Как только наш процесс обнаружил оскорбительное клиентское соединение, мы хотели бы снизить уровень обслуживания этого клиента.
Поскольку вы уже упоминали, что установка нового соединения связана с расходами, я бы рекомендовал вам рассмотреть альтернативный подход, а не разорвать соединение. Может быть, вы можете ограничить скорость этого соединения до 1 байта в минуту или что-то подобное. При таком подходе вы по-прежнему можете держать ресурсы злоумышленника занятыми с минимальными затратами на вашей стороне. Если у вас есть больше времени и вы хотите проявить творческий подход, перенаправьте все такие подключения на один сервер в вашей среде, чтобы другие серверы не тратили впустую свой лимит открытых файлов. Как уже упоминал Эндрю, вы также можете рассмотреть возможность использования fail2ban после того, как подтвердите, что соединение исходит от злоумышленника, и его можно безопасно заблокировать на несколько часов.
Вам следует обратить внимание на брандмауэр и fail2ban. iptables по-прежнему в значительной степени стандартен для дистрибутивов Linux и fail2ban будет работать с большинством сервисов. Что вам нужно сделать, так это настроить fail2ban для мониторинга определенного файла журнала с использованием определенного шаблона регулярного выражения, чтобы узнать, когда один из этих `` проблемных '' клиентов подключается, а затем fail2ban автоматически добавить правило брандмауэра, чтобы сбросить или отклонить соединение. В fail2ban можно настроить выход из правила брандмауэра, чтобы вы могли заблокировать клиента на 5 минут или 5 дней, что вам действительно нужно.
Вы также можете использовать брандмауэр веб-приложений (WAF) для этого типа вещей.
Что касается DOS-атаки, в зависимости от того, как она проводится, вам может не повезти с локальным брандмауэром, и вам, возможно, придется связаться с вашим вышестоящим провайдером по маршрутам или узлам черных дыр, которые, как известно, являются проблематичными и вызывают серьезное нарушение обслуживания. Похоже, вы не находитесь в таком положении, и у вас просто есть потенциальные проблемы на уровне приложения, которые нужно решить, так что это перебор.