Snort intercepts incoming traffic on WAN going to DMZ clients

pftdm007

I am trying to find out what would be the best practices/recommendations on Snort's configurations on a pfsense box handling multiple LAN subnets.

My simple setup:

WAN (snort running)
|
pfsense
|
--LAN (snort running)
--LAN2 (snort running)
--DMZ (snort NOT running)

LAN/LAN2/DMZ are VLANs based on the same physical interface. DMZ is a guest subnet with its own tagged Wifi AP. Obviously, nothing is filtered on DMZ, hence why Snort is not running on that interface. Firewall is also very minimal (* . * allowed to the outside, same incoming).

pfBlockerNG & DNSBL are also excluded from DMZ (thanks to the folks on the pfblocker subforum!)

The issue is, Snort running on WAN intercepts and blocks incoming traffic going to DMZ.

Typical example: DMZ client runs Skype, it sends a request to an external server, no problem since Snort is not running on DMZ, but when the response comes back, it is intercepted on WAN and cannot travel back to the DMZ client.

So I guess my setup is not atypical. How do you guys run/configure Snort? I dont want to disable rules on WAN which would reduce the security of LAN and LAN2 just because of DMZ...

bmeeks

You should generally never run Snort on the WAN when you use NAT and you don't have native services running open to the public on the firewall. Put Snort only only on your internal interfaces. In your case, that would mean LAN and LAN2 (if you don't want it on the DMZ).

Remove the instance from the WAN. Common sense will tell you that since DMZ traffic has to come through the WAN, and Snort is on the WAN interface, that Snort will alert on DMZ traffic traversing the WAN (that would be outbound traffic from the DMZ and the stateful replies to said traffic).

pftdm007

Hello @bmeeks

I just read Snort documentation and some forum posts, and yes, it is clear as day: don't run Snort on WAN. But to me its counter-intuitive. How would my network be protected against outside threats if I have no guards at the main gate of my castle? My point is, since most (all?) threats are from the outside (the web), not guarding the main entry point seems incoherent. Is this possible because of the firewall rule on WAN blocking any kind of incoming traffic ?

I am not currently using NAT, port forward, etc so WAN rules are pretty much stock from pfsense:

Block private & bogon networks
Block IPV4+6 * . * to * . *

For example right now Snort blocks tons of malicious IP's from the internet. All kind of stuff, portscans, failed or automated SSH attempts, MSSQL connection attempts, etc.. Most of the IP's are from China or Russia so why is Snort seeing this traffic and blocking it although WAN FW rule should be blocking it? Unless the traffic gets identified by Snort and blocked by the FW rule at the same time.....

bmeeks

@pftdm007 said in Snort intercepts incoming traffic on WAN going to DMZ clients:

Hello @bmeeks

I just read Snort documentation and some forum posts, and yes, it is clear as day: don't run Snort on WAN. But to me its counter-intuitive. How would my network be protected against outside threats if I have no guards at the main gate of my castle? My point is, since most (all?) threats are from the outside (the web), not guarding the main entry point seems incoherent. Is this possible because of the firewall rule on WAN blocking any kind of incoming traffic ?

I am not currently using NAT, port forward, etc so WAN rules are pretty much stock from pfsense:

Block private & bogon networks

Block IPV4+6 * . * to * . *

For example right now Snort blocks tons of malicious IP's from the internet. All kind of stuff, portscans, failed or automated SSH attempts, MSSQL connection attempts, etc.. Most of the IP's are from China or Russia so why is Snort seeing this traffic and blocking it although WAN FW rule should be blocking it? Unless the traffic gets identified by Snort and blocked by the FW rule at the same time.....

Every one of those things you listed on the WAN is just typical Internet "noise". Your firewall has a default "block all" rule for incoming traffic on the WAN. So all of that traffic is going to be ignored by the firewall anyway. The only way your WAN will let something come in from outside is if an internal host started the conversation and thus a "state" is established for the returning response. So you are blocking things twice. Once with Snort and then your firewall is immediately behind Snort and it blocks it as well. This assumes you have the typical firewall setup where there are no "pass rules" for incoming traffic on the WAN. The default rule is "deny all", and thus all unsolicited inbound traffic is blocked. Only stateful reply traffic will be allowed in.

Look at this simplified block diagram of how traffic flows with Snort running using Legacy Mode Blocking:

IDS-IPS Network Flow - Legacy Mode.png

In order for any LAN host (or DMZ host, or in fact any internal interface) to talk with the Internet, the traffic must come into that interface and then be passed to the WAN. So if you run Snort on that internal interface it will see the traffic and can block it there. That will keep your internal hosts from starting a conversation with some "bad guy host" on the Internet.

Running Snort or any IDS/IPS on the WAN creates two problems. One is the problem you are experiencing where you want different rules for different interfaces. Can't do that with Snort on the WAN as those rules will sort of trump everything else. The second problem with Snort on the WAN is that all alerts only show the firewall's public IP for the internal host. So that means when you have an issue with an internal host you can't track down which one it is unless you resort to elaborate packet captures and matching NAT rules to devices.

When you run the IDS/IPS on the internal interface (LAN, DMZ, etc.), the IP addresses will be the native ones (that is, before NAT happens). Put Snort on your LAN and any other internal interface you want to protect and monitor, and remove it from the WAN. Your life will be much easier and you won't lose any security at all.

pftdm007

@bmeeks said in Snort intercepts incoming traffic on WAN going to DMZ clients:

Only stateful reply traffic will be allowed in.

This really helped me see things.... I get it now!

Thanks @bmeeks for this clear answer!

pftdm007

As we discussed before, Snort is NOT running on neither DMZ or WAN. A client on DMZ triggers alerts on the snort LAN interface when accessing one of the LAN client considered an exception by firewall rules.

Normally, FW rules would forbid communication between DMZ and LAN (in both directions), but I have a network printer on LAN which I want clients on DMZ to have access to, so a FW rule on DMZ allows traffic from . to that particular client on LAN. Simple enough....

If Snort on DMZ is not running (no instance configured at all) why is it causing alerts on the LAN interface? I thought Snort alerts was for incoming traffic, kinda like FW rules.

The alert had source IP = 192.168.2.206 (DMZ subnet) and destination 192.168.3.13 (LAN subnet).

It would appear as if Snort is inspecting "bi-directionally"? Am I missing something here?

bmeeks

Snort on any interface will be inspecting traffic coming "in"on that interface. So for your LAN, it is seeing packets as they enter the firewall immediately off the NIC but before the actual pfSense firewall engine sees them.

Obviously a packet coming from a LAN device headed to a DMZ device will have addresses in it (as source and destination) from both networks. Snort will trigger on the content of the traffic (typically on the payload, but could be the header depending on the rule). Snort will then attempt a block one or both of the IP addresses it sees in the packet. This is where the Pass List comes into play. An IP address on the Pass List will not be blocked. Another thing that comes into play is how you have the blocking option for "Which IP to Block" configured on the INTERFACE SETTINGS tab. The default is BOTH, but you can optionally choose SRC or DST. However, the choice made here can still be overriden by the Pass List.

I don't really understand your question. If a client on the DMZ is speaking with a client on the LAN, and that conversation triggers a Snort rule on the LAN, then it will fire an alert on the LAN. This is expected. I'm not sure what you expect to happen in that case. The traffic flow is in on the DMZ from the device, then out on the LAN to the device there. When the LAN device replies, the traffic comes in on the LAN and flows out of the DMZ interface to the device on the DMZ network. Snort is seeing that bi-directional flow (the initial query from DMZ and the reply from the LAN) on the LAN interface. That's how things are supposed to work. Now if that DMZ client is talking to someone out the WAN to the Internet, and Snort is not running on either interface there, then there will be no alert.

pftdm007

@bmeeks said in Snort intercepts incoming traffic on WAN going to DMZ clients:

I don't really understand your question. If a client on the DMZ is speaking with a client on the LAN, and that conversation triggers a Snort rule on the LAN, then it will fire an alert on the LAN. This is expected. I'm not sure what you expect to happen in that case.

Hello @bmeeks

That wasn't really a question more than trying to understand how snort works. Basically you're saying that the alert triggered on LAN occurred during the reply from LAN client to DMZ client? That would make sense...

Request: DMZ client -> DMZ iface -> LAN iface -> LAN client
Response: LAN client -> LAN iface -> TRIGGERS Snort alert & traffic blocked (or alert only)

bmeeks

@pftdm007 said in Snort intercepts incoming traffic on WAN going to DMZ clients:

@bmeeks said in Snort intercepts incoming traffic on WAN going to DMZ clients:

I don't really understand your question. If a client on the DMZ is speaking with a client on the LAN, and that conversation triggers a Snort rule on the LAN, then it will fire an alert on the LAN. This is expected. I'm not sure what you expect to happen in that case.

Hello @bmeeks

That wasn't really a question more than trying to understand how snort works. Basically you're saying that the alert triggered on LAN occurred during the reply from LAN client to DMZ client? That would make sense...

Request: DMZ client -> DMZ iface -> LAN iface -> LAN client
Response: LAN client -> LAN iface -> TRIGGERS Snort alert & traffic blocked (or alert only)

Yes, although it could also have occured in the other direction when the DMZ client initiated the conversation with the LAN client. Snort would have seen the packet as it left the firewall's filtering/routing engine and was being handed to the NIC driver for transmit. Remember that Snort sits between the NIC driver and the firewall's filter and routing engine. Either way, the alert would be triggered by the LAN instance of Snort and would only show up on the ALERTS tab when you are viewing the LAN alerts.