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 ถูกแปลงจากระยะไกลหรือไม่ ข้อเท็จจริงสี่ข้อนี้คือความต่างระหว่างขอบเขตที่ตรวจสอบแล้วกับขอบเขตแห่งความหวัง