Գաղտնիք չէ, որ Ռուսաստանում արգելված տեղեկատվության ցանկում արգելափակման վերահսկումը վերահսկվում է «Տեսուչ» ավտոմատացված համակարգի կողմից: Ինչպես է այն աշխատում, լավ գրված է այստեղ՝ սրա մեջ , նկար նույն վայրից.
Տեղադրվել է անմիջապես մատակարարի մոտ :
«Գործակալ տեսուչ» մոդուլը «Տեսուչ» (AS «Տեսուչ») ավտոմատացված համակարգի կառուցվածքային տարր է: Այս համակարգը նախատեսված է հեռահաղորդակցության օպերատորների կողմից մուտքի սահմանափակման պահանջներին համապատասխանությունը վերահսկելու համար՝ 15.1 թվականի հուլիսի 15.4-ի թիվ 27-FZ «Տեղեկատվության, տեղեկատվական տեխնոլոգիաների և տեղեկատվության պաշտպանության մասին» Դաշնային օրենքի 2006-149 հոդվածներով սահմանված դրույթների շրջանակներում: »
AS «Revizor» ստեղծելու հիմնական նպատակն է ապահովել հեռահաղորդակցության օպերատորների համապատասխանության մոնիտորինգը «Տեղեկատվության, տեղեկատվական տեխնոլոգիաների և տեղեկատվության պաշտպանության մասին» 15.1 թվականի հուլիսի 15.4-ի թիվ 27-FZ Դաշնային օրենքի 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 արգելափակման տիպով՝ հեշտացնելու զտիչ համակարգի աշխատանքը, որը գերադասելի է վաղուց լքված, որպեսզի նվազագույնի հասցվի կողմնակի տրաֆիկի մուտքը, բացառությամբ Գործակալների: Պարզվեց, որ այս առաջադրանքն ամենևին էլ դժվար չէր, արգելված տեղեկատվության ռեեստրում և ամեն ճաշակի համար կան բավականին շատ անվճար տիրույթներ։ Հետևաբար, տիրույթը գնվել և կապվել է 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 հասցե մեկ ՀԾ-ի համար՝ 1 միջինով: Ամեն ՀՍ հասցեներ՝ 288, 77, 66, 39, 27: Նմուշի առավելագույնը 95%-ը 4 հասցե է մեկ ՀԾ-ում: Այստեղ միջինը ակնկալվում է` մեկ մատակարարի համար մեկ Գործակալ: Մենք նաև գագաթն ենք ակնկալում. նրա մեջ մեծ խաղացողներ կան: Մեծ ցանցում Գործակալները հավանաբար պետք է տեղակայվեն օպերատորի ներկայության յուրաքանչյուր տարածաշրջանում և մի մոռացեք NAT-ի մասին: Եթե վերցնենք ըստ երկրների, ապա առավելագույնները կլինեն՝ 1409 - RU, 42 - UA, 23 - CZ, 36 այլ մարզերից, ոչ թե RIPE NCC: Ուշադրություն են գրավում Ռուսաստանից դուրս եկած հարցումները։ Սա, հավանաբար, կարելի է բացատրել աշխարհագրական տեղաբաշխման սխալներով կամ տվյալների լրացման ժամանակ գրանցման սխալներով: Կամ այն, որ ռուսական ընկերությունը կարող է չունենալ ռուսական արմատներ, կամ ունենալ արտասահմանյան ներկայացուցչություն, քանի որ դա ավելի հեշտ է, ինչը բնական է, երբ գործ ունենք օտարերկրյա RIPE NCC կազմակերպության հետ։ Ինչ-որ մաս, անկասկած, ավելորդ է, բայց հուսալիորեն դժվար է այն առանձնացնել, քանի որ ռեսուրսը արգելափակված է, իսկ երկրորդ օրվանից՝ կրկնակի արգելափակման տակ, և նիստերի մեծ մասը ընդամենը մի քանի ծառայությունների փաթեթների փոխանակում է: Համաձայնենք, որ սա փոքր մասն է։
Այս թվերն արդեն կարելի է համեմատել Ռուսաստանում պրովայդերների թվի հետ։ «Տվյալների փոխանցման կապի ծառայություններ, բացառությամբ ձայնի» լիցենզիաներ - 6387, բայց սա շատ բարձր գնահատական է վերևից, այս լիցենզիաներից ոչ բոլորն են վերաբերում հատուկ ինտերնետ պրովայդերներին, ովքեր պետք է տեղադրեն Գործակալ: RIPE NCC գոտում կա Ռուսաստանում գրանցված նմանատիպ թվով ԱՍ-ներ՝ 6230, որոնցից ոչ բոլորն են պրովայդեր։ և 3940 թվականին ստացել է 2017 ընկերություն, և սա ավելի շուտ գնահատական է վերևից։ Ամեն դեպքում մենք ունենք երկուսուկես անգամ ավելի քիչ թվով լուսավորված ԱՍ-ներ։ Բայց այստեղ արժե հասկանալ, որ 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-ի համար. Միգուցե սա սովորական պրակտիկա է: Վերջում RKN-ն ռեսուրսը ջնջելու հարցում ուղարկում է հոսթերին։ Բայց դա ինձ չզարմացրեց և որոշ առումներով նույնիսկ ի օգուտ ինձ աշխատեց: Զտիչը շատ արդյունավետ էր աշխատում՝ կտրելով բոլոր ճիշտ HTTP հարցումները դեպի արգելված URL, բայց ոչ ճիշտները, որոնք նախկինում անցել էին մատակարարների ֆիլտրով, հասել էին նրանց, թեև միայն վերջավորությունների տեսքով. FIN-ACK и RST - մինուս մինուսի դիմաց, և դա գրեթե պլյուս էր: Ի դեպ, IPv6-ը չի զտվել հոսթերի կողմից։ Իհարկե, դա ազդեց հավաքված նյութի որակի վրա, բայց այնուամենայնիվ հնարավորություն տվեց տեսնել հաճախականությունը։ Պարզվեց, որ սա կարևոր կետ է ռեսուրսների տեղադրման համար կայք ընտրելիս, մի մոռացեք հետաքրքրվել արգելված կայքերի ցանկի և RKN-ի հարցումների հետ աշխատանքի կազմակերպման հարցով:
Սկզբում ՀԾ «Տեսուչին» համեմատեցի . Այս համեմատությունը միանգամայն արդարացված է, և Գործակալների մեծ ցանցը կարող է շահավետ լինել: Օրինակ՝ երկրի տարբեր մասերում տարբեր մատակարարներից ռեսուրսների հասանելիության որակի որոշումը: Դուք կարող եք հաշվարկել ուշացումները, կարող եք կառուցել գրաֆիկներ, կարող եք վերլուծել այդ ամենը և տեսնել փոփոխությունները, որոնք տեղի են ունենում ինչպես տեղական, այնպես էլ գլոբալ մակարդակում: Սա ամենաուղիղ ճանապարհը չէ, բայց աստղագետներն օգտագործում են «ստանդարտ մոմեր», ինչո՞ւ չօգտագործել գործակալները: Իմանալով (գտնելով) նրանց ստանդարտ վարքագիծը, դուք կարող եք որոշել, թե ինչ փոփոխություններ են տեղի ունենում նրանց շուրջ և ինչպես է դա ազդում մատուցվող ծառայությունների որակի վրա: Եվ միևնույն ժամանակ, ձեզ հարկավոր չէ ինքնուրույն զոնդեր տեղադրել ցանցում, Ռոսկոմնադզորն արդեն տեղադրել է դրանք:
Մեկ այլ կետ, որին ուզում եմ անդրադառնալ, այն է, որ յուրաքանչյուր գործիք կարող է զենք լինել: ՀԾ «Տեսուչը» փակ ցանց է, բայց գործակալները հանձնում են բոլորին՝ ուղարկելով արգելված ցուցակից բոլոր ռեսուրսների հարցումները: Նման ռեսուրս ունենալն ընդհանրապես որևէ խնդիր չի ներկայացնում։ Ընդհանուր առմամբ, գործակալների միջոցով պրովայդերները, ակամա, շատ ավելին են պատմում իրենց ցանցի մասին, քան, հավանաբար, արժե այն. միայն ամենաակնհայտը. Ինչպես ինչ-որ մեկը կարող է վերահսկել Գործակալների գործողությունները՝ բարելավելու իրենց ռեսուրսների հասանելիությունը, ինչ-որ մեկը կարող է դա անել այլ նպատակների համար, և դրա համար որևէ խոչընդոտ չկա: Արդյունքը երկսայրի և շատ բազմակողմ գործիք է, սա կարող է տեսնել բոլորը:
Source: www.habr.com