Setting Virtual Instances in a Cloud Environment using Security Groups

Welcome to our second blog entry dedicated to network security in the cloud. Security is a very big concern when you want to move workloads onto an infrastructure that you would not own (and in turn have less control on). Unfortunately, there are many people who just put the term “security concern” out there very randomly and end up tarnish the concept of cloud computing. Today we will mention two network security methods mainly deployed in the IaaS delivery model but focus on just one of them; I.e. Security Groups.

There are two main network security methods in a virtual private cloud (VPC) network:

1. The gateway or internet gateway – This is the device that allows incoming and outgoing traffic from your VPC network to the internet. This device was usually a firewall and/or router+firewall at the office or datacenter when most of the infrastructure used to be on-premise/owned. These devices used to control NAT, firewall rules, forwarded ports, bandwidth throttling, etc. Many network engineers would exactly relate their jobs to what I am mentioning here. These devices were usually situated at the perimeter of your network in a clustered fashion. With cloud computing and all its technological wonders, that network perimeter still exists.

2. Security Groups – These are basically a set of rules that are grouped together (hence the term “group”) and applied to the virtual network interface cards (NICs) of the instances (For the techies out there think of rules and chains in iptables). Rules in a security group are specifically “ALLOW RULES” as by default a security group with no rules means “ALLOW NOTHING”. Think of security groups as an IP packet filter just before the NIC of the instance. When servers, where setup on-premise the only isolation between servers in the same network, was the firewall software on the actual server since a physical firewall usually sits as the gateway of the network or you would have to set up a DMZ to separate “risky hosts”. With security groups, there is an additional filter just before traffic enters or after it exits a network interface of a cloud instance since it is applied at the hypervisor layer. This flexibility allows each instance to have an additional security layer after the perimeter gateway/firewall in case one of the instances in the VPC is compromised.

The below diagram shows a particular setup with security groups applied to each NIC of each instance. This would allow an additional layer of security in the same IP network which always had to be handled by the firewall tools inside the Operating System.

 

Characteristics of Security Groups

    • Security Groups define packet filter rules to be applied to each NIC of each virtual machine as a network security mechanism by filtering incoming and outgoing network traffic.
    • Security Groups are mainly used to reduce or eliminate the occurrence of unwanted network communications while allowing all legitimate communication to flow freely.
    • They provide an essential layer of security that, combined with other measures, prevent attackers from accessing your Virtual Machines in malicious ways.
    • You can specify allow rules, but not deny rules.
    • You can specify separate rules for inbound and outbound traffic.
    • Security group rules enable you to filter traffic based on protocols, network subnets and port numbers.
    • By default, a security group will block all traffic. You will add an allow rule and specify the protocol, traffic direction, port/s and the target network that will be allowed. A security group can have a number of rules for both inbound and outbound traffic simultaneously.
    • Target networks are to be considered in the context of the rule, if it is an inbound rule, then the target network is the originating network. On the other hand, if it is an outbound rule, then the target network is the destination network
    • A security group can be applied globally to the virtual network or to a NIC of an instance. After you launch an instance, you can change the security groups that are associated with the instance, which changes the security groups associated with that particular interface. You can also specify or change the security groups associated with any other network interface. By default, when you create a network interface, it’s associated with the default security group for the VPC, unless you specify a different security group.
    • For each NIC of each instance, two separate chains are created, Below you can see the two chains for incoming and outgoing traffic (identified by the letter “-i” or “-o” at the end) of an instance that has an allow all for both directions.

      # iptables -S zc-instance-650-0-o

      -N zc-instance-650-0-o
      -A zc-instance-650-0-o -m state --state RELATED,ESTABLISHED -j RETURN
      -A zc-instance-650-0-o -j RETURN
      -A zc-instance-650-0-o -j DROP
      # iptables -S zc-instance-650-0-i
      -N zc-instance-650-0-i
      -A zc-instance-650-0-i -m state --state RELATED,ESTABLISHED -j RETURN
      -A zc-instance-650-0-i -j RETURN
      -A zc-instance-650-0-i -j DROP
    • Security groups are stateful — if you send a request from your instance, the response traffic for that request is allowed to flow in regardless of inbound security group rules. Responses to allowed outbound traffic are allowed to flow in, regardless of inbound rules if there is a state allowing the traffic as seen below. The top chain (-o) has an “allow all” outbound rule while at the same time the chain for incoming traffic (-i) has a state rule which would allow the traffic coming in if there is a state-related to it
      
      # iptables -S zc-instance-651-0-o
      -N zc-instance-651-0-o
      -A zc-instance-651-0-o -m state --state RELATED,ESTABLISHED -j RETURN
      -A zc-instance-651-0-o -j RETURN
      -A zc-instance-651-0-o -j DROP
      # iptables -S zc-instance-651-0-i
      -N zc-instance-651-0-i
      -A zc-instance-651-0-i -m state --state RELATED,ESTABLISHED -j RETURN
      -A zc-instance-651-0-i -j DROP

Zyla Cloud – Security Group Options

You can add or remove rules for a security group. A rule applies either to inbound traffic or outbound traffic.

    • Traffic Direction – The direction traffic moves between networks.
        • Inbound – Inbound traffic refers to information coming-in to a NIC
        • Outbound – Outbound traffic refers to information going-out-of a NIC
    • Protocol – The protocol is the predefined way that someone who wants to use a service, talks with that service.
        • Specific Protocol – TCP, UDP, IMCP, IMCPv6 and IPsec. If you specify ICMP as the protocol, you can specify any or all of the ICMP types and codes.
        • All protocols
    • Port Range – A range of ports that are allowed through.
        • Port Range – A range of ports by entering the starting and ending ports separated by a colon or multiple specific ports separated by a comma, or even a single port
        • Manual Network – Enter a specific subnet to apply the filter to
        • IP – This is the first IP of the consecutive set of IPs. Must be used with Size.
        • Size – The number of total consecutive IPs of the network. Use always with IP.
      • All portsTarget Network – Virtual Network to apply the Security Group rule to.
        • ZylaCloud Virtual Network – Select a predefined virtual network that the tenant has access to.
        • Any Network – This is an allow all IPs option.

       

Creating a Security Group

To create a Security Group, navigate to Network > Security Groups and press the Add button (+) which will open the Security Group creation wizard, and there you can define the rules of the Security Group. An easy way to explain what Security Group rules look like is to show an example. The below is an example Security Group for Linux instances, which allows inbound SSH connections on port 22, allows traffic to port 53 outbound (DNS) using both the TCP and UDP protocols, and last but not least allow port 443 outgoing connections to the update servers (Hopefully none of the servers is still using plain HTTP. The equivalent chain and rules in the KVM host are the below for the inbound and the outbound filters:

# iptables -S zc-instance-651-0-i
-N zc-instance-651-0-i
-A zc-instance-651-0-i -m state --state RELATED,ESTABLISHED -j RETURN
-A zc-instance-651-0-i -p tcp -m multiport --dports 22 -j RETURN
-A zc-instance-651-0-i -j DROP

# iptables -S zc-instance-651-0-o
-N zc-instance-651-0-o
-A zc-instance-651-0-o -m state --state RELATED,ESTABLISHED -j RETURN
-A zc-instance-651-0-o -p tcp -m multiport --dports 53 -j RETURN
-A zc-instance-651-0-o -p udp -m multiport --dports 53 -j RETURN
-A zc-instance-651-0-o -p tcp -m multiport --dports 443 -j RETURN
-A zc-instance-651-0-o -j DROP

 

Security Group Update

Security Groups can be updated to edit or add new rules. These changes are propagated to all the VMs which have the security group applied to them, so it may take some time till the changes are applied. It is important to understand the implications of doing security group updates since the changes might affect the traffic of the instances where the security group is applied.

Using a Security Group

To apply a Security Group to your Virtual Machines, you can assign them to the Virtual Networks by selecting the network and adding the security group. Then from now on any Virtual Machines using that network will have the security group applied to them. To accommodate more complex and highly secure scenarios, you can apply a Security Group to each NIC of each instance

The Default Security Group

There is a special Security Group: default (ID 0). This security group allows all OUTBOUND traffic and all INBOUND traffic on all protocols.

Whenever a new virtual network is created, the default Security Group is added to the network. This means that you MUST edit every newly created network and remove the default Security Group from it. Otherwise, even if you add other Security Groups to limit the traffic, once the traffic matches the default Security Group, it will allow all traffic and therefore override the rest of the Security Groups.