Configuración del sistema¶

Este documento describe los pasos básicos para configurar Odoo en producción o en un servidor de internet, sigue la instalación y por lo general no es necesario para un sistema de desarrollo que no está expuesto a internet.

Advertencia

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

dbfilter¶

Odoo es un sistema de tenencia múltiple. Es posible que un solo sistema de Odoo ejecute y preste servicios a varias instancias de la base de datos, también puede tener varias personalizaciones (por ejemplo, cómo se cargan los módulos) dependiendo de la base de datos actual.

Esto no representa un problema al trabajar en el backend (cliente web) como un usuario de la empresa que inició sesión: puede 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.

Para servidores que alojan varias bases de datos en producción, sobre todo si usan sitio web, el dbfilter debe estar configurado. De lo contrario, varias funciones no trabajarán de forma adecuada.

Ejemplos de configuración¶

Para mostrar solo las bases de datos con nombres que empiecen con “mycompany”

establezca lo siguiente en el 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 a mycompany.co.uk, pero no para www2.mycompany.com o helpdesk.mycompany.com.

establezca lo siguiente en el 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 bucles de retorno (también conocidas como loopback) que ocurren desde «localhost», en la misma máquina en la que está instalada el servidor 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.

En /etc/postgresql/<YOUR POSTGRESQL VERSION>/main/pg_hba.conf establezca:

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

En /etc/postgresql/<YOUR POSTGRESQL VERSION>/main/postgresql.conf establezca:

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 manera automática y se establecerá 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 base de datos, entre ellas, la pantalla de gestión de las bases de datos. Para que esta pantalla funcione, el usuario de PostgreSQL necesita tener el permiso createdb.
Los usuarios siempre pueden abandonar las bases de datos que les pertenecen. Para que la pantalla de gestión de la base de datos deje de ser funcional, el usuario de PostgreSQL debe crearse con 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».

establezca lo siguiente en el 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 incorporado¶

Odoo incluye servidores integrados HTTP, cron y de chat en vivo. Estos usan multiprocesos o multihilos.

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 predeterminado es el multihilos, también en los contenedores de docker. Se selecciona al no elegir la opción --workers o establecié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. Lo puede seleccionar al establecer la opción --workers como non-null integer.

Nota

El servidor multiprocesos está personalizado para servidores de Linux, así que no está disponible para Windows.

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 = #worker * ( (light_worker_ratio * light_worker_ram_estimation) + (heavy_worker_ratio * heavy_worker_ram_estimation) )

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 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 solicitudes HTTP a HTTPS.
Redirige las peticiones proxy a «odoo».

establezca lo siguiente en el el archivo de configuración:

proxy_mode = True

En /etc/nginx/sites-enabled/odoo.conf configure:

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

Reforzamiento 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.

Debe forzar las conexiones HTTPS durante un año para cada visitante en NGINX con la línea:

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

Es posible definir una configuración adicional para la cookie session_id, puede agregar el marcador secure para asegurarse de que nunca se transmita por HTTP y samesite=lax para prevenir 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 y archivos adjuntos estáticos¶

Con fines de mejorar el proceso de desarrollo, Odoo gestiona todos los archivos estáticos y adjuntos en sus módulos de forma directa. Sin embargo, puede que esto no sea lo mejor en cuestión de rendimiento, además solo debería utilizar un servidor HTTP estático para gestionar sus archivos estáticos.

Gestión de archivos estáticos¶

Los archivos estáticos de Odoo se encuentran en la carpeta static/ de cada módulo. Por lo tanto, los archivos estáticos se pueden gestionar al interceptar todas las solicitudes 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.

Con la configuración NGINX (https) anterior, agregue los siguientes bloques map y location para gestionar 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 su instalación, sobre todo de --addons-path.

Example

Digamos que Odoo se instaló a través de los paquetes de Debian para Community y Enterprise. Además, la ruta de --addons-path es '/usr/lib/python3/dist-packages/odoo/addons'.

root y try_files deberían ser:

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

Digamos que Odoo se instaló a través del código fuente, que tanto el repositorio de Git de Community como el de Enterprise se clonaron 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'.

root y try_files deberían ser:

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

Alojamiento de 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

La extensión X-Sendfile para Apache (y servidores web compatibles) no necesita de ninguna configuración adicional.
La extensión X-Accel para NGINX sí necesita de la configuración que se encuentra a continuación:
```
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, tenga en cuenta que asegurar un sistema de información es un proceso continuo, no una operación única. En cualquier momento, su entorno será igual de seguro que el vínculo más débil.

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 con acceso a internet, asegúrese de considerar los siguientes temas relacionados a la seguridad:

Siempre configure una contraseña de administrador del super-admin que sea fuerte y también restrinja el acceso a las páginas de gestión de la base de datos tan pronto como configure el sistema. Consulte 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.
Configure su servidor en un modo multiproceso con los límites adecuados que correspondan a su uso habitual (memoria, CPU y tiempos de espera). Consulte Servidor incorporado.
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.
Considere instalar un límite en su proxy o firewall para evitar ataques de fuerza bruta y negar ataques al servicio. También consulte Bloquear ataques de fuerza bruta para obtener más información sobre medidas específicas.

Muchos proveedores de red ofrecen mitigación automática para ataques de denegación de servicio distribuido (DDoS), pero suele ser un servicio opcional. Le recomendamos que lo consulte con ellos.
Siempre que sea posible, aloje sus instancias de demostración, prueba o preproducción en máquinas distintas a las de producción y aplique las mismas precauciones de seguridad que usa para 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 está alojando a varios clientes, aísle los datos y archivos de cada uno con contenedores o técnicas de tipo «jail» adecuadas.
Establezca copias de seguridad diarias de sus bases de datos y datos de almacenamiento de archivos. Cópielos a un servidor de archivo remoto al que no se pueda acceder desde ese 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.

Los registros de entradas 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

Estos registros se pueden analizar con facilidad por un sistema de prevención de intrusos como fail2ban.

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

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

Esto se podría utilizar con una definición de «jail» para bloquear la dirección IP que ataca HTTP(S).

Este es un ejemplo de cómo podría bloquear la dirección IP durante 15 minutos cuando se detectan 10 intentos fallidos de inicio de sesión 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 se menciona un poco sobre admin_passwd.

Esta configuración se utiliza en todas las pantallas de gestión de bases de datos para crear, eliminar, hacer copias (también conocidas como dumps) o restaurar bases de datos.

Si no se debería acceder a las pantallas de gestión de ninguna manera debe configurar la opción list_db en False para bloquear el acceso a todas las pantallas de selección y gestión de 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 sistemas en producción, las operaciones de gestión de la base de datos siempre las debe realizar el administrador del sistema, por ejemplo, el aprovisionamiento de las bases de datos nuevas y las copias de seguridad automáticas.

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 solo se puede acceder a las pantallas de gestión desde un grupo de máquinas específicas, use 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 se debe de mantener el acceso a la pantalla de gestión de la base de datos, la configuración de admin_passwd se debe de cambiar de la predeterminada que es admin: esta contraseña se debe de revisar antes de permitir operaciones que alteren la base de datos.

Se debe guardar en un lugar seguro y se debe de generar aleatoriamente, p. ej.

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

que 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

Consulte esta 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 de Odoo local cualquiera dentro de internet podrá entrar a la instalación hasta que use la contraseña para asegurar la base de datos.

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

Ubicar el archivo de configuración¶

Primero abra el archivo de configuración de Odoo (odoo.conf o odoorc (archivo oculto)).

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

Según cómo se instale Odoo en la máquina Linux, es posible que el archivo de configuración se encuentre en uno de dos lugares diferentes:

Instalación del paquete: /etc/odoo.conf
Instalación de la fuente: ~/.odoorc

Cambiar la contraseña anterior¶

Una vez que haya abierto el archivo adecuado, modifique la contraseña anterior en el archivo de configuración a 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 modifique la línea de la contraseña maestra admin_passwd = $pbkdf2-sha… a admin_passwd = newpassword1234, por ejemplo. Elija la contraseña que desee, siempre y cuando la almacene de forma temporal. Asegúrese de modificar todos los caracteres después del =.

Example

La línea aparece de la siguiente forma: admin_passwd = $pbkdf2-sh39dji295.59mptrfW.9z6HkA$w9j9AMVmKAP17OosCqDxDv2hjsvzlLpF8Rra8I7p/b573hji540mk/.3ek0lg%kvkol6k983mkf/40fjki79m

La línea modificada aparece de la siguiente manera: admin_passwd = newpassword1234

Modifique la línea de la contraseña maestra con el comando de Unix que aparece 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 aparece de la siguiente forma: admin_passwd = $pbkdf2-sh39dji295.59mptrfW.9z6HkA$w9j9AMVmKAP17OosCqDxDv2hjsvzlLpF8Rra8I7p/b573hji540mk/.3ek0lg%kvkol6k983mkf/40fjki79m

La línea modificada aparece de la siguiente manera: 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¶

Después de configurar una contraseña temporal debe reiniciar el servidor de Odoo.

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

Haga clic derecho en Odoo y seleccione 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

Cambie el número después de odoo para que coincida con la versión específica en la que está ejecutando el servidor.

Usar la interfaz web para volver a encriptar la contraseña¶

Primero, vaya a /web/database/manager o a http://server_ip:port/web/database/manager desde un navegador.

Nota

Reemplace server_ip con la dirección IP de la base de datos y reemplace port con 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.

En este punto ya restableció la contraseña con éxito, así que en el archivo de configuración aparecerá una versión encriptada de la nueva contraseña.

Ver también

Consulte la siguiente documentación para obtener más información sobre la seguridad de la base 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 PostgreSQL, o brindar más recursos de cálculo para el software.
2: técnicamente una herramienta como socat puede utilizarse para proxy UNIX sockets a través de redes, pero eso es sobre todo para el software que sólo se puede utilizar a través de UNIX sockets
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