OPNsense Forum
Archive => 15.7 Legacy Series => Topic started by: smajor on July 06, 2015, 12:35:10 am
-
Greetings. I'm exploring 15.7 and found the Intrusion Detection! Excellent job, devs!
First, I checked the wiki because I'd like to learn a little more about it since I've not heard of Suricata before now. Some general questions:
1) By default, IDS is monitoring LAN, is this correct? I would have thought I'd want to watch for these at WAN.
2) Is there a list somewhere, (Suricata site?) that defines what all of these rulesets are? Some are obvious, some not so much.
Once again, thank you. Very nifty!
-
smajor,
(1) I think this was cut+paste from the proxy config. I've changed it to WAN for 15.7.1:
https://github.com/opnsense/core/commit/a1aabc11d631a7ab018bde72d2c5f56d41e2b316
(2) The current rules files come from Emerging Threats, the files that are preloaded were actually shipped with suricata (thus they are old):
https://github.com/opnsense/core/blob/fa8bf4e4ba6167a3186d94d4a1095b550cdede85/src/opnsense/scripts/suricata/metadata/rules/et-open.xml
More file descriptions and remote download support is coming soonish as we gather and implement user feedback, e.g.:
https://github.com/opnsense/core/issues/237
Cheers,
Franco
-
hi smajor,
please take a look here at http://rules.emergingthreats.net/open/suricata/ . They are Emerging Threat rules for suricata. You can manually push them too if you like incase you are looking for regular updates. Also, ET website has detailed description on individual rule and sub rules.
For detailed documentation, please look here http://doc.emergingthreats.net/
-
Its not at all a bad thing to run suricata on LAN as well as WAN.
Run limited set of rules on WAN and the whole encilada on LAN. That means you can track the culprits to specific internal IP's instead of your public WAN.
I havent tested the ability to run 2 instances of Suricata in opnsense but it should be able to.
-
Right now it complains of experimental support in libpcap using two interfaces in the same instance, but it runs. To enable intrusion prevention we need to migrate to ipfw or pf hooks, which takes care of that problem. If we have two instances, should they have completely separate configs?
-
There is both pro's and con's of that.
If they could run on the same overall ruleset with individual boxes ticked then it would be awesome.
Otherwise it would have to run on 2 seperate instances consuming double the ressources depending on the ruleset boxes ticked.
Snort runs like that in pfsense and can comsume quite a lot on the smaller systems with limited ressources.
-
Right now it complains of experimental support in libpcap using two interfaces in the same instance, but it runs. To enable intrusion prevention we need to migrate to ipfw or pf hooks, which takes care of that problem. If we have two instances, should they have completely separate configs?
Trust me on this. You don't want to run two different instances at the same time on moderate hardware. The preprocessors totally bog down the CPU. Besides, running on LAN side creates extra load on suricata daemon as devices on LAN always engage the preprocessors of IDS. The WAN is sufficient. Take an example, you have a LAN infection and your device is trying to communicate with Command & Control servers for Botnet, Malware, Adware, etc then outbound LAN connection also triggers an alert on the IDS.
True, ipfw is the way to go if IPS is under consideration. Or have like Barnyard + Snort with the current stable release for a total IPS solution.
-
Running on LAN will able you to take the infected host offline quickly. Running on WAN you only see the traffic src ahnd dest. IP which is the public one. Then you have to dig deeper to find the culprit.
Notice time here is of essence. The faster you find it, the better for everybody.
I run 2 instances of Snort on every single firewall that I have (46) to be precise for that exact reason.
They run as frontend and then I have a L7 able backend to sort traffic further based on rulesets and buzzwords before passed on to the servers.
-
Running on LAN will able you to take the infected host offline quickly. Running on WAN you only see the traffic src ahnd dest. IP which is the public one. Then you have to dig deeper to find the culprit.
Notice time here is of essence. The faster you find it, the better for everybody.
I run 2 instances of Snort on every single firewall that I have (46) to be precise for that exact reason.
They run as frontend and then I have a L7 able backend to sort traffic further based on rulesets and buzzwords before passed on to the servers.
You are absolutely right. I clearly mentioned "moderate hardware" . I run 4 instances of IPS on every single appliance that i ship but thats on carrier grade 12 core machines with 32G of minimum RAM.
-
I actually tested it quite a lot in the case with SYN flooding and the sweet spot for pfsense/opnsense is 4 cores on the same socket and 4GB memory.
It performs damn well on that exact combo and dont ask me why.
Its like when you move across sockets something fucks up pf and the whole route of packets and the attached CPU's does a bad job spreading the load.
-
I actually tested it quite a lot in the case with SYN flooding and the sweet spot for pfsense/opnsense is 4 cores on the same socket and 4GB memory.
It performs damn well on that exact combo and dont ask me why.
Its like when you move across sockets something fucks up pf and the whole route of packets and the attached CPU's does a bad job spreading the load.
Thats cool Supermule.
With what pre-processors enabled? 4 Cores is pretty good and is above moderate hardware. If you open up and see the insides of Juniper SRX200 series then you will see Dual OCTEON chips. That brings us to a never ending debate created by them so called "hardware based crap" :D
4 IPS instances gave me max 5+ Gbps IPS througput per device with the 12 Cores clocked at 2.25Ghz. Can you run some benchmarks with OPNsense on your current hardware please?
-
Yes. But I dont run OPS in production where I sit on some serious hardware.
I only test it at home on a CARP cluster with 8 cores and 32GB ram total pr. server.
Wont run OPS in production yet since IDS/IPS is not at par yet.