Лучшая альтернатива для tcp_syncookies в Linux
В целях предотвращения DDOS-атак я следовал советам оставить значение /proc/sys/net/ipv4/tcp_syncookies равным 1 в моем окне linux, чтобы включить TCP syncookies.
Однако, когда я смотрю на этот URL: http://ckdake.com/content/2007/disadvantages-of-tcp-syn-cookies.html
Это говорит мне, что если я включу tcp_syncookies, то половина функций tcp, включая управление большими окнами, будет отключена, что может снизить производительность.
В другом месте я читал, что одна из целей файлов cookie cookie заключается в расширении буфера журналов синхронизации tcp за его верхний предел (через /proc/sys/net/ipv4/tcp_max_syn_backlog), когда поступает больше пакетов, чтобы пакеты не отбрасывались.
Я хочу иметь возможность отключить синхронизирующие cookie-файлы, чтобы в полной мере использовать преимущества tcp, ускорить работу моего сервера и избежать атак DDOS. Я могу легко увеличить буфер синхронизации и максимальное количество соединений, но я думаю, что в этот момент у меня не хватит памяти, если я зайду слишком высоко.
Есть ли у кого-нибудь хороший альтернативный метод для синхронизации куки на тяжелом сервере без потенциальной атаки DDOS? Я хочу наслаждаться функциями TCP и очень быстро обслуживать пользователей.
3 ответа
Ubuntu 10.04 имеет настройку по умолчанию "sysctl.d/10-network-security.conf" ниже:
# Turn on SYN-flood protections. Starting with 2.6.26, there is no loss
# of TCP functionality/features under normal conditions. When flood
# protections kick in under high unanswered-SYN load, the system
# should remain more stable, with a trade off of some loss of TCP
# functionality/features (e.g. TCP Window scaling).
net.ipv4.tcp_syncookies=1
По-видимому, tcp_syncookies дает больше преимуществ, чем недостатков.
Вместо типичных предположений о случайных блогах, возможно, мы могли бы обратиться к " источнику":
С обновлениями для IPv6 и современными опциональными схемами TCP, Syncookies, по-видимому, продолжают приносить сладкое облегчение в своей несколько эзотерической нише сетевой безопасности.
Связанная статья цитирует некоторые эксперименты и делает некоторые выводы:
Вилли Тарро: Мои тесты на AMD LX800 с max_syn_backlog на 63000 на обратном прокси-сервере HTTP заключались в том, чтобы внедрить 250 хитов / с легитимного трафика с шумом 8000 SYN/ с.[..] Без файлов cookie SYN среднее время ответа составляло примерно 1,5 секунды и нестабильно (из-за повторных передач), а процессор был установлен на 60%. При включенных файлах SYN cookie время отклика сократилось только до 12-15 мс, а загрузка ЦП возросла до 70%. Разница появляется при более высокой допустимой скорости трафика.
Росс Вандегрифт: при отсутствии потока SYN сервер обрабатывает 750 HTTP-запросов в секунду, измеряемых с помощью httping в режиме потока. С tcp_max_syn_backlog по умолчанию, равным 1024, я могу тривиально предотвратить любые входящие клиентские соединения с помощью двух потоков синхронизации. Включение tcp_syncookies возвращает обработку соединения до 725 выборок в секунду.
Эти данные убедительно подтверждают постоянную ценность syncookie, и эта позиция, кажется, выиграла день. Патчи synvookie IPv6 теперь ставятся в очередь в дереве разработки сети 2.6.26.
Кроме того, согласно документации CentOS, это используется адаптивным способом, возможно, чтобы избежать нарушения законного трафика:
Если достигнут номер, заданный в tcp_max_syn_backlog, этот параметр включается, так что ваш сервер не является недоступным из-за соединений, ожидающих ACK, который никогда не будет получен.
Отредактируйте файл /etc/sysctl.conf, запустите:
# vi /etc/sysctl.conf
Добавить следующую запись:
net.ipv4.tcp_syncookies = 1
Сохраните и закройте файл. Чтобы перезагрузить изменение, введите:
# sysctl -p