информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
За кого нас держат?Где водятся OGRыSpanning Tree Protocol: недокументированное применение
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
 Умер Никлаус Вирт 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / networking
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
I need help по TCP/IP 22.09.02 01:16  Число просмотров: 1225
Автор: dl <Dmitry Leonov>
<"чистая" ссылка>
> Т.е. ты думаешь, что TCP-модуль работает только с номерами
> портов, и не знает, с каким IP адресом установлен
> TCP-сеанc? По-моему это не так. Рассуждая логически: а что
> если на один порт сервера будут коннектиться 2 клиента, и у
> обоих клиентов с их стороны окажутся одинаковые номера
> портов?
> server:25 <- client_1:1055
> server:25 <- client_2:1055
> Тогда TCP-модуль не сможет различить эти 2 сеанса... со
> всеми вытекающими последствиями.

Вообще-то для идентификации сеанса должно хватить знания ISSa и ISSb. Не дело tcp забивать себе голову адресом, у него и поля-то такого нет в заголовках, это осталось на уровне ip.
<networking>
I need help по TCP/IP 21.09.02 00:19  
Автор: PS <PS> Статус: Elderman
<"чистая" ссылка>
Задался на днях таким вопросом: а что будет если если я послал пакет с дестинешен адресом А. а мне пришел ответ с адресом источника В ?

Попытался думать логически. Итак момент посылки опускаем, он нам не нужен, теперь мы получили ответ. Реализация IP смотрит это нам или не нам... да в DEST стоит наш адрес - пропускаем, на адрес источника IP протоколу вообще говоря начихать, далее реализация TCP, даже и не знаю что она может проверять, во всяком случае она посмотрит какому порту предназначен пакет. Такой порт есть, отлично, смотрит сиквенсы, совпадают. Типа, все ОК - пропускает. Про адреса TCP вообще не должно ничего знать, это осталось этажом (вернее протоколом) ниже. Дальше у нас реализация сокетов - ну это вообще тупая штука - ей проверять особо нечего... тоже пропускает. И вот данные в пользовательком приложении.
Так что ли получается ?
Попытался посмотреть как и что реализовано в ядре линуха... одной ночи явно оказалось мало.

Думал провести эксперемент - типа на ходу поменять адрес у одного узла - обломался. Не умею посылать пакеты минуя сокет, а эта гадость запоминает IP адрес на котором он создан, так что после изменения адреса он вообще отказался что либо, куда либо отсылать.

Вообщем есть три пути:
1. Либо мне ответят тут.
2. Либо я продолжу копать ядро.
3. (наиболее вероятный) Заброшу это нафиг ;)
Не пройдет 29.09.02 22:22  
Автор: PS <PS> Статус: Elderman
<"чистая" ссылка>
> Задался на днях таким вопросом: а что будет если если я
> послал пакет с дестинешен адресом А. а мне пришел ответ с
> адресом источника В ?
>

Вообщем, пройти не должен, хотя могу и ошибаться. В линухе такой пакет режится еще на IP уровне.
ipv4/raw.c, __raw_v4_lookup() содержит такой код:
if( ... s->daddr != raddr ...) , где s - указатель на sock структуру, а raddr - адрес источника из хидера IP пакета.
Эта ф-ия вызывается из raw_v4_input, которая в свою очередь вызывается из ip_local_deliver_finish /ip_input.c/, которая вызывается ip_local_deliver ...
Вообщем похоже, что это именно то место.

А вообще сетевая часть ядра построена как спагетти :( Сокеты проходят белыми нитками по всем уровням - хотя, по идеи, это всего лишь программный интерфейс. Здесь же - это универсальное хранилище всевозможной сетевой информации. Все уровни знают обо всех - вообщем катастрофа.
I need help по TCP/IP 22.09.02 00:09  
Автор: :-) <:-)> Статус: Elderman
<"чистая" ссылка>
> далее реализация TCP, даже и не знаю что она
> может проверять, во всяком случае она посмотрит какому
> порту предназначен пакет. Такой порт есть, отлично, смотрит
> сиквенсы, совпадают. Типа, все ОК - пропускает. Про адреса
> TCP вообще не должно ничего знать, это осталось этажом
> (вернее протоколом) ниже.
Т.е. ты думаешь, что TCP-модуль работает только с номерами портов, и не знает, с каким IP адресом установлен TCP-сеанc? По-моему это не так. Рассуждая логически: а что если на один порт сервера будут коннектиться 2 клиента, и у обоих клиентов с их стороны окажутся одинаковые номера портов?
server:25 <- client_1:1055
server:25 <- client_2:1055
Тогда TCP-модуль не сможет различить эти 2 сеанса... со всеми вытекающими последствиями.

> Так что ли получается ?
Наверное TCP-модуль просто определит, что TCP-сеанс с данным IP не существует, и пошлет ему нафиг пакет с флагом RST.

> Думал провести эксперемент - типа на ходу поменять адрес у
> одного узла - обломался. Не умею посылать пакеты минуя
> сокет,
Не вижу никаких препятствий... Сырые сокеты в *nix, WinPcap для виндов. IMHO это легче, чем ковыряться в ядре.
I need help по TCP/IP 22.09.02 01:16  
Автор: dl <Dmitry Leonov>
<"чистая" ссылка>
> Т.е. ты думаешь, что TCP-модуль работает только с номерами
> портов, и не знает, с каким IP адресом установлен
> TCP-сеанc? По-моему это не так. Рассуждая логически: а что
> если на один порт сервера будут коннектиться 2 клиента, и у
> обоих клиентов с их стороны окажутся одинаковые номера
> портов?
> server:25 <- client_1:1055
> server:25 <- client_2:1055
> Тогда TCP-модуль не сможет различить эти 2 сеанса... со
> всеми вытекающими последствиями.

Вообще-то для идентификации сеанса должно хватить знания ISSa и ISSb. Не дело tcp забивать себе голову адресом, у него и поля-то такого нет в заголовках, это осталось на уровне ip.
I need help по TCP/IP 22.09.02 18:31  
Автор: :-) <:-)> Статус: Elderman
Отредактировано 22.09.02 19:20  Количество правок: 2
<"чистая" ссылка>
> Вообще-то для идентификации сеанса должно хватить знания
> ISSa и ISSb.

Но ведь они могут совпасть у двух сеансов. Вероятность этого конечно мала, но все-таки :)

> Не дело tcp забивать себе голову адресом, у
> него и поля-то такого нет в заголовках, это осталось на
> уровне ip.

Насколько я понял после беглого копания в ядре Линукса, в tcp-ресивер передаются daddr, saddr, ip-опции.
/*
 *	A TCP packet has arrived.
 *		skb->h.raw is the TCP header.
 */
 
int tcp_rcv(struct sk_buff *skb, struct device *dev, struct options *opt,
	__u32 daddr, unsigned short len,
	__u32 saddr, int redo, struct inet_protocol * protocol)

---
Вся инфа о состоянии сеанса (адреса и порты получателя и отправителя, seq, ack, window...) хранится в структуре sock. Как поступивший пакет асоциируется с соответсвующим сокетом? Эты строчка наводит на мысль, что все-таки по IP и порту, а не по seq/ack.
sk = get_tcp_sock(saddr, th->source, daddr, th->dest, dev->pa_addr, skb->redirport);

З.Ы. Осмотр ядра был беглый. Если что не так, ногами не пинать =)
hackzone 21.09.02 18:35  
Автор: koras Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> Вообщем есть три пути:
> 1. Либо мне ответят тут.
> 2. Либо я продолжу копать ядро.
> 3. (наиболее вероятный) Заброшу это нафиг ;)
Почитай на хакзоне статью, атака на ТСР, там достаточно полно описан механизм создания виртуального ТСР канала. А вообщето, чем ковырять ядро, лучше rfc почитай, там понятней :-)))
bugtraq :) 22.09.02 00:57  
Автор: dl <Dmitry Leonov>
Отредактировано 22.09.02 01:00  Количество правок: 1
<"чистая" ссылка>
> Почитай на хакзоне статью, атака на ТСР, там достаточно
> полно описан механизм создания виртуального ТСР канала. А
> вообщето, чем ковырять ядро, лучше rfc почитай, там
> понятней :-)))

Здесь гораздо ближе :)

Правда, в вопросе, как я понимаю, речь совсем о другом - о локальной подмене пакетов, когда модифицируется пришедший пакет с нормальным ISS.

Подмена одного из субъектов TCP-соединения в сети Internet
bugtraq :) 22.09.02 15:45  
Автор: koras Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> > Почитай на хакзоне статью, атака на ТСР, там
> достаточно
> > полно описан механизм создания виртуального ТСР
> канала. А
> > вообщето, чем ковырять ядро, лучше rfc почитай, там
> > понятней :-)))
>
> Здесь гораздо ближе :)
>
Просто я сам ее там читал :-)
> Правда, в вопросе, как я понимаю, речь совсем о другом - о
> локальной подмене пакетов, когда модифицируется пришедший
> пакет с нормальным ISS.
Но механизм организации канала там описан полностью, а подмена, лишь одно из применений
1




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


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