Re: man PF :)
Matvey Gladkikh -> Artem Chuprina @ Wed, 18 Oct 2006 00:28:55 +0400:
>> Непонятно, на чем synproxy съест процессор. В память я б еще
>> поверил... И то вроде бы ровно те же расходы. Может быть, у прокси
>> даже меньше - ему только случайное начальное число генерировать, а
>> синкукам еще и куку.
>>
>> Единственное - опять перестал понимать, каким образом он при этом
>> защищает другую машину. За SYN+ACK же при этом надо к ней сходить?
>> Ограничить скорость и бэклог у себя держать? А есть уверенность, что
>> бэклог у него лучше, чем у той другой машины?
MG> man PF :)
MG> SYN PROXY
MG> By default, pf(4) passes packets that are part of a tcp(4)
MG> handshake be- tween the endpoints. The synproxy state option
MG> can be used to cause pf(4) itself to complete the handshake
MG> with the active endpoint, perform a handshake with the passive
MG> endpoint, and then forward packets between the endpoints.
MG> No packets are sent to the passive endpoint before the active
MG> endpoint has completed the handshake, hence so-called SYN
MG> floods with spoofed source addresses will not reach the
MG> passive endpoint, as the sender can't complete the handshake.
MG> The proxy is transparent to both endpoints, they each see a
MG> single con- nection from/to the other endpoint. pf(4) chooses
MG> random initial se- quence numbers for both handshakes. Once
MG> the handshakes are completed, the sequence number modulators
MG> (see previous section) are used to trans- late further packets
MG> of the connection. Hence, synproxy state includes modulate
MG> state and keep state.
Ага, т.е. он тратит процессор не только на хендшейк, но и на всю
сессию. И некоторое количество памяти на все установленные сессии.
Впрочем, это слезы.
Да, пожалуй, задачу защиты слабенькой машинки на толстом канале pf
решает получше, чем iptables...
--
Artem Chuprina
RFC2822: <ran{}ran.pp.ru> Jabber: ran@jabber.ran.pp.ru
Дело говоришь!
Теперь делай его.
Кнышев.
Reply to: