Cloud Firewall

The Cloud Firewall is a distributed firewall for managing network access to, from and between Brightbox Cloud Servers.

It’s controlled using the API, commonly using Brightbox manager or the CLI.

See this screencast for an introduction to using Brightbox Manager to configure firewall policies. Or see the Cloud Firewall guide for a step by step walkthrough of setting up the Cloud Firewall using the CLI.

Server Group

A Server Group is a logical grouping of Cloud Servers. Servers can be a member of one or more Server Groups, and can be added to or removed from them at any time.

Server Groups are a useful system in their own right, and will be the building blocks of other Brightbox features. See the Server Groups guide for more details.

Firewall Policy

A Firewall Policy represents a list of Firewall Rules and is associated with a Server Group. Rules are reapplied whenever the policy or group membership changes.

When first created, a Firewall Policy has no rules and has no associated Server Group.

A Firewall Policy can only consist of Firewall Rules that accept traffic, which means a Cloud Server can easily be controlled by multiple Firewall Policies without worrying about the ordering of the rules. A Cloud Server can have multiple Firewall Policies by being in multiple Server Groups. Any traffic that is not matched by an accept rule in any of the applied policies is rejected.

Firewall Rules

A Firewall Rule is a set of criteria for matching IP packets crossing the firewall. Packets can be matched based on source or destination address, protocol and source and destination ports. For protocol icmp, the icmp type can also be matched.

Direction

There is no explicit concept of incoming or outgoing rules - the direction of the rule is implied by the address criteria. So when matching on destination address, the source is considered to be the Server Group (so is an outgoing rule). When matching on source address, the destination is considered to be the Server Group (so is an incoming rule).

Address criteria

Source or destination addresses can be a few different types:

Both source and destination addresses cannot be specified in the same rule - one “side” of the rule is always the Server Group that the Firewall Policy is applied to.

Note that servers within a Server Group cannot reach each other unless there are both rules allowing traffic destined to and originating from it.

Protocol Criteria

Protocol can be specified as an 8bit integer so you can match any IP protocol, but for convenience the strings tcp, udp or icmp are also accepted.. Not specifying a protocol matches all IP protocols.

Port Criteria

Ports can only be used with protocols tcp and udp. Source and destination ports can be specified in a few different ways:

Not specifying a port matches all ports.

Stateful

The Cloud Firewall is stateful, so you only need to write a rule in one direction - you do not need to worry about the reply packets coming back the other way.

Also, removing rules will only affect new connections. Existing established connections will not be disconnected mid-stream.

For tcp, an established connection is any connection that has passed the three way handshake and hasn’t yet sent the final FIN packets.

udp isn’t a real stateful protocol, so we consider a udp “connection” open for 30 seconds after each packet.

icmp isn’t stateful either, we consider an icmp “connection” open for 30 seconds after receiving an icmp echo request.

Default Firewall Policy

Every account has one default Server Group that all newly created servers become a member of (unless you explicitly put them in a different group). That group has a Firewall Policy applied with some default rules.

For customers who signed up before 2nd November 2011, the default policy is to accept all traffic in both directions (just as it did before the Cloud Firewall was implemented).

For customers who signed up after 2nd November, the default policy is as follows:

Which means allow all outgoing traffic, allow incoming icmp pings, allow incoming tcp ports ssh, http and https, and allow incoming connections from all other servers in the default group.

So incoming access is restricted to some commonly used ports, but all servers in the group can reach each other openly.