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 [2021/06/08 14:30] – [DHCP Running on Firewall Interface] bstaffordpaloaltonetworks:configuration:useful_security_policies [2025/05/26 08:31] (current) – [Block Bad IP] bstafford
Line 212: 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 329: 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 383: 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 404: Line 406:
  
 =====DHCP Relay Running on Firewall Interface===== =====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). 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'.+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"   * Name: "Allow DHCP Relay on Palo"
Line 416: Line 418:
 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. 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 440: 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.1623162607.txt.gz · Last modified: (external edit)