Mənbə kodu: github.com/Alex0176/odoo-web-rbl — AGPL-3, sərbəst istifadə edilə bilər.
İnternetdə Odoo serveri işlədən hər kəsin qonaqları olur. Arabir deyil, fasiləsiz. On yeddi gün ərzində beş veb-saytımızda 731.297 sorğunu qeydə alıb təhlil etdik. Onlardan 110.511-i ziyarətçilərdən gəlmirdi — bunlar zəiflikləri, giriş məlumatlarını və konfiqurasiya fayllarını tapmaq üçün avtomatlaşdırılmış axtarışlar idi.
Bu məqalə Odoo 19 Community üçün hazırlanmış açıq mənbəli Web RBL modulunu təsvir edir. Modul bu trafiki aşkarlayır, qiymətləndirir, qeydə alır və rədd edir, blok siyahısını isə RBL siyahısı kimi, yəni şəbəkə ekranlarının və əks proksilərin birbaşa oxuya bildiyi formatda yayımlayır. Bütün rəqəmlər real istismar məlumatlarına əsaslanır.
Modulun imkanları — funksiyalara ümumi baxış
| Funksiya | Nə edir | İlkin ayar |
|---|---|---|
| Nümunələr üzrə aşkarlama | Yol və fayl uzantısı əsasında yoxlama cəhdlərini aşkarlayır: .env, .git, konfiqurasiya faylları, bulud açarları, CI/CD yığım təlimatları, WordPress, PHP, qovluq sərhədlərindən kənara çıxma cəhdləri, verilənlər bazası idarəetmə alətləri, GraphQL, /api/fs/exec və oxşar interfeyslər vasitəsilə əmrlərin icrası | bloklamaq |
| Hər nümunə üçün üç səviyyə | bloklamaq, saymaq və ya bildirmək — kod yazmadan hər nümunə üçün ayrıca dəyişdirilə bilər | hər nümunə üzrə |
| Hədlər | Bloklamadan əvvəl eyni nümunə üzrə qeydə alınmalı hadisələrin sayı; giriş cəhdləri üçün on | giriş üçün 10 |
| Girişin qorunması | Forma və XML-RPC/JSON-RPC vasitəsilə uğursuz girişlər, uğursuz sessiya yoxlamaları, verilənlər bazası idarəetmə alətinə müraciətlər — operativ yaddaşda deyil, verilənlər bazasında saxlanılır | aktiv |
| Giriş zamanı botların aşkarlanması | On uğursuz cəhddən sonra gözləmə bildirişinə məhəl qoymayıb cəhdlərini davam etdirənlər dərhal bloklanır | bloklamaq |
| Davranış əsasında aşkarlama | Beş dəqiqə ərzində iyirmi xəta səhifəsi yaradan və demək olar ki, heç bir mövcud səhifəyə çatmayan ünvanlar — yəni məzmunu oxumaq əvəzinə ünvanları təxmin edənlər | bildirmək |
| 0–100 arası qiymətləndirmə | Ünvanın arxasında hücumçunun dayandığına nə dərəcədə əmin olmaq olar? Qiymət nümunənin təhlükə dərəcəsi, müxtəlif nümunələrin sayı, şübhəli fəaliyyət olan günlər, təsirlənən domenlər və qeydə alınmış hadisələrin sayı əsasında hesablanır — səbəbi də aydın mətnlə izah olunur | aktiv |
| Qiymətə əsasən girişin bloklanması | Tənzimlənən qiymət həddinə çatdıqda sistemə giriş qadağan olunur, veb-saytı isə oxumaq mümkün qalır | 40-dan başlayaraq |
| Giriş məlumatlarının oğurlanması şübhəsi | Şübhəli ünvandan uğurlu giriş barədə bildiriş verilir və istəyə görə tapşırıq təyin olunur — hər ünvan üçün gündə bir dəfə | aktiv |
| Təhdid siyahıları | Tor çıxış qovşaqları, Spamhaus DROP, FireHOL Level 1 və blocklist.de əvvəlcədən konfiqurasiya edilib; istənilən əlavə RBL siyahısını ünvanı vasitəsilə daxil etmək mümkündür, gündəlik sinxronlaşdırma aparılır, hər siyahı üçün ayrıca səviyyə seçilir | bildirmək |
| Girişə icazə yoxdur | Siyahılar və ölkələr üçün dördüncü səviyyə: veb-saytı oxumaq mümkündür, giriş forması və interfeyslər isə bağlıdır — Tor üçün uyğun tədbir | Seçim |
| Mənşə ölkəsi | Hər hadisə və ünvan üçün ölkə GeoLite2 vasitəsilə müəyyən edilir; modul pulsuz lisenziya açarı ilə verilənlər bazasını özü yeniləyir | göstərmək |
| Ölkələr üzrə qaydalar | Bloklamaq, giriş səhifəsinə çıxışı bağlamaq, bildirmək və ya açıq şəkildə icazə vermək — hər ölkə üçün ayrıca; əvvəlcədən heç bir seçim təyin edilməyib və bu, şüurlu qərardır | yoxdur |
| Yanlış konfiqurasiyalar | QNAP, Synology, Exchange-Autodiscover, ActiveSync və WebDAV/CalDAV/CardDAV aşkarlanır, heç vaxt bloklanmır və aşkarlanan hal, eləcə də təsirlənən domen göstərilməklə iş siyahısına əlavə olunur | bildirmək |
| Hər ünvan üçün bir dəstək sorğusu | Aşkarlanan hal əsasında istəyə görə dəstək sorğusu yaradılır — hər ünvan üçün yalnız bir sorğu; bağlanmış sorğunun dublikatı yaradılmır, özü yenidən açılır | söndürülüb |
| Məcburi səhifələr və məlumat toplayıcıları | Hüquqi məlumatlar səhifəsinin kanonik yolu həmişə əlçatan qalır; alternativ yazılış variantlarının avtomatik yoxlanması aşkarlanır və istəyə görə bloklanır | bildirmək |
| İcazə siyahısı | Heç vaxt bloklanmayan ünvanlar və şəbəkələr; siyahı hər gün şəbəkə ekranından (VPN-in qarşı tərəfləri), həmçinin Googlebot və Bingbot üçün yayımlanmış ünvan diapazonlarından avtomatik doldurulur | aktiv |
| Müştəri ilə əlaqələndirmə | Müştərinin şəbəkəsindən gələn hadisə həmin müştəri ilə əlaqələndirilir — icazə siyahısı əsasında, heç vaxt əl ilə təxmin edilərək deyil | aktiv |
| Hər hadisə üçün domen və identifikator | Hansı veb-sayta və hansı User-Agent ilə müraciət edilib — giriş jurnalında bu məlumatların hər ikisi yoxdur | aktiv |
| Təhlil | Bütün hadisələr üzrə diaqram və çarpaz cədvəl: nümunə, gün, domen, ölkə və ünvan üzrə | aktiv |
| Yem | Yoxlama sorğularına izləmə nişanı olan uydurma cavablar verilir; sonradan həmin nişana müraciət edən bu cavabları oxumuş olur | söndürülüb |
| RBL siyahısının təqdim edilməsi | Blok siyahısı ayrıca, tokenlə qorunan ünvanda sadə ünvan siyahısı və ya JSON şəklində təqdim olunur — HAProxy, OPNsense və URL siyahılarını oxuyan istənilən şəbəkə ekranı üçün | aktiv |
İlkin ayarı bildirmək, söndürülüb və ya Seçim olan bütün funksiyalar qəsdən belə təqdim edilir: bloklamanı aktivləşdirən şəxs bunu bir neçə gün ərzində kimlərin həmin qaydaya düşdüyünü müşahidə etdikdən sonra etməlidir — sadəcə ilkin ayar belə olduğu üçün deyil.
Təhlil: yeddi gün ərzində nümunələr üzrə qeydə alınan hadisələr. Ən hündür sütun .env fayllarının axtarışına aiddir.
RBL siyahıları: bloklama məlumatlarının standartlaşdırılmış təqdimat üsulu
RBL Real-time Blackhole List sözlərinin abreviaturasıdır. Bu anlayış mail dünyasından gəlir; orada Spamhaus və digərləri doxsanıncı illərdən bəri zərərli göndərən ünvanların siyahılarını dərc edir. Prinsip olduqca sadədir və məhz buna görə geniş yayılıb: hər sətirdə bir ünvan, HTTP ilə əldə edilə bilən, müntəzəm yenidən yüklənən. Əvvəlcə analiz edilməli format yoxdur, alət tələb edən interfeys yoxdur.
Demək olar ki, hər bir şəbəkə ekranı və əks proksi belə siyahını oxuyub onun əsasında qaydalar yarada bilir. İstehsalçılar buna müxtəlif adlar versələr də, mexanizm hər yerdə eynidir:
- OPNsense və pfSense — URL Table Alias: ünvan siyahısını HTTP vasitəsilə yükləmək, onu təhlükəsizlik divarı qaydalarında ləqəb kimi istifadə etmək, saatlıq və ya gündəlik yeniləmək
- HAProxy — ACL faylları və Maps:
http-request denyqaydasındasrc -f sperrliste.txt, yenidən başlatmadan icra zamanı API vasitəsilə yenidən yüklənə bilər - nginx — ünvan faylı qoşulmuş geo modulu və ya yaradılmış
includefaylındandenydirektivləri - Fortinet FortiGate — External Block List və ya Threat Feed: təhlükəsizlik divarının IP siyahısını əldə edib siyasətlərdə istifadə etdiyi URL
- Palo Alto Networks — External Dynamic List (EDL): eyni prinsip, təhlükəsizlik siyasətlərində ayrıca obyekt növü kimi
- Check Point — URL vasitəsilə Custom Intelligence Feeds və IP Block Lists
- Cisco Secure Firewall (Firepower) — öz siyahı mənbələri ilə Security Intelligence Feeds
- Sophos Firewall — Third-Party Threat Feeds: bloklama qaydaları üçün mənbə kimi URL-dən alınan ünvan siyahıları
- Juniper SRX — məlumat axınlarından alınan Dynamic Address Entries
- MikroTik RouterOS — skript və
fetchvasitəsilə URL-dən doldurulan Address Lists - CrowdSec — dəstəklənən istənilən sistemdə Bouncer komponentləri üçün mənbə kimi öz siyahılarınız
Web RBL bloklama siyahısını məhz bu formatda təqdim edir. Təhlükəsizlik divarı paketləri veb serverə çatmamış atır — bununla yanaşı, eyni ünvandan gələn digər cəhdləri də, məsələn, poçt serverinə və ya VPN şlüzünə giriş cəhdlərini də dayandırır.
Hər iki istiqamətdə, amma doğru yerdə
Bu üsul əks istiqamətdə də işləyir: Web RBL-ə istənilən RBL siyahısını əlavə etmək olar — bir URL, bir səviyyə, vəssalam. Tor çıxış qovşaqları, Spamhaus DROP, FireHOL və blocklist.de əvvəlcədən sazlanıb, digərləri isə üç kliklə əlavə olunur. Modul hər siyahını ünvan aralıqlarına ayırır və hər sorğunu bir neçə mikrosaniyə ərzində onlarla tutuşdurur.
Bununla belə, kənar siyahıları serverin qarşısındakı təhlükəsizlik divarında istifadə etmək daha məqsədəuyğundur. Bunun üç səbəbi var. Təhlükəsizlik divarı yalnız HTTP-ni deyil, bütün xidmətləri görür — Spamhaus siyahısındakı ünvan poçt serverinə və VPN-ə də daxil ola bilməməlidir. O, bağlantı qurulmazdan əvvəl paket səviyyəsində trafiki kəsir və bununla tətbiq serverinə heç bir yük yaratmır. Üstəlik, belə siyahılar onsuz da orada idarə olunur; tətbiqdəki ikinci nüsxə köhnələ biləcək ikinci bir mənbə deməkdir.
Bəs siyahılar modulun daxilində nəyə lazımdır? Təhlükəsizlik divarının bacarmadığı işlərə. O, giriş formasını tanımır. Web RBL Tor siyahısındakı ünvana hesaba girişi qadağan edib saytı yenə də göstərə bilər — anonim oxumaq istəyənə icazə verilməlidir, anonim şəkildə parolları bir-bir sınamaq istəyənə isə yox. Həmçinin siyahıdakı ünvandan uğurlu girişi şübhəli hal kimi bildirə bilər. Hər iki imkan üçün siyahı girişin baş verdiyi yerdə olmalıdır.
İntuisiyaya deyil, qiymətləndirməyə əsaslanmaq
Bir dəfə /wp-login.php yoluna sorğu göndərən ünvanla iki gün ərzində üç domendə beş fərqli nümunəyə uyğun sorğular göndərən ünvan eyni deyil. Web RBL bunu 0-dan 100-ə qədər balla qiymətləndirir — yalnız öz müşahidələrinə əsasən, kənar xidmət və xaricə sorğu göndərmədən.
Bir qeyd: 99 uyğunluq, 84 bal və aydın dildə əsaslandırma — ən ağır nümunə, beş müxtəlif ciddi nümunə, iki şübhəli gün, iyirmidən çox uyğunluq.
Qiymətləndirmə iki şeyi müəyyən edir. Tənzimlənə bilən dəyərdən etibarən giriş qadağandır — veb sayt oxunaqlı qalır, lakin artıq giriş məlumatlarını axtarmış şəxs tapdıqlarını sınamaq imkanı əldə etmir. Və qiymətləndirməsi olan ünvandan edilən uğurlu giriş bildirilir: onda kimsə artıq təxmin etmir, bilirdi. Ya səlahiyyətli istifadəçi səfərdə idi, ya da giriş məlumatları itib — modul bunu həll etmir, soruşa biləcək birinin qarşısına qoyur. Parolun özünə isə heç vaxt toxunulmur.
40 və daha yüksək bala görə süzülmüş bloklama siyahısı: hər ünvan üzrə uyğunluqların sayı, şübhəli günlər, aidiyyəti domenlər və son sorğu yolu.
Web RBL nəyi qoruyur — qorumanın təfərrüatları
1. Giriş məlumatları aşkar edilmir
Ölçmələrdə ən böyük hücum kateqoriyası Odoo-dakı boşluqları deyil, açıqda qalmış məxfi məlumatları axtarır. On yeddi gün ərzində:
.envfayllarına 57.721 sorğu — bu fayllarda verilənlər bazası parolları, API açarları və sessiyanın məxfi açarları saxlanılır- Konfiqurasiya fayllarına 5.535 sorğu
- Bulud xidmətlərinə giriş məlumatlarına 4.388 sorğu:
credentials.json,service-account.json,firebase-adminsdk.json,rclone.conf,.git-credentials .gitqovluqlarına 2.811 sorğu — belə qovluq tapan şəxs bütün mənbə kodunu dəyişiklik tarixçəsi ilə birlikdə endirir- Reyestrlərin və açar adlarının göstərildiyi
.github/workflows/deploy.ymlvə ya.gitlab-ci.ymlkimi yığma təlimatlarına 1.907 sorğu
Burada həlledici olan sorğuların sayı deyil, fərqli ünvanların sayıdır: /credentials.json üçün 98, /.git-credentials üçün isə 92 ünvandan sorğu gəlib. Bu, tək bir skaner deyil, bütün dünyada eyni vaxtda tətbiq olunan standart üsullar toplusudur.
2. Giriş cəhdləri nəticəsiz qalır — həmişəlik
Odoo-da parolların ardıcıl sınanmasını ləngidən daxili mexanizm var. Onun Odoo-nun mənbə kodunda sənədləşdirilmiş üç məhdudiyyəti mövcuddur: sayğac işçi prosesin operativ yaddaşında saxlanılır və hər yenidən başlatmada sıfırlanır, bloklamaq əvəzinə yalnız ləngidir və yalnız parol yoxlamasına qədər çatan cəhdləri sayır.
Web RBL eyni nöqtələrdə işə qoşulur, amma məlumatları verilənlər bazasına yazır. Bunun sayəsində:
- Sayğacın vəziyyəti hər yenidən başlatmadan sonra saxlanılır və bütün işçi proseslər üçün keçərlidir
- Hər iki yol izlənilir:
/web/logingiriş forması və/xmlrpc/2/commonilə/jsonrpcinterfeysləri - Parol yoxlamasına heç çatmayan cəhdlər də qeydə alınır — məsələn, etibarlı sessiya identifikatoru olmadan giriş cəhdləri
- Verilənlər bazası idarəetmə alətinə uğursuz giriş də sayılır; bu, giriş cəhdlərinin ən ciddisidir
Giriş cəhdləri üçün hədd on olaraq təyin edilib və bunun səbəbi ölçmə nəticəsidir: on yeddi gündə baş vermiş doqquz uğursuz girişin əksəriyyəti müştərilərə aid idi. Onlar başqa cihazda girişi özləri sazlayarkən yanlış domen yazmışdılar — bir halda öz domenlərini nöqtə əvəzinə defislə daxil etmişdilər. İlk uğursuz cəhddə bloklama tətbiq edilsəydi, hücumçular deyil, sazlama aparan müştərilər zərər görəcəkdi.
Server artıq “bir az gözləyin” cavabı verdiyi halda cəhdlərini davam etdirən isə dərhal bloklanır. İnsan bu mesajı oxuyub gözləyir; ona məhəl qoymayan proqramdır. Həddi sıfır olan ayrıca nümunə məhz bu halı tutur və heç bir həmkarı səhvən hədəfə ala bilməz: bu mərhələyə yalnız artıq on uğursuz cəhd etmiş və bundan sonra da davam etmiş şəxs çatır.
3. Hücum artıq serverə yük yaratmır
Modul quraşdırılmazdan əvvəl /@fs/../../.env kimi yola yoxlama sorğusu serverə baha başa gəlirdi: Odoo xəta səhifəsini axtarıb formalaşdırır, ünvanı qurarkən nöqtəli yol seqmentlərində xəta ilə üzləşir, sonra isə xəta səhifəsinin xəta səhifəsini də göstərə bilmir. Hər yoxlama sorğusuna iki stek izi. On yeddi gündə 28.401 belə xəta və bunların ardınca yaranan daha 9.467 xəta qeydə alınıb.
Web RBL ir.http._match mərhələsində, yəni marşrutlaşdırmadan əvvəl işə qoşulur. Cavab şablonsuz, bloklama yoxlamasından əlavə verilənlər bazasına müraciət edilmədən və jurnala sətir yazılmadan verilir. İcazə siyahısı, təhdid siyahıları və ölkə qaydaları üzrə yoxlama keşdəki sıralanmış ünvan aralıqları əsasında aparılır — hətta otuz mindən çox aralıq olduqda belə, cəmi bir neçə mikrosaniyəyə.
4. Təhlükəsizlik divarı hücumçunu serverə çatmamış dayandırır
Bloklama siyahısı RBL siyahısı kimi dərc olunur və HAProxy ilə OPNsense onu birbaşa oxuyur. Beləliklə hücumçu veb serverə ümumiyyətlə çatmır — eyni hostdakı başqa heç bir xidmətə də. Bir dəfə zərərli kimi tanınan giriş beləliklə bütün maşını geriyə dönük qoruyur.
Üç səviyyə: bloklamaq, saymaq, bildirmək
Mövcud olmayan ünvana göndərilən hər sorğu hücum deyil. Buna görə Web RBL üç səviyyə ayırır və kodu dəyişmədən hər nümunənin səviyyəsini ayrıca dəyişmək mümkündür.
| Səviyyə | Qaydanı işə salan sorğu | Ünvan üçün nəticə |
|---|---|---|
| bloklamaq | rədd edilir | 24 saatlıq bloklanır, üç şübhəli gündən sonra isə daimi bloklanır |
| saymaq | buraxılır | yalnız qeydə alınır, bloklanmır |
| bildirmək | buraxılır | aşkarlanan halın təsviri ilə qeydə alınır, heç vaxt bloklanmır |
Təhdid siyahıları və ölkələr üçün dördüncü səviyyə də var: hesaba girişi qadağan etmək. Saytı oxumaq mümkün qalır, giriş forması və interfeyslər isə bağlanır. Bu, şübhəli olsa da, mütləq zərərli sayılmayan hər şey üçün orta yoldur — Tor, məlumat mərkəzinin ünvan aralığı, müştərisi olmayan ölkə.
Hansı hücumlar aşkarlanır
Bütün nümunələr real trafik üzərində yoxlanılıb. Fərqli ünvanların sayı qəsdən yanında göstərilir — bu say nümunənin tək bir skaneri, yoxsa geniş yayılmış üsulu aşkarladığını göstərir.
| Hücum kateqoriyası | Sorğular | Ünvanlar |
|---|---|---|
.env məlumatlarının ələ keçirilməsi | 57.721 | 223 |
| PHP yoxlama sorğuları | 12.237 | 256 |
| Dəyərli hədəfə yönəlmiş qovluq sərhədlərini aşma cəhdləri | 10.046 | 64 |
| Konfiqurasiya faylları | 5.535 | 114 |
| Bulud xidmətlərinə giriş açarları | 4.388 | 152 |
| WordPress yoxlama sorğuları | 3.366 | 385 |
.git məlumatlarının ələ keçirilməsi | 2.811 | 255 |
| Odoo haqqında kəşfiyyat (verilənlər bazası idarəetmə aləti, versiya sorğusu) | 2.500 | 213 |
Süni intellekt alət zəncirləri və əmrlərin icrası (/mcp, /api/fs/exec) | 2.450 | 74 |
| Yığma təlimatları (CI/CD) | 1.907 | 88 |
| GraphQL son nöqtələri | 1.878 | 71 |
Ən yeni kateqoriya xüsusilə diqqət çəkir. /api/fs/exec yoluna 54 fərqli ünvandan 369 dəfə sorğu göndərilib — bu, məlumat oxumaq deyil, əmrləri icra etmək cəhdidir. İki il əvvəl belə hədəflər yox idi; onlar yeni süni intellekt alətlərinin və tapşırıq növbələrinin interfeyslərindən qaynaqlanır. Müdafiəsini yalnız WordPress və PHP-yə yönəldən bunları görmür. Buna uyğun olaraq bu kateqoriyanın qiymətləndirmədə çəkisi böyükdür.
Təhdid siyahıları və mənşə ölkəsi
Dörd siyahı, 32.851 ünvan aralığı, hamısı “yalnız bildir” rejimində. Hər əlavə siyahı üçün bir ünvan və bir səviyyə kifayətdir.
Kənar siyahı başqasının bizə məlum olmayan səbəblərlə, heç görmədiyimiz trafik haqqında irəli sürdüyü iddiadır. O, yanlış, köhnəlmiş və ya başqa məqsəd üçün nəzərdə tutulmuş ola bilər: blocklist.de əsasən başqa sistemlərdə SSH giriş məlumatlarını ardıcıl sınayan ünvanları toplayır, bu isə veb server haqqında çox az şey deyir. Buna görə Web RBL kənar siyahıları öz bloklama siyahısından ayrı saxlayır və ilkin rejim bildirmək olaraq təyin edilir. Öz icazə siyahımız isə həmişə üstün tutulur: tanıdığımız müştəri üçüncü tərəfin qiymətləndirməsindən daha önəmlidir.
Hər uyğunluq və hər ünvan üçün mənşə ölkəsi göstərilir. Qiymətləndirmə zamanı bu məlumat əvəzsizdir — öz ölkəmizdən səhər saat onda edilən giriş cəhdi ilə bircə müştərimizin belə olmadığı ölkədən edilən cəhd eyni deyil. Amma ölkəyə görə hamını bloklamaq üçün bu məlumat o qədər də yararlı deyil və öz rəqəmlərimiz də bunu göstərir: siyahımızdakı hücumçular əsasən Belçika, Finlandiya və Niderlanddakı bulud infrastrukturu aralıqlarından gəlirdi. Almandilli məkanın xaricindəki hər şeyi bloklamaq onlara təsir etməyəcəkdi — əvəzində məzuniyyətdə olan öz əməkdaşlarımızı və işgüzar səfərdə olan müştərilərimizi bloklayacaqdı.
Ölkə qaydaları ilkin olaraq boş verilir və görünüşdə bunun səbəbi izah olunur.
Yanlış sazlamaları bloklamaq əvəzinə bildirmək
Real trafikdə ən çox rast gəlinən hal nə hücumdur, nə də ziyarətçi, veb serveri başqa bir xidmət hesab edən nasaz proqramdır:
- QNAP NAS-ın veb interfeysinə 1.367 sorğu — hədəf ünvanı artıq düzgün olmayan sinxronizasiya proqramı. Tək bir internet xəttindən 962 dəfə müraciət edilib.
- 65 Autodiscover sorğusu — veb domeni öz Exchange serveri hesab edən Outlook
Belə ünvanlar heç vaxt bloklanmır. Bloklama nasazlığı aradan qaldırmır, onu gizlədir — və onsuz da cihazı yanlış sazlanmış şəxsə zərər vurur. Bunun əvəzinə aşkarlanan halın təsviri və aidiyyəti domenlərlə birlikdə qeyd yaradılır. İstəyə görə bu qeyddən avtomatik dəstək müraciəti açılır: hər ünvan üçün yalnız bir müraciət. Müraciət bağlandıqdan sonra ünvan yenidən diqqət çəkərsə, ikinci müraciət yaratmaq əvəzinə həmin müraciət yenidən açılır.
QNAP, Synology, Exchange-Autodiscover, ActiveSync, eləcə də WebDAV, CalDAV və CardDAV müştəri proqramları aşkarlanır. Aşkarlama şablonlarında sadəcə uzantılar deyil, dəqiq fayl və qovluq adları göstərilir: eyni /cgi-bin/ qovluğunda zərərsiz sinxronizasiya sorğuları ilə yanaşı printenv.pl kimi ünvanlara yönələn klassik zondlama sorğuları da olur.
İcazə siyahısı: heç vaxt bloklanmayan ünvanlar
Səhvin qiyməti bütün ünvanlar üçün eyni deyil. Məlumat mərkəzindən olan skaner üçün yanlış həyəcan heç nəyə başa gəlmir. Filial tunelinin qarşı tərəfi üçün isə filiala başa gəlir.
Buna görə birinci siyahıdan əvvəl yoxlanılan ikinci siyahı var: heç vaxt bloklanmayan ünvanlar və şəbəkələr. Bu siyahı müşahidəni dayandırmır — oradakı ünvanlar yenə yoxlanılır və qeydə alınır, yalnız bloklama tətbiq olunmur. Təhlükəsizlik divarındakı istisnadan fərqi də budur: o, nə baş verdiyini görməyə mane olur, bu isə sadəcə daha dözümlü davranmağa imkan verir.
Siyahı hər gün iki mənbədən doldurulur: bütün VPN tərəfləri ilə birlikdə təhlükəsizlik divarının özündən — yeni qurulmuş tunelin işləməsi kiminsə bloklama siyahısını yada salmasından asılı olmasın deyə — və Google ilə Microsoft-un öz veb tarama botları üçün dərc etdiyi ünvan aralıqlarından. Həqiqi Googlebot-u özünü belə adlandıran skanerdən yalnız bu yolla ayırmaq olar. Axtarış sistemləri heç vaxt bloklanmamalıdır; onları bloklayan öz saytını geri dönüşü olmadan indeksdən çıxarır.
Burada tutuşdurmadan da vacib bir qayda var: boş cavab heç vaxt silinməyə səbəb olmur. Mənbə cavab vermirsə, boş və ya anlaşılmaz cavab verirsə, siyahı dəyişməz qalır. Nasazlıq zamanı öz-özünə boşalan icazə siyahısı mümkün olan ən pis anda bütün tunelləri də sıradan çıxarar.
İcazə siyahısındakı qeyd bir müştəri ilə əlaqələndirilibsə, onun şəbəkəsindən gələn hər uyğunluq həmin müştəriyə aid edilir. Beləliklə, ünvanları ayrıca axtarmağa ehtiyac qalmadan yanlış sazlama ilə bağlı dərhal əlaqə saxlanılacaq şəxs məlum olur.
Məcburi məlumatlar və avtomatlaşdırılmış məlumat toplayıcıları
Saytın hüquqi məlumatlar səhifəsi adi səhifə deyil. O, insanlar üçün əlçatan qalmalıdır, çünki onu bloklamaq məhz məlumat toplayıcısının axtardığı pozuntunu yaradır. Eyni zamanda, ad və ünvanın göstərildiyi səhifə olduğu üçün avtomatlaşdırılmış məlumat toplamanın da hədəfidir.
Avstriyada saytlara qoşulmuş Google şriftləri ilə bağlı hüquqi xəbərdarlıq dalğası zamanı jurnallar göstərdi ki, məktublar ayrı-ayrı ziyarətlərə deyil, avtomatlaşdırılmış kütləvi yoxlamaya əsaslanırdı: bir-biri ilə əlaqəsi olmayan müxtəlif hostlara millisaniyə fasilələrlə müraciət edilmişdi.
Web RBL bunu istisna yaratmaq əvəzinə səviyyəni aşağı salmaqla həll edir. Əsas yol olan /impressum heç bir nümunəyə uyğun gəlmir və həmişə əlçatan qalır. Odoo saytında mövcud ola bilməyən /impressum.php kimi alternativ yazılışlar barədə bildiriş verilir. Avtomatlaşdırılmış məlumat toplanmasına dözmək istəməyən isə bir parametri dəyişir. sitemap və robots bundan istisnadır və ümumiyyətlə bloklana bilməz: onlarda şəxsi məlumat yoxdur və onları əldə etmək hər axtarış sistemi botunun işidir.
Domen və identifikator: giriş jurnalında çatışmayan məlumatlar
werkzeug giriş jurnalı nə müraciət edilən hostu, nə də sorğu göndərənin identifikatorunu qeydə alır. Əlbəttə, Odoo hər ikisini alır — host olmasa, bir neçə sayt arasından düzgün olanı seçə bilməzdi. Amma sonradan bu məlumatlara baxmaq mümkün olmur.
Web RBL hər uyğunluq üçün hər iki məlumatı saxlayır. Bu, başqa cür cavablandırılması mümkün olmayan iki suala cavab verir: yanlış sazlama hansı sayta müraciət edir — deməli, domen hansı müştəriyə məxsusdur — və bir ünvan yalnız bir saytı ziyarət edir, yoxsa hamısını. Eyni ünvandan bir-biri ilə əlaqəsi olmayan bir neçə domenə müraciət edilməsi kütləvi yoxlamanın əlamətidir və qiymətləndirmə balını artırır.
İdentifikatorun nə qədər əhəmiyyətli olduğunu saytlarımızdan birində aparılan təhlil göstərdi: orada ümumi trafikin yetmiş faizindən çoxu yüzdən artıq ünvandan sorğu göndərən tək bir mənbənin payına düşürdü. İdentifikator olmasaydı, bu, paylanmış məlumat toplama botuna bənzəyərdi. Bu, OpenAI-nin veb tarama botu GPTBot idi — o, dönə-dönə robots.txt faylını sorğulayır və qaydalara tam əməl edirdi.
Təhlükəsizlik məsələləri ətraflı
1. Proksinin aşkarlanması — ən təhlükəli məqam
Odoo əks proksi arxasında işləyirsə və proxy_mode yanlış təyin edilibsə, modul hər sorğuda eyni ünvanı — proksinin ünvanını görür. Bu halda bloklama bütün ziyarətçilərin girişini eyni anda bağlayar.
Buna görə Web RBL hər blokdan əvvəl ünvanın müəyyən edilməsinin
etibarlı olub-olmadığını yoxlayır. O, proxy_mode-u yönləndirmə
başlığı ilə birlikdə tələb edir, proxy_mode olmadan yönləndirmə
gəldikdə işləməkdən imtina edir və eyni şəkildə
birdən çox aralıq proxy olduqda imtina edir. Şübhə olduqda bloklanmır.
2. Öz şəbəkələrimiz heç vaxt bloklanmır
Özəl ünvan aralıqları, Loopback, Link-Local və CGNAT daimi istisnadır. Onlar heç bir halda, hətta əl ilə də siyahıya salına bilməz. Kənar siyahılara da eyni qayda tətbiq olunur: özəl və rezerv edilmiş aralıqlar, eləcə də həddən artıq böyük şəbəkələr siyahı oxunarkən kənarlaşdırılır.
3. Modulun öz xətası saytı sıradan çıxarmamalıdır
Bütün yoxlama istənilən xətanı tutan qoruyucu mexanizm daxilində aparılır. Burada baş verən nasazlıq jurnala yazılır, sorğu isə dəyişdirilmədən davam edir. Öz xətası üzündən saytı sıradan çıxaran qoruma modulu heç bir qorumanın olmamasından da pisdir. Bundan əlavə, sorğunun emalı zamanı bütün verilənlər bazası sorğuları ziyarətçinin brauzer dili tətbiq edilmədən və tərcümə edilmiş sahələrə görə sıralama aparılmadan icra olunur — sistemi quraşdırılmamış dildə istifadə edən ziyarətçi yoxlamanın uğursuz olmasına səbəb olmamalıdır.
4. Bloklamadan əvvəl müşahidə
Quraşdırıldıqdan sonra adi sorğular zamanı siyahıdakı ünvanların bloklanması söndürülmüş olur. Yoxlama sorğuları rədd edilir və qeydə alınır, qalan sorğular isə buraxılır. Beləliklə, kiminsə girişini bağlamazdan əvvəl bir neçə gün ərzində siyahıya həqiqətən kimlərin düşdüyünü izləmək mümkündür. Davranışın aşkarlanması, təhdid siyahıları və ölkə qaydaları üçün də eyni prinsip keçərlidir: əvvəlcə bildiriş, nəzərdən keçirdikdən sonra bloklama.
5. Geniş əhatə əvəzinə dəqiq nümunələr
Ziyarətçinin səhvən hücumçu sayılması gözdən qaçan yoxlama sorğusundan daha baha başa gəlir. Buna görə hər nümunənin öz səviyyəsi var və bu səviyyə hər nümunə üçün ayrıca dəyişdirilə bilər. Təkcə fayl uzantısı nadir hallarda kifayət edir: .php üçün 14.012 həqiqi yoxlama sorğusuna qarşı cəmi bir neçə köhnə keçid var, .asp üçün isə nisbət əksinədir. Belə qərarlar təxminə deyil, ölçmələrə əsaslanmalıdır.
6. Əl ilə verilən icazə qüvvədə qalır
Bir ünvanı blokdan çıxaran şəxsin bunun üçün səbəbi olub. Növbəti aşkarlama bu qərarı xəbərsiz şəkildə ləğv etmir.
7. Siyahı qorunur, amma məxfi deyil
Son nöqtəyə müraciət üçün token tələb olunur. Etibarlı token olmadıqda cavab olaraq 403 əvəzinə 404 qaytarılır — beləcə, həmin ünvanın mövcudluğu belə təsdiqlənmir. Müqayisə sabit vaxtda aparılır. Siyahının özündə məxfi heç nə yoxdur: o, bizə öz təşəbbüsü ilə müraciət etmiş ünvanlardan ibarətdir.
8. Qeydlərdə məxfi məlumat yoxdur
Uğursuz giriş cəhdlərində istifadə edilmiş istifadəçi adı qeydə alınır, parol isə heç vaxt yazılmır. Verilənlər bazası idarəçisinə ötürülən dəyərlərdən heç nə oxunmur: orada ilk sırada əsas parol dayanır, bloklama siyahısına yazılan qeyd isə verilənlər bazasının hər ehtiyat nüsxəsinə düşür. GeoLite2 lisenziya açarı yalnız sistem parametrində saxlanılır və heç bir jurnal sətrinə yazılmır.
9. Tələ yararlı heç bir məlumat vermir
İstəyə bağlı olaraq Web RBL yoxlama sorğularına unikal izləmə nişanı olan uydurma məzmunla cavab verir. Sonradan həmin nişanla sorğu göndərən şəxs saxta cavabı oxuyub və ona əsasən hərəkət edib — burada yanlış həyəcan ehtimalı yoxdur. Tələlərdə istifadə oluna biləcək məlumatlar, həqiqi yollar və etibarlı giriş məlumatları yoxdur. Bu funksiya ilkin olaraq söndürülmüş vəziyyətdə təqdim edilir, çünki o, sistemin kənardan görünən davranışını dəyişir.
Modul nələri edə bilmir
O, nə şəbəkə təhlükəsizlik divarını, nə də veb tətbiq təhlükəsizlik divarını əvəz edir. Yollarda məlum yoxlama nümunələrini, uğursuz giriş cəhdlərini və şübhəli davranışı aşkarlayır, lakin formalara hücumları və parametrlərə zərərli məzmun yeritmə cəhdlərini aşkarlamır.
Üstəlik, o, yalnız HTTP üzərindən geri gələn sorğuları görür. Hücumçunun ələ keçirdiyi verilənlər bazası və ya poçt qutusu giriş məlumatları ilə nə etdiyi görünmür — məhz buna görə izləmə nişanları giriş məlumatları deyil, yollardır.
O, diqqətli davranmaq zərurətini də aradan qaldırmır: .env yoxlama sorğularını rədd edən modul səhvən açıq yayımlanmış .env faylını təhlükəsiz etmir.
Əlçatanlıq
Web RBL AGPL-3 lisenziyası ilə hamı üçün açıqdır və bizim beş veb saytımızda real iş mühitində istifadə olunur:
github.com/Alex0176/odoo-web-rbl
Modul üçün Odoo 19 Community tələb olunur və onun base və web xaricində heç bir asılılığı yoxdur. Müraciət sistemi ilə inteqrasiya istəyə bağlıdır və konkret bir sistem tələb etmir; belə sistem yoxdursa, sadəcə heç bir əməliyyat aparılmır. Mənşə ölkəsini müəyyən etmək üçün MaxMind şirkətinin pulsuz GeoLite2 verilənlər bazası lazımdır; o olmadıqda sahə boş qalır, qalan hər şey isə əvvəlki qaydada işləyir.
Əlavə oxu: Web RBL-in təhlükəsizlik divarı, iki faktorlu autentifikasiya və giriş icazələri ilə birlikdə tam təhlükəsizlik arxitekturasına necə daxil edilməsi — addım-addım təlimatla: Odoo 19 təhlükəsizlik arxitekturasının elementlərini düzgün birləşdirmək.
Suallarınızı, qeydlərinizi və xəta bildirişlərinizi məmnuniyyətlə qəbul edirik — ən yaxşısı onları GitHub-da Issue kimi açmaqdır.