SSH แบบบาสเทียนหรือการเข้าถึง VPN โดยตรง: นโยบายใดใช้บังคับ

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

ตรวจสอบว่าบาสเทียนควบคุมอะไรจริงๆ

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

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

ตรวจสอบว่าเป้าหมายแยกเส้นทางได้หรือไม่

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

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

ตรวจสอบว่าแต่ละบันทึกเก็บอะไรจริงๆ

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

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

ตรวจสอบว่านโยบายถูกบังคับใช้ที่ใดจริงๆ

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

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

ssh -G app01.lab.internal | grep -iE '^(hostname|port|proxyjump|proxycommand)'

ตรวจสอบด้วยความพยายามตรงโดยเจตนา

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

nc -vz -w 3 10.20.30.41 22
ssh -J bastion.lab.internal app01.lab.internal true

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