User Tools

Site Tools


paloaltonetworks:configuration:useful_security_policies

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
paloaltonetworks:configuration:useful_security_policies [2020/10/05 10:07] – [Default Block] bstaffordpaloaltonetworks:configuration:useful_security_policies [2025/05/26 08:31] (current) – [Block Bad IP] bstafford
Line 2: Line 2:
  
 A list of handy rules. A list of handy rules.
 +
 +===== Useful Methodlology =====
 +  * Block all from IP
 +  * Block all to IP
 +  * Block all to sinkhole
 +  * Block all to tcp/udp/port
 +  * Block all from country
 +  * Block all to country
 +  * Block all application (e.g. quic, ssh-tunnel)
 +  * Allow outside->outside (e.g. VPN, GlobalProtect, ping, firewall ping out,etc)
 +  * Deny outside->outside any/any
 +  * Allow outside->dmz
 +  * Allow all application everywhere (e.g. ping, traceroute, icmp)
 +  * Allow all application everywhere (e.g. ocsp (note that tcp-hand shake has to happen so we put in seperate rule)
 +  * Allow user subnets to Internet
 +    * Block banned applications for user/group
 +    * Allow list of sanctioned applications for user/group
 +    * Allow list of tolorated applications for user/group
 +    * Allow ssl, web-browsing, google-base for user/group
 +    * Allow tcp-80, tcp-443 for user/group
 +    * Allow any (application-default) for user/group
 +    * Allow any any for user/group
 +  * Allow users to servers
 +  * Allow servers to internet
 +  * Allow serverts to other
 ===== Geo Blocking ===== ===== Geo Blocking =====
 Be careful with Geo Blocking. Remember, Palo Alto Networks PAN-OS gets its Geo Location data from Max Mind. In August 2020, Max Mind changed 8.8.8.8 from being in "US" to being in "IN" (India). Anyone blocking access to India lost a lot of DNS capability until bypasses were put in place. Be careful with Geo Blocking. Remember, Palo Alto Networks PAN-OS gets its Geo Location data from Max Mind. In August 2020, Max Mind changed 8.8.8.8 from being in "US" to being in "IN" (India). Anyone blocking access to India lost a lot of DNS capability until bypasses were put in place.
Line 14: Line 39:
 Consider blocking Consider blocking
   * App-ID **quic**   * App-ID **quic**
-  * App-ID *ssh-tunnel**+  * App-ID **ssh-tunnel**
   * UDP-433 (just in case this is not identified as quic. This will also catch some 'dtls' and 'facebook-base' and 'unknown-udp' and 'dnscrypt' and 'sip')   * UDP-433 (just in case this is not identified as quic. This will also catch some 'dtls' and 'facebook-base' and 'unknown-udp' and 'dnscrypt' and 'sip')
   * TCP-853 (DNS over TLS)   * TCP-853 (DNS over TLS)
Line 66: Line 91:
 You can also lock down the URL category by creating a custom one that blocks everything except the following URLS You can also lock down the URL category by creating a custom one that blocks everything except the following URLS
   * ''updates.paloaltonetworks.com''   * ''updates.paloaltonetworks.com''
 +  * ''proitpdownloads.plaoaltonetworks.com''
   * ''downloads.paloaltonetworks.com''   * ''downloads.paloaltonetworks.com''
  
 +To do static updates:
 +  * ''us-static.updates.paloaltonetworks.com'' 
 +  * Avoid using an IP address instead of a URL. Doing so will break the SSL/TLS SNI verification.
 +  * 35.186.202.45:443 and 34.120.74.244:443
 +  * <code>[2600:1901:0:669::]:443 and [2600:1901:0:5162::]:443</code>
 +
 +**OLD INFORMATION THAT WAS RETIRED IN JULY 2021.**
 To do static updates: To do static updates:
   * ''staticupdates.paloaltonetworks.com''   * ''staticupdates.paloaltonetworks.com''
Line 179: Line 212:
   * ''ntp''   * ''ntp''
   * ''ldap''   * ''ldap''
-  * ''active-directory-base'' +  * ''active-directory'' 
-  * ''msrpc-base''+  * ''kerberos'' 
 +  * ''msrpc'' or ''msrpc-base'' (msrpc includes ms-local-security-managment)
   * ''ms-dc-replication''   * ''ms-dc-replication''
-  * ''s-netlogon'' +  * ''ms-netlogon'' 
-  * ''ms-ds-smbv3'' +  * ''ms-ds-smb'' 
-  * ''ms-ds-dmbbase''+ 
 +The 'netbiosapplications are probably not needed.
  
 =====Allow PAN Firewall to another Firewall for User-ID===== =====Allow PAN Firewall to another Firewall for User-ID=====
Line 296: Line 331:
  
  
-  * Name: "Internet to Gateway - Rule 2"+  * Name: "Internet to Gateway - Rule 2" (This is the rule that allows the VPN tunnel to establish)
   * From Zone: Any   * From Zone: Any
   * From Address: Any   * From Address: Any
Line 350: Line 385:
  
 =====DHCP Running on Firewall Interface===== =====DHCP Running on Firewall Interface=====
-Note, the following rule is for allowing unicast DHCP renew requests. The initial DHCP request is a broadcast from 0.0.0.0 to 255.255.255.255. This means that it will not appear in the logs and it cannot be blocked by the firewall. If you have DHCP enabled on an interface, it will issue leases regardless of what security policies are configured on the firewall. Security policies can only be used to stop DHCP renew requests. If it blocks unicast renew requests, the client will eventually do a new DHCP discover and get an new address that way.+Note, the following rule is for allowing unicast DHCP renew requests. The initial DHCP request is a broadcast from 0.0.0.0 to 255.255.255.255. This means that it will not appear in the logs and it cannot be blocked by the firewall (see the page on [[multicast]] for an exception to this statement. If you are doing Layer2 VLANs with a VLAN interface, you will see multicast and broadcast traffic in the logs). If you have DHCP enabled on an interface, it will issue leases regardless of what security policies are configured on the firewall. Security policies can only be used to stop DHCP renew requests. If it blocks unicast renew requests, the client will eventually do a new DHCP discover and get an new address that way.
 (This rule can be an intrazonerule) (This rule can be an intrazonerule)
   * Name: "Allow DHCP on Palo"   * Name: "Allow DHCP on Palo"
Line 370: Line 405:
   * Service: application-default   * Service: application-default
  
 +=====DHCP Relay Running on Firewall Interface=====
 +Note, the following rule is for allowing DHCP clients to get DHCP addresses from a DHCP server via a DHCP relay. It is assumed that the DHCP relay is configured on the firewall on the interface that plugs into the network. The initial DHCP request is a broadcast from 0.0.0.0 to 255.255.255.255. This means that it will not appear in the logs and it cannot be blocked by the firewall (Version 10.0 changes this a little but but we can ignore that for now) (see the page on [[multicast]] for an exception to this statement. If you are doing Layer2 VLANs with a VLAN interface, you will see multicast and broadcast traffic in the logs). If you have DHCP enabled on an interface, it will issue leases regardless of what security policies are configured on the firewall. Security policies can only be used to stop DHCP renew requests. If it blocks unicast renew requests, the client will eventually do a new DHCP discover and get an new address that way. You should allow the client subnet to access the actual DHCP server on the App-ID 'dhcp'.
 +
 +  * Name: "Allow DHCP Relay on Palo"
 +  * From Zone: SZ_Internal (zone of the interface that the DHCP relay is attached to)
 +  * From Address: IP address of the DHCP relay interface.
 +  * To Zone: SZ_Server (zone where the DHCP server sits)
 +  * To Address: IP address of DHCP server.
 +  * Application: dhcp
 +  * Service: application-default
 +
 +Remember, when troubleshooting, the the DHCP relay is on the firewall, you will only see one traffic flow. However, if the DHCP relay is else where (e.g. Cisco AnyConnet box), then you may see two traffic flows. One from the Cisco AnyConnect box external IP to the DHCP server and the DHCP server responding to an internal IP in the Cisco AnyConnect box. Check the "Discover" packets to identify the value of the "Relay Agent" IP. This is what the DHCP server will respond to.
 +
 +
 +Also, remember the port flow:
 +  * client to relay source udp-68 to udp-67
 +  * relay to server udp-67 to udp-67
 +  * server to relay udp-67 to udp-67
 +  * relay to client udp-67 to udp-68
 =====GlobalProtect Cloud Service===== =====GlobalProtect Cloud Service=====
 Allow Allow
Line 394: Line 448:
 Two useful external dynamic address lists to use are IPv6 and IPv4 Bogon lists. Block SZ_Internal -> SZ_External access to these destinations as well as SZ_External -> SZ_Internal access. Remember, the IPV4 list included RFC1918 addresses. Two useful external dynamic address lists to use are IPv6 and IPv4 Bogon lists. Block SZ_Internal -> SZ_External access to these destinations as well as SZ_External -> SZ_Internal access. Remember, the IPV4 list included RFC1918 addresses.
  
-Team Cymru Bogons IPv4 - http://www.team-cymru.org/Services/Bogons/fullbogons-ipv4.txt<br/>+Team Cymru Bogons IPv4 - <code>http://www.team-cymru.org/Services/Bogons/fullbogons-ipv4.txt</code>
 IPv4 addresses that should not be routed across the Internet (including RFC1918 private IP addresses). Either reserved IP address space or unassigned and may be used for malicious purposes. More information: http://www.team-cymru.com/bogon-reference.html IPv4 addresses that should not be routed across the Internet (including RFC1918 private IP addresses). Either reserved IP address space or unassigned and may be used for malicious purposes. More information: http://www.team-cymru.com/bogon-reference.html
  
-Team Cymru Bogons IPv6 - http://www.team-cymru.org/Services/Bogons/fullbogons-ipv6.txt<br/>+Team Cymru Bogons IPv6 - <code>http://www.team-cymru.org/Services/Bogons/fullbogons-ipv6.txt</code>
 IPv6 addresses that should not be routed across the Internet. Either reserved IP address space or unassigned and may be used for malicious purposes. More information: http://www.team-cymru.com/bogon-reference.html IPv6 addresses that should not be routed across the Internet. Either reserved IP address space or unassigned and may be used for malicious purposes. More information: http://www.team-cymru.com/bogon-reference.html
  
-Two other IP addresses you can use for DNS sinkholing are ''192.0.0.1/32'' and ''2600:5200::1/128'' in addition to ''sinkhole.paloaltonetworks.com'' which is ''72.5.65.111''.+Two other IP addresses you can use for DNS sinkholing are ''192.0.0.1/32'' and ''2600:5200::1/128'' in addition to ''sinkhole.paloaltonetworks.com'' which was ''72.5.65.111'' but is now (as of 2025), ''198.135.184.22''.
  
 Also block any/any/any access to and from Palo Alto Networks three built in External Dynamic Lists (The third is only available in PAN-OS 9.0+) Also block any/any/any access to and from Palo Alto Networks three built in External Dynamic Lists (The third is only available in PAN-OS 9.0+)
paloaltonetworks/configuration/useful_security_policies.1601892425.txt.gz · Last modified: (external edit)