กฎไฟร์วอลล์เฉพาะ NEW ไม่ได้ปิดทุกเส้นทาง WAN

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

สถานะเป็นเงื่อนไขการจับคู่ ไม่ใช่คำตัดสิน

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

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

อ่านกฎในบริบทโดยรอบ

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

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

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

แสดงข้อห้ามโดยไม่ขึ้นกับสถานะ

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

การเลือก reject แทน drop เปลี่ยนวิธีที่ทราฟฟิกที่ตรงกันล้มเหลว และไม่ได้ขยายชุดแพ็กเก็ตที่กฎเลือก การเชื่อมต่อที่ถูกปฏิเสธและเวลาหมดที่เงียบงันเป็นอาการต่างกันที่ชี้ไปยังการเลือกเดียวกัน

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

ตรวจสอบว่าใครอยู่ในกลุ่มจริง ๆ

ตัวอย่างครอบคลุมทราฟฟิก IPv4 ที่ส่งต่อจากคำนำหน้าหนึ่งออกทางอินเทอร์เฟซหนึ่ง ไม่ได้กล่าวถึง IPv6 ลิงก์อัปที่สอง หรือทราฟฟิกที่เราเตอร์สร้างเอง เราเตอร์ที่ทำหน้าที่เป็นตัวแก้ไข DNS จะส่งคำถามขึ้นต้นทางของตัวเอง และคำถามเหล่านั้นไม่ผ่านเชน forward เลย

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

iptables -S FORWARD
iptables -L FORWARD -v -n
cat /proc/net/nf_conntrack | grep -c ESTABLISHED

จากนั้นทดลองโฟลว์เก่าควบคู่กับโฟลว์ใหม่ การพยายามเชื่อมต่อใหม่และการถ่ายโอนสองทิศทางที่ทำงานอยู่แล้วมีพฤติกรรมต่างกันภายใต้กฎนี้ และการทดสอบทั้งสองอย่างเท่านั้นจึงจะแสดงว่าคุณมีนโยบายแบบใดจริง