13 มีนาคมถึงคณะทำงานต่อต้านการละเมิด RIPE พิจารณาว่าการไฮแจ็ก BGP (hjjack) ถือเป็นการละเมิดนโยบาย RIPE หากข้อเสนอได้รับการยอมรับ ผู้ให้บริการอินเทอร์เน็ตที่ถูกโจมตีโดยการสกัดกั้นการรับส่งข้อมูลจะมีโอกาสที่จะส่งคำขอพิเศษเพื่อเปิดโปงผู้โจมตี หากทีมตรวจสอบรวบรวมหลักฐานสนับสนุนที่เพียงพอ LIR ซึ่งเป็นแหล่งที่มาของการสกัดกั้น BGP จะถือเป็นผู้บุกรุกและอาจถูกถอดสถานะ LIR ของมัน นอกจากนี้ยังมีข้อโต้แย้งบางอย่าง การเปลี่ยนแปลง
ในเอกสารเผยแพร่นี้ เราต้องการแสดงตัวอย่างการโจมตีที่ไม่เพียงแต่ผู้โจมตีที่แท้จริงเท่านั้นที่ถูกตั้งคำถาม แต่ยังรวมถึงรายการคำนำหน้าที่ได้รับผลกระทบทั้งหมดด้วย ยิ่งไปกว่านั้น การโจมตีดังกล่าวทำให้เกิดคำถามอีกครั้งเกี่ยวกับแรงจูงใจในการสกัดกั้นการรับส่งข้อมูลประเภทนี้ในอนาคต
ในช่วงสองสามปีที่ผ่านมา มีเพียงข้อขัดแย้งเช่น MOAS (Multiple Origin Autonomous System) เท่านั้นที่ถูกกล่าวถึงในสื่อว่าเป็นการสกัดกั้น BGP MOAS เป็นกรณีพิเศษที่ระบบอัตโนมัติสองระบบที่แตกต่างกันโฆษณาคำนำหน้าที่ขัดแย้งกันกับ ASN ที่สอดคล้องกันใน AS_PATH (ASN แรกใน AS_PATH ซึ่งต่อไปนี้จะเรียกว่า ASN ต้นทาง) อย่างไรก็ตาม อย่างน้อยเราก็สามารถตั้งชื่อได้ การสกัดกั้นการรับส่งข้อมูล ช่วยให้ผู้โจมตีสามารถจัดการแอตทริบิวต์ AS_PATH เพื่อวัตถุประสงค์ต่างๆ รวมถึงการหลีกเลี่ยงวิธีการกรองและการตรวจสอบที่ทันสมัย ประเภทการโจมตีที่รู้จัก - การสกัดกั้นประเภทสุดท้าย แต่ไม่สำคัญเลย ค่อนข้างเป็นไปได้ว่านี่คือการโจมตีแบบที่เราพบเห็นในช่วงสัปดาห์ที่ผ่านมา เหตุการณ์ดังกล่าวมีลักษณะที่เข้าใจได้และมีผลตามมาที่ค่อนข้างร้ายแรง
ผู้ที่มองหาเวอร์ชัน TL;DR สามารถเลื่อนไปที่คำบรรยาย "Perfect Attack" ได้
พื้นหลังเครือข่าย
(เพื่อช่วยให้คุณเข้าใจกระบวนการที่เกี่ยวข้องกับเหตุการณ์นี้ได้ดีขึ้น)
หากคุณต้องการส่งแพ็กเก็ตและคุณมีหลายคำนำหน้าในตารางเส้นทางที่มีที่อยู่ IP ปลายทาง คุณจะต้องใช้เส้นทางสำหรับคำนำหน้าที่มีความยาวมากที่สุด หากมีหลายเส้นทางสำหรับคำนำหน้าเดียวกันในตารางเส้นทาง คุณจะเลือกเส้นทางที่ดีที่สุด (ตามกลไกการเลือกเส้นทางที่ดีที่สุด)
วิธีการกรองและการตรวจสอบที่มีอยู่พยายามวิเคราะห์เส้นทางและตัดสินใจโดยการวิเคราะห์แอตทริบิวต์ AS_PATH เราเตอร์อาจเปลี่ยนคุณลักษณะนี้เป็นค่าใดก็ได้ในระหว่างการโฆษณา เพียงเพิ่ม ASN ของเจ้าของที่จุดเริ่มต้นของ AS_PATH (เป็น ASN ต้นทาง) อาจเพียงพอที่จะข้ามกลไกการตรวจสอบต้นทางปัจจุบันได้ ยิ่งไปกว่านั้น หากมีเส้นทางจาก ASN ที่ถูกโจมตีมาถึงคุณ คุณจะแยกและใช้ AS_PATH ของเส้นทางนี้ในโฆษณาอื่นๆ ของคุณได้ การตรวจสอบความถูกต้องเฉพาะ AS_PATH สำหรับประกาศที่คุณสร้างขึ้นจะผ่านในที่สุด
ยังมีข้อจำกัดบางประการที่ควรกล่าวถึง ประการแรก ในกรณีที่คำนำหน้ากรองโดยผู้ให้บริการอัปสตรีม เส้นทางของคุณอาจยังคงถูกกรอง (แม้ว่าจะมี AS_PATH ที่ถูกต้อง) หากคำนำหน้าไม่ได้เป็นของกรวยไคลเอ็นต์ของคุณที่กำหนดค่าไว้ที่อัปสตรีม ประการที่สอง AS_PATH ที่ถูกต้องอาจใช้ไม่ได้หากเส้นทางที่สร้างขึ้นมีการโฆษณาในทิศทางที่ไม่ถูกต้อง และด้วยเหตุนี้ จึงละเมิดนโยบายการกำหนดเส้นทาง สุดท้ายนี้ เส้นทางใดๆ ที่มีคำนำหน้าซึ่งละเมิดความยาว ROA อาจถือว่าไม่ถูกต้อง
เหตุการณ์
เมื่อไม่กี่สัปดาห์ที่ผ่านมา เราได้รับการร้องเรียนจากผู้ใช้รายหนึ่งของเรา เราเห็นเส้นทางที่มี ASN ต้นทางและนำหน้า /25 ในขณะที่ผู้ใช้อ้างว่าเขาไม่ได้โฆษณาเส้นทางเหล่านั้น
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.0/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.128/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.0/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.128/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.0/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.128/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.0/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.128/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
ตัวอย่างประกาศต้นเดือนเมษายน 2019
NTT ในเส้นทางสำหรับคำนำหน้า /25 ทำให้น่าสงสัยเป็นพิเศษ LG NTT ไม่ทราบเส้นทางนี้ในขณะที่เกิดเหตุ ใช่แล้ว โอเปอเรเตอร์บางตัวสร้าง AS_PATH ทั้งหมดสำหรับคำนำหน้าเหล่านี้! การตรวจสอบเราเตอร์อื่นๆ จะพบ ASN หนึ่งรายการ: AS263444 หลังจากดูเส้นทางอื่นที่มีระบบอัตโนมัตินี้แล้ว เราพบสถานการณ์ต่อไปนี้:
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.36.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.38.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.23.143.0/25|265466 262761 263444 22356 6762 9498 9730 45528|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.23.143.128/25|265466 262761 263444 22356 6762 9498 9730 45528|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.24.0.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.24.128.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.26.0.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.26.128.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.64.96.0/20|265466 262761 263444 6762 3491 4760|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.64.112.0/20|265466 262761 263444 6762 3491 4760|IGP|xxx|0|0||NAG||
ลองเดาดูว่ามีอะไรผิดปกติที่นี่
ดูเหมือนว่ามีคนนำคำนำหน้ามาจากเส้นทาง แบ่งออกเป็นสองส่วน และโฆษณาเส้นทางด้วย AS_PATH เดียวกันสำหรับคำนำหน้าทั้งสองนั้น
TABLE_DUMP2|1554076800|B|xxx|263444|1.6.36.0/23|263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|263444|1.6.38.0/23|263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|61775|1.6.36.0/23|61775 262761 263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|61775|1.6.38.0/23|61775 262761 263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.36.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.38.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|28172|1.6.36.0/23|28172 52531 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|28172|1.6.38.0/23|28172 52531 263444 52320 9583|IGP|xxx|0|0||NAG||
ตัวอย่างเส้นทางสำหรับคู่คำนำหน้าแยกคู่ใดคู่หนึ่ง
มีคำถามมากมายเกิดขึ้นพร้อมกัน มีใครลองใช้การสกัดกั้นประเภทนี้ในทางปฏิบัติจริง ๆ หรือไม่? มีใครเคยใช้เส้นทางเหล่านี้บ้างไหม? คำนำหน้าใดได้รับผลกระทบ
นี่คือจุดเริ่มต้นของความล้มเหลวของเรา และยังเป็นความผิดหวังอีกครั้งกับสถานะปัจจุบันของอินเทอร์เน็ต
เส้นทางแห่งความล้มเหลว
สิ่งแรกก่อน เราจะทราบได้อย่างไรว่าเราเตอร์ตัวใดยอมรับเส้นทางที่ถูกดักดังกล่าว และการรับส่งข้อมูลของใครที่สามารถเปลี่ยนเส้นทางได้ในวันนี้ เราคิดว่าเราจะเริ่มต้นด้วยคำนำหน้า /25 เนื่องจาก "ไม่สามารถมีการเผยแพร่ทั่วโลกได้" อย่างที่คุณเดาได้ เราคิดผิดมาก ตัวชี้วัดนี้ดูมีเสียงรบกวนมากเกินไป และเส้นทางที่มีคำนำหน้าดังกล่าวสามารถปรากฏได้แม้กระทั่งจากผู้ให้บริการระดับ 1 ก็ตาม ตัวอย่างเช่น NTT มีคำนำหน้าประมาณ 50 คำ ซึ่ง NTT จะแจกจ่ายให้กับลูกค้าของตนเอง ในทางกลับกัน หน่วยเมตริกนี้ไม่ดี เนื่องจากสามารถกรองคำนำหน้าดังกล่าวออกได้หากผู้ดำเนินการใช้ ในทุกทิศทุกทาง ดังนั้นวิธีนี้จึงไม่เหมาะสำหรับการค้นหาผู้ให้บริการทุกรายที่มีการเปลี่ยนเส้นทางการรับส่งข้อมูลอันเป็นผลมาจากเหตุการณ์ดังกล่าว
อีกหนึ่งความคิดที่ดีที่เราคิดคือการดู . โดยเฉพาะอย่างยิ่งสำหรับเส้นทางที่ละเมิดกฎ maxLength ของ ROA ที่เกี่ยวข้อง วิธีนี้ทำให้เราสามารถค้นหาจำนวน ASN ต้นทางที่แตกต่างกันซึ่งมีสถานะไม่ถูกต้องซึ่ง AS ที่กำหนดมองเห็นได้ อย่างไรก็ตามมีปัญหา "เล็กน้อย" ค่าเฉลี่ย (ค่ามัธยฐานและโหมด) ของตัวเลขนี้ (จำนวน ASN ต้นทางที่แตกต่างกัน) อยู่ที่ประมาณ 150 และแม้ว่าเราจะกรองคำนำหน้าเล็กๆ ออก แต่ก็ยังสูงกว่า 70 สถานการณ์นี้มีคำอธิบายง่ายๆ มาก: มีเพียง มีผู้ให้บริการเพียงไม่กี่รายที่ใช้ตัวกรอง ROA ด้วยนโยบาย "รีเซ็ตเส้นทางที่ไม่ถูกต้อง" ที่จุดเริ่มต้น ดังนั้นเมื่อใดก็ตามที่เส้นทางที่มีการละเมิด ROA ปรากฏในโลกแห่งความเป็นจริง เส้นทางนั้นสามารถเผยแพร่ในทุกทิศทาง
สองวิธีสุดท้ายช่วยให้เราสามารถค้นหาผู้ปฏิบัติงานที่เห็นเหตุการณ์ของเรา (เนื่องจากมีขนาดค่อนข้างใหญ่) แต่โดยทั่วไปแล้วจะไม่สามารถใช้ได้ โอเค แต่เราสามารถหาผู้บุกรุกเจอได้ไหม? คุณสมบัติทั่วไปของการจัดการ AS_PATH นี้คืออะไร? มีข้อสันนิษฐานพื้นฐานบางประการ:
- คำนำหน้าไม่เคยเห็นที่ไหนมาก่อน
- ASN ต้นทาง (คำเตือน: ASN แรกใน AS_PATH) ถูกต้อง
- ASN สุดท้ายใน AS_PATH คือ ASN ของผู้โจมตี (ในกรณีที่เพื่อนบ้านตรวจสอบ ASN ของเพื่อนบ้านในเส้นทางขาเข้าทั้งหมด)
- การโจมตีมาจากผู้ให้บริการรายเดียว
หากสมมติฐานทั้งหมดถูกต้อง เส้นทางที่ไม่ถูกต้องทั้งหมดจะแสดง ASN ของผู้โจมตี (ยกเว้น ASN ต้นทาง) และด้วยเหตุนี้ นี่จึงเป็นจุดที่ "วิกฤต" ในบรรดาจี้ที่แท้จริงคือ AS263444 แม้ว่าจะมีคนอื่นก็ตาม แม้ว่าเราจะละทิ้งเส้นทางเหตุการณ์ไปจากการพิจารณาก็ตาม ทำไม จุดวิกฤติอาจยังคงวิกฤตอยู่แม้ในเส้นทางที่ถูกต้อง อาจเป็นผลมาจากการเชื่อมต่อที่ไม่ดีในภูมิภาคหรือข้อจำกัดในการมองเห็นของเราเอง
ด้วยเหตุนี้ จึงมีวิธีการตรวจจับผู้โจมตีได้ก็ต่อเมื่อตรงตามเงื่อนไขข้างต้นทั้งหมดเท่านั้น และเฉพาะเมื่อมีการสกัดกั้นมีขนาดใหญ่พอที่จะผ่านเกณฑ์การตรวจสอบเท่านั้น หากไม่เป็นไปตามปัจจัยบางประการเหล่านี้ เราจะสามารถระบุคำนำหน้าที่ได้รับความเดือดร้อนจากการสกัดกั้นดังกล่าวได้หรือไม่ สำหรับผู้ให้บริการบางราย - ใช่
เมื่อผู้โจมตีสร้างเส้นทางที่เฉพาะเจาะจงมากขึ้น เจ้าของที่แท้จริงจะไม่โฆษณาคำนำหน้าดังกล่าว หากคุณมีรายการคำนำหน้าแบบไดนามิกทั้งหมด คุณจะสามารถเปรียบเทียบและค้นหาเส้นทางที่เฉพาะเจาะจงมากขึ้นที่บิดเบี้ยวได้ เรารวบรวมรายการคำนำหน้านี้โดยใช้เซสชัน BGP ของเรา เนื่องจากเราไม่เพียงแต่ได้รับรายชื่อเส้นทางทั้งหมดที่ผู้ให้บริการมองเห็นได้ในขณะนี้ แต่ยังรวมถึงรายการคำนำหน้าทั้งหมดที่ต้องการโฆษณาให้โลกได้รับรู้อีกด้วย น่าเสียดายที่ขณะนี้มีผู้ใช้ Radar หลายสิบคนที่ไม่ได้กรอกข้อมูลส่วนสุดท้ายให้ถูกต้อง เราจะแจ้งให้พวกเขาทราบในไม่ช้าและพยายามแก้ไขปัญหานี้ คนอื่นๆ สามารถเข้าร่วมระบบการตรวจสอบของเราได้ทันที
หากเรากลับสู่เหตุการณ์เดิม ทั้งผู้โจมตีและพื้นที่กระจายสินค้าจะถูกตรวจพบโดยการค้นหาจุดวิกฤต น่าแปลกที่ AS263444 ไม่ได้ส่งเส้นทางปลอมไปยังไคลเอนต์ทั้งหมด แม้ว่าจะมีช่วงเวลาที่แปลกประหลาดก็ตาม
BGP4MP|1554905421|A|xxx|263444|178.248.236.0/24|263444 6762 197068|IGP|xxx|0|0|13106:12832 22356:6453 65444:20000|NAG||
BGP4MP|1554905421|A|xxx|263444|178.248.237.0/24|263444 6762 197068|IGP|xxx|0|0|13106:12832 22356:6453 65444:20000|NAG||
ตัวอย่างล่าสุดของความพยายามที่จะสกัดกั้นพื้นที่ที่อยู่ของเรา
เมื่อมีการสร้างคำที่เฉพาะเจาะจงมากขึ้นสำหรับคำนำหน้าของเรา AS_PATH ที่สร้างขึ้นเป็นพิเศษจะถูกนำมาใช้ อย่างไรก็ตาม AS_PATH นี้ไม่สามารถนำมาจากเส้นทางใดๆ ก่อนหน้านี้ของเราได้ เราไม่มีการสื่อสารกับ AS6762 ด้วยซ้ำ เมื่อดูเส้นทางอื่นๆ ในเหตุการณ์ บางเส้นทางมี AS_PATH จริงที่เคยใช้แล้ว ในขณะที่บางเส้นทางไม่มีแม้จะดูเหมือนของจริงก็ตาม การเปลี่ยน AS_PATH เพิ่มเติมนั้นไม่สมเหตุสมผลในทางปฏิบัติ เนื่องจากการรับส่งข้อมูลจะถูกเปลี่ยนเส้นทางไปยังผู้โจมตี แต่เส้นทางที่มี AS_PATH "ไม่ดี" สามารถกรองได้โดย ASPA หรือกลไกการตรวจสอบอื่น ๆ ที่นี่เราคิดถึงแรงจูงใจของนักจี้ ขณะนี้เราไม่มีข้อมูลเพียงพอที่จะยืนยันว่าเหตุการณ์นี้เป็นการโจมตีที่วางแผนไว้ อย่างไรก็ตามก็เป็นไปได้ ลองจินตนาการถึงสถานการณ์ที่แม้จะเป็นเพียงสมมุติฐาน แต่ก็อาจเป็นจริงได้
การโจมตีที่สมบูรณ์แบบ
เรามีอะไร? สมมติว่าคุณเป็นผู้ให้บริการขนส่งที่กระจายเสียงเส้นทางสำหรับลูกค้าของคุณ หากลูกค้าของคุณมีสถานะหลายแห่ง (หลายบ้าน) คุณจะได้รับการเข้าชมเพียงบางส่วนเท่านั้น แต่ยิ่งมีการเข้าชมมากเท่าไหร่ รายได้ของคุณก็จะมากขึ้นเท่านั้น ดังนั้น หากคุณเริ่มโฆษณาคำนำหน้าซับเน็ตของเส้นทางเดียวกันเหล่านี้ด้วย AS_PATH เดียวกัน คุณจะได้รับปริมาณการใช้งานที่เหลือ ส่งผลให้มีเงินเหลือ
ROA จะช่วยที่นี่ได้ไหม? อาจจะใช่ หากคุณตัดสินใจหยุดใช้มันโดยสิ้นเชิง . นอกจากนี้ ไม่เป็นที่พึงปรารถนาอย่างยิ่งที่จะมีบันทึก ROA ที่มีคำนำหน้าที่ตัดกัน สำหรับผู้ให้บริการบางราย ข้อจำกัดดังกล่าวไม่สามารถยอมรับได้
เมื่อพิจารณาถึงกลไกการรักษาความปลอดภัยการกำหนดเส้นทางอื่นๆ ASPA จะไม่ช่วยในกรณีนี้เช่นกัน (เนื่องจากใช้ AS_PATH จากเส้นทางที่ถูกต้อง) BGPSec ยังคงไม่ใช่ตัวเลือกที่ดีที่สุด เนื่องจากมีอัตราการนำไปใช้ต่ำและยังมีความเป็นไปได้ที่จะถูกดาวน์เกรดการโจมตี
ดังนั้นเราจึงได้ประโยชน์ที่ชัดเจนสำหรับผู้โจมตีและขาดความปลอดภัย การผสมผสานที่ยอดเยี่ยม!
ฉันต้องทำอะไร
ขั้นตอนที่ชัดเจนและรุนแรงที่สุดคือการตรวจสอบนโยบายการกำหนดเส้นทางปัจจุบันของคุณ แบ่งพื้นที่ที่อยู่ของคุณออกเป็นส่วนเล็กๆ (ไม่มีการทับซ้อนกัน) ที่คุณต้องการโฆษณา ลงนาม ROA สำหรับพวกเขาเท่านั้น โดยไม่ต้องใช้พารามิเตอร์ maxLength ในกรณีนี้ มุมมองปัจจุบันของคุณสามารถช่วยคุณจากการโจมตีดังกล่าวได้ อย่างไรก็ตาม สำหรับผู้ให้บริการบางราย วิธีการนี้ไม่สมเหตุสมผล เนื่องจากมีการใช้เส้นทางเฉพาะเจาะจงมากกว่าเท่านั้น ปัญหาทั้งหมดเกี่ยวกับสถานะปัจจุบันของ ROA และออบเจ็กต์เส้นทางจะมีการอธิบายไว้ในเอกสารในอนาคตของเรา
นอกจากนี้คุณยังสามารถลองติดตามการสกัดกั้นดังกล่าวได้ ในการดำเนินการนี้ เราต้องการข้อมูลที่เชื่อถือได้เกี่ยวกับคำนำหน้าของคุณ ดังนั้น หากคุณสร้างเซสชัน BGP กับผู้รวบรวมของเรา และแจ้งข้อมูลเกี่ยวกับการเปิดเผยทางอินเทอร์เน็ตของคุณ เราจะสามารถค้นหาขอบเขตของเหตุการณ์อื่นๆ ได้ สำหรับผู้ที่ยังไม่ได้เชื่อมต่อกับระบบการตรวจสอบของเรา รายการเส้นทางที่มีเฉพาะคำนำหน้าของคุณก็เพียงพอแล้ว หากคุณมีเซสชั่นกับเรา โปรดตรวจสอบว่าได้ส่งเส้นทางทั้งหมดของคุณแล้ว น่าเสียดายที่สิ่งนี้ควรค่าแก่การจดจำ เนื่องจากโอเปอเรเตอร์บางตัวลืมคำนำหน้าหนึ่งหรือสองคำ จึงรบกวนวิธีการค้นหาของเรา หากทำอย่างถูกต้อง เราจะมีข้อมูลที่เชื่อถือได้เกี่ยวกับคำนำหน้าของคุณ ซึ่งในอนาคตจะช่วยเราระบุและตรวจจับการสกัดกั้นการรับส่งข้อมูลประเภทนี้ (และอื่นๆ) สำหรับพื้นที่ที่อยู่ของคุณโดยอัตโนมัติ
หากคุณตระหนักถึงการสกัดกั้นการรับส่งข้อมูลของคุณแบบเรียลไทม์ คุณสามารถลองตอบโต้ด้วยตัวเองได้ แนวทางแรกคือการโฆษณาเส้นทางด้วยคำนำหน้าที่เฉพาะเจาะจงมากขึ้นด้วยตนเอง ในกรณีที่มีการโจมตีครั้งใหม่กับคำนำหน้าเหล่านี้ ให้ทำซ้ำ
แนวทางที่สองคือการลงโทษผู้โจมตีและผู้ที่เป็นจุดวิกฤติ (สำหรับเส้นทางที่ดี) โดยตัดการเข้าถึงเส้นทางของคุณไปยังผู้โจมตี ซึ่งสามารถทำได้โดยการเพิ่ม ASN ของผู้โจมตีไปยัง AS_PATH ของเส้นทางเก่าของคุณ และบังคับให้พวกเขาหลีกเลี่ยง AS นั้นโดยใช้กลไกการตรวจจับลูปในตัวใน BGP .
ที่มา: will.com