Multi-vector attack

kimi.md

Summary: Your server is under an active multi-vector attack I SSH'd into 167.71.192.107 and examined the Docker containers, Odoo logs, PostgreSQL logs, system logs, a nd kernel messages. Here is what is happening and why your services are down. ──────────────────────────────────────────────────────────────────────────────────────────────────────────

1. Current Service Status Container Status Issue ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ odoo Up (3 days) Running but returning HTTP 500 to everyone because it cannot reach the database odoo-db (PostgreSQL) Exited (139) 11 hours ago Crashed with a segmentation fault (SIGSEGV) and has n ot restarted Odoo is "down" only because PostgreSQL is down. All Odoo requests currently fail with: OperationalError: could not translate host name "db" to address: Name or service not known ──────────────────────────────────────────────────────────────────────────────────────────────────────────
2. Root Cause: Why PostgreSQL Crashed PostgreSQL did not crash from "too many HTTP requests." It crashed because attackers directly connected to port 5432 and bombarded it with exploit code until it segfaulted. Evidence from the kernel logs (dmesg): postgres[144346]: segfault at ca4 ip ... in ld-2.24.so postgres[1610]: segfault at 4406 ip ... postgres[134104]: segfault at 6500 ip ... These segfaults correspond exactly with the final PostgreSQL log entries. The container exited with code 1 39 (128 + 11 = SIGSEGV). ──────────────────────────────────────────────────────────────────────────────────────────────────────────
3. The Attacks (Three Vectors) A. Direct PostgreSQL Exploitation (The Kill-Shot) Your docker-compose.yml exposes the database to the entire internet: db: ports:
   • "5432:5432" # <-- This is the problem PostgreSQL logs show attackers injecting advanced Remote Code Execution (RCE) payloads, including: • COPY ... FROM PROGRAM with base64-encoded shell scripts • Creating C-language functions linked to libc.so.6 to escape to the OS shell • Privilege escalation via event triggers and postgres_fdw • Brute-force login attempts against users postgres, user1, odoo The decoded payload is a cryptominer/botnet installer that:
4. Kills competing malware processes (watchdog, kinsing, kdevtmpfsi, metabase, etc.)
5. Downloads a binary from http://181.214.147.108/bot
6. Executes it PostgreSQL was repeatedly crashing the malicious child processes (signal 9: Killed), but the sheer volume of corrupt SQL/function-loading attempts eventually caused the database server process itself to segfault and die. B. SSH Brute Force (Massive Volume) Your auth.log shows 33,421+ failed password attempts. Top offending IPs include: • 45.156.87.204 (1,036 attempts) • 192.109.200.78 (1,036 attempts) • 192.109.200.237 (1,036 attempts) • 167.71.197.124, 167.71.197.122 (753 each) • ...and dozens more. They are trying usernames like root, postgres, admin, user, ubuntu, test2, nobody. C. Web Scanning / Odoo Requests Odoo logs show repeated requests from IPs such as: • 101.109.204.183 (legitimate user activity — mom and jah successfully logged in) • 49.230.53.250 • 172.234.217.129 • 104.28.163.98 (this IP also appears in the SSH brute-force logs) ──────────────────────────────────────────────────────────────────────────────────────────────────────────
7. Why There Are "Enormous Requests" Your server has no firewall rules and no brute-force protection: • ufw status = inactive • fail2ban = not installed/running • iptables INPUT policy = ACCEPT everything Because of this, every bot on the internet can reach: • Port 22 (SSH) → Mass brute force • Port 5432 (PostgreSQL) → Direct exploitation and SQL injection • Port 8069 (Odoo) → Scanning and web-layer attacks ──────────────────────────────────────────────────────────────────────────────────────────────────────────
8. How to Prevent This Immediate (Do This Now)
9. Stop exposing PostgreSQL to the internet Edit /root/odoo-7-docker/docker-compose.yml and remove: ports: - "5432:5432" The Odoo container talks to the DB over the internal Docker network; the port never needs to be public.
10. Restart the database container cd /root/odoo-7-docker docker-compose up -d db
11. Block the worst attacking IPs immediately iptables -A INPUT -s 45.156.87.204 -j DROP iptables -A INPUT -s 192.109.200.78 -j DROP iptables -A INPUT -s 192.109.200.237 -j DROP iptables -A INPUT -s 104.28.163.98 -j DROP

    ... etc

12. Enable UFW and allow only necessary ports ufw default deny incoming ufw allow 22/tcp # Or restrict to your office IP ufw allow 8069/tcp # Ideally restrict this too ufw enable Short-Term (This Week)
13. Install and configure Fail2Ban for SSH (and Odoo if possible) to auto-ban IPs after 3-5 failed attempts
14. Harden SSH • Disable password authentication (PasswordAuthentication no) • Use key-based auth only • Consider changing the port or restricting via AllowUsers / AllowIPs
15. Put a reverse proxy (Nginx/Traefik) in front of Odoo • Add rate-limiting (e.g., limit_req_zone in Nginx) • Block common exploit paths (/web/database/manager, /xmlrpc, etc.) or restrict them by IP
16. Scan for compromise Because attackers had direct PostgreSQL access, check for: • New/unknown database users or tables • Unexpected cron jobs on the host (crontab -l, /etc/cron.*) • Suspicious files in /tmp or /var/tmp • Unknown Docker containers or images Long-Term (Critical)
17. Upgrade PostgreSQL and Odoo You are running postgres:9.6 and odoo:7. Both are end-of-life and full of k n vulnerabilities. The attack payloads I saw in your logs target exactly these old versions.
18. Move DB access to a private Docker network Even internally, avoid publishing the DB port. Use Docker C se's default network or create an explicit internal network so only the odoo service can reach db. ────────────────────────────────────────────────────────────────────────────────────────────────────────── Bottom Line Your PostgreSQL container crashed because bots directly exploited port 5432, causing memory corruption/seg faults. Odoo went down as a side effect because it lost its database connection. The "enormous requests" a re a combination of SSH brute force, PostgreSQL RCE exploitation, and web scanning — all possible because the server is completely open to the internet with no firewall or intrusion prevention.