Как настроить ядро ​​Linux, чтобы противостоять DDoS? (HAProxy)

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

Мое ядро ​​Linux с 10 тысячами соединений выходит из строя из-за нехватки ресурсов, таких как ЦП и ОЗУ. Мне было интересно, как безопасно ограничить его, чтобы он не создавал соединения tcp / ip в таблице отслеживания соединений netfilter или где-либо еще, когда кто-то пытается открыть 100.000 соединений с разных хостов?

Сетевая карта - 1 Гбит / с, и с максимальными буферами она может занимать много соединений, однако я бы хотел, чтобы она была только на 5.000 одновременно, а остальные отбрасывались, за исключением случаев, когда есть свободные слоты для подключения. На уровне ядра, поэтому он не загрязняет сетевой фильтр или что-либо еще, и он удаляется как можно скорее. Есть эти факторы:

  • Количество соединений HAProxy ограничено только 5.000
  • Linux падает с 10.000 открытых соединений
  • Я хочу выдерживать 100 000 открытых соединений каждую минуту, поэтому, возможно, netfilter справится с этим, но без HAProxy.
  • Существующие соединения продолжают работать

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

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

4 ответа

Решение

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

Для SYN флудов гугл немного. Вы, вероятно, хотите порвать новое ядро ​​Linux, поскольку в последнее время было немало улучшений. Перейти на 3.6 и включить син куки. Есть несколько других настроек, которые вы можете настроить. Обязательно прочтите это вначале, так как случайная настройка никогда не будет хорошей идеей и вызовет проблемы.

Если это HTTP-флуд, который часто встречается в наши дни, вы можете рассмотреть Varnish. Возможно, вы сможете идентифицировать атакующие запросы по некоторому шаблону и уничтожить их в vcl_recv. Вы можете развернуть защитный модуль, чтобы уничтожить это соединение, поскольку подача страницы с ошибкой является пустой тратой усилий. Имейте в виду: это не быстрое решение и потребует значительных усилий с вашей стороны.

Удачи.

От какой атаки на ddos ​​вы страдаете? Если это синхронный поток, вы можете включить синхронизированные куки.

Нет реального способа уменьшить DDOS от атакующего хоста.

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

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

Я поддержу требование управления DDoS в восходящем направлении, но в качестве промежуточной меры вы можете захотеть использовать какую-либо политику или формирование соединений на вашем собственном маршрутизаторе или переключить переход или около того перед соответствующими серверами. Лучший способ прийти в норму от крушения - это не рухнуть в первую очередь. Маршрутизатор / межсетевой экран / коммутатор на самом деле не завершает пакеты и (надеюсь) предназначен для работы с гораздо более высокой скоростью.

Другие вопросы по тегам