Mit fog el a ProxyChains, és mit hagy békén

A ProxyChains-NG nem hoz létre alagutat. Előtölt egy könyvtárat, amely lecseréli a hálózati libc-hívásokat azon az egyetlen programon belül, amelyet elindít, tehát a határ egy folyamaton belüli hívás, nem pedig eszközszintű útvonal. Ez a különbség dönti el, mit bizonyít valójában egy sikeres teszt. Egy működő curl a láncon keresztül egyetlen megkampózott hívást igazol, nem azt, hogy a névfeloldás, az UDP vagy minden gyermekfolyamat ugyanazt az útvonalat követte. Az alábbi útmutató három lépésben ellenőrzi a lefedettséget, majd felsorolja, mit nem ér el a kampó.

Hogyan ér el az előtöltés egy kapcsolatig

Induláskor az indító behelyezi a libproxychains könyvtárat a LD_PRELOAD változóba, majd végrehajtja a célprogramot. A könyvtár feloldja a valódi libc-szimbólumokat, és saját verzióira cseréli az olyan függvényeket, mint a connect és a getaddrinfo. Az ezeken a szimbólumokon átmenő hívások átíródnak a konfigurációs fájlban megadott SOCKS vagy HTTP proxyra. A másik útvonalat választó hívások soha nem találkoznak a kampóval, ezért a garancia hívásonként, nem gépenként érvényes.

Csak a dinamikusan linkelt programok vesznek részt, a biztonságos végrehajtás alatt futó setuid binárisok pedig teljesen figyelmen kívül hagyják az előtöltést. A gyermekek öröklik a környezetet, de csak ameddig az indító a helyén tartja.

Erősítse meg, hogy a könyvtár be van töltve abba a folyamatba

Indítsa el a kérést, és az azt indító shell helyett az élő folyamatot vizsgálja. A maps fájl minden megosztott objektumot mutat, amely éppen be van képezve a folyamatba.

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

Az egyezés megerősíti a megkampózott könyvtár jelenlétét, ami szükséges, de nem elégséges. Az üres eredmény általában azt jelenti, hogy másik folyamatot vizsgált, például egy böngészőt, amely az URL-t egy az indító előtt elindult példánynak adta át. Mielőtt bármi más után eredne, ellenőrizze a ldd segítségével, hogy a bináris dinamikusan linkelt-e, mert a statikus build egyáltalán nem tudja betölteni az előtöltést. Ezután olvassa el a proxyk listáját abban a konfigurációban, amelyet az indító ténylegesen használt, mert egy elavult útvonal vagy egy zárt port működő kampót ad működő lánc nélkül.

Kövesse nyomon a folyamatból kilépő kapcsolatokat

A könyvtár jelenléte nem bizonyítja, hogy minden hívás átíródott, ezért kövesse a rendszerhívásokat. Futtasson egy kérést a nyomkövető alatt, és olvassa el, hová mentek valójában a socketek.

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

A nyomnak csak a proxy végpontja felé mutató kapcsolatokat kell mutatnia, a portnak pedig egyeznie kell a konfigurációs fájl bejegyzésével. Ha a célwebhely célcímei közvetlenül megjelennek a nyomban, az a hívás megkerülte a kampót, és pontosan ez az a lelet, amelyet keresett. Hasonlítsa össze a portszámokat a proxyk listájával, ahelyett hogy a fájlnévben bízna, mert egy másik projektből maradt konfiguráció a csendes közvetlen hozzáférés gyakori forrása. Őrizze meg a nyomot az átvételi jegyzőkönyvhöz; másodpercekig tart, és eldönti a lefedettségről szóló vitákat.

Döntse el, mit nem tud lefedni a kampó

A proxychains-ng projekt az átirányítást TCP-re korlátozza, és figyelmeztet, hogy a szkriptek, a háttérfolyamatok és a betöltött modulok a főprogramtól eltérően viselkedhetnek. Az UDP és az ICMP a mechanizmuson kívül esik, ezért mindennek, ami rájuk támaszkodik, saját támogatott útvonalra van szüksége. A DNS a proxy_dns beállítást és az alkalmazás saját feloldójának viselkedését követi, ami azt jelenti, hogy egy sikeres HTTPS-kérés semmit nem mond a névfeloldásról. Tartsa a tanúsítvány-ellenőrzést is a helyén: egy kiszolgáló elérése proxyn keresztül nem ok az identitásellenőrzések kikapcsolására.

Ha a közvetlen visszaesésnek lehetetlennek kell lennie, használjon olyan kikényszerítési határt, amely magát a forgalmat szabályozza, például hálózati névteret, tűzfalszabályokat vagy VPN-t, és tartsa külön a könyvtárkampótól. A kampó egy megnevezett program kompatibilitási eszköze, nem kill switch. Jegyezze fel a programot, a pontos parancsot, a nyomban látott proxyportot és azt, hogy a DNS távolról oldódott-e fel; ez a négy tény a különbség az ellenőrzött hatókör és a reményteljes hatókör között.