conntrack NEW บนแพ็กเก็ต ACK: สิ่งที่มันไม่ได้พิสูจน์

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

เริ่มจากแพ็กเก็ต ไม่ใช่จากคำตัดสิน

แยกข้อสังเกตออกจากกันก่อนตีความ แฟล็ก TCP อธิบายแพ็กเก็ตนี้ สถานะของตัวติดตามอธิบายว่ามันรู้อะไร ณ hook นั้น และการดักจับของคุณอธิบายเฉพาะหน้าต่างที่คุณบันทึกไว้

การหลอมสามสิ่งนี้เข้าด้วยกันคือทางที่ ACK กลายเป็น “ผู้ให้บริการปล่อยใครบางคนเข้ามา”

NEW หมายถึงอะไรจริง ๆ ที่ hook

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

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

การติดตามแบบหลวมอธิบายความประหลาดใจเรื่อง ACK ส่วนใหญ่ได้

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

ดังนั้นตรวจสอบค่านั้นก่อนจะสร้างทฤษฎีบนป้าย

ตัดสาเหตุที่น่าเบื่อออกตามลำดับนี้

เหตุการณ์ NEW บน ACK ส่วนใหญ่ที่ผมตามมานั้นจบลงที่สาเหตุใดสาเหตุหนึ่งเหล่านี้ และทั้งหมดตรวจสอบได้ถูก:

• ตาราง conntrack ถูกฟลัช หรือตัวติดตามเริ่มทำงานใหม่
• โฮสต์รีบูต หรือโฟลว์ย้ายไป namespace หรืออุปกรณ์อื่น
• การกำหนดเส้นทางแบบไม่สมมาตรส่ง SYN ออกไปในเส้นทางที่คุณไม่ได้ดักจับ
• NAT เขียน tuple ใหม่ ดังนั้นรายการจึงไม่ตรงกับที่คุณอ่านอีกต่อไป
• การดักจับเริ่มช้าและไม่เคยเห็นจุดเริ่มต้น

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

จดไว้ว่าคุณตัดข้อใดออก และอย่างไร ก่อนจะไปต่อ

อ่าน tuple, อินเทอร์เฟซ และ hook

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

สองมุมมองของโฟลว์เดียวที่ขัดกันให้ข้อมูลมากกว่าอย่างใดอย่างหนึ่ง

เมื่อใดจึงคุ้มที่จะยกระดับ

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

จากนั้นปิดช่องว่างด้านการมองเห็นที่ทำให้แพ็กเก็ตเดียวดูเหมือนทั้งเซสชัน