Co ProxyChains zachytí a co nechá být

ProxyChains-NG nevytváří tunel. Přednačítá knihovnu, která nahrazuje síťová volání libc uvnitř jediného programu, který spouští, takže hranicí je volání v procesu, nikoli trasa pro celé zařízení. Právě tento rozdíl určuje, co úspěšný test skutečně dokazuje. Fungující curl přes řetěz potvrzuje jedno zaháknuté volání, ne to, že překlad jmen, UDP nebo každý podřízený proces šly stejnou cestou. Níže uvedený postup ověřuje pokrytí ve třech krocích a poté vypisuje, na co hák nedosáhne.

Jak se přednačtení dostane ke spojení

Při startu vloží spouštěč libproxychains do LD_PRELOAD a poté spustí cílový program. Knihovna vyhledá skutečné symboly libc a nahradí je vlastními verzemi funkcí, jako jsou connect a getaddrinfo. Volání, která procházejí těmito symboly, se přepíší na proxy SOCKS nebo HTTP z konfiguračního souboru. Volání, která se vydají jinou cestou, se s hákem nikdy nesetkají, a proto platí záruka pro jednotlivé volání, ne pro celý stroj.

Účastní se jen dynamicky slinkované programy a binárky setuid při bezpečném spouštění přednačtení úplně ignorují. Potomci dědí prostředí, ale jen dokud ho spouštěč drží na místě.

Ověřte, že knihovna je v daném procesu načtená

Zahajte požadavek a prohlédněte si živý proces, ne shell, který ho spustil. Soubor maps ukazuje každý sdílený objekt, který je právě namapovaný do procesu.

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

Shoda potvrzuje, že zaháknutá knihovna je přítomna, což je nutné, ale ne dostačující. Prázdný výsledek obvykle znamená, že jste prohlíželi jiný proces, například prohlížeč, který předal URL instanci spuštěné před spouštěčem. Než se pustíte do čehokoli dalšího, ověřte pomocí ldd, že binárka je dynamicky slinkovaná, protože statický build přednačtení vůbec nenačte. Potom si přečtěte seznam proxy v konfiguraci, kterou spouštěč skutečně použil, protože zastaralá cesta nebo zavřený port dávají funkční hák bez funkčního řetězu.

Vysledujte spojení, která opouštějí proces

Přítomnost knihovny nedokazuje, že každé volání bylo přepsáno, proto sledujte systémová volání. Spusťte jeden požadavek pod trasovačem a přečtěte si, kam sockety skutečně šly.

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

Trasa má ukazovat jen spojení na váš proxy koncový bod, s portem odpovídajícím záznamu v konfiguračním souboru. Pokud se v trase přímo objeví cílové adresy cílového webu, znamená to, že volání hák obešlo, a to je právě ten nález, který jste hledali. Porovnejte čísla portů se seznamem proxy, místo abyste věřili názvu souboru, protože zbylá konfigurace z jiného projektu je častým zdrojem tichého přímého přístupu. Trasu si uložte pro záznam o přijetí; trvá to sekundy a ukončí to hádky o pokrytí.

Rozhodněte, co hák nemůže pokrýt

Projekt proxychains-ng omezuje přesměrování na TCP a varuje, že skripty, procesy na pozadí a načtené moduly se mohou chovat jinak než hlavní program. UDP a ICMP stojí mimo mechanizmu, takže vše, co na nich závisí, potřebuje vlastní podporovanou cestu. DNS se řídí nastavením proxy_dns a vlastním chováním resolveru aplikace, což znamená, že jeden úspěšný HTTPS požadavek vám o překladu jmen neřekne nic. Ponechejte také ověřování certifikátů tam, kam patří: dosažení serveru přes proxy není důvod vypínat kontroly identity.

Pokud musí být přímý fallback nemožný, použijte vynucovací hranici, která řídí samotný provoz, například síťový jmenný prostor, pravidla firewallu nebo VPN, a držte ji odděleně od knihovního háku. Hák je nástroj kompatibility pro pojmenovaný program, ne kill switch. Zapište program, přesný příkaz, proxy port viděný v trase a to, zda se DNS překládal vzdáleně; tyto čtyři údaje jsou rozdílem mezi ověřeným rozsahem a rozsahem naděje.