Комментарии:
 |
Если я правильно понял ангельский, у самого атакующего с... 06.10.08 10:19
Автор: lazy_anty Статус: Незарегистрированный пользователь
|
|
Если я правильно понял ангельский, у самого атакующего с каналом все в порядке =)) Просто при помощи манипуляции с данными он дает понять ответной стороне, что канал между ними становится все тоньше и тоньше, а скорость все меньше и меньше. И атакуемый хост соглашается подождать... пару лет )) В отличие от синфлуда, с которым сетевые экраны умеют бороться достаточно эффективно на основании формально заданного порога, отражение этой атаки потребует экспертного мнения - порвать конкретное входящее медленное соединение или нет.
|
| |
Так, уже теплее... 06.10.08 15:50
Автор: HandleX <Александр М.> Статус: The Elderman
|
|
Ну хорошо, понизили скорость передачи данных для одного конкретного соединения до минимума. Что это даёт? Разве это ухудшит процесс передачи данных для других соедений? Дальше-то что делать с «медляками»? -))
|
| | |
Не ухудшит. Но на непропатченных по количеству соединений... 09.10.08 11:33
Автор: lazy_anty Статус: Незарегистрированный пользователь
|
> конкретного соединения до минимума. Что это даёт? Разве это
> ухудшит процесс передачи данных для других соедений?
Не ухудшит. Но на непропатченных по количеству соединений системах количество соединений быстро исчерпается.
> Дальше-то что делать с «медляками»? -))
А это хозяину атакуемой системы решать, в принципе - может, у него фильма гигабайтная медленно тянется, а мы её автоматом... того...? ;)
|
| | |
каждое tcp-соединение кушает ресурсы. Если в довесок к "медленному" подключению шмякнуть выборочную отправку фрагментов (selective ASK), то кол-во ресурсов на соединение может стать заметным. При большом количестве таких соединений сервер исчерпает ОЗУ. 06.10.08 23:14
Автор: kstati <Евгений Борисов> Статус: Elderman
|
|
|
| | | |
Кстати, а вот снижение скорости потока особым видом ICMP пакетов регулируется? 07.10.08 07:07
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 07.10.08 08:30 Количество правок: 1
|
Я это к тому, что крыжик вендовозного файрвола, отвечающий за разрешение обработки таких пакетов, по умолчанию отключён.
Значит ли это, что венда с включенным файром с такими параметрами не подвержена данному виду атаки?
|
| | | | |
Совершенно верно . Если я не ошибаюсь, то эта проблема решается элементарной блокировкой ICMP type4 (Source Quench Message) Описанном в RFC 777 18.10.08 14:58
Автор: kstati <Евгений Борисов> Статус: Elderman
|
|
|
| | | | | |
Вы меня удивляете. ICMP из внешнего мира лучше вообще... 20.10.08 16:23
Автор: TRESPASSER[CfK] Статус: Незарегистрированный пользователь
|
|
Вы меня удивляете. ICMP из внешнего мира лучше вообще отключать. И большинство так и делает...
|
| | | | | | |
It is not true. For instance, PMTU discovery might be very... 25.10.08 19:21
Автор: void <Grebnev Valery> Статус: Elderman
|
> Вы меня удивляете. ICMP из внешнего мира лучше вообще
> отключать.
It is not true. For instance, PMTU discovery might be very usefull.
ICMP uses type 3, code 4 for this purpose.
И большинство так и делает...
I disagree. For instance you can filter ICMP redirection messages, but leave the rest if needed.
Agree?
|
| | | | | | | |
ok. u r right. 26.10.08 15:13
Автор: trespasser]cfk] Статус: Незарегистрированный пользователь
|
|
|
| | | | | | |
Ой, какие мы гуру! ;) Отключать всё нафиг без разбора )). Посмотрел бы я как ты отлаживаешь запутанный роутинг без того же пинга. 20.10.08 17:26
Автор: kstati <Евгений Борисов> Статус: Elderman
Отредактировано 20.10.08 17:37 Количество правок: 2
|
Все, говоришь, отключают ICMP и ты туда же? ;)
>tracert bugtraq.ru
$traceroute bugtraq.ru
|
| | | | | | | |
На гуру не претендовал. Большинство сайтов которым требуется... 21.10.08 11:36
Автор: TRESPASSER[CfK] Статус: Незарегистрированный пользователь
Отредактировано 21.10.08 11:47 Количество правок: 2
|
> Все, говоришь, отключают ICMP и ты туда же? ;)
> >tracert bugtraq.ru
> $traceroute bugtraq.ru
На гуру не претендовал. Большинство сайтов которым требуется повышенная безопасность блокируют ICMP. А маршрутизация разумеется отлаживается с включенным. Это как debug информация в файле, которая потом удаляется при финальной сборке. =^р
PS по крайней мере флаги типа destination unreachable.
|
| | |
Если их будет много, на сервере достигнется предельное число потоков например. И тут достаточно сложно ИМХО отличить атакующий и честный коннект 06.10.08 18:52
Автор: Ustin <Ustin> Статус: Elderman
|
|
|
|
По ссылке не ходил, и в тексте новости не сказано, в чём суть данной уязвимости. Мож кто скажет в двух словах? 02.10.08 14:22
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 02.10.08 14:25 Количество правок: 1
|
|
Cразу же сяду писать эксплойт :-D (Шутка)
|
| |
Читайте первоисточники. Иногда информация не то чтобы навиду, но явная. Кратко говоря -- доверительные отношения TCP к клиентам губительны. В первоисточнике есть теория действительно не популярного(но используемого) DoS. ИМХО, это не ново - просто шум. 02.10.08 20:31
Автор: kstati <Евгений Борисов> Статус: Elderman
|
|
|
| | |
варианты: google -> tcp снижение скорости потока rfc; TCP Selective ACK 04.10.08 20:29
Автор: kstati <Евгений Борисов> Статус: Elderman
Отредактировано 04.10.08 20:48 Количество правок: 2
|
One technique they describe is to behave as if their connection were getting slower and slower to the point that the TCP stack is tricked into believing it will take years to complete the transmission of data. This forces the TCP stack to keep trying for years to send just a few bytes.
http://erratasec.blogspot.com/2008/10/tcp-dos-probably-real.html
I'm seeing something unexpected, though. When clients are downloading large files, the servers aren't immediately retransmitting the lost packets. The file download past the gap continues for a very long time. So far, I've seen the file download continue for 3-megabytes before the server goes back and fills in the gap. This can be easily 20 seconds later.
http://erratasec.blogspot.com/2008/10/tcp-selective-ack-considered-evil.html
|
| | |
Сходил по ссылке. Как я понял, там написано, что стек TCP... 03.10.08 10:13
Автор: HandleX <Александр М.> Статус: The Elderman
|
Сходил по ссылке. Как я понял, там написано, что стек TCP выделяет память под сущность "Соединение" после (syn, syn-ack, ack) цикла рукопожатия.
Но моей светлой голове непонятно, как сидя на "не очень толстом канале" можно вынудить стек TCP/IP атакуемого хоста навыделять столько памяти под эти сущности, чтобы атакуемый хост сдохх.
|
| | | |
Пусть атакующий последний ack не посылает и оставляет... 03.10.08 19:47
Автор: ZloyShaman <ZloyShaman> Статус: Elderman
|
> Сходил по ссылке. Как я понял, там написано, что стек TCP
> выделяет память под сущность "Соединение" после (syn,
> syn-ack, ack) цикла рукопожатия.
> Но моей светлой голове непонятно, как сидя на "не очень
> толстом канале" можно вынудить стек TCP/IP атакуемого хоста
> навыделять столько памяти под эти сущности, чтобы атакуемый
> хост сдохх.
Пусть атакующий последний ack не посылает и оставляет соединение полуоткрытым. И так тысячу миллионов раз. Сам он, конечно, в своей реализации стека про эти полуоткрытые должен сразу забывать.
Хотя где-то это я уже видел, хе-хе.
|
| | | | | |
Угу, и от него защищается любой мальски себя уважающий файрвол. Раз такие большие пацаны расшумелись - наверное правда что-то нетривиальное. Или (хотя маловероятно) - самореклама 03.10.08 22:22
Автор: Ustin <Ustin> Статус: Elderman
Отредактировано 03.10.08 22:23 Количество правок: 1
|
|
|
| | | | | | |
I think you are right. 25.10.08 19:25
Автор: void <Grebnev Valery> Статус: Elderman
|
|
|
| |
Вот из-за таких шутников вряд ли они раскроют даже общие... 02.10.08 14:32
Автор: sattva Статус: Незарегистрированный пользователь
|
> Cразу же сяду писать эксплойт :-D (Шутка)
Вот из-за таких шутников вряд ли они раскроют даже общие черты проблемы. Специалисту хватит и поверхностного описания, чтобы независимо установить точную причину.
|
|
