Create a custom application with a custom signature
Manage custom applications
Create a custom application without a custom signature
Configure an Application Override policy
Applications are not always identified
Some applications can not be uniquely identified. Such as commercial or internally developed software.
These fall under a generic classification, such as unknown-tcp, unknown-udp, unknown-p2p, web-browsing or ssl.
Custom applications offer more granular control and reporting abilities to work in the Palo Alto firewall.
Controlling application traffic
There are different types of control application traffic on the Palo Alto firewall:
Commercial application known to App-ID can be used in Security Policy to permit or deny.
A commercial applciation unknown to App-ID can be submitted to Palo Alto networks to have a new signature created for the application to be used in security policies.
Additionally, a custom application can be created with a signature on the Palo Alto device that can be used as an application in the security policy.
Finally, a custom application can be created without a signature, using the application in application override feature.
With an internal application, your choices are limited to creating a custom application with a signature, to be used in Security Policy, or creating a custom application without a signature to be used as an application in application override.
Creating a custom application
To create an application with a signature, application traffic needs to be captured and unique bit patterns identified. The custom application can be created with signature and then applied in the security policy rules.
Automatic Packet Captures
The Palo Alto firewall randomly captures traffic that has been identified as unknown by the App ID database.
These logs can be downloaded within the Monitor -> Logs -> Traffic section of the firewall, clicking the green arrow next to the maginifying glass with export the file that can be re-imported into a Network Analyser such as wireshark
To verify that unknown traffic is being captured, the CLI command below can be ran on the firewall to check:
show running application setting | match "Unknown capture"
If the setting is not toggled to on or off, it can be changed with the following command, followed with a commit
set deviceconfig setting application dump-unknown <yes/no>
Manual Packet Captures
The Palo Alto firewall can carry out manual packet captures on the data plane, although it must be noted that an active packet capture may impact firewall performance. The Palo Alto firewall has limited analysis abilities built into it’s web interface.
The Palo Alto firewall can also capture traffic on the control plane, though this is limited to troubleshooting operational issues rather than troubleshooting application identification.
A packet capture to a network analyser offers more benefits over a packet capture to the local Palo Alto. Firewall performance is not impacted and much greater analysing abilities are available to an application dedicated to the task.
Capturing packets on the data plane can be filtered to a number of differnet options, such as:
Source IP address
Destination IP address
Source Port number
Destination Port number
Packets can also be captured at different stages as they progress through the Palo Alto firewall.
recieve stage – Captures pre-session packets when they are received on the data plane. Packets will have a pre-NAT address
drop stage – Captures packets dropped by the data plane for whatever reason
firewall stage – Captures packets matched to a session and processed by the firewall
transmit stage – Captures packets matched to a session and trasmitted by the data plane. Captured packets here will have a post NAT address
To take a data plane capture, go to monitor and select the option ‘Packet Capture’
Custom Application Creation
Custom applications can be created under the Objects -> Applications section of the Palo Alto
Once added, the application can be added under the security policy of the firewall.
For applications without a signature, application override can be used.
Interpret the application labels in logs and reports
Migrate from a port-based Security Policy to an application-based Security policy
Maintain an up-to-date App-ID implementation
App-ID identifies applications in traffic o bserved by the firewall.
Traffic enters the firewall, and is attempted to be identified it’s application signature. If the firewall has decryption of SSL enabled, it will try to decrypt it and attempt to identify the decrypted traffic again by it’s signature.
If the application can not be identified by it’s signature, a protocol decoder attempts to identify the application.
If the protocol decoder fails in it’s identification of the application, the traffics analysed using behavioral heuristics.
At this point, if the traffic can still not be identified. The application is listed as unknown traffic.
At any point the application is identified, it is compared against the Security/Decryption and what action is required to be taken. If the application is not identified the same process can occcur, just under the ‘unknown’ application tag.
The Palo Alto firewall can identy encrypted traffic under the SSL application by decrypting it. Once decrypted the Palo Alto firewall takes the same process as above of trying to identify the traffic using signatures, protocol decoders, and behavioral heuristrics.
Applications can also be identified in Encrypted SSL traffic. If a single website users a unique IP address, the CN in the certificate can be used to identify the website being accessed.
If multiple websites shared an IP address, the SNI field in TLS can be used to identify the website being accessed.
When creating security rules, application id’s should be implemented using a positive security model. This means to specify what to allow rather than what to block – similar to a whitelist.
Being a next generation firewall, the Palo Alto should be configured by block via application, rather than port numbers. Port numbers would be a more typical approach to security on a standard router or layer 3 switch.
Applications can be controlled on non-standard ports. Under the service tab of the security rule, selecting application-default only permits the applications to operate on their commonly known ports. This can be changed to ‘any’ which allows the application to operate on any port. An additional service can be created which allows the Palo Alto administrator to permit the application to be communicated with on ports that may be non standard.
Note that when an application is SSL encrypted, it may operate on a port that is different from the standard port that is commonly known when the application operates in plain text.
Following from Palo Alto OS 9.0, applications do contain two different fields that list applications with their Standard non-SSL ports, and another field that lists their secured ports.
Examples of these applications would be:
Application IDs can be identified in the logs, under the column Application in Monitor > Logs > Traffic.
Labeling of TCP traffic in the logs:
not-applicable – Traffic dropped from policy before the traffic could be identified
incomplete – Three-way handshake dd not complete or was followed by no data
insufficent-data – Not enough payload of identification
unknown-tcp – Unidentifiable TCP traffic
unknown-p2p – Unidentifiable peer-to-peer traffic
Labeling of UDP traffic in the logs:
not-applicable – Traffic dropped per polciy before application could be identified
unknown-udp – Unidentifiable UDP traffic
unknown-p2p – Unidentifiable peer-to-peer traffic
If allowed network traffic is unidentifiable by App-ID, it is examined to see if https is present. If https is present the applcation I.D. is set to SSL. If http is detected, the application I.D. is set to web-browsing. If http is not detected, the application i.d. is set to: unknown-tcp, unknown-udp or unknown-p2p. The traffic log can be examined for further details
Unknown applications can be controlled by blocking the three categories unknown-tcp, unknown-udp and unknown-p2p in a security policy. The application can be manually identified by creating a custom application with a custom signature in Objects -> Applications -> Add. Alternatively an application override policy can be created under Policies -> Application Override
Moving to a Palo Alto firewall, or an application based firewall can be done in a couple of methods. Using the greenfield method or the migration method.
The greenfield method involves putting the firewall in a logging state sitting between the legacy third party firewall and the internet. This can be done in VWire, L3 or TAP mode. The information logged can be used to create a suitable security policy on the firewall based on identified applications in the logs.
The Migration method has three phases.
Phase 1 is to migrate the legacy port based policy to a Palo Alto Networks firewall. The goals being to ensure a succesful cutover, with minimised user issues. In this state the firewall can capture application traffic.
Phase 2 consists of adding application based rules above corresponding port-based rules, reducing the attack surface and removing unknown applications as soon as possible.
Phase 3 consists of removing the old legacy port-based rules, completing the policy migration from a port-based firewall to an application one.
The priortisation of rules to migrate can be found in the policy optimiser, that gives clues to the most common port based ruels in use during a migration. Attention should be paid to the rules that utlise the most traffic with services and no applications defined. The policy optimiser also displays the numbers of applications seen attached to a rule and the number of days since an additional application has been observed. A hit count is present in the Rule Usage section of the Policy Optimiser, so that attention can be paid to the Rules with the most hits.
Policy Optimiser also has a section for Unused Applications, that will identify applications permitted in a security rule that have not been seen in some number of days. This can be useful in optimising rules where previous applications are no longer present
Application and Threat conent updates are pulled to the firewalls from https://updates.paloaltonetworks.com
The content updates for application signatures, including Protocol decoders and Protocol context create App-ID that allows the firewall to identify applications. These updates do not require a licence.
Threat signatures, which contain Threat Signatures along with protocol decoders and protocol contexts create Context-ID. The addition of the Threat Signatures are a licenced feature that require a licence on the Palo Alto firewall.
These two signature types are what the Palo Alto firewall depend on to maintain maximum protection on the network and should be scheduled to update regularly. If an outdated application i.d. can not identify the traffic, then the content i.d. can not inspect traffic for threats.
Two content update workflows are available based on the administrators priority for updating the firewall. If application uptime is the priority:
Allow new App-IDs in Security Policy Rule
Schedule download and install
Review content release notes
View new and modified App-IDs
Review and update policies
Commit the configuration
If security first is the chosen workflow:
Schedule a download and install
Review content release notes
View new and modified App-IDs
Review and update policies
Commit the configuration
To not block new applications, create a security rule to permit new applications, adding a filter for the sub-category of the new application type you would like to permit. On the application filter ensure the checkbox: Apply to new App-IDs only is ticked.
To schedule the download and install of new applications, see the Dynamic Updates section under Device. Set the schedule to update as requested.
Release notes for the application I.D.’s can be selected on the same page under the Documentation column as well as new and modified applications since the last installed update.
Updates do not need to be scheduled, but can be manually downloaded and installed from the Dynamic Updates page.
The impact of the downloaded application ids can be checked once downloaded against the existing security policy.
Palo Alto themselves maintan three lists of IP addresses that can be used in Security Policy rules. These are:
Palo Alto Network – Bulletproof IP addresses
Palo Alto Networks – High risk IP addresses
Palo Alto Networks – Known Malicious IP addresses
If an IP address is mistakingly blocked, exceptions can be added.
Other external dynamic lists can be added under Object -> External Dynamic Lists -> Add
A commit operation does not need to be commited each time the IP list requires or has been updated
Mindmeld can be used with Palo Alto firewalls. Mindmeld is an open source tool to input, aggregate, de-duplicate, and output threat intelligence feeds.
The feeds can include malicious IP addresses, domains, and URLS.
Mindmeld shares this list as a webpage that a Palo Alto can access as an External Dynamic List.
Minemeld uses at least 3 nodes to process feeds: A miner, Processor, and Output mode.
The Miner mode accepts a feed input, written for a specific source.
The Processor node aggregates these inputs, and removes any duplicates.
The output node formats the feed and outputs it for a specific target such as a firewall to download as an EDL.
Passive DNS monitoring collects anonymized domain to IP address mapping.
The information gathered from passive DNS monitoring is sent to Wildfire to improve PAN-DB, C2 signatures, and malware detection.
By sharing this information among these databases and signatures, it improves the signatures to detect malicious domains.
This is an opt-in feature, which should be enabled.
Anti-Spyware Security Profiles
Palo Alto distrubute malicious domnain signatures, which are detected with the use of an Anti Spyware Profile. The Anti Spyware Security Profile contains a ruleset to detected and process these threats accordingly.
Malicious domain signature lists are available from many sources accessed as external dynamic lists.
When setting up as an external dynamic list for a Malicious Domain List, it’s type must be set as Domain List.
Malicious Domain Lists can be used from MindMeld
When a DNS query from a client host is received that points to a malicious domain, the Palo Alto firewall responds with a sinkhole address, recording the event in the Threat log.
The host is returned with the IP address of the sinkhole, when the host tries to access this sinkhole address it is logged in the Traffic log.
To configure DNS signature match protection, enter the objects tab and select Anti-Spyware
Add new a profile, select the DNS signatures tab.
Viewing the attempted access of Malicious Domains can be viewed in the Threat Log
URL categories can be used to reduce the attack service of a Delivery or Command and Control stage of the attack life cycle.
There are two methods in accomplishing this, URL categories can be used as a match condition in a Security Policy deny rule or access can be blocked to a URL category in a URL filtering profile.
A security policy deny rule can be used to block access to risky URL categories for most employees.
It is recommended to block command-and-control, dynamic-dns, hacking, high-risk, malware, phishing and unknown.
It is good practice to typically add deny rules towards the top portion of the security policy rules.
URLs denied by the security policy are not logged.
Note that the URL Blocked List has precedence over the Allowed List.
Specific URLs can be blocked by adding them to a custom URL category.
The custom URL category can be attached to a security policy deny rule. Note that individual or specific URLs cannot be attached to a policy rule.
User-ID can be be enabled on the source zone to restrict particular users or groups to policy rules controlling URL category access.
It is recommended to enable logging on the policy rule if the URLs are risky, or to help improve or refine policy rules. Too many hits for example may indicate false positives
URL filtering implements additional security checks on the permitted traffic.
When a URL is checked it is matched against a Security Policy for the following conditions in this order:
Does the URL match to a predefined or custom URl category, if so, does the rule Permit or Deny this URL?
If permited, the traffic continues to a URL filtering profile. Does it match to a predefined or custom URL category?
If so, does the firewall:
Custom URL lists can be fed into the Palo Alto firewall from MineMeld and other services. Ensure to set the Type to URL List when creating the External Dynamic List.
This post is just notes from my own learning, do expect errors in writing!
Describe the security benefits of implementing network segementation
Network segmentation can be used to secure access to data by dividing the network into multiple areas. This helps prevent an attacker from gaining access to key resources
They are factors to consider before implementing network segementation, such as deciding who in your organisation needs access to what. You could consider how the comprimise of data could affect your organisation.
The user to data access is an important factor when it comes to segmenting the network. When implementing the principle of least privilege should be used
Regulatory or law requirements is another factor that needs to be considered. Failure to adhere to this can result in data loss, goverment or regulatory fines, lost customer confidence or in a worst case, loss of the entire business.
A zero trust architecutre fixes the deficiences of a perimeter only architecture. Zero trust is based on the principle to:
‘Never Trust, Always Verify’
After the network is segmented using subnets or VLANs, firewalls with security zones should be used to control traffic between these segements of the network.
Here is a diagram of a zero trust network, note how every VLAN goes through the firewall and a seperate zone:
Network segementation as in the north east south west setup above, can massively reduce the attack surface of the organisations network if implemented correctly
Configure firewall security zones to implement network segmentation
Click Add Rule under Security Policies
Configure a Zone Protection Profile or denial of service Protection policy to mitigate denial of service or reconnaissance attacks
Denial of service attacks are meant to overload or shut down a network, host, or service.
Denial of service attacks attempt to accomplish this by flooding the target with traffic, or sending malware that triggers a software crash.
By crashing the network, host, or service the attacker deprives any legitimate users from access to the service or resource.
This can cost the victim substantial time and money.
The Palo Alto firewall has features to protect against multisession and single-session denial of service attacks.
Overview of a Multisession attack:
Type 1 – Multisession from Single Host
A single device attempts to establish a high rate of connections per second (cps). Each connection attempt tries to initialise a new firewall session.
To mitigate this attack, implement a Zone Protection Profile or Denial Of Service Protection Policy
Type 2 – Multisession from Multiple Hosts
This is also known as a distributed denial of service attack, or DDoS
Multiple devices attempt to establish a high rate of connections per second to a single host. Each connection attempt tries to initialise a new firewall session.
The below Palo Alto CLI command allows you to monitor the firewall connection per second rate:
show session info | match "Number of allocated sessions"
To mitigate this attack, configure a Zone Protection Profile, ask your internet service provider to black-hole your targeted IP addresses, or deploy a dedicated anti denial of service application.
Overview of a Single Session Denial of Service Attack
A single-session denial of service attack is launched from a single host. This single host tries to transmit as much data as possible to the target destination.
These type of attacks can be identified by a high packet rate in an established firewall session.
The below CLI command allows the user to monitor the packet rate:
show session info | match "Packet Rate"
To mitigate this type of attack, enable packet buffer protection or discard the session altogether by using this CLI command:
request session-discard id <session_id>
Mitigating Denial of Service attacks in Palo Altos.
Pointers on the Denial of Service protection within Palo Alto Firewalls:
Palo Alto firewalls use packet header information to detect threats to the network
An advantage is the detections are packet-based rather than signature-based
The denial of service protections are not linked to any security policy, they are deployed before the security policy comes into play
Two primary technologies come into play for denial of service protection on Palo Alto Firewalls:
A Zone Protection Profile provides pre-session, broad-based, comprehenisive denial of service protection at the edge of your network to protect organisations from denial of service attacks. The Zone Protection profile protects against the most common of TCP SYN, UDP, ICMP and other IP based flood attacks
The Protection Profile is applied per zone to ingress traffic, packets that are not already associated with an existing session are counted towards an aggregate connection rate. This is measured once per second
If the aggregated connection rate exceeds and is detected as a flood Palo Alto firewalls have two methods to protect against flood attacks. These are:
Random Early Drop
Exclusively used for UDP, ICMP, and IP based flood mitigation. Can be used for TCP SYN flood mitigation
Used for SYN flood mitigation
Random Early drop works with three thresholds, Alarm Rate, Activate, and Maximum.
SYN packets that do not match an existing session are logged to the Threat log if it exceeds the Alarm Rate connections per second threshold.
Random Early drop is activated once the Activate Threshold is exceeded. Once activated, the firewall will begin to randomly drop packets.
If the maximum threshold has been reached, then the firewall will drop all SYN packets that exceed the Maximum connections per second threshold.
If Random Early Drop is eanbled, the firewall will drop some legitimate traffic along with flood traffic
SYN cookies is to prevent half open TCP connections from exhausting memory resources oin a target server that is flooded with illegitimate TCP SYN packets
When the firewall uses SYN cookies, it’ll record information such as: maximum segment size, TCP window scaling option, and selective acknowledgements.
SYN cookies is the recommended method to use over random early drop, as it wil not drop legitimate traffic.
It is also recommended not to enable SYN cookies if you’re data plane CPU is nearing maximum use.
Switching on Zone Protection
Flood Thresholds can be set in two ways: detect and log, or detect, log, and block denial of service attacks.
Flood Detector ensures the firewall detects a denial of service attack at a low connection per second raete while ensuring packets are not dropped by the firewall. Flood Detector set’s an alarm rate at a low rate to alert, but the Active and Maximum are set to very high levels to ensure legitimate traffic is not dropped.
Flood Blocker sets the Alarm Rate at a low level too. The difference from a Flood Detector is the Active and Maximum rate are set to much lower levels and are more likely to be invoked.
Recommendations for the Flood Thresholds are to set a Zone Protection Profile on an ingress zone to protect against floods. Consider a zero trust approach, with all protocol flood protections enabled using the SYN cookies protection method.
Adjust the specific flood thresholds applied to each zone by taking a base line measure for each flood type so that a normal traffic load for each zone can be determined. The alarm rate and threshold can be used to try determine the baseline, eventually being raised above 15%-20% of the baseline traffic.
Active threshold should be set roughly 10% above the Alarm Rate threshold, and the maximum threshold should be set roughly 20% above that of the Active Threshold.
It’s important to monitor these baselines over time.
The Denial of Service protection policy and denial of service protection profiles provide session-based flexible rules and matching criteria enabling the administrator to protect specific destination zones or end hosts.
These two technologies complement each other and should be deployed in tandem to achieve the best results against the different types of denial of service attacks observed on the internet today.
A Zone Protection profile can protect against host sweep reconnaissance scans, and defend against TCP and UDP port scans.
Port scans discover open ports on a network host. The port scanning tool sends requested to a large range of port numbers on a host to locate a service running on an open port.
Host sweeps contact multiple hosts to determine if a specific port is open and vulnerable to exploitation.
To enable Reconnaise Protection, open the Zone Protection Profile in the Palo Alto Management Interface and select the tab Reconnaisance Protection.
The recommendations for configuring ideal values for Reconnaissance Thresholds are exactly very similar to that of Flood Protection: Establish a baseline with default Interval and Threshold values. Once established set the Interval and Threshold values above the baseline, and Block/Block Ip above that.
If the organisation is currently going under a penetration test, the administrator can whitelist the IP of the pentration tester on the smae Reconnaissance Protection tab.
Alerts from the Reconnaissance Protection will be displayed in the Threat Log on the Palo Alto Firewall
Zone protection also offers a defence against packet based attacks. The Zone Protection Profile can be configured to check IP, IPv6, ICMP, ICMPv6, UDP and TCP packet header parameters.
When the packet header fails a check against the Palo Alto firewall, the firewall can drop the entire packet and it’s undesirable characterisitics or strip undesirable options from TCP packet headers. Do note that the stripping of headers works for TCP packets only
You can set four different types of drop characteristics in the Zone Protection Profile. These are malformed IP packets, TCP SYN packets, SYN-ACK packets, or Fragmented ICMP packets.
Any drop options selected that are activated will be displayed in the Threat Log of the firewall.
The last type of Zone Protection is Protocol Protection. This allows you to control what types of protocol are permitted or denied through the zones of the firewall.
To enable Zone Protection, go to Network tab and select Zones
Select the zone you wish to modify, a new window will open up. Towards the bottom of the screen is a drop down box that allows you select the Zone Protection Profile
Denial of Service Protection Profiles and Policies
Denial of Service Protection comes in two parts, Policies and Profiles.
The Denial of Service Protection Policy defines the match criteria and action taken against that match criteria. The criteria can range in a number of different rules such as:
Source zone or interface
Source IP address
Destination zone or interface
Destination IP address
If a match is found against the criteria, three different actions can be taken:
Protect – Apply limits to the matching traffic passing through the firewall through ethier an Aggregate Profile or a Classified Profile
Allow – Allow all packets through the firewall
Deny – Deny all packets access through the firewall
If a rule is set to be Protect, matching traffic is controlled by the limits set in the Denial of Service Protection Profile. This can be an aggregate profile that applies limits all matching traffic, or a classified profile that applies limits to a single IP address.
The aggregate profile enables the creation of a maximum session limit for all connections matching the denial of service protection policy rule. The threshold will apply a maximum session limit to all IP addresses that match against the policy rule. once the maximum sessions limit is reached, no other new sessions can be created for any other IP addresses that match against the denial of service protection policy rule.
The classisifed profile enable sthe creation of a session limit that jsut applies to a single IP addres.
The firewall administrator can choose whether the single IP address is matched to the source, destination, or both source or destination address.
Both of these profile types can be applied do a Denial of Service Protection Policy rule. A typical usage scenario is that the aggregate profile limits are generally greater than the classified profile limits.
To configure a Denial of Service Protection Profile, under Objects tab select DoS Protection
To configure a DoS protection policy, select Policies on the top tab and navigate to DoS Protection
In the Denial of Service Protection Configuration Window, Source and Destination zones or interfaces can be selected. Particular services (such as HTTP or VNC) can be protected against rather than covering any service that transmits through the firewall zones. Under the Option/Protection tab the Aggregate and/or Classified profiles can selected to apply to the Denial of Service Protection Rule
The firewall maintains a list of source IP ad dreesses that it is blocking in the IP block list.
The block list is populated by a match to a classified Denial of Service Protection policy and profile, or populated by a match to a Vulnerability Protection Profile.
The block list, under Monitor -> Blocked IP List allows several features:
Displaying of blocked IP addresses
Get detailed information about a blocked IP address
Displays a total count of IP addresses that are hardware offload blocked, and software blocked
The ability to delete an IP address from the blocked IP address list
Change the source of information about IP addresses that are listed
Modify the duration that IP addresses are blocked by hardware
Note that hardware offloaded IP address blocking is only supported by some higher end Palo Alto Firewalls, these are:
Configure firewall packet buffer protection
Packet buffer protection allows an administrator to protect their organisation firewall against single-session denial of service attacks.
Packet buffer protection is session-based and is applied on a zone by zone basis. A percentage measure of the packet buffer used by a session is measured, with several thresholds that can be triggered: Alert, Activate, and Start Block Hold Time.
Alert logs that a threshold has been exceeded, but does not drop any packets
Once the activate threshold is triggered, random early discards (RED) will activate to discard session packets. If random early discard protection cannot reduce the packet buffer when the Block Hold Timer expires, the session is discarded.
To configure Packet Buffer Protection, under the Device tab in the firewal select Session. Click the cog for session settings and modify the Packet Buffer Protection sessions as desired.
Once configured in the session settings, navigiate to the Zone configuration section, and open the zone you wish to activate Packet Buffer Protection on.
Packet Buffer Protection can be toggled on in this zone.
An administrator can manually discard a session abusing the packet buffer too. To identity the top five sessions using more than 2% of the system packet buffer, enter the CLI command:
show running resource-monitor ingress-backlogs
The above CLI command will report the session ID, percentage of the buffer used, the Source IP address and application name. This command can be run on any PA-3000, PA-5000, or PA-7000 series firewall.
If the return results use a common TCP or UDP port, yet the CLI output is unable to identify the application (indicating the application as undecided), the session could be attack traffic. The application is displayed as undecided when the firewall is unable to obtain enough information to determine the application in use. If a high amount of traffic is passing through the firewall in a single session yet the application is labeled as undecided, this could be deemed suspicious.
To discard an identified suspicious session, enter the following CLI command:
These are rough notes on my study of Palo Alto Firewalls, expect bad writing!
Describing what happens at each of the seven stages in the cyber-attack lifecycle
Stage 1: Reconnassisance
Attackers research, identify and select targets. This can carried out via typical phishing tatics or mining data from LinkedIn profiles or coprorate websites. Scanning the network for vunerable services or applications that the attacker is another form of reconnassisance.
The methods of reconnassise can be divided into two catogaries, passive and active.
Passive methods search for available information without interacting with the target network, or at least in a way that would not be deemed suspicious.
One passive method would be social engineering. An example could be searching a target user on a popular social network site such as LinkedIn, learning about their hobbies to try improve the success rate of a phishing attack.
Active methods involve actively interacting with a target network to determine information about it. An active method is likely to raise suspiciouson if the attacker is picked up on.
A number of examples of active methods are include:
Host Sweeps – Ping ranges of IP addresses to gain fingerprint information of devices that respond, or do not respond.
DNS Lookups – Discover IP addresses of and public services of a company by looking up DNS records assicioated with that company. This stage could be followed up with a host sweep or port scans.
Palo Alto firewalls have several features to defend against, preventing, or mitigating active reconnaissance.
Network Segementation into zones
Zone Protection Profiles
External Dynamic List (EDL)
Security Policy Rules
Stage 2: Weaponisation
The attackers choose their method of attack, and develop the malware used to initiate that attack. The network/security administrator can’t act on this stage since the activity happens outside of the realm of the organisations network
The malware is designed to exploit a software vulnerability discovered duringt he reconnaissance stage, this can exist in an operating system, network service, or application.
Stage 3: Delivery
Malware is delivered at this stage and designed to exploit existing software vulnerabilities. The attacker may choose embed malicious code in what appears to be legitimate PDF or Word files. An alternative method might be that the attacker will try the victim into accessing a malicious website to deliver the malware payload.
Stage 4: Exploitation
Once the malware has been delivered, it’ll run the attack code that exploits the vulnerabilities on the victoms devices. The code is designed to gain enough access priveileges on the victims device to open an entry point to download and install more sophisticated and damaging malware at the next stage of the attack.
A Palo Alto firewall can prevent the delivery of detected malware that passes through it’s network stack.
If a user brings the malware into company, say on a laptop or usb infected device that does not pass through a firewall, the detection and block method is likely left to any endpoint protection (a locally installed anti-virus)
Stage 5: Installation
The attacker has now gained sufficient privilages from the initial malware delivery. Now downloading further code to gain full and access and control to the device and it’s files it no longer needs to rely on the existing operating system, applications, commands and executables. Providing the attacker with a broad range of powers to modify the behaviors of the compromised device
To establish a consistent method of access, the malware often installs a backdoor to allow the attacker to access the device even if passwords are changed or services are disabled. The back-door is likely created through the use of a kernel, firmware-based rootkit or remote administration tool.
In order to block an attacker at this stage, firewall protections can be configured that can block access to the attackers installation server, or block file downloads from the installation server. An example could be to only permit known application traffic, or controling access to only known and permitted categories of websites. File Blocking Profiles or WildFire profiles can also help block the attacker. An extra layer to assist with these technologies would be the use of decryption and inspection of encrypted web traffic (https).
Stage 6: Command and Control
With the full malware package now installed, attackers will often establish a communication channel back through the internet to a central command and control server, allowing easy future access for the attacker to remotely control the computer. The channel often uses a DNS domain name to resolve the IP address of the control host. The use of DNS allows the attacker to easily move from one IP address to another, so they can avoid an IP block list.
The communcation channel (C2 channel) can be used to update the malware with new functionality as the attackers objectives change, or give the attacker control of the compromised host to change the appearance of the malware.
Changes to the functionality, and appearance can modify the malwares signature so that antivirus scanners are not able to detect the malware from it’s their known signature list.
Similar to the installation stage, Palo Alto firewalls can help prevent giving an attacker access by only permitting known application traffic, preventing access to unknown websites and domains along with blocking access using external dynamic lists. Decryption and inspection of encrypted traffic can aid other firewall technologies in accomplishing this goal
Stage 7: Act on the Objective
Attackers may have different motivations for the attack they carry out – not always being for monetary profity. The reasons could include exfiltrating data, destroying infrastructue, defacing web property, creating fear, extortion, or a polictical or social statement. The infected device might not be the target of the object, but rather a point of attack to the intended target.
The firewall can provide a number of features to obstruct an attackers objective, an example being File Blocking or Data Filtering profiles could block and prevent data exfiltration
Describe the characteristics of commodity threats, advanced persistent threads (APTs), and denial-of-serivce (DoS) threats
Most threats seen today are commodity threats, being opportunistic or targeted.
Some risks are benign such as Adware, and others being serious such as ransomware or rootkit.
Advanced Persistant Threats are seen as the most dangerous type of threat due to the undected, long-term access to sensitive data.
The danger is the result of the poissible damage caused by undetected long term access to sensitive data.
Considered advanced due to likely being perpetrated by highly motivated and well funded attackers.
Attackers use sophisticated knowledge and techniques to gain unauthorised access to monitor, steal, corrupt or delete data.
An advanced persistant threat can utilise commodity threats as part of their attack
The persistance comes from the attacker extering a continious effort to gain unauthorised access, using a varierty of techniques to disguise their activity.
The techniques of hiding activity can come in the form of a firmware-based rootkit or remote adminstration tool. These two techniques are an example of allowing the atrtacker to hide their command and control (C2) communications.
Since the attacker can hide their command and control commuincations, this enables the attacker to modify their malware to avoid detection and change the purpose of the malware to suit their objectives.
An advanced persistant threat can be difficult to defend against since it may use multiple attack vectors to compromise and maintain communication with an infected device
The attacker may use various types of malware (rootkits, remote administation tools, worms, trojans), various social engineering attacks (phishing campaigns, watering holes) or various attack methods (man in the middle attacks, denial of service attacks)
Attacks are often begun by compromising a trusted business parter of the actual target and then using the business partners network access to attack the target.
A denial of service attack is an attempt to disrupt access to data and network services by overloading the network or a server with unnecessary traffic.
Motivations for such an attack may include political or social activsm, for a hacker group to gain notoriety or disrupt a competitor.
Palo Alto firewalls contain a couple of features to defend against denial of service attacks, zone protection profiles provide broad based comprehensive denial of service protection to protect an enterprise from volumetric denial of service attacks. Acting as a first line of defence for the network. Another feature is Denial of Service Protection policy and Denial of Service Protection Profiles. These provide flexible rules and matching criteria to help protect destination zones or specific end hosts. The protection policy or profile is suited to protecting servers that are critical or historicaly prone to denial of service attacks
List examples of firewall threat preventions available at each of the six stages in the firewall packet flow
Sessions and Flows
The firewall inspects data payloads as part of a session, each session as a unique session ID number. Each Palo Alto Firewall model and each of it’s virtual systems has a supported maximum number of sessions.
The maximum number of sessions is reported on the web interface dashboard, along with the number of sessions currently active.
The endpont that initiates the connection is the client, and the endpoint that responds is the server.
A Client to Server rule, must be specifically enabled using a security policy rule.
Return Server to Client traffic is automatically permited, and does not need to be considered for sueciry policys.
A flow is idenitified by using a combination of source and destination IP address, ports, and the protocol in use.
Each flow is assigned a unique flow key, and each flow key is assigned a session ID number
Stages of Packet Flow:
Packet Based Inspection
Stage 1: Ingress
Detects and drops packets with errors
Detects and blocks pression packet-based attacks
Stage 2: Slowpath
Establishes new sessions
Checks FW session limits
Performs session-based DoS protection
Checks and applies Security policy rules
Stage 3: Fastpath
Performs NAT and decryption
Performs session-based DoS protection
Checks and applies Security policy rules
Stage 4: App Identifcation
Checks and applies Security policy rules
Stage 5: Content Inspection
Performs threat inspection and takes action prescribed in Security Profiles