Elastic Watcher 101!
Watcher, Elastic Alerting for beginner
What is a Watcher?
If you are Elastic’s user, in IT operations, or in information security, or a person who is keen on learning new technologies, you would have heard about the Alerting feature or Watcher in Elastic.
So what exactly is Watcher
Alerting or Watcher is The two sides of the same coin, Paid service came when you activate the X-pack, and that allows you to be alert when something bad happened or something different in your data or your infrastructure, Not only that but also let you take the appropriate action to this act or this anomaly, you can for example:
- Availability of website/system or as we said in the business of Accessibility, downtime is a dreaded term using alerting for early problem detection.
- Awareness from the first hacking attempt on system/network.
- Automatically alert the IT staff when systems degrade or fail, or even when a help desk ticket is escalated.
Why should you learn how to use Watcher?
So you may ask why should I learn how to use Watcher?
In this blog, we are going to focus on the Cyber Security field but you can use it for other fields as mentioned previously.
Let’s say you are working on Cybersecurity especially in the Blue team, and you are collecting Authentication logs and indexing them on Elasticsearch, and you want to get a notification in real-time when this scenario appears:
a user failed to log in more than 5 times in less than 15 sec, which is impossible for a user, you may wonder, all of these failed in this short period of time! Exactly, it’s a high possibility of Brute Force Atack, So for this case and other similar is better to use a Watcher to be alerted at the right time.
So How exactly Watcher Works
Before we get into practice, let’s understand how Watcher works. First, try to understand the Watcher architecture.
- Schedule
- Query
- Condition
- Actions
Schedule — time at which checking the condition or executing the query, support several types of schedule: hourly, daily, weekly…
Query — it is the question to ask and comparing a result with the condition, we can use all specifications in DSL(Domain Specific Language).
Condition — comparing the result of our query and if it’s much the condition we execute the action.
Actions — we have different choices: email, webhook, index, logging, or slack, we can choose one or more to send a notification or send data.
Sounds like too much technical stuff lets compare each part with a live example, but first, you need to obtain the license or start a 30-day trial by going to Kibana, choose management, and select license management.
Here you’re ready to start with a Watcher.
For creating, managing, and testing a watcher we have an API, for those who don’t know we have Dev Tools to interact with APIs
Let’s write our first Watcher, We start with a schedule as you can see below:
PUT _watcher/watch/watcher_101
{ “trigger”: {
“schedule”: { “interval”: “10s”
}
}
}
You can name your Watcher, as in this example we name it “watcher_101”, and the trigger is necessary for any Watcher, it decides when the Watcher will execute, also the schedule defining the value of the interval.
After that, we’re going to add a query, using the DSL queries for example here:
“input”: {
“search”: {
“request”: {
“indices”: [
“winlogbeat”
],
“body”: {
“size”: 1,
“query”: {
“bool”: {
“must”: [],
“filter”: [
{
“match_phrase”: {
“event.code”: {
“query”: “4625”
}} },{
“range”: {
“@timestamp”: {
“gte”: “now-15s”,
“lte”: “now”
}}}
],
“should”: [],
“must_not”: []
}}}}}}
As you already notice that our query included in the input, and this list contains the index where we are going to do our search or where we are going to execute our query and here we specify the name of the index as ”Winlogbeat” for example.
Now the query; it’s very simple we are filtering the docs that contain a field event.code with the value 4625, which is a failed login for the Windows OS in less than 15 seconds as range time.
“condition”: {
“compare”: {
“ctx.payload.hits.total”: {
“gt”: 5
}
}
}
So, the condition means if we have more than a 5 “event.code”:”4625” in the last 15 seconds if the condition is certain to move to the Action, if not, do not do anything.
“actions”: {
“log_error”: {
“logging”: {
“text”: “ WARNING! There is a possibility of Brute Force Attack “
}
}
}
We can execute one or more in the Actions session, like this case, we just show this message in the log, you can send a notification to Slack or send an email and others but these need some configuration.
Watcher UI
We talked already about creating a watcher through an API, let’s jump to another part:
- Creating a Watcher via UI
- Managing Watchers via UI
Creating a Watcher via UI
You remember the steps from creating Watcher via API right! It’s the same just instead of using Query you will use interface. In Kibana go to management, after, click on Watcher, as shown below.
And let’s try our first watcher with UI:
And now you know how to do it, but I think the best way to use UI is for the management so we can activate, deactivate, do a modification, or delete the watcher.
If you arrive at this point so CONGRATULATION.
We saw in this post what’s a watcher, and what’s its benefits, also we learned how to create a Watcher from the API and from UI, finally, we saw how to use UI for managing the Watchers.
You want to learn more about Watcher right! You can check our market place to learn more about it on octodet.com there’s a lot to discover waiting for you.
Dive in and learn more, this is only the beginning there’s a lot more to know, after Watcher, we suggest to start with Rule Engine
Mohamed.
