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.
Atenționare
Dacă configurați un server public, asigurați-vă că verificați recomandările noastre de Securitate!
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ă lawww.mycompany.com
saumycompany.co.uk
, dar nu pentruwww2.mycompany.com
sauhelpdesk.mycompany.com
.
în fișierul de configurare setat:
[options]
dbfilter = ^%d$
Notă
Setarea unui --db-filter
corect este o parte importantă a securizării instalării. Odată ce funcționează corect și fiecărui hostname îi corespunde o singura bază de date, este recomandat să se blocheze accesul la ecranele managerului de baze de date și să se utilize --no-database-list
ca parametru de pornire pentru a preveni listarea bazelor de date și pentru a bloca accesul la ecranele de administrare ale bazelor de date. Vedeți și securitate.
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»
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.
Notă
Deoarece este foarte personalizat pentru serverele Linux, serverul de procesare multiplă nu este disponibil pe Windows.
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
[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 proxyConfiguraț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
.
Example
Să presupunem că Odoo a fost instalat prin pachetele Debian pentru Community și Enterprise și că --addons-path
este '/usr/lib/ python3/dist-packages/odoo/addons'
.
root
și try_files
ar trebui să fie:
root /usr/lib/python3/dist-packages/odoo/addons;
try_files $uri @odoo;
Să presupunem că Odoo a fost instalat prin surse, că ambele depozite git Community și Enterprise au fost clonate în /opt/odoo/community
și, respectiv, /opt/odoo/enterprise
și că --addons-path
este '/opt/odoo/community/odoo/addons,/opt/odoo/community/addons,/opt/odoo /întreprindere'
.
root
și try_files
ar trebui să fie:
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).
Notă
Extensia X-Sendfile pentru apache (și serverele web compatibile) nu necesită nicio configurație suplimentară.
Extensia X-Accel pentru NGINX are nevoie de următoarea configurație suplimentară:
location /web/filestore { internal; alias /path/to/odoo/data-dir/filestore; }
Dacă nu știți calea către filestore-ul dvs., porniți Odoo cu opțiunea
--x-sendfile
și navigați la URL-ul/web/filestore
direct prin Odoo (nu navigați la URL-ul prin intermediul NGINX). Acest lucru înregistrează o avertizare, mesajul conține configurația de care aveți nevoie.
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.
Folosiți filtrele de bază de date adecvate (
--db-filter
) pentru a restrânge vizibilitatea bazelor de date în funcție de numele de gazdă. Vedeți dbfilter. De asemenea, puteți utiliza-d
pentru a furniza propria (separate prin virgulă) lista de baze de date disponibile pentru a filtra, în loc să lăsați sistemul să le aducă toate din backend-ul bazei de date.Odată ce
db_name
șidb_filter
sunt configurate și se potrivesc cu o singură bază de date pe nume de gazdă, ar trebui să setați opțiunea de configurarelist_db
laFalse
, pentru a preveni listarea completă a bazelor de date și pentru a bloca accesul la ecranele de administrare a bazelor 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-ulpostgres
dacă folosiți undb_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 precumfail2ban
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.
Atenționare
Este recomandat puternic să dezactivați Database Manager pentru orice sistem care se confruntă cu publicul! Este destinat ca un instrument de dezvoltare/demonstrație, pentru a face ușor crearea și administrarea bazelor de date. Nu este conceput pentru utilizare în producție, și poate expune chiar și caracteristici periculoase atacatorilor. De asemenea, nu este conceput pentru a gestiona baze de date mari, și poate declanșa limitele de memorie.
Pe sistemele de producție, operațiunile de administrare a bazei de date trebuie efectuate întotdeauna de către administratorul de sistem, inclusiv provisionarea de noi baze de date și copii de rezervă automate.
Asigurați-vă că ați configurat un parametru db_name
corespunzător (și opțional, și db_filter
) astfel încât sistemul să poată determina baza de date țintă pentru fiecare solicitare, altfel utilizatorii vor fi blocați deoarece nu vor fi autorizați să aleagă baza de date singuri.
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ă.
Vedeți și
Pentru mai multe informații despre schimbarea parolei unui cont Odoo.com, consultați această documentație: Schimbarea parolei contului Odoo.com.
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.
Atenționare
Când se creează o bază de date Odoo on-premise, instalarea este accesibilă oricui de pe internet, până când această parolă este setată pentru a securiza baza de date.
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)).
Fișierul de configurare se află la: c:\ProgramFiles\Odoo{VERSION}\server\odoo.conf
În funcție de modul în care este instalat Odoo pe computerul Linux, fișierul de configurare se află într-unul din două locuri diferite:
Instalarea pachetului:
/etc/odoo.conf
Instalare sursă:
~/.odoorc
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ă.
După localizarea fișierului de configurare, deschideți-l folosind o (GUI). Acest lucru poate fi realizat printr-un simplu dublu clic pe fișier. Apoi, dispozitivul ar trebui să aibă o GUI implicită pentru a deschide fișierul.
Apoi, modificați linia de parolă principală admin_passwd = $pbkdf2-sha...
la admin_passwd = newpassword1234
, de exemplu. Această parolă poate fi orice, atâta timp cât este salvată temporar. Asigurați-vă că modificați toate caracterele după =
.
Example
Linia apare astfel: admin_passwd = $pbkdf2-sh39dji295.59mptrfW.9z6HkA$w9j9AMVmKAP17OosCqDxDv2hjsvzlLpF8Rra8I7p/b573hji540mtrfW.9z6HkA$w9j9AMVmKAP17OosCqDxDv2hjsvzlLpF8Rra8I7p/b573hji540mklk/%830mklk/%k3vmKAP17. m
Linia modificată apare astfel: admin_passwd = newpassword1234
Modificați linia de parolă principală utilizând următoarea comandă Unix detaliată mai jos.
Conectați-vă la terminalul serverului Odoo prin protocolul Secure Shell (SSH) și editați fișierul de configurare. Pentru a modifica fișierul de configurare, introduceți următoarea comandă: sudo nano /etc/odoo.conf
După deschiderea fișierului de configurare, modificați linia de parolă principală admin_passwd = $pbkdf2-sha…
la admin_passwd = newpassword1234
. Această parolă poate fi orice, atâta timp cât este salvată temporar. Asigurați-vă că modificați toate caracterele după =
.
Example
Linia apare astfel: admin_passwd = $pbkdf2-sh39dji295.59mptrfW.9z6HkA$w9j9AMVmKAP17OosCqDxDv2hjsvzlLpF8Rra8I7p/b573hji540mtrfW.9z6HkA$w9j9AMVmKAP17OosCqDxDv2hjsvzlLpF8Rra8I7p/b573hji540mklk/%830mklk/%k3vmKAP17. m
Linia modificată apare astfel: admin_passwd = newpassword1234
Important
Este esențial ca parola să fie schimbată cu altceva, în loc să declanșeze o nouă resetare a parolei prin adăugarea unui punct și virgulă ;
la începutul liniei. Acest lucru asigură că baza de date este sigură pe parcursul întregului proces de resetare a parolei.
Reporniți serverul Odoo¶
După setarea parolei temporare, este necesară o repornire a serverului Odoo.
Pentru a reporni serverul Odoo, mai întâi tastați services
în bara de căutare Windows Search. Apoi, selectați aplicația Services și derulați în jos la serviciul Odoo.
Apoi, faceți clic dreapta pe Odoo și selectați Start sau Reporniți. Această acțiune repornește manual serverul Odoo.
Reporniți serverul Odoo tastând comanda: sudo service odoo15 restart
Notă
Schimbați numărul după odoo
pentru a se potrivi cu versiunea specifică pe care rulează serverul.
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.
Notă
Înlocuiți server_ip
cu adresa IP a bazei de date. Înlocuiți port
cu portul numerotat din care este accesibilă baza de date.
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.
Vedeți și
Pentru mai multe informații despre securitatea bazei de date Odoo, consultați această documentație: Securitatea managerului de bază de date.
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
Atenționare
Vă rugăm să vă asigurați că browserul este actualizat și încă suportat de editorul înainte de a depune un raport de eroare.
Notă
De la Odoo 13.0, ES6 este suportat. Prin urmare, suportul pentru IE este abandonat.
- 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.