ProxyChains-NG neveido tuneli. Tas iepriekš ielādē bibliotēku, kas aizstāj ar tīklu saistītos libc izsaukumus vienā palaistajā programmā, tāpēc robeža ir izsaukums procesā, nevis maršruts visai ierīcei. Šī atšķirība nosaka, ko veiksmīgs tests patiešām pierāda. Strādājošs curl caur ķēdi apstiprina vienu aizķertu izsaukumu, nevis to, ka nosaukumu atrisināšana, UDP vai katrs bērnprocess gāja to pašu ceļu. Turpmākā rokasgrāmata trīs soļos pārbauda pārklājumu un pēc tam uzskaita, ko āķis nevar sasniegt.

Kā priekšielāde nonāk līdz savienojumam

Palaišanas laikā palaidējs ievieto libproxychains LD_PRELOAD un pēc tam izpilda mērķa programmu. Bibliotēka atrisina īstos libc simbolus un aizstāj tos ar savām funkciju, piemēram, connect un getaddrinfo, versijām. Izsaukumi, kas iet caur šiem simboliem, tiek pārrakstīti uz SOCKS vai HTTP starpniekserveri no konfigurācijas faila. Izsaukumi, kas izvēlas citu ceļu, nekad nesastop āķi, tāpēc garantija attiecas uz izsaukumu, nevis uz visu mašīnu.

Piedalās tikai dinamiski saistītas programmas, un setuid binārie faili drošas izpildes apstākļos pilnībā ignorē priekšielādi. Bērni manto vidi, bet tikai tik ilgi, kamēr palaidējs to notur vietā.

Pārliecinieties, ka bibliotēka ir ielādēta šajā procesā

Sāciet pieprasījumu un pārbaudiet dzīvo procesu, nevis čaulu, kas to palaida. Fails maps parāda katru koplietoto objektu, kas pašlaik ir kartēts procesā.

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

Sakritība apstiprina, ka aizķertā bibliotēka ir klāt, un tas ir nepieciešami, bet nepietiekami. Tukšs rezultāts parasti nozīmē, ka pārbaudījāt citu procesu, piemēram, pārlūku, kas URL nodeva instancei, kas palaista pirms palaidēja. Pirms ķerties pie kaut kā cita ar ldd pārbaudiet, vai binārais fails ir dinamiski saistīts, jo statiska būve priekšielādi vispār nevar ielādēt. Pēc tam izlasiet starpniekserveru sarakstu konfigurācijā, ko palaidējs patiešām izmantoja, jo novecojis ceļš vai aizvērta ports dod strādājošu āķi bez strādājošas ķēdes.

Izsekojiet savienojumiem, kas atstāj procesu

Bibliotēkas klātbūtne nepierāda, ka katrs izsaukums tika pārrakstīts, tāpēc sekojiet sistēmas izsaukumiem. Palaidiet vienu pieprasījumu izsekotāja vadībā un izlasiet, kur ligzdas patiešām aizgāja.

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

Izsekam jārāda tikai savienojumi uz jūsu starpniekservera galapunktu, un portam jāatbilst konfigurācijas faila ierakstam. Ja mērķa vietnes galamērķa adreses izsekā parādās tieši, tas izsaukums apgāja āķi, un tas ir tieši tas atradums, ko meklējāt. Salīdziniet portu numurus ar starpniekserveru sarakstu, nevis paļaujieties uz faila nosaukumu, jo cita projekta atlikusī konfigurācija ir izplatīts klusa tieša piekļuves avots. Saglabājiet izseku pieņemšanas protokolam; tas aizņem sekundes un izbeidz strīdus par pārklājumu.

Izlemiet, ko āķis nevar aptvert

proxychains-ng projekts ierobežo pāradresāciju ar TCP un brīdina, ka skripti, fona procesi un ielādētie moduļi var uzvesties citādi nekā galvenā programma. UDP un ICMP atrodas ārpus mehānisma, tāpēc visam, kas uz tiem paļaujas, vajag savu atbalstīto ceļu. DNS seko proxy_dns iestatījumam un pašas lietotnes atrisinātāja uzvedībai, kas nozīmē, ka viens veiksmīgs HTTPS pieprasījums neko nepasaka par nosaukumu atrisināšanu. Saglabājiet arī sertifikātu validāciju tur, kur tai jābūt: sasniegt serveri caur starpniekserveri nav iemesls izslēgt identitātes pārbaudes.

Ja tiešai atkāpei jābūt neiespējamai, izmantojiet piespiešanas robežu, kas pārvalda pašu datplūsmu, piemēram, tīkla nosaukumtelpu, ugunsmūra noteikumus vai VPN, un turiet to atsevišķi no bibliotēkas āķa. Āķis ir saderības rīks konkrētai programmai, nevis kill switch. Pierakstiet programmu, precīzo komandu, izsekā redzamo starpniekservera portu un to, vai DNS tika atrisināts attālināti; šie četri fakti ir atšķirība starp pārbaudītu tvērumu un cerību tvērumu.

Saistītie raksti