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 ದೂರದಿಂದ ಬಿಡಿಸಲ್ಪಟ್ಟಿದೆಯೇ ಎಂಬುದನ್ನು ದಾಖಲಿಸಿ; ಆ ನಾಲ್ಕು ಅಂಶಗಳೇ ಪರಿಶೀಲಿತ ವ್ಯಾಪ್ತಿ ಮತ್ತು ಆಶಾಭರಿತ ವ್ಯಾಪ್ತಿಯ ನಡುವಿನ ವ್ಯತ್ಯಾಸ.

ಸಂಬಂಧಿತ ಲೇಖನಗಳು