Ի՞նչ է dns կեղծումը: Մենք պլագին ենք գրում Microsoft DNS սերվերի համար՝ IDN կեղծիքից պաշտպանվելու համար: Ազատ ծրագրային ապահովման վրա հիմնված համակարգերի պաշտպանություն
DNS կեղծումը DNS համակարգը խաբելու պարզ մեթոդ է, DNS անվան լուծման բլոկ՝ օգտագործելով կեղծ տեղեկատվություն, որը ստացվել է հոսթից, որը պատասխանատու չէ այդ տեղեկատվության համար: Յուրաքանչյուր DNS փաթեթ ունի 16-բիթանոց id համար, id համարը DNS փաթեթի այն մասն է, որը թույլ է տալիս նույնականացնել յուրաքանչյուր DNS փաթեթ, որն անցնում է 53 պորտով, և հարցումը կարող է կատարվել նաև մեկից ավելի անգամ: ID-ն տարբեր dns հարցումների միջև տարբերելու միակ միջոցն է և կապված է այն բանի հետ, թե ինչ են օգտագործում dns սերվերները՝ որոշելու համար, թե որն էր սկզբնական հարցումը: BIND-ի դեպքում այս թիվը յուրաքանչյուր հարցման համար ավելանում է 1 մակարդակով: TCP seq id-ի նման հարձակումը կարող է իրականացվել, թեև դա ավելի դժվար է: Նույնիսկ եթե BIND-ը չի կարող քեշավորել ձեր ուղարկած տեղեկատվությունը, այն կուղարկի պատասխանը սկզբնական հոսթին: Այն դեպքում, երբ ircd-ն PTR հարցում է կատարում՝ ի պատասխան դրան միացող հոսթի, պատասխանի փաթեթը կարող է ձևակերպվել այնպես, որ պարունակի Լրացուցիչ տեղեկություն, որտեղից ircd-ը կկատարի ներքին քեշավորում։ Այս գրոհը պահանջում է արմատային մուտք dns սերվերի վրա, որը պատասխանատու է dns տեղեկատվության in-addr. arpa բլոկի համար: Բացի այդ, ircd-ը կարող է քեշավորել միայն մեկ տիրույթ: Կա ևս մեկ հարձակում, քանի որ id-ը բաղկացած է 16 բիթից: Օգտագործողը կարող է անցնել ամբողջը: idspace: Ձեր dns-ը կեղծելու համար, ասենք DALNet"e-ում, դուք պետք է ուղարկեք 65000 գեներացված հարցումներ ns սերվերին, հենց որ համակարգիչը պատասխան ստանա հարցումին, դուք պետք է կարդացեք փաթեթը, և դրա մեջ գրվելու է ճիշտ id: ID-ն ստանալուն պես պետք է գտնել ցանկացած «փաթեթ»: ստեղծման գործիք DNS փաթեթ ստեղծելու համար: Մնում է միայն կեղծել DNS փաթեթները, ուղարկել դրանք ns. dal.net և ստանալ կեղծ TCP կապ:
Խնդրի ընդհանուր շարադրանքը Համացանցի արագ աճի հետ կապված՝ պաշտպանելու խնդիրը տեղեկատվական ռեսուրսներդառնում են ավելի կարևոր: Եթե դուք միացված եք ինտերնետին, ձեր համակարգը կարող է հարձակման ենթարկվել: Եկեք նայենք, թե ինչպես է աշխատում DNS-ը: Սեգմենտից դուրս հասցեավորումն իրականացվում է IP հասցեների միջոցով, սակայն սերվերների մուտքը սովորաբար իրականացվում է դոմենային անունների միջոցով: Այս առումով ստեղծվել է դոմենային անունները IP հասցեների փոխակերպելու (քարտեզագրման) համակարգ՝ DNS սերվերներ (Domain Name System): Այս համակարգը պատասխանատու է հեռավոր հոսթի IP հասցեն իր անունով գտնելու համար: DNS համակարգի գործառնական սկզբունքը հետևյալն է. հեռավոր հոսթը հատուկ հարցում է ուղարկում մոտակա DNS սերվերի IP հասցեին, որը նշում է սերվերի անունը, որի IP հասցեն պետք է գտնել: Հարցում ստանալուց հետո DNS սերվերը որոնում է իր տվյալների բազայում պահանջվող տիրույթի անվան առկայության համար: Եթե անունը գտնվի, DNS սերվերը պատասխան է տալիս՝ նշելով որոնված IP հասցեն: Եթե հարցումում նշված անունը չի գտնում DNS սերվերը իր անվան տվյալների բազայում, DNS հարցումը DNS սերվերի կողմից ուղարկվում է արմատային DNS սերվերներից մեկին, և այս պարբերությունում նկարագրված ընթացակարգը կրկնվում է մինչև անունը գտնվի: Եկեք դիտարկենք կեղծ DNS սերվերի աշխատանքի ընդհանուր սխեման. սպասել DNS հարցմանը; ստանալով DNS հարցում, դրանից հանելով անհրաժեշտ տեղեկատվություն և ցանցի միջոցով կեղծ DNS պատասխան փոխանցելով հարցում կատարող հոսթին իրական DNS սերվերի անունից (IP հասցեից), որը ցույց է տալիս կեղծ DNS սերվերի IP հասցեն: ; հոսթից փաթեթ ստանալու դեպքում, փաթեթի IP վերնագրում դրա IP հասցեն փոխելով կեղծ DNS սերվերի IP հասցեի և փաթեթը սերվերին փոխանցելու դեպքում (այսինքն՝ կեղծ DNS սերվերը աշխատում է սերվերի հետ. իր անունից); սերվերից փաթեթ ստանալու դեպքում, փաթեթի IP վերնագրում իր IP հասցեն փոխելով կեղծ DNS սերվերի IP հասցեով և փաթեթը փոխանցելով հոսթին (հոսթի համար կեղծ DNS սերվերը իրական սերվերն է. )
Անհրաժեշտ պայմանԱյս հարձակման տարբերակի իրականացումը DNS հարցման ընդհատումն է: Դա հնարավոր է միայն այն դեպքում, եթե հարձակվողը գտնվում է կամ հիմնական տրաֆիկի ճանապարհին կամ իրական DNS սերվերի հատվածում: Ցանցում հարձակվողի գտնվելու վայրի այս պայմաններից մեկի կատարումը դժվարացնում է նման հեռահար հարձակումը գործնականում (հարձակվողը, ամենայն հավանականությամբ, չի կարողանա մուտք գործել DNS սերվերի հատված, և առավել եւս՝ միջսեգմենտային հաղորդակցման ալիք։ ) Այնուամենայնիվ, եթե այս պայմանները կատարվեն, հնարավոր է ինտերնետում միջսեգմենտային հեռահար հարձակում իրականացնել: Այս հարձակման արդյունքը IP հասցեի և դոմենի անվան միջև պարտադրված համապատասխանության ներմուծումն է քեշի մեջ: DNS սերվերներ. Հաջող հարձակման արդյունքում հյուսիսում գտնվող բոլոր DNS օգտվողները սխալ տեղեկատվություն կստանան տիրույթի անունների և IP հասցեների մասին: Այս հարձակումը բնութագրվում է միևնույն տիրույթի անունով մեծ թվով DNS փաթեթներով: Դա պայմանավորված է DNS փոխանակման որոշ պարամետրեր ընտրելու անհրաժեշտությամբ:
Ինչպես ցույց է տալիս գոյություն ունեցող պաշտպանական տեխնիկայի վերլուծությունը, հարձակումներին կարելի է հակազդել օգտագործելով հետևյալ մեթոդները. DNS-ն անցնելով TCP-ին UDP-ից TCP տեղափոխումը որոշակիորեն կդանդաղեցնի համակարգը: TCP-ն օգտագործելիս անհրաժեշտ է ստեղծել վիրտուալ կապ, և հարկ է նաև հաշվի առնել, որ վերջնական ցանցի ՕՀ-ն նախ ուղարկում է DNS հարցում՝ օգտագործելով UDP արձանագրությունը, և եթե նրանք ստանում են հատուկ պատասխան DNS սերվերից, ապա ցանցային ՕՀ-ն։ կուղարկի DNS հարցում՝ օգտագործելով TCP: TCP արձանագրության օգտագործումը կդժվարացնի փաթեթների կեղծման հարձակումը, բայց կդանդաղեցնի գործողությունը: DNS տրաֆիկի վերլուծությամբ: Դուք կարող եք հակազդել հարձակումներին՝ վերլուծելով երթեւեկությունը: Կեղծ IP հասցեներով կեղծ փաթեթներ անընդհատ ուղարկվում են DNS սերվեր: Եթե ստացված կեղծ փաթեթը համապատասխանում է հարցումի արժեքներին, ապա կեղծ IP-ն ընդունվում է որպես ճշմարիտ: Եթե սերվերից որևէ փաթեթ չի գաղտնալսվում, ապա հարձակումը բնութագրվում է նույն անունով մեծ թվով DNS փաթեթներով: Դա պայմանավորված է DNS փոխանակման որոշ պարամետրեր ընտրելու անհրաժեշտությամբ: Վերլուծելով DNS տրաֆիկը, դուք կարող եք անտեսել նման փաթեթները՝ IP հասցեի կեղծումից խուսափելու համար:
Եզրակացություններ Ուսումնասիրելով DNS սերվերի աշխատանքը, դուք կարող եք դա տեսնել Ընթացիկ տարբերակըբավականին ոչ օպտիմալ է և խոցելի է հարձակումների համար տարբեր տեսակներ. Հարձակումներին կարելի է հակազդել՝ վերլուծելով DNS տրաֆիկը կամ DNS-ի գործարկումը UPD-ից TCP-ի փոխարկելով: Մեթոդներից ոչ մեկը լիարժեք պաշտպանություն չի ապահովում հարձակումներից, երկու մեթոդներն էլ միայն դժվարացնում են հարձակումը: Երկու մեթոդներն էլ պահանջում են լրացուցիչ ռեսուրսներ սերվերից: DNS սերվերի աշխատանքը TCP-ին փոխանցելու դեպքում սերվերների միջև փոխանակման ժամանակը նույնպես մեծանում է, քանի որ UDP արձանագրությունն ավելի արագ է, քան TCP արձանագրությունը: Վրա այս պահին, հակազդեցության առաջարկվող մոդելներն ամենաարդյունավետն են, և նպատակահարմար է օգտագործել դրանք համակցված՝ առավելագույն հնարավոր անվտանգության հասնելու համար։
DNS թունավորումը կամ DNS կեղծումը կիբերհարձակման տեսակ է, որն օգտագործում է համակարգի խոցելիությունը DNS սերվերում՝ օրինական սերվերներից երթևեկությունը կեղծ սերվերներին վերահղելու համար:
Ինչպես է աշխատում DNS թունավորումը կամ DNS կեղծումը
DNS քեշի թունավորման ծածկագիրը հաճախ հանդիպում է սպամ հաղորդագրություններում ուղարկված URL-ներում: Այս հաղորդագրություններում հարձակվողները փորձում են վախեցնել օգտատերերին և դրանով իսկ ստիպել նրանց սեղմել կցված հղման վրա, ինչը, իր հերթին, կվարակի նրանց համակարգիչը։ Բաններներ և պատկերներ, ինչպես ներդիրում էլ, իսկ կասկածելի կայքերում կարող են նաև վերահղել օգտատերերին այս կոդը: Վարակվելուց հետո համակարգիչները օգտատերերին կուղղորդեն կեղծ կայքեր, որոնք ընդօրինակում են բնօրինակ վեբ էջերը՝ այդպիսով ենթարկելով նրանց այնպիսի ռիսկերի, ինչպիսիք են վարակը: լրտեսող ծրագրեր, keyloggers կամ worms.
Ռիսկերը
DNS թունավորումն առաջացնում է տարբեր ռիսկեր՝ սկսած տվյալների գողությունից: Բանկերի և հանրաճանաչ առցանց խանութների կայքերը հեշտությամբ փոխարինվում են, ինչը նշանակում է, որ ցանկացած գաղտնաբառ ԿՐԵԴԻՏ քարտկամ անձնական տվյալները կարող են վտանգված լինել: Եվ եթե ՏՏ անվտանգության ծառայություններ մատուցողների կայքերը կեղծվեն, օգտատիրոջ համակարգիչը կարող է ենթարկվել լրացուցիչ ռիսկերի, ինչպիսիք են վիրուսներով կամ տրոյաններով վարակվելը, քանի որ անվտանգության համակարգերը օրինական թարմացումներ չեն ստանա: Վերջապես, DNS քեշի թունավորումը լուծելը շատ դժվար է, քանի որ վարակված սերվերի մաքրումը չի վերացնում խնդիրը, և վտանգված սերվերին միացող համակարգիչները մաքրելը կհանգեցնի նրանց նորից վարակվելու: Անհրաժեշտության դեպքում օգտվողները կարող են լուծել խնդիրը՝ մաքրելով իրենց DNS քեշը:
DNS-ի թունավորումը կանխելու համար օգտատերերը պետք է խուսափեն անհայտ հղումների վրա սեղմելուց և պարբերաբար ստուգեն իրենց համակարգիչը չարամիտ ծրագիր. Միշտ դա արեք՝ օգտագործելով ձեր համակարգչում տեղադրված ծրագիրը, և ոչ թե առցանց տարբերակը, որը նույնպես կարող է կեղծվել:
IDN-ի կեղծումը ընտրվածին «նման» տիրույթի անունների ստեղծումն է, որը սովորաբար օգտագործվում է օգտագործողին ստիպելու համար հետևել հարձակվողի ռեսուրսի հղմանը: Հաջորդը, եկեք նայենք հարձակման ավելի կոնկրետ տարբերակին:
Պատկերացնենք, որ հարձակման ենթարկված ընկերությանը պատկանում է organisation.org տիրույթը, և այս ընկերության ներսում օգտագործվում է portal.organization.org ներքին ռեսուրսը։ Հարձակվողի նպատակն է ստանալ օգտատիրոջ հավատարմագրերը, և դա անելու համար նա հղում է ուղարկում էլեկտրոնային փոստի կամ ընկերության կողմից օգտագործվող մեսենջերի միջոցով:
Նման հաղորդագրություն ստանալով՝ մեծ է հավանականությունը, որ չնկատեք, որ հղումը սխալ տեղ է տանում։ Հղման վրա սեղմելուց հետո կպահանջվի մուտք/գաղտնաբառ, և տուժողը, կարծելով, որ գտնվում է ներքին ռեսուրսի վրա, մուտքագրելու է իր տվյալները։ հաշիվ. Հարձակվողի շանսերը հատկապես մեծ են, եթե նա արդեն թափանցել է պարագիծ՝ վտանգելով ցանկացած աշխատակցի համակարգը և այժմ պայքարում է համակարգի ադմինիստրատորի արտոնությունների համար։
Այստեղ անհնար է բացարձակ «անխոհեմություն» գտնել, բայց դուք կարող եք փորձել կասեցնել այս հարձակումը անվան լուծման փուլում՝ DNS հարցման միջոցով:
Պաշտպանության համար մենք պետք է հաջորդաբար հիշենք այն անունները, որոնք հանդիպում են գաղտնալսված DNS հարցումներում: Ընկերությունն օգտագործում է իր ներքին ռեսուրսները, ինչը նշանակում է, որ մենք արագ կգտնենք այն portal.organization.org-ի հարցումով: Հենց որ մենք հանդիպենք նախկինում հանդիպածի «նման» անունին, մենք կարող ենք փոխարինել DNS պատասխանը՝ հարձակվողի IP հասցեի փոխարեն սխալ վերադարձնելով:
Ի՞նչ ալգորիթմներ կարող են լինել «նմանությունը» որոշելու համար:
- UTS39 Confusable Detection (http://www.unicode.org/reports/tr39/#Confusable_Detection) Unicode-ը ոչ միայն արժեքավոր խորհրդանիշների աղյուսակ է, այլև ստանդարտների և առաջարկությունների մի խումբ: UTS39-ը սահմանում է unicode տողերի նորմալացման ալգորիթմ, որի դեպքում տողերը, որոնք տարբերվում են հոմոգլիֆներով (օրինակ՝ ռուսերեն «a» և լատիներեն «a») կկրճատվեն նույն ձևով։
- Բառեր, որոնք տարբերվում են ներքին տառերի վերադասավորմամբ: Բավականին հեշտ է շփոթել organisation.org-ը և orgainzation.org-ը
- Առաջին մակարդակի տիրույթի փոխարինում: Անվան առաջին մակարդակը սովորաբար որևէ նշանակություն չունի, և «կազմակերպություն» տեսնելով ընկերության աշխատակիցը կարող է անտեսել .org կամ .net տարբերությունը, թեև այստեղ հնարավոր են բացառություններ։
Մեթոդաբանությունը հասկանալու համար անհրաժեշտ կլինի PE ձևաչափի իմացություն, ավելի մանրամասն կարող եք կարդալ, օրինակ. Գործարկվող ֆայլը բաղկացած է վերնագրերից, բաժինների աղյուսակից և հենց բաժիններից: Բաժիններն իրենք տվյալների բլոկ են, որոնք բեռնիչը պետք է հիշի հարաբերական հասցեով (Relative Virtual Address - RVA), և բոլոր ռեսուրսները, կոդը և այլ տվյալները պարունակվում են բաժիններում: Նաև վերնագրի ներսում կան հղումներ (RVA) դեպի մի շարք աղյուսակներ, որոնք անհրաժեշտ են հավելվածի աշխատանքի համար։ Այս հոդվածի նպատակների համար երկուսը կարևոր կլինեն՝ ներմուծման աղյուսակը և արտահանման աղյուսակը։ Ներմուծման աղյուսակը պարունակում է գործառույթների ցանկ, որոնք անհրաժեշտ են հավելվածի աշխատանքի համար, բայց գտնվում են այլ ֆայլերում: Արտահանման աղյուսակը «հետընթաց» աղյուսակ է, որը պարունակում է գործառույթների ցանկ, որոնք արտահանվում են այդ ֆայլից, կամ արտահանման վերահասցեավորման դեպքում՝ ֆայլի անվանումը և կախվածությունը լուծելու գործառույթի անվանումը:
Մենք կկատարենք dll-ի ներարկումն առանց ձանձրալի CreateRemoteThread-ի: Ես որոշեցի օգտագործել PE արտահանման վերահասցեավորում. սա վաղուց հայտնի տեխնիկա է, երբ ցանկալի գործընթացում բեռնելու համար գրացուցակում ստեղծվում է dll՝ exe ֆայլով, որի անունը հավասար է ներմուծման ցանկացած dll-ի անվանմանը: exe ֆայլի աղյուսակը (հիմնականը չօգտագործել HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\KnownDLLs): Ստեղծված dll-ում արտահանման աղյուսակը թիրախային dll-ից պատճենվում է, բայց արտահանվող ֆունկցիայի կոդի ցուցիչի փոխարեն պետք է գրել RVA առաջընթաց տողի վրա, ինչպիսին է «endpoint!sendto»: Microsoft dns սերվերն ինքնին ներդրված է որպես ծառայություն HKEY_LOCAL_MACHINE\System\CurrentControlSet\services\DNS, որը գտնվում է %systemroot%\system32\dns.exe-ում:
Վերջնական ներարկման ալգորիթմը DNS սերվերում կլինի հետևյալը.
- Ստեղծեք գրացուցակ %systemroot%\system32\dnsflt (ցանկացած այլ գրացուցակ հնարավոր է, անհրաժեշտ չէ տեղադրել գրացուցակը system32-ում):
- Պատճենեք %systemroot%\system32\dnsapi.dll այնտեղ - սա այն dll-ն է, որտեղից dns.exe-ն ինչ-որ բան ներմուծում է, կարող եք ընտրել ցանկացած այլ «անհայտ dll»:
- Վերանվանեք պատճենված dll-ը endpoint.dll-ի - մենք կօգտագործենք այս անունը առաջի տողում:
- Մենք վերցնում ենք մեր ներարկված dll-ը և ավելացնում ենք ճիշտ արտահանման աղյուսակը, պատճենում ենք մեր dll-ը %systemroot%\system32\dnsflt-ում:
- Ռեեստրի բանալի HKEY_LOCAL_MACHINE\System\CurrentControlSet\services\DNS փոխեք նոր երկուական հասցեն ImagePath %systemroot%\system32\dnsflt\dns.exe-ում:
- Ստեղծեք սիմհղում %systemroot%\system32\dnsflt\dns.exe-ից մինչև %systemroot%\system32\dns.exe
DllMain-ից գործընթացում բեռնելուց հետո կարող եք ստեղծել թեմա և ստեղծել ընդհատում: Ի շատ պարզ դեպքմեր dns ծառայությունը հաճախորդին կհայտնի անվան IP հասցեն՝ ուղարկելով UDP փաթեթ 53 նավահանգստից sendto ֆունկցիայի միջոցով ws2_32.dll-ից: Ստանդարտը ենթադրում է, որ TCP պորտը 53-ը կարող է օգտագործվել, եթե պատասխանը չափազանց մեծ է, և ակնհայտորեն, sendto-ի անջատումն այս դեպքում անօգուտ կլինի: Այնուամենայնիվ, tcp-ով գործը հնարավոր է կարգավորել նմանատիպ ձևով, չնայած այն ավելի աշխատատար է: Առայժմ ես ձեզ կասեմ UDP-ի ամենապարզ դեպքը: Այսպիսով, մենք գիտենք, որ dns.exe-ի կոդը կներմուծի sendto ֆունկցիան ws2_32.dll-ից և այն կօգտագործի DNS հարցումին պատասխանելու համար: Կան նաև բավականին շատ գործառույթներ, որոնք կարող են ընդհատել տարբեր ճանապարհներ, դասականը splicing-ն է, երբ իր ֆունկցիայի մեջ առաջին sendto հրահանգները փոխարինվում են jmp-ով, իսկ ավարտից հետո անցում է կատարվում նախկինում պահպանված sendto հրահանգներին և այնուհետև sendto ֆունկցիայի ներսում։ Splicing-ը կաշխատի նույնիսկ այն դեպքում, եթե GetProcAddress-ն օգտագործվում է sendto կանչելու համար, այլ ոչ թե ներմուծման աղյուսակ, բայց եթե օգտագործվում է ներմուծման աղյուսակ, ապա ավելի հեշտ է օգտագործել IAT կեռիկը միացման փոխարեն: Դա անելու համար դուք պետք է գտնեք ներմուծման աղյուսակը ներբեռնված dns.exe պատկերում: Աղյուսակն ինքնին ունի որոշակի շփոթեցնող կառուցվածք, և մանրամասների համար դուք պետք է գնաք PE ձևաչափի նկարագրությանը:
Հիմնական բանը այն է, որ պատկերը բեռնելու գործընթացում համակարգը ներմուծման աղյուսակում գրելու է ցուցիչ դեպի sendto ֆունկցիայի սկիզբը: Սա նշանակում է, որ sendto զանգը ընդհատելու համար պարզապես անհրաժեշտ է ներմուծման աղյուսակում սկզբնական sendto-ի հասցեն փոխարինել ձեր ֆունկցիայի հասցեով:
Այսպիսով, մենք ստեղծեցինք գաղտնալսում և սկսեցինք ստանալ տվյալներ: Sendto ֆունկցիայի նախատիպն ունի հետևյալ տեսքը.
Int sendto(_In_ SOCKET s, _In_ const char *buf, _In_ int len, _In_ int flags, _In_ const struct sockaddr *to, _In_ int tolen);
Եթե s-ը 53-րդ պորտի վարդակից է, ապա buf ցուցիչը կպարունակի dns-ի չափի len պատասխան: Ձևաչափն ինքնին նկարագրված է RFC1035-ում, ես համառոտ նկարագրելու եմ, թե ինչ է պետք անել, որպեսզի հասնենք հետաքրքրող տվյալներին:
Ստանդարտում հաղորդագրության կառուցվածքը նկարագրված է հետևյալ կերպ.
Վերնագրում սկսած անհրաժեշտ տեղեկատվությունհաղորդագրության տեսակը, սխալի կոդը և տարրերի քանակը բաժիններում: Վերնագիրն ինքնին այսպիսի տեսք ունի.
Կառուցվածք DNS_HEADER ( uint16_t id; // նույնականացման համարը uint8_t rd: 1; // ցանկալի ռեկուրսիա uint8_t tc: 1; // կրճատված հաղորդագրություն uint8_t aa: 1; // հեղինակավոր պատասխանի uint8_t օպերատիվ կոդը՝ 4; // qr: uint8_ հաղորդագրության նպատակը 1; // հարցում/պատասխանի դրոշ uint8_t կոդ՝ 4; // պատասխանի կոդը uint8_t cd՝ 1; // ստուգում է անջատված uint8_t գովազդը՝ 1; // վավերացված տվյալները uint8_t z: 1; // դրա z! վերապահված uint8_t ra: 1 ; // հասանելի ռեկուրսիա uint16_t q_count; // հարցերի մուտքերի քանակը uint16_t ans_count; // պատասխանների մուտքերի քանակը uint16_t auth_count; // հեղինակային մուտքերի քանակը uint16_t add_count; // ռեսուրսների մուտքերի քանակը );
Հարցերի բաժինը պետք է ապամոնտաժվի՝ պատասխանին հասնելու համար: Բաժինն ինքնին բաղկացած է վերնագրում նշված բլոկների քանակից (q_count): Յուրաքանչյուր բլոկ բաղկացած է անունից, տեսակից և հարցումների դասից: Անունը կոդավորված է որպես տողերի հաջորդականություն, որոնցից յուրաքանչյուրը սկսվում է տողի երկարությամբ բայտով: Վերջում կա զրոյական երկարությամբ շարան։ Օրինակ, homedomain2008.ru անունը կունենա հետևյալ տեսքը.
Պատասխաններ բաժինը նման տեսք ունի՝ բլոկը բաղկացած է անունից, տեսակից, դասից, ttl-ից և լրացուցիչ տվյալներից: IP հասցեն կպարունակվի հավելումում: տվյալները։ Մեկ այլ դժվարություն է առաջանում անունը վերլուծելիս. Ըստ երևույթին, հաղորդագրության չափը նվազեցնելու համար, պիտակի երկարության փոխարեն, կարող եք հղում գտնել տվյալների այլ տարածքի: Այն կոդավորվում է հետևյալ կերպ. եթե երկարության 2 ամենակարևոր բիթերը հավասար են 11-ի, ապա հաջորդ բայթը, ինչպես նաև երկարության ամենանվազ նշանակալի բիթերը, պետք է մեկնաբանվեն որպես բայթերով օֆսեթ՝ բայթերի սկզբի համեմատ։ հաղորդագրություն. Անվան հետագա վերլուծությունը պետք է կատարվի՝ անցնելով այս օֆսեթը:
Այսպիսով, մենք ընդհատել ենք անհրաժեշտ API-ն, վերլուծել ենք DNS-ի պատասխանը, այժմ մենք պետք է որոշում կայացնենք՝ հետագայում բաց թողնել այս պատասխանը կամ վերադարձնել սխալ: Յուրաքանչյուր անվան համար, որը դեռ չկա տվյալների բազայում, պատասխանից պետք է ստուգել՝ արդյոք այն «կասկածելի է», թե ոչ:
Մենք «կասկածելի» կհամարենք այն անունները, որոնց համար Unicode Technical Standard tr39-ի կմախքի ֆունկցիայի արդյունքը համընկնում է տվյալների շտեմարանի որևէ անունի արդյունքի հետ, կամ այն անունները, որոնք տարբերվում են տվյալների բազայում առկաներից՝ ներքին տառերը վերադասավորելով։ . Ստուգումներ իրականացնելու համար մենք կպահենք 2 աղյուսակ։ Առաջինը բաղկացած կլինի տվյալների բազայի բոլոր անունների կմախքի արդյունքներից, երկրորդ աղյուսակում մենք կգրենք տողերը, որոնք ստացվել են տվյալների շտեմարանի տողերից՝ յուրաքանչյուր պիտակից հեռացնելով առաջին և վերջին նիշը, բացառությամբ առաջին մակարդակի, իսկ հետո տեսակավորելով մնացածը։ յուրաքանչյուր պիտակի նիշերը: Հիմա, եթե երկու աղյուսակներից մեկում նոր անուն է ներառված, ապա մենք դա համարում ենք կասկածելի։
Կմախքի ֆունկցիայի նպատակն է որոշել երկու տողերի նմանությունը, դրա համար յուրաքանչյուր տողի համար նիշերը նորմալացվում են: Օրինակ, Xlœ-ը կվերածվի Xloe-ի, և այդպիսով, համեմատելով ֆունկցիայի արդյունքը, կարող եք որոշել unicode տողերի նմանությունը։
Վերոնշյալի իրականացման օրինակ կարելի է գտնել github-ում:
Ակնհայտ է, որ ուրվագծված լուծումը գործնականում չի կարող ապահովել նորմալ պաշտպանություն, քանի որ գաղտնալսման հետ կապված աննշան տեխնիկական խնդիրներից բացի, ավելի մեծ խնդիր կա «նման» անունների հայտնաբերման հետ կապված: Լավ կլիներ կարգավորել.
- Փոխակերպումների և հոմոգլիֆների համակցություններ.
- Կմախքի կողմից հաշվի չառնված նիշերի ավելացում/փոխարինում:
- UTS tr39-ը չի սահմանափակվում միայն կմախքով, դուք կարող եք նաև սահմանափակել նիշերի հավաքածուները մեկ պիտակի մեջ:
- Ճապոնական ամբողջ լայնությամբ կետ և այլ պիտակների բաժանարար:
- Եվ նաև այնպիսի հրաշալի բաներ, ինչպիսիք են
Գաղտնի տվյալներին կամ բանկային հաշիվներին հասանելիություն ստանալու համար ինչ-որ մեկին անձնավորելու մարտավարությունը հաջողությամբ կիրառվում է ոչ միայն իրական աշխարհում հանցագործների, այլև վիրտուալ տարածքում նրանց գործընկերների կողմից: Այս պրակտիկան կոչվում է խարդախություն. կոլեկտիվ կատեգորիա, որը ներառում է IP հասցեների կեղծման (վստահելի աղբյուրի IP հասցեի միջոցով հաղորդագրություններ համակարգիչներին ուղարկելու), էլփոստի կեղծման (ճշմարիտ ուղարկողին քողարկելու համար տառերի վերնագրի կեղծում) և DNS կեղծման հասկացությունները ( փոխելով DNS սերվերի կարգավորումները՝ դոմենի անունը հարձակվողների IP հասցեին վերահղելու համար):
Ինչպե՞ս է աշխատում խարդախությունը:
Խաբեբայությունը այլ անձին անձնավորելու մեթոդ է՝ ցանցին կամ կոնկրետ օգտագործողին խաբելու նպատակով՝ տեղեկատվության աղբյուրի հավաստիության նկատմամբ վստահություն սերմանելու նպատակով: Օրինակ, հաքերները, էլեկտրոնային փոստի կեղծման միջոցով, կարող են մոլորեցնել օգտվողին ուղարկողի ինքնության վերաբերյալ և մուտք ունենալ դեպի գաղտնի տվյալները: Կամ նրանք կարող են փորձել օգտագործել IP և DNS հարցումների կեղծման տեխնիկան՝ խաբելու օգտատիրոջ ցանցը և վերահղելու նրան խարդախ կայքեր, որոնք դիմակավորված են որպես իրական, ինչի արդյունքում օգտատիրոջ համակարգիչը վարակվում է:
Ինչպե՞ս ճանաչել կեղծիքը:
Էլփոստի կեղծումը ճանաչելու ամենադյուրին ճանապարհն այն է, որ ուղղակի թիրախը հենց օգտատերն է: Ցանկացած էլփոստի հաղորդագրություն Նամակը, որը օգտատիրոջից անձնական տեղեկություններ է խնդրում, կարող է խարդախության փորձ լինել, հատկապես, եթե այն պահանջում է հավատարմագրեր: Հիշեք, որ ոչ մի հեղինակավոր մասնավոր կամ պետական կազմակերպություն այս կերպ չի պահանջում անձնական տվյալներ: Ուշադրություն դարձրեք ուղարկողի հասցեին՝ համոզվելու համար, որ այն օրինական է: Այնուամենայնիվ, օգտատերը գրեթե երբեք չի իմանա, որ ինքը դարձել է IP կամ DNS խարդախության զոհ, չնայած մանրամասներին և կայքի սովորական վարքագծի փոփոխություններին մեծ ուշադրություն դարձնելու սովորությունը կարող է չափազանց օգտակար լինել: Եթե կայքը կամ նրա վարքագիծը ամենաչնչին կասկածի տեղիք է տալիս, ապա ավելի լավ է հրաժարվել պլանավորված գործողությունից՝ տվյալների պահպանման և պահպանման համար։ ֆինանսական ռեսուրսներապահովության մեջ։
Ինչպե՞ս վերացնել կեղծիքը:
Խաբեությունը ներառում է իրական աղբյուրի քողարկումը, ուստի այն այնքան էլ հեշտ չէ «վերացնել»։ Դուք կարող եք պաշտպանվել միայն առողջ բանականությանը հետևելով և դիտարկելով հիմնական կանոններըանվտանգ աշխատանք ցանցում, օրինակ՝ ոչ մի դեպքում չկիսելով ձեր անձնական տվյալները էլեկտրոնային փոստով: փոստ, նույնիսկ եթե ուղարկողի հեղինակությունը կասկածի տակ չէ:
Ինչպես կանխել կեղծիքը
- Մի պատասխանեք հաղորդագրություններին, որոնք խնդրում են ուղարկել ձեր անձնական կամ մուտքի տվյալները
- Ուշադիր ստուգեք ուղարկողի հասցեն
- Ուշադրություն դարձրեք տարօրինակ վարքագծին կամ ձեզ ծանոթ կայքերի մանրամասների տարբերություններին
Պաշտպանեք ձեզ կեղծիքից
Մի կողմից, խարդախությունից պաշտպանելը կարող է լինել նույնքան պարզ, որքան անվտանգ առցանց զննարկման հիմնական սկզբունքներին հետևելը: Այնուամենայնիվ, շատ ավելին կարող եք անել ձեր սեփական անվտանգությունն ապահովելու համար: Առաջին հերթին, դուք կարող եք վստահել ձեր ԱՀ-ի և դրա վրա պահվող տվյալների պաշտպանությանը հզոր հակավիրուսային լուծում, ինչպիսին է Avast-ի կողմից մշակված մեկը, որը հուսալիորեն պաշտպանում է խարդախ կայքերից և արգելափակում է վիրուսները, որոնք փորձում են ներթափանցել ձեր ցանց:
DNS կեղծում ( DNS կեղծում)
DNS համակարգ ( Դոմեյն Անվան Համակարգ) նորադարձներ Տիրույթի անունը(օրինակ՝ www.test.com) իր IP հասցեին (օրինակ՝ 192.168.0.1) և հակառակը: Այս հարձակումն օգտագործում է տեխնոլոգիա՝ զոհի DNS հարցումներին կեղծ պատասխաններ ուղարկելու համար: Հարձակումը հիմնված է երկու հիմնական մեթոդների վրա.
DNS ID-ի կեղծում
DNS արձանագրության փաթեթի վերնագիրը պարունակում է նույնականացման դաշտ, որը համապատասխանում է հարցումներին և պատասխաններին: DNS ID-ի կեղծման նպատակն է իր պատասխանն ուղարկել DNS հարցմանը, նախքան իրական DNS սերվերի պատասխանը: Դա անելու համար դուք պետք է գուշակեք հարցման ID-ն: Տեղայնորեն սա իրականացվում է պարզապես լսելով ցանցային տրաֆիկ. Այնուամենայնիվ, այս առաջադրանքը հեռակա կարգով կատարելը շատ ավելի դժվար է: Կան տարբեր մեթոդներ.
ստուգելով բոլոր առկա նույնականացման դաշտի արժեքները: Շատ գործնական չէ, քանի որ հնարավոր արժեքների ընդհանուր թիվը 65535 է (դաշտի չափը 16 բիթ);
ուղարկելով մի քանի հարյուր DNS հարցումներ ճիշտ հերթականությամբ: Ակնհայտ է, որ այս մեթոդը այնքան էլ հուսալի չէ.
գտնելով սերվեր, որը առաջացնում է կանխատեսելի նույնացուցիչներ (օրինակ՝ 1-ով ավելանալով): Այս տեսակի խոցելիությունը բնորոշ է Bind և-ի որոշ տարբերակներին Windows համակարգեր 9x.
Ամեն դեպքում անհրաժեշտ է արձագանքել իրական DNS սերվերին։ Դրան կարելի է հասնել, օրինակ, սերվերի դեմ ծառայության մերժման հարձակման միջոցով:
Հաջող հարձակում իրականացնելու համար հարձակվողը պետք է վերահսկի DNS սերվերը (ns.attaquant.com), որը հեղինակավոր է attaquant.com գոտու համար: Թիրախային DNS սերվերը (ns.cible.com) պետք է ստեղծի կանխատեսված նույնականացման համարները(յուրաքանչյուր խնդրանքով ավելանալով 1-ով):
Հարձակումը պահանջում է չորս քայլ.
Արդյունքում, թիրախային DNS սերվերի քեշը կպարունակի հարձակվողին անհրաժեշտ համընկնում, իսկ www.spoofed.com հասցեն պահանջող հաջորդ հաճախորդներին կտրվի հարձակվողի մեքենայի հասցեն: Այն կարող է տեղակայել իրական կայքի պատճենը, որի օգնությամբ հարձակվողը կարող է գողանալ գաղտնի տեղեկատվություն։
DNS Cache Poisoning-ի փոփոխություն
DNS սերվերները օգտագործում են քեշ՝ ժամանակի ընթացքում նախորդ հարցումների արդյունքները պահելու համար: Դա արվում է համապատասխան տիրույթների լիազորված սերվերներին հարցումների անընդհատ կրկնությունից խուսափելու համար։ DNS-ի կեղծմանն ուղղված հարձակման երկրորդ տեսակը DNS սերվերի քեշի փոփոխությունն է: Ահա մի օրինակ.
Մենք օգտագործում ենք նույն տվյալները, ինչ նախորդ օրինակում: Ահա այս հարձակման տարբերակի հիմնական կետերը.
ուղարկել DNS հարցում՝ www.attaquant.com անունը լուծելու համար cible.com տիրույթի DNS սերվերին.
թիրախային DNS սերվերը www.attaquant.com անունը լուծելու հարցում է ուղարկում հարձակվողի DNS սերվերին.
