ไม่มีความลับใดที่การควบคุมการบล็อกในรายการข้อมูลที่ต้องห้ามในรัสเซียได้รับการตรวจสอบโดยระบบอัตโนมัติ "ผู้ตรวจสอบ" วิธีการทำงานก็เขียนได้ดีที่นี่ ,ภาพจากที่เดียวกัน:
ติดตั้งกับผู้ให้บริการโดยตรง :
โมดูล "Agent Inspector" เป็นองค์ประกอบโครงสร้างของระบบอัตโนมัติ "Inspector" (AS "Inspector") ระบบนี้ได้รับการออกแบบมาเพื่อตรวจสอบการปฏิบัติตามโดยผู้ให้บริการโทรคมนาคมที่มีข้อกำหนดการ จำกัด การเข้าถึงภายในกรอบของบทบัญญัติที่กำหนดโดยมาตรา 15.1-15.4 ของกฎหมายของรัฐบาลกลางวันที่ 27 กรกฎาคม 2006 ฉบับที่ 149-FZ“ เกี่ยวกับข้อมูลเทคโนโลยีสารสนเทศและการปกป้องข้อมูล ”
วัตถุประสงค์หลักของการสร้าง AS "Revizor" คือเพื่อให้แน่ใจว่าการตรวจสอบการปฏิบัติตามข้อกำหนดของผู้ให้บริการโทรคมนาคมตามข้อกำหนดที่กำหนดโดยมาตรา 15.1-15.4 ของกฎหมายของรัฐบาลกลางวันที่ 27 กรกฎาคม 2006 ฉบับที่ 149-FZ "เกี่ยวกับข้อมูลเทคโนโลยีสารสนเทศและการคุ้มครองข้อมูล " ในด้านการระบุข้อเท็จจริงในการเข้าถึงข้อมูลต้องห้ามและการได้รับเอกสารสนับสนุน (ข้อมูล) เกี่ยวกับการละเมิดเพื่อจำกัดการเข้าถึงข้อมูลต้องห้าม
เมื่อคำนึงถึงความจริงที่ว่าหากไม่ใช่ทั้งหมด ผู้ให้บริการหลายรายได้ติดตั้งอุปกรณ์นี้ ก็ควรมีเครือข่ายโพรบบีคอนขนาดใหญ่เช่น และอีกมากมายแต่มีการเข้าถึงแบบปิด อย่างไรก็ตาม บีคอนก็คือบีคอนที่ส่งสัญญาณไปทุกทิศทุกทาง แต่ถ้าเราจับได้ แล้วดูว่าจับอะไรได้กี่ตัวล่ะ?
ก่อนที่เราจะนับ เรามาดูกันว่าเหตุใดจึงเป็นไปได้
ทฤษฎีเล็กน้อย
เจ้าหน้าที่ตรวจสอบความพร้อมใช้งานของทรัพยากร รวมถึงผ่านคำขอ HTTP(S) เช่นนี้:
TCP, 14678 > 80, "[SYN] Seq=0"
TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
TCP, 14678 > 80, "[ACK] Seq=1 Ack=1"
HTTP, "GET /somepage HTTP/1.1"
TCP, 80 > 14678, "[ACK] Seq=1 Ack=71"
HTTP, "HTTP/1.1 302 Found"
TCP, 14678 > 80, "[FIN, ACK] Seq=71 Ack=479"
TCP, 80 > 14678, "[FIN, ACK] Seq=479 Ack=72"
TCP, 14678 > 80, "[ACK] Seq=72 Ack=480"
นอกเหนือจากเพย์โหลดแล้ว คำขอยังประกอบด้วยขั้นตอนการสร้างการเชื่อมต่อ: การแลกเปลี่ยน SYN и SYN-ACKและขั้นตอนการเชื่อมต่อให้เสร็จสิ้น: FIN-ACK.
การลงทะเบียนข้อมูลที่ต้องห้ามมีการบล็อกหลายประเภท แน่นอนว่าหากทรัพยากรถูกบล็อกโดยที่อยู่ IP หรือชื่อโดเมน เราจะไม่เห็นคำขอใดๆ การบล็อกเหล่านี้เป็นประเภทที่ทำลายล้างมากที่สุด ซึ่งนำไปสู่การไม่สามารถเข้าถึงทรัพยากรทั้งหมดในที่อยู่ IP เดียวหรือข้อมูลทั้งหมดในโดเมน นอกจากนี้ยังมีการบล็อกประเภท "ตาม URL" ในกรณีนี้ ระบบกรองจะต้องแยกวิเคราะห์ส่วนหัวคำขอ HTTP เพื่อกำหนดอย่างชัดเจนว่าจะบล็อกอะไร และก่อนหน้านั้น ดังที่เห็นข้างต้น ควรมีขั้นตอนการสร้างการเชื่อมต่อที่คุณสามารถลองติดตามได้ เนื่องจากตัวกรองส่วนใหญ่จะพลาดไป
ในการดำเนินการนี้ คุณต้องเลือกโดเมนฟรีที่เหมาะสมซึ่งมีประเภทการบล็อก “URL” และ HTTP เพื่ออำนวยความสะดวกในการทำงานของระบบกรอง ซึ่งควรจะละทิ้งไปนาน เพื่อลดการเข้าของการรับส่งข้อมูลภายนอกยกเว้นจากตัวแทน งานนี้กลายเป็นว่าไม่ยากเลยมีโดเมนฟรีจำนวนมากในการลงทะเบียนข้อมูลที่ต้องห้ามและสำหรับทุกรสนิยม ดังนั้นจึงมีการซื้อโดเมนและเชื่อมโยงกับที่อยู่ IP บน VPS ที่ทำงานอยู่ tcpdump และการนับก็เริ่มขึ้น
การตรวจสอบของ “ผู้ตรวจสอบบัญชี”
ฉันคาดว่าจะเห็นคำขอเพิ่มขึ้นเป็นระยะๆ ซึ่งในความคิดของฉันคงบ่งบอกถึงการดำเนินการที่ได้รับการควบคุม พูดไม่ได้ว่าไม่เห็นเลย แต่ไม่มีภาพชัดเจนแน่นอน:
ซึ่งไม่น่าแปลกใจเลย แม้แต่ในโดเมนที่ไม่มีใครต้องการและบน IP ที่ไม่เคยใช้ ก็ยังมีข้อมูลที่ไม่พึงประสงค์มากมาย เช่น อินเทอร์เน็ตสมัยใหม่ แต่โชคดีที่ฉันต้องการเพียงคำขอสำหรับ URL ที่เฉพาะเจาะจงเท่านั้น ดังนั้นเครื่องสแกนและแคร็กรหัสผ่านทั้งหมดจึงถูกค้นพบอย่างรวดเร็ว นอกจากนี้ มันค่อนข้างง่ายที่จะเข้าใจว่าน้ำท่วมเกิดขึ้นจากคำขอที่คล้ายกันจำนวนมาก ต่อไป ฉันรวบรวมความถี่ของการเกิดที่อยู่ IP และค้นหาด้านบนทั้งหมดด้วยตนเอง โดยแยกผู้ที่พลาดไปในขั้นตอนก่อนหน้า นอกจากนี้ ฉันตัดแหล่งที่มาทั้งหมดที่ส่งมาในแพ็คเกจเดียวออก ซึ่งมีจำนวนไม่มากอีกต่อไป และนี่คือสิ่งที่เกิดขึ้น:
การพูดนอกเรื่องโคลงสั้น ๆ มากกว่าหนึ่งวันต่อมา ผู้ให้บริการโฮสติ้งของฉันได้ส่งจดหมายพร้อมเนื้อหาที่ค่อนข้างกระชับ โดยบอกว่าสิ่งอำนวยความสะดวกของคุณมีทรัพยากรจากรายการต้องห้ามของ RKN ดังนั้นจึงถูกบล็อก ตอนแรกฉันคิดว่าบัญชีของฉันถูกบล็อก ซึ่งไม่เป็นเช่นนั้น จากนั้นฉันก็คิดว่าพวกเขาแค่เตือนฉันเกี่ยวกับสิ่งที่ฉันรู้อยู่แล้ว แต่ปรากฏว่าโฮสต์เปิดตัวกรองต่อหน้าโดเมนของฉัน และผลก็คือฉันถูกกรองซ้ำซ้อน: จากผู้ให้บริการและจากโฮสต์ ตัวกรองผ่านการสิ้นสุดคำขอเท่านั้น: FIN-ACK и RST ตัด HTTP ทั้งหมดที่ URL ที่ต้องห้าม ดังที่คุณเห็นจากกราฟด้านบน หลังจากวันแรกฉันเริ่มได้รับข้อมูลน้อยลง แต่ก็ยังได้รับ ซึ่งเพียงพอสำหรับงานนับแหล่งที่มาของคำขอ
ไปถึงจุด. ในความคิดของฉัน การระเบิดสองครั้งสามารถมองเห็นได้ชัดเจนทุกวัน ครั้งแรกเล็กกว่าหลังเที่ยงคืนตามเวลามอสโก ครั้งที่สองใกล้เวลา 6 น. โดยมีหางจนถึง 12 น. จุดสูงสุดไม่ได้เกิดขึ้นในเวลาเดียวกันทุกประการ ในตอนแรก ฉันต้องการเลือกที่อยู่ IP ที่อยู่ในช่วงเวลาเหล่านี้และในแต่ละช่วงเวลาเท่านั้น โดยยึดตามสมมติฐานที่ว่าการตรวจสอบโดยตัวแทนจะดำเนินการเป็นระยะๆ แต่จากการตรวจสอบอย่างละเอียด ฉันค้นพบอย่างรวดเร็วว่าช่วงเวลานั้นอยู่ในช่วงอื่น ๆ พร้อมด้วยความถี่อื่น ๆ มากถึงหนึ่งคำขอทุก ๆ ชั่วโมง จากนั้นฉันก็คิดถึงเขตเวลาและบางทีอาจมีบางอย่างเกี่ยวข้องกับเขตเวลา จากนั้นฉันก็คิดว่าโดยทั่วไปแล้วระบบอาจไม่ซิงโครไนซ์ทั่วโลก นอกจากนี้ NAT อาจจะมีบทบาทและตัวแทนเดียวกันสามารถส่งคำขอจาก IP สาธารณะที่แตกต่างกันได้
เนื่องจากเป้าหมายเริ่มต้นของฉันไม่แน่ชัด ฉันจึงนับที่อยู่ทั้งหมดที่ฉันเจอในหนึ่งสัปดาห์และได้รับ - 2791. จำนวนเซสชัน TCP ที่สร้างจากที่อยู่เดียวคือโดยเฉลี่ย 4 โดยมีค่ามัธยฐาน 2 เซสชันสูงสุดต่อที่อยู่: 464, 231, 149, 83, 77 สูงสุดจาก 95% ของกลุ่มตัวอย่างคือ 8 เซสชันต่อที่อยู่ ค่ามัธยฐานไม่สูงมาก ขอเตือนว่ากราฟแสดงช่วงเวลารายวันที่ชัดเจน ดังนั้นจึงอาจคาดหวังอะไรประมาณ 4 ถึง 8 ใน 7 วัน หากเราทิ้งเซสชันทั้งหมดที่เกิดขึ้นครั้งเดียว เราจะได้ค่ามัธยฐานเท่ากับ 5 แต่ฉันไม่สามารถแยกเซสชันเหล่านี้ออกตามเกณฑ์ที่ชัดเจนได้ ในทางตรงกันข้าม การตรวจสอบแบบสุ่มแสดงให้เห็นว่าเกี่ยวข้องกับคำขอทรัพยากรต้องห้าม
ที่อยู่คือที่อยู่ แต่บนอินเทอร์เน็ต ระบบอัตโนมัติ - AS ซึ่งกลายเป็นสิ่งที่สำคัญกว่า 1510โดยเฉลี่ยแล้วจะมี 2 ที่อยู่ต่อ AS โดยค่ามัธยฐานอยู่ที่ 1 ที่อยู่สูงสุดต่อ AS ได้แก่ 288, 77, 66, 39, 27 ค่าสูงสุดในกลุ่มตัวอย่าง 95% คือ 4 ที่อยู่ต่อ AS ในที่นี้ ค่ามัธยฐานเป็นไปตามที่คาดไว้ คือมี Agent หนึ่งรายต่อผู้ให้บริการ และค่าสูงสุดก็เป็นไปตามที่คาดไว้เช่นกัน เพราะรวมถึงผู้เล่นรายใหญ่ ในเครือข่ายขนาดใหญ่ Agent ควรตั้งอยู่ในแต่ละภูมิภาคที่ผู้ให้บริการนั้น ๆ มีอยู่ และเราไม่ควรลืมเรื่อง NAT หากเราดูที่ประเทศ ค่าสูงสุดคือ 1409 – รัสเซีย, 42 – ยูเครน, 23 – เช็ก, 36 จากภูมิภาคอื่น ๆ RIPE NCCคำขอจากนอกประเทศรัสเซียได้รับความสนใจเป็นพิเศษ ซึ่งอาจเกิดจากข้อผิดพลาดด้านตำแหน่งทางภูมิศาสตร์หรือข้อผิดพลาดในการป้อนข้อมูลโดยผู้จดทะเบียน หรืออีกทางหนึ่ง บริษัทรัสเซียอาจไม่ได้มีรากฐานในรัสเซีย หรืออาจมีสำนักงานตัวแทนในต่างประเทศเพราะสะดวกกว่า ซึ่งเป็นเรื่องปกติเมื่อต้องติดต่อกับองค์กรต่างชาติ RIPE NCCส่วนหนึ่งอาจซ้ำซ้อนอย่างไม่ต้องสงสัย แต่เป็นการยากที่จะแยกแยะได้อย่างน่าเชื่อถือ เนื่องจากทรัพยากรถูกล็อก และตั้งแต่วันที่สองเป็นต้นไปก็ถูกล็อกซ้ำซ้อนอีกชั้นหนึ่ง และเซสชันส่วนใหญ่ประกอบด้วยการแลกเปลี่ยนแพ็กเก็ตบริการเพียงไม่กี่แพ็กเก็ตเท่านั้น เรามาตกลงกันว่าส่วนนี้เป็นส่วนเล็กน้อย
ตัวเลขเหล่านี้สามารถเปรียบเทียบได้กับจำนวนผู้ให้บริการในรัสเซียแล้ว มีใบอนุญาต 6387 ใบสำหรับ "บริการสื่อสารข้อมูล ยกเว้นเสียง" แต่ตัวเลขนี้เป็นการประมาณการที่สูงเกินจริงอย่างมาก ใบอนุญาตเหล่านี้ไม่ได้ใช้กับผู้ให้บริการอินเทอร์เน็ตที่ต้องการการติดตั้ง Agent โดยเฉพาะทั้งหมด ในโซนนี้ RIPE NCC ในรัสเซียมีจำนวน AS ที่จดทะเบียนในลักษณะเดียวกันประมาณ 6230 แห่ง ซึ่งไม่ใช่ทั้งหมดที่เป็นผู้ให้บริการ และได้รับบริษัท 3940 แห่งในปี 2017 และนี่เป็นการประมาณการจากด้านบน ไม่ว่าในกรณีใด เรามี AS ที่ส่องสว่างน้อยกว่าสองเท่าครึ่ง แต่ที่นี่ควรเข้าใจว่า AS ไม่เท่ากับผู้ให้บริการอย่างเคร่งครัด ผู้ให้บริการบางรายไม่มี AS ของตนเอง บางรายมีมากกว่าหนึ่งราย หากเราถือว่าทุกคนยังมีตัวแทนอยู่ ก็จะมีบางคนกรองอย่างเข้มงวดมากกว่าคนอื่นๆ เพื่อให้คำขอของพวกเขาแยกไม่ออกจากขยะหากพวกเขาไปถึงพวกเขาเลย แต่สำหรับการประเมินคร่าวๆ ก็ถือว่าค่อนข้างทนได้ แม้ว่าบางสิ่งจะสูญหายไปเนื่องจากการกำกับดูแลของฉันก็ตาม
เกี่ยวกับ ดีพีไอ
แม้ว่าผู้ให้บริการโฮสติ้งของฉันจะเปิดตัวกรองตั้งแต่วันที่สองก็ตาม แต่จากข้อมูลในวันแรก เราสามารถสรุปได้ว่าการบล็อกทำงานได้สำเร็จ มีเพียง 4 แหล่งที่มาเท่านั้นที่สามารถผ่านและเซสชัน HTTP และ TCP เสร็จสมบูรณ์ได้ (ดังตัวอย่างด้านบน) ส่งได้อีก460ครับ GETแต่เซสชันจะสิ้นสุดลงทันทีโดย RST. ให้ความสนใจกับ TTL:
TTL 50, TCP, 14678 > 80, "[SYN] Seq=0"
TTL 64, TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
TTL 50, TCP, 14678 > 80, "[ACK] Seq=1 Ack=1"
HTTP, "GET /filteredpage HTTP/1.1"
TTL 64, TCP, 80 > 14678, "[ACK] Seq=1 Ack=294"
#Вот это прислал фильтр
TTL 53, TCP, 14678 > 80, "[RST] Seq=3458729893"
TTL 53, TCP, 14678 > 80, "[RST] Seq=3458729893"
HTTP, "HTTP/1.1 302 Found"
#А это попытка исходного узла получить потерю
TTL 50, TCP ACKed unseen segment, 14678 > 80, "[ACK] Seq=294 Ack=145"
TTL 50, TCP, 14678 > 80, "[FIN, ACK] Seq=294 Ack=145"
TTL 64, TCP, 80 > 14678, "[FIN, ACK] Seq=171 Ack=295"
TTL 50, TCP Dup ACK 14678 > 80 "[ACK] Seq=295 Ack=145"
#Исходный узел понимает что сессия разрушена
TTL 50, TCP, 14678 > 80, "[RST] Seq=294"
TTL 50, TCP, 14678 > 80, "[RST] Seq=295"
รูปแบบต่างๆ อาจแตกต่างกัน: น้อยกว่า RST หรือส่งซ้ำมากขึ้น - ขึ้นอยู่กับว่าตัวกรองส่งอะไรไปยังโหนดต้นทางด้วย ไม่ว่าในกรณีใด นี่เป็นเทมเพลตที่น่าเชื่อถือที่สุด ซึ่งชัดเจนว่าเป็นทรัพยากรต้องห้ามที่ถูกร้องขอ แถมยังมีคำตอบปรากฏอยู่ในเซสชั่นเสมอด้วย TTL มากกว่าแพ็คเกจก่อนหน้าและแพ็คเกจถัดไป
คุณไม่สามารถมองเห็นได้จากส่วนที่เหลือ GET:
TTL 50, TCP, 14678 > 80, "[SYN] Seq=0"
TTL 64, TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
#Вот это прислал фильтр
TTL 53, TCP, 14678 > 80, "[RST] Seq=1"
หรือดังนั้น:
TTL 50, TCP, 14678 > 80, "[SYN] Seq=0"
TTL 64, TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
TTL 50, TCP, 14678 > 80, "[ACK] Seq=1 Ack=1"
#Вот это прислал фильтр
TTL 53, TCP, 14678 > 80, "[RST, PSH] Seq=1"
TTL 50, TCP ACKed unseen segment, 14678 > 80, "[FIN, ACK] Seq=89 Ack=172"
TTL 50, TCP ACKed unseen segment, 14678 > 80, "[FIN, ACK] Seq=89 Ack=172"
#Опять фильтр, много раз
TTL 53, TCP, 14678 > 80, "[RST, PSH] Seq=1"
...
ความแตกต่างที่เห็นได้ชัดเจน TTL หากมีบางอย่างมาจากตัวกรอง แต่บ่อยครั้งไม่มีอะไรมาถึงเลย:
TCP, 14678 > 80, "[SYN] Seq=0"
TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
TCP Retransmission, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
...
หรือดังนั้น:
TCP, 14678 > 80, "[SYN] Seq=0"
TCP, 80 > 14678, "[SYN, ACK] Seq=0 Ack=1"
TCP, 14678 > 80, "[ACK] Seq=1 Ack=1"
#Прошло несколько секунд без трафика
TCP, 80 > 14678, "[FIN, ACK] Seq=1 Ack=1"
TCP Retransmission, 80 > 14678, "[FIN, ACK] Seq=1 Ack=1"
...
และทั้งหมดนี้เกิดขึ้นซ้ำแล้วซ้ำอีกซ้ำแล้วซ้ำอีกดังที่เห็นบนกราฟมากกว่าหนึ่งครั้งทุกวัน
เกี่ยวกับ IPv6
ข่าวดีก็คือว่ามันมีอยู่จริง ฉันสามารถพูดได้อย่างน่าเชื่อถือว่าคำขอเป็นระยะไปยังทรัพยากรต้องห้ามนั้นเกิดขึ้นจากที่อยู่ IPv5 ที่แตกต่างกัน 6 รายการ ซึ่งเป็นพฤติกรรมของตัวแทนที่ฉันคาดหวังไว้อย่างแน่นอน นอกจากนี้ หนึ่งในที่อยู่ IPv6 ไม่ตกอยู่ภายใต้การกรอง และฉันเห็นเซสชันทั้งหมด จากอีกสองเซสชัน ฉันเห็นเซสชันที่ยังทำไม่เสร็จเพียงเซสชันเดียว ซึ่งเซสชันหนึ่งถูกขัดจังหวะด้วย RST จากตัวกรองเป็นครั้งที่สอง จำนวนเงินทั้งหมด 7.
เนื่องจากมีที่อยู่ไม่มากนัก ฉันจึงศึกษาทั้งหมดโดยละเอียดและปรากฏว่ามีผู้ให้บริการเพียง 3 รายที่นั่น พวกเขาสามารถได้รับการปรบมือต้อนรับ! อีกที่อยู่หนึ่งคือคลาวด์โฮสติ้งในรัสเซีย (ไม่กรอง) อีกแห่งคือศูนย์วิจัยในเยอรมนี (มีตัวกรองอยู่ที่ไหน?) แต่เหตุใดพวกเขาจึงตรวจสอบความพร้อมของทรัพยากรต้องห้ามตามกำหนดเวลาจึงเป็นคำถามที่ดี อีกสองคนที่เหลือส่งคำขอหนึ่งครั้งและตั้งอยู่นอกรัสเซีย และหนึ่งในนั้นถูกกรอง (ระหว่างทางใช่ไหม)
การบล็อกและเอเจนต์เป็นอุปสรรคสำคัญต่อ IPv6 ซึ่งการใช้งานไม่ได้ดำเนินไปอย่างรวดเร็วนัก มันเป็นเรื่องน่าเศร้า ผู้ที่แก้ไขปัญหานี้สามารถภาคภูมิใจในตนเองได้อย่างเต็มที่
ในข้อสรุป
ฉันไม่ได้มุ่งมั่นเพื่อความถูกต้อง 100% โปรดยกโทษให้ฉันด้วย ฉันหวังว่าจะมีคนต้องการทำซ้ำงานนี้ให้มีความแม่นยำมากขึ้น เป็นสิ่งสำคัญสำหรับฉันที่จะเข้าใจว่าแนวทางนี้จะได้ผลในหลักการหรือไม่ คำตอบคือใช่ ฉันคิดว่าตัวเลขที่ได้รับเป็นการประมาณครั้งแรกค่อนข้างเชื่อถือได้
มีอะไรอีกที่สามารถทำได้และสิ่งที่ฉันขี้เกียจเกินกว่าจะทำคือการนับคำขอ DNS ไม่มีการกรอง แต่ก็ไม่ได้ให้ความแม่นยำมากนัก เนื่องจากใช้ได้เฉพาะกับโดเมนเท่านั้น ไม่ใช่กับ URL ทั้งหมด ควรมองเห็นความถี่ได้ หากคุณรวมเข้ากับสิ่งที่มองเห็นได้โดยตรงในแบบสอบถาม จะช่วยให้คุณสามารถแยกสิ่งที่ไม่จำเป็นออกและรับข้อมูลเพิ่มเติมได้ เป็นไปได้ที่จะระบุผู้พัฒนา DNS ที่ผู้ให้บริการใช้และอีกมากมาย
ฉันไม่ได้คาดหวังเลยจริงๆ ว่าผู้ให้บริการโฮสต์จะมีตัวกรองของตัวเองสำหรับ VPS ของฉันด้วย บางทีนี่อาจเป็นวิธีปฏิบัติทั่วไป ในท้ายที่สุด RKN จะส่งคำขอให้ลบทรัพยากรไปยังโฮสต์ แต่สิ่งนี้ไม่ได้ทำให้ฉันประหลาดใจและในบางวิธีก็ใช้ได้ผลดีกับฉันด้วย ตัวกรองทำงานได้อย่างมีประสิทธิภาพมาก โดยตัดคำขอ HTTP ที่ถูกต้องทั้งหมดไปยัง URL ที่ต้องห้าม แต่คำขอไม่ถูกต้องที่ส่งผ่านตัวกรองของผู้ให้บริการก่อนหน้านี้เข้าถึงได้ แม้ว่าจะอยู่ในรูปแบบของการลงท้ายเท่านั้น: FIN-ACK и RST - ลบต่อลบ และเกือบจะกลายเป็นบวก อย่างไรก็ตาม IPv6 ไม่ได้ถูกกรองโดยโฮสต์ แน่นอนว่าสิ่งนี้ส่งผลต่อคุณภาพของวัสดุที่รวบรวม แต่ก็ยังทำให้สามารถมองเห็นความถี่ได้ ปรากฎว่านี่เป็นจุดสำคัญในการเลือกสถานที่สำหรับวางทรัพยากรอย่าลืมที่จะสนใจในเรื่องของการจัดงานพร้อมรายชื่อไซต์ต้องห้ามและคำขอจาก RKN
ในตอนแรกผมเปรียบเทียบ AS "Inspector" กับ . การเปรียบเทียบนี้ค่อนข้างสมเหตุสมผลและเครือข่ายตัวแทนขนาดใหญ่ก็สามารถเป็นประโยชน์ได้ ตัวอย่างเช่น การพิจารณาคุณภาพของทรัพยากรที่มีอยู่จากผู้ให้บริการที่แตกต่างกันในส่วนต่างๆ ของประเทศ คุณสามารถคำนวณความล่าช้า คุณสามารถสร้างกราฟ คุณสามารถวิเคราะห์ได้ทั้งหมด และดูการเปลี่ยนแปลงที่เกิดขึ้นทั้งในระดับท้องถิ่นและระดับโลก นี่ไม่ใช่วิธีที่ตรงที่สุด แต่นักดาราศาสตร์ใช้ "เทียนมาตรฐาน" ทำไมไม่ใช้ตัวแทนล่ะ เมื่อทราบ (เมื่อพบ) พฤติกรรมมาตรฐานแล้ว คุณสามารถกำหนดการเปลี่ยนแปลงที่เกิดขึ้นรอบตัวพวกเขาได้ และสิ่งนี้ส่งผลต่อคุณภาพของบริการที่มีให้อย่างไร และในเวลาเดียวกันคุณไม่จำเป็นต้องวางโพรบบนเครือข่ายอย่างอิสระ Roskomnadzor ได้ติดตั้งไว้แล้ว
อีกประเด็นที่ผมอยากพูดถึงคือเครื่องมือทุกอย่างสามารถเป็นอาวุธได้ AS "Inspector" เป็นเครือข่ายปิด แต่ตัวแทนมอบทุกคนโดยส่งคำขอทรัพยากรทั้งหมดจากรายการต้องห้าม การมีทรัพยากรดังกล่าวไม่ได้ทำให้เกิดปัญหาแต่อย่างใด โดยรวมแล้ว ผู้ให้บริการผ่านตัวแทนบอกเล่าเรื่องราวต่างๆ มากมายเกี่ยวกับเครือข่ายของตนโดยไม่รู้ตัวมากกว่าที่ควรจะเป็น: ประเภท DPI และ DNS, ตำแหน่งของตัวแทน (โหนดกลางและเครือข่ายบริการ?), เครื่องหมายเครือข่ายของความล่าช้าและการสูญเสีย - และนี่คือ ที่ชัดเจนที่สุดเท่านั้น เช่นเดียวกับที่ใครบางคนสามารถตรวจสอบการกระทำของตัวแทนเพื่อปรับปรุงความพร้อมใช้งานของทรัพยากรของพวกเขา บางคนก็สามารถทำเช่นนี้เพื่อวัตถุประสงค์อื่นได้ และไม่มีอุปสรรคในเรื่องนี้ ผลลัพธ์ที่ได้คือเครื่องดนตรีสองคมและมีหลายแง่มุม ใครๆ ก็สามารถเห็นสิ่งนี้ได้
ที่มา: will.com
