The Internet is full of malicious actors looking to take advantage of insecure networks and devices. While corporate and government targets may be the biggest targets because of the valuable data they possess, home users still need to be cautious. Phishing attacks usually via email is the most common attack for home users. Fortunately, those attacks are typically easy to avoid by cautious users that do not blindly click every attachment and web link contained in their emails.
However, malicious activity is becoming increasing common in regards to consumer routers and Internet of Things (IoT) devices, which many users have on their home network. Software and firmware updates for routers and IoT devices are often neglected by users – either due to lack of awareness and/or the lack of technical ability to apply the updates.
Many routers are providing intrusion detection as an additional security feature. Routers typically have firewall capabilities built in and there is a growing trend to also include intrusion detection. Intrusion detection can be used in conjunction with the standard firewall on the router and provides an additional layer of security. You can think of intrusion detection as a set of indicators/rules that may be used to alert or block specific types of Internet and network traffic. It can be potentially suspicious or dangerous traffic or other unwanted traffic on the network (such as peer-to-peer or tor traffic).
OPNsense is an open source router software that supports intrusion detection. Once enabled, you may select a group of intrusion detection rules (aka a ruleset) for the types of network traffic you wish to monitor or block. The rulesets can be automatically updated periodically so that the rules stay more current. Some rulesets are free while others require a subscription. For home users, the free rulesets should offer reasonable protection.
If you are planning to build your own router, go to my Amazon affiliate link for some hardware ideas. Fanless mini-PCs are great for this purpose since they are small, silent, power efficient, and have 2 to 6 Ethernet ports on them. You will need at least 2 ports since one port will connect to your modem and the other to your LAN which is most likely a network switch so you can have more ports. Also you may want to pick a device that supports AES-NI if you plan to use features that make heavy use of encryption such as a VPN server. Otherwise, you will place a heavy load on your router and potentially slow down your network throughput.
Configuring Intrusion Detection in OPNsense
To configure intrusion detection in OPNsense, go to Services > Intrusion Detection > Administration > Settings. Click the “Enabled” checkbox to enable intrusion detection. It will not actually enable until you click the “Apply” button. To allow network traffic to be blocked instead of only generating alerts, click the “IPS mode” checkbox. If you are using VLANs, you will need to click the “Promiscuous mode” checkbox. This is important in order to capture data on the physical network interface.
The pattern matcher defaults to Aho-Corasick but if you have a modern CPU, you can likely set it to Hyperscan. I noticed a huge increase in network performance on my LAN interface when using Hyperscan. I highly recommend using this setting if you have a modern CPU since the performance increase is quite significant. I no longer notice any drop in performance when using the Hyperscan option. According to this OPNsense forum post, the Hyperscan algorithm should work with 64-bit processors that support SSE3 instructions.
In the “Interfaces” select box, choose the networks in wish you want to apply intrusion detection. The most important thing to note is that you must only select physical interfaces and not VLAN interfaces. If you select a VLAN interface, you will end up causing your VLANs to not function at all.
A word of caution from my experience: I made the mistake of selecting all of my VLAN interfaces when I first set up intrusion detection. None of my VLANs functioned properly when I turned on intrusion detection. That was the consequence of not reading the help message. Also, I may not have had “Promiscuous mode” activated (probably another consequence of not reading the help message). Those two options are very important to set correctly if you have VLANs.
Also some of the help tips included in the user interface suggests that “Promiscuous mode” could cause issues with certain adapters. I have read that Intel network adapters typically have the best support while Realtek is lacking (but may be getting better). Some users have reported issues if they are using certain virtualized network adapters if they are running OPNsense in a virtual machine.
As you can see, I have set my interfaces to be the WAN and LAN interface so I can block Internet and any local network traffic that could be hostile. All of my VLANs are located on the physical LAN interface and by selecting the LAN interface, my VLANs are being monitored and protected by the intrusion detection service. I have noticed that I get many more alerts on my LAN interface than my WAN interface, which I was not expecting. I am supposing that it is due to the direction of the network traffic. Regardless of the technical reason(s), it is blocking a good bit of traffic and it does not seem to interfere with any legitimate network or Internet service that my family uses, which means it is wife approved.
When you have set these options, click “Apply”. Even though we have enabled intrusion detection, nothing is really going to happen at this point until we have downloaded some rulesets.
I have read where the intrusion detection functionality is primarily designed to protect the network traffic on the WAN interface, which makes sense. You certainly want to protect the interface connected to the Internet to prevent malicious traffic from entering your network. Some have recommended to not enable intrusion detection on the LAN interface or any other internal interface – at least not until you have carefully vetted all of the rules that will be blocking network traffic. I am assuming that you risk blocking legitimate services on your network if you enable blocking on some of the installed rulesets. I have several rulesets enabled with blocking turned on and have not experienced a lot of problems.
However, I did encounter an issue recently with streaming live TV, and I later discovered that intrusion detection was slowing the local network throughput significantly for file transfers (around 30-60 MB/s instead of saturating the 1 Gbps network connection which is around 115-120MB/s). Those are the two biggest issues I have encountered so far, but I was able to resolve both issues.
I also read that it is a good idea to enable intrusion detection on the LAN when NAT (Network Address Translation) is used (which is in use by nearly all home networks) since it helps to troubleshoot issues on the local network more than just enabling it on the WAN interface. The reason is that all traffic on the WAN would look like it originates or terminates on the WAN interface so you do not have visibility into which device triggered the alert or block.
I have discovered why the WAN interface practically showed no alerts/blocks. There is a note on the OPNsense documentation page for intrusion detection which states that if you are using NAT, which most home users will be doing, that you need to set the WAN interface IP address to the list in “Home network” section of the intrusion detection settings page. You will need to click the “Advanced” button at the top of the page to see this configuration option. It should already have all private IP address space included.
Simply add your WAN IP address. If your WAN address changes, this will need updated. It may be possible to use a dynamic DNS service and put the hostname in the list. I do not know if hostnames are supported but it quite possible it will work. I have found that hostnames will work in places where IP addresses can be entered (like firewall rules and aliases).
Please note if you do this, you should probably not enable the LAN interface also since you may get duplicated hits in the rules. I have not tested this out to know if that is true. It is something to consider. Mostly likely you would want it on the LAN instead since you can see where traffic is being blocked in more detail. If it is enabled on the WAN, the source/destination is always going to the WAN address instead of the device originating the traffic. Right now I am trying out the new Sensei plugin in OPNsense (a topic for another article perhaps?) since it has some very cool reports and live viewing of network traffic. To use Sensei I had to remove intrusion detection off of the LAN so it would not conflict, but I kept intrusion detection enabled on the WAN interface so that I could still have it protecting the network.
Downloading and Enabling Rulesets
There are various opinions on which rulesets you should download. Some recommend downloading all of the rulesets in order to potentially have the most protection. Others said you should only pick the rulesets that apply to your desired concerns for your network and that it is a waste of hardware resources to select them all. To get a description for the ET rulesets, please refer to the Emerging Threats PDF.
In either scenario, it is important to consider how much hardware resources you have allocated to your OPNsense router. If you have a lot of RAM and a decent CPU, you will be able to apply more rules. Intrusion detection will most likely eat up more of your RAM than any other service you are running on your OPNsense router. I have a majority of the datasets enabled on my router, and I am sitting at around 1.5-2 GB of RAM usage. I have 8 GB of RAM available which is overkill for my usage, but I was afraid I would regret only have 4 GB of RAM if I started turning on a several memory hungry services. Network throughput may be another concern if you enable all of the intrusion detection rulesets especially if you have underpowered hardware and a fast Internet connection.
Go to the “Download” tab and click the checkboxes beside each ruleset you wish to enable. When you are finished selecting rulesets, click the “Enable selected” button to enable the rulesets. Then click “Download & Update Rules” button to retrieve the rules.
By default, all of the rules are set to only alert and not block network traffic. This is intentional so that you can see the types of data that the intrusion detection will be blocking. To view the alerts, click on the “Alerts” tab. If you are content with the data the rules are blocking, you may go back to the “Download” tab and click on the pencil icon that is beside each rule. When the dialog box opens, click the select box and choose “Change all alerts to drop actions” to set all of the rules in the ruleset to “block”. This is much quicker than selecting individual rules in the “Rules” tab and blocking the individually since there are thousands of rules. One thing to note is for the rulesets that state they include rules for detecting basic activity, you may not want to blindly block all rules because you may end up blocking legitimate network traffic (see the Emerging Threats PDF for more details).
Scheduling Updates to Rulesets
Finally, all that is left to do is schedule a time for the rulesets to be updated. Go to the “Schedule” tab and click the “enabled” checkbox. Then enter a time you would like to update the rules. On my router, I set it to 2 am every day. For the “Command” select box, select the “Update and reload intrusion detection rules” if it does not already default to that option. You may optionally provide a description. It will be displayed along with any other scheduled tasks you may have set up for other services.
Congratulations on configuring your intrusion detection service! You should now feel warm and fuzzy knowing that you are more protected than you were before completing this task!
Please Note: You should be aware that the free intrusion detection rulesets are on a 30-day delay from the paid rulesets so it is possible you could still get hit by rapidly spreading zero-day vulnerabilities. While keeping up on patching will not necessarily prevent you from getting hit by a zero-day, it is still a very good practice because the Internet still gets probed by attackers for vulnerabilities which already have patches available hoping to find unpatched systems. They are often very successful with unpatched routers and various IoT devices.
If you wish to pay for a subscription to have more up to date rules, the cheapest ruleset for home users is likely the Snort VRT rules for $29.99/yr. To access these rules, you must enable them from the OPNsense plugins page and sign up on the Snort website.
Update – Alternative Ruleset!: Since I originally wrote this how-to, I discovered that you can get a free version of the ET Pro ruleset if you are willing to allow telemetry data to be submitted to Proofpoint (the vendor which maintains the ET Pro ruleset and sell subscriptions). If you are ok with submitting encrypted, anonymous data to that security company in exchange for the latest and greatest rules, this may be the best route to take to get frequently updated rules for free. You may even have a warm, fuzzy feeling knowing you contributed to helping improve detection rules.
After some time, you may periodically check the “Alerts” tab to see the activity that is occurring on your network. It will list the time of the event, whether the connection was blocked or simply logged as an alert, the interface the event occurred, the IP addresses of your network and/or Internet devices that are in communication, and the description of the rule triggered.
Below is another example that I thought was interesting and would demonstrate how useful an intrusion detection system can be even for a home user. I occasionally take a look at the logs to see if there is anything interesting going on. Low and behold I spotted the following in my alerts:
If you look at the very bottom of the log, you will notice the IP address of 126.96.36.199 which triggered two Microsoft IIS remote code execution attempts. Then further up in the log you will see quite a few “403 Forbidden” alerts that must have been triggered due to attempting to access protected resources on my web server. I did not have time to check my web server logs to determine which resources were being accessed but that would have probably been an interesting exercise. I did look up the IP address, and it originates in Beijing, China. It would be interesting to know if it was simply a random drive-by Chinese hack attempt.
I will note that I am not running any Microsoft IIS servers so it would probably be ok for me to turn off that alert/block. I began going through some of my alerts and turning off blocks for software/hardware that I am currently not using or will probably never use since there is no sense in wasting router resources on processing thousands of rules that are of no use to me. You will find that many suggest pruning your list of rules to make them more applicable since intrusion detection is not simply an enable and forget type of process.
Alerts (and blocks) such as these are why I like having intrusion detection enabled on my LAN interface since I would not have noticed this if it was only enabled on my WAN interface since it receives very few alerts. I would say this is especially true if you are running servers which have a few services exposed to the Internet. I have made a few tweaks to my configuration that helps keep the performance impact on my LAN interface very minimal, which is what I like. Fast local network speed with decent security controls that do not impact any legitimate services.