I recently raised a case in the portal about an event that I didn't think should cause a block, but I don't think we understood each other and due to the pressures of work I let the matter drop as I was able to resolve the issue temporarily.

Unfortunately a related issue has come up and this one needs a general discussion, I think.

Here's what happened:



This caused rule 2010 to trigger, which is Level 6.

Now I don't expect Level 6 events to cause a block, but this one does by default. That can't be a right, can it, especially with the GUI set to show level 7 and above by default? Only Level 7+ events normally trigger blocks.

More importantly, this attempt to use lots of memory is common, if not normal, for a Wordpress site. So causing a block here is a bad thing.

What I was asking for in my support case, but not explainling very well, was for a specific rule to be created for this particular suhosin alert, AND which takes precedence over the first time IDS event rule (20100), which is what triggered originally (and was a Level 8 and blocked the IP). It is not fatal, nor an indication of a real attack. Like I say, it is common for WP to trigger this suhosin alert.

What do you guys think?

Faris.

Level 6 and up block. 7 is the default since 6's are where we put alerts we dont want to show by default because of volume.

Well that doesn't seem like the right thing to do to me. Anything that blocks should be visible, surely? If there's going to be a lot of something, it shouldn't block by default, especially if it is "hidden" ?

I can understand why you may want that. We took the approach that for some events you may not want to always see them by default, even if its shunned. For example, brute force attack alerts (before they get rolled up as a meta event), for example. Or really high volume events, like suhosin (you can get a HUGE stream of events from suhosin). Yes, it should tell you a brute force attack is under way, but may not ever single alert that lead ASL to that conclision.

We didn't want to overwhelm the user (and the GUI) right out of the box, otherwise you could end up DOSing the GUI or maybe even the person. So we have one level of shuns - the bulk ZOMG pre-rolled up non-meta events that dont show. The meta roll ups, like "hey you are in fact being hammered" is a 7+ - so you see that by default. Just not the "um, heres every hammer strike enjoy!". Sometimes something could be a 6 and just not rise to a hammer event. So its a bit of a toss up on some of those "noiser" events, like suhosin that can be a bit chatty. It might be a damn good idea to see all the hammer strikes, so its admittedly a compromise, we try to find a happy medium out of the box.

At least ASL takes it all in stride to protect you, it can handle the load, we just dont want to overwhelm the human!

So we appreciate the feedback, if theres a better way we can do this we definitely want to do it. Please toss out ideas, we're all ears and eyes. Maybe something in the GUI to explain their are shuns below your current "level of awareness" going on? The human factor is far more important in the GUI, so if we can help to present this information in more coherent way please let us know.

I don't see the difference between suhosin logging loads of somethings and mod_sec blocking the 100s of attempts I'm currently seeing by the bad guys trying to exploit an awstats vulnerability on every IP and domain name on our servers, over and over again.

If it gets blocked then it should be visible by default. Any rule capable of (or likely to be capable of) blocking a legit user must be visible by default.

I'd almost say that these Level 6 events should really be Level 8 or 9. They are "unusual" and therefore need more attention than the usual Level 7 ones. I know you say there can be lots of them, but I'm not seeing many here compared to Level 7.

At the very least give us an option for the default viewing level in the asl config file so people concerned about blocking their own users can view those events more easily, without having to remember to change the level in the GUI every time they login.

We've actually been pushing rules down from the default 7 catchall 60118 to lower level 6 events. WAF RBL events for example are 6's, as well as some meta-rules. Its a big list though, and I don't think we'll ever have to/need to map them all to HIDS Id's.

A lot of that pre-dated the rule manager too. You can certainly go into a rule now and change the level it runs at, disable/enable active response, "silence" the alert from logging or emailing, or force a rule that wouldnt normally block/email/alert to do that even if its at a lower level.

That all makes sense.

But next time please can you warn us users when this type of change happens? I'm sure I'm not the only one uncomfortable with blocking events happening that I wasn't aware of.

So can we solve my anguish in this specific case with a suhosin-specific rule?


(1010xx is my local rule range)

But how do I get this to override other rules that might trigger, like 20101 (or is it 2010)?
For example, I might want to leave 20101 on blocking, but if the suhosin rule triggers I don't want to block.

check out the <if_sid> examples in other rules

Ah! My old friend Sid. I hope he's well. I shall find out shortly.

Well, Sid's no help to me really. In fact I've unFriended him.

Thankfully, there's already a suhosin decoder in OSSEC, with a "type" of "ids" in decoder.xml





[50_asl_]ids_rules.xms has two main rules that will trigger on suhosin events, and they are what's really causing the problem:



The first one is a First Time Seen rule, default Level 8.
This means that any suhosin event that happens that's not been seen before (before when? -- I can't figure out where the FTS queue is held) will be Level 8 and will block.

Obviously this can be changed, but as I want to specifically target suhosin, we don't really want to change it. It is Level 8 for a reason, really.

Next, we have a Level 6 rule that will trigger if the suhosin event has been seen before. Again we don't want to touch that because it is a generic rule and we want to specifically target suhosin.

So, as far as I can see, the only solution to this is to modify the existing suhosin decoder and change <type>ids</type> to a custom value, such as "suhosin", when create the required rules in local_rules.xml - maybe a generic suhosin rule at level 8 and a specific rule matching the memory allocation rule at level 5.

The problem is that decoder.xml will get overwritten every time ossec us updated.

There is an option for local_decoder.xml or indeed to put a decoder file in decoders.d as has been done for the 01_asl_decoder.xml

So, I wonder if I can override an existing decoder by simply saving a local_decoder.xml file in decoders.d which redefines the "suhosin" decoder in decoder.xml?

I may try it later, but if anybody knows whether this will work or not then I'd appreciate it.

Faris.

bah! The man from DelGoogle, he says "no!"

But it looks like I may have misunderstood how the rules work.

I figured that if there was a generic rule the triggered at Level X, any subsequent rules that use if_sid to chain off that rule would not prevent the original generic Level X rule triggering.

But looking at ids_rules in more detail, I see



Which implies that I can cause the generic rule not to trigger if I get a match in my custom rule.

Hmm....

Sorted:

in /var/ossec/etc/rules.d/local_rules.xml




I'm not sure if I'm doing my <group> stuff correctly, but the ossec-logtest utility confirms it works as expected.

[EDITED - changed to enhance detection levels to include first time events]