Configuración del sistema¶

Este documento describe los pasos básicos para configurar Odoo en producción o en un servidor al que puedes acceder desde internet, se aplica después de la instalación y, por lo general, no es necesario para sistemas de desarrollo que no están expuestos a internet.

Advertencia

Asegúrate de revisar nuestras recomendaciones de Seguridad si vas a configurar un servidor público.

dbfilter¶

Odoo es un sistema multitenencia o de tenencia múltiple. Un solo sistema de Odoo puede ejecutar y servir a varias instancias de bases de datos. Además, es altamente personalizable y las personalizaciones (desde los módulos cargados) dependen de la «base de datos actual».

Esto no representa un problema al trabajar con el backend (cliente web) como un usuario de la empresa que inició sesión, ya que es posible seleccionar la base de datos al iniciar sesión y las personalizaciones se cargan después.

Sin embargo, esto complica un poco las cosas para los usuarios que no inician sesión (portal, sitio web) y no están vinculados a la base de datos. Odoo necesita saber qué base de datos usar para cargar la página del sitio web o realizar una operación. No hay ningún problema si la tenencia múltiple no está activa, pues solo hay una base de datos disponible para su uso; pero si hay varias bases de datos a las que es posible acceder, Odoo necesita una regla para saber cuál usar.

Uno de los propósitos de --db-filter es especificar cómo se debe seleccionar la base de datos en función del nombre de host (dominio) solicitado. El valor es una expresión regular que puede incluir el nombre del host (%h) de forma dinámica o el primer subdominio (%d) mediante el que se accede al sistema.

dbfilter debe estar configurado en los servidores que alojan varias bases de datos en producción, sobre todo si usan Sitio web, o varias funciones no trabajarán de forma correcta.

Ejemplos de configuración¶

Para mostrar solo las bases de datos que tienen un nombre que inicia con «mycompany»:

Define lo siguiente en el archivo de configuración:

[options]
dbfilter = ^mycompany.*$

Para mostrar solo las bases de datos que coinciden con el primer subdominio después de www. Por ejemplo, la base de datos «mycompany» aparecerá si la solicitud entrante se envió a www.mycompany.com o mycompany.co.uk, pero no a www2.mycompany.com o helpdesk.mycompany.com.

Define lo siguiente en el archivo de configuración:

[options]
dbfilter = ^%d$

Nota

Configurar --db-filter es una parte importante para asegurar tu despliegue. Una vez que funciona de forma correcta y solo coincida con una base de datos por nombre de host, te recomendamos bloquear el acceso a las pantallas de gestión de bases de datos y usar el parámetro de inicio --no-database-list para evitar que tus bases de datos aparezcan y restringir el acceso a dichas pantallas. Consulta también la sección de seguridad.

PostgreSQL¶

De forma predeterminada, PostgreSQL solo permite conexiones mediante sockets UNIX y conexiones de bucle invertido o loopback (desde «localhost», es decir, la misma máquina en la que está instalado el servidor de PostgreSQL).

El socket UNIX es útil si quieres que Odoo y PostgreSQL se ejecuten en la misma máquina, además de que es la opción predeterminada cuando no proporcionas un host. Sin embargo, si quieres que se ejecuten en máquinas diferentes 1, es necesario escuchar las interfaces de red 2. Puedes hacerlo de dos formas:

Acepta solo las conexiones de bucle invertido y usa un túnel SSH entre la máquina en la que ejecutas Odoo y en la que ejecutas PostgreSQL. Después, configura Odoo para conectarlo al extremo del túnel.
Acepta conexiones a la máquina que tiene Odoo instalado, posiblemente a través de SSL (consulta los ajustes de conexión de PostgreSQL para obtener más detalles) y luego configura Odoo para conectarse a través de la red.

Ejemplo de configuración¶

Permite la conexión tcp en localhost.
Permite la conexión tcp desde la red 192.168.1.x.

Configura lo siguiente en /etc/postgresql/<TU VERSIÓN DE POSTGRESQL>/main/pg_hba.conf:

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

Configura lo siguiente en /etc/postgresql/<TU VERSIÓN DE POSTGRESQL>/main/postgresql.conf:

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

Configurar Odoo¶

Odoo se conecta a un servidor local de PostgreSQL mediante un socket UNIX en el puerto 5432 de forma predeterminada. Puedes modificar esto con las opciones de la base de datos si tu despliegue de PostgreSQL no es local o no usa la configuración de instalación predeterminada.

Los paquetes de instalación crearán un nuevo usuario (odoo) de forma automática y lo configurarán como el usuario de la base de datos.

Las pantallas de gestión de bases de datos están protegidas por admin_passwd. Solo puedes definir esto mediante archivos de configuración y se verifica antes de realizar cualquier modificación en la base de datos. Debes configurarlo con un valor generado de forma aleatoria para garantizar que fuentes externas no puedan usar esta interfaz.
Todas las operaciones de la base de datos usan las opciones de la base de datos, incluyendo la pantalla de gestión de las bases de datos. El usuario de PostgreSQL necesita tener el permiso createdb para que esta pantalla funcione.
Los usuarios siempre pueden eliminar las bases de datos que poseen. Para que la pantalla de gestión de bases de datos quede inoperativa, es necesario crear al usuario de PostgreSQL con el permiso no-createdb y otro de los usuarios debe ser propietario de la base de datos.

Advertencia
El usuario de PostgreSQL no debe ser un superusuario.

Ejemplo de configuración¶

Conéctate a un servidor de PostgreSQL en 192.168.1.2.
Puerto 5432.
Usa la cuenta con el usuario «odoo».
Usa «pwd» como contraseña.
Filtra solo las bases de datos que tienen un nombre que inicia con «mycompany».

Define lo siguiente en el archivo de configuración:

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

SSL entre Odoo y PostgreSQL¶

Desde Odoo 11.0 puedes utilizar la conexión SSL entre Odoo y PostgreSQL. En Odoo, db_sslmode controla la seguridad SSL de la conexión y puede tener uno de los siguientes valores: disable, allow, prefer, require, verify-ca o verify-full.

Documentación de PostgreSQL

Servidor integrado¶

Odoo incluye servidores integrados para HTTP, crones y chat en vivo que usan multiprocesos (multi-processing) o multihilos (multi-threading).

El servidor multihilos es un servidor más simple que suele utilizarse para desarrollos, demostraciones y por su compatibilidad con varios sistemas operativos (como Windows). Cada nueva petición HTTP genera un nuevo hilo, incluso para las conexiones larga duración como websocket. También crea hilos demonio adicionales para los crons. Sin embargo, por su limitación con Python (GIL), no aprovecha muy bien el hardware disponible.

El servidor multihilos es el servidor predeterminado, incluso en los contenedores de Docker. Se selecciona al no elegir la opción --workers o configurándola en 0.

El servidor multiprocesos es un servidor completo que se usa principalmente para producción. No está sujeto a la misma limitación de Python (GIL) en cuanto al uso de recursos, por lo que aprovecha mucho mejor el hardware. Al iniciar el servidor se crea un conjunto de workers y el sistema operativo pone en cola las nuevas peticiones HTTP hasta que haya workers disponibles para procesarlas. También se crea un worker HTTP adicional, basado en eventos, para el chat en vivo, que se ejecuta en un puerto alternativo. Además, se generan workers cron adicionales. Un proceso reaper configurable monitorea el uso de recursos y puede detener o reiniciar los workers que tengan errores.

El servidor multiprocesos es opcional y puedes utilizarlo si configuras la opción --workers con un entero que no sea de tipo null.

Nota

El servidor multiprocesos no está disponible para Windows, ya que está personalizado para servidores Linux.

Cálculo del número de workers¶

Regla general: (#CPU * 2) + 1
Los workers del cron también consumen CPU.
1 worker ~= 6 usuarios concurrentes.

Cálculo del tamaño de la memoria¶

Consideramos que el 20% de las solicitudes son pesadas, mientras que el 80% son más simples.
Se estima que un worker para solicitudes pesadas consume aproximadamente 1 GB de RAM, suponiendo que los campos calculados y las consultas SQL están bien diseñadas.
Un worker para solicitudes ligeras, en las mismas condiciones, consume aproximadamente 150 MB de RAM.

RAM necesaria = número de workers * ( (proporción de workers ligeros * estimación de RAM por worker ligero) + (proporción de workers pesados * estimación de RAM por worker pesado) )

Chat en vivo¶

El servidor multiprocesos inicia un worker específico para Chat en vivo de forma automática que escucha en --gevent-port. De manera predeterminada, las peticiones HTTP seguirán accediendo a los workers HTTP regulares, no a los de Chat en vivo. Debes desplegar un proxy en Odoo y redirigir las peticiones entrantes que inician con la ruta /websocket al worker de Chat en vivo. También debes iniciar Odoo en --proxy-mode para que use los encabezados reales de los clientes (como el nombre del host, esquema e IP) en lugar de los del proxy.

Ejemplo de configuración¶

Servidor con 4 CPU, 8 hilos.
60 usuarios concurrentes.
60 usuarios / 6 = 10 <- Número teórico de workers necesarios.
(4 * 2) + 1 = 9 <- Número teórico máximo de workers.
Usaremos 8 workers + 1 para el cron. También usaremos un sistema de monitoreo para medir la carga del CPU y verificar que se encuentre entre 7 y 7.5.
RAM = 9 * ((0.8*150) + (0.2*1024)) ~= 3GB de RAM para Odoo

En el archivo de configuración:

[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¶

Odoo transmite la información de autenticación mediante texto sin cifrar al acceder mediante un sitio web, cliente web o servicio web. Esto significa que un despliegue seguro de Odoo debe usar HTTPS3. Puedes implementar la terminación SSL con cualquier proxy para este fin, pero tendrás que hacer los siguientes ajustes:

Habilita el modo proxy de Odoo. Solo debe estar habilitado cuando Odoo se sitúa detrás de un proxy inverso.
Configura la terminación SSL del proxy (ejemplo de terminación Nginx).
Configura el proxy (ejemplo de proxy para Nginx).
Tu proxy de terminación SSL también debería redirigir las conexiones no seguras al puerto seguro de forma automática.

Ejemplo de configuración¶

Redirige las peticiones HTTP a HTTPS.
Redirige las peticiones proxy a «odoo».

Define lo siguiente en el archivo de configuración:

proxy_mode = True

Configura lo siguiente en /etc/nginx/sites-enabled/odoo.conf:

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

Endurecimiento de HTTPS¶

Agrega el encabezado Strict-Transport-Security a todas las peticiones para evitar que los navegadores envíen una petición HTTP simple a este dominio. Tu servicio HTTPS deberá tener un certificado válido funcional para este dominio todo el tiempo; de lo contrario tus usuarios visualizarán alertas de seguridad o no podrán acceder a tu sitio.

Incluye la siguiente línea para forzar las conexiones HTTPS durante un año para todos los visitantes en NGINX:

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

Puedes hacer otros ajustes en la cookie session_id. Agrega el marcador Secure para que nunca se transmita por HTTP y SameSite=Lax para evitar un CSRF autenticado.

# requires nginx 1.19.8
proxy_cookie_flags session_id samesite=lax secure;

Odoo como una aplicación WSGI¶

También puedes configurar Odoo como una aplicación WSGI estándar. Odoo proporciona la base para un script de lanzamiento WSGI llamado odoo-wsgi.example.py. Es necesario personalizar el script (luego de copiarlo desde la carpeta de instalación) para realizar la configuración de forma correcta en odoo.tools.config y no en la línea de comandos o un archivo de configuración.

Sin embargo, el servidor WSGI solo mostrará el punto de conexión HTTP principal para el cliente web, el sitio web y la API del servicio web API. Odoo ya no controla la creación de workers, así que ya no podrá configurar los workers del cron ni de Chat en vivo.

Workers de cron¶

Es necesario iniciar uno de los servidores integrados de Odoo con el servidor WSGI para procesar las acciones del cron. Ese servidor debe estar configurado para que solo procese los crons y no las peticiones HTTPS. Usa la opción --no-http en la línea de comandos o modifica el archivo de configuración con http_enable = False.

En sistemas de tipo Linux es recomendable utilizar el servidor multiprocesos en lugar del servidor multihilos para aprovechar mejor el hardware e incrementar la estabilidad. Para ello, puedes utilizar las opciones --workers=-1 y --max-cron-threads=n de la línea de comandos.

Chat en vivo¶

Es necesario usar un servidor WSGI compatible con gevent para que la función de Chat en vivo opere de forma correcta. Ese servidor debe poder gestionar vmuchas conexiones simultáneas y de larga duración, pero no requiere mucha potencia de procesamiento. Redirige todas las peticiones que comienzan con /websocket/ a ese servidor y utiliza un servidor WSGI normal (de hilos o procesos) para el resto de las peticiones.

El servidor cron de Odoo también es útil para atender las solicitudes de Chat en vivo. Solo debes eliminar la opción --no-http de la interfaz de la línea de comandos del servidor cron y asegurarte de que las peticiones cuya ruta comienzan con /websocket/ estén dirigidas a este servidor, ya sea en --http-port (servidor multihilos) o en --gevent-port (servidor multiprocesos).

Gestión de archivos estáticos y adjuntos¶

Para facilitar el proceso de desarrollo, Odoo gestiona todos los archivos estáticos y adjuntos en los módulos de forma directa. Es posible que esto no sea lo mejor en términos de rendimiento, además un servidor HTTP especializado en contenido estático debería gestionar los archivos estáticos.

Gestión de archivos estáticos¶

Los archivos estáticos de Odoo están en la carpeta static/ de cada módulo, así que para gestionarlos puedes interceptar todas las peticiones a /MÓDULO/static/ARCHIVO y buscar el módulo (y el archivo) correcto en las distintas rutas de los complementos.

Es recomendable que configures el encabezado Content-Security-Policy: default-src 'none' en todas las imágenes proporcionadas por el servidor web. No es necesario que lo hagas porque los usuarios no pueden modificar o inyectar contenido a la carpeta static/ de los módulos y las imágenes existentes son definitivas (no cargan nuevos recursos por su cuenta), pero es una buena práctica.

Usar la configuración anterior de NGINX (https) agregará los bloques map y location para gestionar los archivos estáticos a través de 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;
    }
}

Las directivas root y try_files reales dependen de tu instalación, sobre todo de --addons-path.

Example

Supongamos que instalaste Odoo con los paquetes Debian para Community y Enterprise, y que la ruta de --addons-path es '/usr/lib/python3/dist-packages/odoo/addons'.

Los elementos root y try_files deberían estar configurados de la siguiente manera:

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

Supongamos que instalaste Odoo con el código fuente, que clonaste el repositorio de Git de Community y de Enterprise en /opt/odoo/community y /opt/odoo/enterprise respectivamente, y que la ruta de --addons-path es '/opt/odoo/community/odoo/addons,/opt/odoo/community/addons,/opt/odoo/enterprise'.

Los elementos root y try_files deberían estar configurados de la siguiente manera:

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

Gestión de archivos adjuntos¶

Odoo regula el acceso a los archivos almacenados en el sistema correspondiente. No es posible acceder a ellos a través de un servidor web estático, ya que es necesario hacer varias consultas en la base de datos para determinar dónde están los archivos y si el usuario actual tiene acceso a ellos.

Una vez que Odoo localiza el archivo y verifica los permisos de acceso, es buena idea que el servidor web estático gestione el archivo en lugar de Odoo. Para que Odoo delegue esta tarea al servidor estático debes habilitar y configurar las extensiones X-Sendfile (apache) o X-Accel (nginx) en ese servidor. Una vez que hayas configurado esto, inicia Odoo con --x-sendfile (sirve tanto para X-Sendfile como para X-Accel) en la línea de comandos.

Nota

No es necesario que hagas ajustes adicionales en la extensión X-Sendfile para Apache (y otros servidores web compatibles).
La extensión X-Accel para NGINX sí necesita que hagas los siguientes ajustes:
```
location /web/filestore {
    internal;
    alias /path/to/odoo/data-dir/filestore;
}
```
Si no sabes cuál es la ruta a tu archivo de almacenamiento, inicia Odoo con la opción --x-sendfile y ve directo a la URL /web/filestore desde Odoo (no lo hagas desde NGINX). Esto registrará una advertencia con un mensaje que incluye la configuración que necesitas.

Seguridad¶

Para empezar, toma en cuenta que asegurar un sistema de información es un proceso continuo, no una acción puntual. Tu nivel de protección está limitado por el punto más débil que tengas en tu entorno.

Esta sección no enumera todas las medidas para evitar problemas de seguridad, solo resume las acciones más importantes que debes incluir en tu plan de acción de seguridad. Recuerda seguir las mejores prácticas para tu sistema operativo y distribución, gestión de usuarios, contraseñas, control de accesos, entre algunas otras cosas.

Al desplegar un servidor al que puedes acceder por internet, asegúrate de considerar los siguientes temas relacionados con la seguridad:

Siempre define una contraseña fuerte para superadmin y también restringe el acceso a las páginas de gestión de las bases de datos una vez que hayas configurado el sistema. Consulta la siguiente sección: Seguridad del gestor de bases de datos.
Usa nombres de usuario únicos y contraseñas fuertes para todas las cuentas de administrador en todas las bases de datos. No uses «admin» como usuario ni para operaciones diarias, solo durante el proceso de control y gestión de la instalación. Nunca uses contraseñas predeterminadas como admin/admin, ni siquiera en las bases de datos de prueba o de preproducción.
No instales los datos de demostración en los servidores que tienen acceso por internet. Las bases con datos de demostración incluyen usuarios y contraseñas predeterminadas que pueden ser explotados para acceder a tu sistema y ocasionar problemas, incluso en entornos de prueba o desarrollo.
Usa los filtros de bases de datos apropiados (--db-filter) para limitar la visibilidad de tus bases según el nombre del host. Consulta dbfilter para obtener más información. También puedes usar -d para especificar una lista (separada por comas) de bases de datos disponibles para filtrarlas y que el sistema las recupere todas desde el backend.
Una vez que hayas configurado db_name y dbfilter, y solo coincida una base por nombre de host, configura la opción list_db a False para evitar enumerar las bases y bloquear el acceso a las pantallas de gestión (esto también aparece como la opción --no-database-list en la línea de comandos).
Asegúrate de que el usuario de PostgreSQL (--db_user) no sea un superusuario y de que tus bases de datos le pertenezcan a un usuario distinto. Por ejemplo, puede que los superusuarios de postgres sean los propietarios si usas un db_user especializado y no privilegiado. Consulta Configurar Odoo.
Mantén las instalaciones actualizadas. Instala las versiones más recientes con frecuencia, ya sea a través de GitHub o descárgalas de https://www.odoo.com/es/page/download o http://nightly.odoo.com.
Configura tu servidor con el modo multiprocesos. Define los límites que correspondan con tu uso habitual (memoria, CPU y tiempos de espera). Consulta Servidor integrado.
Ejecuta Odoo con un servicio web que ofrezca terminación HTTPS con un certificado SSL válido para evitar que alguien intercepte las comunicaciones de texto sin cifrar. Los certificados de SSL no son costosos y hay muchas opciones gratuitas. Configura el proxy web para limitar el tamaño de las solicitudes, define tiempos de espera adecuados y después activa el modo proxy. Consulta HTTPS.
Si necesitas permitir acceso SSH remoto a tus servidores, asegúrate de definir una contraseña fuerte para todas las cuentas, no solo para root. Te recomendamos deshabilitar por completo la autenticación por contraseña y permitir solo la autenticación con una llave pública. También considera restringir el acceso a través de VPN, permitir el acceso solo a las IP de confianza en el firewall o utilizar un sistema de detección de ataques por fuerza bruta como fail2ban o algún equivalente.
Considera instalar límites de velocidad adecuados en tu proxy o firewall para evitar ataques de fuerza bruta y ataques de denegación de servicio. Consulta :ref:`login_brute_force`para obtener más información sobre algunas medidas específicas.

Muchos proveedores de red ofrecen mitigación automática para los ataques de denegación de servicio distribuidos (DDoS), pero suelen considerarlo un servicio opcional. Consulta esta información con ellos.
Siempre que puedas, aloja tus instancias públicas de demostración, prueba o preproducción en máquinas distintas a las de producción y aplica las mismas precauciones de seguridad que usas en producción.
Si tu servidor público de Odoo tiene acceso a recursos o servicios confidenciales de la red interna (por ejemplo, a través de una VLAN privada), implementa reglas de firewall adecuadas para proteger esos recursos internos. Así te aseguras de que nadie use el servidor de Odoo de forma accidental (o por acciones maliciosas de algun usuario) para acceder o interrumpir esos recursos internos. Por lo general, puedes hacer esto si configuras una regla de denegación DENY predeterminada en el firewall para el tráfico saliente, y luego autoriza de forma explícita el acceso solo a los recursos internos que el servidor de Odoo necesita. También puede ser útil usar el control de acceso al tráfico IP de Systemd para gestionar el acceso a la red por proceso.
Si tu servidor público de Odoo está detrás de un firewall de aplicaciones web, un equilibrador de carga, un servicio transparente de protección contra DDoS (como CloudFlare) o un dispositivo similar a nivel de red, puede que quieras evitar el acceso directo al sistema de Odoo. Por lo general es difícil mantener las direcciones IP de tus servidores de Odoo en secreto, ya que pueden aparecer en los registros del servidor web al consultar sistemas públicos o en los encabezados de correos enviados desde Odoo. En ese caso, te conviene configurar tu firewall para que no sea posible acceder a los puntos de conexión de forma pública, excepto desde las direcciones IP específicas de tu firewall de aplicaciones web, equilibrador de carga o servicio proxy. Los proveedores de servicios como CloudFlare suelen mantener una lista pública con los rangos de las direcciones IP para este propósito.
Si alojas a varios clientes, aísla los datos y archivos de cada uno con los contenedores o las técnicas de «jail» (o cárcel) apropiadas.
Configura copias de seguridad diarias de tus bases de datos y del almacenamiento de archivos. Cópialas a un servidor remoto de archivo al que no sea posible acceder desde el mismo servidor.
Te recomendamos que despliegues Odoo en Linux en lugar de Windows. Si decides usar Windows deberás hacer una revisión exhaustiva de seguridad en el servidor, pero no describimos ese proceso en esta guía.

Bloquear ataques de fuerza bruta¶

En los despliegues expuestos a internet, los ataques de fuerza bruta a las contraseñas de los usuarios son muy comunes y no debes subestimar esta amenaza para los servidores de Odoo. Odoo registra una entrada cada que detecta un intento de inicio de sesión e indica el resultado (si fue exitoso o falló), junto con el usuario objetivo y la dirección IP de origen.

Las entradas con los registros tendrán el siguiente formato.

Inicio de sesión fallido:

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

Inicio de sesión exitoso:

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

Los sistemas de prevención de intrusiones como fail2ban pueden analizar estos registros con facilidad.

Por ejemplo, la siguiente definición del filtro de fail2ban debería coincidir con un inicio de sesión fallido:

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

Podrías utilizarla con una definición de «jail» para bloquear la dirección IP atacante en HTTP(S).

Los siguientes parámetros ejemplifican cómo podrías bloquear la dirección IP durante 15 minutos si el sistema detecta 10 intentos de inicio de sesión fallidos desde la misma IP en 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

Seguridad del gestor de bases de datos¶

En Configurar Odoo encontrarás información sobre admin_passwd.

Este ajuste se usa en todas las pantallas de gestión de bases de datos (para crear, eliminar, realizar dumps o restaurar bases de datos).

Configura la opción list_db como False para que no sea posible acceder a las pantallas de gestión, ya que esto bloquea el acceso a todas las pantallas de selección y gestión de las bases de datos.

Advertencia

Te recomendamos desactivar el gestor de bases de datos en todos los sistemas expuestos a internet. Es una herramienta de desarrollo o demostración para crear y gestionar bases de datos de forma fácil y rápida, no para su uso en producción e incluso podría exponer funciones peligrosas a atacantes. El gestor tampoco está diseñado para gestionar bases de datos muy pesadas y podría alcanzar los límites de memoria.

En los sistemas de producción, el administrador del sistema siempre debe realizar las operaciones de gestión de las bases de datos, incluyendo el aprovisionamiento de nuevas bases de datos y las copias de seguridad automatizadas.

Asegúrate de configurar el parámetro db_name correcto (y también dbfilter en caso de que sea necesario) para que el sistema pueda determinar la base de datos de destino en cada solicitud; de lo contrario, los usuarios quedarán bloqueados porque no podrán elegir una base de datos por su cuenta.

Si quieres que solo sea posible acceder a las pantallas de gestión desde un grupo específico de máquinas, usa las funciones de proxy del servidor para bloquear el acceso a todas las rutas que empiecen con /web/database, excepto (quizá) /web/database/selector que muestra la pantalla de selección de base de datos.

Si conservas el acceso a la pantalla de gestión de la base de datos, debes cambiar el valor de admin_passwd``para que no sea ``admin, que es el valor predeterminado. Esta contraseña se verifica antes de permitir que ocurran operaciones que modifican la base de datos.

Guarda la contraseña en un lugar seguro y también es necesario que la generes de forma aleatoria, por ejemplo, de la siguiente manera:

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

El ejemplo anterior genera una cadena imprimible pseudoaleatoria de 32 caracteres.

Restablecer la contraseña maestra¶

Es posible que en algunos casos pierdas la contraseña maestra o se vea comprometida y sea necesario restablecerla. El siguiente proceso está dirigido a los administradores de sistemas con una base de datos de Odoo alojada de forma local y detalla cómo cambiar y volver a cifrarla manualmente.

Ver también

Consulta la siguiente documentación para obtener más información sobre cómo cambiar la contraseña de una cuenta de Odoo.com: Cambiar la contraseña de una cuenta de Odoo.com.

Crear una nueva base de datos local genera una contraseña maestra aleatoria y Odoo recomienda usarla para proteger la base de datos. Esta contraseña se implementa de forma predeterminada, por lo que todas las implementaciones locales de Odoo cuentan con una contraseña maestra segura.

Advertencia

Al crear una base de datos local de Odoo, cualquier persona en internet tiene acceso a la instalación hasta que definas esta contraseña para proteger la base de datos.

La contraseña maestra está en el archivo de configuración de Odoo (odoo.conf u odoorc (archivo oculto)) y es necesaria para modificar, crear o eliminar una base de datos desde la interfaz gráfica de usuario (GUI, por sus siglas en inglés).

Buscar el archivo de configuración¶

Primero, abre el archivo de configuración de Odoo (odoo.conf u odoorc (archivo oculto)).

El archivo de configuración está en c:\ProgramFiles\Odoo{VERSION}\server\odoo.conf.

Según cómo hayas instalado Odoo en la máquina Linux, el archivo de configuración puede estar en una de estas dos ubicaciones:

Instalación mediante el paquete: /etc/odoo.conf
Instalación desde el código fuente: ~/.odoorc

Cambiar la contraseña anterior¶

Una vez que hayas abierto el archivo correspondiente, modifica la contraseña anterior en el archivo de configuración con una contraseña temporal.

Después de ubicar el archivo de configuración, ábrelo con una (GUI). Para ello, haz doble clic en el archivo. El dispositivo debería tener una GUI predeterminada para abrirlo.

Después, modifica la línea de la contraseña maestra admin_passwd = $pbkdf2-sha… a admin_passwd = newpassword1234, por ejemplo. La contraseña puede ser cualquiera, siempre que la guardes de forma temporal. Asegúrate de modificar todos los caracteres después de =.

Example

La línea se ve así: admin_passwd = $pbkdf2-sh39dji295.59mptrfW.9z6HkA$w9j9AMVmKAP17OosCqDxDv2hjsvzlLpF8Rra8I7p/b573hji540mk/.3ek0lg%kvkol6k983mkf/40fjki79m

La línea modificada se ve así: admin_passwd = newpassword1234

Modifica la línea de la contraseña maestra con el comando de Unix detallado a continuación.

Conéctate a la terminal del servidor de Odoo mediante el protocolo Secure Shell (SSH) y edita el archivo de configuración. Para modificarlo, ingresa el siguiente comando: sudo nano /etc/odoo.conf

Luego de abrir el archivo de configuración, modifica la línea de la contraseña maestra admin_passwd = $pbkdf2-sha… a admin_passwd = newpassword1234. La contraseña puede ser cualquiera, siempre que la guardes de forma temporal. Asegúrate de modificar todos los caracteres después de =.

Example

La línea se ve así: admin_passwd = $pbkdf2-sh39dji295.59mptrfW.9z6HkA$w9j9AMVmKAP17OosCqDxDv2hjsvzlLpF8Rra8I7p/b573hji540mk/.3ek0lg%kvkol6k983mkf/40fjki79m

La línea modificada se ve así: admin_passwd = newpassword1234

Importante

Es indispensable que cambies la contraseña por otra en lugar de agregar un punto y coma ; al inicio de la línea para activar un restablecimiento de contraseña. Esto asegura que la base de datos permanezca segura durante todo el proceso de restablecimiento de la contraseña.

Reiniciar el servidor de Odoo¶

Es obligatorio que reinicies el servidor de Odoo después de configurar una contraseña temporal.

Para reiniciar el servidor de Odoo, primero escribe servicios en la barra de búsqueda de Windows. Después, selecciona la aplicación Servicios y ve al servicio Odoo.

Haz clic derecho en Odoo y selecciona Iniciar o Reiniciar. Esta acción reiniciará el servidor de Odoo de forma manual.

Escribe el comando sudo service odoo15 restart para reiniciar el servidor de Odoo.

Nota

Cambia el número después de odoo para que coincida con la versión específica que ejecuta el servidor.

Uso de la interfaz web para volver a cifrar la contraseña¶

Primero, usa un navegador para ir a /web/database/manager o a http://server_ip:port/web/database/manager.

Nota

Sustituye server_ip por la dirección IP de la base de datos y sustituye port por el número de puerto desde el cual es posible acceder a la base de datos.

Después, haz clic en Establecer contraseña maestra y escribe la contraseña temporal que seleccionaste en el campo Contraseña maestra. Después de este paso, escribe una nueva contraseña maestra. La nueva contraseña maestra se cifrará (o encriptará) al hacer clic en el botón Continuar.

Para este momento ya restableciste la contraseña con éxito y el archivo de configuración mostrará la versión cifrada de la nueva contraseña.

Ver también

Consulta la siguiente documentación para obtener más información sobre la seguridad en las bases de datos de Odoo: Seguridad del gestor de bases de datos.

Navegadores compatibles¶

Odoo es compatible con la versión más reciente de los siguientes navegadores.

Google Chrome
Mozilla Firefox
Microsoft Edge
Apple Safari

1: para que varias instalaciones de Odoo usen la misma base de datos de PostgreSQL o para proporcionarle más recursos a ambos softwares.
2: técnicamente, puedes usar una herramienta como socat para realizar el proxy de sockets UNIX a través de la red, pero eso aplica sobre todo al software que solo puedes usar mediante sockets UNIX.
3: o para que solo sea accesible a través de una red interna conmutada por paquetes, pero eso requiere paquetes seguros, protecciones contra suplantación o spoofing de ARP y descarta el uso de Wi-Fi. Incluso en redes internas conmutadas de forma segura se recomienda el despliegue sobre HTTPS y los posibles costos son menores porque los certificados «autofirmados» son más fáciles de desplegar en un entorno controlado que en internet.

Edit on GitHub