? Медленый старт как защита от DOS [tc]

ИМХО проще фильтром убивать пакеты и не городить огород...:)

работать будет только с честными атакерами )
если атакуюзий использует полноценное пожатие tcp, то да.

> ИМХО проще фильтром убивать пакеты и не городить огород...:)
при убивании пакетов фильтром решается только часть проблеммы - не остылаются ответы. канал между тем остается полностью занятым.
Конечная цель средствами tcp протокола занизить скорость выпуска пакетов с стороны атакующего.

Если он захочет завалить - ему пофиг будет на эту виртуальную ширину канала. Пулять кучу син-пакетов... и пофиг как быстро ты будешь отвечать. канал засрётся один фиг... Да даже пингами завалить можно. самый адекватный способ борьбы - звонок провайдеру с просьбой заблокировать атакующего на пограничном маршрутизаторе и разборка по линии абуза.

хорошие системы для защиты от доса есть далеко не у каждого провайдера.
и зачастую при попытке прикрыть паразитный трафик страдает существенная доля нормальных клиентов.
так что, доверяй но проверяй.

ээээ.... тут подразумевается, что есть один атакующий, который известен... в таком варианте провайдер просто лочит в acl. и ещё раз - атакер, который хочет валить систему, не будет ждать ответов. он будет её валить :) а если есть периодические всплески коннектов с определённых ip - логичнее установить ограничение именно на это. Не более скольки-то соединений с одного хоста.

ну во-первых провайдер ничего не лочит, он на это элементарно не имеет права.
во-вторых, понятие "валить" очень многогранно.

во-первых имеет полное право по запросу клиента. да и по своему личному разумению тоже. обычно оставляют для себя такие возможности в договорах. Например чтоб бороться с эпидемиями типа знаменитого мсбласта. во-вторых именно, что многогранно. Но я слабо себе представляю атакующего, который обращает внимание на ширину канала и ждет полноценного рукопожатия чтоб послать следующий запрос на соединение :) вощем бесполезная дискуссия. я просто высказал своё видение данной проблемы. а каждый сам себе админ.

бред. сам работал на крупном прове, на сапорте. и часто бывало на графике трафа - этакий "быстрорастущий пик" со стороны одного из аплинков - сразу кипиш, флуд, звонок админу. и через несколько минут все фильтруется, все попускается. так что имеем право, еще какое.

> канал между тем остается полностью занятым
С чего вдруг ? А ответы кто будет ждать в течение timeout-а ? Если никто не будет ждать, то где гарантия, что удастся "средствами tcp протокола занизить скорость выпуска пакетов с стороны атакующего" ? (он ведь действует не по правилам)

Всем спасибо! разобрался :)