ไม่มี tun0? จับคู่ IPsec ที่ถอดรหัสแล้วใน nftables ด้วย meta ipsec

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

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

สองแพ็กเก็ต หนึ่งอินเทอร์เฟซ

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

สิ่งที่ทำให้แตกต่างคือบริบทของเส้นทางความปลอดภัยขาเข้าที่แนบมากับแพ็กเก็ต nftables เปิดเผยสิ่งนี้เป็น meta ipsec exists ซึ่งเป็นจริงเมื่อแพ็กเก็ตมาจากเส้นทางความปลอดภัย IPsec รวมเข้ากับพูลไคลเอนต์ ปลายทาง และบริการ กฎก็จะเฉพาะเจาะจงพอที่จะปลอดภัย

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

เขียนกฎการส่งต่อ

สมมติว่ามีบริการเข้าถึงระยะไกล IPv4 ที่ผ่านการตรวจสอบแล้วโดยมีไคลเอนต์ใน 10.90.0.0/24 และปลายทางที่อนุมัติหนึ่งแห่งที่ 203.0.113.40 ส่วนของกฎสำหรับโฟลว์นั้นมีลักษณะดังนี้

meta ipsec exists ip saddr 10.90.0.0/24 \
  ip daddr 203.0.113.40 tcp dport 443 \
  oifname "eth0" counter accept

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

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

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

บริบทขาเข้าไม่ใช่บริบทขาออก

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

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

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

NAT ไม่ใช่การตัดสินใจของไฟร์วอลล์

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

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

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

ตรวจสอบบริการภายในที่แน่นอน

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

เอกสารอ้างอิง nftables อธิบาย meta ipsec, rt ipsec และนิพจน์เฉพาะทิศทาง และนั่นคือที่สำหรับตรวจสอบไวยากรณ์กับเวอร์ชันที่ติดตั้งของคุณ และรักษาขอบเขตให้ชัดเจน นี่คือตัวอย่าง IPv4 ไม่ได้กล่าวถึง IPv6 และไม่ได้ทำให้การส่งต่อพอร์ตสาธารณะตามอำเภอใจกลายเป็นส่วนหนึ่งของบริการ VPN