Configurarea sistemului¶

Acest document descrie pașii de bază pentru a configura Odoo în producție sau pe un server cu acces la internet. Urmează instalare și, în general, nu este necesar pentru un sistem de dezvoltare care nu este expus pe internet.

dbfilter¶

Odoo este un sistem multifuncțional: un singur sistem Odoo poate deservi mai multe baze de date. Este de asemenea foarte personalizabil, cu personalizări (începând de la modulele care sunt încărcate) în funcție de „baza de date curentă”.

Acesta nu este un problemă când lucrați cu backend-ul (clientul web) drept utilizator înregistrat în companie: baza de date poate fi selectată la logare și personalizările să fie încărcate ulterior.

Cu toate acestea, este o problemă pentru utilizatorii neînregistrați (portal, website) care nu sunt legați de o bază de date: Odoo trebuie să știe din care bază de date să încarce pagina web sau să efectueze operația. Dacă nu au fost adaugate mai multe baze de date, Odoo va folosi singura bază existenă, dar dacă au fost adaugate mai multe baze de date, Odoo are nevoie de o regulă pentru a determina pe care să o foloseasca.

Acesta este unul dintre scopurile opțiunii --db-filter: specifică cum ar trebui să fie selectată baza de date în funcție de hostname (domeniu) care este solicitat. Valoarea este o expresie regulată, posibil includând hostname-ul injectat dinamic (%h) sau primul subdomeniu (%d) prin care sistemul este accesat.

Pentru serverele care găzduiesc mai multe baze de date în producție, în special dacă website este utilizat, dbfilter trebuie să fie setat, altfel un număr de caracteristici nu vor funcționa corect.

Exemple de configurare¶

• Pentru a afișa doar bazele de date cu nume care încep cu «mycompany»

în fișierul de configurare setat:

[options]
dbfilter = ^mycompany.*$

• Afișează doar bazele de date care se potrivesc cu primul subdomeniu după www: de exemplu, baza de date „mycompany” va fi afișată dacă cererea de intrare a fost trimisă la www.mycompany.com sau mycompany.co.uk, dar nu pentru www2.mycompany.com sau helpdesk.mycompany.com.

în fișierul de configurare setat:

[options]
dbfilter = ^%d$

PostgreSQL¶

În mod implicit, PostgreSQL permite conexiunea doar prin socket-uri UNIX și conexiuni de loopback (de la „localhost”, aceeași mașină pe care este instalat serverul PostgreSQL).

Socket-ul UNIX este ok dacă doriți ca Odoo și PostgreSQL să ruleze pe aceeași mașină, și este implicit atunci când nu este furnizat niciun host, dar dacă doriți ca Odoo și PostgreSQL să ruleze pe mașini diferite 1 va avea nevoie să asculte interfețele de rețea 2, fie:

• Acceptați doar conexiuni de loopback și care folosesc conexiune SSH între mașina pe care rulează Odoo și cea pe care rulează PostgreSQL, apoi configurați Odoo pentru a se conecta la capătul conexiunii sale

• Acceptați conexiunile la mașina pe care este instalat Odoo, posibil prin ssl (vedeți Setările de conexiune PostgreSQL pentru detalii), apoi configurați Odoo pentru a se conecta prin rețea

Exemplu de configurare¶

• Permite conexiunea tcp pe localhost

• Permite conexiunea tcp de pe rețeaua 192.168.1.x

în /etc/postgresql/<YOUR POSTGRESQL VERSION>/main/pg_hba.conf setează:

# IPv4 local connections:
host    all             all             127.0.0.1/32            md5
host    all             all             192.168.1.0/24          md5

în /etc/postgresql/<YOUR POSTGRESQL VERSION>/main/postgresql.conf setează:

listen_addresses = 'localhost,192.168.1.2'
port = 5432
max_connections = 80

Configurare Odoo¶

În mod implicit, Odoo se conectează la un postgres local prin socket-ul UNIX, prin portul 5432. Acesta poate fi suprascris folosind opțiunile bazei de date atunci când instalarea Postgres nu este locală și/sau nu utilizează valorile implicite de instalare.

pachetele de instalare vor crea automat un nou utilizator (odoo) și îl vor seta ca utilizator al bazei de date.

• Ecranele de administrare a bazei de date sunt protejate de setarea admin_passwd. Această setare poate fi modificată doar folosind fișierele de configurare, și este verificată simplu înainte de a efectua modificări la baza de date. Aceasta ar trebui să fie setată la o valoare generată aleatoriu pentru a asigura că terții nu pot folosi această interfață.

• Toate operațiunile bazei de date folosesc opțiunile bazei de date, inclusiv ecranul de administrare a bazei de date. Pentru ca ecranul de administrare a bazei de date să funcționeze, este necesar ca utilizatorul PostgreSQL să aibă dreptul createdb.

• Utilizatorii pot oricând să șteargă bazele de date pe care le dețin. Pentru ca ecranul de administrare a bazei de date să fie complet nefuncțional, utilizatorul PostgreSQL trebuie creat cu no-createdb și baza de date trebuie să fie deținută de un alt utilizator PostgreSQL.

  Atenționare

  utilizatorul PostgreSQL nu trebuie să fie un superutilizator

Exemplu de configurare¶

• conectare la un server PostgreSQL pe 192.168.1.2

• portul 5432

• folosind contul de utilizator «odoo»,

• cu «pwd» ca parolă

• filtrând doar bazele de date cu un nume care începe cu «mycompany»

în fișierul de configurare setat:

[options]
admin_passwd = mysupersecretpassword
db_host = 192.168.1.2
db_port = 5432
db_user = odoo
db_password = pwd
dbfilter = ^mycompany.*$

SSL între Odoo și PostgreSQL¶

Din Odoo 11.0, puteți forța conexiunea ssl între Odoo și PostgreSQL. În Odoo, setarea db_sslmode controlează securitatea ssl a conexiunii cu valoarea aleasă din «disable», «allow», «prefer», «require», «verify-ca» sau «verify-full»

PostgreSQL Doc

Server integrat¶

Odoo include servere HTTP, cron și live-chat încorporate, folosind fie multi-threading, fie multi-procesare.

Serverul multi-threaded este un server mai simplu utilizat în principal pentru dezvoltare, demonstrații și compatibilitatea sa cu diferite sisteme de operare (inclusiv Windows). Un nou thread este generat pentru fiecare cerere HTTP nouă, chiar și pentru conexiuni de lungă durată, cum ar fi websocket. De asemenea, sunt generate fire cron daemonice suplimentare. Din cauza unei limitări Python (GIL), acesta nu folosește cel mai bine hardware-ul.

Serverul cu mai multe fire este serverul implicit, și pentru containerele docker. Se selectează lăsând opțiunea --workers sau setând-o la 0.

Serverul multi-procesare este un server complet utilizat în principal pentru producție. Nu este responsabil de aceeași limitare Python (GIL) privind utilizarea resurselor și, prin urmare, folosește cel mai bine hardware-ul. Un grup de lucrători este creat la pornirea serverului. Noile solicitări HTTP sunt puse în coadă de sistemul de operare până când există lucrători gata să le proceseze. Un lucrător HTTP suplimentar bazat pe evenimente pentru chatul live este generat pe un port alternativ. De asemenea, sunt generați lucrători cron suplimentari. Un procesator configurabil monitorizează utilizarea resurselor și poate ucide/reporni lucrătorii eșuați.

Serverul de procesare multiplă este opt-in. Este selectat prin setarea opțiunii --workers la un întreg non-null.

Calculul numărului de procese worker¶

• Regulă de bază: (#CPU * 2) + 1

• Procesele cron au nevoie de CPU

• 1 proces worker ~= 6 utilizatori concurenți

calculul dimensiunii memoriei¶

• Considerăm că 20% din cererile sunt cereri grele, în timp ce 80% sunt simple

• Un proces worker greu, când toate câmpurile calculate sunt bine proiectate, cererile SQL sunt bine proiectate, … este estimat să consume aproximativ 1GB de RAM

• Un proces worker mai ușor, în același scenariu, este estimat să consume aproximativ 150MB de RAM

RAM-ul necesar = #worker * ( (rata_worker_ușor * estimarea_ram_worker_ușor) + (rata_worker_greu * estimarea_ram_worker_greu) )

LiveChat¶

În procesarea multiplă, un lucrător dedicat LiveChat este pornit automat și ascultă pe --gevent-port. În mod implicit, solicitările HTTP vor continua să acceseze lucrătorii HTTP obișnuiți în loc de pe cel LiveChat. Trebuie să implementați un proxy în fața Odoo și să redirecționați cererile primite a căror cale începe cu /websocket/ către lucrătorul LiveChat. De asemenea, trebuie să porniți Odoo în --proxy-mode, astfel încât să folosească anteturile clientului real (cum ar fi numele de gazdă, schema și IP) în loc de cele proxy.

Exemplu de configurare¶

• Server cu 4 CPU, 8 Thread-uri

• 60 de utilizatori concurenți

• 60 de utilizatori / 6 = 10 <- numărul teoretic de procese worker necesare

• (4 * 2) + 1 = 9 <- numărul maxim teoretic de procese worker

• Vom folosi 8 procese worker + 1 pentru cron. Vom folosi de asemenea un sistem de monitorizare pentru a măsura solicitarea pe CPU, și pentru a verifica dacă este între 7 și 7.5 .

• RAM = 9 * ((0.8*150) + (0.2*1024)) ~= 3Go RAM pentru Odoo

în fișierul de configurare:

[options]
limit_memory_hard = 1677721600
limit_memory_soft = 629145600
limit_request = 8192
limit_time_cpu = 600
limit_time_real = 1200
max_cron_threads = 1
workers = 8

HTTPS¶

Indiferent dacă este accesat prin intermediul website/web client sau web service, Odoo transmite informații de autentificare în text clar. Acest lucru înseamnă că o implementare securizată de Odoo trebuie să folosească HTTPS3. Terminarea SSL poate fi implementată prin intermediul aproape oricărui proxy de terminare SSL, dar necesită următoarea configurare:

• Activați modulul proxy al Odoo. Acesta ar trebui să fie activat numai atunci când Odoo este în spatele unui reverse proxy

• Configurați proxy-ul de terminare SSL (Exemplu de terminare Nginx)

• Configurați proxy-ul în sine (Exemplu de proxy Nginx)

• Proxy-ul dvs. de terminare SSL ar trebui de asemenea să redirecționeze automat conexiunile nesecurizate către port

Exemplu de configurare¶

• Redirecționați cererile http către https

• Proxy request catre Odoo

în fișierul de configurare setat:

proxy_mode = True

în /etc/nginx/sites-enabled/odoo.conf setați:

#odoo server
upstream odoo {
  server 127.0.0.1:8069;
}
upstream odoochat {
  server 127.0.0.1:8072;
}
map $http_upgrade $connection_upgrade {
  default upgrade;
  ''      close;
}

# http -> https
server {
  listen 80;
  server_name odoo.mycompany.com;
  rewrite ^(.*) https://$host$1 permanent;
}

server {
  listen 443 ssl;
  server_name odoo.mycompany.com;
  proxy_read_timeout 720s;
  proxy_connect_timeout 720s;
  proxy_send_timeout 720s;

  # SSL parameters
  ssl_certificate /etc/ssl/nginx/server.crt;
  ssl_certificate_key /etc/ssl/nginx/server.key;
  ssl_session_timeout 30m;
  ssl_protocols TLSv1.2;
  ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
  ssl_prefer_server_ciphers off;

  # log
  access_log /var/log/nginx/odoo.access.log;
  error_log /var/log/nginx/odoo.error.log;

  # Redirect websocket requests to odoo gevent port
  location /websocket {
    proxy_pass http://odoochat;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;
    proxy_set_header X-Forwarded-Host $http_host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Real-IP $remote_addr;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
    proxy_cookie_flags session_id samesite=lax secure;  # requires nginx 1.19.8
  }

  # Redirect requests to odoo backend server
  location / {
    # Add Headers for odoo proxy mode
    proxy_set_header X-Forwarded-Host $http_host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_redirect off;
    proxy_pass http://odoo;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
    proxy_cookie_flags session_id samesite=lax secure;  # requires nginx 1.19.8
  }

  # common gzip
  gzip_types text/css text/scss text/plain text/xml application/xml application/json application/javascript;
  gzip on;
}

HTTPS¶

Adăugați antetul Strict-Transport-Security la toate solicitările, pentru a împiedica browserele să trimită vreodată o solicitare HTTP simplă către acest domeniu. Va trebui să mențineți un serviciu HTTPS funcțional cu un certificat valid pe acest domeniu în orice moment, altfel utilizatorii dvs. vor vedea alerte de securitate sau vor fi complet în imposibilitatea de a-l accesa.

Forțați conexiunile HTTPS pe parcursul unui an pentru fiecare vizitator din NGINX cu linia:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";

Poate fi definită configurație suplimentară pentru cookie-ul session_id. Indicatorul Secure poate fi adăugat pentru a se asigura că nu este niciodată transmis prin HTTP și SameSite=Lax pentru a preveni autentificarea CSRF.

# requires nginx 1.19.8
proxy_cookie_flags session_id samesite=lax secure;

Odoo drept aplicație WSGI¶

Este de asemenea posibil să montați Odoo ca o aplicație standard WSGI . Odoo oferă baza pentru un script de lansare WSGI ca odoo-wsgi.example.py. Acest script ar trebui să fie personalizat (posibil după copierea din directorul de instalare) pentru a seta corect configurarea direct în odoo.tools.config în loc de prin linia de comandă sau un fișier de configurare.

Cu toate acestea, serverul WSGI va expune doar punctul final al HTTP-ului principal pentru web client, website și webservice API. Deoarece Odoo nu mai controlează crearea mai multor procese worker, nu poate configura cron sau procese worker livechat

Procese worker Cron¶

Este necesară pornirea unuia dintre serverele Odoo încorporate lângă serverul WSGI pentru a procesa joburile cron. Serverul respectiv trebuie configurat să proceseze numai cererile crons și nu HTTP folosind opțiunea cli --no-http sau setarea fișierului de configurare http_enable = False.

Pe sistemele asemănătoare Linux, se recomandă utilizarea serverului multi-procesare peste cel multi-threading pentru a beneficia de o utilizare mai bună a hardware-ului și de o stabilitate sporită, adică utilizarea --workers=-1 și --max-cron-threads=n opțiuni cli.

LiveChat¶

Utilizarea unui server WSGI compatibil gevent este necesară pentru funcționarea corectă a funcției de chat live. Serverul respectiv ar trebui să poată gestiona multe conexiuni simultane de lungă durată, dar nu are nevoie de multă putere de procesare. Toate cererile a căror cale începe cu /websocket/ ar trebui să fie direcționate către acel server. Un server WSGI obișnuit (bazat pe thread-uri/proces) ar trebui utilizat pentru toate celelalte solicitări.

Serverul cron Odoo poate fi folosit și pentru a servi solicitările de chat live. Aruncă doar opțiunea --no-http de pe serverul cron și asigură-te că cererile a căror cale începe cu /websocket/ sunt direcționate către acest server, fie pe --http-port (server multi-threading), fie pe --gevent-port (server multi-procesare).

Transmitera fișierelor statice și atașamente¶

Pentru conveniența dezvoltării, Odoo transmite direct toate fișierele statice și atașamentele din modulele sale. Acest lucru nu este ideal din punct de vedere al performanței, iar fișierele statice ar trebui să fie servite de un server HTTP static.

Transmiterea fișierelor statice¶

Fișierele statice Odoo se află în folderul static/ al fiecărui modul, astfel încât fișierele statice pot fi folosite prin interceptarea tuturor cererilor către /MODULE/static/FILE, și căutarea modulului (și fișierului) potrivit în calea variabilă a addon-urilor.

Este recomandat să setați antetul Content-Security-Policy: default-src 'none' pe toate imaginile livrate de serverul web. Nu este strict necesar deoarece utilizatorii nu pot modifica/injecta conținut în folderul static/ al modulelor și imaginile existente sunt finale (nu preiau resurse noi de la sine). Cu toate acestea, este o bună practică.

Folosind configurația NGINX (https) de mai sus, următoarele blocuri hartă și locație ar trebui adăugate pentru a servi fișiere statice prin NGINX.

map $sent_http_content_type $content_type_csp {
    default "";
    ~image/ "default-src 'none'";
}

server {
    # the rest of the configuration

    location @odoo {
        # copy-paste the content of the / location block
    }

    # Serve static files right away
    location ~ ^/[^/]+/static/.+$ {
        # root and try_files both depend on your addons paths
        root ...;
        try_files ... @odoo;
        expires 24h;
        add_header Content-Security-Policy $content_type_csp;
    }
}

Directivele actuale root și try_files depind de instalarea dvs., în special de --addons-path.

root /usr/lib/python3/dist-packages/odoo/addons;
try_files $uri @odoo;

root /opt/odoo;
try_files /community/odoo/addons$uri /community/addons$uri /enterprise$uri @odoo;

Transmiterea atașamentelor¶

Atașamentele sunt fișiere stocate în filestore la care accesul este reglementat de Odoo. Acestea nu pot fi accesate direct prin intermediul unui server web static deoarece accesarea acestora necesită mai multe căutări în baza de date pentru a determina unde sunt stocate fișierele și dacă utilizatorul curent poate accesa acestea sau nu.

Cu toate acestea, odată ce fișierul a fost localizat și drepturile de acces verificate de Odoo, este o idee bună să transmiteți fișierul utilizând serverul web static în loc de Odoo. Pentru ca Odoo să delegheze servirea fișierelor serverului web static, extensiile X-Sendfile (apache) sau X-Accel (nginx) trebuie activate și configurate pe serverul web static. Odată ce este configurat, porniți Odoo cu --x-sendfile flag-ul CLI (acest flag unic este utilizat atât pentru X-Sendfile cât și pentru X-Accel).

Securitate¶

Pentru început, rețineți că securizarea unui sistem de informații este un proces continuu, nu o operațiune unică. În orice moment, veți fi doar atât de sigur cât cel mai slab link din mediul dvs.

Așadar vă rugăm să nu luați această secțiune ca fiind lista completă de măsuri care vor preveni toate problemele de securitate. Este doar destinat ca un rezumat al celor mai importante lucruri pe care ar trebui să fiți sigur că le includeți în planul dvs. de acțiune pentru securitate. Restul va veni din cele mai bune practici de securitate pentru sistemul dvs. de operare și distribuția, cele mai bune practici din punct de vedere al utilizatorilor, parolelor și managementului controlului accesului, etc.

Când implementați un server orientat către internet, vă rugăm să luați în considerare următoarele subiecte legate de securitate:

• Setați întotdeauna o parolă puternică pentru super-admin și restrângeți accesul la paginile de administrare a bazei de date imediat ce sistemul este configurat. Vedeți Securitatea managerului de bază de date.

• Alegeți date de logare unice și parole puternice pentru toate conturile de administrator pe toate bazele de date. Nu utilizați «admin» ca login. Nu utilizați aceste logins pentru operațiuni zilnice, doar pentru controlul/administrarea instalării. Niciodată nu utilizați parolele implicit ca admin/admin, chiar și pentru bazele de date de test/staging.

• Nu instalați date de demonstrație pe servere orientate către internet. Bazele de date cu date de demonstrație conțin date de logare implicite care pot fi utilizate pentru a intra în sistemele dvs. și pot cauza probleme semnificative, chiar și pe sistemele de testare/dezvoltare.

• Utilizați filtre adecvate pentru baze de date ( --db-filter) pentru a restricționa vizibilitatea bazelor de date în funcție de numele gazdei. Vezi dbfilter. De asemenea, puteți utiliza -d pentru a furniza propria dvs. listă (separată prin virgulă) de baze de date disponibile din care să filtrați, în loc să lăsați sistemul să le preia pe toate din backend-ul bazei de date.

• Odată ce db_name și dbfilter sunt configurate și se potrivesc doar cu o singură bază de date pentru fiecare nume de gazdă, ar trebui să setați opțiunea de configurare list_db la False, pentru a preveni listarea completă a bazelor de date și pentru a bloca acces la ecranele de gestionare a bazei de date (aceasta este expusă și ca opțiunea de linie de comandă --no-database-list)

• Asigurați-vă că user-ul PostgreSQL (--db_user) nu este un super-user, și că bazele de date sunt deținute de un alt utilizator. De exemplu, acestea ar putea fi deținute de super-user-ul postgres dacă folosiți un db_user non-privilegiat dedicat. Vedeți și Configurare Odoo.

• Păstrați instalările actualizate prin instalarea regulată a celor mai recente versiuni, fie prin intermediul GitHub sau prin descărcarea celei mai recente versiuni de la https://www.odoo.com/page/download sau http://nightly.odoo.com

• Configurați serverul dvs. în modul multi-proces cu limite adecvate care se potrivesc cu utilizarea tipică (memorie/CPU/timeout-uri). Vedeți și Server integrat.

• Porniți Odoo în spatele unui server web care oferă terminarea HTTPS cu un certificat SSL valid, pentru a preveni interceptarea comunicărilor în limba engleză. Certificările SSL sunt ieftine, și există multe opțiuni gratuite. Configurați proxy-ul web pentru a limita dimensiunea cererilor, setați timeout-uri adecvate, apoi activați opțiunea proxy mode. Vedeți și HTTPS.

• Dacă aveți nevoie să permiteți accesul SSH la distanță la serverele dvs., asigurați-vă că setați o parolă puternică pentru toate conturile, nu doar root. Se recomandă în mod ferm să dezactivați complet autentificarea bazată pe parolă și să permiteți doar autentificarea prin chei publice. De asemenea, luați în considerare restricționarea accesului prin VPN, permiteți doar IP-uri de încredere în firewall și / sau rulați un sistem de detectare a forței brute precum fail2ban sau un echivalent.

• Luați în considerare instalarea limitării adecvate a rate-ului pe proxy-ul dvs. sau firewall, pentru a preveni atacurile brute-force și atacurile de tip denial of service. Vedeți și Blocarea atacurilor brute force pentru măsuri specifice.

  Mai mulți furnizori de rețea oferă automat mitigarea pentru atacurile de tip Distributed Denial of Service (DDOS), dar aceasta este adesea un serviciu opțional, așa că ar trebui să vă consultați cu ei.

• Pe când posibil, găzduiți instanțele demo/test/staging care sunt expuse publicului pe mașini diferite de cele de producție. Și aplicați aceleași precauții de securitate ca și pentru producție.

• Dacă serverul dvs. Odoo care este expus publicului are acces la resurse interne sensibile sau servicii (de exemplu, prin intermediul unei VLAN private), implementați reguli de firewall adecvate pentru a proteja aceste resurse interne. Acest lucru va asigura că serverul Odoo nu poate fi utilizat accidental (sau ca rezultat al acțiunilor de utilizator malițioase) pentru a accesa sau perturba aceste resurse interne. De obicei, acest lucru se poate face prin aplicarea unei reguli de DENY implicită pe firewall, apoi numai autorizând explicit accesul la resursele interne pe care serverul Odoo le are nevoie să le acceseze. Systemd IP traffic access control poate fi de asemenea util pentru a implementa controlul de acces la rețea per-proces.

• Dacă serverul dvs. Odoo care este expus publicului este aparat de un firewall pentru aplicații web, un load-balancer, un serviciu de protecție DDoS transparent (precum CloudFlare) sau un dispozitiv de nivel de rețea similar, este de dorit să evitați accesul direct la sistemul Odoo. Este de obicei greu de păstrat adresele IP de capăt ale serverelor dvs. Odoo secrete. De exemplu, acestea pot apărea în jurnalele serverului web atunci când se interoghează sisteme publice, sau în antetele e-mailurilor postate din Odoo. Într-o astfel de situație, puteți dori să configurați firewall-ul astfel încât capetele să nu fie accesibile public, cu excepția adreselor IP specifice ale serviciului dvs. WAF, load-balancer sau proxy. Furnizorii de servicii precum CloudFlare de obicei mențin o listă publică a gamelor lor de adrese IP pentru acest scop.

• Dacă găzduiți mai mulți clienți, izolați datele și fișierele clienților unul de celălalt utilizând containere sau tehnici adecvate de „jail”.

• Configurați back-uri zilnice ale bazelor de date și a datelor de magazin de fișiere, și copiați-le pe un server de arhivare la distanță care nu este accesibil de la serverul în sine.

• Implementarea Odoo pe Linux este recomandată cu tărie pe Windows. În cazul în care alegeți totuși să implementați pe o platformă Windows, ar trebui să se efectueze o analiză amănunțită de întărire a securității serverului și nu intră în domeniul de aplicare al acestui ghid.

Blocarea atacurilor brute force¶

Pentru implementările conectate la internet, atacurile brute force asupra parolelor de utilizator sunt foarte comune, și această amenințare nu trebuie să fie neglijată pentru serverele Odoo. Odoo emite o intrare în jurnal când este efectuată o încercare de conectare, și raportează rezultatul: reușit sau eșuat, împreună cu numele de utilizator țintă și adresa IP sursă.

Intrările în jurnal vor avea următorul format.

Conectare eșuată:

2018-07-05 14:56:31,506 24849 INFO db_name odoo.addons.base.res.res_users: Login failed for db:db_name login:admin from 127.0.0.1

Conectare reușită:

2018-07-05 14:56:31,506 24849 INFO db_name odoo.addons.base.res.res_users: Login successful for db:db_name login:admin from 127.0.0.1

Aceste jurnale pot fi analizate ușor de către un sistem de prevenire a intruziunilor precum fail2ban.

De exemplu, următoarea definiție de filtru fail2ban ar trebui să se potrivească cu o conectare eșuată:

[Definition]
failregex = ^ \d+ INFO \S+ \S+ Login failed for db:\S+ login:\S+ from <HOST>
ignoreregex =

Acest lucru ar putea fi utilizat cu un jail definition pentru a bloca IP-ul atacatorului pe HTTP(S).

Aici este cum ar putea arăta pentru blocarea IP-ului pentru 15 minute când 10 încercări de conectare eșuate sunt detectate de la același IP într-un minut:

[odoo-login]
enabled = true
port = http,https
bantime = 900  ; 15 min ban
maxretry = 10  ; if 10 attempts
findtime = 60  ; within 1 min  /!\ Should be adjusted with the TZ offset
logpath = /var/log/odoo.log  ;  set the actual odoo log path here

Securitatea managerului de bază de date¶

Configurare Odoo a menționat admin_passwd în trecere.

Această setare este utilizată pe toate ecranele de administrare a bazei de date (pentru a crea, șterge, crea o copie de rezervă sau restaura baze de date).

Dacă ecranele de administrare nu trebuie să fie accesibile deloc, ar trebui să setați opțiunea de configurare list_db la False, pentru a bloca accesul la toate ecranele de selecție și administrare a bazei de date.

Asigurați-vă că ați configurat un parametru adecvat db_name (și opțional, de asemenea, dbfilter), astfel încât sistemul să poată determina baza de date țintă pentru fiecare solicitare, în caz contrar utilizatorii vor fi blocați, deoarece nu vor avea voie să aleagă baza de date în sine.

Dacă ecranele de administrare trebuie să fie accesibile numai dintr-un set selectat de mașini, utilizați funcțiile serverului proxy pentru a bloca accesul la toate rutele care încep cu /web/database cu excepția (posibil) /web/database/selector care afișează ecranul de selecție a bazei de date.

Dacă ecranul de administrare a bazei de date trebuie să rămână accesibil, setarea admin_passwd trebuie să fie schimbată de la admin la implicit: această parolă este verificată înainte de a permite operațiunile de modificare a bazei de date.

Trebuie stocată în siguranță, și ar trebui să fie generată aleatoriu, de exemplu.

$ python3 -c 'import base64, os; print(base64.b64encode(os.urandom(24)))'

care generează un șir tipăribil pseudoaleatoriu de 32 de caractere.

Resetați parola principală¶

Pot exista cazuri în care parola principală este greșită sau compromisă și trebuie resetată. Următorul proces este pentru administratorii de sistem ai unei baze de date Odoo on-premise, care detaliază cum să resetați manual și să recripteze parola principală.

La crearea unei noi baze de date on-premise, este generată o parolă principală aleatorie. Odoo recomandă utilizarea acestei parole pentru a securiza baza de date. Această parolă este implementată în mod implicit, deci există o parolă principală sigură pentru orice implementare Odoo on-premise.

Parola principală este specificată în fișierul de configurare Odoo (odoo.conf sau odoorc (fișier ascuns)). Parola principală Odoo este necesară pentru a modifica, crea sau șterge o bază de date prin interfața grafică cu utilizatorul (GUI).

Găsiți fișierul de configurare¶

Mai întâi, deschideți fișierul de configurare Odoo (odoo.conf sau odoorc (fișier ascuns)).

Schimbați vechea parolă¶

Odată ce fișierul corespunzător a fost deschis, continuați să modificați vechea parolă din fișierul de configurare la o parolă temporară.

Reporniți serverul Odoo¶

După setarea parolei temporare, este necesară o repornire a serverului Odoo.

Utilizați interfața web pentru a recripta parola¶

Mai întâi, navigați la /web/database/manager sau http://server_ip:port/web/database/manager într-un browser.

Apoi, faceți clic pe Set Master Password și introduceți parola temporară selectată anterior în câmpul Master Password. După acest pas, introduceți o Nouă parolă principală. Noua parolă principală este hashing (sau criptat), odată ce se face clic pe butonul Continuare.

În acest moment, parola a fost resetată cu succes și o versiune hashing a noii parole apare acum în fișierul de configurare.

Browsere suportate¶

Odoo suportă toate browserele majore de desktop și mobile disponibile pe piață, atâta timp cât sunt suportate de către editori.

Iată browserele suportate:

• Google Chrome

• Mozilla Firefox

• Microsoft Edge

• Apple Safari

1

pentru a avea mai multe instalări Odoo care folosesc aceeași bază de date PostgreSQL, sau pentru a oferi mai multe resurse de calculare atât software-ului.

2

tehnologic, un instrument precum socat poate fi folosit pentru a proxy socket-uri UNIX prin rețele, dar acest lucru este mai mult pentru software

3

sau sa fie accesibil numai prin rețele interne de pachete, dar acest lucru necesită comutatoare securizate, protecții împotriva ARP spoofing și preclude folosirea WiFi. Chiar și peste rețele de pachete securizate, implementarea peste HTTPS este recomandată, și costurile posibile sunt scăzute deoarece certificatele „self-signed” sunt mai ușor de implementat într-o mediu controlat decât peste internet.