How to Setup a Company Firewall

What’s the best way to set up a company firewall for your business? That’s the right question to ask once you’ve made a decision to protect the perimeter, servers, or endpoints on your network with a firewall. This is an often overlooked question because people assume that a firewall works right out of the box. It’s a common mistake to think that all that is needed is take it out of the box, plug it in, hook up the Internet cable and you’re protected. But you and I both know that is a mistake.

Setting up a firewall for your business can be a difficult project, but with reviewing the purpose, capabilities, and design you’ll be well on your way to building a firewall implementation strategy. With a strategy in hand, you can then push into the individual rules and configurations required to provide the right level of appropriate access, while not impeding on critical company productivity. Let’s start off slowly and then we’ll pick up the pace. If you want, you can jump ahead to the section with the heading where you want to pick up.

Index

• What is a firewall?
  Where should a firewall be placed?
  How does a firewall protect against threats
  Firewall Implementation Strategy
• 1. Block Inbound Port Connections
  2. Allow Inbound Port Connections
  3. Firewalls at the Endpoints
  4. Web Servers
  5. Web Applications
  6. DMZ / Web Data
• Firewall Maturity Perspectives
• 7. Perimeter Outbound
  8. Next Generation – Application Rules
  9 Decryption
  10. Air Gaps
•  

What is a firewall?

A firewall is a piece of security technology that controls the network traffic by applying rules to the communications like; direction, source, destination, protocol, application, time/date, size, and behavior. Newer and more advanced featured firewalls can do even more by going deep into the packets that make up the communication stream and inspecting them for malicious code. Other firewalls can forward traffic that contains files (like a PDF) to a sandbox for further inspection and testing. They forward to another technology that can take the time and has the resources to open the file and see if anything malicious happens. This is referred to as a sandbox. Some cases like file inspection, you want to the firewall to forward off to another tool, so that the firewall isn’t bogged down by chores and tasks that take it away from making traffic decision quickly. A slow down at the firewall can mean a slow down for Internet speeds, sending and receiving files, and cloud application processing among other things. A good firewall implementation strategy will include a progressive approach to enabling features on the firewall, starting with the foundational basics and building on that so that the firewall doesn’t cause the kinds of latency issues for the network users.

A firewall can take many forms. It can be a hardware appliance that is placed in a rack and plugged in. It can be a software firewall that is installed on a server or desktop endpoints. It can also be virtual, a software application firewall that runs likes an appliance.

 

Where should a firewall be placed?

Now that we know what a firewall is and the many forms it can take, let’s look at where it should be installed on the network.

External Perimeter

The firewall found its original home protecting the inside of the network, where your company data is, from the outside world that is connected by an Internet connection. We call the inside of the network the ‘internal’, and the wild Internet side the ‘external’. The firewall applies rules to network traffic effectively blocking traffic from the external Internet going to the internal network that shouldn’t be allowed. This direction of traffic from external to internal is referred to as ‘inbound’ traffic’.

(image)

Endpoint

Another area that is widely popular to place a firewall is at the endpoint. When we say ‘endpoint’ we mean a workstation or computer that somebody uses. Firewalls for endpoints are most often a software application package that is installed on the computer like any other software. Once installed they are configured to apply some basic rules that protect against known malicious traffic.

DMZ

A DMZ stands for ‘demilitarized zone’ and is used to refer to an area of the network that is protected in some way against the external network, and the internal network. A popular use for a DMZ network segment is to host data for the web servers. The web servers are external so that the users on the Internet can access them. The web servers sometimes need to query data from a file share or a database. It’s not good practice to host all your data on the external network. So you can build a segmented network referred to as a DMZ. Here you can install a firewall and build a rule to allow your external web servers to query data from it. And install another firewall on the internal side to allow data to be placed there by users on the internal network.

Applications

Another place a firewall is placed and grown in popularity is in front of your externally facing web applications. In the DMZ example above we referred to a web server. In this example think of that web server hosting a company built application instead of just hosting data. This could be a scheduling application, a job application system, it could even be an online ordering application.

For applications there is a special firewall called a ‘Web Application Firewall’, referred to as a ‘WAF’. This kind of firewall is placed in front of web applications to help filter and protect against Internet traffic that is attempting to do something malicious to the web application.

 

What does the firewall actually do to lower the threats against these resources?

To answer that question, we’ll walk through a good firewall implementation methodology we recommend at Asher Security. This methodology has the purpose of protecting company assets while not impacting productivity. By following this firewall implementation you can incrementally apply and test and ‘level-up’ your firewall strategy.

 

Firewall Implementation Strategy

 

1. Block Inbound Ports Connections

The firewall began by being a network security tool that blocked inbound connection attempts to ports. Ports can be thought of the answering service for a service or application. If you had an application like email hosted on your company network, you could attempt to connect to by the port it listens on for connections. For email, this used port 25. So if you called port 25, an email service would answer.

A good firewall strategy begins with thinking about all the services and applications available on your company network that you don’t want to be accessible from outside, the external, of your network. Often times, email would fall into this category. Based on this a new firewall rule would be created and applied to the perimeter firewall stating to block all inbound attempts form the internet to get to port 25. Because the purpose of this rule is to ‘block’ traffic it is referred to as a ‘DENY’ rule.

 

2. Allow Inbound Port Connections

A better approach, than building DENY rules, is to think of the applications and services you do want accessible from the outside of your network.  You’ll find this list takes a lot less thinking and consideration. Matter of fact, a great practice is to BLOCK all inbound traffic and then once you can think of a single service you want accessible from the external side, create a rule and apply it. Then test it out by making sure you can access that resource from externally. Then finish testing the rule by also validating you can’t get to other resources from externally. You want to verify that rule you created only opened up what you wanted it to open up, and needed to provide more access than what was necessary. This type of firewall rule is called an ‘ALLOW’ rule.

 

Should I Block traffic or Allow traffic?

The question of whether to invest your time into building DENY rules to block traffic, or instead to block everything and focus on rules that ALLOW what you need is an age-old debate. In the early days of information security, the technology and process started with blocking. The firewall came out of the box allowing all traffic and it was the administrator’s job to start creating rules to block things.

As time went on and security became more of a hot topic the philosophy changed. Firewalls and other applications, like Microsoft, started building a deny all philosophy. The idea was nothing was trusted to begin with, and you need to explicitly tell the firewall what should be allowed. This approach made a lot more sense and provides better security.

We recommend you do both. Why? Because firewalls are strange creatures and are only caring for them one way can cause problems you didn’t anticipate. Let me use an analogy. If you tried to train your children using an allow or deny methodology, which one would you use? I’m not saying your children are strange, but hopefully, you see the power in approaching this both ways.

 

3. Firewalls at the Endpoints

Your next step should be considered endpoint protection. Endpoints are the exploit vector for most hacking attempts. I could find some numbers and statistics to use here, but I’m not a fan of leveraging a research company’s data if I don’t know how that got it. I’ll just say its most. That’s really important to consider. If most hacking attempts exploit the endpoint then a large focus of your security strategy should be on protecting the endpoint.

We have a whole workshop dedicated to improving endpoint protection and building an endpoint security strategy.

Installing a firewall, from a reputable company, can provide an excellent risk return on investment. The endpoint firewall is responsible for developing a crucial change in the way a firewall historically worked. It changed the game from focusing on inbound attempts, to also looking at outbound attempts. That might not initially sound important, but it is. What was happening when someone got bad things that could be considered a part of the ‘virus’ family was that malicious software would implant itself than call out its mothership on the Internet for further commands or more software code.

Malicious software that makes outbound connections attempts could be:

• Command & Control Software – Listens and wait for further commands to execute
• Ransomware – Creates a back door to download code and encrypt your computer
• Backdoors / Trojans – Once installed create a back channel for hackers to execute code on your computer
• RAT or Remote Access Tool – Allows an external attacker to remotely get into and control your computer.
• Data Exfiltration – Ability to take data off your computer and send it to the Internet

All of the things we’ve listed above require an outbound connection. With a traditional, inbound blocking only firewall, once an attacker is in they can own you. Hackers referred to owning your computer as ‘pwned’.

 

Pwned: to own or to be dominated by an opponent or situation, especially by some god-like or computer-like force” – Urban dictionary

 

An endpoint firewall cannot be held solely responsible for preventing all those bad things from happening to your computer, but they can do a lot to help prevent it. Many of these firewalls packages come with rules right out of the box to prevent these popular hacking attempts and even include what we call ‘threat intelligence’ to keep track of known hackers addresses and block them when they see those addresses.

 

4. Protect Web Servers

Do you have an external website? Do you host that website with a server at your company network or do you pay another company to host it? If you host the website on your server(s), your next step should be to install a firewall or place firewall rules, in front of your web servers. The purpose of these rules is to allow users on the Internet to view all the beautiful and helpful web pages you have but prevent them getting to resources on the server that hosts the website that is not required.

Typically this is a very easy rule set to build for your webservers. Websites use a ‘protocol’, which is just an agreed upon technology language, called ‘HTTP’. HTTP traffic is most commonly hosted on port 80. With the maturity of security, this traffic has been encrypted using ‘SSL” or secure sockets layer. This type of traffic takes the traditional HTTP and encrypts it making it ‘HTTPS’. You’ve probably seen this with the lock icon in the web browser, or the ‘https://’ before the website name in the URL box. Create a couple of firewall rules to allow this type of traffic, and block everything else is pretty straight forward and will allow for a great gain in protection.

 

5. Web Applications

If you host external web applications on your web servers, the next step you should consider as part of your firewall implementation and security strategy is to protect them with some solid firewall rules, or a job specific firewall like the web application firewall (WAF) referred to above.

The WAF takes the role of a firewall to another level. Remember when endpoint firewalls level-up’d the game on blocking outbound? Well, WAF’s level-up protection again by going beyond the network communication layer and looking into the application layer of the traffic. Let’s pause here for a second and explain what we mean.

 

How do computers talk to each other?

They use layers. Think of this as humans starting with a very basic level of communication such as the physical nod of yes or no. Then progressing to audible sounds like yes and no. Then progressing further to verbal sentences and questions and conversation. Then the ability to write a message back and forth. Computers talk in layers. They use a layer model called the OSI Model.

 

OSI Model: Open Systems Interconnection Model is a conceptual model that characterizes and standardizes the communication functions of telecommunication or compute system though regard to its underlying internal structure and technology.” – Wikipedia

 

The OSI model has seven layers. Traditional network firewalls focus on inspecting communication traffic at layers 3 and 4. The WAF takes this step further and examines traffic at layer 7. At layer 7 it can look for malicious attempts that target application servers. These attacks include:

• Denial of Service – Receiving so much data it will overload your systems and cause them to be unavailable.
• Cross-Site Forgery – Attack that forces a user to execute unwanted actions
• Cross-Site Scripting (XSS) – Malicious scripts injected into websites
• SQL Injection – Putting computer code into your application to get data or cause unexpected results.

A properly configured WAF can greatly reduce the risk of your web applications being exploited. Some of the risks focus on the availability of your web application, but the more severe risks actually focus on the security of the users using them. That is definitely something you want to secure and protect.

 

6. DMZ / Web Data

Once the front end of your web services (representing web sites and web applications) are protected you should pivot and start to consider how to protect the data behind the servers, and protect and secure the vector that allows data to be moved from your internal network to your web services.

When you start to examine the purpose of the web services you’ll find that if they need to be updated from someone in your company (unless externally hosted). The process of updating the websites, or updating the data that is being provided through this communication vector needs to get there somehow. This is a critical vector to examine and protect.

Often what we find when we take a look at this process is that there is a handful of people within the company that have the role of updating web data. These are website administrators, developers and database administrators.

The other observation that is critical to making for this situation is that data should only be allowed to move in one direction, from the internal network to the external network. It is critical to prevent data from moving from the external web servers into the core network (internal). If this was allowed, an attacker could get data, plant malicious code, install scripts, and a host of other malicious attempts. The image that comes to mind is a self-serve ice cream machine at a buffet. When the lever is pulled ice cream comes out. It is a one-way system. If you could push the lever up and it could suck ice cream back in from your bowl, then a malicious user of the ice cream machine could cause other bad things to be sucked into the machine. This could damage the machine making it unusable, or worse yet, cause bad stuff to be dispensed for other self-serve users causing sickness or even death.

A common strategy we recommend for a DMZ is to have a firewall in between the web services and the data storage (file share or database) with a policy to only allow data to be pulled from the approved and associated web services. Block any direct Internet connection attempts. If the data is going to be pulled, it needs to be only through the approved web services. Then a firewall between the data storage and the core network where the users are that update the data. Apply a rule that only allows data to come from the internal network and go to the data storage locations. Block any attempts to move data from the data storage to the internal network. In addition, add all the users that should be performing this role to a group. Then apply that group to the right to perform this data movement. This way, if an attacker is able to get into your network they will not have an open door to move the data to the data storage DMZ, and then get it to the Internet. The attacker would have to exploit a user that has this privilege. Again, this ruleset will greatly reduce the risk of this data being exfiltrated, corrupted, and causing malicious code and virus from getting into your network.

Status Check

At this point, you’ve implemented a great starter program for security using firewalls. You’ve applied basic inbound blocking rules and complimented them with carefully considered inbound allow rules. Then you protected your endpoints against popular exploits they could get while on the web. You’ve created and applied standard blocking rule sets for your Internet web servers and also implemented web application traffic firewalls to prevent exploits and attacks at layer 7. In addition, you’ve created directional rule sets for a DMZ so that you can host data through applications and not allow those Internet vectors to be used maliciously to connect to your internal core network.

When the endpoint firewalls were implemented we up’d the game by moving from inbound only rules to outbound rules.

When the WAF’s were implemented you leveled up by moving from layer 3 and 4 to also protecting layer 7 traffic.

At this point, before we progress on the next step in a firewall implementation strategy we should stop and review the firewall maturity references below and decide what your next biggest goal and motivation is to protect your company and your assets.

It’s easy to become pigeon-holed and do what someone else thinks is best for you. But your actions should be driven by your risk. When we consider how firewalls can be implemented on a maturity scale it can be helpful. We can see that maturity in security controls can be driven by different risk motivators. Let’s take a look.

 

Maturing your firewall based on ‘best practice’ will give you a ‘control perspective’.

Firewall Maturity (Control Perspective)

Level 1: Perimeter Inbound

Level 2: Endpoint Inbound & Outbound

Level 3: Web Services Inbound & Outbound

Level 4: Perimeter Outbound

Level 5: Application Rules

Level 6: Decryption

Level 7: Air Gaps

 

Firewall Maturity (Threat Perspective)

Level 1: External Threats (hackers)

Level 2: Internal Threats (Ignorant Employees)

Level 3: Internal Threats (Malicious Employees)

Level 4: Integration of Threat Intelligence

 

Firewall Maturity (Risk Perspective)

1. Core Network
2. Web Services
3. Critical Assets & Applications
4. Crown Jewels (Data = Sensitive & Confidential)

 

We recommend taking the approach of focusing on your risk and then decreasing that risk by focusing on the biggest threats to that risk.

To successfully do this apply basic controls to prevent external threats from getting to your core network, then your web services. Once this is done, and this is where we are at in this article, then you move up in maturity by pivoting to protecting your critical assets and finally crown jewels from insider threats. As you mature to this level your rules become more complex because of how specific they become. We also start pivoting to governance practices to protect the integrity of these rules, who can change them, how they can change them, and protecting the accounts associated with these privileged changes.

This efforts also becomes more difficult because identifying, discovering, and classifying sensitive and confidential data is a lot of work. It is worthy work, it’s just a giant pain… I mean undertaking.

You also move your focus from external to insider threats. The reason is, one of the biggest causes of data breaches are employees doing something stupid. The other reason is that a mature hacker (a really good one) will look just like an employee. They will focus on exploiting the user. They will leverage their credentials to elevate their privileges and get the data they want, and then exfiltration out of the network. So by maturing your security to focus on internal threats, you’re actually winning two-fold by also working to detect mature external attacks.

If you agree with this security strategy your next step is to put the time and work into identifying what your most critical assets and applications are. Once you have this list prepared in some type of priority based system, then you can leverage this to begin to move your firewall security strategy from inbound penetration prevention to outbound data exfiltration prevention. The following steps are focused on the prevention of data leaving your company network from malicious or ignorant attempts.

(Section on identify, prevent, detect, respond?) How anomaly detection is detection? Lead to that article. Use detection for future protection.

 

7. Perimeter Outbound

Circle back to your perimeter firewall and add rule sets that focus on the prevention of outbound network communications. For example, do you want an end user to be able to initiate a remote desktop connection to another computer outside your company? Can an employee make an outbound FTP connection to a server on the Internet? Work with technology managers to have a discussion and discovery session on what outbound calls to the end user computers need to make. Document this, create a universal (for everyone) and then test this rule on a handful of end users. Monitor the logs and be in continual conversation with the end users to see if this disrupts their productivity or causes side effects. If the rules have the desired outcome then apply the rules to a larger user base. Continue this process until it’s applied to everyone, specific exceptions need to be, and for other outbound services.

 

8. Next Generation – Application Rules

Remember how web application firewalls were able to interrogate layer 7 traffic?  Well, one of the biggest and greatest evolutions in firewall technology has been something referred to as ‘next generation’. This technology is able to build rules around how specific applications, not just the ports, behave. The biggest advantage of this is applying rules to web applications and being able to differentiate between them and how and what they are allowed to do. Let’s take a look at an example.

Traditional firewall – Block outbound FTP on port 21

What if the malicious attacker gets denied trying to FTP the data out, what will they do?

They will try another service.

Traditional Firewall – Allow outbound on port 80 and 443

These are the ports for Internet browsing websites, and the secure versions of those websites. This HTTP service has grown in popularity and use over the last decade and can now be used for much more than just read a website. IT can be used to leverage web applications like Gmail, DropBox, and Evernote. All personal services that allow you to transfer data. What if you want company users to able to browse the Internet, but not upload data to these services? Traditional firewalls cannot support this type of advanced rule creation. There is a solution…

Next Generation Firewall – Allow outbound Internet Browsing / DENY Gmail, DropBox, and Evernote.

This type of rule on a Next Generation firewall will allow your users to continue to browse the Internet but prevent them from using that access to get too personal web services listed int eh rule, like Gmail.

 

What if I want my users to see Facebook, but not post on it?

 

Next Generation firewalls also allow you to create behavior rules on how applications are used. So you can now allow someone to go to Facebook and ‘read’ but deny the ability to ‘write’. Isn’t that amazing?

 

What if I want some users to write, but prevent others from posting?

 

With next-generation firewalls, you can include identity in the rule sets. So you can tie the firewall in with your user directly and coordinate rules with users, and user security groups. Effectively you can allow some users to perform actions, and block others. We’ve seen this be applied in so many ways, but one specific example that comes to mind is allowing a couple approved users from Marketing to post to the companies LinkedIn profile, and blocking all other users from posting to social media sites.

There are so many ways to develop a next-generation firewall rule set, otherwise known as ‘policy’. This full scope of this is large and outside the scope of this article. But hopefully, you can get an idea on when and how this powerful tool can make an introduction into your firewall implementation strategy.

 

9. Decryption

Without getting into the technical complexities here, we do need to spend some time to point out that to effectively build a firewall policy that helps lower the risk of data exfiltration you will need to decrypt some of the data. Remember that HTTPS? That is secure, or encrypted, traffic. Because it is encrypted your firewall will not be able to read it. If it can’t read it, it cannot interrogate it and effectivity apply the correct security controls that you’ve set up in your firewall policy.

Most next-generation firewalls allow you the ability to decrypt traffic. To do this you will need to follow the manufacturers guide on how to set up the secure certificates. After that, you will be on your way and be able to decrypt. The biggest point we want to make in this article on this very mature step of firewall implementation is this:

Decryption takes a lot of processing power.

That means that by turning on decryption you run the risk of impacting productivity by reducing the firewall speed and availability.

This is the biggest reason we recommend you invest in classifying your sensitive and confidential data before applying this control. When you know specifically what data you’re trying to protect, where that data is, and who currently has access to it, then you can build specific decryption rules that allow you to apply security controls to it, and the applications that leverage it. When you don’t have that level of specificity, people tend to build generic companywide rules that will tax the firewall and cause it to be overworked, slow, and risk it not working at all.

By approaching the decryption from an application specific approach, based on a data specific approach, individual rules can be created, applied, and monitored. Then like other processes, rinsed and repeated. This will allow to progressively add protection to your company data while monitoring the health of your technology resources and preventing a production outage.

 

10. Air Gaps

This is the oldest firewall method in existence. If you have data that has tight controls over who can access it, or when it can be accessed, or the integrity of the data, please don’t forget to consider if it can be air gapped.

Air Gap: an absence of a direct or indirect connection between a computer and the Internet, effected for security reasons.- Dictionary.com

An example of data that should be air-gapped is critical system backups. If your network is exploited by an attacker, it’s great to have your critical data in a place, like a secure closet, that an attacker cannot get to.

Caution about Firewalls

Firewalls can play an important role in the protection of these assets and applying these controls, but they are not meant to do it alone. This article is focusing on the role of the firewall and an implementation strategy you can use to mature into. But is important to note that we recommend using a defense-in-depth strategy ta twill leverage other security controls to reduce, remediate the threat the threats to these assets. One of many of those controls might be a backup and recovery solution.

 

Summary

Firewalls can be a critical security control component to protecting your companies computing resources and your company’s data. They are fundamentally a ‘protection’ control. When you look at a security framework, specifically the NIST Cybersecurity 2.0 Framework you will see that ‘Protect’ is one of five pillars of security. Once you have implemented a firewall strategy and effectively applied the security controls, you should start to ask how firewalls can also be used in other pillars of the security program like ‘Identify’, ‘Detect’ and a process to leverage this technology to ‘Respond’.

By including Threat Intelligence feeds, forwarding firewall logs to a dashboard for visibility and turning on the Intrusion Prevention Detection you can build more improved rule sets to further develop your security protections.