paloaltonetworks:configuration:useful_security_policies
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| paloaltonetworks:configuration:useful_security_policies [2021/05/10 11:24] – [Default Block] bstafford | paloaltonetworks:configuration:useful_security_policies [2025/05/26 08:31] (current) – [Block Bad IP] bstafford | ||
|---|---|---|---|
| Line 212: | Line 212: | ||
| * '' | * '' | ||
| * '' | * '' | ||
| - | * '' | + | * '' |
| - | * '' | + | * '' |
| + | * '' | ||
| * '' | * '' | ||
| - | * '' | + | * '' |
| - | * '' | + | * '' |
| - | * '' | + | |
| + | The 'netbios' | ||
| =====Allow PAN Firewall to another Firewall for User-ID===== | =====Allow PAN Firewall to another Firewall for User-ID===== | ||
| Line 329: | Line 331: | ||
| - | * Name: " | + | * Name: " |
| * 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 |
| (This rule can be an intrazonerule) | (This rule can be an intrazonerule) | ||
| * Name: "Allow DHCP on Palo" | * Name: "Allow DHCP on Palo" | ||
| Line 403: | 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 ' | ||
| + | |||
| + | * 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: | ||
| + | * Service: application-default | ||
| + | |||
| + | Remember, when troubleshooting, | ||
| + | |||
| + | |||
| + | 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 427: | 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:// | + | Team Cymru Bogons IPv4 - < |
| 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: | 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: | ||
| - | Team Cymru Bogons IPv6 - http:// | + | Team Cymru Bogons IPv6 - < |
| 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: | 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: | ||
| - | Two other IP addresses you can use for DNS sinkholing are '' | + | Two other IP addresses you can use for DNS sinkholing are '' |
| 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.1620645897.txt.gz · Last modified: (external edit)