Category: EDU-114 Study

Objectives:

Describe authentication and authorization methods supported by the firewall

Configure user accounts for firewall administrators and end users

Define multi-factor authentication implementation methods

Configure the firewall to connect to an MFA server

Configure anti-phishing and user credential submission protections

Summarize the three methods used to break the credential threat attack life cycle

User Authentication

Users connecting to firewall services / connecting to the firewall

Users are required to be authenticated when:

• HTTP/HTTPS access to the mangement interface
• HTTP/HTTPS access to the XML API
• SSH/Telnet to the Command Line Interface
• Serial connection to the Console interface

Users can be required to authenticate when connecting through the firewall for applications such as:

• Accessing a website
• Accessing web mail
• Accessing share point
• Accessing Office 365

Supported Autentication Methods

The Palo Alto software can support three types of authentication services: local, external, and multi-factor authentication.

Local authentication without a database (XML configuration) can be used for stored accounts to authenticate logins to the firewall.

With no database however the firewall cannot authenticate traffic flowing through the firewall.

Local with a database can be used to authenticate logins to the firewall, and for user traffic flowing through the firewall.

The firewall can use all external services to authenticate logins to the firewall, and user traffic flowing through the firewall, these are:

• Kerberos
• LDAP
• RADIUS
• TACACS+
• SAML

Palo Alto software also supports four multi factor authentication venders.

• Duo V2
• Okta Adaptive
• PingID
• RSA SecurID Access

The authentication services above all require an authentication profile. The authentication profile is used to link a set of users to a specific authentication service.

Only the authentication services that use an authentication profile can authenticate user traffic flowing through the firewall.

Configuring Authentication TO the firewall

Dependant on the configuration of the authentication profile for the user, will determine how users are authenticated to the firewall.

Each user can be configured with their own Authentication Profile that points to an authentication service.

Or alternatively all users can be configured to use the same authentication profile and authentication service.

To configure per-user authentication to the firewall, assign an authentication profile to a user account when they are added to the firewall.

To configure an authentication profile for all users on the firewall, assign an authentication profile to the authentication settings of the firewall under Device -> Setup -> Management -> Authentication Settings.

The all users authentication only supports RADIUS, TACACS+, and SAML

SAML can only authenticate users using web based services.

Configuring Authentication THROUGH The Firewall

The firewall can be configured to authenticate user credentials when users attempt to access network resources through the firewall.

Individual authentication profiles should not be assigned to the individual user or the firewalls authentication settings in this mode

Rather, an authentication profile to an authentication policy via an authentication enforcement object should be created.

An example is that a web form could be presented, that asks the user to fill out a username and password before they can gain access to a resource. The form can authenticate against an LDAP service to determine whether user should get access.

Admin Role Profiles

Admin role profiles control authorisation to manage the firewall.

Dynamic Admin Roles are a built in set of permissions, stating what a user can or cannot do on a firewall using the web interface, CLI, or XML API.

A role based admin roles are a custom set of permissions, that can control users activities on a firewall when the Web, CLI, or XML API permissions are in use.

User Authentication TO and THROUGH the Firewall

A source user I.D. can be set to authenticate users accessing network resources through the firewall on the security policy, if user authentication of traffic flowing through the network has been configured.

Adding a Local, Non-Database Firewall Administrator Account

Step 1 – Create a custom Admin Role if required

Browse to Device -> Admin Roles to create a custom Admin Role Profile.

Although they are predefined role based admin roles on the firewall already, they cannot be modified. Custom addtional roles can be created though to fit around the needs of the administrator

Predefined Roles:

• Audit Administrator – Responsible for the regular review of the firewall audit data
• Cryptographic Administrator – Responsble for the configuration and maintenance of the cryptographic elements related to the establishment of secure connections into the firewall
• Security Administrator – Responsible for the administrator tasks that to not fit into the two other roles of the administrators

Step 2 – Create a local, non-database administrator account

Administrators can be created by browsing to Device -> Administrators

Adding a Local Database User as a Firewall Administrator

Step 1 – Create a user in the local user database

Go to Device, Local User Database, Users, and click Add

Step 2 – Create an authentication profile that links to the local user database

An authentication profile links a username in the authentication service that the firewall must use to authenticate login credentials of a user.

Go to Device, Authentication Profile, and click Add. Select the type ‘Local Database’

Note the selection of type ‘None’ could allowed undesired users to log into the firewall

In advanced settings, the Allow List can permit only certain users to be authenticate by a profile.

The account lockout option can be set from 0 – 10 attempts, to prevent brute force attacks. The default is 0

A lockout time can also be set to specify how long a user is locked out of the firewall for after the failed attempts value has been reached. The range is from 0 – 60. 0 means the account is not unlocked automatically and creates additional work for administrators

Step 3 – Create a custom Admin Role Profile if required

Step 4 – Create an administrator account from a user in the local user database

Go to Device, Administrators, enter the name of the username previously created and select the Authentication Profile as created in Step 2.

Adding an External User as a Firewall Administrator

Step 1 – Create a server profile for the external authentication service

To create a service profile, for example LDAP, go to Device -> Server Profiles -> LDAP -> Add

Step 2 – Create an authentication profile that links to the Server Profile

An authentication profile links the username to the authentication service that the firewall uses to authentication the users login credentials.

The firewall uses an authentication profile to verify user credentials when a user attempts to login to the firewall

The profile is also used when the firewall is attempting to verify user credentials when a user is trying to access a network resource through the firewall.

To add a profile, go to Device -> Authentication Profile -> Add

Step 3 – Create a custom Admin Role Profile if required

Go to Device -> Admin Roles -> Add

An externally authenticated user logging in must be given permissions via an assigned admin role

Externally authenticated users can be given a predefined Dynamic Admin Role Profile, or a custom Role Based Admin Role Profile

Step 4 – Create an Administrator account that links to the Authentication Profile and the Admin Role profile

Go to Device -> Administrators -> Add

The username must match that of what is on the external service.

Adding an administrator that is authenticated by a certificate

Step 1. Create the users certificate

Palo Alto Firewalls support interactive and non-interactive authentication

The certificate based authentication, non-interactive, is only available via web browser

If the certificate of the issuing CA is not added to the clients browser, a warning message is generated by the clients browser when attempting to connect

Note, configuration of certificate based authentication for any administrator automatically disables the username and password logins for all administrators on that firewall

Step 2. Create the firewalls certificate profile

Device -> Certificate Mangement -> Certificate Profile -> Add

Add a CA certificate here for the firewall to verify a users certificate.

CRL and OSCP can be used here to check for certificate revocation status

Step 3. Create a custom Admin role if needed

See previous notes

Step 4. Configure the firewall to peform certificate-based authentication

and

Step 5. Create a certificate authenticated administrator account

Under Device -> Setup Management -> Authentication , select the Certificate Profile created earlier

Enabling SSH Key-Based Command Line Firewall Access

Key based command line access provides cryptographic strength over passwords, with passwords not needing to be sent over the network and reducing the risk of brute force attacks. It also options the possibility for two factor authentcation.

Key based SSH logins permits automated scripts access to the CLI too.

This can be configured in Device -> Administrators, ticking the box for ‘Use Public Key Authentication (SSH)’

A public key an imported in the field below the checkbox

Preventing use of stolen credentials by using multi factor authentication

The Palo Alto can be used to detect credential leakage when the firewall is configured to use User-ID. If User-ID detects valid corporate credentials being entered, the Palo Alto can consult the URL filtering to see if the category of the website that is being entered with credentials is valid for having corporate credentials being entered into. If it is meant to be prevented from entering credentials, the firewall will block the attempt to enter corporate credentials.

Block is not the only option that can be configured here, the firewall can be permitted to allow credential submission or set to warns the user against submitting the credentials.

The pages can be customised further, in a way that a pop-up could appear to discourage users from reusing their corporate passwords on other legitimate websites

Steps for Configuring Phishing Protection

Step 1 – Configure User-ID on internal-zones

One Example: See Device -> Server -> Profiles -> LDAP

Device -> User Identification -> Group Mapping Setting

Used to determine user are members of which groups

Second Example: See Device -> User Identification -> User Mapping

User-ID agents monitor devices for login and logout events

Firewall-integrated and Windows-based User IDs agents are available

Firewall-integrated configuration is done in this example, in the username field a user that has permission to view event logs on the event viewer should be entered in the configuration

User-ID also needs to know what type of server it is monitoring, this can be set in Devices -> User Identification -> User Mapping -> Server Monitoring -> Add

Step 2 – Configure a URL filtering Profile to block access to known phishing sites

Objects -> Security Profiles -> URL Filtering

Custom anti-phishing response pages can be set by going to Device -> Response Pages and viewing the Anti Phishing Block Page or Anti Phishing Continue Page

Step 3 – Configure a URL filtering profile to control user credential submission

Objects -> Security Profiles -> URL Filtering -> ADD

Weakest matches to strongest matches:

Use Group Mapping:

Detects corporate usernames by comparing to usernames in LDAP User Group

Uses IP User Mapping

Detects corporate usernames by comparing to User-ID IP-to-Username mapping table

Use Domain Credential Filter

Detects corporate usernames and passwords using bloom filters to match credentials

Default Log Severity on a match is set to medium

Step 4 – Add a URL filtering Profile to Security Policy rules

Objectives:

Block known malware attacks by configuring Security Profiles according to best practices

Detect unknown malware attacks by configuring WildFire according to best practices

Overview of Inspecting Allowed Traffic

When network traffic passes between zones on the firewall, it matches against rules on the security policy.

Even if the security policy gets a match and permits traffic, the security profile attached to the rule can allow further inspection of packets passing through the firewall to occur

The security profile can check for threats like:

• Viruses
• Spyware
• Expoits
• Malicious URLs
• Malicious files
• Sensitive data
• Zero-day malware

If a match is found in the security file, it can carry out various actions like allow, block, ask the user for permission to continue, or log the violation.

The security profile allows a network administrator have more granular control over allowed traffic

Security profiles can detect known and unknown threats

Known threats, updated with regular update downloads, can pick up on new and old malicious traffic. The security profiles designed for detecting known threats are:

• Antivirus
  • Using signature matches
  • Updated daily
• Antispyware
  • Using signature matches
  • Custom signatures can be created
• Vulnerability Protectioin
  • Using signature matches
  • Custom signatures can be created
• URL Filtering
  • Using pattern matches
• Data Filtering
  • Using pattern matches
• File Blocking
  • Using file type and transfer detection

The Palo Alto firewall also has a platform for picking up on unknown threats, WildFire Analysis

WildFire analyses files and URLs in a virtual sandbox enviroment. Wildfire creates new signatures for newly discovered threats, distrubuting them to firewalls worldwide

Day One Security Profile Methodology

The Day One Security Profile is best practice security profile configuration for blocking threat and minimising application downtime between outbound, inbound, and internal zones.

The security profile allows the administrator to build three sets of custom security profiles, one for inbound, one for outbound, and one between internal zones.

If an administrator is concerned that false positives will be blocked, the administrator can configure them to report security profile violations, but do not block them.

Blocking Signature Detected Threats

The Palo Alto firewall uses signatures to detect and block known viruses, spyware, and software exploits.

Updates to these signatures are distributed frequently to firewalls with Palo Alto content updates. Wildfire also frequently distributes updates.

If new spyware is encountered that Palo Alto does not have a signature for, the network administrator can craft their own custom signatures to block threats.

Viewing Information

To view blocked or alerted threat information, click on the Threat Log in the monitor tab.

The ID column in this log can be useful for creating exceptions in the profile rules, if a false positive occurs.

Overview of URL Access

The PAN-DB URL filtering database is maintained by Palo Alto Networks, which groups websites into categories.

A firewall with a valid URL filtering licence can control user access to websites

URL Filtering profiles should be attached to all security policy rules that allow traffic in a zero-trust configuration

Filtering information can be viewed in the URL filtering monitor tab. Note the continue is a prompt sent to the user confirming they wish to continue to visit a webapge, the override action is a result of the user confirming they want to still visit that webpage

Blocking Unauthorised File Transfers

The Palo Alto supports the blocking of unauthorised file transfers via with a link in a E-mail attachment, webpage, or instant mesage containing a FTP, Google Drive, Dropbox or similar URL.

The file blocking profile detects the file type using the filename extension and the content inside the file. Once determined the profile will block or allow the file transfer

Viewing Blocked Files

The data filtering log displays a list of files blocked by the File Blocking Profiles. The firewall records the filename and file type along with other information.

The firewall security policy rules and file blocking profiles should be adjusted accordingly with the information presented in these logs.

Detecting unknown threats

WildFire is the Palo Alto profile that is primarly in use for detecting new or unknown threats. WildFire requires a WildFire subscription to be used.

A cloud based sandbox enviroment, WildFire analyses unknown files and URLs within e-mail links that the Palo Alto discovers. The sandbox determines whether the samples are benign, grayware, phishing or malicious.

If the WildFire cloudbox discovers malware, it generates a signature from the sample file and distributes the signature to all firewalls within minutes (that have an active subscription). These quick updates allow firewalls to have an edge over malicious applications with quick detection and blocking, all potentionally discovered from one other single firewall!

Basic WildFire support is included with a Threat Prevention licence. To get the full features of WildFire a valid WildFire licence is required. If a WildFire licence is not present, Palo Alto firewalls without a licence will get the licence definitions on the next Antivirus Content Update.

If WildFire forwarding is eanbvled, the firewall forwards files that were blocked by antivirus signatures. Signatures can often match multiple variants of the same malware application, and can block new variants of the virus application that have not been seen before. The forwarded file can be used by the Palo Alto research team to further protect firewalls with new additions to IP address, URL and domain blocklists.

The WildFire Profile

The WildFire profile performs additional checks on allowed network traffic. As is the same with other security profile rules, WildFire Analysis applies to all packets over the life of a session.

The recommended practice is to forward all files and links to WildFire for analysis.

Configuring WildFire Forwarding

To configure wildfire forwarding, go to the Device Tab, then the WildFire tab underneath that.

Viewing WildFire Logs

WildFire logs can be viewed in the Monitor, WildFire submissions tab.

Blocking Sensitive Data Transfers

The data filtering profile can prevent sensitive information from leaving a protected network.

A data filtering profile attached to all security policy rules allow scans for data patterns to occur

Three types of data patterns can be scanned for, Predefined Patterns (Credit Card Numbers, Social Security Numbers), Regular Expressions (Regex), and File properties (Property=Value). They are 22 predefined patterns in PAN-OS 2.0

The property=value object type can be tied into a third party data loss prevention product

Data Filtering Log

The Data Filtering Log (under the Monitor tab) allows the administrator to determine if there has been any succesful or blocked transfers of data. Information can also be viewed if there was any hosts or systems involved in the transfer of data. Packet captures can also be viewed to see which sensitive data was transferred but a password needs to be set in order to protect this data.

Protecting Access to the Data Filter

A password must be set on the Data Filtering Log if packet captures are enabled. This is to prevent easy access to sensitive data.

HTTP ‘Accept-Ranges’ Option

The HTTP Accept-Ranges option allows a web client to resume a stopped data transfer, by requesting a resend of the missing data.

Palo Alto recommends that this is disabled, so that if a sensitive data transfer is stopped it can not be resumed

Security Policy Modifications

Rule Tags and Descriptions

Rules can be tagged and assigned on security policies to allow for easy identification, a description can also be entered on a security rule to help any other network administrators learn how a security policy is used

Rule Tags and descriptions can be forced on rules on the Policy Rulebase Settings, a tag, description, or audit comment can be forced to be present before a commit can be made to the firewall.

Configuring Security Profile Groups

The recommended configuration from Palo Alto is to use the same naming convention as the security profiles: outbound, internal, and inbound.

Security Profile Groups can be attached in the same way to a security rule as a Security Profile.

Optional Initial Configuration

If the administrator is concerned about false positives, they have an option to use a configuration that only sends alerts, but does not block malware.

The alerts can be used as a source of information when it comes to reconfiguring the firewall to better protect networks.

Best Practice Configuration Templates

Iron Skillet can be used with Palo Alto to try get a best practice configuration in place. Iron Skillet is a website repository of firewall and Panorama day one configuration templates according to best practice recommendations.

Day One configurations help keep a network safe by blocking malware, but minimises downtime as a result of too strict configuration. They are safe starting points for most deployments

Configuration settings can be added as more information about specific services and applications are learned in a network enviorment

The Iron Skillet template creates a set of inbound, outbound, internal security profile and security profile groups.

Iron Skillet creates custom reports too as well as log and log forwarding settings.

Additional configuration will be required to best suit your network, including but not limited too additional interface addresses, zones, and routing.

How good is your configuration?

A tool is present for Palo Alto to analyse firewall, and panorama configurations. These are compared against Palo Altos best configuation practices. The tool returns a set of recommendations on how to improve the network security

The best practice security tool can be accessed on the Customer Support Portal.

Module objectives:

Create and manage certificates using the web interface

Configure certification revocation checking on the firewall

Configure SSL/TLS decryption on the firewall

Describe the effects of key pinning on firewall Decryption policy

Configure SSH decryption on the firewall

Manage the master key

The importantance of SSL/TLS

Secure Socket Layer / Transport Layer Security secures network communications end to end across a shared network platform. It offers many advantages such as encryption for data privacy, hashes for data integrity, and certificates for authentication.

The Palo Alto next generation firewall offers SSL/TLS decryption to help prevent malware introduction through encrypted channels, and data exfiltration out of the company out encrypted channels.

A quick recap on SSL/TLS operation

An SSL session is established between a client and server as the following:

1. Client requests an SSL connection to the server
2. The SSL server sends the client it’s server certificate
3. The client verifies this SSL certificate against it’s own trusted store of root certificates
4. The client sends an encrypted session key to the SSL server
5. The server uses it’s own private key to decrypt this session key
6. The server and client then begin encrypted private communications between each other using the confidential session key

Palo Alto Certicate Management

The Palo Alto firewall supports two different types of SSL certificate, certificate authority signed certificates and self-signed certificates.

The preferred method for configuration is a CA-signed certificate, which simplifies SSL configuration.

The administrator has a number of options in obtaining a CA-signed certificate

1. Buy a CA-signed certificate and public-private key pair from a public CA
   1. Disadvantage is cost
   2. Limitation in that public CA’s do not sell signing certificates, required for SSL Forward Proxy description
2. Get a CA-signed certificate and public-private key pair from an internal CA
   1. Advantage is usually free
   2. Can be a signing certificate to be used with SSL Forward Proxy decryption
3. Create the certificate and public-private key pair on the CA server
   1. Create a certificate and public-private keys
   2. Import certificate and public-private keys onto the firewall
   3. Disadvantage: A small risk that hte private key transferred over the network would be stolen

On the last point there with the risk of a key being stolen, there is a workaround:

1. Generate a CSR and public-private keys, export the CSR file
2. Sign and return the certificate in a file
3. Import the CA signed certificate from the file

For self signed certificates, a couple of advantages is that they are free and can be obtained in minutes. The self signed certificate can also be used with SSL Forward Proxt decryption. The primary disadvantage is that this self signed certificate would not be trusted by other devices in the organisation.

The administrator could export and install the self signed certificate to the trusted root certificate store on other devices in order for the self signed certificate to be trusted as a work around.

Certificate Creation and Management

Certificate Checking and Revocation

One: Determine chain of trust

Two: Validate each certificate in the chain

Steps to check:

1. Is the certificate signature valid?
2. Is the date range presented by the certificate valid?
3. Is the certificate signature malformed or corrupt?

Three: Check revocation status of each certificate

Compare against the online certificate status protocol (OCSP) first, then the certificate revocation list (CRL)

These lists will return four different statuses:

• Current: valid
• Expired: Cannot trust identity
• Unknown: Cannot establish validity
• Unavailable: OSCP/CRL can’t be contacted

Why would a certificate get revoked?

• The private key has been compromised
• Hostname or username of owner changed
• Host decommissioned, e.g. user left the organisation
• Couterfeit key found

Configuring SSL Decryption Certificate Revocation Checking

The Palo Alto firewall can be configured to verify the revocation status of certificates used for decryption.

This can be set up in Device -> Setup -> Session -> Certificate Revocation Checking

SSL Forward Proxy Review

The firewall uses SSL Forward Proxy to decrypt and inspect SSL traffic when the Palo Alto fireewall does not have access to the SSL servers private key.

The firewall and the SSL server must share a common CA for the firewall to validate the servers identity.

At the other end of the communcation, the SSL client and the firewall must have access to a common certificate authority for the client to validate the firewalls identity.

The SSL session tries to establish a session with the server with a SSL handshake. The Palo Alto firewall intercepts this handset and issues its own handshake between the firewall and the server. The SSL Server responds with a common CA to allow the firewall to validate the servers identity

The firewall copies this servers certificate and signs it with its own forward trust certificate and public key.

A forward trust certificate indicates to the SSL client that hte firewall has verified and trusts the servers certificate. The firewall forwards the newly copied and signed server certificate to the client

The client uses the firewalls forward trust certificate to validate the firewalls identity, using a CA common to both the client and firewall.

The client has now established a secure connection, and the firewall acts a proxy between the client and the server. The firewall can decrypt traffic and inspect it flowing between the client and the server.

If for any reason the server can not verify the servers certificate, it signs the servers certificate with a forward untrust certificate that indicates to the client the SSLs server certificate could not be verified

Configuring a Forward Trust Certificate

Configuring SSL Forward Proxy

Under Objects:

Under Policy Rules:

Configuring SSL Inbound Inspection

This traffic flows originate outside to inside

Note: You load the SSL certificate for the SSL server to the Palo Alto, and use that to decrypt/inspect traffic

So a private key and cert will need to be imported into the server

Identifiying Decrypted Network Sessions

Within monitor -> logs -> traffic, check the column header ‘Decrypted’ for yes or no

With the CLI command:

show session all filter ssl-decrypt yes

Check for the flag *

Decryption Exclusions

Websites with known decryption problems are pre-popualted on this Palo Alto created list.

The exclusion list is updated via content updates, and can also have websites added to it

No Decryption

Even if a website action is set to “no-decrypt”, the decryption profile can still be configured to block sessions with expired or untrusted certificates

Opting out of SSL Decryption

Device -> Response Pages

SSL Decryption Policy Considerations

Key Pinning can affect SSL decryption configuration, it’s purpose is to prevent use of counterfeit man-in-the-middle certificates. There are two types of key pinning, static key pinning and Dynamic Key Pinning (HTTP Public Key Pinning, HPKP)

Static Server Certificate Pinning

The software devceloper writes the code for the SSL server and client. The developer also configures both ends of the client and server to recognise the servers certificate.

The SSL decryption fails here as the client is preconfigured to accept a certain certificate. The firewall re-writes the certificate so the client will fail to validate the certificate presented to it via the firewall.

The same can happen with a certificate authority, where the software developer notes what certificate authority signed the certificate. As the certificate authority will also be different this can cause the client validation to fail.

Dynamic Key Pinning

Dynamic key pinning relies on a HTTP protocol extension called HPKP. A list of acceptable CA certificates and public keys is sent from the SSL server to the client the first time that the client connects to that SSL server.

The acceptable CA certificate information is sent in a HTTP resposne header named Public-Key-Pins. The client must establish at least one HTTPS connection to the server to recieve this list of acceptable CA certificates and public keys

This type of SSL Forward Proxy decryption can fail as the firewall can not perform the decryption unless it modifies the CA signature on the server certificate. The modified signature may not match the list of acceptable server cetificates unless the client is also configured to accept the certifcate and public key of the firewall as an acceptable CA certificate.

Reasons not to configure SSL Decryption

• Prohibited by law or a company policy
• Server requires a client certificate (Forward Proxy)
• New CA can not be added to a client
• Client software requires specific server certificates
• Non-standard SSL implementation in use

SSH Decryption

The Palo Alto firewall can decrypt and inspect SSHv2 traffic, to detect SSH-tunneled applications.

The decryption is unsupported with SSH key passwordless logins.

The Palo Alto firewall uses an automatically generated key to decrypt or encrypt traffic.

The traffic is identified as ethier ssh or ssh-tunnel on the firewall. The traffic can be controlled using Security Policy rules.

Firewall Master Key

The firewall master key is used to encrypt passwords and private keys.

It is good practice to periodically change the master key.

The master key must be the same in a HA pair

Managing the Master Key

All changes must be committed before changing the master key, the master key change does not require a commit after the key has been changed.

An expiration warning is good practice to set to avoid being locked out, an auto-renew can be set as a lockout safeguard to protect against accidental lock-out.

If the master key has expired, firewall access is only available through the console to perform a factory reset.

Objectives:

Create custom software vulnerability and spyware signatures

Create standard and combination threat signatures

Types of signatures:

• Defined by Palo Alto:
  • Vulnerability Signatures
  • Anti-Spyware Signatures
• Are updated frequently (each week) via Applications and Threats content updates
• Custom defined:
  • Vulnerability Signatures
  • Anti-Spyware Signatures
• Are updated by the administrator as required

Creating Custom Threat Signatures:

Browse to Objects -> Custom Objects, select Spyware to create custom spyware signatures or select Vulnerability to create custom vulnerability signatures.

The creation for both of these signatures is a similar process

Standard Verus Combination Threat Signatures

A standard signature looks for a single match condition out of one or more defined, once detected it will trigger the threat action.

A combination signature looks for one or more standard match conditions within a time element. This is only created when the administrator wishes the firewall to take action only when one or more threat signatures are detected within a certain time period

An example of a good combination signature is detecting brute force attacks, when a password is submitted to an application in quick succession.

• Use logs to discover unknown traffic
• List methods to control unknown traffic
• Perform a packet capture using the web interface
• 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:

• Ingress Interface
• Source IP address
• Destination IP address
• Source Port number
• Destination Port number
• Protocol Number
• Non-IP
• IPv6

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.

Objects:

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:

• web-browsing
• SMTP
• FTP
• LDAP
• IMAP

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.

The Palo Alto firewall can block connections from known bad sources. This can be useful for blocking the Delivery or Command and Control stage of a cyber attack lifecycle

Use IP addresses and Address objects in a Security Policy to block traffic

Configure the firewall to use external, third-party IP address lists to block traffic

Configure Anti-Spyware Profiles to block access to malicious domains

Configure Security policy and URL Filtering Profiles to block access to URL categories

Blocking a known bad IP address can be added in the Security Policy Address field.

Blocking a Destination IP address can block connections to a malicious IP address

Blocking a Source IP address can block connections from a malicious IP address

IP addresses can also be created as Objects under Objections -> Addresses. Other type of addressed objects can be an IP Netmask, IP Range, IP Wildcard Mask, or a FQDN.

IP addresses and objects can be grouped under a static address group.

A Dynamic Address group varies from a static address group that tagged IP addresses are automatically added to the group without a commit.

Objects or IP addresses can be tagged by External Software or by Firewall auto-tagging.

The IP addresses in both types of groups can be used in security policies as a match condition for rules.

External Malicious IP Lists can also be used on all firewall models, up to 30 individual lists can be used. Though the maximum numer of IP addresses in total can vary per firewall hardware model.

The maximum amount can be seen if the administrator navigiates to Objects -> External Dynamic Lists and clicking List Capacities.

Some example lists can be found at http://panwdbl.appspot.com

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:
  • allow
  • alert
  • continue
  • override
  • block?

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!

Objectives:

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
• SYN Cookies
  • 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
• Source User
• Destination zone or interface
• Destination IP address
• Service

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:

• PA-3050
• PA-3060
• PA-3200 Series
• PA-5000 Series
• PA-5200 Series
• PA-7000 Series

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:

request session-discard id <session_number>

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
    • Recieves Packets
    • Detects and drops packets with errors
    • Detects and blocks pression packet-based attacks
• Session-Based Inspection
  • 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
    • Identifies applications
    • Checks and applies Security policy rules
  • Stage 5: Content Inspection
    • Performs threat inspection and takes action prescribed in Security Profiles
    • Re-encrypts decrypted traffic
• Packet-Based Forwarding
  • Stage 6: Egress
    • Implements Quality of Service Policy
    • Forwads the packet to the next destination