Using security groups

What are Security Groups?

Security groups (aka secgroups) are the Research Cloud’s primary inbuilt security controls for filtering network traffic. Security groups have a default deny behaviour. So without security group rules applied through assignment of a security group, there will be no external access to your instance/s. Security groups apply to both inbound (ingress) and outbound (egress) network traffic to and from your instance/s. You can find an example of how to add a security group on the Nectar Cloud Tutorial site, on a basic level, as well as an intermediate one.

Defaults

When you create a new security group two rules (one each for IPv6 and IPv4 traffic) are automatically added as a convenience to allow outbound access from your instance to the Internet. Return traffic related to any outbound connections made from your instance/s (e.g. from a host you initiated a connection with) will also be allowed by default, but unlike egress traffic this default behaviour is not explicitly represented by any security group rules.

Security Group Rules

Security groups are made up of security group rules which define network access control lists (ACLs). Security group rules are expressed as tuples of: direction, protocol, port (or port range), and remote host IP address (or IP address range). The host IP addresses in security group rules are defined with CIDR notation. Thus security group rules allow access to certain network services running in your instance/s from particular hosts or groups of hosts on the Internet. Additionally, the remote host can be designated by a source group, which is a special dynamic security group including all instances with that source group assigned. Source groups are useful for defining access relationships between groups of servers in a project without knowing their IP addresses ahead of time.

Which hosts to allow access from?

The Information Security Principle of Least Privilege says we should only allow/open access to necessary services/ports from hosts required to fulfill the normal function of the system and no more.

Access from anywhere - 0.0.0.0/0

In some cases it might be entirely reasonable to allow access to a particular service (and associated port/s) from the whole Internet, e.g., when running a public website. Making such collaboration use-cases simpler is one of the reasons the Nectar Research Cloud exists. To allow public access to a web-server you may have security group rules like:

+--------------------------------------+-------------+-----------+------------+-----------------------+
| ID                                   | IP Protocol | IP Range  | Port Range | Remote Security Group |
+--------------------------------------+-------------+-----------+------------+-----------------------+
| 923ae6fa-e247-4df2-ab5a-7718b6238c7c | tcp         | 0.0.0.0/0 | 80:80      |                       |
| d613f183-50fa-41d8-a042-72325bec73fd | tcp         | 0.0.0.0/0 | 443:443    |                       |
+--------------------------------------+-------------+-----------+------------+-----------------------+

These two rules allow TCP traffic from any host (0.0.0.0/0) to ports 80 and 443, the standard HTTP and HTTPS service ports.

Using the 0.0.0.0/0 remote host IP address range can be convenient when you do not know where users of a particular service may be accessing it from, however you should be cogniscant that you are allowing access from the entire Internet. In doing so you are taking on a responsibility (refer to the Research Cloud terms and conditions) to keep the instance/s in question free from security vulnerabilities that could be exploited by nefarious users or groups. You should be aware that such exposure, coupled with a simple configuration error, could lead to:

• compromise of your instance/s
• unwitting disclosure of private data
• open denial-of-service attack vectors against your instance/s or reflected from your instance/s to other 3rd party targets

In general you should only use 0.0.0.0/0 for services that must be Internet accessible for normal function and almost never across all ports (1:65535), i.e., do not use rules like:

+--------------------------------------+-------------+-----------+------------+-----------------------+
| ID                                   | IP Protocol | IP Range  | Port Range | Remote Security Group |
+--------------------------------------+-------------+-----------+------------+-----------------------+
| cea25c28-4929-4a96-b92d-ab57eb01dcc0 | tcp         | 0.0.0.0/0 | 1:65535    |                       |
+--------------------------------------+-------------+-----------+------------+-----------------------+

The only reasonable scenario to use such a rule is where you have deployed well-managed instance-internal firewall controls (e.g. iptables, ufw). You should be particularly circumspect about opening remote access or management methods (e.g. SSH[1], RDP, telnet, WS-MAN, FTP) to the Internet. A good alternative is to only open these services to your home organisation’s network and use their VPN to access your Nectar cloud instance/s.

Access from specific networks and/or organisations

Making your remote host ranges more specific and restrictive can be a difficult prospect as even if you can narrow down access to a particular organisation, e.g., Monash University, the IP address ranges belonging to hosts on that organisation’s network may not be readily apparent. Fortunately coarse-grained information about organisational networks is public domain knowledge - it is vital information for the operation of the Internet and in particular the Border Gateway Protocol (BGP).

AARNet (Australian Academic and Research Network) is the primary Internet Service Provider (ISP) for the Australian research sector (including all Nodes of the Research Cloud). Many relevant remote host ranges can be found by searching the BGP information of AARNet and its peers. A good online source for this information is the Hurricane Electric BGP Toolkit. Here we can find network prefix details (in CIDR format as required for defining security group rules) for ranges that AARNet manages (e.g. Intersect, ACU, RMIT) and peers with (e.g. Monash, Melbourne, UQ). You can browse these lists and find the supernet ranges for relevant organisations (e.g. for Monash University see AS56132 prefixes) or use the search function to find information on a specific organisation (note that you may need to expand common abbreviations). If possible it would be preferable to ask the relevant organisational IT support for these details as they will be able to provide more specific ranges, but the BGP prefix data is a good starting point.

Note that whilst limiting the scope of access is a major factor in improving the security of your instances it is not the be-all and end-all. You should be aware that large organisations (particularly universities) have a variety of systems and levels of trust inside their networks, e.g., a subnet containing staff servers would be considered cleaner than the student wireless subnet. So you should not rely solely on security groups as the only access control for any particular service.

Best practice for defining security groups

The following recommendations may help you apply the Principle of Least Privilege to your Research Cloud instances:

• Avoid security group rules allowing access from the entire Internet (0.0.0.0/0) unless this is actually required
• If access from the entire Internet (0.0.0.0/0) is required do not open all ports (1-65535) - if you don’t know which ports are required for a particular service please contact the Nectar Helpdesk for support
• Use source groups to allow trusted access between related instances
• Use your institutional VPN or specific host IP addresses/ranges (e.g. your home network or desktop) for remote management access

Footnotes

[1] Note that the risk of exposing SSH has been minimised for all Nectar Official images by configuring the SSH server to only allow login via cryptographic keys and running brute-force detection and banning software.

[2] https://support.ehelp.edu.au/solution/articles/6000055376-launching-virtual-machines#SecurityGroup