რას იჭერს ProxyChains და რას ტოვებს ხელუხლებლად
ProxyChains ბიბლიოთეკის გამოძახებებს კრავს იმ პროგრამაში, რომელსაც უშვებს. შეამოწმეთ TCP დაფარვა maps, strace და ერთი მოთხოვნით, შემდეგ შეწყვიტეთ ვარაუდი, რომ DNS ან UDP მიჰყვება.
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 მოთხოვნა სახელის ამოხსნაზე არაფერს გეუბნებათ. სერტიფიკატების შემოწმებაც თავის ადგილზე დატოვეთ: პროქსის გავლით სერვერთან მისვლა იდენტურობის შემოწმების გამორთვის მიზეზი არ არის.
თუ პირდაპირი უკან დაბრუნება შეუძლებელი უნდა იყოს, გამოიყენეთ აღსრულების საზღვარი, რომელიც თავად ტრაფიკს აკონტროლებს, მაგალითად ქსელური სახელების სივრცე, firewall-ის წესები ან VPN, და შეინახეთ ის ბიბლიოთეკის კაუჭისგან ცალკე. კაუჭი კონკრეტული პროგრამის თავსებადობის ინსტრუმენტია და არა kill switch. ჩაწერეთ პროგრამა, ზუსტი ბრძანება, კვალში ნანახი პროქსის პორტი და ის, დისტანციურად გადაწყდა თუ არა DNS; ეს ოთხი ფაქტი განსხვავებაა შემოწმებულ ფარგლებსა და იმედიან ფარგლებს შორის.