информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Атака на InternetПортрет посетителяSpanning Tree Protocol: недокументированное применение
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Microsoft обещает радикально усилить... 
 Ядро Linux избавляется от российских... 
 20 лет Ubuntu 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / beginners
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Господа, будьте снисходительны, не бросайтесь сразу штрафовать за, как вам кажется, глупые вопросы - beginners на то и beginners.
Этому подвержены не пакеты, а клиентская программа :) Если... 13.05.04 15:37  Число просмотров: 1334
Автор: Ktirf <Æ Rusakov> Статус: Elderman
<"чистая" ссылка>
> > Кроме того, если сервис будет работать по UDP, то
> > теоретически возможно убить клиента соседа одним специально
> > составленным UDP-пакетом, пришедшим якобы от сервера.
>
> А как этого избежать ? Этому подвержены любые UDP-пакеты ?
Этому подвержены не пакеты, а клиентская программа :) Если пакеты принимаются клиентом со всеми возможными проверками на некорректность содержимого, то все будет замечательно - пакет будет просто отброшен. Отличие UDP от TCP в том, что в TCP нужно устанавливать соединение, прежде чем что-то принять от сервера, а для этого нужен больше чем один пакет. Взломщику придется внедряться в установленное соединение со всеми неудобствами этого. А в UDP не нужно, при этом возможность подмены IP-адреса в заголовке никто не отменял. В общем, смотри материалы по атаке Митника (в библиотеке BugTraq.Ru есть про нее).

На самом деле если сервер в той же локалке, то можно прослушать все, что идет к нему и от него, следовательно, протокол работы с сервером, фактически, открыт. Причем не просто протокол, а его конкретная реализация. Даже если клиентские программы тоже имеют закрытые исходники. Очевидный вывод - клиент и сервер должны общаться по зашифрованному каналу. Вывод из вывода - если не пытаться устраивать специальные ухищрения, то UDP можно не рассматривать.
<beginners>
Мозговой штурм - Типичные уязвимости IM 12.05.04 09:18  
Автор: rus_lan Статус: Незарегистрированный пользователь
Отредактировано 12.05.04 13:16  Количество правок: 2
<"чистая" ссылка>
Какие типичные уязвимости имеются у программ типа ICQ (и других чатов) в локальной сети ?
Интересуют именно централизованные IMы, или безсерверные тоже? 12.05.04 17:05  
Автор: Ktirf <Æ Rusakov> Статус: Elderman
<"чистая" ссылка>
> Какие типичные уязвимости имеются у программ типа ICQ (и
> других чатов) в локальной сети ?
В централизованных дырки надо искать не в клиенте, а в сервере. При закрытом протоколе это довольно сложно, но в основном все тоже самое, что и с веб-серверами, например. И вообще с любыми сетевыми службами. Или я не очень понял вопрос?
Специфичной для IMов с сервером является, например, проблема прокидывания некорректного сообщения (сообщения в общем смысле) на целевую машину (с клиентом), используя несовершенство реализации протокола на сервере и(!) доверчивость клиента по отношению к серверу.
Да, интересуют именно централизованные и именно в ЛВС... 13.05.04 06:56  
Автор: rus_lan Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Вопрос возник в связи с необходимостью программно реализовать систему IM . Так как уязвимостей , ИМХО , может быть очень много ( можно вспомнить хотя бы последний асечный вирус - через какую дыру , кстати , он распространялся ? ) , хочется проектировать сразу с учетом требований безопасности . А для этого не хватает информации ...
В ЛВС есть еще одна классическая проблема - прослушивание пакетов соседа 13.05.04 12:38  
Автор: Ktirf <Æ Rusakov> Статус: Elderman
<"чистая" ссылка>
Кроме того, если сервис будет работать по UDP, то теоретически возможно убить клиента соседа одним специально составленным UDP-пакетом, пришедшим якобы от сервера.
Сервер тоже стоит в локалке?
Сервер в той же локалке 13.05.04 14:24  
Автор: rus_lan Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> Кроме того, если сервис будет работать по UDP, то
> теоретически возможно убить клиента соседа одним специально
> составленным UDP-пакетом, пришедшим якобы от сервера.

А как этого избежать ? Этому подвержены любые UDP-пакеты ?
Этому подвержены не пакеты, а клиентская программа :) Если... 13.05.04 15:37  
Автор: Ktirf <Æ Rusakov> Статус: Elderman
<"чистая" ссылка>
> > Кроме того, если сервис будет работать по UDP, то
> > теоретически возможно убить клиента соседа одним специально
> > составленным UDP-пакетом, пришедшим якобы от сервера.
>
> А как этого избежать ? Этому подвержены любые UDP-пакеты ?
Этому подвержены не пакеты, а клиентская программа :) Если пакеты принимаются клиентом со всеми возможными проверками на некорректность содержимого, то все будет замечательно - пакет будет просто отброшен. Отличие UDP от TCP в том, что в TCP нужно устанавливать соединение, прежде чем что-то принять от сервера, а для этого нужен больше чем один пакет. Взломщику придется внедряться в установленное соединение со всеми неудобствами этого. А в UDP не нужно, при этом возможность подмены IP-адреса в заголовке никто не отменял. В общем, смотри материалы по атаке Митника (в библиотеке BugTraq.Ru есть про нее).

На самом деле если сервер в той же локалке, то можно прослушать все, что идет к нему и от него, следовательно, протокол работы с сервером, фактически, открыт. Причем не просто протокол, а его конкретная реализация. Даже если клиентские программы тоже имеют закрытые исходники. Очевидный вывод - клиент и сервер должны общаться по зашифрованному каналу. Вывод из вывода - если не пытаться устраивать специальные ухищрения, то UDP можно не рассматривать.
1




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


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach