Network Firewalls

I can remember working with servers stemming all the way back to the early 1990s where security was an issue, but not like it is today. Not applying updates constantly over the Internet and not having as many exploits available. It just wasn't as widely used. However, it is crucial for server technicians to have a solid understanding of various security mechanisms that they can put in place to protect servers.

 

One of those solutions is, on a wired network for securing it, you might consider the use of an air gapped network. Now this means that you have a sensitive network that you don't want to have any connection to any other network, certainly not the Internet. So an air gapped network does not have a wired link to another network, nor would it have a wireless link to another network.

 

You need to be able to control access to the network in the first place. That's your first line of defense. Who can even get on my network? After that, then, we have things like host-based firewalls and virus scanners, and database security, user login security, that type of thing. But you can enable network authentication.

 

In other words, a client cannot even get on the network and acquire, for example, an IP address through DHCP until they are successfully authenticated. And of course, that means that the communication over the network, since there's not an IP address yet, would occur at layer 2 of the OSI model through MAC addresses. You can also do physical things to protect your network, like installing physical switch port locks and blockers.

 

So a network switch might have 24 ports, and in the server room and even behind a locked rack in a cabinet you would have your switch, where if you don't have a cable plugged into every port, you can physically put in one of these physical switch port locks or blockers that might even have a locking mechanism.

 

It would prevent someone that somehow gained physical access to that network switch from plugging in a network cable and plugging in a device. That's important for network access. Of course, it goes without saying that we should have locked server rooms, equipment racks and wiring closets, to prevent physical access to network equipment and wiring.

 

You can also configure isolated networks, so, network segmentation where you might have one network for storage, depending on the nature of your business, one for guests or clients and another one for managing servers, and then using network security protocols like Transport Layer Security or TLS, and IPsec. So blocking or disabling unused network jacks or ports is crucial. In our diagram, we've got a reception or a waiting area for a business and behind a potted plant, we might have a network jack in the wall.

 

Now, if that's not been blocked at this level, or if it's not been blocked back at the switch where it actually has a link into a network switch, and if that port is left enabled as per switch configuration settings, then that means potentially we could have a malicious user enter the reception area, sit down, and actually plug their laptop, let's say, into that network jack.

 

And if that jack isn't disabled or if it's not blocked and we're not using network access control, that user would get on the network. Now the question is, which network? Maybe that's just a client or reception waiting area network, which is fine, but still, we want to be very wary of this. So the other thing that could be scary is if that network jack actually links, let's say, to a corporate production network, and I'd be lying if I said I haven't done security audits in the past where it is that easy to make a connection.

 

Sometimes it really is. Anyhow, what I could consider doing from a malicious user standpoint is walking into the reception area and casually plugging in a wireless router into that network jack behind the flowerpot, or in the flowerpot, although it might get wet. So the other thing to think about is that we could potentially have allowed an attacker in this case to gain remote access to our network without being physically on-premises.

 

They don't have to be in the office if they've got a wireless router there. So there are lots of scary things that can result from not disabling or blocking unused network jacks and switch ports. Another aspect of network authentication is RADIUS. In this example, on the left, we have a supplicant. A RADIUS supplicant is a client trying to get on the network, in this case, it's a smartphone. Now they might be making a connection through equipment that is IEEE 802.1x compliant. And what that standard means is it supports network access control.

 

It could be a Wi-Fi router or an access point, could be a VPN appliance, could be a network switch. Now all of those devices are called RADIUS clients. The actual client device connecting isn't called a RADIUS client, strangely enough, they're called a RADIUS supplicant. So what happens is they would make a connection through our RADIUS client device, which would force them to authenticate. Maybe that requires a PKI certificate on the device in addition to a username and a password, which would be forwarded on to an internal network to a RADIUS authentication server that actually does the authentication.

 

You don't want the RADIUS client device doing the authentication because it is on the perimeter of the network, and it itself could be hacked. And if it does get compromised, we don't want credentials to be made available to malicious users. So this is RADIUS network authentication. Before that smartphone even gets on the network and can even do anything, it has to have been authenticated. Sounds like a good idea, doesn't it?

 

Then we have virtual local area networks or VLANs and network isolation. You can configure this within one or more network switches that might be linked together. In the end, what we might do, for example, as pictured in the bottom left of our diagram, is we might have an IoT device VLAN and then a separate production VLAN. Now, IoT devices, Internet of Things devices, are many in terms of their functionality.

 

At the consumer grade level, it could be something used for home environmental control or for baby monitors. At the more commercial level, IoT devices might be used in the industrial environment to track the amount of pressure in a system, or whether valves are opened, or the temperature within a vat, in a food production company; could be a lot of things. Now, some of those IoT devices might be susceptible to security attacks, and that's why often they are placed on a separate VLAN so that, if they do get compromised, they're not directly on the network with other production equipment.

 

So you would have restricted access then between these two VLANs. Another way to protect servers is through intrusion detection and prevention. Intrusion detection and prevention, or IDS and IPS, can work at the host level or the network level. So a network intrusion detection system or a NIDS, can be a separate network hardware appliance that plugs into the network, or it could be software. But what it does, is it might be plugged into a switch port configured to copy all switch port traffic. So it would be able to examine all traffic in the switch, and it would look for anomalies.

 

Now you could have the attacker out on the Internet that's trying to come in through an exterior firewall to a DMZ or a screen subnet where public servers might be compromised, which could then potentially allow the attacker in through the interior firewall to the ultimate attacker target, which is a server shown here in the bottom left. So with the network intrusion detection system, it can detect, depending on how it's configured, things that are out of the norm, such as a server, a public server in the DMZ, coming in through the interior firewall to the internal network at odd times of the day it normally would not be.

 

And so, the network intrusion detection system can detect this, it can log it, it can send notifications to admins, whereas an intrusion-prevention system would be able to take steps to stop that type of activity. Of course, an important part of securing servers is managing network security protocols on them, such as working with Transport Layer Security or TLS. TLS is a network security protocol that uses a PKI certificate, and you can apply TLS to a specific network service like SMTP mail transfer or HTTP websites, which would then become HTTPS because they're secured, or FTP file transfer servers.

 

So often it's used for HTTPS, and when you do that, that means the website allows connectivity through port 443 by default. So you might have to adjust firewall rules to allow that traffic in if that wasn't previously configured. Other network security protocols would include IP security, otherwise just called IPsec. Now, IPsec can use a PKI certificate to secure network connections, but it doesn't have to, because it can use a pre-shared key also called a secret key or a symmetric key; the same key is configured on both ends of a connection.

 

You might have experience doing this on a home wireless network where you configure a WPA2 or a WPA3 passphrase on the wireless router and connecting clients have to enter that same passphrase. That's the kind of thing that you can do. Now that's not using IPsec, but IPsec can use that type of mechanism. It can also use Kerberos, which is an authentication protocol. It's a standard, that happens to have been adopted in the Active Directory environment. So, IPsec can apply to limited IP traffic based on your configuration, or you can have IPsec apply to all IP traffic to protect it.

 

Really depends how you configure it. For example, you can configure IPsec on an internal local area network to encrypt all network traffic, even if that network traffic normally itself is not encrypted like Ping traffic or Telnet or FTP. So this is commonly used, though, for VPNs and for LAN security as well, as we've described.

 

These days, server technicians need to be well versed not only in wired networking, but also in wireless networking standards. Now this isn't solely because a server might be directly connected to a wireless network, because often servers are not. They're usually connected to a wired network. However, we have other devices that can use wireless connectivity and ultimately gain access to services hosted on a wired network server.

 

So let's take a look at this. We've got a number of networking standards in the wireless realm, like Zigbee. Zigbee is designed for home use. It's an easy, convenient way to set up devices on a home wireless network. Then we've got the Bluetooth protocol. Most of us have probably used Bluetooth in a variety of ways, which we'll talk about in a moment.

 

We've got Wi-Fi or wireless fidelity for standard wireless networking, whether at home or in the enterprise. And we've also got the notion of Software-defined radio, or SDR. SDR is really what we're talking about being used for modern wireless communications. We've got firmware that can be updated with new wireless standards as new wireless standards and settings become available.

 

Let's start by talking about Bluetooth in a bit of detail. In a Bluetooth environment, two devices can communicate for a variety of reasons that we'll define after, but the idea is that the two devices must be paired together before they can communicate in some way. So the standard Bluetooth range is approximately 10 meters, which works out to be 32.8 feet. Now we say standard because there's more than one type of Bluetooth.

 

Some of them have longer ranges than others, but generally speaking, we're looking at about 30 feet or so when it comes to Bluetooth transmission range, after which the signal just keeps degrading the further you get from the other paired device. So Bluetooth connectivity might be used to share contact lists between devices, like smartphones, or to transfer files between devices.

 

Bluetooth is a great way to wirelessly transmit pictures, for example, between a tablet and a laptop, or between smartphones. You can use Bluetooth printing if your printer supports it. You can also use it to connect to projectors for network connectivity, to project presentations or media of some type. You can use Bluetooth to link a device to a headset, so for hands-free talking on the phone, for example, while driving or walking or doing anything else, you have Bluetooth headphones, Bluetooth speakers.

 

These can all be connected or paired to another device where you have media that streams through the wireless network, through the Bluetooth wireless network, to the other device. Phone calls is very important when it comes to Bluetooth. It allows people to remain alert and drive with both hands. But again, Bluetooth does have a limited transmission range. Now, when we talk about Wi-Fi, we're talking about the 802.11x standard, of which there are many substandards like 802.11g, 802.11n, and so on.

 

Now the standard Wi-Fi range is approximately 71.5 meters, or about 235 feet. This will vary depending on the 802.11x standard that's being used. It'll also vary depending on what is in the atmosphere. This is radio transmission. This is radio waves being sent through the air. So as you might imagine, if there's a heavy snow storm, if there's heavy rainfall, or if you're in a region where there's a dust storm, or even if there are leaves on trees during the spring and summer, that can affect the wireless transmission signal for Wi-Fi.

 

So you can get high-gain antennas, you can actually even build your own. If you use your favorite web search engine to search up cantenna you'll get some interesting return results on how to build your own high-gain Wi-Fi antenna, so therefore you would have a much longer range than the standard 235 feet.

 

So with the Wi-Fi network, a client needs to be authenticated to the wireless access point or the WAP. Now, when the wireless access point can connect to another network at layer 3 of the OSI model for routing, it's then called a wireless router. Either way, the access point can support MAC filtering. That's layer 2 of the OSI model, which deals with MAC addresses.

 

Remember that MAC addresses are the 48-bit hexadecimal addresses that uniquely represent a network interface card. So in a Wi-Fi network, we can configure the access point with a list of allowed or denied MAC addresses. We can also enable pre-shared key authentication, PSK. That means we have the same or symmetric passphrase used on the access point, that the clients have to enter on their end, in order to authenticate and connect to the Wi-Fi network.

 

Or in the enterprise, you can use enterprise authentication mechanisms, which would often mean that we have a centralized RADIUS server on an internal protected network that we forward client authentication requests to. So that's a form of network access control. When it comes to wireless networks, specifically Wi-Fi, there are many free tools that you can use to perform a Wi-Fi site survey.

 

Here I'm using the free NetSpot discovery tool, where we get a list of all of the Wi-Fi devices, whether they're HP network printers or whether they're access points. Interestingly, there are a number of columns here that provide some very interesting information, such as the Signal Level. Now, the Signal Level column shows us the Signal strength, which of course, will vary, if we move closer to or move further away from a given Wi-Fi device.

 

Also, one of the rightmost columns here, labeled Security, shows us how that wireless network is secured, whether it's using WPA2 or WPA3. We have a number of items here, for example, shown as using WPA2 Personal; that's a pre-shared key, versus having a couple of Wi-Fi items here, in our case, specifically HP network printers, where the Security is Open. [Video description begins] The rest of the columns are: SSID , BSSID, Alias, Graph, %, Min., Max., Average, Level, Band, Channel, Width, Vendor, Mode. [Video description ends]

 

So there are a number of Wi-Fi security protocols, the first of which is wired equivalent privacy or WEP. Now, you don't want to use this one. It's older and there are so many known security flaws, and the security flaws are really due to the fact that it uses a 40-bit initialization vector or IV, and the key is static.

 

And so you can predict what the IV will be, given enough captured traffic. Wi-Fi Protected Access, or WPA, was created to address the flaws with WEP. So it supports pre-shared keys or enterprise mode. It supports something called TKIP, which means dynamically changing encryption keys. WPA2 supersedes WPA. It also supports PSK, enterprise mode, and AES encryption.

 

And WPA3 supersedes WPA2. It supports a lot of the same things, but it also supports something called a simultaneous authentication of equals or SAE secure handshake to further enhance security of the wireless network. Another aspect of wireless networking is something called a Wi-Fi captive portal. You've probably experienced this if you've ever been in a public space where there is free public Wi-Fi.

 

Doesn't even necessarily need to be free, but you have to agree to some kind of terms or sign in, and then connect to the Internet. In other words, you already have an IP address prior to accepting and connecting. But the captive portal prevents Internet connectivity until you sign in, or if it's free, just accept, then connect, by clicking perhaps a button on a web page.

 

To secure or harden a wireless network, you can disable unnecessary components, like disabling Bluetooth on a smartphone if it's not needed or a projector. You can apply hardware and software updates, which is always part of hardening. You can also disable the service set identifier or SSID wireless LAN name broadcasting. Normally, when you want to connect to a Wi-Fi network, you can just scan the vicinity and a list of Wi-Fi networks with their names pops up.

 

You can prevent that from happening. It makes it more difficult to connect to because you'd have to know the name of it. You can also enable MAC address filtering. Use WPA3 enterprise mode authentication. You can use a wireless intrusion detection and prevention system to detect anomalies and report or block those suspicious activities.

 

Most Wi-Fi routers allow WAN management from a remote network. That's something you want to disable. You want to make sure that you are on a local area network before you have the ability to remotely manage a Wi-Fi device. So that's a handful of things to consider when it comes to wireless networking in today's modern computing environments.

 

Packet filtering firewalls are designed to either allow or to deny traffic to or from the network or to or from a specific host on the network. So we can have network perimeter packet filtering firewalls or host-based packet firewalls or a combination of both, ideally. So packet filtering firewalls means that we have a security solution that applies up to layer 4 of the OSI model. That's the transport layer, which deals with things like TCP and UDP.

 

Specifically, port numbers is what we're really interested in here. You can have a stateful firewall or a stateless firewall. A stateless firewall looks at each individual packet transmission as its own entity, and does not consider that we might have a session consisting of many packets. Whereas a stateful firewall is smart enough to take a look at a connection, such as a TCP connection that's been established, and treat all of the packets within that session as being one type of connection.

 

So this way, it can monitor the state of a connection, which could consist of many packets and make decisions on whether traffic is allowed or not. When you implement a packet filtering firewall, it can be done at the hardware level. For example, you might enable packet filtering firewall rules on your Wi-Fi router. It's often built in. So you can manage your Wi-Fi router normally through an HTTPS connection to the IP address of that device. Or you might have just a standard network router like a Cisco router or a Juniper Systems router, that type of thing.

 

So it's not a Wi-Fi router, it's a standard network router. Again, you might connect to it remotely using HTTP or HTTPS or SSH, you might manage it locally, but either way, you can configure packet filtering rules. You can also have a dedicated security appliance that's designed to do nothing but security, including packet filtering. Of course, packet filtering firewalls can come in the form of being software.

 

It could be software that's built into an operating system or that you add to it, such as the built in Windows Defender Firewall solution, or in Linux, you might install the uncomplicated firewall, or ufw, packet filtering firewall solution. You could have a dedicated security appliance, and in the software realm, we're really talking about, often, what comes in the form of a prepackaged virtual machine that already has the software installed that you would just configure to suit your needs.

 

And that could be on-premises, or it could be a cloud-based type of firewall solution that runs as a managed service. So what happens when traffic gets inspected? When network traffic is examined by a packet filtering firewall, here's what it can look at. So what we're looking at here is the breakdown of the headers in a packet transmission, so a single packet. So the Ethernet header maps to layer 2 of the OSI model and contains information such as source and destination MAC addresses.

 

The IP header follows next, which maps to layer 3 of the OSI model, and it contains, among other things, source and destination IP addresses. What follows after that might be the TCP or UDP header, I say might, it depends on the type of transmission, but let's assume it's either a client doing a DNS query, which means we have a UDP header, or a client connecting to a web server, which means we'd have a TCP header.

 

Either way, this would apply to OSI layer 4, the transport layer, where we would deal with, among other things, source and destination port addresses. Then we would have a protocol header. So for example, HTTP, which could deal with layers 5 through 7 of the OSI model. So what a packet filtering firewall could do is at least determine that we might have an HTTP packet, but it won't be able to look any further than that.

 

And it certainly will not be able to look at the packet payload or data, because packet filtering firewalls are designed to look only at packet headers, which really is usually, among other things, generally speaking, it's addressing information. So we could look at a MAC address, an IP address, a port address or a protocol type, to either make a decision to allow or deny. Now, notice that this type of firewall can't look at the specific URL that was entered.

 

It can't look at the time of day. It can't detect phishing scams. It can't check for viral infections or anything like that. A deep packet inspection or an OSI layer 7 firewall can do all of those things, and usually that's packaged into what's called a unified threat management or a UTM type of solution.

 

So we know then that packet filtering firewalls can look at source and destination IPs, source and destination port numbers, protocol types, and the direction of the transmission coming into or out of a particular interface on a firewall appliance. In our diagram, we are really focused here on the placement of the firewall device. Towards the left of our diagram, we have an internal network with a firewall that controls traffic into and out of that network, so the firewall would have at least two interfaces.

 

We then have a second firewall to the right of our diagram that connects to the Internet. That's our perimeter-based firewall. Between the two firewalls, we have what's called a demilitarized zone, a DMZ, or otherwise it's called a screened subnet. This is where you can place servers, that should be publicly accessible, in our example, to the Internet.

 

So this means then, that our perimeter firewall to the right connected to the Internet, might allow, for example, inbound traffic to port 443 for an HTTPS website in the DMZ, but our second internal firewall would never allow that type of traffic from the Internet into our internal network. So the point is that firewall rules will differ on different firewalls, especially in a multi-tiered firewall environment such as what we have here in our diagram.

 

The other thing to consider is the performance of the firewall, because it has to examine a lot of network traffic. So will that affect network traffic flow speed in any way? The answer is yes, it could. So really, if you want the utmost in performance, use hardware appliances that are designed to do something specific, like examine network traffic, that always outperform software solutions where the software solution runs in an operating system that's designed to do millions of other things.

 

Always consider the placement of the firewall and maybe using a firewall to isolate certain types of traffic on different network segments. Use multiple firewalls if possible, because you could even direct groups of clients or external entities to a particular firewall to spread out the load of examining network traffic. And if you're dealing with a hardware appliance, think of the CPU power and the amount of RAM available in that appliance for processing network transmissions.

 

And then consider rate throttling configurations where you can limit the amount of traffic coming into or leaving a network, which might be done to prevent flooding attacks. But at the same time, it's also limiting how much traffic throughput you have at the network level. And so, you have to strike a balance, which is often a very delicate type of configuration.

 

In this demonstration, I'll be configuring firewall rules using Windows Defender Firewall. So the first thing I'd like to do is check out what the IP address of this server is. So I'm going to go into the Start menu, I'll fire up cmd to open up a Command Prompt, and I'm just going to go ahead and type ipconfig. So this server's address is 192.168.4.167.

 

So I want to try to at least ping this and make connections to it from another host, over the network. So I'm just going to type hostname, so we know which machine this is. [Video description begins] The name reads: WIN-M6CGN1MFJLQ. [Video description ends] OK. This is a Windows Server with a randomized name. OK, got it. So now let's go to the other machine.

 

OK, from a different computer, and I'll just type hostname; this is a laptop computer, [Video description begins] The name now reads: LAPTOP-R5632Q8M. [Video description ends] I'm going to go ahead and try to ping that host: ping 192.168.4.167. Sure enough, we're getting a reply back. So what's that telling us from a firewall perspective? It's telling us that ICMP echo packets are allowed to that server and the reply is allowed back out to our host.

 

OK, so ICMP works. Ping works. The other thing I want to do is try to hit a web server running on that host, because I know there is a website installed there. So for that, I'm going to fire up a web browser. OK, so I'm able to connect to that web server, given its IP address, and port 80 is implied, so there's no firewall blocking that type of traffic.

 

But what I would like to do is limit which clients can connect to this web server. For that, we're going to need to flip over to the web server and configure the firewall, because we're going to be configuring a host-based firewall, although you could be configuring a network-based firewall. OK, so here on my server, I'm going to go into the Start menu and look for the word defend, and I'm going to bring up Windows Defender Firewall with Advanced Security.

 

When I go into the Advanced Security option, it takes me into this interface where I have Inbound Rules to control traffic coming in, and Outbound Rules to control traffic leaving this particular host. [Video description begins] There are two more blades: Connection Security Rules and Monitoring. [Video description ends] So, if I go to Inbound Rules, and if I click in the list and press the letter W, we've got a World Wide Web Services or HTTPS Traffic-In, and if I go further down, we've got a World Wide Web Services HTTP, which is what we were testing, Traffic-In.

 

If I double click on that, it says this is a predefined rule and you can't modify all of the properties. It allows inbound traffic to port 80. And we know that that works. It's set to Allow the connection because we just viewed the web page, but we want to limit which clients, by IP address, can connect.

 

So to do that, I'm going to go to the Scope tab. Currently, it says local IP addresses, any IP addresses, that's on the local subnet, so I'm going to choose These IP addresses, and this is where I can Add the IP addresses that should be allowed to make a connection to port 80 on this host. So I'm going to click Add and I can specify, as we see in the examples, an entire CIDR range, or I could specify an individual IP address, whether it be IPv4 or IPv6.

 

I'm going to add a single IP, 192.168.4.1, and I'll click OK and OK. Back here on my Windows client, I'm going to try to refresh this web page, and immediately, it looks like it's taking much too long. It certainly is taking longer than it did the initial time that we loaded the web page.

 

And that's because my IP address is not 192.168.4.1, so I'm not part of that scope that should be allowed to connect to port 80 on the host. So eventually this web page is just going to time out. And there we have it. This site can't be reached. OK, so we know that the firewall is working correctly. The other thing I want to do is I want to block ICMP traffic on my server.

 

We were able to ping, and ping uses the ICMP transport mechanism. We're just going to verify that ICMP is being used by capturing network traffic as we ping. So here I'm in The Wireshark Network Analyzer, this is a free download. I'm going to double click on my Wi-Fi interface to begin capturing on it. And from a Command Prompt on that same machine, I'm going to use the up arrow key to bring up our previous command where we were pinging our server.

 

And again, we're getting the replies. Let's go see what we captured in Wireshark. So, in Wireshark, I'll click the stop button to stop capturing and I'm going to filter for the icmp protocol. And sure enough, we have all kinds of ICMP packets being sent to 192.168.4.167, that is our web server, and there are Echo (ping) requests and then the reply is coming back.

 

OK, so if we look at the packet headers, we've got our Ethernet header, our IP header and then our ICMP header. So what we're going to do then, is block ICMP type of packets, and we can even get specific and block ping requests, ping replies, that type of thing. Let's go back to our server and configure Windows Defender Firewall accordingly.

 

OK, so we're back in Windows Defender Firewall with Advanced Security looking at Inbound Rules, where I'm going to create a new one. Last time we just modified an existing predefined rule. OK, so I'm going to right click on Inbound Rules, choose New Rule, and it's going to take us through a wizard. Do we want to create a firewall rule that allows or blocks connections based on a Program, a Port number, Predefined?

 

And there's quite a, an extensive Predefined list of common items like iSCSI, Active Directory Domain Services and so on. Or we can build a Custom rule. Here I'm going to choose Custom so we can see the options and I'll click Next. [Video description begins] The steps listed on the left are: Rule Type, Program, Protocol and Ports, Scope, Action, Profile, Name. [Video description ends] This does not apply to a specific app or program, so I'm just going to continue, Next. But the Protocol type is currently set to Any.

 

I'm going to open that up and choose ICMPv4. And I can even get more specific. I can go down and choose Customize and specify the ICMP types, for example, Echo Request. Maybe what I want to do is block that, so I'm going to go ahead and click OK. Next step, any IP addresses?

 

I'm not going to limit it to a specific IP, and when we get anything that matches these conditions, I want to Block the connection. I want to stop pinging. So I'm going to click Next. It's going to apply to all network profiles. [Video description begins] The Profile section includes: Domain, Private, Public. [Video description ends] Next. Block Inbound Ping Requests, that's what I'm going to call that rule, and Finish.

 

So in the list, if we go to the Bs, there's Block Inbound Ping Requests and it's got a do not enter symbol instead of a green circle with a white checkmark. Let's go back to our client and try to ping this server once again. So back on the client, I'll use the up arrow key once again and we are pinging, but we are getting nothing. And that's because we blocked it with our Windows Defender Firewall.

 

In this demonstration, I'll be configuring a firewall in Ubuntu Linux. Specifically, I'm going to be using ufw, the Uncomplicated Firewall. So to get started here, I need to verify whether or not that firewall service is up and running. Now the command I'm going to issue is going to require elevated privileges and I am not logged in as root as evidenced by the whoami command, I'm logged in as a user called cblackwell.

 

So I'm going to prefix my command with sudo because I do require elevated permissions. I'm going to run systemctl space status space ufw. Let's get the status of that service. It'll prompt me for my current user password, I'll enter that. And so currently, we have it showing as active (exited). OK. [Video description begins] The output also includes information about: Loaded, Docs, Main PID, Tasks, Memory, CGroup. [Video description ends] So what I want to do then, if I need to start that service, I can use the up arrow key again and bring it back up and I could issue the start command.

 

We can view the status again, again using the arrow key, so that's how that was started, but we can also stop the service using the same type of command set. So I'll use the up arrow key, and I will change it to be sudo systemctl stop ufw. And if we check the status again using the up arrow key, it is now inactive or dead as it says. So, we've stopped the firewall service.

 

OK, that's the first order of business with Universal Firewall. So what I want to do is I want to make sure I start it, so I'll use my up arrow key to go through our previous commands to the one that starts the service, and we'll just check our status just to make sure we know what we're doing, and it looks good. It's active. OK. That's what we want to see. Now, what we want to do is set some default configuration rules for our ufw packet filtering firewall.

 

I'm going to run sudo ufw default allow outgoing. So I want to allow outgoing traffic initiating from this host. Now we're going to change our incoming rules a little bit to this host, so I'm going to run sudo ufw allow ssh. It says rules were updated. And I also want to add a rule, let's say, for HTTP or HTTPS, so I could say, sudo ufw allow http/tcp. I could use port numbers, but the default port number of 80 is implied here.

 

So, this kind of nomenclature will work just fine. Once I've done that, the next thing I want to do is block all other traffic to this Linux server. If I were to run ip a, so IP address, I can see that this Linux host has an IP of 192.168.4.154. Let's see if we can ping that from another station on the network. So from a Windows host, I'm going to go ahead and ping my Linux host, and sure enough, we're getting a reply.

 

So ICMP traffic is allowed. [Video description begins] The Ping statistics read: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss). [Video description ends] Well, that shouldn't work in a moment, because we're going to deny all traffic inbound to that Linux host other than what we've allowed, which is SSH and HTTP.

 

So back here in Linux, I'm going to clear the screen and I'm going to run sudo ufw, Uncomplicated Firewall, actually default deny incoming, I have to make sure I've the syntax done correctly. OK, so at this point, let's just make sure; we can also do this, let's just make sure everything's still up and running. We can also run this command: sudo ufw status. Now, it returns that the Status is inactive.

 

Well, wait a minute. If I run sudo systemctl status ufw, it says active. Well, the service is running, but the firewall is not turned on. So for that, I can run sudo ufw enable. It says this might disrupt connections like your current ssh connection. Are you sure you want to proceed? I'll type the letter y for yes. OK. It says firewall is active and enabled on startup.

 

So, now if I were to do, let's say, an sudo systemctl status, we've got active, so we know that's running, but it's also, now the firewall is also enabled. So if we do sudo ufw status, now it shows information about what is allowed. Port 22 traffic, port 80 for IPv4 and IPv6 from Anywhere. But there's nothing here that will allow ping traffic, which uses ICMP. So, I'm still in an SSH session remotely right now, so we know that that's working.

 

Let's see if we can ping this host remotely, so I'm going to use my up arrow key, and it might seem strange that we can still ping the host, but really, it's not. What we have done is we have denied all incoming ports. So, we know that most network services use a port number; web servers are port 80, SSH is 22 and so on. Ping doesn't use ports, and so ping traffic is still allowed, but we want to block it.

 

So let's go back to Ubuntu and let's take a different approach, to make sure that ICMP packets are dropped. So here in Linux, I'm going to run sudo nano, I'm going to use the nano text editor to open up /etc/ufw/before.rules. What I'm really interested in here are all of the ICMP rules. Specifically, we've got one here for --icmp-type echo-request. So that's the ping request, and it is accepted.

 

I'm going to change that to the word DROP, and I'm going to press Ctrl X. Save modified buffer? Type in the letter Y and press Enter to write to that file. Now what I need to do is run sudo ufw reload, reload the configuration, it says Firewall reloaded. If we were to do an sudo ufw status, even verbose, let's see what we have, verbose. OK, so deny (incoming), allow (outgoing), and OK. Looks like we still have our existing rules. Now the change we made was in a config file, so it doesn't show up here, and that's fine.

 

Let's take a look now to see if we can ping this Linux host from another machine over the network. So I've switched back over to my Windows machine. We're going to try to ping the host and this time the ICMP echo request or ping packets are being dropped. And so now, ping no longer works. So that gives us a general sense of how to work with basic firewall rules, using the Uncomplicated Firewall in Linux.

 

Many public cloud providers provide packet filtering solutions. In Amazon Web Services or AWS, we have both security groups and network ACLs, network access control lists, otherwise just called NACLs. So we're talking about cloud-based packet filtering solutions that are considered to be a managed service. And what that means is you don't have to deploy an underlying virtual machine and install firewall software.

 

It's all taken care of for you. And this is considered Platform as a Service or PaaS, because it's a managed service. Now, depending on who you ask, some might consider it to be Infrastructure as a Service because it deals with network infrastructure and the allowance or denial of network traffic. That's fine as well. It really depends on whether it's a managed service or whether you have to set everything up yourself.

 

So let's talk about AWS security groups. In the AWS cloud, a security group can be applied to an EC2 instance, in other words, to a virtual machine. So you don't apply the security group to an entire subnet, it's for specific VMs. And the security group contains an allow list of what traffic is allowed into or out of a virtual machine, so it supports stateful firewall rules that look at the state of an entire session or connection, not just looking at individual packets as separate entities.

 

It supports inbound and outbound traffic. But what's interesting about a security group is it supports allow rules only. In other words, you cannot specify what should be denied. You only specify what is allowed. And there is no priority number to determine which rule gets checked first.

 

So here we have a screenshot of configuring an AWS security group. Notice that we have Inbound rules as a tab that can be selected, as well as Outbound rules. What's been selected in this screenshot is Inbound rules, and down below we have two Inbound rules that we're looking at. One is SSH, Port 22 from a specific Source IP address listed in CIDR notation, with the slash and the number of bits in the mask. [Video description begins] Source reads 24.142.51.137/32. [Video description ends]

 

So we are allowing a specific IP address to SSH into the server that will be associated with this security group. But we are also allowing HTTPS traffic destined for port 443 on this virtual machine that this group will be associated with, from any Source. The Source here for any in IPv4 is represented as 0.0.0.0/0.

 

But notice, nowhere do we specify whether these listings are for allowing or denying traffic. Because in a security group, it's implied that it's only an allow list. In AWS, you can also configure a network access control list or a network ACL. Now this contains allow rules and it applies to subnets, and it also contains deny rules.

 

So as opposed to a security group which can be applied to a specific virtual machine, a network ACL can apply to an entire subnet, which might contain many virtual machines. And so when you have many virtual machines on a cloud-based network with the same firewall needs, a network ACL makes more sense. Plus, aside from just allow rules, which is the case with security groups, you can also create deny rules to block specific types of traffic.

 

You can also assign a specific rule priority number for each rule in the ACL. So you can control how rules are processed, the order. The other thing to think about is network ACL packet inspection is just basically packet filtering firewall types of capabilities. In other words, the network ACL can look at the source and destination IP address, a source and destination port number, the protocol type.

 

So, you could say that it's an OSI layer 4 transport layer type of firewall. Here we have a screenshot of a network ACL. Now what happens here is we have a Rule number in the leftmost column. The Rule number controls the order in which these ACL rules are processed. So a rule with number 100 gets checked before 101, which gets checked before 102.

 

So rule 100 here is an SSH rule from a specific Source IP address, and it's set to Allow, because we have an Allow and Deny dropdown list for each individual rule. So what happens is that, if incoming traffic, because these are inbound rules, if incoming traffic is SSH and it's from that Source, then the rule will apply, the traffic will be allowed, and no further rule processing occurs because we matched the rule.

 

But if rule 100 does not match the inbound traffic, rule 101 will be checked for HTTPS from a specific Source. If that is the case, if that's the type of traffic coming in, then that rule will apply, will be allowed, no further rule gets processed. If those first two rules don't match the incoming traffic, rule 102 will be checked, and so on.

 

So network ACLs have Allow and Deny options, and they also have rule priority numbers to control the order in which the rules are processed. And so this is an example of how you might configure cloud-based packet filtering firewalls.

 

In Amazon Web Services, a security group is like a set of packet filtering rules. It determines what traffic is allowed to a specific virtual machine. So not a subnet, but an individual instance. So to get started here in the AWS Management Console, I want to start by going to ec2. EC2 is where we deal with virtual machines and everything related to them.

 

What I'm primarily interested in doing, first of all, is looking at the properties of an existing virtual machine instance. If I were to select one, for example from the list, then down below, under Security, if I scroll down and take a look, each virtual machine instance is associated with a security group, and there's a link here for it. [Video description begins] The link reads: sg-08097fd98f4796cce. [Video description ends] And if I click on the link for the security group, it takes me into its properties where I have a number of Inbound rules and Outbound rules.

 

So if I were to look at the Inbound rules, let's say, and choose Edit inbound rules, we have the Type of rule, so from the dropdown list, we can choose the Type of protocol. We can also specify if we want to get into custom configurations the Protocol itself, whether it's TCP, UDP, that type of thing, the Port range and the Source, such as where the traffic is coming from. But notice that all we have here are these options.

 

We really don't have the option of denying anything. You can Delete the rule from here, but you can't create a rule that specifically denies, because with security groups you are creating an allow list. So we're going to Cancel out of here, and what I want to do here on the left, we're still in the EC2 management console, is I'm going to scroll all the way down under Network & Security and choose Security Groups, where all of my Security Groups are shown. I want to create a new one, so I'm going to click the Create security group button in the upper right.

 

This is going to be for Linux VMs and I'll call it LinuxVMSStandard. And down below for the Description, I'm going to say Allow SSH, HTTPS, and further down I can specify the VPC where I want this to be associated. Now, I can click the X to remove that and select a particular VPC where I know I've got virtual machines that are deployed.

 

Of course, I associate it with the specific VMs after. [Video description begins] The security group is associated with the default vpc. The host expands the dropdown list and chooses vpc-08d2ba27f5e138d84. [Video description ends] Down below, I can click Add rule for Inbound rules, which I'm going to do. So I can specify from a number of items like Custom Protocol, TCP, UDP, ICMPv4, and even more, as I go further down the list. All the standard protocols; SSH, SMTP, DNS, POP3. So what I want to allow is SSH. So I'm going to add SSH 22, and I can specify from where.

 

Where's the location? It's currently set to Custom. We can also select here My IP. What it will do is read the IP address of the machine for which I am configuring this in the first place. [Video description begins] The IP currently reads 24.142.51.137/32. [Video description ends] And if this is my on-premises management station, then that's perfect. I'm going to click Add rule again, because I want to allow HTTP or HTTPS traffic if this host is running a web server.

 

Let's say HTTPS, it fills in TCP 443, and for that, I want to allow it from anywhere. For IPv4, anywhere can be specified with 0.0.0.0/0. Now those are Inbound rules. We can also create Outbound rules to determine what traffic is allowed to leave virtual machine instances, but I'm OK with just the default.

 

So what I'm going to do at this point is add a tag. The Name here is going to be Standard Linux Security Group and then I'm going to scroll down and click Create security group. So I'm going to go back to my Instances view and select a Linux instance, and I'm going to go to Actions, Security, Change security groups. Now specifically, I can select a network interface that I want the security group applied to. This is the NIC for the virtual machine in the cloud.

 

And down below, I have a list of security groups currently associated with that network interface, but I can add our new one; [Video description begins] Network interface ID is set to eni-084dafc1aeea222fd and the security group name reads launch-wizard-4. [Video description ends] or so you would think.

 

Our Linux security group is not in the list. And that's because, if we Cancel back out of here, and select our Linux virtual machine and go to Networking, it's associated with a different VPC than where we created the security group. This is a VPC that is associated with this Linux instance that ends with 875a.

 

So why don't we take a look at the VPC configuration here? And let's go to Your VPCs. So 875a, that's the default VPC. That's not VPC1 or VPC2. So it's important to track then where you deploy your security group, otherwise it won't be usable. So back into EC2, I'm going to deploy a Linux instance into the appropriate VPC.

 

When I say appropriate VPC, when we go to look at our security group, our Standard Linux Security Group, and we scroll down to view its Details, it's a VPC that ends with ID d84. So we could deploy a new instance, or, if we want to actually use that existing instance, the quickest thing to probably do here is to select the existing security group, go to Actions, Copy to new security group.

 

So I'm going to call it NewLinuxSG just so we can easily identify it; SG for Security Group. This is the VPC affiliation here. This is where I'm going to choose, let's say, the default VPC, and I'm just going to go and put in a Description [Video description begins] The default vpc reads: vpc-27ea875a. The Description reads: Allow SSH and HTTPS. [Video description ends] and in the bottom right I'll click Create security group. So now let's try this again.

 

If we go to our Instances view there's Linux1, I can select it, once again Actions, Security, Change security groups. And now when I go to my list of security groups, there is our NewLinuxSG, because the virtual machine that we are configuring right now is in the same VPC where that security group was created. So I'm going to go ahead and Save that change. And so now, if I select that VM and down below if I go to Security, the security group is associated.

 

In this demonstration, I'll be configuring a network access control list or a Network ACL in the Amazon Web Services cloud. A Network ACL is a list of traffic that is either allowed or denied from coming into or going out of a subnet in the cloud. So AWS security groups are allow lists to allow traffic into a specific instance or out of an instance, technically through a specific instance network interface.

 

But a network ACL works at the subnet level. So to get started here, I'm going to search for vpc in the console, because, to work with a network ACL or NACL, I do it from within the VPC console, meaning I'm going to scroll down on the left-hand navigator, under SECURITY, where I'll have Network ACLs. So I'm going to click on that.

 

Existing Network ACLs will be shown in the list, but I'm going to create a new one by clicking the Create network ACL button in the upper right. So you need to have planned this ahead of time properly, and thinking about the subnet association is important. For instance, if you have a lot of Linux virtual machines in a given subnet, that have the same firewall rules in terms of requirements, maybe they need to allow port 443 traffic for HTTPS, they need to allow SSH traffic on port 22.

 

Well, if they're on the same subnet, it's probably a good idea to use a NACL, a network ACL, with those rules, and assign it to that subnet. So I'm going to call this LinuxStandardAllowances, because remember, you can have deny rules within a network ACL. I'm going to tie this to a particular VPC upon creation. [Video description begins] The host chooses vpc-542e1a2e (VPC1) from the dropdown list. [Video description ends] The Name tag is already added, with a Value of what I've specified as the Name, LinuxStandardAllowances.

 

Let's just create the network ACL. And there it is in the list. So LinuxStandardAllowances. But of course, that's just the object itself. What about the rules within it? If I select that specific network ACL, and I need to make sure only one is selected here, down below, I can click on Inbound rules and see, and also Edit inbound rules.

 

Notice we have a default rule here for All traffic, All protocols, All Port range coming from anywhere, that denies by default. OK, so that's fine. I'm going to click Edit inbound rules. I'm going to add a new rule. Now you have to assign a rule priority number and the priority number, of course, determines the order that they are evaluated in.

 

So, a priority value of 10 would get evaluated for traffic coming in before 12, before 14, before 178, whatever the numbers are. So, it's important to think carefully about your rule numbers. Let's say we start at Rule number 100, and for the Type I could specify TCP, UDP, ICMP, IPv6 for ICMP, or just All TCP traffic, All UDP. And then there's a bunch of built-in items like for SMTP, DNS. Now, DNS (TCP) (53) would be for DNS zone transfers between servers where DNS (UDP) (53) is DNS client queries to the DNS server.

 

So we get a lot of built-in items here, but in this case for Linux, let's start with allowing SSH TCP port 22. Now the default Source is from anywhere, and in IPv4 that's notated as 0.0.0.0/0. Or I could specify whatever my network range is from my on-premises network insider format with the slash and the number of the bits in the subnet mask. [Video description begins] The host types 199.126.129.0/24 in the Source field. [Video description ends] And remember, we can specify whether this is Allow or Deny, which you can't do in a security group.

 

But this isn't a security group, it's a network ACL. I want it to be Allow. I want to add a second rule, let's say 101, and I want to allow HTTPS traffic come in. So there it is, TCP port 443, I'm going to use the same Source, so from my on-premises network, and I want to Allow that traffic. Now, in this case, does it matter if we check SSH or HTTPS first?

 

Really, it doesn't matter. When traffic comes in, rule 100 is going to be checked, and if there is not a match, if it's not going to TCP port 22, then the next rule gets checked. And the next rule, in this case, is 101. But if there is a match with Rule number 100 then it is put into effect, in this case it would Allow the traffic if it's coming from that Source, if there's a match, and no further rule processing would occur.

 

So let's save those rules to that network ACL, and we can make a change at any point in time. Those are just the Inbound rules that we've modified. Of course, we can also go and make changes to the Outbound rules. So here we've got Outbound rules that determine what happens with outbound traffic. So the default is that All traffic, All Protocol, All port and destinations is Deny.

 

If we want to change that, we can make a change. But for this example, I'm going to leave that as it is. So then I'm going to click subnet association. Which individual subnets are associated with this network ACL? There are none by default, but I can click Edit subnet associations and select one or more. So, what I might do then, is select an existing sub that I have, that I've called Public, which is where I'm going to deploy EC2 instances that are publicly visible, because they have public IP addresses, and you want to do that sparingly.

 

So once I've selected the subnet or subnets to be associated with the network ACL, I would save the change. And away we go. It's now Associated with that. Now the thing to bear in mind is a network ACL can be Associated with many subnets, but the opposite is not true, meaning, let's go into the Subnet. Here's the Subnet ID, it's a link. Let's go into that Subnet. [Video description begins] Subnet ID reads: subnet-d5a244f4. [Video description ends]

 

All right. So now we're looking at the Public subnet. If we go down to Network ACL, we can choose to edit the network ACL association, but you can only have one. Now, that sounded like an EC2 security group, remember, because an EC2 security group is designed to be associated with an EC2 instance. Network ACLs are associated with subnets. You can have multiple security groups associated with an instance, but only one network ACL associated with a subnet.

 

In this demonstration, I'm going to be working with the Microsoft Azure Firewall. So we're going to be configuring a packet filtering firewall in the cloud. Now this is going to be important because, as is the case with all firewalls, at least packet filtering firewalls, we want to be able to control what traffic is allowed or denied into or out of cloud resources.

 

So, the first thing that we have to do is take a look at our existing virtual network configuration in our cloud environment. So I'm going to go to the upper left and open up my navigator and scroll all the way down to Virtual networks. So, in my cloud environment, I have one virtual network; I'll just click Refresh here to make sure it's up to date, it's called vnet1, and if I click and open up that VNET, it's got a single subnet within it. The subnet is called subnet1.

 

So, we would have resources like virtual machines deployed into subnet1, and what we want to make sure is that we are protecting those resources like virtual machines, and only allowing the appropriate traffic in, such as perhaps HTTPS, if we're hosting a web server on one of those VMs.

 

Maybe allow inbound SSH for remote Linux management, inbound RDP for remote Windows management, whatever the case is. OK, so now that we know what we're working with, let's go back Home here and let's choose Create a resource and I'm going to type in firewall. And then from the list, I'll click Firewall and then I'll click Create. The Azure Firewall lets us work with standard packet filtering rules.

 

They're called network rules. Things, like we want to base traffic allowance or denials based on source or destination IPs, or protocol, like TCP, UDP, port numbers, that type of thing. Of course, the Azure Firewall can also allow inbound network address translation if you want to configure that kind of mapping, and it also allows you to control outbound traffic destined for certain DNS domain names.