Just like any network on the Internet, your guest networks in the cloud can also be vulnerable to attacks. These attacks can come in many forms via undesirable traffic, such as intrusion or denial of service attacks. To protect your guest networks from such attacks CloudStack employs powerful security means, of which firewall is the first line of defense. Firewall services prevent network attacks by limiting access to your cloud. In CloudStack, Juniper SRX and CloudStack virtual router provide robust firewall services. To support this functionality, as a CloudStack administrator, you will need to create certain firewall rules to control access to the instances in the network. A firewall has two traffic directions—inbound and outbound, based on which you create rules. Today we are going to discuss the one for outbound—Egress Firewall Rules.

What is Egress Traffic?

The egress traffic is outbound packets of data that originates from a private network to a public network, such as the Internet.

What is Egress Firewall Rules?

Firewall rules represent sets of procedures that govern the accessibility of a running instance in your cloud. Although most of us think that firewalls safeguard the guest network from incoming traffic, they can also prevent traffic from leaving your network—egress firewall rules precisely do that—continuously monitor and ensure that unauthorized packet of data never leaves the guest network. Finally, they determine what outside resources your users can have access to. In CloudStack, data packets that are being sent out of the guest network are examined via virtual router or an external firewall device, such as Juniper SRX. Packets that do not meet security policies are not allowed to leave—they are denied egress.

Why Should I Use Egress Firewalls?

Your users entrust their valuable data to your cloud service. Given the sensitivity of the data, some of the largest concerns include leaking out private address space and compromised systems attempting to communicate with remote hosts. By implementing egress rules, you restrict your users from getting off of the guest network and going anywhere they would like. You can create a rule that essentially says that let so and so internal network transmit so and so information patterns out to the public network. In CloudStack, it is that information from a guest network with certain protocol or port number or within a certain CIDR to the Internet that is controlled. Egress firewall rules can also help prevent information leaks due to misconfiguration and stops internal systems from performing outbound IP spoofing attacks.

How Do You Implement Egress Firewall Rules in CloudStack?

In CloudStack, Egress firewall rules are supported in advanced zones. By default egress traffic is blocked, so the traffic originating from a trusted network (guest network) out to the Internet is restricted. To allow certain traffic to the public network, you can create egress firewall rules. You can set firewall rules to allow specific traffic, and the remaining traffic is blocked. When all the rules are removed, the default policy, blocked, is applied. (Read the Administration Guide to know the details.) Using the egress firewall rules, traffic can be allowed based on the following parameters: guest network CIDR, protocol, and destination port range.

Allow Network: Guest Network CIDR

This rule will allow all traffic and any known Internet connectivity from a specific network sources, which could include any applications running on your cloud. When you specify CIDR, data is sent only from the IP addresses within the specified address block. For example: 192.168.0.0/22. To allow all CIDRs, set to 0.0.0.0/0.

Allow Service: TCP/UDP/ICMP/All Protocols

This rule will allow the egress traffic with destination protocol TCP/UDP/ICMP/ALL. The data packets are inspected at the network perimeter for L4 protocol headers.

TCP/UDP: Typically your application protocols use TCP, UDP, or both, depending on the design of the protocol. For example: SMTP, FTP, and HTTPS. An application server typically listens on one or more fixed TCP or UDP ports. Some applications use a single port, but many applications use multiple ports. For example, although SMTP uses TCP port 25 for sending mail, it uses TCP port 587 for mail submission.

UDP: UDP on port 53 is primarily used by DNS to serve requests. UDP is also used for P2P, VOIP, and some messengers.

ICMP: Attackers can use various ICMP types and codes to manipulate the flow of network traffic. To prevent malicious activity, firewalls at the network perimeter should deny all incoming and outgoing ICMP traffic except for those types and codes specifically permitted by your tenant’s organization. However, ICMP is useful in many cases: For example, ICMP type 3 messages should not be filtered because they are used for important network diagnostics. The ping command (ICMP code 8) is an important network diagnostic, but incoming pings should be blocked to prevent attackers from learning more about the internal topology of the organization’s network. Note that there are specific ICMP type/codes you may wish to consider blocking:

• ICMP Echo-Replies (type 0 code 0): This is usually an indication of someone running the Ping utility. Echo-Replies have been used to covertly communicate with compromised systems. • ICMP Host Unreachable (type 3 code 1): Block all the unreachable hosts so that savvy attackers do not find available hosts in the network. • ICMP Time Exceeded in Transit (type 11 code 0).

Allow Service: Range of Ports for Protocols

This rule allows traffic to be sent to a given range of ports. You can specify a range of listening ports that are the destination of the outgoing traffic. If you are opening a single port, use the same number in both fields. If you don’t specify the port range for the protocol (TCP/UDP) all the traffic is allowed. Here is a very short list of ports and the service that uses them:

TCP 21- FTP
TCP 22 – SSH
TCP 80 – HTTP
TCP 443 – HTTPS
TCP 3389 – RDP (Remote Desktop Protocol—remote access for Windows systems)

Allow All

An important step is to create a rule that allows all the egress traffic. When you do not want any traffic to be blocked from the guest network, add the egress rule with protocol ALL so that all the egress traffic is allowed to the public network. This is a way of disabling egress firewall.

Further Reading

Hope this write-up has helped you get started with egress rules in CloudStack. For further reading, I would suggest the following:

https://cwiki.apache.org/CLOUDSTACK/egress-firewall-rules-for-guest-network.html

https://cwiki.apache.org/CLOUDSTACK/egress-firewall-rules-feature-support-for-external-device-juniper-srx.html

http://en.wikipedia.org/wiki/Egress_filtering

http://www.juniper.net/techpubs/en_US/release-independent/junos/information-products/pathway-pages/hardware/SRX5800/index.html

http://jenkins.cloudstack.org/job/docs-4.1-adminguide/lastSuccessfulBuild/artifact/Apache_CloudStack-4.1.0-Admin_Guide-en-US.pdf