WirelessPhreak.com

I like to travel, f*ck with technology, and partake in the occasional tropical drink.
I am also a co-host on The NBD Show podcast.
Follow Me
Showing posts with label Palo Alto Networks. Show all posts
Showing posts with label Palo Alto Networks. Show all posts

 


There is a new flavor of protocol reflection attacks on the streets!  

The TCP Middlebox reflection attack is the first reflection attack to utilize the TCP protocol. Traditionally the TCP protocol was not susceptible to spoofed source packets because of its state based nature (three way handshake).  Researchers at University of Maryland and the University of Colorado discovered that many network devices, such as load balancers, proxies, and firewalls, could be susceptible to specifically-crafted packets that could generate amplified traffic (up to 65x) at a victim.  These devices could be inherently susceptible to the spoofing because many of these devices have to contend with Asynchronous network traffic and out of order packets.

 

Akamai did a really great write up on what they saw and how they mitigated the attack. https://www.akamai.com/blog/security/tcp-middlebox-reflection

 

Shadow Server also has a write up. https://www.shadowserver.org/news/over-18-8-million-ips-vulnerable-to-middlebox-tcp-reflection-ddos-attacks/


So on to your firewalls:

The out of the box Palo Alto Firewalls do not appear to have any mitigation configured by default to protect against this attack.  But its not the end of the world.  Palo Alto and many other security vendors have low level TCP protection that basically normalizes TCP traffic and cuts out the flood attacks, malformed protocol attacks, etc., before they are even processed by your firewall. This minimizes  impact on the device resources like CPU and memory for these types of attacks.

 

In the Palo Alto world this is called "Zone Protection Profiles". If you run BPA (Best Practice Assessment) - which you should - then the Zone Protection Profiles are often flagged if you don't have them configured. 

 

The zone protection profile is pretty strait-forward to set up but, before you start, you need to do a little research and investigation into your device

  1. You need to determine the maximum CPS or connections per second your device can handle. This is a list of devices and their specs on the Palo Alto Networks site. https://www.paloaltonetworks.com/products/product-selection
  2. Next you will want capture some metrics around how many CPS your devices are seeing. https://docs.paloaltonetworks.com/pan-os/9-0/pan-os-admin/zone-protection-and-dos-protection/zone-defense/take-baseline-cps-measurements-for-setting-flood-thresholds/how-to-measure-cps
  3. Next you will want to do a few calculations and configure your zone protection profile. https://docs.paloaltonetworks.com/pan-os/9-0/pan-os-admin/zone-protection-and-dos-protection/zone-defense/zone-protection-profiles

 

Here is the "Cool SH*T Props" to Palo Alto Networks...when you create a zone protection profile, by default under the Packet Based Protection > and > 'TCP Drop the TCP SYN with Data' and 'TCP SYN ACK with Data' are already checked. This means when you apply your newly configured zone protection profile to your security zone it will protect you from current Middlebox vulnerability by dropping any of the cleverly crafted SYN packets because they would be larger then 0 bytes.

 


Yeah!


So I wanted to post a little bonus. Here is a quick and easy flood protection calculator I threw together in google sheets, just add your average CPS.








 

Enhanced Data Visualization Dashboard using Splunk

 

I am a fan of Palo Alto Networks NGFW, especially the visibility it can give you in to your traffic. PAN does a pretty good job within their management tools of organizing and reporting on the data, but most of us also have large SIEMs or Logging solutions like Elastic's ELK stack. Splunk, exabeam, etc.

Splunk being one of the more popular SIEM and logging solutions, I created a PAN Threat Dashboard I wanted to share. If you have Splunk running in your environment and the Splunk Palo Alto Networks add-on installed all the pre-defined fields should work correctly. If not, you may need to tweak 1 or 2 fields in the dashboard to make it work. When you copy the code from my GitHub save it in a text editor and perform the following steps.  It should be up and running in your environment in no time.

 
You will need to identify your Palo Alto firewall host= fields (how Splunk identifies the device sending logs) to populate the field2 drop down menus.
 

Directions:

  1. Log into Splunk and go to Search
  2. Click on Dashboards and Create a new Dashboard
  3. Once you have created your new dashboard go to edit and select source tab on the top
  4. Clear out the default text in the dashboard and copy and paste the dashboard from GitHub.
  5. Before you save the dashboard you will need to identify your Palo Alto firewall host= fields to populate the field2 drop down menus, I have space holders firewall-1, firewall-2, etc. configured currently

 

You should be good to go!

 

 

Recently there has been a change in the behavior when a user tries to upgrade the GP client, they are challenged with the uninstall password if configured with one. Working with Palo Alto networks TAC they identified that during the upgrade the GP client package will uninstall the old version first before it will begin to install the new package. In GP client 5.2.4 and older the upgrade would complete even if uninstall with a password or disallow was enabled. This was identified as a software issue so in clients 5.2.5 and newer the ability to upgrade the client with uninstall option set to password or disallow was disabled.

In a nutshell with the new GP clients you will need to set the client setting to allow uninstall, if you want to utilize the Global Protect client upgrade process. 


Clients 5.2.4 or older, following is the behavior:

  • If you are using GP version older than 5.2.4, the transparent upgrade should work where the user will have no interaction and they can upgrade even if the allow uninstalled is disallowed.

 

Starting with 5.2.5 or above, following is the behavior:

  • Allow User to Uninstall GlobalProtect App is set to Allow
  • Allow User to Upgrade GlobalProtect App as Allow with Prompt/Manually/Transparently. (In this case, the users will be able to upgrade transparently without any interaction and the passcode/password will not be allowed)

  • Allow User to Uninstall GlobalProtect App is set to Disallow
  • Allow User to Upgrade GlobalProtect App as Allow with Prompt/Manually/Transparently (This will be blocked)

  • Allow User to Uninstall GlobalProtect App is set to "Allow with password"
  • Allow User to Upgrade GlobalProtect App as Allow with Prompt/Manually/Transparently. ( In this case, the users will need to enter the uninstall password to complete the upgrade) 


To allow the users to upgrade without providing them a password, you would need to use following.

  • Allow User to Uninstall GlobalProtect App is set to Allow
  • Allow User to Upgrade GlobalProtect App as Allow with Prompt/Manually/Transparently.”

 

My personal recommendation is to allow the client uninstall so you can leverage the GP client upgrade process. I feel the ability to upgrade the clients to ensure functionality and security is more important than blocking them from uninstalling the client. In addition we have tested with clients that are not Admins on the local machine and they were unable to uninstall the client from the windows software manager. So that is a win...


Perhaps the client upgrade functionality can also be managed with an mdm solution or with a software management tool like SCCM. But it will take some testing to find the best process that works for your environment.




Symptoms

As people become more focused on securing their home network, the idea of a "enterprise" firewall for home use is not out of the ordinary. Of course, this focus has grown over time because of teleworking/job requirements but also because some people realize that securing their home network is just as important as securing their "enterprise" network. Of course for us gamers, this causes an issue. I have be given the benefit to use my own Palo Alto Networks (PAN) PA-220 firewall for home use. While the initial setup didn't cause any issues, I had one major issue which was almost make or break for keeping the PA-220. The issue of course was my Xbox One did not function properly and I could not update games, group chat, or do anything an Xbox One should do.

Issue

When connecting to the Xbox Live service or PlayStation Network the console establishes client connections to the service. When hosting some games, or using some applications, a connection from the Xbox Live service or PlayStation Network inbound to the console is required. If these inbound connections can not be established then the console will report that strict NAT has been detected.

The consoles are compatible with uPnP devices to allow dynamic opening of TCP and UDP ports to forward traffic required for connectivity to the service. uPnP-enabled routers allow port forwarding to be configured on the device dynamically based on requests coming from internal devices. In a uPnP environment, the console will request the appropriate ports be forwarded to allow the traffic.

Palo Alto Networks firewalls are not compatible with uPnP. Requests from a console via uPnP to open ports will be ignored by the firewall. A 1-to-1 static NAT mapping must be created to forward the appropriate ports to the console from the Xbox Live service or PSN.

Resolution

The following is my configuration setup to fix my Xbox One as well as other gaming consoles which need Universal Plug and Play (UPnP).

Quick Tangent: While UPnP is a great idea to make home networking easier, it opens up the inside resources to many potential attacks. At a basic level, UPnP allows devices to discover each other on the same network dynamically so that all devices can communicate with each other for data sharing and entertainment purposes. While this sounds good, the security risk is that UPnP also dynamically adds port forwarding to the home router without human invention. This dynamic port forwarding allows for any and all ports to have access inside the network from the outside Internet without no protection. It is for this reason that any "enterprise" firewall will NEVER support UPnP. Of course, when it comes to gaming and our relaxation time, we don't care about the risks we just want our games to work.

The following configuration assumes that all basic connectivity has already been configured on your PA-220. The following configuration is my current setup and has never had any issues since the day I configured it.

The below is an extremely basic PA-220 configuration but the security policy that I want to highlight is the Outbound-Xbox Rule.

All firewall polices are created under Polices>>Security>>Add

Note: The Outbound-Xbox NAT must be above the general Outbound Internet Rule otherwise the Xbox traffic will never hit the dedicated Xbox NAT rule (this to be created next).

Xbox Security Rule:

I configured my Xbox Security Policy to use the dedicated or reserved ip address, this will be the source address (Creating a DHCP address reservation is not covered in this article)

  • The source is my dedicated Xbox/Gaming reserved address as I only wanted to NAT my Xbox traffic

  • The destination is to my UnTrust Zone or Outside security zone.

  • Application: This is the bread and butter of Palo Alto's Next Generation Firewall

  • The list in the image below are the applications which I have fingerprinted at the time of this article. As applications default ports change and Microsoft adds more application, this field will need to be updated from time to time.
    • Please note: A Layer 4 firewall rule will work but what is the point in having a Ferrari in the garage if you're not going to use it to its potential.

  • Action; of course allow

All other options not covered

The below is an extremely basic PA-220 configuration but the NAT policy that I want to highlight is the Xbox_NAT rule.

All firewall NAT polices are created under Polices>>NAT>>Add

Xbox NAT Rule:

I configured my Xbox NAT Policy to have a dedicated source address (Creating a DHCP address is not covered in this article)
  • The packet source is from the Trust/Inside Network
  • The packet destination is to my UnTrust Zone or Outside
  • The packet destination interface is the interface facing my ISP/Dynamic Client
  • The source is my dedicated Xbox/Gaming reserved address as I only wanted to NAT my Xbox traffic
  • The packet destination and service are set to ANY as we want all traffic from the Xbox to be NAT'd

The FOLLWING IS THE SECRET TO FIXING ALL UPnP ISSUES
  • Translated Packet
  • The source translated packet must be a fixed static-ip address
  • The IP missing below MUST be the IP address given to your home "modem" now firewall by the ISP.
    • NOTE: If the address assigned to your Internet Layer3 link ever changes, this NAT rule MUST be updated. Since having this implemented for over a year, I have never had to change this address as the ISP want to be stable and followings the basic rules of DHCP. My ISP always assigned me the same address when my DHCP reservation renews
  • The last major configuration is to check "bi-drectional: yes".

If the above NAT rule and security policy are configured with the proper information, all UPnP issues with be a problem of the past. I have never had an issue except to add applications to my security policy from time-to-time. I have used this configuration on multiple PA-220s and it works every time without any issues. Without the above rules, some games might work but group chat will always be broken.

For information on how to configure a static 1-to-1 destination NAT policy, or bi-directional NAT mapping please refer to the Understanding PAN-OS NAT document.

Please enjoy and hopefully this will help anyone avoid the headaches and research that I went through along with trail and error. Also, hopefully this configuration will allow everyone, including myself, the ability to keep our games but also make sure we are securing and protecting on valuable resources on the inside of the network. With this configuration, we have the ability to function without any issues as well as protect the network from UPnP vulnerabilities that all gaming systems rely on; especially Xbox/Microsoft.


Two cool new exploits have been released complete with cool names and graphics. Welcome Meltdown and Spectre, these critical vulnerabilities exploit pretty much all modern processors. Even though these hardware vulnerabilities have been around forever, four independent groups of researchers discovered these vulnerabilities simultaneously. Meltdown and Spectre at a high level allow programs to steal data which is currently processed on the computer. While programs are typically not permitted to read data from other programs, a malicious program can exploit Meltdown and Spectre to get hold of secrets stored in the memory of other running programs.

Meltdown and Spectre work on personal computers, mobile devices, and in the cloud. But what about our network and security equipment using modern processors, are they vulnerable? Below is a list I put together of links to vendors sites and their responses to the vulnerabilities. I imagine most of them will keep these pages up to date as they discover new information. This is a complicated and low level issue so most vendors are going to need time to really evaluate their products and create patches.

Luckily in most cases it is an attack that is performed through the management access, so if you follow the best practice of limiting device management access from only trusted IPs or networks you should be good until the patches are released.

 PaloAlto Networks

"Our initial review of the vulnerabilities disclosed in the research concludes that all PAN-OS/Panorama platforms are not directly impacted by these attacks. There are no immediate plans to release a software update to PAN-OS in response to these issues at this time"

F5

"Impact
For products with None in the Versions known to be vulnerable column, there is no impact. For products with ** in the various columns, F5 is still researching the issue and will update this article after confirming the required information. F5 Technical Support has no additional information about this issue.

 BIG-IP
All three vulnerabilities require an attacker capable of providing and running binary code of their choosing on the BIG-IP platform. This raises a high bar for attackers attempting to target BIG-IP systems over a network and would require an additional, un-patched, user-space remote code execution vulnerability to exploit these new issues. The only administrative roles on a BIG-IP system that can execute binary code or exploitable analogs, such as JavaScript, are the Administrator and Resource Administrator roles. These users already have nearly complete access to the system and all secrets on the system not protected by hardware-based encryption. F5 believes that the attack with the highest impact may occur in multi-tenancy Virtual Clustered Multiprocessing (vCMP) configurations, running single-core guests owned by different administrative domains on a single BIG-IP system. In this scenario, Spectre Variant 2 may allow an attacker in one administrative domain to collect privileged information from the host or guests owned by another administrative domain, if the attacker's guest is configured as a single-core guest. The BIG-IP system always maps both hyper-threads of a given core to any guest with the "Cores Per Guest" configuration set to 2 or more, but single-core guests may execute on the same processor core as another single-core guest or host code. This threat may be mitigated by setting the "Cores Per Guest" configuration to 2 or more for all guests."

 Cisco

"Cisco is investigating its product line to determine which products may be affected by these vulnerabilities. As the investigation progresses, Cisco will update this advisory with information about affected products, including the Cisco bug ID for each affected product."

 Juniper

"Juniper SIRT is actively investigating the impact on Juniper Networks products and services.”

Brocade

 

Citrix/Netscaler

"Citrix NetScaler SDX: Citrix believes that currently supported versions of Citrix NetScaler SDX are not at risk from malicious network traffic. However, in light of these issues, Citrix strongly recommends that customers only deploy NetScaler instances on Citrix NetScaler SDX where the NetScaler admins are trusted."

Most of the people who have found this post on the internet are already familiar with Palo Alto Firewalls and everything they can do. One of the features I really like is the IPS functionality built into the firewall, but - and its a BIG BUT - if you're terminating SSL after the traffic ingresses your untrusted security zone you're loosing a lot of the PAN's IPS functionality because the traffic is encrypted.

Here is a reference diagram of what I am talking about:

So how do we fix it? PAN has a feature called SSL Inbound Inspection. This feature as of 7.1.x code does not terminate the SSL session or work as a proxy, but at a high-level takes a copy of the traffic and uses your imported certificate and key to inspect the traffic against the policies that have been configured. It's really easy to setup, but there are a couple caveats that I wanted to outline in this post.

SSL and Supported Ciphers: As many of you know the SSL negotiation is determined between the client and the server during the SSL handshake.  Because the firewall does not work as a SSL proxy, or "man in the middle", you have to insure that the client and server negotiate a cipher that the firewall is able to decrypt. This is where we ran into a little confusion.  Much of the documentation on the PAN site is focused around outbound SSL decryption.  This gets confusing when PAN doesn't document what feature they are discussing in an article. For example they have an article of supported decryption ciphers and they did not specify on the document if these were the ciphers used in outbound decryption or inbound inspection.  Then, when I asked for documentation of supported inbound SSL inspection ciphers, they could not point me to a document. FYI if you look at an SSL decryption profile there is a disclaimer in small print that only the listed RSA ciphers are supported for inbound inspection. I was told this was going to fixed.


So to help you out here is what is supported for inbound SSL inspection:

To ensure your firewall can decrypt all inbound SSL traffic it is important you configure your servers or load balancers to only offer ciphers supported by your firewall. If you're using an F5 to terminate SSL here is the string you can define in the cipher list within your SSL client profile.

!DES:!3DES:!SSLv3:!RC4:!EXP:RSA

APP-ID and Application Default Services: Many of you out here have enabled APP-ID on your firewalls and probably leveraged the application default service setting to let the firewall determine the port to allow traffic on.  I have been told application default setting in the services section of a security policy is best practice and, to be honest, I actually like it and use it; but it can break SSL Inbound Inspection. To understand where it breaks we first need to understand how a firewall processes a packet when you have enabled inbound SSL Inspection:

  1. The firewall looks to see if the packet is allowed by the security policy.
  2. The firewall identifies the traffic as SSL
  3. The firewall looks to see if the destination is configured with a SSL decryption policy
  4. If the destination address matches a protected IP address, it is decrypted and processed through the security policies once again as web-browsing still on port 443. 
  5. Bang! Connection is broken.

When you have application default set it is expecting specific ports based on the application that has been identified by APP-ID.  So if you have SSL and web-browsing configured in the APP-ID portion and application default configured in the services portion of your security policy...once the firewall decrypts the packets and runs it back through the security polices as web-browsing traffic on port 443 the firewall drops or resets the connection.

To resolve this issue you can still use APP-ID but you will need to explicitly list the ports the firewall will allow traffic on. This will allow any application, in this case web-browsing traffic on TCP port 443, to be allowed on any of the listed ports.

Configure SSL Inbound Inspection: You can click here to go to the Palo Alto Networks website and they will walk you though the SSL Inbound Inspection configuration.