10.When the session ends, the customer resumes sole control of the computer.

Remote File Transfer

Secure Virtual Assist includes a Remote File Transfer feature that enables the technician to transfer files directly to and from the customer’s computer. The technician launches the File Transfer process by clicking a button in the Virtual Assist taskbar in the top left corner of the Secure Virtual Assist window. The File Transfer feature supports the upload and download of multiple files.

Chat Feature

Secure Virtual Assist includes a chat feature that allows the technician and customer to communicate using an instant message-style chat function. Either the technician or the customer can initiate a chat session by clicking on the Chat button in the Secure Virtual Assist taskbar.

Email Invitation

From the technician view of Secure Virtual Assist, technicians can send email invitations to customers that contain a direct URL link to initiate a Secure Virtual Assist session. The technician can optionally include a unique message to the customer. When the customer clicks on the email link to Secure Virtual Assist, only the technician who sent the invitation can assist that customer.

Secure Virtual Access

Secure Virtual Access, as part of the larger Secure Virtual Assist feature, allows technicians to gain access to systems outside the LAN of the SRA appliance, such as their personal systems. After downloading and installing a client from the portal page for Secure Virtual Access mode, the personal system will appear only on that technician’s Secure Virtual Assist support queue, within the SRA management interface. While Secure Virtual Access must be enabled per-portal, this functionality provides greater remote access flexibility for support technicians.

Installing and using Secure Virtual Access requires administrative privileges.

Launching a Secure Virtual Assist Technician Session

To launch a Secure Virtual Assist session as a technician, perform the following steps.

1. Log in to the SRA Virtual Office. If you are already logged in to the SRA customer interface, click on the Virtual Office button.

2. Click on the Virtual Assist button.

3. If the Virtual Assist plug-in is installed, the Virtual Assist window is displayed automatically. See 9. on page 51.

4. If the Virtual Assist plug-in is not installed, the File Download window displays, and Secure Virtual Assist attempts to automatically install. Click Run to launch the program directly, or click Save to save the installer file to your computer, and then manually launch it.

When downloading through IPv6, the File Download window displays IPv6 information.

5. When you launch the installer, you may see an additional warning message. Click Run.

6. A pop-up window asks if you would like to install Secure Virtual Assist as a standalone client. Click Yes to save the application. A shortcut will be added to your desktop and a link to the application will be added to the program list on your Start Menu. Click No to launch Secure Virtual Assist without saving the application for future use.

7. If you clicked Yes to save the application, you will be prompted to select a location to save the file. Select an appropriate location, such as C:\Program Files\SonicWALL.

8. When Secure Virtual Assist launches for the first time, you may see a security warning pop-up window. De-select the Always ask before opening this file check box to avoid this window in the future. Click Run.

9. The Secure Virtual Assist standalone application launches.

10. The technician is now ready to assist customers.

Performing Secure Virtual Assist Technician Tasks

To get started, the technician logs into the SRA appliance and launches the Secure Virtual Assist application.

Note Each technician can only assist one customer at a time.

Once the technician has launched the Secure Virtual Assist application, the technician can assist customers by performing the following tasks:

• Inviting Customers by Email

• Assisting Customers

• Using the Secure Virtual Assist Taskbar

• Controlling the Secure Virtual Assist Display

• Request Full Control

Inviting Customers by Email

To invite a customer to a Secure Virtual Assist session by email:

1. To invite a customer to Secure Virtual Assist, use the email invitation form on the left of the Secure Virtual Assist window.

Note Customers who launch Secure Virtual Assist from an email invitation can only be assisted by the technician who sent the invitation. Customers who manually launch Secure Virtual Assist can be assisted by any technician.

2. Enter the customer’s email address in the Customer E-mail field.

3. Optionally, enter Technician E-mail to use a different return email address than the default technician email.

4. Optionally, enter an Additional Message to the customer.

5. Click Invite. The customer will receive an email with an HTML link to launch Secure Virtual Assist.

6. Customers requesting assistance will appear in the Assistance Queue, and the duration of time they have been waiting will be displayed.

Assisting Customers

1. A pop-up window in the lower right task bar alerts the technician when a customer is in the assistance queue.

2. Double-click on a customer’s user name to begin assisting the customer.

3. The customer’s entire desktop is displayed in the bottom right window of the Secure Virtual Assist application.

The technician now has complete control of the customer’s keyboard and mouse. The customer can see all of the actions that the technician performs.

During a Secure Virtual Assist session, the customer is not locked out of their computer. Both the technician and customer can control the computer, although this may cause confusion and consternation if they both attempt “to drive” at the same time.

The customer has a small tool bar in the bottom right of their screen, with three options.

The customer has the following options during a Secure Virtual Assist session, each enabled after clicking the corresponding button.

• Active - Toggles to the View Only mode, where the technician can view the customer’s computer but cannot control the computer.

• Chat - Initiates a chat window with the technician.

• End Virtual Assist - Terminates the session.

Using the Secure Virtual Assist Taskbar

The Technician’s view of Secure Virtual Assist includes a taskbar with a number of options.

In Windows, the taskbar contains the following buttons:

• Refresh - Refreshes the display of the customer’s computer.

• File Transfer - Launches a window to transfer files to and from the customer’s computer. see Using the Secure Virtual Assist File Transfer for more information.

• Chat - Launches the chat window to communicate with the customer. The technician can also use the dedicated chat window in the bottom left window of the Secure Virtual Assist application.

• System Info -Displays detailed information about the customer’s computer.

• Reboot Customer - Reboot the customer’s computer. Unless you have Requested full control, the customer will be warned about and given the opportunity to deny the reboot.

• Switch Screen - Switches to a second monitor if the customer’s computer has more than one monitor configured.

In MacOS, the taskbar contains the following buttons:

• Refresh - Refreshes the display of the customer’s computer.

• Auto Scale - Adjusts the screen to fit the window size.

• Full Screen - Adjusts the screen to fill the entire window.

• System Info -Displays detailed information about the customer’s computer similar to that shown for a Windows computer.

• Reboot - Reboot the customer’s computer. Unless you have Requested full control, the customer will be warned about and given the opportunity to deny the reboot.

• Chat - Launches the text chat window to communicate with the customer. The technician can also use the dedicated chat window in the bottom left window of the Secure Virtual Assist application.

• File Transfer - Launches a window to transfer files to and from the customer’s computer. see Using the Secure Virtual Assist File Transfer for more information.

• Hide Toolbar - Hides the taskbar from view.

• Gray Color - Displays everything in grey monochrome

Controlling the Secure Virtual Assist Display

• Full Screen - Hides all of the Secure Virtual Assist toolbars and displays the customer’s desktop on the technician’s entire screen with the Secure Virtual Assist taskbar in the top left corner.

If the Secure Virtual Assist taskbar doesn’t display, move your mouse to the top middle of the screen. Right-click on the taskbar and click Restore to exit full-screen mode.

• Auto Scaling - Zooms the display to fill the entire Secure Virtual Assist window.

• Zoom - Zooms the display to one of several presets or allows you enter a specific value.

• True Size - Zooms to 100%.

• Side Bar - Toggles the display of the side bar with the email invitation and chat windows.

• Top Bar - Toggles the display of the top bar with the customer queue and toolbar.

• All Bars - Displays both the side bar and top bar.

• No Bar - Hides both the side bar and top bar.

Note A number of these options can be configured from the pull-down menus at the top of the Secure Virtual Assist application.

Request Full Control

Technicians can request full control of a customer’s desktop, allowing them to reboot the system, delete files, or over-write files on the customer’s computer without the customer being repeatedly prompted for permission. Select Request Full Control under the Commands menu to issue a request that will appear on the customer’s desktop.

Using the Secure Virtual Assist File Transfer

The File Transfer window is used to transfer files to and from the customer’s computer. The file directory of the technician’s computer is shown on the left and the customer’s computer on the right.

The File Transfer window functions in much the same manner as Windows Explorer or an FTP program. Navigate the File Transfer window by double-clicking on folders and selecting files. The File Transfer window includes the following controls:

• Desktop jumps to the desktop of the technician’s or customer’s computer.

• Up navigates up one directory on either the technician’s or customer’s computer.

• Download transfers the selected file or files from the technician’s computer to the customer’s computer.

• Upload transfers the selected file or files from the customer’s computer to the technician’s computer.

• Delete deletes the selected file or files.

Note When deleting or over-writing files, the customer is warned and must give the technician permission unless the technician has elected Request Full Control and the customer has confirmed.

• New folder creates a new folder in the selected directory.

• Rename renames the selected file or directory.

When a file is transferring, the transfer progress is displayed at the bottom of the File Transfer window. Click the Exit button to cancel a transfer in progress.

Note File Transfer supports the transfer of single or multiple files. It does not currently support the transfer of directories. To select multiple files, hold down the Ctrl button while clicking on the files.

Enabling a System for Secure Virtual Access

If Secure Virtual Access has been enabled on the Virtual Assist tab on the Portals > Portals page of the management interface, users should see a link on the portal to set-up a system for Secure Virtual Access. To enable Secure Virtual Access within the SRA management interface, see Configuring Per-Portal Virtual Assist Settings.

To configure Secure Virtual Access on a system:

1. Login to the portal through the system you wish to configure for Secure Virtual Access and click the Virtual Access link.

2. A file should download with parameters to install the VASAC.exe file that will provide the needed client for Secure Virtual Access mode. Save and run the file.

Note Running the file directly from this dialog box may not work on some systems. Save the file to the system and then run the application.

3. Fill in the necessary information in the provided fields to configure the system in Secure Virtual Access mode and click OK.

• Server: This should be the name or IP address of the appliance the technician normally accesses the Virtual Office from outside the management interface (Do not include “https://”).

• Portal: The name of the portal the technician would normally login to.

• Computer Name: This is an identifier for the system to help differentiate between other systems that may be waiting for support in the queue.

• Password: This is a password the technician must enter prior to accessing the system through the support queue.

4. After installation, the VASAC client should be left running in the desktop tray.

This system’s identifier name should now appear in the technician’s support queue displayed on the Secure Virtual Assist > Status page within the management interface.Upon double-clicking the system listing, the technician will be prompted to provide the password established during system set-up to gain Secure Virtual Access to the system.

Ending Secure Virtual Access Mode

Disconnecting from a Secure Virtual Access session will place the system back in the support queue for later access by the technician. From the personal system-side, the user/technician may uninstall or terminate the application from the tray option icons.

An administrator can forcibly remove a system from the queue. If this occurs, the Secure Virtual Access system should no longer attempt to connect to the support queue and should display an error message.

Note For tasks and information on using Secure Virtual Assist as an end-user, refer to the Dell SonicWALL SRA User’s Guide.

Secure Virtual Meeting Overview

This section provides an introduction to the Secure Virtual Meeting feature. This section contains the following topics:

• What is Secure Virtual Assist?

• Benefits of Secure Virtual Assist

• How Does Secure Virtual Assist Work?

• Launching a Secure Virtual Assist Technician Session

• Performing Secure Virtual Assist Technician Tasks

• Enabling a System for Secure Virtual Access

What is Secure Virtual Meeting?

Secure Virtual Meeting is a for the SRA 4200 and Virtual Appliance. Secure Virtual Meeting allows multiple users to view a desktop and interactively participate in a meeting from virtually anywhere with an Internet connection. Secure Virtual Meeting is similar to the one-to-one desktop sharing provided by Virtual Assist except multiple users can share a desktop.

Benefits of Secure Virtual Meeting

Secure Virtual Meeting provides the following benefits:

• Secure connections - 256-bit AES SSL encryption of the data by the SonicWALL SRA appliance provides a secure environment for the data and assists in the effort to be compliant with regulations like Sarbanes-Oxley and HIPAA.

• Time and cost savings - Secure Virtual Meeting eliminates the need to visit customer sites and reduces the average time-to-resolution of support calls.

• Educational tool - Trainers and support staff can use Secure Virtual Meeting to remotely show customers how to use programs and tools.

• Configurable environment with multiple functions - Meeting parameters can be configured for specific meetings, in addition to meeting configurations that apply to all virtual meetings.

• Meeting functions - Meeting attendees may perform several functions, such as polling meeting attendees, text chatting, and switching who shares their desktop or controls the meeting.

User Roles

Secure Virtual Meeting has several user roles:

• Coordinator (Owner of the meeting) - The Coordinator must be a SonicWALL SRA user on the appliance. The Coordinator schedules, sets up, and controls the meeting. In addition, the Coordinator has the sole power to promote a Participant to the Assistant.

• Assistant (Coordinator-designated Assistant) - The Coordinator selects an Assistant from the list of available Participants and assigns the Assistant privileges. When the Coordinator exits the meeting, the Assistant automatically becomes the Coordinator. A meeting may have multiple Assistants, each with the same or a different set of privileges. An Assistant need not be a user of the SSL-VPN appliance. Possible Assistant privileges are:

– Start/End Meeting

– Set Host

– Open Polling

– Set/Unset View Only

– Invite Participants

– Kick out Participants

– Reschedule Meeting

• Host - The Host is a Participant who shares their desktop with all Participants in the meeting. When a meeting begins, the Host’s desktop is shown to all Participants. The Host can be changed by the Coordinator during the meeting by selecting any available Participant. If a Host is not explicitly set when the meeting starts, the Coordinator becomes the Host. Only one Participant is designated as the Host at any one time.

Only the Host can control the Host System, unless the Host grants permission when a Participant requests control. The Host may also give control to any Participant by selecting the Participant from the Meeting Members list. Only one Participant can control the Host System at any one time. When a Participant takes control of the Host System, he loses control as soon as the Host moves his mouse pointer on the screen. The meeting control permission state is visible to all Participants while in the lobby.

• Participant (User with credentials to join the meeting) - A Participant must enter a meeting code before they can join a meeting. The code required to join the meeting is determined by the Coordinator prior to the meeting. After joining a meeting, the Participant can view the shared desktop and chat with another attendee privately or type a message in the Chat window that is visible to all attendees. A Participant becomes the Assistant if selected by the Coordinator or by an Assistant who has the required privilege.

• View-only Participant (User with limited meeting capabilities) - The Coordinator may designate any Participant as a View-only Participant. A View-only Participant cannot be assigned any privileges nor become an Assistant or Host.

Roles are switched before or during a meeting. A Coordinator or Assistant with necessary privileges can change the roles of any Participant during the meeting. A Participant wishing to become the Host must request permission from the Coordinator.

How Does a Secure Virtual Meeting Work?

The following sections describe how Secure Virtual Meeting works,

Configuring Secure Virtual Meeting

Secure Virtual Meeting configuration and management tasks are performed via the AMC console and consists of the following:

• Status

• Settings

• Log

• Licensing

These tasks are explained in detail in Secure Virtual Meeting chapter of the SRA Administrator’s Guide and the Secure Virtual Meeting Feature Module.

Performing Coordinator Tasks

The Virtual Meeting Coordinator performs the following tasks:

Performing Lobby Functions

The following functions can be performed from the lobby by clicking buttons:

Clicking the Start Meeting button starts the meeting. Only the Coordinator and Assistant can start a meeting.

Clicking the Stop Meeting button stops the meeting. Only the Coordinator and Assistant can end the meeting.

Clicking the Polling button opens the polling window where you can load, edit, and start a poll for Participants currently in the meeting. Only the Coordinator and Assistant can initiate polling.

Clicking the Invite button sends an email invitation to Participants. Only the Coordinator and Assistant can invite Participants.

Clicking the Reschedule Meeting button reschedules the meeting start and end times. Only the Coordinator and Assistant can reschedule a meeting.

Clicking the Request Host button informs the Host that you want to become the Host and share your desktop. Only Participants who are not currently the Host can request to become the Host.

Clicking the Quit button exits the meeting and return to the meeting selection window. Anyone in the meeting can quit the meeting.

Clicking the Start Sharing button shares the Host desktop with all Participants in the meeting. Sharing is only available during a meeting.

Clicking the Stop Sharing button stops sharing the Host System desktop. Only the Host can stop sharing and only while in the sharing state (after Start Sharing has been selected).

Clicking the Request Control button requests that the Host give you control of the keyboard and mouse. Only Participants who aren’t the Host can request control.

Using the Control Menu during a Meeting

The Control Menu is available at the top of a shared desktop when the Host shares the desktop during an active meeting.

The Invite button is available for the Coordinator or Assistants with invite permission. It opens the invite dialog if the lobby is not open.

The Polling button is available for the Coordinator or Assistants with polling permission. It opens the polling dialog.

The Chat button is available for all Participants, including View-only Participants. It opens a chat dialog if the lobby is not open.

The Lobby button is available for all meeting members, including View-only Participants. If the lobby is hidden during a meeting, it displays the lobby window when the Host is sharing the screen.

The Options button opens the Meeting Settings window and is available for all Participants.

The Viewer button is available for all Participants except the Host. It toggles the window between the Participant’s window and the Host’s desktop.

The About button opens the About dialog, which identifies the Secure Virtual Meeting client and version. The About button is available for all meeting members, including View-only Participants.

Performing Participant Taks

Participants can be designated as View-only Participants or regular Participants. View-only Participants enter and exit meetings like other Participants, but cannot perform most functions. However, they can be kicked out of meetings like other regular Participants. Regular Participants can also:

• Respond to polls

• Text chat

• Request control of the Host keyboard and mouse

• Request to become the Host and share the Participant’s desktop

• Become the Assistant

• Become a View-only Assistant

Web Application Firewall Overview

This section provides an introduction to the Web Application Firewall feature. This section contains the following topics:

• What is Web Application Firewall?

• Benefits of Web Application Firewall

• How Does Web Application Firewall Work?

What is Web Application Firewall?

Web Application Firewall is subscription-based software that runs on the Dell SonicWALL SRA appliance and protects Web applications running on servers behind the SRA. Web Application Firewall also provides real-time protection for resources such as HTTP(S) bookmarks, Citrix bookmarks, offloaded Web applications, and the SRA management interface and user portal that run on the Dell SonicWALL SRA appliance itself.

Web Application Firewall provides real-time protection against a whole suite of Web attacks such as Cross-site scripting, SQL Injection, OS Command Injection, and many more. The top ten vulnerabilities for Web applications are tracked by OWASP, an open source community that focuses its efforts on improving the security of Web applications. Dell SonicWALL SRA Web Application Firewall protects against these top ten, defined in 2007 as follows:

Table 9 OWASP Top Ten Vulnerabilities

Slowloris Protection

In addition to the top ten threats listed above, Web Application Firewall protects against Slowloris HTTP Denial of Service attacks. This means that Web Application Firewall also protects all the backend Web servers against this attack. Many Web servers, including Apache, are vulnerable to Slowloris. Slowloris is especially effective against Web servers that use threaded processes and limit the amount of threading allowed.

Slowloris is a stealthy, slow-acting attack that sends partial HTTP requests at regular intervals to hold connections open to the Web server. It gradually ties up all the sockets, consuming sockets as they are freed up when other connections are closed. Slowloris can send different host headers, and can send GET, HEAD, and POST requests. The string of partial requests makes Slowloris comparable to a SYN flood, except that it uses HTTP rather than TCP. Only the targeted Web server is affected, while other services and ports on the same server are still available. When the attack is terminated, the Web server can return to normal within as little as 5 seconds, making Slowloris useful for causing a brief downtime or distraction while other attacks are initiated. Once the attack stops or the session is closed, the Web server logs may show several hundred 400 errors.

For more information about how Web Application Firewall protects against the OWASP top ten and Slowloris types of attacks, see How Does Web Application Firewall Work?.

Offloaded Web Application Protection

Web Application Firewall can also protect an offloaded Web application, which is a special purpose portal created to provide seamless access to a Web application running on a server behind the SRA appliance. The portal must be configured as a virtual host. It is possible to disable authentication and access policy enforcement for such an offloaded host. If authentication is enabled, a suitable domain needs to be associated with this portal and all Dell SonicWALL advanced authentication features such as One Time Password, Two-factor Authentication, and Single Sign-On apply to the offloaded host.

Application Profiling

Starting in SRA 5.5, Application Profiling (Phase 1) allows the administrator to generate custom rules in an automated manner based on a trusted set of inputs. This is a highly effective method of providing security to Web applications because it develops a profile of what inputs are acceptable by the application. Everything else is denied, providing positive security enforcement. This results in fewer false positives than generic signatures, which adopt a negative security model. When the administrator places the device in learning mode in a staging environment, the SRA appliance learns valid inputs for each URL accessed by the trusted users. At any point during or after the learning process, the custom rules can be generated based on the “learned” profiles.

Rate Limiting for Custom Rules

Starting in SRA 5.5, it is possible to track the rate at which a custom rule, or rule chain, is being matched. This is extremely useful to block dictionary attacks or brute force attacks. The action for the rule chain is triggered only if the rule chain is matched as many times as configured.

Cookie Tampering Protection

Cookie Tampering Protection is an important item in the Payment Card Industry Data Security Standard (PCI DSS) section 6.6 requirements and part of the Web Application Firewall evaluation criteria that offers strict security for cookies set by the backend Web servers. Various techniques such as encryption and message digest are used to prevent cookie tampering. See Configuring Cookie Tampering Protection Settings for additional information.

Credit Card and Social Security Number Protection

Credit Card/SSN protection is a Data Loss Prevention technique that ensures that sensitive information, such as credit card numbers and Social Security numbers are not leaked within Web pages. Once such leakage is detected, the administrator can choose to mask these numbers partially or wholly, present a configurable error page, or simply log the event. See Configuring Information Disclosure Protection for additional information.

Web Site Cloaking

Web Site Cloaking prevents guessing the Web server implementation and exploiting its vulnerabilities. See Configuring Web Site Cloaking for additional information.

PDF Reporting for WAF Monitoring and PCI DSS 6.5 and 6.6 Compliance

Starting in SRA 5.5, PDF reporting is introduced for Web Application Firewall Monitoring and PCI DSS 6.5 and 6.6 Compliance. You can generate the reports on the Web Application Firewall > Status page. The timeline for generating the data published in the reports is configurable on the Web Application Firewall > Monitoring page.

Benefits of Web Application Firewall

Web Application Firewall is secure and can be used in various areas, including financial services, healthcare, application service providers, and e-commerce. Dell SonicWALL SRA uses SSL encryption to encrypt data between the Web Application Firewall and the client. Dell SonicWALL SRA also satisfies OWASP cryptographic storage requirements by encrypting keys and passwords wherever necessary.

Companies using Web Application Firewall can reduce the development cost required to create secure applications and also cut out the huge turnaround time involved in deploying a newly found vulnerability fix in every Web application by signing up for Web Application Firewall signature updates.

Resources accessed over Application Offloaded portals and HTTP(S) bookmarks can be vulnerable due to a variety of reasons ranging from badly designed architecture to programming errors. Web Application Firewall provides an effective way to prevent a hacker from exploiting these vulnerabilities by providing real-time protection to Web applications deployed behind the Dell SonicWALL SRA appliance.

Deploying Web Application Firewall at the SRA appliance lets network administrators use application offloading even when it exposes Web applications needing security to internal and remote users. Application offloading avoids URL rewriting, which improves the proxy performance and functionality.

There are several benefits of integrating Web Application Firewall with Dell SonicWALL SRA appliances. Firstly, identity-based policy controls are core to Web Application Firewall and this is easily achievable using SSL VPN technology. Secondly, there are lower latencies due to the existing hardware-based SSL offloading. Most importantly, SRA appliances run Web applications and must be protected from such attacks.

As small businesses adopt hosted services to facilitate supplier collaboration, inventory management, online sales, and customer account management, they face the same strict compliance requirements as large enterprises. Web Application Firewall on a Dell SonicWALL SRA appliance provides a convenient, cost-effective solution.

Web Application Firewall is easy to configure in the Dell SonicWALL SRA management interface. The administrator can configure Web Application Firewall settings globally, by attack priority, and on a per-signature basis. Once custom configuration settings or exclusions are in place, you can disable Web Application Firewall without losing the configuration, allowing you to perform maintenance or testing and then easily re-enable it.

How Does Web Application Firewall Work?

To use the Web Application Firewall feature, the administrator must first license the software or start a free trial. Web Application Firewall must then be enabled on the Web Application Firewall > Settings page of the Dell SonicWALL SRA management interface.Web Application Firewall can be configured to log or block detected attacks arriving from the Internet.

The following sections describe how Web Application Firewall and SRA appliances prevent attacks such as Slowloris or those listed in the OWASP top ten, how Web Application Firewall protects against information disclosure, and how other features work:

• How are Signatures Used to Prevent Attacks?

• How is Cross-Site Request Forgery Prevented?

• How is Information Disclosure Prevented?

• How are Broken Authentication Attacks Prevented?

• How are Insecure Storage and Communications Prevented?

• How is Access to Restricted URLs Prevented?

• How are Slowloris Attacks Prevented?

• What Type of PCI Compliance Reports Are Available?

• How Does Cookie Tampering Protection Work?

• How Does Application Profiling Work?

• How Does Rate Limiting for Custom Rules Work?

How are Signatures Used to Prevent Attacks?

For Cross Site Scripting, Injection Flaws, Malicious File Execution, and Insecure Direct Object Reference vulnerabilities, the Web Application Firewall feature uses a black list of signatures that are known to make Web applications vulnerable. New updates to these signatures are periodically downloaded from a Dell SonicWALL signature database server, providing protection from recently introduced attacks.

When input arrives from the Internet, Web Application Firewall inspects HTTP/HTTPS request headers, cookies, POST data, query strings, response headers, and content. It compares the input to both a black list and a white list of signatures. If pattern matching succeeds for any signature, the event is logged and/or the input is blocked if so configured. If blocked, an error page is returned to the client and access to the resource is prevented. If blocked, an error page is returned to the client and access to the resource is prevented. The threat details are not exposed in the URL of the error page. If configured for detection only, the attack is logged but the client can still access the resource. If no signature is matched, the request is forwarded to the Web server for handling.

The Web Application Firewall process is outlined in the following flowchart.

In the case of a blocked request, the following error page is returned to the client:

This page is customizable under Web Application Firewall > Settings in the SRA management interface. Some administrators may want to customize the HTML contents of this page. Others may not want to present a user friendly page for security reasons. Instead, they may prefer the option to present an HTTP error code such as 404 (Not found) or 403 (Access Denied).

How is Cross-Site Request Forgery Prevented?

CSRF attacks are not detected with signature matching. Using this vulnerability, a hacker disguised as the victim can gain unauthorized access to application even without stealing the session cookie of a user. While a victim user is authenticated to a Web site under attack, the user may unwittingly load a malicious Web page from a different site within the same browser process context, for instance, by launching it in a new tab part of the same browser window. If this malicious page makes a hidden request to the victim Web server, the session cookies in the browser memory are made part of this request making this an authenticated request. The Web server serves the requested Web page as it assumes that the request was a result of a user action on its site. To maximize the benefits, typically, hackers targets actionable requests, such as data updates to carry out this attack.

To prevent CSRF attacks, every HTTP request within a browser session needs to carry a token based on the user session. To ensure that every request carries this token, the Web Application Firewall feature rewrites all URLs contained in a Web page similarly to how they are rewritten by the Reverse Proxy for HTTP(S) Bookmarks feature. If CSRF protection is enabled, this is also performed for Application Offloading.

CSRF protection is provided for anonymous mode as well. If CSRF protection is enabled, then an idle timeout set to the global idle timeout is enforced for anonymous access. If the session times out, an error message is displayed, forcing the user to revisit the site in a new window. If authentication is enforced for the portal, then the user is redirected to the login page for the portal.

How is Information Disclosure Prevented?

Web Application Firewall prevents Information Disclosure and Improper Error Handling by providing a way for the administrator to configure text containing confidential and sensitive information so that no Web site accessed through the Web Application Firewall reveals this text. These text strings are entered on the Web Application Firewall > Settings page.

Beside the ability to pattern match custom text, signatures pertaining to information disclosure are also used to prevent these types of attacks.

Beginning in SRA 5.5, Web Application Firewall protects against inadvertent disclosure of credit card and Social Security numbers (SSN) in HTML Web pages.

Note Only text or HTML pages, and only the first 512K bytes are inspected for credit card or SSN disclosure.

Web Application Firewall can identify credit card and SSN numbers in various formats. For example, a SSN can be specified as XXX XX XXXX or XXX-XX-XXXX. Web Application Firewall attempts to eliminate false-positives by filtering out formats that do not conform to the credit card or SSN specification. For example, credit cards follow the Luhn’s algorithm to determine if an n-digit number could be a credit card number or not.

The administrator can set an appropriate action, such as detect (log), prevent, or just mask the digits that can reveal the user identity. Masking can be done fully or partially, and you can select any of the following characters for masking: #, *, -, x, X, ., !, $, and ?. The resulting masked number is similar to the appearance of credit card numbers printed on an invoice.

How are Broken Authentication Attacks Prevented?

The requirement for Broken Authentication and Session Management requires Web Application Firewall to support strong session management to enhance the authorization requirements for Web sites. Dell SonicWALL SRA already has strong authentication capabilities with the ability to support One Time Password, Two-factor Authentication, Single Sign-On, and client certificate authentication.

For Session Management, Web Application Firewall pops up a session logout dialog box when the user portal is launched or when a user logs into an application offloaded portal. This feature is enabled by default when Web Application Firewall is licensed and can be disabled from the Web Application Firewall > Settings page.

How are Insecure Storage and Communications Prevented?

Insecure Cryptographic Storage and Insecure Communications are prevented by encrypting keys and passwords wherever necessary, and by using SSL encryption to encrypt data between the Web Application Firewall and the client. Dell SonicWALL SRA also supports HTTPS with the backend Web server.

How is Access to Restricted URLs Prevented?

Dell SonicWALL SRA supports access policies based on host, subnet, protocol, URL path, and port to allow or deny access to Web sites. These policies can be configured globally or for users and groups.

How are Slowloris Attacks Prevented?

Slowloris attacks can be prevented if there is an upstream device, such as a Dell SonicWALL SRA security appliance, that limits, buffers, or proxies HTTP requests. Web Application Firewall uses a rate-limiter to thwart Slowloris HTTP Denial of Service attacks.

What Type of PCI Compliance Reports Are Available?

Payment Card Industry Data Security Standard (PCI DSS) 6.5 (Version 2.0) and PCI DSS 6.6 (Version 1.2) are covered in PCI reporting. The administrator can configure Web Application Firewall to satisfy these PCI requirements.

You can generate and download the PCI report file on the Web Application Firewall > Status page.

Note This is not an official PCI Compliance report. It is for your self-assessment only.

In the report cover, the following information is displayed:

• The model, serial number, and firmware version of the appliance

• The user name of the person who downloaded the report, displayed as the author of the report

• Time when the report was generated

An example is shown below:

Two tables are dynamically generated in the PCI compliance report to display the status of each PCI requirement. The format of the table is shown in the example below:

The first column describes the PCI requirement.

The second column displays the status of the PCI requirement under current Web Application Firewall settings. There are 4 possible values for the status, distinguished by color.

• Satisfied (Green)

• Partially Satisfied (Orange)

• Unsatisfied (Red)

• Unable to determine (Black)

The third column provides comments and details explaining the status rating. If the status is Satisfied, no comments are provided.

How Does Cookie Tampering Protection Work?

SRA appliances protect important server-side cookies from tampering.

There are two kinds of cookies:

Server-Side Cookies – These cookies are generated by backend Web servers. They are important and have to be protected. They have optional attributes like Path, Domain, Secure, and HttpOnly.

Client-Side Cookies – These cookies are created by client side scripts in user browsers. They are not safe, and can be easily tampered with.

This feature is found on the Web Application Firewall > Settings page.

This page contains the following options:

Portals – A list of all application offloading portals. Each portal will have its own setting. The item Global is the default setting for all portals.

Tamper Protection Mode – Three modes are available:

• Prevent – Strip all the tampered cookies and log them.

• Detect only – Log the tampered cookies only.

• Inherit Global – Use the global setting for this portal.

Encrypt Server Cookies – Choose to encrypt name and value separately. This affects client-side script behavior because it makes cookie names or values unreadable. Only server-side cookies are encrypted by these options.

Cookie Attributes – The attributes HttpOnly and Secure are appended to server-side cookies if they are enabled.

The attribute HttpOnly prevents the client-side scripts from accessing the cookies, which is important in mitigating attacks such as Cross Site Scripting and session hijacking. The attribute Secure ensures that the cookies are transported only in HTTPS connections. Both together add a strong layer of security for the server-side cookies.

Note By default, the attribute Secure is always appended to an HTTP connection even if Cookie Tampering Protection is disabled. This behavior is a configurable option, and can be turned off.

Allow Client Cookies – The Allow Client Cookies option is enabled by default. In Strict mode, the Allow Client Cookies option is disabled. When disabled, client-side cookies are not allowed to be sent to the backend systems. This option does not affect server-side cookies.

Exclusion List – If the Exclusion List is enabled and contains a cookie, the cookie is passed as usual and is not protected. You can exclude server-side cookies and client-side cookies.

Exclusion list items are case sensitive, and in the format ‘CookieName@CookiePath’. Cookies with the same name and different paths are treated as different cookies. ‘CookiePath’ can be left empty to represent any path.

Import Global – Application Offloading portals can import the Global exclusion list.

How Does Application Profiling Work?

The administrator can configure application profiling on the Web Application Firewall > Rules page. Application profiling is performed independently for each portal and can profile multiple applications simultaneously.

After selecting the portal, you can select the type of application content that you want to profile. You can choose HTML/XML, Javascript, CSS, or All, which includes all content types such as images, HTML, and CSS. HTML/XML content is the most important from a security standpoint, because it typically covers the more sensitive Web transactions. This content type is selected by default.

Then the SRA appliance is placed in learning mode by clicking on the Begin Profiling button (the button then changes to End Profiling). The profiling should be done while trusted users are using applications in an appropriate way. The SRA records inputs and stores them as URL profiles. The URL profiles are listed as a tree structure on the Web Application Firewall > Rules page in the Application Profiling section.

Only the URLs presented as hyperlinks are accessible URLs on the backend server. You can click on the hyperlink to edit the learned values for that URL if the values are not accurate. You can then generate rules to use the modified URL profile.

The SRA learns the following HTTP Parameters:

• Response Status Code

• Post Data Length – The Post Data Length is estimated by learning the value in the Content-Length header. The maximum size is set to the power of two that is closest to and higher than this value. This accommodates the amount of memory that may have been allocated by the backend application. For example, for a Content Length of 65, the next power of two greater than 65 is 128. This is the limit configured in the URL profile. If the administrator determines that this is not accurate, the value can be modified appropriately.

• Request Parameters – This is the list of parameters that a particular URL can accept.

When an adequate amount of input has been learned, you can click the End Profiling button and are ready to generate the rules from the learned input. You can set one of the following as a default action for the generated rule chains:

• Disabled – The generated rules will be disabled rather than active.

• Detect Only – Content triggering the generated rule will be detected and logged.

• Prevent – Content triggering the generated rule will be blocked and logged.

If a rule chain has already been generated from a URL profile in the past, then the rule chain will be overwritten only if the Overwrite existing Rule Chains for URL Profiles check box is selected. When you click the Generate Rules button, the rules are generated from the URL profiles. If a URL profile has been modified, those changes are incorporated.

How Does Rate Limiting for Custom Rules Work?

The administrator can configure rate limiting when adding or editing a rule chain from the Web Application Firewall > Rules page. When rate limiting is enabled for a rule chain, the action for the rule chain is triggered only when the number of matches within a configured time period is above the configured threshold.

This type of protection is useful in preventing Brute Force and Dictionary attacks. An example rule chain with a Rule Chain ID of 15002 is available in the management interface for administrators to use as reference.

The associated fields are exposed when the Enable Hit Counters check box is selected at the bottom of the New Rule Chain or Edit Rule Chain screen.

Once a rule chain is matched, Web Application Firewall keeps an internal counter to track how many times the rule chain is matched. The Max Allowed Hits field contains the number of matches that must occur before the rule chain action is triggered. If the rule chain is not matched for the number of seconds configured in the Reset Hit Counter Period field, then the counter is reset to zero.

Rate limiting can be enforced per remote IP address or per user session or both. The Track Per Remote Address check box enables rate limiting based on the attacker’s remote IP address.

The Track Per Session check box enables rate limiting based on the attacker’s browser session. This method sets a cookie for each browser session. Tracking by user session is not as effective as tracking by remote IP if the attacker initiates a new user session for each attack.

The Track Per Remote Address option uses the remote address as seen by the SRA appliance. In the case where the attack uses multiple clients from behind a firewall that is configured with NAT, the different clients effectively send packets with the same source IP address and will be counted together.