SNORT On LAN Makes AppID Useless

[House Of Cards]

The new common wisdom seems to be that you put Snort on your LAN interface so you can see what is going on inside your network, but when you do that you make every AppID alert trigger a block for that application.

Am I missing something?

Should I run Snort on the LAN without blocking enabled, and also run it on the WAN and block there? If I do that will I still see the internal IP's on the LAN?

What do you folks do?

Thanks,
Steven

[bmeeks]

@wormuths said in SNORT On LAN Makes AppID Useless:

The new common wisdom seems to be that you put Snort on your LAN interface so you can see what is going on inside your network, but when you do that you make every AppID alert trigger a block for that application.

Am I missing something?

Should I run Snort on the LAN without blocking enabled, and also run it on the WAN and block there? If I do that will I still see the internal IP's on the LAN?

What do you folks do?

Thanks,
Steven

What is your use case for OpenAppID? Typically that is not something you want to use in a home environment. It does not matter where you run it (WAN or LAN), if the rule triggers the traffic will be blocked.

OpenAppID works much better using Inline IPS Mode so that all traffic from a host is not blocked. Inline IPS drops only specific packets triggering the rule instead of blocking at the IP level.

The LAN is the best place to run and IPS/IDS for two reasons. First, it will be shielded from all the noise on the WAN interface coming from the Internet. The IPS/IDS sits out in front of the kernel's NIC interface, so it will see and process traffic that the firewall is likely to drop anyway (especially inbound on the WAN). Second, putting the IPS/IDS on the LAN lets you see the actual local host IPs in the alerts since on the LAN you don't have NAT rules getting in the way.

[House Of Cards]

@bmeeks Good morning…

There really is no urgent use case except it provides insight into what activity goes on inside the network. The long term plan is to integrate something like grafana to be able to visualize what applications are using bandwidth. Neither is terribly important though.

Since we’re on the topic, I have Snort running on the LAN and WAN. Alert on the WAN and block on the LAN. Are there any security implications of this setup? I found it to be the recommended configuration by a few who seemed to be knowledgeable…. But after all, this is all just “taking advice from someone on the internet”..

I guess the question is does it still adequately block this way? I know it inspects packets before even entering the firewall, so it sounds safe…. But second, third and fifth opinions are always helpful.

I have a Plex server exposed with a port forward, but nothing else. And that’s running in a BSD jail with only read only access to the media it serves. So as long as Snort will block that on the LAN side, I feel pretty good about it.

Thanks for the advice.
Steven

[bmeeks]

@wormuths said in SNORT On LAN Makes AppID Useless:

@bmeeks Good morning…

There really is no urgent use case except it provides insight into what activity goes on inside the network. The long term plan is to integrate something like grafana to be able to visualize what applications are using bandwidth. Neither is terribly important though.

Since we’re on the topic, I have Snort running on the LAN and WAN. Alert on the WAN and block on the LAN. Are there any security implications of this setup? I found it to be the recommended configuration by a few who seemed to be knowledgeable…. But after all, this is all just “taking advice from someone on the internet”..

I guess the question is does it still adequately block this way? I know it inspects packets before even entering the firewall, so it sounds safe…. But second, third and fifth opinions are always helpful.

I have a Plex server exposed with a port forward, but nothing else. And that’s running in a BSD jail with only read only access to the media it serves. So as long as Snort will block that on the LAN side, I feel pretty good about it.

Thanks for the advice.
Steven

I don't know who told you it was a good practice to run Snort on both the WAN and LAN, but block only on the LAN and alert on both. That is asinine, to put it mildly. It is a complete and total waste of CPU resources and RAM.

There is no security implication of doing this, but it is completely pointless and accomplishes really nothing. Let me start by sharing once again two diagrams I have shared several times in this forum. The two diagrams below show how Snort (and Suricata, if you use it instead) pipe into the pfSense network plumbing.

Notice where the IDS/IPS sits in each diagram. It is always in front of the firewall engine when evaluating inbound traffic on an interface.

So that means when on the WAN, it sees all of the Internet noise the firewall is going to block anyway. I assume you have zero (or very, very few) inbound ALLOW rules on the WAN. So why bother inspecting traffic that is going to be dropped by the firewall? You are spinning CPU cycles and wasting RAM doing that in my view. And if you are not blocking on the WAN, then I REALLY can't see the point of putting IDS there. Add to that the fact all local hosts are hidden behind the public WAN IP due to NAT, and that setup becomes a non-starter for me.

In order to actually reach hosts on your protected LAN, the traffic will have to traverse the IDS/IPS instance on the LAN. Same for traffic leaving your LAN heading out to the Internet -- it must also traverse the IDS/IPS. So that's why the LAN is the best placement location. And if you have mutiple internal interfaces such as a DMZ or Guest WLAN, then feel free to put an IDS/IPS instance on those interfaces.

[House Of Cards]

@bmeeks Thanks for the clarification.

When you search for “Snort WAN or LAN”, the first result you get is this…

https://forum.netgate.com/topic/82334/snort-at-home-wan-or-lan

They block on WAN there but run on LAN also…. So I was trying to figure out what works best. There’s a lot of different options to configure this, and even the Lawrence Systems YouTube video on AppID shows him running AppID on his LAN but not blocking on that interface.

Some is preference, but I want security over the ability to see who may be watching Netflix at any given moment. I appreciate your expertise. I’ll be taking snort off the WAN tonight.

Have a good weekend.

[bmeeks]

@wormuths said in SNORT On LAN Makes AppID Useless:

@bmeeks Thanks for the clarification.

When you search for “Snort WAN or LAN”, the first result you get is this…

https://forum.netgate.com/topic/82334/snort-at-home-wan-or-lan

They block on WAN there but run on LAN also…. So I was trying to figure out what works best. There’s a lot of different options to configure this, and even the Lawrence Systems YouTube video on AppID shows him running AppID on his LAN but not blocking on that interface.

Some is preference, but I want security over the ability to see who may be watching Netflix at any given moment. I appreciate your expertise. I’ll be taking snort off the WAN tonight.

Have a good weekend.

Going back later and reading my initial post I realized I may have come off as a bit harsh ... . In my defense, it was early morning in my time zone and I was still working on the first cup of coffee.

But I do stand by my belief that little is gained these days running IDS/IPS on your WAN. My question to folks who do that is "What are you protecting, your firewall?". If you don't think your firewall is up to protecting itself from inbound traffic, then you really need to consider changing the firewall.

Remember that the only path to your protected hosts from the Internet (or WAN) is through the LAN (or other internal interface). So it is sufficient to place the IDS/IPS there in my view. You may run it in blocking mode or in IDS (alerts only) mode. And if you use Inline IPS Mode, you get the best of both worlds because you can run some rules with ALERT as the action (it's the default, anyway), and then run other rules with DROP as the action (that will essentially block packets that trigger the rule).

My stance is putting the IDS/IPS on the WAN does not do enough for security to make up for the troubles it creates. First, all alerts have internal hosts masked behind the NAT address typically. Second, you spend a lot of CPU cycles analyzing traffic the firewall is not going to pass anyway.

[House Of Cards]

@bmeeks No worries. I didn’t take anything harshly, and I certainly get the “don’t expect much before coffee” thing.

Yeah, I’m going to take the WAN out of the equation completely and run it on the internal interfaces.

One other quick question if you don’t mind? I’ll explain…

I have alias’ set up for device types, like desktops, laptops or servers…. I also have a configured rules to forward each alias to the VPN which I can enable or disable at will. So basically, if I decide all the cell phones in my house should go through the VPN, I turn on the firewall rule to forward the cell phone alias to the VPN gateway. Works like a charm.

In this scenario, the LAN is forwarding to the VPN gateway, so should I treat the VPN as just another WAN type interface, or would you run Snort on VPN for some reason I’m not seeing?

Don’t ask…. I just like unwarranted complications.

[bmeeks]

@wormuths said in SNORT On LAN Makes AppID Useless:

@bmeeks No worries. I didn’t take anything harshly, and I certainly get the “don’t expect much before coffee” thing.

Yeah, I’m going to take the WAN out of the equation completely and run it on the internal interfaces.

One other quick question if you don’t mind? I’ll explain…

I have alias’ set up for device types, like desktops, laptops or servers…. I also have a configured rules to forward each alias to the VPN which I can enable or disable at will. So basically, if I decide all the cell phones in my house should go through the VPN, I turn on the firewall rule to forward the cell phone alias to the VPN gateway. Works like a charm.

In this scenario, the LAN is forwarding to the VPN gateway, so should I treat the VPN as just another WAN type interface, or would you run Snort on VPN for some reason I’m not seeing?

Don’t ask…. I just like unwarranted complications.

Since your phones' traffic still has to come into the LAN interface in order to get routed over the VPN, then the IDS/IPS instance on the LAN will see everything. So no need to put it on the VPN.

There is a caveat, though, with IDS/IPS today no matter what interface you run it on. It cannot peer into encrypted traffic. And the vast majority of all traffic today is encrypted. Heck, even some DNS is now encrypted via TLS. So just remember that many of the rules you enable for Snort really don't do a whole lot with encrypted traffic. That means it is not looking into emails, it's not looking at most web traffic data since that is now HTTPS via SSL, and if you or your clients use DoT, it's not looking at DNS either. So while it can see the IP address, and the little bit of currently not encrypted SNI info, it is not looking at the actual data payloads in the vast majority of packets.

The OpenAppID stuff, for instance, is simply looking at the unencrypted header info to guess at the traffic type. That's all it is doing, though. It can't see the payloads of each packet due to encryption.

[House Of Cards]

@bmeeks Good info...

As they say, security isn't one thing, it's a lifestyle... I could easily buy some generic router like everybody else, but I made the choice long ago to try and be a little more secure. Even if it's a never ending learning curve.

I'm just a home user trying to learn as I go to keep myself a little more secure online. You've been very helpful, and I appreciate it.

Thanks again.

[RegalMonkey]

Thought I'd put in my 2 cents since I happened across this looking for an AppID database somewhere...

Snort appears to be one of the heaviest resource users on a pfSense box, so running it on the external side is not really a grand plan with all the noise out there, or at least not a fully stacked policy. What I've gone with is to run a full policy with all the rules on the inside networks and use the external as a 'test' space by not blocking and only enabling new categories/rules. With a decrypting proxy in the mix both in and out it gives greater visibility on the inside, but by putting it in a test mode like that on the outside first I can get some idea of if the rules are excessively noisy or likely to cause major outages before actually putting them inline.

By only putting the few new rules on the outside it limits the processing used by snort when, like mentioned above, most is going to be whacked by the FW anyhow.

[House Of Cards]

@jobathenoob Thanks.

Yeah, I opted for just using them internally. It’s just a home network on overkill anyhow. . To be honest, I haven’t had any real issues beyond suppressing some of the more mundane stuff like some http_inspect false positive annoyances.

I pay for the snort ruleset and stick with the predetermined profiles. Between snort and pfblocker it can easily drag even a decent machine down if you overdo it.

My network has a four port NIC and I use separate Wi-Fi routers in bridge mode to have, for example, a separate Wi-Fi network for IoT devices versus my regular network. This allows me to prohibit an insecure IoT device from making connections to other things that matter on different segments and such. It’s way more than the average Joe needs, but it prevents some back door made in china sensor from connecting to my laptop.

It also means snort on multiple interfaces…

I’m much happier now though with my changes. I trimmed pfblocker back a bit too. The wife is much happier with fewer random things breaking. . And I’m using maybe 15-30% of ram, cpu or swap at any moment so it’s not struggling at all.

Steve