Re: flood protect
Ed -> debian-russian@lists.debian.org @ Tue, 17 Oct 2006 21:02:51 +0400:
>> MG> tcp syn proxy проверка валидности (досягаемости начального узла /
>> MG> инструмент при проверке на спуф).
>>
>>Не понял... Насколько я представляю себе устройство современных NAT'ов,
>>если к тебе прилетел TCP SYN, единственное, как ты можешь проверить
>>досягаемость узла - это (вообще говоря, неоднократно) отправить обратно
>>SYN+ACK и подождать, что пришлют в ответ - продолжение сессии, ICMP
>>чего-нибудь-unreacheable, TCP RST или вообще проигнорируют. Причем
>>отправить SYN+ACK может только тот сервис, который там висит - у
>>файрвола этот номер не пройдет.
>>
>>
E> я специально посмотрел - единственное правильное, что сказал
E> однофамилец джона. в openbsd pf действиттельно может принимать
E> соединения и отдавать их дальше только после установки соединения.
E> в принципе интересно, хотя проц должно грузить - но всё равно
E> производительнее будет, чем аналогичное userspace решение. с другой
E> стороны непонятно чем syncookies не нравится - при хорошем флуде
E> syn-пакетами сервер будет работать в общем-то нормально, а synproxy
E> съест процессор и устроит dos.
Непонятно, на чем synproxy съест процессор. В память я б еще
поверил... И то вроде бы ровно те же расходы. Может быть, у прокси
даже меньше - ему только случайное начальное число генерировать, а
синкукам еще и куку.
Единственное - опять перестал понимать, каким образом он при этом
защищает другую машину. За SYN+ACK же при этом надо к ней сходить?
Ограничить скорость и бэклог у себя держать? А есть уверенность, что
бэклог у него лучше, чем у той другой машины?
--
Artem Chuprina
RFC2822: <ran{}ran.pp.ru> Jabber: ran@jabber.ran.pp.ru
Проспрягайте, хлопцы, коней...
М. Черкашин
Reply to: