how to exempt one host on LAN from Snort filtering
-
Hi all, we have Snort monitoring the WAN interface and it works wonderfully. The problem at hand is that we now wish one single host on LAN to be exempted from ALL Snort's filtering/blocking, because that host is a test machine and we want all traffic to flow from and to this host without Snort blocking any traffic. We understood that whitelist or Pass List has nothing to do with this, because these lists cater to the origin of traffic going through the WAN and we still want bad traffic to be blocked if it is not going to that specific host.
We also believe that this can be done by setting up custom rules that has a SID specific to that host, but we are not sure about this approach nor know how to do this using the pfSense GUI interface.
Is this something possible with Snort in the way it is being setup for our network, i.e. having Snort working on the WAN interface?
Thanks, William -
You can't is the simple answer. At least so long as you continue to run Snort on the WAN. Snort lives between the physical NIC and the firewall engine. That means it sees inbound traffic before NAT is unwound, and it sees outbound traffic after NAT is applied. So, Snort on the WAN has no knowlege of internal hosts' real IP addresses because it only sees the firewall's public WAN IP for anything "local".
Run Snort on the LAN. That is much better for the reasons listed below:
- It prevents Snort from wasting CPU cycles and RAM scanning packets the default firewall rules are likely going to deny anyway.
- It allows Snort to see the real private IP addresses of internal (LAN) hosts. That makes identifying which internal hosts are causing alerts much easier.
- You see a lot less "junk alerts" caused by all the Internet noise that hits a WAN interface.
I keep saying this over and over to folks. You don't run Snort to protect the firewall. You run Snort to protect internal hosts behind the firewall. Putting the Snort instance on the LAN fully protects internal hosts while avoiding wasting CPU cycles scanning typical Internet "noise" that the firewall rules on the WAN are dropping anyway.
Last point -- always remember that the vast majority of all network traffic these days passing through firewalls is encrypted. Think HTTPS, SMTPS, SSH, IMAPS, POP3S, TLS, DoH, and DoT. Snort can't see a single bit of payload within an encrypted packet. All it can see is the IP header info and sometimes a bit of SNI. The only way Snort can scan encrypted traffic is with a full MITM configuration, and currently that is not supported within the Snort package without a lot of customization.
-
Dear Bill, thank you for taking the time to reiterate what you had mentioned many times in the past in regards to best practice for Snort setup. I have spent time to read up on past postings this morning on the subject. In general, I think the wide spread of setting up Snort on the WAN was due to the many online sources doing that. But I think what you and a few others said made total sense in regards to running Snort on LAN, and I should follow that advice on my lab server.
The logical follow up question will then be if our original goal can be achieved after Snort is switched over to be run on LAN? If so, how is it done using pfSense interface?
Given the huge flexibility of Snort setup, I reckon that a lot of things are possible given the effort. So my question should really say if that can be done with reasonable amount of effort, so as not to waste your precious time to talk about an elaborate and involved solution.
The practical application for this goal of mine is to run a host on the LAN that has an app under examination. And we want to see what kind of traffic, legal or improper, that this app will require to run properly. And if this app is absolutely needed for the usage case, can it be given special privilage which we normally would not allow for other hosts on the same network?
One obvious solution is to put this host on a VLAN of its own, but we want to see if we can achieve that using some sort of "whitelist" for Snort instead of implementing a new network setup. Plus, VLAN solution might not work anyway because we read somewhere that we have to run Snort on the host interface for all the VLAN in order to put the interface in the right mode.
Lastly, following is an article I found on Cisco that could relate to the goal:
https://community.cisco.com/t5/security-knowledge-base/exempt-specific-servers-from-a-snort-rule-to-avoid-false/ta-p/4853155 -
Once you place Snort on the LAN, you have two avenues for exempting that "test box" IP from being blocked by Snort.
-
If you are only concerned with that host getting blocked and don't mind continuing to receive alerts, then you add that host IP to a custom Pass List and assign the Pass List to the interface under the INTERFACE SETTINGS tab. Save that change and restart Snort on the interface so it picks up the modification.
-
You can use a Suppress List entry filtering by host IP to suppress all alerts for that host. Suppressing the alerts will also prevent blocks.
-
If you don't want to receive alerts for that host and you want to not even really scan traffic for that host, then you can use a single PASS rule configured under Custom Rules on the RULES tab. Pass rules are evaluated first, and any traffic matching a pass rule is exempted from all further analysis. Be careful writing that rule and be sure it only applies to the specific host you desire. You can find "how-to" tutorials for Snort rules via a Google search.
-
-
thanks again Bill. That made total sense putting the host IP in the Pass List, because all the traffic would be initiated by that host when there is no NAT forwarding. And the alerts will give us an idea on what traffic will trigger Snort, which in turn will give us a better picture on the app that is running on the host.
And the suggestion to use a Pass Rule, if needed, is the bonus tip.
Thanks again. Without your feedback, it will take me a while to put 2 and 2 together. Have a great weekend. -
@wwoo said in how to exempt one host on LAN from Snort filtering:
a test machine and we want all traffic to flow from and to this host without Snort blocking any traffic
It seems that you could put that PC in a DMZ...
-
@NollipfSense
hi, that would be a way, or like we mentioned, put it in another VLAN. Well, VLAN does not work as well as DMZ like you suggested, but that was the idea if going that route. However, we are trying to assess if the app that is running on the particular host can be safely released to the "general population". Or what will be the minimum suppression rules we can get away with in order for it to run properly? Or what kind of compromise we need to take in order to run the app on this host?
The exercise will give us an idea on whether a new network/interface, like a DMZ, setup will be absolutely required.
Along the way, I also learnt quite a bit on how Snort works and what are good practices.
Cheers and thanks for the suggestion.
W
