как жаль что ни кто не знает , ведь єто должно работать

Не понял вопроса, обратный адрес ЧЕГО ?
Ты про SMTP или про HTTP ?

Date : 03.04.2004 Time : 15:00
From : wizard
http://forum.antichat.ru/cgi-bin....;t=1907

Date : 03.04.2004 Time : 15:00
To : Rabbit
елементарно=)

Date : 03.04.2004 Time : 15:01
To : Rabbit
есть сокс и нттп проксы

Date : 03.04.2004 Time : 15:01
To : Rabbit
вот тебе хттп-прокса 193.170.189.154 кажется еще рабочая порт 80 ставишь в браузере

Date : 03.04.2004 Time : 15:02
To : Rabbit
если ты поставишь этот адрес то такой и будет = т.е. в рамках поставленной задачи это исчерпивающий
ответ=)

Date : 03.04.2004 Time : 15:03
From : wizard
не парень ті гониш , єто совершенно не то , ті прочитай внимательней я говорю ч тобы я сам мог
проставить обратный адрес например такой 111,111,111,111

Date : 03.04.2004 Time : 15:03
To : Rabbit
я же те сказал = какой вопрос такой ответ

Date : 03.04.2004 Time : 15:03
To : Rabbit
формулируй правильно

Date : 03.04.2004 Time : 15:05
To : Rabbit
то что ты хочешь для ТСП-ИП соединений невозможно. можно подделывать только СИНы для ТСП или датаграмы
(там проще)

Date : 03.04.2004 Time : 15:05
From : wizard
надо подменить в поле обратный айпи адрес на такой 123.123.123.123

Date : 03.04.2004 Time : 15:05
To : Rabbit
ТСП протокол требует двустороннего согласования

Date : 03.04.2004 Time : 15:05
To : Rabbit
датаграмы = нет

Date : 03.04.2004 Time : 15:06
From : wizard
наченаю доганять

=============================================
P.S. Напрасно я те помог. Ты оказывается не только полный ламо но и еще воинственно настроенный.

мега тема, чуваки с первого взгляда не то ip сендера надо поменять, а со второго доганяет параноей,
что эт вообще за подмену пакетов вопрос. хрен угадаешь. rabbit уже рассказал за все провсе, но вот я бы хотел
сказать, что эт еще не все, хотя то, что я скажу - это на еще один неслабый оффтоп потянет, но я все же попробую.
значит так: все у нас завязано на tcp/ip, и в сетях, в которых мы находимся он является базовым, и все прилажения
его используют и работают под ним, это мы знаем и так. Для того, что бы понять всю эту ерунду с адрессацией,
следует посмотреть rfc по оному протоколу. а там явным образом нам говорят, что пакет (наш, анатомируемый
ip обязательно должен иметь блок с source и блок с destination: первый сообщает прилажению/серверу/чему_угодно
адресс отправителя ip пакета, т.е. содержит надлежащий отправителю реальный адресс, а второй - указывает на адресс
того самого прилажения, которое и принимает этот пакет с нашего же адресса: здесь ничего не вызывает сомнений, все просто,
и если бы не было этих правил - у нас бы ничего не работало. любой прокси, самый банальный - ему пофигу, что вы шлете и зачем ,
но он просто обязан знать, откуда пришло и куда нужно отправить, иначе он сойдет с ума. rabbit сказал о том, что tcp/ip требует двухстороннего
согласования. должно быть так: мы хотим воспользоваться коммандой... trace route, она же tracert - коммандой трассировки маршрутов tcp/ip.
тогда печатаем в консольке tracert 192.168.0.1, например.
Здесь мы реально задаем службе нужный нам дестинэйшн пакета, а сорс она и сама возьмет из окружения, т.е. из системы.
вот и затусили, все реально. что там будет дальше с трассеровкой - не имеет для нас никакого значения. если когонить смущает трасерт,
приколитесь телнетом. Если тот же самый телнет-сеанс логируется, то тогда мы увидем адресс зателнетенного сендера, т.к. он был указан,
ну и естесно можем как минимум предположить, что адресс получателя был наш все.
нам нужно узнать, есть ли возможность поменять сорс-адресс при отсылке пакета на произвольный? и если есть, то как это разрулить?
да можно делать все, жаль, что только обратное сальто оч трудно дается , а променять содержимое пакета - вполне реально.
как уже говорил и буду - что бы не парицца в сабже, желательно знать как можно глубже структуру протокола. но мы сейчас не об этом,
а о том, как нам самим программировать пакеты, а делаецца в сети этот злободром сплошь и рядом: все мы каждый день слышим о крутейших
dos~ах, которые валят сервера. а в этих самых аттаках(я не учитываю действия червей и тупо_пакетный_флуд) часто применим спуфинг,
т.е. подмена адрессов пакета, где одни сервера выдают себя за другие, аттакуя запросами третьи, а третьи отвечают этим вторым, втягивая
их тем самым в усиление флудирования. нас это не интересует. хотите знать больше? как это работает? тогда ищите в сети доки по tcp/ip,
спуфингу и сами утилиты, помогающие реализовать `ручное` программирование пакетов. ( уверен, найдете в изобилии всякого хлама, типа
dnshijacker'ов, gspoof'ов, sing'ов )
так же хочу сказать, что спуф разруливается и на днс-сервера, естесно, если кто не предпологал: у этой фичи реально очень много перлов.
так, легко отравляется кэш прокси твоего прова, что бы всеобратившиеся юзверы из вашей сети смотрели вместо яндекса какую нить ерунду,
типа мега-портала о собаках или енотах аминь.

попытаюсь высказатся понятно

Протакол -- HTTP

Данные передоваемые на сервер --- Логин/пароль (в веденные на главной странице)

Задача --- подменить ip отправителя
----------------------
я Понимаю, что после того как мы отправим данные на сервер, с неправильным ip , сервер отправит ответ не нам .
но это уже не важно , так как сервер у себя в логах уже зделает нужную нам запись.

=====================================
P.S. Rabbit, ты мне ни чем не помог! надеюсь что ты просто не понял вопроса, и поэтому гониш бред.

</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Цитата (wizard @ апреля 06 2004,18:18)</td></tr><tr><td id="QUOTE">Протакол -- HTTP[/QUOTE]<span id='postcolor'>
Процесс подделки IP адреса в TCP пакетах называется спуффингом.
Поищи в поисковиках на это слово.)
Но по правде говоря не думаю что у тебя это выйдет. Сложно это ....

С securitylab.ru
----------------------------------------------------------


29 апреля 2002
TCP-спуфинг: пошлая сказка.

buggzy

Я уже устал читать как две капли воды похожие друг на друга статьи про TCP-спуфинг. В одном только Хакере за 2002
год было уже две таких статьи. Господа авторы уже четыре года бездумно передирают одну и ту же статью, не замечая
одного грустного факта. Хочу раскрыть им глаза. Читать с выражением: Лю-у-у-уди! Спуфинга не бывааааает! Его уже давно не бывает...

Критерием возможности спуфинга является алгоритм выбора сервером ISS. Выделяются 5 классов алгоритмов:

1. C (Constant). ISS не зависит от времени или изменяется очень медленно.
2. xK (например, 64K). ISS увеличивается на x при каждом подключении.
3. TD (Trivial Time Depency). ISS - линейная функция от времени
4. RI (Random Positive Increments). ISS - нелинейная монотонная функция от времени
5. TR (Trully Random). ISS - немонотонная функция.

Предсказание ISS возможно только в случае, если алгоритм генерации ISS принадлежит к первым трем классам.

Пятый класс - &quot;действительно случайные&quot; ISS, и о предсказании не может быть и речи. Четвертый, хотя и не полностью случаен (RFC рекомендует определенную зависимость от времени, и это правило выполняется), но реальная атака ничем не проще, т.к. обычно (например, в linux) при генерации ISS значение таймера перемешивается с адресом и портом клиента и защищается криптографических хешем (в linux - MD4).

Теперь дело - за списком OS, алгоритм генерации которых принадлежит ко второму или третьему классу (первый класс используется только в несерьезном оборудовнии типа серверов печати или хабов). Вот список наиболее распространенных OS с указанием версии и класса алгоритма.

Class 64K

NetBSD 1.0 - 1.2
FreeBSD 2.1.0 - 2.1.5
Solaris 2.3 - 2.4
Class TD
NT 4 SP1-SP4
Linux 1.0.9

Class RI

FreeBSD 2.2.1 - 4.3
OpenBSD 2.1 - 2.8
NetBSD 1.3 - 1.5
NT 4 SP5-SP6
Linux 1.2.8 - 1.2.13
System V
Solaris 2.5 - 2.7, 8, 9

Class TR

FreeBSD 4.3 - 5.0
OpenBSD 2.9 - 3.0

Как мы видим, Linux избавился от TD уже во второй версии, и случилось это в 94м году. NT 4 перестал быть уязвимым для этой атаки после выхода SP5, в мае 1999 года. NetBSD освободился от этой напасти в январе 1998 с выходом версии 1.3 FreeBSD - в ноябре 98го. Solaris - в том же году с выходом 2.5

Таким образом, прошло уже 4 лет с тех пор, как все операционные системы перестали быть уязвимыми для TCP-спуфинга.

JazzzSummerMan см. выше, а именно: </span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Цитата </td></tr><tr><td id="QUOTE">
попытаюсь высказатся понятно
Протакол -- HTTP[/QUOTE]<span id='postcolor'>
Чел сам не знает че он хочет.
</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Цитата </td></tr><tr><td id="QUOTE">P.S. Rabbit, ты мне ни чем не помог! надеюсь что ты просто не понял вопроса, и поэтому гониш бред.[/QUOTE]<span id='postcolor'>
1. Гонят говно по трубам 2. Ты не понял ответа 3. Чтобы правильно ставить вопросы нужно знать большую часть ответа, а для этого нужно: а) пошевелить немного собственными извилинами и б) потратить некоторую часть своего свободного времени на поиск нужной информации. в) не ждать пока придет добрый дядя и разжует те все да разложит по полочкам. г) вежливо поблагодарить всех добрых дядей из пункта &quot;в&quot;.

Rabid Rabbit --- 1) за помощь я в сегда благодарен...
2) ответа твоего &nbsp;я действительно не понял
3) если я могу разобратся сам , то я не пишу на форум , я обращаюсь за помощью только когда это действительно не обходимо.

------------------
Rabid Rabbit ---- против тебя я лично ни чего не имею , так что не нервничай