|
ru.nethack
- RU.NETHACK -------------------------------------------------------------------
From : DarkCruz.. 2:5020/400 18 Jul 2001 23:35:54
To : All
Subject : Re: PHP-redirect'00
--------------------------------------------------------------------------------
> IMHO криптовать траффик по инициированным сокетам - лишнее - все равно к
> victim-host-y он будет раскриптованый идти. Криптовать имеет смыл только
> пост-овые данные,
> которые содержат информацию о IP. Причем так, чтобы потом фиг кто
> раскриптовал -
> например зашивать ключь в скрипт перед началом "работы", а по окончании
> "работы" -
> опять же менять ключь.
кхе-кхе.. эти фичи были приняты по умолчанию, вообщем-то их-то я и
подразумевал, когда изяснялся по поводу криптования трафика. ествественно
только пост-данные (две причины: 1- если на victim_host улетят
закриптованные данные, то он соответственно не будет знать что с ними
делать; 2- ключ естественно должен и будет меняться... только если
ограничиться одним ключём на сессию [работы], то можно его выкладывать на
mail-box'е, с которого скрипт сам всё стягивает или же, что будет многим
лучше, - положить ещё один скрипт на левый сервер который всего-то что будет
уметь - это записывать ключ к себе в tmp файл из строки запроса, допустим,
/savekey.cgi?ip=222.111.112.221&key=Ghds5jLK, так же и отдавать, например,
/getkey.cgi?ip=222.111.112.221, после чего херить строку соотносяшуюся к
этому ip в своём tmp-файле [или херить по команде /killkey.cgi?ip=... - для
предотвращения ошибок по time0ut'у])
> Если есть наш ПХП-скрипт, и данные переданные ПОСТ-ом,
> расшифровать могут. По тому же ключу, переданному с данными.
см.выше. если сам скрипт "откуда-нить" возьмёт ключ?.. ;)
> все равно - ничего не меняет =( Другое дело - когда "ИМ" может
> понадобиться проследить, расшифровать, вычислить нас - только если
> сильно напакостить,
...
> проторочками. То есть после такой пакости, надо сразу же убивать скрипт,
> либо заменять на другой - с другим алгоритмом - пусть гадают, после
> расшифровки,
думаешь у тебя будет возможность это сделать? я бы на месте админа
просто-напросто с самого начала взял да и закрыл твой аккаунт, а потом уж
сидел тихо и мирно разбирая чего же навоял-то злобный хуцкер... таким
образом надо как можно более полно представить себе сохранность скриптом
информации (от излишней "публики"), ни при каких мотивациях не отдавать им
свои ip!
> что бы это значило =). Правда, все-равно, если проследить логи проксей,
> по которым мы коннектились - вычислить можно. =Е
какая добросовестно анонимная прокся станет отдавать тебе лог?
> У HTTP протокола есть метод CONNECT. Через него, например, аська
> коннектится - его можно
> использовать для построения цепочки проксей. [RFC 2616] По-крайней мере
> сквид его поддерживает.
> Еще можно побаловаться с функцией ignore_user_abort () - утверждается,
> что при разрыве соединения пользователем скрипт остнется висеть, пока
> не закончит свое дело - тогда никакое стабильное соединение через прокси и
> не
> требуется - нужно только инициировать.
no comment.
> Вобщем к каким нельзя мы приходим:
> - Hиззя коннектится самим к скрипту (HTTP) - могут проследить откуда.
спорный, даже весьма спорный попрос
> - Hиззя передавать свой IP пост-ом - могут расшифровать (чтобы не
> расшифровали,
> надо сразу же после работы убивать скрипт).
/повторюсь, но../ ни при каких мотивациях не отдавать им свой ip!
> - И вообще низзя это использовать, если хостинг-сервер ведет полные логи
> всего траффика =( А как узнать - ведет или нет ? По-моему, 99% не ведут.
это мы уже обсуждали,.. практически все из, правда не большого количества
(не особенно уж и крутых) хостингов оставшиеся на моей памяти (и совести)
;) полный дамп трафика к себе на винт не ложили.
> даже сломать ради такого дела какой-нить с посещаемостью около 10 чел все
> время),
...
> ввиду чтобы он как-то доставал наш IP и IP victim-host-a и инициировал
> соединение.
...
> накладывать какой-то XOR, разбивать побайтово и смотреть
> IPb1-IPb2-IPb3-IPb4-PortLo-PortHi
да, интересно... только прийдётся ломать и переписывать скрипт чата.
неспорю: проще-простого (если чатина какая-нить отмороженая), только вот
целью PHP-редиректа была возможность "сотворить redirect без взятия удалён-
ной машины", а она (цель сия в смысле) полностью рушиться при таком
раскладе. Дело в том что этот редирект задумывался "боевым средством
незамедлительного действия", когда чего-то откуда-то делаешь ;)...
> И еще, прикольно было бы клиента написать чтобы он вешался и на локальный
> порт и передавал
> через себя весь траффик, с этого порта на скрипт - если кто-то инициирует
> соединение. Тогда можно будет
таким образом скороть критически упадёт. плюс ко всему интересный вариант:
паралельно с использованием PHP-redirect'а можно ещё проводить поверхностный
скан victim_host'а через цепочку proxy и т.д. заранее представляю себе лицо
админа [root'а ;)] выворачивающего наизнанку свои логи...
> в качестве victim-host прописать какую-то проксю (например проксю у
> хост-сервера - думаю
зачем? лишние потери скорости (учитывая то, что напрямую к скрипту мы всё
равно не пойдём).
> Еще нужно будет подумать над многопотоковостью (и в ПХП скрипте тоже).
> Если нам например нужно
> открыть несколько соединений - как должен поступать PHP скрипт - наверное
> будет какое-то контрольное
> соединение со скриптом - туды будут передаваться IP victim-host-ов, и он
> сразу же инициирует, по приему IP,
> еще два сокета : с нами и с жертвой. Hаш IP передается POST-ом при запуске
> скрипта.
опять же... зачем? просто используем массив-список атакуемых ip. передавая
на скрипт закриптованные данные мы должны позаботиться о предварительном
(локально, у себя) разделении трафика. при передачи просто используем
указатель на необходимый ip хранящий в массиве. всё!
> (это все раньше оговаривалось). Hу это так, отступление на перспективы.
> Hадо еще 2 литра
> пива и подумать =))
угу... :-/ а у меня зарплата полько через 2 недели... :(((
--DarkCruz // 616 // d4rk_Sanity. gr0up..
darkcruz@ff.com.ua
e.0.f.
--- ifmail v.2.15dev5
* Origin: ISP Maket, Slavutich, Ukraine (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
