Chapter 4: Securing Networking Services
In Chapter 2, Securing Compute Services, and Chapter 3, Securing Storage Services, we covered securing compute and storage services, respectively.
Now, it's time to talk about securing networking services. We'll discuss virtual networking services, Domain Name System (DNS) services, content delivery networks (CDNs), virtual private networks (VPNs), distributed denial of service (DDoS) protection services, and web application firewalls (WAFs).
This chapter will cover various networking services and provide you with the best practices on how to securely connect to and use each of them.
In this chapter, we will cover the following topics:
- Securing virtual networking
- Securing DNS services
- Securing CDN services
- Securing VPN services
- Securing DDoS protection services
- Securing WAF services
Technical requirements
For this chapter, the reader needs to have a fundamental understanding of networking services, such as virtual private cloud (VPC)/VNET services and security groups (or access control lists (ACLs)), and a solid understanding of VPN, DDoS protection, and WAF services.
Securing virtual networking
Each cloud provider has its own implementation of virtual networking.
According to the shared responsibility model, responsibility for the network is split between the cloud provider and the customer. The physical network layer (that is, access between the physical network equipment and physical host servers and storage inside the cloud provider's data centers) is the cloud provider's responsibility.
Virtual networking (such as Amazon VPC, Azure VNet, or Google Cloud Platform (GCP) VPC) is a network layer that is the responsibility of the customers (this layer enables access between virtual servers, managed storage services, managed databases, and more).
Traditional on-premises networking deals with the physical connections between devices in a system: for example, concepts such as virtual local area networks (VLANs) or subnetting, to split a network (with the devices connected to a network) and create network security barriers.
In the cloud, a network is software-based (this is also known as software-defined networking (SDN)). In the cloud, you have micro-segmentation, which means you can configure allow and deny access control rules between two instances (even if they are located on the same subnet). You will also be able to audit and control access to a resource such as an API.
A virtual network is a network area inside your cloud environment where most of the common cloud resources reside (such as virtual servers, managed databases, and so on). These resources are split into multiple network segments called subnets.
There can be one or more virtual networks in each customer's cloud environment, but at the end of the day, the basic idea is the same. Following are some important points regarding virtual networks:
- Access to subnets is controlled by access controls (such as Layer 4 firewalls).
- Subnets can be private (no direct access from the internet) or public (access from the internet is allowed).
- If you need to allow access to the internet for private subnet resources, you need to configure a NAT gateway.
- Virtual networks can be connected with each other via peer connections.
Since each cloud provider has its own network access control mechanism, the following table compares the differences between access control mechanisms:
Table 4.1 – Access control mechanisms
Next, we are going to see what the best practices are for securing virtual networking services from Amazon, Azure, and GCP.
Securing Amazon Virtual Private Cloud
Amazon Virtual Private Cloud (Amazon VPC) is the Amazon virtual networking service.
Best practices for securing network access to Amazon VPC
AWS supports the following mechanisms to protect access to resources inside a VPC:
- Network ACLs: A stateless mechanism for protecting access to/from resources at a subnet level. You need to configure both inbound and outbound rules. Network ACLs support both allow and deny rules.
- Security groups: A stateful mechanism for protecting access to resources at an instance level. You need to configure inbound rules. Security groups support only allow rules.
- Network access to a resource is granted by a combination of the network ACLs on a subnet level with an aggregation of all the security groups, effective on a resource such as a virtual machine (in case several security groups allow different access to a resource such as a virtual machine).
Here are some best practices for securing network access to Amazon VPC:
- When creating custom network ACLs, create a final deny rule for both inbound and outbound traffic for better protection.
- Create subnets according to the resource's function (for example, public subnets for web servers, private subnets for database servers, and so on).
- For remote access protocols (SSH/RDP), limit the source IP address (or Classless Inter-Domain Routing (CIDR)) to well-known sources.
- For file sharing protocols (CIFS/SMB/FTP), limit the source IP address (or CIDR) to well-known sources.
- Use security groups to control access between public resources (such as load balancers or publicly facing web servers) and private resources (such as databases) and limit the access to the minimum required ports/protocols.
- Set names and descriptions for security groups to allow a better understanding of any security group's purpose.
- Use tagging (also known as labeling) for security groups to allow a better understanding of which security groups belong to which AWS resources.
- For large-scale environments with multiple AWS accounts, use AWS Firewall Manager to centrally create and enforce VPC security groups.
- For secure access from resources inside your VPC to AWS Managed Services (such as AWS S3, Amazon RDS and more), and to keep traffic inside the AWS backbone, use AWS PrivateLink, and configure your VPC security groups to allow traffic from your VPC to AWS managed services.
- To allow outbound access from internal resources inside private subnets to destinations on the internet (based on the IPv4 protocol), use NAT gateways or any self-hosted NAT proxy.
- To allow outbound access from internal resources inside private subnets to destinations on the internet (based on the IPv6 protocol), use an egress-only internet gateway.
For more information, please refer to the following resources:
Network ACLs:
https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html
Security groups for your VPC:
https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html
AWS Firewall Manager:
https://aws.amazon.com/firewall-manager/
Interface VPC endpoints (AWS PrivateLink):
https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-interface.html
NAT gateways:
https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html
Egress-only internet gateways:
https://docs.aws.amazon.com/vpc/latest/userguide/egress-only-internet-gateway.html
Best practices for monitoring Amazon VPC
AWS allows you to monitor Amazon VPC using the following built-in services:
- Amazon CloudWatch: This is a service that allows you to monitor your VPC components (such as ingress/egress traffic volumes).
- VPC Flow Logs: This is a service that allows you to log network activity inside your VPC (for example, traffic metadata such as source, destination, port, timestamp, size, and allow and deny network events). This is useful for both troubleshooting and investigating security-related events.
Here are some best practices for monitoring Amazon VPC:
- Enable CloudWatch Logs to monitor your VPC components' activity and the traffic between your VPC resources and the VPC endpoint (AWS managed services).
- Use AWS CloudTrail to monitor VPC configuration.
- Enable VPC Flow Logs to log and further analyze allowed and denied traffic activity. Combined with Amazon GuardDuty, you will be able to detect anomalous network behavior, such as interaction with command and control (C&C) networks, malicious IP addresses, and more.
Note
For large-scale production environments, enable VPC Flow Logs only for short periods of time, for troubleshooting purposes only (due to high storage cost and large amounts of data generated by VPC Flow Logs).
- Use AWS Config or AWS Security Hub to detect inbound access to resources inside your VPC via unencrypted protocols (such as HTTP instead of HTTPS, or LDAP instead of LDAPS).
- In case you need to troubleshoot network issues by capturing network traffic without interrupting production systems, use Traffic Mirroring in Amazon VPC to copy live network traffic from a network interface of an Amazon Elastic Compute Cloud (EC2) instance, or from a network load balancer to an out-of-band security appliance.
For more information, please refer to the following resources:
Using CloudWatch Logs with interface VPC endpoints:
https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch-logs-and-interface-VPC.html
Log and monitor your VPC:
https://docs.aws.amazon.com/vpc/latest/userguide/logging-monitoring.html
VPC Flow Logs:
https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html
What is Traffic Mirroring:
https://docs.aws.amazon.com/vpc/latest/mirroring/what-is-traffic-mirroring.html
Summary
In this section, we have learned how to secure the Amazon VPC network environment by relying on the AWS infrastructure and using everything from network ACLs for inbound and outbound traffic to monitoring and capturing network traffic.
Securing Azure VNet
Azure Virtual Network (Azure VNet) is the Azure virtual networking service.
Best practices for securing network access to Azure VNet
To protect resources inside a VNet, Azure supports network security groups (NSGs) – a stateless mechanism for protecting access to resources, at a virtual machine, subnet, or tagging level. You need to configure both inbound and outbound rules for VNet NSGs.
Here are some best practices to follow:
- Create subnets according to the resource function (for example, public subnets for web servers, private subnets for database servers, and so on).
- For remote access protocols (SSH/RDP), limit the source IP address (or CIDR) to well-known sources.
- For file sharing protocols (CIFS/SMB/FTP), limit the source IP address (or CIDR) to well-known sources.
- Use NSGs to control access between public resources (such as load balancer or publicly facing web servers) and private resources (such as databases) and limit the access to the minimum required ports/protocols.
- Set names and descriptions for NSGs to allow a better understanding of any NSG's purpose.
- Use tagging (also known as labeling) for NSGs to allow a better understanding of which network security groups belong to which Azure resources.
- Use application security groups to define access rules at the application layer (for example, rules for allowing inbound HTTP access).
- Use service tags to configure rules for pre-defined service (for example, Azure Load Balancer), instead of using IP addresses.
- To allow outbound access from internal resources inside private subnets to destinations on the internet, use Azure Virtual Network NAT (or use a NAT gateway).
- For large-scale environments with multiple Azure subscriptions, use Azure Firewall to centrally create, enforce, and log network policies across multiple subscriptions.
For more information, please refer to the following resources:
Azure Virtual Network concepts and best practices:
https://docs.microsoft.com/en-us/azure/virtual-network/concepts-and-best-practices
Network security groups:
https://docs.microsoft.com/en-us/azure/virtual-network/network-security-groups-overview
Application security groups:
https://docs.microsoft.com/en-us/azure/virtual-network/application-security-groups
Virtual network service tags:
https://docs.microsoft.com/en-us/azure/virtual-network/service-tags-overview
What is Virtual Network NAT:
https://docs.microsoft.com/en-us/azure/virtual-network/nat-overview
What is Azure Firewall:
https://docs.microsoft.com/en-us/azure/firewall/overview
Best practices for monitoring Azure VNet
Azure allows you to monitor network activity using Azure Network Watcher – a service for capturing NSG Flow Logs.
Here are some best practices for monitoring Azure VNet:
- Enable Azure Network Watcher NSG Flow Logs to log and further analyze allowed and denied traffic activity.
Note
For large-scale production environments, enable NSG Flow Logs only for short periods of time, for troubleshooting purposes only (due to high storage cost and large amounts of data generated by NSG Flow Logs).
- If you need to troubleshoot network issues by capturing network traffic, use the Azure Network Watcher packet capture extension to copy live network traffic from a virtual machine to an Azure storage account.
Note
For large-scale production environments, enable the Network Watcher packet capture extension only for short periods of time, for troubleshooting purposes only (due to the performance impact on the target VM).
- For large-scale environments, use Azure Traffic Analytics to locate security threats (such as open ports, application outbound internet traffic, and so on).
- Use Azure Policy to detect inbound access to resources inside your VNet via unencrypted protocols (such as HTTP instead of HTTPS, or LDAP instead of LDAPS).
For more information, please refer to the following resources:
Log network traffic to and from a virtual machine using the Azure portal:
https://docs.microsoft.com/en-us/azure/network-watcher/network-watcher-nsg-flow-logging-portal
Introduction to flow logging for network security groups:
https://docs.microsoft.com/en-us/azure/network-watcher/network-watcher-nsg-flow-logging-overview
What is Azure Network Watcher:
https://docs.microsoft.com/en-us/azure/network-watcher/network-watcher-monitoring-overview
Manage packet captures with Azure Network Watcher using the portal:
https://docs.microsoft.com/en-us/azure/network-watcher/network-watcher-packet-capture-manage-portal
Traffic Analytics:
https://docs.microsoft.com/en-us/azure/network-watcher/traffic-analytics
Summary
In this section, we have learned how to secure the Azure VNet environment by relying on the Azure infrastructure and using everything from access control lists for inbound and outbound traffic to monitoring and capturing network traffic.
Securing Google Cloud VPC
Google Cloud VPC is the Google virtual networking service.
Best practices for securing network access to Google Cloud VPC
To protect resources inside a VPC, Google supports VPC firewall rules – a stateful mechanism for protecting access to resources. You need to configure either inbound and outbound rules, and for each rule, you can configure either an action of allow or deny.
Here are some best practices for securing network access to Google Cloud VPC:
- Create subnets according to the resource function (for example, public subnets for web servers, private subnets for database servers, and so on).
- For remote access protocols (SSH/RDP), limit the source IP address (or CIDR) to well-known sources.
- For file sharing protocols (CIFS/SMB/FTP), limit the source IP address (or CIDR) to well-known sources.
- Use VPC firewall rules to control access between public resources (such as load balancers or publicly facing web servers) and private resources (such as databases) and limit the access to the minimum required ports/protocols.
- Set names and descriptions for VPC firewall rules to allow a better understanding of any firewall rule's purpose.
- Use tagging (also known as labeling) for VPC firewall rules to allow a better understanding of which VPC firewall rule belongs to which VPC resources.
- Use network tags to configure rules to groups of resources (such as a group of compute engine instances) instead of using IP addresses.
- To allow outbound access from internal resources inside private subnets to destinations on the internet, use a Cloud NAT gateway.
- For large-scale environments with multiple Google Cloud VPC projects, use VPC Service Controls to enforce access restrictions over your VPC resources, based on the identity of the IP address.
For more information, please refer to the following resources:
- VPC firewall rules overview:
https://cloud.google.com/vpc/docs/firewalls
- Using firewall rules:
https://cloud.google.com/vpc/docs/using-firewalls
- Configuring network tags:
https://cloud.google.com/vpc/docs/add-remove-network-tags
- NAT overview:
https://cloud.google.com/nat/docs/overview
- Overview of VPC Service Controls:
https://cloud.google.com/vpc-service-controls/docs/overview
Best practices for monitoring Google Cloud VPC
Google allows you to monitor Google Cloud VPC using the following built-in services:
- Google Cloud Logging: This is a service that allows you to monitor your VPC components.
- VPC Flow Logs: This is a service that allows you to log network activity inside your VPC (for example, allow and deny network events).
Here are some best practices for monitoring Google Cloud VPC:
- Enable VPC audit logs to monitor your VPC components' activity and the traffic between your VPC resources.
- Note that admin activity audit logs are enabled by default and cannot be disabled.
- Explicitly enable data access audit logs to log activities in your Google Cloud VPC.
- Limit access to audit logs to the minimum number of employees (to avoid unwanted changes to the audit logs).
- Enable Firewall Rules Logging to audit the functionality of your VPC firewall rules.
- Enable VPC Flow Logs to log and further analyze allowed and denied traffic activity.
Note
For large-scale production environments, enable VPC Flow Logs only for short periods of time, for troubleshooting purposes only (due to the high storage cost and large amounts of data generated by VPC Flow Logs).
- In case you need to troubleshoot network issues by capturing network traffic, use Packet Mirroring to copy live network traffic from a compute engine VM instance to an instance group behind an internal load balancer.
Note
For large-scale production environments, enable Packet Mirroring only for short periods of time, for troubleshooting purposes only (due to high performance impact on the target VM).
For more information, please refer to the following resources:
Firewall Rules Logging overview:
https://cloud.google.com/vpc/docs/firewall-rules-logging
VPC Flow Logs overview:
https://cloud.google.com/vpc/docs/flow-logs
Using VPC Flow Logs:
https://cloud.google.com/vpc/docs/using-flow-logs
VPC audit logging information:
https://cloud.google.com/vpc/docs/audit-logging
Packet Mirroring overview:
https://cloud.google.com/vpc/docs/packet-mirroring
Summary
In this section, we have learned how to secure Google Cloud VPC by relying on the Google Cloud VPC infrastructure and using everything from VPC firewall rules for inbound and outbound traffic to monitoring and capturing network traffic.
Securing DNS services
Each cloud provider has its own implementation of managed DNS services – these include services for translating hostnames into IP addresses, different types of DNS records services (such as Alias, CNAME, and more), resolving hostname to load-balance IP, and more.
Securing Amazon Route 53
Amazon Route 53 is the Amazon managed DNS service.
Best practices for securing Amazon Route 53
The following are some of the best practices to follow:
- Create an Identity and Access Management (IAM) group, add users to the group, and grant the required permissions on the Route 53 service for the target group.
- Enable Domain Name System Security Extensions (DNSSEC signing) on any public-hosted zone to protect against DNS spoofing attacks.
- Use a new customer master key (CMK) to sign any newly created public-hosted zone.
- Make sure privacy protection is enabled for any domain you manage using Route 53 to protect the privacy of domain owners' contact information.
- Enable the Route 53 domain transfer lock to prevent your domains from being transferred to another registrar.
- Create a sender policy framework (SPF) record on your Route 53 hosted domain to publicly specify which mail servers are authorized to send emails on behalf of your email domain.
- Use the Route 53 Resolver DNS Firewall to block DNS-level threats originating from your VPC.
- Remove unassigned DNS records from your hosted zones (records of resources such as IP addresses that connected to a resource that was removed).
- Use private hosted zones to manage DNS records for internal resources (such as resources located inside private subnets).
- Enable public DNS query logging to be able to analyze which public DNS queries were submitted to Route 53 about your domains.
- Enable Resolver query logging to be able to analyze information such as the Route 53 Resolver DNS Firewall block rules.
- Enable Amazon GuardDuty to analyze DNS logs and raise alerts about suspicious activity, such as C&C activity, Bitcoin mining, and more.
For more information, please refer to the following resources:
Security in Amazon Route 53:
https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/security.html
Overview of managing access permissions to your Amazon Route 53 resources:
https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/access-control-overview.html
Configuring DNSSEC for a domain:
https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/domain-configure-dnssec.html
Enabling or disabling privacy protection for contact information for a domain:
https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/domain-privacy-protection.html
Locking a domain to prevent unauthorized transfer to another registrar:
https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/domain-lock.html
SPF record type:
https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/ResourceRecordTypes.html#SPFFormat
How Route 53 Resolver DNS Firewall works:
https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall-overview.html
Working with private hosted zones:
https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/hosted-zones-private.html
Summary
In this section, we have learned how to secure Amazon Route 53 by relying on the AWS infrastructure and using access controls, DNS record protection, threat detection for DNS-related activities, and more.
Securing Azure DNS
Azure DNS is the Azure managed DNS service.
Best practices for securing Azure DNS:
The following are some of the best practices to follow:
- Grant minimal permissions for accessing and managing the Azure DNS using Azure role-based access controls (RBACs).
- Remove unassigned DNS records from your hosted zones (records of resources such as IP addresses that connected to a resource that was removed).
- Enable the ReadOnly lock for any hosted zone you manage using Azure DNS to protect from accidental changes to DNS records.
- Use private DNS zones to manage DNS records for internal resources (such as resources located inside private subnets).
- Use Azure Defender for DNS to detect and send alerts about suspicious DNS-related activities.
- Enable DNS logging and forward the logs to Azure Sentinel to detect suspicious behavior on the Azure DNS service.
For more information, please refer to the following resources:
Azure security baseline for Azure DNS:
https://docs.microsoft.com/en-us/security/benchmark/azure/baselines/dns-security-baseline
How to protect DNS zones and records:
https://docs.microsoft.com/en-us/azure/dns/dns-protect-zones-recordsets#resource-locks
How to protect private DNS zones and records:
https://docs.microsoft.com/en-us/azure/dns/dns-protect-private-zones-recordsets
Introduction to Azure Defender for DNS:
https://docs.microsoft.com/en-us/azure/security-center/defender-for-dns-introduction
Summary
In this section, we have learned how to secure Azure DNS by relying on the Azure infrastructure and using access controls, DNS record protection, threat detection for DNS-related activities, and more.
Securing Google Cloud DNS
Google Cloud DNS is the Google managed DNS service.
Best practices for securing Google Cloud DNS
The following are some of the best practices to follow:
- Create an IAM group, add users to the group, and grant the required permissions on the Google Cloud DNS service for the target group.
- Enable DNSSEC signing on any public-hosted zone to protect against DNS spoofing attacks.
- Remove unassigned DNS records from your hosted zones (records of resources such as IP addresses that connected to a resource that was removed).
- Use Google Cloud DNS private zones to manage DNS records for internal resources (such as resources located inside private subnets).
- Enable Google Cloud DNS audit logs to monitor DNS activity.
- Note that admin activity audit logs are enabled by default and cannot be disabled.
- Explicitly enable data access audit logs to log activities in Google Cloud DNS.
- Limit access to audit logs to the minimum number of employees to avoid unwanted changes to the audit logs.
For more information, please refer to the following resources:
Cloud DNS overview:
https://cloud.google.com/dns/docs/overview
DNS best practices:
https://cloud.google.com/dns/docs/best-practices
Managing DNSSEC configuration:
https://cloud.google.com/dns/docs/dnssec-config
DNS Security Extensions (DNSSEC) overview:
https://cloud.google.com/dns/docs/dnssec
Cloud DNS audit logging information:
https://cloud.google.com/dns/docs/audit-logging
Logging and monitoring:
https://cloud.google.com/dns/docs/monitoring
Summary
In this section, we have learned how to secure Google Cloud DNS by relying on the Google Cloud infrastructure and using access controls, DNS record protection and more.
Securing CDN services
Each cloud provider has its own implementation of a CDN service – that is, a service for distributing content closer to the customer throughout the entire world.
A CDN caches content (such as images, videos, or static web pages) in multiple locations around the world, allowing customers to receive the content quickly from a location close to the customer.
CDNs also serve as an extra defense mechanism against DDoS attacks by being one of the first services that serves a customer's request, even before the request reaches the servers or applications.
Securing Amazon CloudFront
Amazon CloudFront is the AWS managed CDN service.
Best practices for securing Amazon CloudFront
The following are some of the best practices to follow:
- Restrict access to origin servers (where your original content is stored) from CDN segments only (allow traffic only from the CDN segments towards servers or services that store content).
- Share content via the HTTPS protocol to preserve the confidentiality of the content and to assure the authenticity of the content.
- When distributing content over HTTPS, use TLS 1.2 over older protocols, such as SSL v3.
- If you have a requirement to distribute private content, use CloudFront signed URLs.
- If you have a requirement to distribute sensitive content, use field-level encryption as an extra protection layer.
- Use AWS Web Application Firewall (WAF) to protect content on Amazon CloudFront from application-layer attacks (such as detecting and blocking bot traffic, OWASP Top 10 application attacks, and more).
- Enable CloudFront standard logs for audit logging purposes. Store the logs in a dedicated Amazon S3 bucket, with strict access controls, to avoid log tampering.
For more information, please refer to the following resources:
Using HTTPS with CloudFront:
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-https.html
Configuring secure access and restricting access to content:
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/SecurityAndPrivateContent.html
Serving private content with signed URLs and signed cookies:
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/PrivateContent.html
Using AWS WAF to control access to your content:
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-awswaf.html
Using field-level encryption to help protect sensitive data:
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/field-level-encryption.html
Configuring and using standard logs (access logs):
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/AccessLogs.html
Logging and monitoring in Amazon CloudFront:
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/logging-and-monitoring.html
Summary
In this section, we have learned how to secure Amazon CloudFront by relying on the AWS infrastructure and using secure transport protocols (such as TLS), protection for private or sensitive content, logging, and protection from application-layer attacks.
Securing Azure CDN
Azure Content Delivery Network (CDN) is the Azure managed CDN service.
Best practices for securing Azure CDN
The following are some of the best practices to follow:
- Restrict access to origin servers (where your original content is stored) from CDN segments only (allow traffic only from the CDN segments towards servers or services that store content).
- Prefer sharing content via the HTTPS protocol to preserve the confidentiality of the content and to ensure the authenticity of the content.
- When distributing content over HTTPS, prefer using TLS 1.2 over older protocols such as SSL v3.
- Enable Azure CDN logs for audit logging purposes. Forward the logs to Azure Security Center for further investigation.
- Forward Azure CDN logs to Azure Sentinel (the Azure managed SIEM service) for threat detection.
For more information, please refer to the following resource:
Azure security baseline for Content Delivery Network:
Summary
In this section, we have learned how to secure Azure CDN by relying on the Azure infrastructure and using secure transport protocols, logging, threat detection, and more.
Securing Google Cloud CDN
Google Cloud CDN is the Google managed CDN service.
Best practices for securing Google Cloud CDN
The following are some of the best practices to follow:
- Restrict access to origin servers (where your original content is stored) from CDN segments only (allow traffic only from CDN segments towards servers or services that store content).
- Share content via HTTPS protocol to preserve the confidentiality of the content and to assure the authenticity of the content.
- When distributing content over HTTPS, use TLS 1.2 over older protocols such as SSL v3.
- If you have a requirement to distribute content such as individual files for a short period of time, use signed URLs.
- Enable Google Cloud CDN audit logs to monitor CDN activity.
- Note that admin activity audit logs are enabled by default and cannot be disabled.
- Explicitly enable data access audit logs to log activities in Google Cloud CDN.
- Limit access to audit logs to the minimum number of employees to avoid unwanted changes to the audit logs.
For more information, please refer to the following resources:
Cloud CDN features:
https://cloud.google.com/cdn/docs/features
Signed URLs and signed cookies overview:
https://cloud.google.com/cdn/docs/private-content
Cloud CDN audit logging information:
https://cloud.google.com/cdn/docs/audit-logging
Logging and monitoring
https://cloud.google.com/cdn/docs/logging
Summary
In this section, we have learned how to secure Google Cloud CDN by relying on the Google Cloud CDN infrastructure and using secure transport protocols, logging, and more.
Securing VPN services
Each cloud provider has its own implementation of a VPN service. VPNs allow network-based access to private resources over untrusted networks.
Following are some of the common VPN services concepts:
- Combined with a firewall, a VPN allows organizations to access and manage their internal resources (both sides of the VPN tunnel) in a secure manner.
- A VPN allows corporate users to connect to their organization's cloud environment from either the corporate network or from home.
- The connection between the VPN and the cloud environment is encrypted.
- The connection to the cloud environment is transparent (that is, the same as working locally from the corporate network).
- The VPN can enforce the use of multi-factor authentication (MFA) for end users connecting using a client VPN.
In this section, we will review how site-to-site VPN services and client VPN services can allow connectivity to your cloud environment.
Securing AWS Site-to-Site VPN
AWS Site-to-Site VPN is a managed service that allows you to connect your corporate network to the AWS environment in a secure IPsec channel.
Best practices for securing AWS Site-to-Site VPN
The following are some of the best practices to follow:
- Restrict access to AWS resources inside your AWS environment using Amazon VPC security groups and authorization rules.
- For non-sensitive environments, use pre-shared keys to authenticate to the site-to-site VPN tunnel.
- For highly sensitive environments, use a private certificate from the AWS Certificate Manager (ACM) Private Certificate Authority (CA) service.
- Create an IAM group, add users to the group, and grant the required permissions on the AWS Site-to-Site VPN connection for the target group an example of an IAM role would be the ability to invoke an API action through the VPN).
- It is recommended to schedule a maintenance window and rotate the pre-shared keys or the certificate for the AWS Site-to-Site VPN connection once a year, to avoid potential compromise.
- Use Amazon CloudWatch to monitor the VPN tunnels (for example, it could send an alarm when the amount of traffic in bytes is above a pre-defined threshold).
- Use AWS CloudTrail to monitor users' activity on the AWS VPN service.
For more information, please refer to the following resources:
Site-to-Site VPN tunnel authentication options:
https://docs.aws.amazon.com/vpn/latest/s2svpn/vpn-tunnel-authentication-options.html
Identity and access management for AWS Site-to-Site VPN:
https://docs.aws.amazon.com/vpn/latest/s2svpn/vpn-authentication-access-control.html
Replacing compromised credentials:
https://docs.aws.amazon.com/vpn/latest/s2svpn/CompromisedCredentials.html
Logging and monitoring:
https://docs.aws.amazon.com/vpn/latest/s2svpn/logging-monitoring.html
Monitoring your Site-to-Site VPN connection:
https://docs.aws.amazon.com/vpn/latest/s2svpn/monitoring-overview-vpn.html
Securing AWS Client VPN
AWS Client VPN allows you to connect to the AWS environment from anywhere on the internet using an OpenVPN client in a secure TLS channel.
Best practices for securing AWS Client VPN
The following are some of the best practices to follow:
- Restrict access to AWS resources inside your AWS environment using VPC security groups and authorization rules.
- If you are managing your user identities with AWS Directory Service, use AWS Client VPN Active Directory authentication.
- If you are using the SAML 2.0 federated authentication service, use AWS Client VPN single sign-on authentication (SAML authentication).
- For highly sensitive environments, use AWS Client VPN certificate-based authentication using the ACM service.
- If you are using AWS Client VPN certificate-based authentication, use client certificate revocation lists to revoke access to employees who have left the organization or do not need access through the VPN.
- Use Amazon CloudWatch to monitor the VPN tunnels (for example, it could send an alarm when the amount of traffic in bytes is above a pre-defined threshold).
- Use AWS CloudTrail to monitor users' activity on the AWS VPN service.
For more information, please refer to the following resources:
Restrict access to your network:
https://docs.aws.amazon.com/vpn/latest/clientvpn-admin/scenario-restrict.html
AWS Client VPN authentication:
https://docs.aws.amazon.com/vpn/latest/clientvpn-admin/client-authentication.html
Client certificate revocation lists:
https://docs.aws.amazon.com/vpn/latest/clientvpn-admin/cvpn-working-certificates.html
Authorization rules:
https://docs.aws.amazon.com/vpn/latest/clientvpn-admin/cvpn-working-rules.html
Logging and monitoring:
https://docs.aws.amazon.com/vpn/latest/clientvpn-admin/logging-monitoring.html
Monitoring Client VPN:
https://docs.aws.amazon.com/vpn/latest/clientvpn-admin/monitoring-overview.html
Summary
In this section, we have learned how to secure the AWS VPN services (both site-to-site and client-based) by relying on the AWS infrastructure and using network access controls, authentication mechanisms, logging, and more.
Securing Azure VPN Gateway (Site-to-Site)
Azure VPN Gateway (Site-to-Site) is a managed service that allows you to connect your corporate network to the Azure environment in a secure channel.
Best practices for securing Azure VPN Gateway (Site-to-Site)
The following are some of the best practices to follow:
- Restrict access to Azure resources inside your Azure environment using NSGs.
- Use the GCMAES256 algorithm for both encryption of the IPsec tunnel and ensuring the integrity of the traffic passing through the tunnel.
- Use pre-shared keys to authenticate to the site-to-site VPN tunnel.
- For large-scale environments with multiple Azure subscriptions and multiple site-to-site VPN gateways, use Azure Firewall to centrally create, enforce, and log network policies across multiple subscriptions.
- Use Azure Monitor to monitor the VPN tunnels (for example, it could send alerts when the amount of traffic in bytes is above a pre-defined threshold).
- Enable Azure DDoS Protection to protect your VPN gateway from DDoS attacks.
For more information, please refer to the following resources:
Azure security baseline for VPN Gateway:
https://docs.microsoft.com/en-us/security/benchmark/azure/baselines/vpn-gateway-security-baseline
About cryptographic requirements and Azure VPN gateways:
https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-compliance-crypto
Tutorial: Create a Site-to-Site connection in the Azure portal:
https://docs.microsoft.com/en-us/azure/vpn-gateway/tutorial-site-to-site-portal
Monitoring VPN Gateway:
https://docs.microsoft.com/en-us/azure/vpn-gateway/monitor-vpn-gateway
Securing Azure VPN Gateway (Point-to-Site)
Azure VPN Gateway (Point-to-Site) allows you to connect from anywhere on the internet to the Azure environment in a secure channel using an OpenVPN client, Secure Socket Tunneling Protocol (SSTP), or Internet Key Exchange version 2 (IKEv2) VPN client.
Best practices for securing Azure VPN Gateway (Point-to-Site)
The following are some of the best practices to follow:
- If you are managing your user identities inside Azure Active Directory, use Azure Active Directory to authenticate users to the VPN gateway, combined with Azure RBACs to provide minimal access to resources on your Azure environment.
- If you are authenticating users through Azure Active Directory, enforce MFA for your end users.
- For highly sensitive environments, use certificates to authenticate to the point-to-site VPN tunnel.
- Restrict access to Azure resources inside your Azure environment using NSGs.
- Use the GCMAES256 algorithm for both encryption of the IPSec tunnel and ensuring the integrity of the traffic passing through the tunnel.
- Use Azure Monitor to monitor the VPN tunnels (for example, it could send alerts when the amount of traffic in bytes is above a pre-defined threshold) and to log audit-related events (an example of suspicious behavior could be a user attempting to log in in the middle of the night for the first time).
- Enable Azure DDoS Protection to protect your VPN gateway from DDoS attacks.
- Use Azure Advanced Threat Protection to identify anomalous behavior of users connecting through the point-to-site VPN tunnel.
- Use Azure Security Center to detect security-related events through the VPN gateway.
For more information, please refer to the following resources:
Azure security baseline for VPN Gateway:
https://docs.microsoft.com/en-us/security/benchmark/azure/baselines/vpn-gateway-security-baseline
About cryptographic requirements and Azure VPN gateways:
https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-compliance-crypto
About Point-to-Site VPN:
https://docs.microsoft.com/en-us/azure/vpn-gateway/point-to-site-about
Configure a Point-to-Site VPN connection using Azure certificate authentication: Azure portal:
Enable Azure AD Multi-Factor Authentication (MFA) for VPN users:
https://docs.microsoft.com/en-us/azure/vpn-gateway/openvpn-azure-ad-mfa
Monitoring VPN Gateway:
https://docs.microsoft.com/en-us/azure/vpn-gateway/monitor-vpn-gateway
Summary
In this section, we have learned how to secure the Azure VPN services (both site-to-site and client-based VPN) by relying on the Azure infrastructure and using network access controls, authentication mechanisms, logging, and more.
Securing Google Cloud VPN
Google Cloud VPN is a managed service that allows you to connect your corporate network to the GCP environment in a secure channel (using an IPSec tunnel).
Best practices for securing Google Cloud VPN
The following are some of the best practices to follow:
- Restrict access to GCP resources inside your Google Cloud VPC using VPC firewall rules.
- Use the AES-GCM-16-256 algorithm for both encryption of the IPSec tunnel and ensuring the integrity of the traffic passing through the tunnel.
- Use a strong, 32-character, pre-shared key to authenticate to the Google Cloud VPN tunnel.
- Create an IAM group, add users to the group, and grant the required permissions on the Google Cloud VPN connection for the target group.
- Use Google Cloud Logging to monitor activity on the Google Cloud VPN service.
For more information, please refer to the following resources:
Cloud VPN overview:
https://cloud.google.com/network-connectivity/docs/vpn/concepts/overview
Generating a strong pre-shared key:
https://cloud.google.com/network-connectivity/docs/vpn/how-to/generating-pre-shared-key
Supported IKE ciphers:
https://cloud.google.com/network-connectivity/docs/vpn/concepts/supported-ike-ciphers
Configuring firewall rules:
https://cloud.google.com/network-connectivity/docs/vpn/how-to/configuring-firewall-rules
Best practices for Cloud VPN:
https://cloud.google.com/network-connectivity/docs/vpn/concepts/best-practices
Viewing logs and metrics:
https://cloud.google.com/network-connectivity/docs/vpn/how-to/viewing-logs-metrics
Summary
In this section, we have learned how to secure Google Cloud VPN by relying on the GCP infrastructure and using network access controls, authentication mechanisms, logging, and more.
Securing DDoS protection services
Each cloud provider has its own implementation of a managed DDoS protection service.
Because cloud providers have very large bandwidth, they can offer (as a paid service) mechanisms to protect customers' environments from DDoS attacks.
The following services help to mitigate DDoS attacks:
- DDoS protection services (discussed in this section)
- Auto-scaling groups combined with load-balancing services
- CDN services (discussed earlier in this chapter)
- WAF services (discussed later in this chapter)
In this section, we will focus on DDoS protection services.
Securing AWS Shield
AWS Shield is the Amazon managed DDoS protection service.
It comes in two price models:
- AWS Shield Standard: This is the default and free Layer 7 DDoS protection (HTTP/HTTPS), provided for all customers.
- AWS Shield Advanced: This offers Layers 3/4 (Network layer) and Layer 7 (Application layer) DDoS protection, with additional protection for AWS services such as DNS (Route 53), CDN (CloudFront), Elastic Load Balancing (ELB), and virtual machine (EC2) services. This price tier also offers support from the AWS DDoS response team.
Best practices for securing AWS Shield
The following are some of the best practices to follow:
- Use AWS Shield Standard for any web-based production environment you expose to the internet.
- Use AWS Shield Advanced for large-scale production environments you expose to the internet for better insights into the attacks.
- When using AWS Shield Advanced, register an Elastic IP (EIP) address as a protected source to allow quicker detection of attacks.
- When using AWS Shield Advanced, you can generate near real-time reports about attacks on resources in your AWS account(s).
- When combining AWS Shield and the AWS WAF service, use Amazon CloudWatch to monitor incoming requests and alert you when there is a spike in incoming requests, to have preliminary alerts on incoming DDoS attacks.
- Use AWS Identity and Access Management (IAM) to limit the permissions to the AWS Shield Console.
- Use AWS CloudTrail to log actions in the AWS Shield Console.
For more information, please refer to the following resources:
How AWS Shield works:
https://docs.aws.amazon.com/waf/latest/developerguide/ddos-overview.html
Best practices for DDoS resiliency:
https://d0.awsstatic.com/whitepapers/Security/DDoS_White_Paper.pdf
Reviewing DDoS events:
https://docs.aws.amazon.com/waf/latest/developerguide/using-ddos-reports.html
Overview of managing access permissions to your AWS Shield resources:
https://docs.aws.amazon.com/waf/latest/developerguide/shd-access-control-overview.html
Logging and monitoring in Shield:
https://docs.aws.amazon.com/waf/latest/developerguide/shd-incident-response.html
Monitoring tools:
https://docs.aws.amazon.com/waf/latest/developerguide/monitoring_automated_manual.html
AWS Shield Standard:
https://aws.amazon.com/shield/features/#AWS_Shield_Standard
AWS Shield Advanced:
https://aws.amazon.com/shield/features/#AWS_Shield_Advanced
Amazon says it mitigated the largest DDoS attack ever recorded:
Securing Azure DDoS Protection
Azure DDoS Protection is the Azure managed DDoS protection service.
It comes in two price models:
- Azure DDoS Protection Basic: This provides Layers 3/4 (Network layer) and Layer 7 DDoS protection (HTTP/HTTPS), offered at no cost.
- Azure DDoS Protection Standard: This provides Layers 3/4 (Network layer) and Layer 7 DDoS protection (HTTP/HTTPS), with additional protection at the VNet level, with extra logging and alerting capability.
Best practices for securing Azure DDoS Protection
The following are some of the best practices to follow:
- Enable Azure DDoS Protection Basic for any production environment you expose to the internet.
- Use Azure DDoS Protection Standard for large-scale production environments you expose to the internet for better insights into attacks.
- When using Azure DDoS Protection Standard, enable resource logs for public IP addresses to have quicker detection of attacks.
- When combining Azure Application Gateway with a WAF, you add protection against web application attacks.
- Use Azure Monitor to monitor and alert you when there is a spike in incoming requests to have a preliminary alert on incoming DoS attacks.
- Send Azure DDoS Protection logs to Azure Sentinel for further analysis of DDoS attacks.
- Use Azure Active Directory to limit the permissions to the Azure DDoS Protection Console.
- When using Azure DDoS Protection Standard, you can conduct simulations of DDoS attacks against your Azure staging or production Azure environments (at non-peak hours) by using a third-party solution from BreakingPoint Cloud. Simulations will allow you to have a better understanding of how effective the DDoS Protection plans are and help to train your teams.
For more information, please refer to the following resources:
Azure DDoS Protection Standard overview:
https://docs.microsoft.com/en-us/azure/ddos-protection/ddos-protection-overview
View and configure DDoS protection alerts:
https://docs.microsoft.com/en-us/azure/ddos-protection/alerts
View and configure DDoS diagnostic logging:
Azure DDoS Protection Standard features:
https://docs.microsoft.com/en-us/azure/ddos-protection/ddos-protection-standard-features
Azure security baseline for Azure DDoS Protection Standard:
Test through simulations:
https://docs.microsoft.com/en-us/azure/ddos-protection/test-through-simulations
Securing Google Cloud Armor
Google Cloud Armor is the Google managed DDoS protection and Web Application Firewall (WAF) service.
It comes in two price models:
- Google Cloud Armor Standard: This provides protection against volumetric DDoS attacks and includes preconfigured WAF rules.
- Managed Protection Plus: This provides protection against volumetric DDoS attacks, includes preconfigured WAF rules, and includes an adaptive protection mechanism. This price tier also offers support from the Google DDoS response team.
Cloud Armor protects applications located behind an external Google Cloud load balancer, which is based on HTTP/HTTPS and TCP/SSL proxy load balancers.
Best practices for securing Google Cloud Armor
The following are some of the best practices to follow:
- Create an IAM group, add users to the group, and grant the required permissions on the Cloud Armor for the target group.
- Note that Cloud Armor contains pre-configured protection rules against common web application attacks.
- If you need to configure your own rules to match your application, create custom Cloud Armor security policies to allow or deny traffic to your applications behind an external Google Cloud load balancer.
- Enable Cloud Armor logs for any backend service to detect allowed or denied HTTP/HTTPS requests.
- For critical production applications, it is recommended to subscribe to the Managed Protection Plus service.
- For critical production applications, it is recommended to enable the Cloud Armor Adaptive Protection Mechanism to detect anomalous activity and generate a custom signature for blocking application attacks using WAF rules (for application attacks).
- For scenarios where you would like to allow access to your production applications for third-party partners without them having to specify their external IP address or IP range, use Cloud Armor named IP address lists to configure a whitelist of allowed sources.
- Use the Google Security Command Center service to detect anomalous behavior in the Cloud Armor traffic activity (such as spikes in traffic).
For more information, please refer to the following resources:
Configuring Google Cloud Armor security policies:
https://cloud.google.com/armor/docs/configure-security-policies
Google Cloud Armor Managed Protection overview:
https://cloud.google.com/armor/docs/managed-protection-overview
Google Cloud Armor Adaptive Protection overview:
https://cloud.google.com/armor/docs/adaptive-protection-overview
Google Cloud Armor named IP address lists:
https://cloud.google.com/armor/docs/armor-named-ip
New WAF capabilities in Cloud Armor for on-prem and cloud workloads:
https://cloud.google.com/blog/products/identity-security/new-waf-capabilities-in-cloud-armor
Monitoring Google Cloud Armor security policies:
https://cloud.google.com/armor/docs/monitoring
Security Command Center findings:
https://cloud.google.com/armor/docs/cscc-findings
Summary
In this section, we have learned about the DDoS protection services from AWS, Azure, and Google. We also discussed their pricing models and the advanced reporting and alerting capabilities provided by the more advanced DDoS protection services.
Securing WAF services
Each cloud provider has its own implementation of a WAF service – that is, an application-layer firewall with capabilities to detect and mitigate common HTTP/HTTPS-based attacks against your publicly exposed web applications.
Securing AWS WAF
AWS WAF is the AWS managed web application firewall service.
AWS WAF offers protection against the following types of attacks:
- Layer 7 DDoS attacks (when combined with AWS Shield)
- Common web application attacks
- Bots (non-human generated traffic)
AWS WAF also allows you to protect the following Amazon services:
- Amazon CloudFront: The Amazon managed CDN service
- Amazon API Gateway: The Amazon managed API gateway service
- Amazon ALB: The Amazon managed Application Load Balancer service (Layer 7 load balancer)
Best practices for securing AWS WAF
The following are some of the best practices to follow:
- To protect an external web resource, create web ACLs, with either allow or block actions.
- When creating a new web ACL rule, change the default CloudWatch metric name to an informative name that will allow you to detect it later when reviewing the CloudWatch logs.
- Use Amazon CloudWatch to monitor your web ACL rule activity.
- For protection against non-standard types of web application attacks, create your own custom rules.
- For better protection, subscribe to the rules available on the AWS Marketplace (created by security vendors).
- For large-scale environments with multiple AWS accounts, use AWS Firewall Manager to centrally create and enforce WAF rules.
- Send AWS WAF logs to the Amazon Kinesis Data Firehose service to review near real-time logs of attacks.
- Use AWS Config to enable logging for every newly created web ACL.
- Use AWS IAM to limit the permissions to the AWS WAF Console.
- Use AWS CloudTrail to log actions in the AWS WAF Console.
For more information, please refer to the following resources:
Guidelines for Implementing AWS WAF:
https://d1.awsstatic.com/whitepapers/guidelines-implementing-aws-waf.pdf
Getting started with AWS WAF:
https://docs.aws.amazon.com/waf/latest/developerguide/getting-started.html
Overview of managing access permissions to your AWS WAF resources:
https://docs.aws.amazon.com/waf/latest/developerguide/access-control-overview.html
Logging and monitoring in AWS WAF:
https://docs.aws.amazon.com/waf/latest/developerguide/waf-incident-response.html
Securing Azure WAF
Azure Web Application Firewall (WAF) is the Azure managed web application firewall service.
Azure WAF is integrated with and can be deployed as part of the following services:
- Azure Application Gateway: A Layer 7 load balancer service
- Azure Front Door: A global web application threat protection service
- Azure CDN: A managed CDN
Best practices for securing Azure WAF
The following are some of the best practices to follow:
- Deploy Azure WAF v2 license on any newly exposed web application.
- For large-scale environments with multiple Azure subscriptions and multiple web applications, use Azure WAF with Azure Front Door to protect your web applications.
- After learning the traffic for your production web application (running WAF in learning mode), configure Azure WAF in prevention mode.
- For protection against non-standard types of web application attacks, create your own custom rules.
- Create custom rules to block traffic originating from known malicious IP addresses.
- Use Azure activity logs as part of the Azure Monitor service to monitor changes in Azure WAF rules.
- Send Azure WAF logs to Azure Sentinel to detect and remediate web-based attacks.
- Use Azure Active Directory to limit the permissions to the Azure WAF console.
For more information, please refer to the following resources:
Azure security baseline for Azure Web Application Firewall:
Azure security baseline for Application Gateway:
What is Azure Web Application Firewall on Azure Application Gateway:
https://docs.microsoft.com/en-us/azure/web-application-firewall/ag/ag-overview
Azure Web Application Firewall and Azure Policy:
https://docs.microsoft.com/en-us/azure/web-application-firewall/shared/waf-azure-policy
Summary
In this section, we have learned how to use managed WAF services from both AWS and Azure, covering everything from configuration best practices to monitoring and authorization.
Summary
In this chapter, we have focused on the various network services offered by AWS, Azure, and Google.
This has included virtual networking, DNS, CDN, VPN, DDoS protection, and WAF services.
In each section, we have reviewed the best practices for configuration, authentication, monitoring, and auditing.
Managing these services allows us to control who has access to them and to monitor their activity.
In the next chapter, we will review how to manage identities in the cloud (including directory services and cloud based SAML authentication) and how to enforce MFA.