Security groups on serverplus: the cloud firewall

A security group is a cloud network firewall for your server. It decides which network traffic to let to the server (inbound) and from the server (outbound). The rules work at the cloud level, before a packet even reaches the operating system.

The key principle: rules are allow-only. Everything not explicitly allowed is denied. By default inbound traffic is fully closed, so to connect to the server over SSH or open a website you must allow the needed direction and port with a rule.

Where security groups live

• The "Network" section → the "Security groups" tab. Here is the list of all project groups, their creation and rule editing.
• In the server card → "Security groups". Here you see which groups are assigned to a specific server, and you can add or remove them.
• When creating a server (the "Security groups" step) — a group can be assigned right away.

How a rule is built

Each rule in a group is described by a set of parameters (columns in the rules table):

• Direction. Inbound traffic (ingress) — who can connect to the server; Outbound traffic (egress) — where the server itself can reach.
• Protocol. TCP, UDP, ICMP or ICMPv6. TCP — for most services (SSH, HTTP), ICMP — for ping.
• Port / port range (Open Port). A specific port (Port), a range (Port range) or All ports. For example, 22 for SSH, 443 for HTTPS.
• Source (Remote). CIDR — a range of IP addresses (for example 0.0.0.0/0 — from anywhere, or 203.0.113.7/32 — a single address); or a Security group — allow traffic from servers in another group.
• Ether Type. IPv4 or IPv6.
• Description. An optional note on why the rule exists.

Stateful by default. Replies to allowed inbound connections pass automatically — you do not need a separate rule to open the "return" traffic. Outbound traffic in typical groups is fully open.

Example: what the "SSH" group consists of

The ready-made SSH group in the panel contains three rules:

• ingress · IPv4 · port 22 · TCP · 0.0.0.0/0 — allows inbound SSH connections from anywhere.
• egress · IPv4 · any port · any protocol — allows all outbound traffic (IPv4).
• egress · IPv6 · any port · any protocol — the same for IPv6.

That is, the group opens only SSH inbound, while the server can reach out freely.

Step 1. Create a security group

Open Network → Security groups and click "+ Create security group". Fill in:

• Placement region — for example uz-tas1 / RegionOne (the same as the server).
• Name — the group name, for example web-server or office-ssh.
• Description — a short description of the purpose (optional).

Click "+ Create security group". The new group appears in the list — by default with open outbound traffic and no inbound rules (we will add them next).

Step 2. Add rules

Open the created group and click "+ Add rule". In the form:

• Rule. All protocols or Custom protocol (choosing a specific protocol and port — the usual case).
• Direction — inbound or outbound.
• Open Port — a port, a range or all ports; for "Port" a number input field appears.
• Protocol — TCP / UDP / ICMP / ICMPv6.
• Remote — CIDR (an IP range) or another security group.
• Ether Type — IPv4 or IPv6.

Click "+ Add rule" — it appears in the table right away. An unneeded rule is removed with the button in the "Actions" column.

Typical rules (inbound)

• SSH (Linux): TCP · port 22. Better to limit the source to your own IP rather than 0.0.0.0/0.
• RDP (Windows): TCP · port 3389. Also limit it by IP.
• HTTP website: TCP · port 80 with 0.0.0.0/0 (the site is open to everyone).
• HTTPS website: TCP · port 443 with 0.0.0.0/0.
• Ping: ICMP (no port) — for a reachability check.
• Database (for example PostgreSQL 5432, MySQL 3306): open it only for the needed source — your own application or group, never for 0.0.0.0/0.

Step 3. Attach the group to the server

• When creating a server — at the "Security groups" step select the one you need (for example, SSH + web-server).
• On a running server — open its card → the "Security groups" section → Add security group. You can also remove a group there (the delete button in the row). Changes apply without recreating the server.

Several groups can be attached to one server — their rules are combined (the union of all permissions applies).

Limiting access by IP (CIDR)

The CIDR notation sets which addresses are allowed to reach the server:

• 0.0.0.0/0 — any address on the internet. Appropriate for a public site (80/443), dangerous for SSH/RDP and databases.
• 203.0.113.7/32 — exactly one IP (for example, your office's static address). /32 means "only this address".
• 10.0.0.0/24 — a whole subnet (256 addresses), handy for an internal network.

The main security rule. Never open SSH (22), RDP (3389) and database ports to the whole internet (0.0.0.0/0). Limit them to your own IP or a trusted subnet — this shields the server from mass password brute-forcing.

A group as a source (internal links)

In the Remote field you can specify not a CIDR but another security group. Then the rule allows traffic from all servers that belong to that group. Example: for a database server you open port 5432 not to the whole internet but only to the web-server group — so only your web servers can reach the DB.

Recommendations

• Minimum openness. Open only the ports that are really needed, and only to those who need them.
• Separate by role. A separate group for web servers, a separate one for the DB, a separate one for admin access — this is easier to manage and safer.
• Management — by IP or VPN. SSH/RDP — only from your own addresses; even better — through a VPN, without exposing the management port outward.
• Clear names and descriptions. Six months later web-server and "HTTP/HTTPS for the site" will tell you more than a nameless group.
• Check before removing. Detaching a group from a server can instantly cut off access (including your own SSH). Make sure at least one working inbound rule remains.

FAQ

How is a security group different from ufw/firewalld on the server?

A security group works in the cloud, around the virtual machine, and filters traffic before it reaches the OS. ufw/firewalld is a firewall inside the OS itself. They do not interfere with each other; for reliability they are used together (two layers of protection), but it is easier to start with a security group.

I locked myself out of SSH. What do I do?

Add back the ingress · TCP · 22 rule with your own IP, or log in to the server through the >_ Console in the panel (the web console works even without network access) and fix the settings from there.

Can I change rules on a running server?

Yes. A group's rules and a server's set of groups change on the fly, without a reboot. New rules take effect almost immediately.

What if several groups are attached to a server?

Their rules add up: what is allowed is what at least one group allows. There are no "deny" rules — only permissions on top of the "denied by default" policy.

Do I need to configure outbound rules?

Usually not — in typical groups outbound traffic is fully open. It is restricted only in tasks with heightened security requirements (so the server cannot reach out anywhere it likes).