Могу ли я несанкционированно закрыть TCP-соединение, чтобы смягчить атаку типа «отказ в обслуживании»?

Могу ли я несанкционированно закрыть TCP-соединение, чтобы смягчить атаку типа «отказ в обслуживании»?

Я работаю над веб-сервисом, который может стать целью атаки типа «отказ в обслуживании». У нас есть некоторые меры по смягчению последствий атак типа «SYN-флуд». Но есть и другие атаки «на уровне приложений» против нашего сервиса, когда вредоносный/сломанный клиент может многократно отдавать веб-сервису команды на выполнение дорогостоящих задач.

Мы можем идентифицировать этих злоупотребляющих клиентов на уровне приложений, т. е. в наших серверных процессах. Как только наш процесс идентифицирует злоупотребляющее клиентское соединение, мы хотели бы снизить наш уровень обслуживания для этого клиента.

Наивным методом было бы завершить TCP-соединение с помощью close(2), shutdown(2)или аналогичного. Но тогда клиент может немедленно переподключиться (до предела подключений/секунд, установленного для смягчения SYN-флуда), и это переподключение обходится нам дорого из-за квитирования TLS и других расходов на установку соединения. Мы ищем способ остановить взаимодействие клиента с нашей службой на некоторое время, но чистое завершение TCP-соединения не делает этого.

Однако, если бы наш процесс смог разорвать TCP-соединениенечистоплотный, злоупотребляющий клиент будет задержан на некоторое время, прежде чем он снова подключится, тем самым обеспечивая период "остывания". Под "нечистым завершением" я подразумеваю закрытие TCP-соединения (обе половины полнодуплексного соединения) на стороне сервера без отправки какого-либо FINпакета для уведомления клиента о завершении и без отправки каких-либо дополнительных пакетов, относящихся к этому соединению. Это задержит клиента, пока он будет считать соединение все еще в состоянии ESTABLISHED(что составляет 13-30 минут в Linux).

Однако я не вижу способа, с помощью которого процесс UNIX/Linux мог бы нечестно завершить TCP-соединение. close(2), shutdown(2)и подобные им, похоже, все они аккуратно завершают соединение и не предоставляют никаких вариантов нечестного завершения.

Существует ли в UNIX/Linux возможность немедленного некорректного завершения TCP-соединения в качестве меры по смягчению последствий DOS-атак?

решение1

Вам следует обратить внимание на брандмауэр, и fail2ban. iptablesпо-прежнему является стандартом для дистрибутивов Linux и fail2banбудет работать с большинством служб. Вам нужно настроить fail2banмониторинг определенного файла журнала с использованием определенного шаблона регулярного выражения, чтобы знать, когда подключается один из этих «проблемных» клиентов, а затем fail2banавтоматически добавить правило брандмауэра, чтобы сбросить или отклонить соединение. fail2ban можно настроить так, чтобы можно было выйти из правила брандмауэра, чтобы вы могли заблокировать клиента на 5 минут или 5 дней, на что угодно.

Для подобных задач вы также можете использовать брандмауэр веб-приложений (WAF).

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

решение2

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

Поскольку вы уже упомянули, что для установления нового соединения требуются затраты, я бы рекомендовал вам рассмотреть альтернативный подход, нежели разрыв соединения. Возможно, вы можете рассмотреть ограничение скорости этого соединения до 1 байта в минуту или что-то подобное. При таком подходе вы все равно сможете занять ресурсы злоумышленника при минимальных затратах с вашей стороны. Если у вас больше времени и вы хотите проявить креативность, перенаправьте все такие соединения на один сервер в вашей среде, чтобы другие серверы не тратили зря свой лимит открытых файлов. Как упомянул Эндрю, вы также можете рассмотреть возможность использования fail2ban, как только вы подтвердите, что соединение исходит от злоумышленника, и его можно безопасно забанить на несколько часов.

Связанный контент