NACL Update – Least-Privilege??

I just had a go at this through the expert path, got it to work and could have been done with it, but I choose to look at the end of the video. While I like to the general format of this lab, the answer/fix around NACLs provided in the lab is just (sorry) horrible. Here is why and feel free to disgree/discuss:

1. There are two NACLs that are available after the "LaFour" CFT has been run. One of them has "everything is open", but it is not associated with anything. Given that this NACL has "everything is open", I decided to delete this one, because just having such a NACL is dangerous and goes against any security best practice. Afterwards I fixed the broken other NACL so that it allows inbound TCP on port 80 only and outbound on ephemeral ports (1025 – 65535). I assumed that Scott would use the same approach, but to my absolute bewilderment, he choose to simply associate the "allow everything" NACL with the subnet where the EC2 instance is. This choice reduced the layers of security by one (now it is just the security group instead of security group + NACL) and has the danger that someone configures the security group equally open resulting in an "all open" EC2 instance. For a course on ARCHITECTURE, the proper choice here is definitely using a least-privilege approach an restricting the NACL as described above.

2. The response really misses out on a great demo on VPC Flow Logs as you can really debug this issue with VPC Flow Logs properly and understand first what is going wrong before making changes. If you use VPC flow logs, you can also see why the choice with the NACL completely open is so bad: In the 10 minutes that my instance was up, the instance saw tons of connection attempts on all kinds of ports outside of 80. This is exactly the kind of "port/vulnerability" scanning traffic that you want to keep out with NACLs.

While the 2nd remark here is just an improvement, the first issue is really a reason to say "no this is not how to do it".

BR, Markus