Сегодня я имел дело с сервером, страдающим от того, что выглядело как атака SYN-флуда. Было немного спешить, чтобы снова запустить сайт, поэтому мы выполнили эти три шага, чтобы вернуть службу в рабочее состояние. Нагрузка на сервер во время атаки была низкой, поэтому она не остановила сервер, а просто отключила HTTP-посетителей.
Я не верю, что это решило проблему, но они определенно разрешили симптомы, пока наводнение не утихло.
Устанавливать sysctl -w net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv = 5
Увеличенный префорк Apache ServerLimit и MaxClient до 512 (с 256).
Установить Apache ListenBackLog до 1024
Я видел разные iptables - предел варианты, обсуждаемые в других местах в Интернете, однако мы пришли к выводу, что они ограничат законный трафик, поскольку каждый элемент запрашиваемой веб-страницы (каждое изображение и т. д.) будет учитываться в этом ограничении, останавливая полную загрузку страницы.
Что люди делают в таких ситуациях, и были ли наши действия мудрыми, поскольку нагрузка не была проблемой?
Я бы использовал брандмауэр на периметре сети для предотвращения \ исправления атак SYN flood (а также DOS, DDOS, спуфинга, зондов портов, зондов адресного пространства и т. Д.). Я не хочу, чтобы подобные вещи попадали в мою внутреннюю сеть, где мне придется разбираться с ними по отдельности.
Поскольку я не являюсь экспертом в iptables, я обычно позволяю одному из двух межсетевых экранов делать это за меня. Обе APF и CSF являются отличными брандмауэрами, когда дело доходит до защиты от SYN-атак, а также множества других способов, которыми люди могут атаковать ваш сервер.
Я не знаю вашу конкретную конфигурацию, но я использовал оба упомянутых брандмауэра на «общих» серверах cPanel / DirectAdmin / Plesk, а также некоторые с настраиваемыми службами, и он отлично работает, когда вы разрешаете правильные порты.
Отдельно можно включить SYN файлы cookie, что помогает смягчить атаки, когда SYN остается открытым. В обоих приведенных выше сценариях это есть опция.