การสแกนแบบ raw ของ Nmap ล้มเหลวผ่าน VPN แต่การเชื่อมต่อ -sT ยังใช้ได้?

หน้าเว็บโหลดผ่านอุโมงค์ แต่การสแกนพอร์ตรายงานว่าโฮสต์อยู่ในสภาพดับ และความคิดแรกคือ VPN กำลังบล็อกอะไรสักอย่าง โดยปกติมันไม่บล็อกสิ่งใหม่ การทดสอบทั้งสองขอระบบปฏิบัติการความสามารถต่างกัน และมีเพียงอย่างเดียวที่ต้องใช้การเข้าถึงแพ็กเก็ตแบบ raw จงระบุว่าความสามารถใดล้มเหลวก่อนที่จะแตะอุโมงค์

แยกความสามารถออกจากอุโมงค์

แอปปลิเคชันปกติขอให้เคอร์เนลเปิดการเชื่อมต่อ TCP และเคอร์เนลทำการจับมือโดยไม่ต้องมีสิทธิ์พิเศษ ส่วนการสแกนแบบ raw จะสร้างแพ็กเก็ตเอง ซึ่งต้องใช้รองเซ็กแบบ raw หรือไดเวอร์จับเงาตามแพลตฟอร์ม เหล่านี้คือคำถามเรื่องสิทธิ์และไดเวอร์ ซึ่งมีอยูไม่ว่า VPN จะเชื่อมต่อหรือไม่

ความแตกต่างนี้อธิบายความไม่สมดุลที่พบปกติ curl สำเร็จเพราะเส้นทางของซ็อกเก็ตทำงาน แต่การสแกน SYN ล้มเหลวเพราะโปรเซสเปิดซ็อกเก็ตแบบ raw บนอินเตอร์เฟสของอุโมงค์ไม่ได้ มันยังอธิบายกรณีกลับกัน คือเมื่อการสแกนแบบ raw รายงานว่าถูกกรอง เพราะเส้นทางทิ้งโปรบ แต่เส้นทางของแอปปลิเคชันยังดีอยู่

ไม่มีผลลัพธ์ใดอธิบายบริการระยะไกล ทั้งสองอธิบายเส้นทางเดียวภายใต้วิธีเดียว ดังนั้นจึงควรผูกวิธีไว้กับข้อสรุป

รันการตรวจสอบการเชื่อมต่อบนโฮสต์ที่อนุมัติหนึ่งเหน่งเท่านั้น

เลือกโฮสต์เดียวที่งานของคุณครอบคลุม แล้วใช้โหมดที่ไม่ต้องการการเข้าถึงแบบ raw เป้าหมายตัวอย่างที่นี่คือ 198.51.100.24 ซึ่งเป็นช่วงเอกสารเอกสารที่รวงไว้สำหรับการสาธิตทำนองนี้

หนึ่งบรรทัด หนึ่งโฮสต์ หนึ่งพอร์ต ไม่มีระยะการค้นหา

nmap -sT -Pn -p 443 --unprivileged 198.51.100.24

-sT เลือกการเชื่อมต่อ TCP แบบเต็มรูปแบบ ดังนั้นมันจึงใช้เส้นทางเคอร์เนลเดียวกับที่แอปปลิเคชันใช้ และไม่ต้องการไดเวอร์จับเงา -Pn ข้ามการค้นหาโฮสต์ nmap ยังคลี่คลายชั้นลิงก์สำหรับเป้าหมายในเซกเมนต์ท้องถิ่น ดังนั้นแฟล็กนี้ไม่ใช่คำสัญญาว่าจะไม่มีทราฟฟิกก่อนหน้า --unprivileged บอกให้ nmap สมมุติว่าไม่มีสิทธิ์แบบ raw หรือสิทธิ์ดักฟัง ซึ่งเปลี่ยนวิธีและไม่ให้อะไรเลย

อ่านแต่ละแฟล็กเป็นการเปลี่ยนหนึ่งอย่าง ไม่ใช่การซ่อม

มองทุกตัวเลือกเป็นข้อความเกี่ยวกับวิธี ไม่มีตัวใดใน -sT -Pn หรือ --unprivileged ที่เพิ่มเส้นทาง เปิดไฟร์วอลระยะไกล หรือตรวจสอบใบรับรอง การสแกนแบบเชื่อมต่อยังทำการจับมือจริงที่บริการบันทึก ดังนั้นการตรวจสอบที่อนุมัติกับการกวาดที่ไม่อนุมัติจะดูเหมือนกันจากเซิร์ฟเวอร์ ยกเว้นขอบเขตและจังหวะ การพูนตัวเลือกจนกว่าผลลัพธ์จะเปลี่ยนคือวิธีที่ปัญหาของวิธีถูกบันทึกเป็นข้อค้นพบด้านเครือข่าย

เมื่อผลลัพธ์บอกว่าปิด หมายความว่ามีบางสิ่งตอบกลับด้วยการรีเซ็ต ซึ่งเป็นข้อค้นพบต่างจากความเงียบ เมื่อผลลัพธ์บอกว่าถูกกรอง หมายความว่าอุปกรณ์ทิ้งโปรบหรือคำตอบของโปรบ และ VPN อาจเป็นเรื่องบังเอิญ จดคำเป็นเอาไว้ให้ชัด เพราะคำตัดสินของระยะการค้นหากับความล้มเหลวระดับโปรบชี้ไปที่ชั้นต่างกัน

ถ้าโหมดที่มีสิทธิ์พิเศษจำเป็นต้องจริง เจ้าของแพลตฟอร์มเป็นผู้ตัดสินว่าสิทธิ์ ไดเวอร์ และการจัดวางอินเตอร์เฟสรับหรือไม่ การยกระดับการเรียกเดียวกันไม่เปลี่ยนวิธีของมัน

หยุดที่ผลลัพธ์ของการขนส่ง แล้วทดสอบบริการ

การจับมือที่สำเร็จตอบคำถามเรื่องหนึ่งที่อยู่หนึ่ง พอร์ต แหล่งกำเนิด และช่วงเวลา มันไม่พิสูจน์ว่าภาคหลังสุขภาพ เพราะตัวกระจายภารหรือโปรกซีด้านหน้าอาจรับการเชื่อมต่อขณะที่แอปปลิเคชันด้านหลังหยุดทำงาน

ต่อด้วยคลายแอนท์ของบริการเอง เพื่อให้ตัวตน TLS และพฤติกรรมของแอปปลิเคชันถูกสังเกตเป็นข้อเท็จจริงแยกกัน

openssl s_client -connect 198.51.100.24:443 -servername staging.example.net </dev/null 2>/dev/null | openssl x509 -noout -subject -dates
curl -sS -o /dev/null -w '%{http_code}\n' https://staging.example.net/health

อีกนิสัยหนึ่งช่วยทำให้ผลลัพธ์มีประโยชน์ต่อไป จดคำสั่งที่ใช้จริง ที่อยู่ต้นทางที่ใช้ และเวลา เพราะผลลัพธ์ของการขนส่งโดยไม่มีบริบทศนี้ไม่สามารถทำซ้ำหรือเปรียบเทียบได้

ถ้าใบรับรองระบุชื่อโฮสต์ที่คุณไม่คาดคิด การขนส่งทำงานและการเส้นทางไม่เคยเป็นปัญหา ความผิดพลาดอยู่ที่โฮสต์เอิงแบบเสมือนหรือ DNS ถ้าการจับมือล้มเหลว ให้บันทึกสตริงข้อผิดพลาดท้องถิ่นแทนที่จะสรุปเป็นกลางเกี่ยวกับอุโมงค์ เก็บบันทึกขอบเขตไว้ข้างผลลัพธ์ เพราะคนต่อไปต้องรู้ว่าวิธีใดสร้างสิ่งนี้ขึ้นมา