กฎการเข้าถึงของ SSH และ VPN: รายการที่อนุญาตควบคุมอะไรจริง
ติดตามการเชื่อมต่อหนึ่งครั้งจากไคลเอนต์ถึงโฮสต์: ผ่านฮุกใด ทำไมการค้างและการถูกปฏิเสธจึงหมายถึงกฎที่ต่างกัน และทำไมการปฏิเสธไม่เคยเป็นนโยบาย
เชื่อมต่อหนึ่งครั้งก่อนเปลี่ยนกฎ แล้วบันทึกว่าไคลเอนต์ค้างหรือถูกปฏิเสธทันที ความต่างเพียงข้อเดียวนี้บอกว่าการตัดสินใจใดทิ้งแพ็กเก็ตและประหยัดเวลาอ่านไฟล์นโยบายไปหนึ่งชั่วโมง เส้นทางที่เหลือสั้น: แพ็กเก็ตข้ามฮุกหนึ่งตัว จับคู่กับกฎ แล้วไปถึงตัวรับฟังหรือไม่ถึง รายการที่อนุญาตเป็นเพียงการทำบัญชีรอบข้อเท็จจริงสามข้อนั้น
ติดตามความพยายาม SSH หนึ่งครั้งไปจนถึงฮุกขาเข้า
ไคลเอนต์ส่ง SYN ไปยังที่อยู่ของโฮสต์ที่พอร์ต 22 และเคอร์เนลตัดสินว่าแพ็กเก็ตนั้นสำหรับบริการภายในหรือไม่ ถ้าใช่ เส้นทางขาเข้าจะทำงานและชุดกฎจะรับแพ็กเก็ตหรือทิ้งมัน ความเงียบหมายความว่า SYN ตายก่อนที่ตัวรับฟังจะเห็นมัน ส่วนการปฏิเสธอย่างรวดเร็วหมายความว่ามีบางสิ่งตอบกลับด้วยการรีเซ็ต นี่คือคำตัดสินที่ต่างกันจากกฎที่ต่างกัน และทั้งสองเป็นผลลัพธ์ที่ชอบด้วยเหตุผล
จากนั้นยืนยันตัวรับฟัง เพราะไม่มีกฎใดกอบกู้บริการที่ไม่มีอยู่ได้ รัน ss -ltnp และตรวจสอบว่ามีบางสิ่งผูกกับพอร์ตและตระกูลที่อยู่ที่คุณคาดหวัง แล้วอ่าน ssh -v บนไคลเอนต์เพื่อดูว่ามันหยุดที่ใด
การส่งต่อเป็นการตัดสินใจแยกต่างหาก
บนเซิร์ฟเวอร์ VPN ฮุกที่น่าสนใจกว่าคือ forward เพราะทราฟฟิกของไคลเอนต์ถูกกำหนดเส้นทางผ่านเครื่องแทนที่จะถูกส่งให้เครื่อง เครื่องที่เป็นโฮสต์ซึ่งรันไคลเอนต์ VPN ของตัวเองเท่านั้นต้องการชุดกฎที่เล็กกว่ามากกว่าเครื่องที่ส่งต่อแพ็กเก็ตของผู้อื่น การผสมสองดีไซน์บนเครื่องเดียวทำให้เกิดกฎที่ดูถูกต้องและไม่ปล่อยอะไรผ่านเลย
เขียนนโยบายภายในเป็นคำถามแยกต่างหาก: ที่อยู่ไคลเอนต์ใดเข้าถึงปลายทางใดได้ผ่านอุโมงค์ เก็บเส้นทางบริหาร เช่น SSH ไว้บนเส้นทางขาเข้าพร้อมข้อจำกัดต้นทางของตัวเอง กฎ forward ที่ผ่อนปรนซึ่งเพิ่มระหว่างการทดสอบคือข้อบกพร่องคลาสสิกที่อายุยืนกว่าการทดสอบ ดังนั้นหลังการเปลี่ยนแปลงให้ทบทวนชุดกฎทั้งหมดไม่ใช่บรรทัดเดียวที่คุณแก้ การเปิดตัวรับฟังของอุโมงค์ไม่ใช่การอนุญาตให้ไคลเอนต์ที่เชื่อมต่อทุกตัวบริหารโฮสต์
การทิ้งและการปฏิเสธเป็นการกระทำ ไม่ใช่นโยบาย
นโยบายของเชนฐานรับหรือทิ้ง และนั่นคือรายการตัวเลือกทั้งหมด ตามที่ เอกสารอ้างอิง nftables กล่าว การปฏิเสธมีอยู่เป็นการกระทำของกฎที่มีการเลือกคำตอบ จึงเขียนเป็นนโยบายไม่ได้ทั้งบน nftables และ iptables ในทางปฏิบัติ drop ไม่ให้ข้อมูลใดแก่ไคลเอนต์ ขณะที่ reject ให้ข้อผิดพลาดที่มันนำไปใช้ได้
table inet admin {
chain input {
type filter hook input priority filter; policy drop;
ct state established,related accept
ip saddr 203.0.113.0/28 tcp dport 22 accept
udp dport 51820 accept
icmp type { destination-unreachable, time-exceeded } accept
}
}
อ่านภาพร่างนั้นเป็นรูปทรงของการตัดสินใจ ไม่ใช่ไฟล์สำหรับวาง เพราะช่วงที่อยู่เป็นเพียงตัวอย่าง การ reject อย่างชัดเจนบนพอร์ต SSH ทำให้ไคลเอนต์ที่ไม่ได้รับอนุญาตล้มเหลวในหนึ่งวินาทีแทนที่จะรอหมดเวลา ซึ่งย่นเวลาการแก้จุดบกพร่องของคุณเอง ความเงียบยับยั้งการสแกนโดยบังเอิญและไม่บอกอะไรกับผู้ใช้ที่ได้รับอนุญาตเลย เลือกเป็นรายบริการและจดเหตุผลไว้ ไม่อย่างนั้นคนถัดไปจะเปลี่ยนกลับ
เก็บทราฟฟิกควบคุมที่คุณต้องการจริง ๆ ไว้
การบล็อก ICMP ทั้งหมดเป็นค่าเริ่มต้นยอดนิยมที่ทำให้การค้นหา MTU ของเส้นทางพัง และอาการคือการเชื่อมต่อที่สร้างขึ้นแล้วหยุดที่แพ็กเก็ตใหญ่กว่า การค้นหาเพื่อนบ้านบน IPv6 ขึ้นกับชนิด ICMPv6 ของตัวเอง และการทิ้งชนิดเหล่านั้นทำให้ลิงก์ขาดก่อนที่จะมีการอ่านกฎ TCP ใด ๆ ทั้งสองอย่างควรอยู่ในรายการที่อนุญาตในฐานะการพึ่งพาที่มีชื่อ ไม่ใช่การอนุญาตแบบเหมารวม นโยบายที่ทำให้การค้นหาพังเงียบ ๆ แย่กว่านโยบายที่ยอมให้ทราฟฟิกวินิจฉัยผ่านไปบ้าง
อนุญาตสถานะ established และ related สำหรับการเชื่อมต่อที่คุณเริ่มเอง และปล่อยให้เอนจินที่ติดตามสถานะจัดการคำตอบ จากนั้นยืนยันว่าเส้นทางคำตอบไม่ถูกบล็อกไกลออกไป เพราะข้อจำกัดเฉพาะทราฟฟิกขาออกที่อยู่เหนือขึ้นไปก่อให้เกิดการหมดเวลาแบบเดียวกับที่คุณกำลังจะโทษโฮสต์
พิสูจน์การกู้คืนก่อนเลิกใช้เส้นทางเดิม
เปิดเซสชันคอนโซลค้างไว้ ใช้การเปลี่ยนแปลง แล้วเปิดการเชื่อมต่อบริหารใหม่ทั้งหมดจากเทอร์มินัลอื่น เซสชันที่มีอยู่ไม่ได้พิสูจน์อะไร เพราะมันอาจรอดจากกฎที่บล็อกการเข้าสู่ระบบใหม่ทุกครั้ง ซึ่งทำให้มันเป็นผลบวกลวงที่น่าเชื่อที่สุดในงานไฟร์วอลล์ หากระบบตรวจสอบตรวจโฮสต์ ให้เพิ่มที่อยู่ต้นทางของมันก่อนการเปลี่ยนแปลง ไม่ใช่หลังการแจ้งเตือนครั้งแรก จากนั้นทดสอบแพ็กเก็ตใหญ่หนึ่งและเล็กหนึ่งเพื่อพิสูจน์ว่าการค้นหยังทำงานอยู่
สำหรับบริการ VPN ให้ทำซ้ำจากไคลเอนต์ที่ไม่เคยเชื่อมต่อเลย เพราะเซสชันที่กลับมาทำต่ออาจใช้สถานะซ้ำที่เซสชันใหม่ต้องเจรจา บันทึกชุดกฎที่ผ่านอย่างแม่นยำพร้อมเช็กซัมหรือสำเนา เพื่อให้การแก้ไขภายหลังนำมาเปรียบเทียบได้แทนการเดา ประสานกับผู้ที่เป็นเจ้าของลำดับกฎ เพราะกฎที่มาก่อนจะชนะกฎที่คุณเพิ่มอย่างเงียบ ๆ