There are a number of devices that
are connected to our networking infrastructure that can provide
us with feedback about things that may
be occurring on the network.
These might be switches, routers, firewalls,
VPN concentrators, and other devices.
This is a log file from a switch that
is giving us information about what interfaces may be going
up and down on the switch.
There's also security information on the switch.
The TCP SYN traffic destined to the local system
is automatically blocked for 60 seconds.
This type of information might vary depending
on the logs we are receiving.
If we're looking at router logs, then we'd see router updates.
We may see authentication issues occur with some of these,
especially if it's a VPN concentrator, or things
like this TCP SYN attack, which is related to a network
security issue.
If you've ever looked at log files on an operating system,
then you know there is extensive information
that you can gather.
And very often, this can include information
about the operating system, the file system,
and the applications that are running on that OS.
In Windows, not only do we collect information
about the application, the setup, the system,
and forwarded events, there's also
a section for security events.
The operating system can monitor for security or authentication
events, and log all of that information as well.
Because there is so much information stored
in these operating system log files,
you're going to need some way to filter this information.
You can see on this particular Event Viewer,
there are over 7,000 events stored in this log file.
Fortunately, built into Event Viewer
are a number of different actions
that allow you to filter or be able to view
the data in different ways, so that you can find exactly
what you're looking for.
Many applications also keep their own log files,
and we can get more details about the way an application is
performing based on what we're finding in this log
information.
In Windows, you'll find this application log information
in the Event Viewer under Application log.
And if you're on a Linux operating system,
you'll find many different log entries under /var/log.
You can either view the logs on the system itself,
like I have here, or you could bring those log files
into a Security Information and Event Manager, or SIEM,
and look at all of this information consolidated
into one single place.
The emphasis in this course is on security.
So certainly, there will be a lot of security log information
to view.
You have many different devices that
can gather security details, so that you
can see what traffic flows have been allowed or blocked
through your network.
You can view any exploits that may have been attempted.
You can see if any URL categories have been blocked
by your firewall or your proxy.
And you can also see DNS sinkhole traffic,
which can tell you what devices attempted to connect
to a known malicious location.
Most of these logs and security details
are created on security devices that we have connected
to our network, such as intrusion prevention
systems, firewalls, or proxies.
This can provide us with detailed security information
about every single traffic flow going through the network.
We can get a summary of what attacks
may be inbound to our network, and we can correlate this log
file with the other log files that we're
collecting at the same time.
Firewall logs can give us information about traffic flows
that may be allowed or blocked.
This is a firewall log that shows information
on what IPv6 packets have been blocked on this network.
This firewall is also able to provide information
on website access that has been denied.
And there's many other error messages in here
that might give us an idea of what attacks may be underway.
A web application firewall can also
provide details about application level attacks.
We can see information such as cross-site scripting
attacks that have been attempted from a particular location.
We can see error codes that were created but suppressed,
and kept from the attacker, and this was a code 405
on this particular web server.
And then there are SQL injections
and cross-site scripting attacks that were occurring later
on in this log.
All of this information gives us an idea
about where attacks may be coming from.
It can tell us what attacks we're
stopping at our firewalls, and give us
an idea of where we may want to add additional security
controls in the future.
If you're running a web server, then you
have an extensive log that shows exactly who connected
to your website server, and what pages they were able to view.
We're also able to get information about what errors
may be occurring, especially if someone's
trying to access nonexistent files,
or files that might be associated
with known vulnerabilities.
You can look through log files individually on a web server,
or you can consolidate these log files into a SIEM,
or log file analyzer, to be able to tell
if someone's trying to take advantage of a vulnerability.
And from an operational perspective,
the log file has information about when a service started,
when a service ended, and you'll be
able to get some operational details about how well this web
server is performing.
A Domain Name System server can give us
information about what queries have been made against this DNS
server.
We can view the IP address of the request,
and many log files will also store
the fully-qualified domain name for the request.
We can see if someone's trying to perform a name
resolution to a known malicious site, or site
that has known command and control information.
This may indicate that a device has already been infected
on the inside of our network.
And since we have control of our own DNS server,
we can block any attempts that have
been made to resolve a known malicious site.
We can then use that list to identify potentially infected
devices, and then we can clean those devices,
or remove them from our network.
Whenever we authenticate into a device,
we're commonly using a username, a password,
and perhaps some other type of authentication factor.
Each time we attempt an authentication,
the results of that attempt are logged in an authentication log
file.
We know exactly who was able to gain access to a system,
and who was denied access to that system.
We can find account name, source IP address, the authentication
method they used, and we can create
a report that shows, over time, what devices successfully
authenticated, and what devices did not successfully
authenticate.
If this is one where someone is performing
multiple authentication attempts,
then we may be able to identify brute force attacks
and block them just by looking through our log files.
We can then correlate that with other log files we might have.
So we could see router and switch information,
we can identify SSL VPN authentication,
and see if we can see why this particular device is
authenticating incorrectly, and where it may be coming from.
Here's an authentication log file
showing a series of brute force attempts
where someone is trying to put in the password for the route
login on the server, and ultimately keeps
trying over and over again.
Perhaps in this case, even with different IP
addresses, to try to gain access to this particular server.
You can see exactly when a password attempt failed, you
can see the disconnects for that,
and then you can see the next failed attempt later
on in the log.
All of this information can be consolidated
from all of your servers into one single SIEM,
and then you can create a report that
shows all of the authentication attempts
across your entire network.
Most of the log files we've been discussing so far
are created constantly on the devices that we use every day.
But there's some log files we can create on demand.
A good example of this are memory dump files.
We can take a single application,
using task manager and Windows, and we
can create a dump file that will store everything
in memory associated with that application into a single file.
We would usually create one of these files
when working with tech support to resolve an application
problem.
And we can send that memory dump file to developers in an effort
to try to locate and resolve that issue.
This is very easy to do in the Windows Task Manager
application.
You simply right click the application
and choose create dump file.
You might also find that the application you're
using in Windows, or any other operating system,
has its own internal method of creating a dump
file for the developers.
So make sure you work with the support team
to find the best way to create this memory
dump for your application.
Although most of the environments we're working in
have moved from the traditional plain old telephone
system, running over analog phone lines,
to voiceover IP and digital packets.
And although we've made this technology shift,
we still have reports that we create
based on these voice over IP systems
and our Call Manager logs.
For example, you can view inbound and outbound call
information, including what endpoints were involved
in the phone call, and any communication
that may go in and out of a particular gateway.
There may also be security information inside these log
files, especially if these phones are authenticating
to the Call Manager, and we can see
exactly when a particular phone may have been in use.
And we can get detailed log information
from voiceover IP protocol, such as the session initiation
protocol, which sets up and tears down our phone calls
and messages so that we can see the call setup, the management,
and the tear down of the phone call.
We're also able to see inbound and outbound call information,
and if somebody happens to use unusual country codes,
we may have alarms and alerts based on these log files that
can inform us when something like this
may be happening with our phone system.