The Cloud Instance Firewall

Every cloud instance has its own firewall: a packet filter in front of the instance that decides which traffic reaches it. You write rules by protocol, port and source, switch the firewall on, and only what you've allowed gets through. It's independent of anything running inside the instance, so a rule here still holds when the guest's own firewall is off.

How a rule works

A rule has a direction (inbound or outbound) and an action: accept, drop (throw the packet away without a word) or reject (refuse it and say so). Three optional filters narrow what it matches:

• A protocol: tcp, udp or icmp.
• A port or port range, such as 443 or 8000:8100. A port means nothing without a protocol, so set that too.
• A source, either one IP address or a CIDR range, when the rule should only apply to certain senders.

Rules are evaluated in order. Each can carry an optional comment, so you remember later why it's there.

Turning it on without locking yourself out

As soon as a firewall is enabled, anything not allowed is blocked, and the classic mistake is switching on a filter that drops your own SSH session. So if you enable the firewall before adding any inbound allow rule, we add one for you: inbound, accept, TCP port 22. That keeps SSH reachable while you build your rule set, and you can't lock yourself out. When your own rules are in place and you've confirmed you can still get in, you can remove that keep-alive rule.

In the portal

Open the instance from Virtual Machines, go to Network, and find the Firewall panel. Add rules with direction, action, protocol, port and source; each one shows up in the list with its position and a remove control. One switch turns the whole firewall on or off. Build your rules first, check you still have access, and only then enable it.

With the API

Reading needs read, and changing rules takes the VMs scope (vms.write). The calls below read the current state, add a rule, remove one by position, and toggle the firewall:

curl -s https://api.amoni.app/v1/vms/990204/411/firewall \
  -H "Authorization: Bearer nr_live_..."
# { "success": true, "data": {
#   "enabled": true,
#   "rules": [ { "pos": 0, "direction": "in", "action": "ACCEPT",
#                "proto": "tcp", "port": "22", "source": null, "comment": "SSH" } ] } }

# allow HTTPS from anywhere
curl -s -X POST https://api.amoni.app/v1/vms/990204/411/firewall \
  -H "Authorization: Bearer nr_live_..." -H "Content-Type: application/json" \
  -d '{"direction": "in", "action": "ACCEPT", "proto": "tcp", "port": "443", "comment": "web"}'
# { "success": true, "data": { "message": "Rule added." } }

# restrict SSH to your office range
curl -s -X POST https://api.amoni.app/v1/vms/990204/411/firewall \
  -H "Authorization: Bearer nr_live_..." -H "Content-Type: application/json" \
  -d '{"direction": "in", "action": "ACCEPT", "proto": "tcp", "port": "22", "source": "203.0.113.0/24", "comment": "office SSH"}'

# remove the rule at position 0
curl -s -X DELETE https://api.amoni.app/v1/vms/990204/411/firewall/0 \
  -H "Authorization: Bearer nr_live_..."

# turn the firewall on (or off with false)
curl -s -X PUT https://api.amoni.app/v1/vms/990204/411/firewall/enable \
  -H "Authorization: Bearer nr_live_..." -H "Content-Type: application/json" \
  -d '{"enabled": true}'

The API checks two things in what you send. A port without a proto gets 422 with code port_needs_proto, since without a protocol the filter can't do anything with a port. A source that isn't an IP or CIDR gets 422 invalid_source. And if you enable a firewall that has no inbound allow rule yet, the SSH keep-alive rule from above goes in before it turns on.

A safe starting set

For a typical web instance, allow inbound TCP 22 from your own address and inbound TCP 80 and 443 from anywhere, and let everything else fall to the default drop once the firewall is on. Add your own SSH rule before enabling and the automatic one never gets created. Whichever way you go, check SSH still works before you log out.

Questions we get

• Drop or reject? Drop throws the packet away without replying, so a scanner sees nothing at all. Reject sends back a refusal, which is kinder to your own clients. Drop suits the open internet; reject fits where failing fast helps.
• Why is there an SSH rule I did not add? That's the keep-alive we add when a firewall is enabled without any inbound allow rules, so you can't lock yourself out. Once your own rules cover access, remove it.
• Does this replace the firewall inside my instance? No. It sits in front of that one, and you can run both; this one keeps holding even if the guest's is off.
• Can I filter outbound traffic? Yes. Set direction to out. Most setups only filter inbound, though the option exists.
• Do bare-metal servers have this? It's a cloud-instance feature. For a bare-metal server under attack, see DDoS protection and blackholing.

Still stuck?

Open a support ticket naming the instance and the rule you're trying to add, and we'll check what the filter accepted.