ike-scan ไม่ได้รับการตอบสนองจากเกตเวย์ IPsec ที่ทำงานอยู่

เกตเวย์ให้บริการโทรศัพท์และแล็ปท็อปทุกวัน แต่ ike-scan รายงานว่าไม่มีโฮสต์ใดตอบสนอง เอาต์พุตนั้นอ่านเหมือนเป็นหลักฐานว่าเครื่องไม่มี IPsec โดยปกติหมายความว่าเครื่องทิ้งทุกข้อเสนอในการตรวจและเลือกที่จะไม่ตอบอะไรเลย ความเงียบก็เป็นการตอบสนอง และเป็นคำตอบที่ให้ข้อมูลน้อยที่สุดที่เครื่องมือนี้ให้คุณได้

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

ขั้นตอนที่ 1: อ่านข้อเสนอที่เครื่องมือส่ง

โหมดหลักเริ่มด้วยเพย์โหลด SA ที่ระบุการแปลงที่ผู้ริเริ่มจะยอมรับ และ ike-scan เติมรายการนั้นจากค่าเริ่มต้นที่คอมไพล์ไว้ ชุดค่าเริ่มต้นถูกทำให้เก่าโดยตั้งใจ: DES และ 3DES สำหรับการเข้ารหัส MD5 และ SHA1 สำหรับแฮช กลุ่ม 1 และ 2 สำหรับการแลกเปลี่ยนกุญแจ กุญแจที่แชร์ล่วงหน้าสำหรับการรับรองความถูกต้อง ไม่มี AES ไม่มี SHA-2 ไม่มีกลุ่ม 14 เกตเวย์ที่กำหนดค่าสำหรับ AES-256 กับ SHA-256 และ modp2048 ไม่มีอะไรใช้ร่วมกันกับชุดนี้

บางการใช้งานตอบกลับการตรวจที่ไม่ตรงกับ การแจ้งเตือน NO-PROPOSAL-CHOSEN บางตัวก็ทิ้งไปเฉย ๆ ซึ่งเป็นเรื่องปกติในอุปกรณ์ที่ถือว่าคู่สนทนาที่ไม่รู้จักเป็นสัญญาณรบกวน ไม่ว่าจะทางใด การสแกนก็ไม่พิมพ์อะไร และความไม่มีนั้นเหมือนกับ UDP 500 ที่ถูกกรองเมื่อมองจากภายนอก ตามที่เอกสารโครงการ ike-scan ชี้แจงเกี่ยวกับชุดค่าเริ่มต้น

ขั้นตอนที่ 2: เสนอข้อเสนอที่ทันสมัยหนึ่งรายการ

แทนที่ชุดค่าเริ่มต้นด้วย --trans รูปแบบแอตทริบิวต์ใช้หมายเลขแอตทริบิวต์ IKE โดยตรง: 1 สำหรับการเข้ารหัส 2 สำหรับแฮช 3 สำหรับการรับรองความถูกต้อง 4 สำหรับกลุ่ม และ 14 สำหรับความยาวกุญแจเมื่ออัลกอริทึมใช้ สิ่งที่ออกมาคือบรรทัดที่คุณอ่านออกเสียงได้ในการทบทวนการเปลี่ยนแปลง

รูปแบบตำแหน่งนำค่าเดียวกันตามลำดับและหลีกเลี่ยงวงเล็บ ซึ่งสำคัญเมื่อคำสั่งผ่านเชลล์

ike-scan --trans="(1=7,14=256,2=5,3=1,4=14)" 203.0.113.10

หนึ่งข้อเสนอต่อแพ็กเก็ตช้าเมื่อคุณแจกแจง ดังนั้นวนซ้ำค่าที่เป็นไปได้: การเข้ารหัส 5, 7/128, 7/192, 7/256; แฮช 1, 2, 5, 6, 7; กลุ่ม 1, 2, 5, 14, 15, 19, 20, 21; การรับรองความถูกต้อง 1 สำหรับกุญแจที่แชร์ล่วงหน้า และ 3 สำหรับลายเซ็น RSA พิมพ์ทุกคำสั่งก่อนเรียกใช้ เพื่อให้บันทึกแสดงว่ามีการเสนออะไรและตามลำดับใด

ขั้นตอนที่ 3: ตีความการตอบสนอง

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

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

ขั้นตอนที่ 4: ตีความความเงียบ

ความเงียบเป็นหลักฐานที่อ่อนกว่าที่เห็น ทุกข้อเสนออาจถูกปฏิเสธ UDP 500 และ 4500 อาจถูกกรอง แหล่งที่มาอาจถูกจำกัดอัตราหลังการระเบิด หรือบริการอาจฟังที่อยู่คนละที่กับที่คุณสแกน เปรียบเทียบบันทึก IKE ของเกตเวย์กับไคลเอนต์ที่เชื่อมต่ออยู่แล้วด้วยข้อมูลรับรองที่ถูกต้องก่อนสรุปอะไรเกี่ยวกับกล่องนี้

พฤติกรรมตอนระเบิดอยู่ในรายการนั้นเพราะการแจกแจงสร้างแพ็กเก็ตจำนวนมากในช่วงเวลาสั้น เกตเวย์ที่ตอบความพยายามแรกแล้วเงียบไปกำลังอธิบายนโยบาย anti-DoS ของตน ไม่ใช่ชุดข้อเสนอ

ขั้นตอนที่ 5: บันทึกสิ่งที่คุณพิสูจน์ได้

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

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