sudo ಜೊತೆ ಚಲಾಯಿಸಿದಾಗ ಪೋರ್ಟ್ ಸ್ಕ್ಯಾನ್ ಏಕೆ ಬದಲಾಗುತ್ತದೆ

Nmap ಯಾವಾಗಲೂ ನೀವು ಕೇಳಿದ್ದೀರಿ ಎಂದು ನೀವು ಭಾವಿಸುವ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಕಳುಹಿಸುವುದಿಲ್ಲ. raw ಸಾಕೆಟ್‌ಗಳು ಲಭ್ಯವಿಲ್ಲದಿದ್ದಾಗ ಅದು ಡೀಫಾಲ್ಟ್ SYN ಸ್ಕ್ಯಾನ್‌ನ ಸ್ಥಾನದಲ್ಲಿ TCP connect ಸ್ಕ್ಯಾನ್ ಅನ್ನು ಹಾಕುತ್ತದೆ, ಹಾಗಾಗಿ ನಿಮ್ಮ ಸಾಮಾನ್ಯ ಬಳಕೆದಾರರಾಗಿ ಚಲಾಯಿಸುವುದು ಮತ್ತು sudo ಅಡಿಯಲ್ಲಿ ಚಲಾಯಿಸುವುದು ಒಂದೇ ಪೋರ್ಟ್ ಬಗ್ಗೆ ಬೇರೆ ಬೇರೆ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸಬಹುದು. ಫಲಿತಾಂಶಗಳು ಅನುಮತಿ-ಸಮಸ್ಯೆಯಂತೆ ಕಾಣುತ್ತವೆ, ಆದರೆ ಸಾಮಾನ್ಯವಾಗಿ ಅವು ವಿಧಾನದ ಬದಲಾವಣೆ. ವಿಧಾನವನ್ನು ಸ್ಪಷ್ಟಪಡಿಸುವುದು ಎರಡೂ ಚಲಾವಣೆಗಳನ್ನು ಹೋಲಿಸುವ ಏಕೈಕ ದಾರಿ.

ಎರಡು ಪ್ರೋಬ್, ಒಂದು ಪೋರ್ಟ್, ಬೇರೆ ಬೇರೆ ಕೋಡ್ ಮಾರ್ಗಗಳು

SYN ಸ್ಕ್ಯಾನ್ ಸ್ವತಃ TCP ಹೆಡರ್ ಅನ್ನು ನಿರ್ಮಿಸಿ, raw ಸಾಕೆಟ್‌ನಿಂದ ಕಳುಹಿಸಿ, ಕರ್ನಲ್‌ನ TCP ಸ್ಟಾಕ್ ಪೂರ್ಣಗೊಂಡ ಸಂಪರ್ಕವನ್ನು ದಾಖಲಿಸುವ ಮೊದಲೇ ಜಾಲದಿಂದ ಉತ್ತರವನ್ನು ಓದುತ್ತದೆ. connect ಸ್ಕ್ಯಾನ್ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಮ್‌ಗೆ ಸಾಮಾನ್ಯ ಸಾಕೆಟ್ ತೆರೆಯಲು ಹೇಳಿ connect() ಏನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ ಎಂದು ವರದಿ ಮಾಡುತ್ತದೆ. ಎರಡೂ ಪೋರ್ಟ್ ಅನ್ನು ತೆರೆದಿದೆ ಎಂದು ಹೇಳಬಹುದು, ಆದರೆ ಒಂದೇ ಅರ್ಧ-ತೆರೆದ ಪ್ರಯತ್ನವನ್ನು ಬಿಡುತ್ತದೆ ಮತ್ತು ಒಂದೇ ಕಳುಹಿಸುವ ಪ್ರಕ್ರಿಯೆಗೆ ಸಂಬಂಧಿಸಿದ ಸಾಕೆಟ್-ಮಟ್ಟದ ನೀತಿಗೆ ಒಳಪಟ್ಟಿರುತ್ತದೆ.

raw ಮಾರ್ಗಕ್ಕೆ CAP_NET_RAW ಬೇಕು, ಹಾಗಾಗಿ ಆ ಸಾಮರ್ಥ್ಯ ಇಲ್ಲದಿದ್ದಾಗ ಡೀಫಾಲ್ಟ್ ಸ್ಕ್ಯಾನ್ ಮೌನವಾಗಿ ಕ್ಷೀಣಿಸುತ್ತದೆ. Nmap ನ ಸ್ವಂತ ಸ್ಕ್ಯಾನ್ ತಂತ್ರಗಳ ಉಲ್ಲೇಖ ಈ ಬದಲಾವಣೆಯನ್ನು ದಾಖಲಿಸುತ್ತದೆ: connect ಸ್ಕ್ಯಾನ್ ಪರ್ಯಾಯವಾಗಿದೆ ಏಕೆಂದರೆ ಅದಕ್ಕೆ ಯಾವುದೇ ವಿಶೇಷ ಅನುಮತಿ ಬೇಕಿಲ್ಲ. ಬಹುಪಾಲು ಚಲಾವಣೆಗಳಲ್ಲಿ ಈ ಅದಲುಬದಲು ಎಚ್ಚರಿಕೆ ಇಲ್ಲದೆ ಸಂಭವಿಸುತ್ತದೆ, ಮತ್ತು ಅದೇ ಅದನ್ನು ತಪ್ಪಾಗಿ ಓದಲು ಸುಲಭವಾಗಿಸುತ್ತದೆ. ಪರ್ಯಾಯ ಇದೆ ಎಂದು ತಿಳಿದ ನಂತರ, “root ಆಗಿ ತೆರೆದಿದೆ, ಬಳಕೆದಾರರಾಗಿ ಮುಚ್ಚಿದೆ” ಎಂಬುದು ಅನುಮತಿ ದೋಷದಂತೆ ಕೇಳಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿ ಎರಡು ಬೇರೆ ಅಳತೆಗಳಂತೆ ಕೇಳಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ.

ಸ್ಕ್ಯಾನ್‌ನಲ್ಲಿ sudo ನಿಜವಾಗಿ ಏನನ್ನು ಬದಲಿಸುತ್ತದೆ

ಅನುಮತಿಗಳನ್ನು ಹೆಚ್ಚಿಸುವುದು raw ಸಾಕೆಟ್ ಮಾರ್ಗವನ್ನು ಮರುಸ್ಥಾಪಿಸುತ್ತದೆ, ಮತ್ತು ಅದು ತೀರ್ಪಿಗಿಂತ ಹೆಚ್ಚನ್ನು ಬದಲಿಸುತ್ತದೆ. ಮೂಲ ಪೋರ್ಟ್ ಆಯ್ಕೆ, ಪ್ಯಾಕೆಟ್ ಸಮಯ, ಮರು ಕಳುಹಿಸುವ ವರ್ತನೆ ಮತ್ತು ಫಿಲ್ಟರ್ ಆದ ಉತ್ತರದ ವರ್ಗೀಕರಣ — ಎಲ್ಲವೂ ಬೇರೆ ಕೋಡ್‌ನಿಂದ ಬರುತ್ತವೆ. SYN ಗಳ ದರವನ್ನು ಮಿತಿಗೊಳಿಸುವ ಮಧ್ಯಸ್ಥ ಸಾಧನ ಗಮ್ಯ ಹೋಸ್ಟ್ ಒಂದೇ ಆಗಿದ್ದರೂ ಎರಡೂ ಚಲಾವಣೆಗಳನ್ನು ಅಸಮಾನವಾಗಿ ನೋಡುತ್ತದೆ.

ಗಮ್ಯದ ಕಡೆಯ ಲಾಗಿಂಗ್ ಕೂಡ ಭಿನ್ನವಾಗಿರುತ್ತದೆ. ಪೂರ್ಣಗೊಂಡ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಸೇವೆಗೆ ಮತ್ತು ಯಾವುದೇ ಸಾಕೆಟ್ ಲೆಕ್ಕಿಗೆ ಕಾಣುತ್ತದೆ, ಆದರೆ ಮರುಹೊಂದಿಸಿದ ಅರ್ಧ-ತೆರೆದ ಪ್ರೋಬ್ ಹಲವು ಬಾರಿ ಕಾಣುವುದಿಲ್ಲ. ನೀವು ಲಾಗ್‌ಗಳನ್ನು ಸಹ ಓದುವ ಹೋಸ್ಟ್ ವಿರುದ್ಧ ಚಲಾವಣೆಗಳನ್ನು ಹೋಲಿಸಿದರೆ, ನೀವು ಕಾಣುವ ವ್ಯತ್ಯಾಸದ ಒಂದು ಭಾಗ ವೀಕ್ಷಣೆಯೇ ಆಗಿದೆ.

ಎರಡೂ ಚಲಾವಣೆಗಳಲ್ಲಿ ವಿಧಾನವನ್ನು ಸ್ಥಿರವಾಗಿಡಿ

ಎರಡೂ ಕರೆಗಳಲ್ಲಿ ಅದೇ ತಂತ್ರವನ್ನು ಒತ್ತಾಯಿಸಿ, ಆಗ ಹೋಲಿಕೆ ಅರ್ಥಪೂರ್ಣವಾಗಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. -sT ಫ್ಲ್ಯಾಗ್ connect ಸ್ಕ್ಯಾನ್ ಅನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಕೇಳುತ್ತದೆ, -Pn ಹೋಸ್ಟ್ ಅನ್ವೇಷಣೆಯನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ, -n ಹೆಸರು ಪರಿಹಾರವನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ, ಮತ್ತು ಒಂದೇ -p ಪೋರ್ಟ್ ಪಟ್ಟಿಯ ವ್ಯತ್ಯಾಸಗಳನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ.

nmap -sT -Pn -n -p 8443 198.51.100.77
sudo nmap -sT -Pn -n -p 8443 198.51.100.77

ವಿಳಾಸ ಮತ್ತು ಪೋರ್ಟ್ ಅನ್ನು ಪರೀಕ್ಷಿಸಲು ನಿಮಗೆ ಅನುಮತಿ ಇರುವ ಹೋಸ್ಟ್‌ನಿಂದ ಬದಲಾಯಿಸಿ; ಮೇಲಿನ ದಸ್ತಾವೇಜು ಶ್ರೇಣಿ ಮಾದರಿ, ಗುರಿಯಲ್ಲ. ಎರಡೂ ಚಲಾವಣೆಗಳು ಈಗ ಹೊಂದಿಕೆಯಾದರೆ, ಮೂಲ ವ್ಯತ್ಯಾಸ ಸ್ಕ್ಯಾನ್ ವಿಧಾನದಿಂದ ಬಂದಿತ್ತು. ಅವು ಇನ್ನೂ ಹೊಂದಿಕೆಯಾಗದಿದ್ದರೆ, ಬೇರೆ ಯಾವುದೋ ಸಂಚಾರವನ್ನು ವರ್ಗೀಕರಿಸುತ್ತಿದೆ, ಮತ್ತು ಮುಂದಿನ ವಿಭಾಗವೇ ನೋಡಬೇಕಾದ ಸ್ಥಳ.

ಖಾತೆಯ ಸಂದರ್ಭ ಕೇವಲ ಅನುಮತಿ-ಫ್ಲ್ಯಾಗ್ ಅಲ್ಲ

VPN ನಿಯೋಜನೆ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು UID ಮೂಲಕ, cgroup ಮೂಲಕ, ಅಥವಾ ಸಾಕೆಟ್ ತೆರೆದ ಪ್ರಕ್ರಿಯೆಗೆ ಸಂಬಂಧಿಸಿದ ನಿಯಮದ ಮೂಲಕ ವರ್ಗೀಕರಿಸಬಹುದು. ಆಗ root ಸಂಚಾರ ಮತ್ತು ಬಳಕೆದಾರ ಸಂಚಾರ ಬೇರೆ ಬೇರೆ ರೂಟಿಂಗ್ ಕೋಷ್ಟಕಗಳಿಂದ ಹೊರಬರುತ್ತವೆ ಅಥವಾ ಬೇರೆ ಬೇರೆ ನಿಯಮ ಗುಂಪುಗಳಿಗೆ ತಗಲುತ್ತವೆ, ಮತ್ತು ಸ್ಕ್ಯಾನ್ ವಿಧಾನದ ಯಾವುದೇ ಶಿಸ್ತು ಅವನ್ನು ಹೊಂದಿಸಲಾರದು.

ಅನುಮತಿಯಲ್ಲ, ನೀತಿಯನ್ನು ಪರಿಶೀಲಿಸಿ. Linux ನಲ್ಲಿ nftables ಇದನ್ನು meta skuid ನಿಂದ ವ್ಯಕ್ತಪಡಿಸುತ್ತದೆ ಮತ್ತು iptables ಮಾಲೀಕ-ಹೊಂದಾಣಿಕೆಯಿಂದ, ಮತ್ತು ಯಾವುದಾದರೂ ಒಂದು UID ಅನ್ನು ಸುರಂಗದಲ್ಲಿ ಕಳುಹಿಸಬಹುದು, ಇನ್ನೊಂದು ಭೌತಿಕ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವನ್ನು ಬಳಸುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತದೆ.

sudo nft list ruleset | grep -n skuid
sudo iptables-save | grep -n uid-owner
ip rule show
ip route get 198.51.100.77

ಫಲಿತಾಂಶಗಳನ್ನು ಹೋಲಿಸುವ ಮೊದಲು ಪ್ರೋಬ್ ಅನ್ನು ದೃಢೀಕರಿಸಿ

ತೀರ್ಮಾನಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುವ ಮೊದಲು ಯಾವ ಪ್ರೋಬ್ ಚಲಿಸಿತು ಎಂದು ಸಾಬೀತುಪಡಿಸಿ. Nmap ತನ್ನ ಔಟ್‌ಪುಟ್‌ನಲ್ಲಿ ತಂತ್ರವನ್ನು ಹೆಸರಿಸುತ್ತದೆ, ಮತ್ತು --reason ಪ್ರತಿ ಸ್ಥಿತಿಯ ಹಿಂದಿನ ಸಾಕ್ಷ್ಯವನ್ನು ಸೇರಿಸುತ್ತದೆ, ಮತ್ತು ಅದೇ ಭಾಗ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ನಿಜವಾಗಿ ಪೂರ್ಣಗೊಂಡಿತೇ ಎಂದು ಹೇಳುತ್ತದೆ.

nmap --reason -sT -Pn -n -p 8443 198.51.100.77
sudo nmap --reason -sS -Pn -n -p 8443 198.51.100.77
getcap "$(command -v nmap)"
capsh --print | grep -i net_raw

ಬೇರೆ ಬೇರೆ ಕಾರಣಗಳಿಗೆ ಒಂದೇ ಸ್ಥಿತಿಯನ್ನು ವರದಿ ಮಾಡುವ ಎರಡು ಚಲಾವಣೆಗಳು ವಿರೋಧಾಭಾಸವಲ್ಲ, ಮತ್ತು ಒಂದೇ ಕಾರಣಕ್ಕೆ ಬೇರೆ ಬೇರೆ ಸ್ಥಿತಿಗಳನ್ನು ವರದಿ ಮಾಡುವ ಎರಡು ಚಲಾವಣೆಗಳು ಸ್ಕ್ಯಾನ್ ಅಲ್ಲ, ರೂಟಿಂಗ್ ಅಥವಾ ನೀತಿಯತ್ತ ಸೂಚಿಸುತ್ತವೆ. ಗಮ್ಯ, ಪೋರ್ಟ್, ಹೆಸರಿನ ಜಾಗ ಮತ್ತು ಸಮಯವನ್ನು ಒಂದೇ ರೀತಿ ಇರಿಸಿ, ನಂತರ ಒಂದು ಸಲಕ್ಕೆ ಒಂದು ಚರವನ್ನು ಬದಲಿಸಿ. ಸೇವೆಯನ್ನು root ಆಗಿ ಚಲಾಯಿಸುವುದು ನೀತಿ-ಹೊಂದಾಣಿಕೆಯಿಲ್ಲದಿರುವಿಕೆಯ ಪರಿಹಾರವಲ್ಲ; ಪರಿಹಾರವೆಂದರೆ ಉದ್ದೇಶಿತ ನೀತಿಯನ್ನು ಸೇವೆಯ ಮಾಲೀಕರ ಮೂಲಕ ವ್ಯಕ್ತಪಡಿಸುವುದು.