Full FQDN blocking on SSL encrypted websites is only possible if the Web Browser being used declares it in the Server Name Indication (SNI) extension which is optional, or if it matches literally with the CN presented in the Server's Certificate. Besides the Web Browser choosing not to expose the FQDN in the SNI, there are two other situations that can prevent URL Filtering matching: 1. The browser in use is Google Chrome, and the connection is established using the QUIC protocol instead of using HTTP(S). The solution is to create a Security Policy at the top of your security policy set blocking application 'quic'. 2. The browser in use is encrypting the Client Hello (ECH) or encrypting the SNI (also known as ESNI), which are options in TLSv1.3. In that case you will not be able to read the SNI and you may need to resort into taking a decision based on the validity of the Root CA signer. You can set a decryption profile without rolling out SSL Decryption, and check with a no-decrypt Decryption Policy to see if the root CA is trusted, and if not, block the connection.   The best way to determine what situation you're encountering is to run a packet capture of one of your user's traffic being allowed. ... View more

Host sweep will detect whenever a source attempts to hit different IP addresses on the same destination port, which if you think of it is by definition internet activity (multiple IP's hit on port 443 and 80). This means that if you enable this protection on an internal Zone with internet access, it is highly likely to trigger FP's continuously for public IP's on the internet on regular internet ports (most frequently 443 and 80). ... View more

For SSH   > configure # delete deviceconfig system ssh # set deviceconfig system ssh ciphers mgmt aes256-ctr # set deviceconfig system ssh default-hostkey mgmt key-type ECDSA 256 # set deviceconfig system ssh regenerate-hostkeys mgmt key-type ECDSA key-length 256 # set deviceconfig system ssh session-rekey mgmt interval 3600 # set deviceconfig system ssh mac mgmt hmac-sha2-256 # commit # exit > set ssh service-restart mgmt   If you need to move away from using the diffie-hellman key exchange algorithm, you need to upgrade to PAN-OS 9.0 or above. After upgrading, to modify the key-exchange algorithm for SSH please execute:   > configure # set deviceconfig system ssh kex mgmt ecdh-sha2-nistp256 # commit # exit > set ssh service-restart mgmt   Please note that stronger versions are also available, so you can pick the one that you prefer, additional options include ecdh-sha2-nistp384 or ecdh-sha2-nistp521. The command for those would instead be:   # set deviceconfig system ssh kex mgmt ecdh-sha2-nistp384 # set deviceconfig system ssh kex mgmt ecdh-sha2-nistp521   Special note for SSH: If you are in HA, make sure you have an open SSH session to the secondary firewall prior to running those commands on a primary member in a cluster, because once you commit, and the config gets synced to the secondary, it won't let you SSH in until the SSH service is restarted. If you do forget, a simple way around it is to enable Telnet through GUI, jump in via Telnet, run the restart command and then disable Telnet again. Otherwise you have to get console access. For SSL/TLS:   set shared ssl-tls-service-profile TLS-PROFILE protocol-settings min-version tls1-2 set shared ssl-tls-service-profile TLS-PROFILE protocol-settings max-version max set shared ssl-tls-service-profile TLS-PROFILE protocol-settings auth-algo-sha1 no set shared ssl-tls-service-profile TLS-PROFILE protocol-settings enc-algo-3des no set shared ssl-tls-service-profile TLS-PROFILE protocol-settings enc-algo-rc4 no set shared ssl-tls-service-profile TLS-PROFILE protocol-settings keyxchg-algo-dhe no     Special note for SSL: If you move to using a ECDSA self-signed certificate for management, make sure you deploy a chained certificate. If you instead used a standalone ECDSA CA certificate it won't work and you will lose access to the WebUI. If you want to be careful, enable the HTTP service temporarily until you verify that the HTTPS access is working properly.   You can verify which algorithms the firewall is running by using these NMAP commands:   SSH   nmap --script ssh2-enum-algos -sV -p 22 [TARGET_IP]     SSL   nmap --script ssl-enum-ciphers -p 443 [TARGET_IP]     Here are official KBs which cover this topic as well. HOW TO FIX WEAK CIPHERS AND KEYS ON THE MANAGEMENT INTERFACE FOR SSH ACCESS  Refresh SSH Keys and Configure Key Options for Management Interface Connection INFORMATION ON SWEET32 FOR PALO ALTO NETWORKS CUSTOMERS  HOW TO DISABLE MEDIUM STRENGTH SSL CIPHERS FOR SSL/TLS SERVICE PROFILE   ... View more

I verified that you can estimate the uptime of the firewall by running:     nmap -d -v -O <mgmt_ipaddress>     To mitigate this, move the management-interface to a data port, and tie a Zone Protection profile with the option  Packet Based Attack Protection > TCP Drop > Strip TCP Options > TCP Timestamp (check)   A fix would be to add an option in PAN-OS to enable/disable TCP Timestamps in the management interface (toggle the value of  net.ipv4.tcp_timestamps).  Disabling the option can be achieved by editing the firewall's /etc/sysctl.conf file, and adding value ipv4.tcp_timestamps=0  ( I am with TAC and I verified this by going into root in the firewall in our lab and then running a new scan, which now shows clean).  This will require a Feature Request, please involve your Palo Alto Networks SE to 'vote up' on FR ID: 10815. ... View more

Por favor reportalo en https://urlfiltering.paloaltonetworks.com/query/ ... View more

Host sweep will detect whenever a source attempts to hit different IP addresses on the same destination port, which if you think of it is by definition internet activity (multiple IP's hit on port 443 and 80). This means that if you enable this protection on an internal Zone with internet access, it is highly likely to trigger FP's continuously for public IP's on the internet on regular internet ports (most frequently 443 and 80). ... View more

It was resolved with Antivirus package version  3616. ... View more

The release notes for 9.1.5 didn't include it but it was issue PAN-110168. I tested it in the lab and I actually see it was fixed earlier than stated in our notes (I see it fixed in 9.1.4, where the " Strict-Transport-Security : max-age=31536000" header is included).   For jQuery the issue id is PAN-147254 and the fix has not been released yet, however, we released a Security Advisory letting our customers know that even though the version of jQuery is outdated,  the conditions required for exploiting this vulnerability in jQuery do not exist in PAN-OS. You can find this information in https://security.paloaltonetworks.com/PAN-SA-2020-0007.     ... View more

That's an interesting find. Please open a case with Support. ... View more

HSTS issue was resolved in 9.1.5 JQuery is targeted to be resolved in 9.1.8 ... View more

As mentioned you can't create a blocking action against a file hash. You could however create a custom signature if you have a copy of the sample.   For more info please see: https://docs.paloaltonetworks.com/pan-os/u-v/custom-app-id-and-threat-signatures/custom-application-and-threat-signatures/custom-signature-contexts/string-contexts/file-data.html ... View more

Please open a case with Support. ... View more