Security information can be found in the logs files of almost any device. In this video, you’ll learn about viewing log files on network devices, systems, applications, web servers, and more.
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.