UDP is a lot faster since there’s less overhead, however that same overhead allows TCP to be a lot more reliable and prevent loss of events/logs when there is a disconnection or problem. As most of you would know, this roughly would translate to a discussion around TCP vs UDP transport. In this particular environment, there were major discussions around reliability vs performance during log transport. There were a couple of design considerations that led to the above architecture:ġ. To give some context to the configuration files which follow, below is the high level architecture which was implemented: High Level Architecture for ELK forensic logging platform There are multiple ways to achieve the desired result, so the rest of this blog post must be taken in context and adapted to your own environment where appropriate. One of the main advantage of ELK is it’s flexibility. There are some additional links which are most definitely useful when using ELK for logging: The official documentation is extremely helpful and is a must read before starting anything. The ELK stack is proving to be a very popular suite of tools, and good documentation abounds on the internet. This article presents some configuration scripts and research links that were used to provision the system and some tips and tricks learned during implementation and R&D of the system This seemed right up elasticsearch’s alley, and the more we use the system, the more adept at this sort of use case it turns out to be. The amount of data generated is quite large, ranging into terabytes of logs and events. The platform would then be used for queries during forensic investigations and to help follow up on Indicators of Compromise. During a recent project we were required to build a “Logging Forensics Platform”, which is in essence a logging platform that can consume data from a variety of sources such as windows event logs, syslog, flat files and databases.

Nxlog flat file