Cloud providers come with built-in firewalls and firewall rules that control traffic routes and access to cloud resources. Proper configuration management of these firewall rules is absolutely critical, as they determine who or what is able to access your resources at a basic level. In our experience, improperly configured firewall rules are often involved in cloud security compromises.
Firewalls can take many forms such as Web Application Firewalls. For this article we consider AWS Security Groups and Azure Security Groups as “firewall rules” as they represent firewall rule functionality that is often found on network equipment such as pfsense Firewall Rules or Cisco Access Rules.
The first approach we take to firewalls involves classifying the segments of the network so that the firewall rules are appropriate for each network segment. This classification is usually split between public access and private network access. Additional rules for specific functionality are added as needed, depending on the project’s or the organisation’s environment.
Ironically, our public firewall rules are almost never truly public. Except in scenarios where firewalls absolutely must be fully open, - such as for regulated Open APIs - we always geo-block IP ranges assigned to countries with which we cannot do business. For example, sanctions against Russia or trade barriers with mainland China mean there is no benefit in accepting traffic from these regions. Since we cannot do business with them, there is no advantage to allowing their traffic.
This approach depends on your business and risk appetite. However, from a technical standpoint, closing access to regions that do not offer commercially benefits improves your security posture.
Our public rules are applied to Load Balancers and firewalls, as they form the entry point for our entire solution. No other resources are publicly accessible hence other resources utilise Private Rules.
Virtual cloud networks have an internal IP range assigned at creation. Our private rules always allow traffic to freely move within this internal IP range, essentially creating a trusted private network within the cloud. While this is not a perfectly secure posture and further segmentation is recommended to ensure network traffic cannot traverse across all resources, it serves well as an initial and general rule-set.
By setting up private rules to enable communication within the internal IP range, we establish a foundation for secure communication between cloud resources. However, it’s important to implement additional measures such as network segmentation, access controls, and monitoring to strengthen security and prevent unauthorised access or lateral movement within the cloud environment.
The other core component of our basic network design is to categorise subnets into three types:
With these distinctions, resources in private subnets do not have routing access to the wider internet no matter what network firewall rules are applied. This makes private subnets ideal for hosting databases and protected computations which should not have any access to the internet.
Most compute resources are hosted in NAT subnets such that they can access the internet as they require but cannot be directly contacted. All inbound internet traffic must go through the public entry points such as a Load Balancer.
With these foundational rules in place, we further subdivide the network as needed for different services, access points like VPNs, private connections, and private gateways. Applying routes to subnets can be fundamental for effectively managing traffic within the network as firm subnet routes ensure that even if there are accidental misconfigurations or bad firewall rules, route management prevents unauthorised access at a network level.
f your resources are limited and network subdivision seems unnecessary, firewall rules serve as a practical way to manage connectivity without introducing complex network structures. This approach allows for granular control over traffic while maintaining simplicity in network architecture.
If you are hosting applications on Amazon Web Services (AWS), it is important to consider the impact to AWS from your penetration testing. A key aspect of this consideration is determining whether what penetration testing can be safely conducted on the AWS platform without advanced permission and which testing should be abstained from without prior agreement.
penetration testing cloud aws
