Snort WAN/LAN NAT question
-
Hi,
I have been experimenting with pfSense/Snort for a week now and had a "ET TROJAN Win32.Sharik Microsoft Connectivity Check" detected. Only then I realized that I have no way to identify which computer on my network was causing this since I had been running Snort on my WAN interface (NAT entry was long gone).
So I'm guessing I have to run Snort on internal interfaces. Since I have lots of VLANs, how would I do this in an efficient way? I don't think the GUI allows me to select multiple interfaces and have all of them use the same configuration. Keeping the settings in sync manually/through the GUI doesn't seem efficient. Are there some files I can directly edit through Diagnostics –> Edit file?
Also, it was not my goal for Snort to inspect traffic between my internal networks (to save resources), but is there any other choice? Wouldn't it technically be possible for Snort to look up the LAN computer from the NAT table the moment it detects something and write that to the log?
-
If you search here, lot of people are running larger ruleset on their LAN(s) and a very basic one on their WAN(s). For this reason, among others. And actually yes, if you really want to keep the config in sync, you can just re-configure one interface, remove the others and re-add those with the + button next to the configured interface. But - there's really no requirement to keep those in sync, in fact pretty much waste of resources with a large ruleset.
-
In a WAN/LAN scenario where theres only two interfaces I get what you're saying, but I'm not sure I understand why I wouldn't need to keep the configuration in sync between my internal interfaces. If I want to inspect packets traveling to internet from any of my VLANs, don't I have to have all my rules enabled on them all?
Also if I send a packet from LAN1 to LAN2 and both have Snort enabled, is the packet inspected twice, meaning twice the CPU load? This wouldn't be good, since I really wouldn't care to inspect internal traffic at all.
-
In a WAN/LAN scenario where theres only two interfaces I get what you're saying, but I'm not sure I understand why I wouldn't need to keep the configuration in sync between my internal interfaces. If I want to inspect packets traveling to internet from any of my VLANs, don't I have to have all my rules enabled on them all?
Also if I send a packet from LAN1 to LAN2 and both have Snort enabled, is the packet inspected twice, meaning twice the CPU load? This wouldn't be good, since I really wouldn't care to inspect internal traffic at all.
You are correct about the extra load and double inspection. When NAT is involved, Snort setup can be problematic with more than one or two LAN (or VLAN) interfaces. It's just the nature of the beast.
Bill
-
Thank you for the comments. It would be interesting to know what's the best practice with bigger deployments (I'm not a network professional), Snort running on a different box before NAT takes place maybe? Anyhow, I still think it would be neat if Snort logging could consult the NAT table and log the internal IP address even when it's running on the WAN interface. I'll maybe end up enabling it on internal interfaces as needed and normally keep running it on the WAN only. On the other hand, that also wastes resources by inspecting packets that would be dropped by the firewall anyway.. decisions, decisions..
-
… Anyhow, I still think it would be neat if Snort logging could consult the NAT table and log the internal IP address even when it's running on the WAN interface...
This would require customizations to the underlying Snort binary (as in insert changes that are not currently in upstream). Right now the only modification to the Snort binary on pfSense is to include a custom output plugin to implement the blocking. That uses an established Snort API.
Bill
-
After upgrading one machine to Windows 10, I also started receiving the Sharik alerts in Snort. After poking around on google, seems that all the IPs are owned by Microsoft. Haven't really performed any additional analysis, but I'm guessing it's false-positives. Would be curious if you're also having this same issue.
-
Correct, this was a Windows 10 machine. The "offending" process was svchost.exe and the IP resolved to Akamai Technologies.
