Scenarios to obtain an intrusion event on the monitory
The suricata CNF is responsible to monitor network packets to detect possible intrusions on the network chain. During its work Suricata fills logs related with the packets it surveys, being the information related with interesting events in our perspective or not at all. To obtain an intrusion event, we need to search on these logs for specific patterns related on what to espect when we have undue access to the CNFs we are patrolling.
It is as close as possible to the source event, which is always good in terms of performance.
The format of existing logs will not be conductive to searches for the events we are looking for. The parsing will surelly be complex and not entirelly evident. It will take awhile to establish the definitive format of the logs relating to all possible events. Each time a new event changes the logs, the process will start anew. This presents us with a problem, every time a new entry is logged the process will be called, which means we have to keep track of previous invocations. Under this premisses an event here would be a difficult implementation, though not impossible.
Here we have a lightweight shipper for forwarding log data using lumberjack protocol. To obtain an intrusion event here we must have to register a lumberjack server onto filebeat to receive every event sent by suricata and choose the ones we are interested in. That will surelly involve a lumberjack interpretation. We will need to pill off all the protocol unneeded information to obtain the JSON pertaining desired events.
We receive each new event on the fly, which we should analyze to accept those refering to intrusions. It's an event approach, which should be easier than each time analyzing the whole log and needing to keep track of previous invocations.
We need to address the Lumberjack protocol to obtain event properties, and obviously check if the event addresses our specific needs. We need to register on filebeat to receive the events sent to elasticsearch and logstach.
Logstash is an open source tool for collecting, parsing, and storing logs for future use. It permits a reordering of the events properties when logged for posterity. We can add a new output that facilitates our search for intrusion events.
We can order the event properties in a way that favors the search for our purpose when the events are stored. Permits a quick search based on the ordering of the stored event. A timeline can be also easily established. It facilitates hugely any type of research done on the stored data, permiting several types of access. Mainly uses http so we are limited to that technology.
Lagging time from the proper time of the event can be a little high. Processing for storing events will delay significantly in relation to the other components.
Elasticsearch is a document-oriented database, designed to store, retrieve and manage document oriented or semi-structured data. When you use Elasticsearch you store data in JSON document form. So to obtain an intrusion event we must search each JSON document stored to obtain the ones we are interested in.
Document oriented db, we get all related properties for an event at once - the document should be stored in JSON.
The events are registered like JSON documents. It is difficult to search for the type of event we want because we must fetch the whole document. It's difficult to keep track of previous invocations. It is difficult to order the events. It may have a lag time from the event happening.