- Newest
- Most votes
- Most comments
Hello! The risk with allowing versus denying at WAF or Security Groups comes down to "where" you want to control traffic.
The WAF resides in front of your application and allowing/blocking traffic with the WAF allows you to prevent traffic from ever making it to your application. On the other hand, the risk you pose by allowing all IPs to cross your WAF is that traffic will be able to get closer to your application before hitting any sort of security evaluation.
Your Security Groups act as a box around all of the resources added to a Security Group. This means traffic doesn't get evaluated until it tries to cross into the SG (or out of the SG if the request is originating from within the Security Group).
Using the WAF is particularly appropriate when you want to control ALL traffic coming into your application before it actually gets to your application. It comes with managed rule sets that you can use to block common vulnerabilities (for example, blocking all traffic from a database of IP addresses that are publicly known to be malicious). It also has the ability to perform rate-based limiting and provides monitoring features for the traffic that passes through it. Using SGs is great for applying rules to groups of resources with shared traffic needs and can prevent the wrong kind of traffic from flowing between resources within your application. Depending on the needs of your application, it's possible that you could achieve all of the security configurations you need for your application with just SGs. However, using SGs in tandem with WAF provides "defense in depth" by adding security at multiple layers of your application. Like I mentioned, this all comes down to knowing the needs of your application and what requirements you have in place for security.
If you restrict access to trusted IPs in the security group attached to the resource to which outside clients connect directly, such as an Application Load Balancer or Network Load Balancer, there's no need to apply the same restrictions in the WAF web ACL associated with the same ALB.
As the other reply correctly pointed out, if you want to apply context-sensitive restrictions, such as limiting access to a web site's administration pages to your trusted IPs but allowing other access to the same site from the entire internet, security groups can't do that, but I'm assuming you know that already.
The restrictions imposed by security groups attached to the ALB/NLB prevent requests from reaching the ALB/NLB in the first place, also preventing an attack from incurring costs by the ALB scaling out or charging for the load balancer capacity units that depend on factors such as the amount of traffic and number of connections. In that sense, it is beneficial to apply the restrictions in the security groups, if you have the option of doing so, if the alternative is only to enforce the restrictions in the WAF web ACL.
However, security groups only scale to a maximum of 1000 inbound rules per network interface (with a default maximum of 60 rules per direction per SG), with the default action for the ENI being to discard flows that aren't permitted by any security group rule. By comparison, WAF can support orders of magnitude larger IP address collections. A single WAF IP set can accommodate up to 15,000 CIDRs, and you can reference multiple IP sets in the rules of a single web ACL. That puts the degree of scalability far above what security groups alone are capable of.
Both replys are accurate Leo and Segrace.
However, Id like to throw a curve ball and ask why are they doing that? Its adding costs going out and in again along with un-needed complexity. I had this at a client once so I deployed an Internal ALB (as well as keeping the internet facing ALB) and configured split horizon Route 53 zone so that the DNS Names remained the same but the traffic is routed internally than to the public ALB.
This its self is a better way to route traffic by keeping it all internal
Relevant content
- Accepted Answerasked 5 months ago
- Accepted Answerasked a year ago
- AWS OFFICIALUpdated 5 months ago
- AWS OFFICIALUpdated 2 months ago
- AWS OFFICIALUpdated 3 months ago
- AWS OFFICIALUpdated a year ago