У меня недавно был простой сервера. Я искал везде, и единственное, что я нашел в своих файлах журнала, это:
Feb 17 18:58:04 localhost kernel: possible SYN flooding on port 80. Sending cookies.
Feb 17 18:59:33 localhost kernel: possible SYN flooding on port 80. Sending cookies.
Может кто-нибудь дать мне больше информации об этом. Что это такое, как отладить причину и как исправить то же самое. Я также опубликовал ipconntrack внезапно стал слишком большим в котором есть еще одна точка данных, которую я нашел необычным, задавая вопрос, связаны ли эти две вещи, поскольку они произошли точно в одно и то же время, но на разных серверах. Один на обратном прокси, а другой на реальном сервере Varnish)
Спасибо
Syn flood - это атака, при которой в большинстве случаев злоумышленник подделывает адрес источника созданного пакета, который пытается установить соединение с вашим сервером (в данном случае порт 80).
Если злоумышленник быстро сгенерирует много таких пакетов, он может исчерпать пул соединений и тем самым предотвратить подключение законных пользователей к хосту.
Файлы cookie TCP Syn - это метод, который используется для лучшей обработки атакуемой ситуации, и хотя у него есть некоторые ложноотрицательные результаты, многие пользователи могут получить доступ к вашей службе (сети) во время атаки SYN-флуда.
Это правило iptables, которое можно быстро использовать
iptables -N syn_flood
iptables -A INPUT -p tcp --syn -j syn_flood
iptables -A syn_flood -m limit --limit 1/s --limit-burst 3 -j RETURN
iptables -A syn_flood -j DROP
Это базовая DDOS-атака, называемая атака синего наводнения. По сути, злоумышленник использует ботнет для полуоткрытия TCP-соединений на вашем компьютере, чтобы получить доступ к вашей таблице соединений. Вы можете защитить от этого с помощью iptables или, что еще проще, с помощью брандмауэра, такого как CSF, который включает эти встроенные правила. Я писал об этом Вот, а теперь рекомендую ConfigServer Firewall (CSF), в который встроены эти средства защиты.
Дайте мне знать, если у вас возникнут какие-либо конкретные вопросы об атаках такого типа.
http://blog.dubbelboer.com/2012/04/09/syn-cookies.html есть отличная запись по этому поводу. Если соединения являются подлинными и ожидаемыми, попробуйте настроить параметры ядра net.ipv4.tcp_max_syn_backlog и net.core.somaxconn, а также размер невыполненной работы, передаваемой вызову listen () в вашем приложении.
Приведенный выше набор правил бесполезен в случае, если SYN-атаки исходят с одного IP-адреса, поскольку другой законный трафик также будет блокироваться в качестве опции ограничения, не учитывающей один IP-адрес, поэтому я предлагаю использовать connlimit или hashlimit.