Use numeric as field type instead of default string in wazuh indexes

[Cyril Mouchel]

Hi there,

I am facing an issue with my Wazuh configuration. I would like to analyze 100% of my IIS logs so that I can start building powerful dashboards to detect issue with my server's performances - easy right?

Among the key values I need to track, there is the "timetaken" one - which is supposed to represent the delay in ms the web server spent to handle the request. That value is available in IIS logs.

I did write my decoder (update the default iis log one actually) with the following XML

    <decoder name="web-accesslog-iis-default">
        <type>web-log</type>
        <use_own_name>true</use_own_name>
        <prematch>^\d\d\d\d-\d\d-\d\d \d\d:\d\d:\d\d \S* GET |^\d\d\d\d-\d\d-\d\d \d\d:\d\d:\d\d \S* POST </prematch>
        <regex>^(\d\d\d\d-\d\d-\d\d \d\d:\d\d:\d\d) \S* \S* (\S+ \S*) (\d*) (\S*) (\S*) (\S*) (\S*) (\d*) (\d*) (\d*) (\d*)</regex>
        <order>date_utc,url,srcport,username,srcip,ua,referer,id,subcode,win32status,timetaken</order>
    </decoder>

All fields are well extracted and I'm able to get my timetaken value (see picture attached).

Issue comes when I want to use this timetaken value in visualization. I would like to run some numeric aggregation like mean, sum or whatever. These computations are not available for string fields - only for numeric fields.

Then the question is, how can I manage to configure wazuh to create index with timetaken as a numeric value in ElasticSearch instead of a string value? I did not see any way to configure this and the fact that we extract only digit from the regex is not sufficient for Wazuh to know we are going to use digit only.

As Wazuh is creating new indexes everyday, my guess is that there is no need for me to re index everything by updating the index mapping manually - that would be useless as nex indexes pop everyday.

Also, I tried to use the "Scripted Fields" functionnality to convert my string to numeric value - seems to work (at least the timetaken is seen as a numeric in the Discover tab) but the visualization is throwing errors. I'm not sure we can actually use Scripted Fields in aggregation functions - I will check that on Elastic search directly.

Is there something I'm doing wrong here?

Thank you for time and expertise!

Cyril

[Adrian Jesús Peña Rodríguez]

Hi Cyril, 

I have reviewed what you say and I see that everything is correct, about the question "how can I manage to configure wazuh to create index with timetaken as a numeric value in ElasticSearch instead of a string value?".

To do this you must create a new index in Elasticsearch, in its documentation is indicated as: https://www.elastic.co/guide/en/elasticsearch/reference/current/indices.html

Your alert template will be very similar to this one: https://raw.githubusercontent.com/wazuh/wazuh/3.9/extensions/elasticsearch/wazuh-elastic6-template-alerts.json

You should add something like:

"timetaken: {
     "type: "long",
     "doc_values": "true"
},

inside the object data.

When you do this you will have to reindex the alerts that you already have, once you have it ready you will be able to make the aggregations without problem because it will be a numerical value.

I hope this answer is helpful, any other question you have do not hesitate to ask.

Best regards,

Adri 

[Cyril Mouchel]

Thanks Adrian for your insight.

I tried to update the wazuh template to specify timetaken as a "long" type using the following query

PUT /_template/wazuh/_mapping/_doc
{
  "properties": {
    "timetaken": {
      "type": "long"
    }
  }
}

But this is actually throwing an error

{
  "error": "no handler found for uri [/_template/wazuh/_mapping/_doc?pretty] and method [PUT]"
}

I'm still trying to understand what's wrong there - I'm not yet an ELK proficient user :) Any help will be appreciated

Cyril

[Cyril Mouchel]

Also, I tried this query

PUT /_template/wazuh
{
  "mappings":{
    "properties": {
      "timetaken": {
        "type": "long"
      }
    }
  }
}

Throws another error

{
  "error": {
    "root_cause": [
      {
        "type": "action_request_validation_exception",
        "reason": "Validation Failed: 1: index patterns are missing;"
      }
    ],
    "type": "action_request_validation_exception",
    "reason": "Validation Failed: 1: index patterns are missing;"
  },
  "status": 400
}

[Adrian Jesús Peña Rodríguez]

Hi Cyril, let's try to fix the error :), you can check if adding to the file /wazuh/extensions/elasticsearch/wazuh-elastic7-template-alerts.json the following, inside the data:

"timetaken": {

       "type": long,

       "doc_values": "true"

},

So the result would be something like this:

Tell me if it worked for you and anything don't hesitate to ask.

Best regards,

Adri

On Monday, May 20, 2019 at 8:51:25 AM UTC+2, Cyril Mouchel wrote:

[Cyril Mouchel]

Hi Adrian,

I am not able to locate that file - neither I am to find anything that looks like an index template in my VM.

I did search about this index template configuration from disk file but it seems this ElasticSearch deprecated this possibility - see https://stackoverflow.com/questions/27970625/elasticsearch-templates

Instead we should use the API only (mostly to avoid server-side configuration).

I will focus on understanding more precisely this API endpoint then.

That being said, as Wazuh is able to update index templates by parsing decoders, I was wondering if there was a possibility to add some argument in my decoders to tell Wazuh to create new fields but with a specified type instead of the default string type?

Thanks again for your time,

Cyril

[Adrián Jesús Peña Rodríguez]

Hi Cyril, 

Don't mention it!, let's start again, as we want to change the template to be able to have the timetaken field as a numerical data, first let's download the Elasticsearch template on which we want to make the changes:

curl https://raw.githubusercontent.com/wazuh/wazuh/3.9/extensions/elasticsearch/wazuh-elastic6-template-alerts.json -o template.json

We will edit the template-alerts.json file that we have just downloaded we will make the changes we see appropriate, in this case what we want is to add your custom alert, in this case we will go to our object data and we will add our field as follows:

"data": {
          "properties": {
            "protocol": {
              "type": "keyword",
              "doc_values": "true"
            },

            "timetaken": {
              "type": "long",
              "doc_values": "true"
            },

            ...
}

Once we have our custom template we will proceed to send it to Elasticsearch as follows:

curl -X PUT "ip_elasticsearch:9200/_template/wazuh" -H 'Content-Type: application/json' -d @template-alerts.json

This should give us back the following answer if everything went right:

{"acknowledged":true}

As you indicate Wazuh creates an index every day but the indexes already created and that are affected by this change must be re-indexed so that the changes are applied to them.

To reindex the affected indices we must do the following, let's take as an example today wazuh-alerts-3.x-2019.05.21:

curl -X POST "ip_elasticsearch:9200/_reindex" -H 'Content-Type: application/json' -d'
{
    "source": {
        "index": "wazuh-alerts-3.x-2019.05.21"
    },
    "dest": {
        "index": "wazuh-alerts-3.x-backup"
    }
}

We eliminate indices that are affected and do not show change:

curl -XDELETE "ip_elasticsearch:9200/wazuh-alerts-3.x-2019.01.29"

Now we will reindex the copy of the indexes to the new index that we have created:

curl -X POST "ip_elasticsearch:9200/_reindex" -H 'Content-Type: application/json' -d'
{
    "source": {
        "index": "wazuh-alerts-3.x-backup"
    },
    "dest": {
        "index": "wazuh-alerts-3.x-2019.05.21"
    }
}

And we'll be able to remove the copy we created earlier:

curl -XDELETE ip_elasticsearch:9200/wazuh-alerts-3.x-backup

Finally, we will restart logstash:

systemctl restart logstash

It is possible that when you access Kibana you will see that the index fieldset is incorrect, to fix this remove the index pattern and restart Kibana, a new one will be created.

To restart Kibana we can do the following:

systemctl restart kibana

In our documentacion you can see more information: https://documentation.wazuh.com/3.x/user-manual/kibana-app/reference/index.html

Best regards,

Adri

On Monday, May 20, 2019 at 8:51:25 AM UTC+2, Cyril Mouchel wrote:

[Cyril Mouchel]

Hi Adrian,

I see - my bad, I thought you were referring to a file system :)

In the meantime I mess up a bit with my wazuh template (the PUT will actually overwrite the whole config instead of adding fields as I thought first).

Anyway, I did recreate the wazuh alert template following the github template and by adding my field as you mentioned.

Then I had to delete my previous index (I dont need to keep data) and everything went well. I'm now having numeric value extracted and can run powerful dashboards with my custom fields - see attach! Woohoo

Thanks Adrian,

[Adrián Jesús Peña Rodríguez]

You're welcome, Cyril. It looks useful and awesome!. I'm glad I helped you.

For anything else do not hesitate to ask.

Best regards,

Adri

On Monday, May 20, 2019 at 8:51:25 AM UTC+2, Cyril Mouchel wrote: