End-of-Life (EoL)
Network threats can originate from different vectors, including malware and spyware infections due to drive-by downloads, phishing attacks, unpatched servers, and random or targeted denial of service (DoS) attacks, to name a few methods of attack. The ability to react to a network attack or infection requires processes and systems that alert the administrator to an attack and provide the necessary forensics evidence to track the source and methods used to launch the attack.
The advantage that Panorama provides is a centralized and consolidated view of the patterns and logs collected from the managed firewalls across your network. You can use the information from the automated correlation engine alone or in conjunction with the reports and logs generated from a Security Information Event Manager (SIEM), to investigate how an attack was triggered and how to prevent future attacks and loss of damage to your network.
The questions that this use case probes are:
How are you notified of an incident? How do you corroborate that the incident is not a false positive? What is your immediate course of action? How do you use the available information to reconstruct the sequence of events that preceded or followed the triggering event? What are the changes you need to consider for securing your network?
This use case traces a specific incident and shows how the visibility tools on Panorama can help you respond to the report.
Incident Notification
There are several ways that you could be alerted to an incident depending on how you’ve configured the Palo Alto Networks firewalls and which third-party tools are available for further analysis. You might receive an email notification that was triggered by a log entry recorded to Panorama or to your syslog server, or you might be informed through a specialized report generated on your SIEM solution, or a third-party paid service or agency might notify you. For this example, let’s say that you receive an email notification from Panorama. The email informs you of an event that was triggered by an alert for a Zero Access gent.Gen Command And Control Traffic that matched against a spyware signature. Also listed in the email are the IP address of the source and destination for the session, a threat ID and the timestamp of when the event was logged.
Review the Widgets in the ACC
In the ACC > Threat Activity tab, check the Compromised Hosts widget and Threat Activity widget for any critical or high severity threats. In the Compromised Hosts widget, look into the Matching Objects and click a Match Count value to view the match evidence for the associated incident.
Review Threat Logs
To begin investigating the alert, use the threat ID to search the Threat logs on Panorama ( Monitor > Logs > Threat). From the Threat logs, you can find the IP address of the victim, export the packet capture (PCAP) by clicking the download icon in the log entry, and use a network analyzer tool such as WireShark to review the packet details. In the HTTP case, look for a malformed or bogus HTTP REFERER in the protocol, suspicious host, URL strings, the user agent, the IP address and port in order to validate the incident. Data from these pcaps is also useful in searching for similar data patterns and creating custom signatures or modifying security policy to better address the threat in the future.
As a result of this manual review, if you feel confident about the signature, consider transitioning the signature from an alert action to a block action for a more aggressive approach. In some cases, you may choose to add the attacker IP to an IP block list to prevent further traffic from that IP address from reaching the internal network.
If you see a DNS-based spyware signature, the IP address of your local DNS server might display as the Victim IP address. Often this is because the firewall is located north of the local DNS server, and so DNS queries show the local DNS server as the source IP rather than showing the IP address of the client that originated the request. If you see this issue, enable the DNS sinkholing action in the Anti-Spyware profile in security rules to identify the infected hosts on your network. DNS sinkholing allows you to control outbound connections to malicious domains and redirect DNS queries to an internal IP address that is unused; the sinkhole that does not put out a response. When a compromised host initiates a connection to a malicious domain, instead of going out to the internet, the firewall redirects the request to the IP address you defined and it is sinkholed. Now, reviewing the traffic logs for all hosts that connected to the sinkhole allows you locate all compromised hosts and take remedial action to prevent the spread.
To continue with the investigation on the incident, use the information on the attacker and the victim IP address to find out more information, such as:
Where is the attacker located geographically? Is the IP address an individual IP address or a NATed IP address? Was the event caused by a user being tricked into going to a website, a download, or was it sent through an email attachment? Is the malware being propagated? Are there other compromised hosts/endpoints on the network? Is it a zero-day vulnerability?
The log details for each log entry display the related logs for the event. This information points you to the Traffic, Threat, URL Filtering or other logs that you can review and correlate the events that led to the incident. For example, filter the Traffic log ( Monitor > Logs > Traffic) using the IP address as both the source and the destination IP to get a complete picture of all the external and internal hosts/clients with which this victim IP address has established a connection.
Review WildFire Logs
In addition to the Threat logs, use the victim IP address to filter though the WildFire Submissions logs. The WildFire Submissions logs contain information on files uploaded to the WildFire service for analysis. Because spyware typically embeds itself covertly, reviewing the WildFire Submissions logs tells you whether the victim recently downloaded a suspicious file. The WildFire forensics report displays information on the URL from which the file or .exe was obtained, and the behavior of the content. It informs you if the file is malicious, if it modified registry keys, read/wrote into files, created new files, opened network communication channels, caused application crashes, spawned processes, downloaded files, or exhibited other malicious behavior. Use this information to determine whether to block the application that caused the infection (web-browsing, SMTP, FTP), make more stringent URL Filtering rules, or restrict some applications/actions (for example, file downloads to specific user groups).
Access to the WildFire logs from Panorama requires the following: a WildFire subscription, a File Blocking profile that is attached to a Security rule, and Threat log forwarding to Panorama. If Panorama will manage firewalls running software versions earlier than PAN-OS 7.0, specify a WildFire server from which Panorama can gather analysis information for WildFire samples that those firewalls submit. Panorama uses the information to complete WildFire Submissions logs that are missing field values introduced in PAN-OS 7.0. Firewalls running earlier releases won’t populate those fields. To specify the server, select Panorama > Setup > WildFire, edit the General Settings, and enter the WildFire Private Cloud name. The default is wildfire-public-cloud, which is the WildFire cloud hosted in the United States.
If WildFire determines that a file is malicious, a new antivirus signature is created within 24-48 hours and made available to you. If you have a WildFire subscription, the signature is made available within 30-60 minutes as part of the next WildFire signature update. As soon as the Palo Alto Networks next-generation firewall has received a signature for it, if your configuration is configured to block malware, the file will be blocked and the information on the blocked file will be visible in your threat logs. This process is tightly integrated to protect you from this threat and stems the spread of malware on your network.
Review Data Filtering Logs
The Data Filtering log ( Monitor > Logs > Data Filtering) is another valuable source for investigating malicious network activity. While you can periodically review the logs for all the files that you are being alerted on, you can also use the logs to trace file and data transfers to or from the victim IP address or user, and verify the direction and flow of traffic: server to client or client to server. To recreate the events that preceded and followed an event, filter the logs for the victim IP address as a destination, and review the logs for network activity.
Because Panorama aggregates information from all managed firewalls, it presents a good overview of all activity in your network. Some of the other visual tools that you can use to survey traffic on your network are the Threat Map, Traffic Map, and the Threat Monitor. The threat map and traffic map ( Monitor > AppScope > Threat Map or Traffic Map) allow you to visualize the geographic regions for incoming and outgoing traffic. It is particularly useful for viewing unusual activity that could indicate a possible attack from outside, such as a DDoS attack. If, for example, you do not have many business transactions with Eastern Europe, and the map reveals an abnormal level of traffic to that region, click into the corresponding area of the map to launch and view the ACC information on the top applications, traffic details on the session count, bytes sent and received, top sources and destinations, users or IP addresses, and the severity of the threats detected, if any. The threat monitor ( Monitor > AppScope > Threat Monitor) displays the top ten threats on your network, or the list of top attackers or top victims on the network.
Update Security Rules
With all the information you have now uncovered, you can sketch together how the threat impacts your network—the scale of the attack, the source, the compromised hosts, the risk factor—and evaluate what changes, if any, to follow through. Here are some suggestions to consider:
Forestall DDoS attacks by enhancing your DoS Protection profile to configure random early drop or to drop SYN cookies for TCP floods. Consider placing limits on ICMP and UDP traffic. Evaluate the options available to you based on the trends and patterns you noticed in your logs, and implement the changes using Panorama templates.
Create a dynamic block list ( Objects > Dynamic Block Lists), to block specific IP addresses that you have uncovered from several intelligence sources: analysis of your own threat logs, DDoS attacks from specific IP addresses, or a third-party IP block list.
The list must be a text file that is located on a web server. Using device groups on Panorama, push the object to the managed firewalls so that the firewalls can access the web server and import the list at a defined frequency. After creating a dynamic block list object, define a Security rule that uses the address object in the source and destination fields to block traffic from or to the IP address, range, or subnet defined. This approach allows you to block intruders until you resolve the issue and make larger policy changes to secure your network.
Determine whether to create shared policy rules or device group rules to block specific applications that caused the infection (web-browsing, SMTP, FTP), make more stringent URL Filtering rules, or restrict some applications/actions (for example, file downloads to specific user groups). On Panorama, you can also switch to the firewall context and configure the firewall for Botnet reports that identify potential botnet-infected hosts on the network.

Recommended For You