pfSense Fundamentals - Secure Networks With pfSense Firewall

pfSense Firewall

Firewall Refresher

If you're already familiar with firewalls, this lesson is supposed to be a refresher. If you're not, this may be a lot of information and be quite high level. If you're new, bear with me, things will be explained as you go through the course.

The term firewall used to refer to a wall, often concrete or brick, designed to keep fire from quickly engulfing an entire home or complex. It can also refer to a piece of metal separating the passenger compartment from the engine compartment on an aircraft or in a car.

In that sense, a network firewall performs a similar task. If an area of a network such as the Internet is untrusted, traffic isn’t allowed in from there, except in very controlled circumstances.

In relation to networking, I envision a firewall to be more like a check-valve than a wall though.

A check valve lets air or fluid flow in one direction but not another.

One classic place for check valves is between your residence or business and a city sewer system. You want your waste water to flow out from your house to the city sewer system, but you do not want overflow or pressurized waste from the system flowing into your home!

We want traffic from our computers to get to the Internet, but we do not want unrequested traffic from the Internet on our home or business networks.

A firewall will permit all outbound traffic, that is from your home or business to the Internet, or only traffic you specify, and will only let return traffic associated with that request back into your network. There are controlled exceptions such as Virtual Private Network (VPN) connections, but we’ll cover those cases separately.

A firewall deployed in this manner is known as a perimeter firewall. It protects your network perimeter or the boundary between your internal network and the Internet.

pfSense, or any firewall, can be deployed internally as well. On corporate networks, you may have different network segments segregated into zones, with some zones requiring greater protection or having less trust than other zones.

The boundary between these zones could be guarded with pfSense firewalls.

Whatever the configuration pfSense is deployed in, the firewall functionality works the same.

pfSense is a stateful firewall. It keeps track of connections requested internally, and maps those to the replies from external servers. It keeps track of these transactions in state tables within the firewall.

When my computer wants to request information from a server on the Internet, like asking Google to find sites matching my query, the firewall will keep track of what computer asked for the request. It will permit the request to go to Google, and keep track of what IP Address the response should be coming from and permit the reply to go to the requestor.

The two components that allow this traffic are the IP Addresses of the requestor and the server, and the TCP port numbers.

If Network Address Translation (NAT) is in use, the firewall will send the request on behalf of the internal requesting device, keeping track of what internal IP address made the request so it can forward the reply to it when it is returned.

pfSense performs many additional functions you would expect from a modern firewall like Intrusion Detection System / Intrusion Prevention System (IDS/IPS), Domain Name System (DNS) filtering, web content filtering, and much more.

The two options for IDS/IPS are Snort and Suricata. Both will be explained later in the course.

If you’re not familiar with these terms, there will be further lessons on them later in the course.

For those of you already indoctrinated in networking, you’re ready to carry on!

References:

Brick wall photo by Martin Vorel, downloaded from Libreshot:

https://libreshot.com/old-brick-wall/

Checkvalveopen: By Original:MionVector:Chris828 - Own work based on: Checkvalveopen.png, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=5959456

Check valve Wikipedia page:

https://en.wikipedia.org/wiki/Check_valve

Network Firewall image by OpenClipart-Vectors on Pixabay

https://pixabay.com/vectors/firewall-fire-burning-computer-156127/

Firewall (computing) Wikipedia page:

https://en.wikipedia.org/wiki/Firewall_(computing)

pfSense Firewall

Perimeter Firewall

This course will focus almost exclusively on using pfSense as a perimeter firewall.

We will explore using the Opt interface as a Demilitarized Zone (DMZ) to protect a web server, but the primary focus will be on protecting your infrastructure by using pfSense at the Enterprise Edge or between your home or business network and the Internet.

In its role as the gatekeeper at the boundary between your home or business and the Internet, we’ll be taking advantage of some of the awesome features available to us to detect and stop potential threats.

We will configure the following built-in features and add-on services:

• IDS/IPS

• Snort

• Suricata (Use only one or the other)

• Bogon Filtering

• pfBlockerNG DNS Blacklist (DNSBL)

We’ll also cover installation and configuration, tuning out false positives, backups, and more.

Optionally, you can complete the pfSense lab section and create your own lab using VirtualBox. If you choose to do this, you’ll be able to experiment all you want without worrying about taking your family or business offline as you try out new features. You can then deploy your new and tested feature to your live pfSense firewall.

If you’d like greater detail on anything covered in this course, or just a greater understanding of pfSense, I highly recommend the pfSense Book available for free in web form or as a .pdf.

It is written by Chris Buechler and Jim Pingle. Chris is a founder of the pfSense project and Jim is a Netgate employee with many years of FreeBSD experience. The book is kept perpetually updated. A rare and valuable commodity in the world of IT documentation where books become out of date before they’re even published.

The link is in References below.

References:

pfSense Book (This is free and highly recommended)

https://docs.netgate.com/manuals/pfsense/en/latest/the-pfsense-book.pdf

pfSense Course

Installation Options

This lesson covers the installation options available to you for pfSense.

Whether you want pfSense for your home, small office, enterprise, or cloud, pfSense has you covered.

For home or small office environments, you could install pfSense on some old hardware you had laying around in your basement, or you could buy a really cost effective pre-installed hardware device from netgate. A Netgate-1100, adequate for most home users, will protect your home for $189 US dollars. Netgate is the company that sells pfSense+ and pre-installed pfSense hardware appliances.

To install to hardware, or for a virtualized environment, you’ll want to download the netgate-installer-amd64.iso image.

To do this you would, go to pfSense.com and click on Download. You would download the latest stable version.

If installing from the downloadable installer image, it is compressed when downloaded, so you’ll have to uncompressed it before you can use it to install pfSense on hardware or in a virtualized environment. Virtualized environments include vmWare, KVM, Xen, Proxmox, or VirtualBox, to name but a few. We’ll cover installing to VirtualBox, free virtualization software, later in the course.

If your infrastructure is in the cloud on Amazon Web Services (AWS) or Microsoft Azure, there are pre-built images you can use to protect your cloud environment.

There are fees for the AWS or Azure solutions as they run pfSense+, a version of pfSense with support and some options commercial users may appreciate. pfSense in the AWS Marketplace runs from 12 cents to 45 cents per hour, and Azure instances start at one cent per hour to 10 cents per hour, with optional monthly pricing available.

If you purchased a pfSense firewall hardware device from Netgate, it comes with pfSense pre-installed, and you can keep it up to date through the web console. If you ever have to re-install, you can do so using the .iso installer.

An .iso installer image, cloud based appliances for Amazon Web Services, or Microsoft Azure, or a Netgate optimized image preloaded on your Netgate purchased hardware are your installation options for pfSense.

That covers the installation options for pfSense.

pfSense Course

Installation - Hardware Requirements

This lesson covers the minimum recommended hardware for pfSense to run properly.

At a minimum, you’ll need a 500 Megahertz Central Processing Unit (CPU) with 512 Megabytes of Random Access Memory (RAM), but a 1 Gigahertz CPU with 1 Gigabyte of RAM is recommended.

You can, if you want, use hardware that’s almost 20 years old to run pfSense! 1 Ghz processors came out in 2000.

If you have old hardware, it will very, very likely be able to run pfSense. If this is for home use, and you don’t mind circumventing your firewall while you look for replacement hardware in the event of a failure, use what you will. If this is for a business, you may want some fairly modern, reliable hardware.

pfSense provides some guidance about use of some of the features available that will work better with newer, more capable hardware.

VPN - If you want to leverage Virtual Private Networking or VPN to connect to your home or office securely you’ll want a beefier CPU.

Captive Portal - Locking down who can do what on your network with Captive Portal can likewise need a more powerful CPU.

Large State Tables - Many network interactions for the firewall to track will require more memory. Large state tables are a result of either more users, or of huge numbers of connections by individual users.

Packages - Some packages available require more CPU and RAM. The Snort Intrusion Detection System / Intrusion Prevention System (IDS / IPS) is one example.

The Network Interface Card or NIC you choose is as important to the maximum supported throughput of your firewall as CPU and RAM. You’ll want at least two NICs for pfSense to be set up in the most common configurations.

pfSense recommends Intel cards or systems with built in NICs up to 1 Gigabit Per Second (Gbps). You may want to learn more about available options if you need throughput better than 1 Gbps.

As a rough guideline, with no packages installed, pfSense recommends the following minimum hardware to produce the desired throughput listed.

• 10-20 Mbps - Intel or AMD CPU of at least 500 MHz

• 21-100 Mbps - 1.0 GHz Intel or AMD CPU

• 101-500 Mbps - Intel or AMD CPU at 2.0 GHz or higher with PCI-e network adapters

• 501+ Mbps - Multi-core 2.0 GHz of higher CPU with PCI-e NICs

If you are using pfSense to protect your internal infrastructure including traffic within your wireless or wired networks, you’ll want a robust system.

For a detailed list of what hardware is compatible with FreeBSD, see the latest FreeBSD hardware compatibility list.

To summarize, while you can run on hardware that’s quite old, you’ll want more modern hardware for corporate systems and for higher throughput, or for using additional features on your device like VPN, or packages like Snort IDS/IPS.

pfSense Firewall

Installation - Lab Environment with VirtualBox

One way we can set up an entire lab to learn to use pfSense in is by using virtualization software like VirtualBox.

VirtualBox is maintained by Oracle and it is free and available for Windows, Linux, and MAC OS X. That should cover anyone taking this course. You can download it at https://www.virtualbox.org.

Virtualization software lets you run an operating system within an operating system. The operating system you will run inside VirtualBox is called a Virtual Machine or VM.

You can download pfSense as an .iso image, then boot your VM to that, to install pfSense as a VM.

You can also put other Windows or Linux VM’s on VirtualBox, and have them behind or inside your pfSense firewall.

You can set all of this up for free, so please give it a try.

You’ll see how to install VirtualBox on Windows and MAC OS X in the next lesson. The process is very similar for installing on Linux.

Don’t worry if you’ve never been exposed to virtualization before and this doesn’t make sense to you right now. You’ll understand as you proceed through the lessons.

Even if you plan to install directly to hardware, please consider learning VirtualBox as understanding virtualization can server you well in the future, whether you’re a home user or an IT professional.

pfSense Course

Installation - Installing VirtualBox

You want to run another OS, but you don’t have any extra hardware, and you don’t want to overwrite or dual-boot your Windows or MAC computer. What to do?

Use VirtualBox! It’s free software that lets you run multiple operating systems within an application on your existing computer.

It’s available for Windows, MAC OS X, Linux, and Solaris. That covers any operating system you’re likely to be using.

Once you’ve tried a virtual environment, installing on hardware seems slow and painful.

Many server infrastructures are virtualized, running on VMware ESXi, Microsoft HyperV, or are in the cloud on Amazon Web Services, DigitalOcean, or a similar provider.

Taking a moment now to learn VirtualBox increases your options for trying new operating systems and practicing new things yourself, and can make using virtualization software at work more understandable.

The Operating System you install the downloaded VirtualBox software to is called the Host. The systems you install are virtual machines, or Guests.

Virtual machines are often abbreviated as VM’s.

So, let’s get VirtualBox installed.

Download the appropriate package for your operating system from https://virtualbox.org/wiki/downloads.

Once it’s downloaded, browse to the file. It will probably be in your Downloads folder, unless you typically download to another location or moved it.

I’m showing the steps for MAC OS X here, but it will be similar for other operating systems.

For MAC OS X, double click on the VirtualBox…dmg file to start the installation process.

Your MAC will verify the integrity of the downloaded file.

The VirtualBox installation window will open. Double click on VirtualBox.pkg. 

Your system will verify the integrity of the VirtualBox.pkg file.

A window will open asking you to run a program to determine if the software can be installed. Click on Continue to continue the installation.

In the Install Oracle VM VirtualBox window, click on Continue.

Enter your username and password if prompted and click Install Software.

If the installation was successful, click Close to close the installer window.

Under Number 2 in the VirtualBox window, double click the Applications folder to open it and browse to VirtualBox.

Double click on VirtualBox to launch it.

You can also launch it from Launchpad.

For Windows, double click the executable you downloaded and follow the default installation prompts. Then open it as you would any other application.

On a Windows install, consider right clicking the downloaded executable and installing it as Administrator. I haven't had it happen myself, but I had one student report grayed out permissions when he was trying to select a certain network setting. Installing as Administrator will minimize your chances of encountering this error.

You’ll see how to install new virtual machines and work with them in upcoming lessons

pfSense Installation

Adding a pfSense VM to VirtualBox

In this lesson we’ll install pfSense as a Virtual Machine on VirtualBox.

Let’s do this step-by-step.

Go to https://www.pfsense.org/download/. Select AMD64(64-bit) for Architecture, CD Image (ISO) Installer under Installer, and select a Mirror close to your location. A Mirror server is just a server with the same content as another allowing you to download from one geographically close to you.

Remember where the file downloads to and its name, or where you typically find downloaded files like your Downloads folder.

Unzip the file. How you do this will vary slightly depending on your operating system but if you have a Graphical User Interface (GUI), you can probably right click on the file and select an option like Extract Here, or find a Zip or 7Zip menu allowing you to extract the contents.

Open VirtualBox and click New in the upper left.

Create a sensible name, choose BSD for the type and FreeBSD (64-bit) for the Version, then click on Continue.

If you have plenty of memory available, I recommend bumping this to 2048 MB or 2 Gigabytes then clicking Continue.

Leave Create a virtual hard disk now selected and click on Create.

Leave Hard disk file type set at VDI (VirtualBox Disk Image) and click on Continue.

Leave Storage on physical hard disk at Dynamically allocated and click Continue. (This means the disk will appear to grow in size as you use more space, saving space on your host systems hard drive until it is needed).

Leave File location and size at their defaults of a folder named after your machine name and 16.00 GB for hard drive size if you have enough space and click on Create.

Your new VM is created and waiting to have its operating system installed. There are a couple of changes we have to make first before booting though.

Right click on the VM and go to Settings.

Click on Storage and the CD/DVD that says Empty in the left pane.

Click the CD/DVD Icon next to the Optical Drive window and browse to your downloaded .iso image file.

Now click on Network. For my system, things work most smoothly if I change Adapter 1 from NAT to Bridged Adapter.

Click on Adapter 2. Select Enable Network Adapter and under Attached to: select Internal Network. Then click on OK

Now double click on your newly created and configured VM to boot to the .iso image you downloaded.

You’ll see a bunch of text scrolling by as the setup script starts installing pfSense.

[NOTE] To escape from the VM and get your cursor and keyboard back to the Host OS, hit Ctrl-Alt on Windows or left Command on MAC OS X. To get back into the VM just click in it with your mouse.

When it gets to the Copyright screen, hit Enter to accept.

When the Welcome menu opens, leave Install selected and hit Enter.

Leave Continue selected and hit Enter.

For keyboard type, leave it at default, or if you need a special keyboard, hit the down arrow to find it and spacebar to select it then tab down to Select and hit Enter to continue.

Leave Auto (UFS) selected under Partitioning and hit OK to continue.

Under Manual Configuration, hit Enter with No selected to go to the next screen.

When you get to the Complete screen, tab over to Shell and hit Enter to exit to the Shell prompt.

At the Shell prompt type shutdown -h now which tells the system to perform a shutdown then halt instead of rebooting. If you don’t do this, the system will reboot, and you’ll be caught in an installation loop because you didn’t eject the virtual CD yet.

When it says Please press any key to reboot. click on the CD/DVD in the lower right of your VM’s window and select Remove disk from drive.

Click back into the VM and hit Enter to reboot.

You’ll see text scrolling by as the VM boots to the newly installed operating system.

That’s it for now. Good job!

pfSense Firewall

Virtual Lab - Installing Ubuntu

In this lesson, you’ll install Ubuntu into your Virtual Lab.

You’ll want an operating system with a graphical user interface or gui in your lab so you can manage your firewall via the web browser.

Installing Ubuntu Desktop will fulfill that role.

First a description of our network topology for the lab.

We’ll have pfSense installed as a virtual machine with two NIC’s installed. One will be bridged or NAT’ed with the hosts adapter, and the other will be configured on an internal VM only network.

The bridged interface will be the WAN interface and internal interface will be the LAN interface on the firewall.

You can download a Windows VM if you prefer. Even if you’ve never used Linux Desktop, you’ll find some of the lessons easier with a Linux VM than with Windows. However, it’s your choice.

Download an Ubuntu desktop image from the link below.

I’m showing how to install on a MAC OS X, but the process is nearly identical across platforms.

Remember where it downloads to because you’ll need the .iso file during installation of your vm.

Open VirtualBox and click on the New icon to create a new Virtual Machine.

Select an appropriate name.

Under Type, select Linux.

Under Version, choose Ubuntu (64-bit).

Click on Continue.

Set memory to 2048 MB minimum.

Leave Create a virtual hard disk now selected and click on Create.

Leave VDI selected and click on Continue.

Leave Dynamically allocated selected and click on Continue. This means drive space will be as small as possible to accommodate the actual data stored and will grow as needed.

Set size at 20 GB and click on Create.

Right click on the newly created VM and select Settings from the menu.

Click on Storage.

Under Controller: IDE, click on the Empty disc icon.

On the right, click on the Disc icon and select your image from the menu. If it is not there, click Choose Virtual Optical Disk File, and browse to the .iso you downloaded earlier.

Click on the Network icon.

Change Adapter 1, Attached to: to Internal Network.

Click on OK.

Double click the VM to start the installation.

In the Install screen, click on Install Ubuntu.

Keep defaults with the following exceptions.

• Chose Minimal Installation under Updates and other software.

• Under Installation type, click the box to use LVM with the new Ubuntu Installation.

Complete the installation and make sure you can ping the firewall at 192.168.1.1 or the IP Address you’ve assigned.

When connecting to the firewall with a web browser, click past the warning about a self signed certificate and you’re in!

The username is admin and the password is pfsense.

We’ll reset the password in the next lesson.

References

Download Ubuntu 18.04 Desktop iso

https://www.ubuntu.com/download/desktop

Download Windows vm

https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/

pfSense book

https://docs.netgate.com/manuals/pfsense/en/latest/the-pfsense-book.pdf

In this lesson, you'll look with me as we troubleshoot and resolve a simple DNS issue.

pfSense Firewall

Installation - Enabling SSH

After you have done the initial setup and added DNS Servers to your DHCP configuration, the next thing I recommend doing is enabling the Secure Shell or SSH protocol.

Even if you don’t have much, or any Linux or BSD experience, I recommend enabling this so you can get to the FreeBSD command line on your pfSense Firewall if you need to.

Although virtually all management tasks can be completed via the web interface, and I encourage you to manage your firewall through it, some some things are much easier to do at the command line.

One example is resetting your pfSense password. This will be covered in the Troubleshooting section.

Enabling SSH is simple. Click on System, then Advanced. Scroll down under Admin Access and look for the Secure Shell section.

Check the box that says Enable Secure Shell.

Leave SSHd Key Only set to Password or Public Key for now. Configuring key based authentication will be covered in the optional Enabling Public Key Authentication section toward the end of the course.

Leave Allow Agent Forwarding unchecked and the port used at 22.

These values can be changed if needed later. We’ll test with defaults.

Scroll to the bottom of the page and click Save to save your changes.

That’s it!

In the next lesson, we’ll test SSH.

References

pfSense book

https://docs.netgate.com/manuals/pfsense/en/latest/the-pfsense-book.pdf

pfSense Firewall

Installation - Adding A User

In this lesson, we’ll add a user, so we’ll have a login other than admin if needed.

To add a user, go to System, User Manager.

Under the Users tab, to the right of the screen, click on Add.

Enter a username, a password, and a password confirmation.

Enter a full name if you want.

Leave Custom Settings unchecked.

We want to add our new user to the admins group, so under Group membership, click on admins, then click Move to ‘Member of’ list.

Leave the keys blank for now. We’ll learn how to add SSH keys in the SSH section.

That's it!

Good job!

pfSense Firewall

Initial Setup

Disabling IPv6

In this lesson, you’ll learn how to disable IPv6.

If you don’t need IP Version 6, consider disabling it.

I very often only use IP Version 4, so disabling IPv6 saves me from having to duplicate all of my firewall rules or IPv6 equivalents on my firewall.

To block IPv6 traffic globally on your firewall, disable IPv6 traffic globally, and on each interface. We’ll also disable the default Firewall Rule permitting it on the LAN Interface. Finally, we’ll disable it from the DHCP Scope.

To block it globally, go to System, Advanced, Networking. and uncheck the Allow IPv6 checkbox under IPv6 Options.

Click Save at the bottom of the screen to save your changes.

To disable on your WAN interface, go to Interfaces, WAN, and under General Configuration, IPv6 Configuration Type, select None from the dropdown.

Scroll to the bottom and save.

Before you can do this step for the LAN Interface, you’ll have to disable DHCP for IPv6 on this interface.

To do this, go to Services, DHCPv6 Server & RA.

As a final step, go to Firewall, Rules, LAN, and click Disable to disable the rule allowing all IPv6 traffic. Save and Apply Changes.

DHCP for IPv6

That’s it!

References

pfSense Book

https://docs.netgate.com/manuals/pfsense/en/latest/the-pfsense-book.pdf

pfSense Firewall

Initial Setup

Customizing The Dashboard

In this lesson, you’ll learn how to set the dashboard up the way you like it.

You can customize the dashboard to show the things about your pfSense Firewall that are most important to you.

Just click the + in the upper right and choose from available options.

To delete one you don’t want, just click on the X in the upper right of the widget you want to remove.

That’s it!

References

pfSense Book

https://docs.netgate.com/manuals/pfsense/en/latest/the-pfsense-book.pdf

pfSense Firewall

Firewall Initial Setup - Themes

In this lesson, we’ll see how to change the look and feel, or theme of your pfSense installation.

I do like the look of the default pfSense web configurator, but I also like some variety.

To see what’s available to you out of the box, go to System, General Setup in the menu, then scroll down to webConfigurator.

The top dropdown under webConfigurator is for choosing the Theme.

Available options are pfSense (the default), pfSense-dark, pfSense-dark-BETA, pfSense-BETA, and Compact-RED.

You may have to back out to the main screen to see the changes.

I do happen to like the dark theme, so that’s what I often use.

You can find themes for pfSense on GitHub and elsewhere around the Internet.

Just remember, this is a security device. Adding external code could create security vulnerabilities.

You can also search for guidance on how to customize it yourself if you’re so inclined.

That’s it for changing your theme!

References

How to rebrand the pfSense software (tutorial is dated but may still work)

https://www.yawarra.com.au/tutorials/how-to-rebrand-the-pfsense-software/

pfSense Book

https://docs.netgate.com/manuals/pfsense/en/latest/the-pfsense-book.pdf

pfSense Firewall

Firewall Features - Considerations

Prior to diving into firewall rules and configuration, we’ll look at some considerations for best results in firewall deployment.

We’ll discuss:

• Rules and Rulesets

• Stateful Filtering

• Blocking vs. Rejecting Traffic

• Ingress vs. Egress

Rules and Rulesets

Firewalls process traffic and permit, take action on, or deny it based on Rules. You can group sets of related rules into Rulesets if your configuration is complex enough to warrant that.

Once you create a rule, you assign it to an interface or to interfaces. You also specify the direction on the interface.

Rules are read from top to bottom and traffic is processed based on the first match observed in the rules or ruleset.

If you have a rule that is likely to be used often, it is best to have it higher in the list of rules. This will reduce the processing load on your system. The firewall won’t have to go through a rule or rules that don’t apply to get to the one that does as often if the common traffic is processed first.

For example, if you use HTTPS a lot, and SSH only a little, and you want to have rules to allow both, it makes sense to check for HTTPS first, then SSH.

Stateful Filtering

You’ll see this referred to as Stateful Packet Inspection or SPI by some firewall vendors such as Cisco.

You want your firewall to keep track of information going out, and you want it to let the return traffic back in to the requestor.

However you don’t want to let unrequested traffic or potentially malicious into your network.

You don’t want to have to define all return traffic, because you likely don’t know ahead of time what your users or even you will have to have access in advance.

The firewall keeps track of outbound requests and listens for and processes related replies in a State Table. The state table records the source, destination, protocol, ports, and the state of the connection as well as the interface involved.

You can see the state table on your pfSense Firewall at any time by clicking on Diagnostics and choosing States from the menu.

Some examples of state types are ESTABLISHED for active connections, and FIN_WAIT_2 for a connection that is or is expected to be closing. States are shown as pairs separated by a colon.

ESTABLISHED:ESTABLISHED means the connection is established from the perspective of the sender and receiver as far as the firewall can tell.

TCP is connection oriented so sessions can be established.

UDP is connectionless so state is kind of simulated or set up for the purpose of knowing what may be expected in association with UDP traffic being sent.

You will see states like SINGLE:MULTIPLE, and MULTIPLE:SINGLE for UDP.

Other protocols like Internet Control Message Protocol (ICMP) will have states as well.

Any outbound request that is expecting a reply must have an entry in the state table.

Blocking vs. Rejecting

Blocking traffic silently drops it, not notifying the sender in any way. Your device looks like it is turned off.

Rejecting traffic sends an appropriate reply to the requestor to let them know the device is there, but the connection is not allowed.

In general, it is good practice to have Internet exposed devices block unwanted traffic and internal devices reject traffic that is not allowed.

Blocking theoretically makes it more difficult for an attacker to know a device is even there, and  rejecting reduces the wait times associated with unanswered requests.

Ingress vs. Egress

Ingress and Egress from the firewall’s perspective, if it’s a device between your home or business and the Internet refers to traffic into or out of your home or business network.

If you want to go to google.com from a browser on your computer, the request from your computer to the nearest Google presence is considered Egress traffic.

If you have a web server hosted in a DMZ off of the Opt port on your pfSense Firewall, requests to that would be Ingress traffic.

Considering that the Internet is a wild and crazy place with automated scanners and manual hackers constantly scouring any exposure for weaknesses, you will typically want to disallow all Ingress traffic with very rare, highly secure exceptions like Virtual Private Networking (VPN) connections.

If your network isn’t too complex, or maybe even if it is, you may want to consider Egress filtering as well. You would start by allowing protocols you know you’ll use all the time like HTTP and HTTPS for web browsing, SSH for remotely accessing any servers you have on the Internet, if you have any, and making sure updates still work for your computers and Internet of Things (IoT) devices. Hopefully, those IoT things use HTTP or HTTPS, so they should not have to have other ports open.

You would also want to allow Domain Name System (DNS) queries from all of your computers, or at least from your internal DNS forwarders or resolvers so name resolution can occur.

For your home network, this can be a great way to see what’s going on.

For work, you’ll want to have a pretty firm grasp on what other protocols are needed for your employees to do their work before denying traffic.

We’ll cover some strategies for doing this with minimal chance of breaking things in an upcoming lesson.

Try to mentally put yourself in the position of the firewall when deciding whether traffic is Ingress or Egress from its perspective.

Traffic Into the LAN Interface would be Egress traffic from the network’s perspective. Traffic going from the Firewall Out on the WAN Interface would also be Egress.

Traffic coming Into the WAN Interface would be Ingress. Traffic going Out from the Firewall toward the LAN on the LAN interface would also be Ingress. I hope the following table will make this clearer.

In this lesson, you learned about:

• Rules and Rulesets

• Stateful Filtering

• Blocking vs. Rejecting Traffic

• Ingress vs. Egress

Next, we’ll have a look at Whitelisting vs. Blacklisting approaches to firewalling.

References

pfSense book - 12.1 Firewalling Fundamentals

https://docs.netgate.com/manuals/pfsense/en/latest/the-pfsense-book.pdf

pfSense Firewall

Firewall Features - Whitelisting vs. Blacklisting

We’ll learn about whitelisting and blacklisting in this lesson.

Blacklisting is denying the things you don’t want or things you believe are likely to be malicious. Perhaps you want to block port 1337 because it is associated with Shadyshell. You create a rule to block it.

It’s great that you blocked one suspected bad thing on one port, but there 65,534 more TCP port numbers! The bad guys will quickly migrate their badness to another port once people start blocking their first choice.

Maintaining blacklists for suspicious ports is extremely difficult. This is not to be confused with SMTP Blacklisting or DNS Blacklisting. Although SMTP and DNS blacklisting is also difficult to maintain, there are enough people working at it to make it a worthwhile added layer of defence.

Whitelisting is allowing what you want and blocking everything else. You could allow HTTP, HTTPS, SSH, DNS, and NTP. Block everything else.

If you know what you want to allow, you don’t have to know what you don’t. Just whitelist what you want and block everything else.

This is the default mode for Ingress Filtering. Consider putting it in place for Egress Filtering too. You can stop much badness that way.

References

Blacklisting vs. Whitelisting - Understanding the Security benefits of Each

https://blog.finjan.com/blacklisting-vs-whitelisting-understanding-the-security-benefits-of-each/

TCP 1337, Shadyshell

https://www.auditmypc.com/tcp-port-1337.asp

pfSense Firewall

Firewall Features - Rule Placement

In this lesson, you’ll learn where to place your rules to provide the greatest protection to the resource you want to protect.

In the firewall graphic depicted below, it’s a very simple firewall configuration with a LAN and a WAN interface. Consider that you could possibly have many interfaces on your firewall as well as many networks in the form of other physical or virtual network interfaces, or in the form of multiple Virtual Local Area Networks or VLANS.

If you want to keep TCP Port 1337 from making it to the Internet if a computer is exploited on your LAN, it makes sense to put the rule blocking it on the LAN Interface.

Put the rule protecting the asset or others as close to the threat as possible.

If you want to protect your LAN from spoofed traffic in the form of BOGONs or MARTIANs, put the rule on the WAN interface.

This way, all other areas of your network protected by the firewall are also protected.

You could, on our example Firewall, provide the same protection by putting the rule on the LAN interface, but if you later add a DMZ, on the OPT interface, it will not be protected.

Likewise, if you were to add another physical interface or VLAN’s on the LAN side.

One difference in firewall rules on pfSense from rules by other vendors is that pfSense automatically creates all rules for inbound traffic from the firewall’s perspective.

If I want to create a firewall  rule on Cisco or Juniper, I have to specify the interface and the direction of flow I want it applied to.

LAN Inbound (for traffic going into the firewall from the LAN), or LAN Outbound for traffic going to the LAN from the Firewall.

You’ll notice there’s no ability to specify inbound or outbound on an interface rule on pfSense.

You can achieve a similar level of granularity with Floating Rules which will be covered in a separate lesson.

References

Wikipedia - Martian packet

https://en.wikipedia.org/wiki/Martian_packet

Wikipedia - Bogon filtering

https://en.m.wikipedia.org/wiki/Bogon_filtering

Team Cymru’s Bogon Reference

http://www.team-cymru.com/bogon-reference.html

pfSense book - 12.1 Firewalling Fundamentals

https://docs.netgate.com/manuals/pfsense/en/latest/the-pfsense-book.pdf

pfSense Firewall

Firewall - Floating Rules

In this lesson, we’ll take a cursory look at floating rules.

Remember that firewall rules are applied to interfaces only in the inbound direction. This is usually desired behavior. In some cases though, you may want a rule or rules applied no matter where the traffic is observed.

The example referred to in the book is traffic shaping rules. In most cases, it is better to stick with the easier to configure and understand interface inbound rules.

This lesson will let you know floating rules exist and some of the considerations regarding their use so you can utilize them if needed.

Floating Rule Precautions

Floating rules are more flexible and powerful than interface rules. They are, due to this power, prone to misconfigurations that may deny, or worse, permit traffic you didn’t intend.

Fellow network administrators may not be aware of floating rules or may not look for them, causing extended troubleshooting.

Determining source and destination for packets is not always straight forward. Outbound rules applied to the WAN are applied after Network Address Translation or NAT has occurred, so they will have a local source of the firewall’s IP.

Uses

Traffic shaping with ALTQ

Controlling traffic leaving the firewall itself. (Prevent the firewall from reaching specific IP’s or ports)

Ensuring no traffic can exit from other paths into a secure network regardless of any other rules created elsewhere on the firewall.

When enacting state timeouts, tag/match operations, no state and sloppy state rules for asymmetric routing.

Processing Order

Inbound rules work very similarly to interface rules, however they are processed first.

Firewall rules are processed after NAT rules, so rules in the outbound direction cannot match a local address source if outbound NAT is enabled on that interface.

Floating rules are processed before interface group rules and interface rules.

Match Action

Only floating rules have the match action. The match action does not pass or block a packet. It is only used to assign traffic to queues or limiters for shaping traffic. If Quick is enabled, match rules will not work.

Quick

When Quick is enabled for rules on your firewall, processing stops after the first match to a rule is hit. This is the normal, default behavior for interface rules.

On Floating Rules, you have the option of disabling Quick processing. With Quick disabled, the last rule hit wins.

Quick cannot be used with tagged queuing when managed with floating rules.

In almost all cases, it is best to leave Quick enabled.

Interface Selection

With floating rules, you can add one, multiple, or all interfaces. You can select multiple interfaces by Ctrl-clicking or clicking and dragging.

Direction

You can manage traffic that is inbound, outbound, or traversing in any direction with floating rules.

Marking and Matching

You can use the Tag and Tagged fields to mark and manage specific traffic. This can be used to take action on WAN outbound traffic from a specific internal host that would not have been matched due to NAT substituting the source address.

That’s it!

References

pfSense Book Chapter 12.9

https://docs.netgate.com/manuals/pfsense/en/latest/the-pfsense-book.pdf

pfSense Firewall

Firewall - Adding A Rule

In this lesson, we’ll learn how to add a firewall rule.

First, we’ll do a quick test to demonstrate that the traffic we want to block works with no rules in place.

Then, we’ll create a rule to block. We’ll see that the traffic is blocked and the offenders actions logged.

You don’t have to follow along in the initial demonstration unless you just like doing that stuff and want to for fun.

In the VirtualBox lab, I have pfSense, the Ubuntu 18.04 Desktop behind pfSense, and an Ubuntu 18.04 server outside the firewall all running.

On the Ubuntu 18.04 server outside the firewall, I’ll have netcat listen on port 1337.

nc -l 1337

On the Ubuntu Desktop behind the firewall, I’ll telnet to the listening server.

telnet 192.168.254.143 1337

The connection goes live, and communication is possible.

The firewall took no action because the activity was permitted.

Now, we’ll add a rule, and try again.

Log into the firewall, and go to Firewall, Rules in the menu.

Remembering that we want to place the rule as close to the threat as possible, we’ll put our new rule on the LAN interface. The bad actor is supposedly on our LAN trying to get out.

Click on LAN.

We don’t expect this rule to be hit very often, so well add it to the bottom of the list by choosing the Add with the down arrow.

For traffic inside the network, we’ll choose Reject for the Action.

Specify port 1337 in the From field in the Destination Port Range, and leave the To field blank.

Check the box to Log packets that are handled by this rule.

Provide a descriptive name like Reject 1337 - shadyshell.

Save your rule.

You can see your new rule defined at the bottom of the list.

On the Firewall/Rules/LAN page, click Apply Changes.

And it didn’t work. What happened?

Well, we have a permit ANY IP, ANY PORT outbound enabled above our rule. First match wins!

We have to move our rule up so it is hit before the permit ANY ANY rules.

Click to the box next to the green check mark on the two ANY ANY rules (IPv4 and IPv6) then press shift and click the up arrow next to the edit icon on the right.

Click Save at the bottom right of the list, then Apply Changes in green at the top.

Now, we see the traffic is blocked and logged.

If we saw a hit on this rule, we could go and investigate to see what happened to the infected host and clean it up.

Even if you don’t want to try the full exercise, I encourage you to add the rule and move it up in the list. You could then try to telnet to any IP address off your network on port 1337 to see the rule enforced.

Nice work!

References

pfSense book

https://docs.netgate.com/manuals/pfsense/en/latest/the-pfsense-book.pdf

pfSense Firewall

Firewall - Adding ICMP

In this lesson, you’ll learn how to add ICMP aliases for useful message types.

ICMP stands for Internet Control Message Protocol. ICMP provides some much needed guidance in controlling traffic.

ICMP messages are broken down by message types and codes.

Some message types can be risky and should be avoided if not absolutely needed. Some, however, are crucial to proper operation of your network.

Here are the types I recommend allowing outbound to keep things running smoothly:

Note that I’m differing from the author’s recommendations here. In the pfSense book, they say allowing any ICMP message type is typically acceptable. Although I believe the authors know more about firewalls than I ever will, as a security professional, I know ICMP has been and can be abused.

I leave it to you to decide.

I provide the steps for only allowing the four types outlined above, but you can easily just specify any for type if desired.

Unlike with TCP, and UDP, when creating a rule for ICMP, you can specify multiple types you want to work with in a single rule without the need for creating and alias.

Go to Firewall, Rules, LAN, and select Add. It doesn’t matter whether you add to the top or bottom. We’ll put it in the appropriate spot after you create it.

For Protocol, under Edit Firewall Rule, select ICMP. The ICMP Subtypes menu will appear.

You can select multiple subtypes by holding down the [Ctrl] key while left clicking on the ones you want. If you make a mistake, just hold down the [Ctrl] key and left click again to deselect.

If you want to go with my recommendation, [Ctrl] left click on echo request, time exceeded, parameter problem, and destination unreachable.

If you want to side with the authors, you could simply choose any.

Scroll to the bottom and click on Save, then Apply Changes.

Move the new rule so it is just below the rule permitting TCP and UDP traffic.

References

pfSense Book - 12.8.6 ICMP Type

https://docs.netgate.com/manuals/pfsense/en/latest/the-pfsense-book.pdf

pfSense Firewall

Firewall - Rule Order

In this lesson, you’ll learn how to put your rules in an order that will optimize performance and manipulate traffic in the way you intended.

Although it has been hit upon in previous lessons, rule order on firewalls is so important it deserves a quick lesson of its own.

As already mentioned, the most used rules should appear first in the rule order. There are exceptions though.

If you have a deny all else rule at the end of your rule list, and it has the most traffic, you do not want to move it up!

What would be the result of such a move?

That’s right, you would be stopping traffic before it gets to some use cases where you may want it allowed.

In our previous lesson, when we permitted certain UDP traffic. Even if the UDP Alias was getting fewer hits than the deny all rule at the end, we would not move the deny rule up, or DNS would stop working!

If you haven’t experienced it before, practically nothing Internet facing will work without DNS.

We’ll cover the default deny or blacklist and default allow or whitelist considerations below.

Default Deny or Blacklist

Deny specific traffic you may want to stop (DNS Blacklists for example)

Place your most used deny rules highest on the list

Place the next most used rule after that, and so on.

Permit traffic you want to allow

Place your most used rules highest on the list

Deny anything not permitted by the previous rules.

Default Allow or Whitelist

Deny any specific traffic you may want to stop (DNS Blacklists for example)

Place your most used deny rules highest on the list

Permit traffic you want to allow

For either strategy, even if your default deny for blacklisting or your default allow for whitelisting become your most used rules, don’t move them up from the bottom of the list or you’ll have unintended consequences.

If you disable the catch-all permit any rule at the end of the list on the LAN interface an invisible, implicit default deny any rule will be invoked.

I do like to define my own deny any so I can see what’s going on with that rule. I can see stats with it just like any other rule from the main Firewall/Rules screen.

Traffic dropped by the implicit deny rule is logged. It is your preference whether to configure your own.

As mentioned in a previous lesson, if you want to filter traffic that is allowed from the Internet based on a request from a LAN based system, you’ll have to create a floating rule to deal with this.

Otherwise, the connection will be allowed based on being part of the State Table.

That’s it!

References

pfSense Book Chapter 12

https://docs.netgate.com/manuals/pfsense/en/latest/the-pfsense-book.pdf

pfSense Firewall

Firewall Initial Setup - Rule Separators

In this lesson, we’ll see how to add rule separators so we can group related rules.

To see what rules are configured, go to Firewall, Rules on the menu. We’ll look at the LAN interface.

We don’t have many rules configured yet, but you can see how some are related. We have our standard allow rules for TCP, UDP, and ICMP.

We’ll add a separator to describe those and give us a visual queue that they’re related now.

To add a separator, scroll to the bottom of the rule list and click the + Separator link. Give your rule separator a descriptive name and choose a color for it. Left-click on the rule and drag it to the location you want it.

Now, we’ll add one more separator. I called it Deny any not allowed above.

With just a few rules, these aren’t that needed. On a larger rule set, they can be very useful in helping you keep your rules organized and helping you quickly find what you’re looking for.

I think of them like the tabs on a file folder. A bunch of related papers are in the folder and are grouped together by the named tabs.

That’s it for adding rule separators!

References

pfSense Book

https://docs.netgate.com/manuals/pfsense/en/latest/the-pfsense-book.pdf

pfSense Firewall

pfBlockerNG

Overview

pfBlockerNG is an extremely useful plugin. I recommend everyone with a pfSense Firewall install it.

Dallas Haselhorst, on his blog, Linux Included, said if he could choose only one package to enable on pfSense, pfBlockerNG would be it.

Dallas has several outstanding blog posts about pfBlockerNG among other things. A link to his blog is provided below.

I agree with Dallas. The suite of tools provided with this package is indispensable.

Per the pfBlockerNG info page in the Netgate documentation, pfBlockerNG allows:

Assigning many IP address URL lists from sites like I-blocklist to a single alias and then choose a rule action.

Blocking countries and IP ranges.

Replacement of both Countryblock and IPblocklist by providing the same functionality, and more, in one package.

Uses native functions of pfSense instead of file hacks and table manipulation.

Features include:

Country_Block features

IP_Blocklist features

XMLRPC Sync

Dashboard widget with aliases applied and package hits

Lists update frequency

Many new options to choose what to block and how to block.

Network lists may be used for custom rules.

pfBlockerNG aggregates several IP and DNS Block Lists into a single list that can be checked by your firewall. These lists are drawn from popular feeds.

Stopping traffic before DNS name resolution is even complete can save a lot of effort by your firewall and a lot of risk for you. If resolution of a bad site completed, the firewall would then have to analyze all the traffic using other tools hopefully recognizing and stopping the bad traffic.

You’re stopping name resolution from occurring, so malware that relies on it can’t “phone home” to receive further instructions or malware.

In the following lessons, we’ll install and configure the main features available with pfBlockernNG.

If you like the project, please consider contributing to @BBcan177’s Patreon campaign. I did. He’s put a huge amount of effort into making this a useful, easy to install and use package.

References

Dallas Hazelhorst’s blog (LinuxIncluded) walkthrough for pfBlockerNG

https://www.linuxincluded.com/block-ads-malvertising-on-pfsense-using-pfblockerng-dnsbl/

MalwareTech blog:

https://www.malwaretech.com/2017/05/how-to-accidentally-stop-a-global-cyber-attacks.html

pfBlocker-NG Package Info page

https://docs.netgate.com/pfsense/en/latest/packages/pfblocker.html

pfSense book

https://docs.netgate.com/manuals/pfsense/en/latest/the-pfsense-book.pdf

pfSense Firewall

pfBlockerNG

Package Installation

We’ll install the pfBlockerNG package in this lesson.

Installing pfSense packages is pretty straight forward.

Go to System, Package Manager, and click on the Available Packages link.

There are a lot of packages you can choose from. They’re in alphabetical order, so scroll down to pfBlockerNG.

I’m going with Dallas Haselhorst’s recommendation and installing the -devel package. I would normally avoid -devel packages for production devices, but I’ve been using this and it seems stable, and has features I want you to be able to use.

Click the + Install link on the right.

Click on Confirm.

The package will install and you’ll see the progress as it goes.

Do not click out of the window during installation.

Now, after successful installation, we can see it is visible under Installed Packages.

It is also visible as a menu entry under Firewall.

References

Dallas Hazelhorst’s blog (LinuxIncluded) walkthrough for pfBlockerNG

https://www.linuxincluded.com/block-ads-malvertising-on-pfsense-using-pfblockerng-dnsbl/

pfBlocker-NG Package Info page

https://docs.netgate.com/pfsense/en/latest/packages/pfblocker.html

pfSense book

https://docs.netgate.com/manuals/pfsense/en/latest/the-pfsense-book.pdf

pfSense Firewall

pfBlockerNG

Enabling IP and DNSBL With Setup Wizard

In this lesson, we’ll enable pfBlockerNG and configure DNS Blacklisting (DNSBL) and IP Blacklisting using a setup wizard.

To launch the wizard, go to Firewall, pfBlockerNG. If you haven’t cancelled out of it or already or set something up in pfBlockerNG, a setup screen appears.

Even though we installed pfBlockerNG in the last lesson, it isn’t enabled because we haven’t configured anything yet.

To launch the wizard, go to Firewall, pfBlockerNG, and the wizard will appear if you haven’t already cancelled it and configured anything manually.

The wizard will configure an entry level configuration for IP and DNSBL.

You’ll receive a warning telling you any settings you had before will be wiped when you run the wizard.

We don’t have anything configured, so this is fine for us now.

It also lets us know it will configure IP rules to block the worst offending IP’s outbound, and will enable DNS Blacklist using the DNS Resolver blocking ADverts and the worst malicious domains.

Click on Next to start the Wizard.

Inbound interface is the WAN, and outbound is LAN, so click on Next.

Leave the default ports and IP as they are unless they may conflict with another interface on your pfSense Firewall. If you have 10.10.10.x/24 in use on one of your interfaces or VLAN’s, you would change this.

Click Next.

One more warning that it is going to wipe any previous configuration.

Click on Finish.

pfBlockerNG will run its first update. Scroll back up to make sure there were no errors. If you have any, search for the error and resolve it.

If not, you’ll be able to find logs and statistics under the Reports/Alerts Tab. You can look at the Reports/Statistics for specifics.

Good job!

References

Dallas Hazelhorst’s blog (LinuxIncluded) walkthrough for pfBlockerNG

https://www.linuxincluded.com/block-ads-malvertising-on-pfsense-using-pfblockerng-dnsbl/

pfBlocker-NG Package Info page

https://docs.netgate.com/pfsense/en/latest/packages/pfblocker.html

pfSense book

https://docs.netgate.com/manuals/pfsense/en/latest/the-pfsense-book.pdf

IDS/IPS - Overview

So, what is an Intrusion Detection System / Intrusion Prevention System? As the name implies, it's a system for detecting and/or preventing network intrusions.

When attackers try to find and exploit vulnerabilities on your servers, there are patterns in the network traffic that can be detected, and if configured for prevention, blocked upon detection.

One simple example is a Directory Traversal Attack. When an attacker tries to find a vulnerable server, there will be attempts to go up directory levels sent in her requests to your server. The GET request to your web server will look something like this:

GET http://infosec.theos-blog.com/show.asp?view=../../../../../Windows/system.ini HTTP/1.1 Host: infosec.theos-blog.com

In simple terms, the IDS can look for a pattern like "../.././../" and create an alert. If configured to prevent attacks, it can block the offending source IP Address, keeping the attacker at bay for a length of time you determine, or permanently until you manually allow traffic from there again.

An IDS/IPS can have hundreds or thousands of patterns like above that check traffic for many, many types of attacks. This is an example of signature based detection.

Snort does signature and protocol based detection.

Signature based detection is described above.

Stateful protocol analysis looks for deviations in a pre-defined set of norms for how a protocol should function. If someone is using Secure Shell (SSH) over a port other than its standard port of TCP port 22, Snort should detect this and respond accordingly.

We'll be installing Snort IDS/IPS on pfSense and looking at its operation in upcoming lessons.

pfSense - Snort - Installation

Installing Snort is super easy.

Navigate to System, Package Manager, Available Packages in your pfSense web GUI.

Scroll down to Snort.

You can see there are many, many packages available for pfSense!

We're focused on Snort, so click on Install next to Snort.

Leave the installation window up so you can watch the installation process.

At the end, you should have a success message at the bottom of the window and a green bar at the top of the screen saying the installation was successful.

That's it!

In upcoming lessons, you'll learn about rule sets, how to install them, and now to configure Snort.

pfSense - Snort - Snort Rule Sets

As mentioned in a previous lesson, Snort runs on rules.

Before we dive into configuring Snort, it is helpful to understand rule sets and to be prepared to download and install them by registering with Snort for the rules you want, if applicable.

Rule sets available for download are:

• Snort VRT

• Snort GPLv2

• ET Open

• ET Pro

• Sourcefire OpenAppID Detectors

Some details on each follow.

Snort VRT 

VRT stands for Vulnerability Research Team. It used to be a group of volunteers on the Snort team, but I believe it all now falls under Talos, which is still a team at Snort but I believe is paid. From the Snort Talos site: "Talos (formerly the VRT) is a group of leading-edge network security experts working around the clock to proactively discover, assess, and respond to the latest trends in hacking activities, intrusion attempts, malware and vulnerabilities."

There is a free subscription and a paid subscription.

• Snort VRT Free

The Snort VRT Free subscription is 30 days behind the paid subscription service.

• Snort Subscriber Rule Set (by Talos)

The paid subscriber rules set is full featured and updated twice a week or more often if a vulnerability comes out between updates.

I recommend a paid subscription for businesses and, if $29 a year sounds reasonable to you, a paid subscription for home too. A business license is a bit more pricey at $399 per sensor, but considering what you'd spend on a product like a Palo Alto subscription or anti-malware for your company, that seems very reasonable.

Snort GPLv2

The Snort GPLv2 rule set is the official Snort Community Ruleset. It is certified by Talos. From the pfSense configuration page: "It is free of charge without any Snort Subscriber License restrictions." It is updated daily but is only a subset of the subscriber rule set.

ET Open

ET stands for Emerging Threats. The ET rule sets are maintained by Proofpoint. It offers more limited coverage than ET Pro.

ET Pro

ET Pro has daily updates and extensive coverage of current malware threats. The site seems to direct me to sales reps instead of telling me the price, so I doubt it's cheap. I'll post a price if I find one. I recommend ET Open unless you feel the need to research how much ET Pro costs.

Sourcefire OpenAppID Detectors

"OpenAppID is an application-focused detection language and processing module for Snort." according to the Snort website.

OpenAppID is free and I recommend enabling this rule set.

In upcoming lessons you'll learn how to enable the rule sets you choose and how to schedule automatic updates for them.

pfSense - Snort - Enabling Rule Sets and Initial Settings

Enabling rule sets is pretty straight forward.

If you haven't already done so and want Snort VRT Rules, please register with Snort. Whether the free or paid version, you'll be emailed your "Oinkmaster" code once you sign up.

I love that. "Oinkmaster".

Once you've registered and have your code, open pfSense and go to Services, Snort in the menu.

In Services, Snort, click on Global Settings.

If you sign up for the paid Snort VRT rules, you should not check the box for Snort GPLv2 as those rules are included with the paid subscription.

If you have a free Oinkmaster code, you can select both Snort VRT and Snort GPLv2.

Chose ET Open if you want those rules.

Enable OpenAppID if you want those rules and check Enable RULES for OpenAppID too.

For Update Interval, I choose 1 day and I have them update at a time that's convenient for me on my home network, since my ISP is pretty bad and oversubscribes leaving all of us with low bandwidth.

I do like to hide deprecated rules, so I check that. Deprecated rules are rules that are no longer supported, and therefore are not recommended.

Leave Disable SSL Peer Verification unchecked unless you have to enable it due to a self-signed certificate being needed in your path. It is unlikely you'll need this checked for home use, but you may for businesses that use a proxy for web traffic.

For Remove Blocked Hosts Interval, you can set it as you desire. Bear in mind, if you're accidentally locked out for some reason, and you set it to Never, and you don't have easy remote access to your firewall, you could have issues. For corporate devices I like 1 day. For home, I set it to 4 days. If you're thinking Never is best, bear in mind that IP Addresses are reissued all the time, and a host that's evil one day can be owned by a good guy the next.

I leave Keep Snort Settings After Deinstall checked, but remember to uncheck this if you're uninstalling and reinstalling for troubleshooting purposes. The same goes for Remove Blocked Hosts After Deinstall. Again, if you're removing and reinstalling for troubleshooting, I'd check that box.

I select the Startup/Shutdown Logging to have detailed messages written to the system log when Snort starts or stops.

Click Save at the bottom to save your changes.

pfSense - Snort - First Rule Update

Before you can start using your new Snort IDS/IPS, you'll have to do the first update.

Although it's really easy to kick it off, it can take some time depending on the speed of your Internet connection.

Just go to Services Snort, and click on Updates in your menu.

Click on Update Rules to start the download.

A dialogue will come up saying Updating may take a while. I will leave it up but will pause recording the video and come back when the rules are up to date.

Once updated, you can see that the MD5 Signature Date is current.

That's it! Next we'll add Snort to Interfaces.

Choosing Whether To Block On Alert Detection

We'll discuss enabling rules on interfaces soon. Before doing that, it is useful to discuss the Detection vs. Prevention piece of an IDS/IPS.

In Detect mode, an IDS will tell you badness is occurring, but will not act on that information other than generating an alert and log entries that something potentially dangerous is happening or has happened.

In Prevent mode, an IPS will actively block offending traffic. For Snort, that means once a snort rule has been violated, Snort will block the traffic from the source or the destination IP, or both as you specify.

In Snort on pfSense, enabling Prevent mode is done by checking the Block Offenders and optionally the Kill States checkboxes in Services, Snort, Edit Interface, <LAN or WAN or other>, LAN Settings, Alert Settings.

Kill States means if a connection is established with a service, and maliciousness is later detected, sessions that were already active with one of the systems involved will be terminated.

If you're pretty familiar with firewalls and your network, using Prevent mode may be fine from the start, provided you're prepared to do some quick troubleshooting if something is blocked from a false positive.

When I was managing a network with a lot of developers, something in the way they did SSH tunneling was triggering false positives and blocking their traffic.

I don't remember the details now, but I was pretty quickly able to find the rule that was causing the false positives and tune or disable it. It happened as soon as I enabled Snort IPS in front of the servers in my environment so it was easy to know it was firewall related and to fix it.

If you're new to such activities or you're not sure whether you may have some false positives that could block your network traffic, you may want to start with Block Offenders unchecked, leaving Snort in Detect mode. You can check the logs to see what's being alerted on, tune it, then enable it for blocking once you're sure you won't be blocking legitimate traffic.

For a corporate network, or for someone who has never administered a firewall whether home or business, I recommend getting familiar with the firewall by using monitoring mode for a few days or weeks before enabling prevention by checking Block Offenders.

Also remember, if you're putting pfSense outside your home wireless device, you'll likely be using Network Address Translation from that device to pfSense. That means everything on your home network will look as though it's coming from the one IP address for the outside interface on your home wireless access point/firewall/router. If anything on your home network is flagged by Snort, your whole home network will not be able to reach the Internet until you troubleshoot the problem.

This issue would mainly come to light if you enable Block Offenders on the LAN interface, blocking the source (SRC) IP address.

To summarize, if you're feeling lucky, you may go straight to blocking mode, but I recommend the more cautious detection mode until you see what Snort alerts on.

pfSense - Snort - Adding Snort To Interfaces

OK. You've selected your rules sets, and updated them. There's one more step before Snort will start doing it's thing and protecting your network. You have to assign Snort to interfaces on your firewall.

I recommend enabling Snort on both the outside and the inside interfaces.

Bear in mind, if you're placing pfSense outside your home Wireless Router/Firewall, or outside another router or firewall at work, all the traffic on the inside interface will appear to pfSense to be coming from the single NAT'ed IP Address of your device.

That means, if there's one offender on your inside interface, all traffic to pfSense may be blocked until you fix the problem and find a different way into your firewall.

I'm OK with this risk on my home network.

If you're paranoid and have management support on your corporate network, you can configure it at work as well.

An alternative is to configure your internal interface in IDS mode and your external interface in IPS mode, then watch your logs for alerts! If you're alerted but don't see it for days, weeks or months, it will be very late in the game to try and repair the damage.

To assign rules to interfaces, go to Services, Snort. Snort Interfaces should already be selected.

Click on Add.

We'll do the WAN interface first.

Check the box to Send Alerts to System Log.

Under Block Offenders, select Source.

Leave Detection Performance Settings at their defaults.

Leave Choose the Networks Snort Should Inspect and Whitelist at defaults.

Leave Choose a Suppression or Filtering List at default.

Click on Save.

To add your internal interface, click on Add.

I configure it the same as my external interface. Consider carefully whether you want to alert or block on suspicious traffic.

Click the little Start button under Snort Status to enable Snort on each interface.

That's it! You have Snort enabled in a basic configuration.

pfSense

Suricata IDS/IPS

In this section, we’ll install Suricata IDS/IPS.

Suricata is a kind of meerkat. Perhaps the name was chosen because meerkats are watchful creatures, always on alert for danger?

Snort is older and has a large community for support and documentation. Suricata is newer and supports multi-threading which can greatly improve performance.

Suricata also supports IP reputation, and automated protocol detection.

I see those as the key differences, and beyond that I leave it to personal preference which you choose. You can try both and see which you like best.

I don’t know if it’s possible to run both on the same firewall at the same time, but even if it is, I don’t recommend it.

Having two services trying to manage network flows at the same time will be resource intensive and may result in conflicts and difficulty in troubleshooting.

In this section, we’ll:

• Remove Snort

• Install Suricata

• Configure Suricata

• Test IDS Functionality

Let’s get started!

pfSense - Suricata

Removing Snort

In this lesson, we’ll remove Snort in preparation for installing Suricata.

Let’s take a moment to do a quick backup before removing Snort so you can quickly go back to it if you decide you prefer Snort.

Click on Diagnostics, then Backup & Restore from the menu.

Under Backup Configuration, be sure to Skip packages is UNCHECKED.

Encrypt the configuration file if desired.

Click Download configuration as XML.

Know where you stored your backup. Typically your Downloads folder.

To remove Snort, go to System, Package Manager.

Click on the trash can icon to the right under snort to remove the package.

Click Confirm.

pfSense will remove Snort and tell you when it’s done.

In the next lesson we’ll install Suricata.

pfSense

Suricata - Installation

In this lesson, we’ll install the Suricata package.

Go to System, Package Manager.

Click on Available Packages.

Scroll down to Suricata and click on Install to the right.

Click Confirm.

The Package Manage will download the Suricata package.

You’ll see the message saying installation was successful, and now see it under Installed Packages.

That’s it!

In the next lesson we’ll start configuring Suricata.

pfSense - Suricata

Global Configuration

In this lesson, we’ll configure Suricata’s Global Settings.

Go to Services, Suricata, and click on the Global Settings tab.

We’re going to add free and easy to configure rules, but I encourage you to add a Snort Oinkmaster code if you’ve already signed up for one, or are OK with doing so.

Check the box next to ETOpen to obtain the Emerging Threats open rule set.

I think their pro license is a bit pricey, but you’re welcome to contact Proofpoint if you’d like to explore options.

As mentioned, you can sign up for a free Snort account and enter the code under Snort Oinkmaster Code. Free rules are 30 days behind those of paid subscribers. I do have a paid home subscription ($29 US per year) for my home firewall.

Check the box next to Install Snort GPLv2 Community Rules if you don’t have a paid subscription. If you do have a paid subscription, these are automatically installed when you update your rules.

Under Rule Update Settings, I like to update daily. It doesn’t make sense to hit the update servers more often than you need to.

I set the time at 2:00 AM.

We’ll enable Live Rule Swap on Update, but I’ll update the lesson if I experience issues with this.

We’ll sign up for a free MaxMind account so we can leverage their GeoLite2 database.

Go to https://maxmind.com/en/geolite2/signup and complete the sign on process.

Enter the license key you receive in the dialogue box next to GeoLite2 DB License Key.

Under General settings, I recommend 1 hour for Remove Blocked Hosts Interval, but please tweak this to suit your needs and environment.

If it’s a home network, you could consider longer durations. If it’s work, 1 hour may be good, unless it’s a site you manage remotely and there’s a risk of locking yourself out. In that case, you may want a shorter timeout like 1/2 hour.

You can leave Log to System Log unchecked. If you have a syslog server receiving all your logs, you may consider enabling that.

You can leave Keep Suricata Settings After Deinstall checked, although you may want to uncheck this when de-installing if you don’t plan to reinstall Suricata later.

Click on Save.

That’s it!

In the next lesson, we’ll download our first updates.

pfSense - Suricata

First Update

In this lesson, we’ll download our first updates.

Updates are really simple. Just go to Services, Suricata, Updates.

Click on Update.

Wait until the download completes.

If it completes successfully, you’ll see MD5 hashes and MD5 update dates and times.

If it isn’t successful, please try again.

In the next lesson, we’ll assign interfaces to Suricata.

pfSense - Suricata

Assigning Interfaces

In this lesson, we’ll assign interfaces to Suricata so we can monitor them or block malicious activity on them.

To add an interface, go to Services, Suricata, Interfaces, and click on Add.

We’ll start with the WAN interface.

Be sure Enable is checked. Interface is WAN, Description is WAN or something more if you prefer.

I’ll leave Send Alerts to System Log unchecked as well as Enable Stats Log.

As before, if you have a log server, you may want to capture alerts in your System Log.

Enable HTTP Log, Append HTTP Log, and Log Extended HTTP Info should all be checked.

We’ll leave Enable TLS Log, Enable Tracked-Files Log, Enable File-Store, and Enable Packet Log unchecked. You can tweak those after having Suricata running for a while to see if it captures information you find interesting without taking up too much log space.

Of those options, I see Enable Packet Log probably being the most chatty or resource intensive. Try a quick test during busy hours on your home or business network to test the impact.

We’ll leave EVE JSON Log unchecked. Eve is Extensible Event Format. All alerts, http logs, anomalies, and metadata into a single file that is formatted so it can be read by 3rd party tools like Logstash (ELK) or jq.  More info is available here: https://suricata.readthedocs.io/en/suricata-5.0.0/output/eve/eve-json-output.html

It looks like an interesting thing to explore but we’ll leave it for now.

On the WAN interface, I usually check Block Offenders for the WAN interface. We’ll leave IPS mode in Legacy Mode so we don’t have to worry about whether our NIC drivers are compatible. I leave Kill States checked. This will kill existing connections with an offender.  For WAN, I typically choose to block the SRC (source) address. We’ll leave Block on DROP Only unchecked. If this option were checked, it would not block a connection based on an ALERT trigger, only on DROP actions.

We’ll leave Run Mode at AutoFP, Max Pending Packets at 1024, Detect-Engine Profile at Medium, Pattern Matcher Algorithm at Auto, Signature Group Header MPM Context at Auto, Inspection Recursion Limit at 3000, Delayed Detect unchecked, Promiscuous Mode checked, and Interface PCAP Snaplength at 1518.

Home Net, External Net, and Pass List will all stay at default.

Alert Suppression and Filtering remains default.

Advanced Configuration Pass-Through remains empty.

Click on Save, then Apply.

I suggest using the same settings on the LAN interface, and the DMZ interface which we’ll configure in an upcoming section, with the following exceptions.

On the LAN it is good to start out allowing all but logging warnings so you can tune your firewall before denying traffic.

Once you’ve tuned, you may want to block source and destination on the LAN.

You should be able to safely block source and destination for offending traffic straight off with the DMZ as any traffic there should be tightly controlled.

Remember to apply after making changes.

That’s it for this lesson.

In the next lesson, we’ll test to make sure Suricata blocks suspicious traffic.

pfSense - Suricata

Testing

In this lesson, we’ll make sure Suricata blocks malicious traffic.

You won’t be able to follow this lesson as I present it until you get a DMZ set up.

If you run any scanning tool against a WAN interface with no ports open, you won’t see anything and all your packets will be dropped, which is a basic purpose of a firewall.

To see interesting traffic, you’ll want to allow at least one port through.

For us, it will be an nginx web server on port 80.

You’ll learn how to set up a DMZ, an nginx server, and how to test that it’s working and blocking malicious traffic with Snort in an upcoming section of this course.

For now, I want you to see that Suricata works as we’ve configured it.

I’ll be running Nikto from a Kali Linux virtual machine I have running.

Kali is free to download and is designed specifically for penetration testing and network forensics, so it has a lot of tools built in.

I’ll be using a free, easy to run, quick and dirty web scanner called Nikto.

You can download it for free and can be installed on Linux, Windows, and MAC OS.

We’ll start with Suricata disabled on the WAN and DMZ interfaces.

Go to Services, Suricata, Interfaces, and click the stop icon next to WAN and DMZ to disable Suricata for this test.

Find the WAN IP of your pfSense firewall which can be found on the main Status / Dashboard page by clicking on the pfSense Community Edition link in the upper left of your management console.

On the system you want to run Nikto from, type nikto —host <IP of WAN Interface>.

nikto —host 192.168.254.102 in my case.

It runs pretty quickly with default settings and provides a report on what it finds.

In my case, with a default nginx installation, it found three things, and only took 23 seconds to run.

Now we’ll enable Suricata on the WAN and DMZ and try again.

Go to Services, Snort, Interfaces, and click the start icon next to DMZ and WAN.

Back on your scanning machine, type nikto —host <IP of WAN Interface>.

The scan will be blocked on the firewall as soon as Suricata figures out it’s a Nikto scan which is malicious activity.

Click on Blocks under Services, Suricata, Interfaces, to see that it is now blocked.

If you stop the scanner by hitting Ctrl-C you can then remove the offender from the Block list by clicking on the red X to the right of the item in the blocked log.

You could then bring up the nginx test page on the attacking system.

That’s it for this lesson!

You’ve enabled Suricata, added rule sets, added Interfaces, and tested to make sure it blocks malicious traffic.

Good job!

pfSense Fundamentals

Configuring a DMZ - Overview

Welcome back!

In this section, we’ll configure a Demilitarized Zone (DMZ) for an nginx web server. We’ll also configure Snort to protect our web server.

Here’s what we’ll cover in this section:

• Understand what a DMZ is and why it’s useful

• Review the network topology of our lab environment

• Configuring networking on our pfSense Firewall to accommodate our DMZ

  • Add a physical interface

  • Configure the new OPT interface to be our DMZ interface

• Spin up a Linux Mint VM for the internal network

• Spin up a Linux Mint VM for our DMZ network

• Configure firewall rules to permit traffic from the DMZ for testing

• Configure firewall rules to send web traffic from outside interface to the DMZ

• Configure firewall rules to allow SSH to your web server from the internal network

• Protect your web server with Snort

Lots of fun stuff ahead. See you in the next lesson!

pfSense Fundamentals

Configuring a DMZ - What is a DMZ?

Welcome back!

As mentioned in the last lesson, DMZ stands for Demilitarized Zone. It is a term borrowed from the military.

Think of the boundary between North and South Korea. This is perhaps the most famous DMZ.

https://en.wikipedia.org/wiki/Korean_Demilitarized_Zone

The fenced-off and heavily guarded and patrolled border is a no-man’s-land. Anyone in there is suspect. Anyone having to enter must be authorized and will be very closely monitored by both sides.

It would be very nice if we could trust people to behave well when we expose a server to the Internet, like a web server, or email server. As you’ll see from your logs on any server exposed to the Internet, this just isn’t the case. Hostile forces are constantly looking for weaknesses in our servers, and if they find any, they’ll try to exploit them to take over or abuse our server.

The next logical step for an attacker is to see what else she could get to after breaking into the exposed server.

If someone breaks into your web server, and your web server is on your internal network, the attacker would be able to go after any system on your corporate local area network or LAN!

If you configure your environment as I recommend and show you here, damage from such an attack will be limited.

You should put any service you have to expose to the Internet or to people outside your network in a DMZ.

This server should be hardened and monitored closely for any sign of compromise.

Network traffic to and from the server should be tightly restricted.

For a web server, only web traffic from the Internet should be allowed to access it.

Management traffic such as SSH for Linux or Remote Desktop Protocol (RDP) for Windows should only be allowed from the internal network.

The DMZ server should not be allowed to communicate with the LAN except in very controlled circumstances like allowing logs to be sent to a log server.

To summarize, a DMZ is a network location where you can put things you want to share with outside consumers. Traffic flow into and out of the DMZ should be closely monitored.

See you in the next lesson!

pfSense Fundamentals

Configuring a DMZ - Lab Topology

Welcome back!

We’ll have a look at the network topology for our DMZ. We’ll be setting this up in VirtualBox.

The topology is pretty straight forward.

We’ll allow incoming traffic from the “Internet”, in this case our home network, or the place we’re hosting VirtualBox, into our web server in the DMZ over ports 80, HTTP, and 443, HTTPS.

We’ll deny all other inbound traffic from the “Internet”.

We’ll allow traffic from our internal network over port 22, SSH, so we could manage our server from the corporate network.

We’ll add a network interface card on our pfSense firewall which will become our DMZ.

This interface will use a new internal-only network called inet2.

For my VirtualBox environment, I use the 192.168.254.0/24 network for the WAN, the 10.0.0.0/24 network for the DMZ, and the 192.168.1.0/24 network for the internal or corporate network.

We’ll go through the steps for the entire process in upcoming lessons.

See you in the next lesson!

pfSense Firewall

Initial Firewall Configuration

Welcome back!

In this lesson, we’ll do the initial configuration of our pfSense firewall to prepare it to have a DMZ.

With the pfSense VM powered off, select the pfSense VM then click on Settings.

There are a few things to look at in Settings, all under Network.

Make sure Adapter 1 is set to Bridged Adapter. It will pose some challenges if you have NAT or Network Address Translation selected. This is your WAN interface.

Adapter 2 should be attached to an Internal Network, and it should say intnet in the Name dropdown.

For Adapter 3, check Enable Network Adapter. Under Attached to:, select Internal Network, and under Name, type intnet2. Then click OK.

Once it starts, you can see that the IP addresses assigned are on the subnets I mentioned in the Topology lesson earlier. Yours will differ, but it is good to know what they are.

Don’t worry about the new adapter yet.

In the next lesson, we’ll set up our Linux Mint VM’s on the Corporate and DMZ networks.

See you in the next lesson!

pfSense Firewall

Linux Mint - Internal Network

Welcome back!

In this lesson we’ll install the first of two Linux Mint VM’s. This one will be for our Internal network.

If you already have your internal VM set up, you can skip this lesson!

Browse to linuxmint.com and click on Download.

Scroll down to the bottom and select the Mate (64-bit) link.

On the downloads page, scroll down to a mirror near you, or click on World.

Download the .iso image for use in installing the Mint VM.

In VirtualBox, click on New.

Select a sensible name for your VM.

Type should be Linux

Version should be Ubuntu (64-bit). Mint is based on Ubuntu.

Set the Memory size to 2048 Megabytes or 2 Gigabytes if you can afford to do so on your system.

Select Create a new hard disk now, VDI, (VirtualBox Disk Image), Dynamically allocated, and 20 Gigabytes. Click on Create.

Before you start your VM, you’ll have to change a few things.

Click on the VM, then click on Settings, or right click on it and select Settings.

Click on Storage, then under Controller: IDE, click Empty. Click the disc icon next to Optical Drive: and browse to the .iso image you downloaded.

It will likely be in your Downloads folder unless you stored it elsewhere or moved it.

Click on the Network icon.

Under Adapter 1, Enable Network Adapter should be checked. Click the drop-down next to Attached to: and select Internal Network. Be sure the name is intnet, not intnet2.

Click on OK.

Double-click the VM to start it.

The VM will start in Live-CD mode. To actually install Linux Mint, double click on the Install Linux Mint icon on the desktop.

Select defaults or change to suite your locale.

Under Preparing to install Linux Mint, click the checkbox to Install third-party software to add proprietary drivers if needed if you want and click on Continue.

Under Installation Type, I like to check Use LVM. It makes resizing hard drives much easier if you ever have to.

Click on Install Now.

Click on Continue.

Select your timezone if it isn’t already selected and click on Continue.

I try to keep my VirtualBox name and my computer’s name the same. This is up to you, but it is helpful to name it sensibly and not have a bunch of generic sounding machine names on your network.

Leave Require my password to log in selected.

I don’t encrypt my home directory for a lab environment.

Click Restart Now when prompted to finish the installation.

The .iso image should be automatically removed from the virtual CDROM drive, so just press Enter when prompted.

Uncheck Show this dialog at startup if you want and close the Welcome screen.

We can ping our pfSense firewall (gateway) but can’t yet resolve names on the Internet because DNS has not been configured on the firewall. If you’re using an already configured firewall, you should be fine now.

In your browser, type in your firewall’s internal IP, typically 192.168.1.1. Click on Advanced, then Accept the Risk and Continue to get past the certificate warning.

Log in to your pfSense firewall.

If you’re using an already configured firewall, you know your credentials. If you’re using a clean install, the login is admin, and the password is pfsense.

Change the password if it’s a new installation.

In the next lesson, we’ll do some more configuration of the firewall to set up the DMZ.

See you in the next lesson!

pfSense Firewall

Configuring a DMZ - Configuring the Firewall Part 2

Welcome back!

In this lesson, we’ll continue configuring our firewall to accommodate our DMZ.

I’ll be configuring DNS on this firewall because I started with a clean build for this lesson. If you’re using a firewall that’s already configured, you won’t have to do that.

We could have added the interface to the DMZ with the text menu at the console for the firewall, but it’s much nicer to use the web GUI so we’ll use that.

First, we’ll create a DMZ interface.

From the menu, choose Interfaces and Assignments.

If you already added the interface to the firewall in VirtualBox as shown in a previous lesson, you’ll see a new one as an Available network port. Click on Add.

We’ll change the name from OPT1 to DMZ.

Check Enable Interface.

Under IPv4 Configuration Type, choose Static IPv4.

Set the IP Address at 10.0.0.1 with a 24 bit mask. This creates a Class C size subnet.

Since this is a private network we will not check Block private networks… and we won’t worry about bogon’s either.

Click on Save then click on Apply Changes.

Looking back at Interfaces, Assignments, and you can see that the DMZ interface is configured.

I’m going back to System, General Setup to configure DNS servers. Again, you won’t have to do this step if your firewall is already configured.

Now we’ll configure some firewall rules for the DMZ. When you first add a new interface, there are no rules applied so no traffic can flow on that interface.

In the menu, click on Firewall, Rules.

Click on the DMZ interface.

Click on Add.

Action is Pass, Interface is DMZ, Protocol is UDP, Destination is any, port is DNS(53) for the destination port range The source will be DMZ net.

I like to log DNS resolution.

Give the rule a name that makes sense like DNS Outbound from DMZ.

Remember to put rules from most used to least used as you add them.

Add a rule for UDP, NTP(123). All other settings are the same as the last.

Add a rule for ICMP. We can allow all message types for this. It is good to specify only echo requests and replies if you’re going to leave this set up.

Log packets.

Click Save, then Apply Changes.

Next, we’ll set up our second Linux Mint VM and that will act as our server in the DMZ. We’ll install nginx web server on it.

Configuring a DMZ

Adding a Linux Mint VM to the DMZ

In this lesson, we’ll add a Linux Mint computer to the DMZ to be our web server.

A lot of the steps are similar to the previous lesson as far as the installation of Mint, so we’ll focus on the differences.

Remember, if you have enough memory on your system, 2 Gigabytes of RAM and 20 Gigabytes of hard drive space.

Under settings, select your .iso image under Storage, Controller: IDE, Empty.

Under Networking, be sure you choose the intnet2 internal network.

You’ll get a network warning in the upper right as you install because we’ll be configuring static networking. You can disregard this and it will go away as soon as we enable networking.

Once the system boots, click on Menu, Control Center, scroll down to Internet and Network and double click it.  Double click on Wired connections 1.

Click on the IPv4 Settings tab.

Select Manual from the dropdown, then under Addresses, click on Add.

For my network, I entered 10.0.0.10 for the IP, 255.255.255.0 for the Netmask, and 10.0.0.1 for the Gateway.

After you click Add, an additional line will be added beneath your preferred IP. Select that empty line and delete it.

Add your DNS servers. I used 8.8.8.8 and 8.8.4.4 but if you prefer, you can use your pfSense firewall as long as it is configured to resolve DNS.

Click on IPv6 Settings, and select Ignore.

Click Save to save your settings and enable networking.

Networking should come up.

Test by pinging your gateway successfully, and if that works, ping an Internet host like www.google.com. The response from the gateway shows you networking is up, and the response from the Internet host shows you name resolution and outside networking is up.

Remember, we allowed ping and DNS in our firewall rules, but nothing else.

Updates will not work until we enable them.

How do we know what rule(s) to add?

Try running an update. It will fail, but the blocked attempt will be logged on the firewall.

Look at the firewall logs for the DMZ and you’ll see the traffic was trying to go out on port 80.

Go back to Firewall, Rules, DMZ on the firewall. Click on Add with the up arrow to add a rule for port 90, TCP.

TCP, Source is DMZ Net, Destination is HTTP. Be sure to click Save, and Apply.

For some reason, this worked at first for me at first, but then updates quit working.

I looked at the logs and discovered that I had to add port 53, UDP inbound from 8.8.8.8 to the DMZ Net for this to work for me. I’m not sure if you’ll have to do this, but if you have trouble, always check the logs, and keep the rule as narrow as you can to make things work. 

To add an inbound port number on the WAN interface, you’ll have to click on Advanced when setting up the rule to see the port numbers.

pfSense Firewall

Configuring a DMZ

Adding nginx to our DMZ Mint Server

In this lesson, we’ll add nginx to our Mint build in the DMZ.

First, we’ll make sure updates work by typing sudo apt update. Be sure they download successfully. That way you’ll be installing the latest version of nginx available in packages.

Type sudo apt install nginx to install nginx.

There are a few commands you’ll want to know to manage your nginx server.

sudo service nginx status will show you status information about your server and let you know it is running. Type q to quit the status screen.

You can test by opening a browser and just typing localhost in the url field.

You should get a Welcome to nginx! web page.

sudo service nginx stop stops nginx.

sudo service nginx start starts nginx.

pfSense Firewall

Configuring a DMZ

Configuring the Firewall Part 3

In this lesson, we’ll allow inbound traffic from the WAN to the nginx web server.

We’ll do this using port forwarding.

Go to Firewall, NAT, Port Forward in the menu.

Click on Add to add a new rule.

The Interface is WAN, the Protocol is TCP, The Destination will be the WAN address. This is the address the user will be coming to from the Internet.

Destination port is HTTP.

The Redirect Target IP will be the IP Address of your nginx web server in the DMZ. In my case, 10.0.0.10.

You can type ip addr | grep inet to get the IP Addresses assigned in Linux.

Redirect target port will be HTTP.

Make a reasonable description.

Make sure Add an associated firewall rule above save from the dropdown.

Save and Apply changes.

Bring up a web server and enter the WAN IP of your firewall in a browser on the network outside the firewall.

For this environment, we had to go to Interfaces, WAN, and uncheck Block private networks, apply, and save because we’re using a private iP network on the outside interface.

In the next lesson, we’ll protect our web server with Snort.

pfSense Firewall

Configuring a DMZ - Protecting nginx with Snort

In this lesson, we’ll protect our nginx web server in the DMZ with Snort.

If you already had Snort configured from previous lessons, this may already be set up for you if you protected your WAN interface and enabled blocking of suspicious traffic.

If not, or to double-check, go to Services, Snort, Interfaces, and be sure the WAN interface is listed there.

If you’re just adding Snort protection to your WAN, be sure to start Snort on the interface once you’ve added it.

If you want to test to make sure it’s working, you can download and run nikto on a system on that is outside the firewall on its WAN interface.

Be sure blocking of offending source IP’s is enabled.

You can do this by typing sudo apt install nikto on a Debian based system which includes Ubuntu and Linux Mint.

The command to scan a site with nikto is nikto -host http://<target ip>. In my case, nikto -host http://192.168.254.138. Your target IP should be the WAN IP of your pfSense firewall.

First stop Snort to see what a full scan looks like.

Nikto will run many tests, and send 7,000 + requests depending on what it finds and what options you select. and will provide a report.

Now, enable Snort on the WAN interface and try again.

You should see your IP quickly identified and blocked.

Nikto will take quite a while to timeout.

To remove an IP from the blocked list, go to the Blocked list and click the red X to the right under Remove.

pfSense Firewall

Configuring a DMZ - SSH - Preparing Your Server

Now that we have a DMZ configured and a web server running in it, you’ll want to be able to manage your web server from the inside or Corporate LAN.

A straight forward way to do this is to have your web server in the DMZ listen for SSH connections on a port other than port 22.

TCP port 22 is the standard port for SSH.

If you have servers you manage on the Internet, you’ll likely still want to be able to do that on port 22.

If you redirect all port 22 traffic to the server in the DMZ, you’ll no longer be able to get out there and manage your other servers.

All port 22 traffic from the LAN would be redirected to the nginx server in the DMZ.

An easy way around this is to configure the server to listen for incoming SSH connections on a different port.

We’ll do that now.

Get on your DMZ server and go to the command prompt.

Install openssh-server by typing sudo apt install openssh-server -y.

Once ssh server is installed, you can change the default port to a port of your choosing by editing the /etc/ssh/sshd_config file.

First make a backup copy of /etc/ssh/sshd_config.

cp /etc/ssh/sshd_config /etc/ssh/sshd_config.0

The .0 assumes this is the original backup of sshd_config which would be sshd_config.0.

If you have other backup copies and you want to save them, increment the last digit appropriately.

After you’ve made your backup, edit /etc/ssh/sshd_config.

sudo vim /etc/ssh/sshd_config

Scroll down to the line that says #Port 22.

Uncomment it by deleting the leading #.

Change 22 to 2222.

This will now be the port your server listens for SSH connections on.

Check to see that the service is enabled with systemctl.

systemctl is-enabled ssh

If the system responds with ‘enabled’ you’re good. If not, you can enable it by running:

sudo systemctl enable ssh

Check whether it is running with:

systemctl is-active ssh

If the system replies with ‘active’ you’re good. If not, activate it by typing:

sudo systemctl start ssh

Restart ssh to have it listen on the newly configured port of 2222 by typing:

sudo systemctl restart ssh

You can check the ssh server status at any time by typing:

systemctl status ssh

There should be a line that says Active: active (running) since… in the output.

Finally, test to make sure it works.

ssh <username>@localhost -p 2222

Replace <username> with the username you’re logged in with.

ssh tedl@localhost -p 2222

in my case.

You’ll be prompted for a password, and be logged in if ssh is working correctly and your credentials are right.

If you’re using the username you configured at start up, you should already have sudo permissions. It’s good to test that they work over ssh though.

While connected over ssh, type sudo su -. If you get a root command prompt, you’re good.

If not, type sudo usermod -aG sudo <username> to add your user to the sudo group.

sudo usermod -aG sudo tedl in my case.

That’s it! Good job!

In the next lesson, we’ll configure the firewall to pass traffic on TCP port 2222 to the web server in the DMZ.

pfSense Firewall

Configuring a DMZ - SSH Firewall Configuration

In this lesson, we’ll configure the firewall to forward outbound traffic from the LAN on port 2222 to the nginx server in the DMZ.

To do this, go to Firewall, NAT.

Under Port Forward, click Add with the down arrow to put the  new rule below the existing HTTP rule.

Interface will be LAN.

Protocol is TCP.

Destination is the LAN address.

Destination port is 2222.

Redirect target IP is the IP of our web server. 10.10.0.10 in my case.

Redirect target port is 2222.

Add a meaningful description such as “SSH from LAN to DMZ on port 2222.

Leave Add associated filter rule selected.

Click on Save, then Apply changes.

To test, ssh from your LAN computer to the LAN IP on your firewall on port 2222.

ssh <username>@ 192.168.1.1 -p 2222

That’s it! You’re done with this lesson.

Good job!