Odoo 19 Community. Web RBL – արգելափակման ցուցակ սեփական կայքերի վրա հարձակման տրաֆիկի դեմ

Սկզբնական կոդ. github.com/Alex0176/odoo-web-rbl — AGPL-3, ազատ օգտագործման համար։

Ով Odoo սերվեր է շահագործում ինտերնետում, այցելուներ է ստանում։ Ոչ պարբերաբար, այլ անընդհատ։ Տասնյոթ օրվա ընթացքում մենք մեր հինգ կայքերում գրանցել և վերլուծել ենք 731 297 հարցում։ Դրանցից 110 511-ը այցելուներ չէին, այլ խոցելիությունների, մուտքի տվյալների և կոնֆիգուրացիայի ֆայլերի ավտոմատացված որոնում։

Այս հոդվածը նկարագրում է Web RBL-ը՝ Odoo 19 Community-ի համար բաց կոդով մոդուլ, որը հայտնաբերում, գնահատում, գրանցում և մերժում է այս տրաֆիկը և որը արգելափակման ցուցակը հրապարակում է որպես RBL ցուցակ՝ այսինքն այն ձևաչափով, որը firewall-ները և reverse proxy-ները ուղղակիորեն կարդում են։ Բոլոր թվերը վերցված են իրական շահագործումից։

Ինչ կարող է անել մոդուլը — գործառույթները մի հայացքով

Ֆունկցիա	Ինչ է անում	Մատակարարում
Ձևանմուշների հայտնաբերում	Հայտնաբերում է զոնդավորումները ըստ ուղու և վերջավորության՝ .env, .git, կոնֆիգուրացիայի ֆայլեր, cloud բանալիներ, CI/CD կառուցման հրահանգներ, WordPress, PHP, Path Traversal, տվյալների բազայի կառավարիչ, GraphQL, հրամանի կատարում /api/fs/exec-ի և նմանատիպ ինտերֆեյսների միջոցով	արգելափակել
Երեք մակարդակ յուրաքանչյուր ձևանմուշի համար	արգելափակել, հաշվել կամ զեկուցել — փոխարկելի յուրաքանչյուր ձևանմուշի համար՝ առանց կոդի	ըստ ձևանմուշի
Շեմեր	Նույն ձևանմուշի այսքան համընկնում՝ մինչև արգելափակումը. մուտքի համար՝ տասը	10՝ մուտքի դեպքում
Մուտքի պաշտպանություն	Ձախողված մուտքեր մուտքի ձևի և XML-RPC/JSON-RPC-ի միջոցով, ձախողված սեսիայի ստուգումներ, մուտքեր տվյալների բազայի կառավարիչ — տվյալների բազայում, ոչ թե օպերատիվ հիշողության մեջ	միացված
Բոտերի հայտնաբերում մուտքի ժամանակ	Ով տասը անհաջող փորձից հետո անտեսում է սպասման հաղորդագրությունը և շարունակում է թակել, անմիջապես արգելափակվում է	արգելափակել
Վարքի հայտնաբերում	Հասցեներ, որոնք հինգ րոպեում քսան սխալ էջ են առաջացնում և գրեթե ոչ մի գտնված էջ՝ այսինքն գուշակում են՝ կարդալու փոխարեն	զեկուցել
Գնահատական 0–100	Որքանո՞վ է վստահ, որ հասցեի հետևում հարձակվող կա։ Ձևանմուշի ծանրությունից, տարբեր ձևանմուշների քանակից, աչքի ընկնող օրերից, տուժած դոմեյններից և համընկնումների քանակից՝ պարզ տեքստով հիմնավորմամբ	միացված
Մուտքի արգելափակում ըստ գնահատականի	Կարգավորվող գնահատականից սկսած մուտքն արգելվում է, կայքը մնում է ընթեռնելի	40-ից սկսած
Կասկած գողացված մուտքի տվյալների վրա	Կասկածելի հասցեից հաջող մուտքը գրանցվում է և, ցանկության դեպքում, հանձնարարվում որպես առաջադրանք՝ մեկ անգամ յուրաքանչյուր հասցեի և օրվա համար	միացված
Սպառնալիքների ցուցակներ	Tor-ի ելքային հանգույցները, Spamhaus DROP, FireHOL Level 1, blocklist.de՝ նախապես կարգավորված են. ցանկացած այլ RBL ցուցակ կարելի է ավելացնել հասցեով, ամենօրյա համադրում, յուրաքանչյուր ցուցակի համար՝ իր մակարդակը	զեկուցել
Մուտքի էջը փակ է	Չորրորդ մակարդակը ցուցակների և երկրների համար. կայքը կարդացվում է, մուտքի ձևը և ծրագրային միջերեսները փակ են՝ Tor-ի համար հարմար պատասխան	Տարբերակ
Ծագման երկիր	Երկիրը՝ ըստ յուրաքանչյուր գրանցման և հասցեի, GeoLite2-ի միջոցով. տվյալների բազան մոդուլն ինքն է թարմացնում անվճար լիցենզիայի բանալիով	ցուցադրել
Երկրների կանոններ	Արգելափակել, մուտքի էջը փակել, հաղորդել կամ հստակ թույլատրել՝ յուրաքանչյուր երկրի համար, միտումնավոր առանց լռելյայն արժեքի	չկա
Սխալ կարգավորումներ	QNAP, Synology, Exchange Autodiscover, ActiveSync, WebDAV/CalDAV/CardDAV-ը ճանաչվում են, երբեք չեն արգելափակվում և արդյունքով ու տուժած դոմենով տեղադրվում են աշխատանքային ցուցակում	զեկուցել
Թիքեթ՝ յուրաքանչյուր հասցեի համար	Արդյունքից ցանկության դեպքում ստեղծվում է թիքեթ՝ ճիշտ մեկը յուրաքանչյուր հասցեի համար. փակվածը նորից բացվում է, այլ ոչ թե կրկնապատկվում	անջատված
Պարտադիր էջեր և հավաքիչներ	Իրավաբանական տվյալների (Impressum) կանոնական ուղին միշտ հասանելի է. օտար գրելաձևերի մեքենայական փորձարկումը ճանաչվում է և ցանկության դեպքում արգելափակվում	զեկուցել
Թույլատրելի ցուցակ	Հասցեներ և ցանցեր, որոնք երբեք չեն արգելափակվում. ամեն օր համալրվում է firewall-ից (VPN-ի հանդիպակաց կողմեր) և Googlebot-ի ու Bingbot-ի հրապարակված հասցեային տիրույթներից	միացված
Հաճախորդին վերագրում	Հաճախորդի ցանցից եկած գրանցումը վերագրվում է նրան՝ թույլատրելի ցուցակից, երբեք ձեռքով՝ գուշակությամբ	միացված
Դոմեն և նույնացուցիչ՝ յուրաքանչյուր գրանցման համար	Որ կայքին է դիմել և ինչ User-Agent-ով. երկուսն էլ բացակայում են մուտքի մատյանում	միացված
Վերլուծություն	Դիագրամ և pivot՝ բոլոր գրանցումների վերաբերյալ. ըստ ձևանմուշի, օրվա, դոմենի, երկրի, հասցեի	միացված
Խայծ	Զոնդերին տրվում են հորինված պատասխաններ՝ «կանարյան» արժեքով. ով հետագայում դիմի դրան, նշանակում է՝ կարդացել է դրանք	անջատված
RBL-ի տրամադրում	Արգելափակման ցուցակը՝ որպես զուտ հասցեների ցուցակ կամ JSON, առանձին, token-ով պաշտպանված հասցեով՝ HAProxy-ի, OPNsense-ի և URL-ցուցակներ կարդացող ցանկացած firewall-ի համար	միացված

Այն ամենը, ինչ տրվում է հաղորդել, անջատված կամ տարբերակ նշումով, դա միտումնավոր է արված. ով արգելափակումը սուր է դարձնում, թող դա անի այն պատճառով, որ մի քանի օր դիտել է, թե ով է ընկնում դրա տակ, այլ ոչ թե այն պատճառով, որ լռելյայն արժեքն այդպես է պահանջել։

Վերլուծություն. գրանցումներն ըստ ձևանմուշի՝ յոթ օրվա ընթացքում։ Ամենաբարձր սյունը .env ֆայլերի որոնումն է։

RBL ցուցակներ. արգելափակումները տրամադրելու ստանդարտացված եղանակ

RBL-ը նշանակում է Real-time Blackhole List։ Եզրույթը ծագել է փոստի աշխարհից, որտեղ Spamhaus-ը և մյուսները 1990-ական թվականներից հրապարակում են վնասակար ուղարկողների հասցեների ցուցակներ։ Սկզբունքը չափազանց պարզ է և հենց դրա համար այդքան տարածված է՝ մեկ հասցե մեկ տողում, հասանելի HTTP-ով, պարբերաբար նորից բեռնվող։ Ոչ մի ձևաչափ, որը նախ պետք է վերլուծել, ոչ մի միջերես, որի համար գործիք է պետք։

Գործնականում ցանկացած firewall և reverse proxy կարող է կարդալ նման ցուցակ և դրանից կանոններ կազմել։ Արտադրողները դա տարբեր կերպ են անվանում, սակայն մեխանիզմը ամենուր նույնն է՝

• OPNsense և pfSense — URL Table Alias. հասցեների ցուցակը բեռնել HTTP-ով, օգտագործել որպես alias firewall-ի կանոններում, թարմացում՝ ժամային կամ օրական ռիթմով
• HAProxy — ACL ֆայլեր և Maps. src -f sperrliste.txt՝ http-request deny կանոնում, վերաբեռնվում է աշխատանքային API-ի միջոցով առանց վերագործարկման
• nginx — geo մոդուլ՝ կցված հասցեների ֆայլով, կամ deny հրահանգներ՝ գեներացված include ֆայլից
• Fortinet FortiGate — External Block List կամ Threat Feed. URL, որից firewall-ը ստանում է IP ցուցակ և օգտագործում քաղաքականություններում
• Palo Alto Networks — External Dynamic List (EDL). նույն սկզբունքը՝ որպես առանձին օբյեկտի տեսակ անվտանգության քաղաքականություններում
• Check Point — Custom Intelligence Feeds և IP Block Lists URL-ի միջոցով
• Cisco Secure Firewall (Firepower) — Security Intelligence Feeds՝ սեփական ցուցակների աղբյուրներով
• Sophos Firewall — Third-Party Threat Feeds. URL-ից հասցեների ցուցակներ՝ որպես արգելափակման կանոնների աղբյուր
• Juniper SRX — Dynamic Address Entries feed-երից
• MikroTik RouterOS — Address Lists՝ սկրիպտի և fetch-ի միջոցով URL-ից լրացված
• CrowdSec — սեփական ցուցակներ՝ որպես աղբյուր ցանկացած աջակցվող համակարգի bouncer-ների համար

Web RBL-ն իր արգելափակման ցուցակը տրամադրում է հենց այս ձևաչափով։ Firewall-ը մերժում է փաթեթները, նախքան դրանք կհասնեն վեբ սերվերին — և դրանց հետ միասին՝ նույն հասցեի ցանկացած այլ փորձ, օրինակ՝ փոստային սերվերի կամ VPN gateway-ի նկատմամբ։

Երկու ուղղություն, բայց ճիշտ տեղում

Ճանապարհը գործում է նաև հակառակ ուղղությամբ. Web RBL-ում կարելի է մուտքագրել ցանկացած RBL ցուցակ — մեկ URL, մեկ մակարդակ, և պատրաստ է։ Tor-ի ելքային հանգույցները, Spamhaus DROP-ը, FireHOL-ը և blocklist.de-ն նախապես կարգավորված են, մյուսները ավելացվում են երեք սեղմումով։ Մոդուլը յուրաքանչյուր ցուցակ տրոհում է հասցեային տիրույթների և դրանց համեմատ ստուգում է յուրաքանչյուր հարցում՝ մի քանի միկրովայրկյանում։

Սակայն՝ ավելի նպատակահարմար է օտար ցուցակները օգտագործել առաջ գտնվող firewall-ում։ Երեք պատճառով։ Firewall-ը տեսնում է բոլոր ծառայությունները, ոչ միայն HTTP-ը. Spamhaus ցուցակի հասցեն պետք է ձախողվի նաև փոստային սերվերում և VPN-ում։ Այն մերժում է փաթեթների մակարդակում՝ մինչև կապի հաստատվելը, և այդպիսով հավելվածի սերվերին ոչինչ չի արժենում։ Եվ դա այն վայրն է, որտեղ նման ցուցակները այնուամենայնիվ պահպանվում են. հավելվածում երկրորդ պատճենը երկրորդ տեղ է, որը կարող է հնանալ։

Իսկ ինչի՞ համար են այդ դեպքում ցուցակները մոդուլում. այն բանի համար, ինչ firewall-ը չի կարող։ Այն չի ճանաչում մուտքի ձևը։ Web RBL-ը կարող է Tor ցուցակի հասցեին մերժել մուտքի էջը՝ կայքը այնուամենայնիվ տրամադրելով — ով ուզում է անանուն կարդալ, թող կարդա. ով ուզում է անանուն գաղտնաբառեր փորձարկել՝ ոչ։ Եվ այն կարող է ցուցակում գտնվող հասցեից հաջող մուտքը հայտնել որպես կասկածելի դեպք։ Երկուսն էլ պահանջում են ցուցակը այնտեղ, որտեղ մուտքն իրականացվում է։

Գնահատական՝ զգացողության փոխարեն

Հասցեն, որը մեկ անգամ դիմել է /wp-login.php-ին, այլ բան է, քան այն, որը երկու օրվա ընթացքում հինգ տարբեր ձևանմուշներով անցել է երեք դոմենով։ Web RBL-ը դա վերածում է 0-ից 100 գնահատականի՝ այն հիման վրա, ինչ ինքն է տեսել, առանց արտաքին ծառայության և առանց դեպի դուրս հարցման։

Մեկ գրանցում. 99 համընկնում, գնահատական 84, և հիմնավորումը պարզ տեքստով՝ ամենածանր ձևանմուշը, հինգ տարբեր լուրջ ձևանմուշներ, երկու կասկածելի օր, քսանից ավելի համընկնում։

Գնահատականը որոշում է երկու բան։ Կարգավորելի արժեքից սկսած մուտքն արգելվում է — կայքը մնում է կարդացվող, բայց ով արդեն որոնել է մուտքի տվյալներ, հնարավորություն չի ստանում փորձարկել գտածները։ Իսկ գնահատական ունեցող հասցեից հաջող մուտքը հայտնվում է. այդ դեպքում մեկը այլևս չի գուշակել, այլ գիտեր։ Կամ իրավաչափ օգտվողը ճանապարհորդության մեջ էր, կամ մուտքի տվյալները կորել են՝ մոդուլը դա չի որոշում, այն դա ներկայացնում է մեկին, ով կարող է հարցնել։ Գաղտնաբառին ինքնին այդ ընթացքում ոչ մի տեղ չի դիպչում։

Արգելափակման ցուցակը՝ զտված 40-ից սկսած գնահատականով. համընկնումների քանակը, կասկածելի օրերը, տուժած դոմենները և յուրաքանչյուր հասցեի վերջին ուղին։

Ինչ է պաշտպանում Web RBL-ը — պաշտպանության ազդեցությունը մանրամասն

1. Մուտքի տվյալները չեն հայտնաբերվում

Չափված հարձակումների ամենախոշոր դասը Odoo-ի խոցելիություններ չի որոնում, այլ՝ մոռացված գաղտնիքներ։ Տասնյոթ օրվա ընթացքում՝

• 57.721 հարցում .env ֆայլերի համար — այնտեղ պահվում են տվյալների բազայի գաղտնաբառեր, API բանալիներ և սեսիայի գաղտնիքներ
• 5.535 հարցում կարգավորման ֆայլերի համար
• 4.388 հարցում ամպային մուտքի տվյալների համար՝ credentials.json, service-account.json, firebase-adminsdk.json, rclone.conf, .git-credentials
• 2.811 հարցում .git դիրեկտորիաների համար — ով գտնում է այդպիսին, ներբեռնում է ամբողջական սկզբնական կոդը՝ պատմության հետ միասին
• 1.907 հարցում կառուցման հրահանգների համար, ինչպիսիք են .github/workflows/deploy.yml կամ .gitlab-ci.yml, որտեղ նշված են registry-ներ և բանալիների անուններ

Այստեղ վճռորոշը հարցումների թիվը չէ, այլ տարբեր հասցեների թիվը. /credentials.json-ը եկել է 98 հասցեից, /.git-credentials-ը՝ 92-ից։ Սա առանձին սկաների գործ չէ, այլ ստանդարտ խումբ, որը աշխարհով մեկ աշխատում է միաժամանակ։

2. Մուտքի փորձերը ձախողվում են — մշտապես

Odoo-ն ունի սեփական արգելակ՝ գաղտնաբառերի փորձարկման դեմ։ Այն ունի երեք սահմանափակում, որոնք փաստաթղթավորված են հենց Odoo-ի սկզբնական կոդում. հաշվիչը գտնվում է աշխատանքային պրոցեսի օպերատիվ հիշողության մեջ և յուրաքանչյուր վերագործարկման ժամանակ զրոյացվում է, այն միայն դանդաղեցնում է՝ արգելափակելու փոխարեն, և հաշվում է բացառապես այն փորձերը, որոնք հասնում են գաղտնաբառի ստուգմանը։

Web RBL-ն կիրառվում է նույն կետերում, բայց գրանցում է տվյալների բազայում։ Դրանով՝

• Վիճակը պահպանվում է ցանկացած վերագործարկումից հետո և գործում է բոլոր աշխատանքային պրոցեսների համար
• Գրանցվում են երկու ուղիներն էլ՝ մուտքի ձևը /web/login և միջերեսները /xmlrpc/2/common և /jsonrpc
• Գրանցվում են նաև այն փորձերը, որոնք երբեք չեն հասնում գաղտնաբառի ստուգմանը — օրինակ՝ մուտքեր առանց վավեր սեսիայի նշանի
• Տվյալների բազայի կառավարչին ձախողված դիմումը նույնպես հաշվվում է. սա ամենածանր մուտքի փորձն է ընդհանրապես

Մուտքերի շեմը սահմանված է տասը, և պատճառը չափումն է. տասնյոթ օրվա ընթացքում ձախողված ինը մուտքերի մեծ մասը հաճախորդներից էր, որոնք մուտքը ինքնուրույն կարգավորում էին մեկ այլ սարքի վրա և այդ ընթացքում մուտքագրում էին սխալ դոմեն — մի դեպքում սեփականը, միայն կետի փոխարեն գծիկով։ Առաջին ձախողված փորձի արգելափակումը հարվածած կլիներ ոչ թե հարձակվողներին, այլ հաճախորդներին՝ կարգավորման ժամանակ։

Իսկ ով շարունակում է թակել, թեև սերվերն արդեն պատասխանել է «խնդրում ենք մի փոքր սպասել», անմիջապես արգելափակվում է։ Այս հաղորդագրությունը կարդում է մարդը և սպասում է. ով անտեսում է այն, ծրագիր է։ Զրոյական շեմով առանձին ձևանմուշը ճիշտ այս դեպքն է բռնում, և այն չի կարող հարվածել գործընկերոջը. այնտեղ է հասնում միայն նա, ով արդեն տասը ձախողված փորձ ունի և դրանից հետո շարունակում է։

3. Հարձակումն այլևս ոչինչ չի արժենում սերվերին

/@fs/../../.env նման ուղու զոնդը մոդուլից առաջ թանկ էր. Odoo-ն փնտրում է սխալի էջը, վերարտադրում այն, հասցեն կառուցելիս սայթաքում է կետային հատվածների վրա և դրանից հետո ձախողվում է նաև սխալի էջի սխալի էջի վրա։ Երկու stack trace յուրաքանչյուր զոնդի համար։ Տասնյոթ օրվա ընթացքում չափվել է նման 28.401 սխալ, դրանց ավելացել է 9.467 հետևանքային սխալ։

Web RBL-ը ներգրավվում է ir.http._match-ում, այսինքն՝ ուղու որոշումից առաջ։ Պատասխանը տրվում է առանց ձևանմուշի, առանց տվյալների բազայի դիմումի՝ արգելափակման ստուգումից այն կողմ, և առանց մատյանի տողի։ Թույլատրելի ցուցակի, սպառնալիքների ցուցակների և երկրների կանոնների ստուգումը կատարվում է քեշից՝ տեսակավորված հասցեային տիրույթներով — մի քանի միկրովայրկյան՝ նույնիսկ երեսուն հազարից ավելի տիրույթների դեպքում։

4. Firewall-ը դուրս է նետում հարձակվողին՝ մինչև նրա հասնելը

Արգելափակման ցուցակը հրապարակվում է որպես RBL ցուցակ, որը HAProxy-ն և OPNsense-ը անմիջապես կարդում են։ Հարձակվողն այդպիսով այլևս չի հասնում վեբ սերվերին — ինչպես նաև նույն հոսթի ոչ մի այլ ծառայության։ Մեկ անգամ վնասակար ճանաչված դիմումն այդպիսով հետընթաց պաշտպանում է ամբողջ մեքենան։

Երեք մակարդակ՝ արգելափակել, հաշվել, հաղորդել

Ոչ յուրաքանչյուր դատարկ հարցում է հարձակում։ Web RBL-ը դրա համար տարբերում է երեք մակարդակ, և մակարդակը կարելի է փոխել յուրաքանչյուր ձևանմուշի համար՝ կոդին դիպչելու կարիք չկա։

Մակարդակ	Ակտիվացնող հարցումը	Հետևանքը հասցեի համար
արգելափակել	մերժվում է	արգելափակվում է 24 ժամով, երեք կասկածելի օրից հետո՝ մշտապես
հաշվել	անցնում է	միայն գրանցվում է, առանց արգելափակման
հաղորդել	անցնում է	գրանցվում է եզրակացության տեքստով, երբեք չի արգելափակվում

Սպառնալիքների ցուցակների և երկրների համար կա չորրորդը՝ մուտքի էջը փակ է։ Կայքը մնում է կարդացվող, մուտքի ձևը և միջերեսները փակ են։ Սա միջին ճանապարհ է այն ամենի համար, ինչ կասկածելի է, բայց պարտադիր չէ, որ վնասակար լինի՝ Tor, տվյալների կենտրոնի տիրույթ, հաճախորդներ չունեցող երկիր։

Ինչ հարձակումներ են ճանաչվում

Բոլոր ձևանմուշները ստուգված են իրական երթևեկության դեմ։ Տարբեր հասցեների թիվը միտումնավոր նշված է կողքին՝ այն ցույց է տալիս՝ արդյոք ձևանմուշը հարվածում է առանձին սկաների, թե տարածված մեթոդի։

Հարձակման դաս	Հարցումներ	Հասցեներ
.env-ի հափշտակում	57.721	223
PHP զոնդեր	12.237	256
Path traversal՝ արժեքավոր թիրախով	10.046	64
Կարգավորման ֆայլեր	5.535	114
Ամպային մուտքի բանալիներ	4.388	152
WordPress զոնդեր	3.366	385
.git-ի հափշտակում	2.811	255
Odoo-ի հետախուզում (տվյալների բազայի կառավարիչ, տարբերակի հարցում)	2.500	213
AI գործիքների շղթաներ և հրամանների կատարում (/mcp, /api/fs/exec)	2.450	74
Կառուցման հրահանգներ (CI/CD)	1.907	88
GraphQL վերջնակետեր	1.878	71

Ուշագրավ է ամենաթարմ դասը։ /api/fs/exec-ին 54 տարբեր հասցեից դիմել են 369 անգամ — սա ընթերցման հասանելիություն չէ, այլ հրամաններ կատարելու փորձ։ Նման թիրախներ երկու տարի առաջ չկային. դրանք գալիս են նոր AI գործիքների և առաջադրանքների հերթերի միջերեսներից։ Ով իր պաշտպանությունը կողմնորոշում է միայն WordPress-ի և PHP-ի վրա, դրանից ոչինչ չի տեսնում։ Գնահատականում այս դասը համապատասխանաբար ծանր է կշռում։

Սպառնալիքների ցուցակներ և ծագման երկիր

Չորս ցուցակ, 32.851 հասցեային տիրույթ, բոլորը՝ «միայն հաղորդել»։ Յուրաքանչյուր հավելյալ ցուցակ՝ մեկ հասցե և մեկ մակարդակ։

Օտար ցուցակը պնդում է, որը ինչ-որ մեկ ուրիշն է առաջ քաշում՝ մեզ անհայտ պատճառներով, մեր երբեք չտեսած երթևեկության վերաբերյալ։ Այն կարող է սխալ լինել, հնացած կամ նախատեսված այլ նպատակի համար. blocklist.de-ն հավաքում է հիմնականում այն հասցեները, որոնք այլուր փորձարկել են SSH մուտքեր, և դա վեբ սերվերի մասին քիչ բան է ասում։ Այդ պատճառով Web RBL-ն օտար ցուցակները վարում է սեփական արգելափակման ցուցակից առանձին, և այդ պատճառով լռելյայն արժեքը հաղորդել է։ Իսկ սեփական թույլատրելի ցուցակը միշտ հաղթում է. մեր ճանաչած հաճախորդն ավելի կշիռ ունի, քան երրորդ անձի գնահատականը։

Ծագման երկիրը նշված է յուրաքանչյուր համընկնման և հասցեի մոտ։ Գնահատելու համար այն անփոխարինելի է — սեփական երկրից առավոտյան ժամը տասին կատարված մուտքի փորձը այլ բան է, քան մեկ հաճախորդ իսկ չունեցող երկրից եկածը։ Տոտալ արգելափակման համար այն քիչ է պիտանի, և դա ասում են սեփական թվերը. մեր ցուցակի հարձակվողները գերազանցապես եկել էին Բելգիայի, Ֆինլանդիայի և Նիդեռլանդների ամպային տիրույթներից։ Գերմանալեզու տարածաշրջանից դուրս բոլորի համար արգելափակումը նրանց չէր հարվածի — բայց հարվածելու էր սեփական աշխատակիցներին՝ արձակուրդում, և հաճախորդներին՝ գործուղման մեջ։

Երկրների կանոնները տրամադրվում են դատարկ, և տեսքը ասում է՝ թե ինչու։

Սխալ կարգավորումները՝ հաղորդել, ոչ թե արգելափակել

Իրական երթևեկության ամենահաճախ դեպքը ոչ հարձակում է, ոչ այցելու, այլ վնասված ծրագրակազմ, որը վեբ սերվերը շփոթում է այլ բանի հետ՝

• 1.367 դիմում QNAP NAS-ի վեբ միջերեսին — սինքրոնիզացիայի կլիենտ, որի թիրախն այլևս ճիշտ չէ։ Մեկ միակ միացում թակել է 962 անգամ։
• 65 Autodiscover հարցում — Outlook, որը վեբ դոմենը շփոթում է իր Exchange-ի հետ

Նման հասցեները երբեք չեն արգելափակվում։ Արգելափակումը թերությունը չի շտկում, այլ թաքցնում է այն — և հարվածում է նրան, ում սարքն առանց այն էլ սխալ է կարգավորված։ Փոխարենը ստեղծվում է գրանցում՝ եզրակացության տեքստով և տուժած դոմեններով, որից ցանկության դեպքում ավտոմատ ստեղծվում է թիքեթ՝ յուրաքանչյուր հասցեի համար ճիշտ մեկը, և եթե այն փակվի ու հասցեն նորից աչքի ընկնի, նույն թիքեթը կրկին բացվում է՝ երկրորդ թիքեթ ստեղծվելու փոխարեն։

Ճանաչվում են QNAP, Synology, Exchange Autodiscover, ActiveSync, ինչպես նաև WebDAV, CalDAV և CardDAV կլիենտները։ Ձևանմուշները նշում են ճշգրիտ ֆայլերի անուններ և դիրեկտորիաներ, երբեք՝ զուտ ընդլայնումներ. նույն /cgi-bin/ դիրեկտորիայում անվնաս սինքրոնիզացիայի դիմումները գտնվում են հենց դասական զոնդերի կողքին, ինչպիսին printenv.pl-ն է։

Թույլատրելի ցուցակ. հասցեներ, որոնք երբեք չեն արգելափակվում

Սխալի գինը բոլոր հասցեների համար նույնը չէ։ Տվյալների կենտրոնի սկաների դեպքում կեղծ տագնապը ոչինչ չի արժենում։ Տարածքային թունելի հանդիպակաց կողմի դեպքում այն արժենում է ամբողջ տարածքը։

Այդ պատճառով կա երկրորդ ցուցակ, որը կանգնած է առաջինից առաջ. հասցեներ և ցանցեր, որոնք երբեք չեն արգելափակվում։ Այն ոչինչ չի լռեցնում — ով այնտեղ է, շարունակում է ստուգվել և գրանցվել, միայն հետևանքն է բացակայում։ Սա տարբերությունն է firewall-ի բացառությունից. վերջինս կուրացնում է, սա միայն համբերատար է դարձնում։

Այն ամեն օր լրացվում է երկու աղբյուրից. հենց firewall-ից՝ բոլոր VPN հանդիպակաց կողմերով, որպեսզի նոր կարգավորված թունելը կախված չլինի նրանից, որ ինչ-որ մեկը կհիշի արգելափակման ցուցակի մասին — և Google-ի ու Microsoft-ի հրապարակված հասցեային տիրույթներից՝ իրենց crawler-ների համար։ Միայն այդպես կարելի է իսկական Googlebot-ը տարբերել սկաներից, որն իրեն այդպես է անվանում։ Որոնողական համակարգերը երբեք չպետք է արգելափակվեն. ով նրանց փակում է, իր կայքը հետ է վերցնում ինդեքսավորումից՝ առանց վերադարձի ճանապարհի։

Այստեղ գործում է մի կանոն, որն ավելի կարևոր է, քան համադրումը՝ դատարկ պատասխանը երբեք չի ջնջում։ Եթե աղբյուրը չի պատասխանում, պատասխանում է դատարկ կամ անհասկանալի, ցուցակը մնում է անփոփոխ։ Թույլատրելի ցուցակը, որը խափանման ժամանակ ինքն իրեն դատարկում է, ամենավատ պատկերացվող պահին իր հետ տանում է բոլոր թունելները։

Եթե թույլատրելի ցուցակի գրանցումը հաճախորդ է կրում, նրա ցանցից եկած յուրաքանչյուր համընկնում վերագրվում է նրան։ Սխալ կարգավորումն այդպիսով անմիջապես ունի կոնտակտային անձ՝ առանց որևէ մեկի հասցեներ փնտրելու կարիքի։

Պարտադիր տվյալներ և ավտոմատացված տվյալների հավաքիչներ

Իրավաբանական տվյալների էջը (Impressum) սովորական էջ չէ։ Այն պետք է մնա մարդկանց համար հասանելի, քանի որ դրա արգելափակումը ստեղծում է հենց այն խախտումը, որը հավաքիչը փնտրում է։ Միաժամանակ դա այն էջն է, որտեղ նշված են անունն ու հասցեն — և դրանով՝ մեքենայական հավաքի թիրախը։

Ավստրիայում Google-ի ներառված տառատեսակների պատճառով տեղի ունեցած դատական սպառնալիքների ալիքի ժամանակ մատյանները ցույց տվեցին, որ նամակները չեն ծագել առանձին այցերից, այլ ավտոմատացված զանգվածային հարվածից. տարբեր, իրար հետ կապ չունեցող հոսթեր՝ միլիվայրկյանների ընդմիջումով։

Web RBL-ը դա լուծում է իջեցումով՝ բացառության փոխարեն։ Կանոնական ուղի /impressum-ը չի համընկնում որևէ ձևանմուշի և միշտ մնում է հասանելի։ Օտար գրելաձևերը, ինչպես /impressum.php — որը Odoo էջում չի կարող գոյություն ունենալ — հաղորդվում են, և ով մեքենայական հավաքը չի ուզում հանդուրժել, փոխում է մեկ պարամետր։ sitemap-ը և robots-ը բացառված են և սկզբունքորեն չեն արգելափակվում. դրանք չեն պարունակում անձնական տվյալներ, և դրանք ստանալը ցանկացած որոնողական crawler-ի խնդիրն է։

Դոմեն և նույնացուցիչ. ինչ է բացակայում մուտքի մատյանում

werkzeug-ի մուտքի մատյանը չի գրանցում ո՛չ դիմված հոսթը, ո՛չ դիմողի նույնացուցիչը։ Odoo-ն երկուսն էլ, բնականաբար, ստանում է — առանց հոսթի մի քանի կայքի դեպքում այն ընդհանրապես չէր կարող ընտրել ճիշտը։ Բայց հետագայում դա այլևս հնարավոր չէ ստուգել։

Web RBL-ը երկուսն էլ գրանցում է յուրաքանչյուր համընկնման համար։ Դա պատասխանում է երկու հարցի, որոնց այլ կերպ պատասխանել հնարավոր չէ՝ որ կայքն է դիմում սխալ կարգավորմանը — և դրանով՝ որ հաճախորդին է պատկանում դոմենը — և արդյոք հասցեն այցելում է մեկ էջ, թե բոլորը։ Նույն հասցեի մի քանի իրար հետ կապ չունեցող դոմեններ զանգվածային հարվածի հատկանիշն են, և դրանք բարձրացնում են գնահատականը։

Թե որքան է նշանակում նույնացուցիչը, ցույց տվեց մեր կայքերից մեկի վերլուծությունը՝ ամբողջ երթևեկության յոթանասուն տոկոսից ավելին այնտեղ բաժին էր ընկնում մեկ դիմողի՝ բաշխված հարյուրից ավելի հասցեների վրա։ Առանց նույնացուցիչի դա բաշխված scraper-ի տեսք կունենար։ Դա GPTBot-ն էր, OpenAI-ի crawler-ը — այն անընդհատ հարցնում էր robots.txt-ը և իրեն պահում էր լիովին ճիշտ։

Անվտանգության կողմերը մանրամասն

1. Proxy-ի ճանաչումը — ընդհանրապես ամենավտանգավոր կետը

Եթե Odoo-ն աշխատում է reverse proxy-ի հետևում, և proxy_mode-ը սխալ է սահմանված, մոդուլը յուրաքանչյուր հարցման ժամանակ տեսնում է նույն հասցեն՝ proxy-ինը։ Այդ դեպքում արգելափակումը բոլոր այցելուներին միաժամանակ դուրս կմնար։

Այդ պատճառով Web RBL-ը յուրաքանչյուր արգելափակումից առաջ ստուգում է՝ արդյոք հասցեի որոշումը հուսալի է։ Այն պահանջում է proxy_mode-ը վերահասցեավորման վերնագրի հետ միասին, հրաժարվում է աշխատել, եթե վերահասցեավորում է գալիս առանց proxy_mode-ի, և նույն կերպ հրաժարվում է մեկից ավելի միջանկյալ proxy-ի դեպքում։ Կասկածի դեպքում չի արգելափակվում։

2. Սեփական ցանցերը երբեք

Մասնավոր հասցեային տիրույթները, loopback-ը, link-local-ը և CGNAT-ը ամրագրված բացառված են։ Դրանք ոչ մի պայմանով չեն կարող հայտնվել ցուցակում, նույնիսկ ձեռքով։ Նույնը վերաբերում է օտար ցուցակներին. մասնավոր և վերապահված տիրույթները, ինչպես նաև անհեթեթ մեծ ցանցերը ընթերցման ժամանակ մերժվում են։

3. Սեփական սխալը չպետք է կայքը իր հետ տանի

Ամբողջ ստուգումը աշխատում է պաշտպանության շրջանակում, որը ցանկացած սխալ բռնում է։ Այն, ինչ այստեղ վրիպում է, գրանցվում է մատյանում, և հարցումը շարունակվում է անփոփոխ։ Պաշտպանության մոդուլը, որը սեփական սխալի դեպքում կայքն իր հետ է տանում, ավելի վատ է, քան ընդհանրապես չլինելը։ Հարցման ճանապարհի բոլոր դիմումները աշխատում են նաև առանց այցելուի դիտարկչի լեզվի և առանց թարգմանված դաշտերով տեսակավորման — չտեղադրված լեզվով այցելուն չի կարող ստուգումը խափանել։

4. Դիտարկել՝ նախքան արգելափակելը

Տեղադրումից հետո սովորական հարցումների դեպքում ցուցակում գտնվող հասցեների արգելափակումը անջատված է։ Զոնդերը մերժվում են և գրանցվում, մնացածը անցնում է։ Այդպես մի քանի օր կարելի է դիտել՝ թե ով է իրականում հայտնվում ցուցակում, նախքան որևէ մեկին դուրս կմնա։ Նույնը վերաբերում է վարքագծի ճանաչմանը, սպառնալիքների ցուցակներին և երկրների կանոններին՝ նախ հաղորդել, արգելափակել՝ դիտարկումից հետո։

5. Նեղ ձևանմուշներ՝ լայն ցանցերի փոխարեն

Սխալ ճանաչված այցելուն ավելի թանկ է, քան չնկատված զոնդը։ Յուրաքանչյուր ձևանմուշ դրա համար կրում է իր մակարդակը, և այն կարելի է փոխել յուրաքանչյուր ձևանմուշի համար։ Առանձին ֆայլի ընդլայնումը հազվադեպ է բավարար. .php-ի դեպքում 14.012 իրական զոնդ է հանդիպում մի բուռ հին հղումների դեմ, .asp-ի դեպքում հարաբերակցությունը հակառակն է։ Նման որոշումները պետք է չափվեն, ոչ թե գնահատվեն։

6. Ձեռքով տրված թույլտվությունը մնում է ուժի մեջ

Ով հասցեն թույլատրում է, պատճառ է ունեցել։ Հերթական համընկնումը այդ որոշումը լուռ չի չեղարկում։

7. Ցուցակը պաշտպանված է, բայց գաղտնիք չէ

Վերջնակետը պահանջում է token և առանց վավեր token-ի պատասխանում է 404-ով, ոչ թե 403-ով — հասցեի գոյությունը այդպիսով առհասարակ չի հաստատվում։ Համեմատությունը կատարվում է հաստատուն ժամանակում։ Ցուցակն ինքնին ոչ մի գաղտնի բան չի պարունակում. այն բաղկացած է հասցեներից, որոնք իրենք են մեզ թակել։

8. Գաղտնիքներ՝ հաշվառման մեջ՝ ոչ

Ձախողված մուտքերի դեպքում գրանցվում է փորձված օգտանունը, երբեք՝ գաղտնաբառը։ Տվյալների բազայի կառավարչի դեպքում փոխանցված արժեքներից ոչինչ չի կարդացվում. այնտեղ ամենասկզբում հիմնական գաղտնաբառն է, և արգելափակման ցուցակի գրանցումը անցնում է յուրաքանչյուր տվյալների բազայի կրկնօրինակի մեջ։ GeoLite2-ի լիցենզիայի բանալին գտնվում է միայն համակարգային պարամետրում և ոչ մի մատյանի տողում։

9. Խայծը ոչ մի օգտագործելի բան չի բացահայտում

Ընտրովի Web RBL-ը զոնդերին պատասխանում է հորինված բովանդակությամբ, որը պարունակում է միանշանակ «կանարյան» արժեք։ Ով հետագայում դիմում է այդ արժեքին, կարդացել է կեղծ պատասխանը և դրանից հետո գործել — կեղծ տագնապն այստեղ բացառված է։ Խայծերը չեն պարունակում օգտագործելի տվյալներ, ոչ մի իրական ուղի և ոչ մի վավեր մուտքի տվյալ։ Այս գործառույթը տրամադրվում է անջատված, քանի որ այն փոխում է արտաքուստ տեսանելի վարքագիծը։

Ինչ չի կարող մոդուլը

Այն չի փոխարինում ո՛չ firewall-ը, ո՛չ Web Application Firewall-ը։ Այն ճանաչում է հայտնի զոնդավորման ձևանմուշները ուղիներում, ձախողված մուտքերը և կասկածելի վարքագիծը — ոչ թե ձևերի դեմ հարձակումները, ոչ թե պարամետրերում ներարկման փորձերը։

Բացի այդ, այն տեսնում է միայն այն, ինչ HTTP-ով վերադառնում է։ Այն, ինչ հարձակվողը անում է կորզված տվյալների բազայի կամ փոստարկղի մուտքերով, մնում է անտեսանելի — և հենց դրա համար կանարյան արժեքները ուղիներ են, ոչ թե մուտքի տվյալներ։

Եվ այն չի փոխարինում խնամքը. մոդուլը, որը .env զոնդերը մերժում է, չի դարձնում անվտանգ պատահաբար տրամադրված .env ֆայլը։

Հասանելիություն

Web RBL-ը AGPL-3 լիցենզիայով հանրային հասանելի է և մեզ մոտ արտադրական միջավայրում աշխատում է հինգ կայքերում՝

github.com/Alex0176/odoo-web-rbl

Մոդուլը պահանջում է Odoo 19 Community և կախվածություններ չունի՝ բացի base-ից և web-ից։ Թիքեթային միացումը ընտրովի է և որևէ որոշակի թիքեթային համակարգ չի պահանջում. առանց այդպիսիի պարզապես ոչինչ չի տեղի ունենում։ Ծագման երկիրը պահանջում է MaxMind-ի անվճար GeoLite2 տվյալների բազան. եթե այն բացակայում է, դաշտը մնում է դատարկ, և մնացած ամեն ինչ աշխատում է անփոփոխ։

Լրացուցիչ. Ինչպես է Web RBL-ը տեղավորվում անվտանգության լիարժեք ճարտարապետության մեջ -- firewall-ի, երկգործոն նույնականացման և իրավասությունների հետ միասին, ներառյալ քայլ առ քայլ ուղեցույցը՝ Odoo 19-ի անվտանգության ճարտարապետության ճիշտ համադրումը.

Հարցերը, դիտողություններն ու սխալների հաշվետվությունները ուրախությամբ ընդունում ենք — ամենից շատ՝ որպես issue GitHub-ում։