Unable to use 'contains' on 'event.desc'

[Kedras]

Hi Guys,

I am facing problem with root login rule.

I would like to obtain alert (from RE) everytime when somebody login as root and it usualy works, but...

Today we tested root login on Debian server and it sent log:

" Sep 22 16:01:57 10.10.10.10 login[20773]: ROOT LOGIN on '/dev/tty1' "

whole part " login[20773]: ROOT LOGIN on '/dev/tty1' " is parsed as "event.desc" and message ID is 00010:22

Unfortunately root is not parsed as username, so I tryed to parse this by using rule such as:

" msg.id='00010:22' && event.desc contains 'ROOT LOGIN' "

but it's not working. Also in investigation query " event.desc = 'login[20773]: ROOT LOGIN on '/dev/tty1'' " is not working.

Do you guys know some solution for this? I suspect those apostrophs in desc are problem, but idk how to force it to work.

Is parser modification the only way?

Thank in advance for any idea.

--

David

[JohnSnider]

1. Go to the config view on your Concentrators and check the index type on the "event.desc" metakey. Under the "files" tab, select "index-concentrator.xml", then hit <ctr/> f to open the browser "find" dialog, and search for "event.desc", if the level="indexKeys" or "IndexNone", then you won't be able to use a "contains" against the key. it would have to be fully indexed (level="IndexValues") to be able to  use a "contains" search.  If you need to change it, copy the entire line for that key, then open the "index-concentrator-custom.xml" file and paste the key there, then modify the level to be "IndexValues"  you will also need to make sure it has a "valueMax" setting ( valueMax="1000000") for starters.

2. if the key is already indexing values, then you may be running into the limit on "valueMax", check /var/log/messages for any reports of index keys exceeding valueMax.  The way the value max works is if there are more "unique" values than the "valueMax" setting in a single index slice, then the rest of the values are NOT indexed, until a new slice is created.  You can try increasing the valueMax but I wouldn't go over 5000000 (5 million)

[Kedras]

Hi John,

Thank you for fast response.

In index-concentrator.xml there is already "IndexValues", I am also able to search in "event.desc" except in this one (it's the first one which I found to be unusable).

There must be some problem with apostrophes in meta. Now I tested it and I am unable to use contains on any event.dest which contains apostrophes. All other are OK. 

Example:

in investigation " event.desc contains 'root' " over this two event.desc metas 

"login[20773]: root login  on '/dev/tty1'"

'pam_unix(sudo:session): session closed for user root'

will returtn just that one without apostrophes in message

'pam_unix(sudo:session): session closed for user root'

[ChristopherAhea]

What about escaping the character in the search?. Also, is that the only place where the data to match your query existed?. Perhaps it could have it parsed a little better or an app rule defined to find it at capture and make finding it easier. 

[Kedras]

Hi Christopher,

There is nothing to be escaped in my query therefore I am searching just for "ROOT" or "ROOT LOGIN" in event.desc (event.desc contains 'root').

I'll push that rule to Decoder and take a look if there will be some difference.

[ChristopherAhea]

Then one possible consideration would be the index.

Event.desc would contain fairly unique values. It's possible that some of the searches are not coming back because the index level is not set high enough.

If what you are searching for is anytime 'root' is used to log in our from which particular terminal, it may be possible to get in other ways.

What is the event source?

Perhaps we could look at any log samples offline, then post a solution here once we get to that.

Chris

Sent from my mobile device

[Kedras]

It would be fine if you can take a look on it.

It's Debian and I think, that index level is set high enough.

Everything in timeframe close to this log seems to be indexed regarding event.desc and I am able to run queries over them successfully.

[ChristopherAhea]

You can email me directly at

Christopher.ahearn@rsa.com

We can have a look and figure out the next steps.

--

Chris