Best rules to best protection in WAN and LAN Interface
-
Hello guys !
I'am nobe with Pfsense , especially with Snort IDS/IPS
and i would protect/monitor my network traffic . Which rule should be implemented for protect my network from risk and attack ?
-
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.
-
@trumee said in Best rules to best protection in WAN and LAN Interface:
@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.
See my most recent reply to @torefloo. When I say "LAN" I am just using that as a reference for any internal interfaces.
-
Help me understand something. I have HAProxy set up on pfSense that proxy's over to backend servers on the LAN. I understand the noise that get's generated if i set up Snort on the WAN interface, by default all unsolicited WAN traffic is dropped, but when I have port 80 and 443 allowed through the firewall to "This firewall" to the pfSense, how can I set up Snort to only apply the snort rules if ports 80 or 443 are alerted?
I do get a bunch of noise as mentioned on the WAN interfaces on other Dports 1433, 3389, etc that I do not have opened in the firewall rules, but I also get port 80 and 443 targeted with attacks and would like to mitigate them. Short of offloading ha proxy duties to a VM that resides on a dedicated LAN interface, I am not sure on what I can do.
Setting monitor mode on the LAN interface does me no good because the attacks are hitting the pfsense firewall on port 80/443 and are not sent down to a LAN machine to respond to.
Current WAN firewall rules:
Snort Alerts on WAN Interface Port 80:
The destination IP is my WAN interface IP.
Snort Alerts on WAN Interface Port 443:
-
This post is deleted! -
@maksimred20 said in Best rules to best protection in WAN and LAN Interface:
Help me understand something. I have HAProxy set up on pfSense that proxy's over to backend servers on the LAN. I understand the noise that get's generated if i set up Snort on the WAN interface, by default all unsolicited WAN traffic is dropped, but when I have port 80 and 443 allowed through the firewall to "This firewall" to the pfSense, how can I set up Snort to only apply the snort rules if ports 80 or 443 are alerted?
I do get a bunch of noise as mentioned on the WAN interfaces on other Dports 1433, 3389, etc that I do not have opened in the firewall rules, but I also get port 80 and 443 targeted with attacks and would like to mitigate them. Short of offloading ha proxy duties to a VM that resides on a dedicated LAN interface, I am not sure on what I can do.
Setting monitor mode on the LAN interface does me no good because the attacks are hitting the pfsense firewall on port 80/443 and are not sent down to a LAN machine to respond to.
Current WAN firewall rules:
Snort Alerts on WAN Interface Port 80:
The destination IP is my WAN interface IP.
Snort Alerts on WAN Interface Port 443:
Huh? What you are asking really makes no sense. Try restating your issue again in another way to see if I can understand what you are asking.
Each rule has its own set of criteria derived from the particular threat that rule is designed to detect. That means the rules are looking at all kinds of criteria for matching including (usually) destination port numbers.
-
@bmeeks said in [
Each rule has its own set of criteria derived from the particular threat that rule is designed to detect. That means the rules are looking at all kinds of criteria for matching including (usually) destination port numbers.
This is the answer I was looking for.
-
@maksimred20 said in Best rules to best protection in WAN and LAN Interface:
@bmeeks said in [
Each rule has its own set of criteria derived from the particular threat that rule is designed to detect. That means the rules are looking at all kinds of criteria for matching including (usually) destination port numbers.
This is the answer I was looking for.
Maybe you are asking why those ET Dshield rules were alerting on port 443?? Those rules, and a few other similar categories such as CIARMY, are simply looking at the source IP address. If the source IP is in a list of "known bad actor IPs", then the rule alerts. Has nothing to do with the destination port (usually) for those kinds of rules. But other rules categories would be looking at the destination port. It all depends on what the rule is looking for.
-
I guess what I was asking is if Snort/Suricata can only add offenders to the block list if Dports 80 or 443 rules are triggered, all other alerts can be ignored, don't add to block list, they are blocked anyway.
-
@maksimred20 said in Best rules to best protection in WAN and LAN Interface:
I guess what I was asking is if Snort/Suricata can only add offenders to the block list if Dports 80 or 443 rules are triggered, all other alerts can be ignored, don't add to block list, they are blocked anyway.
No, that's not really possible nor desirable. I think you are fundamentally misunderstanding how an IDS/IPS works and what it looks for, or else you would not be asking that question. Do some Google research for how IDS/IPS operates and how to select rules to match threats and exposed attack surfaces within a network, and I think you will be able to see that your question is not logical with regards to an IPS/IDS.
-
I challenge the idea that there is no point in having snort on the LAN interface if there are no open ports to the LAN. Having snort on the LAN interface should block malicious code from reaching out to the internet. So this will mitigate the damage of a bad download. Do you agree?
-
@gspatton I think the point with enabling Snort on LAN is that you have control of what kind of traffic is going out from the network. Let say you have critical tools on LAN and multiple developers with access to those servers. They can misconfigure or install some malicious software. IPS/IDS will detect it once such application tries to connect to the Internet and based on rules configured on IPS/IDS will block such traffic. At least that how I see it. Most important you will know something is not right and start further investigation. Can you use other tools for that - sure, but IPS might actually save your bacon :)