Odoo 19 təhlükəsizlik arxitekturası: Firewall, 2FA, səlahiyyətlər və Web RBL-in düzgün birləşdirilməsi

Odoo beş veb saytımızda açıq internetdən əlçatandır və bu istisna deyil, normal haldır: təklif, mağaza və ya müştəri girişi təqdim edən hər kəsin ictimai serveri var. Tək bir həssas parol, unudulmuş bir konfiqurasiya faylı və ya həddindən artıq səxavətli bir səlahiyyət ictimai serveri açıq serverə çevirmək üçün kifayətdir.

Bu yazı Odoo 19-u düzgün necə qorumağı göstərir — tək bir tədbirlə deyil, bir-birini tamamlayan bir neçə qatla: firewall və reverse proxy, açıq mənbəli modulumuz Web RBL, iki faktorlu autentifikasiya, parol siyasəti və səlahiyyətlər — və bunlardan hər birinin əslində hansı hücum cəhdlərini tutduğunu. Sonda hər kəsin öz Odoo quraşdırmasında təkrar edə biləcəyi addım-addım təlimat durur.

Dərinlikdə müdafiə: nə üçün tək bir tədbir heç vaxt kifayət etmir

Hər bir təhlükəsizlik tədbirinin boşluğu var. Firewall Odoo giriş formasında baş verənləri görmür. Güclü parol onsuz da başqa yerdə oğurlanıbsa qoruya bilməz. Səlahiyyət strukturu hələ ümumiyyətlə daxil olmamış hücumçuya qarşı heç nə etmir. Bu boşluqları bağlayan prinsip dərinlikdə müdafiə (defense in depth) adlanır: bir neçə müstəqil qat, onlardan hər biri təkbaşına yan keçilə bilər — amma hamısı birlikdə yox.

Bizdə dörd qat var, hər birinin fərqli vəzifəsi var:

• Firewall / Reverse Proxy — açıq-aşkar zərərli olanı server üçün ümumiyyətlə çatmamış uzaq tutur
• Web RBL — hər iki tərəfi birləşdirir: Odoo firewall-ın heç görə bilmədiyini öz tətbiq jurnalından öyrənir və onu geri ona ötürür
• Odoo-nun özü — iki faktorlu autentifikasiya, parol siyasəti, səlahiyyətlər, sessiya idarəetməsi
• Verilənlər bazası & istismar — ehtiyat nüsxə, idarəetməyə girişin qorunması, sirlərin hər hansı jurnaldan kənarda saxlanması

Növbəti bölmələr hər qatı ayrı-ayrılıqda nəzərdən keçirir.

Qat 1: Firewall və reverse proxy

Firewall sorğunu görən ilk instansiyadır və hücumçunu serverdəki hər xidmətdən uzaq tuta bilən yeganə instansiyadır — təkcə veb saytdan deyil, həm də mail serverdən, VPN girişindən və öz idarəetmə interfeysindən. Bu nöqtədə nəyin məqsədəuyğun aktivləşdirildiyi istehsalçıdan asılıdır, lakin tikinti formaları OPNsense, pfSense, HAProxy, FortiGate, Sophos və ya Check Point-də eynidir:

RBL siyahıları: reputasiyanın çatdırıldığı standart yol

RBL Real-time Blackhole List sözlərinin abreviaturasıdır, mail dünyasından gələn anlayış: hər sətirdə bir ünvan, HTTP ilə əldə edilə bilən, müntəzəm yenidən yüklənən. Praktiki olaraq hər firewall belə bir siyahını oxuyub ondan qaydalar yarada bilər — OPNsense və pfSense URL Table Alias kimi, HAProxy ACL faylı kimi, FortiGate External Block List kimi, Palo Alto External Dynamic List kimi, Cisco, Sophos, Juniper və MikroTik eyni prinsip üçün öz adları ilə.

Məhz burada öz modulumuz işə qoşulur — və məhz burada ikinci qat başlayır.

Qat 2: Web RBL — tətbiq ilə firewall arasında körpü

Firewall paketləri görür, tətbiq məntiqini yox. O, /xmlrpc/2/common sorğusunun giriş cəhdi olduğunu, on dörd saniyə ərzində iyirmi fərqli yolun skaner olduğunu və ya bir ünvanın az əvvəl parolu uğurla təxmin etdiyini bilmir. Bütün bunları yalnız Odoo-nun özü bilir. Web RBL, öz açıq mənbəli modulumuz (AGPL-3), bu biliyi istifadəyə yararlı edir — Odoo-nun özü üçün və RBL siyahısı kimi təqdim edilərək, onun qarşısındakı firewall üçün də.

Təhdid siyahıları fasiləsiz müqayisə olunur, hər biri öz səviyyəsi ilə.

Əvvəlki yazıda ətraflı təsvir ediləni qısaca yekunlaşdıraq:

• Yollarda şablonların aşkarlanması: .env faylları, .git qovluqları, konfiqurasiya faylları, WordPress və PHP zondları, yol traversalı, yeni süni intellekt interfeysləri vasitəsilə əmrlərin icrası
• Yenidən başlatmalardan sonra da sayan giriş müdafiəsi — Odoo-nun əməli yaddaşda yaşayan öz sayğacından fərqli olaraq
• Hər ünvanın açıq mətnlə əsaslandırılmış, 0-dan 100-ə qədər qiymətləndirilməsi
• Yanlış konfiqurasiyalar (QNAP, Autodiscover, Synology) aşkar edilir və heç vaxt bloklanmır, çünki blok qüsuru aradan qaldırmır, yalnız gizlədir
• Spamhaus, FireHOL və Tor çıxış qovşaqları kimi kənar təhdid siyahıları, fasiləsiz müqayisə olunur
• Heç vaxt bloklanmaması lazım olan ünvanlar üçün icazə siyahısı

Bu yazı üçün iki xüsusiyyət xüsusilə vacibdir, çünki onlar birbaşa firewall və girişlə bağlıdır.

Ətalətli siyahı etibar edilə bilən siyahıdır

İcazə siyahısı — heç vaxt bloklanmayan ünvanlar, məsələn öz filial bağlantılarımız — qaydaya görə nadir hallarda dəyişir. Məhz bu onun dəyəridir, çatışmazlığı deyil: sakit siyahı günlərlə demək olar ki, tərpənmirsə, hər nadir dəyişiklik dərhal nəzərə çarpır. Gündəlik avtomatik yeniləmə çox şeyin dəyişəcəyi üçün mövcud deyil, nadir dəyişikliyin əllə əlavə edilməsinə ehtiyac qalmaması üçün mövcuddur — məhz bu, insanın onu unutduğu nöqtədir. Keçən ay öz yanlış konfiqurasiyalarımızdan biri məhz belə nəzərə çarpdı: çoxlu hadisə ilə yox, müştərinin QNAP veb API-si səhvən bloklanana qədər heç kimin tanımadığı o tək hadisə ilə. O vaxtdan bəri QNAP heç vaxt bloklanmayan, yalnız bildirilən yanlış konfiqurasiyalar siyahısındadır.

Giriş firewall-ın görmədiyi yerdir

Firewall ünvanı bloklaya bilər. O, girişin uğurlu olub-olmadığını bilmir, bunun az əvvəl hələ giriş məlumatlarını axtarmış ünvandan gəlib-gəlmədiyini isə heç bilmir. Web RBL isə bilir: tənzimlənə bilən hədd dəyərindən yuxarı qiymətləndirmə girişi tamamilə qadağan edir və şübhəli ünvandan edilən uğurlu giriş bildirilir — bu, növbəti qata bağlayıcı həlqədir.

Qat 3: Odoo-nun özünü qorumaq

İki faktorlu autentifikasiya: təkrar istifadə edilə bilməyən ikinci sirr

Parolların ən böyük problemi onların keyfiyyəti deyil, təkrar istifadəsidir. Başqa xidmətdə oğurlanmış parol, eyni olduğu müddətcə bizdə də eyni cür işləyir. İki faktorlu autentifikasiya (2FA, TOTP də adlanır) buna ikinci sirr qarşı qoyur: hər otuz saniyədən bir dəyişən və yalnız şəxsi smartfonun bildiyi sirrdən hesablanan altırəqəmli kod. Beləliklə, oğurlanmış parol tək başına artıq kifayət etmir.

Odoo 19 Community bunu daxili olaraq təqdim edir — quraşdırıla bilən Two-Factor Authentication (TOTP) modulu kimi, e-poçt ehtiyat seçimi ilə tamamlanmış. Hər istifadəçi bunu özü üçün, QR kodu ilə, hər hansı geniş yayılmış Authenticator tətbiqi ilə qurur:

Quraşdırma: QR kodunu skan et, altırəqəmli kodu bir dəfə təsdiqlə, hazırdır.

Lakin bu tək başına yalnız onu özü quranlara kömək edir — və təcrübə göstərir ki, məcburiyyət olmadan bu azlıq olaraq qalır. Buna görə Odoo-da məcburi tətbiq siyasəti var: ya yalnız əməkdaşlar (daxili istifadəçilər) üçün, ya da portal istifadəçiləri də daxil olmaqla hamı üçün. Qurulmuş ikinci sirr olmadan heç kim giriş formasından keçə bilmir, heç olmasa e-poçt kodu ilə təsdiqləmədən.

Parol siyasəti: minimum uzunluq özlüyündə aydın deyil

Əlavə modul olmadan Odoo Community parollar üçün minimum uzunluğa əsaslanmır — heç kim mane olmasa, istifadəçi üç simvoldan ibarət parol təyin edə bilər. Öz Password Policy modulumuz məhz bu boşluğu bağlayır: yalnız brauzerdə təklif edilməyən, server tərəfində tətbiq edilən minimum uzunluq. Daha çox istəyən — məcburi müddət, təkrar istifadəyə qarşı tarixçə — bunun üçün OCA və ya üçüncü tərəf modulu tələb edir; Community versiyasında bu qəsdən sadə saxlanılıb.

Səlahiyyətlər: yalnız ehtiyacı olan giriş əldə edir

Odoo ilkin olaraq üç səviyyəni ayırır: portal istifadəçiləri (yalnız öz müştəri və ya təchizatçı portalı), daxili istifadəçilər (backend, hər tətbiq üzrə hüquqlarla) və administratorlar (texniki parametrlər daxil olmaqla məhdudiyyətsiz giriş). Ən tez-tez rast gəlinən səhv çox zəif parol deyil, həddindən artıq səxavətlə verilmiş administrator rolu olur: yalnız hesab-fakturalar yaratmalı olan şəxsə sistem parametrlərinə giriş lazım deyil.

İki prinsip yükün çox hissəsini daşıyır:

Hər ikisi iki faktorlu autentifikasiyanın da qurulduğu eyni görünüşdə yoxlanıla bilər:

Bir icmal, dörd rıçaq: parol, ikinci faktor, API açarları, daxil olmuş cihazlar.

Sessiyalar və cihazlar: hazırda kim daxil olub

Eyni görünüş hesabın hazırda hansı cihazlardan daxil olduğunu da göstərir — və tək birini və ya hamısını birdən çıxarmağa imkan verir. İtirilmiş noutbukdan və ya parolun kompromat olunduğu şübhəsindən sonra bu, ən sürətli təsirli addımdır: Sessiya parolun artıq dəyişdirilib-dəyişdirilmədiyindən asılı olmayaraq dərhal bitir.

Qat 4: Verilənlər bazası və istismar

Dördüncü qat ən az görünəni və eyni zamanda ən bağışlanmazıdır, çünki burada edilən səhv əvvəl qurulmuş hər şeyi puç edə bilər.

• Müntəzəm, yoxlanılmış ehtiyat nüsxələri, serverin özündən ayrı saxlanılır. Heç vaxt geri qaytarılmamış ehtiyat nüsxə fərziyyədir, ehtiyat nüsxə deyil.
• Sirlər heç bir jurnal faylına aid deyil. Parollar, API açarları, lisenziya məlumatları — öz əlavələrini yazan şəxs onlara əsas parolun özü kimi yanaşmalıdır: heç yerdə yazmayın, „yalnız debug üçün" də yox.
• Modulları aktual saxlayın, üçüncü tərəf modullarını da, hətta xüsusilə onları. Pulsuz əlavə modullar (OCA və digərləri) təbii olaraq yeni Odoo versiyalarından geri qalır; hər quraşdırmadan əvvəl hansı asılılıqların avtomatik gəldiyinə baxmağa dəyər.

Giriş yolu bütövlükdə

Dörd qat bir-birinin ardınca ayrı otaqlarda deyil, eyni sorğuya, pillə-pillə təsir edir. Bu, giriş nümunəsində ən aydın görünür:

Zərərli sorğunun həqiqi hədəfə çatmamış bitə biləcəyi beş yer — və səlahiyyətli istifadəçinin hamısından keçdiyi yalnız bir yer.

Hücum ssenariləri və onlara qarşı müdafiə

Aşağıdakı icmal real hücum şablonlarını onları həqiqətən dayandıran qatlara aid edir. Bunlardan bir neçəsi nəzəriyyə deyil, beş veb saytımızda on yeddi günlük real trafikdən öz müşahidələrimizdir.

Addım-addım: öz Odoo quraşdırmasını qorumaq

Aşağıdakı ardıcıllıq bizim özümüzün hərəkət edəcəyimiz ardıcıllıqdır — ən böyük təsirdən ən incə parametrə doğru.

1. İki faktorlu autentifikasiyanı məcburi etmək

1. Hələ quraşdırılmayıbsa: Apps açın, „Two-Factor Authentication" axtarın və quraşdırın (bir neçə veb sayt olduqda əlavə olaraq ehtiyat seçimi kimi „Two-Factor Authentication by Mail" tövsiyə olunur).
2. Parametrlər → Ümumi parametrlər → Səlahiyyətlər açın.
3. „İki faktorlu autentifikasiyanı məcburi et" seçimini aktivləşdirin.
4. Siyasəti seçin: daxili istifadəçilər üçün „Yalnız əməkdaşlar", portal istifadəçiləri (girişi olan müştərilər) də daxil edilməlidirsə „Bütün istifadəçilər".
5. Saxlayın. Növbəti giriş cəhdindən etibarən Odoo qurulmuş ikinci sirri olmayan hər istifadəçidən Authenticator tətbiqini quraşdırana qədər ən azı e-poçt kodunu tələb edir.

2. Parollar üçün minimum uzunluq təyin etmək

1. Apps açın, „Password Policy" axtarın və quraşdırın.
2. Parametrlər → Ümumi parametrlər → Səlahiyyətlər açın.
3. „Parolun minimum uzunluğu" təyin edin — on iki simvol ağlabatan başlanğıc dəyərdir.
4. Saxlayın. Qayda dərhal hər yeni və ya dəyişdirilmiş parol təyinatı üçün qüvvəyə minir, mövcud parollara geriyə dönük deyil.

3. Səlahiyyətləri nəzərdən keçirmək

1. Parametrlər → İstifadəçilər & Şirkətlər → İstifadəçilər açın.
2. Hər istifadəçini ayrıca açın və hər tətbiq üzrə giriş hüquqları olan vərəqi yoxlayın: Bu şəxsə həqiqətən „Manager" və ya „Administrator" lazımdır, yoxsa „İstifadəçi" kifayətdir?
3. Xüsusilə yoxlayın: Kimin „Parametrlər"-in özünə girişi var? Bu çox kiçik qrup olmalıdır.
4. Hər xarici inteqrasiya (mühasibatlıq, öz skriptləriniz, vaxt uçotu) üçün müvafiq texniki istifadəçinin „Hesab təhlükəsizliyi" vərəqində istifadəçi parolunu ötürmək əvəzinə ayrıca API açarı yaradın.

4. Web RBL-i quraşdırmaq və kəskin rejimə keçməzdən əvvəl müşahidə etmək

1. Modulu buradan github.com/Alex0176/odoo-web-rbl götürüb addon yoluna qoyun və quraşdırın.
2. Bir neçə gün müşahidə edin: Web RBL → Təhlil menyusu hansı şablonların həqiqətən işlədiyini göstərir.
3. Yalnız bundan sonra web_rbl.sperren_aktiv seçimini aktivləşdirin (Parametrlər → Texniki → Sistem parametrləri) — buradan etibarən aşkar edilmiş zondlar həqiqətən rədd edilir.
4. Bloklama siyahısını modulda göstərilən, token ilə qorunan ünvan altında firewall-a RBL siyahısı kimi qoşun (OPNsense/pfSense-də URL Table Alias, HAProxy-də ACL faylı kimi).

5. Firewall-ın özünü qorumaq

1. Firewall-ın idarəetmə interfeysini yalnız daxili şəbəkədən əlçatan edin, heç vaxt veb saytla eyni ictimai ünvandan yox.
2. İstehsalçı təklif edirsə, firewall proqram təminatı üçün avtomatik təhlükəsizlik yeniləmələrini aktivləşdirin.
3. TLS konfiqurasiyasını yoxlayın: yalnız aktual protokol versiyaları, köhnəlmiş şifrələmə üsullarını söndürün.
4. Mümkündürsə: tanınmış reputasiya siyahısını (məsələn Spamhaus DROP) birbaşa firewall-a qoşun — Web RBL-dən asılı olmayaraq, çünki firewall bununla Odoo-nun heç vaxt çatmadığı xidmətlərə gedən trafiki də görür.

6. Verilənlər bazası idarəetməsini bağlamaq

1. /web/database/manager-in xaricdən əlçatan olub-olmadığını yoxlayın — əlçatandırsa, Odoo konfiqurasiyasında list_db = False təyin edin və ya yolu firewall səviyyəsində bloklayın.
2. Verilənlər bazası idarəetməsinin əsas parolunu uzun və təsadüfi təyin edin və onu başqasının oxuya biləcəyi heç bir yerdə qeyd etməyin.

7. Ehtiyat nüsxəni yalnız qurmaq deyil, yoxlamaq

1. Odoo serverindən ayrı saxlanılan avtomatik, müntəzəm ehtiyat nüsxə qurun.
2. Ən azı bir dəfə həqiqətən geri qaytarın və bərpanın işlədiyini yoxlayın — yoxlanılmamış ehtiyat nüsxə fərziyyədir.

Bu addımların heç biri digərini əvəz etmir. Yalnız birini həyata keçirən bir qapını gücləndirib digər hamısını açıq qoyub — hamısı yeddisini həyata keçirən isə tək qat uğursuz olsa belə dayanan müdafiəyə malikdir.

Bu arxitektura nəyi əvəz etmir

Təsvir edilən tədbirlərin heç biri ehtiyatlılığı lazımsız etmir. .env zondlarını rədd edən modul səhvən dərc edilmiş .env faylını təhlükəsiz etmir. İki faktorlu autentifikasiya kodunu telefonda zəng edən şəxsə oxuyan istifadəçidən qorumur. Və firewall kimin hansı səlahiyyətə həqiqətən ehtiyacı olduğu barədə qərarı əvəz etmir. Təhlükəsizlik arxitekturası tək bir səhvin dərhal insidentə çevrilmədiyi şərtləri yaradır — o, heç kimi ehtiyatlılıqdan azad etmir.

Tez-tez verilən suallar

Odoo 19-u qorumaq üçün güclü parol kifayətdirmi?

Xeyr. Parol keyfiyyətindən tamamilə asılı olmayaraq başqa yerdə oğurlana bilər və sonra eyni parolu qəbul edən hər xidmətdə işləyir. Yalnız iki faktorlu autentifikasiya, qarşıdakı firewall və məntiqli səlahiyyət strukturu ilə birləşmə parol oğurlandıqdan sonra da dayanan müdafiə yaradır.

Odoo 19-da iki faktorlu autentifikasiyanı necə aktivləşdirim?

„Two-Factor Authentication (TOTP)" modulunu Apps idarəetməsi vasitəsilə quraşdırın, sonra Parametrlər → Ümumi parametrlər → Səlahiyyətlər bölməsində məcburi tətbiqi aktivləşdirin və „Yalnız əməkdaşlar" ilə „Bütün istifadəçilər" arasında seçin. Hər istifadəçi bundan sonra öz ikinci faktorunu QR kodu ilə qurur.

RBL siyahısı nədir və Odoo-ya nə üçün lazımdır?

RBL (Real-time Blackhole List) HTTP ilə əldə edilə bilən ünvan siyahısıdır və praktiki olaraq hər firewall onu oxuya bilir. Odoo özü belə siyahı təqdim etmir — Web RBL modulumuz bu boşluğu hücum trafikini öz tətbiq jurnalından aşkar edib RBL siyahısı kimi qarşıdakı firewall-a qaytarmaqla bağlayır.

Əlavə modullar olmadan Odoo 19 Community kifayət qədər qorunubmu?

Tam deyil. Password Policy modulu olmadan parollar üçün minimum uzunluq yoxdur, Two-Factor Authentication olmadan ikinci faktor yoxdur və Web RBL kimi modul olmadan Odoo nə yoxlama cəhdlərini, nə də yenidən başlatmadan sonra da davam edən təkrar giriş cəhdlərini aşkar edir. Dördü də pulsuz əlavə edilə bilər.

Mövcudluq

Web RBL AGPL-3 lisenziyası ilə açıq şəkildə mövcuddur və bizdə beş veb saytda istehsalatda işləyir:

github.com/Alex0176/odoo-web-rbl

Bütün şablonlar, qiymətləndirmə və təhdid siyahıları ilə tam funksiya təsviri əvvəlki yazıdadır: Web RBL – öz veb saytlarda hücum trafiki üçün bloklama siyahısı.

Suallar, qeydlər və xəta hesabatlarını məmnuniyyətlə qəbul edirik — ən yaxşısı GitHub-da Issue kimi.