Hi.
This is Rushabh Doshi.
I'm a cloud security architect,
and I welcome you to the course Network Analysis with Maltrail.
With the increase in cybersecurity threats,
it's quite critical to monitor these events and prevent
them at an early stage before it causes any data security
issues or network malfunction.
In this course,
we will study the application called Maltrail and its
architecture to monitor these threats.
We will see some real‑life case studies and a few demos
pertaining to Maltrail installation, monitoring,
and configuration aspects of the server and sensor components.
Maltrail is based on the traffic, sensor, server, client architecture,
and the direction of this communication is based on these arrows shown.
You will see there is a one‑directional area from traffic to sensor, a
bidirectional between sensor and server, and a bidirectional between
server and client.
Sensor is a standalone component running on the monitoring node, for
example Linux platform connected passively to the SPAN mirroring port
or transparently inline on a Linux bridge or at the standalone machine,
example Honeypot, where it monitors the passing traffic for blacklisted
items or trails, that is domain names, URLs, and IPs. In case of a
positive match,
it sends the event details to the server where they are being
stored inside the appropriate logging directory.
If sensor is being run on the same machine as server,
logs are stored directly into the local logging directory.
Otherwise, they are being sent via UDP messages to the remote server.
Server's primary role is to store the event details and provide back‑end
support for the reporting web application. In default configuration, server
and sensor will run on the same machine. So to prevent potential disruptions
in sensor activities, the front‑end reporting part is based on the fat
client architecture. That is, all data post processing is being done inside
the client's web browser interface. Events, that is log entries, for the
chosen period are transferred to the client where the reporting web
application is solely responsible for the presentation part. Data is sent
towards the client in compressed chunks where they are processed
sequentially. The final report is created in a highly condensed form,
practically allowing presentation of virtually unlimited number of events.