Network Security
Policy Object: Addresses
Table of Contents
Expand All
|
Collapse All
Network Security Docs
Policy Object: Addresses
Reuse and reference an address or group of addresses across security rules, filters, or
other functions without having to manually add the address or addresses each
time.
An address object is a set of IP addresses that
you can manage in one place and then use in multiple security rules,
filters, and other functions. An address object can include either
IPv4 or IPv6 addresses (a single IP address, a range of addresses,
or a subnet), an FQDN, or a wildcard address (IPv4 address followed
by a slash and wildcard mask). An address object of type IP Netmask,
IP Range, or FQDN can specify IPv4 or IPv6 addresses. An address
object of type IP Wildcard Mask can specify only IPv4 addresses.
There are four types of address objects:
- IP Netmask - IP address or a network must be entered using slash notation to indicate the IPv4 network or the IPv6 prefix length. For example, 192.168.18.0/24 or 2001:db8:123:1::/64.
- IP Range - the IPv4 or IPv6 range of addresses must be separated by a hyphen.
- FQDN - For example, paloaltonetworks.com. This is easy to use because DNS provides the FQDN resolution to the IP addresses instead of you needing to know the IP addresses and manually updating them every time the FQDN resolves to new IP addresses.
- IP Wildcard Mask - This is useful if you define private IPv4 addresses to internal devices and your addressing structure assigns meaning to certain bits in the address.
It's important to understand that in security rules, the set of IPv4 addresses is treated
as a subset of the set of IPv6 addresses. However, the set of IPv6 addresses isn't a
subset of the set of IPv4 addresses. An IPv4 address can match a set or range of IPv6
addresses; but an IPv6 address cannot match a set or range of IPv4 addresses.
In all policy types, the keyword any for a source or destination
address means any IPv4 or IPv6 address. The keyword any is
equivalent to ::/0. If you want to express "any IPv4 address", specify 0.0.0.0/0.
During policy matching, an IPv4 address is converted into an IPv6 prefix where the first
96 bits are 0. An address of ::/8 means, match the rule if the first 8 bits are 0. All
IPv4 addresses will match ::/8, ::/9, ::/10, ::/11, ... ::/16, ... ::/32, ... through
::/96.
If you want to express "any IPv6 address, but no IPv4 addresses", you must configure two
rules. The first rule denies 0.0.0.0/0 to deny any IPv4 address (as the source or
destination address), and the second rule has ::/0 to mean any IPv6 address (as the
source or destination address), to satisfy your requirement.
Use of Address Object Type: Create an address object to
group IP addresses or to specify an FQDN, and then reference the
address object in a security rule, filter, or other function to avoid
having to individually specify multiple IP addresses in the rule,
filter, or other function. You can reference the same address object
in multiple security rules, filters, or other functions without needing
to specify the same individual addresses in each use. For example,
you can create an address object that specifies an IPv4 address
range and then reference the address object in a Security rule, a NAT security rule, and a custom report log filter. You create
an address object using the web interface or CLI. Changes require
a commit operation to make the object a part of the configuration.
After you create an Address Object:
- You can reference an address object of type IP Netmask, IP Range, or FQDN in a security rule for Security, Authentication, NAT, NAT64, Decryption, DoS Protection, Policy-Based Forwarding (PBF), QoS, Application Override, or Tunnel Inspection; or in a NAT address pool, VPN tunnel, path monitoring, External Dynamic List, Reconnaissance Protection, ACC global filter, log filter, or custom report log filter.
- You can reference an address object of type IP Wildcard Mask only in a Security rule.
More on IP Wildcard Mask
Now let's talk about using a wildcard address object in a Source Address or
Destination Address of a Security rule. When you assign private IPv4
addresses to internal devices, you can use an IP addressing structure that assigns
meaning to certain bits in the address. For example, the first three bits in the
third octet of an IP address signify the device type. This structure helps you
easily identify details about a device, such as device type or location, based on
the IP address of the device. You can use this same IP addressing structure in
Security rules for easier deployment. You create an address
object that uses a wildcard address (IP address and wildcard mask
separated by a slash, such as 10.1.2.3/0.127.248.0). A wildcard address can identify
many source or destination addresses in a single Security rule, which is
especially helpful for data centers serving many devices. You won’t have to manage
an unnecessarily large number of address objects to cover all the matching IP
addresses or use less restrictive Security rules than you need due to IP
address capacity constraints.
For example, suppose you use the IPv4 addressing scheme shown in the following figure
where the first octet represents your organization (bits 00001010 are fixed). In the
second octet, the first four bits designate the country where the network device is
located (1000 indicates the U.S.) and the last four bits indicate the region (0100
indicates the northeast). In the third octet, the first four bits are zeros and the
last four bits indicate device type (0001 indicates cash register and 0011 indicates
printer). The last octet indicates the ID number of the networking device.
Based on that structure, the IP address of cash register number 156 in the
northeastern U.S. would be 10.132.1.156:
You can use an address object of type IP Wildcard Mask to
support such an addressing structure in a Security rule. You apply a wildcard
mask to an IPv4 source or destination address to specify which addresses are subject
to the rule. In a Palo Alto Networks wildcard mask, a zero bit indicates that the
bit being compared must match the bit in the IP address that is covered by the zero.
A one bit in the mask is a wildcard or “ignore” bit, meaning the bit being compared
need not match the bit in the IP address. For example, the following snippets of an
IP address and wildcard mask illustrate how they yield four matches:
Not all vendors use a one as a wildcard bit and a zero as a matching bit.
In the example, cash registers have an IPv4 address with the third octet 00000001 and
printers have an IPv4 address with the third octet 00000011. Suppose you want to
apply a Security rule to all cash registers and printers having any ID number
from 0 to 255. To get that result, you need a wildcard mask; the third octet of the
wildcard mask must be 2 and the device ID (the fourth octet) must be 255. The
address object to specify all cash registers and printers in the northeastern U.S.
would use wildcard address 10.132.1.2/0.0.2.255:
Thus, a single Security rule that uses an address object with wildcard address
10.132.1.2/0.0.2.255 as the destination address matches the addresses of 512 devices
(256 cash registers + 256 printers), which is an efficient way to apply a rule to
many devices. The wildcard mask must begin with at least one zero (0), such as
0.0.2.255.
Consider the following when you use an address object of type IP Wildcard
Mask in a Security rule:
- A source or destination address that uses an address object of type IP Wildcard Mask doesn’t support the Negate option.
- Your environment oesn’t consider wildcard addresses when doing shadow matching, which means you won’t be warned if a Security rule using an address object of type IP Wildcard Mask overlaps a subsequent rule or is overlapped by a rule higher on the list.
- If an address matches rules that have overlapping wildcard masks, the match to the longest prefix in the wildcard mask is chosen, as shown in the following figure:
The behavior in the preceding bullet is the default behavior. However, there are use
cases where you want to have broad rules that allow some sources access to generic
applications (such as Ping, Traceroute, and web-browsing), but have narrower rules
that allow a subset of these sources access to different applications (such as SSH,
SCP) in addition to the generic applications. In earlier releases, such a deployment
did not work because only the match to the rule with the longest prefix in the
wildcard mask was processed and other rules were not considered.
Beginning with PAN-OS 10.2.1, you can enable Wildcard Top Down
Match Mode so that if a packet with an IP address matches prefixes
in Security rules that have overlapping wildcard masks, the first fully
matching rule in top-down order is chosen (instead of choosing the matching rule
with the longest prefix in a wildcard mask). A packet is found to match the prefix
in rules that use overlapping wildcard masks; then those rules that fully match all
address bits based on masking are chosen, keeping in mind the ones in the mask
indicate wildcard or “ignore” bits. Then other rule criteria, such as application
and zones, are examined. During the other rule criteria examination, the first of
those rules (in top-down order) that match the criteria is chosen. No other rules
are evaluated.
The Wildcard Top Down Match Mode means that more than one rule
has the potential to be enforced on different packets (not just the rule with the
longest matching prefix). Place your more specific rules toward the top of the list.
For example, you can allow a smaller range of matching addresses (a longer wildcard
mask) to access certain applications, and also, in a subsequent rule allow a larger
range of IP addresses (a shorter wildcard mask) to access a different (more generic)
set of applications. You can enable Wildcard Top Down Match
Mode by selecting DeviceSetupManagement and editing the Security Policy Rulebase Settings.
The following example has Wildcard Top Down Match Mode enabled
and three Security rules, each specifying a source IP address with wildcard
mask address object, and the wildcard masks overlap:
In this example, Client A with source IP address 10.143.8.1 (0000 1010 1000 1111 0000
1000 0000 0001) fully matches Rule 1, Rule 2, and Rule 3; the first match is to Rule
1 (top-down order). Assuming other rule criteria match, the packet from Client A is
subject to the Rule 1 action.
Client B with source IP address 10.160 2.1 (0000 1010 1010 0000 0000 0010 0000 0001)
does not fully match the address in Rule 1 and does not match the prefix in Rule 2.
Client B’s address fully matches Rule 3, which is the first matching rule in
top-down order. Assuming other rule criteria match, the packet from Client B is
subject to the Rule 3 action. Thus we see the benefit of Wildcard
Top Down Match Mode, that both Rule 1 and Rule 3 can be in effect on
different packets.