Skip to content

Firewalls#

Once you're in an established environment you'll be updating firewall rules quite a lot. Firewalls are fundamental to understanding how-to secure a network.

Note

Throughout this book we'll implement two firewalls: at the AWS level using Security Groups; and at the operating system using the Ubuntu UFW firewall system.

At the most basic level, all a firewall is doing is looking at the traffic coming through its network interfaces, inspecting it, and then comparing some of the traffic's characteristics against a set of rules. Those rules determine if the traffic can pass through or not. It's that simple (but of course it can get way more complicated quickly.)

What can a firewall be configured to check for? The most common thing you'll be doing at a junior level is checking for some very simple parameters:

  • What is the source IP address?
  • What is the destination IP address?
  • What protocol is the connection? (TCP, UDP, ICMP?)
  • What port is the connection trying to reach?
  • Is the connection related to an already approved, established connection?

And that's it. There's a lot more to learn later in your career, but as you know by now this book is about maintaining focus on the important components and saving the complex stuff for later. For now, simply understand the basics of firewalls and review the content below.

Let's visualise a simple network with a firewall and simulate some rules:

Firewall Example

Firewall Example

There's a lot going on here, so let's first break it down into a series of firewall rules and then we'll explain it all.

# Protocols Ports Source Destination Action
1 UDP 1194 67.88.88.1/32 34.3.5.6/32 ALLOW
2 ALL ALL 0.0.0.0/0 34.3.5.6/32 DENY
3 TCP 443 10.100.1.0/24 10.0.3.0/24 ALLOW
4 TCP 443 10.200.1.0/24 10.0.3.0/24 ALLOW
5 TCP 443 10.0.1.0/24 10.0.3.0/24 ALLOW
6 TCP 443 10.0.3.0/24 10.0.2.0/24 ALLOW
7 ALL ALL 10.0.1.0/24 10.0.2.0/24 DENY
8 ALL ALL 10.100.1.0/24 10.0.2.0/24 DENY
9 ALL ALL 10.200.1.0/24 10.0.2.0/24 DENY

Rule 1 is saying we allow connections from a specific public IP (67.88.88.1/32) and we allow it to connect to our firewall's VPN server, which is also a specific, public IP (34.3.5.6/32). This is what this employee, who's working from home, needs to do to access the internal web app (in this scenario.)

Note

See how the employee connected to the VPN has a public IP AND an internal IP inside of the 10.200.1.0/24 range? Their public IP is used to connect to and send information to the VPN server on the firewall. Their internal IP address uses that VPN connection, over the public Internet (but encrypted), to access other internal IP addresses. Essentially it's like they're on the internal network like the other employee inside of 10.0.1.0/24.

After that, rule 2 says all protocols (TCP, UDP, ICMP, and more) on all ports are blocked from connecting to our firewall. So the employee is let in, but if a connecting system's public IP doesn't match rule 1, it'll successfully match rule 2 which is a DENY rule. That means the packets are dropped and never get processed any further.

It's because of rule 2 that the IPs 34.65.78.1 and 45.56.67.78 are dropped and are never allowed to connect to anything. Rule 2 is called an "explicit deny". It's common practice to have a list of ALLOW statements from top to bottom, and then at the bottom a single, wide, catch-all DENY. This is called a "white list".

Rule 3 is an internal rule. Everything internal goes through the central firewall. In rule 3 we're saying all systems in the firewall's subnet of 10.100.1.0/24 can connect to the web app's subnet (and anything inside of it) of 10.0.3.0/24.

Rule 4 is an interesting one. It does the exact same thing as rule 3 but it's a bit more interesting because it's the subnet range given to VPN clients: 10.200.1.0/24. What this rule says is: anyone on the VPN will be inside of 10.200.1.0/24 and should have access to anything inside of 10.0.3.0/24 on TCP/443.

Rules 5 and 6 are the same again - allowing internal subnets to talk to other internal subnets. You should be able to work out which is which here.

Rules 7, 8, and 9 are DENY statements. They're preventing any connections to the database subnet directly. Instead, we want employees to only go to the internal web app (which talks to the database.)

And that's a simple set of firewall rules. When we're eventually building Security Groups inside of AWS you'll realise it's actually quite simple provided you understand the above.

Next#

Now let's review Authz and what it means.