Security Groups, Firewalls, ELBs and additional layers of security

Also read AWS NACLs versus Security Groups and Service Accounts as an intelligent firewall option on GCP

Private Clouds, Virtual Private Clouds and such were introduced as a security measure – for companies that weren’t sure about having their apps/data out on a ‘public’ cloud.

So – you build yourself a Virtual Private Cloud – and isolate yourself from the public cloud – and all it’s evils. However,  you might still expose part of your VPC to the internet – otherwise, what will you do with your public facing apps?

The typical workaround for this is to only partition a part (a SUBNET ) of your VPC into a PUBLIC facing subnet. This means that IP addresses on that subnet will be routable from the internet. Everything else (all other subnets in your VPC) will still be private.

So – for these public facing apps, the same security questions apply – are my apps/data safe from hackers on the internet ?

The answer is – you would secure these applications much the same way you would in a non-cloud environment (by adding firewalls, Intrusion Protection etc.). However, while all of these non-cloud products have cloud service equivalents, the cloud does provide you with some out-of-the-box services to make this task easier.

Security Groups (Very basic firewalls)

The first thing to realize about security groups is – they are insecure.  They are a VERY minimal layer of protection – restricting IP addresses (and ports) – but doing nothing more besides that. This means – if you have your internal subnet protected by JUST a security group –  anyone who gets to a machine on the EXTERNAL subnet – can hack into your internal subnet. Very easily – since that machine’s IP is trusted by the internal subnet – and there is no other protection in place.

This is where a full-blown firewall is needed.

Firewalls in the Cloud (Firewall as a Service, Firewall Appliances)

For network level security , one could use an appliance such as a Cisco ASAv (virtual ASA).

Cisco ASA is an industrial strength firewall appliance – that is used for an enterprise wide firewall.   Cisco offers their firewall as a service – known as Virtual ASA. Virtual ASA has all the capabilities of the hardware ASA.

While it excels at network level security, to protect against application level attacks (SQL Injection etc), you have two options:

1. Custom configure (using regex match patterns) against each type of sql injection (and other) attacks. This can be difficult to maintain.
2. IPS – use an Intrusion Prevention System in conjunction with the virtual ASA  – these are already configured to block the most common type of attacks. Moreover, they are updated constantly by the vendor (e.g. Cisco) with new vulnerability blocking capabilities.

To summarize, a virtual appliance (such as Cisco’s ASAv)  provides great NETWORK level security  – but needs a helping hand to provide application level security. This can be in the form of an IPS (Intrusion Prevention System).

Sophos (and its ability to be scripted into an ASG)

Sophos offers protection against both – network level and Application level attacks. It inspects all incoming traffic – and raises alerts if it detects any malicious looking traffic.

One of the reasons Sophos is popular is that it can be spun up via a script – and hence can be placed in an ASG.

Web Application Firewall (from AWS)

WAF is a generic term used to describe an Intrusion Protection System that protects against Application Attacks. Amazon also has its own ‘Firewall as a Service’ – known as WAF (Web Application Firewall). While it is able to provide protection against common application attacks, it too has its drawbacks.

Currently, it only works if you are also using an AWS service called CloudFront. It inspects traffic that is forwarded from cloudfront – and without cloudfront, it is not able to do its thing. Hopefully, AWS will change this in future releases.

AWS WAF works by allowing you to define a set of rules, called a web access control list (web ACL). Each rule in the list contains a set of conditions and an action. Requests received by CloudFront are handed over to AWS WAF for inspection. Individual rules are checked in order. If the request matches the conditions specified in a rule, the indicated action is taken; if not, the default action of the web ACL is taken. Actions can allow the request to be serviced, block the request, or simply count the request for later analysis. Conditions offer a range of options to match traffic based on patterns, such as the source IP address, SQL injection attempts, size of the request, or strings of text. These constructs offer a wide range of capabilities to filter unwanted traffic.

Elastic Load Balancer (ELBs) and SSLs

While these are primarily meant to load balance your application traffic, they do provide a basic layer of ‘blocking and redirecting’ traffic to application servers.

Typically – a firewall will surround the ELB along with the multiple nodes that it serves. An ELB will act more at an instance (or multiple instances) level.

A security certificate can be applied to the ELB – adding a layer of data (in transit) encryption.

Summary

In contrast to enterprise security, the cloud offers a few more options (such as security groups and ELBs) – that are are not easily available in the enterprise solutions space.  At the same time, Enterprise firewalls etc. all have their cloud equivalents – known as Virtual firewalls (e.g.virtual ASA from CISCO).

When comparing virtual firewall offerings, one important thing to keep in mind is its ‘compatibility’ with the cloud. For e.g. – can the product be placed in an Auto Scaling Group (i.e. does it provide a scriptable, configurable automated method of creation)?

This limits a lot of the virtual firewall offerings – since not all of them support automated methods of installation and configuration.