Address Objects are one of four object classes (Address, User, Service, and Schedule) in
SonicOS Enhanced. These Address Objects allow for entities to be defined one time, and to be re-used in multiple referential instances throughout the SonicOS interface. For example, take an internal Web-Server with an IP address of 67.115.118.80. Rather than repeatedly typing in the IP address when constructing Access Rules or NAT Policies, Address Objects allow you to create a single entity called “My Web Server” as a Host Address Object with an IP address of 67.115.118.80. This Address Object, “My Web Server” can then be easily and efficiently selected from a drop-down menu in any configuration screen that employs Address Objects as a defining criterion.
Since there are multiple types of network address expressions, there are currently the following
Address Objects types:
|
|
•
|
Host
– Host Address Objects define a single host by its IP address. The netmask for a Host Address Object will automatically be set to 32-bit (255.255.255.255) to identify it as a single host. For example, “My Web Server” with an IP address of “67.115.118.110” and a default netmask of “255.255.255.255”
|
|
|
•
|
Range
– Range Address Objects define a range of contiguous IP addresses. No netmask is associated with Range Address Objects, but internal logic generally treats each member of the specified range as a 32-bit masked Host object. For example “My Public Servers” with an IP address starting value of “67.115.118.66” and an ending value of “67.115.118.90”. All 25 individual host addresses in this range would be comprised by this Range Address Object.
|
|
|
•
|
Network
– Network Address Objects are like Range objects in that they comprise multiple hosts, but rather than being bound by specified upper and lower range delimiters, the boundaries are defined by a valid netmask. Network Address Objects must be defined by the network’s address and a corresponding netmask. For example “My Public Network” with a Network Value of “67.115.118.64” and a Netmask of “255.255.255.224” would comprise addresses from 67.115.118.64 through to 67.115.118.95. As a general rule, the first address in a network (the network address) and the last address in a network (the broadcast address) are unusable.
|
|
|
•
|
MAC Address
– MAC Address Objects allow for the identification of a host by its hardware address or MAC (Media Access Control) address. MAC addresses are uniquely assigned to every piece of wired or wireless networking device by their hardware manufacturers, and are intended to be immutable. MAC addresses are 48-bit values that are expressed in 6 byte hex-notation. For example “My Access Point” with a MAC address of “00:06:01:AB:02:CD”. MAC addresses are resolved to an IP address by referring to the ARP cache on the security appliance MAC address objects are used by various components of Wireless configurations throughout SonicOS.
|
|
|
•
|
FQDN Address
– FQDN address objects allow for the identification of a host by its Fully Qualified Domain Names (FQDN), such as 'www.sonicwall.com'. FQDNs are be resolved to their IP address (or IP addresses) using the DNS server configured on the security appliance. Wildcard entries are supported through the gleaning of responses to queries sent to the sanctioned DNS servers.
|
SonicOS Enhanced has the ability to group Address Objects into Address Object Groups.
Groups of Address Objects can be defined to introduce further referential efficiencies. Groups can comprise any combination of Host, Range, or Network Address Objects. MAC address Objects should be grouped separately, although they can safely be added to Groups of IP-based Address Objects, where they will be ignored when their reference is contextually irrelevant (e.g. in a NAT Policy). For example “My Public Group” can contain Host Address Object “My Web Server” and Range Address Object “My Public Servers”, effectively representing IP addresses 67.115.118.66 to 67.115.118.90 and IP address 67.115.118.110.
The
Network > Address Objects
page allows you to create and manage your Address Objects.
You can view Address Objects in the following ways using the
View Style
menu:
Sorting Address Objects allows you to quickly and easily locate Address Objects configured on
the SonicWALL security appliance.
The Address Objects and Address Groups tables provides easy pagination for viewing a large
number of address objects and groups. You can navigate a large number of entries listed in the Address Objects or Address Groups tables by using the navigation control bar located at the top right of the tables. Navigation control bar includes four buttons. The far left button displays the first page of the table. The far right button displays the last page. The inside left and right arrow buttons moved the previous or next page respectively.
You can enter the policy number (the number listed before the policy name in the
# Name
column) in the Items
field to move to a specific entry. The default table configuration displays 50 entries per page. You can change this default number of entries for tables on the System >
Administration
page.
You can sort the entries in the table by clicking on the column header. The entries are sorted
by ascending or descending order. The arrow to the right of the column entry indicates the sorting status. A down arrow means ascending order. An up arrow indicates a descending order.
The
Default Address Objects
view displays the default Address Objects
and Address
Groups
for your SonicWALL security appliance. The Default Address Objects
entries cannot be modified or deleted. Therefore, the Edit and Delete icons are dimmed.
To add an
Address Object
, click Add
button under the Address Objects
table in the All
Address Objects
or Custom Address Objects
views to display the Add Address Object
window.
|
Step 2
|
Select
Host
, Range
, Network
, MAC
, or FQDN
from the Type
menu.
|
|
|
–
|
If you select
Host
, enter the IP address and netmask in the IP Address
and Netmask
fields.
|
|
|
–
|
If you selected
Range
, enter the starting and ending IP addresses in the Starting IP
Address
and Ending IP Address
fields.
|
|
|
–
|
If you selected
Network
, enter the network IP address and netmask in the Network
and Netmask
fields.
|
|
|
–
|
If you selected
MAC
, enter the MAC address and netmask in the Network
and MAC
Address
field.
|
|
|
–
|
If you selected
FQDN
, enter the domain name for the individual site or range of sites (with a wildcard) in the FQDN
field.
|
To edit an Address Object, click the edit icon 
in the
Configure
column in the Address
Objects
table. The Edit Address Object
window is displayed, which has the same settings as the Add Address Object
window.
To delete an Address Object, click the Delete icon 
in the
Configure
column for the Address Object you want to delete. A dialog box is displayed asking you to confirm the deletion. Click OK to delete the Address Object. To delete multiple active Address Objects, select them and click the Delete
button.
As more and more Address Objects are added to the SonicWALL security appliance, you can
simplify managing the addresses and access policies by creating groups of addresses. Changes made to the group are applied to each address in the group. To add a Group of Address Objects, complete the following steps:
|
Step 1
|
Click
Add Group
to display the Add Address Object Group
window.
|
To edit a group, click the edit icon in the
Configure
column of the Address Groups
table. The Edit Address Object Group
window is displayed. Make your changes and then click OK
.
To delete a group, click on the Delete icon in the
Configure
column to delete an individual Address Group. A dialog box is displayed asking you to confirm the deletion. Click OK
to delete the Address Group. To delete multiple active Address Groups, select them and click the Delete
button.
SonicOS Enhanced includes the
Public Server Wizard
to automate the process of configuring the SonicWALL security appliance for handling public servers. For example, if you have an e-mail and Web server on your network for access from users on the Internet.
The
Public Server Wizard
allows you to select or define the server type (HTTP, FTP, Mail), the private (external) address objects, and the public (internal) address objects. Once the server type, private and public network objects are configured, the wizard creates the correct NAT Policies and Access Rule entries on the security appliance for the server. You can use the SonicWALL Management Interface for additional configuration options.
See
Part 21, Wizards
for more information on configuring the SonicWALL security appliance using wizards.
From its inception, SonicOS Enhanced has used Address Objects (AOs) to represent IP
addresses in most areas throughout the user interface. Address Objects come in the following varieties:
|
|
•
|
Host
– An individual IP address, netmask and zone association.
|
|
|
•
|
MAC (original)
– Media Access Control, or the unique hardware address of an Ethernet host. MAC AOs were originally introduced in SonicOS 2.5 and were used for:
|
MAC AOs were originally not allowable targets in other areas of the management
interface, such as Access Rules, so historically they could not be used to control a host’s access by its hardware address.
|
|
•
|
Range
– A starting and ending IP address, inclusive of all addresses in between.
|
|
|
•
|
Group
– A collection of Address Objects of any assortment of types. Groups may contain other Groups, Host, MAC, Range, or FQDN Address Objects.
|
SonicOS Enhanced 3.5 redefined the operation of MAC AOs, and introduces Fully Qualified
Domain Name (FQDN) AOs:
|
|
•
|
MAC
– SonicOS Enhanced 3.5. and higher will resolve MAC AOs to an IP address by referring to the ARP cache on the SonicWALL.
|
|
|
•
|
FQDN
– Fully Qualified Domain Names, such as ‘www.reallybadWebsite.com’, will be resolved to their IP address (or IP addresses) using the DNS server configured on the SonicWALL. Wildcard entries are supported through the gleaning of responses to queries sent to the sanctioned DNS servers.
|
While more effort is involved in creating an Address Object than in simply entering an IP
address, AOs were implemented to complement the management scheme of SonicOS Enhanced, providing the following characteristics:
|
|
•
|
Zone Association
– When defined, Host, MAC, and FQDN AOs require an explicit zone designation. In most areas of the interface (such as Access Rules) this is only used referentially. The functional application are the contextually accurate populations of Address Object drop-down lists, and the area of “VPN Access” definitions assigned to Users and Groups; when AOs are used to define VPN Access, the Access Rule auto-creation process refers to the AO’s zone to determine the correct intersection of VPN
[zone] for rule placement. In other words, if the “192.168.168.200 Host” Host AO, belonging to the LAN zone was added to “VPN Access” for the “Trusted Users” User Group, the auto-created Access Rule would be assigned to the VPN
LAN zone.
|
|
|
•
|
Management and Handling
– The versatilely typed family of Address Objects can be easily used throughout the SonicOS Enhanced interface, allowing for handles (e.g. from Access Rules) to be quickly defined and managed. The ability to simply add or remove members from Address Object Groups effectively enables modifications of referencing rules and policies without requiring direct manipulation.
|
|
|
•
|
Reusability
– Objects only need to be defined once, and can then be easily referenced as many times as needed.
|
The term Dynamic Address Object (DAO) describes the underlying framework enabling MAC
and FQDN AOs. By transforming AOs from static to dynamic structures Firewall > Access
Rules
can automatically respond to changes in the network.
|
FQDN wildcard
support
|
FQDN Address Objects support wildcard entries, such as “*.somedomainname.com”, by first
resolving the base domain name to all its defined host IP addresses, and then by constantly actively gleaning DNS responses as they pass through the firewall.
For example, creating an FQDN AO for “*.myspace.com” will first use the DNS servers configured
on the firewall to resolve “myspace.com” to 63.208.226.40, 63.208.226.41, 63.208.226.42, and 63.208.226.43 (as can be confirmed by nslookup myspace.com
or equivalent). Since most DNS servers do not allow zone transfers, it is typically not possibly to automatically enumerate all the hosts in a domain. Instead, the SonicWALL will look for DNS responses coming from sanctioned
DNS servers
as they traverse the firewall. So if a host behind the firewall queries an external DNS server which is also a configured/defined DNS server on the SonicWALL, the SonicWALL will parse the response to see if it matches the domain of any wildcard FQDN AOs.
|
Note
|
Sanctioned DNS servers are those DNS servers configured for use by the SonicWALL firewall. The
reason that responses from only sanctioned DNS servers are used in the wildcard learning process is to protect against the possibility of FQDN AO poisoning through the use of unsanctioned DNS servers with deliberately incorrect host entries. Future versions of SonicOS Enhanced might offer the option to support responses from all DNS server. The use of sanctioned DNS servers can be enforced with the use of Access Rules, as described later in the “Enforcing the use of sanctioned servers on the network” section.
|
To illustrate, assume the firewall is configured to use DNS servers 4.2.2.1 and 4.2.2.2, and is
providing these DNS servers to all firewalled client via DHCP. If firewalled client-A performs a DNS query against 4.2.2.1 or 4.2.2.2 for “vids.myspace.com”, the response will be examined by the firewall, and will be matched to the defined “*.myspace.com” FQDN AO. The result (63.208.226.224) will then be added to the resolved values of the “*.myspace.com” DAO.
|
Note
|
If the workstation, client-A, in the example above had resolved and cached vids.myspace.com prior
to the creation of the “*.myspace.com” AO, vids.myspace.com would not be resolved by the firewall because the client would use its resolver’s cache rather than issuing a new DNS request. As a result, the firewall would not have the chance to learn about vids.myspace.com, unless it was resolved by another host. On a Microsoft Windows workstation, the local resolver cache can be cleared using the command ipconfig /flushdns
. This will force the client to resolve all FQDNs, allowing the firewall to learn them as they are accessed.
|
Wildcard FQDN entries will resolve all hostnames within the context of the domain name, up to
256 entries per AO. For example, “*.sonicwall.com” will resolve www.sonicwall.com,
software.sonicwall.com, licensemanager.sonicwall.com
, to their respective IP addresses, but it will not resolve sslvpn.demo.sonicwall.com
because it is in a different context; for sslvpn.demo.sonicwall.com to be resolved by a wildcard FQDN AO, the entry “*.demo.sonicwall.com” would be required, and would also resolve sonicos
‑
enhanced.demo.sonicwall.com, csm.demo.sonicwall.com,
sonicos
‑
standard.demo.sonicwall.com
, etc.
|
|
FQDN
resolution using DNS
|
FQDN Address Objects are resolved using the DNS servers configured on the SonicWALL in the
Network > DNS
page. Since it is common for DNS entries to resolve to multiple IP addresses, the FQDN DAO resolution process will retrieve all of the addresses to which a host name resolves, up to 256 entries per AO. In addition to resolving the FQDN to its IPs, the resolution process will also associate the entry’s TTL (time to live) as configured by the DNS administrator. TTL will then be honored to ensure the FQDN information does not become stale.
|
|
Feature
|
Benefit
|
|
FQDN entry
caching
|
Resolved FQDN values will be cached in the event of resolution attempt failures subsequent to
initial resolution. In other words, if “www.moosifer.com” resolves to 71.35.249.153 with a TTL of 300, but fails to resolve upon TTL expiry (for example, due to temporary DNS server unavailability), the 71.35.249.153 will be cached and used as valid until resolution succeeds, or until manually purged. Newly created FQDN entries that never successfully resolve, or entries that are purged and then fail to resolve will appear in an unresolved
state.
|
|
MAC Address
resolution using live ARP cache data
|
When a node is detected on any of the SonicWALL’s physical segments through the ARP
(Address Resolution Protocol) mechanism, the SonicWALL’s ARP cache is updated with that node’s MAC and IP address. When this update occurs, if a MAC Address Objects referencing that node’s MAC is present, it will instantly be updated with the resolved address pairing. When a node times out of the ARP cache due to disuse (e.g. the host is no longer L2 connected to the firewall) the MAC AO will transition to an “unresolved” state.
|
|
MAC Address
Object multi‑homing support
|
MAC AOs can be configured to support multi-homed nodes, where multi-homed refers to nodes
with more than one IP address per physical interface. Up to 256 resolved entries are allowed per AO. This way, if a single MAC address resolves to multiple IPs, all of the IP will be applicable to the Access Rules, etc. that refer to the MAC AO.
|
|
Automatic and
manual refresh processes
|
MAC AO entries are automatically synchronized to the SonicWALL’s ARP cache, and FQDN AO
entries abide by DNS entry TTL values, ensuring that the resolved values are always fresh. In addition to these automatic update processes, manual Refresh and Purge capabilities are provided for individual DAOs, or for all defined DAOs.
|
|
FQDN
resolution using DNS
|
FQDN Address Objects are resolved using the DNS servers configured on the SonicWALL in the
Network > DNS
page. Since it is common for DNS entries to resolve to multiple IP addresses, the FQDN DAO resolution process will retrieve all of the addresses to which a host name resolves, up to 256 entries per AO. In addition to resolving the FQDN to its IPs, the resolution process will also associate the entry’s TTL (time to live) as configured by the DNS administrator. TTL will then be honored to ensure the FQDN information does not become stale.
|
Although not a requirement, it is recommended to enforce the use of authorized or sanctioned
servers on the network. This practice can help to reduce illicit network activity, and will also serve to ensure the reliability of the FQDN wildcard resolution process. In general, it is good practice to define the endpoints of known protocol communications when possible. For example:
MAC and FQDN DAOs provide extensive Access Rule construction flexibility. MAC and FQDN
AOs are configured in the same fashion as static Address Objects, that is from the Network >
Address Objects
page. Once created, their status can be viewed by a mouse‑over of their appearance, and log events will record their addition and deletion.
Dynamic Address Objects lend themselves to many applications. The following are just a few
examples of how they may be used. Future versions of SonicOS Enhanced may expand their versatility even further.
There might be instances where you wish to block all protocol access to a particular destination
IP because of non-standard ports of operations, unknown protocol use, or intentional traffic obscuration through encryption, tunneling, or both. An example would be a user who has set up an HTTPS proxy server (or other method of port-forwarding/tunneling on “trusted” ports like 53, 80, 443, as well as nonstandard ports, like 5734, 23221, and 63466) on his DSL or cable modem home network for the purpose of obscuring his traffic by tunneling it through his home network. The lack of port predictability is usually further complicated by the dynamic addressing of these networks, making the IP address equally unpredictable.
Since these scenarios generally employ dynamic DNS (DDNS) registrations for the purpose of
allowing users to locate the home network, FQDN AOs can be put to aggressive use to block access to all hosts within a DDNS registrar.
Step 1
– Create the FQDN Address Object
|
|
•
|
From
Network > Address Objects
, select Add
and create the following Address Object:
|
Step 2
– Create the Firewall Access Rule
|
|
•
|
From the
Firewall > Access Rules
page, LAN->WAN
zone intersection, Add an Access Rule as follows:
|
It is common for dynamically configured (DHCP) network environments to work in combination
with internal DNS servers for the purposes of dynamically registering internal hosts – a common example of this is Microsoft’s DHCP and DNS services. Hosts on such networks can easily be configured to dynamically update DNS records on an appropriately configured DNS server (for example, see the Microsoft Knowledgebase article “How to configure DNS dynamic updates in Windows Server 2003” at http://support.microsoft.com/kb/816592/en-us
).
The following illustrates a packet dissection of a typical DNS dynamic update process, showing
the dynamically configured host 10.50.165.249
registering its full hostname bohuymuth.moosifer.com
with the (DHCP provided) DNS server 10.50.165.3
:
In such environments, it could prove useful to employ FQDN AOs to control access by
hostname. This would be most applicable in networks where hostnames are known, such as where hostname lists are maintained, or where a predictable naming convention is used.
Since DHCP is far more common than static addressing in most networks, it is sometimes
difficult to predict the IP address of dynamically configured hosts, particularly in the absence of dynamic DNS updates or reliable hostnames. In these situations, it is possible to use MAC Address Objects to control a host’s access by its relatively immutable MAC (hardware) address.
Like most other methods of access control, this can be employed either inclusively, for example,
to deny access to/for a specific host or group of hosts, or exclusively, where only a specific host or group of hosts are granted access, and all other are denied. In this example, we will illustrate the latter.
Assuming you had a set of DHCP-enabled wireless clients running a proprietary operating
system which precluded any type of user-level authentication, and that you wanted to only allow these clients to access an application-specific server (e.g. 10.50.165.2) on your LAN. The WLAN segment is using WPA-PSK for security, and this set of clients should only have access to the 10.50.165.2 server, but to no other LAN resources. All other wireless clients should not be able to access the 10.50.165.2 server, but should have unrestricted access everywhere else.
Step 1
– Create the MAC Address Objects
|
|
•
|
From
Network > Address Objects
, select Add
and create the following Address Object (multi-homing optional, as needed):
|
Step 2
– Create the Firewall Access Rules
Streaming media is one of the most profligate consumers of network bandwidth. But trying to
control access, or manage bandwidth allotted to these sites is difficult because most sites that serve streaming media tend to do so off of large server farms. Moreover, these sites frequently re-encode the media and deliver it over HTTP, making it even more difficult to classify and isolate. Manual management of lists of servers is a difficult task, but wildcard FQDN Address Objects can be used to simplify this effort.
Step 1
– Create the FQDN Address Object
|
|
•
|
From
Network > Address Objects
, select Add
and create the following Address Object:
|
Upon initial creation, youtube.com will resolve to IP addresses 208.65.153.240,
208.65.153.241, 208.65.153.242, but after an internal host begins to resolve hosts for all of the elements within the youtube.com domain, the learned host entries will be added, such as the entry for the v87.youtube.com server (208.65.154.84).
Step 2
– Create the Firewall Access Rule
|
|
•
|
From the
Firewall > Access Rules
page, LAN->WAN zone intersection, add an Access Rule as follows:
|