Taming the beasts… aka suricata blueprint

A Former User

You didn't ask suricata nicely, that's why it's behaving badly. Most of those alerts are known FPs, as per the list linked to in this thread. Never add something that gives up an alert to a passlist. A passlist should only contain systems under your home net and DNS servers. Not a single host more than that. In other words, it should contain the bare minimum of systems that should NOT be banned, under any circumstance. Can you imagine what would happen if suricata decided to ban the DNS servers?

If a rule repeatedly gives a bad alert on known good traffic, suricata isn't the one that must be blamed. It's the rule writer that must be blamed and held accountable. Bug him until he changes the rule. Judging by ET's past record, it's not going to happen any time soon, but one can only hope.

Please remove the host from the passlist and disable the rules following instructions in this thread.

raab

Appears I missed one alert that was in your list, however these aren't in your list:

SURICATA IPv4 invalid checksum
GPL SHELLCODE x86 setuid 0
ET POLICY Download Windows Help File CHM 2
ET INFO EXE - Served Attached HTTP
ET POLICY Internet Explorer 6 in use

Also this is another alert I was getting downloading those iso's
ET EXPLOIT Windows Media Player parsing BMP file with 0 size offset to start of image

I'm certainly not blaming suricata, I completely agree with you that some of these rules are absolutely ludicrous..

I've removed the passlist and disabled the rules instead

A Former User

Too long night, too short day ;D

Those not on my list doesn't necessarily mean they are not false positives. Don't remember if it was in this thread, or the other (snort blueprint) that someone mentioned the ipv4 checksum one.

My list is the starting point, I can't possibly cover all the use cases out there. Adding to the list rules that come from external sources (other than me) means adding yet another layer of management to the list, something I currently do not have time for. For example I promised a new thread using the new auto management files, and guess what, haven't had time to even begin typing it yet.

This thread described the process of identifying FP rules, and how to deal with them. I'm not attacking you in any way, I'm just saying that a passlist is not the solution for this specific problem. Disabling the rules if you know the alerts are coming from a trusted source, is. If a rule is repeatedly found to be an FP rule, then the rule maintainer has the obligation to correct it, if everyone bugged them about it. He can't correct something that he doesn't even know is wrong. He must correct it though, if others tell him that it's wrong. As was mentioned, don't hold your breath on it when dealing with the ET rules. There are 10 year old rules in there that I have been personally screaming at the writers to remove, for years.

Then there are the "write once, never maintain rules", eg: NT 6.1. As mentioned, directed at ET, "FFS windows 7 IS 6.1, get it into your thick skulls and delete the rule already". Windows 7 was RTM'd on August 6 2009. That's 5 years of a rule FPing, and still counting, since as far as I can tell, they don't plan to correct it. 5 years of people telling you "you are doing it wrong", yet you still don't correct it. :o

raab

Haha tell me about it.

Don't worry, I'm not taking offence and know you weren't attacking me. I'm thankful for this thread and the work that you've done with your list.

Cheers for pointing out that I should be disabling rules if I'm certain its legit traffic, rather than using a pass list

A Former User

I have finally found a bit of time to work on the next part of this guide.

Roadmap:

Provide an easy way to upload minimal configurations to pfsense and get it going. Thanks to bmeeks for implementing the behind the scenes work needed for this. What would everyone's suggestion be as to the absolute bare minimum rules? Rules that generally cause mayhem when used, or add even more "delicate" rules (rules that might trigger an FP from akamai for example).
Provide the customizations recommended in this topic as an easily uploaded file/s
Start work on custom rules for the typical pfsense+suricata usage (network gateway). This came as an inspiration after having been bitten countless times by rules not making any sense at all. That and the push towards more encryption everywhere, which renders most ET rules invalid (not saying a bug, saying that suricata can't see inside the SSL traffic). Not saying that it will be the end-all-be-all configuration, it's just a minimal configuration that will do a hell of a lot more than what the default rules do. YMMV
Since this is also a taming pfsense topic, start work on an easy way to push server banned IPs to pfsense for immediate addition to a blocked alias (or an alias to direct traffic to a "YOU HAVE BEEN A BAD, BAD BOY" page). I don't like the way I'm currently implementing this, because I believe it's dangerous to pfsense's security (you need ssh access to it from the servers, even on limited access things can go wrong), and so I want the community's input on how to best implement it. poke poke if only the pfsense devs would add a customizable update schedule to the URL tables…poke poke
I'm willing to put up with a few seconds delay if pulling in the updates instead of them getting pushed forcefully to pfsense is easier (and it should be a lot safer).
Undecided, but we do have to burn a bit of company time if they are sponsoring me working on all of these, so anyone that wishes to add something they would like to see, feel free to do so.

The way forward I believe is to publish the "main" topics on github, and keep discussions here. That makes it easy to keep track of changes (and actually see the changes) and keeps the topics well, on topic (discussions about pfsense+suricata). Anyone objecting to this should speak up now or forever hold their silence.

Sorry to disappoint certain people by not insulting anyone, but I'm tired :-\

Mr. Jingles

@jflsakfja:

Sorry to disappoint certain people by not insulting anyone, but I'm tired :-\

;D ;D ;D ;D ;D

@jflsakfja:

The way forward I believe is to publish the "main" topics on github, and keep discussions here. That makes it easy to keep track of changes (and actually see the changes) and keeps the topics well, on topic (discussions about pfsense+suricata). Anyone objecting to this should speak up now or forever hold their silence.

Message copied, Roger, I do not object, not at all, but I am to shut up in the future anyway I read ( ??? ;D )

(I don't object at all, aux contraire, because now the information has been shattered over more than 1 thread - other people adding to your work too - and I had planned a couple of hours to find out where is what these days in the first place)

@jflsakfja:

Undecided, but we do have to burn a bit of company time if they are sponsoring me working on all of these, so anyone that wishes to add something they would like to see, feel free to do so.

Yes, I have, but I have to find the note where I wrote I down.

A Former User

The main problem I see is that you can't edit the old posts. I would love to add more information to the topic as things move forward/things change, but I simply can't do so in an organized way. Expecting everyone to go through 100 pages of posts is not exactly user intuitive ;)

I also enjoy seeing people take over the "technical support"/troubleshooting for other users. It means at least a few understood what the topic is trying to do, how to do it, and are willing to contribute to it ;D. The downside to that, is that updates to the topic get pushed further back in the thread, which takes us back to the "trying to keep things organized" subject. Having the main topic be outside the thread would (IMHO) help with keeping discussions/insulting-"innocent"-passers-by organized. For example, we could have a "ridicule the industry leaders week" (*see note) without affecting the actual guides.

I'm looking at you Google, time to take your own advise** and migrate away from SHA-1 certificates on your selected sites, eg www.google.com.cy (at time of writing:PKCS #1 SHA-1 With RSA Encryption). Especially when you yourself are a CA and can just sign a new certificate with no cost, other than the 2 minutes it takes to generate/re-issue/sign a new certificate and change/revoke the old certificate. Or you can take my advice, if you think that your depreciation policy is adequate. I've been screaming since March (this year) that everybody had plenty of time to migrate away from the old (and weak) certificates, time to force everyone to move on. As usual, no industry leader should listen to the "who-the-f***-are-you" random bloke on the Internet.

**http://googleonlinesecurity.blogspot.com/2014/09/gradually-sunsetting-sha-1.html which brings us to ***

***9 years is indeed a lot of time. That's why for the past few months I've been literally (not just using the word without any context), literally SCREAMING at the CAs to force everyone off the old certificates already FFS (my exact words). which takes us to ****

**** Comodo just recently (after the Heartbleed security feature*****, and after 2 all round re-issues) has finally decided to force SHA-2 certificates.

***** In open source, bugs are not bugs. They are features. A bug introduced in the most respected (previous to the Heartbleed bug, now (as the Cypriot saying goes) not even dogs will piss on it) cryptographic software would imply that someone was directly paid to put it there. Especially when the ZOMGWTFNEW1337FEATURE is not needed. We wouldn't go around accusing anyone of getting paid to subvert security software now, would we? Of course not, don't be silly. The bloke accidentally introduced a "spil your guts out" feature. See? Only open source can offer you 2in1 features****(something, lost count)

****(something, lost count) to RMS and gang: I'm a die-hard open source supporter.

Cino

Here's a laugh for you…

So I'm browsing around http://suricata-ids.org and click on their News - Planet link http://planet.suricata-ids.org/


TCP  Potentially Bad Traffic  96.43.130.12 80  x.x.x.x 38263  1:2100498  GPL ATTACK_RESPONSE id check returned root

gotta love it

A Former User

@Cino:

Here's a laugh for you…

So I'm browsing around http://suricata-ids.org and click on their News - Planet link http://planet.suricata-ids.org/
TCP  Potentially Bad Traffic  96.43.130.12 80  x.x.x.x 38263  1:2100498  GPL ATTACK_RESPONSE id check returned root
gotta love it

Analyzing the packets just before the website was blocked brings us to this: (code tags not added because they interfere with my red emphasis)
–---------------------------------------------------------------------------
"Lets kick it up notch.....

We want to search through -

all the generated alerts that have
a printable payload data
that have the following string: uid=0(root)

Easy, here is the query:

payload_printable:"uid=0(root)"

You should enter it like this in Kibana:
[–---------------------------------------------------------------------------
The rule says this:

msg:"GPL ATTACK_RESPONSE id check returned root"; content:"uid=0|28|root|29|"; classtype:bad-unknown; sid:2100498; rev:7;

The rule is not an FP rule, but a DANGEROUS FP rule. Rules based on plaintext should be banned by legislation. They are the kind of rules that wake you up in the middle of the night when it starts hitting the fan.

I'll add the rule to the list, as well as make the small correction you pointed out on github.

While we are at it, does anyone have anything to say on the proposed way forward as mentioned in a previous post of mine?](http://2.bp.blogspot.com/-u81HF0TVrr4/U_C1BmpQdwI/AAAAAAAAAhU/dJdR8iAQk-k/s1600)

Cino

I didn't have time to look at the packet capture but I will over the weekend. You explaining it is a good example on how rules are triggered by Suricata.

I think your proposed way going forward will work. Maybe start a new thread linking to github while posting links to this thread and the snort one for background info. Ideally it would be nice if we could just edit post like every other forum out there…

BBcan177

@Cino:

Here's a laugh for you…

So I'm browsing around http://suricata-ids.org and click on their News - Planet link http://planet.suricata-ids.org/
TCP  Potentially Bad Traffic  96.43.130.12 80  x.x.x.x 38263  1:2100498  GPL ATTACK_RESPONSE id check returned root
gotta love it

I have similar Alerts when Emerging Threats or Snort posts details of a rule in any of their Newsletters.

Instead of suppressing SIDs, i would probably suppress these Sites to avoid FPs.

bmeeks

What I would like to do is migrate both the Suricata and Snort packages to a new paradigm where you have alerts and blocks, but not a block from every alert like you have today. In a true IPS, you manually edit rules to change the "alert" action to "drop" only for those rules that detect really bad threats. For other things a simple alert to notify you is enough. However, in both Suricata and Snort today on pfSense, the output plugin that handles blocking simply keys off every alert. So any alert results in a block (unless the offending IP is in a Pass List).

I have been running some ideas around in my head on a method for presenting this new paradigm in the GUI. I am thinking about a series of behavior options the admin can choose from. Maybe something along these lines:

1. Legacy behavior where every alert results in a block unless the offender is in a Pass List. This is how things work today.

2. Only blocking when the PRIORITY field in the associated rule is less than or equal to a set value. For example, block on Priority 1 alerts but only alert for Priority 2 and 3 alerts. Still not sure how useful this option would really be, nor how reliable the Priority field values are.

3. A more conventional IPS setup where all rules are only alerts (with no blocks) unless the admin explicitly changes the rule action from "alert" to "drop". This could be handled fairly easily using the new SID MGMT tab feature. It would still require the admin to do a lot of work, though.

4. A refinement of #3 above where choosing one of the Snort VRT IPS policy settings results in blocks from all alerts originating from any of the IPS Policy rules, while other rules (non-IPS policy ones) simply alert. Of course the admin would still have the ability to manually edit any of the other rules to block (drop) by changing the action keyword from "alert" to "drop".

This would set both packages up to be ready to implement true IPS mode when the pfSense kernel is ready to support it. As both packages exist today where any alert results in a block, things could be a pain to administer if those blocks were true inline traffic drops.

I would like the community's input on the above. What changes would you like to see in the blocking behavior?

Thanks,
Bill

A Former User

@bmeeks:

1. Legacy behavior where every alert results in a block unless the offender is in a Pass List. This is how things work today.

That would be a nice option.
@bmeeks:

2. Only blocking when the PRIORITY field in the associated rule is less than or equal to a set value. For example, block on Priority 1 alerts but only alert for Priority 2 and 3 alerts. Still not sure how useful this option would really be, nor how reliable the Priority field values are.

Not at all useful, since I've seen priorities that really don't match the rules.
@bmeeks:

3. A more conventional IPS setup where all rules are only alerts (with no blocks) unless the admin explicitly changes the rule action from "alert" to "drop". This could be handled fairly easily using the new SID MGMT tab feature. It would still require the admin to do a lot of work, though.

If you turn that around, I'd love to have the functionality. Instead of all rules being alert and you had to change them to drop, I would prefer all rules to be drop and you can change them to alert, if need be. Makes a lot more sense when the inline parts are finally available.

That's what I would like to see, alert/blocking wise. I didn't even gave it much thought, until I saw your post.

What I would like though (WANTED FEATURE ALERT!) is a way to turn off the category + priority from the syslog logs. It's driving me (and our loggers) insane. Every IDS/IPS/firewall log should be:
Source IP - Source Port - Destination IP - Destination Port - Protocol - Rule ID - Reason for blocking/dropping/rule explanation.

Warning:RANT!
Anything more than that is, pardon my Greek, BS. Having the line wrap at just the exact point where the IP (and splitting the IP across the screen) is annoying to say the least ;D. I do remember you mentioning that the logging facility is taken straight from the binary (which BTW, everyone reading this* go here:https://redmine.openinfosecfoundation.org/issues/809, then stalk** the developers until they fix it. Bonus points if you print out a large banner and display it in public). That would require the upstream devs to fix it, correct? While they are at it, they can fix the bug linked above. When the time comes (and I can sign a note stating it WILL come), and it hits the fan, everybody will run around screaming "IT WAS THE LOGGING BUG REPORTED OVER A YEAR AGO". Just like the recent POODLE attack. Nobody pays any attention to the guy screaming "stop using an (almost) 20 year old cryptographic protocol. It's proven broken time and time again!". NOPE. Everybody pays attention to Google's engineers when they publish a paper asking everyone to stop using a broken protocol. Doesn't matter, I pointed and laughed because I (unlike the "leaders") eat my own dogfood ;D

all 5 of you

** literally stalk them: show up at random times at their houses, stand next to them in queues staring, peek through their windows while they are having sex. Stalk them. I find it personally offending when a serious bug is reported over a year ago and is yet to be determined when it will be fixed (looks over at the traffic shaping bug…oh wait ;))

bmeeks

@jflsakfja:

@bmeeks:

1. Legacy behavior where every alert results in a block unless the offender is in a Pass List. This is how things work today.

That would be a nice option.
@bmeeks:

2. Only blocking when the PRIORITY field in the associated rule is less than or equal to a set value. For example, block on Priority 1 alerts but only alert for Priority 2 and 3 alerts. Still not sure how useful this option would really be, nor how reliable the Priority field values are.

Not at all useful, since I've seen priorities that really don't match the rules.
@bmeeks:

3. A more conventional IPS setup where all rules are only alerts (with no blocks) unless the admin explicitly changes the rule action from "alert" to "drop". This could be handled fairly easily using the new SID MGMT tab feature. It would still require the admin to do a lot of work, though.

If you turn that around, I'd love to have the functionality. Instead of all rules being alert and you had to change them to drop, I would prefer all rules to be drop and you can change them to alert, if need be. Makes a lot more sense when the inline parts are finally available.

That's what I would like to see, alert/blocking wise. I didn't even gave it much thought, until I saw your post.

What I would like though (WANTED FEATURE ALERT!) is a way to turn off the category + priority from the syslog logs. It's driving me (and our loggers) insane. Every IDS/IPS/firewall log should be:
Source IP - Source Port - Destination IP - Destination Port - Protocol - Rule ID - Reason for blocking/dropping/rule explanation.

Thank you for the comments. Option #1 is sort of a no-brainer since that is how things work today and no changes in any code would be required.

Your assessment of Option #2 reinforces what I suspected – the assignment of the Priority value in a rule is not necessarily perfect.

Your comment on Option #3 regarding turning the logic around (making all alerts DROP by default and allowing changing some to only ALERT) would require rewriting some of the underlying binary code in both Suricata and Snort. All of the internal routines are geared to act on the action keyword (either ALERT or DROP) in the rule. So without essentially rewriting the core mechanisms of both binaries, implementing as you suggest would not be possible. And for several very valid reasons, the pfSense team wants packages to stay in sync with upstream to the maximum amount possible. That means no or very limited patching for use on pfSense.

Turning off fields in the syslog output would also require upstream changes in the binary. Today the fields are hard-coded in that Suricata source code module.

Bill

dstroot

I am attempting the red pill. However it is not going down all that well. ;) I am attempting the very first portion of the tutorial, blocking everything and setting up explicit "whitelist rules" I am using version 2.1.5.

First setup your port aliases - check.
Next setup your anti-lockout rule - check. (and it works… phew)
Next setup a floating rule that blocks basically everything in/out on WAN - check.
Next setup rule(s) that allow LAN services access to services (DNS, DHCP, NTP) - check. I get a DHCP address and I can resolve DNS.
Finally, setup your explicit outbound ports rule to allow traffic out from the LAN - No Joy.

Here's what I suspect is happening - can someone help me figure this out?

Floating rules are parsed before rules on other interfaces. Thus, if a packet matches a floating rule and the Quick option is active (as we were told to do) on that rule, pfsense will not attempt to filter that packet against any rule on any other interface. Thus in step 5 the explicit outbound rules are not being hit because the floating "block everything in/out" has "quick" checked.

Does this make any sense? Has anyone else followed the first post in the thread and got working? I'm stumped.

Cheers,
Dan

rules.png_thumb

A Former User

I'm thinking that you too got confused by the floating rule. The floating "block everything" rule isn't meant to be a "block everything" rule. It's meant to be a rule to block everything to pfsense's ports!, hence the giant red warning. I'm working on version 2.0 of this guide, which will clear up some confusion (and possibly create confusion elsewhere :p).

dstroot

I'm still confused. If you "DON'T CHANGE DESTINATION PORT RANGE!!!" on a new rule then you end up with "any" on the rule. It looks like the attached. And yes, it blocks everything. ;)

So instead I should use the alias for the pfSense ports? i.e. instead of "DON'T CHANGE DESTINATION PORT RANGE!!!" on a new rule it should say "Destination port range 'pfsense_ports' as above"?

a 2.0 guide would be much appreciated - this thread is a long hard slog. ;D

edit: I did find what I was looking for somewhere in the middle of this thread you give a very clear explanation:

Re-reading it does make sense on why it blocked out traffic. I meant to say create a new floating rule, based on the previous allow rule, but this time around change the pass to a block, keeping the destination ports the same.

A)1 normal pass rule for the ports active on the interface you want to administer pfsense from.

B)1 floating rule block rule for ALL interfaces EXCEPT the one you want to administer pfsense from.

floating.png_thumb

fsansfil

@bmeeks:

What I would like to do is migrate both the Suricata and Snort packages to a new paradigm where you have alerts and blocks, but not a block from every alert like you have today. In a true IPS, you manually edit rules to change the "alert" action to "drop" only for those rules that detect really bad threats. For other things a simple alert to notify you is enough. However, in both Suricata and Snort today on pfSense, the output plugin that handles blocking simply keys off every alert. So any alert results in a block (unless the offending IP is in a Pass List).

I have been running some ideas around in my head on a method for presenting this new paradigm in the GUI. I am thinking about a series of behavior options the admin can choose from. Maybe something along these lines:

1. Legacy behavior where every alert results in a block unless the offender is in a Pass List. This is how things work today.

2. Only blocking when the PRIORITY field in the associated rule is less than or equal to a set value. For example, block on Priority 1 alerts but only alert for Priority 2 and 3 alerts. Still not sure how useful this option would really be, nor how reliable the Priority field values are.

3. A more conventional IPS setup where all rules are only alerts (with no blocks) unless the admin explicitly changes the rule action from "alert" to "drop". This could be handled fairly easily using the new SID MGMT tab feature. It would still require the admin to do a lot of work, though.

4. A refinement of #3 above where choosing one of the Snort VRT IPS policy settings results in blocks from all alerts originating from any of the IPS Policy rules, while other rules (non-IPS policy ones) simply alert. Of course the admin would still have the ability to manually edit any of the other rules to block (drop) by changing the action keyword from "alert" to "drop".

This would set both packages up to be ready to implement true IPS mode when the pfSense kernel is ready to support it. As both packages exist today where any alert results in a block, things could be a pain to administer if those blocks were true inline traffic drops.

I would like the community's input on the above. What changes would you like to see in the blocking behavior?

Thanks,
Bill

Well I'm alot like you on those feelings.

1,2,3 - Maybe the answer is in the "log" operator. Alert, Drop = block, Pass = Pass and … Log = Log; No drop, No block, just log.. There are many rules these days that I would want to be "log" only in pfsense. Also...all those complains about false positives, you can switch them manualy to "log" only. What I hate the most is when a rule is disabled because of too many false positives....well hell, let me decide whats FP...

"Pass" is sweet too, I have a set of rules that are true firewall rules with barely any payload inspection. "Pass" comes handy in this ruleset...

I personnaly replace all Alert with Drop and monitor the traffic, then, I change single rules to log only, one by one.

Keep up the good work Bill!

Cheers.

F.

bmeeks

@fsansfil:

@bmeeks:

What I would like to do is migrate both the Suricata and Snort packages to a new paradigm where you have alerts and blocks, but not a block from every alert like you have today. In a true IPS, you manually edit rules to change the "alert" action to "drop" only for those rules that detect really bad threats. For other things a simple alert to notify you is enough. However, in both Suricata and Snort today on pfSense, the output plugin that handles blocking simply keys off every alert. So any alert results in a block (unless the offending IP is in a Pass List).

I have been running some ideas around in my head on a method for presenting this new paradigm in the GUI. I am thinking about a series of behavior options the admin can choose from. Maybe something along these lines:

1. Legacy behavior where every alert results in a block unless the offender is in a Pass List. This is how things work today.

2. Only blocking when the PRIORITY field in the associated rule is less than or equal to a set value. For example, block on Priority 1 alerts but only alert for Priority 2 and 3 alerts. Still not sure how useful this option would really be, nor how reliable the Priority field values are.

3. A more conventional IPS setup where all rules are only alerts (with no blocks) unless the admin explicitly changes the rule action from "alert" to "drop". This could be handled fairly easily using the new SID MGMT tab feature. It would still require the admin to do a lot of work, though.

4. A refinement of #3 above where choosing one of the Snort VRT IPS policy settings results in blocks from all alerts originating from any of the IPS Policy rules, while other rules (non-IPS policy ones) simply alert. Of course the admin would still have the ability to manually edit any of the other rules to block (drop) by changing the action keyword from "alert" to "drop".

This would set both packages up to be ready to implement true IPS mode when the pfSense kernel is ready to support it. As both packages exist today where any alert results in a block, things could be a pain to administer if those blocks were true inline traffic drops.

I would like the community's input on the above. What changes would you like to see in the blocking behavior?

Thanks,
Bill

Well I'm alot like you on those feelings.

1,2,3 - Maybe the answer is in the "log" operator. Alert, Drop = block, Pass = Pass and … Log = Log; No drop, No block, just log.. There are many rules these days that I would want to be "log" only in pfsense. Also...all those complains about false positives, you can switch them manualy to "log" only. What I hate the most is when a rule is disabled because of too many false positives....well hell, let me decide whats FP...

"Pass" is sweet too, I have a set of rules that are true firewall rules with barely any payload inspection. "Pass" comes handy in this ruleset...

I personnaly replace all Alert with Drop and monitor the traffic, then, I change single rules to log only, one by one.

Keep up the good work Bill!

Cheers.

F.

Utilizing LOG and PASS in addition to ALERT and DROP are excellent suggestions. I now have more options to be thinking about …

Bill

Soloam

Hi, I made the transition from snort to suricata, I followed your tutorial from the beginning, and I think that I have all working. But one thing is wired, on snord I had several alerts a day, some were identified as false positives, others I wasn't able to determine, so a keep them blocked until I identified the real source. On Suricata, I have it running now at 5 days, and not even one alert. Should I go back to snort in my production system until Suricata is in a more mature state?