Mîmariya ewlehiyê ya Odoo 19: Firewall, 2FA, destûrdayîn û Web RBL bi rêkûpêk bi hev re bikar bîne

Odoo li ser pênc malperên me ji înternetê vekirî tê gihîştin, û ev ne îstîsna ye, lê rewşa asayî ye: Yê ku pêşniyarekê, firotgehekê an têketina mişteriyan dimeşîne, serverekî giştî heye. Şîfreyeke tenê ya bi qelsî, pelekî mîhengkirinê yê ji bîrkirî an destûrdayîneke zêde fireh bes e ku serverekî giştî bibe yekî vekirî.

Ev nivîs nîşan dide ka hûn çawa Odoo 19 bi rêkûpêk biparêzin — ne bi tedbîreke tenê, lê bi çend qatan ku hev temam dikin: Firewall û Reverse Proxy, modula me ya open-source Web RBL, pejirandina du-faktorî, polîtîkaya şîfreyê û destûrdayîn — û ka her yek ji wan bi rastî kîjan hewldanên êrîşê digire. Di dawiyê de rêbernameyeke gav bi gav heye, ku bi wê her sazkirineke Odoo ya xwe dikare were pêşxistin.

Parastina di kûrahiyê de: çima tedbîreke tenê qet bes nîne

Her tedbîreke ewlehiyê ya tenê valahiyek heye. Firewall nabîne ka di forma têketina Odoo de çi diqewime. Şîfreyeke xurt nayê parastin heke berê li cihekî din hatibe dizîn. Avaniyeke destûrdayînê li hember êrîşkarekî ku hê têneketiye tu feyde nake. Prensîba ku van valahiyan digire parastina di kûrahiyê de (defense in depth) tê gotin: çend qatên serbixwe, ku her yek ji wan bi tena serê xwe dikaribû were dorpêçkirin — lê hemû bi hev re ne.

Li cem me çar qat hene, her yek bi erkeke cuda:

• Firewall / Reverse Proxy — tiştên eşkere xerab dûr digire, berî ku bigihîjin serverê
• Web RBL — her du aliyan girê dide: Odoo ji tomara sepana xwe fêr dibe ka Firewall çi nikare bibîne, û wê vedigerîne wî
• Odoo bi xwe — pejirandina du-faktorî, polîtîkaya şîfreyê, destûrdayîn, rêveberiya danişînê
• Danegeh & xebat — yedekkirin, parastina gihîştinê ya rêveberiyê, nepenî li derveyî her tomarekê

Beşên jêrîn her qatekê ji hev cuda derbas dikin.

Qata 1: Firewall û Reverse Proxy

Firewall yekem rayedar e ku daxwazê dibîne, û tenê yê ku dikare êrîşkarekî ji her karûbarekî li ser serverê dûr bigire — ne tenê ji malperê, lê ji serverê e-nameyê, ji gihîştina VPN û ji navrûya rêveberiyê ya xwe jî. Tiştê ku li vir bi maneyî tê çalakkirin bi hilberîner ve girêdayî ye, lê formên avakirinê li OPNsense, pfSense, HAProxy, FortiGate, Sophos an Check Point heman in:

Lîsteyên RBL: rêya standard ku bi wê navdarî tê radestkirin

RBL kurtkirina Real-time Blackhole List e, têgehek ji dinyaya e-nameyê: navnîşanek ji bo her rêzekê, bi HTTP tê girtin, bi rêkûpêkî nû tê barkirin. Hema hema her Firewall dikare lîsteyeke wisa bixwîne û ji wê rêzik ava bike — OPNsense û pfSense wekî URL Table Alias, HAProxy wekî pelê ACL, FortiGate wekî External Block List, Palo Alto wekî External Dynamic List, Cisco, Sophos, Juniper û MikroTik bi navên xwe ji bo heman prensîbê.

Modula me ya xwe tam li vir dest pê dike — û qata duyem tam li vir dest pê dike.

Qata 2: Web RBL — pira di navbera sepanê û Firewallê de

Firewall pakêtan dibîne, ne mantiqa sepanê. Ew nizane ku daxwazeke ji bo /xmlrpc/2/common hewldaneke têketinê ye, ku bîst rêyên cuda di çardeh sanîyeyan de skaner e, an ku navnîşanek niha şîfreyekê bi serkeftî texmîn kiriye. Hemû ev tenê Odoo bi xwe dizane. Web RBL, modula me ya xwe ya open-source (AGPL-3), vê zanînê bikêr dike — ji bo Odoo bi xwe û, wekî lîsteya RBL hatî radestkirin, ji bo Firewalla li pêşiya wê jî.

Lîsteyên gefan bi berdewamî têne berawirdkirin, her yek bi pileya xwe.

Bi kurtî, tiştê di nivîsa berê de bi hûrgilî hatiye şirovekirin:

• Nasîna nimûneyan di rêyan de: pelên .env, peldankên .git, pelên mîhengkirinê, sondeyên WordPress û PHP, path traversal, darvekirina fermanan bi navrûyên nû yên AI
• Berevaniya têketinê ya ku di ji nû ve destpêkirinan re jî dihejmêre — berevajî jimarvana xwe ya Odoo, ku di bîra xebatê de dijî
• Nirxandina her navnîşanê ji 0 heta 100, bi sedemê bi zimanê zelal
• Mîhengkirinên şaş (QNAP, Autodiscover, Synology) têne nasîn û qet nayên astengkirin, ji ber ku astengkirin xeletiyê çareser nake, tenê wê vedişêre
• Lîsteyên gefan ên biyanî wekî Spamhaus, FireHOL û girêkên derketinê yên Tor, bi berdewamî têne berawirdkirin
• Lîsteya serbest ji bo navnîşanên ku divê qet neyên astengkirin

Ji bo vê nivîsê du taybetmendî bi taybetî girîng in, ji ber ku rasterast bi Firewall û bi têketinê ve girêdayî ne.

Lîsteyeke bêhal lîsteyeke e ku mirov dikare pê bawer bike

Lîsteya serbest — navnîşanên ku qet nayên astengkirin, wekî mînak girêdanên cihên xwe — bi gelemperî kêm diguhere. Tam ev nirxa wê ye, ne kêmasiya wê: Dema lîsteyeke bêdeng çend rojan hema hema nelive, her guhertineke kêm tavilê xuya dike. Nûkirina otomatîk a rojane ne ji ber ku gelek tişt biguherin heye, lê da ku guhertina kêm neyê bi destan lêzêdekirin — û tam ev e cihê ku mirov wê ji bîr dike. Yek ji mîhengkirinên me yên şaş ên meha borî tam bi vî awayî hat dîtin: ne bi gelek bûyeran, lê bi ya ku kes nizanibû, heta ku API ya webê ya QNAP a mişteriyekî bi şaşî hat astengkirin. Ji hingê ve QNAP li ser lîsteya mîhengkirinên şaş e, ên ku qet nayên astengkirin, tenê têne ragihandin.

Têketin cihê ye ku Firewall nabîne

Firewall dikare navnîşanekê asteng bike. Ew nikare zanibe ka têketineke serkeftî bûye, û bêguman nikare zanibe ka ji navnîşaneke hatiye ku demek kurt berê li agahiyên têketinê geriyabû. Web RBL dizane: Nirxandineke ji sînorekî mîhengkirî ve têketinê bi tevahî qedexe dike, û têketineke serkeftî ji navnîşaneke gumanbar tê ragihandin — ev girêdana qata din e.

Qata 3: Parastina Odoo bi xwe

Pejirandina du-faktorî: nepeniyeke duyem ku nayê dubare bikaranîn

Pirsgirêka herî mezin a şîfreyan ne kalîteya wan e, lê dubare bikaranîna wan e. Şîfreyeke ku li karûbareke din hatiye dizîn, li cem me jî wekî xwe dixebite heta ku heman be. Pejirandina du-faktorî (2FA, bi navê TOTP jî tê zanîn) nepeniyeke duyem li hember wê datîne: kodeke şeş-hejmarî ku her sî sanîyeyan diguhere û ji nepeniyekê tê hesibandin ku tenê smartphone ya xwe dizane. Şîfreyeke dizîn a tenê êdî bes nîne.

Odoo 19 Community vê bi xwe re tîne — wekî modulek sazkirinê Two-Factor Authentication (TOTP), bi vebijarkeke paşvekişînê ya e-nameyê temamkirî. Her bikarhêner wê ji bo xwe saz dike, bi QR-kodê, bi her sepana Authenticator a berbelav:

Sazkirin: QR-kodê skan bike, kodeke şeş-hejmarî carekê piştrast bike, qediya.

Lê ev tenê bi tenê ji bo wan alîkar e ku wê ji bo xwe saz dikin — û ezmûn nîşan dide ku bê mecbûrî ev kêmanî dimîne. Odoo ji ber vê yekê polîtîkayeke mecbûrkirinê dizane: yan tenê ji bo karmendan (bikarhênerên navxweyî) an ji bo hemûyan, bikarhênerên portalê jî tê de. Bê nepeniyeke duyem a sazkirî êdî kes ji formê têketinê derbas nabe, bêyî ku herî kêm bi koda e-nameyê wê piştrast bike.

Polîtîkaya şîfreyê: dirêjahiya herî kêm ne tiştekî xwezayî ye

Bê modulek zêde Odoo Community li ser tu dirêjahiya herî kêm ji bo şîfreyan nabe — bikarhênerek dikare şîfreyeke ji sê tîpan bide, heke kesek nehêle wî. Modula Password Policy ya xwe tam vê valahiyê digire: dirêjahiyeke herî kêm ku li aliyê serverê tê sepandin, ne tenê di gerokê de tê pêşniyar kirin. Yê ku bêtir dixwaze — demeke mecbûrî ya bidawîbûnê, dîrokek li hember dubare bikaranînê — ji bo wê modulek OCA an a sêyem hewce dike; ev di guhertoya Community de bi mebest sivik hatiye hiştin.

Destûrdayîn: tenê yê hewce dike gihîştinê distîne

Odoo ji xwe ve sê asta ji hev cuda dike: bikarhênerên portalê (tenê portala mişterî an dabînkerê xwe), bikarhênerên navxweyî (backend, bi mafên ji bo her sepanê) û rêveberan (gihîştina bêsînor tevî mîhengkirinên teknîkî). Xeletiya herî pir ne şîfreyeke pir qels e, lê rola rêveberê ya zêde fireh hatiye dayîn: Yê ku tenê divê fatûreyan çêbike, hewcedariya gihîştina mîhengkirinên pergalê nîne.

Du prensîb piraniya barê hildigirin:

Her du jî dikarin di heman dîmenê de werin kontrolkirin, ku pejirandina du-faktorî jî lê tê sazkirin:

Dîmeneke giştî, çar hêz: şîfre, faktora duyem, mifteyên API, cihazên têketî.

Danişîn û cihaz: kî niha têketî ye

Heman dîmen her wiha nîşan dide ku hesabek niha ji kîjan cihazan têketî ye — û dihêle ku yek an hemû bi carekê werin derxistin. Piştî laptopeke windabûyî an gumana şîfreyeke xeterbûyî, ev gava herî bilez a bi bandor e: Danişîn tavilê diqede, bêyî ku şîfre berê hatibe guhertin.

Qata 4: Danegeh û xebat

Qata çaremîn ya herî kêm xuya ye û di heman demê de ya herî negengaz e, ji ber ku xeletiyeke li vir dikare her tiştê berê hatî avakirin vala bike.

• Yedekkirinên rêkûpêk û kontrolkirî, ji serverê bi xwe cuda hatine tomarkirin. Yedekkirineke ku qet nehatiye vegerandin, texmîn e, ne yedekkirin e.
• Nepenî ne di tu pelê tomarê de ne. Şîfre, mifteyên API, daneyên lîsansê — yê ku zêdekirinên xwe dinivîse, divê wan bi heman awayî wekî şîfreya sereke bi xwe bi kar bîne: li tu derê tomar neke, “tenê ji bo debugkirinê” jî na.
• Modulan nûjen bihêle, bi taybetî modulên sêyem. Modulên zêde yên azad (OCA û yên din) bi xwezayî ji guhertoyên nû yên Odoo paş dikevin; berî her sazkirinê hêjayî nihêrînê ye ka kîjan girêdayî bi otomatîk tên.

Rêya têketinê bi giştî

Çar qat ne li ser hev di jûreyên cuda de dixebitin, lê li ser heman daxwazê, pile bi pile. Bi mînaka têketinekê ev herî zelal e:

Pênc cih ku daxwazeke xerab dikare lê biqede, berî ku bigihîje armanca rastîn — û tenê yek, ku bikarhênerekî mafdar hemûyan derbas dike.

Senaryoyên êrîşê û berxwedana li hemberî wan

Dîmena jêrîn nimûneyên êrîşê yên rastîn bi qatên ku bi rastî wan disekinînin ve girê dide. Çend ji wan ne teorî ne, lê çavdêriyên me yên xwe ne ji hevdeh rojan trafîka rast li ser pênc malperên me.

Gav bi gav: sazkirina xwe ya Odoo biparêze

Rêzkirina jêrîn ew e ku em bi xwe dê wê bişopînin — ji bandora herî mezin heta mîhengkirina herî zirav.

1. Pejirandina du-faktorî mecbûr bike

1. Heke hê saz nebûye: Apps veke, li “Two-Factor Authentication” bigere û saz bike (di rewşa çend malperan de her wiha “Two-Factor Authentication by Mail” wekî vebijarka paşvekişînê tê pêşniyarkirin).
2. Mîhengên → Mîhengên giştî → Destûrdayîn veke.
3. “Pejirandina du-faktorî mecbûr bike” çalak bike.
4. Polîtîkayê hilbijêre: “Tenê karmend” ji bo bikarhênerên navxweyî, “Hemû bikarhêner”, heke bikarhênerên portalê (mişteriyên bi gihîştinê) jî bên tevlîkirin.
5. Tomar bike. Ji hewldana têketinê ya paşîn ve Odoo ji her bikarhênerê bê nepeniya duyem a sazkirî herî kêm koda e-nameyê dixwaze, heta ku wî sepana Authenticator saz bike.

2. Dirêjahiyeke herî kêm ji bo şîfreyan diyar bike

1. Apps veke, li “Password Policy” bigere û saz bike.
2. Mîhengên → Mîhengên giştî → Destûrdayîn veke.
3. “Dirêjahiya herî kêm a şîfreyê” bi cih bike — diwanzdeh tîp nirxeke destpêkê ya maqûl e.
4. Tomar bike. Rêzik ji niha ve ji bo her dayîna şîfreyeke nû an guhertî derbasdar e, ne bi paşveçûnî ji bo şîfreyên heyî.

3. Destûrdayînan binihêre

1. Mîhengên → Bikarhêner & Pargîdanî → Bikarhêner veke.
2. Her bikarhênerî ji hev cuda veke û tabê bi mafên gihîştinê ji bo her sepanê kontrol bike: Gelo ev kes bi rastî “Manager” an “Rêveber” hewce dike, an “Bikarhêner” bes e?
3. Bi taybetî kontrol bike: Kî gihîştina “Mîhengên” bi xwe heye? Divê ev komeke pir biçûk be.
4. Ji bo her girêdana derve (hesabkarî, skrîptên xwe, tomarkirina demê) di tabê “Ewlehiya hesabê” ya bikarhênerê teknîkî yê têkildar de mifteyeke API ya xwe çêbike, li şûna ku şîfreya bikarhêner bê dayîn.

4. Web RBL saz bike û berî çalakkirinê çavdêrî bike

1. Modulê ji github.com/Alex0176/odoo-web-rbl têxe nav riya addon û saz bike.
2. Çend rojan çavdêrî bike: Menûya Web RBL → Analîz nîşan dide ka kîjan nimûne bi rastî dixebitin.
3. Tenê piştî wê web_rbl.sperren_aktiv çalak bike (Mîhengên → Teknîkî → Parametreyên pergalê) — ji vir ve sondeyên naskirî bi rastî têne redkirin.
4. Lîsteya astengkirinê li navnîşana di modulê de hatî diyarkirin, bi token hatî parastin, wekî lîsteya RBL têxe nav Firewallê (li OPNsense/pfSense wekî URL Table Alias, li HAProxy wekî pelê ACL).

5. Firewallê bi xwe biparêze

1. Navrûya rêveberiyê ya Firewallê tenê ji tora navxweyî bike gihîştî, qet bi heman navnîşana giştî wekî malperê.
2. Nûvekirinên ewlehiyê yên otomatîk ji bo nermalava Firewallê çalak bike, heke hilberîner vê pêşkêş dike.
3. Mîhengkirina TLS kontrol bike: tenê guhertoyên protokolê yên nûjen, rêbazên şîfrekirinê yên kevn neçalak bike.
4. Heke hebe: lîsteyeke navdarî ya naskirî (wekî Spamhaus DROP) rasterast li ser Firewallê têxe — bêyî Web RBL, ji ber ku Firewall bi vî awayî trafîka ber bi karûbaran jî dibîne ku Odoo qet nagihîje wan.

6. Rêveberiya danegehê bigire

1. Kontrol bike ka /web/database/manager ji derve tê gihîştin — heke erê, di mîhengkirina Odoo de list_db = False deyne an rê li astê Firewallê asteng bike.
2. Şîfreya sereke ya rêveberiya danegehê dirêj û rasthatî deyne û li tu cihê ku kesê din dikare bixwîne nenivîse.

7. Yedekkirinê kontrol bike, ne tenê saz bike

1. Yedekkirineke otomatîk û rêkûpêk saz bike, ji serverê Odoo cuda hatî tomarkirin.
2. Herî kêm carekê bi rastî vegerîne û kontrol bike ka vegerandin dixebite — yedekkirineke nehatî kontrolkirin texmîn e.

Tu yek ji van gavan yeka din nagire şûna. Yê ku tenê yekê pêk tîne, deriyekî xurt kiriye û hemû yên din vekirî hiştine — yê ku hemû heftan pêk tîne, parastineke wî heye ku dîsa jî dimîne heke qatek tenê têk biçe.

Ev mîmarî çi nagire şûna

Tu yek ji tedbîrên hatine şirovekirin hewcedariya baldariyê ji holê nade. Modulek ku sondeyên .env red dike, pelekî .env ê bi şaşî hatî weşandin ne bê xetere dike. Pejirandina du-faktorî nayê parastin ji bikarhênerekî ku koda xwe ji gazîkarekî li têlefonê dixwîne. Û Firewall biryarekê li ser ka kî bi rastî kîjan destûrdayînê hewce dike nagire şûna. Mîmariya ewlehiyê şert çêdike ku di wan de xeletiyeke tenê tavilê nabe bûyer — ew baldariyê ji kesî nagire.

Pirsên pir tên pirsîn

Gelo şîfreyeke xurt bes e ku Odoo 19 were parastin?

Na. Şîfreyek dikare li cihekî din were dizîn, bêyî ku kalîteya wê çi be, û paşê li her karûbarê ku heman şîfreyê qebûl dike dixebite. Tenê tevlihevkirina bi pejirandina du-faktorî, Firewallek li pêş û avaniyeke destûrdayînê ya maqûl parastineke dide ku piştî şîfreyeke dizîn jî dimîne.

Ez pejirandina du-faktorî di Odoo 19 de çawa çalak bikim?

Modula “Two-Factor Authentication (TOTP)” bi rêveberiya Apps saz bike, piştre di Mîhengên → Mîhengên giştî → Destûrdayîn de mecbûrkirinê çalak bike û di navbera “Tenê karmend” û “Hemû bikarhêner” de hilbijêre. Her bikarhêner paşê faktora xwe ya duyem bi QR-kodê saz dike.

Lîsteyeke RBL çi ye, û Odoo çima hewceyî wê ye?

RBL (Real-time Blackhole List) lîsteyeke navnîşanan e ku bi HTTP tê girtin û hema hema her Firewall dikare bixwîne. Odoo bi xwe tu lîsteyeke wisa nayîne — modula me Web RBL vê valahiyê digire, bi naskirina trafîka êrîşê ji tomara sepana xwe û vegerandina wê wekî lîsteya RBL ji Firewalla li pêşiya wê re.

Gelo Odoo 19 Community bê modulên zêde bi têra xwe parastî ye?

Ne bi tevahî. Bê modula Password Policy dirêjahiyeke herî kêm ji bo şîfreyan tune, bê Two-Factor Authentication faktoreke duyem tune, û bê modulekî wekî Web RBL Odoo ne hewldanên sondajê û ne jî hewldanên têketinê yên dubare li ser ji nû ve destpêkirinekê dinase. Hemû çar bêpere dikarin werin lêzêdekirin.

Peydabûn

Web RBL di bin AGPL-3 de ji raya giştî re tê peyda kirin û li cem me li ser pênc malperan di hilberînê de dimeşe:

github.com/Alex0176/odoo-web-rbl

Danasîna fonksiyonan a tam bi hemû nimûne, nirxandin û lîsteyên gefan di nivîsa berê de ye: Web RBL – lîsteya astengkirinê ji bo trafîka êrîşê li ser malperên xwe.

Em pirs, şîrovekirin û raporên çewtiyan bi kêfxweşî werdigirin — çêtir wekî Issue li ser GitHub.