All
right, let's take a look at Module 18,
which deals with network logs, monitoring, and analysis.
All right, log files give a tremendous amount of information.
Help us in troubleshooting, help us in incident response, help us in forensics,
help us in performance monitoring, and so forth.
The Log, defined collection of information
or data events generated in the form of an audit trail by the various components of
information system, networks, applications, OS service, etc.
Lots of log files.
All right, so remember, identify, authenticate,
authorize, account, auditing, gives us an audit trail.
So collecting records of events can be a lot of information.
You might want to be discriminating in what you actually log.
From an administration perspective, you
want to log enough so that the log files are manageable, that they don't fill up
logging systems, that they can be easily reviewed, and it's useful information.
From a detection security perspective,
you want to log absolutely everything because in an investigation, you want as
much information or as evidence as possible.
There's a bit of a happy medium between
the both, but log files need to be manageable first and foremost.
They're also supposed to be reviewed by a
human, which I don't know about the other network administrators out there, but
there's always something pressing to do a network administration.
Log file analysis and review often takes a back seat to that thing.
You may get to those logs, you may not.
We have lots of automated log file pricing utilities that will try to do this for us.
But again, there's no replacement for
discriminating judgment by the administrator.
It's logging the process, recording and
storing logs and the events that occur on the network.
Attackers would love to get rid of your log files.
That is step five in the hacking cycle.
The log information needs to be protected.
The logging mechanism needs to be secure
and you should invariably log to a remote system so the log files on the system
that's been compromised can't be easily wiped.
An example of a log, trail of login
failure events followed by successful login event.
We talked a little bit about filtering FTP
logins, things like that in the previous module.
The need for logs, to identify security incidents, monitor policy violations,
identify a fraudulent activity, identify operational and long term problems,
establish baselines, and ensure compliance with laws, rules, and regulations.
Our login requirements.
Before enabling logging capability, you
should know what to log, where to store the logs, what methods used for logging,
tools required for logging, and the log format.
That's really important, making sure that that log format is universally compatible
with your analysis tools, logging engines, and so forth.
You should be able to perform regular tuning and review of logs, synchronized
timestamps of all the sources to perform correlation.
That's really important.
Without a common time setting across multiple systems or a synchronization,
then all of your logged activities are going to appear out of sequence.
That could cause real problems.
One of the first things we look at in a
forensics investigation is what is the current system time?
Is that skewing from an authoritative time
source that you can actually accommodate for any time skews.
Prevent unauthorized access and
manipulation of logs, coordinate data sources to identify malicious activity,
analyzing security events that are to be stored in the event logs.
Typical log format.
Log file contains all sorts of information.
Typically, you're going to have a series of fields that indicate what each column
in the log file indicates, but they can be really verbose.
Identify actual information from logs,
proper log analysis and monitoring is required.
User identification, date and timestamp, pretty common type of event.
Success or failure indications, event
origin, description, severity, service name, protocol, and user potentially.
A lot of times you're not even set by default to log everything.
Enabling extended logging in IS, for
example, throws all sorts of extra fields in.
Our logging approaches.
Local logging means logging the local box.
That's dangerous because if that box gets intruded upon, then those local log files
are accessible to the attacker and they're easily wiped or manipulated or corrupted.
Examples of instances when a host machine generates logs, system crash, shutdown,
restart or startup, failed login attempts, user access privileges.
So all this stuff can be enabled locally
on Windows systems and then using a remote logging mechanism, forwarding these log
events to a centralized server is again, probably a better idea.
So centralized logging, definitely more preferable.
When you centralize everything, but it
does require infrastructure dedicated machines, possibly a denial service on the
centralized logging server, which is why you have backups.
When you set up a SIEM, for example, and
you forward all of your security notifications, alerts, IDS alerts,
antivirus alerts, log entries, events, and so forth to that centralized platform,
it's much easier to get to analyze, manipulate, correlate, and so forth.
So addition, deletion of network devices,
change deployment network settings, user access to the network.
Again, they can be network wide.
They could also be local events or a combination of both.
Serious advantages to centralized logging.