Мои вопросы:
1.) Каков рекомендуемый «SYN PROXY SERVER» для фильтрации фиктивных SYN-атак и пересылки только «подтвержденных» действительных соединений на хост позади него (для защиты). Я ищу этот термин, но не нашел прямых обращений / продуктов, желательно с открытым исходным кодом / бесплатно?
2.) Если нет «готовых» прокси-серверов Syn, как я могу создать свой собственный (с iptables?)
3.) Рекомендуются ли и полезны ли прокси-серверы Syn? У кого-нибудь есть опыт работы с этим? (В противном случае я мог бы вам использовать файлы cookie ...)
Вы можете заменить процессорное время памятью, используя прокси-сервер syn, который добавляет секрет к адресу сокета и вычисляет его хэш, который используется как начальный порядковый номер сервера для TCP-соединения.
Никакие записи для полуоткрытых соединений не будут добавлены в таблицу состояний.
Если приходит пакет (с установленным флагом ack), номер подтверждения, отправленный от клиента, минус 1, будет сравниваться с хешем адреса сокета, соединенного с секретом.
Если числа не совпадают, пакет будет отброшен.
Нет ограничения на количество полуоткрытых соединений, только скорость соединения зависит от мощности процессора.
Важно понимать, что SYN-cookie позволяет серверу отвечать на начальный SYN без создания записи в таблице потоков; он потребляет меньше ресурсов и поддерживает ваш сервер в сети; повышение производительности до 20 раз является обычным явлением!
Вам действительно стоит прочитать эти справочные статьи; SYNPROXY действительно стоит попробовать.
http://rhelblog.redhat.com/2014/04/11/mitigate-tcp-syn-flood-attacks-with-red-hat-enterprise-linux-7-beta/ https://r00t-services.net/knowledgebase/14/Homemade-DDoS-Protection-Using-IPTables-SYNPROXY.html
Когда был задан этот вопрос, вероятно, не было прокси TCP SYN с файлами cookie SYN с открытым исходным кодом (вероятно, был OpenBSD PF, но он использует кеш SYN вместо файлов cookie SYN). Однако теперь есть SYN-прокси netfilter: https://lwn.net/Articles/563151/
В качестве альтернативы этому SYN-прокси netfilter вы можете написать свой собственный. Я сделал это. Моя реализация - это 9000 строк кода основного компонента и 17 000 строк кода вспомогательной библиотеки, написанного на языке C. Счетчик строк включает очень тщательные модульные тесты. Я не рекомендую этот подход «кодируйте свой собственный» для производственных целей, но если у вас есть свободное время, создание собственного SYN-прокси может быть хорошим способом узнать много нового о TCP. Я выполнил свою реализацию чуть больше месяца.
В прокси-сервере netfilter SYN, по-видимому, некоторое время назад была ошибка, из-за которой пакет TCP RST не был должным образом модифицирован, чтобы быть принятым хостом, открывшим соединение. Таким образом, если вам удалось прокси-соединение с прокси-сервером SYN, но другая конечная точка не приняла его, соединение не было закрыто должным образом, чтобы инициирующая конечная точка это заметила. Я не уверен, исправили ли они ошибку сейчас.
Что касается моей рекомендации, я бы порекомендовал запускать хосты конечных точек с поддержкой TCP SYN cookie. Это делает SYN-прокси устаревшим. Если вам абсолютно необходимо запускать хосты конечных точек, у которых нет поддержки SYN cookie, тогда SYN-прокси может быть хорошей идеей. Кроме того, если вы запустите брандмауэр, он создаст новую цель для исчерпания ресурсов: не исчерпайте ресурсы хоста конечной точки, а вместо этого истощите ресурсы брандмауэра. У брандмауэра нет другого способа защитить себя, кроме правильного SYN-прокси с SYN cookie. Итак, если вы используете брандмауэр, подумайте о тех, которые поддерживают прокси TCP SYN. PF OpenBSD имеет SYN-прокси с SYN-кешем, который уязвим для атак из-за исчерпания ресурсов, хотя и не так уязвим, как брандмауэр без SYN-кеша. В Linux iptables можно настроить с помощью прокси-модуля SYN таким образом, чтобы использовать файлы cookie SYN и, таким образом, он не уязвим для атаки из-за исчерпания ресурсов.
Прокси-сервер SYN - это не что иное, как хост-бастион, который настроен для обработки огромного количества входящих наполовину созданных TCP-соединений и передает только завершенные. Честно говоря, я понятия не имею, зачем вам его использовать; они по-прежнему уязвимы к сбоям из-за исчерпания ресурсов (у них все еще есть конечный объем пространства состояний) и, следовательно, не масштабируются так же хорошо, как хорошая реализация SYN cookie.
Не могли бы вы поделиться своими рекомендациями относительно прокси-сервера SYN?