ru.nethack

 
 - RU.NETHACK -------------------------------------------------------------------
 From : Add Guzhovskiy                       2:5020/400     15 Jul 2001  10:44:56
 To : All
 Subject : RE: socks
 -------------------------------------------------------------------------------- 
 

 ...
 
 > .AK> Какие  Вы знаете   способы  скpытия IP, пpи пpямых
 > .AK> коннектах (HTTP/FTP пpокси сюда не относятся) ?
 > OA> Hикакое сокрытие IP при реальной работе по TCP протоколу и любому
 > OA> существующему  протоколу с установлением соединения при работе
 > OA> напрямую невозможно, поскольку требует долговременного угадывания
 > OA> чисел вычисляемых
 
 ...
 
 Целиком и полностью соглашаюсь с Olli...
 При непосредственном осуществлении соединения на удалённый <*> хост скрыть
 ip адрес будет невозможным (как следствие черезвычайно долгого процесса
 предсказывания seq и ackn идентификаторов пакета), во всяком случае слишко
 далеко оно будет растянуто во времени и пространстве :), что по default'у
 нам не подходит... Итак проблема представляется нам совершенно непробиваемой
 если подходить к её решению "лбом о стену" (что так же настоятельно не
 рекомендуется практиковать).
 
 Один из представляющихся универсальных путей дальнейших действий есть
 redirect <***>. Его, теоретическое, устройство состоит в том что-бы
 перенаправлять пакеты через себя (функция firewall'а ;). Для осуществления
 редиректа требуется иметь доступ к какому-либо хосту в сети с возможностью
 воздействия на его работу <**> ,.. r0ot.sh3lL, например ;)...
 
 ------
 <*> Если victim_host (то есть атакуемый хост) находиться в локальной сети,
 то задача становиться совершенно тривиальной и сводиться к тому, что при
 надобности _программа_ (через которую проходит трафик) изменяет обратный
 адрес пакета уходящего на victim_host на адрес, заведомо несуществующий в
 локальной сети, после чего выбрасывает его заранее переведя сетевую карточку
 в suspend (или как его там, вот ведь - не помню) режим, в котором свободно
 прослушиваются, ловятся и просматриваются все проходящие пакеты (большая
 недоработка глупых [неинтелектуальных] сетевых хабов). В этом режиме мы
 может отлавливать все пакеты летающие в сегменте, в том числе летящие на
 "наш" несуществующий адрес и вуаля... админ уходит в осадок, когда смотрит
 логи пробитой системы ;)))...
 Эту штуку можно использовать так же вместе с нижеизложенным redirect'ом,
 если victim_host расположен в одном сегменте сети с за-redirect-ченой
 машиной...
 
 ------
 <**> Тут тоже есть один маленький нюанс - можно поставить redirect на
 каком-нить компе какого-нить института или лаборатории или просто на ppp
 пользователя Интернет посредством e-mail, через немеренное количество дырок
 в java-машине, mime и т.д. и уж на крайний случай постредством корыстного
 использования человеческой глупости... как с I_LOVE_YOU.virij...
 "Hа-а-а-ажмите, пожайлуста на эту скрепку, подтвердиы запуск программы.. и
 скорость вашей работы в Интернет возрастёт в 300 раз!!! 8-)))... такие
 пироги.
 
 ------
 <***>
 !! не пользуйся чужими redirect'ами - своя рубашка ближе к телу; да и
 антивирусы (если win-os) трогать не будут.
 
 Hесколько нотаций по поводу написания собственного redirect'а.
 
 + Слушать (т.е. ожидать соединения) должен не удалённый, а твой хост. А для
 возбуждения у редиректа желания приконнектиться к тебе пусть он читает
 какой-нить свой порт на предмет указания ему ip-адреса к коему он
 незамедлительно будет пытаться открывать соединение.
 Зачем? что-б если что-то случиться ты просто отписался тем, что ничего не
 знаешь не видел и не слышал... только всякие трояны у тебя водятся, иногда,
 потому, как в ИнтерДе копаешься, и вот этот тоже наверное тоже дело рук
 злобного хучкера закинувшего тебе троян и регулярно чего-то белающего с
 твоей машиной! Лучше даже, если ты будешь открывать так называемое
 _неполное_соединение_, что бы сервер сам по твоему пакету к тебе обращался с
 целью connect'а.. (точно не скажу как это делается, сам же я это
 игнорировал..).
 
 + Весь трафик _от_тебя_к_нему_ и обратно советую криптовать - вполне
 достаточно будет
 'xor eax,12341234h'.. (и совсем красяво выйдет, если с инкрементацией)...
 Для чего? Вот ведь вопрос... Что бы если у твоего провайдера (да и вообщем,
 любого промежуточного пункта rout'а посланого пакета) стоит полный tcpdmp,
 то всё равно никто ничего не понял!
 
 + Теперь как забивать кульки-в-кульки, то есть пакетики в пакетики...
 Садишься на winsock (но тут уже литературу почитай.. времени нет
 распинаться)... все уходящие в ИнтерДу пакеты (если они летят на указанный
 ip, или просто все подрят - простойший способ) ты xor'ишь и выплёвываешь
 своему редиректному хосту...
 
 Hо тут есть одна маленькая заморочь - ты можешь (если н?ср?ть на dump у
 провайдера, да и если он есть у них вообще) отсылать пакеты прямо на
 victim_host подменяя обратный ip адрес на адрес твоего redirect'а - это
 существено увеличит скорость передачи одного пакета (пока он дойдёт до
 редиректа, затем до victim_host, затем опять до редирека, и только тогда к
 тебе,.. а так ты -> victim_host -> редирект -> ты... 1.5 раза быстрее, если
 не учитывать времени ping'а [прохождения пакета] до редиректа и
 victim_host'а).
 
 + Редирект запоминает ip-адрес получателя пакета и выкидывает его в
 дальше... Получая же весь поток приходящих пакетов он отсеивает те, что
 пришли с victim_host и передает тебе... Причём обязательно пропиши ему
 возможность запоминать несколько адресов, тогда ты просто сможешь ходить в
 i-net'е через редирект, как через super-анонимный proxy ;))
 
 + Hу и обязательно добавить возможность удалённо полностью снести свой
 редирект конечно-же...
 
 Вышеизложенные предположения по созданию программы-redirect'а в большинстве
 своём применимы к win-os системам,.. под *unix'ом всё проще...
 --DarkCruz..  // d4rk_Sanity. gr0up.. // darkcruz@newmail.ru
 --- ifmail v.2.15dev5
  * Origin: ISP Maket, Slavutich, Ukraine (2:5020/400)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор