Create a Non-root Account#

Create an account that can elevate privileges with the following command:

1
useradd -m -G sudo -s /bin/bash <username>

Then set a password for this user — at least 16 characters of mixed upper/lowercase letters and digits (my personal minimum for acceptable security):

1
passwd <username>

You should also change the root password. The default passwords on cloud servers are usually weak, and some providers even email the default credentials, which isn’t great for security.

Disable Root Password Login over SSH#

Leaving aside the fact that logging in as root is inherently risky, the root username is always “root” — if password login is allowed for it, an attacker only needs to brute-force the password to try to break into your system. Since we’ve already created a non-root account, we can simply disable SSH login for root.

Edit the SSH configuration file:

1
sudo vim /etc/ssh/sshd_config

Set the following:

1
# Disable remote password login for the root user
2
PermitRootLogin prohibit-password

Then restart the SSH service to apply the change:

1
sudo systemctl restart ssh

Why not set it to no?

I don’t usually fully disable root login with PermitRootLogin no either. I’m more used to setting up keys like any other sudoer and disabling password login entirely, allowing keys only. I only configure it that way on machines where I can operate the out-of-band cluster console; otherwise one failure could leave you without root — for example, if the disk fills up, you can’t even establish a remote SSH session.

In theory PermitRootLogin prohibit-password is fine, but it becomes a hassle when the server dies and you need rescue access. I’d actually recommend only disabling remote password login while keeping local password login, so you can still log in as root locally via VNC or IPMI to rescue the machine when something goes wrong.

Change the SSH Port#

The very first thing is to move SSH off port 22.

This is a supplement added on top of the original post.

In practice, most people change the port as soon as they log in.

The first thing I do after logging in is change the sshd port and update the firewall — port 22 gets nothing but password-guessing attempts.

One trick: after changing the port and restarting sshd, your current connection stays alive. Try connecting to the new port — if it connects, the change worked. If you can’t establish a new connection, you can still revert the change or check your firewall configuration.

Normally, editing the SSH port via sudo vim /etc/ssh/sshd_config and restarting with sudo systemctl restart ssh.service is enough:

1
# Set the SSH port
2
Port <your-port>

However, on Ubuntu 22.10 or newer you may find this is ineffective — after restarting, the SSH service still listens on the original port.

That’s because on Ubuntu 22.10 and newer, ssh is socket-activated by default.

On Ubuntu 22.10, Ubuntu 23.04, and Ubuntu 23.10, change it like this:

1
sudo mkdir -p /etc/systemd/system/ssh.socket.d
2
sudo vim /etc/systemd/system/ssh.socket.d/listen.conf
3
sudo systemctl daemon-reload
4
sudo systemctl restart ssh.socket
5
sudo systemctl restart ssh.service

A reference listen.conf:

1
[Socket]
2
ListenStream=
3
ListenStream=2233

On Ubuntu 24.04, change it like this:

1
sudo vim /etc/ssh/sshd_config
2
sudo systemctl daemon-reload
3
sudo systemctl restart ssh.service

If you don’t care about the memory saved by socket activation, you can revert to a non-socket-activated setup with the following commands:

WARNING

Make sure your configuration files are correct first.

1
sudo systemctl disable --now ssh.socket
2
sudo systemctl enable --now ssh.service

If you’re migrating a configuration (from Ubuntu 22.10 and above, below 24.04):

1
sudo systemctl disable --now ssh.socket
2
rm -f /etc/systemd/system/ssh.service.d/00-socket.conf
3
rm -f /etc/systemd/system/ssh.socket.d/addresses.conf
4
sudo systemctl daemon-reload
5
sudo systemctl enable --now ssh.service

Instead of editing /etc/ssh/sshd_config directly, it’s better to create a conf file under /etc/ssh/sshd_config.d/ for your custom sshd settings. This prevents configuration conflicts after an OpenSSH update.

Reference: ssh - PasswordAuthentication no, but I can still login by password - Unix & Linux Stack Exchange

Some cloud providers drop their own conf file into /etc/ssh/sshd_config.d/ to enable remote password login (sshd disables it by default). Rule those out before modifying any sshd settings:

1
# Check whether sshd_config.d contains other conf files
2
sudo ls /etc/ssh/sshd_config.d/*.conf
3
# If so, rename them so your custom config isn't overridden
4
sudo mv /etc/ssh/sshd_config.d/xxx.conf/etc/ssh/sshd_config.d/xxx.conf.bak

CloudCone, for example, ships a /etc/ssh/sshd_config.d/50-cloud-init.conf.

After changing sshd settings, run sudo sshd -T first to inspect the effective configuration, so you’re not blindsided by an override :joy:.

1
# How root is allowed to log in
2
sudo sshd -T | grep -i "PermitRootLogin"
3
# Password authentication
4
sudo sshd -T | grep -i "PasswordAuthentication"
5
# SSH port
6
sudo sshd -T | grep -i "Port"

Worth noting: prohibit-password is an alias of without-password, so seeing the output below is perfectly normal.

1
$ sudo sshd -T | grep -i "PermitRootLogin"
2
permitrootlogin without-password

References:

• Permit root to login via ssh only with key-based authentication - Unix & Linux Stack Exchange
• OpenSSH 7.0 Release Notes

Protect SSH from Brute Force with Fail2ban#

Install Fail2ban:

1
sudo apt install fail2ban

The officially recommended approach is to customize settings via jail.local:

1
sudo vim /etc/fail2ban/jail.local

Use the following config as a starting point for your own (remember to remove the comments):

1
[sshd]
2
ignoreip = 127.0.0.1/8 # Whitelist
3
enabled = true
4
filter = sshd
5
port = 22 # Port; update this if you changed the SSH port
6
maxretry = 5 # Maximum number of attempts
7
findtime = 300 # Window in seconds within which maxretry applies
8
bantime = 600 # Ban duration in seconds; -1 is a permanent ban (not recommended)
9
action = %(action_) s [port="%(port) s", protocol="%(protocol) s", logpath="%(logpath) s", chain="%(chain) s"] # Use this if you don't need email notifications
10
banaction = iptables-multiport # Ban method
11
logpath = /var/log/auth.log # SSH login log location

SSH Login Notifications#

Very useful. I also added a WeCom bot notification that fires automatically on every SSH login, so I’d know right away if someone got in.

You can use a PAM module to trigger a script on every SSH login.

Edit /etc/pam.d/sshd and append:

1
session    optional    pam_exec.so /path/to/script

For the use case above, the script looks roughly like this: Reference: https://developer.work.weixin.qq.com/document/path/91770

Note (Nov 26, 2024): Fixed some issues in the example script.

1
#!/bin/bash
2

3
if [ "$PAM_TYPE" != "open_session" ]; then
4
    exit 0
5
fi
6

7
ip=$PAM_RHOST
8
date=$(date +"% e % b % Y, % a % r")
9
name=$PAM_USER
10

11
webhook_url="https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=xxxxxxxxxxxxxxx"
12

13
curl -s -X POST "$webhook_url" \
14
    -H "Content-Type: application/json" \
15
    -d "{
16
    \"msgtype\": \"markdown\",
17
    \"markdown\": {
18
        \"content\": \"**Login Alert**\\n> User: $name\\n> Client IP: $ip\\n> Login time: $date\"
19
    }
20
}"

Replace the API key and delivery method with whatever fits your own use case.

Once the script is written, make it executable:

sudo chmod +x /usr/local/bin/notify_ssh_login.sh

[Strict] Run Commands with Absolute Paths#

Using absolute paths pins down exactly which program or file runs, so a tampered environment variable can’t trick you into executing a potentially malicious program.

Using the full path to su avoids running a fake su planted by an attacker.

Log In with SSH Keys#

TIP

If your VPS provider offers SSH key binding, you can skip this section and follow the provider’s method.

Run this in PowerShell:

1
ssh-keygen -t ed25519

Just accept the default key path. You can leave the passphrase empty or set one.

1
Generating public/private ed25519 key pair.
2
Enter file in which to save the key (C:\Users\<user>/.ssh/id_ed25519): # Press Enter to accept the default
3
Enter passphrase (empty for no passphrase): # Leave empty or set a passphrase
4
Enter same passphrase again: # Same as above

Then edit the authorized keys file on the VPS:

1
vim ~/.ssh/authorized_keys

Next, open C:\Users<user>/.ssh/id_ed25519.pub, copy its contents, and paste them in.

Edit the SSH configuration file:

1
sudo vim /etc/ssh/sshd_config

Set the following:

1
PubkeyAuthentication yes
2
AuthorizedKeysFile .ssh/authorized_keys
3
PasswordAuthentication no

Then restart the SSH service to apply the change:

1
sudo systemctl restart ssh

Enable the UFW Firewall#

TIP

If your VPS provider offers a firewall and you don’t have complex requirements, you can skip this section and use the provider’s firewall.

Before enabling UFW, we need to set up rules first. Let’s start with UFW’s default policies:

1
sudo ufw default allow outgoing # Allow all outbound traffic by default
2
sudo ufw default deny incoming # Deny all inbound traffic by default

View the currently active UFW rules:

1
sudo ufw status
2
sudo ufw status numbered  # Show rules with numbers

Allow or deny traffic on a port with the following commands (22, 80, and 443 used as examples):

1
# Allow inbound traffic on port 22/proto
2
sudo ufw allow in 22/proto
3

4
# Allow outbound traffic on port 22/proto
5
sudo ufw allow out 22/proto
6

7
# Without specifying in/out, it defaults to in
8
sudo ufw allow 22/proto
9

10
# Without specifying a protocol, both tcp and udp are allowed
11
sudo ufw allow 22
12

13
# To deny instead, change allow to deny
14
sudo ufw deny 22
15

16
# Allow a port range from start_port to end_port
17
sudo ufw allow start_port:end_port
18

19
# Allow multiple ports, comma-separated
20
sudo ufw allow port1,port2
21

22
# Allow traffic from a specific IP or CIDR range
23
sudo ufw allow from ip/cidr
24

25
# Allow traffic from a specific IP or CIDR range to port 22
26
sudo ufw allow from ip/cidr to any port 22
27

28
# Allow tcp traffic from a specific IP or CIDR range to port 22
29
sudo ufw allow from ip/cidr to any proto tcp port 22
30

31
# If you specify multiple ports, you must specify the protocol
32
sudo ufw allow from ip to any proto tcp port 80,443
33

34
# comment adds a description to the rule
35
sudo ufw allow from ip to any proto tcp port 80,443 comment "hello"

Delete active rules with:

1
sudo ufw delete allow 22 # Prefix the rule with delete
2
sudo ufw delete 1 # Or delete by the number from "ufw status numbered"

Once all rules are in place, start, stop, or reload UFW:

WARNING

Before enabling the firewall, make sure port 22 (or whatever your SSH port is) is allowed.

1
sudo ufw enable|disable|reload

To reset all rules:

WARNING

Make sure UFW is disabled before resetting the rules.

1
sudo ufw reset

My advice: only allow the ports you actually use, such as 22, 80, and 443.

By default, UFW only logs dropped packets that don’t match a rule. If you want detailed logging for a service, add log after allow:

1
# Log successful SSH connections too, for the record
2
ufw allow log 22/tcp

Block Ping#

1
-A ufw-before-input -p icmp --icmp-type echo-request -j DROP
2
-A ufw-before-forward -p icmp --icmp-type echo-request -j DROP

1
-A ufw6-before-output -p icmpv6 --icmpv6-type echo-request -j DROP
2
-A ufw6-before-output -p icmpv6 --icmpv6-type echo-reply -j DROP

Restrict SSH Access by IP#

My office network has a static IP, so I open port 22 in the VPS provider’s firewall and restrict it to that IP. Whenever I need access from another IP, I just add it.

If you have a dynamic public IP and your provider offers an API for modifying firewall rules, you can use that directly.

If you don’t have a static IP at home, you can use a web terminal like Tencent Cloud’s orcaterm — the basic features are free forever. Here are orcaterm’s IP ranges; load them into ipset and allow only those IPs to reach the SSH port. Test that the connection actually works before applying the rule. If you’re a Tencent Cloud user, you can even drop the SSH port entirely in the security group — when I used Tencent Cloud, I only opened ports 80 and 443.

You can also do this with UFW.

Or use the firewall provided by your VPS provider (if supported) — it’s easier to adjust when you run into connectivity problems.

Steps for adding servers from other providers to orcaterm:

Update Regularly#

My advice is to log into your VPS periodically and run sudo apt update && sudo apt upgrade to keep every package up to date.

That said, Ubuntu installs security updates automatically every day by default, so you don’t need to do this too often.

Enable Ubuntu Pro#

The same great OS, with more security updates Reducing the average CVE (Common Vulnerabilities and Exposures) exposure time from 98 days to 1 day Extended CVE patching, ten years of security maintenance, optional support, and maintenance for your entire open-source application stack

That’s Ubuntu’s official marketing copy. I can’t tell you exactly how useful it is, but a fix is better than no fix — and it’s free for up to 5 machines for personal use, so enabling it costs you nothing.

First, create an Ubuntu One account: https://ubuntu.com/login

After registering, go to https://ubuntu.com/pro/dashboard to find your token.

Once you have your token, head to the VPS and run sudo pro attach [YOUR_TOKEN]. After a short wait, Ubuntu Pro is enabled. I’d recommend running sudo apt update && sudo apt upgrade once more afterwards to make sure the latest security updates are installed.

Stop SSL Certificates from Leaking Your IP#

This section, “Stop SSL Certificates from Leaking Your IP,” is quoted from “How to Prevent Certificates from Leaking Your Origin IP” by Qiu Weimeng, published under the CC BY-SA 4.0 license. The rest of this article is published under the CC BY-NC-SA 4.0 license, but this section uses the CC BY-SA 4.0 license.

1
-----BEGIN CERTIFICATE-----
2
contents of certificate.crt
3
-----END CERTIFICATE-----
4
-----BEGIN CERTIFICATE-----
5
contents of ca_bundle.crt
6
-----END CERTIFICATE-----

1
server {
2
#HTTP Server Default Set
3
    listen 80;
4
    listen 443 ssl http2 default_server;
5
    server_name ip;
6

7
    #HTTP_TO_HTTPS_END
8
    ssl_certificate /etc/nginx/ip-certificate/certificate.crt;
9
    ssl_certificate_key /etc/nginx/ip-certificate/private.key;
10
    ssl_protocols TLSv1.1 TLSv1.2 TLSv1.3;
11
    ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:HIGH:!aNULL:!MD5:!RC4:!DHE;
12
    ssl_prefer_server_ciphers on;
13
    ssl_session_cache shared:SSL:10m;
14
    ssl_session_timeout 10m;
15

16
    #Server ROOT
17
    index index.html;
18
    root /var/www/html/;
19
    index index.html;
20

21
    return 444; #NGINX HTPP Code 444
22
}

The Newer Method (Nginx 1.19.4+)#

If your Nginx version is 1.19.4 or newer, you can use the ssl_reject_handshake directive to reject every TLS handshake that doesn’t match a configured domain:

1
server {
2
    listen 443 ssl default_server;
3
    server_name _;
4
    ssl_reject_handshake on;
5
}

If you get an error like nginx: [emerg] unknown directive "ssl_reject_handshake", first check whether your Nginx version is at least 1.19.4 — ssl_reject_handshake on; was added in Nginx 1.19.4 (mainline).

If you compiled Nginx from source, make sure the ngx_http_ssl_module module is enabled. It isn’t built by default; you need the --with-http_ssl_module configure option.

Are We Safe Now?#

In the previous sections, we only ensured that an attacker can’t fetch a default certificate by visiting your IP directly and infer your domain from it. Nothing says an attacker has to learn IP-to-domain mappings that way, though. As you can see, the rules above all rely on server_name matching. An attacker could easily walk through every non-CDN IP range carrying the correct server_name, recording which targets respond correctly. Here’s a simple implementation of that check (without the scanning part):

1
# https://gist.github.com/Raven95676/39ffdba22144e39d7155ad9dc1bcca55
2
import ssl
3
import socket
4
def check (ip, domain):
5
    try:
6
        context = ssl.create_default_context ()
7
         with socket.create_connection ((ip, 443)) as sock:
8
            with context.wrap_socket (sock, server_hostname=domain) as ssl_sock:
9
                request = f"GET / HTTP/1.1\nHost: {domain}\nConnection: close\n\n"
10
                ssl_sock.sendall (request.encode ())
11
                ssl_sock.recv (4096)
12
        return True
13
    except Exception:
14
        return False
15

16
print (check ("192.168.0.256", "example.com"))

Patching It Up#

TIP

If your VPS provider offers a firewall, you can just use the provider’s firewall.

You can just use this method

We can allow only the CDN’s CIDR ranges to reach ports 80/443 on the server. First, add the allow rules:

1
sudo ufw allow from "CIDR range" to any proto tcp port 80,443 comment "CDN provider"

The comment isn’t required — it’s just so you can recognize what the rule is for later.

Ask your CDN provider for its CIDR ranges — some publish them on their website. For example, Cloudflare’s CIDR ranges are available at: https://www.cloudflare.com/ips-v4

That’s the IPv4 list; the IPv6 one is at: https://www.cloudflare.com/ips-v6

For Cloudflare, a community member also wrote a script that syncs Cloudflare’s IPs into UFW for port 443 when run:

1
RULES=$(sudo ufw status numbered | grep 'Cloudflare IP' | awk -F"[][]" '{print $2}' | sort -nr)
2
for RULE in $RULES; do
3
    echo "Deleting rule $RULE"
4
    echo "y" | sudo ufw delete $RULE
5
done
6

7
for cfip in `curl -sw '\n' https://www.cloudflare.com/ips-v {4,6}`; do ufw allow proto tcp from $cfip to any port 443 comment 'Cloudflare IP'; done
8

9
ufw reload > /dev/null

Because of the special circumstances involved, I’d suggest running the following command first to check that the output is correct before deploying the script:

1
for cfip in `curl -sw '\n' https://www.cloudflare.com/ips-v {4,6}`; do echo $cfip; done

If the output looks right (like below), you can deploy it:

1
173.245.48.0/20
2
103.21.244.0/22
3
… (omitted)
4
2400:cb00::/32
5
2606:4700::/32
6
… (omitted)

After adding the rules, list the current firewall rules:

1
sudo ufw status numbered

Delete any pre-existing rules that allow all traffic on ports 80 and 443:

1
sudo ufw delete <number>

Why not just use Nginx’s deny directive? Because deny returns a 403 Forbidden status code — and before it can, the TLS handshake must complete. Only after a successful TLS handshake can the client send an HTTP request and receive a response. So using deny directly here would be doing pointless work.

Are We Really Safe…?#

This is really a Cloudflare special, but the ideas apply to other CDN providers too if you want extra security. Cloudflare offers more than CDN services — there’s a whole lineup of products like Workers and WARP. Some of these services have characteristics worth noting:

• They can make outbound requests
• They use Cloudflare’s IP ranges

Cloudflare certainly restricts abuse, but just in case, we can take one more security measure — Authenticated Origin Pulls.

[!INFO] Make sure the SSL/TLS encryption mode is set to Full or Full (strict).

Download the Cloudflare certificate and configure it:

1
ssl_client_certificate /path/to/certificate.pem;
2
ssl_verify_client on;

Then enable Authenticated Origin Pulls under SSL/TLS → Origin Server.

The SafeLine WAF community edition can’t stably use this method yet, unless you’re willing to put another reverse proxy in front of it.

Docker Basics#

NOTE

There’s mature documentation available, so I won’t reinvent the wheel.

This article is unrelated to the https://github.com/yeasy/docker_practice project.

Just being a little lazy

Side note: if docker-compose says the command isn’t found, try docker compose. The version field is deprecated in docker compose — it will be ignored with a warning in existing compose files.

https://yeasy.gitbook.io/docker_practice

Update: added the official Chinese Docker documentation.

https://docs.docker.net.cn/manuals/

When UFW Can’t Control Docker (Recommended)#

One more thing about Docker: you don’t really need UFW to manage which ports Docker exposes — Docker writes its own iptables rules to control them. Using docker compose as an example:

1
ports:
2
    - 127.0.0.1:<port>:<port>

1
ports:
2
      - <port>:<port>

1
services:
2
    rsshub:
3
        image: diygod/rsshub:latest
4
        restart: always
5
        ports:
6
            - 127.0.0.1:1200:1200
7
        environment:
8
            NODE_ENV: production
9
            CACHE_TYPE: redis
10
            REDIS_URL: "redis://redis:6379/"
11
            PUPPETEER_WS_ENDPOINT: "ws://browserless:3000"
12
        env_file:
13
            - .env
14
        healthcheck:
15
            test: ["CMD", "curl", "-f", "http://localhost:1200/healthz"]
16
            interval: 30s
17
            timeout: 10s
18
            retries: 3
19
        depends_on:
20
            - redis
21
            - browserless
22

23
    browserless:
24
        image: browserless/chrome
25
        restart: always
26
        ulimits:
27
            core:
28
                hard: 0
29
                soft: 0
30
        healthcheck:
31
            test: ["CMD", "curl", "-f", "http://localhost:3000/pressure"]
32
            interval: 30s
33
            timeout: 10s
34
            retries: 3
35

36
    redis:
37
        image: redis:alpine
38
        restart: always
39
        volumes:
40
            - ./data:/data
41
        healthcheck:
42
            test: ["CMD", "redis-cli", "ping"]
43
            interval: 30s
44
            timeout: 10s
45
            retries: 5
46
            start_period: 5s
47

48
    sb:
49
        image: ghcr.io/sagernet/sing-box
50
        container_name: sb
51
        restart: always
52
        volumes:
53
            - ./sing-box:/etc/sing-box/
54
        command: -D /var/lib/sing-box -C /etc/sing-box/run

1
networks:
2
  default:
3
    external: true
4
    name: ${DOCKER_MY_NETWORK}
5
services:
6
  mysql:
7
    container_name: mysql8
8
    image: mysql:8
9
    # ports:
10
    #   - "3306:3306"
11
    environment:
12
      TZ: Asia/Shanghai
13
    networks:
14
      default:
15
        ipv4_address: 172.20.0.15
16
    restart: unless-stopped

When UFW Can’t Control Docker (Not Recommended)#

This section, “When UFW Can’t Control Docker (Not Recommended),” is quoted from the README of the project ufw-docker by chaifeng, released under the GPL-3.0 license. The rest of this article is published under the CC BY-NC-SA 4.0 license, but this section uses the GPL-3.0 license.

The current new solution only requires modifying one UFW config file; keep all of Docker’s own config and options at their defaults.

Edit UFW’s config file /etc/ufw/after.rules and append the following rules:

1
# BEGIN UFW AND DOCKER
2
*filter
3
:ufw-user-forward - [0:0]
4
:ufw-docker-logging-deny - [0:0]
5
:DOCKER-USER - [0:0]
6
-A DOCKER-USER -j ufw-user-forward
7

8
-A DOCKER-USER -j RETURN -s 10.0.0.0/8
9
-A DOCKER-USER -j RETURN -s 172.16.0.0/12
10
-A DOCKER-USER -j RETURN -s 192.168.0.0/16
11

12
-A DOCKER-USER -p udp -m udp --sport 53 --dport 1024:65535 -j RETURN
13

14
-A DOCKER-USER -j ufw-docker-logging-deny -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 192.168.0.0/16
15
-A DOCKER-USER -j ufw-docker-logging-deny -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 10.0.0.0/8
16
-A DOCKER-USER -j ufw-docker-logging-deny -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 172.16.0.0/12
17
-A DOCKER-USER -j ufw-docker-logging-deny -p udp -m udp --dport 0:32767 -d 192.168.0.0/16
18
-A DOCKER-USER -j ufw-docker-logging-deny -p udp -m udp --dport 0:32767 -d 10.0.0.0/8
19
-A DOCKER-USER -j ufw-docker-logging-deny -p udp -m udp --dport 0:32767 -d 172.16.0.0/12
20

21
-A DOCKER-USER -j RETURN
22

23
-A ufw-docker-logging-deny -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW DOCKER BLOCK]"
24
-A ufw-docker-logging-deny -j DROP
25

26
COMMIT
27
# END UFW AND DOCKER

Then restart UFW with sudo systemctl restart ufw. From now on, the outside can no longer access any port published by Docker, while containers can still communicate with each other on private network addresses, and containers can still access the external network normally. The rules may fail to take effect after restarting UFW due to some unknown reason — if so, reboot the server.

To allow external access to a service provided by a Docker container — say a container’s service port is 80 — use the following command:

1
ufw route allow proto tcp from any to any port 80

This allows external access to every service published by Docker whose internal service port is 80.

Note that this 80 is the container’s port, not the 8080 port published on the server with something like -p 0.0.0.0:8080:80.

If multiple containers have service port 80 but you only want a specific one reachable from outside — say its private address is 172.17.0.2 — use a command like:

1
ufw route allow proto tcp from any to 172.17.0.2 port 80

If a container’s service uses UDP, say a DNS service, use the following command to allow external access to all published DNS services:

1
ufw route allow proto udp from any to any port 53

Similarly, to target just one specific container, e.g. the IP 172.17.0.2:

1
ufw route allow proto udp from any to 172.17.0.2 port 53

Deployment#

There’s a one-click deployment command:

1
bash -c "$(curl -fsSLk https://waf-ce.chaitin.cn/release/latest/setup.sh)"

Or deploy the LTS version:

1
RELEASE=lts bash -c "$(curl -fsSLk https://waf-ce.chaitin.cn/release/latest/setup.sh)"

Since this setup puts Cloudflare in front of the SafeLine WAF, you need to set Protected Sites → Global Config → Origin IP retrieval to “Take the address of the previous proxy from X-Forwarded-For”.

If other issues come up, check the troubleshooting section of the official documentation.

Accessing the SafeLine Console via a Domain#

Best solution: don’t use a domain

If you want to access the SafeLine console via a domain, you’ll find it doesn’t work once Cloudflare’s orange cloud is enabled. That’s because Cloudflare’s port forwarding only supports a fixed set of ports:

HTTP ports supported by Cloudflare: 80, 8080, 8880, 2052, 2082, 2086, 2095

HTTPS ports supported by Cloudflare: 443, 2053, 2083, 2087, 2096, 8443

The solution is simple: go to Rules → Origin Rules and create a rule. The incoming request match expression looks roughly like:

1
(starts_with (http.request.full_uri, "https://<your-domain>"))

Set the destination port rewrite to 9443.

To hide your public IP, add a firewall rule that only lets Cloudflare’s CDN CIDR ranges reach port 9443.

Redirect Issues#

If a port number unexpectedly appears in the URL after a redirect, add the following under Protected Sites → Site Details → Custom NGINX Config:

1
proxy_redirect https://$host:[port] https://$host;

Hide the Admin Panel with WireGuard#

Don’t expose your VPS admin panels (such as the SafeLine WAF or BT Panel) to the public internet. Accessing them over a VPN like WireGuard is a more secure choice. Detailed WireGuard installation instructions are available at Installation - WireGuard.