Flexus L: Minimum Security Group Openings and SSH Hardening

When I first opened a Flexus L instance, the fastest way to get in was also the riskiest way: open port 22 to the whole internet and log in with a password. It works, and it is also exactly what automated scanners look for. This note is the stricter version I now use on a small study server: open as little as possible in the security group, and harden SSH so that even the one open door is hard to abuse.

Start with the security group, not with the server

A security group is a virtual firewall that sits in front of the instance. On Huawei Cloud, open the instance and check its security group inbound rules before you install anything. The rule I start from is: nothing inbound, then add only what the workload actually needs.

For a typical small web study server, that means:

• SSH, TCP 22, only from your own public IP, written as a /32 address. Never 0.0.0.0/0 if you can avoid it. If your home IP changes, update the rule instead of widening it permanently.
• HTTP, TCP 80, and HTTPS, TCP 443, only if the server really serves a website to the public. If it is only a study box you reach over SSH, leave both closed.
• Nothing else. In particular, do not open database ports such as 3306 or 6379, or remote desktop port 3389, to the internet. A database should be reached from the application server or a private network, not from anywhere.

Outbound rules can stay permissive at first, because the server needs to fetch updates and packages. Inbound is where the risk lives, so that is where you should be strict.

A useful check after every change: try to reach the server from a network that is not on the allow list. The connection should time out, not be refused with a login prompt. If you can still reach SSH from anywhere, the rule did not take effect or another security group is attached.

Harden SSH after the firewall

With only your IP allowed through, harden the service itself. These steps are for a Linux server, and they assume you have a key pair ready before you turn password login off. Do not lock yourself out: test the key login in a second terminal window before you close the first one.

1. Use a key pair, not a password, for daily login. Create a key on your own computer, add the public key to the server, and confirm that ssh with the key works.
2. Edit the SSH daemon configuration, usually /etc/ssh/sshd_config, and set:

PasswordAuthentication no
PermitRootLogin prohibit-password
PubkeyAuthentication yes

Then restart the service. Root should never log in with a password, and ordinary users should not either once keys work.
3. Create a normal user with sudo rights and log in as that user. Reserve root for the console or for emergencies, not for routine SSH sessions.
4. Consider changing the SSH port only as an extra layer, not as a substitute for a firewall rule. If you change it, update the security group to match the new port, and remember that scanners still find open ports. The firewall rule and key login matter far more than the port number.
5. Keep the system patched, and check login logs from time to time. Repeated failed logins from many addresses are a sign that the port is visible. If you see them, tighten the security group first, then look at the service.

What not to do

Do not copy a wide-open security group from a tutorial and leave it in place after the tutorial ends. Do not share a server password in chat or in a note, and do not reuse the same password for the console and for SSH. Do not open a port just to test something and forget to close it. The cheapest audit is a regular look at the inbound rules: every rule should have a reason, a source address, and an owner. If a rule has none of those, remove it.

A short checklist for a new Flexus L server

• Security group inbound: SSH from one /32 only, plus 80 and 443 only if serving a website.
• No database, cache, or remote desktop port open to the internet.
• SSH key login tested, password login off, root password login off.
• A non-root user with sudo for daily work.
• System updated, and inbound rules reviewed again after any test that needed a temporary opening.

The point is not to make the server unreachable. It is to make it reachable only in the ways you intended, from the places you intended. A small server with a narrow security group and key-only SSH is far less interesting to a scanner than a server with every port open, and it is also easier to reason about when something goes wrong.