กลุ่มความปลอดภัยบนคลาวด์สำหรับ VPN: เปิดผู้รับฟัง ไม่ใช่เปิดทั้งหมด

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

ระบุโปรโตคอลก่อนกฎ

กฎคือโปรโตคอล ช่วงพอร์ต และแหล่งที่มา WireGuard ฟังบน UDP โดยทั่วไปคือ 51820 OpenVPN มักเป็น UDP หรือ TCP 1194 ขึ้นอยู่กับการกำหนดค่า IPsec ต้องมีการแลกเปลี่ยน IKE บน UDP 500 และ 4500 รวมถึงโปรโตคอล ESP เอง ซึ่งเป็นหมายเลขโปรโตคอลไม่ใช่พอร์ต การเดาว่าเป็น TCP เพราะกฎอื่นเป็น TCP คือวิธีที่ทำให้ได้กฎที่ดูถูกต้องแต่ไม่ตรงกับอะไรเลย

อ่านผู้รับฟังจากบริการที่กำลังทำงาน ไม่ใช่จากบทแนะนำ. เดมอนที่ผูกกับที่อยู่หนึ่งจะไม่รับทราฟฟิกที่มาถึงอีกที่อยู่หนึ่ง

จำกัดแหล่งที่มาให้อยู่ในช่วงไคลเอนต์ที่การออกแบบอนุญาต แทนที่จะเป็นอินเทอร์เน็ตทั้งหมด

กลุ่มความปลอดภัยเก็บสถานะ แต่ ACL ของซับเน็ตไม่เก็บ

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

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

นโยบายที่บังคับใช้คือการรวมกันของสิ่งที่ผูกอยู่ ไม่ใช่ไฟล์ที่คุณแก้ไข

ไฟร์วอลล์ของโฮสต์เป็นขอบเขตแยกต่างหาก

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

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

การดักจับบนอินเทอร์เฟซบอกคุณว่าขอบเขตใดทิ้งแพ็กเก็ต

การอนุญาตผู้รับฟังไม่ใช่การกำหนดเส้นทางให้ไคลเอนต์

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

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

แก้เส้นทางเป็นการเปลี่ยนแปลงแยกต่างหากพร้อมการตรวจสอบของตัวเอง และบันทึกว่าเกตเวย์ที่ส่งต่อต้องมีนโยบายขาออกที่อนุญาตปลายทางด้วย

เก็บทางกลับไว้ แล้วค่อยทำให้กฎแคบลง

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

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

จัดทำเอกสารการผูกด้วย มิฉะนั้นอินเทอร์เฟซทดแทนจะสูญเสียนโยบายไปอย่างเงียบ ๆ