Snort as IPS on WAN behind (VDSL-)Router
-
Hi there,
just wondering whether you can actually use Snort in IPS-Mode (block offenders) if your WAN-Interface got a static private IP behind a providers router on the wall? Could it actually detect external IPs or would it only try to nlock the router? ;)
thank you very much =)
-
Hi there,
just wondering whether you can actually use Snort in IPS-Mode (block offenders) if your WAN-Interface got a static private IP behind a providers router on the wall? Could it actually detect external IPs or would it only try to nlock the router? ;)
thank you very much =)
Is this a home-user setup? If so, are you saying the provider's VDSL modem handles the NAT and all your pfSense box gets is a private non-routable IP?
In this setup, I would suggest you run Snort on the LAN side. It will put the WAN IP and the far-end default gateway IP (which should be the LAN side of your VDSL modem) into the default Pass List and not block them.
Bill
-
…and if I want to block (external) offenders? - i do not have any chance to in this setup?
thank you. :D
-
…and if I want to block (external) offenders? - i do not have any chance to in this setup?
thank you. :D
Putting your Modem in "Bridge Mode" will help get Snort/Suricata to work as intended. It will also make NAT work if you require that (avoids Double-NAT)
-
@bmeeks Is it useful put snort on WAN interface for block portscans and attacks?
-
@v0id said in Snort as IPS on WAN behind (VDSL-)Router:
@bmeeks Is it useful put snort on WAN interface for block portscans and attacks?
Only if your doing port forwards on the WAN interface to the LAN or If you're interested in seeing what's hitting your WAN.
-
@v0id said in Snort as IPS on WAN behind (VDSL-)Router:
@bmeeks Is it useful put snort on WAN interface for block portscans and attacks?
Do you have internal services open to the Internet?
- Do you have a public web server behind pfSense?
- Do you offer email services from a server behind pfSense?
- Do you provide a publicly accessible DNS server behind pfSense?
If the answer to those questions is "No", then you do not need an IDS/IPS on your WAN. By default, out of the box, unless you change it pfSense will drop all unsolicited inbound traffic. All putting an IDS on the WAN would do in that case is just put another block on top of an existing block. The WAN default rule is going to block the traffic and the rule inserted by Snort would block the same traffic. What's the point in that?
If you want to run an IDS/IPS, put it on the LAN and perhaps other internally-facing interfaces.
-
@bmeeks Have no public internal services, just wanted be protected from attacks and port scan on public IP
-
@v0id said in Snort as IPS on WAN behind (VDSL-)Router:
@bmeeks Have no public internal services, just wanted be protected from attacks and port scan on public IP
Read what I posted again. Do you understand that pfSense will, by default, block all external sources from connecting to your firewall? So what good does Snort do in that circumstance? How can it help improve security. If pfSense is already going to block the port scan attempt, what's to be gained by having Snort block it again? If you scan the WAN side of a pfSense firewall from an external host, it will show nothing. No ports open at all. So out of the box a port scan is worthless to an adversary.
The only time a port scan matters (and even then, the risk of such an attack is somewhat overblown) is if you have a series of public-facing servers such as web servers, DNS servers, email servers, etc., and there are rules in place on the WAN to allow traffic to those servers. In that case you might want to add an IDS/IPS on the WAN to police traffic before it reaches those kinds of servers.
However, in a typical home setup using NAT, you have nothing "visible" to the Internet on the WAN side of your firewall. None of your hosts can be contacted nor connected to unless the internal host initiates the conversation. And in that case, the stateful inspection engine of the firewall will set up a temporary "allow" rule to let the reply traffic come in through the WAN and then on to the internal host that started the conversation.
And if you put Snort on the WAN and enable the portscan feature, expect to see quite a number of false positives caused by what is today just normal traffic. The portscan preprocessor is somewhat easily fooled by the way certain applications work today. It will false-positive on some traffic, block the external host, and then you will have grief with your internal clients as the application will likely quit working.
-
This post is deleted!
