How to secure Odoo on a VPS before going live

Command or manual check

sudo apt update
apt list --upgradable
[ -f /var/run/reboot-required ] && echo "Reboot required" || echo "No reboot flag found"

How to interpret the result

If packages are listed, updates are pending. Do not automatically upgrade a production Odoo server without planning the impact.

Pay special attention if the list includes:
- odoo
- postgresql
- nginx
- linux-image / linux-headers / kernel packages
- docker packages

These updates may restart services, change runtime behavior, or require a reboot.

If "Reboot required" appears, do not reboot a production Odoo server immediately. First:
- notify users if the server is used in production
- confirm you have working SSH or VPS console access
- confirm backups or snapshots exist
- schedule the restart during low-activity hours

For a demo or unused server, applying updates immediately may be acceptable, but it should still be a conscious decision.

Command or manual check

sudo ss -tulpn

How to interpret the result

Common public ports:
- 22 for SSH
- 80 for HTTP
- 443 for HTTPS

Odoo commonly uses:
- 8069 for the main Odoo HTTP service
- 8072 for websocket / longpolling traffic

Seeing port 8069 is not automatically a problem. What matters is the bind address.

Safer examples:
- 127.0.0.1:8069
- 127.0.0.1:8072

These mean Odoo is reachable locally by Nginx, but not directly exposed to the internet.

Risky examples:
- 0.0.0.0:8069
- 0.0.0.0:8072
- [::]:8069
- [::]:8072

These may mean Odoo is listening on public network interfaces.

Also investigate carefully if you see:
- 5432 exposed publicly for PostgreSQL
- 0.0.0.0:5432
- [::]:5432

If Odoo appears publicly exposed:
1. Do not ignore it just because the site works.
2. Confirm whether the firewall blocks direct access.
3. Check Docker port bindings with docker ps.
4. Prefer binding Odoo to 127.0.0.1 and exposing it only through Nginx.
5. Do not allow 8069, 8072, or 5432 publicly in the firewall.
6. Test from outside the server using http://your-server-ip:8069 after changes.

Command or manual check

docker ps --format "table {{.Names}}\t{{.Ports}}"

How to interpret the result

Prefer local-only bindings when Nginx runs on the host:
127.0.0.1:8069->8069/tcp
127.0.0.1:8072->8072/tcp

Avoid public bindings for Odoo:
0.0.0.0:8069->8069/tcp
0.0.0.0:8072->8072/tcp

Never expose PostgreSQL publicly:
0.0.0.0:5432->5432/tcp

If you see a public Odoo binding in Docker, update docker-compose.yml to bind Odoo to 127.0.0.1, then recreate the container.

Safer Docker Compose example:
ports:
  - "127.0.0.1:8069:8069"
  - "127.0.0.1:8072:8072"

Avoid:
ports:
  - "8069:8069"
  - "8072:8072"

The short form may publish the ports publicly depending on Docker defaults and host firewall behavior.

Command or manual check

sudo ufw status verbose

How to interpret the result

Expected allowed ports:
- SSH
- 80/tcp
- 443/tcp

Odoo 8069/8072 and PostgreSQL 5432 should not be allowed publicly.

Important: if Docker is used, do not trust UFW alone. Docker can create iptables rules that publish ports even when UFW looks restrictive.

Command or manual check

# Example only — do not run blindly on production.
# Keep a second SSH session open before changing firewall rules.

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw status verbose

How to interpret the result

Before enabling or changing UFW:
- keep a second SSH session open
- confirm OpenSSH is allowed
- confirm your VPS provider has an emergency console
- do not allow Odoo 8069/8072 publicly
- do not allow PostgreSQL 5432 publicly

Only enable or reload firewall rules when you understand the impact.

Command or manual check

sudo find / -name "odoo.conf" 2>/dev/null

How to interpret the result

You should locate the active Odoo config file.

Common locations:
- /etc/odoo/odoo.conf
- /etc/odoo.conf
- inside a Docker volume or mounted config folder

Do not edit it yet. First identify which config file the running Odoo service actually uses.

Command or manual check

# Replace the path with your real odoo.conf path.
# Do not share the full output publicly if it contains secrets.

sudo grep -E "^(admin_passwd|proxy_mode|list_db|dbfilter|log_level|workers|max_cron_threads|limit_time_cpu|limit_time_real)" /path/to/odoo.conf

How to interpret the result

Important settings to review:
admin_passwd = should be strong and not default
proxy_mode = True when Odoo is behind a trusted reverse proxy
list_db = False for production-style single-database setups
dbfilter = should restrict which database is exposed
log_level = info or warn, not debug in production
workers = configured for production if needed
max_cron_threads = controlled
limit_time_cpu / limit_time_real = prevents long-running requests from hanging workers

Do not expose admin_passwd publicly.

Command or manual check

# Local check when Odoo is bound to 127.0.0.1
curl -I http://127.0.0.1:8069/web/database/manager
curl -I http://127.0.0.1:8069/web/database/selector
curl -I http://127.0.0.1:8069/web/database/create

# Public check after Nginx/domain setup
curl -I https://your-odoo-domain.com/web/database/manager
curl -I https://your-odoo-domain.com/web/database/selector
curl -I https://your-odoo-domain.com/web/database/create

How to interpret the result

It is normal for Odoo database manager routes to exist locally.

Example local result:
- http://127.0.0.1:8069/web/database/manager may return 200 OK
- http://127.0.0.1:8069/web/database/selector may return 200 OK
- create/drop/backup routes may require POST or authentication

This is not automatically dangerous if Odoo is bound only to 127.0.0.1 and reachable only by the server or Nginx.

The real risk is public exposure.

Risky situations:
- Odoo is published on 0.0.0.0:8069
- Odoo is reachable from http://your-server-ip:8069
- Nginx proxies /web/database routes publicly without restriction
- PostgreSQL is also exposed publicly

Recommended protection layers:
- strong admin_passwd in odoo.conf
- list_db = False
- dbfilter configured to the intended database
- Nginx restriction for /web/database routes before exposing Odoo through HTTPS
- optional IP allowlist or basic auth for administrators
- no public PostgreSQL access

Sensitive routes to review:
- /web/database/manager
- /web/database/selector
- /web/database/create
- /web/database/drop
- /web/database/backup
- /web/database/restore

For many production deployments, blocking /web/database at the Nginx level is a sensible extra protection layer.

Target public result after Nginx hardening:
- /web/database/manager should return 403, 404, or be restricted
- /web/database/selector should return 403, 404, or be restricted
- /web/database/create should return 403, 404, or be restricted

Command or manual check

sudo ss -tulpn | grep 5432 || echo "No local PostgreSQL listener found in ss output"
docker ps --format "table {{.Names}}\t{{.Ports}}" | grep 5432 || echo "No Docker PostgreSQL public binding found in docker ps output"

How to interpret the result

Safer examples:
127.0.0.1:5432
Docker internal network only
No public binding shown

Risky example:
0.0.0.0:5432->5432/tcp

If PostgreSQL is public, treat it as urgent and plan a safe fix.

Command or manual check

who
last -a | head -30

How to interpret the result

You should recognize the active users and recent login history.

Unexpected users, unknown sessions, or unusual login origins should be investigated before continuing.

Command or manual check

# Full list of usernames
cut -d: -f1 /etc/passwd

# Better focused check: human-like users
awk -F: '$3 >= 1000 && $3 < 65534 {print $1, "uid="$3, "home="$6, "shell="$7}' /etc/passwd

# Users with interactive shells
grep -E "/bin/bash|/bin/sh" /etc/passwd

How to interpret the result

It is normal to see many system users such as:
- root
- daemon
- bin
- www-data
- sshd
- systemd-resolve
- _apt
- nobody
- postgres

Do not delete these users blindly. Many are required by Linux services, Nginx, PostgreSQL, SSH, package management, or systemd.

Usually normal on an Odoo/STYD server:
- your admin user, for example ubuntu, deploy, admin
- root, even if direct root SSH login is disabled
- postgres if PostgreSQL is installed on the host
- www-data if Nginx or web services are installed

Investigate carefully if you see:
- human-looking users you did not create
- old developer/admin accounts you no longer use
- users with /bin/bash that you do not recognize
- users with home folders under /home that you do not recognize
- recently created users after suspicious activity
- users with sudo access that you do not recognize

Useful follow-up checks:
- groups username
- sudo -l -U username
- ls -la /home
- last -a | head -30

If a user looks suspicious, first identify what owns it and whether a service depends on it. Do not delete accounts blindly on a production server.

Command or manual check

echo "=== Failed SSH attempts in last 24 hours ==="
(
  sudo journalctl -u ssh --since "24 hours ago" 2>/dev/null
  sudo journalctl -u sshd --since "24 hours ago" 2>/dev/null
  sudo cat /var/log/auth.log 2>/dev/null
) | grep -Ei "failed|invalid" || echo "No failed SSH attempts found in common SSH log locations"

echo "=== Successful SSH login summary ==="
(
  sudo journalctl -u ssh --since "24 hours ago" 2>/dev/null
  sudo journalctl -u sshd --since "24 hours ago" 2>/dev/null
  sudo cat /var/log/auth.log 2>/dev/null
) | grep -Ei "Accepted " \
  | sed -E 's/.*Accepted ([^ ]+) for ([^ ]+) from ([^ ]+).*/method=\1 user=\2 ip=\3/' \
  | sort \
  | uniq -c

echo "=== Recent login table ==="
last -a | head -30

echo "=== SSH hardening status ==="
sudo sshd -T | grep -Ei "permitrootlogin|passwordauthentication|pubkeyauthentication|kbdinteractiveauthentication|maxauthtries"

echo "=== Fail2ban SSH status ==="
sudo fail2ban-client status sshd 2>/dev/null || echo "Fail2ban sshd jail not found"

How to interpret the result

On some systems, SSH logs may be under the ssh service, the sshd service, or /var/log/auth.log. This checklist checks common SSH log locations, but if all outputs are empty, do not treat that alone as proof that there were no SSH attempts.

A few failed attempts can be normal. Many public VPS servers are scanned constantly.

Common bot usernames:
- root
- admin
- ubuntu
- test
- oracle
- postgres
- odoo
- odoo12
- deploy
- vagrant
- pi

Signs of brute-force scanning:
- many "Invalid user ..." lines
- repeated "Failed password for root"
- many different IP addresses
- many generic usernames you never created
- repeated attempts within minutes

How to check whether a brute-force attempt succeeded:
Look for successful login lines, especially:
- Accepted password for root from unknown-ip
- Accepted password for admin from unknown-ip
- Accepted password for any user from unknown-ip
- Accepted publickey for unknown-user from unknown-ip
- any successful login at a time you do not recognize

Good successful login example:
- method=publickey user=your-admin-user ip=your-known-ip

Risky successful login examples:
- method=password user=root ip=unknown-ip
- method=password user=admin ip=unknown-ip
- method=publickey user=unknown-user ip=unknown-ip

Good protection signs:
- permitrootlogin no
- passwordauthentication no
- pubkeyauthentication yes
- kbdinteractiveauthentication no
- Fail2ban sshd jail is active
- Fail2ban shows banned IPs

Recommended hardening:
- use SSH keys only
- disable root SSH login
- disable password authentication
- install or verify Fail2ban
- reduce MaxAuthTries, for example MaxAuthTries 3
- consider SSH IP allowlisting only if your IP is stable
- consider VPN-only SSH for stronger production environments

If a successful login from an unknown IP or unknown user is found, treat the server as possibly compromised.

Immediate response if suspicious successful login is found:
1. Do not ignore it.
2. Take a snapshot for investigation if possible.
3. Disable or lock the suspicious user.
4. Rotate SSH keys and passwords.
5. Check sudo users, cron jobs, systemd services, running processes, and recently modified files.
6. Check application secrets such as Odoo, PostgreSQL, API keys, .env files, and backup credentials.
7. Consider rebuilding the VPS from a clean snapshot if compromise is likely.

Do not simply change the password and continue if an attacker may have logged in. Once a server is compromised, credentials, backdoors, cron jobs, SSH keys, or malware may already have been added.

Fail2ban helps against repeated brute-force attempts, but it is not full DDoS protection. Large network floods must be handled by the hosting provider, upstream firewalling, or network-level protection.

Command or manual check

crontab -l
sudo ls -la /etc/cron.d
sudo ls -la /etc/cron.daily
sudo ls -la /etc/cron.hourly

How to interpret the result

You should recognize the scheduled jobs.

Unknown scripts should be reviewed before exposing the server. Do not delete cron jobs blindly; first understand what they do.

Command or manual check

df -h
free -h

How to interpret the result

Disk should have enough free space for:
- Odoo database growth
- filestore
- logs
- backups
- Docker images and volumes

Memory should not be constantly exhausted.
Swap is recommended on small VPS instances.