И еще одна дырка в ключевом интернет-протоколе dl // 02.10.08 11:25
Этот год оказался урожайным на принципиальные уязвимости, заложенные отцами-основателями в ключевые сетевые протоколы. [Не забывайте при копировании материала указывать полный адрес источника: //bugtraq.ru/rsn/archive/2008/10/01.html] На сей раз очередь дошла до протокола TCP и нового класса DoS-атак, которые способны при небольшой толщине канала атакующего эффективно парализовать сервер либо маршрутизатор, причем эффект сохраняется и после окончания воздействия (поскольку в системе жертвы просто заканчиваются ресурсы и она уходит в себя).
Роберт Ли (Robert E. Lee), руководитель подразделения безопасности шведской компании Outpost24, сообщил, что он и его коллега Джек Луис (Jack Louis) обнаружили уязвимость еще в 2005, но решили придержать информацию в надежде обнаружить обходные пути. Однако, окончательно упершись лбом в стенку, они решили обнародовать эти сведения. В течение последнего месяца были проинформированы основные производители операционных систем, маршрутизаторов и межсетевых экранов. В настоящее время не существует реализации TCP-стека, свободного от данной уязвимости (проверено было 15 реализаций).
К сожалению, пока не нашлось приемлемого решения проблемы, за исключением полного запрета анонимных соединений, что полностью неприемлемо для большинства приложений. Впрочем, окончательно впадать в панику еще рановато - детали уязвимости еще не обнародованы, и независимого подтверждения не было. Все, что говорят другие эксперты - "да, это может оказаться серьезным".
Если я правильно понял ангельский, у самого атакующего с каналом все в порядке =)) Просто при помощи манипуляции с данными он дает понять ответной стороне, что канал между ними становится все тоньше и тоньше, а скорость все меньше и меньше. И атакуемый хост соглашается подождать... пару лет )) В отличие от синфлуда, с которым сетевые экраны умеют бороться достаточно эффективно на основании формально заданного порога, отражение этой атаки потребует экспертного мнения - порвать конкретное входящее медленное соединение или нет.
Так, уже теплее...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 77718.10.08 14:58 Автор: kstati <Евгений Борисов> Статус: 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
Читайте первоисточники. Иногда информация не то чтобы навиду, но явная. Кратко говоря -- доверительные отношения TCP к клиентам губительны. В первоисточнике есть теория действительно не популярного(но используемого) DoS. ИМХО, это не ново - просто шум.02.10.08 20:31 Автор: kstati <Евгений Борисов> Статус: Elderman
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
Угу, и от него защищается любой мальски себя уважающий файрвол. Раз такие большие пацаны расшумелись - наверное правда что-то нетривиальное. Или (хотя маловероятно) - самореклама03.10.08 22:22 Автор: Ustin <Ustin> Статус: Elderman Отредактировано 03.10.08 22:23 Количество правок: 1
Вот из-за таких шутников вряд ли они раскроют даже общие черты проблемы. Специалисту хватит и поверхностного описания, чтобы независимо установить точную причину.
подробно о проекте
Анализ криптографических сетевых...
