☰

Linux: предотвращение исходящего TCP-флуда

tag-icon • tag-icon linux networking debian denial-of-service
Linux: предотвращение исходящего TCP-флуда

Я управляю несколькими сотнями веб-серверов за балансировщиками нагрузки, размещая множество различных сайтов с множеством приложений (которые я не контролирую). Примерно раз в месяц один из сайтов взламывается и загружается скрипт флуда для атаки на какой-нибудь банк или политическое учреждение. Раньше это всегда были флуды UDP, которые эффективно устранялись путем блокировки исходящего трафика UDP на отдельном веб-сервере. Вчера они начали флудить крупный банк США с наших серверов, используя множество TCP-подключений к порту 80. Поскольку такие типы подключений вполне допустимы для наших приложений, просто заблокировать их — неприемлемое решение.

Я рассматриваю следующие альтернативы. Какую из них вы бы рекомендовали? Вы их реализовали и как?

  • Ограничение на исходящие TCP-пакеты веб-сервера (iptables) с исходным портом != 80
  • То же самое, но с очередью (tc)
  • Ограничение скорости исходящего трафика на пользователя на сервер. Довольно административная нагрузка, так как потенциально на сервер приложений приходится 1000 разных пользователей. Может быть, это:как ограничить пропускную способность для каждого пользователя?
  • Что-нибудь еще?

Разумеется, я также ищу способы минимизировать вероятность проникновения хакеров на один из размещенных нами сайтов, но поскольку этот механизм никогда не будет на 100% защищен, я хочу существенно ограничить последствия вторжения.

Обновление: Я сейчас тестирую эти правила, которые предотвратили бы эту конкретную атаку. Как бы вы предложили сделать их более общими? Я упускаю известную атаку TCP DoS, когда ограничиваю только скорость пакетов SYN?

iptables -A OUTPUT -p tcp --syn -m limit --limit 100/min -j ACCEPT
iptables -A OUTPUT -p tcp --syn -m limit --limit 1000/min -j LOG --log-prefix "IPTables-Dropped: " --log-level 4
iptables -A OUTPUT -p tcp --syn -j REJECT --reject-with tcp-reset

Ваше здоровье!

решение1

Наилучшим возможным решением, по моему мнению, и тем, которое сработало для меня очень хорошо, является ограничение количества соединений/пакетов для IP-адреса назначения. Установка разумного предела не позволит злоумышленнику отправлять большое количество соединений к цели. Установка порта и протокола — не очень хорошая идея, потому что если злоумышленник отправляет http-флуд сегодня, завтра он будет использовать другой тип атаки. Поэтому ограничение соединений на IP-адрес в целом будет решением вашей проблемы.

Я надеюсь, что это помогает :)

решение2

Я всегда придерживался той позиции, что веб-сервер вообще не должен создавать исходящие TCP-соединения, а только отправлять трафик в качестве сервера, отвечающего на входящие запросы. (Я также разрешаю входящие TCP только для веб-сервера и SSH.) (В связи с этим я также считаю, что веб-сервер никогда не является подходящим хостом для отправки почты.) Это не только предотвратит исходящие атаки, но и немного усложнит атаки на ваши системы (хакеры не смогут получить доступ к окну xterm или wget для своего инструментария на вашем хосте).

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