Không có gì bí mật rằng việc kiểm soát việc chặn danh sách thông tin bị cấm ở Nga được giám sát bởi hệ thống tự động “Thanh tra”. Cách nó hoạt động được viết tốt ở đây trong này , hình ảnh từ cùng một nơi:
Được cài đặt trực tiếp tại nhà cung cấp :
Mô-đun "Thanh tra đại lý" là một thành phần cấu trúc của hệ thống tự động "Thanh tra" (AS "Thanh tra"). Hệ thống này được thiết kế để giám sát việc tuân thủ của các nhà khai thác viễn thông với các yêu cầu hạn chế truy cập trong khuôn khổ các quy định được thiết lập theo Điều 15.1-15.4 của Luật Liên bang ngày 27 tháng 2006 năm 149 Số XNUMX-FZ “Về thông tin, công nghệ thông tin và bảo vệ thông tin. ”
Mục đích chính của việc tạo ra AS "Revizor" là đảm bảo giám sát việc tuân thủ các yêu cầu của các nhà khai thác viễn thông theo Điều 15.1-15.4 của Luật Liên bang ngày 27 tháng 2006 năm 149 Số XNUMX-FZ "Về thông tin, công nghệ thông tin và bảo vệ thông tin " về mặt xác định sự thật về việc truy cập thông tin bị cấm và thu thập tài liệu (dữ liệu) hỗ trợ về các hành vi vi phạm để hạn chế quyền truy cập vào thông tin bị cấm.
Tính đến thực tế là, nếu không phải tất cả, thì nhiều nhà cung cấp đã cài đặt thiết bị này, lẽ ra phải có một mạng lưới lớn các đầu dò báo hiệu như và thậm chí nhiều hơn nữa, nhưng với quyền truy cập đóng. Tuy nhiên, đèn hiệu là đèn hiệu để gửi tín hiệu đi mọi hướng, nhưng nếu chúng ta bắt được chúng và xem mình đã bắt được những gì và bao nhiêu thì sao?
Trước khi đếm, hãy xem tại sao điều này lại có thể xảy ra.
Một chút lý thuyết
Đại lý kiểm tra tính khả dụng của tài nguyên, bao gồm thông qua các yêu cầu HTTP(S), chẳng hạn như yêu cầu này:
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"
Ngoài tải trọng, yêu cầu còn bao gồm giai đoạn thiết lập kết nối: trao đổi SYN и SYN-ACKvà các giai đoạn hoàn thành kết nối: FIN-ACK.
Sổ đăng ký thông tin bị cấm có chứa một số loại chặn. Rõ ràng, nếu một tài nguyên bị chặn bởi địa chỉ IP hoặc tên miền thì chúng ta sẽ không thấy bất kỳ yêu cầu nào. Đây là những kiểu chặn có sức tàn phá mạnh nhất, dẫn đến không thể truy cập được tất cả tài nguyên trên một địa chỉ IP hoặc tất cả thông tin trên một miền. Ngoài ra còn có kiểu chặn “theo URL”. Trong trường hợp này, hệ thống lọc phải phân tích tiêu đề yêu cầu HTTP để xác định chính xác nội dung cần chặn. Và trước đó, như có thể thấy ở trên, cần có một giai đoạn thiết lập kết nối mà bạn có thể cố gắng theo dõi, vì rất có thể bộ lọc sẽ bỏ lỡ nó.
Để làm được điều này, bạn cần chọn một miền miễn phí phù hợp với kiểu chặn “URL” và HTTP để tạo điều kiện thuận lợi cho hoạt động của hệ thống lọc, tốt nhất là đã bị bỏ hoang từ lâu, nhằm giảm thiểu sự xâm nhập của lưu lượng truy cập không liên quan ngoại trừ từ Đại lý. Nhiệm vụ này hóa ra không hề khó khăn, có khá nhiều tên miền miễn phí trong sổ đăng ký thông tin bị cấm và dành cho mọi sở thích. Do đó, tên miền đã được mua và liên kết với địa chỉ IP trên VPS đang chạy tcpdump và việc đếm bắt đầu.
Kiểm toán của "Kiểm toán viên"
Tôi đã mong đợi sẽ thấy các yêu cầu bùng nổ định kỳ, theo ý kiến của tôi, điều này sẽ cho thấy hành động được kiểm soát. Không thể nói là tôi không nhìn thấy gì cả, nhưng chắc chắn là không có hình ảnh rõ ràng:
Điều này không có gì đáng ngạc nhiên, ngay cả trên một miền không ai cần và trên một IP chưa bao giờ được sử dụng, sẽ có rất nhiều thông tin không được yêu cầu, đó là Internet hiện đại. Nhưng may mắn thay, tôi chỉ cần yêu cầu một URL cụ thể nên tất cả các máy quét và trình bẻ khóa mật khẩu đều nhanh chóng được tìm thấy. Ngoài ra, khá dễ hiểu trận lụt xảy ra ở đâu dựa trên hàng loạt yêu cầu tương tự. Tiếp theo, tôi biên soạn tần suất xuất hiện của các địa chỉ IP và xem xét toàn bộ phần trên cùng một cách thủ công, tách biệt những địa chỉ đã bỏ sót ở các giai đoạn trước. Ngoài ra, tôi đã cắt bỏ tất cả các nguồn được gửi trong một gói, không còn nhiều nguồn nữa. Và đây là những gì đã xảy ra:
Một sự lạc đề trữ tình nhỏ. Hơn một ngày sau, nhà cung cấp hosting của tôi gửi thư với nội dung khá hợp lý, nói rằng cơ sở của bạn chứa tài nguyên thuộc danh sách cấm RKN nên bị chặn. Lúc đầu tôi tưởng tài khoản của mình bị khóa nhưng không phải vậy. Sau đó tôi nghĩ rằng họ chỉ cảnh báo tôi về điều gì đó mà tôi đã biết. Nhưng hóa ra nhà cung cấp dịch vụ lưu trữ đã bật bộ lọc của nó trước miền của tôi và kết quả là tôi phải chịu sự lọc kép: từ nhà cung cấp và từ nhà cung cấp dịch vụ lưu trữ. Bộ lọc chỉ vượt qua phần cuối của yêu cầu: FIN-ACK и RST cắt tất cả HTTP tại một URL bị cấm. Như bạn có thể thấy từ biểu đồ trên, sau ngày đầu tiên, tôi bắt đầu nhận được ít dữ liệu hơn, nhưng tôi vẫn nhận được, khá đủ cho nhiệm vụ đếm nguồn yêu cầu.
Vào vấn đề. Theo tôi, có thể thấy rõ hai vụ nổ mỗi ngày, vụ đầu tiên nhỏ hơn, sau nửa đêm theo giờ Moscow, vụ thứ hai gần 6 giờ sáng và kéo dài đến 12 giờ trưa. Đỉnh điểm không xảy ra cùng một lúc. Lúc đầu, tôi muốn chọn các địa chỉ IP chỉ rơi vào các khoảng thời gian này và từng địa chỉ trong tất cả các khoảng thời gian, dựa trên giả định rằng việc kiểm tra của Đại lý được thực hiện định kỳ. Nhưng khi xem xét cẩn thận, tôi nhanh chóng phát hiện ra các khoảng thời gian rơi vào các khoảng thời gian khác, với tần suất khác, tối đa một yêu cầu mỗi giờ. Sau đó, tôi nghĩ về các múi giờ và có thể nó liên quan gì đó đến chúng, rồi tôi nghĩ rằng nhìn chung hệ thống có thể không được đồng bộ hóa trên toàn cầu. Ngoài ra, NAT có thể sẽ đóng một vai trò và cùng một Agent có thể đưa ra yêu cầu từ các IP công cộng khác nhau.
Vì mục tiêu ban đầu của tôi không chính xác nên tôi đã đếm tất cả các địa chỉ mà tôi tìm thấy trong một tuần và nhận được - 2791. Số phiên TCP được thiết lập từ một địa chỉ trung bình là 4, với giá trị trung bình là 2. Các phiên hàng đầu trên mỗi địa chỉ: 464, 231, 149, 83, 77. Tối đa từ 95% mẫu là 8 phiên cho mỗi địa chỉ. Mức trung bình không cao lắm, hãy để tôi nhắc bạn rằng biểu đồ hiển thị chu kỳ hàng ngày rõ ràng, vì vậy người ta có thể mong đợi khoảng 4 đến 8 trong 7 ngày. Nếu chúng tôi loại bỏ tất cả các phiên xảy ra một lần, chúng tôi sẽ nhận được trung vị bằng 5. Nhưng tôi không thể loại trừ chúng dựa trên một tiêu chí rõ ràng. Ngược lại, một cuộc kiểm tra ngẫu nhiên cho thấy chúng có liên quan đến các yêu cầu về tài nguyên bị cấm.
Địa chỉ là địa chỉ, nhưng trên Internet, các hệ thống tự trị - AS, hóa ra lại quan trọng hơn 1510, trung bình có 2 địa chỉ trên mỗi AS với giá trị trung bình là 1. Các địa chỉ hàng đầu trên mỗi AS: 288, 77, 66, 39, 27. Tối đa 95% mẫu là 4 địa chỉ trên mỗi AS. Ở đây dự kiến có mức trung bình - một Đại lý cho mỗi nhà cung cấp. Chúng tôi cũng mong đợi đỉnh cao - có những người chơi lớn trong đó. Trong một mạng lớn, Đại lý có thể phải được đặt ở từng khu vực có sự hiện diện của nhà điều hành và đừng quên NAT. Nếu chúng tôi lấy theo quốc gia, mức tối đa sẽ là: 1409 - RU, 42 - UA, 23 - CZ, 36 từ các khu vực khác, không phải RIPE NCC. Yêu cầu từ bên ngoài nước Nga thu hút sự chú ý. Điều này có thể được giải thích là do lỗi định vị địa lý hoặc lỗi của nhà đăng ký khi điền dữ liệu. Hoặc việc một công ty Nga có thể không có gốc gác ở Nga, hoặc có văn phòng đại diện nước ngoài vì dễ dàng hơn, đó là điều đương nhiên khi giao dịch với tổ chức nước ngoài RIPE NCC. Một số phần chắc chắn là không cần thiết, nhưng rất khó để tách nó ra, vì tài nguyên đang bị chặn và kể từ ngày thứ hai bị chặn kép và hầu hết các phiên chỉ là trao đổi một số gói dịch vụ. Hãy đồng ý rằng đây là một phần nhỏ.
Những con số này có thể được so sánh với số lượng nhà cung cấp ở Nga. giấy phép cho “Dịch vụ liên lạc để truyền dữ liệu, không bao gồm giọng nói” - 6387, nhưng đây là ước tính rất cao so với trên, không phải tất cả các giấy phép này đều áp dụng cụ thể cho các nhà cung cấp Internet cần cài đặt Đại lý. Trong khu vực RIPE NCC có số lượng AS tương tự được đăng ký ở Nga - 6230, trong đó không phải tất cả đều là nhà cung cấp. và đã nhận được 3940 công ty vào năm 2017, và đây đúng hơn là ước tính từ phía trên. Trong mọi trường hợp, chúng ta có số lượng AS được chiếu sáng ít hơn hai lần rưỡi. Nhưng ở đây cần hiểu rằng AS không hoàn toàn ngang bằng với nhà cung cấp. Một số nhà cung cấp không có AS riêng, một số có nhiều hơn một. Nếu chúng ta giả định rằng mọi người vẫn có Đại lý, thì ai đó sẽ lọc mạnh hơn những người khác, để các yêu cầu của họ không thể phân biệt được với rác nếu chúng đến được với họ. Nhưng để đánh giá sơ bộ thì điều đó là khá chấp nhận được, ngay cả khi có thứ gì đó bị mất do sự sơ suất của tôi.
Giới thiệu về dpi
Mặc dù thực tế là nhà cung cấp dịch vụ lưu trữ của tôi đã bật bộ lọc bắt đầu từ ngày thứ hai, nhưng dựa trên thông tin từ ngày đầu tiên, chúng tôi có thể kết luận rằng tính năng chặn đang hoạt động thành công. Chỉ có 4 nguồn vượt qua được và hoàn thành đầy đủ các phiên HTTP và TCP (như ví dụ trên). 460 khác có thể được gửi GET, nhưng phiên kết thúc ngay lập tức bởi RST. Chú ý đến 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"
Các biến thể của điều này có thể khác nhau: ít hơn RST hoặc nhiều lần truyền lại - cũng phụ thuộc vào những gì bộ lọc gửi đến nút nguồn. Trong mọi trường hợp, đây là mẫu đáng tin cậy nhất, từ đó có thể thấy rõ rằng đó là tài nguyên bị cấm đã được yêu cầu. Ngoài ra, luôn có câu trả lời xuất hiện trong phiên với TTL lớn hơn trong các gói trước và gói tiếp theo.
Bạn thậm chí không thể nhìn thấy nó từ phần còn lại 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"
Hay như vậy:
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"
...
Sự khác biệt chắc chắn có thể nhìn thấy được TTL nếu có gì đó đến từ bộ lọc. Nhưng thường thì không có gì có thể xảy ra cả:
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"
...
Hay như vậy:
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"
...
Và tất cả những điều này được lặp đi lặp lại, lặp đi lặp lại, như có thể thấy trên biểu đồ, hơn một lần, mỗi ngày.
Giới thiệu về IPv6
Tin tốt là nó tồn tại. Tôi có thể nói một cách đáng tin cậy rằng các yêu cầu định kỳ tới một tài nguyên bị cấm xảy ra từ 5 địa chỉ IPv6 khác nhau, đây chính xác là hành vi của các Đại lý mà tôi mong đợi. Hơn nữa, một trong các địa chỉ IPv6 không thuộc diện lọc và tôi thấy toàn bộ phiên. Từ hai phần nữa tôi chỉ thấy một phiên còn dang dở, một trong số đó đã bị gián đoạn bởi RST từ bộ lọc, lần thứ hai. Tổng cộng 7.
Vì có ít địa chỉ nên tôi đã nghiên cứu chi tiết tất cả và hóa ra chỉ có 3 nhà cung cấp ở đó, họ có thể được hoan nghênh nhiệt liệt! Địa chỉ khác là cloud hosting ở Nga (không lọc), địa chỉ khác là trung tâm nghiên cứu ở Đức (có bộ lọc, ở đâu?). Nhưng tại sao họ lại kiểm tra sự sẵn có của các tài nguyên bị cấm theo lịch trình là một câu hỏi hay. Hai người còn lại thực hiện một yêu cầu và được đặt bên ngoài nước Nga, và một trong số chúng đã được lọc (rốt cuộc là đang quá cảnh phải không?).
Việc chặn và các đại lý là một trở ngại lớn đối với IPv6, việc triển khai nó không diễn ra nhanh chóng. Thật là buồn. Những người giải quyết được vấn đề này có thể hoàn toàn tự hào về mình.
Kết luận
Tôi đã không cố gắng đạt độ chính xác 100%, xin hãy tha thứ cho tôi vì điều này, tôi hy vọng ai đó muốn lặp lại công việc này với độ chính xác cao hơn. Điều quan trọng đối với tôi là phải hiểu liệu phương pháp này có hiệu quả về mặt nguyên tắc hay không. Câu trả lời là có. Tôi nghĩ những số liệu thu được là khá đáng tin cậy, như ước tính đầu tiên.
Những gì khác có thể đã được thực hiện và điều tôi quá lười để làm là đếm các yêu cầu DNS. Chúng không được lọc nhưng cũng không cung cấp nhiều độ chính xác vì chúng chỉ hoạt động cho miền chứ không hoạt động cho toàn bộ URL. Tần số phải được nhìn thấy. Nếu bạn kết hợp nó với những gì hiển thị trực tiếp trong các truy vấn, điều này sẽ cho phép bạn loại bỏ những thông tin không cần thiết và nhận được nhiều thông tin hơn. Thậm chí có thể xác định các nhà phát triển DNS được các nhà cung cấp sử dụng và hơn thế nữa.
Tôi hoàn toàn không ngờ rằng nhà cung cấp dịch vụ lưu trữ cũng sẽ đưa vào bộ lọc riêng cho VPS của tôi. Có lẽ đây là thông lệ. Cuối cùng, RKN gửi yêu cầu xóa tài nguyên đến máy chủ lưu trữ. Nhưng điều này không làm tôi ngạc nhiên và ở một khía cạnh nào đó thậm chí còn có lợi cho tôi. Bộ lọc hoạt động rất hiệu quả, cắt bỏ tất cả các yêu cầu HTTP chính xác tới một URL bị cấm, nhưng không phải những yêu cầu chính xác đã đi qua bộ lọc của nhà cung cấp trước đó đã đến được với họ, mặc dù chỉ ở dạng kết thúc: FIN-ACK и RST - trừ cho trừ và nó gần như trở thành một điểm cộng. Nhân tiện, IPv6 không được nhà cung cấp dịch vụ lưu trữ lọc. Tất nhiên, điều này ảnh hưởng đến chất lượng của tài liệu thu thập được, nhưng nó vẫn có thể nhìn thấy tần số. Hóa ra đây là một điểm quan trọng khi chọn địa điểm đặt tài nguyên, đừng quên quan tâm đến vấn đề tổ chức công việc với danh sách các địa điểm bị cấm và yêu cầu từ RKN.
Lúc đầu, tôi đã so sánh AS "Thanh tra" với . Sự so sánh này khá hợp lý và một mạng lưới Đại lý rộng lớn có thể mang lại lợi ích. Ví dụ: xác định chất lượng nguồn lực sẵn có từ các nhà cung cấp khác nhau ở các vùng khác nhau của đất nước. Bạn có thể tính toán độ trễ, bạn có thể xây dựng biểu đồ, bạn có thể phân tích tất cả và xem những thay đổi xảy ra ở cả cục bộ và toàn cầu. Đây không phải là cách trực tiếp nhất mà các nhà thiên văn học dùng “ngọn nến chuẩn”, tại sao lại không dùng Tác nhân? Biết (đã tìm thấy) hành vi tiêu chuẩn của họ, bạn có thể xác định những thay đổi xảy ra xung quanh họ và điều này ảnh hưởng như thế nào đến chất lượng dịch vụ được cung cấp. Đồng thời, bạn không cần phải đặt các đầu dò độc lập trên mạng, Roskomnadzor đã cài đặt chúng.
Một điểm khác tôi muốn đề cập đến là mọi công cụ đều có thể là vũ khí. NHƯ "Thanh tra" là một mạng đóng, nhưng Đại lý bàn giao cho mọi người bằng cách gửi yêu cầu về tất cả các tài nguyên từ danh sách bị cấm. Có một nguồn tài nguyên như vậy không có bất kỳ vấn đề gì cả. Tổng cộng, các nhà cung cấp thông qua Đại lý, vô tình, cho biết nhiều thông tin về mạng của họ hơn mức có thể đáng giá: các loại dpi và DNS, vị trí của Đại lý (nút trung tâm và mạng dịch vụ?), điểm đánh dấu mạng về sự chậm trễ và mất mát - và đây là chỉ là điều rõ ràng nhất. Giống như ai đó có thể giám sát hành động của Đại lý để cải thiện tính sẵn có của tài nguyên của họ, ai đó có thể thực hiện việc này cho các mục đích khác và không có trở ngại nào đối với việc này. Kết quả là một công cụ hai lưỡi và rất nhiều mặt, ai cũng có thể thấy điều này.
Nguồn: www.habr.com