17. 09. 2019 Angelo Rosace NetEye

How To: Using the Elastic Watcher Feature to React to Failed Login Attempts (Part 2)

Our continued development of the Tornado event processing module has led to a new set of functionalities and capabilities. Among these is the possibility of altering host and service statuses as the result of a certain event.

Let’s look at a typical use case for this feature.

Suppose you want to trigger a webhook that will set a service’s status to critical each time a certain event involving that service takes place, and do this by creating a webhook collector in the Tornado module. More specifically, you want to create a webhook to handle calls from Elastic.

For the purposes of this example, let’s also assume you want to trigger it after a failed login attempt happens on a NetEye server.

First of all, you need to have a host and a service related to it in place on your NetEye System. Having satisfied this prerequisite, you can now configure the webhook collector in Tornado.

The first thing you should do is add a new webhook configuration to handle calls from Elastic. The webhook needs to extract data from an Elastic webhook call. In order to do this you will have to create a JSON structure that looks like this:

{
 "id": "failed_passwords",
  "token": "abc",
  "collector_config": {
    "event_type": "failed_passwords",
    "payload": {
      "source": "elastic",
      "hostname": "${hits.hits[0]._source.host.name}",
      "message": "${hits.hits[0]._source.message}"
    }
  }
}

This structure, which represents the webhook itself, should be created in the folder neteye/shared/tornado/conf/collectors/webhook/webhooks.

Now that your JSON file is ready, you need to configure Tornado and then restart the Tornado webhook collector.

Next, we need to set the correct IcingaWeb2 API credentials for the Tornado Icinga2 client, and then configure the password in the Tornado Icinga2 Client configuration file (/neteye/shared/tornado/conf/icinga2_client_executor.toml).

Once this is done you will need to create a Tornado rule to detect the error condition and do something about it. Each rule consists of a “constraint” structure that defines under which conditions the rule should apply, and an “actions” structure that defines which action will be taken by Tornado when the constraints are satisfied.

{
  "name": "failed_password_check",
  "description": "Checks for failed password events",
  "continue": true,
  "active": true,
  "constraint": {
    "WHERE": {
       "type": "equal",
       "first": "${event.type}",
       "second": "failed_passwords"
    },
    "WITH": {}
  },
  "actions": [
    {
      "id": "icinga2",
      "payload": {
        "icinga2_action_name": "process-check-result",
        "icinga2_action_payload": {
          "exit_status": "2",
          "plugin_output": "${event.payload.message}",
          "filter": "${event.payload.hostname}",
          "type": "Service"
        }
      }
    }
  ]
}

In the rule above, the “constraint” structure looks for a failed passwords event. Whenever this happens, the “actions” section triggers the process-check-result command to set the appropriate monitoring status for all monitored objects matching the filter (in this case, event.payload.hostname).

Now save the file and restart the Tornado service. From now on you will be able to use your new Tornado-implemented webhook.

Angelo Rosace

Angelo Rosace

Author

Angelo Rosace

Leave a Reply

Your email address will not be published. Required fields are marked *

Archive