Firewalls are an important part of any security protection strategy. In this video, you’ll learn about next-generation firewalls, firewall rules, screen subnets, and more.
A network-based firewall is an appliance that sits inline in your network and makes decisions about whether traffic should be allowed or disallowed through the firewall. These decisions can be made looking at port numbers, which is associated with a traditional firewall, or with an application itself. Those would commonly be associated with the more modern next-generation firewall.
But these firewalls are more than simply a security device that allows or disallows traffic. There are many other services that you can also run inside of these firewalls. These firewalls can also be VPN endpoints or VPN concentrators where you might have point-to-point connections between different sites or used as a remote access VPN.
And many firewalls are configured to also act as a router or layer 3 device. These will often be used on the ingress/egress point of the network. So it’s usually at the point where the outside network meets the inside network. And because it’s a router, it can also perform network address translation, dynamic routing, and other routing functions.
A common firewall type that you’ll find on many networks today is the Next-Generation FireWass, or NGFW. This next-generation firewall is able to analyze the traffic flowing through the firewall and recognize the specific application that’s currently being used. We can then make decisions about whether that application is allowed through the firewall or not. Sometimes a next-generation firewall is referred to as an application layer gateway, a stateful multi-layer inspection device, or a deep packet inspection device.
There’s a lot more work that goes into deciding whether traffic should be allowed by application versus simply looking at port numbers. A next-gen firewall has to be able to analyze all of the traffic passing through. So we have to perform packet captures, categorize each of those captures into their appropriate applications, and then make security decisions on how this traffic should be handled.
Traditional firewalls didn’t have the ability to understand what the applications were traversing the network. All they knew was what port numbers were communicating from point A to point B. And we can make security decisions based on that port number. Obviously, next-generation firewalls provide us with much more flexibility in understanding the exact application, but we can also apply port numbers to our decision-making process as well.
So in a next-generation firewall, you can allow or disallow web server traffic. On a traditional firewall, you would be specifying that this was TCP port 80 or TCP port 443. Next-generation firewalls would understand SSH as it’s passing by, whereas a traditional firewall would focus on TCP port 22. The same thing applies for Microsoft Remote Desktop protocol, which can easily be recognized by next-gen firewall, but you would have to know TCP port 3389 on a traditional firewall.
Next-generation firewalls are very good at identifying DNS queries which, of course, run over UDP port 53. And a next-gen firewall will know about the network time protocol. A traditional firewall would only be able to control NTP traffic by allowing or disallowing UDP port 123.
Here is a security policy from a next-generation firewall. And you can see that there are a number of different parameters that can be chosen. For example, we can see the name that is associated with the rule, where the source of the traffic is coming from, where the destination is going to, and then you can specify information about IP addresses, services, which would be port numbers, the user that is associated with that traffic flow, and then, of course, the application, web category, URL list, or other matches that you can then add into that next-gen firewall rule.
Most firewall rules will start at the top of the rule base and begin evaluating each rule individually until it matches a rule that is listed in that rule base. This means we usually put the more specific rules at the top of the firewall, so we can recognize them quickly, and then, more generic or broad rules can go lower down in the firewall rule list. Most firewalls will also include an implicit deny as part of the rule base.
That means that it will step through each rule in succession from the very top to the very bottom. But if no rule matches in the firewall rule base, we have to know what to do with the traffic once we reach the bottom of the rules. And in the case of an implicit deny firewall, everything that doesn’t have a specific match in the rule base will automatically be denied once it reaches the bottom of that list.
Another way to describe a rule base or policy list in a firewall is an Access Control List, or ACL. So it would be common to see, in a firewall, a rule that has a source IP address, a destination IP address, a port number, time of day, the name of an application, and other variables as well. So let’s look at a list of firewall rules and understand what might be allowed or what might be blocked through this particular firewall.
This rule base has a very simple set of parameters. We’re looking at the number of the rule, a remote IP address, a remote port number, a local port number, a protocol, and an action or disposition. The first rule that’s in our firewall will accept all traffic that is coming from a remote IP address and remote port number. And it’s looking for any traffic that may be destined for local port 22 using the TCP protocol. Knowing what we’ve already learned about protocols, we know that is SSH. And any SSH traffic inbound from a remote device to our local network is allowed through this firewall.
The next rule is also one that is allowed from all remote IP addresses and any remote port numbers to a local port number of 80. So this would be HTTP traffic. This is also traffic that is allowed through the firewall. Port 3 also allows traffic from the outside over any IP address and port number to a local port number of 443. That would be HTTPS. And that traffic is also allowed.
Rule number four also allows Microsoft Remote Desktop protocol. We know that because it allows all traffic from any remote IP address and port number to a local port number of 3389 using TCP, and all of that traffic is allowed. Rule number five is for all traffic from a remote IP address using port 53 to be allowed into any local port number using UDP. This would be DNS traffic. And all of that traffic is allowed.
Rule six allows another type of inbound traffic from any remote IP address using a port number of 123. So this is the network time protocol. And that can communicate to any local port number over UDP, and the action is set to allow. And lastly, we have a rule for any remote IP address. And this particular rule does not have a remote port number or local port number because the protocol that’s being used is ICMP which is commonly associated with a ping. And ICMP does not use UDP or TCP. If there’s any inbound traffic over ICMP, that traffic is denied in the firewall.
And let’s assume that this firewall is also configured as an implicit deny. That means, if the traffic coming through the firewall does not match any of these rule numbers, it is automatically dropped by the firewall. Most organizations will put their firewall at the ingress/egress point of the network. This is the point that separates the internet from the internal part of the network. And in this diagram, we do have a firewall that sits between the rest of our networks and the internet at large.
This firewall is actually connected to two different networks on the inside. One is the internal network. This would be where all of our confidential data might be. And the other is a screened subnet. A screened subnet commonly holds services and devices that need to be accessed by individuals on the internet.
By putting these devices on a screened subnet, we can take all of that traffic from the internet and direct it to a subnet that does not contain any of our sensitive devices or data. That means all of the traffic from the internet can be directed to the screened subnet and back to the internet again. And it would prevent anyone from the internet from accessing the internal network.
Just as we have rules that are built into our firewalls, we also have rules for our Intrusion Prevention Systems, or our IPS. Often, today, an IPS is included as part of a next-generation firewall, and it has its own rule base within that firewall specific to the IPS. An IPS is also monitoring traffic in real time as it’s passing through. And it’s able to use signatures that have been loaded on that IPS to be able to recognize any type of malicious software that may be traversing the network.
Many of the rules built into an IPS use a signature. This is an example of an IPS signature that has been written for the Conficker worm. This signature is looking for a very specific type of traffic to pass through the IPS. And if that traffic matches the signature, the IPS can then react to that and make decisions on whether that traffic should be allowed or blocked.
Some intrusion prevention systems can also work without specific signatures by looking for anomalies to occur. The IPS may have been configured to recognize what a generic intrusion might look like such as a database injection. And if any type of database injection passes through the IPS, it will be blocked even if a specific signature doesn’t exist. The rule base of an IPS is also very similar to the rule base of a firewall. There will be a list of vulnerabilities, and you can decide whether the IPS should allow those vulnerabilities to pass through or whether you should block them at the IPS.
Most intrusion prevention systems will have thousands of these signatures inside, and you can make decisions over what signatures are allowed through your network and which might be blocked by the IPS. Because there are so many rules in an IPS, you can often summarize the rules and make broad decisions about what’s allowed or blocked by grouping these rules into a group. Those groups are often selected automatically by the IPS software, or you can make groups yourself.
This allows you to set very broad dispositions based on all of the rules that may be in a group. For example, you could set a policy that says, if any of the roles associated with a database injection are identified, block all of that traffic at the IPS. With so many rules in an IPS, it’s not uncommon to occasionally find a false positive. But if you customize the rolls inside the IPS, you can find the right balance between providing security and identifying something that might be a false positive.
Here’s an example of rules that you might find in an IPS. Many of these are based on malware. You can see port numbers that might be used and the name of the malware that would be identified by the IPS. There might also be other rules. This one is for an FTP protocol where there is a worm that can be identified as part of the FTP login process. And you can configure your IPS to identify that worm logging in and block it before it gets inside of your network.