Exemplos de configuração

• Show only databases with names beginning with 'mycompany'

no arquivo de configuração <reference/cmdline/config_file>, defina:

[options]
dbfilter = ^mycompany.*$

• Show only databases matching the first subdomain after www: for example the database "mycompany" will be shown if the incoming request was sent to www.mycompany.com or mycompany.co.uk, but not for www2.mycompany.com or helpdesk.mycompany.com.

no arquivo de configuração <reference/cmdline/config_file>, defina:

[options]
dbfilter = ^%d$

A configuração de um --db-filter <odoo-bin --db-filter> adequado é uma parte importante da segurança de sua implementação. Quando estiver funcionando corretamente e corresponder apenas a uma única base de dados por nome de host, é altamente recomendável bloquear o acesso às telas do gerenciador da base de dados e usar o parâmetro de inicialização --no-database-list para evitar a listagem das bases de dados e para bloquear o acesso às telas de gerenciamento da base de dados. Consulte também security.

Exemplo de configuração

• Allow tcp connection on localhost

• Allow tcp connection from 192.168.1.x network

em /etc/postgresql/<YOUR POSTGRESQL VERSION>/main/pg_hba.conf, defina:

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

em /etc/postgresql/<YOUR POSTGRESQL VERSION>/main/postgresql.conf, defina:

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

Configurar o Odoo

Fora da caixa, o Odoo se conecta a um Postgres local através de um soquete UNIX pela porta 5432. Isso pode ser substituído usando as opções de base de dados <reference/cmdline/server/database> quando sua implementação do Postgres não for local e/ou não usar os padrões de instalação.

Com os instaladores de pacotes, um novo usuário (odoo) será automaticamente criado e definido como o usuário da base de dados.

• The database management screens are protected by the admin_passwd setting. This setting can only be set using configuration files, and is simply checked before performing database alterations. It should be set to a randomly generated value to ensure third parties can not use this interface.

• All database operations use the database options <reference/cmdline/server/database>, including the database management screen. For the database management screen to work requires that the PostgreSQL user have createdb right.

• Users can always drop databases they own. For the database management screen to be completely non-functional, the PostgreSQL user needs to be created with no-createdb and the database must be owned by a different PostgreSQL user.

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

SSL entre Odoo e PostgreSQL

A partir do Odoo 11.0, você pode impor a conexão ssl entre o Odoo e o PostgreSQL. No Odoo, o db_sslmode controla a segurança ssl da conexão com o valor escolhido entre 'disable', 'allow', 'prefer', 'require', 'verify-ca' ou 'verify-full'

Doc do PostgreSQL

Cálculo do número de workers

• Rule of thumb : (#CPU * 2) + 1

• Cron workers need CPU

• 1 worker ~= 6 concurrent users

Cálculo do tamanho da memória

• We consider 20% of the requests are heavy requests, while 80% are simpler ones

• A heavy worker, when all computed field are well designed, SQL requests are well designed, ... is estimated to consume around 1GB of RAM

• A lighter worker, in the same scenario, is estimated to consume around 150MB of RAM

RAM necessária = #worker * ( (light_worker_ratio * light_worker_ram_estimation) + (heavy_worker_ratio * heavy_worker_ram_estimation) )

Chat ao vivo

No multiprocessamento, um trabalhador dedicado do Chat ao Vivo é iniciado automaticamente e escuta --gevent-port <odoo-bin --gevent-port>. Por padrão, as solicitações HTTP continuarão acessando os workers HTTP normais em vez do chat ao vivo. Você deve implementar um proxy na frente do Odoo e redirecionar as solicitações de entrada cujo caminho começa com /websocket/ para o worker do chat ao vivo. Você também deve iniciar o Odoo em --proxy-mode <odoo-bin --proxy-mode> para que ele use os cabeçalhos reais do cliente (como nome do host, esquema e IP) em vez dos cabeçalhos do proxy.

Exemplo de configuração

• Server with 4 CPU, 8 Thread

• 60 concurrent users

• 60 users / 6 = 10 <- theoretical number of worker needed

• (4 * 2) + 1 = 9 <- theoretical maximal number of worker

• We'll use 8 workers + 1 for cron. We'll also use a monitoring system to measure cpu load, and check if it's between 7 and 7.5 .

• RAM = 9 * ((0.8*150) + (0.2*1024)) ~= 3GB RAM for Odoo

no o arquivo de configuração <reference/cmdline/config_file>:

[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

Exemplo de configuração

• Redirect http requests to https

• Proxy requests to odoo

no arquivo de configuração <reference/cmdline/config_file>, defina:

proxy_mode = True

em /etc/nginx/sites-enabled/odoo.conf, defina:

#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;
}

Proteção de HTTPS

Adicione o cabeçalho Strict-Transport-Security a todas as solicitações, para evitar que os navegadores enviem uma solicitação HTTP simples para esse domínio. Você precisará manter um serviço HTTPS em funcionamento com um certificado válido nesse domínio o tempo todo; caso contrário, seus usuários receberão alertas de segurança ou não conseguirão acessá-lo.

Forçar conexões HTTPS durante um ano para cada visitante no NGINX com a linha:

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

Configurações adicionais podem ser definidas para o cookie session_id. O sinalizador Secure pode ser adicionado para garantir que ele nunca seja transmitido por HTTP e SameSite=Lax para evitar CSRF autenticado.

# requires nginx 1.19.8
proxy_cookie_flags session_id samesite=lax secure;

Workers Cron

É necessário iniciar um dos servidores Odoo integrados ao lado do servidor WSGI para processar os trabalhos cron. Esse servidor deve ser configurado para processar apenas crons e não solicitações HTTP com a opção --no-http <odoo-bin --no-http> do cli ou a definição do arquivo de configuração http_enable = False.

Em sistemas do tipo Linux, é recomendável usar o servidor de multiprocessamento em vez do de multi-threading para se aproveitar o melhor uso do hardware e a maior estabilidade, ou seja, usar as opções --workers=-1 <odoo-bin --workers> e --max-cron-threads=n <odoo-bin --max-cron-threads> de cli.

Chat ao vivo

O uso de um servidor WSGI compatível com gevent é necessário para a operação correta do recurso de chat ao vivo. Esse servidor deve ser capaz de lidar com muitas conexões simultâneas de longa duração, mas não precisa de muita capacidade de processamento. Todas as solicitações cujo caminho começa com /websocket/ devem ser direcionadas a esse servidor. Um servidor WSGI normal (baseado em thread/processo) deve ser usado para todas as outras solicitações.

O servidor cron do Odoo também pode ser usado para atender às solicitações de chat ao vivo. Basta remover a opção --no-http <odoo-bin --no-http> do servidor cron e certificar-se de que as solicitações cujo caminho começa com /websocket/ sejam direcionadas para esse servidor, seja no servidor --http-port <odoo-bin --http-port> (servidor multi-threading) ou no --gevent-port <odoo-bin --gevent-port> (servidor de multiprocessamento).

Fornecimento de arquivos estáticos

Os arquivos estáticos do Odoo estão localizados na pasta static/ de cada módulo, de modo que os arquivos estáticos podem ser fornecidos interceptando todas as solicitações para /{MODULE}/static/{FILE} e procurando o módulo (e o arquivo) correto nos vários caminhos de complementos.

Recomenda-se definir o cabeçalho Content-Security-Policy: default-src 'none' em todas as imagens fornecidas pelo servidor Web. Isso não é obrigatório, pois os usuários não podem modificar/injetar conteúdo dentro da pasta static/ dos módulos e as imagens existentes são finais (elas não buscam novos recursos por si mesmas). No entanto, é uma boa prática.

Usando a configuração do NGINX (https) acima, os blocos mapa e localização devem ser adicionados para fornecer arquivos estáticos por 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;
    }
}

As diretivas root e try_files dependem da sua instalação, especificamente de --addons-path <odoo-bin --addons-path>.

Digamos que o Odoo tenha sido instalado pelos pacotes Debian para Community e Enterprise, e que --addons-path <odoo-bin --addons-path> seja '/usr/lib/python3/dist-packages/odoo/addons'`.

O root e o try_files devem ser:

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

Digamos que o Odoo tenha sido instalado por fontes, que os repositórios git Community e Enterprise tenham sido clonados em /opt/odoo/community e /opt/odoo/enterprise respectivamente, e que --addons-path <odoo-bin --addons-path> é '/opt/odoo/community/odoo/addons,/opt/odoo/community/addons,/opt/odoo/enterprise'.

O root e o try_files devem ser:

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

Fornecimento de anexos

Os anexos são arquivos armazenados no armazenamento de arquivos cujo acesso é regulado pelo Odoo. Eles não podem ser acessados diretamente por um servidor da web estático, pois o acesso a eles requer várias pesquisas na base de dados para determinar onde os arquivos estão armazenados e se o usuário atual pode acessá-los ou não.

Nevertheless, once the file has been located and the access rights verified by Odoo, it is a good idea to serve the file using the static web server instead of Odoo. For Odoo to delegate serving files to the static web server, the X-Sendfile (apache) or X-Accel (nginx) extensions must be enabled and configured on the static web server. Once it is set up, start Odoo with the --x-sendfile <odoo-bin --x-sendfile> CLI flag (this unique flag is used for both X-Sendfile and X-Accel).

Caso não saiba qual é o caminho para o seu armazenamento de arquivos, inicie o Odoo com a opção --x-sendfile <odoo-bin --x-sendfile> e navegue até o URL /web/filestore diretamente do Odoo (não acesse o URL pelo NGINX). Isso registra um aviso, a mensagem contém a configuração necessária.

Bloqueio de ataques de força bruta

Em implementações voltadas para a Internet, ataques de força bruta às senhas dos usuários são muito comuns, e essa ameaça não deve ser negligenciada nos servidores Odoo. O Odoo emite uma entrada de registro sempre que uma tentativa de login é realizada e informa o resultado (sucesso ou falha), juntamente com o login de destino e o IP de origem.

As entradas de registro terão o seguinte formato.

Falha no login:

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

Login bem-sucedido:

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

Esses registros podem ser facilmente analisados por um sistema de prevenção de intrusões, como o fail2ban.

Por exemplo, a seguinte definição de filtro fail2ban deve corresponder a um login com falha:

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

Seu uso com uma definição de jail pode servir para bloquear o IP de ataque em HTTP(S).

Isso poderia ser feito para bloquear o IP por 15 minutos quando 10 tentativas de login com falha são detectadas do mesmo IP em 1 minuto:

[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

Segurança do gerenciador da base de dados

setup/deploy/odoo fez menção, de passagem, à admin_passwd.

Essa configuração é usada em todas as telas de gerenciamento de base de dados (para criar, excluir, fazer dump ou restaurar bases de dados).

Se as telas de gerenciamento não devem ser acessadas de forma alguma, defina a opção de configuração list_db como False para bloquear o acesso a todas as telas de seleção e gerenciamento de base de dados.

É altamente recomendável desativar o gerenciador de base de dados em qualquer sistema voltado para a internet! Ele foi criado como uma ferramenta de desenvolvimento/demo, para facilitar a criação e o gerenciamento rápidos de bases de dados. Não foi projetado para uso em produção e pode até expor recursos perigosos a invasores. Também não foi projetado para lidar com bases de dados grandes e pode disparar limites de memória.

Em sistemas de produção, as operações de gerenciamento da base de dados devem sempre ser realizadas pelo administrador do sistema, inclusive o provisionamento de novos bases de dados e backups automatizados.

Certifique-se de configurar um parâmetro db_name adequado (e, opcionalmente, dbfilter também) para que o sistema possa determinar a base de dados de destino em cada solicitação; caso contrário, os usuários serão bloqueados, pois não poderão escolher a base de dados por conta própria.

Se as telas de gerenciamento só puderem ser acessadas a partir de um conjunto selecionado de máquinas, use os recursos do servidor proxy para bloquear o acesso a todas as rotas que começam com /web/database, exceto (talvez) /web/database/selector, que exibe a tela de seleção de base de dados.

Se a tela de gerenciamento da base de dados permanecer acessível, a configuração admin_passwd deverá ser alterada do padrão admin: essa senha é verificada antes de permitir operações de alteração da base de dados.

Ela deve ser armazenada de forma segura e deve ser gerada aleatoriamente, ex.:

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

que gera uma string imprimível pseudo-aleatória de 32 caracteres.

Redefinir a senha mestra

Pode haver casos em que a senha mestra tenha sido perdida ou comprometida e precise ser redefinida. O processo a seguir é para administradores do sistema de uma base de dados local do Odoo, detalhando como redefinir manualmente e criptografar novamente a senha mestra.

Ao criar uma nova base de dados no local, é gerada uma senha mestra aleatória. A Odoo recomenda o uso dessa senha para proteger a base. Essa senha é implementada por padrão, portanto, há uma senha mestra segura para qualquer implantação local do Odoo.

A senha mestra é especificada no arquivo de configuração do Odoo (odoo.conf ou odoorc (arquivo oculto)). Essa senha é necessária para modificar, criar ou excluir uma base de dados pela interface gráfica do usuário (GUI).