Best rules to best protection in WAN and LAN Interface
-
For someone new to an IDS/IPS, here is my recommendation.
-
Configure Snort on your LAN interface only. There is generally no extra security obtained by putting an instance on your WAN as the WAN, by default in pfSense, drops all unsolicited inbound traffic anyway.
-
Do NOT configure blocking at first. Just use the default IDS (detection-only) mode for at least two weeks and potentially a month so you can see what alerts happen on your network. This lets you investigate and weed out false positives without getting frustrated because things get blocked.
-
Register for either a free or paid ($29.99/year for paid) Snort Subscriber Rules Oinkcode. There is link for that on the GLOBAL SETTINGS tab when you click the checkbox to enable the Snort Subscriber Rules. For convenience, here is another copy of the link: https://www.snort.org/products#rule_subscriptions. Once you have done this, go to the UPDATES tab and force a rules update so your Snort Subscriber Rules will download.
-
Edit the LAN interface in Snort and go to the CATEGORIES tab. Check the box to use an IPS Policy and then choose IPS-Connectivity in the drop-down selector. This is an excellent starter policy that offers very good protection with hardly any false positives. Save the change then start Snort on the LAN interface (or restart it if it was already running).
-
Sit back and study the alerts you receive by periodically reviewing the ALERTS tab. It is likely you will get some false positive alerts from the HTTP_INSPECT preprocessor rules. Here is a link to an older thread about Suppression Lists and using the SID MGMT tab to control false positives: https://forum.netgate.com/topic/50708/suricata-snort-master-sid-disablesid-conf. Remember that with Snort, once blocking is enabled, every alert you see could have resulted in a block of host traffic. This is why you examine the alerts and suppress or disable those rules which are firing on benign traffic in your environment.
-
After you get the rule set tuned up, you can go back and enable blocking mode. If things are smooth, then you can bump up your IPS Policy to IPS-Balanced and see how that works for you. I do not recommend folks use the IPS-Security policy as that one enables a bunch of extra rules that are highly prone to false positives (especially in home networks). You can also choose to start using some of the free Emerging Threats rule categories by going back to the GLOBAL SETTINGS tab and enabling the Emerging Threats Open rules. You would then add those rule categories to your ruleset back on the CATEGORIES tab for your LAN interface.
-
-
@bmeeks why not just enable LAN, so you don't need to activate it for WAN interface because there will be attacks from outside.
-
@torefloo said in Best rules to best protection in WAN and LAN Interface:
@bmeeks why not just enable LAN, so you don't need to activate it for WAN interface because there will be attacks from outside.
By default Internet -> WAN would be blocked by the default deny rules.
The other advantage doing it on the LAN side is that you see the various LAN IP addresses, if you were to enable it only on the WAN you'd see just the WAN IP address.
-
@NogBadTheBad is 100% correct. In a typical setup the WAN will drop all unsolicited inbound traffic by default unless there is an existing state for it. There would be an existing state only if something inside the firewall started the conversation. Putting Snort or Suricata on the WAN means all the IP addresses you see in the alerts are after NAT is applied for outbound traffic and before NAT is undone for inbound traffic, so all of your local hosts (those on your LAN you are actually concerned with) show up as having your WAN's public IP address. This makes finding an infected host on your LAN very difficult.
Snort and Suricata are primarily designed to protect hosts behind a firewall, not the firewall itself. In order for any traffic from outside to get to a LAN host it must traverse the LAN interface of your pfSense firewall. Likewise, for any other locally-attached interface such as a DMZ, the same is true: the traffic must traverse that local interface to reach the hosts behind it.
The only potential case for putting an IDS/IPS on the WAN interface would be if you have public facing services running on the firewall itself (for example, you run an authoritative DNS server on the firewall or you run a public-facing web server on the firewall: both of which are very, very bad ideas anyway!).
-
thanks for the snort, only VRT is sufficient to enable.which settings you would like to activate.
-
@torefloo said in Best rules to best protection in WAN and LAN Interface:
thanks for the snort, only VRT is sufficient to enable.which settings you would like to activate.
I'm sorry, but I don't fully understand your post. Are you asking me a question or are you stating that you have the answer you wanted to your original question? Perhaps English is a second language for you and there is some misunderstanding on my part due to the translation. If you need more information from me, can you please restate your question?
Thanks!
-
@bmeeks said in Best rules to best protection in WAN and LAN Interface:
thanks for the snort, only VRT is sufficient to enable.which settings you would like to activate.
for snort settings, I only need to activate the VRT rule or recommend which other rules should be activated.
-
@torefloo said in Best rules to best protection in WAN and LAN Interface:
@bmeeks said in Best rules to best protection in WAN and LAN Interface:
thanks for the snort, only VRT is sufficient to enable.which settings you would like to activate.
for snort settings, I only need to activate the VRT rule or recommend which other rules should be activated.
For users new to administering an IDS/IPS I recommend starting with a basic security policy. The Snort VRT (Vulnerability Research Team) tags their rules with a piece of metadata called "IPS Policy". They have four policies they tag rules with. In order of increasing security those policy tags are:
- Connectivity
- Balanced
- Security
- Max-Detect (testing only)
That fourth policy (Max-Detect) is suggested for testing only as it will generate a ton of alerts and many of them will likely be false positives.
So when you install the Snort Subscriber Rules and enable automatic rule section via an IPS Policy, the Snort package will find all the rules from the Snort VRT that are tagged with the policy you select and add them to your list of enforcing rules. The Snort Subscriber Rules are the only ones tagged with this policy metadata. The Emerging Threats rules are not tagged with a policy, so using them requires manually selecting categories and then tuning individual rules in each category. That's a lot of work even for an experienced admin, and can be a bit overwhelming for a new security admin. That's why I suggest starting with the IPS Policy - Connectivity setting only.
There is nothing else you need to change in the Snort package out-of-the-box if you select to use the IPS Policy - Connectivity as I described above. As you gain experience you can experiment with other rules such as Emerging Threats and even the OpenAppID DPI ruleset.
-
@bmeeks thank you I have gained important information from you.
-
Very good info, Thanks! One question I have to clarify. I understand why no need to run IPS on the WAN and instead on the LAN. What about additional physical networks within? I have my lab of wired only devices on LAN port, and an additional OPT port configured as a separate subnet for wireless access point stuff such as crap devices as well as some trusted laptops that use the wireless. Should Snort be set up on all subnets inside the home network?
-
-
@aljames said in Best rules to best protection in WAN and LAN Interface:
Very good info, Thanks! One question I have to clarify. I understand why no need to run IPS on the WAN and instead on the LAN. What about additional physical networks within? I have my lab of wired only devices on LAN port, and an additional OPT port configured as a separate subnet for wireless access point stuff such as crap devices as well as some trusted laptops that use the wireless. Should Snort be set up on all subnets inside the home network?
As I mentioned everything by default is blocked by the WAN rules.
If you have any port forwards then also run Snort on the WAN, I have it on WAN and LAN, but it will show alerts 2 alerts per alert, 1 for the LAN and 1 for the WAN.
Treat any OPTx interface as a LAN interface, if they are VLANS run Snort on the parent interface as it puts the interface into promiscuous mode and captures all traffic.
-
@NogBadTheBad
By default Internet -> WAN would be blocked by the default deny rules.What is the default deny rules ?
-
@koko_adams said in Best rules to best protection in WAN and LAN Interface:
@NogBadTheBad
By default Internet -> WAN would be blocked by the default deny rules.What is the default deny rules ?
Block everything, by default, the rule isn't visible.
-
@koko_adams
Just to clarify as there may be some confusion here, @NogBadTheBad is talking about the hidden default pfSense firewall rules on the WAN. He is not talking about Snort rules.Out-of-the-box pfSense comes with the firewall rules defined that block all inbound unsolicited traffic on the WAN (from the Internet). These rules are hidden within the GUI, but they are there. The only way traffic can get into your firewall from the WAN using a default setup is if some host inside your firewall first initiates a conversation with a host outside the firewall. That conversation setup results in the creation of a "state" in the firewall, and that "state" allows inbound traffic to pass, but only that traffic destined for the internal host that started the conversation.
-
@bmeeks Well I will have one last question, this wan interface facing an iis server (web server) and the server we provide is the web server service that runs on plesk, but only if the LAN interface snort is still sufficient to activate.
-
@torefloo said in Best rules to best protection in WAN and LAN Interface:
@bmeeks Well I will have one last question, this wan interface facing an iis server (web server) and the server we provide is the web server service that runs on plesk, but only if the LAN interface snort is still sufficient to activate.
I'm having a little trouble following the translation of your question. What do you mean about an IIS web server facing your WAN interface? Do you mean the two are simply in the same subnet on the WAN side, or do you mean the IIS server is behind your firewall on some sort of DMZ?
Sorry, but the language translation is confusing me in terms of what you are asking.
-
@bmeeks iis server (web server) in the LAN network with the WAN interface to go out and request from outside. In this case it is only necessary to activate the snort on the LAN interface.
two interfaces are available WAN and LAN. -
@bmeeks Instead of saying setup SNORT on LAN, isn't it better to suggest putting SNORT on all the interfaces which are receiving port forwards from WAN. This would then cover DMZ and all other Vlan interfaces.
-
@torefloo said in Best rules to best protection in WAN and LAN Interface:
@bmeeks iis server (web server) in the LAN network with the WAN interface to go out and request from outside. In this case it is only necessary to activate the snort on the LAN interface.
two interfaces are available WAN and LAN.Yes, it is only necessary to install Snort on the internal firewall interfaces; be that a single LAN or multiple internal interfaces such as a LAN, Wireless LAN, DMZ, etc.
Do not get single-focused on the use of the word "LAN". I only mean that to represent internal (behind the WAN) firewall interfaces. If you have a DMZ with servers in it, then of course you can run a Snort instance there. I didn't literally mean just put Snort on the LAN and nowhere else.
