Create and manage firewall groups from the Firewall page in my.cubepath.com. A group is a reusable set of inbound and outbound rules you attach to one or more Virtual Machines or Bare Metal (dedicated) servers.

Groups live at the project level, so any machine in the project can use one. Write the rules once, apply them everywhere, and edit them in one place when something changes. That's the whole point compared with configuring iptables on each box.

Create a group

  1. 1
    Open the create flow
    On the Firewall page, click New Group and give it a name.
  2. 2
    Add rules
    Each rule sets a direction (incoming/outgoing), protocol (TCP/UDP/ICMP/GRE), port(s) and a source/destination CIDR (empty = any).
  3. 3
    Save
    Review the rules and save the group.

Ports accept a single value (443), a list, or a range (8000-9000).

Default policies

The defaults are the part that matters, and they are not symmetric:

  • Incoming: DROP. Anything you don't explicitly allow is blocked. With no incoming rules at all, all inbound traffic is blocked.
  • Outgoing: ACCEPT. Anything you don't explicitly restrict is allowed.

So the practical work is one incoming rule per service you expose: TCP 22 for SSH, TCP 80 and 443 for a website, and so on.

Attach it to machines

Open a machine's Firewall tab (VPS or Bare Metal), click Groups, tick the group and click Apply changes. Rules take effect live, with no reboot.

Click a group on the Firewall page to see its rules. The group shows how many machines are using it, so you can see the blast radius before editing. Changing a rule affects every attached machine at once, VPS and Bare Metal alike.

Bare Metal servers

Bare Metal servers use the same firewall groups as VPS. Assign them from the server's Firewall tab in the dashboard (/baremetal/{id}/firewall), exactly as you would on a VPS, or through the API:

curl -X PUT https://api.cubepath.com/firewall/baremetal/{id}/groups \
  -H "Authorization: Bearer $CUBEPATH_TOKEN" \
  -H "X-Requested-With: XMLHttpRequest" \
  -H "Content-Type: application/json" \
  -d '{"firewall_group_ids": [12, 34]}'

A GET on the same path returns the groups assigned to the server and the status of the last sync.

How it differs from a VPS:

  • Enforced on the network, not on the server. Rules are applied on the network switch in front of the server, so filtering uses none of the server's CPU or RAM, you don't need UFW or iptables, and it survives OS reinstalls. Changes take effect within seconds.
  • Inbound only. Only incoming rules apply; outbound traffic is not filtered. Inbound traffic to the server's public IPv4 and IPv6 addresses is denied unless a rule allows it.
  • Stateless. Replies to connections the server opens are allowed for TCP, and for UDP from ports 53 (DNS) and 123 (NTP). ICMP is always allowed. Other UDP replies, for example QUIC (UDP 443), need an inbound rule.
  • Private networks are not filtered. Traffic between your servers over a private network bypasses the groups.
  • Reinstall and rescue keep working with groups attached.

To turn the firewall off on a Bare Metal server, remove all its groups.

Designing groups that stay manageable

  • One group per role, not per machine: web, database, bastion. A machine can have more than one group applied.
  • Restrict the source wherever you can. 0.0.0.0/0 on port 22 invites the entire internet's brute-force traffic into your logs; your office or VPN range removes almost all of it.
  • Keep a bastion pattern for admin ports. Allow SSH only from one hardened machine's address, and reach everything else through it.

What it doesn't do