วิธีทดสอบว่าสวิตช์ฉุกเฉินครอบคลุมอะไรบนโฮสต์ที่ถูกเจาะ

เปิดสวิตช์ฉุกเฉิน ตัดเซิร์ฟเวอร์อุโมงค์ออกจากเครือข่าย แล้วสังเกตว่าเครื่องยังทำอะไรอยู่ การทดสอบนี้คุ้มค่าเพราะมันแยกสิ่งที่ไฟร์วอลล์บังคับใช้จริงออกจากสิ่งที่คุณสันนิษฐาน และผลลัพธ์ก็แคบกว่าที่หน้าเว็บผลิตภัณฑ์ส่วนใหญ่บอก สวิตช์ฉุกเฉินควบคุมเส้นทางเครือข่าย ไม่ได้ควบคุมซอฟต์แวร์ที่รันอยู่บนอุปกรณ์แล้ว ฉันรันลำดับนี้บนทุกเครื่องที่ไคลเอนต์อ้างว่าเป็น fail-closed และใช้เวลาราวสิบนาที

เริ่มจากไคลเอนต์ ไม่ใช่เซิร์ฟเวอร์

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

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

ขั้นแรก: ยืนยันการบล็อกบนเส้นทางที่คุณคิดว่ามันครอบคลุม

ลดอุโมงค์ลงที่ปลายทางไกล ไม่ใช่ที่ไคลเอนต์ เพื่อให้ไคลเอนต์ยังเชื่อว่าควรเชื่อมต่ออยู่ จากนั้นลองสิ่งที่คนจะลองจริง ๆ:

curl -m 5 -sS -o /dev/null -w '%{http_code}
' https://example.com
ping -c 2 1.1.1.1
ip route
nft list ruleset   # or: iptables -S

คุณต้องการไคลเอนต์ที่ล้มเหลวอย่างรวดเร็วและสะอาด ไม่ใช่ตัวที่ค้างจนถึงเวลาหมดของเบราว์เซอร์ การค้างมักหมายความว่าแพ็กเก็ตถูกทิ้งอย่างเงียบ ๆ โดยกฎที่ไม่มีการปฏิเสธ ซึ่งยอมรับได้ แต่อาจหมายความว่าไคลเอนต์ทิ้งเส้นทางเริ่มต้นเก่าที่ชี้ไปยังอินเทอร์เฟซที่ตายแล้ว อ่านตารางเส้นทางขณะอุโมงค์ลง: เส้นทางเริ่มต้นที่ยังชี้ไปยังอุปกรณ์อุโมงค์กับกฎไฟร์วอลล์ที่บล็อกเฉพาะการเชื่อมต่อขาออกใหม่เป็นสองสถานะที่ต่างกัน และมีเพียงหนึ่งเดียวที่เป็น fail-closed

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

ขั้นที่สอง: ตรวจสอบ DNS และ IPv6 เป็นเส้นทางแยกกัน

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

dig +short example.com
dig +short @1.1.1.1 example.com
curl -6 -m 5 -sS https://example.com -o /dev/null -w '%{http_code}
'
ip -6 route

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

เบราว์เซอร์ทำให้อ่านจากภายนอกได้ยากขึ้น เพราะเบราว์เซอร์ที่ตั้งค่า DNS over HTTPS จะแก้คำถามผ่านคำขอ HTTPS คำถามจึงถูกบล็อกเท่ากับพอร์ต 443 ที่ไปยังปลายทางนั้น บนโฮสต์ที่นโยบายอนุญาตซับเน็ตภายใน คำขอนั้นยังเข้าถึงตัวแก้ไขใน LAN ได้

ขั้นที่สาม: แยกการเปิดเผยเครือข่ายออกจากการเปิดเผยปลายทาง

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

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

ตัวจัดการคลิปบอร์ดที่อัปโหลดไปยังบัญชีคลาวด์แสดงจุดนี้อย่างคมชัด ทราฟฟิกถูกเข้ารหัส ปลายทางได้รับอนุญาต และสวิตช์ฉุกเฉินรายงานสถานะแข็งแรงตลอดเวลา

ขั้นที่สี่: เขียนข้อกล่าวอ้างที่การทดสอบของคุณรองรับ

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

แยกปัญหาสองข้อออกจากกันและให้การควบคุมของตัวเองแก่แต่ละข้อ:

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

รันลำดับอีกครั้งหลังการอัปเดตครั้งถัดไป เพราะสวิตช์ฉุกเฉินเป็นการกำหนดค่าที่เคลื่อนไปตามเวอร์ชัน การทดสอบเป็นหลักฐานเดียวว่าพฤติกรรมที่คุณพึ่งพายังเป็นพฤติกรรมที่คุณได้รับ