Ez da sekretua Errusian debekatutako informazioaren zerrendan blokeatzeko kontrola "Inspector" sistema automatizatuak kontrolatzen duela. Nola funtzionatzen duen ondo idatzita dago hemen honetan , leku bereko argazkia:
Hornitzailean zuzenean instalatuta :
"Agente Inspector" modulua "Inspector" sistema automatizatuaren egitura-elementu bat da (AS "Inspector"). Sistema hau telekomunikazio-operadoreek sarbide-murrizketa-eskakizunak betetzen dituztela kontrolatzeko diseinatuta dago 15.1ko uztailaren 15.4ko 27-FZ Lege Federalaren 2006-149 artikuluek ezarritako xedapenen esparruan, “Informazioari, Informazioaren Teknologiei eta Informazioaren Babesari buruzkoa. ”
AS "Revizor" sortzearen helburu nagusia telekomunikazio-operadoreek 15.1ko uztailaren 15.4ko 27-FZ Lege Federalaren 2006-149 artikuluek ezarritako eskakizunak betetzen dituzten kontrolatzea da. " debekatutako informaziorako sarbidearen gertakariak identifikatzeari eta debekatutako informaziorako sarbidea murrizteko urratzeei buruzko euskarri-materialak (datuak) lortzeari dagokionez.
Kontuan izanda, denek ez bada, hornitzaile askok gailu hau instalatu dutela, baliza-zunda sare handi bat egon beharko litzateke, esaterako. eta are gehiago, baina sarbide itxiarekin. Hala ere, baliza norabide guztietan seinaleak bidaltzeko baliza bat da, baina harrapatzen baditugu eta ikusten badugu zer eta zenbat?
Kontatu aurretik, ikus dezagun zergatik izan daitekeen hori posible.
Teoria apur bat
Agenteek baliabide baten erabilgarritasuna egiaztatzen dute, HTTP(S) eskaeren bidez barne, adibidez:
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"
Karga erabilgarriaz gain, eskaerak konexioa ezartzeko fase bat ere osatzen du: trukea SYN и SYN-ACK, eta konexioa amaitzeko faseak: FIN-ACK.
Debekatutako informazioaren erregistroak hainbat blokeo mota ditu. Jakina, baliabide bat IP helbideak edo domeinu-izenak blokeatzen badu, ez dugu eskaerarik ikusiko. Hauek dira blokeo mota suntsitzaileenak, IP helbide bakarreko baliabide guztiak edo domeinu bateko informazio guztia eskuragarri ez izatea eragiten dutenak. "URL bidez" blokeo mota bat ere badago. Kasu honetan, iragazketa-sistemak HTTP eskaeraren goiburua analizatu behar du blokeatu beharrekoa zehazki zehazteko. Eta aurretik, goian ikus daitekeen bezala, konexioa ezartzeko fase bat egon beharko litzateke, jarraipena egiten saia zaitezke, ziurrenik iragazkiak galdu egingo duelako.
Horretarako, doako domeinu egoki bat hautatu behar duzu "URL" eta HTTP blokeo motarekin, iragazketa-sistemaren lana errazteko, ahal dela luzaroan utzitakoa, Agenteetatik izan ezik kanpoko trafikoaren sarrera minimizatzeko. Zeregin hau ez zen batere zaila izan; debekatutako informazioaren erregistroan doako domeinu asko daude eta gustu guztietarako. Hori dela eta, domeinua exekutatzen ari den VPS batean IP helbideetara erosi eta lotu zen tcpdump eta zenbaketa hasi zen.
"Auditoreen" auditoretza
Aldizkako eskaeren eztanda ikustea espero nuen, nire ustez ekintza kontrolatua adieraziko lukeena. Ezinezkoa da esan ez dudala batere ikusi, baina zalantzarik gabe ez zegoen argazki argirik:
Ez da harritzekoa, inork behar ez duen domeinu batean eta inoiz erabili gabeko IP batean ere, eskatu gabeko informazio mordoa egongo da, hala nola Internet modernoa. Baina, zorionez, URL zehatz baterako eskaerak baino ez nituen behar, beraz, eskaner eta pasahitz-cracker guztiak azkar aurkitu ziren. Gainera, nahiko erraza zen uholdea non zegoen antzeko eskaeren masan oinarrituta ulertzea. Ondoren, IP helbideen maiztasuna bildu eta goiko osoa eskuz pasatu nuen, aurreko etapetan galdu zutenak bereiziz. Gainera, pakete batean bidalitako iturri guztiak moztu nituen, jada ez zeuden asko. Eta hauxe gertatu zen:
Digresio liriko txiki bat. Egun bat geroago, nire ostalaritza-hornitzaileak gutun bat bidali zuen eduki nahiko errazarekin, zure instalazioek RKN debekatutako zerrendako baliabide bat dutela esanez, beraz, blokeatuta dagoela. Hasieran nire kontua blokeatuta zegoela pentsatu nuen, ez zen horrela. Orduan pentsatu nuen lehendik nekien zerbaiti buruz abisatzen zidatela besterik gabe. Baina konturatu zen ostalariak bere iragazkia piztu zuela nire domeinuaren aurrean eta, ondorioz, iragazketa bikoitzarekin etorri nintzen: hornitzaileetatik eta ostalaritik. Iragazkiak eskaeren amaierak baino ez ditu gainditu: FIN-ACK и RST HTTP guztiak debekatutako URL batean moztuz. Goiko grafikoan ikusten denez, lehen egunaren ondoren datu gutxiago jasotzen hasi nintzen, baina hala ere jaso nuen, nahikoa zen eskaera iturriak zenbatzeko zereginerako.
Lortu puntura. Nire ustez, bi eztanda ikusten dira egunero, lehenengoa txikiagoa, Moskuko gauerdia pasa ondoren, bigarrena 6:12etatik gertuago buztanarekin XNUMX:XNUMXak arte. Gailurra ez da aldi berean gertatzen. Hasieran, aldi hauetan bakarrik eta bakoitza aldi guztietan jaitsi ziren IP helbideak hautatu nahi nituen, Agenteen egiaztapenak aldian-aldian egiten direla kontuan hartuta. Baina arretaz aztertu ondoren, azkar aurkitu nituen beste tarte batzuetan erortzen ziren aldiak, beste maiztasun batzuekin, orduro eskaera bat arte. Orduan pentsatu nuen ordu-eremuei buruz eta agian haiekin zerikusirik izan zuela, gero pentsatu nuen orokorrean sistema globalki sinkronizatuta ez zegoela. Horrez gain, NATek papera izango du ziurrenik eta Agente berak IP publiko ezberdinetatik eskaerak egin ditzake.
Nire hasierako helburua zehatza ez zenez, aste batean topatu nituen helbide guztiak zenbatu eta lortu nuen - 2791. Helbide batetik ezarritako TCP saio kopurua batez beste 4 da, 2ko mediana batekin. Helbide bakoitzeko saio nagusiak: 464, 231, 149, 83, 77. Laginaren % 95etik gehienez 8 saio dira helbide bakoitzeko. Mediana ez da oso altua, gogorarazten dizut grafikoak eguneroko aldizkakotasun argia erakusten duela, beraz, 4 eta 8 inguruko zerbait espero liteke 7 egunetan. Behin gertatzen diren saio guztiak botatzen baditugu, 5eko mediana lortuko dugu. Baina ezin izan ditut baztertu irizpide argi baten arabera. Aitzitik, ausazko egiaztapen batek erakutsi zuen debekatutako baliabide baten eskaerarekin zerikusia zutela.
Helbideak helbideak dira, baina Interneten, sistema autonomoak - AS, garrantzitsuagoak izan zirenak 1510, batez beste 2 helbide AS bakoitzeko mediana 1. Helbide nagusiak AS bakoitzeko: 288, 77, 66, 39, 27. Laginaren % 95 gehienez 4 helbide AS bakoitzeko. Hemen mediana espero da - hornitzaile bakoitzeko Agente bat. Goiena ere espero dugu: jokalari handiak daude bertan. Sare handi batean, Agenteak operadorearen presentziaren eskualde bakoitzean kokatu beharko lirateke ziurrenik, eta ez ahaztu NATaz. Herrialdeka hartzen badugu, maximoak hauek izango dira: 1409 - RU, 42 - UA, 23 - CZ, 36 beste eskualdeetakoak, ez RIPE NCC. Errusia kanpoko eskaerek arreta erakartzen dute. Hori ziurrenik geokokapen akatsen edo erregistratzaileen akatsen bidez azal daiteke datuak betetzean. Edo Errusiako enpresa batek errusiar sustraiak ez izatea, edo atzerriko ordezkaritza bulego bat izatea errazagoa delako, hori naturala da RIPE NCC atzerriko erakunde batekin aritzean. Zati batzuk soberan daude, dudarik gabe, baina fidagarriki zaila da bereiztea, baliabidea blokeatuta baitago, eta bigarren egunetik blokeo bikoitzarekin, eta saio gehienak hainbat zerbitzu-paketeren trukea besterik ez dira. Ados gaitezen hau zati txiki bat dela.
Zenbaki hauek Errusiako hornitzaileen kopuruarekin alderatu daitezke dagoeneko. "Datu-transmisiorako komunikazio zerbitzuak, ahotsa kenduta" lizentziak - 6387, baina hau oso estimazio altua da, lizentzia hauek guztiak ez zaizkie aplikatzen Agente bat instalatu behar duten Interneteko hornitzaileei bereziki. RIPE NCC eremuan Errusian erregistratutako ASen antzeko kopuru bat dago - 6230, eta horietatik guztiak ez dira hornitzaileak. eta 3940 enpresa jaso zituen 2017an, eta hau goitik datorren estimazio bat da. Nolanahi ere, bi aldiz eta erdi gutxiago dugu argiztatutako AS kopurua. Baina hemen merezi du ulertzea AS ez dela hornitzailearen zorrozki berdina. Hornitzaile batzuek ez dute beren AS, beste batzuek bat baino gehiago. Guztiek oraindik Agenteak dituztela suposatzen badugu, norbaitek besteek baino indartsuago iragazten dute, bere eskaerak zaborretatik bereizi ez daitezen, haiengana iristen bada. Baina balorazio zakarra egiteko nahiko onargarria da, nire gainbegiratzeagatik zerbait galdu bazen ere.
DPIri buruz
Nire ostalaritza-hornitzaileak bere iragazkia bigarren egunetik hasita aktibatu zuen arren, lehenengo eguneko informazioaren arabera blokeoak arrakastaz funtzionatzen duela ondoriozta dezakegu. 4 iturri baino ez ziren lortu eta HTTP eta TCP saioak guztiz osatu zituzten (goiko adibidean bezala). Beste 460 bidal daitezke GET, baina saioa berehala amaituko da RST. arreta jarri 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"
Honen aldaerak desberdinak izan daitezke: gutxiago RST edo birtransmisio gehiago - iragazkiak iturburu-nodora bidaltzen duenaren araberakoa ere bada. Nolanahi ere, horixe da txantiloirik fidagarriena, eta hortik argi dago eskatutako baliabide debekatua zela. Gainera beti dago saioan agertzen den erantzuna TTL aurreko eta ondorengo paketeetan baino handiagoa.
Gainontzekoetatik ere ezin duzu ikusi 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"
Edo, beraz:
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"
...
Zalantzarik gabe, aldea ikusten da TTL iragazkitik zerbait ateratzen bada. Baina askotan ez da ezer iristen:
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"
...
Edo, beraz:
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"
...
Eta hori guztia errepikatu eta errepikatu eta errepikatzen da, grafikoan ikus daitekeen bezala, behin baino gehiagotan, egunero.
IPv6ri buruz
Albiste ona da existitzen dela. Era fidagarrian esan dezaket debekatutako baliabide bati egindako aldizkako eskaerak 5 IPv6 helbide ezberdinetatik gertatzen direla, horixe da nik espero nuen Agenteen portaera. Gainera, IPv6 helbideetako bat ez da iragazketan sartzen eta saio osoa ikusten dut. Beste bitan amaitu gabeko saio bakarra ikusi nuen, eta horietako bat eten zuen RST iragazkitik, denboran bigarrena. Kopuru osoa 7.
Helbide gutxi daudenez, denak zehatz-mehatz aztertu ditut eta hor 3 hornitzaile baino ez daudela ikusi da, txalo zaparrada eman diezaiekete! Beste helbide bat Errusian hodeiko hostinga da (ez du iragazten), beste bat Alemaniako ikerketa zentro bat da (iragazkia dago, non?). Baina zergatik egiaztatzen duten debekatutako baliabideen erabilgarritasuna ordutegi batean galdera ona da. Gainerako biek eskaera bat egin zuten eta Errusiatik kanpo daude, eta horietako bat iragazten da (garraioan, azken finean?).
Blokeoak eta Agenteak oztopo handia dira IPv6rentzat, eta horren ezarpena ez da oso azkar mugitzen. Tristea da. Arazo hau konpondu zutenak guztiz harro egon daitezke bere buruaz.
Ondorioz
Ez nintzen %100eko zehaztasuna lortzeko ahaleginik egin, mesedez barka iezadazu hau, espero dut norbaitek lan hau zehaztasun handiagoz errepikatu nahi izatea. Garrantzitsua zen niretzat ulertzea planteamendu honek printzipioz funtzionatuko zuen ala ez. Erantzuna baiezkoa da. Lehen hurbilketa gisa, lortutako zifrak, nire ustez, nahiko fidagarriak dira.
Zer gehiago egin zitekeen eta alferegi egin nuena DNS eskaerak zenbatzea zen. Ez dira iragazten, baina ez dute zehaztasun handirik ematen, domeinurako soilik funtzionatzen baitute, eta ez URL osorako. Maiztasuna ikusgai egon behar da. Kontsultetan zuzenean ikusten denarekin konbinatzen baduzu, beharrezkoak ez direnak bereizteko eta informazio gehiago lortzeko aukera emango dizu. Hornitzaileek eta askoz gehiago erabiltzen dituzten DNS garatzaileak ere zehaztu daitezke.
Ez nuen espero ostalariak nire VPSrako bere iragazkia ere sartuko zuenik. Agian hau ohiko praktika da. Azkenean, RKN-k baliabidea ezabatzeko eskaera bidaltzen dio ostalariari. Baina honek ez ninduen harritu eta nolabait nire onurarako ere lan egin zuen. Iragazkiak oso eraginkortasunez funtzionatu zuen, debekatutako URL baterako HTTP eskaera zuzen guztiak moztu zituen, baina aurretik hornitzaileen iragazkitik igarotako zuzenak ez ziren iristen, amaiera moduan bakarrik bada ere: FIN-ACK и RST - Minus minus eta ia plus bat izan zen. Bide batez, IPv6 ez zuen ostalariak iragazi. Noski, horrek bildutako materialaren kalitatean eragina izan zuen, baina hala ere maiztasuna ikusteko aukera ematen zuen. Baliabideak jartzeko gune bat aukeratzerakoan puntu garrantzitsua dela ikusi zen; ez ahaztu lana antolatzeko gaian interesa hartzea debekaturiko guneen zerrendarekin eta RKNren eskaerekin.
Hasieran, AS "Inspector"-ekin alderatu nuen . Konparaketa hau nahiko justifikatuta dago eta Agente sare handi bat onuragarria izan daiteke. Adibidez, herrialdeko toki ezberdinetako hornitzaile ezberdinen baliabideen erabilgarritasunaren kalitatea zehaztea. Atzerapenak kalkula ditzakezu, grafikoak eraiki ditzakezu, dena aztertu eta tokian tokiko zein mundu mailan gertatzen diren aldaketak ikus ditzakezu. Hau ez da biderik zuzenena, baina astronomoek "kandela estandarrak" erabiltzen dituzte, zergatik ez Agenteak erabiltzen? Haien portaera estandarra ezagututa (aurkitu ondoren), haien inguruan gertatzen diren aldaketak eta horrek emandako zerbitzuen kalitatean nola eragiten duen zehaztu dezakezu. Eta, aldi berean, ez duzu sarean zundak modu independentean jarri behar; Roskomnadzorrek dagoeneko instalatu ditu.
Ukitu nahi dudan beste puntu bat tresna bakoitza arma izan daitekeela da. AS "Inspector" sare itxia da, baina Agenteek denak entregatzen dituzte debekatutako zerrendako baliabide guztien eskaerak bidaliz. Horrelako baliabide bat edukitzeak ez du inolako arazorik sortzen. Guztira, Agenteen bidez hornitzaileek, nahi gabe, merezi dutena baino askoz gehiago kontatzen dute beren sareari buruz: DPI eta DNS motak, Agentearen kokapena (nodo zentrala eta zerbitzu-sarea?), atzerapenen eta galeren sare-markatzaileak, eta hau da. agerikoena baino ez. Norbaitek bere baliabideen erabilgarritasuna hobetzeko Agenteen ekintzen jarraipena egin dezakeen bezala, norbaitek beste helburu batzuetarako egin dezake eta horretarako ez dago oztoporik. Emaitza aho biko eta oso polifazetikoa den tresna da, edonork ikus dezake hori.
Iturria: www.habr.com