On Tue, Oct 17, 2006 at 09:00:15PM +0400, Ed wrote:
> Artem Chuprina wrote:
>
> >MG> tcp syn proxy проверка валидности (досягаемости начального узла /
> >MG> инструмент при проверке на спуф).
> >
> >Не понял... Насколько я представляю себе устройство современных NAT'ов,
> >если к тебе прилетел TCP SYN, единственное, как ты можешь проверить
> >досягаемость узла - это (вообще говоря, неоднократно) отправить обратно
> >SYN+ACK и подождать, что пришлют в ответ - продолжение сессии, ICMP
> >чего-нибудь-unreacheable, TCP RST или вообще проигнорируют. Причем
> >отправить SYN+ACK может только тот сервис, который там висит - у
> >файрвола этот номер не пройдет.
> >
> >
>
> я специально посмотрел - единственное правильное, что сказал однофамилец
> джона. в openbsd pf действиттельно может принимать соединения и отдавать
> их дальше только после установки соединения.
Да вы начинаете сечь фишку :)
>
> в принципе интересно, хотя проц должно грузить - но всё равно
> производительнее будет, чем аналогичное userspace решение. с другой
> стороны непонятно чем syncookies не нравится - при хорошем флуде
> syn-пакетами сервер будет работать в общем-то нормально, а synproxy
> съест процессор и устроит dos.
P.S. проц не грузит. скорее вы просядете по прерываниям к сетевой карте
но! :) в режиме поллинга да еще и с pfsync + carp есть маза разрулить
гигантские объемы агрессивного трафа кластером PF. (Кстати вот еще о чем можно
поговорить - пример такой реализации синхронизации стейтов между 10ю фаерволами
аля pfsync в линуксе в студию!!!! :) )
при хорошей атаке синкуки вам не помогут
достаточно вспомнить принцип их работы и сколько лажи уже с ними отрыли.
когда очередь syn забита предлагается хешировать новые сины и отправлять синаки
пройдет немало времени пока валидизированному таким механизмом запросу
удастся прорвется через забитую очередь к приложению а то и при потере ака
со стороны клиента запрос вообще перейдет в 5тое измерение.
кроме того откройте ман tcp - синкуки нарушение протокола и **не**
рекомендуются.
tcp_syncookies
Enable TCP syncookies. The kernel must be compiled with
CONFIG_SYN_COOKIES. Send out syncookies when the
syn backlog queue of a socket overflows. The syncookies feature
attempts to protect a socket from a SYN
flood attack. This should be used as a last resort, if at all.
This is a violation of the TCP protocol,
and conflicts with other areas of TCP such as TCP extensions.
It can cause problems for clients and
relays. It is not recommended as a tuning mechanism for heavily
loaded servers to help with overloaded or
misconfigured conditions. For recommended alternatives see
tcp_max_syn_backlog, tcp_synack_retries,
tcp_abort_on_overflow.
**проверьте на практике**.
sysctl -a |grep tcp
net.ipv4.tcp_max_syn_backlog покажет вам ничтожный размер вашей очереди которую
бесполезно увеличивать.
Use PF!
OpenBSD PF is your familly's **only** line of deffence. :)
--
Matvey Gladkikh
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
