Best rules to best protection in WAN and LAN Interface
-
@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 :)
