“Возможный SYN, лавинно рассылающий” в журнале несмотря на небольшое число соединений SYN_RECV
Можно использовать Установщик Веб-платформы от Microsoft. Это легко и очень эффективно.
Так, это - аккуратный вопрос.
Первоначально, я был удивлен, что Вы видели любые соединения в состоянии SYN_RECV с включенными куки SYN. Красота cookie SYN состоит в том, что Вы можете statelessly участвовать в в трехстороннем квитировании TCP как сервер с помощью криптографии, таким образом, я ожидал бы, что сервер не представит полуоткрытые соединения вообще, потому что это будет тем же самым состоянием, которое не сохраняется.
На самом деле быстрый быстрый взгляд на источник (tcp_ipv4.c) показывает интересную информацию о том, как ядро реализует cookie SYN. По существу, несмотря на включение их, ядро ведет себя, как оно обычно было бы, пока его очередь незаконченных соединений не полна. Это объясняет Ваш существующий список соединений в состоянии SYN_RECV.
Только то, когда очередь незаконченных соединений полна, И другой пакет SYN (попытка подключения) получен, И это была больше чем минута начиная с последнего предупреждающего сообщения, делает ядро, отправляют предупреждающее сообщение, которое Вы видели ("передающие cookie"). Cookie SYN отправляются, даже когда предупреждающее сообщение не; предупреждающее сообщение должно только дать Вам головы, что проблема не ушла.
Другими словами, если Вы выключите cookie SYN, то сообщение уйдет. Это только собирается удаться для Вас, если Вы больше не лавинно рассылаемый SYN.
Для обращения к некоторым из других вещей, Вы сделали:
net.ipv4.tcp_synack_retries:- Увеличение этого не будет иметь никакого положительного влияния для тех входящих соединений, которые имитируются, ни для любого, которые получают cookie SYN вместо состояния серверной стороны (никакие повторения для них любой).
- Для входящих имитировавших соединений увеличиваясь это увеличивает число пакетов, которые Вы отправляете в поддельный адрес и возможно количество времени, которое, который имитировал адрес, остается в Вашей таблице соединений (это могло быть значительным отрицательным эффектом).
- Под нормальной нагрузкой / количество входящих соединений, чем выше это, тем более вероятно Вы к быстро / успешно, завершают соединения по ссылкам то отбрасывание пакеты. Существует убывающая доходность для увеличения этого.
net.ipv4.tcp_syn_retries: Изменение этого не может иметь никакого эффекта на входящие соединения (это только влияет на исходящие соединения),
Другие переменные Вы упоминаете, что я не исследовал, но я подозреваю, что ответы на Ваш вопрос в значительной степени прямо здесь.
Если Вы не лавинно рассылаемый SYN, и машина является быстро реагирующей к не-HTTP-соединениям (например, SSH), я думаю, что существует, вероятно, сетевая проблема, и Вы должны сделать, чтобы сетевой инженер помог Вам посмотреть на него. Если машина обычно безразлична, даже когда Вы не лавинно рассылаемый SYN, это походит на серьезную проблему загрузки, если это влияет на создание соединений TCP (довольно низкий уровень и неинтенсивный ресурс)
Я столкнулся с точно такой же проблемой при новой установке Ubuntu Oneiric 11.10 на веб-сервере (apache2) с сильно загруженным веб-сайтом. В Ubuntu Oneiric 11.10 синхронные файлы cookie были включены по умолчанию.
У меня были те же сообщения ядра, в которых говорилось о возможной атаке SYN-флуда на порт веб-сервера:
ядро: [739408.882650] TCP: Возможное SYN-флуд на порт 80. Отправка файлов cookie.
В то же время я был почти уверен, что нападения не было. Эти сообщения возвращались с интервалом в 5 минут. Это было похоже на просмотр нагрузки, потому что злоумышленник все время будет поддерживать высокую нагрузку, пытаясь заставить сервер перестать отвечать на запросы.
Настройка параметра net.ipv4.tcp_max_syn_backlog не привела к улучшению - сообщения продолжались с той же скоростью. тот факт, что количество соединений SYN_RECV всегда было очень низким (в моем случае менее 250), был индикатором того, что должен быть какой-то другой параметр, который отвечает за это сообщение.
Я нашел это сообщение об ошибке https://bugzilla.redhat.com/show_bug.cgi?id=734991 на сайте красной шляпы, в котором говорится, что сообщение ядра могло быть результатом ошибка (или неправильная конфигурация) на стороне приложения. Конечно, сообщение журнала вводит в заблуждение! Поскольку в этом случае отвечает не параметр ядра, а параметр вашего приложения, передаваемый ядру.
Поэтому мы также должны взглянуть на параметры конфигурации нашего приложения веб-сервера. Возьмите документы apache и перейдите по адресу http://httpd.apache.org/docs/2.0/mod/mpm_common. html # listenbacklog
Значение параметра ListenBacklog по умолчанию - 511. (Это соответствует количеству подключений, которые вы наблюдали на своем сервере Red Hat. Возможно, на другом сервере настроено меньшее число .)
Apache имеет собственный параметр конфигурации для очереди невыполненных работ для входящих соединений. если у вас много входящих подключений, и в любой момент (как раз случайным образом) они прибывают все вместе почти одновременно, так что веб-сервер не может обслуживать их достаточно быстро надлежащим образом, ваш бэклог будет будет заполнено 511 соединений, и ядро выдаст вышеуказанное сообщение о возможной атаке SYN flood.
Чтобы решить эту проблему, я добавляю следующую строку в /etc/apache2/ports.conf или в один из других файлов .conf, который будет загружен apache ( /etc/apache2/apache2.conf также должно быть в порядке):
ListenBackLog 5000
, вам также следует установить net.ipv4.tcp_max_syn_backlog до разумного значения. Насколько я понимаю, максимум ядра ограничивает значение, которое вы сможете настроить в конфигурации apache. так что запустите:
sudo sysctl -w net.ipv4.tcp_max_syn_backlog=5000
После настройки конфигурации не забудьте перезапустить apache:
sudo service apache2 restart ( or sudo /etc/init.d/apache2 restart )
В моем случае это изменение конфигурации немедленно остановило предупреждения ядра. Я могу воспроизвести сообщения, установив низкое значение ListenBackLog в конфигурации apache.
максимум ядра ограничивает значение, которое вы сможете настроить в конфигурации apache. так что запустите:sudo sysctl -w net.ipv4.tcp_max_syn_backlog=5000
После настройки конфигурации не забудьте перезапустить apache:
sudo service apache2 restart ( or sudo /etc/init.d/apache2 restart )
В моем случае это изменение конфигурации немедленно остановило предупреждения ядра. Я могу воспроизвести сообщения, установив низкое значение ListenBackLog в конфигурации apache.
максимум ядра ограничивает значение, которое вы сможете настроить в конфигурации apache. так что запустите:sudo sysctl -w net.ipv4.tcp_max_syn_backlog=5000
После настройки конфигурации не забудьте перезапустить apache:
sudo service apache2 restart ( or sudo /etc/init.d/apache2 restart )
В моем случае это изменение конфигурации немедленно остановило предупреждения ядра. Я могу воспроизвести сообщения, установив низкое значение ListenBackLog в конфигурации apache.
После некоторых тестов с ядром 3.4.9 количество соединений SYN_RECV в netstat зависит от
/ proc / sys / net / core / somaxconnс округлением до следующей степени 2 (например, 128 -> 256)- 75%
/ proc / sys / net / ipv4 / tcp_max_syn_backlog, если для/ proc / sys / net / ipv4 / tcp_syncookiesустановлено значение0или 100%, если/ proc / sys / net / ipv4 / tcp_syncookiesустановлен на1 ListenBackLogв конфигурации apache округлено до следующего степень 2 (например, 128 -> 256)
используется минимум каждого из этих параметров. После изменения somaxconn или ListenBackLog необходимо перезапустить apache.
И после увеличения tcp_max_syn_backlog apache также должен быть перезапущен.
Без tcp_syncookies apache блокирует, почему в этом случае только 75% tcp_max_syn_backlog является пределом, странно. и увеличение этого параметра увеличивает количество соединений SYN_RECV до 100% от старого значения без перезапуска apache.