What would you choose and why? Two correct ways.
AWS NACL. You need to close one port - and you can do that two ways:
- Add “deny” rule with higher priority, before the “allow” one.
- Split the single “allow” rule to two, excluding the port number from allowed/open.
I have these reasons: If we have mix of “deny” and “allow” rules - we’ll distract our attention - we have to remember every point - allowed range, denied range, and in case of numbered order of rules, that will confuse you. Otherwise, if we have only one “deny all” rule in as the last one, which means it will be applied last, we’ll have allow rules, which allows certain list of ports, and you can check them with less parameters - you’ll know, all these rules are “allow”, so you need just check if the port number allowed, that’s all.
Sounds good enough?
I agree, it sounds really reasonable. Until you’ll have hunderds of different ranges of port numbers. As in the example above - block port RDP 3389, which means you have two ranges now instead of one. Also, all ports below 1024 are blocked either (btw, do you remember why?). Next you’ll block port 3306, 5432, 6379, etc. You’ll have 5 ranges. Every new port to block changes the existing rule and add one more rule.
In fact, here we come to comparison of ways: “deny all” and “allow all” in the end. In case of “deny all” we allow port numbers explicitely. In case of “allow all” we deny ports clearly.
Why we have both type policies, and not just choose “single one to rule them all”? I mean, “best practice”.
Because we have different situations. For example, in the topic question, AWS Network Access Control List we have two lists of rules - for ingress and for egress.
For ingress usually use “deny all” rule, as more secured. For egress - “allow all”, because usually you want to have access from your network to the internet freely, right?
But, in case you want to fully control the traffic, you may allow only specified list of ports, required by your apps. That’s also common situation, just a bit more complicated.
Next, we come to responces)))) When the app sends request somewhere, it shoulf get response. And according to the network protocols, it is usually a random port number somewhere in 40k. ;) But NACL is a stateless thing! it doesn’t remember what it allowed to ask a second ago, and doesn’t allow you to get answer “because you’ve asked”. That’s a security group feature. For NACL you have to explicitely describe the list of ports, allowed to passthrough. That’s why we have allow ingress rule for range 1024-65535. With exceptions.