Router-Based Monitoring

Router-based monitoring relies on routers or switches with routing capabilities to provide information about the flow of traffic on the network and the status of the network device itself. Since routers are normally placed at network borders or other internal boundaries, router-based monitoring can provide a useful view of traffic at those points.

Most router-based monitoring relies on capturing data about the traffic that is passing through the device. This information about traffic flow is often referred to as network flows. A number of technologies exist to capture flows and other router information, including

• NetFlow, or similar technologies like sFlow, J-Flow, and others, are standards for monitoring traffic flows. They count information about traffic at network device interfaces and then send that information to flow collectors. Flows are often sampled due to the sheer quantity of data, meaning that one in a thousand or one in a hundred packets are sampled rather than every packet.
• RMON was developed to monitor local area networks and operates at layers 1–4 of the network stack. RMON typically operates in a client/server model and uses monitoring devices (probes) to gather data. It is implemented as a management information base (MIB), which provides monitoring groups with information about networks and focuses on flow-based information, including statistics, history, alarms, and events.
• In addition to flow-based reporting, the Simple Network Management Protocol (SNMP) is commonly used to collect information from routers and other network devices and provides more information about the devices themselves instead of the network traffic flow information provided by RMON or NetFlow or related flow-capture protocols.

In Figure 12.1, a simple example of a typical network shows how the central placement of routers can provide visibility into the overall traffic flow of a network. Traffic sent from the distribution switches to the other division's network, or to the Internet, will be sent through the division routers and possibly through the border router, allowing network flow information to be captured on a central flow collection system.

Flow information can look a lot like information from a typical phone bill—you can see who you called, what number they were at, and how long you talked. With flows, you can see the source, its IP address, the destination, its IP address, how many packets were sent, how much data was sent, and the port and protocol that was used, allowing a good guess about what application was in use. Figure 12.2 shows an example of PRTG's NetFlow tool, with this data listed in a way that allows data to be sorted and searched.

This information can be very useful for both day-to-day monitoring and for investigations. In addition, feeding flow data to a security monitoring tool that uses behavior-based detection capabilities can identify issues like unexpected communications to remote command and control (C&C) systems. In Figure 12.2, you can see that local hosts are browsing remote sites—192.168.1.14 visits 157.240.2.35—a Facebook content delivery network host. If you saw traffic that was not expected when you reviewed traffic or if you were investigating suspicious traffic, flows can provide a useful way to quickly review what a given host is doing. Network flow data can be used both proactively, to monitor overall network health and traffic levels, and reactively, to monitor for unexpected traffic or for sudden changes in network bandwidth usage. This data is often combined with other network and system log and event data using a security information and event management (SIEM) device or log analysis tool to provide deeper analysis and response capabilities.

Active Monitoring

Active monitoring techniques reach out to remote systems and devices to gather data. Unlike flows and SNMP monitoring, where data is gathered by sending information to collectors, active monitors are typically the data gathering location (although they may then forward that information to a collector). Active monitoring typically gathers data about availability, routes, packet delay or loss, and bandwidth.

Two examples of active monitoring are

• Pings—Network data can also be acquired actively by using Internet Control Message Protocol (ICMP) to ping remote systems. This provides only basic up/down information, but for basic use, ICMP offers a simple solution.
• iPerf—A tool that measures the maximum bandwidth that an IP network can handle. Public iPerf servers allow remote testing of link bandwidth in addition to internal bandwidth testing. iPerf testing data can help establish a baseline for performance to help identify when a network will reach its useful limits.

Both active and router-based monitoring add traffic to the network, which means that the network monitoring systems may be competing with the traffic they are monitoring. When significant network bandwidth utilization issues appear, this type of network monitoring data may be lost or delayed as higher-priority traffic is likely to be prioritized over monitoring data.

Passive Monitoring

Passive monitoring relies on capturing information about the network as traffic passes a location on a network link. In Figure 12.3, a network monitor uses a network tap to send a copy of all the traffic sent between endpoints A and B. This allows the monitoring system to capture the traffic that is sent, providing a detailed view of the traffic's rate, protocol, and content, as well as details of the performance of sending and receiving packets.

Unlike active and router-based monitoring, passive monitoring does not add additional traffic to the network. It also performs after-the-fact analysis, since packets must be captured and analyzed, rather than being recorded in real time as they are sent. This means that the trade-offs between each monitoring method should be considered when choosing a technique.

PRTG

One common choice for monitoring bandwidth usage is PRTG (the Paessler Router Traffic Grapher). PRTG provides a variety of network monitoring capabilities, including server monitoring, network monitoring, and bandwidth monitoring. PRTG combines four types of monitoring to provide a more accurate picture of bandwidth utilization:

• Packet sniffing, which monitors only the headers of packets to determine what type of traffic is being sent. This can identify information from packets that the sensor can read, but an encrypted session may not reveal much.
• Flows, which can send either information about all connections, or a sampled dataset.
• SNMP (Simple Network Management Protocol), a protocol that allows network devices to send information about important events as SNMP traps.
• WMI (Windows Management Instrumentation), which provides an interface that allows script and application access for automation of administrative tasks, as well as a means of accessing management data for the operating system, and can provide reports to tools like System Center Operations Manager for Windows systems. A hybrid mode allows access to Windows performance counters using the remote registry service, with WMI as a fallback. This approach can make a Windows system's native monitoring capability useful for a central view.

Figure 12.4 shows PRTG's overview window. Traffic over time as well as flow information are shown in near real time. To investigate a problem, you can simply drill down by clicking the appropriate view.

Overview and dashboard screens in tools like PRTG are often used to provide a high-level overview of network performance. A sudden drop-off or increase in network usage can be quickly seen on the overview chart, and drilling down by clicking the chart can help to isolate or identify a system or interface that is affected or that may be causing the issue. More detailed searches and filters can also be accessed in tools like this to answer specific questions if you are working from existing knowledge like an IP address or interface that needs to be investigated.

SolarWinds

SolarWinds sells a variety of network monitoring tools that address multiple types of data gathering. Combining the ability to identify network issues and intelligence about network bandwidth and flows can provide a better view of what is occurring on a network, making a pairing of tools like this a good solution when trying to understand complex network issues.

Nagios

Nagios is a popular network and system log monitoring tool. Nagios supports a broad range of plug-ins, including the ability to build and integrate your own plug-ins using Perl or executable applications. Nagios provides a broad range of monitoring capabilities beyond network monitoring, making it a useful tool if you want to have a central view of system and network data in one place.

Cacti

Cacti is an open source tool that uses SNMP polling to poll network devices for status information and provides graphical views of network and device status. Additional data can be included by using scripts with data stored in a database, allowing Cacti to provide visibility into a range of devices and data types. Cacti leverages RRDTool, a graphing and analysis package to provide detailed graphical views of the data it gathers.

Bandwidth Consumption

Bandwidth consumption can cause service outages and disruptions of business functions, making it a serious concern for both security analysts and network managers. In a well-designed network, the network will be configured to use logging and monitoring methods that fit its design, security, and monitoring requirements, and that data will be sent to a central system that can provide bandwidth usage alarms. Techniques we have already discussed in this chapter can provide the information needed to detect bandwidth consumption issues:

• Tools like PRTG that use flow data can show trend and status information indicating that network bandwidth utilization has peaked.
• Monitoring tools can be used to check for high usage levels and can send alarms based on thresholds.
• Real-time or near-real-time graphs can be used to monitor bandwidth as usage occurs.
• SNMP data can be used to monitor for high load and other signs of bandwidth utilization at the router or network device level.

Beaconing

Beaconing activity (sometimes a heartbeat) is activity sent to a C&C system as part of a botnet or malware remote control system and is typically sent as either HTTP or HTTPS traffic. Beaconing can request commands, provide status, download additional malware, or perform other actions. Since beaconing is often encrypted and blends in with other web traffic, it can be difficult to identify, but detecting beaconing behavior is a critical part of detecting malware infections.

Detection of beaconing behavior is often handled by using an IDS or IPS with detection rules that identify known botnet controllers or botnet-specific behavior. In addition, using flow analysis or other traffic-monitoring tools to ensure that systems are not sending unexpected traffic that could be beaconing is also possible. This means that inspecting outbound traffic to ensure that infected systems are not resident in your network is as important as controls that handle inbound traffic.

Figure 12.5 shows simulated beaconing behavior, with a host reaching out to a remote site via HTTP every 10 seconds. This type of repeated behavior can be difficult to find when it is slow, but automated analysis can help to identify it. Using a tool like Wireshark to directly capture the traffic, as shown in the figure, can be useful for detailed analysis, but flows and IDSs and IPSs are more useful for a broader view of network traffic.

Unexpected Traffic

Unexpected traffic on a network can take many forms: scans and probes, irregular peer-to-peer traffic between systems that aren't expected to communicate directly, spikes in network traffic, or more direct attack traffic. Unexpected traffic can be detected by behavior-based detection capabilities built into IDSs and IPSs, by traffic-monitoring systems, or manually by observing traffic between systems. Understanding what traffic is expected and what traffic is unexpected relies on three major techniques:

• Baselines, or anomaly-based detection, which requires knowledge of what normal traffic is. Baselines are typically gathered during normal network operations. Once baseline data is gathered, monitoring systems can be set to alarm when the baselines are exceeded by a given threshold or when network behavior deviates from the baseline behaviors that were documented.
• Heuristics, or behavior-based detection, using network security devices and defined rules for scans, sweeps, attack traffic, and other network issues.
• Protocol analysis, which uses a protocol analyzer to capture packets and check for problems. Protocol analyzers can help find unexpected traffic, like VPN traffic in a network where no VPN traffic is expected, or IPv6 tunnels running from a production IPv4 network. They can also help identify when common protocols are being sent over an uncommon port, possibly indicating an attacker setting up an alternate service port.

Not all unexpected traffic is malicious, but it is important to ensure that you have appropriate systems and methods in place to detect anomalies and unexpected behaviors and that you can identify when unexpected traffic is occurring so that you can respond appropriately.

Figure 12.6 shows an IDS detection based on unexpected traffic between a local host (Iodine) and a system in Russia. This detection was flagged as a potential malware download based on its behavior.

DoS Attacks

DoS attacks typically include one or more of the following patterns of attack:

• Attempts to overwhelm a network or service through the sheer volume of requests or traffic
• Attacks on a specific service or system vulnerability to cause the system or service to fail
• Attacks on an intermediary system or network to prevent traffic from making it between two locations

Each of these types of attacks requires slightly different methods of detection. This means that your network, system, and service monitoring capabilities need to be set up to monitor for multiple types of attacks depending on which might target your infrastructure.

A DoS attack from a single system or network can typically be stopped by blocking that system or network using a firewall or other network security device. IPSs can also block known attack traffic, preventing a DoS attack from occurring. Single-system DoS attacks are not as likely as DDoS attacks unless the target suffers from a specific service or application vulnerability, or the target can be easily overwhelmed by a single remote system due to limited bandwidth or other resources.

Distributed Denial-of-Service Attacks

Distributed denial-of-service (DDoS) attacks come from many systems or networks at the same time. They can be harder to detect due to the traffic coming from many places, and that also makes them much harder to stop. Many DDoS attacks are composed of compromised systems in botnets, allowing attackers to send traffic from hundreds or thousands of systems.

Detecting DoS and DDoS Attacks

Since there are many flavors of DoS and DDoS attacks, building an effective DoS and DDoS detection capability usually involves multiple types of tools and monitoring systems. These often include the following:

• Performance monitoring using service performance monitoring tools
• Connection monitoring using local system or application logs
• Network bandwidth or system bandwidth monitoring
• Dedicated tools like IDS or IPSs with DoS and DDoS detection rules enabled

During incident response, the same command-line tools that you can use to analyze network traffic (like netstat) can help with troubleshooting on local servers, but a view from the network or service perspective will typically provide a broader view of the issue.

Wired Rogues

Most wired rogues rely on open or unauthenticated networks to connect. Open networks without access controls like port security, which checks for trusted MAC addresses, or network access control (NAC) technology are easy targets for wired rogue devices. A wired rogue device typically means that one of two likely scenarios has occurred:

• An employee or other trusted member of the organization has connected a device, either without permission or without following the process required to connect a device.
• An attacker has connected a device to the network.

The first scenario may be a simple mistake, but the second implies that an attacker has had physical access to your network! In either case, rogue devices connected to a wired network should be responded to quickly so that they can be removed or otherwise handled appropriately.

Wireless Rogues

Wireless rogues can create additional challenges because they can't always easily be tracked to a specific physical location. That means that tracking down a rogue may involve using signal strength measures and mapping the area where the rogue is to attempt to locate it. Fortunately, if the wireless rogue is plugged into your network, using a port scan with operating system identification turned on can often help locate the device. In Figure 12.7, a common consumer router was scanned after it was connected to a network. In this example, nmap cannot immediately identify the device, but it is obvious that it is not a typical desktop system since it shows the router as potentially being a VoIP phone, firewall, or other embedded device.

Processor Monitoring

Understanding what processes are consuming CPU time, how much CPU utilization is occurring, and when the processes are running can be useful for incident detection and response. Sudden spikes, or increased processor consumption in CPU usage on a system with otherwise consistent usage levels, may indicate new software or a process that was not previously active. Consistently high levels of CPU usage can also point to a DoS condition. Used alone, CPU load information typically will not tell the whole story, but it should be part of your monitoring efforts.

Memory Monitoring

Most operating system level memory monitoring is focused on memory utilization or memory consumption, rather than what is being stored in memory. That means your visibility into memory usage is likely to focus on consumption and process identification. Most protective measures for memory-based attacks occur as part of an operating system's built-in memory management or when code is compiled.

Most organizations set memory monitoring levels for alarms and notification based on typical system memory usage and an “emergency” level when a system or application is approaching an out-of-memory condition. This can be identified by tracking memory usage during normal and peak usage and then setting monitoring thresholds, or levels where alarms or alerts will occur, based on that data.

Drive Capacity Monitoring

Drive capacity monitoring typically focuses on specific capacity levels and is intended to prevent the drive or volume from filling up, causing an outage. Tools to monitor drive capacity consumption are available for all major operating systems, as well as centralized monitoring and management systems like System Center Operations Manager (SCOM) for Windows or Nagios for Linux. Microsoft Endpoint Configuration Manager can also provide information about disk usage, but it is not a real-time reporting mechanism. Disk monitoring in real time can help prevent outages and issues more easily than a daily report since disks can fill up quickly.

Filesystem Changes and Anomalies

Monitoring in real time for filesystem changes can help to catch attacks as they are occurring. Tools like the open source Wazuh security platform provide file integrity monitoring that keeps an eye on files, permissions, ownership, and file attributes and then sends alerts based on that monitoring.

Open source tools like Tripwire (Tripwire is available as both a commercial and an open source tool) and Advanced Intrusion Detection Environment (AIDE) as well as a wide variety of commercial products offer this type of functionality. The trade-off for most products is noise level due to filesystem changes that are part of normal operations versus catching unexpected changes.

Manual verification of files using known good checksums is also part of many incident responders practice. Sites like the National Software Reference Library (NSRL) collect digital signatures to allow verification against known checksums: www.nist.gov/itl/ssd/software-quality-group/national-software-reference-library-nsrl.

System Resource Monitoring Tools

Windows provides built-in resource and performance monitoring tools. Resource Monitor, or resmon, is the Windows resource monitor and provides easy visibility into the CPU, memory, disk, and network utilization for a system. In addition to utilization, its network monitoring capability shows processes with network activity, which TCP connections are open, and what services are associated with open ports on the system. Figure 12.8 shows the Resource Monitor overview screen for a sample Windows 10 system.

Performance Monitor, or perfmon, provides much more detailed data, with counters ranging from energy usage to disk and network activity. It also supports collection from remote systems, allowing a broader view of system activity. For detailed data collection, perfmon is a better solution, whereas resmon is useful for checking the basic usage measures for a machine quickly. Figure 12.9 shows perfmon configured with a disk and processor monitor. This data can be combined into user- or system-defined reports.

The Sysinternals suite for Windows provides extensive monitoring capabilities beyond the built-in set of tools. You can download the Sysinternals tools at technet.microsoft.com/en-us/sysinternals/, or you can run them live at the Windows command prompt or from File Explorer by entering https://live.sysinternals.com/toolname, replacing toolname with the name of the tool you want to use.

Linux has a number of built-in tools that can be used to check CPU, disk, and memory usage. They include the following:

• ps provides information about CPU and memory utilization, the time that a process was started, and how long it has run, as well as the command that started each process.
• top provides CPU utilization under CPU stats and also shows memory usage as well as other details about running processes. top also provides interaction via hotkeys, including allowing quick identification of top consumers by entering A.
• df displays a report of the system's disk usage, with various flags providing additional detail or formatting.
• w indicates which accounts are logged in. Although this isn't directly resource related, it can be useful when determining who may be running a process.

Many other Linux tools are available, including graphical tools; however, almost all Linux distributions will include ps, top, and df, making them a good starting point when checking the state of a system.

Abnormal OS Process Behavior

Abnormal behavior observed in operating system processes can be an indicator of a rootkit or other malware that has exploited an operating system component. For Windows systems, a handful of built-in tools are most commonly associated with attacks like these, including cmd.exe, at.exe and schtasks.exe, wmic.exe, powershell.exe, net.exe, reg.exe, and sc.exe, and similar useful tools.

Tools like Metasploit have built-in capabilities to inject attack tools into running legitimate processes. Finding these processes requires tools that can observe the modified behavior or check the running process against known good process fingerprints.

Another common technique is to name rogue processes with similar names to legitimate operating system components or applications, or use DLL execution via rundll32.exe to run as services via svchost.

Registry Changes or Anomalies

The Windows registry is a favorite location for attackers who want to maintain access to Windows systems. Using run keys, the Windows Startup folder, and similar techniques is a common persistence technique.

Registry run keys can be found in

• HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionRun
• HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionRun
• HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionRunOnce
• HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionRunOnce

That means that monitoring the Windows registry for changes can be an important part of incident response. For systems with infrequent changes like servers, protecting the registry can be relatively easily done through the use of application whitelisting. In cases where registry monitoring tools are not an option, lockdown tools can be used that prohibit registry changes. When changes are required, the tools can be turned off or set into a mode that allows changes during patching windows, and then turned back on for daily operations. For workstations where changes may be made more frequently, more in-depth control choices like an agent-based tool may be required to prevent massive numbers of false positives.

Unauthorized Scheduled Tasks

Scheduled tasks, or cron jobs in Linux, are also a popular method for attackers to maintain persistent access to systems. Checking for unexpected scheduled tasks (or cron jobs) is a common part of incident response processes.

To check scheduled tasks in Windows, you can access the Task Scheduler via Start ➢ Windows Administrative Tools ➢ Task Scheduler. Figure 12.10 shows the detail you can access via the graphical Task Scheduler interface, including when the task ran, when it was created, and other information.

You can detect unexpected scheduled tasks in Linux by checking cron. You can check crontab itself by using cat /etc/crontab, but you may also want to check /etc/cron for anything stashed there. Listing cron jobs is easy as well; use the crontab -l command to do so. You should pay particular attention to jobs running as root or equivalent users, and using the -u root flag in your crontab list command will do that.

Application Logs

Application logs can provide a treasure trove of information, but they also require knowledge of what the application's log format is and what those logs will contain. While many Linux logs end up in /var/log, Windows application logs can end up gathered by the Windows logging infrastructure or in an application specific directory or file.

Part of a security professional's work is to ensure that appropriate logging is set up before an incident occurs so that logs will be available and will be protected from modification or deletion by an attacker. Sending critical application logs to a central log collection and/or analysis service is a common part of that strategy.

Application and Service Anomaly Detection

Anomalous activity from services and applications can be relatively common. A variety of non-security-related problems can result in issues, such as

• Application or service-specific errors, including authentication errors, service dependency issues, and permissions issues
• Applications or services that don't start on boot, either because of a specific error or, in the case of services, because the service is disabled
• Service failures, which are often caused by updates, patches, or other changes

Service and application failure troubleshooting typically starts with an attempt to start, or restart, the service. If that is not successful, a review of the service's log message or error messages can provide the information needed to resolve the problem.

Anomalies in services and applications due to security issues may be able to be detected using the same monitoring techniques; however, additional tools can be useful to ensure that the service and its constituent files and applications are not compromised. In addition to common service and log monitoring tools, you might choose to deploy additional protection such as the following:

• Antimalware and antivirus tools
• File integrity checking tools
• Whitelisting tools

service –-status-all

/etc/init.d/servicename status

Application Error Monitoring

Most Windows applications log to the Windows Application log (although some maintain their own dedicated log files as well). To check for application errors, you can view the Application log via the Windows Event Viewer. You can also centralize these logs using SCOM.

Many Linux applications provide useful details in the /var/log directory or in a specific application log location. Using the tail command, these logs can be monitored while the application is tested. Much like Windows, some Linux applications store their files in an application-specific location, so you may have to check the application's documentation to track down all the data the application provides.

Application Behavior Analysis

Applications that have been compromised or that have been successfully attacked can suddenly start to behave in ways that aren't typical: outbound communications may occur, the application may make database or other resource requests that are not typically part of its behavior, or new files or user accounts may be created. Understanding typical application behavior requires a combination of

• Documentation of the application's normal behavior, such as what systems it should connect to and how those connections should be made
• Logging, to provide a view of normal operations
• Heuristic (behavioral) analysis using antimalware tools and other security-monitoring systems to flag when behaviors deviate from the norm