Suricata crashes on rule reload
-
Since I have a NAS in my home network, and I am planning to host a site on it, and run a honeypot (not necessarily in that order), I am steadily increasing my network security :). It is true that the blindness of an IDS / IPS in regards to encryption puts a serious marker on their usefulness.
To familiarise myself with actual malicious alerting in suricata, i thought honeypot x suricata on my FW would make sense.
I do like how, in contrast to pfblockerng, it gives me much more information as to why it alerts (or blocks), eg. an emerging-dns 'contacting a .to domain'.@bmeeks said in Suricata crashes on rule reload:
Yes, but for a home network you would usually not need these categories:
- ET-Policy
- ET-Info
Luckily those were already disabled! I've added an attachment in spoiler of how i currently configured the ET rules.
Didn't find an easier way to export the currently active rules
-
@b3rt: go learn about the features on the SID MGMT tab in the package. So much easier to manage rules and categories that way.
You will find a Sticky Post on the topic at the top of this forum. The feature is available for both Snort and Suricata, and it works the same way in both packages.
-
@b3rt said in Suricata crashes on rule reload:
even though i was already implementing the sid management way of editing the rules.Thx, already on it :).
-
@b3rt said in Suricata crashes on rule reload:
host a site on it, and run a honeypot
Two very bad ideas in my opinion.
First, do you have a static IP from your ISP? If not, hosting a public website is more of a challenge requiring a Dynamic DNS provider configuration. Additionally, almost every ISP I've heard about prohibits hosting public services on your residential connection in their terms of service. You may find yourself in hot water at some point with your ISP if you host a website. If you want to host a website, pay the small fee for a genuine hosting service using a VPS at a data center. They at least likely have the infrastructure to protect from most DDoS attacks. Your ISP and your residential connection can never hope to cope with a DDoS attack. And if one is launched against your public site on your residential IP because somebody gets mad with you, then your ISP is certainly going to terminate your connection (and likely permanently).
Why would you want a honeypot on your home network? I can't fathom that at all. It's like riding through the most crime-ridden neighborhood in your town in an expensive convertible sports car wearing diamond jewelry and a Rolex watch in plain view. You are going to attract the attention of someone who would have otherwise ignored you.
-
@bmeeks The honeypot would be located in a different subnet (a dmz, as you may). Primarily I want to collect attack patterns logs, analyze them on a grander scale in my ELK stack.
@bmeeks said in Suricata crashes on rule reload:
First, do you have a static IP from your ISP?
My public IP has changed once or twice since i've started using my pfsense about a year ago, so not static.
Afaik my ISP should allow it, with port forwarding and ddyns it shouldn't be a problem. I'll definitely read through EULA again before it do it though, thanks for the tip! -
@b3rt said in Suricata crashes on rule reload:
@bmeeks The honeypot would be located in a different subnet (a dmz, as you may). Primarily I want to collect attack patterns logs, analyze them on a grander scale in my ELK stack.
@bmeeks said in Suricata crashes on rule reload:
First, do you have a static IP from your ISP?
My public IP has changed once or twice since i've started using my pfsense about a year ago, so not static.
Afaik my ISP should allow it, with port forwarding and ddyns it shouldn't be a problem. I'll definitely read through EULA again before it do it though, thanks for the tip!You might also want to check if your IP from your ISP is in CGNAT space. That is becoming much more common these days than it used to be. If in CGNAT space, then outside direct access is not possible unless your ISP creates the necessary port forwards in their routing infrastructure. I would say the odds of them agreeing to do that are slim and none
. -
@bmeeks Fortunately, this is not the case for my ISP :). I already thought it wasn't a problem since my openvpn setup just works like <public_ip:port> and port forwarding isn't really a problem (although this could also be due to PCP afaik).
-
Just as an addendum, i've noticed my device(the SG-2100) wouldn't support inline blocking mode, so i'd have to use legacy mode.
I'll need to rethink my strategy for network defense because this HW doesn't seem up for it. -
@b3rt said in Suricata crashes on rule reload:
Just as an addendum, i've noticed my device(the SG-2100) wouldn't support inline blocking mode, so i'd have to use legacy mode.
I'll need to rethink my strategy for network defense because this HW doesn't seem up for it.Yes, the Inline IPS Mode is limited to only NICs that support native netmap operation. While netmap can run in an emulated driver mode, that mode is quite inefficient and can handicap IPS mode performance, especially on marginal hardware.
The PHP code checks the NIC in use against a list of drivers known to support native netmap operation. If the NIC is not in that list, an error is printed and the change to Inline IPS Mode is not allowed. On FreeBSD, these are the approved drivers:
cxgbe,em,iflib(providingvmx,igbandem),ixgbe,ixl,re, andvtnet -
@bmeeks Right! The sg-2100 has the mvnat variant.
I did however improve the stability of the system by making some changes to my auto backup config. Turning of 'creating a backup after each config change', has enabled me to update suricate rules without it crashing. I'll test this evening to see up to which point!
