Contents


Building out infrastructure that is publicly accessible means it also has a risk of intrusion. GoGrid's Firewall Service is designed to protect your infrastructure out-of-the box. It is fully integrated into our cloud so we have designed it to work seamlessly with our infrastructure and be centrally managed via our management console or API.

If you are looking for information on our hardware firewalls, it can be found here: Hardware Firewalls

GoGrid provides a Firewall Service using a state-of-the-art distributed architecture that was built from the ground-up by our engineering team. Our software defined network architecture means that the Firewall is elastic, highly available, and deeply integrated into our entire cloud infrastructure.


Key Features

  • Self-healing, distributed architecture
  • Available for all GoGrid accounts
  • Easily provisioned using the management console or API
  • Global security groups synchronized across all data centers
  • Define Inbound AND Outbound policies
  • Dynamically edit the connections to the Firewall
  • No policy priority needed. Just enter the ports you want to open

Data Center Availability

The Firewall Service is currently available in our US-West-1, US-East-1, and EU-West-1 data centers.

API

Use API:GoGrid_Basic_Firewall_API_v2 to manage the firewall service.

Recommended Use

The Firewall Service is designed for basic protection against intrusion. You easily create policies and group servers together under security groups.

  • Non-guaranteed bandwidth
  • Cloud servers
  • Unicast setups
  • Any application that requires guaranteed bandwidth or public multicast is not recommended for this product


64-warn.gif
NOTE: Once you associate a connection with a security group, the firewall will block Multicast and Broadcast traffic for the entire VLAN. This action also switches the entire VLAN to routed mode.

Firewall Service

The Firewall Service is designed to be highly available and has a distributed architecture. This setup means that even if one of our nodes goes down, the Firewall Service will continue to service the remaining nodes. Let’s say you have three servers associated with the Firewall Service and one of the nodes on which your servers are running fails. Your server on this node will not be accessible; however, the Firewall will continue to protect the other cloud servers in your security group that are on other nodes. Once the affected infrastructure is brought back up, the Firewall will once again protect those servers automatically. We designed the Firewall Service to have a high default level of security so it blocks all traffic. You'll need to add policies to open up port access through the Firewall Service.

When creating a Firewall, you’ll need to create all the associated objects for it to function correctly. The Firewall is composed of security groups, which you’ll create and name first. You’ll then associate policies and server connections to the security groups.

The relationship of these objects is detailed below.


Firewall relationships.jpg

Notes

  • You are limited to 20 policies per security group. Contact Support if you require more.
  • You are limited to 20 security groups per account. Remember that security groups are global so you don't need to create one per data center. Contact Support if you require more.
  • Policies are specific to a security group
  • You can associate a connection with only one security group. This setup prevents policy overlaps.
  • There is no separate SLA associated with the Firewall Service.

Security Group

The security group is the core of the Firewall Service and is designed so users can easily organize their security policies and servers. First, create and name your security group. Note that it is GLOBAL and not tied to a particular data center. Therefore, if you have a consistent security policy for your web servers, you only need to create one security group and then associate your connections to it regardless of their location.

You can enable or disable your security group. You would do so to diagnose a connection issue or stop that particular security group from protecting its connections. Your other security groups that are enabled will continue to run, but any connections on the disabled security group will no longer be protected by the Firewall. You can also delete a security group, but use caution since it will also delete all associated connections.

You'll be unable to update any security group that you have just edited since the service has to ensure that the changes are in all data centers.


64-warn.gif
NOTE: If you disable your security group, it is the same as not having a firewall!

Default Security Groups

The Firewall Service comes with four default security groups. You can choose to use them or not. You CANNOT delete or edit them but you can clone them as a baseline for creating your own security groups. We provide these as templates for the most common use cases and to save you time from having to open up the most common ports. The four are:


  • Core - This security group blocks all inbound traffic except pings; however, it can communicate with any server within the same security group. You can use this security group to define a pseudo private cloud - for example, if you want to create servers that are used only to distribute files non-interactively or a group of servers that need to communicate with each other on the private interface. It can also serve as a baseline for your own security group because you just need to add the ports you want to open for your specific use case.
    • Accepts any connection from servers in the same security group*
    • Accepts ICMP (ping), Type 0 (Echo Reply), and Type 8 (Echo Request)
    • Blocks all other incoming traffic
    • Accepts all outgoing traffic


  • Block All - This is the most restrictive security group. It blocks all inbound and outbound traffic. You can use this security group to completely lock out servers that might be under attack or are suspected of being compromised and need to be investigated. Since it has no policies, you'll be unable to access servers in this security group through SSH or RDP.
    • Blocks all incoming traffic
    • Blocks all outgoing traffic


  • Linux Web - Use this for Linux based web servers. You can use this security group if you have a Linux-based web server and want to grant HTTP access on port 80 and 433 and administer the server via SSH on port 22.
    • Accepts any connection from servers in the same security group*
    • Accepts ICMP (ping) Type 0 (Echo Reply) and Type 8 (Echo Request)
    • Accepts TCP (HTTP and HTTPS) on ports 80 and 443
    • Accepts TCP (SSH) on port 22
    • Blocks all other incoming traffic
    • Accepts all outgoing traffic


  • Windows Web - Use this for Windows based web servers. You can use this security group if you have a Windows-based web server and want to grant HTTP access on port 80 and 433 and administer the server via RDP on port 3389.
    • Accepts any connection from servers in the same security group*
    • Accepts ICMP (ping) Type 0 (Echo Reply) and Type 8 (Echo Request)
    • Accepts TCP (HTTP and HTTPS) on ports 80 and 443
    • Accepts TCP (RDP) on port 3389
    • Blocks all other incoming traffic
    • Accepts all outgoing traffic


(*) See the definition of Self

Policies

Policies govern the behavior of the Firewall and are associated with a particular security group. Pay attention to what you are entering as a policy, in particular the direction (inbound or outbound) and the port range. By default, the firewall drops all traffic. You'll need to add policies to allow traffic through. Related and Established connections are honored if a TCP / UDP policy exists on the security group. You'll notice that there is no interface specified on the policy. The policies are interface agnostic - the Firewall will know which interface to apply the policies based on the connections attached to the security group.

The order in which you enter policies doesn't matter.

Transport Protocol

The following transport protocols are supported:

  • TCP (HTTP/web traffic)
  • UDP (DNS-type traffic)
  • ICMP (Ping)


For TCP and UDP you'll need to specify the port or port range. You can enter the following values for the port:

  • any (allow on any port)
  • 80 (a specific port number)
  • a port range (e.g. 5000-5020 or 5000:5020)


For ICMP, you will use type instead of port. The type parameter accepts numeric values for the ICMP Type. The most common are:

  • 0 (Echo Reply)
  • 8 (Echo Request)
  • 3 (Destination Unreachable)


All the ICMP types are supported by the Firewall Service (0-40).

In the management console, we provide a drop-down of services. These are simply shortcuts of protocol/port combinations. (e.g., HTTP is TCP on Port 80, DNS is UDP on Port 53, etc.)

Policy Direction

Each policy must contain a direction. There are only three accepted values:


  • Inbound - for traffic traveling TO the connected servers
  • Outbound - for traffic FROM the connected servers
  • Any - applies to both directions


This parameter is very important, since it determines in which direction traffic is allowed to travel. All our default groups (except for Block All) have all outbound protocols and ports open. This setting is intentional since most users want to block inbound traffic and allow outbound traffic. If you clone one of our security groups, you have the flexibility to modify what traffic can travel outbound.


64-warn.gif
NOTE: If you create a new security group and don't specify an outbound policy this means that NO traffic will travel from your servers!

Address

For each policy, you can specify particular IP addresses that the policy applies to. You can enter the following values:


  • 0.0.0.0/0 or Any (any IP address)
  • Self (any server connected to this security group)
  • any server in the specified security group (e.g. Web_sg1)
  • a specific IP address (e.g. 50.145.33.17)
  • a specific subnet (e.g. 50.145.33.1/24)


This setup is used to restrict access to your servers from only particular addresses. For example, you can restrict web traffic to your web servers from only the VIP of your load balancer.


64-warn.gif
NOTE: If the policy direction is set to inbound, then the address refers to the SOURCE address. If the direction is set to outbound, then the address refers to the DESTINATION address. If the direction is set to any, the address applies to both.

The meaning of self

Self is a special value that you can enter in the address field that means the policy will only apply to servers in that security group. If you create a policy that opens up TCP on port 80 and set the address to self, for example, traffic from any other address to port 80 is blocked except for the servers connected to the security group.

Although security groups are global, self refers only to servers in the same data center if you have the following setup:

Security group: Local_only
Connection1: Server A Public (US-West-1)
Connection2: Server B Public (US-West-1)
Connection3: Server C Public (US-East-1)
Portrange: 80
Protocol: TCP
Direction: Inbound
Address: Self

This setup means that Server A and Server B can communicate with each other on port 80. Server C (because it's in another data center) CANNOT communicate with Servers A and B on Port 80. This is distinction is intentional. Although servers in the same data center are communicating on the public interface, they never do so over the Internet. If the servers were to communicate with servers outside the data center, then traffic would have to travel over the Internet.

Example Policy

An example policy would look this this:

Security group: Core2
Name: Allow_web
Portrange: 8080
Protocol: TCP
Direction: Inbound
Address: any

This is a policy that is added as a cloned copy of the Core security group. The Core security group doesn't usually allow inbound traffic on port 8080. This user made a clone of that security group and called it Core2. The user then added this new policy, which allows TCP traffic on port 8080 from ANY address in the Inbound direction for servers in this security group. Because this is an inbound policy, the address is the source address.

Connections (Servers)

Once you've defined the security group and policies, you'll want to add connections. Connections are the servers to which you want the policies to apply. Technically, a connection is the specific interface (public or private) of the server. Let's say you have Server A and Server B, for example. The public IP of Server A is defined as a connection you can associate with a security group. The private IP of Server A will be considered a separate connection.

Although the security group is global, connections are local. Your connections will reside in particular data centers, but the policies in the security group will apply to all the connections in that group. You can only associate a connection that is an active server. As of this release, only cloud servers are supported. If you delete a server, then the connection is also deleted.

You have the ability to associate connections from different data centers into the same security group.


64-warn.gif
NOTE: You can associate a connection with only one security group. This restriction is intentional.


User Manual

See the Firewall Service User Manual for instructions on deploying a firewall.

Getting Help

See our Support page for information on contacting GoGrid for any questions or issues that arise.

Frequently asked Questions

How can I access the Firewall Service?

The GoGrid Firewall Service is accessible via the management console or the API in all our data centers.


Can I load balance my GoGrid servers that are protected by a GoGrid Firewall?

Yes, load balancing can be configured for servers protected by GoGrid's Firewall Service. You can also restrict the Firewall to accept traffic only from your Dynamic Load Balancer.


Can I associate servers in US-East-1, US-West-1 and EU-West-1 to a single security group?

Yes, this is possible. Security groups are global and any GoGrid cloud server can be associated with a security group.


Can I associate Dedicated Servers to the Firewall Service?

Currently, you can only associate cloud servers with the Firewall Service. You'll be able to associate Dedicated Servers in a future release.


Why can I only associate my server with one security group?

One of the most common firewall issues is traffic being blocked because of overlapping policies (which also often causes performance issues). Associating a server with a single security group will simplify setup (because only the policies of that security group will apply to that server) and makes issues easier to diagnose. It also improves performance because traffic doesn't have to travel through a large chain of policies. If you want to apply different policies to the same server, you might be overloading your server. Consider separating its functionality into different servers.


Am I required to use a security group like on Amazon?

No. You are not required to use the Firewall Service but it is highly recommended you protect your infrastructure behind a Firewall for security reasons.


Can I remove a server from a security group or do I need to delete the server first?

Yes. You can remove the connection from the security group dynamically without deleting the server. Remember, doing so means that server is no longer associated with a security group and is vulnerable to external threats.


I opened up port 3389 on the Firewall Service but traffic isn't entering that port on my server. What is going on?

All our base server images have the host firewall enabled. It's possible your host firewall is blocking that port. If you're protecting your server in a security group, you'll want to open that port on your host firewall or disable the host firewall for those servers. Please see the documentation for your particular OS because the process is different for each one.


What if I want to multicast/broadcast traffic?

If you don't associate your private connections with a security group, the VLAN will stay in bridge mode. Therefore you can firewall your public connections and maintain multicast/broadcast with your private traffic.


I need more than 20 security groups!

Please file a ticket with Support to make your request.


But I want to use a dedicate firewall!

We still have those available. See the Firewall Product Page to learn more about our Hardware Firewalls.


Can I have more than one public IP when using the Firewall Service?

When enabled, the Firewall Service switches the VLAN to routed mode which limits the system to recognizing only the assigned IP on a server. If you need servers with more than one IP you will not be able to use this service as this restriction applies to any server on the VLAN where Firewall Service is enabled.


I am trying to add a connection and I see an error that it is not compatible. What's up with that?

You're attempting to add a server that is not compatible with the Firewall Service. You will most likely need to migrate it so please contact Support to help you out.
Personal tools