ทำไมการสแกนพอร์ตจึงเปลี่ยนเมื่อรันด้วย sudo

Nmap ไม่ได้ส่งแพ็กเก็ตที่คุณคิดว่าคุณขอทุกครั้ง เมื่อไม่มี raw socket มันจะแทนที่การสแกน SYN เริ่มต้นด้วยการสแกน TCP connect ดังนั้นการรันในฐานะผู้ใช้ปกติและการรันภายใต้ sudo อาจตอบคำถามที่ต่างกันเกี่ยวกับพอร์ตเดียวกัน ผลลัพธ์ดูเหมือนปัญหาเรื่องสิทธิ์ แต่จริง ๆ แล้วมักเป็นการเปลี่ยนวิธีการ การระบุวิธีการให้ชัดเจนเป็นหนทางเดียวที่จะเปรียบเทียบการรันทั้งสองได้

สองโพรบ หนึ่งพอร์ต เส้นทางโค้ดที่ต่างกัน

การสแกน SYN สร้างส่วนหัว TCP เอง ส่งจาก raw socket และอ่านคำตอบจากเครือข่ายก่อนที่สแตก TCP ของเคอร์เนลจะบันทึกการเชื่อมต่อที่สมบูรณ์ การสแกน connect ขอให้ระบบปฏิบัติการเปิดซ็อกเก็ตธรรมดาและรายงานสิ่งที่ connect() ส่งคืน ทั้งสองอาจบอกว่าพอร์ตเปิด แต่มีเพียงวิธีเดียวที่ทิ้งความพยายามแบบครึ่งเปิด และมีเพียงวิธีเดียวที่อยู่ภายใต้นโยบายระดับซ็อกเก็ตที่ผูกกับโปรเซสผู้ส่ง

เส้นทาง raw ต้องใช้ CAP_NET_RAW จึงทำให้การสแกนเริ่มต้นอ่อนลงอย่างเงียบ ๆ เมื่อขาดความสามารถนั้น เอกสารอ้างอิงเทคนิคการสแกน ของ Nmap เองบันทึกการแทนที่นี้ไว้ การสแกน connect เป็นตัวสำรองเพราะไม่ต้องใช้สิทธิ์พิเศษใด ๆ เลย การสลับเกิดขึ้นโดยไม่มีคำเตือนในการรันส่วนใหญ่ และนั่นคือสิ่งที่ทำให้อ่านผิดได้ง่าย เมื่อรู้ว่ามีตัวสำรองอยู่ “เปิดในฐานะ root ปิดในฐานะผู้ใช้” ก็ไม่ฟังดูเป็นข้อบกพร่องเรื่องสิทธิ์อีกต่อไป และเริ่มฟังดูเป็นการวัดสองแบบที่ต่างกัน

sudo เปลี่ยนอะไรจริง ๆ ในการสแกน

การยกระดับสิทธิ์คืนเส้นทาง raw socket และสิ่งนั้นเปลี่ยนมากกว่าคำตัดสิน การเลือกพอร์ตต้นทาง จังหวะของแพ็กเก็ต พฤติกรรมการส่งซ้ำ และวิธีจำแนกคำตอบที่ถูกกรอง ล้วนมาจากโค้ดที่ต่างกัน อุปกรณ์กลางที่จำกัดอัตรา 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 ไม่ใช่การแก้ไขความไม่สอดคล้องของนโยบาย การแสดงนโยบายที่ตั้งใจผ่านเจ้าของบริการต่างหากคือการแก้ไข