Naieve Config Ques: Why not enable all?
-
[1] Each interface has a separate setup:
-
For Categories, why would I not simply enable them all? (How about a set-all and clear-all button too)
-
For Pre-Processors and Flow, why would I not check all?
[2] I have a trusted network (LAN), a less trusted for Windows machines (YEL), and an untrusted for game boxes (ORA). It seems to me that I should attach snort to WAN and my other two internal networks, either of which could be trying to attach my LAN. Is this good reasoning?
Thanks.
-
-
It would help to know what you are talking about. It took you until almost the last sentence to say it was snort, that sort of thing should be in the topic to draw attention to the thread.
Enabling all categories takes up a lot of RAM and CPU time and will also likely give you a lot of false positives. There is really no reason to run with everything on in most any situation.
As for point 2, that is up to you, but in situations with untrusted clients it does help to attach to the internal interfaces. At least until snort is done inline.
-
Jimp, I apologize for the poor question. Thank you.
I assume that I would pick rules for ports/services that I have open. No sense analysing attacks on things I don't have. There is little information in the names alone. What information does one use to decide which to pick? It seems unreasonable that every pfsense/snort user is intimately familiar with the insides of each of these rule sets. I am trying to figure out how to approach this. Would you please point me in the right direction?
Thanks.
-
Well you generally pick what kinds of traffic you want to be on the lookout for. Services you run are one rule to follow, but you also need to be aware of services you do not ever want to see on your network as well, plus attacks of varying kinds (spyware, etc)
For example, if you're only running a web server, you may want to run some of the rules that apply to https, and you may also want to be sure that the web server never has something like IRC traffic coming from it – that could be a sign it has been compromised.
Running an IDS and doing it well will take some tuning. If you have the spare RAM and the spare CPU cycles, load 'em all up and see what gets triggered. If "good" traffic is triggering a rule, disable it or disable that set.
It really is all up to the admin of a network to make these choices - only the admin of that network will know what should and should not be present there.