Што ProxyChains перахапляе, а што пакідае ў спакоі

ProxyChains-NG не стварае тунэль. Яна папярэдне загружае бібліятэку, якая замяняе сеткавыя выклікі libc унутры адзінай праграмы, якую запускае, таму мяжа — гэта выклік у працэсе, а не маршрут на ўсёй прыладзе. Гэта розніца вызначае, што насамрэч даказвае паспяховы тэст. Працуючы curl праз ланцуг пацвярджае адзін перахоплены выклік, а не тое, што развязанне імён, UDP ці кожны даччыны працэс ішлі тым жа шляхам. Інструкцыя ніжэй правярае ахоп у тры крокі, а затым пералічвае тое, чаго перахоп не дасягае.

Як папярэдняя загрузка дасягае злучэння

Пры запуску праграма-лаўнчар змяшчае libproxychains у LD_PRELOAD і затым выконвае мэтавую праграму. Бібліятэка развязае сапраўдныя сімвалы libc і падстаўляе свае версіі функцый, такіх як connect і getaddrinfo. Выклікі, якія праходзяць праз гэтыя сімвалы, перанакіроўваюцца на SOCKS- або HTTP-проксі з файла канфігурацыі. Выклікі, якія ідуць іншым шляхам, ніколі не сустракаюць перахоп, і таму гарантыя дзейнічае для кожнага выкліку, а не для ўсёй машыны.

Удзельнічаюць толькі дынамічна злучаныя праграмы, а setuid-бінарнікі пры бяспечным выкананні цалкам ігнаруюць папярэднюю загрузку. Даччыныя працэсы атрымліваюць асяроддзе ў спадчыну, але толькі пакуль лаўнчар трымае яго на месцы.

Пераканайцеся, што бібліятэка загружана ў гэтым працэсе

Пачніце запыт і агледзьце жывы працэс, а не абалонку, якая яго запусціла. Файл maps паказвае кожны агульны аб’ект, які зараз адлюстраваны ў працэсе.

proxychains4 -q curl -sS --max-time 8 https://example.com/ -o /dev/null &
pgrep -a curl
grep libproxychains /proc/$(pgrep -n curl)/maps

Супадзенне пацвярджае наяўнасць перахопленай бібліятэкі, што неабходна, але недастаткова. Пусты вынік звычайна азначае, што вы агледзелі іншы працэс, напрыклад браўзер, які перадаў URL асобніку, запушчанаму да лаўнчара. Праверце праз ldd, што бінарнік дынамічна злучаны, перш чым ганяцца за чымсьці іншым, бо статычная зборка наогул не можа загрузіць папярэднюю загрузку. Затым прачытайце спіс проксі ў канфігурацыі, якую лаўнчар фактычна выкарыстаў, бо састарэлы шлях або закрыты порт даюць працоўны перахоп без працоўнага ланцуга.

Прасочвайце злучэнні, якія пакідаюць працэс

Наяўнасць бібліятэкі не даказвае, што кожны выклік быў перапісаны, таму сачыце за сістэмнымі выклікамі. Запусціце адзін запыт пад трасіроўшчыкам і прачытайце, куды насамрэч пайшлі сокеты.

strace -f -e trace=connect -o /tmp/pc.trace proxychains4 -q curl -sS https://example.com/ -o /dev/null
grep -o "sin_port=htons([0-9]*)" /tmp/pc.trace | sort -u

Траса павінна паказваць злучэнні толькі да вашай проксі-канчатковай кропкі, а порт павінен адпавядаць запісу ў файле канфігурацыі. Калі адрасы прызначэння мэтавага сайта з’яўляюцца ў трасе напрамую, гэта азначае, што выклік абмінуў перахоп, і гэта менавіта тая знаходка, якую вы шукалі. Параўнайце нумары партоў са спісам проксі, а не давярайце імені файла, бо канфігурацыя, якая засталася ад іншага праекта, — частая крыніца маўклівага прамога доступу. Захавайце трасу для запісу аб прыёмцы; гэта займае секунды і спыняе спрэчкі пра ахоп.

Вызначце, што перахоп не можа пакрыць

Праект proxychains-ng абмяжоўвае перанакіраванне TCP і папярэджвае, што скрыпты, фонавыя працэсы і загружаныя модулі могуць паводзіць сябе інакш, чым асноўная праграма. UDP і ICMP знаходзяцца па-за механізмам, таму ўсё, што на іх спадзявацца, патрабуе свайго падтрыманага шляху. DNS ідзе за наладай proxy_dns і ўласнымі паводзінамі развязальніка праграмы, а значыць адзін паспяховы HTTPS-запыт нічога вам не кажа пра развязанне імён. Трымайце праверку сертыфікатаў там, дзе ёй належыць месца: дасягненне сервера праз проксі не прычына адключаць праверку асобы.

Калі прамы адкат павінен быць немагчымым, выкарыстоўвайце мяжу прымусу, якая кіруе самім трафікам, напрыклад сеткавую прастору імён, правілы файрвола або VPN, і трымайце яе асобна ад бібліятэчнага перахопу. Перахоп — гэта інструмент сумяшчальнасці для названай праграмы, а не kill switch. Запішыце праграму, дакладную каманду, порт проксі, убачаны ў трасе, і ці быў DNS развязаны аддалена; гэтыя чатыры факты — розніца паміж правераным ахопам і спадзяваннем.