Конфігурація системи¶

У цьому документі описано основні кроки для налаштування Odoo у виробництві або на сервері з доступом до Інтернету. Він іде за installation і зазвичай не є необхідним для систем розробки, які не доступні в Інтернеті.

Попередження

Якщо ви налаштовуєте загальнодоступний сервер, обов’язково ознайомтеся з нашими рекомендаціями Безпека!

dbfilter¶

Odoo є системою з кількома клієнтами: одна система Odoo може працювати та обслуговувати декілька екземплярів бази даних. Він також легко настроюється, з налаштуваннями (починаючи з модулів, що завантажуються) залежно від «поточної бази даних».

Це не проблема під час роботи з серверною частиною (веб-клієнтом) як користувач компанії, який увійшов у систему: базу даних можна вибрати під час входу в систему, а налаштування завантажити після цього.

Однак це проблема для незареєстрованих користувачів (портал, веб-сайт), які не прив’язані до бази даних: Odoo потрібно знати, яку базу даних слід використовувати для завантаження сторінки веб-сайту або виконання операції. Якщо багатокористувацький режим не використовується, це не проблема, можна використовувати лише одну базу даних, але якщо є кілька доступних баз даних, Odoo потребує правила, щоб знати, яку з них слід використовувати.

Це одна з цілей --db-filter: указує, як слід вибирати базу даних на основі імені хоста (домену), який запитується. Значенням є регулярний вираз, який, можливо, включає динамічно введене ім’я хоста (%h) або перший субдомен (%d), через який здійснюється доступ до системи.

Для серверів, на яких розміщено кілька баз даних у робочому стані, особливо якщо використовується веб-сайт, dbfilter має бути встановлений, інакше низка функцій не працюватиме належним чином.

Зразки конфігурації¶

Показати лише бази даних, імена яких починаються з «моя компанія»

у файлі конфігурації встановити:

[options]
dbfilter = ^mycompany.*$

Показувати лише бази даних, які відповідають першому субдомену після www: наприклад, база даних «mycompany» буде показана, якщо вхідний запит було надіслано на www.mycompany.com або mycompany.co.uk , але не для www2.mycompany.com або helpdesk.mycompany.com.

у файлі конфігурації встановити:

[options]
dbfilter = ^%d$

Примітка

Налаштування правильного --db-filter є важливою частиною безпеки вашого розгортання. Якщо він працює належним чином і відповідає лише одній базі даних на ім’я хоста, настійно рекомендується заблокувати доступ до екранів менеджера баз даних і використовувати параметр запуску --no-database-list, щоб запобігти переліку ваших баз даних, і блокувати доступ до екранів керування базою даних. Дивіться також security.

PostgreSQL¶

За замовчуванням PostgreSQL дозволяє лише з’єднання через сокети UNIX і петлеві з’єднання (з «localhost», тієї самої машини, на якій встановлено сервер PostgreSQL).

Сокет UNIX підходить, якщо ви хочете, щоб Odoo і PostgreSQL виконувалися на одній машині, і є стандартним, якщо хост не надано, але якщо ви хочете, щоб Odoo і PostgreSQL виконувалися на різних машинах 1, потрібно буде прослуховувати мережеві інтерфейси 2 або:

Приймайте лише петлеві з’єднання та використовуйте тунель SSH між машиною, на якій працює Odoo, і тією, на якій працює PostgreSQL, а потім налаштуйте Odoo для підключення до свого кінця тунелю
Прийміть підключення до комп’ютера, на якому встановлено Odoo, можливо, через ssl (додаткову інформацію див. у розділі Параметри з’єднання PostgreSQL), а потім налаштуйте Odoo для підключення через мережу

Зразок конфігурації¶

Дозволити підключення TCP на локальному хості
Дозволити підключення TCP з мережі 192.168.1.x

в /etc/postgresql/<YOUR POSTGRESQL VERSION>/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

в /etc/postgresql/<YOUR POSTGRESQL VERSION>/main/postgresql.conf встановити:

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

Налаштування Odoo¶

З коробки Odoo підключається до локального сокета postgres через UNIX через порт 5432. Це можна змінити за допомогою параметрів бази даних, якщо ваше розгортання Postgres не локальне та/або не використовує параметри встановлення за замовчуванням.

Запаковані інсталятори <packages> автоматично створить нового користувача (odoo) і встановить його як користувача бази даних.

Екрани керування базою даних захищені параметром admin_passwd. Цей параметр можна встановити лише за допомогою файлів конфігурації, і його просто перевіряють перед внесенням змін до бази даних. Його слід встановити на випадково згенероване значення, щоб сторонні сторони не могли використовувати цей інтерфейс.
Усі операції з базою даних використовують параметри бази даних, включаючи екран керування базою даних. Щоб екран керування базою даних працював, необхідно, щоб користувач PostgreSQL мав право createdb.
Користувачі завжди можуть видалити бази даних, якими вони володіють. Щоб екран керування базою даних був повністю нефункціональним, користувач PostgreSQL має бути створений за допомогою no-createdb, а база даних має належати іншому користувачеві PostgreSQL.

Попередження
користувач PostgreSQL не повинен бути суперкористувачем

Зразок конфігурації¶

підключитися до сервера PostgreSQL на 192.168.1.2
порт 5432
використовуючи обліковий запис користувача „odoo“,
з „pwd“ як паролем
фільтрація лише db з іменем, що починається з „моя компанія“

у файлі конфігурації встановити:

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

SSL між Odoo і PostgreSQL¶

Починаючи з Odoo 11.0, ви можете примусово встановити ssl-з’єднання між Odoo і PostgreSQL. в Odoo db_sslmode контролює безпеку SSL з’єднання зі значенням, вибраним із „disable“, „allow“, „prefer“, „require, „verify-ca“ або „verify-full“

Документація PostgreSQL

Вбудований сервер¶

Odoo містить вбудовані сервери HTTP, cron і живого чату, які використовують або багатопотоковість, або багатопроцесорність.

Багатопоточний сервер - це простіший сервер, який в основному використовується для розробки, демонстрації та його сумісності з різними операційними системами (включаючи Windows). Новий потік створюється для кожного нового запиту HTTP, навіть для довготривалих з’єднань, таких як websocket. Також створюються додаткові демонічні потоки cron. Через обмеження Python (GIL) він не найкращим чином використовує апаратне забезпечення.

Багатопоточний сервер є сервером за замовчуванням, також для контейнерів докерів. Його вибирають, залишивши --workers виключити або встановити для нього значення 0.

Багатопроцесорний сервер - це повноцінний сервер, який використовується переважно для виробництва. Він не підпадає під обмеження Python (GIL) щодо використання ресурсів і, отже, найкраще використовує апаратне забезпечення. Пул воркерів створюється під час запуску сервера. Нові HTTP-запити ставляться в чергу ОС, доки не буде працівників, готових їх обробити. Додатковий HTTP-обробник, керований подіями, для живого чату створюється на альтернативному порту. Також створюються додаткові воркери cron. Настроюваний процес Reaper відстежує використання ресурсів і може вбивати/перезапускати невдалих робочих.

Багатопроцесорний сервер доступний. Його вибирають установкою -workers для ненульового цілого числа.

Примітка

Оскільки він дуже налаштований для серверів Linux, багатопроцесорний сервер недоступний у Windows.

Розрахунок кількості воркерів¶

Емпіричне правило: (#CPU * 2) + 1
Воркерам Cron потрібен процесор
1 воркер ~= 6 одночасних користувачів

розрахунок обсягу пам’яті¶

Ми вважаємо, що 20% запитів є важкими, тоді як 80% є простішими
Важкий працівник, коли всі обчислювані поля добре розроблені, SQL-запити добре розроблені, … за оцінками, споживає приблизно 1 ГБ оперативної пам’яті
За таким же сценарієм легший воркер споживає близько 150 МБ оперативної пам’яті

Необхідна оперативна пам’ять = #worker * ((light_worker_ratio * light_worker_ram_estimation) + (heavy_worker_ratio * heavy_worker_ram_estimation) )

Живий чат¶

У режимі багатопроцесорної обробки автоматично запускається спеціальний робочий чат Живий чат, який слухає --gevent-port. За замовчуванням HTTP-запити продовжуватимуть отримувати доступ до звичайних робочих HTTP замість Живий чат. Ви повинні розгорнути проксі-сервер перед Odoo і перенаправляти вхідні запити, шлях яких починається з /websocket/, до робочого Живий чат. Ви також повинні запустити Odoo в --proxy-mode тому він використовує реальні заголовки клієнта (такі як ім’я хоста, схема та IP) замість заголовків проксі.

Зразок конфігурації¶

Сервер з 4 процесорами, 8 потоками
60 одночасних користувачів
60 користувачів / 6 = 10 <- необхідна теоретична кількість воркерів
(4 * 2) + 1 = 9 <- теоретична максимальна кількість воркерів
Ми будемо використовувати 8 воркерів + 1 для cron. Ми також використаємо систему моніторингу для вимірювання навантаження на ЦП і перевіримо, чи воно знаходиться між 7 і 7.5.
RAM = 9 * ((0,8*150) + (0,2*1024)) ~= 3Go RAM для 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¶

Незалежно від того, доступ до нього здійснюється через веб-сайт/веб-клієнт чи веб-сервіс, Odoo передає інформацію автентифікації у відкритому вигляді. Це означає, що безпечне розгортання Odoo має використовувати HTTPS3. Завершення SSL можна реалізувати майже через будь-який проксі-сервер завершення SSL, але вимагає таких налаштувань:

Увімкніть режим проксі Odoo <odoo-bin --proxy-mode>. Це слід увімкнути, лише якщо Odoo знаходиться за зворотним проксі
Налаштувати проксі-сервер завершення SSL (Приклад завершення Nginx)
Налаштувати саме проксі (Приклад проксі Nginx)
Ваш проксі-сервер завершення SSL також має автоматично перенаправляти незахищені з’єднання на безпечний порт

Зразок конфігурації¶

Перенаправлення запитів http на https
Запити проксі до odoo

у файлі конфігурації встановити:

proxy_mode = True

у /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;
}

HTTPS Hardening¶

Додайте заголовок Strict-Transport-Security до всіх запитів, щоб браузери ніколи не надсилали звичайний HTTP-запит до цього домену. Вам потрібно буде постійно підтримувати робочу службу HTTPS із дійсним сертифікатом у цьому домені, інакше ваші користувачі бачитимуть сповіщення безпеки або взагалі не зможуть отримати до неї доступ.

Примусово з’єднуйте HTTPS протягом року для кожного відвідувача в NGINX за допомогою рядка:

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

Для файлу cookie session_id можна визначити додаткову конфігурацію. Можна додати позначку Secure, щоб гарантувати, що він ніколи не передається через HTTP, і SameSite=Lax, щоб запобігти автентифікованому CSRF.

# requires nginx 1.19.8
proxy_cookie_flags session_id samesite=lax secure;

Odoo як програма WSGI¶

Також можна підключити Odoo як стандартний додаток WSGI. Odoo надає основу для сценарію запуску WSGI як odoo-wsgi.example.py. Цей сценарій слід налаштувати (можливо, після копіювання його з каталогу встановлення), щоб правильно встановити конфігурацію безпосередньо в odoo.tools.config, а не через командний рядок або файл конфігурації.

Однак сервер WSGI відкриє лише основну кінцеву точку HTTP для веб-клієнта, веб-сайту та API веб-служби. Оскільки Odoo більше не контролює створення воркерів, він не може налаштувати воркери cron або livechat

Вокери Cron¶

Для обробки завдань cron потрібно запустити один із вбудованих серверів Odoo поруч із сервером WSGI. Цей сервер має бути налаштований лише на обробку crons, а не HTTP-запитів за допомогою --no-http параметр cli або параметр файлу конфігурації http_enable = False.

У системах, подібних до Linux, рекомендується використовувати багатопроцесорний сервер замість багатопотокового, щоб отримати вигоду від кращого використання апаратного забезпечення та підвищення стабільності, тобто використання --workers=-1 і --max-cron-threads=n опції cli.

Живий чат¶

Для правильної роботи функції живого чату потрібне використання gevent-сумісного сервера WSGI. Цей сервер має бути в змозі обробляти багато одночасних довготривалих з’єднань, але не потребує великої обчислювальної потужності. Усі запити, шлях яких починається з /websocket/, повинні бути спрямовані на цей сервер. Для всіх інших запитів слід використовувати звичайний (на основі потоків/процесів) сервер WSGI.

Сервер Odoo cron також можна використовувати для обслуговування запитів у чаті. Просто відпустіть --no-http cli із сервера cron і переконайтеся, що запити, шлях яких починається з /websocket/, спрямовуються на цей сервер або на --http-port (багатопоточний сервер) або на --gevent-port (багатопроцесорний сервер).

Обслуговування статичних файлів і вкладень¶

Для зручності розробки Odoo безпосередньо обслуговує всі статичні файли та вкладення у своїх модулях. Це може бути не ідеальним, коли йдеться про продуктивність, і статичні файли, як правило, повинні обслуговуватися статичним HTTP-сервером.

Обслуговування статичних файлів¶

Статичні файли Odoo знаходяться в папці static/ кожного модуля, тому статичні файли можна обслуговувати, перехоплюючи всі запити до /MODULE/static/FILE і шукаючи потрібний модуль (і файл) у різних шляхах додатків.

Рекомендується встановити заголовок Content-Security-Policy: default-src 'none' для всіх зображень, які доставляє веб-сервер. Це не є суворо необхідним, оскільки користувачі не можуть змінювати/вставляти вміст у папку static/ модулів, а наявні зображення є остаточними (вони не отримують нові ресурси самостійно). Однак це хороша практика.

Використовуючи наведену вище конфігурацію NGINX (https), слід додати такі блоки map і location для обслуговування статичних файлів через 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;
    }
}

Фактичні директиви root і try_files залежать від вашого встановлення, зокрема від вашого --addons-path.

Example

Скажімо, Odoo встановлено за допомогою пакетів debian для спільноти та підприємства, і що --addons-path є '/usr/lib/python3/dist-packages/odoo/addons`.

root і try_files мають бути:

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

Скажімо, Odoo було встановлено через джерела, що git-репозиторії спільноти та підприємства були клоновані у /opt/odoo/community та /opt/odoo/enterprise відповідно, і що --addons-path це '/opt/odoo/community/odoo/addons,/opt/odoo/community/addons,/opt/odoo/enterprise'.

root і try_files мають бути:

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

Обслуговування вкладень¶

Вкладення - це файли, що зберігаються у сховищі файлів, доступ до яких регулює Odoo. До них неможливо отримати прямий доступ через статичний веб-сервер, оскільки доступ до них вимагає кількох пошуків у базі даних, щоб визначити, де зберігаються файли та чи може поточний користувач отримати до них доступ чи ні.

Тим не менш, після того, як Odoo знайде файл і перевірить права доступу, доцільно обслуговувати файл за допомогою статичного веб-сервера замість Odoo. Щоб Odoo делегував обслуговувати файли статичному веб-серверу, X-Sendfile<https://tn123.org/mod_xsendfile/> `_ (apache) або `X-Accel<https://www.nginx.com/resources/wiki/start/topics/examples/x-accel/> Розширення `_ (nginx) мають бути ввімкнені та налаштовані на статичному веб-сервері. Після налаштування запустіть Odoo за допомогою :option:–x-sendfile <odoo-bin –x-sendfile>` Прапор CLI (цей унікальний прапор використовується як для X-Sendfile, так і для X-Accel).

Примітка

Розширення X-Sendfile для apache (і сумісних веб-серверів) не потребує додаткової конфігурації.
Розширення X-Accel для NGINX потрібно такої додаткової конфігурації:
```
location /web/filestore {
    internal;
    alias /path/to/odoo/data-dir/filestore;
}
```
Якщо ви не знаєте шлях до сховища файлів, запустіть Odoo за допомогою --x-sendfile і перейдіть до URL-адреси /web/filestore безпосередньо через Odoo (не переходьте до URL-адреси через NGINX). Це реєструє попередження, повідомлення містить потрібну конфігурацію.

Безпека¶

Для початку пам’ятайте, що захист інформаційної системи - це безперервний процес, а не одноразова операція. У будь-який момент ви будете захищені лише як найслабша ланка у вашому оточенні.

Тому, будь ласка, не сприймайте цей розділ як остаточний список заходів, які допоможуть запобігти всім проблемам безпеки. Він призначений лише як короткий виклад перших важливих речей, які ви повинні обов’язково включити у свій план заходів безпеки. Решта буде отримано з найкращих практик безпеки для вашої операційної системи та дистрибутива, найкращих практик щодо користувачів, паролів, керування доступом тощо.

Під час розгортання сервера з доступом до Інтернету обов’язково враховуйте такі питання, пов’язані з безпекою:

Завжди встановлюйте надійний пароль адміністратора суперадміністратора та обмежуйте доступ до сторінок керування базою даних, щойно систему буде налаштовано. Перегляньте Безпека менеджера баз даних.
Виберіть унікальні логіни та надійні паролі для всіх облікових записів адміністраторів у всіх базах даних. Не використовуйте „admin“ як логін. Не використовуйте ці логіни для повсякденних операцій, лише для контролю/керування встановленням. Ніколи не використовуйте паролі за замовчуванням, як-от admin/admin, навіть для тестових/проміжних баз даних.
Не встановлюйте демонстраційні дані на серверах з доступом до Інтернету. Бази даних із демонстраційними даними містять логіни та паролі за замовчуванням, які можна використовувати для входу у ваші системи та спричинити серйозні проблеми навіть у системах для підготовки/розроблення.
Використовуйте відповідні фільтри бази даних ( --db-filter), щоб обмежити видимість ваших баз даних відповідно до імені хоста. Перегляньте dbfilter. Ви також можете використовувати -d, щоб надати власний (розділений комами) список доступних баз даних для фільтрації, замість того, щоб дозволяти системі отримувати їх усі з серверної частини бази даних.
Після того як ваші db_name і dbfilter налаштовані та відповідають лише одній базі даних на ім’я хоста, ви повинні встановити параметр конфігурації list_db на False, щоб повністю запобігти переліку баз даних і заблокувати доступ до екранів керування базами даних (це також відображається як --no-database-list параметр командного рядка)
Переконайтеся, що користувач PostgreSQL (--db_user) не є суперкористувачем, і ваші бази даних належать іншому користувачеві. Наприклад, вони можуть належати суперкористувачу postgres, якщо ви використовуєте виділеного непривілейованого db_user. Дивіться також Налаштування Odoo.
Регулярно встановлюйте найновіші версії через GitHub або завантажуючи останню версію з https://simbiozems.com/page/download чи http://nightly.odoo.com.
Налаштуйте свій сервер у багатопроцесорному режимі з належними обмеженнями, що відповідають типовому використанню (memory/CPU/timeouts). Дивіться також Вбудований сервер.
Запустіть Odoo позаду веб-сервера, який забезпечує завершення HTTPS із дійсним сертифікатом SSL, щоб запобігти прослуховуванню комунікацій відкритого тексту. Сертифікати SSL дешеві, і існує багато безкоштовних варіантів. Налаштуйте веб-проксі, щоб обмежити розмір запитів, установіть відповідні тайм-аути, а потім увімкніть режим проксі варіант. Дивіться також HTTPS.
Якщо вам потрібно дозволити віддалений доступ SSH до ваших серверів, переконайтеся, що встановлено надійний пароль для всіх облікових записів, а не лише для root. Настійно рекомендується повністю вимкнути автентифікацію на основі пароля та дозволити лише автентифікацію за відкритим ключем. Також подумайте про обмеження доступу через VPN, дозволяючи лише довірені IP-адреси в брандмауері та/або запустивши систему виявлення грубою силою, таку як fail2ban або еквівалент.
Подумайте про встановлення відповідного обмеження швидкості на вашому проксі-сервері чи брандмауері, щоб запобігти атакам підбору даних і атакам на відмову в обслуговуванні. Перегляньте також Блокування атак грубою силою для конкретних заходів.

Багато мережевих провайдерів надають автоматичне пом’якшення атак розподіленої відмови в обслуговуванні (DDOS), але це часто необов’язкова послуга, тому вам слід проконсультуватися з ними.
За можливості розміщуйте публічні демонстраційні/тестові/проміжні екземпляри на машинах, відмінних від виробничих. І застосовувати ті ж заходи безпеки, що й на виробничій.
Якщо ваш загальнодоступний сервер Odoo має доступ до конфіденційних внутрішніх мережевих ресурсів або послуг (наприклад, через приватну VLAN), застосуйте відповідні правила брандмауера, щоб захистити ці внутрішні ресурси. Це гарантує, що сервер Odoo не може бути використаний випадково (або в результаті зловмисних дій користувача) для доступу або порушення роботи цих внутрішніх ресурсів. Як правило, це можна зробити, застосувавши вихідне правило DENY за замовчуванням на брандмауері, а потім лише явно дозволити доступ до внутрішніх ресурсів, до яких сервер Odoo має отримати доступ. Контроль доступу до IP-трафіку Systemd також може бути корисним для реалізації контролю доступу до мережі для кожного процесу.
Якщо ваш відкритий сервер Odoo знаходиться за брандмауером веб-додатків, балансувальником навантаження, прозорою службою захисту від DDoS (наприклад, CloudFlare) або подібним пристроєм мережевого рівня, ви можете уникнути прямого доступу до системи Odoo. Як правило, важко зберегти IP-адреси кінцевих точок ваших серверів Odoo в секреті. Наприклад, вони можуть відображатися в журналах веб-сервера під час запитів до публічних систем або в заголовках електронних листів, опублікованих з Odoo. У такій ситуації ви можете налаштувати свій брандмауер так, щоб кінцеві точки були недоступні публічно, за винятком конкретних IP-адрес вашого WAF, балансувальника навантаження або служби проксі. Для цієї мети постачальники послуг, як-от CloudFlare, зазвичай підтримують загальнодоступний список діапазонів своїх IP-адрес.
Якщо ви розміщуєте кількох клієнтів, ізолюйте дані та файли клієнтів один від одного за допомогою контейнерів або відповідних методів «jail».
Налаштуйте щоденне резервне копіювання ваших баз даних і даних файлового сховища та скопіюйте їх на віддалений сервер архівування, який недоступний із самого сервера.
Розгортання Odoo на Linux наполегливо рекомендується замість Windows. Якщо ви все ж вирішите розгортати на платформі Windows, необхідно провести ретельний огляд посилення безпеки сервера, що виходить за рамки цього посібника.

Блокування атак грубою силою¶

У розгортаннях з Інтернетом атаки грубою силою на паролі користувачів є дуже поширеними, і не слід нехтувати цією загрозою для серверів Odoo. Odoo створює запис у журналі щоразу, коли виконується спроба входу, і повідомляє про результат: успішний чи невдалий, разом із цільовим логіном та вихідною IP-адресою.

Записи журналу матимуть такий вигляд.

Помилка входу:

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

Успішний вхід:

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

Ці журнали можуть бути легко проаналізовані системою запобігання вторгненням, наприклад fail2ban.

Наприклад, наступне визначення фільтра fail2ban має відповідати невдалому входу:

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

Це можна використовувати з визначенням в’язниці для блокування атакуючої IP-адреси на HTTP(S).

Ось як може виглядати блокування IP-адреси на 15 хвилин, якщо протягом 1 хвилини виявлено 10 невдалих спроб входу з однієї IP-адреси:

[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

Безпека менеджера баз даних¶

Налаштування Odoo згадав admin_passwd.

Цей параметр використовується на всіх екранах керування базами даних (для створення, видалення, створення дампу чи відновлення баз даних).

Якщо екрани керування взагалі не повинні бути доступними, вам слід встановити для параметра конфігурації list_db значення False, щоб заблокувати доступ до всіх екранів вибору та керування базами даних.

Попередження

Наполегливо рекомендуємо вимкнути диспетчер баз даних для будь-якої системи, що має доступ до Інтернету! Він призначений як інструмент розробки/демонстрації, щоб полегшити швидке створення та керування базами даних. Він не призначений для використання у виробництві та може навіть надавати небезпечні функції для зловмисників. Він також не призначений для обробки великих баз даних і може викликати обмеження пам’яті.

У виробничих системах операції з керування базами даних завжди повинні виконуватися системним адміністратором, включаючи створення нових баз даних і автоматичне резервне копіювання.

Обов’язково встановіть відповідний параметр db_name (і додатково dbfilter), щоб система могла визначити цільову базу даних для кожного запиту, інакше користувачі будуть заблоковані, оскільки їм не буде дозволено вибирати самі бази даних.

Якщо екрани керування мають бути доступні лише з вибраного набору машин, використовуйте функції проксі-сервера, щоб заблокувати доступ до всіх маршрутів, які починаються з /web/database, крім (можливо) /web/database/selector який відображає екран вибору бази даних.

Якщо екран керування базою даних потрібно залишити доступним, параметр admin_passwd має бути змінений із значення admin за замовчуванням: цей пароль перевіряється перед тим, як дозволити операції зміни бази даних.

Його слід надійно зберігати та генерувати випадковим чином, напр.

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

який генерує 32-символьний псевдовипадковий рядок для друку.

Скинути головний пароль¶

Можуть бути випадки, коли головний пароль загубився або був зламаний, і його потрібно скинути. Нижченаведений процес призначений для системних адміністраторів локальної бази даних Odoo і детально описує, як вручну скинути та повторно зашифрувати головний пароль.

Дивись також

Щоб дізнатися більше про зміну пароля облікового запису Odoo.com, перегляньте цю документацію: Зміна пароля облікового запису Odoo.com.

Під час створення нової локальної бази даних генерується випадковий головний пароль. Odoo рекомендує використовувати цей пароль для захисту бази даних. Цей пароль реалізовано за замовчуванням, тому для будь-якого локального розгортання Odoo існує безпечний головний пароль.

Попередження

Під час створення локальної бази даних Odoo встановлення доступне для будь-кого в Інтернеті, доки цей пароль не буде встановлено для захисту бази даних.

Головний пароль вказано у файлі конфігурації Odoo (odoo.conf або odoorc (прихований файл)). Головний пароль Odoo потрібен для зміни, створення або видалення бази даних через графічний інтерфейс користувача (GUI).

Знайдіть файл конфігурації¶

Спочатку відкрийте файл конфігурації Odoo (odoo.conf або odoorc (прихований файл)).

Конфігураційний файл знаходиться за адресою: c:\ProgramFiles\Odoo{VERSION}\server\odoo.conf

Залежно від того, як Odoo встановлено на машині Linux, файл конфігурації розташовується в одному з двох різних місць:

Встановлення з пакета: /etc/odoo.conf
Встановлення з вихідного коду: ~/.odoorc

Змінити старий пароль¶

Після відкриття відповідного файлу перейдіть до зміни старого пароля у файлі конфігурації на тимчасовий пароль.

Знайшовши файл конфігурації, відкрийте його за допомогою (GUI). Це можна зробити, просто двічі клацнувши на файлі. Тоді пристрій має мати типовий GUI, за допомогою якого можна відкрити файл.

Потім змініть рядок головного пароля admin_passwd = $pbkdf2-sha… на admin_passwd = newpassword1234, наприклад. Цей пароль може бути будь-яким, якщо він збережений тимчасово. Обов’язково змініть усі символи після =.

Example

Рядок виглядає так: admin_passwd = $pbkdf2-sh39dji295.59mptrfW.9z6HkA$w9j9AMVmKAP17OosCqDxDv2hjsvzlLpF8Rra8I7p/b573hji540mk/.3ek0lg%kvkol6k983mkf/40fjki79m

Змінений рядок виглядає так: admin_passwd = newpassword1234

Змініть рядок головного пароля за допомогою наведеної нижче команди Unix.

Підключіться до терміналу сервера Odoo через протокол Secure Shell (SSH) і відредагуйте файл конфігурації. Щоб змінити файл конфігурації, введіть таку команду: sudo nano /etc/odoo.conf

Відкривши файл конфігурації, змініть рядок головного пароля admin_passwd = $pbkdf2-sha… на admin_passwd = newpassword1234. Цей пароль може бути будь-яким, якщо він збережений тимчасово. Обов’язково змініть усі символи після =.

Example

Рядок виглядає так: admin_passwd = $pbkdf2-sh39dji295.59mptrfW.9z6HkA$w9j9AMVmKAP17OosCqDxDv2hjsvzlLpF8Rra8I7p/b573hji540mk/.3ek0lg%kvkol6k983mkf/40fjki79m

Змінений рядок виглядає так: admin_passwd = newpassword1234

Важливо

Важливо, щоб пароль було змінено на щось інше, а не викликало скидання нового пароля шляхом додавання крапки з комою ; на початку рядка. Це гарантує безпеку бази даних протягом усього процесу скидання пароля.

Перезапустіть сервер Odoo¶

Після встановлення тимчасового пароля необхідно перезапустити сервер Odoo.

Щоб перезапустити сервер Odoo, спочатку введіть services у Пошук панелі Windows. Потім виберіть програму Сервіс і перейдіть до служби Odoo.

Потім клацніть правою кнопкою миші на Odoo і виберіть Запустити або Перезапустити. Ця дія вручну перезапускає сервер Odoo.

Перезапустіть сервер Odoo, ввівши команду: sudo service odoo15 restart

Примітка

Змініть номер після odoo, щоб відповідати конкретній версії, на якій працює сервер.

Використовуйте веб-інтерфейс для повторного шифрування пароля¶

Спочатку перейдіть до /web/database/manager або http://server_ip:port/web/database/manager у браузері.

Примітка

Замініть server_ip на IP-адресу бази даних. Замініть port пронумерованим портом, з якого доступна база даних.

Потім натисніть Встановити головний пароль і введіть попередньо вибраний тимчасовий пароль у поле Головний пароль. Після цього кроку введіть Новий головний пароль. Новий головний пароль хешується (або шифрується) після натискання кнопки Продовжити.

На цьому етапі пароль успішно скинуто, і хешована версія нового пароля тепер відображається у файлі конфігурації.

Дивись також

Для отримання додаткової інформації про безпеку бази даних Odoo перегляньте цю документацію: Безпека менеджера баз даних.

Підтримувані браузери¶

Odoo підтримує всі основні настільні та мобільні браузери, доступні на ринку, за умови, що вони підтримуються їхніми видавцями.

Ось підтримувані браузери:

Google Chrome
Mozilla Firefox
Microsoft Edge
Apple Safari

Попередження

Будь ласка, переконайтеся, що ваш веб-переглядач оновлено та підтримується його видавцем, перш ніж надсилати звіт про помилку.

Примітка

Починаючи з Odoo 13.0, підтримується ES6. Тому підтримку IE припинено.

1: щоб кілька інсталяцій Odoo використовували ту саму базу даних PostgreSQL або щоб надати більше обчислювальних ресурсів для обох програм.
2: технічно такий інструмент, як socat, можна використовувати для проксі сокетів UNIX у мережах, але це здебільшого для програмного забезпечення, яке можна використовувати лише через сокети UNIX
3: або бути доступним лише через внутрішню мережу з комутацією пакетів, але це вимагає захищених комутаторів, захисту від ARP-spoofing та виключає використання WiFi. Навіть у захищених мережах з комутацією пакетів рекомендується розгортання через HTTPS, і можливі витрати знижуються, оскільки «самопідписані» сертифікати легше розгортати в контрольованому середовищі, ніж через Інтернет.

Edit on GitHub