에이전트 "Inspector"를 세어 봅시다

러시아의 금지 정보 목록 차단 제어가 자동화 시스템 "Inspector"에 의해 모니터링된다는 것은 비밀이 아닙니다. 작동 방식은 여기에 잘 설명되어 있습니다. Habr에 관한 기사, 같은 장소에서 찍은 사진:

공급자에게 직접 설치됨 모듈 "에이전트 검사기":

"Agent Inspector" 모듈은 자동화 시스템 "Inspector"(AS "Inspector")의 구조적 요소입니다. 이 시스템은 15.1년 15.4월 27일자 연방법 No. 2006-FZ "정보, 정보 기술 및 정보 보호에 관한" 149-XNUMX조에 의해 확립된 조항의 틀 내에서 통신 사업자의 액세스 제한 요구 사항 준수를 모니터링하도록 설계되었습니다. ”

AS "Revizor"를 만드는 주요 목적은 15.1년 15.4월 27일자 연방법 No. 2006-FZ "정보, 정보 기술 및 정보 보호에 관한 연방법 149-XNUMX조에 의해 설정된 요구 사항을 통신 사업자가 준수하는지 모니터링하는 것입니다. " 금지정보에 대한 접근사실을 확인하고, 금지정보에 대한 접근을 제한하기 위한 위반행위에 대한 근거자료(자료)를 확보하는 것입니다.

전부는 아니더라도 많은 공급자가 이 장치를 설치했다는 사실을 고려하면 다음과 같은 대규모 비콘 프로브 네트워크가 있어야 합니다. 익은 아틀라스 그 이상이지만 접근이 제한되어 있습니다. 그런데 비콘은 사방으로 신호를 보내는 비콘인데, 그걸 잡아서 무엇을 잡았는지, 얼마나 많이 잡았는지 보면 어떨까요?

계산하기 전에 이것이 왜 가능한지 살펴보겠습니다.

약간의 이론

에이전트는 다음과 같은 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 차단 유형이 있는 적절한 무료 도메인을 선택해야 하며, 에이전트를 제외한 외부 트래픽의 진입을 최소화하기 위해 바람직하게는 오래 방치된 도메인을 선택해야 합니다. 이 작업은 전혀 어렵지 않은 것으로 판명되었으며 금지 정보 등록부와 모든 취향에 맞는 무료 도메인이 상당히 많습니다. 따라서 도메인을 구입하여 실행 중인 VPS의 IP 주소에 연결했습니다. tcpdump 그리고 계산이 시작되었습니다.

"감사인"의 감사

나는 주기적으로 요청이 급증할 것으로 예상했는데, 이는 통제된 조치를 의미한다고 생각합니다. 전혀 보지 못했다고 말할 수는 없지만 명확한 그림은 확실히 없었습니다.

아무도 필요하지 않은 도메인과 한 번도 사용하지 않은 IP에도 현대 인터넷과 같이 원치 않는 정보가 엄청나게 많이 있다는 것은 놀라운 일이 아닙니다. 하지만 다행스럽게도 특정 URL에 대한 요청만 필요했기 때문에 모든 스캐너와 비밀번호 크래커를 빠르게 찾을 수 있었습니다. 또한 유사한 요청이 대량으로 발생한 것을 바탕으로 홍수가 발생한 곳을 이해하는 것은 매우 쉬웠습니다. 다음으로 IP 주소의 발생 빈도를 집계하고 전체 상단을 수동으로 살펴 이전 단계에서 놓친 사람들을 분리했습니다. 게다가 하나의 패키지로 보내졌던 소스도 모두 잘라내서 더 이상 많지 않았습니다. 그리고 일어난 일은 다음과 같습니다.

작은 서정적 여담. 하루가 조금 지나서 호스팅 제공업체는 귀하의 시설에 RKN 금지 목록의 리소스가 포함되어 있어 차단되었다는 내용의 다소 간소화된 내용이 포함된 편지를 보냈습니다. 처음에는 내 계정이 차단된 줄 알았는데, 사실이 아니었습니다. 그러다가 나는 그들이 단지 내가 이미 알고 있는 것에 대해 경고하는 것이라고 생각했습니다. 그러나 호스팅 업체가 내 도메인 앞에서 필터를 켠 것으로 밝혀졌고 그 결과 공급자와 호스팅 업체로부터 이중 필터링을 받게 되었습니다. 필터는 요청의 끝만 통과했습니다. FIN-ACK и RST 금지된 URL에서 모든 HTTP를 차단합니다. 위 그래프에서 볼 수 있듯이, 첫날부터 수신되는 데이터의 양이 줄어들기 시작했지만 여전히 수신하고 있어 요청 소스 계산 작업에 충분했습니다.

요점을 파악하세요. 제 생각에는 매일 두 번의 폭발이 명확하게 보입니다. 첫 번째는 모스크바 시간 자정 이후에 더 작고 두 번째는 정오까지 꼬리가 있는 오전 6시에 가깝습니다. 피크는 정확히 동시에 발생하지 않습니다. 처음에는 Agent의 점검이 주기적으로 수행된다는 가정하에 해당 기간에만 해당하는 IP 주소와 모든 기간에 해당하는 IP 주소를 선택하고 싶었습니다. 그러나 주의 깊게 검토한 결과, 기간이 다른 간격, 빈도, 매시간 최대 12회 요청에 해당한다는 사실을 빠르게 발견했습니다. 그런 다음 시간대에 대해 생각했고 그것이 아마도 그것과 관련이 있을 수도 있다고 생각했고 일반적으로 시스템이 전역적으로 동기화되지 않을 수도 있다고 생각했습니다. 또한 NAT가 역할을 수행할 수 있으며 동일한 에이전트가 다른 공용 IP에서 요청할 수 있습니다.

처음 목표가 정확하지 않았기 때문에 일주일 동안 발견한 모든 주소를 세어보니 다음과 같은 결과가 나왔습니다. 2791. 한 주소에서 설정된 TCP 세션 수는 평균 4개이며 중앙값은 2입니다. 주소당 상위 세션: 464, 231, 149, 83, 77. 샘플의 95%에서 최대값은 주소당 8개 세션입니다. 중앙값은 그리 높지 않습니다. 그래프에는 명확한 일일 주기가 표시되므로 4일에 약 8~7일을 예상할 수 있습니다. 한 번 발생한 세션을 모두 버리면 중앙값은 5가 됩니다. 하지만 명확한 기준에 따라 이들을 제외할 수는 없었습니다. 오히려 무작위로 확인한 결과 금지된 자원에 대한 요청과 관련이 있는 것으로 나타났습니다.

주소는 주소이지만 인터넷에서는 자율 시스템-AS가 더 중요하다는 것이 밝혀졌습니다. 1510, AS당 평균 2개의 주소(중간값 1). AS당 상위 주소: 288, 77, 66, 39, 27. 샘플의 최대 95%는 AS당 4개의 주소입니다. 여기서 예상되는 중앙값은 공급자당 하나의 에이전트입니다. 우리는 또한 최고를 기대합니다. 거기에는 큰 플레이어가 있습니다. 대규모 네트워크에서는 에이전트가 운영자가 있는 각 지역에 위치해야 하며 NAT도 잊지 마세요. 국가별로 살펴보면 최대값은 RIPE NCC가 아닌 다른 지역의 1409 - RU, 42 - UA, 23 - CZ, 36입니다. 러시아 외부의 요청이 주목을 받고 있습니다. 이는 데이터를 입력할 때 지리적 위치 오류나 등록자 오류로 인해 설명될 수 있습니다. 또는 러시아 회사가 러시아에 뿌리를 두지 않거나 더 쉽기 때문에 외국 대표 사무소를 가질 수 있다는 사실은 외국 조직 RIPE NCC를 상대할 때 자연스러운 현상입니다. 일부 부분은 의심할 여지없이 불필요하지만 리소스가 차단되고 둘째 날부터 이중 차단이 적용되며 대부분의 세션은 여러 서비스 패킷의 교환일 뿐이므로 이를 분리하는 것은 안정적으로 어렵습니다. 이것이 작은 부분이라는 데 동의합시다.

이 수치는 이미 러시아의 제공업체 수와 비교할 수 있습니다. RKN에 따르면 "음성을 제외한 데이터 전송을 위한 통신 서비스"에 대한 라이센스 - 6387이지만 위에서 보면 이는 매우 높은 추정치이며 이러한 라이센스 모두가 에이전트를 설치해야 하는 인터넷 제공자에게 특별히 적용되는 것은 아닙니다. RIPE NCC 영역에는 러시아에 등록된 비슷한 수의 AS가 6230개 있는데, 그 중 모두가 공급자는 아닙니다. UserSide는 더 엄격한 계산을 수행했습니다. 3940년에는 2017개 업체를 접수했는데 이는 오히려 위에서 추정한 수치이다. 어쨌든 조명이 들어오는 AS 수가 XNUMX배 적습니다. 그러나 여기서는 AS가 공급자와 엄격하게 동일하지 않다는 점을 이해하는 것이 좋습니다. 일부 제공업체에는 자체 AS가 없고 일부 제공업체에는 둘 이상의 AS가 있습니다. 모든 사람이 여전히 에이전트를 갖고 있다고 가정하면 누군가가 다른 사람보다 더 강력하게 필터링하므로 요청이 도달하더라도 쓰레기와 구별할 수 없게 됩니다. 그러나 대략적으로 평가하면 내 감독으로 인해 무언가가 손실된 경우에도 상당히 견딜 수 있습니다.

DPI 소개

호스팅 제공업체가 둘째 날부터 필터를 켰음에도 불구하고 첫날의 정보를 바탕으로 차단이 성공적으로 작동하고 있다는 결론을 내릴 수 있습니다. 위의 예에서와 같이 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 정보

좋은 소식은 그것이 존재한다는 것입니다. 금지된 리소스에 대한 주기적인 요청이 5개의 서로 다른 IPv6 주소에서 발생한다고 확실하게 말할 수 있습니다. 이는 정확히 제가 예상했던 에이전트의 동작입니다. 게다가 IPv6 주소 중 하나가 필터링에 속하지 않고 전체 세션이 표시됩니다. 두 개 이상의 세션에서 나는 완료되지 않은 세션을 하나만 보았습니다. 그 중 하나는 다음에 의해 중단되었습니다. RST 필터에서 두 번째로. 총액 7.

주소가 적기 때문에 모두 자세히 조사한 결과 제공 업체가 3 개 뿐이어서 기립 박수를받을 수 있습니다! 또 다른 주소는 러시아의 클라우드 호스팅(필터링되지 않음)이고, 또 다른 주소는 독일의 연구 센터입니다(필터가 어디에 있습니까?). 그런데 왜 일정에 따라 금지된 자원의 가용성을 확인하는지는 좋은 질문입니다. 나머지 두 개는 하나의 요청을 했고 러시아 외부에 위치하고 있으며 그 중 하나는 필터링되었습니다(결국 전송 중인가요?).

차단 및 에이전트는 IPv6의 구현이 매우 빠르게 진행되지 않는 IPvXNUMX에 큰 방해가 됩니다. 슬프다. 이 문제를 해결한 사람들은 스스로 자부심을 느낄 수 있습니다.

결론적으로

나는 100% 정확성을 위해 노력하지 않았습니다. 이 점을 용서해 주십시오. 누군가가 이 작업을 더 정확하게 반복하기를 원하기를 바랍니다. 이 접근 방식이 원칙적으로 작동하는지 이해하는 것이 중요했습니다. 대답은 '예'입니다. 내 생각에 얻은 수치는 첫 번째 근사치로서 매우 신뢰할만하다고 생각합니다.

그 밖에 할 수 있었던 일이 있었는데 제가 너무 게을러서 할 수 없었던 일은 DNS 요청을 세는 것이었습니다. 필터링되지는 않지만 전체 URL이 아닌 도메인에 대해서만 작동하므로 정확도가 높지 않습니다. 주파수가 표시되어야 합니다. 이를 쿼리에 직접 표시되는 것과 결합하면 불필요한 것을 분리하고 더 많은 정보를 얻을 수 있습니다. 공급자 등이 사용하는 DNS 개발자를 결정하는 것도 가능합니다.

호스팅 업체가 내 VPS에 대한 자체 필터도 포함할 것이라고는 전혀 예상하지 못했습니다. 어쩌면 이것이 일반적인 관행일 수도 있습니다. 결국 RKN은 호스팅 업체에 리소스 삭제 요청을 보냅니다. 그러나 이것은 나에게 놀라운 일이 아니었고 어떤 면에서는 나에게 유리하게 작용하기도 했습니다. 필터는 매우 효과적으로 작동하여 금지된 URL에 대한 모든 올바른 HTTP 요청을 차단했지만, 이전에 공급자의 필터를 통과한 올바른 HTTP 요청은 비록 엔딩 형식으로만 도달했지만 도달하지 못했습니다. FIN-ACK и RST - 마이너스는 마이너스이고 거의 플러스로 판명되었습니다. 그런데 IPv6는 호스팅 업체에 의해 필터링되지 않았습니다. 물론 이는 수집된 자료의 품질에 영향을 주었지만 여전히 빈도를 확인할 수 있게 해주었습니다. 이는 리소스 배치를 위한 사이트를 선택할 때 중요한 점이며, 금지된 사이트 목록과 RKN의 요청을 사용하여 작업을 구성하는 문제에 관심을 갖는 것을 잊지 마십시오.

처음에는 AS "Inspector"를 다음과 비교했습니다. 익은 아틀라스. 이 비교는 상당히 타당하며 대규모 에이전트 네트워크가 도움이 될 수 있습니다. 예를 들어, 국가의 여러 지역에 있는 다양한 공급자의 리소스 가용성 품질을 결정합니다. 지연을 계산하고, 그래프를 작성하고, 모든 것을 분석하고 로컬 및 전역적으로 발생하는 변경 사항을 확인할 수 있습니다. 이것이 가장 직접적인 방법은 아니지만 천문학자들은 "표준 양초"를 사용합니다. 에이전트를 사용하지 않는 이유는 무엇입니까? 표준 동작을 알면(발견) 주변에서 발생하는 변경 사항과 이것이 제공되는 서비스 품질에 어떤 영향을 미치는지 확인할 수 있습니다. 동시에 네트워크에 프로브를 독립적으로 배치할 필요가 없으며 Roskomnadzor가 이미 프로브를 설치했습니다.

제가 언급하고 싶은 또 다른 점은 모든 도구가 무기가 될 수 있다는 것입니다. AS "Inspector"는 폐쇄형 네트워크이지만 에이전트는 금지 목록의 모든 리소스에 대한 요청을 보내 모든 사람을 넘겨줍니다. 그러한 리소스가 있으면 전혀 문제가 발생하지 않습니다. 전체적으로, 공급자는 에이전트를 통해 자신도 모르게 DPI 및 DNS 유형, 에이전트 위치(중앙 노드 및 서비스 네트워크?), 지연 및 손실에 대한 네트워크 마커 등 네트워크에 대해 가치 있는 것보다 더 많은 정보를 제공합니다. 가장 분명한 것뿐입니다. 누군가 에이전트의 작업을 모니터링하여 리소스 가용성을 향상시킬 수 있는 것처럼 누군가는 다른 목적으로 이를 수행할 수 있으며 이에 대한 장애물은 없습니다. 그 결과 양날의 매우 다면적인 도구가 탄생했습니다. 누구나 이를 볼 수 있습니다.

출처 : habr.com