One of the key aspects of operating any application, whether on-premises or in the cloud, is network security. This is well understood in AWS, and there is a whole range of security services and devices that can provide us with the required security mechanisms to keep our application protected on the network. This chapter will walk you through all you need to know about securing VPCs. You will learn about the security components and how and when to use them in the best possible manner.
The following topics will be covered in this chapter:
When dealing with network security, we should always strive to implement as many security mechanisms as our application design and budget will support. Think of network security as an onion – the more layers the onion has, the more work there will be to get to the middle of it. The same idea applies to providing network security. VPC Network Security.
The more security devices we implement, the harder it will be for malicious traffic to reach our application. We should be thinking about network security at all the layers of our application. We need to be careful, especially when it comes to identifying our entry points and protecting each of them with the appropriate security measures. The following diagram breaks down the attack vectors according to Verisign. The diagram represents the security breaches that were successful in 2018 and network security only accounts for about one fifth of the attacks leading to a breach:
We should treat network security as our first line of defense when it comes to stopping attacks from external sources. However, attacks that can be prevented with good network security devices range in type and severity, and are roughly broken down into the following categories:
There are several types of network layer attacks, including but not limited to the following:
AWS inherently prevents IP spoofing and port scanning within EC2 networks. Any attempt at spoofing an IP or scanning ports within an EC2 environment is treated as a violation of the AWS terms, and any system attempting to perform either of those will be automatically and immediately blocked from any further access.
AWS provides a set of guidelines on how to protect an application against DoS and DDoS attacks and allows for the ease of management of the security features that help to achieve this with AWS Shield and AWS WAF. We will discuss this in more detail in the Delivering advanced network security in AWS section of this chapter. We can also use WAF to prevent injection attacks and session hijacking, and we can use the AWS Shield service to help us mitigate DoS and DDoS attacks. We will discuss these two services in the Delivering advanced network security in AWS section of this chapter.
Service layer attacks are designed to attack a service that an application relies on to function correctly. One of the most frequently used attacks is DNS and domain hijacking. An attacker will try to intercept DNS traffic by taking over a domain and/or inject incorrect DNS information into a compromised application. The requests from the application will be sent to the attacker's DNS instead of the legitimate DNS service. We can prevent these attacks from happening by using the AWS Route 53 service.
There are several types of vulnerability attacks that can be executed over the network:
Application layer attacks come in the highest variety and severity, and include but are not limited to the following:
We can easily detect brute-force attacks with a monitoring solution such as CloudWatch, which can provide an alert when a certain user has reached a certain threshold of invalid logins over a certain period of time.
To protect from session hijacking, we could use encryption. Since the traffic is encrypted, it will make it very difficult for an attacker to perform a session hijack. We can also implement mechanisms that allow you to check network packets on several layers. This helps our application determine whether the packet has been altered, thus indicating an interception and a possible attempt to hijack the session.
AWS WAF can be used to prevent injection attacks, but the wisest way to protect your application is to secure it at the application layer.
Possibly the most difficult attack to detect and protect from the network layer would be account hijacking. Phishing or inadvertent credential disclosures can lead to an attack that is hard to detect. An attacker can easily fool any automated system and pretend to be a legitimate user while trying to gain deeper access or transferring confidential data from our application. The recommended way to protect from account hijacking is to use multi-factor authentication (MFA). AWS has built-in MFA for AWS accounts and IAM users. We should always make sure that any developers building any type of publicly accessible application understand the need for MFA. Building MFA capability into the application level will raise the security of any application accounts dramatically.
Network security spans several layers in the OSI model. The following diagram gives us a breakdown of the different attack vectors and the representation of the percentage of attacks that succeeded in compromising an application in 2018:
As we can see, more than half of all attacks are represented by network layer attacks. These are spread out over multiple layers of the OSI model. Network attacks are most commonly layer 3 and layer 4 attacks, and they usually do the following:
The other half is shared by the other two types of attacks, which are intended to attack the application itself or the services that support the application being available on the internet:
In this section, we will look at all the relevant layers of the OSI model where our services typically reside and look at the approaches to security on these layers.
Traditionally, layer 2 security is the first level of defense we have from rogue devices within our on-premise local area network. In the cloud, this would be replaced by AWS Config. AWS Config allows us to detect any changes (creation of instances and network interfaces) that could be connected to the VPC. An alert can be sent out that would act in the same fashion as an alert from a network switch that detected a device connection. AWS Config can also be integrated with Lambda, and in cases where strict compliance is required, Lambda can automatically detach and isolate these unauthorized resources so that an incident response team can investigate.
The next layer of security would be on layer 3, which should secure all IP communication. Layer 3 spans all our subnets and all of the internet. Essentially, when we talk about layer 3 protection, we are talking about stateless firewalls. These work in a way that allows everyone to connect from the get-go and then once bad actors on the network are detected, the IP addresses or ranges of these actors are blocked. Layer 3 firewalling can also help with specific network isolation requirements that need to be implemented due to compliance reasons. For example, we would only want a certain IP address range to communicate with another specific IP address range.
This can be simply implemented with layer 3 stateless rules. Stateless firewalls also seamlessly operate without any performance or latency impact on the packet flows. The Network Access Control Lists (NACLs) in the VPC take the form of stateless layer 3 firewalls. Layer 3 firewalls are great at stopping the volumetric attacks from the internet once the source has been identified by stopping the attacker at the perimeter of the network. Layer 3 firewalls can also stop some network layer attacks but not all, as the traffic source and destination sometimes isn't enough to identify whether the traffic is legitimate or not.
To prevent more sophisticated network attacks, we need to allow firewalling at the transport layer. Layer 4 firewalls can get some insight into the types of packets being sent and can prevent any kind of malformed packets being dropped at the perimeter where the firewall operates. Layer 4 firewalls also have the ability to aintain session state and, therefore, much easier to manage since once we open the incoming port, the return response will be allowed, no matter what port the return comes from. In AWS security groups, the operating system firewall, AWS Shield, and AWS WAF all play a role in stopping layer 4 attacks and provide a multi layered approach to network security.
With applications becoming more sophisticated every day, we also need to start thinking about more sophisticated ways to protect our applications. At the application layer, we need a device that understands the application and the type of traffic that will be flowing to and from the application. Application firewalling is perhaps the most difficult and wideranging subject, and there are numerous ways to approach it. AWS offers WAF, which can help with securing web applications, but there are also other third-party solutions for different application types and for centralized security that's been designed by mainstream firewall vendors and is available from the AWS Marketplace.
As you can see, network security has many different aspects to take into consideration. When designing network security for our application, we need to consider any and all connection points of our application and think about which types of communication protocols we will be using. We should then map these protocols to the OSI network layers to discover the vulnerabilities we might be introducing. Finally, once we have categorized our potential weaknesses, we need to implement appropriate security solutions for each and every layer. In the following sections, we will take a look at how to design our AWS services with security in mind and how to implement security for our application at all the relevant OSI layers.
One of the more important aspects of computing is network security. The features of the VPC allow us to put all the basic checks in place to ensure that only the services that we want to expose are reachable. The VPC introduces two network security mechanisms:
The primary layer of defense for our instances is the security group. When creating new instances, we will always need to assign a security group to the EC2 instance's primary network adapter or any other ENI that we connect to the instance. The security group acts like a personal stateful firewall protecting each ENI with the security group rules that we assign to it. The security group has stateful port filtering capabilities and allows both the traffic coming into a certain port defined in a rule as well as any return traffic.
For example, a typical modern Linux-based web server would require access to the SSH console on port 22 and to HTTP/HTTPS on ports 80 and 443. To allow access to this server, we would simply create one or more security groups with the appropriate rules that would allow access on ports 22, 80, and 443. We would then assign the security group(s) to the instance, thus allowing access.
For the source, we can specify either IP ranges or other security groups. Specifying security groups is good practice as it allows much easier management as they will be dynamically applied to any instance that has the security group assigned, no matter what subnet the instance is started on.
If we needed to scale the application to multiple instances, we would simply assign the same security groups to them, and the services running on those instances would become accessible on the ports defined in the policy within the group.
Since all inbound ports are implicitly denied by default, all other ports would not be accessible. All outgoing traffic is allowed by the security group by default.
Another best practice is to specify security groups in the incoming rules of other security groups. The security groups are designed as follows:
A: Allows access from the internet to the public IP of the ELB. B: Allows access from only the load balancer security group to the web service security group. C: Allows access from the web service security group to the database service security group:
However, there are some limitations in regards to security groups. An ENI of an instance can be a member of only five security groups. We can have multiple ENIs attached to the instance (the maximum depends on the instance type). If we require more than five security groups to be assigned to an instance, we can open a request on AWS support to raise this limit to up to 16. This will not affect the maximum number of security group rules as that is always set at 300, no matter how many security groups we are attaching to an ENI.
One of the primary goals in meeting the SLA is the ability to maintain the desired availability of the application. Network security is a crucial factor in maintaining availability as there are many forms of attack that can bring down even the most secure publicly available application. These attacks can be directed either at our application or are designed to disrupt the services our application is depending on.
As we have already mentioned, the ability to protect our application at each and every entry point is crucial. Additionally, we should be implementing security herever possible. We have already discussed the layers of protection that come with the VPC and within the operating system of the EC2 instance, but today's attackers are very sophisticated and will try and disrupt our service in a way that will mimic real-life traffic and try to overwhelm our application, bringing it to its knees.
AWS outlines several aspects of how to be prepared and mitigate DDoS attacks:
Scaling: The ability to scale our application is crucial. Within AWS, we have all the necessary tools to withstand anything the attacker might throw at us. Though it may be expensive to mitigate an attack through scaling, it is one of the features that will allow us to survive an attack and maintain the SLA.
Minimizing the attack surface: We need to make sure that any unnecessary or unused entry points to the application are removed. We also need to identify all the possible mitigation strategies for any entry points that are crucial for the operation of our application and implement them.
Identify traffic patterns: We need to make sure that we understand the typical traffic pattern of our application. We also need to maintain watch over the traffic pattern and identify any anomalies. This can be automated through CloudWatch alarms in AWS.
Resiliency: Finally, building our application in a manner where it will be resilient to attacks is also a crucial approach to reducing the impact a DDoS attack will have on our application.
To mitigate DDoS attacks and to make sure that our application is secure, we can use two different services in AWS:
WAF is a service that's provided by AWS, which lets you monitor and filter traffic that's intended for the following destinations:
WAF allows us to specify conditions like IP addresses or strings in the HTTP request, upon which we can control access to our content. With WAF, we are able to control the intricate details of each request and are able to achieve the following:
WAF can be implemented at the edge location when protecting the API Gateway or a CloudFront distribution. This gives us the ability to filter the traffic at the edge location, as shown in the following diagram:
The WAF service can also be implemented as a scalable solution with the so-called WAF sandwich approach, where an ELB is put in front of a WAF or a group of WAF evices that can be scaled according to the incoming traffic. The WAF devices send the filtered traffic through to the second ELB that sits in front of our web instances. The naming comes from the WAF being sandwiched between two ELBs, as shown in the following diagram:
AWS Shield is a DDoS protection service. It allows for automatic detection and mitigation of common DDoS scenarios. AWS Shield comes with the following two options:
AWS Shield Standard: It provides protection at no additional cost when using CloudFront and Route 53. The service provides protection from layer 3 and 4 DDoS attacks.
AWS Shield Advanced: In addition to the features of the standard version, it allows for the protection of EC2 instances and ELBs. On top of the layer 3 and 4 DDoS mitigation, it also provides higher level attack mitigation and near realtime visibility to the traffic. AWS Shield Advanced also allows for integration with AWS WAF to deliver a complete all-in-one mitigation strategy for protecting any kind of web application.
Refer to the following references to learn more about what was covered in this chapter: