@Fmstrat:
I have all of them enabled except sensitive data. My hardware setup is an internal NIC for LAN, and a USB NIC for WAN. I tried switching snort over to the LAN and it seems to function fine there, so I'm wondering if the issue is somehow related to the network card itself. Is that even physically possible given snort's architecture?
As I look at the snort blocks', I'm actually curious as to if running on the LAN is better. When I run on WAN, I can't see which internal IP is engaged in the connection that causes the alert, making it very hard to trace sources. However, when it's on the LAN, all the alerts display the internal IP and the blocks show the external IP, which makes it much easier to debug. Is there any downside to running on the LAN end of things? Seems the benefit would be scanning internal traffic for infected machine, but the downside would be missing external attackers that are scanning ports that are already blocked by the firewall (which shouldn't matter, really.) Thoughts?
Ben
P.S. Unfortunately, I probably won't get back to the script we discussed until next week.
I don't think you will get good success with USB NICs on pfSense.
The LAN will show a little more detail. If you want more, you need a full IDS like "Security Onion" installed after pfSense or before it.
Bill does recommend that a smaller list be put on the WAN like Port scans, Cins, Compromised, Drops, etc… and than as many rules on the LAN that it can handle (without the rules you don't require for your network)
If you use pfBlocker (or my script ;) ), you could also avoid the Cins, Drops, Compromised on the WAN as Snort sees a copy of the packets first before pfBlocker and they will both Log the same packets.
Make sure you check out my Github Gist for recent changes to the script.
Thanks.
