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.
-
@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.
