Running Moltbot (or any always-online bot service) on a VPS is powerful—but it also makes your server a target. The reality is that most attacks aren’t personal. The internet is full of automated scanners that continuously probe VPS IPs for open ports, weak SSH, exposed dashboards, public databases, and misconfigured webhooks. If Moltbot is new (or quickly evolving), it’s even more important to lock things down before you go live.

This guide is a complete, practical playbook to secure your VPS when running Moltbot. It covers the most common ways VPS machines get compromised and shows you exactly how to protect yourself with hardening, firewall rules, safe networking, proper secrets management, monitoring, and incident response.

Security Disclaimer: This article is general security guidance. Security is a process, not a one-time setup. Apply the steps that fit your environment, keep your system updated, and treat your bot token, database credentials, and SSH access like the keys to your home.

---

Table of Contents

1. Threat Model: How Hackers Actually Target VPS Bots
2. The “Golden Rules” for Securing Moltbot
3. VPS Hardening: Secure SSH, Users, and Updates
4. Firewall & Port Exposure: Close Everything You Don’t Need
5. Run Moltbot Safely: Localhost Binding, Reverse Proxies, and Least Privilege
6. Webhooks & Dashboards: HTTPS, Auth, and Rate Limiting
7. Database Security: Local-Only, Permissions, and Backups
8. Secrets: .env Safety, Rotation, and Leak Prevention
9. Monitoring & Alerts: Logs, Audit Trails, and Suspicious Activity
10. Malware & Persistence Checks: What to Look For
11. Incident Response: What to Do If You Think You’re Compromised
12. Security Maintenance Checklist (Weekly/Monthly)

---

Before you secure anything, understand the common attack paths. Most compromises happen through a handful of repeating patterns:

A) Open Ports

Attackers scan public IP ranges for:

• Open SSH (22)
• Open bot ports (3000/5000/8080/etc.)
• Exposed databases (3306 MySQL, 5432 PostgreSQL, 6379 Redis)
• Exposed admin dashboards and panels

B) Weak SSH Security

Common failures:

• Password login enabled (brute-forced)
• Root login allowed
• Reused credentials
• No rate limiting (thousands of guesses per minute)

C) Exposed Webhooks / Admin Endpoints

If your bot exposes /webhook, /admin, /panel, /debug, or a health endpoint returning too much info, scanners will find it and try:

• Credential stuffing
• Default passwords
• Exploit attempts against known framework vulnerabilities

D) Dependency Vulnerabilities

Node/Python projects often pull many dependencies. If you run outdated packages, attackers may exploit:

• Known RCE vulnerabilities
• Prototype pollution (Node)
• Unsafe deserialization (Python)
• Misconfigured debug modes

E) Leaked Secrets

This is extremely common:

• .env pushed to Git
• Tokens pasted into public chats/screenshots
• Server logs containing secrets
• World-readable .env (chmod 644)

---

If you do nothing else, do these:

1. Expose the fewest ports possible (ideally only 22 + 80/443 if using HTTPS).
2. SSH keys only + disable password login + disable root login.
3. Bind Moltbot to localhost (127.0.0.1) if using a reverse proxy.
4. Never expose your database to the public internet.
5. Keep OS + dependencies updated and remove unused services.
6. Use least privilege: run Moltbot as a non-root user with minimal permissions.
7. Monitor logs and use brute-force protections like Fail2ban.

---

3.1 Create a non-root user (if you’re using root now)

adduser molt
usermod -aG sudo molt

Switch to that user:

su - molt

3.2 Update the system

sudo apt update && sudo apt -y upgrade
sudo apt -y install curl git ufw unzip

3.3 Use SSH keys (recommended)

On your local machine:

ssh-keygen -t ed25519
ssh-copy-id molt@YOUR_VPS_IP

Test login:

ssh molt@YOUR_VPS_IP

3.4 Lock down SSH (critical)

Edit SSH configuration:

sudo nano /etc/ssh/sshd_config

Set (or ensure) these values:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
ChallengeResponseAuthentication no
UsePAM yes

Restart SSH:

sudo systemctl restart ssh

Important: Make sure you can still log in with keys before disabling password auth.

---

4.1 Set strict firewall defaults

sudo ufw default deny incoming
sudo ufw default allow outgoing

Allow SSH:

sudo ufw allow OpenSSH

If you use webhooks or a dashboard behind HTTPS, allow web traffic:

sudo ufw allow 80
sudo ufw allow 443

Enable firewall:

sudo ufw enable
sudo ufw status

4.2 Make sure Moltbot’s internal port is NOT public

If your bot runs on port 3000, do not open it:

sudo ufw delete allow 3000 2>/dev/null || true
sudo ufw status

4.3 Check what’s listening publicly

sudo ss -tulpn

You want sensitive services to bind to 127.0.0.1 (localhost), not 0.0.0.0.

---

5.1 Run Moltbot as a non-root user

Never run your bot with sudo node ... or as root.

If you use PM2 (Node):

pm2 start "npm start" --name moltbot
pm2 save
pm2 startup

If you use systemd (Python or Node), run it under your non-root user.

5.2 Bind to localhost only (very important)

Bad (publicly reachable):

Good (local only):

Example: Node (Express) bind to localhost

const host = "127.0.0.1";
const port = process.env.PORT || 3000;

app.listen(port, host, () => {
  console.log(`Listening on http://${host}:${port}`);
});

Example: FastAPI / Uvicorn bind to localhost

uvicorn app:app --host 127.0.0.1 --port 3000

5.3 Use least-privilege file permissions

If you store configs in .env:

chmod 600 .env

Ensure your project directory isn’t world-writable:

chmod -R o-w ~/moltbot

---

If Moltbot uses webhooks, you should terminate TLS with a reverse proxy like Nginx and only forward traffic internally.

6.1 Install Nginx

sudo apt -y install nginx
sudo systemctl enable --now nginx

6.2 Reverse proxy to localhost app port

Example Nginx server block:

server {
    listen 80;
    server_name YOUR_DOMAIN;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

6.3 Add SSL

Use Let’s Encrypt with Certbot:

sudo apt -y install certbot python3-certbot-nginx
sudo certbot --nginx -d YOUR_DOMAIN

6.4 Add Basic Auth to admin routes (recommended)

Install utility:

sudo apt -y install apache2-utils
sudo htpasswd -c /etc/nginx/.htpasswd admin

Nginx config:

location /admin {
    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;
    proxy_pass http://127.0.0.1:3000;
}

Reload Nginx:

sudo nginx -t && sudo systemctl reload nginx

6.5 Add rate limiting for webhooks

This reduces bot abuse and brute attempts.

In Nginx http {} block:

limit_req_zone $binary_remote_addr zone=webhook_limit:10m rate=10r/s;

In your server block:

location /webhook {
    limit_req zone=webhook_limit burst=20 nodelay;
    proxy_pass http://127.0.0.1:3000/webhook;
}

---

7.1 Never expose DB ports publicly

Do not allow:

• 3306 (MySQL)
• 5432 (Postgres)
• 6379 (Redis)

Check firewall rules:

sudo ufw status numbered

7.2 Bind DB to localhost

MySQL

Edit:

sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf

Set:

bind-address = 127.0.0.1

Restart:

sudo systemctl restart mysql

PostgreSQL

Edit:

sudo nano /etc/postgresql/*/main/postgresql.conf

Set:

listen_addresses = 'localhost'

Restart:

sudo systemctl restart postgresql

7.3 Use a dedicated DB user with minimal permissions

Don’t use root DB users in Moltbot.
Create a separate user limited to Moltbot’s database.

7.4 Backups (simple examples)

Postgres:

pg_dump -U moltbot_user -d moltbot > moltbot_backup.sql

MySQL:

mysqldump -u moltbot_user -p moltbot > moltbot_backup.sql

Store backups securely (preferably off-server).

---

8.1 Store secrets in .env (not in code)

Example:

BOT_TOKEN=YOUR_TOKEN
DB_PASSWORD=STRONG_PASSWORD

8.2 Make .env private

chmod 600 .env

8.3 Prevent accidental commits

Create .gitignore:

nano .gitignore

Add:

.env
*.log

8.4 Rotate secrets regularly

If your token or DB password leaks:

• Rotate bot token immediately
• Rotate DB password
• Revoke old keys

---

9.1 Install Fail2ban (blocks brute force)

sudo apt -y install fail2ban
sudo systemctl enable --now fail2ban
sudo fail2ban-client status

9.2 Watch auth logs

sudo tail -n 200 /var/log/auth.log

9.3 Watch your bot logs

PM2:

pm2 logs moltbot

systemd:

journalctl -u moltbot@YOURUSER -f

9.4 Check for unexpected network activity

sudo ss -tulpn

---

If a VPS is compromised, attackers often install:

• Crypto miners
• Backdoor SSH keys
• Cron jobs that re-download malware
• Hidden processes

10.1 Check CPU spikes

top

10.2 Check suspicious cron jobs

System-wide:

sudo ls -la /etc/cron.*
sudo cat /etc/crontab

User crons:

crontab -l
sudo crontab -l

10.3 Check authorized SSH keys

cat ~/.ssh/authorized_keys
sudo cat /root/.ssh/authorized_keys 2>/dev/null

10.4 Check new users

cut -d: -f1 /etc/passwd

10.5 Check recently modified binaries in common dirs

sudo find /usr/bin /usr/local/bin -type f -mtime -7 2>/dev/null | head -n 50

---

If you suspect compromise, don’t “wait and see.”

Immediate steps (fast and effective)

1. Disconnect exposure

• Tighten firewall immediately:

sudo ufw default deny incoming
sudo ufw allow OpenSSH
sudo ufw allow 80
sudo ufw allow 443
sudo ufw enable

2. Rotate secrets

• Bot token
• Database passwords
• Any API keys

3. Check logins

last -a | head -n 50
sudo tail -n 200 /var/log/auth.log

4. Find suspicious processes

ps aux --sort=-%cpu | head
ps aux --sort=-%mem | head

5. If you confirm compromise
   The most reliable remediation is:

• Back up only essential data (DB dumps, config templates—not binaries)
• Rebuild the VPS from a clean image
• Re-deploy Moltbot securely
• Restore data from trusted backups

In real incidents, “cleaning” a compromised server is often less reliable than rebuilding.

---

Daily / Weekly

• Check bot logs for unusual errors or spikes
• Check auth logs for brute-force attempts
• Confirm only expected ports are open: sudo ss -tulpn sudo ufw status

Monthly

• Update OS: sudo apt update && sudo apt -y upgrade
• Update dependencies:
  • Node: npm audit + update packages
  • Python: update pinned versions where possible
• Rotate secrets if your risk is high (public bot, high traffic)

Every change

• If you changed ports, Nginx, or webhook routes: re-check firewall rules
• If you added an admin route: add auth + rate limiting
• If you enabled remote DB access: reconsider (and lock it down by IP)

---

Extra Hardening (Optional but Strong)

If you want to go beyond basics:

• Use SSH allowlisting (only your home/office IP can SSH)
• Use 2FA via a bastion (advanced setups)
• Put Moltbot behind Cloud WAF/CDN (for public endpoints)
• Run Moltbot in a container with limited permissions
• Use AppArmor/SELinux profiles (advanced)

---

Summary (What “Secure Moltbot on a VPS” Really Means)

A secure Moltbot deployment usually looks like this:

• Only ports 22 + 80/443 open
• Bot app listens on 127.0.0.1 only
• Nginx reverse proxy handles HTTPS
• Admin/dashboard routes require authentication
• SSH uses keys only, root disabled, fail2ban enabled
• Databases bind to localhost, not public internet
• Secrets stored safely, not committed, and rotated when needed
• Logs monitored regularly