информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Spanning Tree Protocol: недокументированное применениеВсе любят мед
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Крупный взлом GoDaddy 
 Просроченный сертификат ломает... 
 Phrack #70/0x46 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / site updates
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
варианты: google -> tcp снижение скорости потока rfc; TCP Selective ACK 04.10.08 20:29  Число просмотров: 2512
Автор: 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
<site updates>
И еще одна дырка в ключевом интернет-протоколе 02.10.08 11:25  
Publisher: dl <Dmitry Leonov>
<"чистая" ссылка>
И еще одна дырка в ключевом интернет-протоколе
The Register http://www.theregister.co.uk/2008/10/01/fundamental_net_vuln/

Этот год оказался урожайным на принципиальные уязвимости, заложенные отцами-основателями в ключевые сетевые протоколы. На сей раз очередь дошла до протокола TCP и нового класса DoS-атак, которые способны при небольшой толщине канала атакующего эффективно парализовать сервер либо маршрутизатор, причем эффект сохраняется и после окончания воздействия (поскольку в системе жертвы просто заканчиваются ресурсы и она уходит в себя).
Роберт Ли (Robert E. Lee), руководитель подразделения безопасности шведской компании Outpost24, сообщил, что он и его коллега Джек Луис (Jack Louis) обнаружили уязвимость еще в 2005, но решили придержать информацию в надежде обнаружить обходные пути. Однако, окончательно упершись лбом в стенку, они решили обнародовать эти сведения. В течение последнего месяца были проинформированы основные производители операционных систем, маршрутизаторов и межсетевых экранов. В настоящее...

Полный текст
Если я правильно понял ангельский, у самого атакующего с... 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 не посылает и оставляет соединение полуоткрытым. И так тысячу миллионов раз. Сам он, конечно, в своей реализации стека про эти полуоткрытые должен сразу забывать.
Хотя где-то это я уже видел, хе-хе.
Ну дык синфлуду поболе чем 10 лет 03.10.08 21:58  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>


http://en.wikipedia.org/wiki/SYN_flooding
Угу, и от него защищается любой мальски себя уважающий файрвол. Раз такие большие пацаны расшумелись - наверное правда что-то нетривиальное. Или (хотя маловероятно) - самореклама 03.10.08 22:22  
Автор: Ustin <Ustin> Статус: Elderman
Отредактировано 03.10.08 22:23  Количество правок: 1
<"чистая" ссылка>
1  |  2 >>  »  






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2021 Dmitry Leonov   Page build time: 1 s   Design: Vadim Derkach