Taming the beasts… aka suricata blueprint
-
Hello jflsakfja, thank you for your replay. Yes, all is ok, no errors on the logs and the interface is running. I don't know if something is wrong. I only find it weird that I don't have no alerts in 6 days, but then again, probably your rules blue print is that good and I don't get any false positives :P.
The only thing that I would like is to force some kind of attack or error that would trigger the alert in suricata just to be sure that everything is ok.
I will take advantage of this post to ask if you think that it's a good practice to have suricata on the lan ports? On snort I had it working, and a rarely get any alerts, but it helped me once to diagnose some malware in some computers. Snort started blocking all the connections to the WAN because it detected something suspicious.
Best Regards
Soloam -
Without knowing how closely you followed the guide (for example, did you set up unused ports rules?) I can't say how you can easily test it. If you left the ping rules enabled for example, a simple ping from outside the network to your WAN should show an alert.
I often get asked if it's a good idea to have snort/suricata enabled on LANs. I'll flat out say my answer: I don't think it's a good idea to set up identical setups on WAN and LANs and expect an increased sense of security. Some rules aren't designed to be used like that. snort/suricata on an internal interface (the way I set them up) only uses custom rules (IF the interface requires an IDS in place).
Some people are already taking aim with their stones at hand, so I have to be quick to explain that. 3 interface setup, extrapolate from there: WAN, LAN1, LAN2:
LAN1 is your admin interface.
LAN2 is your general "browse the net" type of interface.LAN1 should ONLY have access to the admin ports. Hosts on this interface shouldn't be able to access anything else. Ideally it's a single system that is on this interface. Easy to identify a compromised system, things should show up in the logs. 99.9999% of installations are NOT set up like this.
LAN2 clients should be able to browse the net, so connectivity to anything NOT LAN1 (get it? ;-)) should be allowed. Since these are client boxes, incoming connections to them shouldn't be allowed. The pfsense ports are already taken care of by the floating rule. Clients on this interface can only do these things:
1)Get compromised through a website/downloaded program
2)Compromise other systems on LAN2
3)Compromise foreign systems on WAN.in the case of 1) nothing you can do about that, other than keeping things up to date. WAN side snort/suricata will handle the alerting. If it's a 0-day exploit that's used against you, that means you pissed off the wrong persons ;-).
in the case of 2) No matter how you set up snort/suricata, the gateway NEVER SEES TRAFFIC INTERNAL TO THE NETWORK. Host1 wants to talk to Host2. Gateway1 won't see any of their direct packets. Without seeing their packets, snort/suricata will not alert. The only thing you can do about this, is have internal firewalls on each of the hosts (as you should) and keep them up to date.
in the case of 3) WAN side snort/suricata should catch the bad packets and generate an alert. At this point communication to the remote host has been cut off. The infected internal host, can't compromise what it can't see. This is where most people misunderstand things.
Ideally rules should be designed to fire up early in an "attack", not wait for the attack to be successful to generate an alert. Yes I do admit that it's difficult to do this, and not all rules follow it.
Since the remote host has been cut off, and you noticed the alert, you manually set up the packet capture on the internal interface to identify what host is doing the blah blah with the remote host (attempting to, but can't). You then proceed to unplug that host from the network and repair it.
Talking from a provider's POV, most things these days are using TLS/some other form of encryption. Unless you are actively MITMing the traffic that's passing through the gateway (if you do, you are a bad a person, shame on you), it doesn't actually matter if you have a WAN IDS, or a WAN and a million LAN IDSs. They still can't see inside the traffic.
My advice is don't focus too much on the network defenses and forget the other defenses. As mentioned in the guide, design your defenses in a layered form. Work from the inside out, not the outside in. A strong network defense, but a 13 year old webserver (yes I've seen in in real life by so called "industry experts") will not get you far down the line before someone compromises it. A weak network defense but an up to date and properly hardened server can withstand a whole lot of battering before showing any signs of weakness.
Again, don't forget that the same principles applied to servers can be applied to client machines as well. For example, raise hands everybody, who uses a separate browser profile to keep everything related to pfsense (cookies, cached files) separate from the rest of the browsing? You at the back? No? You in the front row? No?
Design security systems from the heart, or core, outwards. The strongest defenses should be at the center, even if they are never reached from the outside.
A recent (relative, more on this later) compromise of a customer's website has shown that internal security measures can be even more effective than strong perimeter ones. A few dozen backdoored files were uploaded to our servers, after going through a malware/antivirus scan (which missed the backdoor). The files were taken directly from the previous hosting company, downloaded, scanned, and uploaded (directly by me if anyone asks).
A week later, alerts started going off. The servers were attempting to send a very large volume of emails, coming from that domain. A quick look at them showed about 400 queued emails, sat there for the past 4 hours (an email server almost never queues emails more than a few minutes, let alone queue 400 emails from a domain that rarely sees 5 emails a day).
So how did the queued emails end up there? The server upon seeing an increased number of emails wanting to be sent, started slowly backing off on the sending rate for that domain. Suricata on the other hand saw that something was up (a few custom rules I use ;-)) and started banning remote servers.
The aftermath? A hidden spambot backdoor managed to send about 40 emails. Needless to say that the previous hosting company is still spamming (to this day) the hell out of everyone out there. When further analysis of the backdoor took place (and subsequent cleaning up of every infected file, by hand), the backdoor was found to be 2 different forms. One of them being early 2013 (yes almost 2 years ago) code. I don't care who is on either side. A 2 year old compromise (that is still undetected to this date) and a compromise completely fixed hours after it was used (NOT found out, used!), says a LOT.
Had this depended entirely on suricata with the default ruleset, I'm sure the servers would be at least on one (likely on all of them) of the 88 email blacklists that are out there :-). As I said, suricata isn't the tweak this knob, tweak that knob, OK, you now have the best security on the planet. Suricata combined with other security layers, yes that is the best you can get. Ideally suricata should be the first thing you install (well, after pfsense), but the last thing you finish setting up.
Back to my cave.
-
Great explanation jflsakfja.
I had a bad conclusion, my suricata is not working, I tried (temporary test) to allow ping to my wan port from a external address, and they passed with success, on suricata alert, still empty. =/
-
I guess I have my answer, looks it seems that suricata is not compatible with PPPOE :/
https://forum.pfsense.org/index.php?topic=73906.15
-
I guess I have my answer, looks it seems that suricata is not compatible with PPPOE :/
https://forum.pfsense.org/index.php?topic=73906.15
That's true for now. It is a limitation of the Suricata binary itself. FreeBSD presents a data link type for PPPoE that Suricata does not recognize at the moment. Snort will work, though if you want to try it instead. The DAQ module in Snort correctly handles the FreeBSD PPPoE data link type.
Bill
-
I used snort without any problem for some time, I changed to Suricata to test it out. Back to Snort for now.
Thank You
-
The only problem that I had with Snort, that lead me searching for a new IDS was the fact that Snort keep blocking my WAN ip, even that the ip is on the passing list (it's dynamic ip, its always changing, but the list is updated).
-
I just wanted to thank you all for the great write up! I really appreciate you taking the time to provide all of this information.
After following the guide I got everything working except for some of the PfIP Reputation widget output. Also, BBcan177 refers to version 2.3.4 of the pfiprep script but I am only able to find version 2.3.3. I feel I may be behind the times due to other updates that have taken place, but this was a great starting point for me.
I am running pfSense 2.1.5 and everything is going well. If there have been other changes due to software updates since this post began; would someone be able to point me in the right direction to learn about the changes/updates?
Thanks for all the great information!
Dan
-
A new guide is in the works, as well as a better "keeping the guide up-to-date" procedure is being worked on.
For now, this thread is a great starting point. Most updates in the new guide have to do with making it easier to set everything up, but the outline basically follows this guide.
I know I promised the new guide a while back. I haven't given up on, it's just that work has been keeping me a bit busy lately.
-
Thanks for the quick response. I definitely understand how wok can take up all your time!
Like I said, after following this guide everything seems to be running great except for some of the widget stuff to monitor the IP Lists. I need notice on the forums that BBcan177 is developing a pfBlockerNG package so I may look into that going forward. It would be nice to have that streamlined and able to backup.
Do you know of a way to backup the Suricata settings? I am not sure if they are getting backed up with the regular pfSense backup. I do not see them in the restore options. Also, anytime my box is power cycled I lose my Suricata block list. Is that the proper behaviour?
Your ET rule list on github is great! I have run into a few rules that trigger due to things I use day-to-day such as Cisco VPN phones and what not. Would you mind if I forked your list just so I can keep up with my findings?
I am also getting into writing some custom rules. I had to read your posts a few times but I think it has finally "clicked". Very exciting stuff!
Again…thanks for sharing with the community.
-
Thanks for the quick response. I definitely understand how wok can take up all your time!
Like I said, after following this guide everything seems to be running great except for some of the widget stuff to monitor the IP Lists. I need notice on the forums that BBcan177 is developing a pfBlockerNG package so I may look into that going forward. It would be nice to have that streamlined and able to backup.
Yes, BBcan177 is pushing towards a pfBlockerNG package. Should be very good when it's released. I'll leave it up to him for more info.
@dancwilliams:Do you know of a way to backup the Suricata settings? I am not sure if they are getting backed up with the regular pfSense backup. I do not see them in the restore options. Also, anytime my box is power cycled I lose my Suricata block list. Is that the proper behaviour?
Make sure you visit Suricata>Global settings> and tick the checkbox to keep the settings when the package is removed. That should take care of keeping settings between package upgrades/reinstallations if something goes wrong. As for transfering the complete settings over to a "new" system, bmeeks should be able to point out more details for it.
Yes, the blocked hosts get cleaned when you reboot. It's an annoying "feature" ;-)
Your ET rule list on github is great! I have run into a few rules that trigger due to things I use day-to-day such as Cisco VPN phones and what not. Would you mind if I forked your list just so I can keep up with my findings?
You are only permitted to fork the list if you contact ET and tell them the rules on the list have long been broken and should be removed/updated. Then you are free to do what you want with it. Except one thing, claim copyrights and sue me later :P
@dancwilliams:I am also getting into writing some custom rules. I had to read your posts a few times but I think it has finally "clicked". Very exciting stuff!
Again…thanks for sharing with the community.
Not a problem. I'll send an invoice later ;)
-
@jflsakfja:
Yes, the blocked hosts get cleaned when you reboot. It's an annoying "feature" ;-)
You really have to love those features. They are saving you from yourself you know….ha! :)
@jflsakfja:
You are only permitted to fork the list if you contact ET and tell them the rules on the list have long been broken and should be removed/updated. Then you are free to do what you want with it. Except one thing, claim copyrights and sue me later :P
I will definitely start hounding them. You are right…there are some rules in there that are just ridiculous! And no copyrights will be claimed...can't be too careful these days!
@jflsakfja:
Not a problem. I'll send an invoice later ;)
Of course! I just appreciate the chance to get to learn this stuff. ;)
-
Also, BBcan177 refers to version 2.3.4 of the pfiprep script but I am only able to find version 2.3.3.
Thanks Dan.. I moved my gist to the following URL.. Unfortunately I can't edit my original post.
https://gist.github.com/BBcan177/3cbd01b5b39bb3ce216a
If anyone else is using my pfIPrep script, please PM me and I will move you to the new pfBlockerNG package. As my script is a manual process, I can guide you on how to cleanly remove it.
-
So, I have fallen deep into this Suricata hole…so much you can do!
Is there a way to pass custom variables into Suricata through the GUI? I see under the interface "WAN Variables" there are some static definitions that can be adjusted, but I am curious about adding a few custom variables.
Thanks!
Dan
-
Do you mean declaring your own variables and using them in the rules? that was possible with snort (custom rules, declare the variables at the top), but suricata for some reason doesn't accept my custom variables.
Not particularly fussed about it, didn't give it too much attention. Maybe bmeeks can chime in if you can in fact do it.
-
Exactly,
Trying to pass in my own variables to use in custom rules.
Thanks!
-
Exactly,
Trying to pass in my own variables to use in custom rules.
Thanks!
Currently there is no way to handle this within the GUI. You can manually do this if you are willing to edit a file, and are willing to have the same custom variables defined across all interfaces. Here are the steps.
Edit the file /usr/local/pkg/suricata/suricata_yaml_template.inc
Locate this section of the file (it's near the bottom):
# Holds variables that would be used by the engine. vars: # Holds the address group vars that would be passed in a Signature. address-groups: HOME_NET: "[{$home_net}]" EXTERNAL_NET: "{$external_net}" {$addr_vars} # Holds the port group vars that would be passed in a Signature. port-groups: {$port_vars}Add your custom variables to the appropriate section (either address-groups: or port-groups:).
Be sure that you DO NOT change anything else in that section! Here is an example:
# Holds variables that would be used by the engine. vars: # Holds the address group vars that would be passed in a Signature. address-groups: HOME_NET: "[{$home_net}]" EXTERNAL_NET: "{$external_net}" {$addr_vars} MY_CUSTOM_ADDRESSS_GROUPS_VAR: "some_value" # Holds the port group vars that would be passed in a Signature. port-groups: {$port_vars} MY_CUSTOM_PORT_VAR: "some_number"This template file is used by the code to create the actual suricata.yaml configuration file for the interface. The string variables inside the braces, such as {$addr_vars} are replaced by values from the GUI code as it reads the config file. All you need to do is just add your custom variables beneath the existing string variables and they will be included in the generated suricata.yaml file.
Bill
-
bmeeks,
Thanks for the info! That is what I was looking for. Just wanted to make sure I was not missing a spot in the GUI.
Has anyone had any issues with Pass Lists in Suricata? WebEx keeps triggering a certain rule so I thought I would use a pass list for the WebEx subnets and leave the rule in place. I created the list with the appropriate subnets and restarted Suricata on the appropriate interface. I am still seeing alerts and blocks on those IPs.
Is there a step I am missing?
Dan
-
Yes, the part where you disable the rule :D
If a rule generates an alert, but you are absolutely sure that the alert shouldn't be generated (alert on an older version of the software in use for example) then disable the rule instead of suppressing/whitelisting it.
-
Great! ;D
I was not sure what the appropriate response to those situations would be.
Disable the rule it is!
Dan
