Firewall & ACLs
A firewall decides which traffic is allowed to reach a server and which is turned away. On GalaxyGate, firewall rules are set per instance: each server has its own Firewall tab, and the rules you add there act like an access control list sitting in front of that machine. Traffic that matches an allow rule gets through; traffic that matches a deny rule is dropped.
Because the rules belong to one instance, you manage them by opening that server, not from the Security sidebar.
What a rule is
A rule describes a kind of traffic and whether to allow or deny it. You build one from a few parts.
| Part | What it means |
|---|---|
| Action | Allow the matching traffic through, or deny it. |
| Protocol | The kind of traffic, such as TCP or UDP. |
| Port | The port the traffic is headed to, for example 22 for SSH or 443 for HTTPS. |
| Source | Where the traffic is coming from, given as an address or range. Narrow this to only the addresses that should be allowed in. |
Taken together, your rules form an ordered access control list in front of the server. You use them to open exactly the ports your service needs and to keep everything else closed.
Add a rule
Open the instance, select the Firewall tab, and choose Add rule. Pick the action, protocol, port, and source, then save. The rule takes effect on that instance.
| Action | Protocol | Port | Source |
|---|---|---|---|
| Allow | TCP | 22 | 203.0.113.10/32 |
| Allow | TCP | 443 | 0.0.0.0/0 |
| Deny | TCP | 3306 | 0.0.0.0/0 |
The button pulses because that is where you click.
A bad rule can lock you out
Firewall rules apply to your own connections too. If you deny the port you log in on, or restrict SSH to a source address that is not yours, you can shut yourself out of the server.
Do not lock yourself out of SSH
Before you deny or narrow the SSH port (22 by default), make sure the source you allow includes the address you connect from. If you lose SSH access, you are not stuck: open the instance's Terminal tab to reach the machine over the VNC console, which does not go through the firewall, and fix or remove the rule from there.
Test on a narrow rule first
Add one specific allow rule and confirm you can still connect before you add a broad deny. It is much easier to widen access than to recover from a rule that cut you off.
Related
- VNC console for getting back in if a rule locks you out.
- Security overview