Working with Dynamic Addresses

From its inception, SonicOS 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 are used for:

•	Identifying SonicPoints

•	Allowing hosts to bypass Guest Services authentication

•	Authorizing the BSSID (Basic Service Set Identifier, or WLAN MAC) of wireless access points detected during wireless scans.

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 redefined the operation of MAC AOs, and supports Fully Qualified Domain Name (FQDN) AOs:

•	MAC – SonicOS resolves MAC AOs to an IP address by referring to the ARP cache on the firewall.

•	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 firewall. 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, 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 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.

Key Features of Dynamic Address Objects

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.

 

Table 28. Dynamic address objects: Features and benefits

Feature	Benefit
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 firewall 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 firewall, the firewall 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 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 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 is examined by the firewall and matched to the defined *.myspace.com FQDN AO. The result (63.208.226.224) is then 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 before 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 forces the client to resolve all FQDNs, thereby allowing the firewall to learn them as they are accessed. Wildcard FQDN entries resolve all hostnames within the context of the domain name, up to 256 entries per AO. For example, *.sonicwall.com resolves www.sonicwall.com, software.sonicwall.com, and licensemanager.sonicwall.com, to their respective IP addresses, but it does 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, which would also resolve sonicos‑enhanced.demo.sonicwall.com, csm.demo.sonicwall.com, sonicos‑standard.demo.sonicwall.com, and so on. NOTE: Wildcards only support full matches, not partial matches. In other words, *.sonicwall.com is a legitimate entry, but w*.sonicwall.com, *w.sonicwall.com, and w*w.sonicwall.com are not. A wildcard can only be specified once per entry, so *.*.sonicwall.com, for example, is not be functional.
FQDN resolution using DNS	FQDN Address Objects are resolved using the DNS servers configured on the firewall 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.
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 firewall’s physical segments through the ARP (Address Resolution Protocol) mechanism, the firewall’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 (for example, 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 firewall’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 firewall 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.

Enforcing the Use of Sanctioned Servers on the Network

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:

•	Create Address Object Groups of sanctioned servers (for example, SMTP, DNS)

•	Create Access Rules in the relevant zones allowing only authorized SMTP servers on your network to communicate outbound SMTP; block all other outbound SMTP traffic to prevent intentional or unintentional outbound spamming.

•	Create Access Rules in the relevant zones allowing authorized DNS servers on your network to communicate with all destination hosts using DNS protocols (TCP/UDP 53).

IMPORTANT: Be sure to have this rule in place if you have DNS servers on your network, and you will be configuring the restrictive DNS rule that follows.

•	Create Access Rules in the relevant zones allowing Firewalled Hosts to only communicate DNS (TCP/UDP 53) with sanctioned DNS servers; block all other DNS access to prevent communications with unauthorized DNS servers.

•	Unsanctioned access attempts will then be viewable in the logs.

Using MAC and FQDN Dynamic Address Objects

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 may expand their versatility even further.

Blocking All Protocol Access to a Domain using FQDN DAOs

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.

NOTE: A DDNS target is used in this example for illustration. Non-DDNS target domains can be used just as well.

Assumptions

•	The firewall is configured to use DNS server 10.50.165.3, 10.50.128.53.

•	The firewall is providing DHCP leases to all firewalled users. All hosts on the network use the configured DNS servers above for resolution.

•	DNS communications to unsanctioned DNS servers can optionally be blocked with Access Rules, as described in Enforcing the Use of Sanctioned Servers on the Network .

•	The DSL home user is registering the hostname moosifer.dyndns.org with the DDNS provider DynDNS. For this session, the ISP assigned the DSL connection the address 71.35.249.153.

•	A wildcard FQDN AO is used for illustration because other hostnames could easily be registered for the same IP address. Entries for other DDNS providers could also be added, as needed.

Step 1 – Create the FQDN Address Object

•	From Network > Address Objects, select Add and create the following Address Object:

•	When first created, this entry will resolve only to the address for dyndns.org, e.g. 63.208.196.110.

Step 2 – Create the Firewall Access Rule

•	From the Firewall > Access Rules page, LAN->WAN zone intersection, Add an Access Rule as follows:

NOTE: Rather than specifying LAN Subnets as the source, a more specific source could be specified, as appropriate, so that only certain hosts are denied access to the targets.

•	When a host behind the firewall attempts to resolve moosifer.dyndns.org using a sanctioned DNS server, the IP address(es) returned in the query response will be dynamically added to the FQDN AO.

•	Any protocol access to target hosts within that FQDN will be blocked, and the access attempt will be logged:

Using an Internal DNS Server for FQDN-based Access Rules

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.

Controlling a Dynamic Host’s Network Access by MAC Address

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):

•	Once created, if the hosts are present in the firewall’s ARP cache, they will be resolved immediately, otherwise they will appear in an unresolved state in the Address Objects table until they are activated and are discovered through ARP:

•	Create an Address Object Group comprising the Handheld devices:

Step 2 – Create the Firewall Access Rules

•	To create access rules, navigate to the Firewall > Access Rules page, click on the All Rules radio button, and scroll to the bottom of the page and click the Add button.

•	Create the following four access rules:

 

Table 29. Sample access rules

Setting	Access Rule 1	Access Rule 2	Access Rule 3	Access Rule 4
From Zone	WLAN	WLAN	WLAN	WLAN
To Zone	LAN	LAN	LAN	LAN
Service	MediaMoose Services	MediaMoose Services	Any	Any
Source	Handheld Devices	Any	Handheld Devices	Any
Destination	10.50.165.3	10.50.165.3	Any	Any
Users allowed	All	All	All	All
Schedule	Always on	Always on	Always on	Always on

NOTE: The MediaMoose Services service is used to represent the specific application used by the handheld devices. The declaration of a specific service is optional, as needed.

Bandwidth Managing Access to an Entire Domain

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:

NOTE: If you do not see the Bandwidth tab, you can enable bandwidth management by declaring the bandwidth on your WAN interfaces.

NOTE: The BWM icon appears within the Access Rule table, indicating that BWM is active and providing statistics. Access to all *.youtube.com hosts, using any protocol, is now be cumulatively limited to 2% of your total available bandwidth for all user sessions.