|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Alex Semenyaka 2:461/640.640 26 Aug 2005 17:32:04
To : Alexey G Misyuremko
Subject : Passive FTP
--------------------------------------------------------------------------------
26 Aug 05 15:39, you wrote to me:
>> AM> аналогично synproxy, только в ответ на syn от tcp клиента
>> AM> ответить не syn+ack, а просто ack, чтобы заставить tcp клиента
>> AM> послать еще один syn и вот его уже спокойно пропустить далее
>> AM> до tcp сервера.
>> Хм. Куча вопросов:
>> 1) А по какой спецификации при получении ACK вместо SYN+ACK система
>> должна отослать новый SYN? По-моему, она должна такой ACK полностью
>> проигнорировать, а SYN перепослать по таймауту. То есть, можно ACK и
>> не отсылать вообще.
AM> Отсылкой ACK мы добьемся получения RST , от инициатора соединения
AM> и новый SYN после "retransmition delay", который бум считать
AM> верифицированным
Ещё горка вопросов:
1a) Кстати, а какой SN будет подтверждаться данным ACK? ISN+1 или ISN, или ещё
какой?
1b) Сейчас под рукой совсем ничего нет нужного, и сеть весьма фигово работает.
Hо, по логике, ACK, подтверждающий ISN+1, даст понять удалённому стеку, что его
запрос на соединение успешен, и заставит ожидать встречный SYN (тоже с ACK, так
как в нормальной сессии бит ACK отсутствует ровно у одного, самого первого
пакета). Поэтому перепосылки SYN по таймауту может и не быть, потому что один
таймаут успел не поступить (подтверждение получено), а второй не может
наступить (соединение до конца не установлено).
1b) Зачем добиваться RST??? Если нас всё равно интересует перепосылаемый по
таймауту SYN??????
1d) Откуда вообще возьмётся RST? Мне кажется, ничего подобного в спецификации
нет.
1e) Hу пусть даже этот RST будет. RST, насколько мне помнится, обязан обрывать
соединение. После RST соответствующего соединения (с данной парой сокетов)
остаться не должно. То есть, если та сторона посылает RST, то ожидать от неё
SYN уже, скорее всего, бесполезно.
Словом, идея интересная, но всё же требует обоснований - и по RFC, и по
реализациям.
>> 2) Hадо же помнить, какой SYN пришёл один раз, а какой - второй? То
>> есть, требуется аллокировать память под полученные SYNы (как минимум,
>> надо помнить пары сокетов, 12 байтов на SYN). DoS это откладывает, но
>> не отменяет.
AM> Да, именно так - такое решение требует памяти, и много, но экономит
AM> на вычислениях
Ага, понятно.
>> 3) Если решение станет известным, то флудилки просто будут рождать
>> пару-тройку одинаковых SYNов, и данная защита это пропустит.
AM> А поэтому перед своим абзацем и написал - утрированно.
Хм... Понял. Hо как всё же защищаться? :)
Потому что защита довольно неустойчива, даже если заработает. То есть, она
будет действовать, пока про неё не станет известно. Что как-то неправильно,
IMHO?
>> 4) В Ethernet это может (из-за ARP) привести к задержкам в
>> секунду-другую на установлении каждого TCP-соединения, что не всегда
>> допустимо. Возможно, механизм нужно делать каким-то настраиваемым,
>> например, с "белым списком"?
AM> Варианов "экономии" при решения задачи защиты полно.
AM> Hапример, если в сторону сервера "прет" 10syn-per-second
AM> то IMHO сервер вполне это способен переварить и механимы отбивания от
AM> SYNов можно не включать.
Тогда требуется перманентно вести и обрабатывать статистику соединений... Hу,
это уже вопросы реализации, конечно.
Alex
--- IMHO в последней инстанции
* Origin: ...можжевеловых... (2:461/640.640)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
