Ресейде тыйым салынған ақпарат тізіміндегі бұғаттауды бақылау «Инспектор» автоматтандырылған жүйесі арқылы бақыланатыны ешкімге құпия емес. Бұл қалай жұмыс істейтіні осы жерде жақсы жазылған , сол жерден алынған сурет:
Тікелей провайдерде орнатылған :
«Инспектор агенті» модулі «Инспектор» автоматтандырылған жүйесінің құрылымдық элементі болып табылады («Инспектор» АС). Бұл жүйе «Ақпарат, ақпараттық технологиялар және ақпаратты қорғау туралы» 15.1 жылғы 15.4 шілдедегі № 27-ФЗ Федералдық заңының 2006-149-баптарында белгіленген ережелер шеңберінде байланыс операторларының қол жеткізуді шектеу талаптарын сақтауын бақылауға арналған. »
«Revizor» АС құрудың негізгі мақсаты «Ақпарат, ақпараттық технологиялар және ақпаратты қорғау туралы» 15.1 жылғы 15.4 шілдедегі № 27-ФЗ Федералдық заңының 2006-149-баптарында белгіленген талаптарға байланыс операторларының сәйкестігін бақылауды қамтамасыз ету болып табылады. «Тыйым салынған ақпаратқа қол жеткізу фактілерін анықтау және тыйым салынған ақпаратқа қолжетімділікті шектеу үшін бұзушылықтар туралы растаушы материалдарды (деректер) алу бөлігінде.
Барлығы болмаса да, көптеген провайдерлер бұл құрылғыны орнатқанын ескере отырып, маяк зондтарының үлкен желісі болуы керек еді. және одан да көп, бірақ жабық қол жетімділікпен. Дегенмен, маяк барлық бағыттарға сигнал жіберуге арналған маяк, бірақ біз оларды ұстап алып, не ұстағанымызды және қанша екенін көрсек ше?
Біз санамас бұрын, неге бұл мүмкін болуы мүмкін екенін көрейік.
Біраз теория
Агенттер ресурстың қолжетімділігін, соның ішінде 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 мекенжайларының пайда болу жиілігін құрастырдым және алдыңғы кезеңдерде жіберіп алғандарды бөліп, бүкіл жоғарғы жағын қолмен аралап шықтым. Сонымен қатар, мен бір пакетте жіберілген барлық дереккөздерді кесіп тастадым, енді олардың көпшілігі жоқ. Ал мына оқиға болды:
Шағын лирикалық шегініс. Бір күннен сәл астам уақыттан кейін менің хостинг провайдерім сіздің нысандарыңызда ҚРН тыйым салынғандар тізіміндегі ресурс бар, сондықтан ол бұғатталған деп, біршама жеңілдетілген мазмұны бар хат жіберді. Басында менің аккаунтым бұғатталған деп ойладым, олай емес. Содан кейін олар маған бұрыннан білетін нәрсе туралы ескертеді деп ойладым. Бірақ хосттер менің доменімнің алдында сүзгіні қосқаны белгілі болды, нәтижесінде мен қос сүзгіден өттім: провайдерлерден және хосттерден. Сүзгі тек сұраулардың соңынан өтті: FIN-ACK и RST тыйым салынған URL мекенжайындағы барлық HTTP-ны кесу. Жоғарыдағы графиктен көріп отырғаныңыздай, бірінші күннен кейін мен аз деректерді ала бастадым, бірақ мен оны әлі де алдым, бұл сұрау көздерін санау тапсырмасы үшін жеткілікті болды.
Нүктеге келіңіз. Менің ойымша, екі жарылыс күн сайын анық көрінеді, біріншісі кішірек, Мәскеу уақыты бойынша түн ортасынан кейін, екіншісі таңғы сағат 6-ға жақын, түскі 12-ге дейін құйрықпен. Шың дәл бір уақытта болмайды. Алдымен мен Агенттердің тексерулері мерзімді түрде орындалады деген болжамға сүйене отырып, тек осы кезеңдерде және әрқайсысында барлық кезеңдердегі IP мекенжайларын таңдағым келді. Бірақ мұқият қарап шыққаннан кейін мен сағат сайын бір сұрауға дейін басқа жиіліктермен басқа аралықтарға түсетін кезеңдерді тез таптым. Содан кейін мен уақыт белдеулері туралы ойладым және мүмкін олармен қандай да бір қатысы бар шығар, содан кейін жалпы жүйе жаһандық деңгейде синхрондалмаған болуы мүмкін деп ойладым. Сонымен қатар, NAT рөл атқаруы мүмкін және сол Агент әртүрлі жалпы IP мекенжайларынан сұраулар жасай алады.
Бастапқы мақсатым дәл болмағандықтан, мен бір апта ішінде кездестірген барлық мекенжайларды санап шықтым - 2791. Бір мекенжайдан орнатылған TCP сеанстарының саны орта есеппен 4, медианасы 2. Әр мекенжай бойынша ең жоғары сеанстар: 464, 231, 149, 83, 77. Үлгідегі 95% ең көбі бір мекенжайға 8 сеанс. Медиана өте жоғары емес, графикте айқын күнделікті кезеңділік көрсетілгенін еске сала кетейін, сондықтан 4 күнде 8-тен 7-ге дейін бірдеңені күтуге болады. Егер біз бір рет болатын барлық сеанстарды тастасақ, біз 5-ке тең медиана аламыз. Бірақ мен оларды нақты критерийге сүйене отырып алып тастай алмадым. Керісінше, кездейсоқ тексеру олардың тыйым салынған ресурсқа сұраныстармен байланысты екенін көрсетті.
Адрестер мекенжайлар, бірақ Интернетте автономды жүйелер - AS маңыздырақ болып шықты 1510, медианасы 2 болатын АС үшін орта есеппен 1 мекенжай. AS үшін ең жоғары мекенжайлар: 288, 77, 66, 39, 27. Үлгідегі ең көбі 95% AS үшін 4 мекенжай. Мұнда медиана күтіледі – әр провайдерге бір Агент. Біз де шыңды күтеміз – оның құрамында үлкен ойыншылар бар. Үлкен желіде агенттер оператордың әрбір аймағында орналасуы керек және NAT туралы ұмытпаңыз. Ел бойынша алатын болсақ, максимумдар: 1409 - RU, 42 - UA, 23 - CZ, RIPE NCC емес, басқа аймақтардан 36 болады. Ресейден тыс жерлерден келген сұраныстар назар аудартады. Бұл деректерді толтыру кезінде геолокация қателері немесе тіркеуші қателерімен түсіндірілуі мүмкін. Немесе ресейлік компанияның ресейлік тамыры болмауы мүмкін, немесе шетелде өкілдігі болуы мүмкін, себебі бұл оңайырақ, бұл RIPE NCC шетелдік ұйымымен жұмыс істегенде табиғи нәрсе. Кейбір бөліктер сөзсіз артық, бірақ оны ажырату сенімді түрде қиын, өйткені ресурс бұғаттауда, ал екінші күннен бастап қос блоктауда және сеанстардың көпшілігі тек бірнеше қызмет пакеттерінің алмасуы болып табылады. Келісейік, бұл шағын бөлік.
Бұл сандарды қазірдің өзінде Ресейдегі провайдерлердің санымен салыстыруға болады. «Деректерді беру, дауысты қоспағанда, байланыс қызметтері» лицензиялары - 6387, бірақ бұл жоғарыдан жоғары баға, бұл лицензиялардың барлығы Агентті орнатуды қажет ететін Интернет-провайдерлерге арнайы қолданылмайды. RIPE NCC аймағында Ресейде тіркелген АС саны ұқсас - 6230, олардың барлығы провайдер емес. және 3940 жылы 2017 компанияны қабылдады, бұл жоғарыдан жасалған болжам. Қалай болғанда да, бізде жарықтандырылған АС саны екі жарым есе аз. Бірақ бұл жерде 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-ға үлкен кедергі болып табылады, оны іске асыру өте жылдам емес. Бұл өкінішті. Бұл мәселені шешкендер өздерін толық мақтана алады.
Қорытындылай келе
Мен 100% дәлдікке ұмтылмадым, бұл үшін мені кешіріңіз, біреу бұл жұмысты дәлірек қайталағысы келеді деп үміттенемін. Мен үшін бұл тәсілдің принципті түрде жұмыс істейтінін түсіну маңызды болды. Жауап иә. Алынған сандар, бірінші жуықтау ретінде, менің ойымша, өте сенімді.
Басқа не істеуге болатын еді және мен істеуге тым жалқау болғаным - DNS сұрауларын санау. Олар сүзгіден өтпейді, бірақ олар да көп дәлдік бермейді, өйткені олар бүкіл URL үшін емес, тек домен үшін жұмыс істейді. Жиілік көрінетін болуы керек. Егер сіз оны тікелей сұрауларда көрінетін нәрселермен біріктірсеңіз, бұл қажетсіздерді бөліп алуға және қосымша ақпарат алуға мүмкіндік береді. Тіпті провайдерлер пайдаланатын DNS әзірлеушілерін және т.б. анықтауға болады.
Мен хостинг менің VPS-ім үшін өз сүзгіні қосады деп мүлде күткен жоқпын. Мүмкін бұл әдеттегі тәжірибе. Соңында РКН ресурсты жою туралы сұрауды хосттерге жібереді. Бірақ бұл мені таң қалдырмады және кейбір жағынан менің пайдама жұмыс істеді. Сүзгі өте тиімді жұмыс істеді, тыйым салынған URL мекенжайына барлық дұрыс HTTP сұрауларын кесіп тастады, бірақ бұрын провайдерлердің сүзгісінен өткен дұрыс емес сұраулар оларға тек аяқталу түрінде болса да жетпеді: FIN-ACK и RST - минус үшін минус және бұл плюс болып шықты. Айтпақшы, IPv6 хостпен сүзгіден өтпеді. Әрине, бұл жиналған материалдың сапасына әсер етті, бірақ ол әлі де жиілікті көруге мүмкіндік берді. Бұл ресурстарды орналастыру үшін сайтты таңдау кезінде маңызды сәт екені белгілі болды, тыйым салынған сайттар тізімімен жұмысты ұйымдастыру мәселесіне қызығушылық танытуды ұмытпаңыз және ҚРН сұраныстары.
Басында мен «Ревизор» АС-ын салыстырдым . Бұл салыстыру өте орынды және Агенттердің үлкен желісі пайдалы болуы мүмкін. Мысалы, елдің әртүрлі бөліктеріндегі әртүрлі провайдерлердің ресурстарға қолжетімділік сапасын анықтау. Сіз кідірістерді есептей аласыз, графиктер құра аласыз, барлығын талдай аласыз және жергілікті және ғаламдық деңгейде болып жатқан өзгерістерді көре аласыз. Бұл ең тікелей жол емес, бірақ астрономдар «стандартты шамдарды» пайдаланады, неге агенттерді қолданбасқа? Олардың стандартты мінез-құлқын біле (табу) олардың айналасында болып жатқан өзгерістерді және бұл көрсетілетін қызметтердің сапасына қалай әсер ететінін анықтауға болады. Сонымен қатар, желіге зондтарды өз бетінше орналастырудың қажеті жоқ, Роскомнадзор оларды орнатып қойған.
Тағы бір тоқталғым келетін мәселе, әрбір құрал қару бола алады. AS «Инспектор» жабық желі болып табылады, бірақ Агенттер тыйым салынған тізімнен барлық ресурстарға сұрау жіберу арқылы барлығын тапсырады. Мұндай ресурстың болуы ешқандай қиындық тудырмайды. Жалпы алғанда, агенттер арқылы провайдерлер өз желілері туралы ойланбастан көп айтады: DPI және DNS түрлері, Агенттің орналасқан жері (орталық түйін және қызмет көрсету желісі?), кешігулер мен жоғалтулардың желілік маркерлері - және бұл тек ең айқын. Біреу Агенттердің өз ресурстарының қолжетімділігін жақсарту бойынша әрекеттерін бақылай алатыны сияқты, біреу мұны басқа мақсаттар үшін жасай алады және бұған ешқандай кедергілер жоқ. Нәтиже - екі қырлы және өте көп қырлы құрал, мұны кез келген адам көре алады.
Ақпарат көзі: www.habr.com