Application Control provides the functionality to handle several types of access control very efficiently. The following use cases are presented in this section:
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:
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 may 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:
or
which can be written more concisely as:
or
respectively.
These can be written as two regular expressions within one match object or can be further compressed into one regular expression such as:
You can also capture credit card numbers with digits separated by a '-' with the following regular expression:
The preceding ‘\D’ should be included in all of these regular expressions.
The Dell 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 Dell SonicWALL Reassembly Free Deep Packet Inspection engine also provides proactive defense against newly discovered application and protocol vulnerabilities.
To create an Application Control policy, first create a match object of type Application Signature List or Application Signature Category List. These two types allow for selection of either general application categories or individual application signatures.
The example below shows a match object targeted at LimeWire and Napster Peer to Peer sharing applications.
After creating a signature-based match object, create a new App Rules policy of type App Control Content that uses the match object. The example below shows a policy which uses the newly created “Napster/LimeWire P2P” match object to drop all Napster and LimeWire traffic.
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 Application Control policy that triggered the alert/action. To obtain more detail about the log event, select the Log using App Control message format checkbox in the App Control Policies Settings dialog for that policy.
Many businesses and organizations need to ensure compliance with their policies regarding outbound file transfer. Application Control 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.
Servers are typically accessed by many untrusted clients. For best protection of these valuable resources, you should have multiple lines of defense. With Application Control 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 may be configured as read-only, this adds a layer of security that is controlled by the firewall administrator. Your server will still be protected even if its configuration is changed by an error, a side-effect of a patch, or by someone with malicious intent. With Application Control, 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 Application Control to enforce these restrictions, by creating a policy for each customer.