กฎ UFW ใหม่กับการเชื่อมต่อเก่า: สถานะ established เป็นฝ่ายชนะ

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

ลำดับเป็นตัวตัดสิน ไม่ใช่การมีอยู่ของกฎ

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

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

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

แทรกเหนือการอนุญาตแบบกว้าง

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

sudo ufw --dry-run route insert 1 deny in on tun0 proto tcp from 10.88.0.55/32 to 192.0.2.88/32

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

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

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

โฟลว์ที่ established อยู่รอดจากกฎใหม่

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

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

อย่าลืมขอบเขตด้วย กฎนี้ไม่ได้พูดถึง ICMP, UDP หรือ IPv6 เลย ดังนั้น ping ที่สำเร็จไม่ใช่หลักฐานว่าการปฏิเสธล้มเหลว ที่อยู่ IPv4 หนึ่งที่อยู่ก็ไม่ใช่เว็บไซต์ ชื่อหนึ่งอาจแปลงเป็นหลายที่อยู่ และมีเพียงที่อยู่ที่คุณระบุเท่านั้นที่ครอบคลุม

ทดสอบด้วยโฟลว์ใหม่

อ่านกฎผู้ใช้แบบมีหมายเลขและมุมมองดิบที่มีผลจริง แล้วเปิดการเชื่อมต่อใหม่จากไคลเอนต์ที่เลือก

sudo ufw status numbered
sudo ufw show raw
# from 10.88.0.55, a new TCP connection to 192.0.2.88 should fail

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

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

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