Configuration du système¶

Ce document décrit les étapes de base pour configurer Odoo en production ou sur un serveur Internet. Il suit installation, et n’est généralement pas nécessaire pour un développement de systèmes qui n’est pas exposé sur Internet.

Avertissement

Si vous configurez un serveur public, assurez-vous de consulter nos recommandations Sécurité !

filtre db¶

Odoo est un système multi-tenant : un seul système Odoo peut exécuter et servir plusieurs instances de base de données. Elle est également hautement personnalisable, avec des personnalisations (à partir des modules en cours de chargement) en fonction de la « base de données actuelle ».

Ce n’est pas un problème lorsque vous travaillez avec le backend (client Web) en tant qu’utilisateur connecté de l’entreprise : la base de données peut être sélectionnée lors de la connexion et les personnalisations chargées ensuite.

Cependant c’est un problème pour les utilisateurs non connectés (portail, site web) qui ne sont pas liés à une base de données : Odoo a besoin de savoir quelle base de données doit être utilisée pour charger la page du site ou effectuer l’opération. Si la multi-location n’est pas utilisée, ce n’est pas un problème, il n’y a qu’une seule base de données à utiliser, mais s’il y a plusieurs bases de données accessibles, Odoo a besoin d’une règle pour savoir laquelle utiliser.

C’est l’un des objectifs de db-filter : il spécifie comment la base de données doit être sélectionnée en fonction du nom d’hôte (domaine) demandé. La valeur est une expression régulière, incluant éventuellement le nom d’hôte injecté dynamiquement (%h) ou le premier sous-domaine (%d) via lequel le système est accédé.

Pour les serveurs hébergeant plusieurs bases de données en production, surtout si website est utilisé, dbfilter doit être défini, sinon un certain nombre de fonctionnalités ne fonctionneront pas correctement.

Exemples de configuration¶

Afficher uniquement les bases de données dont les noms commencent par « monentreprise »

[options]
dbfilter = ^mycompany.*$

Afficher uniquement les bases de données correspondant au premier sous-domaine après www : par exemple, la base de données « mycompany » sera affichée si la requête entrante a été envoyée à www.mycompany.com ou mycompany.co.uk ``, mais pas pour ``www2.mycompany.com ou helpdesk.mycompany.com.

[options]
dbfilter = ^%d$

Note

La définition d’un filtre de base de données approprié est un élément important pour sécuriser votre déploiement. Une fois qu’il fonctionne correctement et ne correspond qu’à une seule base de données par nom d’hôte, il est fortement recommandé de bloquer l’accès aux écrans du gestionnaire de bases de données, et d’utiliser le paramètre de démarrage --no-database-list pour éviter de lister vos bases de données, et de bloquer l’accès aux écrans de gestion de la base de données. Voir aussi security.

PostgreSQL¶

Par défaut, PostgreSQL autorise uniquement les connexions via les sockets UNIX et les connexions de bouclage (à partir de « localhost », la même machine sur laquelle le serveur PostgreSQL est installé).

Le socket UNIX convient si vous souhaitez qu’Odoo et PostgreSQL s’exécutent sur la même machine et constitue la valeur par défaut lorsqu’aucun hôte n’est fourni, mais si vous souhaitez qu’Odoo et PostgreSQL s’exécutent sur des machines différentes [#différentes machines]_, il faudra le faire. écouter les interfaces réseau 2, soit :

Acceptez uniquement les connexions de bouclage et « utilisez un tunnel SSH »_ entre la machine sur laquelle Odoo s’exécute et celle sur laquelle PostgreSQL s’exécute, puis configurez Odoo pour qu’il se connecte à son extrémité du tunnel.
Acceptez les connexions à la machine sur laquelle Odoo est installé, éventuellement via SSL (voir Paramètres de connexion PostgreSQL pour plus de détails), puis configurez Odoo pour qu’il se connecte via le réseau

Exemple de configuration¶

Autoriser la connexion TCP sur localhost
Autoriser la connexion TCP à partir du réseau 192.168.1.x

dans /etc/postgresql/<VOTRE VERSION POSTGRESQL>/main/pg_hba.conf définissez :

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

dans /etc/postgresql/<VOTRE VERSION POSTGRESQL>/main/postgresql.conf définissez :

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

Configurer Odoo¶

Prêt à l’emploi, Odoo se connecte à un postgres local sur un socket UNIX via le port 5432. Cela peut être remplacé à l’aide de la base de données lorsque votre déploiement Postgres n’est pas local et/ou n’utilise pas les paramètres d’installation par défaut.

Les packaged installateurs créeront automatiquement un nouvel utilisateur (odoo) et le définiront comme utilisateur de la base de données.

Les écrans de gestion de la base de données sont protégés par le paramètre admin_passwd. Ce paramètre ne peut être défini qu’à l’aide de fichiers de configuration et est simplement vérifié avant d’effectuer des modifications sur la base de données. Il doit être défini sur une valeur générée aléatoirement pour garantir que des tiers ne puissent pas utiliser cette interface.
Toutes les opérations de base de données utilisent la base de données, y compris l’écran de gestion de la base de données. Pour que l’écran de gestion de la base de données fonctionne, il faut que l’utilisateur de PostgreSQL ait le droit createdb.
Les utilisateurs peuvent toujours supprimer les bases de données qu’ils possèdent. Pour que l’écran de gestion de la base de données soit complètement non fonctionnel, l’utilisateur PostgreSQL doit être créé avec no-createdb et la base de données doit appartenir à un autre utilisateur PostgreSQL.

Avertissement
l’utilisateur PostgreSQL ne doit pas être un superutilisateur

Exemple de configuration¶

connectez-vous à un serveur PostgreSQL sur 192.168.1.2
port 5432
en utilisant un compte utilisateur “odoo”,
avec “pwd” comme mot de passe
filtrer uniquement la base de données dont le nom commence par « mycompany »

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

SSL entre Odoo et PostgreSQL¶

Depuis Odoo 11.0, vous pouvez imposer une connexion SSL entre Odoo et PostgreSQL. dans Odoo, le db_sslmode contrôle la sécurité SSL de la connexion avec une valeur choisie parmi “disable”, “allow”, “prefer”, “require”, “verify-ca” ou “verify-full”

Doc PostgreSQL

Serveur intégré¶

Odoo comprend des serveurs HTTP intégrés, utilisant soit le multithreading, soit le multitraitement.

Pour une utilisation en production, il est recommandé d’utiliser le serveur multitraitement car il augmente la stabilité, utilise un peu mieux les ressources informatiques et peut être mieux surveillé et limité en ressources.

Multiprocessing is enabled by configuring :option: a non-zero number of worker processes odoo-bin –workers, the number of workers should be based on the number of cores in the machine (possibly with some room for cron workers depending on how much cron work is predicted)
Les limites des travailleurs peuvent être configurées en fonction de la configuration matérielle pour éviter l’épuisement des ressources

Avertissement

le mode multitraitement n’est actuellement pas disponible sous Windows

Calcul du nombre de travailleurs¶

Règle générale : (#CPU * 2) + 1
Les travailleurs Cron ont besoin d’un processeur
1 travailleur ~= 6 utilisateurs simultanés

calcul de la taille de la mémoire¶

Nous considérons que 20 % des demandes sont des demandes lourdes, tandis que 80 % sont des demandes plus simples.
Un gros travailleur, quand tous les champs calculés sont bien conçus, les requêtes SQL sont bien conçues, … est estimé consommer environ 1 Go de RAM
On estime qu’un travailleur plus léger, dans le même scénario, consommera environ 150 Mo de RAM.

RAM nécessaire = #worker * ( (light_worker_ratio * light_worker_ram_estimation) + (heavy_worker_ratio * heavy_worker_ram_estimation) )

Chat en direct¶

En multitraitement, un travailleur LiveChat dédié est automatiquement démarré et écoute sur odoo-bin –gevent-port mais le client ne s’y connectera pas.

À la place, vous devez disposer d’un proxy redirigeant les requêtes dont l’URL commence par /websocket/ vers le port gevent. Les autres requêtes doivent être transmises par proxy au port odoo-bin –http-port.

Pour y parvenir, vous devrez déployer un proxy inverse devant Odoo, comme nginx ou apache. Ce faisant, vous devrez transférer d’autres en-têtes http à Odoo et activer le mode proxy_mode dans la configuration d’Odoo pour qu’Odoo lise ces en-têtes.

Exemple de configuration¶

Serveur avec 4 CPU, 8 Threads
60 utilisateurs simultanés
60 utilisateurs / 6 = 10 <- nombre théorique de travailleur nécessaire
(4 * 2) + 1 = 9 <- nombre maximal théorique de travailleur
Nous utiliserons 8 travailleurs + 1 pour cron. Nous utiliserons également un système de surveillance pour mesurer la charge du processeur et vérifier si elle est comprise entre 7 et 7,5.
RAM = 9 * ((0,8*150) + (0,2*1024)) ~= 3Go de RAM pour 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¶

Qu’il soit accessible via un site Web/client Web ou un service Web, Odoo transmet les informations d’authentification en texte clair. Cela signifie qu’un déploiement sécurisé d’Odoo doit utiliser HTTPS3. La terminaison SSL peut être implémentée via à peu près n’importe quel proxy de terminaison SSL, mais nécessite la configuration suivante :

Activez le mode proxy d’Odoo. Cela ne devrait être activé que lorsque Odoo est derrière un proxy inverse
Configurez l’exemple de terminaison Nginx du proxy de terminaison SSL.
Configurez le proxy lui-même, exemple de proxy Nginx.
Votre proxy de terminaison SSL devrait également rediriger automatiquement les connexions non sécurisées vers le port sécurisé

Exemple de configuration¶

Rediriger les requêtes http vers https
Demandes de proxy à odoo

proxy_mode = True

dans /etc/nginx/sites-enabled/odoo.conf définissez :

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

  # Redirect requests to odoo backend server
  location / {
    # Add Headers for odoo proxy mode
    proxy_set_header X-Forwarded-Host $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;
  }

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

Odoo en tant qu’application WSGI¶

Il est également possible de monter Odoo en tant qu’application WSGI standard. Odoo fournit la base d’un script de lancement WSGI sous le nom de odoo-wsgi.example.py. Ce script doit être personnalisé (éventuellement après l’avoir copié depuis le répertoire d’installation) pour définir correctement la configuration directement dans odoo.tools.config plutôt que via la ligne de commande ou un fichier de configuration.

Cependant, le serveur WSGI n’exposera que le point de terminaison HTTP principal pour le client Web, le site Web et l’API du service Web. Parce qu’Odoo ne contrôle plus la création de travailleurs, il ne peut pas configurer de travailleurs cron ou livechat.

Travailleurs de Cron¶

Pour exécuter des tâches cron pour un déploiement Odoo comme le nécessite une application WSGI

Un Odoo classique (exécuté via odoo-bin)
Connecté à la base de données dans laquelle les tâches cron doivent être exécutées via odoo-bin
Qui ne doit pas être exposé au réseau. Pour garantir que les exécuteurs cron ne sont pas accessibles au réseau, il est possible de désactiver entièrement le serveur HTTP intégré avec odoo-bin –no-http` ou en définissant http_enable = False dans le fichier de configuration.

Chat en direct¶

Le deuxième sous-système problématique pour les déploiements WSGI est le LiveChat : où la plupart des connexions HTTP sont relativement courtes et libèrent rapidement leur processus de travail pour la prochaine requête, LiveChat nécessite une connexion de longue durée pour chaque client afin de mettre en œuvre des notifications en temps quasi réel. .

Ceci est en conflit avec le modèle de travail basé sur les processus, car cela bloquera les processus de travail et empêchera les nouveaux utilisateurs d’accéder au système. Cependant, ces connexions de longue durée font très peu et restent pour la plupart stationnées en attente de notifications.

Les solutions pour prendre en charge le livechat/motifications dans une application WSGI sont :

Déployez une version threadée d’Odoo (au lieu d’une version de pré-forkage basée sur un processus) et redirigez uniquement les requêtes vers les URL commençant par /websocket/ vers cet Odoo, c’est la plus simple et l’URL du websocket peut servir d’instance cron .
Déployez un Odoo événementiel via odoo-gevent et des requêtes proxy commençant par /websocket/ sur le port gevent.

Servir des fichiers statiques et des pièces jointes¶

Pour faciliter le développement, Odoo sert directement tous les fichiers statiques et pièces jointes dans ses modules. Cela n’est peut-être pas idéal en termes de performances, et les fichiers statiques doivent généralement être servis par un serveur HTTP statique.

Servir des fichiers statiques¶

Les fichiers statiques Odoo sont situés dans le dossier static/ de chaque module, de sorte que les fichiers statiques peuvent être servis en interceptant toutes les requêtes adressées à /MODULE/static/FILE et en recherchant le bon module. (et fichier) dans les différents chemins des addons.

Example

Supposons qu’Odoo ait été installé via les packages Debian pour Community et Enterprise et que le –addons-path <odoo-bin –addons-path>` est '/usr/lib/python3/dist-packages/ odoo/addons'.

En utilisant la configuration NGINX (https) ci-dessus, le bloc d’emplacement suivant doit être ajouté pour servir les fichiers statiques via NGINX.

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

# Serve static files right away
location ~ ^/[^/]+/static/.+$ {
    root /usr/lib/python3/dist-packages/odoo/addons;
    try_files $uri @odoo;
    expires 24h;
}

Example

Say Odoo has been installed via the source. The two git repositories for Community and Enterprise have been cloned in /opt/odoo/community and /opt/odoo/enterprise respectively and '/opt/odoo/community/odoo/addons,/opt/odoo/community/addons,/opt/odoo/enterprise'.

En utilisant la configuration NGINX (https) ci-dessus, le bloc d’emplacement suivant doit être ajouté pour servir les fichiers statiques via NGINX.

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

# Serve static files right away
location ~ ^/[^/]+/static/.+$ {
    root /opt/odoo;
    try_files /community/odoo/addons$uri /community/addons$uri /enterprise$uri @odoo;
    expires 24h;
}

Avertissement

La configuration NGINX réelle dont vous avez besoin dépend fortement de votre propre installation. Les deux extraits ci-dessus ne mettent en évidence que deux configurations possibles et ne peuvent pas être utilisés tels quels.

Diffusion de pièces jointes¶

Les pièces jointes sont des fichiers stockés dans le magasin de fichiers dont l’accès est réglementé par Odoo. Ils ne sont pas directement accessibles via un serveur Web statique, car leur accès nécessite plusieurs recherches dans la base de données pour déterminer où les fichiers sont stockés et si l’utilisateur actuel peut y accéder ou non.

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 CLI flag (this unique flag is used for both X-Sendfile and X-Accel).

Note

L’extension X-Sendfile pour Apache (et les serveurs Web compatibles) ne nécessite aucune configuration supplémentaire.
L’extension X-Accel pour NGINX nécessite la configuration supplémentaire suivante :
```
location /web/filestore {
    internal;
    alias /path/to/odoo/data-dir/filestore;
}
```
In case you don’t know what is the path to your filestore, start Odoo with the option and navigate to the /web/filestore URL directly via Odoo (don’t navigate to the URL via NGINX). This logs a warnings, the message contains the configuration you need.

Sécurité¶

Pour commencer, gardez à l’esprit que la sécurisation d’un système d’information est un processus continu et non une opération ponctuelle. À tout moment, votre sécurité dépend du maillon le plus faible de votre environnement.

Ne considérez donc pas cette section comme la liste ultime des mesures qui permettront d’éviter tous les problèmes de sécurité. Il s’agit uniquement d’un résumé des premiers éléments importants que vous devez vous assurer d’inclure dans votre plan d’action de sécurité. Le reste viendra des meilleures pratiques de sécurité de votre système d’exploitation et de votre distribution, des meilleures pratiques en termes d’utilisateurs, de mots de passe et de gestion du contrôle d’accès, etc.

Lors du déploiement d’un serveur accessible sur Internet, veillez à prendre en compte les sujets suivants liés à la sécurité :

Définissez toujours un mot de passe administrateur super-administrateur fort et restreignez l’accès aux pages de gestion de la base de données dès que le système est configuré. Voir Sécurité du gestionnaire de base de données.
Choisissez des identifiants uniques et des mots de passe forts pour tous les comptes d’administrateur sur toutes les bases de données. N’utilisez pas « admin » comme identifiant. N’utilisez pas ces connexions pour les opérations quotidiennes, uniquement pour contrôler/gérer l’installation. N’utilisez jamais de mots de passe par défaut comme admin/admin, même pour les bases de données de test/stade.
N’installez pas de données de démonstration sur des serveurs accessibles sur Internet. Les bases de données contenant des données de démonstration contiennent des identifiants et des mots de passe par défaut qui peuvent être utilisés pour accéder à vos systèmes et causer des problèmes importants, même sur les systèmes de test/de développement.
Use appropriate database filters to restrict the visibility of your databases according to the hostname. See filtre db.You may also use to provide your own (comma-separated) list of available databases to filter from, instead of letting the system fetch them all from the database backend.
Once your db_name and db_filter are configured and only match a single database per hostname, you should set list_db configuration option to False, to prevent listing databases entirely, and to block access to the database management screens (this is also exposed as the command-line option)
Make sure the PostgreSQL user is not a super-user, and that your databases are owned by a different user. For example they could be owned by the postgres super-user if you are using a dedicated non-privileged db_user. See also Configurer Odoo.
Maintenez les installations à jour en installant régulièrement les dernières versions, soit via GitHub, soit en téléchargeant la dernière version depuis https://www.odoo.com/page/download ou http://nightly.odoo.com
Configurez votre serveur en mode multi-processus avec des limites appropriées correspondant à votre utilisation habituelle (mémoire/CPU/timeouts). Voir aussi Serveur intégré.
Run Odoo behind a web server providing HTTPS termination with a valid SSL certificate, in order to prevent eavesdropping on cleartext communications. SSL certificates are cheap, and many free options exist. Configure the web proxy to limit the size of requests, set appropriate timeouts, and then enable the option. See also HTTPS.
Si vous devez autoriser l’accès SSH à distance à vos serveurs, assurez-vous de définir un mot de passe fort pour tous les comptes, pas seulement « root ». Il est fortement recommandé de désactiver entièrement l’authentification par mot de passe et d’autoriser uniquement l’authentification par clé publique. Envisagez également de restreindre l’accès via un VPN, d’autoriser uniquement les adresses IP de confiance dans le pare-feu et/ou d’exécuter un système de détection par force brute tel que « fail2ban » ou équivalent.
Pensez à installer une limitation de débit appropriée sur votre proxy ou pare-feu, pour empêcher les attaques par force brute et les attaques par déni de service. Voir aussi Bloquer les attaques par force brute pour des mesures spécifiques.

De nombreux fournisseurs de réseau proposent une atténuation automatique des attaques par déni de service distribué (DDOS), mais il s’agit souvent d’un service facultatif, vous devez donc les consulter.
Dans la mesure du possible, hébergez vos instances de démonstration/test/stade publiques sur des machines différentes de celles de production. Et appliquez les mêmes précautions de sécurité que pour la production.
Si votre serveur Odoo public a accès à des ressources ou services réseau internes sensibles (par exemple via un VLAN privé), mettez en œuvre des règles de pare-feu appropriées pour protéger ces ressources internes. Cela garantira que le serveur Odoo ne peut pas être utilisé accidentellement (ou à la suite d’actions malveillantes d’un utilisateur) pour accéder ou perturber ces ressources internes. Généralement, cela peut être fait en appliquant une règle DENY sortante par défaut sur le pare-feu, puis en autorisant explicitement uniquement l’accès aux ressources internes auxquelles le serveur Odoo doit accéder. Le « contrôle d’accès au trafic IP Systemd <http://0pointer.net/blog/ip-accounting-and-access-lists-with-systemd.html> »_ peut également être utile pour implémenter le contrôle d’accès au réseau par processus.
Si votre serveur Odoo public se trouve derrière un pare-feu d’application Web, un équilibreur de charge, un service de protection DDoS transparent (comme CloudFlare) ou un périphérique similaire au niveau du réseau, vous souhaiterez peut-être éviter l’accès direct au système Odoo. Il est généralement difficile de garder secrètes les adresses IP des points de terminaison de vos serveurs Odoo. Par exemple, ils peuvent apparaître dans les journaux du serveur Web lors de l’interrogation des systèmes publics, ou dans les en-têtes des e-mails publiés depuis Odoo. Dans une telle situation, vous souhaiterez peut-être configurer votre pare-feu de manière à ce que les points de terminaison ne soient pas accessibles publiquement, sauf à partir des adresses IP spécifiques de votre WAF, équilibreur de charge ou service proxy. Les fournisseurs de services comme CloudFlare maintiennent généralement une liste publique de leurs plages d’adresses IP à cet effet.
Si vous hébergez plusieurs clients, isolez les données et les fichiers des clients les uns des autres à l’aide de conteneurs ou de techniques de « prison » appropriées.
Configurez des sauvegardes quotidiennes de vos bases de données et des données de votre magasin de fichiers, et copiez-les sur un serveur d’archivage distant qui n’est pas accessible depuis le serveur lui-même.

Bloquer les attaques par force brute¶

Pour les déploiements Internet, les attaques par force brute sur les mots de passe des utilisateurs sont très courantes, et cette menace ne doit pas être négligée pour les serveurs Odoo. Odoo émet une entrée de journal chaque fois qu’une tentative de connexion est effectuée et rapporte le résultat : succès ou échec, ainsi que la connexion cible et l’adresse IP source.

Les entrées du journal auront la forme suivante.

Échec de connexion : :

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

Connexion réussie:

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

Ces journaux peuvent être facilement analysés par un système de prévention des intrusions tel que « fail2ban ».

Par exemple, la définition de filtre fail2ban suivante doit correspondre à un échec de connexion : :

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

Cela pourrait être utilisé avec une définition de prison pour bloquer l’adresse IP attaquante sur HTTP(S).

Voici à quoi cela pourrait ressembler si vous bloquiez l’adresse IP pendant 15 minutes lorsque 10 tentatives de connexion infructueuses sont détectées à partir de la même IP en 1 minute : :

[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

Sécurité du gestionnaire de base de données¶

Configurer Odoo a mentionné admin_passwd en passant.

Ce paramètre est utilisé sur tous les écrans de gestion de bases de données (pour créer, supprimer, vider ou restaurer des bases de données).

Si les écrans de gestion ne doivent pas être accessibles du tout, vous devez définir l’option de configuration list_db à False, pour bloquer l’accès à tous les écrans de sélection et de gestion de la base de données.

Avertissement

Il est fortement recommandé de désactiver le gestionnaire de base de données pour tout système connecté à Internet ! Il est conçu comme un outil de développement/démonstration, pour faciliter la création et la gestion rapides de bases de données. Il n’est pas conçu pour être utilisé en production et peut même exposer des fonctionnalités dangereuses aux attaquants. Il n’est pas non plus conçu pour gérer des bases de données volumineuses et peut entraîner des limites de mémoire.

Sur les systèmes de production, les opérations de gestion des bases de données doivent toujours être effectuées par l’administrateur système, y compris la mise à disposition de nouvelles bases de données et les sauvegardes automatisées.

Assurez-vous de configurer un paramètre db_name approprié (et éventuellement db_filter également) afin que le système puisse déterminer la base de données cible pour chaque requête, sinon les utilisateurs seront bloqués car ils ne seront pas autorisés à choisir la base de données elle-même.

Si les écrans de gestion ne doivent être accessibles qu’à partir d’un ensemble sélectionné de machines, utilisez les fonctionnalités du serveur proxy pour bloquer l’accès à toutes les routes commençant par /web/database sauf (peut-être) /web/database/selector qui affiche l’écran de sélection de la base de données.

Si l’écran de gestion de la base de données doit rester accessible, le paramètre admin_passwd doit être modifié par rapport à sa valeur par défaut admin : ce mot de passe est vérifié avant d’autoriser les opérations de modification de la base de données.

Il doit être stocké en toute sécurité et doit être généré de manière aléatoire, par ex.

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

qui générera une chaîne imprimable pseudo-aléatoire de 32 caractères.

Navigateurs pris en charge¶

Odoo prend en charge tous les principaux navigateurs de bureau et mobiles disponibles sur le marché, à condition qu’ils soient pris en charge par leurs éditeurs.

Voici les navigateurs pris en charge :

Google Chrome
Mozilla Firefox
Microsoft Bord
Safari aux pommes

Avertissement

Veuillez vous assurer que votre navigateur est à jour et toujours pris en charge par son éditeur avant de déposer un rapport de bug.

Note

Depuis Odoo 13.0, ES6 est pris en charge. Par conséquent, la prise en charge d’IE est abandonnée.

1: pour que plusieurs installations Odoo utilisent la même base de données PostgreSQL, ou pour fournir plus de ressources informatiques aux deux logiciels.
2: techniquement, un outil comme socat peut être utilisé pour proxy les sockets UNIX sur les réseaux, mais c’est principalement pour les logiciels qui ne peuvent être utilisés que sur les sockets UNIX
3: ou être accessible uniquement sur un réseau interne à commutation de paquets, mais cela nécessite des commutateurs sécurisés, des protections contre « l’usurpation d’identité ARP » et exclut l’utilisation du WiFi. Même sur des réseaux sécurisés à commutation de paquets, le déploiement via HTTPS est recommandé et les coûts possibles sont réduits car les certificats « auto-signés » sont plus faciles à déployer dans un environnement contrôlé que sur Internet.