SonicOS 7 Match Objects
- SonicOS 7
- Zones
- How Zones Work
- Predefined Zones
- Security Types
- Allow Interface Trust
- Enabling SonicWall Security Services on Zones
- Effect of Wireless and Non-Wireless Controller Modes
- Match Objects > Zones
- The Zone Settings Table
- Adding a New Zone
- Configuring a Zone for Guest Access
- Configuring a Zone for Open Authentication and Social Login
- Configuring a Zone for Captive Portal Authentication with RADIUS
- Configuring a Zone for Customized Policy Message
- Configuring a Zone for Customized Login Page
- Configuring the WLAN Zone
- Configuring the RADIUS Server
- Configuring DPI-SSL Granular Control per Zone
- Enabling Automatic Redirection to the User-Policy Page
- Deleting a Zone
- Addresses
- Types of Address Objects
- About Address Groups
- About UUIDs for Address Objects and Groups
- Addresses Page
- Default Address Objects and Groups
- Default Pref64 Address Object
- Default Rogue Address Groups
- Adding an Address Object
- Editing Address Objects
- Deleting Custom Address Objects
- Purging MAC or FQDN Address Objects
- Creating Address Groups
- Editing Address Groups
- Deleting Address Groups
- Working with Dynamic Address Objects
- Services
- About Default Service Objects and Groups
- Predefined IP Protocols for Custom Service Objects
- Adding Service Objects using Predefined Protocols
- Adding Custom IP Type Services
- Editing Custom Service Objects
- Deleting Custom Service Objects
- Adding Custom Service Groups
- Editing Custom Service Groups
- Deleting Custom Service Groups
- URI Lists
- Match Objects
- Schedules
- Dynamic Group
- Email Addresses
- SonicWall Support
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.
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 optionally can 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:
- Navigate to Object > Match Objects > Addresses > Address Objects page.
-
Click Add and create the following FQDN address object:
When first created, this entry will resolve only to the address for dyndns.org, for example, 63.208.196.110. 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.
Step 2 – Create the Access Rule:
- Navigate to Policy > Access Rules page.
-
Click Add and create the access rule:
Any protocol access to target hosts within that FQDN will be blocked, and the access attempt will be logged.
Was This Article Helpful?
Help us to improve our support portal