@JohnSCarter:
Hello all,
Recently I've had some time on my hands and I've been thinking about pfSense and have some questions and was hoping that someone could elaborate as I'm not quite getting my head around them.
Question 1:
Is there any way to mass-drop rule actions in Suricata / snort just because I don't have time to 100% be active on my network to see the alert telling me that malware has infected my system and also because manually changing the "alert" rules to "drop" (even with a AHK script) takes more time than I have in a day.
Question 2:
With IDS/IPS systems (for someone who doesn't have time to sit and monitor their constantly active network 24/7) why aren't most rules set to automatically drop, for example if there was a rule for a packet that's a known malicious packet that compromises a system and that packet triggered a rule but the action was "alert" wouldn't that be pointless? like a fire alarm with a 6 hour delay, wouldn't the damage already be done?
Question 3:
Obviously putting all the firewalls, IPS/IDS and additional content filtering systems in place is good however none of it means anything if pfSense itself is compromised, I was just wondering (from somewhat of a "lamens" perspective) what is done to keep pfSense secure, how difficult it would be to compromise and if there's any way to check / know if your pfSense is compromised (perhaps a tool or checklist of sorts?)
Thanks for your time,
John.
Question #1 Answer:
You don't have to change each rule action to DROP in order to get a block if you simply do these two things:
(1) Use Legacy Mode blocking (on the INTERFACE SETTINGS tab) and then;
(2) Uncheck the option for "Block on drops only".
If you do those two things, then every single rule that raises an alert will result in a block. Just be prepared for some frustration, though, since with all the sloppiness in web programming these days you can expect some rules to trigger that are enforcing various standards. When those standards are not ahered to, the rules trigger. You can mitigate this somewhat by being more selective in the rules you enable.
Question #2 Answer:
Because most security admins want to be notified of issues, evaluate the alert to weed out false positives, and only then enable blocking. This is to prevent the "frustration problem" alluded to in answer #1 above. Put yourself in the shoes of a network security admin in a Fortune 500 corporation who just turns on an IPS with all the rules enabled and all the rules set to drop traffic. Just imagine how many times his phone would ring from users whose computers stopped working because of all the blocked traffic. Would it not be better to run with everything in alert, analyze the received alerts, weed out and either disable or suppress false positive rules, and only then enable blocking?
Question #3 Answer:
Firewalls are incredibly hard to compromise unless they are horribly administered. All the stuff you see on TV shows where the "good guy" hacks into the firewall to save the day is just BS. Doesn't happen. But if your firewall is compromised, then all bets are off. If you are really paranoid, you could put Suricata inline between your firewall and your first LAN switch and run it on a separate physical box. You would also need a NIC that fully supports Netmap and Inline IPS mode.
Bill
