1. Barracuda Web Application Firewall - Overview

1. Barracuda Web Application Firewall - Overview ...... 4 1.1 What's New in the Barracuda Web Application Firewall ...... 4 1.1.1 Release Notes Version 7.8.2 ...... 6 1.1.2 Release Notes Version 7.8.1 ...... 7 1.1.3 Release Notes Version 7.8 ...... 9 1.1.4 Release Notes Version 7.7 ...... 11 1.2 Deployment Options ...... 14 1.2.1 Choosing Your Deployment Mode ...... 14 1.2.1.1 Configuring Two-Arm Proxy Mode ...... 17 1.2.1.2 Configuring One-Arm Proxy Mode ...... 18 1.2.1.3 Configuring Bridge-Path Mode ...... 18 1.2.2 Public Cloud Hosting ...... 19 1.2.2.1 Microsoft Azure ...... 19 1.2.2.1.1 Deploying the Barracuda Web Application Firewall Vx - Microsoft Azure ...... 22 1.2.2.1.2 Barracuda Web Application Firewall Vx Quick Start Guide - Microsoft Azure ...... 25 1.2.2.1.3 Load Balancing For Clustered Barracuda Web Application Firewall Vx Instances in Microsoft Azure ...... 27 1.2.2.2 Amazon Web Services ...... 32 1.2.2.2.1 Barracuda Web Application Firewall Vx Deployment and Quick Start Guide for Amazon Web Services ...... 38 1.2.2.2.2 Load Balancing For Clustered Barracuda Web Application Firewall Vx Instances in Amazon Web Services (AWS) 45 1.2.2.2.3 Troubleshooting the Barracuda Web Application Firewall on Amazon Web Services ...... 49 1.2.3 Virtual Deployment ...... 49 1.2.3.1 Hypervisor Compatibility and Deployment - OVF Package ...... 50 1.2.3.2 Hypervisor Compatibility and Deployment - VMX Package ...... 51 1.2.3.3 Hypervisor Compatibility and Deployment - XVA Package ...... 52 1.2.3.4 Hypervisor Compatibility and Deployment - HyperV Package ...... 52 1.2.3.5 Barracuda Web Application Firewall Vx Quick Start Guide ...... 52 1.2.3.6 Sizing CPU, RAM, and Disk for Your Barracuda Web Application Firewall Vx ...... 54 1.2.3.7 Backing Up Your Virtual Machine System State ...... 55 1.3 Getting Started ...... 55 1.3.1 Step 1: Installing the Barracuda Web Application Firewall ...... 56 1.3.1.1 Prepare for the Installation ...... 56 1.3.1.2 Connect the Barracuda Web Application Firewall to the Network ...... 56 1.3.1.3 Configure the IP Address and Network Settings ...... 57 1.3.1.4 Configure the Barracuda Web Application Firewall from the Web Interface ...... 57 1.3.1.5 Activate the Subscription Status ...... 58 1.3.1.6 Update the Barracuda Web Application Firewall Firmware ...... 58 1.3.1.7 Update the Attack, Virus, Security and GeoIP Definitions ...... 58 1.3.2 Step 2: Configuring a Service ...... 59 1.3.3 Step 3: Configuring Basic Service Settings ...... 60 1.3.3.1 Configuring SSL for Services and Servers ...... 61 1.4 Services ...... 62 1.4.1 Creating an HTTP Service ...... 62 1.4.2 Creating an HTTPS Service ...... 63 1.4.3 Securing an HTTP Website with HTTPS ...... 63 1.4.4 Creating a Redirect Service ...... 63 1.4.5 Creating a Custom Service ...... 64 1.4.6 Creating a Custom SSL Service ...... 64 1.4.7 Creating an FTP Service ...... 64 1.4.8 Creating an FTP SSL Service ...... 64 1.5 Securing HTTP/HTTPS Traffic ...... 64 1.5.1 Security Policies ...... 65 1.5.1.1 Configuring Request Limits ...... 66 1.5.1.2 How to Secure HTTP Cookies ...... 67 1.5.1.2.1 Cookie Tampering Attacks Logged When the Barracuda Web Application Firewall Is Initially Deployed ...... 68 1.5.1.3 Configuring URL Protection ...... 68 1.5.1.4 Configuring Parameter Protection ...... 69 1.5.1.5 Limiting Allowed Methods in HTTP Headers and Content ...... 70 1.5.1.6 Configuring Cloaking ...... 70 1.5.1.7 Configuring Data Theft Protection ...... 71 1.5.1.8 Configuring URL Normalization ...... 73 1.5.1.9 Configuring Global ACLs ...... 73 1.5.1.10 Configuring Action Policy ...... 74 1.5.2 Back-end SSL Server Configuration ...... 75 1.5.3 Allow/Deny Rules for Headers and URLs ...... 76 1.5.3.1 Allow/Deny Rules for Headers ...... 76 1.5.3.2 Allow/Deny Rules for URLs ...... 76 1.6 Web Services and XML Firewall Protection ...... 77 1.6.1 Web Services ...... 77 1.6.2 Configuring XML Firewall to Protect a Web Application ...... 80 1.6.3 Web Service Validation ...... 81 1.7 Advanced Security ...... 82 1.7.1 Enabling Antivirus Protection for File Uploads and Downloads ...... 82 1.7.2 Enabling Data Theft Protection ...... 82 1.7.3 Enabling Brute Force Protection ...... 84 1.7.4 How to Configure Session Tracking ...... 85 1.7.5 Enabling Clickjacking Protection for a Service ...... 86 1.7.6 Configuring User Defined Patterns ...... 86 1.7.6.1 Regular Expression Notation ...... 90 1.7.7 How to Clear Locked Out Clients ...... 92 1.8 Application DDoS Attack Protection ...... 92 1.8.1 Configuring IP Reputation Filter ...... 93 1.8.2 Configuring DDoS Policy ...... 94 1.8.3 Slow Client Attack Prevention ...... 95 1.8.4 How To Configure Secure Browsing For An HTTPS Service ...... 97 1.9 Tuning Security Rules ...... 99 1.9.1 Tuning Security Rules Using Web Firewall Logs ...... 99 1.9.2 How to Configure Exception Profiling ...... 108 1.9.3 Configuring Action Policy for Attack Groups ...... 109 1.9.4 How to Configure Trusted Hosts ...... 111 1.9.5 Mitigating Website Vulnerabilities using Vulnerability Scanners ...... 112 1.9.6 How to Configure Adaptive Profiling ...... 114 1.9.7 Configuring Website Profiles ...... 117 1.10 Access Control ...... 124 1.10.1 How to Configure Authentication and Access Control (AAA) ...... 125 1.10.2 Kerberos Authentication ...... 130 1.10.3 How to Set Up a Custom Login Page for Authentication ...... 135 1.10.4 How to Configure Single Sign-On (SSO) ...... 137 1.10.5 How to Configure SiteMinder Single Sign-On (SSO) ...... 139 1.10.6 How to Integrate RSA SecurID with the Barracuda Web Application Firewall ...... 142 1.10.7 How to Integrate CA SiteMinder with the Barracuda Web Application Firewall ...... 151 1.10.8 How to Use Client Certificates ...... 165 1.10.8.1 Allowing or Denying Client Certificates ...... 165 1.10.8.2 Client Certificate Validation Using OCSP and CRLs ...... 166 1.10.8.3 How to Pass Client Certificate Details to a Back-end Server ...... 167 1.10.9 RSA SecurID Implementation ...... 168 1.10.10 How to Configure SMS Passcode Authentication Service ...... 174 1.10.11 How to Set Up a Custom Challenge Page for Authentication ...... 175 1.11 Traffic Management ...... 176 1.11.1 Load Balancing Overview ...... 177 1.11.2 Configuring Load Balancing for a Service ...... 179 1.11.2.1 Configuring Server Settings ...... 180 1.11.2.2 How to Add a Real Server ...... 182 1.11.3 Configuring Caching and Compression ...... 183 1.11.4 How to Configure Rate Control ...... 185 1.11.5 Using Connection Pooling: How and Why ...... 186 1.11.6 Content Routing ...... 187 1.11.6.1 How to Add a Content Rule ...... 187 1.11.6.2 How to Redirect Traffic to a Different Back-end Server Based on a URL Pattern ...... 187 1.11.7 Content Rewriting ...... 188 1.11.8 How to Allow Internet Access for the Back-end Servers in Two-Arm Proxy Mode ...... 191 1.12 Logging, Reporting and Monitoring ...... 192 1.12.1 How to Configure Syslog and other Logs ...... 192 1.12.2 How to Make the Client IP Address Available to the Back-end Server in Proxy Mode ...... 208 1.12.2.1 Configuring Client Impersonation ...... 215 1.12.2.2 Logging Actual Client IP Address on the Apache Server ...... 216 1.12.2.3 Logging Actual Client IP Address In the IIS 7 and IIS 7.5 Server ...... 216 1.12.3 How to Mask Sensitive Data in Logs ...... 222 1.12.4 Reporting ...... 223 1.12.5 How to Set Up Barracuda Cloud Control ...... 223 1.12.6 Receiving Trap Messages and System Alerts ...... 224 1.12.7 System Log Messages ...... 225 1.13 High Availability ...... 255 1.13.1 How to Set Up a High Availability Environment with Two Barracuda Web Application Firewalls ...... 257 1.13.2 Failover and Failback in an Active-Active Cluster ...... 258 1.13.3 How to Remove or Replace Units in a Cluster ...... 261 1.14 Networking ...... 262 1.14.1 Network Address Translation (NAT) ...... 263 1.14.2 Access Control List (ACL) ...... 264 1.14.3 ACLs for Forwarded Traffic ...... 265 1.14.4 Virtual Local Area Network (VLAN) ...... 265 1.14.5 Routes ...... 266 1.14.6 Interfaces ...... 266 1.14.7 Configuration ...... 267 1.15 System Administration and Maintenance ...... 267 1.15.1 Updating Firmware on the Barracuda Web Application Firewall ...... 268 1.15.2 Backing up and Restoring your System Configuration ...... 269 1.15.3 Scheduling Automated FTP Backups ...... 269 1.15.4 Scheduling Automated SMB Backups ...... 270 1.15.5 How to Configure Role Based Administration ...... 271 1.15.6 Using Templates to Save and Import Configuration Objects ...... 274 1.15.7 Updating the Firmware in Clustered Units ...... 276 1.15.8 Barracuda Web Application Firewall Hardware Features ...... 277 1.15.9 How to Clear Configuration on the Barracuda Web Application Firewall ...... 283 1.15.10 Rebooting the System in Recovery Mode ...... 283 1.15.11 Replacing a Failed System ...... 284 1.16 Certificate Management ...... 285 1.16.1 Introduction to Certificates ...... 285 1.16.2 How to Add an SSL Certificate ...... 286 1.16.3 Using Client Certificates ...... 288 1.16.4 Installing SSL Certificates with Correct Chain Order ...... 288 1.16.5 Creating a Client Certificate ...... 290 1.17 SNMP GET Commands ...... 292 1.18 Extended Match Syntax Help ...... 293 1.19 Attacks Description - Action Policy ...... 295 1.20 How to Use IPV6 ...... 335 1.21 Evaluation Policy and Flow ...... 336 1.22 Limited Warranty and License ...... 348 Barracuda Web Application Firewall - Overview en The Barracuda Web Application Firewall blocks an ever-expanding list of sophisticated web-based intrusions and attacks that target applications hosted on web servers and in the cloud. The Barracuda Web Application Firewall scans all inbound web traffic to block attacks, and inspects the HTTP responses from the configured back-end servers for Data Loss Prevention (DLP). The integrated access control engine enables administrators to create granular access control policies for Authentication, Authorization & Accounting (AAA) without having to change the application. The onboard L4/L7 Load Balancing capabilities enable organizations to quickly add back-end servers to scale deployments as they grow. Its application acceleration capabilities like SSL Offloading, caching, compression, and connection pooling ensures faster application delivery of the web application content.

The Barracuda Web Application Firewall is available in multiple models and can be used to securely deploy applications of any size. For information on available models, refer Barracuda Web Application Firewall Datasheet and 860/960 Hardware Datasheet.

Where to Start

Learn about your Deployment Options.

If you have the Barracuda Web Application Firewall Vx virtual machine, start here: Virtual Deployment .

If you have the Barracuda Web Application Firewall appliance, start here: Getting Started.

Alternatively, you can download the Barracuda Web Application Firewall Quick Start Guide.

Key Features

Protection against common, high-visibility attacks – SQL injection, Cross Site Scripting, Command injection, CSRF, XML attacks, Antiviru s Protection, Adaptive Profiling Protection against attacks based on session state – Session Hijacking, Cookie Tampering, Clickjacking Brute Force Attack Prevention Application denial of service (DoS) protection – Slow Client Attack, DDoS Prevention using CAPTCHA, IP Reputation Filter Data Theft Protection – Deep inspects all server responses to prevent leakage of sensitive information using provided default patterns (credit card data, social security numbers, etc.) or User Defined Patterns (Custom Patterns). Website Cloaking – Strips identifying banners of web server software and version numbers and provides customizable HTTP error handling to defeat server fingerprinting attacks (Suppressing error codes and filtering headers). Access Control – Form and Basic Authentication and Single Sign On with integrations into LDAP, RADIUS, CA SiteMinder, RSA SecurID, Kerberos, SMS Passcode Application Delivery – Load Balancing, Caching and Compression, SSL Offloading, Rate Control Logging, Reporting and Monitoring – Inbuilt reporting module, Web Firewall Logs, Access Logs, Audit Logs, Configuring Syslog

Additional Resources

Barracuda Web Application Firewall REST API Guide Configuring Syslog and other Logs System Log Messages Mitigating Website Vulnerabilities using Vulnerability Scanners What's New in the Barracuda Web Application Firewall en What's New in Version 7.8

Security

DDoS Enhancements: Administrators can define policies for specific URL spaces to ensure suspicious clients are challenged with a CAPTCHA for verification. These challenges thwart DDOS attacks on process and memory intensive resources of the back-end applications from bots and crawlers. Configure challenges using the WEBSITES > DDoS Prevention page. Additionally, CAPTCHA challenges can also be invoked as a Follow Up Action to other attacks, such as SQL Injection, via the Security Policies > Action Policy feature. Use this to detect and thwart automated tool attempts to repeatedly scan the website for vulnerabilities and waste resources. For example, sqlmap tool scanning for SQLi can be blocked.

4 Barracuda Blocklist Integration: Barracuda Blocklist is an extensive IP reputation system that lists IP addresses that are open proxies or are botnet infected. The system relies on honeypots to flag both web and spam botnets, which are used interchangeably, depending on the need. Under a DDoS attack, these addresses can be blocked with a single click to deflate the attack, with minimal false positive risk. Configure this on the WEBSITES > DDoS Prevention page. True File type checks for File Uploads: In earlier releases, file extension checks could be evaded on a file upload by changing the extension to match one of the whitelisted extensions. As of this release, such evasions are detected by fingerprinting the file, thus establishing its true MIME type for comparison to the whitelist. For example, this prevents a hacker from changing a file extension from .exe to .doc to upload it, since it will be evaluated to application/octet-stream and blocked (assuming the latter has not been added to the Allowed Mime Types on the WEBSITES > Parameter Protection page). Kerberos Authentication: The AAA module has been enhanced to support Kerberos authentication to back-end services like OWA and SharePoint using Kerberos. The front-end authentication is form based while the back-end uses the Kerberos protocol. Clickjacking Protection: Clickjacking and UI redressing attacks can now be prevented by enabling Clickjacking protection from the WEBSITES > Advanced Security page.

Cryptography

SNI support: SNI (Server Name Indication ) extension to SSL is now supported. This is particularly useful in a virtual hosting scenario where organizations may have several domains hosted on a single server using the same IP address and each domain has a distinct SSL certificate. CRL (Certification Revocation Lists) support: Client certificate CRLs can be automatically retrieved over HTTP and can be updated periodically by the system. Backup Enhancements: System backups can now be done over FTPS. Performance and Stability improvements: Rearchitected SSL modules now ensure higher transactions per second and throughput support with less memory footprint and reduced risk of race conditions than earlier releases.

Networking

Synchronization for Network elements: The following objects are now synchronized across the cluster: (1) VLANs (2) Static routes (3) Interface routes and (4) ACLs. Interfaces in Management network group will not be synced in cluster. Backup Enhancements: NTLM V2 is now supported while taking system backup. Deployment: System IP can now be on a VLAN interface. Persistence Enhancements: The Load balancing module can use HTTP header based persistence for directing traffic to back-end servers.

Usability improvements

Clients locked out by the configured Follow Up Action of Block Client can now be unblocked manually by the administrator on the WEBSITES > Advanced Security page. Parameter profile viewing preferences have been added on the WEBSITES > Website Profiles page. In a clustered setup, the Join Cluster operation is now available when the Failback Mode is manual, no longer only when in automatic mode. NIC speed, duplexity and statistics can now be viewed and edited from ADVANCED > Advanced Networking, under the configuration for Network Group: System. This is only available when Show Advanced Settings is set to Yes under ADVANCED > System Configuration. Access Logs now have a host filter. Interface routes and Custom Virtual Interfaces can now be edited. The login page can now display a custom message to comply with FISMA, which requires federal systems to display an access notice on the login pages. A new tool indicates how an IP address is categorized in the Geo IP database. The data path can be manually restarted after an attack definitions update.

Logging and Reporting

The logging module has been enhanced to integrate with IBM QRadar SIEM System.

For detailed information on fixes and enhancements in the Firmware Version 7.8, see Release Notes Version 7.8.

What's New in Version 7.7

Firmware version 7.7 of the Barracuda Web Application Firewall is a major firmware release enhancing security and networking capabilities including:

Security

5 Protection From Slow Client Attacks: Tools designed by network and security experts to test the robustness of their networks are now being used by the hacker community to attack the applications. Some of these attacks are done using Slowloris, PyLoris, QSlowLoris, slowhttprequest type of tools. The Barracuda Web Application Firewall augments its security capability by adding a variable traffic window detection algorithm to thwart these attacks. See Slow Client Attack Prevention. Access Blocked Based On Client IP Reputation: Protecting your network against botnet requires a multi-pronged strategy. One step in that direction is to control access to the applications based on IP reputation. The reputation of an IP address is dependent on attributes such as geographic location of the IP address or its identity as an anonymous proxy. The Barracuda Web Application Firewall now provides an easy way to block out clients based on Geo Location, Anonymous Proxy identity or Satellite ISP identity. See Configuring IP Reputation Filter. Armored Browser Integration: The Barracuda Web Application Firewall now integrates with the Quarri Protect On Q armored browser to extend security coverage to the client side. Enhanced Shared Security Policies: CSRF can be enabled using the shared security policy. Enhanced max instances check for parameters which prevent a class of HTTP Parameter pollution attacks, for wild card parameter profiles. Finger Print Evasion: Administrators can now change the system generated tokens such as ncforminfo, BNES_ or BNIS_.

Networking

Advanced Routing Capabilities: A virtual site is now a networking entity with its own routing tables and ACLs, allowing services on the Barracuda Web Application Firewall to be grouped by their routing requirements. See Networking. Network ACL: Traffic to the server networks can be restricted using network layer ACLs. Network ACLs can now be configured for traffic that is being NATed or proxied via the Barracuda Web Application Firewall.

Deployment

Active-Active HA: Two Barracuda Web Application Firewalls in a clustered environment can be configured to have active services on them, and to failover/failback if one of the units fail. See High Availability. IPv6 Enhancements: Enhanced stability and improvements in the IPv6 functionality.

Usability improvements

Integration with Cenzic for vulnerability patch management. Bulk edit for Services page. Persistence of node expansion state in the BASIC > Services page.

Logging and reporting enhancements

Service level SNMP stats: The enhanced SNMP MIB now supports multiple statistics at the application level. System Logs, (e.g., server up and server down events) are now displayed on the web interface. Syslog NG integration. Integration with Splunk and Arcsight now available.

For detailed information on fixes and enhancements in the Firmware Version 7.7, see Release Notes Version 7.7. Release Notes Version 7.8.2 en

The 7.8.2 release has enhancements and fixes exclusively for the Barracuda Web Application Firewall Vx deployed on Azure and AWS ONLY.

Fixes and Enhancements in 7.8.2

In the Azure cloud deployment, configuration amongst systems can be synchronized in a active/active cluster of two or more nodes. [BNWF-15475] In the Azure cloud deployment, the Virtual IP for services is fixed to the WAN IP address and cannot be changed. [BNWF-15855], [BNWF-15838] The Barracuda Web Application Firewall now supports REST based APIs for configuration of Services, Security Policies, Certificates and Clustering. [BNWF-15474] The “Allowed API IP/Range”, “Operation Mode”, “Addresses” and “Interface for System Services” modules are not available in the Barracuda Web Application Firewall Vx deployed on Azure and Amazon Web Services. [BNWF-15902], [BNWF-15911]

6 The REST API guide can be downloaded here: Barracuda Web Application Firewall REST API Guide. Release Notes Version 7.8.1 en

Please Read Before Updating

Before installing any firmware version, be sure to make a backup of your configuration and read all release notes that apply to versions more recent than the one currently running on your system.

Do not manually reboot your system at any time during an upgrade, unless otherwise instructed by Barracuda Networks Technical Support. The update process typically takes only a few minutes after the update is applied. If the process takes longer, please contact Barracuda Networks Technical Support for further assistance.

Please make sure that the system has attack definition 1.45 if the system is being upgraded using the offline upgrade process. The upgrade to 7.8.1 may take little longer time due to kernel upgrade. For this reason, you might see the web interface coming up before the actual upgrade completes. It is recommended to wait for few minutes (approximately 10 minutes) after the web interface comes up, and then continue accessing the box.

Fixes and Enhancements in 7.8.1

Security

Feature: Tor exit nodes can now be blocked from accessing services. [BNWF-15295] Feature: An irreversible hash is performed on the user passwords including the admin password to ensure password secrecy in the system. [BNWF-14816] Enhancement: The CSRF token embedded in the form can have validity period/expiry time set when CSRF Prevention is set to "Forms" or "Forms and URLs". [BNWF-15346] Enhancement: The double decoding is now applied to URL before deep inspection. [BNWF-15286] Enhancement: The encryption algorithm used for backup file now supports multibyte/wide characters. [BNWF-15276] Enhancement: Support for normalization of Microsoft %u encoding before deep inspection. [BNWF-15221] Enhancement: Deep inspection is now applied for "text/plain" content types in POST body parameters. [BNWF-14836] Fix: An issue with flow control in SSL layer, which may affect large size SSL transactions is addressed. [BNWF-15736] Fix: The CSRF protection for forms with action URL as "#" was causing false positives. This issue has been fixed. [BNWF-15219] Fix: An issue where authorization policies not getting displayed has been fixed. [BNWF-15205] Fix: False positives in CSRF protection in case of direct access to URL from a valid reference has been fixed. [BNWF-15183] Fix: Protection against Apache range header DoS has been added. No more than 5 range-bytes can be requested. [BNWF-15104] Fix: XML data which has TRANSACTION node is masked now. [BNWF-15065] Fix: Mime type detection works for multiple file uploads. [BNWF-14679]

Networking

Enhancement: Prioritization of Network ACL is now supported. [BNWF-15237] Fix: IP rules for MGMT static routes get correctly synchronized on the secondary in the cluster. [BNWF-15533] Fix: Upper limit for network ACL priority has been removed. [BNWF-15172] Fix: Interface status will not be shown as DOWN if the IP address has not been configured. [BNWF-15076] Fix: STM crash issue during a brute force attack where more than 2 million concurrent connections are attempted on the Service has been resolved. [BNWF-14842] Fix: Restoring a backup does not affect the values of management routes and system routes of a system. [BNWF-14710]

Access Control

Feature: The domain information of the client is forwarded to the server along with the user credentials in the Basic Authentication Header when Send Basic Authentication is set to Yes (ACCESS CONTROL > Authorization). [BNWF-15444] Feature: For MS LDAP authentication, if the server indicates an expired password, the Barracuda Web Application Firewall can redirect the user to reset it. [BNWF-14830] Fix: Accessing a page with multiple web links in Kerberos authentication service was sometimes causing the user to get logged out abruptly. This issue has been fixed. [BNWF-15667] Fix: LDAP lookups for RBA now supports group filters. [BNWF-14562]

7 Cloud Hosting

Feature: Ability to automatically get the DNS server IP address during provisioning of the Barracuda Web Application Firewall Vx in the Azure cloud. [BNWF-15143]

System

Feature: Automatic recovery from a Bypass state is now possible without the need for rebooting the appliance. [BNWF-15491] Feature: Optimizations to reduce the overall configuration commit times for large configurations. [BNWF-14810] Enhancement: Henceforth, the attack definitions are not activated automatically until "Enable Auto Apply Attack Definition" is set to Yes on the ADVANCED > System Configuration page manually. This setting is implemented to ensure that the activation of definition can be carried out during the production maintenance window. [BNWF-15250] Enhancement: Apart from the "admin" user, LDAP users with "admin" role also have permissions to restore backup. [BNWF-15238] Enhancement: The new version 7.8.1 has an updated core kernel to address rare kernel panics reported on Barracuda WAF. [BNWF-14817] Enhancement: FTP Allowed Verbs list now includes MLSD and MLST commands. [BNWF-7302] Enhancement: IP Reputation Filter is now available in Bridge mode. [BNWF-14761] Enhancement: Some important processes which relate to the management of the Barracuda Web Application Firewall now run with constrained privileges to prevent any misuse of privileges by potential attackers. [BNWF-14851] Enhancement: TCP dump captures bi-directional traffic for specified IP/Port. [BNWF-14729] Fix: Option to use SSL v3.0 in addition to all TLS versions for back-end SSL added. [BNWF-15735] Fix: A race condition in datapath process when Authentication was enabled for a SSL service has been fixed. [BNWF-15519] Fix: An issue where the Service was showing Active even when all servers were down has been fixed. [BNWF-15511] Fix: The "default" policy in Action Policy now includes secure-browsing, slow-client-attack, and captcha. [BNWF-15384] Fix: A possible race condition in case of arrival of multiple pipelined requests has been fixed. [BNWF-15246] Fix: Cipher suite preference can now be enforced from the service rather than relying only on the client's preference. [BNWF-15231] Fix: Chained certificates uploaded in PFX format are now arranged according to the certificate hierarchy. [BNWF-15015] Fix: Instances of Certificates page not getting displayed issue has been fixed. [BNWF-15192] Fix: The redirect URL can now include query string parameters in it. [BNWF-15139] Fix: Configuration rollbacks during "Policy Fix" operation in Web Firewall Logs has been fixed. [BNWF-15136] Fix: Issue with a possible outage when learning is enforced from trusted hosts, is fixed. [BNWF-15016] Fix: If the installed attackdef version is higher than new firmware's attackdef, firmware upgrade will not upgrade the attackdef. [BNWF-14995] Fix: Response body rewrite now honors Content Type: application/json. [BNWF-14952] Fix: All cipher suites are carried over to the upgraded version when the firmware version of the Barracuda Web Application Firewall is upgraded. [BNWF-14938] Fix: In rare cases FTP proxy was aborting connection randomly when multiple files were uploaded. This issue has been fixed now. [BNWF-14891] Fix: Configuring a rewrite condition with the macro X509_OU for a request rewrite rule is not allowed. [BNWF-14760] Fix: Caching a large number of big size files was causing the STM process to crash. This issue has now been fixed to handle. [BNWF-14730] Fix: Concurrent session issue while uploading the wsdl/schema file is resolved. [BNWF-5468]

Logging and Reporting

Feature: The interface IP address information is now included in problem report files as well as configuration snapshot files to aid troubleshooting. [BNWF-14790] Fix: Unit serial number is added to the file names generated by the reporting module. [BNWF-15079] Fix: Logs exported via FTP now export completely, upto a maximum of 500K entries. [BNWF-15034] Fix: Special characters such as ? In the requests are correctly handled to ensure that the syslog entries are not sent with incorrect Syslog Facility. [BNWF-14991]

Management

Feature: Redirect action can be configured as temporary redirect or permanent redirect resulting in the Barracuda Web Application Firewall using 301 or 302 response codes respectively. [BNWF-12212] Fix: Service related statistics can be enabled in the BASIC > Status page only if there is atleast one service of type HTTP. [BNWF-15039] Fix: It's now possible to generate and download Problem Report in the Japanese web interface. [BNWF-14736] Fix: Relative URLs can be specified in redirect URL for Action Policy. [BNWF-12401]

High Availability

8 Feature: Under Bridge mode, (Link Loss Carry Forward) LLCF is now supported. If enabled, either WAN or LAN going down causes the other one to be brought down forcibly. [BNWF-6070] Fix: In Bridge mode, the disjoin operation is not supported if the Primary unit is in Passive state. [BNWF-15374]

Release Notes Version 7.8 en

Please Read Before Updating

Before installing any firmware version, be sure to make a backup of your configuration and read all release notes that apply to versions more recent than the one currently running on your system.

Please make sure that the system has attack definition 1.45 if the system is being upgraded using the offline upgrade process.

Fixes and Enhancements in 7.8

Security

Feature: Barracuda IP reputation database (BBL) is now integrated with the Barracuda Web Application Firewall. [BNWF-13834] Feature: The extension "*.css" is added by default to the list of Excluded URL patterns under the website profiles. [BNWF-13661] Enhancement: New action policies have been added for DDoS policies using Captcha based protection.[BNWF-14655] Enhancement: Response body rewrite is now performed for the content-type "application/x-java-jnlp-file" too. [BNWF-14608] Enhancement: OWA 2010 is added to the list of default Security Policies. [BNWF-11698] Fix: Sensitive parameter names that needs to be masked can include colon (:) in it. [BNWF-14281] Fix: The sensitive parameters in the query string are cloaked when a request matches the rule group. [BNWF-14641] Fix: The encoded parameters in the URL are not decoded once the SSO Cookie Update Interval is triggered. [BNWF-14522] Fix: The follow up action in the action policy feature is now fixed to check for values in the x-forwarded-for headers. [BNWF-14255] Fix: SOAP1.2 requests are checked for attacks and blocked. [BNWF-14220] Fix: Secure browsing feature is now compatible with Safari and Firefox browsers running on Macintosh computers. [BNWF-14204] Fix: A reflexive XSS vulnerability in the URL ACL name field has been fixed. [BNWF-14151] Fix: An attack variant of an SQL injection attack that uses white space characters for obfuscation can be blocked through an addition of a new pattern called "SQL-Command-strict" to the SQL Strict pattern list. [BNWF-13371] Fix: All the configured Authorization policies in the Access Control > Authorization page are now visible to an administrator. [BNWF-13481] Fix: Cookie entries can include a # in the name. [BNWF-13479] Fix: Forceful browsing of /README URI is not allowed. [BNWF-12046] Fix: The SSLv3/TLS attack referred in CVE-2009-3555 has been addressed. [BNWF-4970] Fix: Response headers are suppressed/cloaked for all pre-defined security policies. [BNWF-4444] Fix: Pattern algorithm can now be configured for input types and attack types. [BNWF-889]

Networking

Enhancement: The ACLs , routes for the management network are now synchronized as part of the configuration synchronization in a cluster. [BNWF-14453] Enhancement: Ability to have system IP address on a VLAN interface. [BNWF-5013] Fix: Source port range and destination report range options are disabled if the protocol selection is "All-Protocols" during ACL configuration. [BNWF-14203] Fix: The configuration file restore operation on a different system ensures proper import of static routes created under the management network group. [BNWF-14202] Fix: Multiple source NAT policies can be created if the source port value is different in each policy. [BNWF-14180] Fix: An issue where the interface routes were not persistent across reboots has been fixed. [BNWF-13846] Fix: The external syslog server communication is initiated through the required interface after checking the routing table. [BNWF-13600] Fix: With certain NAT or firewall devices, aggressive socket recycling could lead to dropped SYN requests due to differing timestamps sequences from the devices for multiple hosts behind them. The system now employs a safer alternative of reusing sockets that works

9 well with remote NAT devices and doesn't reduce performance either. [BNWF-11488]

System

Feature: Persistence method based on HTTP headers can be configured for server load balancing under the service configuration. [BNWF-14124] Feature: A certificate revocation list can be configured on the Barracuda Web Application Firewall. [BNWF-13739] Feature: Ability to unblock clients that got blocked due to a follow up action configuration. [BNWF-13707] Feature: It is now possible to select the required cipher suites for SSL negotiation. [BNWF-13769] Feature: Multiple certificates can be associated to a single Service, using SNI. [BNWF-13678] Enhancement: Client IP address is logged in the System Logs when the verification of client certificate fails. [BNWF-14493] Enhancement: Report graphs are now displayed with all legends in High Chart layout. [BNWF-14364] Enhancement: Remote Support can now be enabled through console to override the disable option set in web UI. [BNWF-14574] Enhancement - The default access control login page for a service can be modified to include a descriptive text. [BNWF-13502] Enhancement: Widget to select HTTP Methods has been added to filter the logs (Web Firewall and Access Logs). [BNWF-1359] Fix - The appliances that are not connected to the internet for activation can now be activated offline. [BNWF-13873] Fix: Browsers cannot save the password for the authentication login page automatically. [BNWF-14362] Fix: Trusted hosts IP addresses are also checked while inserting values for client IP address if "Header for Client IP address" option is configured. [BNWF-14640] Fix: A service group cannot be deleted until all the Services within the group are deleted. [BNWF-14465] Fix: An issue where a TCP connection between the client and the Barracuda Web Application Firewall was getting abruptly closed due to receiving a 401 response from the back-end server during NTLM authentication handshake has been fixed. [BNWF-13826] Fix: When authentication service is created to use LDAP over SSL, credentials are not cached thus allowing valid credentials to be used after a failed login attempt. [BNWF-13801] Fix: An issue which resulted in heart beat traffic with the wrong version being used after a firmware upgrade is now fixed. [BNWF-13730] Fix: It is now possible to configure a rewrite condition while configuring a request rewrite rule. [BNWF-13726] Fix: Template for URL ACLs now displays only the list of Service(s) that have URL ACLs configured in it. [BNWF-11432] Fix: Administrator can set the required ICMP response code while configuring Network ACLs. [BNWF-12382] Fix: Passive mode FTP on Microsoft IIS FTP is supported. [BNWF-13298]

Logging and Reporting

Feature: Client IP addresses are included in system logs messages generated for renegotiation and handshake abortions. [BNWF-13781] Enhancement: Ability to change the font type while generating the reports in HTML or PDF format. [BNWF-12772] Fix: An issue while filtering the logs (Web Firewall/Access/Audit Logs) using Time as an additional filter has been fixed. [BNWF-13691] Fix: The virtual IP address is not duplicated in the database after the firmware upgrade. [BNWF-13778] Fix - Booting up issues on virtual machine instances installed on Citrix XEN Hypervisor have been fixed. [BNWF-14270] Fix: Server Time field in access logs was not displaying proper time in some cases. Fixed now. [BNWF-14410] Fix: In some cases, the cookie tampered logs were not logged due to the event manager process crashing. This issue has been fixed. {BNWF-14460] Fix: All necessary fields as prescribed by ArcSight SIEM are now added in the log format while configuring export log. [BNWF-13899] Fix: The log severity for the OCSP status check logs has been changed from error to Notice/Information. [BNWF-13841] Fix: In rare cases, the Web Firewall and Access Logs were not updated correctly. This issue has been fixed. [BNWF-13716] Fix: An issue that resulted in the configuration summary report for the URL profile and ACL getting generated as a blank report is now fixed. [BNWF-13660] Fix: Custom headers in the Access Logs display proper information. [BNWF-12987] Fix: Issue of logging random IP addresses when Header Name for Actual Client IP is specified and header has non-numeric value has been fixed. [BNWF-12979]

User Interface

Feature: IP lookup tool is now provided to check the IP categorization based on location. [BNWF-13740] Feature: Bulk edit option has been provided to edit file upload extensions. [BNWF-13659] Enhancement: Bulk edit option is available for ACLs, Static Routes, Interface Routes and Custom Virtual Interfaces. [BNWF-11621] Fix: The X509_subject macro is now handled correctly in request rewrite rules. [BNWF-14723] Fix - Local Host Map entries on the BASIC > IP Configuration page can now be bulk edited. [BNWF-13998] Fix: CPU Utilization graph on the BASIC > Status page displays accurate value for the time scale "Month". [BNWF-14344] Fix: When CSRF protection is enabled under the URL protection, a PCI report generation on the Barracuda Web Application Firewall will show CSRF protection as "fully satisfied". [BNWF-14052] Fix : An issue which prevented an admin from editing the "More action" link in the Japanese language UI is now fixed. [BNWF-13733] Fix: An issue which resulted in the security policies not getting shown in the UI after a join cluster operation has been fixed.

10 [BNWF-13728] Fix: Syslog details contain login/logout activity of Guest user. [BNWF-12828] Fix: Preferences option is available to set the Parameter profiles to be displayed per page. [BNWF-12692] Fix: Trusted certificates getting deselected automatically while editing the Service has been fixed. [BNWF-11008]

Management

Enhancement: FTP Allowed Verbs list now includes MLSD and MLST commands. [BNWF-7302] Fix: An STM crash due to the brute force prevention feature is now fixed. [BNWF-14553] Fix: In some instances, the website profiles page displayed the directory structure information incorrectly. This has been fixed. [BNWF-14478] Fix: It is now possible to backup configuration remotely using NTLMv2 authentication. [BNWF-14450] Fix: Ability to configure a custom admin role with permission to APPLY-FIX-FOR-ATTACKS which allows the user to apply policy violation fix rules in web firewall logs. [BNWF-14372] Fix: An issue where the SNMP agent on the Barracuda Web Application Firewall would not respond to SNMP queries due to heavy system load has been fixed. [BNWF-14321] Fix: SMB share names with white space can now be added during remote backup configuration. [BNWF-14296] Fix: Having a password less than five (5) characters in SNMP Manager was preventing further configuration changes under the Administration tab. This issue has been fixed now. [BNWF-14188] Fix: It’s possible to configure `--no-check-certificate' option while specifying the target URL for wget troubleshooting option. [BNWF-14059] Fix: An issue where client impersonation feature stopped working after a firmware upgrade is fixed. [BNWF-13820]

High Availability

Fix: Join Cluster operation does not remove Management routes on the secondary/backup device. [BNWF-14420] Fix: An issue where the services stopped working due to incorrect system gateway information during cluster synchronization tasks has been fixed. [BNWF-14359] Fix: Cookie persistency is applied during HA failover. [BNWF-13927] Fix: In some instances, the services were not getting failed over to the peer system in the HA. This is now fixed. [BNWF-13684] Fix: Service disruption after recovering from network partitioning in cluster where the failback mode was set to manual has been fixed. [BNWF-14776]

Release Notes Version 7.7 en

Please Read Before Updating

Before installing any firmware version, be sure to make a backup of your configuration and read all release notes that apply to versions more recent than the one currently running on your system.

Please make sure that the system has attack definition 1.45 if the system is being upgraded using the offline upgrade process.

Fixed in Version 7.7

Security

SSL

Fix for SSL renegotiation vulnerability, CVE-2009-3555.[BNWF-11177] Fix for SSL BEAST attack, CVE-2011-3389: ciphers can be preferred or enforced. [BNWF-12541] Back-end SSL connections from the Barracuda Web Application Firewall to the web servers can now be validated using trusted certificates. [BNWF-4963] OCSP certificate validation is supported. [BNWF-10260]

11 Cookie Security

Internally generated cookies for signing and encryption now reflect the path and expiry set by the application. [BNWF-10073] Cookies are no longer dropped if the Action Policy setting mismatched-IP-cookie-replay-attack is set to None. [BNWF-8771]

Website Profiles

The learning of Parameter profiles is improved by removing the restrictions of name lengths from the existing 255 character limitation. [BNWF-11309] The upper limit for Max Content Length and Max Value Length has been increased for profiles: [BNWF-1602] Max Content Length is now configurable up to 1GB for URL profiles Max Value Length is now configurable up to 1GB for Parameter profiles. In rare cases profiling engine was adding duplicate parameter profiles without considering the case and length of the parameter’s name. This issue has been fixed. [BNWF-10521] Apply Fix option is now available for unknown content types in POST body in added URL profiles. [BNWF-10256] It is now possible to import URL profiles having parameter profile names more than 64 characters. [BNWF-9221]

Request Limits

Request limits can now be set to a discrete length: [BNWF-10872] Max Request Length – increased to 512k Max Request Line Length – increased to 128k Max URL Length – Increased to 16k Max header length is increased to 64k. [BNWF- 9255] Issues with multiple simultaneous large file (1.5 GB or larger) uploads resolved. [BNWF-8431] In rare cases Keep Alive headers were triggering false positives when the value is not a numeric. This issue is fixed now. [BNWF-12215] Strict patterns added to help prevent SQL injection, OS command, Cross Site Scripting and Remote File Inclusion based attacks. [BNWF-4486]

XML Validations

Error handling added for malformed WSDL files. [BNWF-11229]

Allow / Deny Rules

A configuration rollback no longer occurs when two URL ACL deny rules have similar URL matches which differ in case. [BNWF-10636]

Access Control

The Barracuda Web Application Firewall now does not perform anonymous bind request to the LDAP server when authenticating the user. [BNWF-12081] SiteMinder response attributes are now sent along with the initial request to protected resources. [BNWF-12591] When creating an authorization rule, the upper limit for the Allowed Users field has been extended to 45 characters. [BNWF-12045] Logs of the Access Control Module are now integrated into the System logs. [BNWF-10147] Users are now authenticated even when LDAP bind password is reconfigured in the LDAP configuration for external authentication of admin access control users. [BNWF-8317] Local RBA users are now required to enter a confirm password when adding or editing Local Administrators. [BNWF-7331]

Networking

Back-end servers can now reach the internet even when both SNAT and Stateful Network Firewall are enabled. [BNWF-10458] Independent default gateways can now be configured for WAN, LAN and MGMT interfaces. [BNWF-4868] After upgrade, servers on the LAN side can now reach the internet without manually disabling and re-enabling SNAT. [BNWF-4965] Default gateways can now be configured per VLAN. [BNWF-7181] Independent network settings can now be configured for each Vsite. [BNWF-6354]

System

Chunked encoded responses from the server without the terminating "/r/n" at the end are now processed by the Barracuda Web Application Firewall. [BNWF-3050] Persistence Idle Timeout for client IP persistence is increased to 86400 seconds. [BNWF-10125] Huge welcome banners are now supported for FTP services. [BNWF-10968] Client Impersonation feature now works in one-arm proxy deployment. [BNWF-6721]

12 The session timeouts can now be configured larger than 180 seconds. [BNWF-4660] POST requests are now handled correctly when Content-Type contains “Charset=”. [BNWF-10224] SSL renegotiation is now honored when initiated from the back-end server. [BNWF-8239] The rare case in which huge FTP downloads were terminated, no longer occurs. [BNWF-3289] URL encoded POST- Requests with parameter values greater than 1M in URL encoded POST are now allowed. [BNWF-10107] In rare circumstances malformed HTTP requests caused latencies. This issue is now fixed. [BNWF-5033] The configured port range for FTP Passive mode is now correctly utilized by the clients. [BNWF-7957] Packet captures taken from the Troubleshooting page now have .pcap extension without any integer appended (e.g., pcap0). [BNWF-7655] LAN and MGMT interfaces can now be configured from the console. [BNWF-9039] Increased STM stability under large values of null parameters. Uploading a PFX file that does not have a password is allowed. [BNWF-7355] Issue regarding rendering energize update page has been resolved. [BNWF-11160] Connection pool was getting timed out after 180 seconds in spite of configured value being higher. This issue is fixed now. [BNWF-7024] Administrators can now configure From Address for the email notification alerts sent by the Barracuda Web Application Firewall. [BNWF-13177] SNMP's default community string is changed to “cudaSNMP”. [BNWF-13017]

Management

Backup

Configuration can now be backed up to SMB shares in Windows 2008 R2. [BNWF-10084] In rare circumstances generating a backup file resulted in a file of zero bytes being created. This issue has been fixed. [BNWF-11637] The process of generating a problem report can be customized to include specific components (e.g., configuration or backup). [BNWF-11664]

SNMP

In certain cases SNMP traps were not generated when back-end server failure was detected. This issue has been fixed. [BNWF-12102] The SNMP monitoring feature has been enhanced to support monitoring of concurrent SSL Connections in real time. [BNWF-5512] All SNMP metrics supported on the NC-gateway product are now supported on the Barracuda Web Application Firewall. [BNWF-9942] By default SNMP will not be listening on all interfaces, but only on the system IP.

Migration

It is now possible to change the web firewall policy of a service belonging to a Vsite, when migrating from NC-Gateway. [BNWF-9852]

User Interface

Security Policies

Changing the configuration of Security Policy options no longer results in the UI navigating incorrectly. Adding exception patterns under Security Policies > URL Protection no longer results in the blocked attack types check boxes getting unchecked. This issue has been fixed. [BNWF-11827] Changing the Global URL ACL rule in a custom Security Policy no longer results in a configuration rollback. [BNWF-4216] Bulk edit is now available for the Cookie Exempted parameter on Security Policies > Cookie Security page. [BNWF-10504] Editing values of the Data Theft Protection parameters for the policies other than "default" and saving resulted in context switching back to default policy. This issue has been fixed. [BNWF-10635] NIC advanced configuration UI is also enhanced to show operational and configured autoneg status. [BNWF-13039]

Services

The rare circumstance where a service creation operation resulted in the error message “Duplicate value not allowed for Sequence Number, Sequence Number”, no longer exists. [BNWF-12593] Trusted certificates can now bind to a real server in order to validate the back-end SSL communication. [BNWF-4963] Comments window is now available for various objects on the Basic > Services page. [BNWF-10724] Bulk edit is now available for services and servers. [BNWF-10836]

IP Configuration

Form values entered are retained after an invalid submit on the BASIC > IP Configuration page. [BNWF-5327]

Energize Update

13 UI now shows the date for the Currently Installed Version of virus definitions. [BNWF-7692]

Logging and Reporting

Logging

Additional error handling added to the logging module. [BNWF-10897] Exporting logs to CSV format honors existing query filters. [BNWF-10996] All logs capture Module ID of the Module where the log was generated. [BNWF-7271] In Access logs, the server IP address was incorrectly recorded as 0.0.0.0 when the response status code is a 404. This issue is fixed now. [BNWF-8323] In Audit Logs, configuration changes made by the admin are now always captured in the Audit logs. [BNWF-11220] In some cases SQL injection attacks were not getting logged. This issue has been fixed. [BNWF-11787] In System Logs, system hostname / unit name can now be added to custom syslog format. [BNWF-6689] Policy Wizard Apply Fix to an existing URL profile is improved. [BNWF-10256] Attack definition updates no longer automatically restart STM, an alert message is displayed on the Basic > Status page indicating new definition is synchronized and to apply the definitions the administrator needs to reboot the system. [BNWF-13012]

Export Logs using Syslog

Syslog can now be transported using the following connections/features: TCP connection. [BNWF-1456] SSL enabled TCP connection. [BNWF-180] SSL enabled TCP connection with SSL Client Authentication. [BNWF-2137] Additional flexibility added to export log format.

Reports

Certificate Status Report on the BASIC > Reports page displays issue and expiry dates of certificates. [BNWF-9787] Issue while generating HTML reports to be emailed to administrators has been fixed. [BNWF-8882]

Deployment Options en In This Section

Choosing Your Deployment Mode Public Cloud Hosting Virtual Deployment Choosing Your Deployment Mode en The Barracuda Web Application Firewall can be deployed as a reverse proxy, in Two-Arm Proxy or in One-Arm Proxy configuration. Alternatively, it can be deployed in a bridge-path configuration with the Barracuda Web Application Firewall appliance - but bridge-path is not supported by the Barracuda Web Application Firewall Vx virtual machine.

Reverse Proxy Deployment of the Barracuda Web Application Firewall

Reverse proxy deployments accept traffic on the virtual IP address and proxy the traffic to the back-end server network behind the Barracuda Web Application Firewall. Reverse proxy options include:

Two-Arm Proxy Deployment One-Arm Proxy Deployment

Two-Arm Proxy Deployment

The Barracuda Web Application Firewall is in-line with the web servers; it intercepts and inspects incoming and outgoing traffic, preventing attacks from reaching the web servers and preventing the leak of sensitive data to the requesting clients. Apart from web application security, this mode also allows all delivery acceleration features like server/application load balancing and tcp connection pooling to be employed. For details on

14 configuring this deployment type, see Configuring Two-Arm Proxy Mode. This deployment mode is supported by the Barracuda Web Application Firewall virtual appliance (see Virtual Deployment).

How This Deployment Works

The Two-Arm Proxy deployment is the recommended mode for initial deployment. The Barracuda Web Application Firewall is shipped in Proxy mode. In a Two-Arm Proxy configuration, the Barracuda Web Application Firewall is deployed in-line using both physical ports (WAN and LAN) of the device. This configuration is recommended because it provides the best security and can utilize all traffic acceleration features. Deploying in Two-Arm Proxy requires changes to the existing network infrastructure.

Two-Arm Proxy deployment requires the WAN and LAN interfaces of the Barracuda Web Application Firewall to be on separate logical networks.

The servers must be on a private network connected through a switch on the LAN port. The WAN port connects to the Internet facing switch that connects to a router/network firewall which routes the traffic to the Internet.

Each server in the private network is assigned a virtual IP address on the Barracuda Web Application Firewall (for example, 192.168.9.110, 192.1 68.9.120, and 192.168.9.130 in Figure Sample Two-Arm Proxy Network Layout). The virtual IP addresses should be accessible from the Internet, routed to the WAN port via the switch connected to it. When a request is received by the Barracuda Web Application Firewall on a VIP advertised through the WAN port, it inspects and redirects it to the real server on the private network via the LAN port. For example, the VIPs map to real servers 10.10.10.10, 10.10.10.20, and 10.10.10.30. See Figure: Sample Two-Arm Proxy Network Layout.

Sample Two-Arm Proxy Network Layout:

Advantages and Considerations

The following table describes the advantages and considerations of deploying your Barracuda Web Application Firewall in Two-Arm Proxy mode.

Advantages Considerations

Full feature availability including Load Balancing and Instant SSL. Requires network changes to Server IP addresses and DNS mappings.

Most secure deployment choice since back-end servers are Deployment requires cut-over of live services. completely isolated.

Fast High Availability failover. Network reconfiguration required to restore network to original state.

One-Arm Proxy Deployment

Allows the deployment of the Barracuda Web Application Firewall with minimal changes to the network configuration of the web servers. However, traffic from the upstream devices will have to explicitly pass through the Barracuda Web Application Firewall. For details on configuring this deployment type, see Configuring One-Arm Proxy Mode. This deployment mode is supported by the Barracuda Web Application Firewall virtual appliance (see Virtual Deployment).

How This Deployment Works

15 One-Arm proxy deployment requires minimal changes to the existing infrastructure. In this deployment, the WAN port is used for both incoming and outgoing traffic passing through the Barracuda Web Application Firewall. One-Arm Proxy deployment allows the retention of alternate paths to access the servers. For example, this deployment configuration can be used to load balance HTTP/HTTPS traffic at the application layer, while letting SMTP and other traffic go directly to the server.

Sample One-Arm network layout:

Advantages and Considerations

The following table describes the advantages and considerations of deploying your Barracuda Web Application Firewall in One-Arm Proxy mode.

Advantages Considerations

Requires fewer network configuration changes than Two-Arm Proxy. Requires DNS, IP address changes. Network infrastructure and partitioning unchanged.

Allows multiple access paths to servers for testing. Decreased throughput with only one port (WAN) used.

Integrates easily with existing enterprise load balancers. Potentially compromises server security by providing direct server access, unlike Two-Arm Proxy configuration.

Bridge Mode Deployment of the Barracuda Web Application Firewall

The Barracuda Web Application Firewall is inline with the web servers and acts as an L2 transparent bridge. It inspects only the traffic that is configured for inspection while bridging all other traffic. Bridge mode deployment can be achieved with no changes to the network configuration of the upstream devices or web servers. For details on configuring this deployment type, see Configuring Bridge-Path Mode . This deployment mode is not supported on the Barracuda Web Application Firewall virtual appliance (see Virtual Deployment).

How This Deployment Works

In Bridge-Path deployment the Barracuda Web Application Firewall is located inline between the network firewall and the web servers, inspecting configured traffic and bridging any other traffic to the servers. Bridge-Path provides the easiest configuration scenario because it uses the same IP address for the VIP and back-end server, so it does not require changing the server IP addresses or DNS mappings. You can place the Barracuda Web Application Firewall inline with the existing IP address infrastructure and add servers without changing IP addresses. In a Bridge-Path deployment, the WAN and LAN interfaces must be on physically separate networks and the LAN interface must be on the same logical switch as the servers.

Sample Bridge-Path network layout:

16 Advantages and Considerations

The following table describes the advantages and considerations of deploying your Barracuda Web Application Firewall in Bridge mode.

Advantages Considerations

Minimal network changes since the existing IP address infrastructure Sensitive to broadcast storms and address resolution looping errors. is reused.

Real Servers keep existing IP addresses. Less resilient to network misconfiguration.

Features like Load balancing and TCP pooling are not available.

Configuring Two-Arm Proxy Mode en

Configuring Two-Arm Proxy Mode

The Two-Arm Proxy mode uses both physical ports (WAN and LAN) of the device. This is the recommended configuration as it provides the best security, and utilizes all traffic acceleration features. Perform the following configuration for Two-Arm Proxy mode:

1. Go to the BASIC > IP Configuration page. 2. Specify values for the following in the WAN IP Configuration section: IP Address Subnet Mask Default Gateway 3. Specify values for the following in the LAN IP Configuration section: LAN IP Address LAN Netmask 4. In the Operation Mode section, set the Mode of Operation to Proxy. 5. Enter Default Hostname and Default Domain in the Domain Configuration section. The Host Name will be used in reporting, and the Default Domain is the domain for the system. 6. Click Save Changes.

If you want to switch from Proxy to Bridge mode or Bridge to Proxy mode, you have to remove all configured Services, VLANs and Virtual Interfaces on the device. You can remove services on the BASIC > Services page, VLANs and Virtual Interfaces on the ADVAN CED > Advanced IP Config page. Note that Bridge Mode is not supported by the Barracuda Web Application Firewall Vx virtual machine.

Continue with Step 1: Installing the Barracuda Web Application Firewall.

17 Configuring One-Arm Proxy Mode Configuring Bridge-Path Mode

Configuring One-Arm Proxy Mode en

Configuring One-Arm Proxy

In One-Arm proxy mode, the device uses only the WAN port for both incoming and outgoing traffic. Do the following to configure One-Arm Proxy mode:

1. Go to the BASIC > IP Configuration page. 2. Specify values for the following in the WAN IP Configuration section: IP Address Subnet Mask Default Gateway 3. In the Operation Mode section, set the Mode of Operation to Proxy. 4. Enter Default Hostname and Default Domain in the Domain Configuration section. The Host Name will be used in reporting, and the Default Domain is the domain for the system. 5. Click Save Changes.

Continue with Step 1: Installing the Barracuda Web Application Firewall. Related Articles:

Configuring Two-Arm Proxy Mode Configuring Bridge-Path Mode Configuring Bridge-Path Mode en

Configuring Bridge Mode

In Bridge mode, the Barracuda Web Application Firewall uses the same IP address for Virtual IP (VIP) and back-end server. Use this mode of operation when you want to avoid network changes such as the server IP address and DNS mappings. Bridge Mode is not supported by the Barracuda Web Application Firewall Vx virtual machine.

In the Barracuda Web Application Firewall 861, 862, 961 and 962, when the unit is forced into a Bypass on Failure or Hard Bypass st ate, the Bypass LED on the front panel will not be lit.

Changing the Mode of Operation

To change the mode of operation from Proxy to Bridge, select Bridge All Traffic under Operation Mode on the BASIC > IP Configuration page and click Save Changes. If you want to change the mode of operation from Bridge to Proxy:

Make sure that Bypass on Failure and Hard Bypass in the Bypass Configuration section is set to No. Select Proxy and click Save Changes.

Continue with Step 1: Installing the Barracuda Web Application Firewall. Related Articles

18 Configuring One-Arm Proxy Mode Configuring Two-Arm Proxy Mode Public Cloud Hosting en Barracuda Networks offers the Barracuda Web Application Firewall Vx as a cloud hosted virtual machine, protecting your applications that are set up in the public cloud or in private networks. Cloud hosted virtualization is currently available for:

Windows Azure Amazon Web Services

Microsoft Azure en

Cloud hosted deployment of the Barracuda Web Application Firewall Vx on Microsoft Azure currently supports One-Arm Proxy Mode. For more information, see Configuring One-Arm Proxy Mode.

In this article:

en In this article: Barracuda Web Application Firewall Vx Models on Microsoft Azure

19 Before You Begin Step 1 - Configure Windows Azure Active Directory Authentication in PowerShell Step 2 - Create a Storage Account Step 3 - Create a Storage Container Step 4 - Set Up Windows Azure Cmdlets to upload the Barracuda Web Application Firewall Vx VHD Next Step

Barracuda Web Application Firewall Vx Models on Microsoft Azure

The Barracuda Web Application Firewall Vx is available in three models on Microsoft Azure. The following table lists each model with their corresponding cores, Instance Type and Memory allocated to each Instance Type.

Barracuda Web Application Supported Instance Type in Cores Memory Firewall Vx Model Microsoft Azure

BWFCAZ001a A1 1 1.7 GB

BWFCAZ005a A2 2 3.5 GB

BWFCAZ010a A3 4 7 GB

If you want to increase the performance of a license that you have already purchased, you can buy additional cores from Barracuda and reconfigure your VM for a larger instance type. You can add multiple Barracuda Web Application Firewall Vx instances under one cloud service and load balance the traffic between the deployed VMs to increase the throughput. For more information on load balancing, see the Load Balancing For Clustered Barracuda Web Application Firewall Vx Instances in Microsoft Azure article.

Before You Begin

1. Create a Microsoft Azure account. 2. Get a Barracuda Web Application Firewall Azure Vx license, either by: a. Providing the required information for a free evaluation in the Barracuda Networks Evaluation page, OR b. Purchasing online in the Barracuda Networks Purchase Online page. i. From the Select a Product list, select Barracuda Web Application Firewall Azure under the Public Cloud Solutions category. ii. From the Select Edition list, select a level you desire. iii. Enter other information and click SUBMIT REQUEST. You will receive an email containing the serial number and license token of your Barracuda Web Application Firewall Vx. 3. Download the Microsoft Hyper-V Virtual Hard Disk (VHD) from the Barracuda Networks Virtual Appliance Download page.

4. Download and install Windows Azure PowerShell for your platform.

Step 1 - Configure Windows Azure Active Directory Authentication in PowerShell

1. Open the Windows Azure PowerShell console (Run as Administrator), type Add-AzureAccount and hit Enter to add an account. The Si gn in to Windows Azure window appears. 2. Enter your Windows Azure credentials and sign into your Azure account. Note that this sign-in is valid until your access token expires, after which you will be prompted again to enter the credentials.

20 2.

Step 2 - Create a Storage Account

To create a storage account to store your Barracuda Web Application Firewall Vx VHD, perform the following steps:

1. Log into the Microsoft Azure Management Portal. 2. Click NEW at the bottom of the screen.

3. In the NEW window, navigate to DATA SERVICES > STORAGE and click QUICK CREATE. 4. Enter storage account details: a. URL - The hostname within the URL that is used to address Blob, Queue, or Table resources for the subscription. b. LOCATION/AFFINITY GROUP - Select an affinity group for the storage. c. REPLICATION - Select the level of replication for the storage. By default, this is set to Geo-Redundant. With Geo-Redundant replication, all stored content/data fails over to a secondary location in case of a major disaster in the primary location.

21 4.

5. Click CREATE STORAGE ACCOUNT.

Step 3 - Create a Storage Container

To create a container in your storage account to store your Barracuda Web Application Firewall Vx VHD, perform the following steps:

1. Log into the Microsoft Azure Management Portal. 2. In the left pane, click STORAGE. 3. Click the storage account that you created above (under Create a Storage Account ). 4. Click on the CONTAINERS tab, and then click ADD at the bottom of the screen. 5. In the New container window: a. Enter a NAME for the container. b. From the ACCESS list, select Private and click the check mark.

Step 4 - Set Up Windows Azure Cmdlets to upload the Barracuda Web Application Firewall Vx VHD

Refer to the Microsoft documentation Get Started with Windows Azure Cmdlets for instructions to prepare your work environment before installing the Windows Azure module for Windows PowerShell & configuring connectivity between Windows Azure and your workstation.

Next Step

Continue with Deploying the Barracuda Web Application Firewall Vx - Microsoft Azure for instructions on installation and configuration.

22 Deploying the Barracuda Web Application Firewall Vx - Microsoft Azure en This guide will walk you through the steps to upload the Barracuda Web Application Firewall Vx to your Microsoft Azure account and provision it. Make sure you've completed the steps in the article Microsoft Azure befor e continuing with the instructions below.

Related Articles Barracuda Web Application Firewall Vx Quick Start Guide - Microsoft Azure Configuring One-Arm Proxy Mode

The Barracuda Web Application Firewall Vx on Microsoft Azure supports ONLY One-Arm Proxy mode deployment. For more information, see Configuring One-Arm Proxy Mode.

In this article:

en In this article: Step 1 - Upload the Barracuda Web Application Firewall Vx VHD on Microsoft Azure portal Step 2 - Create an IMAGE or a DISK from the Uploaded VHD Step 3 - Provision the Barracuda Web Application Firewall Vx using the Uploaded VHD on Microsoft Azure Next Step

Step 1 - Upload the Barracuda Web Application Firewall Vx VHD on Microsoft Azure portal

Upload the Barracuda Web Application Firewall Vx VHD on Microsoft Azure portal by following the steps below:

1. Click Start, click All Programs, click Windows Azure, right-click Windows Azure PowerShell, and then select Run as administrator. 2. Enter the command below to upload the Barracuda Web Application Firewall Vx image from your workstation to the Microsoft Azure portal on Windows Azure PowerShell.

Add-AzureVhd -LocalFilePath -Destination

where:

LocalFilePath is the path on your local workstation where your Barracuda Web Application Firewall Vx Virtual Hard Disk (VHD) is stored. Destination is the uri for the blob; i.e, this will be the URI of the container to which you want to upload the VHD on the Microsoft Azure Management Portal. To get the URI for the container, log in to your portal and navigate to STORAGE, and then click on CONTAINERS a nd look for the container you created in Create a Storage Container. Copy the URL next to your container name.

For example:

Add-AzureVhd -LocalFilePath C:\Users\user1\Desktop\WAF_770.026_azure.vhd –Destination http://cudastorage02 .blob.core.windows.net/images/WAF_770.026_azure.vhd

Step 2 - Create an IMAGE or a DISK from the Uploaded VHD

After you upload the VHD, create the image or disk out of the uploaded VHD by following the steps below:

1. Log into the Microsoft Azure Management Portal. 2. Navigate to VIRTUAL MACHINES, and then click IMAGES or DISKS.

You can create ONLY one Barracuda Web Application Firewall Vx instance per disk, whereas an image allows you to create multiple instances of the Barracuda Web Application Firewall Vx.

3. Click CREATE at the bottom of the screen. 4. On the Create an image from a VHD/Create a disk from a VHD window, enter the following details: a. NAME: Name to identify the created image or disk. b. DESCRIPTION: Description for the image (Available ONLY in IMAGES). c.

23 4.

c. VHD URL: Browse and select the uploaded VHD d. Check the The VHD contains an operating system check box and select LINUX for OPERATING SYSTEM FAMILY. e. Check the I have run waagent -deprovision on the virtual machine check box, and then click the check mark.

Step 3 - Provision the Barracuda Web Application Firewall Vx using the Uploaded VHD on Microsoft Azure

After uploading the Barracuda Web Application Firewall Vx image to Microsoft Azure, perform the steps below to provision the Barracuda Web Application Firewall Vx.

1. Log into the Microsoft Azure Management Portal. 2. On the VIRTUAL MACHINES page, click NEW at the bottom of the screen. 3. In the NEW window, navigate to COMPUTE > VIRTUAL MACHINE > FROM GALLERY. 4. On the Choose an Image page, click MY IMAGES or MY DISKS, and then select an appropriate image/disk. Click Next (->) to continue. 5. On the Virtual machine configuration page, do the following configuration: a. In case of MY DISKS: i. Enter a name in the VIRTUAL MACHINE NAME field. ii. Select the TIER (BASIC or STANDARD). iii. Select a size for the virtual machine from the SIZE drop-down list based on the Barracuda Web Application Firewall Vx license. Click Next (->) to proceed.

See Barracuda Web Application Firewall Vx Models on Microsoft Azure to verify the recommended instance type for your Barracuda Web Application Firewall Vx model.

b. In case of MY IMAGES: i. Enter a name in the VIRTUAL MACHINE NAME field. ii. Select the TIER (BASIC or STANDARD). iii. Select a size for the virtual machine from the SIZE drop-down list based on the Barracuda Web Application Firewall Vx license.

See Barracuda Web Application Firewall Vx Models on Microsoft Azure to verify the recommended instance type for your Barracuda Web Application Firewall Vx model.

iv. In the NEW USER NAME field, enter a random username. This entry is not used by the Barracuda Web Application Firewall Vx. v. Clear the UPLOAD COMPATIBLE SSH KEY FOR AUTHENTICATION check box. vi. Select the PROVIDE A PASSWORD check box and enter a password in NEW PASSWORD. Re-enter the password in CONFIRM and click Next (->). This entry is not used by the Barracuda Web Application Firewall Vx.

The username and password values specified while configuring MY IMAGES will NOT be used further, but are mandatory fields for a successful configuration.

6. On the second page of Virtual machine configuration: a. Select Create a new cloud service from the CLOUD SERVICE drop-down list. b. Enter a name in the CLOUD SERVICE DNS NAME field. c. Select a region from the REGION/AFFINITY GROUP/VIRTUAL NETWORK drop-down list. d. Select a subnet from the VIRTUAL NETWORK SUBNETS drop-down list. e. Select None for AVAILABILITY SET. f. Configure the ENDPOINTS to access the web interface of the Barracuda Web Application Firewall Vx. By default, the Barracuda Web Application Firewall Vx web interface listens on port 8000 for HTTP and port 443 for HTTPS. Make sure these ports (8000 and 443) are configured as ENDPOINTS on the Barracuda Web Application Firewall Vx. Additionally, in order to be notified of virtual appliance (re)boots due to initial installation, system upgrades, instance changes or other administrative reasons, make sure to add port 40080 also as your endpoint. Specify values for the following fields to configure the endpoints. i. NAME: a name of your choice (e.g.: GUI8000) ii. PROTOCOL: TCP iii. PUBLIC PORT: 8000 iv. PRIVATE PORT: 8000 g. Follow the same steps to open other ports. h. Click Next (->) to continue. 7. On the third page of Virtual machine configuration, clear the The VM agent that supports extensions is already installed check box and click on ().

24 After clicking on (), Microsoft Azure begins provisioning the Barracuda Web Application Firewall Vx. You can check the status of the provisioned Barracuda Web Application Firewall Vx from the Microsoft Azure Management Portal under VIRTUAL MACHINES. You will see Starting (Provisioning) in the beginning on the Microsoft Azure Management Portal. Allow a few minutes before taking any further actions in the Portal. During this time, the Microsoft Azure Linux Agent and Barracuda Web Application Firewall Vx image boot up.

Make sure you do not restart the Barracuda Web Application Firewall Vx while it is provisioning. If the status displays as Stopped on Microsoft Azure Management Portal under VIRTUAL MACHINES, do not restart it manually as it will automatically restart after a few minutes, and the status will again display as Running.

Next Step

Continue with the Barracuda Web Application Firewall Vx Quick Start Guide - Microsoft Azure for licensing and initial configuration of your virtual machine.

Barracuda Web Application Firewall Vx Quick Start Guide - Microsoft Azure en

Make sure you have completed the steps in the article Deploying the Barracuda Web Application Firewall Vx - Microsoft Azure before continuing with the instructions below.

Licensing of Barracuda Web Application Firewall Vx after deploying on Microsoft Azure

After provisioning the Barracuda Web Application Firewall Vx on Microsoft Azure, the next step is licensing. After you deploy the Barracuda Web Application Firewall Vx image on the Microsoft Azure environment, do the following:

1. Sign in to the Microsoft Azure Management Portal. 2. Go to the VIRTUAL MACHINES and click on the Barracuda Web Application Firewall Vx you created, noting down the DNS.

25 2.

3. Open the browser and enter the copied DNS (from step 2) with port 8000 for HTTP. No port is required for HTTPS. For example: For HTTP : http://:8000 For HTTPS : https://

The Barracuda Web Application Firewall Vx is not accessible via HTTPS port when it is booting up. Therefore, it is recommended to use ONLY HTTP port to access the unit when booting. This displays the status of the unit i.e., System Booting. Once the boot process is complete, the user will be redirected to the login page.

4. You will see the Licensing page. Enter your Barracuda Networks Token and Default Domain to complete licensing.

26 Verify Configuration and Change Password

1. Log into the Barracuda Web Application Firewall Vx web interface as the administrator using the URL as described in step 3 of Licensing of Barracuda Web Application Firewall Vx after deploying on Microsoft Azure.

Username: admin Password: admin

2. Navigate to the BASIC > Administration page and enter your old password, new password, and re-enter the new password. 3. Click on Save Password. 4. Navigate to the BASIC > IP Configuration page and do the following:

a. Verify the WAN IP Configuration.

Do not make any changes in this section as this configuration is provided by Microsoft Azure and should not be changed.

b. Configure the Primary and Secondary DNS Server in DNS Configuration. c. Enter Default Host Name and Default Domain in the Domain Configuration. The Host Name will be used in reporting and displays in alerts, notifications and messages sent by the Barracuda Web Application Firewall Vx. The Default Domain is the domain for the system and is appended to the Host Name.

Update the Firmware

Navigate to the ADVANCED > Firmware Update page and check if there is a new Latest General Release available. If so, perform the following steps to update the system firmware.

Make sure to read the release notes to learn about enhancements and new features before upgrading the firmware. It is also good practice to verify settings, as new features may have been included with the firmware update.

1. Click on the Download Now button located next to the firmware version that you wish to install. When the download is complete, the App ly Now button appears. 2. Click on the Apply Now button to apply the firmware. This will take a few minutes to complete. After the firmware has been applied, the Barracuda Web Application Firewall Vx will automatically reboot, displaying the login page when the system has come back up. 3. After applying the firmware, you will be required to log into the web interface of the Barracuda Web Application Firewall Vx again.

Continue with the Next step - Configuring a Service. Load Balancing For Clustered Barracuda Web Application Firewall Vx Instances in Microsoft Azure

This guide will walk you through the steps to load balance traffic across multiple instances of the Barracuda Web Application Firewall Vx deployed in Microsoft Azure:

Step 1. Deploy the Barracuda Web Application Firewall Vx Instances in Microsoft Azure Step 2. Set Up a High Availability Environment With the Barracuda Web Application Firewall Vx Step 3. Set Up Load Balancing on the First Barracuda Web Application Firewall Vx Instance Step 4. Add Other Barracuda Web Application Firewall Vx Instances to the Load-Balanced Set

In Microsoft Azure, you can create Services using the WAN IP Address of the Barracuda Web Application Firewall Vx.

Step 1. Deploy the Barracuda Web Application Firewall Vx Instances in Microsoft Azure

1. Follow the steps in Deploying the Barracuda Web Application Firewall Vx - Microsoft Azure. To license and configure your virtual machine, continue with Barracuda Web Application Firewall Vx Quick Start Guide - Microsoft Azure. In these instructions, the newly configured virtual machine is called Barracuda-WAF1. 2. Verify that Barracuda-WAF1 is accessible through port 8000 (for HTTP) and port 443 (for HTTPS). 3. Add new ports for HTTP and HTTPS to Barracuda-WAF1 in ENDPOINTS (for example, port 8001 for HTTP and port 8443 for HTTPS). To configure ENDPOINTS, refer to step 6 (f) under Provision the Barracuda Web Application Firewall Vx using the Uploaded VHD on Microsoft Azure in the Deploying the Barracuda Web Application Firewall Vx - Microsoft Azure article 4. In the web interface of Barracuda-WAF1, do the following: a. Enter the HTTP port number you configured in step 3 into Web Interface HTTP Port under Web Interface Settings on the BAS IC > Administration page. b. Enter the HTTPS port number you configured in step 3 into Web Interface HTTPS/SSL Port on the ADVANCED > Secure Administration page. 5. Verify that you can access Barracuda-WAF1 using the HTTP and HTTPS ports specified in the step 4 (a) and (b). 6. In Microsoft Azure, delete port 8000 and port 443 from the listed ENDPOINTS for Barracuda-WAF1. 7. To deploy another Barracuda Web Application Firewall Vx (called Barracuda-WAF2) in Microsoft Azure, follow the instructions from the U pload the Barracuda Web Application Firewall Vx Image on Microsoft Azure portal section in Deploying the Barracuda Web Application Firewall Vx - Microsoft Azure.

Note: When you configure the CLOUD SERVICE DNS NAME, choose the CLOUD SERVICE DNS NAME of Barracuda-WAF1 from the CLOUD SERVICE list.

8. Continue with Barracuda Web Application Firewall Vx Quick Start Guide - Microsoft Azure to license and configure your virtual machine. 9. By default, the Barracuda-WAF2 is configured with port 8000 (for HTTP) and port 443 (for HTTPS).

Now Barracuda-WAF1 is accessible through port 8001 for HTTP and port 8443 for HTTPS, and Barracuda-WAF2 is accessible through port 8000 for HTTP and port 443 for HTTPS.

Step 2. Set Up a High Availability Environment With the Barracuda Web Application Firewall Vx

Follow these steps to cluster your Barracuda Web Application Firewall virtual machines in Microsoft Azure:

The Barracuda Web Application Firewall Vx virtual machines should all be deployed in the same CLOUD SERVICE for High Availability in Microsoft Azure. Before clustering your Barracuda Web Application Firewall virtual machines, ensure the following ports are configured as END POINTS in the Barracuda Web Application Firewall virtual machines:

1. Install each system and ensure that each Barracuda Web Application Firewall Vx is running the same firmware version. Each Barracuda Web Application Firewall Vx in a cluster must have the same model number and firmware version. 2. Make a backup of each Barracuda Web Application Firewall Vx configuration. 3. No processes should be running on any virtual machine when you link them together. To be sure, go to the ADVANCED > Task Manager page of each Barracuda Web Application Firewall Vx and verify that no processes are running. 4. From the ADVANCED > High Availability page of Barracuda-WAF1, enter a Cluster Shared Secret password, and click Save Changes. 5. From the ADVANCED > High Availability page of Barracuda-WAF2, do the following: a. Enter the same Cluster Shared Secret password, and click Save Changes. Both units in a cluster must have the same Cluster Shared Secret to communicate with each other. b. In the Clustered Systems section, enter the WAN IP address of Barracuda-WAF1, and click Join Cluster. Make sure that the

28 5.

join cluster task is not cancelled when the join is in progress. 6. On each Barracuda Web Application Firewall Vx, refresh the ADVANCED > High Availability page, and verify the following: a. Each system's Hostname, serial number and WAN IP address appears in the Clustered Systems list. b. The identity of the system (Self or Peer) displays in the Type field. c. The Status is green for all virtual machines in the cluster. 7. View the Cluster Status from the BASIC > Status page, under Performance Statistics.

To add more units to the existing cluster, repeat step 1 to 5.a. and then do the following:

Step 3. Set Up Load Balancing on the First Barracuda Web Application Firewall Vx Instance

1. Go to the Microsoft Azure Management Portal. 2. Click Virtual Machines and select Barracuda-WAF1. 3. Click ENDPOINTS, and then click ADD.

4. In the Add an endpoint to a virtual machine window, select Add A STAND-ALONE ENDPOINT and click the arrow to continue.

29 4.

5. Specify values for the following fields: a. NAME – Enter the name for the endpoint. Example: HTTP b. PROTOCOL – Select TCP from the list. c. PUBLIC PORT – Enter the port number of the service you are load balancing. Example: Port 80 for HTTP traffic. d. PRIVATE PORT – Enter the internal port that should listen to traffic on the endpoint. Example: 80. e. Select Create A LOAD-BALANCED SET and click the arrow to continue.

30 6. In the Configure the load-balanced set window, specify a name for the load-balanced set and assign the values for the load-balancing probe.

7. Click the check mark to set up a load-balanced set. 8. Repeat the process to add more ports to the load-balanced set.

Step 4. Add Other Barracuda Web Application Firewall Vx Instances to the Load-Balanced Set

After you create the load-balanced set for Barracuda-WAF1, add other Barracuda Web Application Firewall Vx virtual machines to the set. Examp le: Barracuda-WAF2

1. Go to the Microsoft Azure Management Portal. 2. Click Virtual Machines and select Barracuda-WAF2. 3. Click ENDPOINTS, and then click ADD.

4. In the ADD ENDPOINT window, select ADD AN ENDPOINT TO AN EXISTING LOAD-BALANCED SET and then select the load-balanced set name from the list. Click the arrow to continue.

31 4.

5. In the Specify the details of the endpoint window, specify a name for the load-balanced set and then click the check mark.

6. Repeat the process to add more Barracuda Web Application Firewall Vx virtual machines to the load-balanced set.

32 Amazon Web Services en The Barracuda Web Application Firewall Vx provides proven application security and data loss prevention for your applications on Amazon Web Service (AWS), including:

Detecting and blocking attacks including SQL injections, Cross-Site Scripting, malware uploads, and volumetric or application DDoS. Authentication and access control allowing organizations to exercise strong user control. Scanning of outbound traffic for sensitive data, with admin control of masking or blocking information to prevent data leakage. Built-in load balancing and session management, allowing organizations to manage multiple applications behind a single instance of the Barracuda Web Application Firewall Vx.

The Barracuda Web Application Firewall Vx on Amazon Web Services protects your applications in the cloud.

Public cloud hosted deployment of the Barracuda Web Application Firewall Vx on Amazon Web Services currently supports One-Arm Proxy Mode.

To meet a variety of performance requirements, the M1 Medium, M1 Large, and M1 Extra Large instance types are supported. Depending on the instance type, you can have:

Up to 4 vCPUs. Up to 15 GB of memory. Up to 15 private IP addresses per network interface. To ensure that services are available over the Internet, you can allocate a public IP address, or Elastic IP address (EIP), to each private IP address.

The Barracuda Web Application Firewall Vx is available hourly in the AWS Marketplace or you can bring your own license (BYOL).

In this article:

en Licensing Options

33 Bring Your Own License (BYOL) BYOL Models and Instance Types Hourly / Metered Hourly / Metered Model and Instance Types Before You Begin Step 1 - Create the Amazon VPC Cloud Step 2 - Add an Internet Gateway to the VPC Step 3 - Add a Subnet to the VPC Step 4 - Attach the Internet Gateway to the Route Table Next Step

Licensing Options

The Barracuda Web Application Firewall Vx AMI is available on Amazon Web Services with the Bring Your Own License (BYOL) and Hourly / Metered option.

Bring Your Own License (BYOL)

With the Bring Your Own License (BYOL) option, you are required to get the Barracuda Web Application Firewall Vx license token, either by:

Providing the required information for a free evaluation at https://www.barracuda.com/purchase/evaluation OR Purchasing online at https://www.barracuda.com/purchase. With this license option, there will be no Barracuda Web Application Firewall Software charges, but Amazon Elastic Compute Cloud (Amazon EC2) usage charges on Amazon will be applicable.

BYOL Models and Instance Types

For BYOL, Barracuda offers three models. The table below lists each model, the corresponding Instance Type to be used in Amazon Web Services, the default CPU and Memory for the instance, and the number of Private IP addresses that can be associated per ENI.

If you want to increase the performance of a license that you have already purchased, you can buy additional cores from Barracuda and reconfigure your VM for a larger instance type.

Barracuda Web Supported Instance Name Default vCPU Default Memory Maximum Number Application Type in Amazon of Private IP Firewall Vx Model Web Services Addresses per ENI

BWFCAW001a M1 Medium m1.medium 1 3.7 GB 6

BWFCAW005a M1 Large m1.large 2 7.5 GB 10

BWFCAW010a M1 Extra Large m1.xlarge 4 15 GB 15

Hourly / Metered

With the Hourly/Metered licensing option, you complete the purchase or evaluation of the Barracuda Web Application Firewall Vx entirely within the AWS Marketplace. After the instance is launched, it is provisioned automatically. You are charged hourly for both the Barracuda Web Application Firewall Software and Amazon Elastic Compute Cloud (Amazon EC2) usage on Amazon. For pricing information, refer to the AW S Marketplace.

Hourly / Metered Model and Instance Types

For Hourly / Metered licensing, Barracuda offers only model BWFCAW000p. Three instance types are available for this model. The following table lists each instance type with its CPU, memory, and the number of Private IP addresses that can be associated per ENI.

If you want to increase the performance of an existing VM, configure it with a larger instance type on AWS and you will be charged accordingly by Amazon. The VM will automatically be reconfigured by Amazon with the resources and capabilities of the larger instance type.

Barracuda Web Supported Instance Name Default Default Maximum Number Application Type in Amazon vCPU Memory of Firewall Vx Model Web Services Private IP Addresses per ENI

34 M1 Medium m1.medium 1 3.7 GB 6

BWFCAW000p M1 Large m1.large 2 7.5 GB 10

M1 Extra Large m1.xlarge 4 15 GB 15

Before You Begin

Before you deploy the Barracuda Web Application Firewall Vx on Amazon Web Services, choose the licensing option (Bring Your Own License (BYOL) or Hourly / Metered). Then set up an Amazon Virtual Private Cloud (VPC).

A Virtual Private Cloud (VPC) is an isolated virtual network on Amazon Web Services (AWS) Cloud where you can launch AWS resources, such as Amazon EC2 instances. When creating a VPC, the IP address(es) should be in the form of Classless Inter-Domain Routing (CIDR) block (for example, 10.0.0.0/16). In a VPC, you can select your own IP address range, create subnets, configure routing tables and network gateways.

The VPC cannot be larger than /16.

For more information about CIDR notation, refer to Classless Inter-Domain Routing on Wikipedia. For information about the number of VPCs that you can create, refer to Amazon VPC Limits.

To set up a VPC, complete the following steps. If you have already configured a VPC for the Barracuda Web Application Firewall Vx, you can skip the steps below and continue with Deploying the Barracuda Web Application Firewall Vx on Amazon Web Services.

Step 1 - Create the Amazon VPC Cloud

Perform the steps below to create a VPC:

1. Go to the AWS Management Console. 2. In the Compute & Networking section, click VPC.

3. From the VPC Dashboard, select Your VPCs under VIRTUAL PRIVATE CLOUDS. 4. Click Create VPC. 5. In the Create VPC dialog box, do the following: a. Enter the IP address in the CIDR Block field. b. Select Default from the Tenancy drop-down list.

35 5.

6. Click Yes, Create.

Step 2 - Add an Internet Gateway to the VPC

By default, the instances launched on the Virtual Private Cloud (VPC) cannot communicate with the internet until an Internet Gateway is created and attached to the VPC.

Perform the following steps to add an internet gateway to your VPC:

1. From the VPC Dashboard, select Internet Gateways under VIRTUAL PRIVATE CLOUDS. 2. Click Create Internet Gateway. 3. In the Create Internet Gateway dialog box, click Yes, Create.

4. Select the internet gateway created in the above step, and then click Attach to VPC.

5. Select the VPC that you created in Step 1, and then click Yes, Attach.

Step 3 - Add a Subnet to the VPC

Perform the following steps to add a subnet to your VPC:

1. From the VPC Dashboard, select Subnets under VIRTUAL PRIVATE CLOUDS. 2. Click Create Subnet. 3. In the Create Subnet dialog box, do the following: a. Select the created VPC from the VPC drop-down list. b. Select the availability zone that your VPC resides from the Availability Zone drop-down list. c. Specify the IP address(es) in the CIDR Block field.

4. Click Yes, Create.

Step 4 - Attach the Internet Gateway to the Route Table

Attach the internet gateway created in Step 2 - Add an Internet Gateway to the VPC to the route table by following the steps below:

1. From the VPC Dashboard, select Subnets under Virtual Private Cloud. 2. In the Subnets list, select the subnet you created in Step 3 - Add a Subnet to the VPC, and note the Route table entry.

37 2.

3. Now, select Route Tables under Virtual Private Cloud. 4. In the Route Tables list, select the route that you noted down in step 2 above. 5. In the Routes tab, click Edit and specify the following values: a. Destination – 0.0.0.0/0 b. Target – Should be the internet gateway created in Step 2 - Add an Internet Gateway to the VPC.

6. Click Save.

Next Step

Now that you have set up a VPC for the Barracuda Web Application Firewall Vx, you can continue with Barracuda Web Application Firewall Vx Deployment and Quick Start Guide for Amazon Web Services. If you encounter network connectivity issues, see Troubleshooting the Barracuda Web Application Firewall on Amazon Web Services.

Barracuda Web Application Firewall Vx Deployment and Quick Start Guide for Amazon Web Services en The Barracuda Web Application Firewall Vx can be deployed in One-Arm Proxy Mode on Amazon Web Services. This article explains One-Arm Proxy Mode deployment. Complete the steps in this guide to configure, launch, and license your Barracuda Web Application Firewall Vx instance. Then log into the Barracuda Web Application Firewall Vx to verify your configuration and change your password.

In this article:

en Requirements Step 1 - Create a Security Group Step 2 - Create a Network Interface Step 3 - (Optional) Assign Multiple Private IP Addresses to the Network Interface of the Instance Step 4 - Allocate and Assign an Elastic IP Address to your Instance Step 5 - Deploy the Barracuda Web Application Firewall Vx on Amazon Web Services Step 6 - License the Barracuda Web Application Firewall Vx Step 7 - Verify Configuration and Change the Password Next Steps

Requirements

Before you deploy the Barracuda Web Application Firewall Vx on Amazon Web Services, ensure that you have completed the following:

38 Set up an Amazon Virtual Private Cloud (VPC) for the Barracuda Web Application Firewall Vx. If you want to use the Bring Your Own Licensing (BYOL) model, get the Barracuda Web Application Firewall Vx license. See Bring Your Own License (BYOL).

Step 1 - Create a Security Group

Create a security group with rules specifying allowed protocols, ports and source IP ranges. Multiple security groups can be created with different rules, and assigned to each instance. For more information on security groups, refer to the AWS article Amazon EC2 Security Groups.

1. Log into the Amazon EC2 Management Console. 2. From the EC2 dashboard, select Security Groups under NETWORK & SECURITY. 3. Click Create Security Group. 4. In the Create Security Group window, do the following: a. Enter a name to identify the security group. b. Specify the description for the security group. c. Select a VPC ID from the list and click Yes, Create. 5. The created group appears in the security group table. 6. Select the security group from the table, and specify the inbound and outbound traffic to be allowed for the instance.

By default, the Barracuda Web Application Firewall web interface listens on port 8000 for HTTP and port 443 for HTTPS. Make sure these ports (8000 and 443) are allowed by the Inbound rule of the associated security group. Also, add the port(s) through which you configure the Service(s) for this instance.

Step 2 - Create a Network Interface

Create a network interface using the static IP address, for association with the Barracuda Web Application Firewall Vx later during deployment.

1. Log into the Amazon EC2 Management Console. 2. From the EC2 dashboard, select Network Interfaces under NETWORK & SECURITY. 3. Click Create Network Interface. 4. In the Create Network Interface window, provide the following information for the network interface: a. Description – Enter a name for the interface. b. Subnet – Select a subnet from the drop-down list. Make sure to select the subnet of the VPC where you want to create the instance. c. Private IP – Enter the static primary private IP address. It is recommended to use the Static IP address. d. Security Groups – Select one or more security groups. Make sure the security group has all the required ports open.

By default, the Barracuda Web Application Firewall Vx web interface listens on port 8000 for HTTP and port 443 for HTTPS. Make sure these ports (8000 and 443) are added to the Inbound Rule of the security group associated with the Barracuda Web Application Firewall Vx. Additionally, in order to be notified of any virtual appliance (re)boots due to initial installation, system upgrades, instance changes or other administrative reasons, make sure to add port 40080 to the set of security groups. Also add the port(s) through which you configure the Service(s) for this instance.

e. Click Yes, Create.

Step 3 - (Optional) Assign Multiple Private IP Addresses to the Network Interface of the Instance

39 Multiple secondary private IP addresses can be assigned to the network interface of the Barracuda Web Application Firewall Vx instance, depending on the selected Instance Type, and can be used to create Services on the Barracuda Web Application Firewall Vx. To assign a secondary private IP address to the Barracuda Web Application Firewall Vx instance, perform the following steps:

1. Log into the Amazon EC2 Management Console. 2. From the EC2 dashboard, select Network Interfaces under NETWORK & SECURITY. 3. Identify the instance needing a secondary private IP address assignment and right-click on the network interface attached to the instance. 4. Select Manage Private IP Addresses. 5. In the Manage Private IP Addresses window, do the following: a. Click Assign a secondary private address. b. In the Address field, enter a specific IP address that is within the subnet range for the instance. c. (Optional) Select Allow reassignment to allow the secondary private IP address to be reassigned if it is already assigned to another network interface. d. Click Yes, Update, and then click Close.

You can also assign a secondary private IP address to an instance by clicking Instances in the navigation pane. In the Instances table, right-click on the instance needing a secondary private IP address assignment and select Manage Private IP Addresses. Repeat step 5 above. For more information, refer to Multiple IP Addresses.

Step 4 - Allocate and Assign an Elastic IP Address to your Instance

When an instance of your Barracuda Web Application Firewall Vx is created, a public IP address is associated with the instance. That public IP address changes automatically when you STOP and START the Barracuda Web Application Firewall Vx. To resolve this issue, assign a persistent public IP address to the instance using Elastic IP addressing. For more information, refer to the Amazon Web Services article Elastic IP Addresses.

1. Log into the Amazon EC2 Management Console. 2. From the EC2 dashboard, select Elastic IPs under NETWORK & SECURITY. 3. Click Allocate New Address. 4. Click Yes, Allocate to confirm and allocate a new IP address. A random Public IP gets generated and displayed in the Allocate New Address table. 5. In the Allocate New Address table, right click on the new IP address and select Associate. 6. In the Associate Address window: a. Select the Instance and the Private IP Address of the instance from the respective lists. OR b. Select a Network Interface and the Private IP Address from the respective lists. c. Select the Allow Reassociation check box. 7. Click Yes, Associate.

If you have configured multiple internal IP addresses to the interface, then follow the steps above to allocate and assign the elastic IP address to each internal IP address, so that they can be accessible from the outside world.

Step 5 - Deploy the Barracuda Web Application Firewall Vx on Amazon Web Services

In the Amazon VPC that you configured, launch an Amazon EC2 instance with the Barracuda Web Application Firewall AMI image. The Amazon Launch Instance wizard guides you through the following steps:

1. Log into the AWS Management Console and open the EC2 Management Console. 2. From the top right corner of the page, select the region for the instance. This is important because some Amazon EC2 resources can be shared between regions.

40 2.

3. Click Launch Instance.

4. On the Step 1: Choose an Amazon Machine Image (AMI) page, select AWS Marketplace and search for the Barracuda Web Application Firewall AMI. Click Select next to the Barracuda Web Application Firewall AMI.

5. On the Step 2: Choose an Instance Type page, select an instance type from the All Instance types or General purpose table. Click N ext: Configure Instance Details to continue.

41 5.

6. On the Step 3: Configure Instance Details page: a. Enter the Number of instances you want to launch. b. Select the appropriate Network from the list in which you want to deploy the instance. c. Select the appropriate Subnet from the list and select the network interface under Network Interface section that was created in Step 2- Create a Network Interface. d. In the Advanced Details pane, keep the default setting for all parameters and click Next: Add Storage.

7. On the Step 4: Add Storage page, the table displays the storage device settings for the instance. Modify the values if required and click Next: Tag Instance.

42 7.

8. On the Step 5: Tag Instance page, add/remove the tags for the instance (if required) and click Next: Configure Security Group.

9. On the Step 6: Configure Security Group page, choose Select an existing security group to select and assign the security group(s) from the existing list, or choose Create a new security group to create a new group (see Step 1 - Create a Security Group for more information). Click Review and Launch.

43 9.

10. On the Step 7: Review Instance Launch page, review your settings before launching the instance, and then click Launch.

After you click Launch, Amazon Web Services begins provisioning the Barracuda Web Application Firewall Vx. Allow a few minutes for the Amazon Web Services Agent and the Barracuda Web Application Firewall Vx image to boot up.

DO NOT restart the Barracuda Web Application Firewall Vx while it is launching.

Step 6 - License the Barracuda Web Application Firewall Vx

If you deployed the Barracuda Web Application Firewall Vx with the Hourly/Metered option, you do not need to license the system; skip ahead to Step 7 - Verify your Configuration and Change the Password.

If you deployed the Barracuda Web Application Firewall Vx with BYOL, complete the licensing and provisioning of your system.

1. Log into the Amazon EC2 Management Console. 2. From the EC2 Dashboard, select Instances under INSTANCES.

3. In the Instances table, select the Barracuda Web Application Firewall Vx instance you created and note the Elastic IP address.

44 3.

4. Open the browser and enter the copied Elastic IP address (from step 3) with port 8000 for HTTP. No port is required for HTTPS. For example: For HTTP: http://:8000 (Unsecured) For HTTPS: https:// (Secured)

5. On the Licensing page, enter your Barracuda Networks Token and Default Domain to complete licensing and then click Provision. The Barracuda Web Application Firewall Vx connects to the Barracuda Update Server to get the required information based on your license, and then reboots automatically. Allow a few minutes for the reboot process.

Step 7 - Verify Configuration and Change the Password

1. Log into the Barracuda Web Application Firewall Vx web interface as the administrator using the URL, as described in step 4 of Licensin g of the Barracuda Web Application Firewall Vx after deploying on Amazon Web Services above. Log in with: a. Username: admin b. Password: Instance ID of your Barracuda Web Application Firewall Vx in Amazon Web Services. 2. Navigate to the BASIC > Administration page and enter your old password, new password, and re-enter the new password. Click Save Password.

Next Steps

Continue with Configuring a Service.

Load Balancing For Clustered Barracuda Web Application Firewall Vx Instances in Amazon Web Services (AWS)

45 en This guide will walk you through the steps to load balance traffic across multiple instances of the Barracuda Web Application Firewall Vx deployed in Amazon Web Services:

In this article:

en Step 1 - Deploy Multiple Barracuda Web Application Firewall Vx Instances in Amazon Web Services Step 2 - Set Up Load Balancing on the Barracuda Web Application Firewall Vx Instances Step 3 - Set Up a High Availability Environment with the Barracuda Web Application Firewall Vx

To set up High Availability environment between multiple Barracuda Web Application Firewall Vx instances in Amazon Web Services, make sure all services configured on the instance uses the WAN IP Address of the Barracuda Web Application Firewall Vx.

Step 1 - Deploy Multiple Barracuda Web Application Firewall Vx Instances in Amazon Web Services

Follow the steps mentioned in Deploying the Barracuda Web Application Firewall Vx on Amazon Web Services to deploy multiple Barracuda Web Application Firewall Vx instances. To license and configure your virtual machine, continue with Barracuda Web Application Firewall Vx Quick Start Guide for Amazon Web Services. In these instructions, let’s consider two Barracuda Web Application Firewall Vx instances as Barracuda-WAF1 and Barracuda-WAF2. Where, Barracuda-WAF1 is the first unit and Barracuda-WAF2 is the second unit.

Step 2 - Set Up Load Balancing on the Barracuda Web Application Firewall Vx Instances

1. Log into the Amazon EC2 Management Console. 2. From the EC2 dashboard, select Load Balancers under NETWORK & SECURITY.

3. Click Create Load Balancer. The Create Load Balancer window appears.

46 3.

4. In the Define Load Balancer page: a. Load Balancer Name – Enter a name for the load balancer. b. Create LB Inside – Select the VPC ID under which the Barracuda Web Application Firewall Vx instances are launched. c. Leave Create an internal load balancer and Enable advanced VPC configuration set to default value. d. Add the ports on which the Services are created and needs to be load balanced. e. Click Continue. 5. In the Configure Health Check page: a. Ping Protocol – Keep the default value i.e. HTTP. b. Ping Port – Set to 8000. By default, the Barracuda Web Application Firewall Vx listens on port 8000. If you have configured a different port through which the Barracuda Web Application firewall Vx is accessible, then specify that port number. c. Ping Path – Enter /cgi-mod/index.cgi. d. In the Advanced Details section, specify the values as per your requirement and click Continue.

6. In the Assign Security Groups page, choose Select an existing security group to select and assign the security group(s) from the existing list, or choose Create a new security group to create a new group (refer to Creating a Security Group for more information). Click Continue.

Ensure the selected group has all ports open which are configured for load balancer in step 4.

47 6.

7. In the Add EC2 Instances page, select the instances to be added to this load balancer and click Continue. 8. In the Review page, review your settings before creating the load balancer, and then click Create.

9. The Load Balancers table displays the created load balancer details.

The services configured should be accessed using the DNS Name of the created load balancer. For example, in the above example the DNS Name of the Load Balancer is WAF-LB-678529183 and the HTTP service created on port 80 can be accessible via http://WAF-LB-678529183 / ht tp://WAF-LB-678529183:80.

Step 3 - Set Up a High Availability Environment with the Barracuda Web Application Firewall Vx

Follow these steps to cluster your Barracuda Web Application Firewall virtual machines in Amazon Web Services:

Before clustering your Barracuda Web Application Firewall virtual machines, ensure the following ports are opened in Security Group a ssigned to the Barracuda Web Application Firewall virtual machines:

48 3. Manager page of each Barracuda Web Application Firewall Vx and verify that no processes are running. 4. From the ADVANCED > High Availability page of Barracuda-WAF1, enter a Cluster Shared Secret password, and click Save Changes. 5. From the ADVANCED > High Availability page of Barracuda-WAF2, do the following: a. Enter the same Cluster Shared Secret password, and click Save Changes. Both units in a cluster must have the same Cluster Shared Secret to communicate with each other. b. In the Clustered Systems section, enter the WAN IP address of Barracuda-WAF1, and click Join Cluster. Make sure that the join cluster task is not cancelled when the join is in progress.

The unit from which the join cluster is initiated will inherit the configuration from its Peer unit and have its configuration overwritten.

6. On each Barracuda Web Application Firewall Vx, refresh the ADVANCED > High Availability page, and verify the following: a. Each system's Hostname, serial number and WAN IP address appears in the Clustered Systems list. b. The identity of the system (Self or Peer) displays in the Type field. c. The Status is green for all virtual machines in the cluster. 7. View the Cluster Status from the BASIC > Status page, under Performance Statistics.

To add more units to the existing cluster, repeat step 1 to 5.a. and then do the following:

From the ADVANCED > High Availability page of the Barracuda Web Application Firewall Vx you are adding to the cluster, enter the WAN IP address of any system in the cluster in the Peer IP Address field and click Join Cluster. Verify that the following occurs: The configuration of the cluster automatically propagates to the newly added system. The new unit information propagates to all other units in the cluster. Troubleshooting the Barracuda Web Application Firewall on Amazon Web Services en To troubleshoot the Barracuda Web Application Firewall Vx on Amazon Web Services, log in to the Amazon Web Services web interface, right click on the Barracuda Web Application Firewall Vx instance and select Get System Log to view the console logs.

To use the Barracuda Web Application Firewall troubleshooting tools, log into the Barracuda Web Application Firewall Vx web interface with your credentials. Go to the ADVANCED > Troubleshooting page. The page provides various tools you can use to resolve network connectivity issues that may impact the performance of your Barracuda Web Application Firewall:

Support Connection can establish a secure tunnel connection to Barracuda Central so that a Barracuda technician can help you diagnose issues. Click Establish Connection To Barracuda Support Center to establish a connection to Barracuda Central. Contact B arracuda Networks Technical Support for assistance. Problem Report generates a report of all logs (Web Firewall Logs, Access Logs, Audit Logs, Network Firewall Logs and System Logs), backup, configuration and temporary files as well as the internal state of the system. Network Connectivity Tests provides access to a command line utility which includes ping, telnet, Dig/NS-lookup, traceroute, etc., which you can use to diagnose potential network problems/issues. TCP Dump provides access to a command line utility which includes TCP Dump, which allows the user to intercept and capture the TCP/IP and other packets transmitted or received over the network to which the Barracuda Web Application Firewall is connected. Session recording enables you to capture requests from and responses to the Barracuda Web Application Firewall for a specified Client IP Address or User ID. The captured session is stored in an XML file.

See the ADVANCED > Troubleshooting page for details and procedures. Virtual Deployment en This virtual appliance requires a 64-bit capable host. Note that only proxy mode deployments are supported with the Barracuda Web Application Firewall Vx; Bridge mode is not supported. For more information about proxy mode deployments, please see Confi guring Two-Arm Proxy Mode and Configuring One-Arm Proxy Mode.

49 In this Section Step 1: Select Your Hypervisor Deployment:

Download Package Type Hypervisor Compatibility

OVF Package VMware ESX and ESXi ("vSphere Hypervisor") versions 4.0 and 4.1, 5.0, 5.1 VMware ESX and ESXi version 3.5 Sun/Oracle VirtualBox and VirtualBox OSE version 3.2

VMX Package Deployment VMware Server 2.0+ Workstation 6.0+, Player 3.0+ Fusion 3.0+

XVA Package Deployment Citrix XenServer 5.5+

HyperV Package Deployment Microsoft Hyper-V 2008

Step 2: Getting Your Virtual Machine Up and Running: Quick Start Guide Managing Your Virtual Machine: Sizing CPU, RAM, and Disk for Your Barracuda Web Application Firewall Vx Backing Up Your Virtual Machine System State

Continue to configure the Barracuda Web Application Firewall from the web interface following instructions in Configure the Barracuda Web Application Firewall. Hypervisor Compatibility and Deployment - OVF Package en

Hypervisor Compatibility

This package's virtual appliance runs under the following hypervisors:

VMware ESX and ESXi ("vSphere Hypervisor") versions 4.0 and 4.1, 5.0, 5.1 VMware ESX and ESXi version 3.5 Sun/Oracle VirtualBox and VirtualBox OSE version 3.2

Deploying the Virtual Appliance With Your Hypervisor

ESX(i) 3.5:

Use the OVF file ending in:

-35.ovf for this environment.

1. From the File menu in the VMware Infrastructure client, choose Virtual Appliance -> Import 2. Select Import from file: and navigate to the file BarracudaWebApplicationFirewall-vm-fw__FIRMWARE__--35.ovf. 3. Clicking Next, review the appliance information, End User License Agreement, and set the name of the virtual appliance to something useful to your environment. Click Finish. 4. Once your appliance has finished importing, right-click it and choose Open Console and then click the green arrow to power on the virtual appliance. 5. Follow the Quickstart Guide -Vx instructions to provision your virtual appliance.

ESX(i) 4.x:

Use the OVF file ending in:

-4x.ovf for this environment.

1. From the File menu in the vSphere client, choose Deploy OVF Template... 2.

50 2. Select Import from file: and navigate to the file BarracudaWebApplicationFirewall-vm-fw__FIRMWARE__--4x.ovf. 3. Clicking Next, review the appliance information, End User License Agreement, and set the name of the virtual appliance to something useful to your environment. Set the network to point to the target network for this virtual appliance. 4. Once your appliance has finished importing, right-click it and choose Open Console and then click the green arrow to power on the virtual appliance. 5. Follow the Quickstart Guide - Vx instructions to provision your virtual appliance.

VirtualBox:

Use the OVF file ending in:

-4x.ovf for this environment.

1. From the File menu in the VirtualBox client, choose Import Appliance. 2. Navigate to the file BarracudaWebApplicationFirewall-vm-fw__FIRMWARE__--4x.ovf 3. Use the default settings for the import and click Finish. 4. Start the appliance. 5. Follow the Quickstart Guide - Vx instructions to provision your virtual appliance.

Hypervisor Compatibility and Deployment - VMX Package en

Hypervisor Compatibility

This package's virtual appliance runs under the following hypervisors:

VMware Server 2.0+ Workstation 6.0+, Player 3.0+ Fusion 3.0+

Deploying the Virtual Appliance With Your Hypervisor

Server 2.x:

1. Put the files ending in .vmx and .vmdk into a folder in your datastore (which you can locate from the Datastores list on your server's summary page). 2. From the VMware Infrastructure Web Access client's Virtual Machine menu, choose Add Virtual Machine to Inventory. 3. Navigate to the folder used in step 1 and click the file BarracudaWebAppFirewall.vmx from the list under Contents. Click OK. 4. Start the appliance. 5. Follow the Quickstart Guide - Vx instructions to provision your virtual appliance.

Player 3.x:

1. From the File menu, choose Open a Virtual Machine. 2. Navigate to the file BarracudaWebAppFirewall.vmx 3. Use the default settings and click Finish. 4. Start the appliance. 5. Follow the Quickstart Guide - Vx instructions to provision your virtual appliance.

Workstation 6.x:

Fusion 3.x:

51 1. From the File menu, choose Open a Virtual Machine. 2. Navigate to the file BarracudaWebAppFirewall.vmx 3. Use the default settings and click Finish. 4. Start the appliance. 5. Follow the Quickstart Guide - Vx instructions to provision your virtual appliance.

Hypervisor Compatibility and Deployment - XVA Package en

Hypervisor Compatibility

This package's virtual appliance runs under the following hypervisors:

Citrix XenServer 5.5+

Deploying the Virtual Appliance With Your Hypervisor

1. From the File menu in the XenCenter client, choose Import VM... 2. Browse to the file BarracudaWebAppFirewall--fw__FIRMWARE__-.xva and choose the Exported template radio button. 3. Clicking Next >, review the template information and click Finish to import the template. 4. Right-click the resulting template and choose New VM... 5. Follow the Quickstart Guide - Vx instructions to provision your virtual appliance. Hypervisor Compatibility and Deployment - HyperV Package en Hypervisor Compatibility

This package's virtual appliance runs under the following hypervisors:

Microsoft Hyper-V 2008

This virtual appliance requires a 64-bit capable host.

Deploying the Virtual Appliance With Your Hypervisor

1. In Hyper-V Manager, right-click your VM Host and choose Import Virtual Machine. 2. Navigate to the folder “BarracudaWebAppFirewall-vm-fw__FIRMWARE__--hyperv” and select HyperV. 3. Click Select Folder. Ensure the correct folder is selected. This folder should have the following subfolders in it: a. Virtual Machines b. Virtual Hard Disks c. Snapshots 4. Select Copy the virtual machine and Duplicate all files, and then click Import. 5. Start your virtual appliance. 6. Follow the Quickstart Guide - Vx instructions to provision your virtual appliance. Barracuda Web Application Firewall Vx Quick Start Guide en To setup your Barracuda Web Application Firewall Vx, complete the following steps:

en Before You Begin Step 1. Enter the License Code Step 2. Open Firewall Ports Step 3. Verify Configuration Step 4. Update the Firmware Step 5. Change the Administrator Password Next Step

52 Related Articles Adding Disk Space, Drives and RAM for Your Virtual Appliance Backing Up Your Virtual Machine System State

Before You Begin

Deploy the Barracuda Web Application Firewall Vx on your hypervisor. You need only a single virtual NIC on your virtual appliance.

Only Proxy mode is supported for virtual deployment. For more information about deployment modes, please see Choosing Your Deployment Mode.

Step 1. Enter the License Code

You should have received your Barracuda Vx license token via email or from the website when you downloaded the Barracuda Load Balancer ADC Vx package. If not, you can request an evaluation on the Barracuda Networks website at http://www.barracuda.com. The license token looks similar to the following: 01234-56789-ACEFG.

1. Power On your virtual appliance, making sure to open the console. 2. When the login prompt appears, log in as admin with a password of admin. 3. In the System Configuration window, use the down arrow key and select TCP/IP Configuration. Configure the following: a. WAN IP Address b. WAN Netmask c. Gateway Address d. Primary DNS Server e. Secondary DNS Server 4. If the Internet can be accessed only through an explicit proxy, configure the proxy server using Proxy Server Configuration (Optional), so that it reaches the Internet for provisioning. 5. Under Licensing enter your Barracuda License Token and Default Domain to complete provisioning. The appliance will reboot at this time. 6. Once the appliance has finished rebooting, go to http://:8000 to access the web interface and finalize configuration.

Step 2. Open Firewall Ports

If your Barracuda Web Application Firewall Vx is located behind a corporate firewall, open the following ports on your firewall to ensure proper operation:

Port Direction TCP UDP Usage

22 Out Yes No Technical Support connections

25 In/Out Yes No Email alerts

53 Out Yes Yes Domain Name Service (DNS)

80/8000 Out Yes No Virus/attack/security definition and firmware updates

123 Out No Yes Network Time Protocol (NTP)

80 Out Yes No Initial Provisioning *

* The initial provisioning port can be disabled once the initial provisioning process is complete.

Step 3. Verify Configuration

53 1. Log into the Barracuda Web Application Firewall Vx web interface as the administrator: Username: admin Password: admin 2. Go to the BASIC > IP Configuration page and configure the following: 3. Verify that the WAN IP Configuration is setup properly for IP Address, Subnet Mask, and Default Gateway. Make sure Allow Administrative Access is set to Yes. 4. Make sure Operation Mode is set to Proxy. You should review the proxy deployment options and choose your desired configuration before continuing. See Configuring Two-Arm Proxy Mode and Configuring One-Arm Proxy Mode. 5. Verify that the Primary and Secondary DNS server are correct. 6. Enter Default Hostname and Default Domain (for example, ) in the Domain Configuration. The Hostnam e will be used in reporting and the Default Domain is the domain for the system.

The above configuration puts the VM in One-Arm Proxy mode. To deploy the VM in Two-Arm Proxy mode, do the following additional configuration:

Add the interfaces (LAN and/or MGMT) by editing the VM on the VM server. Access the web interface using the WAN IP address and configure the IP addresses for the added interfaces (LAN and/or MGMT) on the BASIC > IP Configuration page.

For more information, see Configure the Barracuda Web Application Firewall.

Step 4. Update the Firmware

Click on the ADVANCED > Firmware Update page. If there is a new Latest General Release available, perform the following steps to update the system firmware:

1. Click on the Download Now button located next to the firmware version that you wish to install. To view download progress, click on the Refresh button. When the download is complete, the Refresh button will be replaced by an Apply Now button. 2. Click on the Apply Now button to install the firmware. This will take a few minutes to complete. 3. After the firmware has been applied, the Barracuda Web Application Firewall Vx will automatically reboot, displaying the login page when the system has come back up. 4. Log back into the web interface again and read the Release Notes to learn about enhancements and new features. It is also good practice to verify settings you may have already entered, as new features may have been included with the firmware update.

Step 5. Change the Administrator Password

To avoid unauthorized use, we recommend you change the default administrator password to a more secure password. You can only change the administrator password for the web interface. Go to the BASIC > Administration page and enter your old and new passwords, then click on Sav e Password.

Next Step

Continue with the next step, Configuring a Service. Sizing CPU, RAM, and Disk for Your Barracuda Web Application Firewall Vx en Barracuda Networks recommends the following sizing for initial deployment of your virtual appliance, or upgrading existing installations.

RAM, Cores, and Hard Disk

Model Maximum #Cores RAM - Recommended Hard Disk Space - Minimum Recommended Minimum

360 2 2GB 50GB

460 3 3GB 50GB

660 4 or more(1) 4GB(1) 50GB

Note: (1) 1GB per core.

Provisioning CPUs/Cores

54 You need to provision the number of cores in your hypervisor before the Barracuda Web Application Firewall Vx can make use of them. Each model can only make use of a certain number of cores. If you assign 6 cores, for example, to a model 360 Barracuda Web Application Firewall Vx, which can only make use of 2 cores, the virtual machine will turn off the extra cores that cannot be used. To add cores:

1. Shut down your hypervisor. 2. Go into Hypervisor settings. 3. Add CPUs. Note: The number of CPUs shown that you can add will vary with your hypervisor licensing and version. In some cases, the number of CPUs you can add must be a multiple of 2.

Additional cores can purchased and provisioned if required. For more information, please contact Barracuda Networks Technical Support.

Provisioning Hard Drives

Barracuda Networks requires a minimum of 50G hard disk space to run your Barracuda Web Application Firewall Vx. From your hypervisor, you can edit the provisioned size of the hard drives, or you can add a hard drive.

To add a hard drive:

1. Shut down your Barracuda Web Application Firewall Vx. 2. Take a snapshot of your virtual machine. 3. Edit the settings in your virtual machine and either increase the size of the hard drive or add a new hard drive. 4. Restart the virtual machine. As it is booting up, using the POPOUT CONSOLE, a blue screen pop-up displays asking if you want to use the new additional space. Answer Yes. Note that the pop-up will time out after 30 seconds if you do not respond, and the answer will default to No. Resizing may take several minutes, depending on the amount of provisioned hard drive space.

Backing Up Your Virtual Machine System State en Virtual machine environments generally provide a "snapshot" capability, which captures the state of a system as it's running. Once a snapshot is created, you can perform additional operations on the system and "revert" to the snapshot in the case of disaster recovery (or for any other reason). Because this feature is so powerful, Barracuda Networks strongly recommends performing a snapshot at certain points in time:

Before upgrading the Barracuda Networks product firmware. Before making major changes to your configuration (this makes snapshotting a convenient "undo" mechanism). After completing and confirming a large set of changes, such as initial configuration. As a periodic backup mechanism.

Before taking a snapshot, Barracuda Networks strongly recommends powering off the virtual machine. This step is particularly important if you are using Microsoft Hyper-V as your virtual machine environment.

Barracuda Networks recommends that you review your virtual environment documentation regarding the snapshot capabilities and be familiar with their features and limitations. Getting Started en Recommended Steps

Barracuda Networks recommends the following steps for choosing the best deployment for your network, installing, and configuring the Barracuda Web Application Firewall.

Step 1: Installing the Barracuda Web Application Firewall

55 Prepare for the Installation Connect the Barracuda Web Application Firewall to the Network Configure the IP Address and Network Settings Configure the Barracuda Web Application Firewall from the Web Interface Activate the Subscription Status Update the Barracuda Web Application Firewall Firmware Update the Attack, Virus, Security and GeoIP Definitions Step 2: Configuring a Service Step 3: Configuring Basic Service Settings Configuring SSL for Services and Servers

Step 1: Installing the Barracuda Web Application Firewall en Before proceeding with the initial setup choose the mode of deployment under Operation Mode (Proxy or Bridge All) on the BASIC > IP Configuration page. You choose the deployment mode depending on the current network configuration at your site and the types of services that you want from the Barracuda Web Application Firewall. Two-Arm Proxy is recommended for initial deployment, so the Barracuda Web Application Firewall is shipped with the Proxy mode setting. For more information on deployment, see Choosing Your Deployment Mode.

Once you have chosen the right deployment for your network you are ready to install the Barracuda Web Application Firewall and configure the initial settings.

Steps to Install the Barracuda Web Application Firewall:

1. Prepare for the Installation 2. Connect the Barracuda Web Application Firewall to the Network 3. Configure the IP Address and Network Settings 4. Configure the Barracuda Web Application Firewall from the Web Interface 5. Activate the Subscription Status 6. Update the Barracuda Web Application Firewall Firmware 7. Update the Attack, Virus, Security and GeoIP Definitions

Continue with Step 2: Configuring a Service. Prepare for the Installation en Before installing your Barracuda Web Application Firewall:

Installing the Barracuda Web Application Firewall may require certain changes to the existing network depending upon the network configuration and the deployment mode of the Barracuda Web Application Firewall you choose. Network Changes can be classified as: Hardware changes – Changes related to cabling, switches, routers, network interfaces, etc. Configuration changes – Changes related to DNS databases, IP addresses of hosts and services, router configuration etc. (Reverse proxy deployment only) If Client Impersonation is set to Yes on the BASIC > Services page, then an additional IP address should be configured on the LAN subnet of the Barracuda Web Application Firewall and this should be the default gateway configured on the back-end real servers. Note the server IP address and TCP port of Web applications you want to protect. Verify that you have the necessary equipment: Barracuda Web Application Firewall (check that you have received the correct model) AC power cord Ethernet cables Mounting rails (model 660 and higher) and screws VGA monitor (recommended) PS2 keyboard (recommended) Connect the Barracuda Web Application Firewall to the Network en 1. Fasten the Barracuda Web Application Firewall to a standard 19-inch rack or other stable location. 2. If using Reverse Proxy, then the network switch referenced in 2 (a) and (b) below may be the same physical switch. If using Bridge Path, however, then separate switches on different Layer 2 networks must be used. a. Connect a CAT5 Ethernet cable from the WAN interface on the Barracuda Web Application Firewall to the network switch where the VIPs reside. b.

56 2.

b. Connect a CAT5 Ethernet cable from the LAN interface on the Barracuda Web Application Firewall to the network switch where the Real Servers reside.

Connecting the MGMT port located on the back panel of the unit to the network switch where the VIPs reside is recommended.

3. Connect the following to your Barracuda Web Application Firewall: a. Power cord b. VGA monitor c. PS2 keyboard 4. Press the Power button located on the front of the unit. The login prompt for the administrative console displays on the monitor, and the power light on the front of the Barracuda Web Application Firewall turns on. For a description of each indicator light, refer to Front Panel Indicator Lights in the Barracuda Web Application Firewall's Administrators Guide. Configure the IP Address and Network Settings en The Barracuda Web Application Firewall is assigned a default IP address of 192.168.200.200. You can change the address using the administrative console or by pressing and holding the RESET button on the front panel.

Holding RESET for eight seconds changes the default IP address to 192.168.1.200. Holding the button for 12 seconds changes the IP address to 10.1.1.200.

To set a new IP address from the administrative console:

1. Connect your keyboard and monitor directly to the Barracuda Web Application Firewall. 2. At the barracuda login prompt, enter admin for the login and admin for the password. The User Confirmation Requested window displays the current IP address configuration of the Barracuda Web Application Firewall. 3. Using your Tab key, select Change and press Enter to change the IP address configuration. 4. Enter the new IP address, netmask, and default gateway for your Barracuda Web Application Firewall. Select Save to enter your changes. (The Primary and Secondary DNS fields may be entered at this step or from the web interface). Select Exit.

The new IP address and network settings are applied to your Barracuda Web Application Firewall. Configure the Barracuda Web Application Firewall from the Web Interface en

After specifying the IP address of the Barracuda Web Application Firewall and opening the necessary ports on your corporate firewall, configure the Barracuda Web Application Firewall from the web administration interface. This interface is accessed from a web browser on any machine that can communicate with the appliance, so it must be on the same network, or have routing set up accordingly.

Secure Access

To ensure the highest security, use HTTPS to configure your Barracuda Web Application Firewall web interface. In addition, Barracuda Networks recommends requiring HTTPS to connect to the Barracuda Web Application Firewall. To configure this setting, go to the ADV ANCED > Secure Administration page in the Barracuda Web Application Firewall web interface.

To configure the Barracuda Web Application Firewall:

1. From a web browser, for HTTP access, enter the IP address of the Barracuda Web Application Firewall followed by port 8000. For example: http://192.168.200.200:8000. For HTTPS access, enter: https://192.168.200.200 2. To log into the administration interface, enter username: admin and password: admin. 3. Select BASIC > IP Configuration, and perform the following steps: a. Enter the following information in the LAN IP Address Configuration section: i. IP Address – The address that connects the Barracuda Web Application Firewall to the Real Server network. If Client Impersonation is set to Yes on the BASIC > Services page, then an additional IP address should be configured on the LAN subnet of the Barracuda Web Application Firewall and this should be the default gateway configured on the back-end real servers. ii. Subnet Mask – The subnet mask tied to the LAN. b. Enter the IP address of your primary and secondary DNS servers (if these have not yet been set up). c. Enter the default hostname and default domain name of the Barracuda Web Application Firewall.

57 4. Click Save Changes. 5. Select BASIC > Administration, and do the following steps: a. Assign a new administration password to the Barracuda Web Application Firewall (optional but highly recommended). b. Make sure the local time zone is set correctly. Time on the Barracuda Web Application Firewall is automatically updated via NTP (Network Time Protocol). It requires that port 123 is opened for outbound UDP (User Datagram Protocol) traffic on your firewall (if the Barracuda Web Application Firewall is located behind one). It is important to set the time zone correctly because it is used to coordinate traffic distribution and timestamps appear in all logs and reports. c. If desired, change the port number used to access the Barracuda Web Application Firewall administration interface. The default port is 8000. d. Enter a web administration session expiration length (in minutes), after which an administrator will be required to log back in. e. (Optional) Specify your local SMTP server. Enter the email address for your Administrator where the system should send threat email alerts and notifications. 6. Click Save Changes. Activate the Subscription Status en After you install the Barracuda Web Application Firewall, activate Barracuda Energize Updates and other applicable subscriptions to fully enable the appliance and let it continue to receive the latest updates to all virus, attack, and security definitions from Barracuda Central. The Barracuda Energize Updates service downloads these updates to your Barracuda Web Application Firewall on an hourly basis.

To activate your subscription status:

1. At the top of the page, click the link in this message warning you that you must activate the Barracuda Web Application Firewall:

2. On the Product Activation page, fill in the required fields and click Activate. A confirmation page opens to display the terms of your subscription. a. If your Barracuda Web Application Firewall cannot communicate directly to Barracuda Central servers, note the Activation Code displayed on the confirmation page. 3. Return to the Barracuda Web Application Firewall administration interface and go to the BASIC > Status page. 4. In the Subscription Status section, verify that your subscriptions are Current. 5. If required, enter the Activation Code from step 2 and then click Activate.

It can take a few minutes for your current subscription statuses to display. If your subscription statuses are still displayed as inactivated, click Refr esh in the Subscription Status section.

If your subscription status does not change to Current, or you need help filling out the Product Activation page, call a Barracuda Networks sales representative.

Update the Barracuda Web Application Firewall Firmware en To update the firmware on the Barracuda Web Application Firewall:

1. Go to the ADVANCED > Firmware Update page. 2. Read the release notes to learn about the latest features and updates provided in the new firmware version. 3. Click Download Now next to Latest Early Release(s). Download Now is disabled if the Barracuda Web Application Firewall is already up-to-date with the latest firmware version. Click OK on the download duration window. Updating the firmware may take several minutes. Do not turn off your appliance during this process. The Barracuda Web Application Firewall begins downloading the latest firmware version. You can view the download status by clicking Refresh. A “Firmware downloaded” message displays once the download is complete. 4. Click Apply Now when the download completes. 5. Click OK when prompted to reboot the Barracuda Web Application Firewall. A Status page displays the progress of the reboot. Once the reboot is complete, the login page appears. Update the Attack, Virus, Security and GeoIP Definitions en To apply the latest attack, virus, security and geoIP definitions:

1. Go to the ADVANCED > Energize Updates page. 2. Set Automatic Update to On. Click Save Changes. This enables repeated definition updates whenever they are available.

Attack definition requires administrator to REBOOT the system. An alert message will be displayed on the Basic > Status page

58 2.

indicating new attack definition is synchronized and to apply the definitions the administrator needs to reboot the system

3. Check if the Current Installed Version is the same as the Latest Version for all definitions. 4. If the Current Installed Version is not the Latest Version, click Update to download and install the latest available attack definitions, virus definitions, security definitions or geoIP definitions. Step 2: Configuring a Service en In this article:

en What is a Service? Configuring Your First Service Steps to Configure a Service Creating SSL Enabled Services Configuring SSL for SSL Enabled Services Health Indicators for Services and Servers

The Barracuda Web Application Firewall can be configured to secure web servers from incoming traffic threats. To do this, create a Service which can receive the incoming traffic type (for example: an HTTP service can receive HTTP data), then associate security settings with that service to address the security risks of that traffic type. The Service also receives responses from the servers and applies security before returning responses to the client.

Using any Service, the Barracuda Web Application Firewall acts as a server to which the client connects on the front-end. On the back-end, the Service acts as a client to the real servers. The Barracuda Web Application Firewall fulfills each of these roles using the Service and its associated configuration settings.

What is a Service?

A Service is configured with a Virtual IP (VIP) address and a TCP port. Traffic arriving at the designated VIP and port is validated, subjected to security checks configured for the service, and then passed to one of the Real Servers associated with that Service.

Configuring Your First Service

The BASIC > Services page allows you to add a new service(s) and server(s) to be protected by the Barracuda Web Application Firewall. The type of Service you choose should correlate to the type of traffic coming into the application you are protecting, so the service can terminate and validate the requests before applying security. For example, you should select an HTTP Service for unsecured traffic, versus an HTTPS Service for secured traffic.

The types of Services you can configure with the Barracuda Web Application Firewall depend on the deployment mode you choose.

In Bridge Mode (Bridge Path) you can configure:

HTTP or HTTPS Services: Validate and apply security to unencrypted or encrypted HTTP traffic.

In Proxy Mode, you can configure:

HTTP and HTTPS Services: Validate and apply security to unencrypted or encrypted HTTP traffic; FTP and FTPS Services: Validate and apply security to unencrypted and encrypted FTP traffic; Instant SSL and Redirect Services: Implement off-loaded SSL validation and encryption for unencrypted traffic; Custom and Custom SSL Services: Allow the Barracuda Web Application Firewall to process any application layer traffic over TCP. Traffic sent by the client to a Custom or Custom SSL Service is forwarded to the back-end servers without analysis. The Barracuda Web Application Firewall does not validate the incoming requests or outgoing responses.

Steps to Configure a Service

For detailed instructions on configuring a service, go to the BASIC > Services page and click Help.

Once successfully created, a Service appears in the Services section with a green, orange, or red health indicator next to it. See Health Indicators for Services and Servers for more information. Newly configured Services, by default, use the ‘default security policy’, and have a

59 Passive enforcement mode, so at first, all URLs and Parameters are compared to the ‘default security policy’ settings. The Service page allows you to edit Services so you can change the settings or enforcement mode. For instructions on editing a Service, see Step 3: Configuring Basic Service Settings.

Creating SSL Enabled Services

To use SSL you need to select a Certificate which the service presents to authenticate itself to a client. Certificates are created or uploaded using the BASIC > Certificates page, where you can add a certificate to the available Certificate list. You choose your Service certificate from this list before using Add to create the service. You can change the certificate to any available certificate by clicking Edit for the service in the Services li st.

Configuring SSL for SSL Enabled Services

By clicking Edit next to the service on the Services section of the BASIC > Services page, you can configure the SSL supported protocols. SSL status defaults to On for a newly created SSL enabled service. If you set Enforce Client Certificate to Yes, any request from a client without a certificate immediately terminates. If you set Enable Client Authentication to Yes, the Barracuda Web Application Firewall authenticates the client with the presented certificate, or authenticates the client using an authorization policy configured through ACCESS CONTROL > Authorization. Authentication of certificates uses selected trusted certificates.

SSL enabled services allow configuration of encryption between the requesting client and the Barracuda Web Application Firewall. To encrypt transactions between the appliance and the back-end servers, refer to Back-end SSL Server Configuration.

Health Indicators for Services and Servers

The following are the health indicators displayed for each Service and server:

- Service is up; Server is responding. - If multiple servers are configured for a Service, the orange dot indicates that more than 50% of Servers are down and the Service is running. - Service is down; Server is not responding.

Continue with Step 3: Configuring Basic Service Settings. Step 3: Configuring Basic Service Settings en When created, Services default to a Passive mode of enforcement using the default Security Policy provided and updated by Barracuda Networks.

Configuring Service Settings

When a Service is created, a basic set of web firewall features are activated automatically with the default security policy which is provided and updated by Barracuda Central. These default configuration features provide an adequate amount of attack protection from the majority of web attacks. When refinements to default security are required for a web application, a variety of options provide increasingly refined settings. You can edit basic service settings to tailor attack prevention for a Service. To edit service settings, navigate to the BASIC > Services page, identify the Service you want to edit in the Services list, and click Edit next to it. The Service window displays the following sections:

Service Basic Security SSL Load Balancing

Service

Verify the settings displayed in the Service section are correct. Modify the settings if required.

Basic Security

The basic set of web firewall features can be modified in the Basic Security section. Specify values for the following fields:

a. Web Firewall Policy – By default, all Services are associated with the default security policy. To enforce a new security policy, click the drop-down list and select the desired security policy. The list includes security policies provided by the Barracuda Web

60 a.

Application Firewall (default, sharepoint, sharepoint2013, owa, owa2010, owa2013 and oracle) and previously saved customized policies (if any). To create a new policy, or to edit an existing policy, see Security Policies. If you wish to fine-tune the security policy, see Tuning Security Rules Using Web Firewall Logs. b. Web Firewall Log Level – Set the threshold for logging the error messages for the Service. This log level determines whether only the most urgent attack information, or less serious attack information including warnings or debug information are written to the logs for the Service. For example, if the log level is set to 3-Error, then logs with 0-3 log levels are logged on the BASIC > Web Firewall Logs page. Here, the 0-3 log levels include 0-Emergency, 1-Alert, 2-Critical and 3-Error logs. c. Mode – The Mode determines how the Service responds to offending traffic. By default, it is set to Passive which just logs violating events and allows the request to pass through. Active mode performs the action configured in association with the perceived threat. Note: Passive mode is recommended in the initial stages of deployment, so that no traffic to the service is broken due to false positives. d. Trusted Hosts Action – You can override default settings and configure a specific response to violations for a set of trusted hosts accessing the Service. If set to Allow or Passive, all requests from trusted hosts, including those that are possible attacks, are ignored and passed through. Allow mode doesn't log events, whereas in Passive mode, events are logged. Set to Default, if trusted hosts requests need no special handling. e. Trusted Hosts Group – Select the trusted hosts group to which you want to apply the configured Trusted Hosts Action. Truste d Hosts and Trusted Hosts Groups are configured on WEBSITES > Trusted Hosts. f. Ignore Case – This determines how, for this Service, the URLs are matched to rules like URL ACLs and URL Profiles. When set to Yes, text in upper or lower case can match the specified URL for any Barracuda Web Application Firewall rule. Note: This is applicable only to URLs, and not parameter names. g. Header Name For Actual Client IP – Enter the name of the header in which the client IP address is stored for identification by the server. h. Rate Control Status – Set to On to bind a rate control pool to limit the rate of requests for the Service. i. Rate Control Pool – Select a rate control pool you want to associate with the Service. If the pool is configured with a set of preferred clients, then the rate control policy is applied only to the requests from the preferred clients. If not, the rate control policy is applied to all requests forwarded to the Service.

SSL

See Configuring SSL for SSL Enabled Services.

Load Balancing

See Configuring Load Balancing for a Service.

Additional security for a Service can be configured using URL policies. URL policies allow Anti-Virus protection, Data Theft protection and Brute Force protection to be enabled or disabled for specific URL spaces. Configuring SSL for Services and Servers en

Configuring SSL for SSL Enabled Services

By clicking Edit next to a listed Service on the BASIC > Services page, in the SSL section you can configure SSL Encryption of data transmitted between the client and the Service. Configure the following fields:

Status – Set to On to enable SSL on your Service. Status defaults to On for a newly created SSL enabled service. Certificate – Select a certificate which should be presented to the browser accessing the Service. For information on how to upload a certificate, see Adding an SSL Certificate. SSL Protocols – Select the SSL protocol(s) to be used by the clients to establish the connection to the Service from the table. Enable SNI – Select Yes to enable Server Name Indication (SNI). Enable Strict SNI Check – Set to Yes to block access for non-SNI clients. If set to No, the certificate selected in the Certificate drop-do wn list will be used for non-SNI clients. Domain – Enter the domain name and the certificate that needs to be associated with the domain. You can enter multiple domain names and associate a certificate with each one. Client requests for domains that are not associated with any certificate will get the default certificate (i.e. the certificate selected in the Certificate drop-down list). The Configured Domains parameter displays the configured domains and associated certificates. Ciphers – Select Custom to choose the Ciphers for the Service from the Available Ciphers list. Default includes all Ciphers listed in Avail able Ciphers. Enable Client Authentication – When set to Yes, the Barracuda Web Application Firewall authenticates the client with a presented certificate, or authenticates the client using an authorization policy configured through ACCESS CONTROL > Authorization. Note: Certificate validation is performed only when both Enable Client Authentication and Enforce Client Certificate are set to Yes.

61 Enforce Client Certificate – Set to Yes if you want clients to present their certificate while connecting to the Service. If the clients fail to present their certificate, the SSL handshake is immediately terminated. Trusted Certificates – Select one or more trusted certificates, which should be used to validate the certificates presented by the clients connecting to the Service. Only those client certificates that are signed by one of these trusted certificates will be allowed access. For information on how to upload a trusted certificate, see Adding an SSL Certificate.

Select a Certificate to present to requesting clients for authentication. You can select an already uploaded certificate, or use the BASIC > Certificates page to upload a Certificate you desire. SSL enabled services allow you to handle encrypted traffic passing between the requesting client and the Barracuda Web Application Firewall. To encrypt transactions between the unit and the back-end servers, refer to SSL (Server). Certificates are authenticated using the Trusted Certificates you select. Upload Trusted Certificates on the BASIC > Certificates page.

Server Name Indication (SNI)

SNI extends the SSL/TLS protocol to solve the issue of hosting multiple domains on the same IP address. If each domain has a distinct SSL certificate, there needs to be a way for the Real Server to select the proper certificate for a particular domain. The virtual domain information is sent as part of the SSL/TLS negotiation between the client and server. Clients supporting this extension send the domain name when initializing a secure SSL session. The server side component will look at the domain name and send the corresponding certificate to the client.

For SNI to work properly, both the client browser and the web servers must support the SNI extension. SNI is already supported on most major browser platforms, and on both Apache and IIS.

With SNI, you can use the Barracuda Web Application Firewall to assign any number and any type of certificates (single, wildcard or SAN) to a single Barracuda Web Application Firewall Service. SNI support applies only to Services with type HTTPS.

The SNI extension supported browsers are:

Firefox 2.0 and higher IE 7 and higher on Windows Vista and higher Safari 5.17 on Windows 7 Google Chrome 6 or higher on Windows 7

SSL (Server)

To encrypt data transmitted between the Barracuda Web Application Firewall and the server, configure the following fields:

Server uses SSL – Set to Yes to enable SSL for communication with the back-end servers. SSL Protocols – Select the SSL protocol(s) to be used by the clients to establish the connection to the Server from the table. Validate Server Certificate – Set to Yes to validate the server certificate using an internal bundle of certificates belonging to well known Certificate Authorities. If set to No, any certificate from the server is accepted. If your servers provide self-signed or test certificates, you should set this to No. Send TLS Extensions – Set to Yes to use TLS extensions (as defined in RFC 4366) to negotiate SSL connection with the back-end server. Client Certificate – Select a certificate from the drop-down list to be used when the server requires client authentication (Barracuda Web Application Firewall authenticates itself to the Server).

Services en In this Section:

Creating an HTTP Service Creating an HTTPS Service Securing an HTTP Website with HTTPS Creating a Redirect Service Creating a Custom Service Creating a Custom SSL Service Creating an FTP Service Creating an FTP SSL Service

62 Creating an HTTP Service en An HTTP service is a controlled entry point for an HTTP web application on the server. To create an HTTP service, select HTTP as the type of service. For additional instructions go to the BASIC > Services page and click Help. Creating an HTTPS Service en

Configuring an HTTPS Service requires the configuration of a Certificate. See Configuring SSL for Services and Servers.

An HTTPS service is a controlled entry point for an encrypted HTTPS web application on the server. This service handles encrypted transactions between clients and the Barracuda Web Application Firewall, authenticating itself using a configured certificate, while acting as a server to requesting clients. To create an HTTPS service, select HTTPS as the type of service. For additional instructions go to the BASIC > Services pag e and click Help. Securing an HTTP Website with HTTPS en

Configuring an HTTPS Service requires the configuration of a Certificate. See Configuring SSL for Services and Servers.

Creating an Instant SSL Service creates two services with the same IP address: an HTTPS service with port 443 and a redirect service with port 80. The redirect service is a non-SSL service that redirects all the requests to the HTTPS service. At least one secured site domain should be specified so relevant links in the response are converted from 'http' to 'https'. For example refer to Figure 4.1; if http://www.barracuda.com is specified, all matching instances found in the outgoing response will be rewritten to https://www.barracuda.com. After the HTTPS service is added, you can edit it to add more domains which need to be rewritten in the response. Upon receiving a request, the redirect service does the redirection to the service on port 443/HTTPS which in turn sends it to the servers. The HTTPS service rewrites each “http:...” in the request into an “https:...” in the response content.

SharePoint Rewrite

Sharepoint rewrite support is relevant only if an Instant SSL service is created to protect a Microsoft SharePoint application. Normally, an Instant SSL Service rewrites the HTTP links in the responses to HTTPS by gleaning them from within HTML tags, like href. But the Sharepoint application also inserts hyperlinks outside the basic HTML tags which may not be rewritten to HTTPS with a normal ISSL Service. Enabling this option ensures that HTTP links outside HTML tags are also properly rewritten to HTTPS for responses from Sharepoint applications.

Go to the BASIC > Services page, and click Edit next to an HTTPS service to set SharePoint Rewrite Support to On. By default SharePoint Rewrite is disabled. To create a Instant SSL service, select Instant SSL as the type of service. For additional instructions go to the BASIC > Services page and click Help.

Creating a Redirect Service en

63 The redirect service is a non-SSL service that redirects all HTTP requests to an existing HTTPS service. Since the only purpose of this service is to redirect to an existing service,you cannot specify the Real Server IP address. The redirect service can allow client requests on port 80 even when the server is only serving SSL requests on port 443. To create a Redirect service, select Redirect as the type of service. For additional instructions go to the BASIC > Services page and click Help. Creating a Custom Service en A Custom Service allows the Barracuda Web Application Firewall to process any application layer protocol over TCP. Data sent by the client to a custom service is forwarded to the back-end servers without analysis. The Barracuda Web Application Firewall does not validate the incoming requests or outgoing responses. To create a Custom service, select Custom as the type of service. For additional instructions go to the BASIC > Services page and click Help. Creating a Custom SSL Service en

Configuring a Custom SSL Service requires the configuration of a Certificate. See Configuring SSL for Services and Servers.

A Custom SSL Service is a controlled entry point for an encrypted non-HTTP non-FTP web application on the server. This handles encrypted transactions between clients and the Barracuda Web Application Firewall and authentication with certificates. To create a Custom SSL service, select Custom SSL as the type of service. For additional instructions go to the BASIC > Services page and click Help. Creating an FTP Service en An FTP service is the controlled entry point for an unencrypted FTP web application on the server. To create an FTP service, select FTP as the type of service.To create an FTP service, select FTP as the type of service. For additional instructions go to the BASIC > Services page and click Help. Creating an FTP SSL Service en

Configuring an FTP SSL Service requires the configuration of a Certificate. See Configuring SSL for Services and Servers.

An FTP SSL Service is a controlled entry point for an encrypted FTP Web application on the server. This handles encrypted transactions between clients and the Barracuda Web Application Firewall and authentication with certificates. To create an FTP SSL service, select FTP SSL as the type of service. For additional instructions go to the BASIC > Services page and click Help. Securing HTTP/HTTPS Traffic en The Barracuda Web Application Firewall protects your application from the attacks that are categorized by OWASP, as well as additional attacks such as application DDoS attacks, Slow Client attacks, Session hijacking attacks, XML / SOAP based attacks, etc. This is applicable to both HTTP and HTTPS application traffic. The Barracuda Web Application Firewall provides a variety of security policies to protect websites and web services. Security Policies define matching criteria for requests, and specify what actions to take when a request matches. All policies are global and they can be shared among multiple services configured on the Barracuda Web Application Firewall. For HTTPS applications, the Barracuda Web Application Firewall decrypts the SSL traffic before matching the HTTP requests with security policies.

When a Service requires customized settings, the provided security policies can be tuned, or customized policies can be created. Each policy is a collection of nine sub-policies. Modify a policy by editing the value of the parameter(s) on the sub-policy page.

In this Section

Security Policies Configuring Request Limits How to Secure HTTP Cookies Configuring URL Protection Configuring Parameter Protection Limiting Allowed Methods in HTTP Headers and Content

64 Configuring Cloaking Configuring Data Theft Protection Configuring URL Normalization Configuring Global ACLs Configuring Action Policy Back-end SSL Server Configuration Allow/Deny Rules for Headers and URLs Allow/Deny Rules for Headers Allow/Deny Rules for URLs

Security Policies en

Overview

The Barracuda Web Application Firewall associates security policies with HTTP and HTTPS Services. A security policy has preset configured security settings which apply to any associated Service. Security policies are shareable, so once a policy is created, it can be assigned to more than one Service. The security policy rules specify inspection criteria for input or output data, identifying malicious or vulnerable data. Security policies include mostly negative and some positive elements. For most web sites, security policies sufficiently implement good web application security.

Any existing security policy can be refined manually, and new security policies can be created. Security Policies can also be refined using automated tools (see Tuning Security Rules for instructions).

Security policies include general URL and Parameter protection which is applied to all service requests. When required, more customized URL and Parameter protection can be implemented using Web Site Profiles, URL profiles, and parameter profiles.

When is a security policy associated with the Service?

When a Service is created, it is associated with the default security policy and log levels. For more information on how to configure a Service see Configuring a Service, and Configuring Basic Service Settings. The Barracuda Web Application Firewall includes the following pre-configured security policies:

default sharepoint sharepoint2013 owa owa2010 owa2013 oracle

When needed, the security policy associated with the Service can be changed or refined. Security policies define matching criteria to compare to requests, and rules for matching requests. All security policies are global, that is, they can be shared by multiple Services configured on the Barracuda Web Application Firewall.

When a Service needs refined security settings, the provided security policies can be adjusted, or customized policies can be created. To create a customized security policy, see Steps to Create a New Policy. Each policy is a collection of nine sub-policies. Modify the following sub-policies by editing the corresponding sub-policy page. The sub-policies include:

Request Limits Cookie Security URL Protection Parameter Protection Cloaking Data Theft Protection URL Normalization Global ACLs Action Policy

65 Steps To Create a New Policy

1. Go to the SECURITY POLICIES > Policy Manager page. 2. In the Create New Policy section, enter a name in the Policy Name text box and click Add. 3. The new policy appears in the Policy Overview section with the default values.

Configuring Request Limits How to Secure HTTP Cookies Configuring URL Protection Configuring Parameter Protection Limiting Allowed Methods in HTTP Headers and Content Configuring Cloaking Configuring Data Theft Protection Configuring URL Normalization Configuring Global ACLs Configuring Action Policy

Configuring Request Limits en Request limits define the validation criterion for incoming requests by enforcing size limits on HTTP request header fields. The requests that have fields larger than the specified maximums are dropped. Properly configured limits mitigate buffer overflow exploits, preventing Denial of Service (DoS) attacks.

Request Limits are enabled by default, requests that exceed the specified length are assumed buffer overflow attacks. The defaults are normally appropriate, but you might choose to change one or more of the default values under certain conditions.

When to change default values:

Defaults can be modified if the Service or the server may have problems lengths smaller than the defaults. When Action is set to Deny and Log or Deny with no Log for a Service under URL : Allow/Deny Rules on the WEBSITES > Allow/Deny page, the Barracuda Web Application Firewall continues to examine the request till it hits the default length configured. Smaller limits therefore lead to a slight performance improvement since a smaller number of bytes is parsed before denying requests. The defaults can be changed to bigger values if the original defaults result in false alarms.

Steps To Configure Request Limits

1. Go to the SECURITY POLICIES > Request Limits page. 2. Select the policy from the Policy Name drop-down list for which you want to modify request limits settings. 3. In the Request Limits section, specify values for the following fields: a. Enable Request Limits - When set to Yes, size limit checks are enforced on request headers. b. Max Request Length - Enter the maximum allowable request length. This includes the Request Line and all HTTP request headers (for example, User Agent, Cookies, Referer etc.) The Request Length limit does not include the request body, which is typically present for POST requests. Any request, whose length exceeds this limit, will be denied. c. Max Request Line Length – Enter the maximum allowable length for the request line. The request line consists of the method, the URL (including any query strings) and the HTTP version. Example: GET /index.cgi?page=home HTTP/1.1 In the above request line, GET is the method, /index.cgi?page=home is the URL and HTTP/1.1 is the version. The length of the entire line is considered when checking for request line length. d. Max URL Length – Enter the maximum allowable URL length including the query string portion of the URL. e. Max Query Length – Enter the maximum allowable length for the query string portion of the URL. f. Max Number of Cookies – Enter the maximum number of cookies to be allowed. g. Max Cookie Name Length – Enter the maximum allowable length for cookie name. h. Max Cookie Value Length – Enter the maximum allowable length for a cookie value. Requests with Cookie values that are larger than the defined setting are denied. i. Max Number of Headers – Enter the maximum number of headers in a request. If there are more headers than this limit in the request, the request is denied.

66 3.

j. Max Header Name Length – Enter the maximum allowable length for header name. k. Max Header Value Length – Enter the maximum allowable length for any request header. A request header could either be a HTTP protocol header such as "Host," "User-Agent" and so on, or a custom header such as "IIS Translate". A request may contain any number of these headers.

This setting does not apply to Cookies. Cookie lengths are instead controlled by the Cookie related parameters, Max Cookie Name Length and Max Cookie Value Length.

4. Click Save Changes. How to Secure HTTP Cookies en

Overview How Cookie Security Works Cookie Security Interaction With Other Security Features Configuring Cookie Security

Overview

Cookies provide a mechanism to store session state information on client's navigation platforms such as browsers and other user agents. Cookies can store user preferences or shopping cart items, and can include sensitive information like registration or login credentials. If a cookie can be modified, the system can become vulnerable to attacks and sensitive information can be stolen.

How Cookie Security Works

The Barracuda Web Application Firewall cookie security is transparent to back-end servers. When a server inserts a cookie, the Barracuda Web Application Firewall intercepts the response and encrypts or signs the cookie before delivering it to the client. When a subsequent request from the client returns this cookie, the Barracuda Web Application Firewall intercepts the request and decrypts it or verifies its signature. If the cookie is unaltered, the Barracuda Web Application Firewall forwards the original cookie to the server. Altered cookies are removed before the Barracuda Web Application Firewall forwards the request to the server.

Encryption prevents both viewing and tampering with cookies, so it prevents the client from accessing cookie values. For clients who need to access cookie values, use signing to allow it. When signing cookies, the Barracuda Web Application Firewall actually forwards two cookies to the client browser, one plain text cookie and one signed cookie. When a subsequent request from the client returns the cookies, if either cookie is altered signature verification fails, and the Barracuda Web Application Firewall removes the cookies before forwarding the request to the server.

Cookie Security Interaction With Other Security Features

When a cookie is encrypted it may change the length of the cookie, but the number of headers in the message remains unchanged. When a cookie is signed, it changes the length of the cookie and appends one or more headers to the forwarded message. If the SECURITY POLICIES > Request Limits configuration specifies constraints on the number or length of HTTP headers, a signed or encrypted cookie may violate the request limits and result in unwanted rejection of messages. Messages thus rejected are logged as Cloak under Action on the BASIC > Web Firewall Logs page.

Configuring Cookie Security

To encrypt or sign cookies and reject tampered cookies, you need to enable cookie security using the following steps:

1. Go to the SECURITY POLICIES > Cookie Security page. 2. Select a policy from the Policy Name drop-down list. 3. In the Cookie Security section, select the desired Tamper Proof Mode, either Encrypted or Signed. Note: Encrypting cookie data makes cookie values inaccessible to the client. If required, change values of other parameter(s): Cookie Max Age – Enter the maximum age in minutes for session cookies after which cookies are automatically expired. Cookie Replay Protection Type – Select the type of protection to be used to prevent the cookie replay attacks from the drop-down list. Custom Headers – Enter the custom headers to be used in the cookie if the parameter Cookie Replay Protection Type is set to Custom Headers or IP and Custom Headers and click Add. Secure Cookie – Set to Yes if you want to allow cookies to be returned to the web server if the client makes secure HTTPS connection only. HTTP Only – Set to Yes if you want to allow cookies to be returned to the web server if the client makes HTTP connection only. When a cookie containing HTTPOnly flag is set on the browser and client side script code attempts to read the cookie, the browser returns an empty string as the result. Enabling this feature prevents the cookie from being accessed through client-side

67 3.

scripts. Allow Unrecognized Cookies – Select whether unrecognized cookies should be allowed. Use Custom to temporarily allow unrecognized cookies after deploying. Days Allowed indicates for how long. Days Allowed – Enter the number of days unrecognized cookies will not be rejected. This field is only used when Allow Unrecognized Cookies is Custom. Cookies Exempted – Add the names of cookies to be exempted from the cookie security policy. 4. Click Save Changes. Related Articles

Cookie Tampering Attacks Logged When Barracuda Web Application Firewall Is Initially Deployed Cookie Tampering Attacks Logged When the Barracuda Web Application Firewall Is Initially Deployed en The Barracuda Web Application Firewall's default security policy signs all outgoing cookies. The Barracuda Web Application Firewall appends a digital signature to any web Server cookie before delivering it to the client’s browser. When a subsequent request from the client returns the cookie, the Barracuda Web Application Firewall intercepts the request and verifies its signature. If the cookie is intact, the Barracuda Web Application Firewall forwards the original cookie to the server. If the cookie has been altered, signature verification fails, and the Barracuda Web Application Firewall removes the cookie and forwards the request to the server without the cookie.

When the Barracuda Web Application Firewall is deployed in front of your production web Server, all new cookies sent out by the web application are signed. Note that before deploying the Barracuda Web Application Firewall many clients may already have cookies cached in their browsers. When the Barracuda Web Application Firewall encounters pre-existing, non-signed cookies, it interprets them as altered cookies and displays them as a Cookie Tampered message on the BASIC > Web Firewall Logs page.

These log entries gradually disappear as the old cookies expire and the web application sends new cookies, signed by the Barracuda Web Application Firewall. Related Articles

How to Secure HTTP Cookies Configuring URL Protection en URL requests and embedded parameters in them can contain malicious script. Attacks embedded in URL requests or their parameters are executed with the permissions of the executing component. Injection of operating system or database commands into the parameters of a URL request, cross site scripting, remote file inclusion attacks, and buffer overflow attacks can all be perpetrated through unchecked URL requests or their parameters.

Here is an example of malicious script within a URL Request: http://www.example.com/sharepoint/default.aspx/%22 );}if(true){alert(%22qwertytis

Defense from these attacks is achieved by restricting the allowed methods in headers and content for invoked URL requests, restricting the number of request parameters and their lengths, limiting file uploads, and specifying attack types to explicitly detect and block. (Attack types are configured on ADVANCED > Libraries or ADVANCED > View Internal Patterns.) URL Protection uses a combination of these techniques to protect against various URL attack types. URL Protection defends the Service from URL request attacks when no URL Profile is configured to do it. For information on URL Profiles, see Configuring Website Profiles.

Steps To Configure URL Protection

1. Go to the SECURITY POLICIES > URL Protection page. 2. Select the policy from the Policy Name drop-down list for which you want to modify URL protection settings. 3. In the URL Protection section, specify values for the following fields: a. Enable URL Protection – Select Enable to enforce URL Protection when URL Profiles are not used for validating the incoming requests. b. Allowed Methods – Specify the list of methods to be allowed in the request. The Barracuda Web Application Firewall uses this list to determine whether to allow or deny methods in the requests. See Limiting Allowed Methods in HTTP Headers and Content . c. Allowed Content Types – Specify the list of content types to be allowed in the POST body for a URL. “application/x-www- form-urlencoded” and “multipart/form-data” are typical content types that are used in form submissions. These content types are recognized by the Barracuda Web Application Firewall and cause it to parse the content into parameters and values.

68 3.

Other content types are used by custom built applications in various special ways. For example, text/xml may be used by Web Services enabled applications. These content types, when encountered in the request, are not given any special consideration, and are passed through to the server if they are allowed by this setting. d. Max Content Length – Enter the maximum content length to be allowed for POST request body. Note: Only requests with the Content-Length: headers are validated. Requests encoded using "Chunked Encoding" DO NOT have a Content-Length: header, and therefore are not subject to the Content Length check. e. Max Parameters – Enter the maximum number of parameters to be allowed in a request. Parameters can be supplied as part of the query string or as part of the request body or both. This limit applies to each method of supplying the parameter individually. For example, if the Max Parameters is 4, a maximum of 4 query string parameters are allowed and a maximum of 4 request body parameters are allowed. Thus, when both methods are combined, a maximum of 8 parameters will be allowed (4 each). f. Max Upload Files – Enter the maximum number of files that can be uploaded in one request. If the value is set to two (2), then the third (3) file upload is denied. The Passive mode logs every uploaded file that exceeds the max count. g. Max Parameter Name Length – Enter the maximum length of the parameter name in the request. h. Blocked Attack Types – Select the attack types that needs to be matched in the requests/responses. Attack Types are specifications of malicious patterns. If the value of a parameter matches one of the specified Attack Types, an intrusion is detected and logged on the BASIC > Web Firewall Logs page. Attack Types are defined with groups of Regular expression patterns. Attack Types for SQL Injection, Cross Site scripting and System Command Injection attacks are provided by default, and one or more of these can be enabled for matching against request parameters.

Each security policy is configured with default set of attack types that are applied to the matching requests. For more comprehensive validation, select other attack type patterns.

i. Custom Blocked Attack Types – Select the custom attack types that needs to be matched in the requests/responses. For information on how to create custom blocked attack types, see Configuring User Defined Patterns. j. Exception Patterns – Enter the patterns to be allowed as exceptions in spite of them being part of a malicious pattern group. The configuration should be the exact "Pattern Name" as found on the ADVANCED > View Internal Patterns page, or as defined during the creation of a "New Group" through the ADVANCED > Libraries page. The pattern name can also be found in a Web firewall log when a false positive occurs due to such a potentially "exception" pattern. For example, if the parameter value matched "sql-comments" regex pattern under "sql-injection medium" attacks on the ADVANCED > View Internal Patterns page, then adding "sql-comments" to this list will allow "sql-comments" in future. 4. Click Save Changes. Configuring Parameter Protection en To protect a service from attacks which employ the parameters of a URL query string or parameters of the form POST parameters, use SECURIT Y POLICIES > Parameter Protection. Parameter Protection defends web applications from Parameter based attacks when parameter profiles aren't used.

Parameters that contain special characters may have SQL or html tagging expressions embedded in them. Embedded SQL keywords like "OR," "SELECT," or "UNION" in a parameter, or system commands such as "xp_cmdshell" can exploit web application vulnerabilities. These attack patterns can be configured in Parameter Protection, and compared to requests and responses. If a parameter matches, the corresponding request or response is not processed.

Steps To Configure Parameter Protection

1. Go to the SECURITY POLICIES > Parameter Protection page. 2. Select the policy whose parameter protections settings you want to configure from the Policy Name drop-down list. 3. In the Parameter Protection section, configure the following fields: a. Enable Parameter Protection – Select Yes to enforce parameter protection when Parameter Profiles are not used for validating the incoming requests. b. Denied Metacharacters – Specify disallowed meta-characters in parameters. Non-printable characters such as "backspace" and UI reserved characters like "?" should be URL encoded. Denied meta-characters help prevent SQL Injection and cross-site scripting attacks. Some specified meta-characters may be valid for some parameters, resulting in valid requests being blocked. The meta-character list should be appropriately tuned for specific parameters to avoid this problem. To add meta-characters, click the Edit icon enter disallowed values. c. Maximum Parameter Value Length – Specify the maximum allowed length of any parameter value, including no-name parameters. d. Maximum Instances – Enter the maximum number of times a parameter is allowed in a request. By default, the value is set to 1. Restricting this value to one (1) avoids a large class of HTTP Parameter pollution attacks and is recommended. e. Base64 Decode Parameter Value – Set to Yes to apply base64 decoding to the parameter values. If the parameter value

69 3.

adheres to the Data URI Scheme, the base64 decoding is applied on the parameter value irrespective of Base64 Decode Parameter Value is set to Yes or No. If not, the base64 decoding is applied to the parameter value only when Base64 Decode Parameter Value is set to Yes. Once the decoding is successful, other parameter checks are enforced as per the policy settings.

The parameter value length check is always applied on the encoded/original value.

f. Allowed File Upload Type – Select Extensions to allow the files uploaded with extensions specified in File Upload Extensions. Select Mime Types to identify the content in the files before allowing to be uploaded with the mime types specified in File Upload Mime Types. g. File Upload Extensions – Specify the extensions of files which may be uploaded. '.' is a special extension allowing files with no extension, and '*' allows any extension. h. File Upload Mime Types – Specify the Mime types that are to be allowed as uploaded files. Use a "." to indicate a file with unknown mime type, and use a * to indicate any kind of mime type. i. Max Upload File Size – Specify the maximum allowed size of individual files being uploaded. j. Blocked Attack Types – Select the attack types that needs to be matched in the requests/responses. Attack Types specify malicious patterns. Parameter values which match one of the specified Attack Types indicate an intrusion and are logged on the BASIC > Web Firewall Logs page. Attack Types are defined by groups of Regular expression patterns. Attack Types for SQL Injection, cross-site scripting and System Command Injection attacks are provided by default, one or more of which can be enabled for comparison to request parameters.

Each security policy is configured with default set of attack types that are applied to the matching requests. For more comprehensive validation, select other attack type patterns.

k. Custom Blocked Attack Types – Select the custom attack types that needs to be matched in the requests/responses. For information on how to create custom blocked attack types, see Configuring User Defined Patterns. l. Exception Patterns – Enter patterns which should be allowed despite matching a malicious pattern group. Configure the exact "Pattern Name" displayed on the ADVANCED > View Internal Patterns page, or configured creating a "New Group"on the ADV ANCED > Libraries page. The pattern name is also displayed in the Web Firewall Log when it is wrongly denied (a false positive). For example, if the parameter value matched "sql-comments" regex pattern under "sql-injection medium"on the ADVA NCED > View Internal Patterns page, then add "sql-comments" to the list to allow "sql-comments" in future. m. Ignore Parameters – Specify parameters exempt from all validations. Use this to skip validations for especially large parameters that are automatically generated by servers, such as __VIEWSTATE. Since these parameters are auto-generated, they are less likely to be attacks, and therefore can safely be exempted from validation checks. Note: Ignore Parameter is an exact match; wildcard is not supported. So a value with "*" does not work like a wildcard. Examples: __VIEWSTATE, POSTBODY 4. Click Save Changes. Limiting Allowed Methods in HTTP Headers and Content en While GET and POST are the predominant methods used by web servers for information access,

HTTP allows several less known methods*:

HEAD GET POST PUT DELETE TRACE OPTIONS CONNECT

*RFC 2616 describes the above HTTP methods in detail.

The OPTIONS command allows clients to determine which methods the web server supports. Some methods allow modification of stored files, stealing of user credentials, or bypassing environment level access control checks. URL protection allows an explicit way to specify allowed or disallowed methods in URL calls. Disallowing PUT, DELETE, and TRACE is recommended. The allowed request content-types also need to be carefully restricted to prevent similar security threats. Configuring Cloaking en

70 Cloaking prevents hackers from obtaining information that could be used to launch a successful subsequent attack. HTTP headers and return codes are masked before sending a response to a client. The response headers are filtered based on the headers defined in the Headers to Filter field.

Cloaking features include:

Removing banner headers such as "Server" etc from responses. Blocking client error (status code 4xx) and server error (status code 5xx) responses.

Steps To Configure Cloaking

1. Go to the SECURITY POLICIES > Cloaking page. 2. Select the policy from the Policy Name drop-down list for which you want to modify cloaking settings. 3. In the Cloaking section, specify values for the following fields: a. Suppress Return Code – When set to Yes, the Barracuda Web Application Firewall blocks an HTTP Status code in the response header and inserts a default of custom response page in case of any error responses from the server. Two types of response error codes are suppressed: i. 4xx (client): These are 400-series error codes. These codes are intended for instances when a client seems to have erred when attempting to access a Web page. Note: The codes 401 and 407 are not suppressed since these are for authentication and the clients need to see them to return the authentication credentials. Example: 404: Page not found. ii. 5xx (server): These are 500-series error codes. These codes are intended to indicate that a server is aware that it has a problem or that it is incapable of performing a request. Example: 500: Internal Error. b. Filter Response Header – Set to Yes to remove HTTP headers in the response before relaying to the client. The HTTP headers are filtered based on the headers defined in the Headers to Filter field below. c. Headers to Filter – Define the HTTP headers to be removed from the response before serving it to the client. Note: If "set-cookie" header is added to Headers to Filter and Cookie Security is enabled, then set-cookie header is not filtered from the response. 4. Click Save Changes.

When Suppress Return Code is set to Yes, the Barracuda Web Application Firewall inserts a default or custom response page in case of any error responses from the server. Typically, the Barracuda Web Application Firewall uses the default response page for error responses from the server. You can define custom response page on the ADVANCED > Libraries > Response Pages section using A dd Response Page. The default response page can be replaced with the custom response page on:

SECURITY POLICIES > Action Policy SECURITY POLICIES > Global ACLs > Existing Global ACLs WEBSITES > Allow/Deny > URL : Allow/Deny Rules

Configuring Data Theft Protection en Data theft protection prevents unauthorized disclosure of confidential information. Configuring data theft protection requires two steps:

Specify any at risk data elements handled by the web application using Security Policy. Enable protection of these elements where needed, using URL Policy.

Sensitive data elements may require masking to prevent their unauthorized disclosure, or requests containing sensitive data may be blocked altogether. Using Security Policy, you can configure any sensitive data elements which may need protection, along with the desired way to handle them. These settings can then be used by any service associated with the security policy. URL policies applied to narrowly defined URL spaces requiring this protection can individually enable it as needed. Other URL spaces operate without unnecessarily incurring the processing hit. To optimize performance, enable data theft protection only for parts of the site known to carry sensitive information.

The SECURITY POLICIES > Data Theft Protection page allows configuration of Identity Theft data types for a Security Policy. You can enable protection for specific URLs using the WEBSITES > Advanced Security page. Security Policy Data Theft settings are then enforced only for configured URLs. While, Barracuda Energize Updates provides a set of default protected patterns such as credit card and social security numbers, these can be expanded or customized, using ADVANCED > Libraries, to include other web application specific data patterns needing protection from disclosure. Any configured pattern can be masked, or the response blocked altogether, if a protected pattern occurs in the server response.

When Data Theft Protection is enabled, the Barracuda Web Application Firewall intercepts the response from the server and matches with the pattern listed in the ADVANCED > View Internal Patterns page and ADVANCED > Libraries page (if any custom identity theft patterns). If the response matches any of the defined patterns, it is blocked or cloaked based on the Action (Block or Cloak) set. If action is set to Block, the response sent by the server is blocked. If set to Cloak, a part of the data is cloaked that is, overwritten with "X"s.

71 When set to Block, the response is blocked according to the configured action for “Identity-theft-pattern-matched-in-response” in SECU RITY POLICIES > Action Policy.

The default identity theft elements provided by the Barracuda Web Application Firewall are:

Credit Cards Directory Indexing Social Security Number (SSN)

Credit Cards and SSN

To prevent exposure of personal data such as Credit Card number and Social Security Number (SSN), select Block to block the response from the server, Cloak to overwrite the characters based on values defined in the Initial Characters to Keep and Trailing Characters to Keep parameters. By default, credit-card and ssn are set to Cloak.

Directory Indexing

If a web server is configured to display the list of all files within a requested directory, it may expose sensitive information. The Barracuda Web Application Firewall prevents exposure of valuable data by blocking the response from the server. By default, directory indexing is set to Block.

Steps to Configure Data Theft Protection:

1. From the SECURITY POLICIES > Data Theft Protection page select a policy from the Policy Name drop-down list to which you want to enable data theft protection. 2. In the Configure Data Theft Protection section, specify values for the following fields: a. Data Theft Element Name – Enter a name for the data theft element. b. Enabled – Select Yes to use this data element to be matched in the server response pages. This data element is used for matching server response pages only when Enable Data Theft Protection is also set to Yes on the WEBSITES > Advanced Security page. c. Identity Theft Type – Select the data type from the drop-down list that the element mentioned in Data Theft Element Name belongs to. The default identity theft patterns (Credit Card, SSN and Directory Indexing) are associated to data types defined under ADVANCED > View Internal Patterns > Identity Theft Patterns. If you want to associate a custom identity theft pattern created on the ADVANCED > Libraries page, select from the drop-down list and then select customized identity theft type from the Custom Identity Theft Type field below. d. Custom Identity Theft Type – Select the customized identity theft type to be used from the drop-down list. e. Action – If set to Block, the response sent by the server containing this data type is blocked. The Block mode should be used if the server should never expose this information. In the Cloak mode, a part of the data is cloaked, that is, overwritten with X’s based on Initial Characters to Keep and Trailing Characters to Keep. f. Initial Characters to Keep – Enter the number of initial characters to be displayed to the user when the data of this data type is identified in a server page. For example, an online shopping service displays a user’s credit card number 1234 0000 0000 5678. If Initial Characters to Keep is set to 4, the credit card number is displayed as 1234 XXXX XXXX XXXX. g. Trailing Characters to Keep – Enter the number of trailing characters to be displayed to the user when the data of this data type is identified in a server page. For example, an online shopping service displays a user’s credit card number as 1234 0000 0000 5678. If Trailing Characters to Keep is set to 4, the credit card number is displayed as XXXX XXXX XXXX 5678. 3. Click Add to add the above configuration settings.

Custom Identity Theft Patterns

The default data theft types are displayed under Protected Data Types in the SECURITY POLICIES > Data Theft Protection page. You can also create custom identity theft data types on the ADVANCED > Libraries page to use.

Creating a Custom Identity Theft Pattern

1. Go to the ADVANCED > Libraries page, Identity Theft section, enter a name in the New Group field and click Add. 2. Click Add Pattern next to the created identify theft pattern group. The Identity Theft Patterns window appears. Specify values for the following fields: a. Pattern Name – Enter a name to identify the pattern. b. Status – Set to On if you wish to use this pattern for pattern matching in the responses. c. Pattern Regex – Define the regular expression of the pattern or click the Edit icon to select and insert the pattern. d. Pattern Algorithm – Select the algorithm to associate with the pattern from the drop-down list. e. Case Sensitive – Select Yes if you wish the pattern defined to be treated as case sensitive. f. Pattern Description – (Optional). Enter the description for the pattern defined. Example, Visa credit card pattern. This indicates

72 2.

the pattern used here is the visa credit card pattern. 3. Click Add.

Using a Custom Identity Theft Pattern

1. Go to the SECURITY POLICIES > Data Theft Protection page. 2. Select a policy from the Policy Name drop-down list. 3. In the Configure Data Theft Protection section, enter a name in the Data Theft Element Name text field. 4. Set Enabled to Yes to use this data element to be matched in the server response pages. This data element is used for matching server response pages only when Enable Data Theft Protection is also set to Yes on the WEBSITES > Advanced Security page. 5. Select CUSTOM from the Identity Theft Type drop-down list. 6. Select the Identity theft pattern you created from the Custom Identity Theft Type drop-down list. 7. Set the Action to Block or Cloak. If set to Block, the response sent by the server containing this data type is blocked. The Block mode should be used if the server is never expected to expose such information. In the Cloak mode, a part of the data is cloaked, that is, overwritten with X’s based on Initial Characters to Keep and Trailing Characters to Keep. 8. If required, change the values of Initial Characters to Keep and Trailing Characters to Keep and click Add. 9. Now, you should bind this policy to a Service, so that any request coming to that service is matched with the pattern and then processed.

Turning on Data Theft Protection using URL Policy

To use Data Theft Protection for a requested URL, from the WEBSITES > Advanced Security page you must set Enable Data Theft Protection to Yes for the appropriate URL Policy, either a URL policy matching the requested URL, or if the URL has no matching policy, for the default URL Policy. When Enable Data Theft Protection is set to Yes for a requested URL, the Data Theft Protection settings from the Service's Security Policy will be enforced for this request. Configuring URL Normalization en The Barracuda Web Application Firewall normalizes all traffic before applying any security policy string matches. For HTTP data, this requires decoding Unicode, UTF, or Hex to base text, to prevent disguised attacks using encoding formats for which string matches are not effective.

Normalization is always enabled if the Barracuda Web Application Firewall is active. The Default Character set parameter specifies the character set encoding type for incoming requests. ASCII is the default.

In some cases multiple character set encoding is needed, as for a Japanese language site which might need both Shift-JIS and EUC-JP encoding. To add character set encoding, set the Detect Response Charset parameter to Yes. All response headers will be searched for a META tag specifying the character set encoding type and any supported types will be added dynamically.

Double encoding is the re-encoding of the encoded data. For example: The UTF-8 escape for the backslash character is %5C, which is a combination of three characters i.e. %, 5, and C. So the Double encoding is the re-encoding either one or all the 3 characters by using their corresponding UTF-8 escapes as %25, %35, and %63.

Steps To Configure URL Normalization

1. Go to the SECURITY POLICIES > URL Normalization page. 2. Select the policy from the Policy Name drop-down list. 3. In the URL Normalizationsection, specify values for the following fields: a. Default Character Set– Select the character set decoding type to be used for incoming requests. By default, it is set to UTF-8. The character set decoding type are: i. English only: ASCII (7-bit), ISO-8859-1 (8-bit) ii. Unicode: UTF-8 iii. Chinese: GBK, GB2312, HZ, BIG-FIVE, EUC-TW, ISO-2022-CN iv. Japanese: Shift-JIS, EUC-JP, ISO-2022-JP v. Korean: EUC-KR, JOHAR, ISO-2022-KR b. Detect Response Charset – Set to Yes to detect the character set decoding in the response page through the META tags Content-Type headers. When set to No, it will not detect the character set decoding of the response. Instead it will use the static settings of "Default Character set". c. Parameter Separators – Select the url-decoded parameter separator to be used from the drop-down list. d. Apply Double Decoding – Set to Yes to detect decoding of the character set after the completion of regular URL normalization. If decoding fails, the request is blocked in active mode and log gets generated in the BASIC > Web Firewall Logs page. In passive mode the request is allowed and also the logs get generated. 4. Click Save Changes. Configuring Global ACLs

73 en Global ACLs (URL ACLs) are strict allow/deny rules shareable among multiple services configured on the Barracuda Web Application Firewall. They are associated with configured Security Policies.

Steps To Configure Global ACLs

1. Go to the SECURITY POLICIES > Global ACLs page. 2. Select the policy from the Policy Name drop-down list. 3. In the Create Global ACL section, specify values for the following: a. URL ACL Name – Enter a name for the URL ACL. b. URL Match – Enter a URL to be matched against the URL in the request. The URL should start with a "/" and can have at most one " * " anywhere in the URL. Examples: /Bank/Forms/*, /images/*. c. Extended Match – Define an expression that consists of a combination of HTTP headers and/or query string parameters. This expression is used to match against special attributes in the HTTP headers or query string parameters in the requests. Use '*' to denote "any request", that is, do not apply the Extended Match condition. For information on how to write extended match expression, see Extended Match Syntax Help. d. Extended Match Sequence – Enter a number to indicate the order in which the extended match rule must be evaluated in the requests. e. Action – Select the action from the drop-down list to be taken on the request matching this URL. i. Process – Processes any request matching this ACL. ii. Allow – Allows the request by disabling all security checks on an incoming request that matches the ACL. It also disables Data Theft on such responses. iii. Deny and Log – Denies any request matching this ACL and also logs the event. The request is not subjected to any security policies. This is an unconditional Deny. When a request is denied, the Barracuda Web Application Firewall sends a cryptic error response. iv. Deny with no Log – Same as Deny, but the event is not logged. v. Temporary Redirect – Redirects the denied request with the 302 status code to the URL specified in the Redirect URL fi eld. vi. Permanent Redirect – Redirects the denied request with the 301 status code to the URL specified in the Redirect URL fi eld. f. Redirect URL – Specify a URL to which a user should be redirected if Action is set to Redirect. 4. Click Add. Configuring Action Policy en Action policy is a collection of settings that decide what action to be taken when a violation occurs. It consists of a set of attack groups and associated attack actions with it. The following attack groups are available:

advanced-policy-violations application-profile-violations param-profile-violations protocol-violations request-policy-violations response-violations url-profile-violations

The attack action specifies the action to be taken for a particular type of web attack. The attack action can be modified by clicking Edit next to it. For description about the attack actions under each attack group, see Attacks Description - Action Policy.

Steps to Edit an Attack Action Policy

1. Go to the SECURITY POLICIES > Global ACLs page. 2. Select the policy from the Policy Name drop-down list. 3. In the Action Policy section, identify the attack action and click Edit next to it. The Edit Attack Action window appears. Specify values for the following: a. Action – Select the action to be enforced when this attack is encountered. i. Protect and Log – Blocks any request with the specified attack with a log message. ii. Protect and no Log – Blocks any request with the specified attack with no log message. iii. Allow and Log – Logs the request error. iv. None – Allows the request by ignoring the violation. b. Deny Response – Select the response to be sent to the client if the request is denied. A deny response is used when Action is set to Protect and Log or Protect and no Log.

74 3.

i. Close Connection – Closes the connection to the client sending the invalid request. ii. Send Response – Sends the specified response page for the denied request. iii. Temporary Redirect – Redirects the request with the 302 status code to the URL specified in the Redirect URL field below. iv. Permanent Redirect – Redirects the request with the 301 status code to the URL specified in the Redirect URL field below. c. Redirect URL – Enter the URL to be used to redirect the request if the deny response is set to Redirect. The Redirect URL should be specified when the status-code in HTTP Status is one of 3xx redirect response codes.

The parameter "Redirect URL" should be specified in one of the following formats: http://domain/url https://domain/url /url Where URL and domain can be any ASCII strings. URL can be empty.

Examples:

http://secure.xyz.com/error.html https://secure.xyz.com/logerror.cgi /error.html

Response Page – Select the response page to be sent to the client, if the parameter Deny Response is set to Send Response. Follow Up Action – Select the follow up action to be taken if the request is denied. a. None – Allows the request by ignoring the violation. b. Block Client-IP – Blocks all client requests to the Service for the time specified in Follow Up Action Time. c. Challenge with CAPTCHA – Denies the response and any subsequent requests from the same client IP address will be tracked for the next 900 seconds, and will be challenged with a CAPTCHA image. The client will not be allowed to access any further resource until the CAPTCHA is answered. This is to thwart any reconnaissance efforts from the automated clients which are found to be suspicious due to such attack activity. The number of attempts for solving such a CAPTCHA challenge is five (5), and the number of re-fetches of the CAPTCHA image allowed is 128. Such tracked client IP addresses will have to answer the CAPTCHA if they are idle for more than 300 seconds. Note that the Follow Up Action Time has no relevance to this option. a. Follow Up Action Time – Specify the time in seconds to block the client IP, if Follow Up Action is set to Block Client IP. 4. Click Save Changes.

Back-end SSL Server Configuration en To use SSL encryption between the Barracuda Web Application Firewall and a server, Edit the server from the list of Servers in the BASIC > Services list and set Server uses SSL to Yes in the SSL (Server) section. The Barracuda Web Application Firewall can validate the server certificate using trusted certificates. If the server provides a self signed certificate, Validate Server Certificate should be No. You can also configure a client certificate for the service to present to the server. This certificate configuration is needed if the server requires client authentication, because the service acts as a client to the back-end server when it forwards requests. Online help provides more detailed instructions for configuring these settings.

SSL for Barracuda Web Application Firewall to Server Transmissions

The Barracuda Web Application Firewall also provides server-side encryption, and can provide a certificate to the servers for client authentication (the Barracuda Web Application Firewall acting as the client to the back-end servers). This protects services configured on the Barracuda Web Application Firewall. The client-server negotiations include the following:

The Barracuda Web Application Firewall receives and verifies the Real server’s certificate. The Barracuda Web Application Firewall may provide a certificate in return if client authentication is required by the back-end server.

The SSL handshake allows the server and the Barracuda Web Application Firewall to authenticate each other. Once mutually authenticated, both use keys for encryption, decryption, and tamper detection during the SSL sessions.

To configure the Barracuda Web Application Firewall to use SSL in Server communications, add a Server for the respective service on the BASI C > Services page using the Add column, and configure the Barracuda Web Application Firewall to validate the server certificate. For more information on Client Certificates, refer to How to Use Client Certificates.

Allow/Deny Rules for Headers and URLs en The WEBSITES > Allow/Deny page allows you to define strict access control rules for the Services. Further a request with any violation is allowed or denied based on the settings in this URL ACL and Header ACL. These controls include location checks, form checks, size checks, and content checks both to and from the servers. They can also set landing page and entry controls, and they can provide custom error responses and request redirection.

In this Section:

Allow/Deny Rules for Headers Allow/Deny Rules for URLs Allow/Deny Rules for Headers en You can enforce strict limitations on incoming headers intended for a service using the WEBSITES > Allow/Deny Rules > Header : Allow/Deny Rules section. You can sanitize HTTP headers that carry sensitive information identifying the client and some application-specific state information passed as one or more HTTP headers. A header ACL can be configured to prevent attack types and stop potentially malicious metacharacters and keywords from being allowed in a header.

To create a Header ACL rule:

1. Go to the WEBSITES > Allow/Deny Rules page. 2. In the Header : Allow/Deny Rules section, identify the Service which needs a header ACL rule. 3. Click Add next to the Service. The Create Header ACL window appears. 4. Specify appropriate values for the given fields and click Save.

For more information, click Help in the web interface. Related Articles:

Allow/Deny Rules for URLs Allow/Deny Rules for URLs en Strict allow/deny rules for a web application can be configured on the WEBSITES > Allow/Deny page. Allow/Deny rules allow you to customize access to the web application based on a set of matching criteria. An administrator can configure a rule to control access to certain portions of the web application as per the business requirement without changing any configuration on the web application itself.

A rule can be configured for a URL match, a Host header match and a set of optional extended match criteria (example: client IP address or the HTTP method). Once a match is found, the request will be processed as per the configured action. The rule action can be configured to either redirect the incoming request to another absolute URL, or to continue the processing of the request using the other security layers of the Barracuda Web Application Firewall, in addition to allowing or denying a request explicitly.

To configure a specific match, click Add or Edit next to the Service and use the Extended Match widget. For rule matching and subsequent evaluation, URL match and Host header matches are prioritized over extended matches. If more than one rule with the same URL match/Host header match is configured, they are evaluated based on the specified extended match sequence.

There are two ways of redirecting a request using the URL ACL:

Set the Action parameter to Temporary Redirect or Permanent Redirect, and specify the Redirect URL. Set the Action parameter to Deny and Log, set the Deny Response to Temporary Redirect or Permanent Redirect and specify the Redirect URL.

The first case is not considered an attack, therefore:

It is logged at a lesser severity. Passive mode has no effect on it.

The second case is a suspected attack, therefore:

It is logged at a higher severity. Passive mode is applied so that the request is not denied.

76 To create a URL ACL rule:

1. Go to the WEBSITES > Allow/Deny Rules page. 2. In the URL : Allow/Deny Rules section, identify the Service to which you want to add the URL ACL rule. 3. Click Add next to the Service. The Create ACL window appears. 4. Specify appropriate values for the given fields and click Save.

For more information, click Help in the web interface. Related Articles:

Allow/Deny Rules for Headers Web Services and XML Firewall Protection en In this Section

Web Services Configuring XML Firewall to Protect a Web Application Web Service Validation Web Services en Overview

A web application is designed to take input from a human user and display output to a human user. In contrast, a web service is an application that is accessible on the web but is intended to be used by another application. Web services share business logic, data, and processes through a programmatic interface. Web services allow businesses to communicate with each other and with clients without requiring inside knowledge of each other's infrastructure and security configurations. They are used to assist organizations in streamlining business processes, providing increased efficiency and reduced application integration costs.

Web Services Implementation

Web services use a universal language to send data and instructions to one another over the Internet with no translation required. The term web service describes a standardized way of integrating web based applications using the Extensible Markup Language (XML), Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL), and Universal Description, Discovery, and Integration (UDDI) open standards over an Internet protocol (usually HTTP). XML is used to tag the data, SOAP is used to exchange the data, WSDL is used for describing the services available, and UDDI is used for listing available services.

For example, consider two banks needing to share account balance information. Figure 14.1 illustrates the steps to share the data using a web service:

1. Bank A creates a web service description (in the XML-based WSDL format) that describes web service required inputs and outputs (for example, the customer's account number and password) and sends a SOAP request to register it with a UDDI service. 2. Bank B sends a SOAP request to the UDDI service to look up information about Bank A's web service. (While using a UDDI service is common practice, it is not a requirement for a web service.) 3. Bank B sends a SOAP request to Bank A's web service to retrieve the WSDL definition and bind to that web service. 4. Bank B sends a SOAP request to Bank A's web service that conforms to the WSDL definition.

In this example, access to account information must be restricted to approved intermediaries, requiring authentication through passwords, public keys, or other mechanisms. In addition, the bank might want to prioritize requests (such as by how much customers are paying for the service), confirm that payment for the service is received, or send a receipt. Each function requires that information be secure from unauthorized access, attack, and data theft.

77 A business can combine multiple web services to accomplish a task. For example, a travel service might define one web service for interacting with a client application, another web service for communicating with a credit card service (with the travel service acting as the client of the credit card service), another for communicating with one or more hotel services, and another for communicating with one or more airline services.

WSDL

A web service description (WSDL document) is a human-readable document, written from the web service perspective, that describes the expectations and functionality of a particular web service, and clarifies how client and service should interact. A potential client reads the web service description, to learn how to correctly interact with the service.

WSDL is an XML grammar for describing network services as collections of communication end points capable of exchanging messages. WSDL service definitions provide documentation for distributed systems and serve as a recipe for automating the details of application communications.

Web Service Vulnerabilities

Web services are vulnerable to many of the same attack risks as other web applications, but also face additional vulnerabilities including:

Publicly available WSDL documents provide a blueprint for the service. The document details messaging request and response, expected parameters (including data type), and available operations for the service. By analyzing its WSDL document, a hacker not only knows exactly what the service is supposed to do, but also which parts are open to attack through techniques such as malformed SOAP messages and other XML parser attacks. A WSDL document may reveal what tools generated the Web service, providing attackers with more insight into potential vulnerabilities. SOAP and XML are standards used to wrap data for easy consumption. SOAP envelops information to deliver messages seamlessly between applications. XML includes metadata to describe the structure of the information. CDATA is used to delineate information in the message that should not be parsed. Malicious code or characters can be embedded in the elements or CDATA, allowing unintentional display or execution by the receiving application or service. XML encapsulation (a form of cross site scripting) can embed commands that tie up system resources or gain unauthorized access. XML-based attacks can overload XML parsers which process SOAP messages. Attackers that put in recursive relationships to create entity expansions, bogus parameters, or even significant amounts of white space, can cause XML parsers to be overloaded or to behave unpredictably. Any type of application behind a web service interface, including a packaged application, an internally developed application, a desktop application, or a legacy mainframe application carries its own security vulnerabilities. These inherent security risks are even more

78 exposed through a web service interface. Because each application type approaches security its own way, it’s a significant security challenge to protect these services.

Web Service Protections

The following table describes possible web service attack techniques and the corresponding protection provided by the Barracuda Web Application Firewall.

Technique Description of Attack Barracuda Web Application Firewall Protection

Schema Poisoning Manipulating the WS schema to alter the Protects against schema poisoning by data processed by the application. validating that content adheres to the defined WSDL and schema.

XML Parameter Tampering Injection of malicious scripts or content into Protects against parameter tampering by XML parameters. validating that parameter values are consistent with the WSDL and schema specifications.

Inadvertent XDoS Sending poorly encoded SOAP messages Inspects SOAP at the header, envelope, and that cause the application to fail. message level to ensure proper structure and content.

WSDL Scanning Scanning the WSDL (business API) to Uses web services cloaking to hide the true uncover sensitive information about the internal URI of sensitive web services. application data format.

Coercive Parsing Injection of malicious content into the XML. Utilizes real-time WS-I checking and content inspection to block malicious payloads.

Oversized Payload Sending oversized files to create an XDoS Inspects transmitted data and enforces attack (similar to a buffer overflow attack). element, document, and other maximum sizes.

Recursive Payload Sending mass amounts of nested data to Validates WSDL and schema formats, create an XDoS attack on the XML parser. inspects SOAP headers, envelopes, and messages, and ensures that WS-I standards are met.

SQL Injection Hiding a malicious SQL command inside a Utilizes real-time WS-I checking and content SOAP wrapper attempting to uncover or inspection to compare to schema. modify back-end data.

Replay Attacks Using repetitive SOAP messages to force an Includes request-level throttling technology to XDoS attack ensure resources cannot reach a fail state.

External Entity Attack Parses XML input from untrusted sources Can suppress external URI references to using an incorrectly configured XML parser. protect against external manipulation of data.

Information Disclosure Exposes unencrypted Web Service message Has extensive SSL security capabilities at data to anyone watching application traffic. the ASIC level to ensure end to end encryption of XML traffic.

Malicious Code Injection Delivers scripts embedded deep within Ensures SOAP messages conform to SOAP messages directly to applications and customized policies. databases.

Identity Centric Attack Forges credentials in an attempt to access Enforces authentication (basic or strong) at sensitive data the SOAP message level.

Processing Instructions (PI) Uses PI (a text data section that is ignored by the XML parser) to pass instructions to Can block requests containing Processing applications. Instructions (PI).

79 Inline or external DTDs Uses DTDs (a text data section that is Can block requests containing both inline or ignored by the XML parser) to pass external DTDs. instructions to applications.

External References Uses requests containing external entities Can block requests containing external including external URI references or external entities including external URI references or DTDs (text data sections that are ignored by external DTDs. the XML parser) to pass instructions to applications.

Configuring XML Firewall to Protect a Web Application en The "XML Firewall" feature is available only in the Barracuda Web Application Firewall 660 and above.

Configure the XML Firewall with the following steps:

1. Turn on the XML Firewall on WEBSITES > XML Validations, by setting Enable XML Firewall to Yes. 2. Import the Schema file(s) and WSDL file for the web service you want to protect. 3. Bind the Imported Schema file(s) and WSDL file to the website; select the validations you wish to enforce and enable validation checking for the website. 4. View or modify the Validation Settings for the XML features you choose to enforce.

Import the Schema file(s) and WSDL file for the Web Service

Import the Schema file(s), and then the WSDL file for your website on the WEBSITES > XML Validations page Import Schema/WSDL section using the following steps:

1. Select the File Type you want to import: SCHEMA or WSDL.

Import all Schema files and WSDL references before importing the WSDL file.

2. Enter the Name you want to appear in the display list for this imported file. For example: Encoding. 3. Optionally, you can enter the Namespace you want to appear in the display list for this imported file. For example: http://schemas.xmlsoa p.org/soap/encoding. 4. Click Browse..., locate the desired file and select it. 5. Click Import to upload the file. It will appear in the Imported Schema/WSDLs display with the provided Name and Namespace.

Repeat the import process for all Schemas and WSDL references before importing the WSDL file.

Bind the Imported Schema file(s) and WSDL file to the Website

To bind the schema(s) and WSDL to the website, do the following:

1. Click Add next to the desired website in the WEBSITES > XML Validations, XML Protected URLs list to bind the imported WSDL to the URL you want to protect. The Add Protected URL window appears. Do the following settings: a. Data Format – You must choose SOAP if you want to enforce WS-I Validations or SOAP Validations. Otherwise, you may choose XML to intercept generic XML data. b. Enforce WSDL – Select the WSDL you want to bind to the website. c. URLs - Enter the URL pattern you want to protect using XML Firewall. Note: Selectively choose URLs requiring SOAP or XML validations to avoid introducing unnecessary latency in serving requests. d. Direction – Select Requests, Responses or Both to be validated with the bound WSDL. e. Enforce XML Validations – Set to Yes to enforce the settings configured on WEBSITES > XML Protection > XML Validation Settings. f. Enforce WS-I Validations – Set to Yes to enforce the settings configured on WEBSITES > XML Protection > WS-I Basic Profile Assertions. Note: Data Format must be SOAP for this setting to apply. g. Enforce SOAP Validations – Set to Yes to enforce the settings configured in WEBSITES > XML Protection > SOAP

80 1.

Validations. Note: Data Format must be SOAP for this setting to apply. h. Set Status to On to enable XML firewall validations for this website. To disable all of your Enforce ... Validations settings for this website, set Status to Off. 2. Click Add to save your settings and bind them to the selected website. 3. Click Edit from WEBSITES > XML Validations, XML Protected URLs list by the desired website to change the enforcement parameters, the direction of enforcement, or to turn off XML firewall for this website by setting Status to Off. 4. Click Delete to remove the WSDL binding on the web service.

View or Modify the Validation Settings for the XML Firewall

Default settings for validations are provided for the XML Firewall. You can edit those settings on the WEBSITES > XML Protection page of the web interface.

Web Service Validation en XML Validation Settings

The XML Validation Settings allows you to set custom validation rules for XML requests or responses. For example, a rule that aborts request processing if there are more than 50 total elements in the XML or limit the message size or total number of bytes, minimizing the chance of an unknown attacker flooding the service with too much data.

SOAP Validations and the WS-I Basic Profile tests (described in the next sections) determine whether a SOAP message is valid, identifying invalid messages as intrusions. Blocking the invalid messages is enabled through XML Validation Settings.

The XML validation parameters are set to default values which can be modified.

The XML requests which violates the XML validation rules are listed under the attack group xmlfwdos-violations on the SECURITY > Action Policy page. Action policy specifies the action to be taken when a violation occurs. You can edit the default attack action settings for a policy.

WS-I Basic Profile Assertions

The Web Services Interoperability Organization (WS-I) Basic Profile Version 1.0 contains implementation guidelines for the core web services specifications: XML 1.0, XML Schema 1.0, SOAP 1.1, and WSDL 1.1. These guidelines define how the specifications should be used to develop inter-operable web services. The WS-I test tools Basic Profile Test Assertions can be used to verify that a web service conforms to these requirements. The Barracuda Web Application Firewall performs these tests during run time to validate SOAP messages.

There are forty two test case parameters, all set to Yes by default, meaning the test is applied; a No setting would cause that test to be ignored. You can modify existing settings.

XML requests violating the WS-I Basic Profile Assertions are listed under the attack group xmlfwwsi-assertion-failures on the SECURITY > Action Policy page. Action policy specifies the action to be taken when a violation occurs. You can edit the default attack action settings to implement the desired attack response.

SOAP Validations

SOAP is the transfer mechanism protocol for sending web service descriptions in an HTTP message. The SOAP validation parameters set the SOAP validation checks to apply. (These checks verify the message adheres to SOAP standards.)

SOAP is a lightweight communication protocol for exchanging data using XML over HTTP. SOAP is a mechanism that provides communication between web applications. SOAP is both platform independent and language independent. SOAP was developed as a W3C standard protocol. SOAP is a call-response mechanism that operates in a client-server paradigm. The client application makes a call to the server, passing in parameters, and the server provides a response. Both call and response are transported in the form of XML documents.

SOAP messages are susceptible to a number of potential attacks. Unintentionally exposing SOAP services could make the back-end server or application vulnerable to attacks. These attacks include the same attacks as in HTTP, such as SQL injection, and buffer overflow attacks. SOAP makes the back-end server more vulnerable because it allows actions to be invoked remotely on the back-end server.

There are four SOAP validation parameters, which are all set to No by default. You can edit the existing values setting them to Yes to validate these SOAP standards.

The XML requests which violate the SOAP Validations are listed under the attack group xmlfw-soapviolations on the SECURITY > Action Policy page. Action policy specifies the action to be taken when a violation occurs. You can edit the default attack action settings to implement

81 the desired attack response.

Advanced Security en In this Section

Enabling Antivirus Protection for File Uploads and Downloads Enabling Data Theft Protection Enabling Brute Force Protection How to Configure Session Tracking Enabling Clickjacking Protection for a Service Configuring User Defined Patterns Regular Expression Notation How to Clear Locked Out Clients

Enabling Antivirus Protection for File Uploads and Downloads en Virus scanning is enabled on a per URL basis. It should only be enabled for URLs which allow file uploads and downloads because virus checking is a performance intensive task.

To enable Antivirus for file uploads/downloads

1. From the WEBSITES > Advanced Security page in the Advanced Security section, identify the service for which you want to enable Antivirus checking. 2. Click Edit next to that Service. The Edit URL Policy window appears. 3. In the Edit URL Policy section: a. Set Enable Virus Scan to Yes. b. Set Status to On. c. Set Mode to Active. 4. Click Save Changes.

When Virus Scan is enabled for a Service, all requests passing through the Barracuda Web Application Firewall for that Service are scanned for viruses, and any traffic containing viruses is blocked.

Antivirus Details

The Barracuda Web Application Firewall uses the Clam AV integrated Antivirus engine to scan files for embedded viruses and malware. Barracuda Networks does its own research to create the AV signatures and push them out to all units with active Energize Updates subscriptions. The Barracuda Web Application Firewall Antivirus engine supports all file types the Clam AV engine supports. Integration with the Antivirus engine uses streaming, so chunks of data are sent to the AV engine as they are received. Once the AV engine returns scanned data, the data is pushed to the back-end server.

The file size limitation for Antivirus scanning is currently set to 25Mb, set in the Clam engine so it knows what file size it should expect. Barracuda Networks Technical Support can change the file size limit, however, customers do not have access to this configuration setting. The Clam engine rejects the connection request for files that are too large. Files larger than the configured limit result in a log entry indicating the scan failed because the file size was too large. Enabling Data Theft Protection en Data theft protection prevents unauthorized disclosure of confidential information. Configuring data theft protection requires two steps:

82 Specify any at risk data elements handled by the web application using Security Policy. Enable protection of these elements where needed, using URL Policy.

When set to Block, the response is blocked according to the configured action for “Identity-theft-pattern-matched-in-response” in SECU RITY POLICIES > Action Policy.

The default identity theft elements provided by the Barracuda Web Application Firewall are:

Credit Cards Directory Indexing Social Security Number (SSN)

Credit Cards and SSN

Directory Indexing

Steps to Configure Data Theft Protection:

83 2.

g. type is identified in a server page. For example, an online shopping service displays a user’s credit card number as 1234 0000 0000 5678. If Trailing Characters to Keep is set to 4, the credit card number is displayed as XXXX XXXX XXXX 5678. 3. Click Add to add the above configuration settings.

Custom Identity Theft Patterns

Creating a Custom Identity Theft Pattern

Using a Custom Identity Theft Pattern

Turning on Data Theft Protection using URL Policy

Brute Force Protection

To enable Brute Force protection, edit the default URL policy from WEBSITES > Advanced Security. Brute Force attacks attempt unauthorized access by repeatedly bombarding the system with guessed parameters.

Preventing Brute Force Attacks

Brute Force protection sets a maximum number of requests (all requests or only invalid requests) to a URL space from a single client, or from all sources, within a configured time interval. It blocks offending clients from making further requests. You can specify exception clients for which no maximum is enforced. Bruteforce protection prevents the following types of rate based attacks:

Brute force attempts to gain access – Repetitive login failures in quick succession may be an attempt to gain unauthorized access using guessed credentials. Brute force attempts to steal session tokens – Session tokens, authentication mechanisms for requests by already authenticated users,

84 can be guessed and stolen through repeated requests. Distributed Denial of Service attacks (DDoS) – Repeated requests for the same resource can impair critical functionality by exhausting server resources. Vulnerability scanning tools – High rates of requests can probe web applications for weaknesses. Typically these tools execute a database of commonly known and unknown (blind) attacks which are executed in quick succession.

Other Brute Force Attack Prevention 1. To detect brute force attacks against session management (too many sessions given out to a single IP address or range), use session tracking. 2. To control the rate of requests to specific resources (URL spaces), and to provide different levels of service to different sets of clients, use rate control pool.

On the WEBSITES > Advanced Security page, locate the desired URL policy and click Edit in the Options column next to it. Configure the following values to configure protection from Brute Force attacks:

Enable Bruteforce Prevention – Set to Yes to enable bruteforce attack prevention for this URL policy. Enable Invalid status code only – Set to Yes to monitor and count only invalid requests from a single client or all sources. If set to No, both valid and invalid requests from a single client or all sources are counted. Requests exceeding the configured Max Allowed Accesses Per IP and Max Allowed Accesses From All Sources are blocked. Count Window – Specifies the time interval in seconds to which the Max Allowed Accesses Per IP or Max Allowed Accesses From All Sources applies. Range: 1 - 6000; Default: 60 (one minute). Max Allowed Accesses Per IP – Specifies the maximum number of requests allowed to this web application per IP address. Range: 1 - 65535; Default: 10. Max Allowed Accesses From All Sources – Specifies the maximum number of requests allowed to this web application from all sources. Range: 1 - 65535; Default: 100. Counting Criterion – Specifies whether requests from all sources, or requests per IP are counted. Values: Per IP, All Sources; Default: Per IP. Exception Clients – Specifies IP addresses for which no maximum number of accesses is enforced. You can enter a single, or a range of IP addresses, or a combination of both with a comma (,) as a delimiter. The range of IP addresses must be separated with a hyphen (-). This makes an exception list of client IPs (unlimited access users). This list should not have any overlapping IP ranges. Values: Suitable IP Range;

Click Save Changes to save the above settings. How to Configure Session Tracking en

Session Tracking

A Session refers to all requests a single client makes to a server. A session is specific to the user and for each user a new session is created to track all requests from that user. Every user has a unique session identified by a unique session identifier. Session Tracking enables the Barracuda Web Application Firewall to limit the number of sessions originating from a particular client IP address in a given interval of time. Limiting the session generation rate by client IP address helps prevent session-based Denial of Service (DoS) attacks. To configure Session Tracking use WEBSITES > Advanced Security and choose Edit from Options. Specify the desired session protection fields:

New Session Count – Maximum number of new sessions allowed per IP address; Range: 1 - 65535; Default: 10. Interval – The time in seconds for which the number of sessions cannot exceed the New Session Count setting; Range: 1 - 6000 seconds; Default: 60. Session Identifiers – The token type used to recognize sessions. Choose from the list, or see Configuration of Session Identifiers to add a Session Identifier. Exception Clients: List clients which are exempted from this protection. IP address ranges should be separated by a "-" (hyphen). Multiple ranges or IP addresses can be listed with "," (comma) separation. The list should not contain overlapping IP address ranges. Status – Set to On to enable session tracking.

After configuring the above fields, click Save Changes.

Configuration of Session Identifiers

Configuring session identifiers allows the Barracuda Web Application Firewall to recognize session information in requests and responses.To create a new session identifier, perform the following steps:

85 1. Go to the ADVANCED > Libraries > Session Identifiers section. 2. Locate the desired identifier and click Edit, or to add a new identifier, click Add Session Identifiers. 3. Enter or modify the session Identifier Name. This name will appear in the list of Session Identifiers from which you choose when you configure Session Tracking. 4. Enter or modify the following session token parameters: Token Name, Token Type, Start Delimiter, End Delimiter. For example, “JSESSIONID=12345;” would be configured with session Token Name: JSESSIONID, Token Type: Parameter, Start Delimiter: = and E nd Delimiter: ; to allow Barracuda Web Application Firewall to successfully extract the Session ID 12345. 5. Newly added or edited Session Identifiers appear in the Session Identifiers list on the Edit Session Tracking page when you choose the Edit option on the WEBSITES > Advanced Security > Session Tracking section.

Enabling Clickjacking Protection for a Service en Clickjacking (also known as UI redressing and iframe overlay) is a malicious technique where a user is tricked into clicking on a button or link on a website using hidden clickable elements inside an invisible iframe. This attack hijacks clicks intended for the visible page and routes the user to an application and/or domain on another page. The Barracuda Web Application Firewall uses the X-Frame-Options HTTP response header to detect and prevent frame based UI redressing. The X-Frame-Options header is inserted to indicate whether a browser should be allowed to render a page in a "frame" or "iframe", and if allowed, the frame origin that needs to be matched. The three values of the X-Frame-Options header are:

Never – The browser will not render the page if it is contained within a frame. Same Origin – The browser will allow rendering only if the top-level browsing context is same as the origin. If it is different, the browser will block rendering of the page. Allowed Origin – The browser will allow rendering only if the top-level browsing context is same as specified in the Allowed Origin URI f ield.

When “Clickjacking” is enabled for a Service, make sure NO Response Rewrite rule is configured with the header name 'X-Frame-Options' for that Service on the WEBSITES > Website Translations > HTTP Response Rewrite section. Also, if the back-end server is inserting 'X-Frame Options' header in the response, then enabling Clickjacking or configuring Response Rewrite rule is not needed. If your website is rendered inside a iframe, then “Clickjacking” should not be turned On, as it will prevent rendering the website inside the iframe. By default, Clickjacking is turned Off.

To enable Clickjacking protection for a Service:

Perform the following steps:

1. Go to the WEBSITES > Advanced Security page. 2. In the Clickjacking Protection section, identify the Service for which you want to enable clickjacking protection and click Edit next to it. The Edit Clickjacking Protection window appears. a. Set Status to On. b. Select the appropriate option next to Render Page Inside Iframe to specify how the page should be rendered in a frame. c. If Render Page Inside Iframe is set to Allowed Origin, specify in the Allowed Origin URI field the top-level browsing URI for which rendering in a frame is allowed. 3. Click Save Changes.

Configuring User Defined Patterns en The Barracuda Web Application Firewall allows you to create customized data patterns which can be detected and handled according to configured security settings.

The Barracuda Web Application Firewall uses regular expressions (regex) to define data type patterns. Custom data types can be defined using regex patterns to implement advanced data type enforcement on input parameters. For guidelines on how to write regular expressions, see Exten ded Match Syntax Help. The pattern-match engine recognizes the lexical patterns in text and compares inputs to defined data type patterns. For example, the following is the default regex pattern for a Visa credit card:

86 4[[:digit:]]{12}|4[[:digit:]]{15}

A pattern can also be associated with an algorithm, for example, an algorithm to validate a credit card number can be associated with a credit card pattern. The algorithm runs on all strings matching the regular expression to decide whether they actually conform to this pattern.

Internal Patterns

The ADVANCED > View Internal Patterns page includes Identity Theft Patterns, Attack Types, Input Types, and Parameter Class. Each data type exhibits a unique pattern. These patterns can be bound to a policy or to profiles of an web application to validate the incoming requests.

The patterns displayed by default under each pattern group cannot be modified. To create a modified pattern, use the Copy function to copy a pattern, then modify it as required. The copied pattern group can be found on the ADVANCED > Libraries page under the corresponding group. You can modify or delete patterns as required, and then apply them to a service security policy. For more information on how to copy a pattern group, refer to Steps to Copy a Pattern Group.

The following provides a brief description about the internal patterns.

Identity Theft Patterns

Identity theft is the loss of personal data resulting in fraud. Disclosure of sensitive information such as credit card numbers, banking information, passwords, or usernames in service communication might enable identity theft. The Barracuda Web Application Firewall prevents unauthorized exposure of at risk data.

The Identity Theft container includes Credit Cards, Social Security Numbers, and Directory Indexing data types. In addition, customized identity theft patterns can be created and used. For more information, see Enabling Data Theft Protection.

Attack Types

An attack is a technique used to exploit vulnerabilities in web applications. Attacks can insert or modify code in requests. If a request contains an attack pattern, it is dropped. The attack data type container includes patterns for identifying Cross-site Scripting, Remote-file Inclusion, SQL Injection, Directory Traversal, and OS Command Injection attacks. In addition customized attack data types can be created and used.

Input Types

Input data types are used to validate the HTTP request parameters. Inputs come from web forms, applications and Services, custom client applications, or file based records. This validation ensures that the data conforms to the correct syntax, is within length boundaries, and contains only permitted characters or numbers. Requests failing validation are assumed intrusions and are blocked. Input types are defined using reg-ex patterns. Default Input Types including credit cards, numeric, hex-number, alpha, alphanumeric, string, name, and date are provided. In addition, customized Input Types can be defined and used.

Parameter Class

Parameter class defines acceptable values for parameters. Parameter classes are bound to Parameter Profiles using WEBSITES > Web Site Profiles > Parameter Profiles and specify validation criteria for parameters in a request. In addition to the internal parameter classes, customized parameter classes can be created and used.

Steps to Copy a Pattern Group

Do the following to copy a pattern group:

1. From the ADVANCED > View Internal Patterns page identify the group you want to copy. 2. Click Copy next to that group. The Copy window appears. 3. In the New Group field, specify a new name for the group and click Paste. 4. Navigate to the ADVANCED > Libraries page. The new pattern group appears under the group to which it belongs. 5. Click Edit Pattern to edit a particular pattern. 6. Click Delete to delete a particular pattern.

Creating and Using Custom Attack Types

The ADVANCED > Libraries > Attack Types section allows creation of custom attack data types which, when detected in a request, identify the request as an attack. One or more patterns which define the format of the attack type can be added to each group.

Creating a Custom Attack Type Pattern

1. Go to the ADVANCED > Libraries > Attack Types section. 2.

87 2. Enter a name in the New Group text box and click Add. The new attack type group created appears in the Attack Types section. 3. Click Add Pattern next to that group. The Attack Types window appears. Specify values for the following fields: a. Pattern Name - Enter a name for the pattern. b. Status - Set to On if you wish to use this pattern for pattern matching in the responses. c. Pattern Regex - Define the regular expression of the pattern or click the Edit icon to select and insert the pattern. d. Pattern Algorithm - Select the algorithm to be associated with the pattern from the list. e. Case Sensitive - Select Yes if you wish the pattern defined to be treated as case sensitive. f. Pattern Description - Optional. Enter a description for the defined pattern. Example, Visa credit card pattern would indicate the pattern matches a visa credit card. 4. Click Add.

Using a Custom Attack Type

The added attack type pattern becomes available under Custom Blocked Attack Types on the following pages and sections:

ADVANCED > Libraries > Custom Parameter Class WEBSITES > Web Site Profiles > URL Profiles SECURITY POLICIES > URL Protection SECURITY POLICIES > Parameter Protection

The Custom Blocked Attack Types are enabled by default under the ADVANCED > Libraries > Custom Parameter Class section and the WE BSITES > Web Site Profiles > URL Profiles section. Whereas in the SECURITY POLICIES > URL Protection and SECURITY POLICIES > Parameter Protection pages you have to manually select the custom attack types.

Creating and Using Custom Input Types

The Barracuda Web Application Firewall includes a collection of predefined and custom input data types, which can be used to validate HTTP Request parameters. Input data types are used to validate that request parameters conform to expected formats. Most attacks can be prevented by properly validating input parameter values against expected input data types. Input Type validation enforces the expected formats rather than trying to identify malicious values. Requests failing validation are identified as intrusions and blocked. Default Input Types including alpha-numeric strings, credit card, date and positive-long-integer are provided. Custom Input Data Types can also be added.

The ADVANCED > Libraries > Input Types section allows you to create customized input data types. One or more patterns which define the format of the input type can be added to each group.

Creating a Custom Input Type Pattern

1. Go to the ADVANCED > Libraries > Input Types section. 2. Enter a name in the New Group text box and click Add. The new input type group created appears in the Input Types section. 3. Click Add Pattern next to that group. The Input Types window appears. Specify values for the fields and click Add to save the pattern.

Using a Custom Input Type

Perform the following steps to use a custom input data type:

1. Go to the ADVANCED > Libraries > Custom Parameter Class section. 2. Click Add Custom Parameter Class. The Add Custom Parameter Class window appears. 3. In the Name text box, enter a name for the custom parameter class. 4. Select CUSTOM from the Input Type Validation drop-down list. 5. Select the custom input type you created from the Custom Input Type Validation drop-down list. 6. In the Denied Metacharacters text box, enter the metacharacters or click the Edit icon to select and apply the metacharacters to be denied in this parameter value. 7. Select the required check box(es) of Blocked Attack Types and Custom Blocked Attack Types and click Add. 8. Bind this custom parameter class to a parameter profile.

Creating and Using Custom Parameter Class

The ADVANCED > Libraries > Custom Parameter Class section allows creation of custom parameter classes which enforce expected input formats and block attack formats for request parameters. One or more patterns which define the format of the data type can be added to each group. Bind the custom parameter class to a parameter profile by adding a new parameter profile or editing an existing parameter profile using W EBSITES > Web Site Profiles.

Creating a Custom Parameter Class

88 1. Go to the ADVANCED > Libraries > Custom Parameter Class section. 2. Click Add Custom Parameter Class. The Add Custom Parameter Class window appears. Specify values for the following fields: a. Name - Enter a name for the custom parameter class. b. Input Type Validation - Select the expected type of value for the configured parameter on the WEBSITES > Web Site Profiles. Most of the attacks could be prevented by properly validating input parameter values against the expected input. Input Type validation enforces the expected value type as opposed to looking for malicious values. Values of configured parameters are validated against the specified Input Type and requests with failed validations are detected as intrusions and blocked. c. Custom Input Type Validation - Select the expected custom input data type for the configured parameter. d. Denied Metacharacters - Enter the metacharacters to be denied in the parameter value, or click the Edit icon to select and apply the metacharacters. e. Blocked Attack Types - Select the check box(es) to detect malicious patterns in the configured parameter. An intrusion is detected when the value of the configured parameter matches one of the specified Attack Types and the request is blocked. f. Custom Blocked Attack Types - Select the custom attack type check box(es) to be used to detect the intrusions. 3. Click Add to add the above configuration.

Using a Custom Parameter Class

Perform the following steps to use a custom parameter class:

1. Go to the WEBSITES > Web Site Profiles page 2. In the Service section, click the Web Site drop-down list and select the Service for which you wish to add the parameter profile. 3. In the URL Profiles section, select the check box next to the URL profile to which you want to add the Parameter profile. 4. In the Parameter Profiles section, click Add Param. The Create Parameter Profile window appears. 5. In the Parameter Profile Name text box, specify a name for the parameter profile. Ensure the Status is set to On. 6. Select CUSTOM from the Parameter Class drop-down list. 7. Select the custom parameter class you created from the Custom Parameter Class drop-down list and click Add. 8. Now, the parameter profile is used to validate the requests coming for the Service you selected depending on the Mode you configured in the URL profile. For more information on URL and Parameter Profiles. See Configuring Website Profiles.

Creating and Using Custom Response Page

The ADVANCED > Libraries > Response Pages section allows creation of customized HTML response pages for HTTP requests that violate security policies on the Barracuda Web Application Firewall. Either Edit an existing default response page or use Add Response Page to add customized response pages that can be shared among multiple Services.

Creating a Custom Response Page

1. Go to the ADVANCED > Libraries > Response Page section. 2. Click Add Response Page. The Add Response Page window appears. Specify values for the following fields: a. Response Page Name - Enter a name for the response page. b. Status Code- Enter the HTTP status for the response page. Examples: i. 403 Forbidden ii. 405 Method Not Allowed iii. 406 Not Acceptable c. Headers- Enter the response headers for the response page. Examples: i. Allow - What request methods (GET, POST, etc.) does the server support? ii. Content-type - Content type of the resource (such as text/html). iii. Connection - Options that are specified for a particular connection and must not be communicated by proxies over further connections. iv. Location - Where should client go to get document? v. Refresh - How soon should browser ask for an updated page (in seconds)? d. Body- Enter the response body for the response page. The following macros are supported: i. %action-id - This will be replaced by the attack ID of the violation which resulted in the response page to be displayed. ii. %host - This will be replaced by the host header which sent the request. iii. %s - This will be replaced by the URL of the request which caused the violation. iv. %client-ip - This will be replaced by the Client IP of the request which caused the violation. v. %attack-time - This will be replaced by the time at which the violation occurred. vi. %attack-name - This will be replaced by the attack name of the violation which resulted in the response page to be displayed. 3. Click Add to add the new custom page.

Example of a custom response: The request from %client-ip at %attack-time for the URL %s cannot be served due to attack %action-id on the

89 host %host.

An image can also be embedded in the response page. Here are the steps to do so:

1. Convert the image to base64 using openssl or any other utility. Example: openssl base64 -in barracuda.jpg -out barracuda-jpg.b64 2. Embed the base64 encoded image into html with the "img" tag. Example:

Using a Custom Response Page

The added response page is listed under the following pages and sections:

SECURITY POLICIES > Global ACLs > Existing Global ACLs SECURITY POLICIES > Action Policy > Action Policy WEBSITES > Allow/Deny > URL : Allow/Deny Rules

Perform the following steps to use a custom response page:

Steps to Use a Custom Response Page in the URL : Allow/Deny Rules

1. Go to the WEBSITES > Allow/Deny > URL : Allow/Deny Rules section. 2. Click Add next to the Service for which you want to configure the response page. The Create ACL window appears. 3. In the URL ACL Name text box, enter a name for the URL ACL. 4. Select Response Page from the Deny Response drop-down list. 5. Select the response page you created from the Response Page drop-down list. 6. If required change values of other parameter(s) and click Add.

Steps to Use a Custom Response Page in the Action Policy

1. Go to the SECURITY POLICIES > Action Policy > Action Policy section. 2. Click Edit next to the action policy for which you want to add the response page. The Edit Attack Action window appears. 3. Select the response page you created from the Response Page drop-down list, and click Save Changes.

Steps to Use a Custom Response Page in the Existing Global ACLs

1. Go to the SECURITY POLICIES > Global ACLs > Existing Global ACLs section. 2. Click Edit next to the URL ACL for which you want to add the response page. The Edit Global ACL window appears. 3. Select the response page you created from the Response Page drop-down list, and click Save Changes.

Regular Expression Notation en The Barracuda Web Application Firewall employs a regular expression (regex) engine to evaluate regular expressions (as defined in POSIX 1003.2) used as values in various parameters. Regular expressions allow you to specify complex relationships. The following table describes syntax rules that apply when creating a regular expression for a parameter value.

Regular expressions use raw bytes/characters for everything except for NUL(0x00 that gets escaped to %00) and LF(0x0a that gets escaped to %0a).

Value Meaning

x Match the character x.

. Match any character (byte) except newline.

[xyz] Match the pattern (character class) among x, y, or z. Matching is case dependent.

[abj-oZ] Match the pattern (character class with a range) among a, b, any letter from j through o, or Z. Matching is case dependent.

90 [^A-Z] Match anything except the pattern (negated character class), that is, any character but those in the class, which in this case is any character except an uppercase letter.

[^A-Z\n] Match anything except the pattern (negated character class), which in this case is any character except an uppercase letter or a newline.

r+ Match zero or more of r, where r is any regular expression.

r? Match zero or one of r (that is, an optional r), where r is any regular expression.

r{2,5} Match two to five of r.

r{2,} Match two or more of r.

r{4} Match exactly 4 of r.

"[xyz]\"foo" Match the literal string: [xyz]"foo

\X If X is an a, b, f, n, r, t, or v, then match the ANSI-C interpretation of \x applies. Otherwise, it is a literal X (used to escape operators such as an asterisk [*]).

\0 Match a NULL character (ASCII code 0).

\123 Match the character with octal value 123.

\x2a Match the character with hexadecimal value 2a.

(r) Match the r. Parentheses are used to override precedence; expressions in parentheses are evaluated first.

rs Match the regular expression r followed by the regular expression s. This type of pattern is called concatenation.

r|s Match either an r or an s. This type of pattern is called alternation.

r/s Match an r if it is followed by an s. The text matched by s is included when determining whether this rule is the "longest match," but it is then returned to the input before the action is executed, so the action only sees the text matched by r. This type of pattern is called trailing context.

^r Match an r at the beginning of a line (that is, when starting to scan or immediately after a newline has been scanned). Note: The circumflex (^) character means beginning of the input string when it appear at the beginning of a pattern. If it appears elsewhere, it is treated as a character.

r$ Match an r at the end of a line (that is, just before a newline). This is equivalent to r/\n. Note: The dollar sign ($) character means end of the input string when it appear at the end of a pattern. If it appears elsewhere, it is treated as a character.

The following are special characters (that is, have special meaning as described in the above table) and must be escaped by prefixing a back-slash (\) in order to be recognized as the character itself:

. [ ] ( ) ^ $ / * + ? { } \ |

The following characters must be escaped or quoted during header rule configuration for proper rule matching: White spaces[' ', '\t', '\n'], the brackets '[' '(' and ')' ']] and ';' Precede each character with the "\" character to escape it, or quote the entire string.

The regular expressions listed in Regular Expression Values table are grouped according to precedence, from highest precedence at the top to

91 lowest at the bottom. For example, the following two expressions are identical because the asterisk (*) operator has higher precedence than concatenation, and concatenation has higher precedence than alternation (|): foo|bar* (foo)|(ba(r*))

This pattern matches either the string "foo" or the string "ba" followed by zero or more "r" strings.

Inside a character class, all regular expression operators lose their special meaning except escape (\) and the character class operators dash (-), right bracket (]), and circumflex (^) at the beginning of the class. Valid character class expressions are the following: [:alnum:] [:alpha:] [:blank:] [:cntrl:] [:digit:] [:graph:] [:lower:] [:print:] [:punct:] [:space:] [:upper:] [:xdigit:]

These expressions are equivalent to the corresponding standard C isXXX function. If used in case-insensitive mode, [:upper:] and [:lower:] are equivalent to [:alpha:].

A rule can have at most one instance of the / or $ operators. The start condition (^) can only occur at the beginning of a pattern, none of these operators can be grouped inside parentheses. A ^ character that does not occur at the beginning of a rule or a $ character that does not occur at the end of a rule loses its special properties and is treated as a normal character.

If more than one match is found, the rule matching the most text is used. If two or more matches are of the same length, the first rule is chosen.

Usage Examples:

^r: Match the beginning of an input string only. For example, ^[a-z]+ matches foo but does not match 1foo because the latter does not begin with an alphabetic character. [^a-z]: Negate character class. This form matches anything other than a lower case alphabetic character. For example, ^[^a-z] matches 1foo but does not match foo. ^ anywhere else: Literal character. For example, ^(^|[a-z]) matches foo and ^1foo but does not match 1foo.

Usage Examples: $

r$: Match the end of an input string only. For example, [a-z]+$ matches foo and 1foo but does not match foo1. $ anywhere else: Literal character. For example, ([a-z]+|$) matches foo, 1foo, foo1, and foo$.

Usage Examples: Combinations

^r$: Match the pattern exactly. There can be no additional characters. (r1|r2$): The dollar sign is treated as a literal character. (^r1|r2): The circumflex is treated as a literal character.

How to Clear Locked Out Clients en The client IP address(es) are blocked when a request from the client matches any of the following policy settings:

Follow Up Action set to Block Client-IP for an attack on the SECURITY POLICIES > Action Policy page. Enable Bruteforce Prevention set to Yes in the URL policy associated with the Service on the WEBSITES > Advanced Security page. Session tracking Status set to On for a Service on the WEBSITES > Advanced Security page.

The administrator can unblock the locked client IP address(es) using Clear Locked Out Clients on the WEBSITES > Advanced Security page.

To unblock a client IP address

1. Go to the WEBSITES > Advanced Security page, Clear Locked Out Clients section. 2. In the Client IP Address field, specify the IP address of the client that you want to unblock. 3. Click Remove from the Lock Out List. 4. Click Clear All to clear all blocked client IP addresses. Application DDoS Attack Protection

92 en In this Section

Configuring IP Reputation Filter Configuring DDoS Policy Slow Client Attack Prevention How To Configure Secure Browsing For An HTTPS Service Configuring IP Reputation Filter en

Overview

In order to prevent geographically distributed DoS attacks which span multiple sub networks, the Barracuda Web Application Firewall provides an IP reputation based filter which can apply to an entire geographic region or collection of regions spanning multiple countries and/or continents.

This feature is available ONLY in Firmware Version 7.7 and above.

You can configure a Geo Pool with one or more geographic regions and allow or deny requests from it. IP addresses can be filtered based on the following categories:

Geo Pool – The IP address is from an included geographic region. Barracuda Reputation Blocklist – The IP addresses that are identified as potential originators of spam, malware and bots. TOR Nodes – The IP addresses that are identified as TOR. Anonymous Proxy – The IP address is from an anonymizer that hides the IP address of the requesting client. Satellite Provider – The IP address is from a Satellite Internet Service Provider (ISP) so the IP address of the requesting client is unknown.

Anonymous Proxy and Satellite Provider IP addresses are not specific to geographic regions. IP addresses are compared to the MaxMind database to determine if the requester is a known anonymizer or ISP address.

Once an IP Reputation Pool is created, it can be associated with one or more Services using the IP Reputation Filter section.

Geographic Filtering

You can create an IP Reputation pool on the WEBSITES > IP Reputation page. Use the Add IP Reputation Pool section, or edit a Service in the IP Reputation Filter section and select New IP Reputation Pool ... from the IP Reputation Pool list to create a new IP reputation pool.

Steps to Create a New IP Reputation Pool:

1. Enter a name for the new Geo Pool in New IP Reputation Pool Name.

The name can include alphanumeric characters, periods (.), hyphens (-) and underscores (_). Any other special characters such as space, semicolon, asterisk, etc. are not allowed.

2. Select the geographic region(s) to include in your IP Reputation Filter using the Expand button. Expand lists smaller regions inside a continent, and Collapse lists discrete continents. When you can discretely select the areas you desire, select one or more entities you wish to geographically filter. Alternatively, you can use Select All or Deselect All. 3. Click Add to save the new IP Reputation pool. The created pool appears in the IP Reputation Pools list showing the configured settings.

Use the IP Reputation Pools section to edit or delete an existing IP reputation pool.

To Edit: Select the Edit icon from the Options column next to the desired IP Reputation Pool. To Delete: Select the Delete icon from the Options column next to the IP Reputation Pool you wish to remove.

Click Help on the relevant page for more information.

You must associate the newly created IP Reputation Pool to a Service to enable filtering for the selected geographic region. See Applying an IP Reputation Filter to a Service.

Applying an IP Reputation Filter to a Service

To associate an IP reputation pool to a Service, perform the following steps:

93 1. Go to the WEBSITES > IP Reputation > IP Reputation Filter section. 2. Identify the Service to which you want to associate an IP reputation pool. Click Edit next to it. The Edit IP Reputation Filter window appears. 3. In the IP Reputation Filter section: a. Set Enable IP Reputation Filter to On to enable the filter for the service. b. Set Enable Logging to Yes if you want to generate logs for the IP reputation rule. The generated logs are displayed on the ADV ANCED > Network Firewall Logs page. 4. In the Geo IP Filter section, set the Action to Allow or Block: a. Allow – Allows the traffic ONLY from the selected geographical regions, but blocks the traffic from other geographical regions. b. Block – Blocks the traffic ONLY from the selected geographical regions, but allows the traffic from other geographical regions. 5. In the Block IP Categories section, select the IP categories that needs to be blocked for this Service. If set to Block, the requests from the IP addresses of the selected category will be terminated and logged on the ADVANCED > Network Firewall Logs page (if Enable Logging is set to Yes). You can override any of these IP address(es) and allow by adding the IP address(es) in Allowed Networks unde r the Exception Networks section. a. Barracuda Reputation Blocklist – Set to Block to block the IP addresses that have been identified as potential originators of spam, malware and bots. b. TOR Nodes – Set to Block to block the IP addresses that have been identified as TOR. c. Anonymous Proxy – Set to Block to block the IP addresses that are used as anonymizers to hide the identity of client's IP address. d. Satellite Provider – Set to Block to block the IP addresses from the Satellite Internet Service Providers (ISPs) that provide internet service. 6. In the Exception Networks section, enter the IP address(es) that needs to be considered an exception despite originating from the geographical region specified in the IP Reputation pool, or from the Barracuda Blacklist. 7. Click Add. The configured IP Reputation Filter will now apply to all requests for the Service.

Click Help on the relevant page for more information.

Configuring DDoS Policy en The DDOS Policy allows administrators to validate incoming users by challenging them with CAPTCHAs (Completely Automated Public Turing test to tell Computers and Humans Apart) to find out if a client is a regular browser, a BOT, or a crawler. Administrators can configure DDOS Policy to issue CAPTCHAs to all clients who access a URL space, or to issue CAPTCHAs only to clients with suspicious profiles.

The DDOS policy provides a way to evaluate a client and determine if it is suspicious or not. When Evaluate Clients is set to On, the Barracuda Web Application Firewall embeds JavaScript challenges in responses that are going out. The client is tagged as suspicious if more than a configured number of requests do not come back with the JavaScript challenge answer, indicating the requests are coming from an automated source such as a bot or a crawler which cannot execute JavaScripts.

The client tagged as suspicious is forced to answer a CAPTCHA challenge before accessing the URL space. Suspicious client IP addresses are tracked and challenged with a CAPTCHA image for a period of time. The client is not allowed to access any further resource until the CAPTCHA is answered. This thwarts reconnaissance efforts from suspicious clients.

Clients which answer the CAPTCHA can access the URL space. If a validated client remains idle for more than the configured Expiry Time secon ds, it is challenged with CAPTCHA to access the resource again. This re-issuance of CAPTCHA after an Expiry Time ensures that a public IP validated as a good client source once does not remain permanently in good standing, but is detected as a non-browser if it gets compromised.

To configure a DDoS policy, click Add next to the Service in the DDoS Policy section.

Configuration of DDoS Policy

The following settings allow the Barracuda Web Application Firewall to enforce DDoS policy for a Service:

Host Match

The host name, compared to the host in the request. This can be either a specific host match or a wildcard host match with a single “*“. For example, *.example.com; any request matching this host is required to authenticate before accessing this page.

URL Match

The URL compared to the URL in the request. The URL should start with a "/" and can have at most one " * " anywhere in the URL. For example,

94 /netbanking.html; any request matching this URL is required to authenticate before accessing this page. A value of “/*” means that the access control rule (ACL) applies for all URLs in that domain.

Extended Match

Define an expression that consists of a combination of HTTP headers and/or query string parameters. This expression is compared to special attributes in the HTTP headers or query string parameters in the requests.

Extended Match Sequence

This number indicates the order in which the extended match rule must be evaluated in the requests.

Evaluate Clients

When set to On the Barracuda Web Application Firewall inserts JavaScript in the responses that are sent to the client. Note that the JavaScript mechanism will work only if at least one URL accessed within the specified URL Match space is an HTML file. If the URL space does not result in at least one request for an HTML URI, the Barracuda Web Application Firewall continues to add to the failed count and eventually issues CAPTCHA instances to all client IP addresses. In other words, the response to at least one request within the URL space should have a content type of text/html for the mechanism to work effectively and encourage clients to use regular web browsers.

Enforce CAPTCHA

Select the enforce CAPTCHA option.

Do Not Enforce – Clients are allowed to pass through with the usual security validation. Suspicious Clients Only – CAPTCHA is enforced for clients that exhibit suspicious behavior. All Clients – CAPTCHA is enforced for all clients accessing this Service.

Number of CAPTCHA Attempts

The number of attempts a client can make before failing to solve the CAPTCHA.

Unanswered CAPTCHA Limit Per IP

This limits the number of CAPTCHA instances that can be issued to a given client IP address, preventing an attacker from executing a DoS attack on the service by rendering CAPTCHA images without submitting the CAPTCHA response.

Expiry Time

The number of seconds a client IP can be idle before being challenged for CAPTCHA again.

Steps to Configure DDoS Policy for a Service

1. Go to the WEBSITES > DDoS Prevention > DDoS Policy section. 2. Identify the Service to which you want to enable DDoS policy. 3. Click Add next to that Service. The Add DDoS Policy window appears. 4. Specify values for the given parameters and click Save.

For more information, click the Help icon on the web interface. Slow Client Attack Prevention en The Slow Client Attack Prevention feature is available ONLY in Firmware Versions 7.7 and above.

Overview

In a slow client attack, an attacker deliberately sends multiple partial HTTP requests to the server to carry out an HTTP DoS attack on the server. The client attempts to slow the request or response so much that it holds connections and memory resources open on the server for a long time, but without triggering session time-outs. Common ways to carry out this attack include:

Slow HTTP Headers Vulnerability (Slowloris) – As described in Slowloris HTTP DoS (http://ha.ckers.org/slowloris/), using this technique the client never completes sending the headers. It sends headers one-by-one at regular intervals to keep sockets from closing

95 and the web servers thereby tied up. In particular, threading servers tend to be vulnerable when they try to limit the amount of allowed threading. Slowloris must wait for all of the sockets to become available before successfully consuming them, so for high traffic websites, it may take awhile for the site to free up its sockets. Slow HTTP POST Vulnerability (R-U-Dead-Yet or RUDY) – Using this technique, the client attempts to DoS the server using long form field submissions. The client sends all of the HTTP headers, one of which is a legitimate Content-Length header with a large value. The client then iteratively injects data into the form's post field at a very slow rate, so the web application keeps waiting for the full data to arrive. Once multiple threads are tied up by waiting, the server eventually runs out of resources and gets DoS'ed. More technical details about layer-7 DDoS attacks can be found in the OWASP lecture: OWASP-Universal-HTTP-DoS (http://www.hybridsec.com/papers/OWA SP-Universal-HTTP-DoS.ppt). Slow Read DoS Attack – Using this attack technique, the client request completes fully. When the server responds, the client advertises very small windows for accepting response data. For a large response (a file download, for example) the client's slow reception rate ties up server resources for a long time. Multiple requests of this type can eventually take the server down.

These requests are layer 7 DoS attacks. They are typically legitimate from a protocol compliance point of view and are therefore not detected by network layer DDoS devices, by IPS/IDS, or even by your ISP. Clients can DoS the server stealthily and slowly, without consuming any significant bandwidth on the network, so they remain otherwise undetected.

The WEBSITES > DDoS Prevention page allows you to configure slow client attack prevention for HTTP and HTTPS Services.

How does Slow Client Attack Prevention Work?

The following settings allow the identification of prevention of a slow client request or response attack:

Data Transfer Rate

The minimum data transfer rate the Barracuda Web Application Firewall expects for requests from the client and responses to the client. Data transfer rates slower than this are considered slow.

Max Request Timeout

The maximum time allowed to receive a request from a client. If a request does not complete in this time, the connection is terminated, FIN is sent to the client, and further requests are blocked.

Max Response Timeout

The maximum time allowed to send a response to the client. If the response transfer is not complete in this time, the connection is terminated, Fin is sent to the client, and further responses to the client are not sent.

Incremental Request Timeout

This value specifies the initial timeout window a client has in which to complete a request. The system then progressively shrinks the window using an adaptive algorithm. If the client repeatedly fails to complete a request in the shrinking window, the request timeout window converges to zero and the connection is dropped. If the client begins to send data at a healthy rate, the window is progressively expanded.

This adaptive algorithm ensures that temporary network delays do not affect genuine clients, but persistent slow clients are detected and denied.

Incremental Response Timeout

This value specifies the initial timeout window a client has in which to receive a response. The system then progressively shrinks the window using an adaptive algorithm. If the client repeatedly fails to receive the response in the shrinking window, the response timeout window converges to zero and the connection is dropped. If the client begins to receive data at a healthy rate, the window is progressively expanded.

This adaptive algorithm ensures that temporary network delays do not affect genuine clients, but persistent slow clients are detected and denied.

Exception Clients

The IP addresses that should be exempted from slow client attack prevention. Specify a single IP address or range of IP addresses, or a combination of both using a comma delimiter with no spaces.

Steps to Configure Slow Client Attack Prevention

To view or edit Slow Client Attack Prevention for a Service, perform the following steps:

1. From the WEBSITES > DDoS Prevention > Slow Client Attack Prevention section Edit the Service requiring the protection. 2. In the Edit Slow Client Attack Prevention page, you can view or edit the configured values.

96 3. Click Save Changes after modifying values. For more information, click Help on the web interface. How To Configure Secure Browsing For An HTTPS Service en In this article :

en Overview Components of Secure Browsing Armored Browser Credential Server Session Validator Credential Manager How Secure Browsing Works Configuring Secure Browsing Adding a Credential Server Adding a Secure Browsing Policy

Secure browsing can be enabled ONLY for HTTPS Services.

Overview

The Barracuda Web Application Firewall integrates with armored browsers to mitigate risks from malware infected clients. Key loggers and cache miners on client desktops and laptops can introduce risks such as session hijacking, credential theft and leakage of sensitive information. By using armored browsers, sensitive web applications such as Net-banking applications or trading platforms can push a layer of security onto the client side to protect applications from infected hosts.

Armored browsers reduce client-side risk by providing a temporary layer around a browser connecting to a secured website. The website administrator defines a specific security policy to protect sensitive data from theft and data leakage. When the browser is closed, the browser leaves no data remnants.

Currently, the Barracuda Web Application Firewall integrates with Quaresso Protect On Q (PoQ) armored browser, which is based on the Microsoft Internet Explorer and is available only on Windows operating systems.

Components of Secure Browsing

The secure browsing environment includes the following components:

Armored Browser Credential Server Session Validator Credential Manager

Armored Browser

The armored browser is a temporary browser created on a client machine when it attempts to access a website enforcing secure browsing. The browser is instantiated remotely by the Credential Server component.

The armored browser protects the website from client-side weaknesses by providing a temporary security layer around the browser. The Credential Server controls the browser settings. All temporary files are cleared when the browser is closed.

Credential Server

A credential server is a server side component which downloads to clients the secured browser instance, and validates incoming requests.

You can configure credential servers on the WEBSITES > Secure Browsing > Credential Servers section. For more information, see Adding a Credential Server.

Session Validator

97 The Session Validator ensures that access to the secured web applications is via a secured browser instance with a valid session ID.

The Session Validator is deployed either as a module on the server or integrated with a reverse proxy deployed in front of the web server.

The Barracuda Web Application Firewall acts as the Session Validator. The administrators need to configure a secure browsing policy and associate it with the website that needs to be secured. The WEBSITES > Secure Browsing, Add Secure Browsing Policy enables you to define custom access rule and associate with your website. For more information, see Adding a Secure Browsing Policy.

Credential Manager

The Credential Manager is used to configure the Credential Servers.

How Secure Browsing Works

An HTTPS Service is protected by configuring secure browsing using the following steps:

1. A user attempts to access a protected website using their normal browser. 2. The Barracuda Web Application Firewall intercepts the request and checks if the request contains an armored browser specific header or not. 3. If not, the user is redirected to a credential server to download the armored browser. Once the download is complete, a new browser session is launched through which the user is allowed to access the protected website. 4. If the request is from an armored browser session, then the Barracuda Web Application Firewall checks for the armored browser specific header, and validates with the credential server. 5. If the credential server acknowledges that the header is valid, the client is allowed to access the protected website. If not, the request is blocked.

Configuring Secure Browsing

To enable secure browsing for an HTTPS Service through the Barracuda Web Application Firewall, do the following:

Add a Credential Server Add a Secure Browsing Policy

Adding a Credential Server

The Barracuda Web Application Firewall uses the configured credential server to verify the armored browser is being used to access the service. A service should be associated with only one credential server.

Steps to add a credential server:

1. Go to the WEBSITES > Secure Browsing page. 2. In the Credential Servers section, click Add Credential Server. The Add Credential Server window appears, specify values for the following fields: a. Name – Enter a name for the credential server. b. Armored Browser Type – Select the armored browser type from the list. c. Server Name /IP Address – Enter the name or IP address of the Credential Server to be used for protecting web applications. d. Server Port – Enter the port number of the Credential Server. e. Policy Name – Specify the Policy Name defined on the Credential Server. f. Cache Valid Sessions – Set to Yes if you wish Barracuda Web Application Firewall to cache the session state information to validate subsequent requests from the client. g. Cache Expiry (Seconds) – Specify the duration of time (in seconds) to store the cached session state information to validate the requests after which the session information is re-validated against the Credential Server h. Redirect URL – Specify the URL where you want to redirect a user who accesses the protected web application from a normal browser. If not specified, the Barracuda Web Application Firewall redirects the user to the Credential Server. 3.

98 3. Click Add to add the credential server.

Adding a Secure Browsing Policy

To add a secure browsing policy and associate it with the HTTPS Service, do the following:

1. Go to the WEBSITES > Secure Browsing page. 2. In the Add Secure Browsing Policy section, specify values for the following fields: a. Policy Name – Enter a name for the armored browsing policy. b. Service – Select the Service from the list for which you desire secure browsing. c. Host Match – Enter a host name to be compared to the host in the request. This can be either a specific host match or a wildcard host match with a single “* “ anywhere in the host name. For example, *.example.com, any request matching this host is required to authenticate before accessing this page. d. URL Match – Enter a URL to be compared to the URL in the request. The URL should start with a "/" and can have at most one " * " anywhere in the URL. For example, /netbanking.html, indicates any request matching this URL is required to authenticate before accessing this page. A value of “/*” means that the access control rule (ACL) applies for all URLs in that domain. e. Credential Server – Select the credential server to verify the armored browser session. 3. Click Add to associate the secure browsing policy with the service.

Tuning Security Rules en Options for Refining Security

You can fine tune security to your website using the following features:

Tuning Security Rules Using Web Firewall Logs How to Configure Exception Profiling Configuring Action Policy for Attack Groups How to Configure Trusted Hosts Mitigating Website Vulnerabilities using Vulnerability Scanners How to Configure Adaptive Profiling Configuring Website Profiles

Tuning Security Rules Using Web Firewall Logs en en Introduction Creating Exceptions using the Web Firewall Logs Examples of Fixes Suggested by the Barracuda Web Application Firewall Manually Configuring a Fine Grained Rule Using Exception Profiling to Generate Recommendations for Tuning Manually Fine Tuning the Security Policy Using Exception Profiling Examples for Tuning the Security Policy Using Exception Profiling

Introduction

Barracuda Web Application Firewall enables administrators to configure security rules with varying degrees of granularity. A security policy, comprised of security settings, is shared by multiple applications.

A newly configured service originally uses the ‘default security policy’, so all URLs and Parameters are compared to the ‘default security policy’ settings. The Barracuda Web Application Firewall applies rules to traffic and generates a log of rule violations viewable in the BASIC > Web Firewall Logs page.

You can use the Web Firewall Logs to evaluate rule violations, and when warranted, create exceptions to the rule violated. Exceptions can apply globally if they modify the security policy, which affects all services using that policy. Or you can apply an exception locally that only applies to a specific website or URL. To create a fine grained exception, you use the WEBSITES > Allow/Deny OR WEBSITES > Website Profiles pages.

99 The default security policy associated with a Service might sometimes end up blocking genuine requests, which are called false positives. To reduce false positives you can enable Exception Profiling for desired websites on the WEBSITES tab. Exception profiling uses heuristics displayed on the WEBSITES > Exception Heuristics page to identify false positives. You can set the exception profiler to automatically refine security policy rules for the respective site section by setting Request Violation Handling to Auto on the Exception Heuristics page; alternatively, set Request Violation Handling to Manual if you want the profiler to generate policy recommendations under Pending Recommendation on WEBSITES > Exception Profiling. In this case, the administrator must review the violations, and manually apply desired fixes. See Using Exception Profiling to Generate Recommendations for Tuning.

Automatic settings are recommended for trusted hosts.

Creating Exceptions using the Web Firewall Logs

Once logged in to the unit, select Web Firewall Logs from the BASIC tab to search for a log entry believed to be a false positive. These log entries will be in red and have an action of DENY (active mode) or LOG (passive mode).

Scroll over to the right of the selected log and click Fix. A Policy Fix window will appear.

The fix recommended by the Barracuda Web Application Firewall may be localized or global, depending upon which rule was violated. Accepting a recommendation could have the following impact:

1. Web site profile (localized) modification: As the most fine-grained security, changes impact only a given URL or parameter. 2. Security Policy (global) modification: As a policy shared by multiple applications, changes impact all applications using the security policy.

Examples of Fixes Suggested by the Barracuda Web Application Firewall

Example 1: Recommendation to configure a fine grained rule.

Following the recommendation to create a URL Profile for /modules.php creates an exception only for that particular page.

Example 2: Recommendation to change the configuration in Security Policy.

100 The Barracuda Web Application Firewall suggested change to the ‘Parameter Protection’ sub policy of the ‘default Security Policy’ would allow the Meta character (%08) in any parameter for any application using this security policy. To avoid an exception which applies globally, you can add an exception which only applies to the URL or parameter noted in the log.

Manually Configuring a Fine Grained Rule

When you want to apply a local exception instead of a recommended global fix you need to manually do a two step process.

Step 1: Figure out the exception specifics from Web Firewall Logs.

Scroll over to the selected log in the Web Firewall Logs and click Details. Select the URL after the VIP address and before the question mark (if present). If there is a question mark present in the URL, note the parameter name. Close the Web Firewall log Details window.

Example: For the log shown above – VIP is 192.168.9.96 – Port 80. The URL is /HacmeBooks/passwordHint.html and the URL has a parameter called ‘username’.

Step 2: Configure the Exception.

From the WEBSITES > Website Profiles page select the appropriate service from the Website drop down list (192.168.9.96 : 80). In the URL Profiles section, click Add URL. The Create URL Profile window appears. Enter a name in the URL Profile Name field. Paste the URL into the URL field (/HacmeBooks/passwordHint.html). Click Add.

101 You should now see the new URL profile in the URL Profile section. Click Edit to make the necessary security exceptions to the URL. Click Sav e Changes when done.

To specify parameter settings, you will need to configure Parameter profiles for the relevant URL Profile (Example: passwordHint).

Click Add Param in the Parameter Profiles section. The Create Parameter Profile window appears. Select the appropriate URL Profile from the drop down list (Example: passwordHint). Enter a name in the Parameter Profile Name field. In the Parameter field, enter the parameter that you noted from the details of the Web Firewall Logs. Select the appropriate Parameter Class – typically ‘No Validation’ is selected if it isn’t a specific class. Click Add.

You should now see the new parameter profile in the Parameter Profile section. Click Edit to make the necessary exceptions to the Parameter. Click Save Changes when done.

The example below shows the created local exception to allow meta character %08 in parameter username for URL profile passwordhint.

102 Using Exception Profiling to Generate Recommendations for Tuning

103 To configure exception profiling for a Service:

1. From the WEBSITES > Exception Profiling page identify the Service for which you want exception profiling enabled. 2. Click Edit next to that Service. The Edit Exception Profiling window appears. 3. To learn from a trusted hosts group, select the trusted host group from the Trusted Hosts Group drop-down list and set Learn From Trusted Host Group to Yes. For more information, see Fine Tuning Security Settings for a Trusted Hosts Group using Exception Profiling. 4. To learn from untrusted traffic, select the level of tolerance to violations (Low, Medium or High) from the Exception Profiling Level drop- down list. For more information on Exception Profiling, see How to Configure Exception Profiling. 5. Click Save Changes.

The figure below shows the Exception Profiling Level set to Low for untrusted traffic.

Exception profiling provides default settings for each violation type. The settings indicate how exceptions update profiles (Automatically, Manually, or not at all), how the new setting in the profile is generated (for example, increasing the current value, or accepting the observed value) and how many times the logged error needs to be seen before generating an exception (Trigger Count). These default settings for an Exception Profiling Level can be edited and saved on the WEBSITES > Exception Heuristics page.

The figure below displays the default set of heuristics for the Exception Profiling Level: Low.

By default, all settings are set to Auto for the Exception profiling levels for untrusted traffic. The Trusted settings are either Auto or Off. For untrusted traffic, the Manual setting requires you to verify the exception before applying it, or you can turn exception profiling Off for a particular violation. If the traffic originates from trusted hosts, the trusted policy heuristics apply. If the traffic originates from non-trusted hosts, the selected Exception Profiling policy applies.

Manually Fine Tuning the Security Policy Using Exception Profiling

By default, each violation type is set to Auto on the WEBSITES > Exception Heuristics page. Hence, whenever violations from unique sources

104 are encountered the number of times indicated in Trigger Count, the profiles are automatically updated creating the respective profiles for the Service. This applies ONLY when exception profiling is enabled for the Service on WEBSITES > Exception Profiling; that is, the Exception Profiling Level for the service is not equal to None.

To view encountered violations and manually apply desired recommended fixes, do the following:

Step 1: The Setting for the desired Violation Type should be Manual.

1. From the WEBSITES > Exception Heuristics page select the Exception Profiling Level (Low, Medium or High) you want to modify. No te: Trusted does not support Manual exception creation. 2. In the Request Violation Handling section, identify the violation type(s) for which you wish to generate recommendations. 3. Change Setting to Manual next to the violation type(s). Also, change the settings in New Value and Trigger Count if required. 4. Click Save Changes.

Learned false positives are displayed on the WEBSITES > Exception Profiling > Pending Recommendation page every 600 seconds (10 minutes).

Step 2: Select the recommendation and apply fix.

1. Go to the WEBSITES > Exception Profiling page. 2. In the Pending Recommendations section, view the recommendations for relevant violation type(s). 3. Select the check box(es) next to the recommendations you want to fix, and click Apply Fix.

Examples for Tuning the Security Policy Using Exception Profiling

Example 1: Parameter Name length exceeded

In this example, the violation type Parameter Name Length exceeded is set to Manual, New Value is set to Increase 100%, and Trigger Count i s set to 3.

The Max Parameter Name Length, set on SECURITY POLICIES > URL Profiles, is 5.

105 When three unique clients (based on the value set in Trigger Count) send requests with parameter name length 10, the violation is logged under BASIC > Web Firewall Logs.

The recommendations are displayed after 600 seconds (10 minutes) on the WEBSITES > Exception Profiling page.

Click Details to see the log information. Select the check box(es) and click Apply Fix to apply the recommended fix.

Since New Value for Parameter Name length exceeded is set to Increase 100% on WEBSITES > Exception Heuristics and the parameter length in the request is 10, a new URL profile is created on the WEBSITES > Website Profiles page with the Max Parameter Name Length set to 20.

106 Example 2: Query length exceeded.

In this example, Query length exceeded is set to Manual, New Value is set to Increase 100% and Trigger Count is set to 3.

The Max Query Length, specified on the SECURITY POLICIES > Request Limits, is 5.

Recommendation generated on WEBSITES > Exception Profiling:

Clicking Apply Fix increases the Max Query length to 24 on SECURITY POLICIES > Request Limits.

107 How to Configure Exception Profiling en In this article:

en Exception Profiling Exception Profiling Levels Configuring Exception Profiling Configuring Exception Heuristics

Exception Profiling

Exception profiling fine tunes security policies associated with a Service, and reduces wrongly blocked accesses. Typically, when a Service is created, it is associated with the “default security policy”, so all URLs and Parameters are compared to the “default security policy” settings. This might cause blocking of some genuine requests. Blocked genuine requests are called false positives. Exception Profiling uses a heuristics based strategy to refine web application security settings in response to logged traffic in the Web Firewall logs, viewable on BASIC > Web Firewall Log s. Exception profiling can create URL and Parameter profiles which relax the default security policy settings or existing URL profile or Parameter profile settings thus fine-tuning them to the Service. If a profile does not exist, Exception Profiling can create a new profile, or if a profile already exists it is fine tuned to reflect the exception.

You can enable Exception Profiling for a Service by clicking Edit next to the service on the WEBSITES > Exception Profiling page and setting the Exception profiling level to one of three levels for untrusted traffic. Each level has settings for exception handling which correspond to it. The levels are:

Low Medium High

Trusted traffic is always handled according to separately configured Trusted settings.

Exception Profiling Levels

A Low Profiling Level indicates a low tolerance to violations, so logged traffic violations are reviewed frequently to properly adjust security settings. On the other hand, a High exception profiling level indicates a greater tolerance of violations, and a higher confidence in the security settings, so review or adjustment of the profile only happens if a violation is seen more frequently. Exception profiling treats traffic violations differently for trusted hosts. Trusted hosts heuristics have a "Trigger Count" permanently set to one (1) for all violations. Any request from a trusted host is assumed to be a genuine request; so an exception from any trusted host automatically refines security, creating or modifying profiles for the Service as required.

Because only three levels of Exception Profiling Heuristics for untrusted traffic apply to all services, a change in the settings of any level applies to any service using that level (Low, Medium, or High). Exception profiling provides default settings for each violation type. The settings indicate how exceptions update profiles (Automatically, Manually, or not at all), how the new setting in the profile is generated (increasing the current value, or accepting the observed value, for example) and how many times the logged error needs to be seen before generating an exception (Trigger Count). These default settings for an Exception Profiling Level can be edited and saved. For information on how to edit request violation settings, see Configuring Exception Heuristics.

Selecting an Exception Profiling Level of Low will increase the number of exceptions or recommendations for profile adjustment, causing a more

108 rapid adjustment of the profile to reflect observed traffic. On the other hand, an Exception Profiling Level of High results in fewer exceptions and pending recommendations, indicating increased confidence in the profile, and higher tolerance for traffic violations. The Trusted profiling level is recommended for trusted hosts.

Configuring Exception Profiling

You can configure exception profiling for a Service by setting the exception profiling level, thereby applying the corresponding Exception Heuristics settings to that Service. Perform the following steps to configure exception profiling:

1. From the WEBSITES > Exception Profiling page identify the Service for which you want exception profiling enabled. 2. Click Edit next to that Service. The Edit Exception Profiling window appears. 3. To learn from a trusted hosts group, select the trusted host group from the Trusted Hosts Group drop-down list and set Learn From Trusted Host Group to Yes. For information on trusted hosts, see Configuring Trusted Hosts. 4. To learn from untrusted traffic, select the level of tolerance to violations (Low, Medium or High) from the Exception Profiling Level drop- down list. For information on exception profiling levels, see Exception Profiling Levels. 5. Click Save Changes.

Configuring Exception Heuristics

The WEBSITES > Exception Heuristics page allows you to view the definitions for any exception profiling level and adjust settings for various Violation Types if required.

Exception Profiling Level Settings

Exception Profiling Level determines the exception creation heuristics for the Service to which it is bound. Four policies, or levels, are provided: Low, Medium, High (for untrusted traffic) and Trusted.

To view the settings for a profiling level:

1. Go to the WEBSITES > Exception Heuristics page. 2. Select the desired level to view the heuristics settings in the Exception Profiling Level module, and click Show Definition.

The Request Violation Handling module gets populated with the settings for that level and can be modified. The levels are shareable across multiple Services. Any change made to an exception heuristics level setting applies to any Service bound to this level. Services may have an untrusted traffic exception profiling level (Low, Medium, or High) as well as designated trusted hosts using the Trusted Hosts exception profiling settings.

The exception heuristics for various Violation Types are classified into:

Length Violations Input Violations Header Violations Cookie Violations Forceful Browsing

For each violation type, set the following parameters:

Setting – How exceptions are created: Automatically, Manually through approval of Pending Recommendations, or no exceptions should be created. New Value – How to modify the parameter after learning. New Value can be a function of the old value (increase 100% for example). Or the new value can be based on the default option provided. New Value is selected from provided options. Trigger Count – This threshold sets the number of times a violation must be received from unique sources before triggering exception learning either automatically or manually. Only unique requests from a client are counted. Multiple violations from the same client generate a single violation in the trigger count. This neutralizes a hacker conducting repeated attacks on the Service. An exception profiling agent processes the web firewall logs which generated the violations defined on the Exception Heuristics page. It maintains a cache of the trigger counts and compares the running count with the configured trigger count. When the trigger count is met, it invokes the exception profiling process.

Learned false positives are either applied automatically or displayed on the WEBSITES > Exception Profiling > Pending Recommendations section every 600 seconds (10 mins) depending on Setting (Auto or Manual).

When set to Auto, the profiles are automatically updated every 600 seconds. If set to Manual, the recommendations are generated after 600 seconds and displayed on the WEBSITES > Exception Profiling > Pending Recommendations section.

109 Configuring Action Policy for Attack Groups en Using SECURITY POLICIES > Action Policy you can configure for each security policy what action to take when a violation occurs. Discrete Action Policies can be configured for the following attack groups:

advanced-policy-violations application-profile-violations param-profile-violations protocol-violations request-policy-violations response-violations url-profile-violations header-violations

You can edit the Action taken when a particular attack is detected by locating the respective Attack Action Name in the list and clicking Edit (in the Options column) next to it.

You can configure choose from the response to a request deemed an Attack by this security policy:

Protect and Log: Blocks any request containing the specified attack and logs the attack. Protect and no Log: Blocks any request containing the specified attack without logging the attack. Allow and Log: Logs the violation. None: Ignores the violation.

For description about the attack actions under each attack group, see Attacks Description - Action Policy.

Configuring Request Denials

If you choose an action policy which protects (Denying attacks, whether Logging or not) you will need to configure the Deny Response and Followup Actions for attacks.

Set Deny Response to one of the following options:

Close Connection: Closes the connection to the sending client; Temporary Redirect: Redirects the request with the 302 status code to the URL specified in the parameter "Redirect URL". Permanent Redirect: Redirects the request with the 301 status code to the URL specified in the parameter "Redirect URL". Redirect URL: Specifies the URL where the request is redirected if the deny response is set to Temporary Redirect or Permanent Redirect. Redirect URL should be specified when the status-code in HTTP Status is one of 3xx redirect response codes.

Redirect URL should be specified in one of the following formats:

http://domain/url https://domain/url /url

Where "url" and "domain" can be any ASCII strings. URL can be empty.

Examples: http://secure.xyz.com/error.html, https://secure.xyz.com/logerror.cgi, or /error.html

Send Response: Sends the response indicated in Response Page. Response Page: Specify the response page to be sent to the client.

Configure a Follow Up Action taken when a request is denied by choosing from the following:

None: Ignores the violation. Block Client IP: Blocks the sending client for the time specified in Follow Up Action Time. Challenge with CAPTCHA: Denies the response and any subsequent requests from the same client IP address will be tracked for the next 900 seconds, and will be challenged with a CAPTCHA image. The client will not be allowed to access any further resource until the CAPTCHA is answered. This is to thwart any reconnaissance efforts from the automated clients which are found to be suspicious due to

110 such attack activity. The number of attempts for solving such a CAPTCHA challenge is five (5), and the number of re-fetches of the CAPTCHA image allowed is 128. Such tracked client IP addresses will have to answer the CAPTCHA if they are idle for more than 300 seconds. Note that the Follow Up Action Time has no relevance to this option.

Follow Up Action Time: Specifies the time in seconds to block the sending client if Follow Up Action is set to Block Client IP.

Range: 1 to 600000 Units: Seconds

Click Help on the SECURITY POLICIES > Action Policy page for more information about configuring action policy. How to Configure Trusted Hosts en In this article:

en Trusted Hosts Associate a Trusted Hosts Group with a Service Exempting a Trusted Hosts Group from Security Checks Exempting a Trusted Hosts Group from Authentication Learning from the Trusted Hosts Fine Tuning Security Settings for a Trusted Hosts Group using Adaptive Profiling Fine Tuning Security Settings for a Trusted Hosts Group using Exception Profiling

Trusted Hosts

The Barracuda Web Application Firewall allows you to designate Trusted Hosts by IP address and Mask which are not subjected to security checks. Traffic coming from trusted hosts is assumed safe. The WEBSITES > Trusted Hosts page allows you to create a trusted hosts group with one or more hosts. Trusted Host Groups have an associated Trusted Hosts Action so a policy violation from a Trusted Host results in the Tr usted Hosts Action overriding the Action configured for other hosts. You can set the Trusted Hosts Action to:

Allow - All requests pass through, including possible attacks are ignored; No logs are generated. Passive - All requests pass through, including possible attacks, but logs are generated on the BASIC > Web Firewall Logs page. Default - Trusted hosts are treated the same as all other clients.

Steps to create a trusted hosts group:

1. Go to the WEBSITES > Trusted Hosts page. 2. In the Add New Trusted Host section, specify a name in the Trusted Hosts Group Name field and click Add. 3. In the Trusted Hosts section, click Add Host next to the Trusted Host Group that you created. The Create Trusted Host window appears. Specify values for the following: a. Trusted Host Name – Enter a trusted host name to which you want to exempt the security checks. b. Version – Select the Internet Protocol version (IPv4 or IPv6) for the trusted host from the drop-down list. c. IP Address – Enter the IP address of the trusted host. d. Mask – Enter the netmask associated with the IP address. 4. Click Add. 5. If you wish to add multiple hosts to the Trusted Hosts group, repeat Step 3 and Step 4.

Associate a Trusted Hosts Group with a Service

Once a trusted hosts group is created with a set of trusted hosts, you can associate that group to a Service and exempt them from security checks or authentication as explained below.

Exempting a Trusted Hosts Group from Security Checks

The following steps bind a trusted hosts group with a Service and exempt them from security checks.

1. Go to the BASIC > Services page. 2. In the Services section identify the Service to which you want to associate the trusted hosts group for exempting security checks. 3. Click Edit next to the Service. The Service window appears. 4. Scroll down to the Basic Security section and set Trusted Hosts Action to Allow or Passive. 5. Select the Trusted Hosts Group from the drop-down list. 6. Specify values to other parameters as required and click Save Changes.

111 Exempting a Trusted Hosts Group from Authentication

If you do not wish to require authentication for a set of trusted hosts, associate the trusted hosts group with an authentication policy and set the Tr usted Hosts Action to Allow. The Barracuda Web Application Firewall identifies the trusted hosts as allowed users and all of its requests are exempted from authentication.

Steps to associate a trusted host group with an authentication policy:

1. Go to the ACCESS CONTROL > Authentication page. 2. In the Authentication Policies section, identify the Service to which you want to associate the trusted host group that you are exempting from authentication. 3. Click Edit next to that Service. The Edit Authentication Policy window appears. 4. In the Edit Authentication Policy window, select the Trusted Hosts Group from the drop-down list to associate it with the policy. 5. Set Trusted Hosts Action to Allow to exempt the set of trusted hosts from authentication. 6. Specify values to other parameters as required and click Save Changes.

Learning from the Trusted Hosts

When a Service is associated with a security policy, all URLs and Parameters are matched to that security policy setting. Web applications are dynamic and vary widely, so a one size fits all security strategy might not be adequate across a website. For this reason, it might block some genuine requests which are identified as false positives. You can reduce false positives and fine tune the security settings for a trusted hosts group using:

Adaptive Profiling, or Exception Profiling

Both assist in development of fine grained security settings. Exception Profiling uses a heuristics based strategy to refine web application security settings in response to logged traffic on BASIC > Web Firewall Logs. Adaptive Profiling learns the intricate structure of an application and enforces conformance to it. Detailed security profiles are created by Learning from requests and responses served by a particular web application. For more information on how exception profiling works, see Configuring Exception Profiling.

Fine Tuning Security Settings for a Trusted Hosts Group using Adaptive Profiling

1. Go to the WEBSITES > Adaptive Profiling page. 2. Click Edit next to the Service to which you want to associate a trusted host group and learn the requests and/or responses from the trusted hosts. The Edit Service Adaptive Profiling window appears. 3. Select Trusted from the Request Learning drop-down list if you wish to learn the requests from a trusted host. 4. Select Trusted from Response Learning drop-down list if you wish to learn the responses from a trusted host. 5. Select Trusted Hosts Group from the drop-down list. 6. Specify values to other parameters as required and click Save Changes.

Fine Tuning Security Settings for a Trusted Hosts Group using Exception Profiling

1. From the WEBSITES > Exception Profiling page identify the Service to which you want bind the trusted hosts group. 2. Click Edit next to that Service. The Edit Exception Profiling window appears. 3. Select Trusted Hosts Group from the drop-down list. 4. Set Learn From Trusted Hosts Group to Yes and click Save Changes. 5. The exceptions from trusted hosts are learned using trusted hosts heuristics displayed on the WEBSITES > Exception Heuristics page. 6. Select Exception Profiling Level from the drop-down list if you wish to learn from non-trusted hosts as well. The exceptions from non-trusted hosts are learned based on Low, Medium or High exception profiling settings on WEBSITES > Exception Heuristics.

Mitigating Website Vulnerabilities using Vulnerability Scanners en In this article:

en Overview Importing Vulnerability Report Viewing and Applying Recommendations to a Service Choosing the Recommendations

112 Steps to Mitigate Website Vulnerabilities

Overview

The Barracuda Web Application Firewall integrates with Web Application Vulnerability Scanners to make it easier to address web application vulnerabilities detected by these scanning tools. The vulnerabilities can be mitigated quickly and easily using the Barracuda Web Application Firewall, allowing an optimal engineering solution to be designed and incorporated through the regular code release cycle without incurring continued risk.

Administrators use vulnerability scanners to detect and report website vulnerabilities in a variety of report formats. Vulnerability reports can be imported using the ADVANCED > Vulnerability Reports > Import Vulnerability Report section. The Barracuda Web Application Firewall uses imported reports to provide Security Policy Recommendation(s), which, if applied by the administrator, modify applicable security policy settings or configuration to mitigate the reported vulnerabilities.

Currently, the Barracuda Web Application Firewall supports only IBM AppScan (version 7.9) and Cenzic Hailstorm (version 6.6). The assessment report exported should be in .xml format.

Importing Vulnerability Report

Perform the following steps to import a vulnerability assessment report:

1. Go to the ADVANCED > Vulnerability Reports page. 2. Specify a name for the assessment report in the Assessment Name field. 3. Select the scanner used to detect vulnerabilities in the web application from the Scanner Used list. 4. Click Browse next to Vulnerability Report to locate and select the scanned file. The report should be in .xml format. 5. Click Import Vulnerability Report.

Viewing and Applying Recommendations to a Service

Summaries of imported vulnerability assessment reports are visible, along with corresponding configuration update recommendations, using the Manage Vulnerability Assessments section. To view the summary of an assessment report and apply recommendations, perform the following steps:

1. Go to the ADVANCED > Vulnerability Reports page. 2. In the Manage Vulnerability Assessments section, select the assessment report from the Assessment Name list. The Summary Information panel provides the following details: a. Scanner Type – The name of the scanner tool used to detect vulnerabilities. b. Scanner Version – The version of the scanner tool. c. Import Date – The date and time at which the vulnerability assessment report was imported to the Barracuda Web Application Firewall. d. Vulnerabilities Detected – The number of vulnerabilities detected in the website. 3. The Recommendation Summary panel enables you to select a Service, and apply the recommendations selected in the Security Policy Recommendation(s)section. It also displays the number of recommendations: a. Total Recommendations – Number of recommendations generated by the Barracuda Web Application Firewall for vulnerabilities detected. b. Pending Recommendations – Number of recommendations pending, not yet applied to the Service. c. Applied Recommendations – Number of recommendations applied to the Service to mitigate threats. d. Rejected Recommendations – Number of recommendations viewed and rejected by the administrator. 4. Recommendations for vulnerabilities detected get populated in the Security Policy Recommendation(s) section. 5. Select the Service from the Apply To Service list in the Recommendation Summary panel. 6. In the Security Policy Recommendation(s) section, select single or multiple check box(es) to apply the recommended fixes for website vulnerabilities identified by the scanner. The administrator must review the recommendation before applying fixes. For information on how to choose recommendations before applying, see Choosing the Recommendations. 7. Click Apply to apply the recommended fixes.

Choosing the Recommendations

The Security Policy Recommendation(s) section displays the recommendations for the selected assessment report. Before applying the recommended fixes the administrator must review the recommendations and choose one or more entries by selecting the check box(es).

Steps to view recommendations:

113 1. From the ADVANCED > Vulnerability Reports page, select an assessment report in the Manage Vulnerability Assessments section from the Assessment Name list. 2. Recommendations for the selected assessment report get populated in the Security Policy Recommendation(s) section. 3. Select an entry in the Recommendation List to view detailed information about the vulnerability detected, and security policy recommended by the Barracuda Web Application Firewall in the Preview Pane. By default, Preview Pane is turned Off. Use the Setting s option on the tool bar to turn on the Preview Pane at Right, Bottom or Left. The following information is displayed in the Preview Pane: a. Attack – Name of the attack detected in the web application. b. Attack Group – Name of the attack group of this attack. Example: constTransient is an Attack in the Session Identifier Not Updated Attack Group. c. Severity – Vulnerabilities are categorized as HIGH, MEDIUM, or LOW severity. i. HIGH – Indicates a critical security threat that can potentially affect the web application. This should be fixed immediately. ii. MEDIUM – Indicates that these vulnerabilities are not harmful by themselves but combined with other vulnerabilities may cause a potential threat to the web application. The administrator needs to review the recommendation before applying the fix. iii. LOW – Vulnerabilities that have little impact on the web application, so the fix has a lower priority. d. URL – The URL in the web application where vulnerability was detected. e. Parameter – The parameter(s) in which vulnerability was detected. f. Status – The recommendation status, New if not yet applied by administrator or Applied. g. Attack Information – Click to see detailed information about the attack detected in the web application. h. Recommendations – Click to see the security policy recommended by the scanner and Barracuda Web Application Firewall to mitigate the identified vulnerability. 4. Select the Service from the Apply To Service list using the Manage Vulnerability Assessments section. 5. Select one or more check box(es) next to the recommendations and use one of the action controls on the tool bar: a. Apply – Applies the recommended fixes for selected vulnerabilities. b. Reject – Rejects the recommendations for selected vulnerabilities. If you want to apply rejected recommendations, you need to Un-Reject first and then Apply. c. Un-Reject – Un-rejects the rejected recommendations.

Once the recommendations are applied to a service, they cannot be re-applied or rejected.

Steps to Mitigate Website Vulnerabilities

1. Scan web application(s) using third party vulnerability scanning software. 2. Choose *.xml (the only supported format) for the exported vulnerability output file format. 3. Navigate to the ADVANCED > Vulnerability Reports > Import Vulnerability section, and import the scanned file. For information on how to import, see Importing Vulnerability Report. 4. Select the assessment report from the Assessment Name list in the Manage Vulnerability Assessments section. 5. Select the Service from the Apply To Service list in the Recommendation Summary panel. 6. In the Security Policy Recommendation(s) section, select the check box(es) to apply the recommended fixes. 7. Click Apply to mitigate corresponding vulnerabilities.

How to Configure Adaptive Profiling en

Overview

Adaptive Profiling and Exception Profiling are the two significant modules incorporated to fine tune the security settings of a Service. Exception profiling works with generated log files to refine security settings, customizing them to the web application. For more information on exception profiling, see How to Configure Exception Profiling. Adaptive profiling analyzes the request and response traffic to generate customized security profiles for the web application.

Adaptive Profiling learns the intricate structure of an application and enforces conformance to that structure. Detailed security profiles are created by Learning from requests and responses served by a particular web application. Learning creates a positive security model by generating valid URL and Parameter profiles.

The learned structure of the application is called a profile of the website. A Web Site Profile consists of individual URL and Parameter Profiles. These profiles are initially generated using the settings in the default security policy, but over time the profiler refines them to accurately reflect the

114 safe incoming traffic for the web application.

How Adaptive Profiling Differs from Exception Profiling

In Exception Profiling, URL and Parameter profiles are created for a Service in Active Mode on the WEBSITES > Website Profiles page. This means any created profiles would immediately be in Active Mode. So profiles in this case are created/updated periodically, every 600 seconds (10 minutes), and then only when violations from unique sources are encountered the number of times indicated in Trigger Count on the WEBSI TES > Exception Heuristics page. To learn more about how profiles are created in Exception Profiling, see Configuring Exception Profiling. In Adaptive Profiling, the entire Service is in Learning Mode, so any URL and Parameter profiles created for the Service are in Learning Mode. In learning mode, violations are logged on the BASIC > Web Firewall Logs page. Any changes in the request or response are learned and respective URL and/or Parameter profiles are created/updated instantly.

Enabling Adaptive Profiling for a Service

By default, adaptive profiling is disabled.

Steps to enable adaptive profiling for a Service:

1. Go to the WEBSITES > Website Profiles page. 2. Select the Service you want to "learn" from the Website drop-down list. 3. Click Start Learning. 4. Navigate to the WEBSITES > Adaptive Profiling page and verify the Status is set to On for the relevant Service.

Editing Adaptive Profiling Settings

By default, each Service is configured for adaptive profiling with predefined settings. The predefined settings include Request Learning and Res ponse Learning set to Successful and learning Status set to Off. To modify the predefined settings for adaptive profiling, do the following:

1. From the WEBSITES > Adaptive Profiling page identify the Service to requiring modification of adaptive profiling settings. 2. Click Edit next to that Service. The Edit Service Adaptive Profiling window appears. 3. Specify values for the required fields and modify the learning settings if required: a. Status – By default, this is set to Off. To enable adaptive profiling for the Service, see Enabling Adaptive Profiling for a Service. b. Request Learning – Specify when to learn the requests: i. Successful – Learn from requests which result in a successful response (Usually 200 OK). ii. Trusted – Learn only if the requests are from trusted client IP address(es). iii. None – No requests are learned. c. Response Learning– Specify when to learn the responses: i. Successful – Learn elements only from successful responses (Usually 200 OK). ii. Trusted – Learn the responses only if the request sent was from trusted client IP address(es). iii. None – No elements in the response are learned. d. Navigation Parameters – Enter the constant query parameters that are shared among multiple URLs. For example, consider the Barracuda Web Application Firewall user interface URL: http://waf.barracuda.com/cgi-bin/index.cgi?primary_tab=basic &secondary_tab=status . Here, the values of primary tab and secondary tab together determine which page displays. Different value combinations of parameters display completely different pages. For more information on navigation parameters, see Worki ng with Navigation Parameters . e. Ignore Parameters – Enter the list of parameters that should be ignored while learning the corresponding URL profile. A "*" is allowed as a prefix or suffix. For example, an Ignore Parameter "ctl*" would result in ctl1, ctl2, ctl3, etc. being ignored during learning, so no parameter profiles for parameters ctl1, ctl2 and ctl3 would be created/updated. f. Trusted Hosts Group – Select the trusted hosts group to which Request Learning and/or Response Learning are restricted. To learn more about trusted hosts, see Configuring Trusted Hosts. g. Content Types – Enter the type of content to be learned from the responses. 4. Click Save Changes to save your adaptive profiling settings.

Adding an Adaptive Profiling Rule

The WEBSITES > Adaptive Profiling page enables you to add adaptive profiling rules for a URL space that needs to be learned. One or more rules can be created for a URL space and host match.

To add an adaptive profiling rule

1. From the WEBSITES > Adaptive Profiling page identify the Service to which you want to add a rule. 2. Click Add next to that Service. The Add Adaptive Profiling Rule window appears. Specify values for the following fields: a. Learn Rule Name – Enter a name to identify the adaptive profiling rule.

115 2.

b. Status – Set to On to enable learning for this rule. c. URL Match – Enter a URL to be matched against the URL in the request. The URL should start with a "/" and can have at most one " * " anywhere in the URL. Examples: /Bank/Forms/*, /images/*. d. Host Match – Enter the host to be matched against the host in the request. The host match can either be a domain name or IP address. A value of '*' means it matches any domain. Examples: www.mysite.com, 192.168.128.2 e. Learn From Request – Set to Yes to learn the client requests and create/update URL and parameter profiles if the URL and/or domain space defined above matches. The URL and Parameter profiles are created/updated for the corresponding service on the WEBSITES > Website Profiles page. Learning from requests includes: i. URL profile for the requested URL. ii. Parameter profiles for the query parameters (if any). iii. Parameter profile for the FORM parameters (if any). f. Learn From Response – Set to Yes to learn the server responses and create/update URL and parameter profiles if the URL and/or domain space defined above matches. The URL and Parameter profiles are created/updated for the corresponding service on the WEBSITES > Website Profiles page. Learning from responses includes: i. URL profiles for the links embedded in the response and corresponding query parameter profiles (if any) provided they match the URL and Host matching expressions for any one of the Adaptive Profiling rules. ii. URL profile for the URL which is found as an action URL or a URL with a query string in the response. iii. Parameter profiles for the FORM parameters of those forms whose action URL matches the above expressions body. 3. Click Add to add the rule you just configured.

How Adaptive Profiling Rules are Matched

A Service can be configured with one or more rules with different URL spaces. When learning is enabled, the Barracuda Web Application Firewall uses a Best Match Algorithm to match the most specific request URL rule. If no rules are configured for a Service, learning is enforced on all URLs based on the default adaptive profiling settings of that Service. To see the default adaptive profiling settings, click Edit next to the Service. See Editing Adaptive Profiling Settings.

Rules must be created before enabling Learning for a Service.

For example, consider the following two rules configured for a Service (Service_1):

Learn Rule Name – Rule 1

Status – On URL Match – /Bank/Forms/* Host Match – www.a_bank.com Learn From Request – No Learn From Response – Yes

Learn Rule Name – Rule 2

Status – On URL Match – /* Host Match – www.a_bank.com Learn From Request – Yes Learn From Response – Yes

For a request for www.a_bank.com /Bank/Forms/loan.html, Rule 1 is considered as the best match.

Working with Navigation parameters

To distinguish between two requests with the same URL but different query parameters, specify those parameters as Navigation Parameters. By doing so, a page is uniquely defined using the combination of the request URL and the navigation parameter settings. To define navigation parameters for a Service, edit the adaptive profiling settings. See Editing Adaptive Profiling Settings.

For example, consider the following Barracuda web user interface URL: http://waf.barracuda.com/cgi-bin/index.cgi?primary_tab=basic&secondary_tab=status

Here, the values of query parameters primary_tab and secondary_tab together determine which page displays. Different value combinations of navigation parameters display completely different pages, containing different FORM elements and content.

To protect this application, primary_tab and secondary_tab would be defined as Navigation Parameters forcing the profiler to generate separate

116 profiles for each possibility. For example, the above case would produce the following profiles:

/cgi-bin/index.cgi?primary_tab=basic&secondary_tab=ip_config

/cgi-bin/index.cgi?primary_tab=basic&secondary_tab=services

/cgi-bin/index.cgi?primary_tab=advanced&secondary_tab=troubleshooting

By default parameters are considered non-navigation parameters.

Configuring Website Profiles en In this article:

en Overview Steps to Enable Learning Modifying the default settings of a Service URL Profiles Steps to Manually Create a URL Profile Parameter Profiles Steps to Add a Parameter Profile Understanding Request and Response Learning Response Learning Request Learning Viewing Newly Generated Profiles Enforcing Learned Profiles Using Use Profile and Strict Profile Checks Recommended Way to Use the Learning Feature

Overview

The learned structure of an application is called a profile of the website. Website profiles are made up of profiles for URLs and profiles for parameters of those URLs. A URL profile lists allowed fields like HTTP methods, names and types of each parameter, query strings, length based restrictions, etc. A Parameter profile defines the allowed format for each parameter using either a negative or positive security model and includes length restrictions. Website profiles can be defined manually, or can be automatically generated using Adaptive Profiling or Exception Profiling.

Website Profiles allow you to create specific rules to fine tune the security settings of a Service. They do not modify the default security policy settings, but fine tune security settings specific to a Service. For a Service, a Website Profile is applied if Use Profile is set to Yes, meaning the request must be validated against configured URL and Parameter profiles of that Service. Initially no URL and Parameter Profiles exist for a Service. To use Website Profiles, the administrator must manually create them for the Service, or create them automatically by enabling learning.

Steps to Enable Learning

1. Go to the WEBSITES > Website Profiles page. 2. In the Service section, select the Service you want to learn from the Website list. 3. Click Start Learning.

The "Learning" feature is available only in the Barracuda Web Application Firewall 660 and above.

When learning is enabled for a Service, the default settings for the Service to validate requests/responses include:

Use Profile – Yes Strict Profile – Yes Mode – Learning Adaptive Profiling is enabled automatically for the Service by setting Status to On in the WEBSITES > Adaptive Profiling page. For more information on adaptive profiling, see Configuring Adaptive Profiling.

Modifying the default settings of a Service

117 To modify the default settings of a Service, perform the following steps:

1. From the WEBSITES > Website Profiles page select the Service whose settings you want to modify from the Website list. 2. Click the Edit button. The Edit Website Profile window appears. Specify values for the following fields if required: a. Mode – Set to Learning when the application is in learning mode. Change the mode if required. i. Learning – Learns the requests and responses for the selected Service. ii. Passive – Validates the requests against the URL Profiles and Parameter Profiles settings and logs request errors/violations on the BASIC > Web Firewall Logs page. iii. Active – Validates the requests against the URL Profiles and Parameter Profiles settings, blocks request violations and logs the corresponding violations on the BASIC > Web Firewall Logs page. b. Allowed Domains – Enter the domain or IP address of the Service whose requests/responses should be validated against the URL and Parameter Profiles. If you wish to allow multiple sub domains under a main domain, then Allowed Domain should be set as *maindomain. For example, "world.com" might have pages at "india.world.com," "america.world.com," and "japan.world.c om." By default, if a web page on "india.world.com" is configured under Allowed Domains, only pages on "india.world.com" are allowed. If the user wants all subdomains in the "world.com" domain to be allowed, then specify "*world.com". c. Exclude URL Patterns – Enter the list of URL patterns to be excluded from the URL Profile validations. These URLs are exempted from learning even if the Learning is On. Examples: *.html,*.htm,*.jpg, *.gif,*.css,*.js d. Include URL Patterns – Enter the list of URL patterns to be included in the URL profile validations even when listed in Exclude URL Patterns. 3. Click Save Changes to save the settings.

URL Profiles

URL profiles can be created manually by the administrator, or automatically generated by enabling Learning for a Service. URL Profiles are validated against the requests for the Service based on the Mode setting of the URL profile. To enable learning, see Steps to Enable Learning.

Steps to Manually Create a URL Profile

To manually create a URL profile, follow the steps below:

1. Go to the WEBSITES > Website Profiles page. 2. Select the desired Service from the Website drop-down list. 3. In the URL Profiles section, click Add URL. The Create URL Profile window appears. Specify values for the following fields: a. URL Profile Name – Enter a name for the URL profile. b. Status – Set to On if you want to enforce checks on requests/responses for the Service using this profile. c. URL – Enter a URL to be compared to the URL in the request. The URL should start with a "/" and can have at most one " * " anywhere in the URL. The value of “/*” means all URLs in the Service are matched against the URL in the request. d. Extended Match – Specify an expression, a combination of HTTP headers and/or query string parameters, you want used to match the special attributes in the HTTP headers or query string parameters in the requests. Use '*' to denote "any request", that is, do not apply the Extended Match condition. For information on how to write extended match expression, see Extended Match Syntax Help. To build an expression, click Edit and specify values for the following fields:

i. Header Expression – Expression gets populated when the values for other fields are specified and inserted. ii. Element Type – Select the element type to compare in the request. iii. Operation – Select the operator for comparison of the element type in the request. iv. Value – Enter the value of the Element to be compared. Some Element Types have predefined values eg, Method, HTTP-Version, etc. In case the value is not listed in the predefined list, select the Others check box and specify the value.

118 3.

v. Concatenate – Use this if you wish to join another expression. and matches if both the expressions are true; or matche s if either expression is true. vi. Click Insert and then Apply to apply the expression. Click Cancel if you wish to cancel the expression. e. Extended Match Sequence – Enter a number to indicate the order in which the extended match rule will be evaluated in for requests. f. Mode – Set the mode for this URL profile. i. Learning – Starts learning the URL profile and corresponding Parameter profile(s) if the Service is in Learning mode. ii. Passive – Validates the requests comparing them to the URL profile and corresponding Parameter profile(s) settings and logging request errors/violations on the BASIC > Web Firewall Logs page. iii. Active – Validates the requests comparing them to the URL profile and corresponding Parameter profile(s) settings, blocking request violations and logging the corresponding violation on the BASIC > Web Firewall Logs page. g. Allow Query String – Set to Yes to allow parameters and its values along with the URL. h. Hidden Parameter Protection – Specify whether or not to protect hidden parameters in the forms and URLs. i. Forms – Protects the hidden parameters in the post body of forms. ii. Forms and URLs – Protects the hidden parameters in the post body of forms and query string of the URLs. iii. None – No protection to hidden parameters in forms and URLs. i. CSRF Prevention – Specify whether or not to prevent cross-site request forgery attack on the forms and URLs. j. Max Content Length – Enter the maximum content length to be allowed for POST request body. k. Max Parameter Name Length – Enter the maximum length of the parameter name. The allowed length is 1 to 1024 bytes. No value (empty) implies unlimited. l. Max Upload Files – Enter the maximum number of files that can be uploaded in one request. If the value is set to two (2), then the third (3) file upload is denied. The Passive mode logs every uploaded file that exceeds the max count. m. Blocked Attack Types – Select the attack types that needs to be matched in the requests/responses. Attack Types are specifications of malicious patterns. If the value of a parameter matches one of the specified Attack Types, an intrusion is detected and logged on the BASIC > Web Firewall Logs page. Attack Types are defined with groups of Regular expression patterns. Attack Types for SQL Injection, Cross Site scripting and System Command Injection attacks are provided by default, and one or more of these can be enabled for matching against request parameters. n. Custom Blocked Attack Types – Select the custom attack types that needs to be matched in the requests/responses. 4. Click Add. 5. Click Edit next to the created URL profile to specify values for the following fields: a. Allowed Methods – Enter the methods to be allowed in the request. The Barracuda Web Application Firewall uses this to decide whether to allow or disallow the methods. b. Allowed Content Types – Enter the content types to be allowed for this URL profile. c. Referrers for the URL Profile – Enter the address (URI) of the resource from which the Request URI was obtained. In case of adaptive profiling, the referrers are learned as the profile sources. This referrer is not same as the “Referrer” in CSRF protection. Note: This is used only for information purpose, and no security checks are enforced by the Barracuda Web Application Firewall. d. Exception Patterns – Enter the patterns to be allowed as exceptions even if part of a malicious pattern group. The configuration should be the exact "Pattern Name" as found on the ADVANCED > View Internal Patterns page, or as defined during the creation of a "New Group" through the ADVANCED > Libraries page. The pattern name can also be found in a Web firewall log when a false positive occurs due to a potential exception pattern. For example, if the parameter value matched "sql-comments" regex pattern under "sql-injection medium" attacks on the ADVANCED > View Internal Patterns page, then adding "sql-comments" to this list will allow "sql-comments" in future. 6. Click Save Changes to save the above settings.

If the Mode is set to Active for a Service and Passive for a URL profile, then the URL profile settings override the Service settings (i.e., the Barracuda Web Application Firewall validates the requests using the URL profile and corresponding Parameter profile(s) and logs request errors/violations on the BASIC > Web Firewall Logs page).

Parameter Profiles

Parameter profiles can also be created manually or automatically. Parameter profiles are compared to the requests for the Service based on the Mode setting of the corresponding URL profile.

Steps to Add a Parameter Profile

Perform the following steps to create a parameter profile:

1. Go to WEBSITES > Website Profiles page. 2. Select the desired Service from the Website drop-down list.

119 3. In the URL Profiles section, select the desired URL profile where you want to add the Parameter profile. 4. In the Parameter Profiles section, click Add Param. The Create Parameter Profile window appears. Specify values for the following fields: a. Parameter Profile Name – Enter a name for the parameter. b. Status – Set to On to validate the requests coming to the Service using this Parameter Profile. c. Parameter – Enter the name of the parameter to be validated in requests/responses. The parameter names with the special characters like &pathinfo and &sessionid and wildcard (*) should be manually specified, they are not learned automatically. d. Type – Select the type of parameter to be validated in requests/responses. Note: If two or more parameters of different type have the same name, then parameters would be considered as Input type and be bound to one of standard parameter classes and the value of the parameter Max Instances would be updated. The types of parameters i. Input – The parameter other than File Upload, Global Choice, Read Only, Session Choice, and Session Invariant type is treated as Input type. ii. Read Only – All hidden parameters in the form and query parameters in the URL is learned as Read Only type. If an exception occurs while learning, then the type is updated to Input. This type makes the parameter session specific. iii. Session Choice – The parameter from a response form and the drop-down list is different across different sessions or same session, then it is treated as Session Choice. iv. Global Choice – The input type parameters like check boxes, radio buttons and menu parameters in a form is treated as Global Choice type. v. Session Invariant – Select this if the parameter value is same across multiple requests from the same session, then it can be set as Session Invariant, for example; session-id. This type of parameter is not learned automatically. vi. File Upload – The parameter of the type file upload in forms is treated as File Upload type. e. Values – Define a fixed set of strings to match against the parameter's value, if the parameter Type is to Global Choice. f. Parameter Class – Select a parameter class to be compared to the parameters sent in the requests/responses. g. Custom Parameter Class – Select the custom parameter class to be compared to the parameters sent in the requests/responses. This is applicable only when Parameter Class is set to CUSTOM. h. Max Value Length– Set the maximum allowable length for the value of the parameter. Example: The parameter "param" set to 0, which means:

p1=v1¶m=&p2=v2 : allowed

p1=v1¶m=v&p2=v2 : not allowed i. Required – Set to Yes if the parameter must always be present in the request. j. Ignore – Set to Yes if the parameter must be ignored completely, that is, never validate the value of the parameter at all. k. Maximum Instances – Specify the maximum number of times the parameter should be allowed in the request/response. l. Base64 Decode Parameter Value - Set to Yes to apply base64 decoding to the parameter values. If the parameter value adheres to the Data URI Scheme, the base64 decoding is applied on the parameter value irrespective of Base64 Decode Parameter Value is set to Yes or No. If not, the base64 decoding is applied to the parameter value only when Base64 Decode Parameter Value is set to Yes. Once the decoding is successful, other parameter checks are enforced as per the policy settings.

The parameter value length check is always applied on the encoded/original value.

m. Allowed File Upload Type – Select Extensions to allow the files uploaded with extensions specified in File Upload Extensions. Select Mime Types to identify the content in the files before allowing to be uploaded with the mime types specified in File Upload Mime Types. n. File Upload Extensions – Define the extensions to be allowed in file upload. ‘.' is a special extension which indicates no extension, and * is a wildcard which indicates any extension is allowed. o. File Upload Mime Types – Define the Mime types that are to be allowed as uploaded files. Use a "." to indicate a file with unknown mime type, and use a * to indicate any kind of mime type. 5. Click Add to save the above settings.

Understanding Request and Response Learning

The table below provides the list of elements that are learned through request and response learning:

Profiler Type Elements Learned During the Learning Phase

URL Profile Allowed Query string, Allowed Methods, Allowed Content Types, Max Content Length, Max Parameters, Max Upload Files, Max Parameter Name Length, Referrers.

120 Parameter Profile Type, Allowed Meta-characters, Max Parameter Value Length, Required, Ignore, Max Instances, File Upload Extensions, Max Upload File Size.

The initial values of these elements are taken from the applicable security policies displayed under Policy Overview on the SECURITY POLICIES > Policy Manager page.

For example, when a new URL profile is generated the parameter Max Content Length is set to 32k if the service uses default security policy. If the profiler receives a successful request with content length 35k, the new value of Max Content Length is set to 35k for the request URL.

Other security policy elements for the Service specified for the website (e.g. Advanced Security elements, Allow/Deny rules, etc.) and those inherited from the associated Security Policy (e.g. Cookie Security, Normalization, etc.) continue to apply during the learning phase. This maintains protection from application attacks even during the profile development phase. Whether attacks are blocked or just logged during this phase depends on the Service’s Mode setting.

The following URL and Parameter profile configuration elements are not learned. They continue to be applied even during the learning phase:

Profile Type Elements Not Learned During the Learning Phase

URL Profile Blocked Attack Types, Custom Blocked Attack Types

Parameter Profile Blocked Attack Types, Custom Blocked Attack Types

The following table describes different Types for a parameter profile. Read Only, File Upload, Global Choice, and Input parameter types are automatically learned by the profiler. Session Choice and Session Invariant need to be manually specified.

Parameter Type FORM Attribute Used for Description Allowed Values

Read Only type=hidden All hidden FORM parameters are When profile mode is Active: learned as Read Only. Known by Allowed value for the parameter the attribute in in a request is exactly equal to the HTML response content, the that learned from the response. value of the parameter is learned on a per session basis. When profile mode is Learning: If the value varies in requests during the learning stage, the type updates to Input.

File Upload type=file The parameter of type file upload in FORM is treated as File Upload type.

Global Choice type=checkbox|radio|submit The input type parameters like The system constructs an check boxes, radio buttons and aggregated list of values learned menu parameters in a FORM are by observing the values in treated as Global Choice type. responses across sessions.

Session Choice NA Has to be specified manually. The system constructs an Similar to Global Choice, but allowed list of values learned by values are learned on a per observing the values on a per session basis. session basis.

Session Invariant NA Has to be specified manually. If The unique value learned for a the parameter value should be parameter per session. constant across multiple requests from the same session, then it can be set as Session Invariant type, for example: session-id.

121 Input Any parameter not of the above All values allowed by the regex types is treated as Input type. for Comments Data Type element on ADVANCED > View Internal Patterns.

Response Learning

If Response Learning is On for a URL space, the system inspects HTTP responses in that space and learns the following from it:

FORM parameters – Parameter profiles are created based on their FORM attribute type as described in the table above. The system will also learn the maximum length for the parameter if specified (using the “maxlen” attribute in the HTML). Note that these parameter profiles are created for the action URL specified in the FORM, and not for the request URL which generated this response.

Embedded URLs – The profiler parses all the hyperlinks in the response body and generates URL Profiles for them. Note that this is only done for those hyperlinks which match one of the URL profile learn rules specified on WEBSITES > Adaptive Profiling. To add an adaptive profiling rule, refer Adding an Adaptive Profiling Rule.

Embedded URL query parameters – For the embedded URLs found above in the response content, the profiler also generates parameter profiles for the query parameters, if any. By default, these parameters are learned as Read Only parameters. If they differ in a subsequent request while the URL space is still being learned, their type changes to Input.

Request Learning

When the profiler sees an incoming GET request, it generates profiles for the URL and its query parameters (assuming they do not match any of the navigation parameters for the relevant URL space).

For a POST request, the profiler may have already learned the FORM and query parameters from a prior response. For example, client side scripting may introduce additional parameters in the POST request for url1 which were not present in the url2 response. These are learned as Input type parameters. If the client side scripting modifies a parameter learned as Read Only from an earlier response, the profiler will update the parameter type to Input when Request Learning is On for this URL and the profile is learning. When Request Learning is Off, and the profile is learning, the request is allowed, but the parameter type is not changed. When the profile is Active (learning is turned Off), the request is blocked.

Example:

The following example shows a request response scenario with the corresponding profiles generated by the profiler at each step.

1. Initial request for a.cgi containing two query parameters

Request: a.cgi?q1=abc&q2=def

URL Profile Parameter Profile

a.cgi Query Params {q1, q2}

2. Response for a.cgi containing an embedded FORM with action URL= b.cgi

Request: a.cgi?q1=abc&q2=defsdfsdf

When the user fills in values for the fields and clicks submit, the values are sent to the URL defined in the action field. In this example, the URL is b.cgi?q3=userinfo

URL Profile Parameter Profile

a.cgi Query Params: {q1, q2}

122 b.cgi Form Params: {firstname, lastname, married}

Query Params: {q3}

3. User submits the FORM; Client-side injects additional parameters

Request: b.cgi?q3=userinfo

Client side javascript: If Married, inject FORM param: spousename

URL Profile Parameter Profile

a.cgi Query Params: {q1, q2}

b.cgi Form Params: {firstname, lastname, married, spousename}

Query Params: {q3}

Viewing Newly Generated Profiles

The newly generated profiles from the Adaptive Profiler module are displayed in red color on the WEBSITES > Website Profiles page. To view, select the Website and Directory. The URL/Parameter profiles are displayed in red as shown in the figure below.

One measure of the maturity of a security profile is the number of hits, or matching requests, which it has encountered. If Hits is small, the profile will reflect only that small number of requests or responses it has encountered and not reflect the spectrum of potential requests and responses.

Filter the list of profiles by selecting Profiles not reviewed or URLs with Params not reviewed. Keep track of viewed profiles with the Mark Read option from More Actions. The profile will be listed in black font next time it is viewed. This way the administrator can track which learned profiles still need review.

Enforcing Learned Profiles

Once satisfied with generated profiles, select them, and Lock Profiles using More Actions to begin their enforcement. The system now considers violations to these profiles as attacks, no longer learning from them. The Mode setting for these URLs determines how attacks are handled.

To assist in this transition, the system displays as Hits on WEBSITES > Website Profiles the number of successful requests matching generated URL profiles after the last update. The number of hits to a profile is a good indicator of the profile maturity. The higher the number of hits, the more mature the profile is.

When the Website Profile Mode is Learning and the URL Profiles are Locked, the Barracuda Web Application Firewall stops learning the selected URL Profiles. The Website Profile Mode switches to Active and URL Profile Status is On. Changing the Status of the URL Profiles to Off results in the Barracuda Web Application Firewall completely ignoring them. In this case, if a new request matching the turned Off URL Profiles comes in, it would need to be learned again.

Using Use Profile and Strict Profile Checks

When configuring a website profile, set Use Profile to Yes to validate the incoming requests to that service against the URL Profiles and Parame ter Profiles. To enforce strict profile validation, set Strict Profile Check to Yes. Strict Profile Check cannot be modified when Adaptive Profiling is On.The following table describes how a website profile functions with Use Profile and Strict Profile Check:.

Use Profile Strict Profile Check Behavior

123 Yes Yes Uses URL Profiles and Parameter Profiles for validating the incoming requests to that service. Performs strict profile check and denies the requests that do not match the URL Profiles and Parameter Profiles.

Yes No Uses URL Profiles and Parameter Profiles for validating the incoming requests to that service. If the requests do not match the URL Profiles and Parameter Profiles, then the requests are validated against the global security policy (URL Protection and Parameter Protection).

No Yes, No The incoming requests to that service are validated against the global security policy (URL Protection and Parameter Protection).

Using the Use Profile and Strict Profile Check you can enforce the positive or negative security model. For the administrators who would want to enforce a "deny unless allow" strict rules, set Use Profile to Yes and Strict Profile Check to Yes. This setting ensures the requests with no matching profiles are dropped and thus enforcing a positive security model.

For the administrators who prefer a negative security model, set Use Profile to Yes and Strict Profile Check to No. This setting ensures the requests that do not match any profile use service's global security policy. If any exceptions, they can be handled by adding relevant profiles.

The global security policy is the Web Firewall Policy associated with the service on the BASIC > Services page.

Recommended Way to Use the Learning Feature

From the WEBSITES > Website Profiles page, select the Website and then click Start Learning. Either manually browse through the application (recommended) or crawl the application. Let Adaptive Profiling populate the URL and Parameter profiles automatically. View the created profiles to review them. If satisfactory, click Stop Learning to stop the profiling for the Service. Select a subset of the profiles and enforce them by selecting Lock Profiles when desired. The profile mode is initially in Passive mode. Look for any false positives using BASIC > Web Firewall Logs. Examine the Hits statistic on WEBSITES > Website Profiles, under URL Profiles. If satisfactory, select Lock all Profiles from the More Actions drop-down list to turn all profiles to Active. Enabling Exception Profiling would fill in missing URL spaces not sufficiently profiled during Adaptive Profiling. If possible, manually combine the learned profiles to optimize the configuration. If the back-end application, or a portion of it has changed, revise the profiles accordingly using Resume Learning from More Actions for the URL. Access Control en Authentication Options

Configure Access Control and Authentication for the Barracuda Web Application Firewall using the following instructions:

How to Configure Authentication and Access Control (AAA) Kerberos Authentication How to Set Up a Custom Login Page for Authentication How to Configure Single Sign-On (SSO) How to Configure SiteMinder Single Sign-On (SSO) How to Integrate RSA SecurID with the Barracuda Web Application Firewall How to Integrate CA SiteMinder with the Barracuda Web Application Firewall How to Use Client Certificates Allowing or Denying Client Certificates

124 Client Certificate Validation Using OCSP and CRLs How to Pass Client Certificate Details to a Back-end Server RSA SecurID Implementation How to Configure SMS Passcode Authentication Service How to Set Up a Custom Challenge Page for Authentication

How to Configure Authentication and Access Control (AAA) en Overview

The Barracuda Web Application Firewall provides features to implement user authentication and access control. You can create a virtual private network (VPN) tunnel to control user access to websites. The user-access features allow you to specify who can access your websites and what access privileges each user has. By combining these with SSL encryption, you can create a secure VPN tunnel to your websites.

Authentication can be implemented only for HTTP or HTTPS services. The authentication process requires users to provide a valid name and password to gain access. A validated user has qualified access to the website; that is, the data and services this user can access depend on his authorization privileges. The following figure illustrates the authentication process:

The user accesses a login page (a GET request), a form for entering a username and password. The login form must be accessible to all users, but need not reside on a back-end server. The Barracuda Web Application Firewall includes a default login form which can be used instead of creating your own login page. The user submits the form (a POST request) and the Barracuda Web Application Firewall compares the submitted information against an internally or externally located authentication database. If successfully authenticated, the requester receives a cookie and is redirected to a success page. On subsequent requests, after verifying proper authorization (the authenticated user has the needed access privileges for the request) , the Barracuda Web Application Firewall forwards the request to the desired location.

If a user fails authentication, the user is redirected to a failed authorization page (not illustrated in the figure). When an authenticated user attempts to access an unauthorized page, for which he does not have permission, he is redirected to a denied authorization page.

Steps to Configure Access Control

To configure access control to your website, do the following:

125 1. Configure an authentication database. 2. Associate the authentication database with your website. 3. Configure the authorization policy for your website.

Step 1 - Configuring an Authentication Database

An authentication database can be internal or external. To configure an internal database, set up local users and groups on the ACCESS CONTROL > Local User/Group page. To configure an external database, use the ACCESS CONTROL > Authentication Services page.

Configuring Internal Authentication Database

The Barracuda Web Application Firewall maintains an internal LDAP authentication database, to which the administrator is required to create users and groups using the ACCESS CONTROL > Local Users/Groups page. One or more users can be added to each group, and one user can belong to multiple groups.

To Create a Group

1. Go to the ACCESS CONTROL > Local Users/Groups page. In the Groups section enter a name for the group in the New Group Name field. 2. Click Add. The new group gets listed under Available Groups.

To Create a User

1. Go to the ACCESS CONTROL > Local Users/Groups page. In the Users section, specify values for the following: a. New User Name – Enter a name for the user. Note that this is the username used to authenticate the user. b. Password – Enter a password for the user. c. User Groups – Select a group name from the list of groups and click Add. If you wish to associate the user to multiple groups, perform the same step again. 2. Click Add.

Configuring External Authentication Database

External authentication databases are configured on the ACCESS CONTROL > Authentication Services page. The Barracuda Web Application Firewall supports the following authentication database servers:

LDAP RADIUS SITEMINDER RSA SECURID

Configuring LDAP Database Server

LDAP Authentication service identifies a database server supporting the LDAP protocol, which contains a set Authentication service. It is a unique identifier that identifies a set of users, groups, and contains mapping between the groups and the users. Configuration of this page allows the Barracuda Web Application Firewall to communicate with an existing LDAP directory server, and authenticate a user.

To enable LDAP user authentication:

1. From the ACCESS CONTROL > Authentication Services page select the LDAP tab. 2. Enter information about your LDAP server: a. Realm Name – Enter the name of the realm under which the Barracuda Web Application Firewall admins are stored (A realm identifies a collection of users and groups. It specifies information, in a flat directory structure, such as where users are located and where groups are located.). b. Server IP – Enter the IP address of the external LDAP server to authenticate users. c. Server Port – Enter the port number on which the server listens to LDAP connections. The standard LDAP ports are: port 389 for non-SSL connections and 636 for SSL connections. d. Secure Connection Type – Select the type of secure connection to be used by Barracuda Web Application Firewall when querying the LDAP database for user authentication and role retrieval. None – Establishes a plain text connection. SSL/TLS – With SSL you can create a SSL socket and send/ receive LDAP messages over it. Typically LDAP server accepts SSL connections on port 636. The LDAP URI for this is defined as ldaps://

126 2.

Transport Layer Security (TLS) protocol enables client/server applications to establish a secure connection over the Internet. TLS allows client/server applications to communicate in a way that is designed to prevent tampering or message forgery. StartTLS – Upgrades an existing insecure plain text connection by sending an extended request to encrypt the connection using TLS. 3. Enter information about a user in your LDAP directory that has read access to all the users in LDAP directory: a. Bind DN – Enter Distinguished Name (DN) of the user to query the LDAP server. b. Base DN – Enter DN at which to start the search in the LDAP directory. c. Bind Password – Enter the password for the user querying the LDAP server. d. Login Attribute – Enter the attributes of an LDAP object used for identifying the user. For example: uid, sAMAccountName. e. Group Name Attribute – Enter the attributes of an LDAP object used for identifying the name of a group. Example: cn, sAMAccountName. f. Group Filter – Enter the filter attribute to retrieve the list of groups of the user in the LDAP directory. The maximum allowable characters are 500. g. Query For Group – Select Yes to query the groups in the LDAP directory for authentication. If set to No, queries are directed to individual user names for authentication. 4. Optional. Test the entered values for connectivity, username binding, and encryption: a. Click Test LDAP. The Barracuda Web Application Firewall checks the information you provided. b. Check the test results displayed at the bottom of the page. c. If the test fails, you can either correct settings as needed and repeat Step 4, OR you can use the LDAP Discovery tool as described in the next step. 5. Test the entered values and view troubleshooting details and recommendations (if any): a. Click LDAP Discovery. The Barracuda Web Application Firewall checks the information you provided. b. Check the test results: Verified information is indicated with a green dot next to the field. Information that need to be corrected is indicated with a red dot next to the field. Note: If you want to view detailed query results, click Verbose. If any information is incorrect or missing, edit fields as needed and then repeat Step 5. 6. After your settings have been validated, click Add to save your settings.

Configuring RADIUS Database Server

The RADIUS protocol is based on a client/server model. The Barracuda Web Application Firewall can operate as a client of a RADIUS server. The client is responsible for passing user information to a designated RADIUS server and then acting on the response that is returned.

A RADIUS server (or daemon) can provide authentication and accounting services to one or more Barracuda Web Application Firewall devices. RADIUS servers are responsible for receiving user connection requests, authenticating users, and then returning all configuration information necessary for the client to deliver service to the users. A RADIUS server is generally a dedicated workstation connected to the network.

RADIUS Authentication service identifies a database server supporting the RADIUS protocol that contains a set of users, groups, and mapping between groups and users. This container allows the user to configure the Barracuda Web Application Firewall to communicate to an existing RADIUS directory server to authenticate a user.

To enable RADIUS user authentication:

1. From the ACCESS CONTROL > Authentication Services page select the RADIUS tab. 2. Enter information about your RADIUS server: a. Realm Name – Enter the name of a realm. A realm is a RADIUS compliant database of authorized user and group records. The realm can be located internally or externally on a RADIUS server. b. Server IP – Enter the IP address of the RADIUS server to authenticate users. c. Server Port – Enter the port number of the RADIUS server. Port 1812 is normally used for RADIUS. d. Shared Secret – Enter the secret key which is shared between the Barracuda Web Application Firewall and RADIUS server. Minimum value of the key is 6. e. Timeout – Enter the time in seconds for Barracuda Web Application Firewall to wait for a response from the RADIUS server before retransmitting the packet. f. Retries – Enter the number of times you want the Barracuda Web Application Firewall to transmit a request packet to the RADIUS server before giving up. 3. Click Add to add your RADIUS server configuration.

Configuring a Secondary RADIUS Server

The Barracuda Web Application Firewall supports secondary RADIUS server for authenticating users. In case the primary RADIUS server fails,

127 the secondary RADIUS server takes over as the primary RADIUS server for authenticating users. When configuring the secondary server, note all parameter values including shared secret of the secondary RADIUS server must be identical to the primary RADIUS server, except the server IP address and port number.

To configure a secondary RADIUS server

1. Click Add next to the RADIUS authentication service for which you want to add the secondary server. The Authentication Services window appears, specify values for the following: a. Secondary Server IP – Specifies the IP address of the secondary RADIUS server. b. Secondary Server Port – Specifies the port number of the secondary RADIUS server. 2. Click Add to add the secondary RADIUS server configuration

Configuring SITEMINDER Database Server

SiteMinder Authentication service identifies a database server supporting the SiteMinder protocol, which contains a set of users, groups, and mapping between groups and users. This container allows the user to configure the Barracuda Web Application Firewall to communicate to an existing SiteMinder directory server for authenticating a user.

To enable SITEMINDER user authentication

1. From the ACCESS CONTROL > Authentication Services page select the SITEMINDER tab. 2. Enter information about your SITEMINDER server: a. Realm Name – Enter the name of the realm under which the Barracuda Web Application Firewall admins are stored. b. Server IP – Enter the IP address of the SiteMinder Policy Server to authenticate users. c. Port – Enter the authentication port of the SiteMinder Policy Server. Port 44443 is the standard port used for SiteMinder. d. Enter information about a user in your SITEMINDER server that has privilege to access all the SITEMINDER policies in SITEMINDER server. i. Admin – Enter the privileged username for the SiteMinder Policy Server. ii. Password – Enter the privileged user's password for the SiteMinder Policy Server. iii. Agent Name – Specifies the agent name configured in the SiteMinder Policy Server to represent Barracuda Web Application Firewall as SiteMinder agent. Note: The specified agent name must have the following parameters set to Ye s under Agent Conf Objects on the SiteMinder Policy Server: AcceptTPCookie RequireCookies 3. Host Conf Object – Enter the corresponding Host Configuration Object defined on the SiteMinder Policy Server. 4. Shared WAF IP Addresses – Enter the IP address(es) of the Barracuda Web Application Firewall that share the user sessions. Each system specified here should set Single User Session to Yes on the ACCESS CONTROL > Authentication page to synchronize information between each other, and keep only one active session for a user. For example, consider you have two systems with the IP addresses 10.10.10.10 and 10.10.11.11. The system with IP address 10.10.10.10 should have 10.10.11.11 configured as Shared WAF IP Addresses and vise versa. Also, both systems should set Single User Session to Yes to synchronize information and keep only one active user session. Note: When configuring this parameter, all Barracuda Web Application Firewalls should have the same Realm Name and Cookie Encryption Key. 5. Click Add to add your SITEMINDER server configuration.

Configuring RSA SECURID Database Server

RSA SecurID authentication service uses the RSA Authentication Manager database to authenticate the identity of users based on two factors: the current code generated on the user's assigned RSA SecurID authenticator, and a secret memorized Personal Identification Number (PIN) before granting access to protected resources.

To enable RSA SECURID user authentication:

1. From the ACCESS CONTROL > Authentication Services page select the RSA SECURID tab. 2. Enter information about your RSA RADIUS server: a. Realm Name – Enter the name of the realm under which the Barracuda Web Application Firewall admins are stored. b. Server IP – Enter the IP address of the RSA RADIUS server to authenticate users. Note: The RSA Authentication Manager server running RADIUS is termed as RSA RADIUS server in the Barracuda Web Application Firewall. c. Server Port – Enter the port number of the RSA RADIUS server. Port 1812 is the standard port for RADIUS. d. Shared Secret – Enter the secret key which is shared between the Barracuda Web Application Firewall and the RSA RADIUS server. Minimum value of the key is 6. e. Timeout – Enter the time in seconds for Barracuda Web Application Firewall to wait for a response from the RSA RADIUS server before retransmitting the packet.

128 2.

f. Retries – Enter the number of times you want the Barracuda Web Application Firewall to transmit a request packet to the RSA RADIUS server before giving up. 3. Click Add to add your RSA RADIUS server configuration.

Step 2 - Associating the authentication database with your website

The ACCESS CONTROL > Authentication page allows you to specify the parameters and resources to bind a configured authentication database with your Service and configure authentication of users.

Steps to associate an authentication database server with your website:

1. From the ACCESS CONTROL > Authentication page identify the Service to which you want to bind an authentication database. 2. Click Edit next to that Service. The Edit Authentication Policy window appears. 3. In the Edit Authentication Policy section, set the Status to On and select the authentication database server from the Authentication Service drop-down list. 4. Specify values to other parameters as required and click Save Changes.

When LDAP is selected as an authentication database server, the Auth Password Expired URL field is displayed. Specify the URL to redirect the user when authentication fails due to an expired password. The Barracuda Web Application Firewall identifies the password expiry of a user and redirects the user to the specified URL to reset the password. This feature is supported ONLY when Authentication Database is Microsoft Active Directory-LDAP. Expired password on OpenLDAP server is not detected by the Barracuda Web Application Firewall.

Step 3 - Configuring the authorization policy for your website

The ACCESS CONTROL > Authorization page allows you to configure custom access across your website allowing or denying users or groups access to specific services. Access control for a service is configured per URL and Host Match. Configure access control for a URL key of a service to restrict which users/groups can access that URL space. Customized access is configured by user and/or group.

Steps to configure an authorization policy for your website:

1. Go to the ACCESS CONTROL > Authorization page. In the Add Authorization Policy section specify values for the following: a. Service – Select the Service to which you want to configure access control. b. Policy Name – Enter a name for the authorization policy. c. Status – Set to On to apply this authorization policy to the Service. d. URL Match – Enter a URL to be matched to the URL in the request. The URL should start with a "/" and can have at most one " * " anywhere in the URL. For example, /netbanking.html, any request matching this URL is required to authenticate before accessing this page. A value of “/*” means that the access control rule (ACL) applies for all URLs in that domain. e. Host Match – Enter a host name to be matched against the host in the request. This can be either a specific host match or a wildcard host match with a single “* “anywhere in the host name. For example, *.example.com, any request matching this host is required to authenticate before accessing this page. f. Extended Match – Define an expression that consists of a combination of HTTP headers and/or query string parameters. This expression is used to match against special attributes in the HTTP headers or query string parameters in the requests. g. Extended Match Sequence – Enter a number to indicate the order in which the extended match rule must be evaluated in the requests. h. Login Method –Select the login method to be used for authenticating users. 2. Click Add to associate the authorization policy with the Service. 3. To enforce fine grained access control, click Edit next to the Authorization Policy. The Edit Authorization Policy window appears. 4. In the Edit Authorization Policy section, specify values for the following: a. Allowed Users – Enter the list of users allowed to access the URL. Note: To access to the URL, the user must be included either in "Allowed Users" or "Allowed Groups". For example, all the users in the group-HR get access to this URL when group-HR is listed in "Allowed Groups" parameter. Now, user-1 who does not belong to group-HR also needs access to the same URL. To achieve this, specify user-1 in "Allowed Users". This setting enables user-1 and group-HR get access to this URL. b. Allowed Groups – Enter the list of allowed groups to access the URL. c. Auth Not Done URL – Enter the URL where a user who attempts to access a protected URL before being authenticated will be redirected. If the URL is not specified, the user is redirected to the default login page generated by the Barracuda Web Application Firewall. Use this to redirect the user to a customized page or an error page instead of the default login page. Note: The redirect URLs need not reside in the same service. Also, these pages must be hosted outside the Barracuda Web Application Firewall, typically in the server of the application. The internal Barracuda Web Application Firewall pages cannot be customized. d. Access Denied URL – Enter the URL where an authenticated user who lacks required access privileges should be redirected.

129 4.

e. Send Basic Authentication – Select Yes to convert user credentials to HTTP Basic Authentication header, included in every request sent to the server. This is useful when Login Method is set to HTML Form, and when the server needs to know the user credentials. Two typical cases of the server needing to know the user credentials are: i. To implement single sign on. The server may require customization to process the Basic Authentication header, extract the user ID and password, and perform any authentication or authorization required by the Service so a user is not challenged to log in again. ii. To personalize the home page, the server needs to know the user ID. Note: HTTP Basic Authentication Headers are sent in clear text, so it is not a secure means of exchanging user credentials. The user ID and password are visible in the data packets transmitted to the server. It is recommended that this option is used only when the traffic to the server is encrypted. f. Send Domain in Basic Authentication – If set to Yes, the domain information of the client is forwarded to the server along with the user credentials in the Basic Authentication Header. This is applicable only when Send Basic Authentication is set Yes. 5. To perform advanced settings, specify values for the following in the Advanced section: a. Authorization Agent – The Barracuda Web Application Firewall is set as a default authorization agent to authorize users accessing this Service. This value remains the same for Services that are associated with the LDAP, RADIUS and RSA SECURID authentication services. For SITEMINDER authentication service, select SiteMinder as an authorization agent from the drop-down list to authorize users accessing SiteMinder protected resources. b. Authorization Result Cache – Select an option from the drop-down list to cache the authorization result for allowed and denied responses. No Cache – Does not cache authorization results. Cache All – Caches all allowed and denied authorization results. Cache Allows – Caches only the allowed authorization results. 6. Authorization Resource Depth – Enter the number of levels in the URI path of the request to be used for caching the authorization entries. 7. Ignore Query String – Set to Yes if you wish to ignore query strings in the request while caching authorization entries. 8. Click Save Changes.

How to Set Up a Custom Login Page for Authentication Kerberos Authentication en

Overview

Kerberos is the native authentication method used by Windows 2000 and later platforms. This authentication protocol provides mutual authentication; i.e. both the user and the server verify the other's identity. Kerberos uses a trusted third party known as Key Distribution Center (KDC). The Key Distribution Center must be a part of the Windows Domain Controller Active Directory. The Key Distribution Center provides two services, an Authentication Service (AS) which authenticates a user and a Ticket Granting Service (TGS) that issues a session ticket to a client.

Kerberos relies on Service Principal Names (SPNs) to uniquely identify an instance of a service (which runs on a host) by a client. Each web service should be assigned a SPN which is registered in Active Directory. The SPN is represented in the following format:

/, OR /:/

The port and service name are optional, port is required ONLY when the is other than the default.

Pre-requisite:

The Barracuda Web Application Firewall should have proper DNS servers configured. The DNS Server IP address configured on BASIC > IP Configuration > DNS Configuration should be reachable by the Active directory domain (the domain where Key Distribution Center (KDC) is installed). Ensure the Barracuda Web Application Firewall time is synchronized with the Kerberos server time.

Configuring Kerberos Authentication Service

Perform the following steps:

1. Go to the ACCESS CONTROL > Authentication Services page. 2. In the New Authentication Service section, click the KERBEROS tab and specify values for the following fields:

130 2.

a. Realm Name – A name identifying the KERBEROS authentication service on the Barracuda Web Application Firewall. b. KDC Realm Name – Enter the name of the realm configured on KDC. c. KDC IP Address/Name – Enter the name or IP address of the KERBEROS server used for authenticating users. d. KDC Port – Enter the port address of the KERBEROS server used for authenticating users. Port 88 is the standard port used for KERBEROS. e. Domain Alias (Optional) - Enter the domain name alias of the Kerberos Domain Server. For example, if the domain name is "Kerberos.example.com" and the alias for it is "Kerberos", then configure "Kerberos" in this field. This is optional if you are configuring for a single domain, but mandatory when you want to enable multi-domain authentication for users. 3. Click Add.

Associate the Service with the Kerberos Authentication Service

Perform the following steps:

1. Go to the ACCESS CONTROL > Authentication page. 2. Identify the Service with which you want to associate the Kerberos authentication service. 3. Click Edit next to the Service. The Edit Authentication Policy window appears. 4. In the Edit Authentication Policy section, do the following: a. Set Status to On. b. Select the Kerberos authentication service from the Authentication Service drop-down list. c. Specify the Service Principal Name (SPN) used for enabling Kerberos authentication for this Service in the Kerberos SPN field.

This should be the SPN registered for this Service in Active Directory. For example, consider "HTTP/test.abc.com" is the SPN registered in Active Directory. The Kerberos SPN to specify would be "test.abc.com".

d. Kerberos Delegation – When set to Yes, the delegation flag will be set in the request from the Barracuda Web Application Firewall to the Kerberos server. 5. Specify values of other parameters as required and click Save Changes.

Configure the authorization policy for the Service

Perform the following steps:

1. Go to the ACCESS CONTROL > Authorization page. 2. In the Add Authorization Policy section, do the following: a. Service – Select the Service from the drop-down list. b. Policy Name – Enter a name for the authorization policy. c. Status – Set to On. 3. Specify values of other parameters as required and click Add. Click the Help icon for more information. 4. In the Existing Authorization Policies section, click Edit next to the policy created above to configure advanced authorization settings.

Authentication of Client Traffic in Kerberos Environment

131 The following process authenticates client traffic:

1. The user attempts to access an application which is protected by Kerberos. a. The Barracuda Web Application Firewall challenges the user to provide login credentials via Authentication Form. b. The user enters username and password. 2. The Barracuda Web Application Firewall transmits the credentials to the Kerberos Server for validation. 3. The Kerberos server authenticates the user and creates a session ticket for the user. 4. The Barracuda Web Application Firewall sends the request with the session ticket to the back-end server to fetch the requested page which it in turn serves to the client.

Load Balanced Environment

Kerberos requires a unique Service Principal Name (SPN) configured for each Service. If you have multiple servers configured for a Service, then a single SPN should be registered in Active Directory for that Service. For example, consider you have a service “web1.domain.com” for which two servers S1 and S2 are configured for load balancing. The SPN should be created for the domain “web1.domain.com” and registered in Active Directory under the User (eg: Web User). The servers S1 and S2 should provide required permissions for that user.

In the above example, the SPN should be registered as HTTP/abc.com abc/Web user

Steps to Enable Kerberos Authentication for the Servers that are used to Load Balance

Perform the following steps:

Step 1 - Creating a User in Active Directory

1. From the Active Directory Users and Computers window, right click Users, select New > User. The New Object – User window appears.

132 1.

2. Specify the First name and Last name of the user. Also, User login name and Password.

3. Click Next and specify values for other fields as required and click Finish.

Step 2 - Set SPN for the user

To set SPN for the user created in the earlier step, open a Command Prompt and execute the setspn command.

Step 3 - Configure the Web server application poll to run for the created user

To Run the web application poll for the user “svradm”, perform the steps below (Go to server S1):

1. In the IIS Manager, click Application Pools in the left pane. All the running applications will get displayed in the right pane.

133 1.

2. Identify the application to associate to the user. Right click on the application and select Advanced Settings. 3. In the Advanced Settings window, click the button next to Identity. The Application Pool Identity window appears.

4. In the Application Pool Identity window, select the Custom account radio button and click Set…. Enter the user name and password for the user and click OK.

134 4.

5. Repeat Step 3 on the server S2. 6. Configure the DNS server to resolve the SPN name to the virtual IP address of the service.

How to Set Up a Custom Login Page for Authentication en Setting up a custom login page for authentication is a three step process:

1. Create a custom login page. 2. Deploy the created custom page on your web server. 3. Configure the Barracuda Web Application Firewall to use the custom login page.

As an example setup, let's assume:

A back-end server at 192.168.128.10 needs access restricted to authenticated users. The particular web application resources which reside in "http://192.168.128.10/secure" are the ones requiring users to authenticate before gaining access. You would like to authenticate users against an LDAP server. Service-1 (10.10.10.2:80) is configured on the Barracuda Web Application Firewall to secure the access to the web application, with 192.168.128.10:80 configured as the server.

Step 1 - Creating a Custom Login Page

Now create a custom login page "login.html". It must contain the following:

Form ID = nclogin Name = nclogin Action = "/nclogin.submit" Method = POST User name field should be named - f_username Password field should be named - f_passwd An additional hidden parameter named f_method should be specified with value "LOGIN"

135 The form will look something like this:

Step 2 - Deploying the created custom page on your web server

To use the "login.html" file, deploy it on your web server. For example:

The IP address of the web server is 192.168.128.10 And the “login.html” is available by accessing "http://192.168.128.10/login.html"

Step 3 - Configuring the Barracuda Web Application Firewall to use the custom login page

Once the custom page is deployed on your web server, configure the Barracuda Web Application Firewall to use the custom login page by doing the following steps:

1. Configure Authentication Service – Specify the authentication database server (LDAP) which will be used to authenticate the user's credential. See How to Configure Authentication and Access Control (AAA). 2. Configure Authentication Policy – Create an authentication policy for the Service you want to secure. To do this, click Edit next to the relevant Service ("Service-1"in this example) on the ACCESS CONTROL > Authentication page. In the Edit Authentication Policy win dow, configure the following: Set Status to On. Select LDAP from the Authentication Service drop-down list. Note that this is the authentication service created in Step 3 (1.). Enter your domain in Session Cookie Domain, for instance: www.example.com. Specify values for other parameters appropriately and click Add. For more information, click Help on that page. 3. Configure Authorization Policy – Create an authorization policy to specify the accessible resources after a successful authentication on the ACCESS CONTROL > Authorization page using the following steps: On the ACCESS CONTROL > Authorization page, in the Add Authorization Policy section, specify values for the following: Service - Select the relevant service (Service-1 in the example) from the drop-down list. Policy Name – Enter a name for the authorization policy. Example: secure.access URL Match – Enter the URL of the secured part of the web application. In this example the URL is: /secure/ Login Method – Select HTML Form. Click Add.

On the ACCESS CONTROL > Authorization page, in the Existing Authorization Policies section, click Edit next to your new authorization policy (secure.access). In the Edit Authorization Policy window, do the following: Set Status to On. Specify “/login.html” in Auth Not done URL. Set Send Basic Authentication to Yes. Set Send Domain in Basic Authentication to Yes if you want the domain information of the client to be forwarded to the server along with the user credentials in the Basic Authentication Header. This is applicable only when Send Basic Authentication is set Yes. Specify values for other parameters appropriately and click Save Changes. For more information click Help on that page.

Once configured this way, when a client accesses "http://10.10.10.2/secure/mydoc.html" they will be presented with the configured custom login page (login.html). The user ID and password forwarded by the web server's custom login page are validated against the Authentication server integrated with the Barracuda Web Application Firewall before a request is allowed to reach the back-end web server.

If you are enabling "Authorization" for entire website (/*), then a "GLOBAL ACL" rule needs to be created with URL match as the custom login URL (for example: /login.html) and the action as “Allow”. This URL ACL rule should be created on the SECURITY POLICIES > Global ACLs page for the policy to which the Service is associated to.

Note that a URL ACL rule created per website will not take precedence over the authorization policy.

136 Related Articles

Configuring Authentication and Access Control How to Configure Single Sign-On (SSO) en In this article:

Single domain SSO Setting up Single domain Single Sign-On Environment Logout in Single domain Single Sign-On Environment Multi-domain SSO Multi-domain Single Sign-On Configuration Multi-domain Single Sign-On Functionality Setting up Multi-domain Single Sign-On Environment Chained Logout in a Multi-domain Single Sign-On Session

Single Sign-On (SSO) is a mechanism where a single set of user credentials is used for authentication and authorization to access multiple applications across different web servers and platforms, without having to re-authenticate.

The SSO system acts as a web gate for all inbound web traffic. When a user initially attempts to access the website, the user is challenged to provide login credentials. If authentication succeeds, an SSO User Session Cookie is generated. The SSO User Session Cookie authenticates the user for a period of time. If the log in fails, the authentication request is rejected.

The SSO environment protects defined resources (websites and applications) by requiring the following steps before granting access:

Authentication: Authentication verifies the identity of a user using login credentials. Authorization: Authorization applies permissions to determine if this user may access the requested resource.

The Barracuda Web Application Firewall supports both single domain and multi-domain SSO.

Single domain SSO

Single domain SSO takes place within a single domain. For example, consider the domain barracuda.com which hosts several restricted websites on several hosts. You can configure single sign-on for this domain, so that authenticated users can access all or a subset of the restricted resources by authenticating just once.

Setting up Single domain Single Sign-On Environment

1. Go to the ACCESS CONTROL > Authentication page. 2. Identify the Service for which you want to set up single sign-on and click Edit next to that Service. The Edit Authentication Policy windo w appears. 3. In the Edit Authentication Policy section, set the Status to On. 4. Select the Authentication Service to be associated with the Service. 5. Set the Session-Cookie Domain to the domain name of the Services for which you are configuring single domain SSO. Example: service1 and service2 both have .barracuda.com as the session cookie domain. 6. Click Save Changes.

In a Single domain SSO set up, ensure that you configure the same Session Cookie Domain name for each service on the ACCESS CONTROL > Authentication page.

Logout in Single domain Single Sign-On Environment

When a user logs out of a domain, the Barracuda Web Application Firewall removes the user session cookie from the browser by expiring it, so the user is automatically logged out of other corresponding domains. For example, consider a user logged into host1.bc.com, host2.bc.com and host3.bc.com using bc.com as the cookie domain. if the user performs a logout in host1.bc.com, the user session cookie is removed from the browser, and the user is automatically logged out of host2.bc.com and host3.bc.com.

If the user does not access the SSO environment within the specified idle timeout, the user session becomes idle and the user is challenged to provide login credentials to access the SSO environment again.

137 Multi-domain SSO

Multi-domain SSO enables a user authentication to be honored by hosts in two or more domains. For example, a set of URLs that reside within the domains www.abc.com and www.xyz.com can be set to single sign-on.

To achieve a multi-domain single sign-on, a master domain is required for authentication. The Barracuda Web Application Firewall multi-domain single sign-on environment can have one master domain and one or more slave domains. The master domain acts as a centralized authentication server that authenticates the users and transfers the SSO User Session Cookie to the slave domains.

In a multi-domain single sign-on environment, each domain is responsible for maintaining and enforcing its own idle timeout. This means the cookie value for different domains might be different. You have to configure the master service and the slave services on the Barracuda Web Application Firewall on the ACCESS CONTROL > Authentication page.

Multi-domain Single Sign-On Configuration

For a multi-domain SSO environment, you should explicitly specify the master service and master service URL for the domains as explained below:

Master Service: Specifies if the master service URL is handled by this service. When set to Yes, this service acts as the master domain to the subsequent domains. When set to No, this service acts as the slave domain that accepts the cookie from the master domain. Master Service URL: Specifies the URL that provides a cookie. In case of the master domain specify only the URL path, but for the slave domains specify the protocol, host, master domain and URL path.

The master service URL should be a virtual URL (internal URL). For example, /ncsso.process, /index.html, etc. This URL is used to identify the master service URL in a multi-domain environment. A global ACL rule must be created for the specified master service URL on the SECURITY POLICIES > Global ACL's page with the following configuration settings: The parameter Action must be set to Allow. The configured master service URL should be specified in the URL Match field.

For example, consider www.abc.com as the master domain and www.xyz.com as the slave domain. If the master service URL for the master domain is /ncsso.process, then the master service URL for the slave domain is http://www.abc.com/ncsso.process .

Multi-domain Single Sign-On Functionality

If a user attempts to access the master domain first, the user is challenged to provide login credentials. On a successful login, the user gains access to the master domain and to the slave domains. But if a user attempts to visit the slave domain first, the Barracuda Web Application Firewall redirects the user to the master service URL for authentication, and challenges the user to provide login credentials. If successful, the user gains access and is redirected to the requested domain.

For example, consider www.abc.com as the master domain and www.xyz.com as the slave domain. If a user attempts to access the master domain first (www.abc.com), the user is challenged to provide login credentials. An SSO User Session Cookie is generated on a successful login. Now, the user gains access and can navigate to the slave domains using the generated session cookie without having to re-authenticate.

If a user attempts to access the slave domain first (www.xyz.com), the Web application redirects the user to the master service URL for authentication. The user is challenged to provide login credentials. If successful, SSO User Session Cookies are generated for both domains (master and slave) and the user is allowed to access the slave domain.

Setting up Multi-domain Single Sign-On Environment

Steps to Configure Master domain:

1. Go to the ACCESS CONTROL > Authentication page. 2. Identify the Service that you want to configure as a master domain and click Edit next to that Service. The Edit Authentication Policy wi ndow appears. 3. In the Edit Authentication Policy section, set the Status to On. 4. Select the Authentication Service to be associated with the Service. 5. Scroll down to the Single Sign On section and set Master Service to Yes. Note that this is the master service that provides the cookie for the subsequent slave domains. 6. Specify the URL path in the Master Service URL field. The master service URL path can be any URL you choose. Example: /ncsso.p rocess, /index.html, etc. Note that a global ACL rule must be created for the specified master service URL on the SECURITY POLICIES > Global ACL's page. For more information, see Multi-domain Single Sign-On Configuration.

138 7. Click Save Changes.

Steps to Configure Slave domain:

1. Go to the ACCESS CONTROL > Authentication page. 2. Identify a Service that you want to configure as a slave domain and click Edit next to that Service. The Edit Authentication Policy windo w appears. 3. In the Edit Authentication Policy section, set the Status to On. 4. Select the Authentication Service from the drop-down list to associate with the Service. 5. Scroll down to the Single Sign On section; set Master Service to No. Note that this is the slave service. 6. Specify the protocol, host, master domain and URL path in the Master Service URL field. 7. Click Save Changes.

Chained Logout in a Multi-domain Single Sign-On Session

If logout is from the master domain, the Barracuda Web Application Firewall removes the master domain cookie from the browser by expiring it. If logout is from the slave domain, the slave domain cookie is removed from the browser by expiring it, which redirects the user to the master domain, and informs the master domain to logout the user (remove the master cookie).

For example, consider the case where three domains www.xyz.com, www.abc.com and www.def.com are a part of a multi-domain SSO environment, with www.xyz.com as the master domain, and both www.abc.com and www.def.com as the slave domains. When a logout is from the master domain (www.xyz.com), the user session cookie is removed from the browser by expiring it, which automatically accomplishes logout of the corresponding domains (www.abc.com and www.def.com).

When a logout is from a slave domain (e.g., www.abc.com), the slave domain expires its cookie, redirects to the master domain (www.xyz.com), and requests the master domain to expire its cookie and log out. Then www.abc.com redirects the user to log out from www.def.com. To achieve this, configure Auth Logout Success URL as http://www.def.com/nclogin.submit?f_method=LOGOUT for authentication of w ww.abc.com.

In this case, the Auth Logout Success URL in www.abc.com is http://www.def.com/nclogin.submit?f_method=LOGOUT . This assumes that 'nclogin.submit' is configured as the login-processor-path in www.def.com. Similarly for multiple slave domains; you need to configure the same settings in www.def.com for the corresponding next domain and so on.

Steps involved in chained logout:

1. User performs a logout on www.abc.com. www.abc.com expires it's cookie, and redirects the user to www.xyz.com. 2. www.xyz.com expires its cookie and redirects the user back to www.abc.com 3. www.abc.com redirects the user to perform a logout on www.def.com 4. www.def.com expires its cookie and redirects the user to www.xyz.com 5. www.xyz.com simply redirects the user back to www.def.com, since its cookie has been expired in step 2. 6. The SSO User Session cookie of all the three domains has been removed from the browser. 7. This process can be extended for more slave domains by simply chaining the logout-success-url configuration in the authentication container.

If the user does not access the SSO environment within the specified idle timeout, the session becomes idle and the user is challenged to provide login credentials to access the SSO environment again.

How to Configure SiteMinder Single Sign-On (SSO) How to Configure SiteMinder Single Sign-On (SSO) en In this article:

SiteMinder Components in SiteMinder Setup Single Sign-On (SSO) Setup Single Sign-On (SSO) SiteMinder SSO How it works

139 Configuring SiteMinder SSO through Barracuda Web Application Firewall Configuring SiteMinder Authentication Service Configuring Authorization Policy Configuring SiteMinder Single Sign-On

SiteMinder

The Barracuda Web Application Firewall integrates with CA/Netegrity SiteMinder to provide Single Sign-On and centralized management of Web applications using the predefined security policies. It uniquely identifies users before they are authenticated as named users, and manages user’s privileges to ensure that they access only authorized applications or operations.

Components in SiteMinder Setup

The two significant components of SiteMinder are:

Web Agents – Integrated with a standard Web server or application server that enables SiteMinder to manage Web applications based on the predefined security policies. Policy Server – Provides Policy management and AAA functions within the SiteMinder framework.

Single Sign-On (SSO) Setup

In SiteMinder Single Sign-On (SSO), a user successfully authenticates through one agent and does not have to re-authenticate when accessing a realm protected by a different agent. The two agents must be in the same cookie domain, for example: /abc.siteminder.com. CA SiteMinder supports both single and multi-domain Single Sign-On. For more information about Single sign-on functionality, refer to How to Configure Single Sign-On (SSO).

The ACCESS CONTROL > Authentication page provides two types of Single Sign-On:

Single Sign-On (SSO)

Supports single and multiple domains. The Barracuda Web Application Firewall authenticates and authorizes users accessing the Web application.

SiteMinder SSO

Supports single and multiple domains. Authentication and authorization is performed by the SiteMinder Policy Server. By default, the Barracuda Web Application Firewall is set as an authorization agent for all authentication services. To change the Authorization Agent to SiteMinder, navigate to the ACCESS CONTROL > Authorization page and click Edit next to the Service. See Configuring Authorization Policy.

How it works

The following steps describe how the Barracuda Web Application Firewall communicates with the Policy Server before granting access to the protected resource.

1. The Barracuda Web Application Firewall intercepts requests and communicates with the Policy Server to determine whether the requested resources are protected or not. For protected resources, users are redirected to a login page, and challenged to provide credentials. If the resource is not protected, the user is allowed to access the requested resource instantly. Note: If a customized login URL is defined in Auth Not Done URL on the ACCESS CONTROL > Authorization page, the user is redirected to that page for authentication. If not, the user is redirected to the default login page. 2. User enters username and password. 3. The Barracuda Web Application Firewall transmits the credentials to the SiteMinder Policy Server for validation. 4. The SiteMinder Policy Server authenticates the user against the configured external user directories. The Policy Server supports LDAP, Oracle, Microsoft SQL Server and custom user directories. 5. After successful authentication, the Barracuda Web Application Firewall communicates with the Policy Server to authorize the user. During authorization, SiteMinder: a. Checks the rules and policies assigned to the users and groups. b. Generates an SSO token for the request. 6. On successful authorization, SiteMinder sends the SSO token along with other information such as user details, session expiration time and additional user attributes defined on the Policy Server if any. 7. The Barracuda Web Application Firewall uses the SSO token, appends the SMSESSION cookie to the request and allows access to the protected resource. 8. When the user attempts to access another protected resource:

140 8.

a. The Barracuda Web Application Firewall validates the user based on the contents of the SMSESSION cookie and communicates with the Policy Server for authorization, without challenging the user for credentials. b. If authorized, the user is allowed to access the protected resource and the information is stored in the cache.

Configuring SiteMinder SSO through Barracuda Web Application Firewall

The Barracuda Web Application Firewall requires the following configuration settings for SiteMinder SSO:

Pre-requisite:

1. Before enabling SiteMinder SSO on the Barracuda Web Application Firewall the administrator must configure the SiteMinder Policy Server as follows: a. SiteMinder Agent – Create an Agent with the Agent Type as SiteMinder and Web Agent. Note: The Name field in the Agent Properties window must match the Agent Name parameter in the Barracuda Web Application Firewall configuration for SITEMINDER server. b. Agent Conf Objects – In Agent Configuration Objects Properties, do the following: i. Add a new parameter AcceptTPCookie and set Value to Yes. ii. Set DefaultAgentName to Agent Name parameter defined in Step 1a. c. Host Conf Objects – In Host Configuration Object Properties, ensure the IP address and port numbers assigned to Policy Server are correct. If the Policy Server is in a cluster, specify the IP addresses of all Policy Servers in the cluster. d. Create a user directory with all user names to be authenticated by SiteMinder. Create Realms and define rules and policies for the realm.You should create realms for each URL pattern you want to protect or unprotect instead of protecting the root directory (/). For example “/images/logo.jpg”, “/images/banner.png” can be ignored from protection, and “/finance/report.html”, “/server/login.html” can be configured to be protected. Note: The SiteMinder Realm is not related with the Realm on the Barracuda Web Application Firewall. A realm in SiteMinder is a cluster of protected and unprotected resources. The SiteMinder Realm and the corresponding policies determine the users and groups to be allowed for a protected resource. Refer CA SiteMinder Policy Design Guide for more information on how to configure these objects.The values configured on the Policy Server now need to be specified in the SITEMINDER tab under the ACCESS CONTROL > Authentication Services page.

Note: The Barracuda Web Application Firewall uses “Custom Agent” capabilities of SiteMinder to provide authentication and authorization in a Single Sign-On environment.

Configuring SiteMinder Authentication Service

The SiteMinder Policy Server must be specified as the authentication service on the ACCESS CONTROL > Authentication Services > SITEMINDER tab. The Barracuda Web Application Firewall uses this information to communicate with the SiteMinder Policy Server to authenticate a user.

To configure SITEMINDER authentication service:

1. From the ACCESS CONTROL > Authentication Services page select the SITEMINDER tab and specify values for the following: a. Realm Name – Enter a name for the realm to identify this server in the Web interface. b. Server IP – Enter the IP address of the SiteMinder Policy Server used for authenticating users. c. Port – Enter the port number associated with the IP address of the SiteMinder Policy Server. d. Admin – Enter the username of a user with privileges to access the SiteMinder Policy Server. e. Password – Enter the password associated with the above username (Admin). f. Agent Name – Enter the agent name of the SiteMinder Agent you configured in the SiteMinder Policy Server. g. Host Conf Object – Enter the corresponding Host Configuration Object defined in the SiteMinder Policy Server. 2. Click Add to save your settings.

Configuring Authorization Policy

By default, the Barracuda Web Application Firewall is the authorization agent for Services associated with the LDAP, RADIUS and RSA SECURID authentication services. If a Service is associated with the SITEMINDER authentication service, the authorization agent must be SiteMi nder to authorize the users accessing SiteMinder protected resources. To change the Authorization Agent, click Edit next to the SiteMinder service on ACCESS CONTROL > Authorization and scroll down to the Advanced section. For more information on how to configure an authorization policy, see Configuring Authorization Policy.

Configuring SiteMinder Single Sign-On

Configure the following the parameters to set up single sign-on (SSO) using SiteMinder:

141 1. From the ACCESS CONTROL > Authentication page identify the Service to which you want to enable SiteMinder SSO. Ensure the Service is associated with the SiteMinder authentication service. 2. Click Edit next to the Service. The Edit Authentication Policy window appears. 3. Scroll down to the SiteMinder SSO section and specify values for the following: a. Cookie Provider – Set to Yes to enable this Service to act as a cookie provider agent to other agents that are in SiteMinder SSO setup. b. Cookie Provider URL – Specify the URL path of the cookie provider. This service acts as a cookie provider agent to other agents that are in SiteMinder SSO setup. c. Source IP Check – Set to Yes if you want to check the source IP address in the cookie while authenticating the user. d. Session Validation Timeout – Specify the time interval in seconds for the Barracuda Web Application Firewall to re-validate a session with the Policy Server. e. Set-Cookie List – Specify the list of cookies as comma separated regular expressions. If the regex matches the requesting URL, the corresponding cookie will be set in the redirect response to the Login page. f. Idle Timeout URL – Specify a URL to which the user will be redirected after Idle Timeout is exceeded. g. Idle Timeout Cookie – Specify a cookie name and value to be inserted in the redirect response to the client after the Idle Timeout is exceeded. h. Extended Idle Timeout – Set the maximum time (in minutes) that a user can remain idle, after which the user is redirected to the configured Extended Idle Timeout URL. i. Extended Idle Timeout URL – Specify a URL to which the user will be redirected once the Extended Idle Timeout is exceeded. j. Extended Idle Timeout Cookie – Specify a cookie name and value to be inserted in the redirect response to the client after the Extended Idle Timeout is exceeded. k. Single Session Per User – Set to Yes to allow only one active session per user. l. Enable Debug Logs – Set to Yes to enable debug logs. 4. Click Save Changes to save your settings.

References:

For more information about the SiteMinder Policy Server and Web Agent Configuration, refer to SiteMinder Bookshelf.

How to Configure Single Sign-On (SSO) How to Integrate RSA SecurID with the Barracuda Web Application Firewall en In this article:

en Configure the RSA Authentication Manager Configure the RADIUS Protocol Settings Add the Barracuda Web Application Firewall as an Agent Host Import SecurID Tokens Add Users to the RSA Authentication Manager and Assign Tokens Configure the Barracuda Web Application Firewall Add the RSA SecurID Server as an Authentication Service Bind the Service(s) on the Barracuda Web Application Firewall with the RSA SecurID Authentication Service Configure the Authorization Policy for the Service Verify the Setup and Authentication Process

The Barracuda Web Application Firewall can be configured as a RADIUS client to the RSA SecurID Server System, comprised of the RSA Authentication Manager and the Radius Server. Integrating the Barracuda Web Application Firewall with RSA SecurID requires three steps:

1. Configure the RSA Authentication Manager. 2. Configure the Barracuda Web Application Firewall. 3. Verify the Setup and Authentication Process.

Configure the RSA Authentication Manager

Configure the following settings on the RSA Authentication Manager Server:

1. Configure the RADIUS protocol settings that will be used by the Barracuda Web Application Firewall.

142 2. Add the Barracuda Web Application Firewall as an Agent Host within the RSA Authentication Manager's Database. 3. Import SecurID Tokens. 4. Add Users to the RSA Authentication Manager and Assign Tokens.

Configure the RADIUS Protocol Settings

1. Before configuring the RADIUS protocol, ensure the RADIUS server is up and running on the RSA Authentication Manager Server System. To check: a. Go to Start > Programs > RSA Security and select RSA Authentication Manager Control Panel. b. Select Start & Stop RSA Auth Mgr Services in the tree on the left pane. The Status of RSA RADIUS Server must be Running . If not, click Start RADIUS to bring it up. 2. On the RSA Authentication Manager Server System, go to Start > Programs > RSA Security and select RSA Authentication Manager Host Mode. Select the RADIUS menu, and select Manage RADIUS Server. 3. When the RSA RADIUS window appears, select RADIUS Clients in the tree on the left pane. 4. Click Add and the Add RADIUS Client window appears.

5. Specify values for the following fields: a. Name – Enter the Hostname of the Barracuda Web Application Firewall. b. Description – Optional. c. IP Address – Enter the IP address of the Barracuda Web Application Firewall. d. Shared Secret – Type the secret key. You will need to configure the same Shared Secret on the Barracuda Web Application Firewall in ACCESS CONTROL > Authentication Services > RSA SECURID. e. Make/Model – Select Juniper-ERX. 6. Click OK to save your settings.

Add the Barracuda Web Application Firewall as an Agent Host

1. On the RSA Authentication Manager Server System, go to Start > Programs > RSA Security and select RSA Authentication Manager Host Mode. 2. Select the Agent Host menu, and select Add Agent Host. The Add Agent Host window appears. 3. Specify values for the following fields: a. Name: Enter the hostname of the Barracuda Web Application Firewall. b. Network Address: Enter the IP address of the Barracuda Web Application Firewall. c. Agent Type: Select RADIUS Server. d. Encryption Type: Select DES or SDI encryption. e. Select Open to All Locally Known Users and Requires Name Lock. 4. Click User Activations... to assign users to the Agent host.

143 4.

5. Click OK. The Barracuda Web Application Firewall is added as an Agent Host to the RSA Authentication Manager.

Import SecurID Tokens

1. On the RSA Authentication Manager Server System, go to Start > Programs > RSA Security and select RSA Authentication Manager Host Mode. 2. From the Token menu, select Import Tokens. 3. Navigate to the token XML file provided by RSA and click Open to import the tokens. 4. The Import Status window appears displaying the number of tokens imported.

144 Add Users to the RSA Authentication Manager and Assign Tokens

On the RSA Authentication Manager Server System, go to Start > Programs > RSA Security and select RSA Authentication Manager Host Mode.

1. From the User menu, select Add User.

2. The Add User window appears. Specify values for the following fields: a. First and Last Name – Enter a user's first and last name. b. Default Login – Enter the default username this user will use to log in. 3. Users on the RSA Server can be authenticated in two ways: Token Mode or Passcode Mode(default). In Token Mode, users authenticate using the Tokencode currently generated by the RSA SecurID authenticator. In Passcode Mode, users authenticate using a

145 3.

Passcode (Personal Identification Number (PIN) followed by the Tokencode).

The random unpredictable code generated by the RSA SecurID authenticator at an interval of every 60 seconds is known as T okencode.

The combination of user’s PIN (Personal Identification Number) and the Tokencode currently generated by the user’s RSA SecurID authenticator is the user’s Passcode.

A PIN can be generated one of three ways: a. If neither Allowed to Create a PIN or Required to Create a PIN are selected, the system generates the PIN and gives it to the user. b. If Allowed to Create a PIN is selected, the user may choose to create a PIN or have the system generate the PIN.The user is offered a system generated pin, and if declined, is prompted to enter a PIN. c. If Required to Create a PIN is selected, the user must enter a PIN and is prompted to do so when logging in. 4. Select Allowed to Create a PIN or Required to Create a PIN as you prefer. 5. Select Assign Token. Click Yes to confirm. The Select Token window appears. a. To automatically assign a token, select the method by which you want to sort the token using Sorted by in the Auto Select secti on. Click Unassigned Token, and then click OK. b. To manually select the token, click Select Token from List. In the Select Token window, select the serial number for the token to assign, and click OK.

6. Give the user the serial number of the assigned token.

The RSA Authentication Manager configuration is now complete.

Configure the Barracuda Web Application Firewall

1. Add the RSA SecurID server as an Authentication Service on the Barracuda Web Application Firewall. 2. Bind the service(s) on the Barracuda Web Application Firewall with the RSA SecurID Authentication Service. 3. Configure the authorization policy for the service.

Add the RSA SecurID Server as an Authentication Service

146 On the Barracuda Web Application Firewall web interface, go to ACCESS CONTROL > Authentication Services:

1. Select the RSA SECURID tab and specify values for the following fields: a. Realm Name: Enter the realm name. b. Server IP: Enter the IP address of the RSA Authentication Server. c. Server Port: Default is 1812. If you aren't sure of the port, you can check on the RSA Authentication Manager Server system. i. Go to Start > Programs > RSA Security. ii. Select RSA Authentication Manager Host Mode. iii. On the Agent Host menu choose Edit Agent Host to verify the values. d. Shared Secret: Provide the same Shared Secret you configured on the RSA Authentication Manager in the Configure the RADIUS Protocol Settings steps. e. Timeout: Enter the time the Barracuda Web Application Firewall waits for a response from the RSA RADIUS Server before retransmitting the packet. f. Retries: Enter the maximum number of times the Barracuda Web Application Firewall transmits a request packet to the RSA RADIUS server. 2. Click Add to save your settings.

Bind the Service(s) on the Barracuda Web Application Firewall with the RSA SecurID Authentication Service

On the Barracuda Web Application Firewall web interface, go to the ACCESS CONTROL > Authentication page:

1. Click Edit next to the service you want to bind with the RSA SecurID Authentication Service. The Edit Authentication Policy window appears. 2. Set the Status to On. 3. Select the RSA SecurID Server Authentication Service you created above. 4. Specify values to other parameters and click Save Changes. Click the help icon if you need more information.

Configure the Authorization Policy for the Service

On the Barracuda Web Application Firewall web interface, go to the ACCESS CONTROL > Authorization page:

1. In the Add Authorization Policy section, do the following. 2. Service: Select the service. 3. Policy Name: Enter a name for the Authorization Policy. 4. Status: Set Status to On. 5. Specify values to other parameters as required. Click the help icon if you need more information. 6. Click Add to add the Authorization policy. 7. Click Edit next to the policy in the Existing Authorization Policies section to configure advanced authorization settings.

147 If you want users to authenticate using a custom login page when they attempt to access a resource protected by RSA SecurID, use the advanced authorization configuration and set Auth Not Done URL to the custom login URL.

Note:

Authorization using RSA is not possible using the RADIUS protocol when communicating with the RSA SecurID Server. Native authorization can be done via the Barracuda Web Application Firewall in this case.

Verify the Setup and Authentication Process

3. Depending on your configuration, you will be prompted to enter your username and password. If configured in Passcode mode, you will be offered a system generated PIN, or instructed to provide a PIN.

148 3.

System Generated Pin Screens

149 3.

User Generated Pin Screens

150 3.

4. To verify your login results, navigate to BASIC > Access Logs on your Barracuda Web Application Firewall and enable the Login column by selecting the Login checkbox under the Detail column.

151 How to Integrate CA SiteMinder with the Barracuda Web Application Firewall en

Overview

CA/Netegrity SiteMinder provides an infrastructure for centralized and secure policy management of websites. It uniquely identifies users before they are authenticated as named users, and manages user privileges to ensure that they access only authorized applications or operations.

Components in SiteMinder Setup

The two significant components of SiteMinder are:

Web Agents – Integrated with a standard web server or application server to enable SiteMinder to manage web applications using predefined security policies. Policy Server – Provides Policy management and AAA functions within the SiteMinder framework.

To integrate the Barracuda Web Application Firewall with CA/Netegrity SiteMinder, perform the following steps:

1. Configure the Netegrity SiteMinder Policy Server 2. Configure the Barracuda Web Application Firewall 3. Verify the Setup

Configure the Netegrity SiteMinder Policy Server

The images captured in the following steps are taken from the Netegrity SiteMinder Policy Server Version 6.0 SP4. The screens may vary depending on the version you are using.

Follow these steps on the Netegrity SiteMinder Policy Server:

1. Create an Agent in the SiteMinder Policy Server 2. Create an Agent Configuration Object 3. Create a Host Conf Object 4. Create a User Directory with All User Names to be Authenticated by SiteMinder 5. Create a Domain for the User Directory 6. Create a Realm and Associate the Agent with the Realm 7. Create Rules for the Realm 8. Create a Policy for the Realm

Create an Agent in the SiteMinder Policy Server

1. From the System tab of the Netegrity Policy Server window, right click the Agents option from the System Configuration tree and select Create Agent. The Agent Properties window appears. To create the Agent, fill in the following fields: a. Name – Enter the agent name. b. Description – Enter the description for the agent. c. Agent Type – Select SiteMinder as agent type, and then select Web Agent from the drop-down list. 2. Click Apply, and then OK. The created agent appears in the Netegrity Policy Server window.

Figure 1. Creating SiteMinder Agent.

152 Create an Agent Configuration Object

1. From the System tab of the Netegrity Policy Server window, right click the Agent Conf Objects option from the System Configuration t ree. In the right hand pane, right click ApacheDefaultSettings and select Duplicate Configuration Object (Figure 2). The Agent Configuration Object Properties window appears. Fill in the following fields: a. Name – Enter a name for the agent configuration object. b. Description – Enter a description for the agent configuration object. 2. Click Add. The Edit Parameter Dialog appears. Provide the Parameter Name: AcceptTPCookie and Value: Yes and click OK (Figure 3) . 3. Locate and select DefaultAgentName in the Configuration Values, and click Edit. 4. When the Edit Parameter Dialog appears, remove the hash (#) associated with the DefaultAgentName and enter the Name from step a. above in the Value field (Figure 4). 5. Verify the RequireCookies parameter in the Configuration Values is set to Yes for the agent. 6. Leave the remaining parameters set to their default values. Click Apply and then OK.

Figure 2. Agent Conf Object List.

153 Figure 3. Agent Configuration Object Properties.

Figure 4. Configuring Default Agent Name.

154 Create a Host Conf Object

1. From the System tab of the Netegrity Policy Server window (Figure 1), right click the Host Conf Objects option from the System Configuration tree and click the Create Host Conf Object. The Host Configuration Object Properties window appears (Figure 5). Do the following to create the host configuration object: a. Name: Enter a name for the host configuration object. b. Description: Enter a description for the host. c. Click Add. The Edit Parameter Dialog window appears. Add the following parameters and set appropriate values. For example, see Figure 5. i. EnableFailOver ii. MaxSocketsPerPort iii. MinSocketsPerPort iv. NewSocketStep v. PolicyServer vi. RequestTimeout 2. Click Apply and then OK. The created Host Config Object appears in the Netegrity Policy Server window.

Figure 5. Host Configuration Object Properties.

155 Create a User Directory with All User Names to be Authenticated by SiteMinder

1. From the System tab of the Netegrity Policy Server window (Figure 1), right click the User Directories option from the System Configuration tree and click Create User Directory. The User Directory Properties window (Figure 6) appears. Click the Directory Setup tab and do the following to configure the User Directory: a. Name: Enter a name for the user directory. b. Description: Enter a description. c. NameSpace: Select the directory where users can be authenticated. d. Server: Enter the IP Address of the NameSpace directory. SiteMinder communicates with this server to authenticate users. 2. Click the Credentials and Connection tab and configure the Administrator Credentials section: a. Select the Require Credentials check box. b. Username: Enter the Distinguished Name (DN) that can be used to query the LDAP server. c. Password: Enter the password for querying the LDAP server. d. Confirm Password: Reconfirm the password. 3. Click Apply and then OK. The created user directory appears in the Netegrity Policy Server window (Figure 7).

Figure 6. User Directory Properties.

156 Figure 7. User Directory List.

Create a Domain for the User Directory

1. From the System tab of the Netegrity Policy Server window (Figure 1), right click the Domains option from the System Configuration tr ee and click Create Domain. When the Domain Properties Dialog (Figure 9) appears, do the following: a. Name: Enter a domain name. b. Description: Enter a description for the domain. c. In the User Directories tab, select the relevant directory and click Add (Figure 8). 2. Click Apply and then OK. The created agent appears in the Netegrity Policy Server window.

157 Figure 8. Domain Properties.

Create a Realm and Associate the Agent with the Realm

Realm on the SiteMinder Policy Server is different from Realm on the Barracuda Web Application Firewall.

1. From the Domains tab of the Netegrity Policy Server window (Figure 9), right click the Realm option from the Domains tree and click Cr eate Realm. When the Realm Properties Dialog (Figure 11) appears, do the following to create the realm: a. Name: Enter a realm name. b. Description: Enter a description for the realm. 2. Enter the name of the created agent in the Agent field, or click Lookup to select it from a list. 3. Select Basic or HTML Form authentication type from the Authentication Scheme list. a. If Basic authentication is selected, the Barracuda Web Application Firewall presents the default login page for authentication. b. If HTML Form authentication is selected, specify the target URL for authentication in the Authentication Scheme Properties wi ndow (Figure 10). 4. Click OK in the Realm Properties window to associate the agent with the created realm.

Figure 9. Domains.

158 Figure 10. Authentication Scheme.

Create Rules for the Realm

Two rules needs to be configured for a realm:

Rule for Authentication Event Rule for Web Agent actions

Rule for Authentication Event:

1. From the Domains tab of the Netegrity Policy Server window (Figure 9), click the Realms option from the Domains tree. Right click on

159 1. the realm to which you want to add a rule and click Create Rule under Realm (Figure 11). When the Rule Propertieswindow appears, do the following to configure the rule: a. Name: Enter a rule name. b. Description: Enter a description for the rule. c. Select Authentication events in the Action section (Figure 12). 2. Click Apply and then OK. The created rule appears in the list of rules and realms for the bwaf-doc-realm.

Figure 11. Creating a Rule.

Figure 12. Rule Properties.

160 Rule for Web Agent Actions:

1. Follow Step 1: a and b under Rule for Authentication Event. In Step 1: c, select Web Agent actions in the Action section. 2. Select the methods for web agent (Figure 13). Click Apply and then OK.

Figure 13. Rule for Web Agent Actions.

Create a Policy for the Realm

1. From the Domain tab of the Netegrity Policy Server window, click the Policies option from the Domains tree. Right click and select Crea te Policy. When the Policies Properties window appears , do the following to configure the policy: 2. In the Users tab, click the Add/Remove button. When the Users/Groups window appears, add the desired users and click OK. The added users appear in the Policy Properties window ( Figure 14). 3. In the Rules tab, click the Add/Remove Rules button. When the Rule Items window appears, add the rules and click OK. The added rules appear in the Policy Properties window ( Figure 15). 4. Click Apply and then OK. The created policy appears in the Policy List.

Figure 14. Users.

161 Figure 15. Rules.

The Barracuda Web Application Firewall can be integrated with an external CA web agent, which can act as a cookie provider application (master application) to the slave applications configured on the Barracuda Web Application Firewall.

Configure the Barracuda Web Application Firewall

Do the following steps to configure the Barracuda Web Application Firewall with CA SiteMinder:

1. Add the SiteMinder Policy Server as an Authentication Service on the Barracuda Web Application Firewall

162 2. Bind the appropriate Service(s) with the SiteMinder Authentication Service 3. Configure the Authorization Policy for the Service

Add the SiteMinder Policy Server as an Authentication Service on the Barracuda Web Application Firewall

1. In the Barracuda Web Application Firewall web interface, go to the ACCESS CONTROL > Authentication Services page and select the SITEMINDER tab. 2. Specify values for the following fields: a. Realm Name – Enter the name of the realm where the Barracuda Web Application Firewall admins are stored. b. Server IP – Enter the IP address of the SiteMinder Policy Server used to authenticate users. c. Port – Enter the authentication port of the SiteMinder Policy Server. Port 44443 is the standard port used for SiteMinder. d. Admin – Enter the privileged username for the SiteMinder Policy Server. e. Password – Enter the privileged user password for the SiteMinder Policy Server. f. Agent Name – Enter the agent name configured in the SiteMinder Policy Server to act as the Barracuda Web Application Firewall's SiteMinder agent. Note: The specified agent name must have the following parameters set to Yes under Agent Conf Objects on the SiteMinder Policy Server: AcceptTPCookie RequireCookies g. Host Conf Object – Enter the corresponding Host Configuration Object defined on the SiteMinder Policy Server. 3. Click Add to add the SiteMinder server configuration.

When SiteMinder is initially accessed, a trusted host is generated on the SiteMinder Policy Server. It includes the Barracuda Web Application Firewall Serial Number and agent name.

Figure 16. SiteMinder Authentication Service Configuration.

Bind the appropriate Service(s) with the SiteMinder Authentication Service

1. Go to the ACCESS CONTROL > Authentication page. 2. Identify the Service you want to bind to the SiteMinder Authentication Service. 3. Click Edit next to the Service. When the Edit Authentication Policy window appears (Figure 17), do the following: 4. Set the Status to On. 5. Select the SiteMinder Authentication Service created above (Figure 16) from the list. Specify values for other parameter(s) and click Save Changes.

163 Figure 17. Authentication Policy.

Configuring Authorization Policy for the Service

1. Go to the ACCESS CONTROL > Authorization > Add Authorization Policy section. 2. Service: Select the desired service from the list. 3. Policy Name: Specify a name for the Authorization Policy. 4. Set the Status to On and specify the values for other parameter(s) as required. 5. Click Add to add the authorization policy configuration. 6. If you wish to enforce fine grained access control, click Edit next to the created policy. The Edit Authorization Policy window appears. For more detailed instructions, see Configuring Authorization Policy.

Figure 18. Authorization Policy.

If the user realm is set to HTML Form authentication type on the SiteMinder Policy Server, the Login Method on the Barracuda Web Application Firewall must be set to HTML Form.

Verify the Setup

1. Enter the restricted URL in the browser. For example, for the above configuration you would enter http://192.168.132.121/forms/ in the address bar of a web browser (Figure 19). 2. If the user realm on the SiteMinder Policy Server is set to Basic Authentication type and the Auth Not Done URL field is blank on the A CCESS CONTROL > Authorization page, the Barracuda Web Application Firewall presents the default authentication page (Figure 20 ). 3. If the user realm on the SiteMinder Policy Server is set to HTML Form authentication type, the Barracuda Web Application Firewall redirects the user to the login URL specified in the Authentication Scheme Properties window (Figure 10). 4.

164 4. Go to the BASIC > Access Logs page (Figure 21), enable the login column and verify the results.

Figure 19. Address bar.

Figure 20. Default Authentication Page.

Figure 21. Access Logs.

How to Use Client Certificates en

In this Section:

Allowing or Denying Client Certificates Client Certificate Validation Using OCSP and CRLs How to Pass Client Certificate Details to a Back-end Server

Allowing or Denying Client Certificates en The ACCESS CONTROL > Client Certificates page allows you to define allow/deny rules based on Client Certificates. These settings are not used unless Enable Client Authentication is Yes for the Service on the BASIC > Services page. For more information on service settings, see Step 3: Configuring Basic Service Settings.

165 When Client Authentication is turned on for a service, all clients are required to present a certificate to access the website. The certificate is first checked for validity. A valid certificate cannot have expired, and must be signed by a certificate authority (CA) listed under Trusted Certificates for the service. Even a valid certificate signed by a trusted CA can be rejected based on the certificate attributes. This is useful when you wish to revoke an issued valid certificate.

How it works:

Each Allow/Deny rule has the following important attributes:

A sequence number specifying the order in which to evaluate the rule. A set of attribute matches (like Certificate Serial number). The attribute can either be a wildcard match (*, to indicate match any value), or it can be a specific value, matching the certificate's corresponding attribute exactly. An action to take when the presented client certificate matches this rule.

When a request is received, the Client certificate is compared to all Allow/Deny rules in sequence number order, starting from the lowest sequence number. Each attribute in the rule is compared, and if all attributes match a rule, the corresponding action (Allow or Deny) is taken and no further rules are compared.

When no rule matches the Client Certificate in the request, the request is allowed by default.

To allow only requests whose Client Certificates match a rule, create a Deny rule with a high sequence number (10000, for example) which matches all rules (has * for all attributes) and the action Deny. Every request with a client certificate which fails to match a rule will be denied. Each allowed certificate must have a corresponding Allow rule with a lower sequence number.

If you create a high sequence number Deny rule to deny all except explicitly allowed Certificates, a request will be allowed only if its Certificate and all Certificates in its chain match an Allow Rule. If its intermediate or Trusted Certificate does not match any rule, then the request will be denied.

Complex rules can be built using Allow/Deny rules. For example, to deny all certificates from the Sales department except one that is identified by its serial number, create the following two rules:

Sequence = 1; Action = Allow; Organizational Unit = Sales; Serial Number = 12345 Sequence = 2; Action = Deny; Organizational Unit = Sales

While complex rules can be built if needed, the recommended configuration allows all certificates signed by a trusted CA and uses the Allow/Deny list only to revoke access for issued certificates that are no longer valid. The Certificate serial number can uniquely identify a Certificate issued by a single CA in the event that it must be revoked. The Common Name can also be used to identify a revoked Certificate. Configuring Allow/Deny Certificate Rules

Detailed instructions for configuring Allow/Deny Certificate rules are available on the ACCESS CONTROL > Client Certificates page by clicking Help on that page.

In order for a certificate to be allowed via an Allow Rule, ensure that Allow Rules also exist for all Certificates in its chain. If the Certificate itself matches an Allow Rule, but its intermediate or Trusted Certificate does not match any rule, then the request will be denied.

Client Certificate Validation Using OCSP and CRLs en The Barracuda Web Application Firewall supports Online Certificate Status Protocol (OCSP) and Certificate Revocation Lists (CRLs) to determine the current status of clients' digital certificates. SSL connections from clients can be allowed or blocked based on the status of the client certificate presented to the Barracuda Web Application Firewall, which is maintained externally by a certificate management system.

OCSP Validation CRL Validation

The Barracuda Web Application Firewall connects to the certificate The certificate is verified using the downloaded CRL file. management system to verify the current status of a client certificate.

OCSP provides current revocation status information for certificates. Certificate Revocation Lists (CRLs) provide periodically updated certificate status.

Client Certificate Validation using OCSP

166 When a client attempts to access a server over an SSL connection that requires client certificate, an OCSP status request for the client certificate is sent to an OCSP Responder. The OCSP Responder determines whether the status request contains the information required to identify the certificate and then returns a signed response message indicating one of the following:

"GOOD" a positive response indicating that the certificate has not been revoked. "REVOKED" a negative response indicating that the certificate has been revoked. "UNKNOWN" indication that the OCSP Responder has no information about the requested certificate.

For any error or failure, the Responder may return an unsigned message indicating a failed communication, logged under System Logs. Errors can occur because of a malformed request, an internal error, or an unauthorized request. To view system logs, navigate to the ADVANCED > System Logs page. If you want system events sent to the syslog servers, configure one or more (maximum of three) syslog servers using Add Syslog Server on the ADVANCED > Export Logs > Syslog section. For more information on configuring syslog, see How to Configure Syslog and other Logs.

Enforce Client Certificate must be set to Yes for a service on the BASIC > Services page if you want to authenticate client certificates using OCSP.

Configuring OCSP Validation

To enable OCSP validation, do the following:

1. Go to the ACCESS CONTROL > Client Certificates page. 2. In the Client Certificate Validation - OCSP section, identify the Service for which you want to enable client certificate validation using OCSP and click Edit next to that Service. The Client Certificate Validation - OCSP window appears. 3. Specify values for the following fields: a. Enabled – Set to Yes to enable OCSP validation. b. OCSP Responder URL – Specify the OCSP Responder URL. This is the URL issued by the trusted Certificate Authority (CA) where the Barracuda Web Application Firewall will send OCSP requests. Both HTTP and HTTPS (SSL/TLS) URLs can be specified. For example, http://ocsp.example.com c. Certificate – Click the drop-down list and select a certificate to verify the signature on the OCSP response. 4. Click Save Changes.

Client Certificate Validation using CRLs

A CRL file contains a list of client certificates that while not yet expired are revoked by the Certificate Authority (CA) that issued the certificate. The certificate might be revoked for various reasons, such as the certificate was compromised by an unauthorized user, or the user no longer works for that company.

When a CRL is added, the CRL file is downloaded and stored locally on the Barracuda Web Application Firewall. The CRL file can be updated periodically (Daily, Weekly or Monthly) by enabling the CRL Auto Update option. If CRL validation is enabled and a client attempts to access a server with a certificate, the Barracuda Web Application Firewall validates the certificate using the downloaded CRL file. If the certificate presented by the client matches a revoked client certificate in the CRL, the SSL connection from the client is dropped. Otherwise, the connection is established and the client is allowed to access the requested website.

The Barracuda Web Application Firewall uses the default gateway or a static route to access the server hosting the CRL.

Configuring CRL Validation

To enable CRL validation, do the following:

1. Go to the ACCESS CONTROL > Client Certificates page. 2. In the Client Certificate Validation - CRL section, identify the Service for which you want to enable client certificate validation using CRLs and click Add next to that Service. The Add CRL window appears. 3. Specify values for the following fields: a. CRL Name – Specify the name of the CRL file. b. Enable CRL – Select Yes to use this CRL file to validate the client certificates. c. CRL URL – Specify the location of the CRL file that needs to be downloaded. d. CRL Auto Update – Select Yes if you wish to automatically update the CRL file (Daily, Weekly or Monthly). e. Number of Retries – Specify the maximum number of times the Barracuda Web Application Firewall can attempt to download the CRL file from the specified path before giving up. 4. Click Save Changes.

167 How to Pass Client Certificate Details to a Back-end Server en This article applies to the Barracuda Web Application Firewall 460 and above.

You can configure the Barracuda Web Application Firewall to pass information from a client to the back-end server through the Barracuda Web Application Firewall. Using this feature web servers can access client authentication information like Client Certificate parameters or authenticated username and password.

On the Barracuda Web Application Firewall, you can add client information to a request by configuring a Request Rewrite. Headers can be inserted into the request, or existing headers can be rewritten or deleted before passing the request to the web server, which can then extract the added information. The Barracuda Web Application Firewall provides macros you can use to communicate request parameters like client certificate details or authenticated user information through headers.

Configuring Request Rewrite to Pass Client Information to a Web Application

To configure a request rewrite rule, perform the following steps:

1. Go to the WEBSITES > Web Site Translations page, and in the HTTP Request Rewrite section specify values for the following fields: a. Rule Name – Enter a name for the request rewrite rule. b. Sequence Number - Set the sequence number for the request rewrite policy. The sequence number determines the order of execution for multiple configured policies from highest (1) to lowest (1500). c. Action - Select the action. To modify client information sent to the web application, the request rewrite action should be set to In sert Header or Rewrite Header. d. Header Name – Enter the relevant Header Name, for example X-Forwarded-For. e. Old Value – Enter the initial request header to be rewritten if the Action is Rewrite Header. An asterisk (*) rewrites all named headers, or specify the value or expression to be rewritten. f. Rewrite Value – Enter the new value of the header to be rewritten when the Action is set to Insert Header or Rewrite Header. Use the macros listed below to specify parameters from the client. When rewriting a header you can specify one or more fields using the separators such as colon (:), semicolon (;), space ( ) and comma (,). In Rewrite Value, the fields can be defined for example: "Name=abc_cookie; Domain=example.com:Path=/". The rewrite-value supports substring addressing of matches, i.e. the matching substrings can be referenced using $1,$2,...$n. The following macros are supported for rewrite values: $X509_ORGANIZATION, $X509_LOCALITY, $X509_CN, $X509_COUNTRY, $X509_OU,$X509_STATE, $X509_EM AIL, $X509_SUBJECT, $X509_WHOLE: Fields in the X509 client certificate when client authentication is On. $SRC_ADDR: The client IP from which the request originated. $DST_ADDR: The destination address. $URI: URI. $AUTH_USER: Username of the authenticating user. $AUTH_PASSWD: Password of the authenticating user. $AUTH_GROUPS: Group associated to the authenticating user. g. Rewrite Condition – Set the condition under which a rewrite should occur. An asterisk (*) indicates there are no conditions (applies to all). Details on the format of the Rewrite Condition are explained below in Rewrite Condition Format. 2. Click Add to add the above settings.

Note: When multiple policies are configured, the request continues to be processed by other (higher sequence number) policies. If you wish to stop processing after a particular rule is matched, click Edit next to the rule and set Continue Processing to No. Rewrite Condition Format

The request Rewrite Condition specifies when a rewrite should occur. The Rewrite Condition is made up of expressions combining Request Rewrite Tokens and Operations on those tokens. These expressions can then be joined with each other using logical or (or, OR, ||) or logical and (and, AND, &&). Examples of Rewrite Conditions: (Header User-Agent co mozilla) , (URI rco /abc*html), (Client-IP eq 10.0.0.1)&&(Method eq POST). An asterisk indicates there are no conditions for rewrite, so the rewrite is done in every case.

RSA SecurID Implementation en

Partner Information

Product Information

168 Partner Name Barracuda Networks

Website —www.barracudanetworks.com

Product Name Barracuda Web Application Firewall

Version & Platform x60 Series

Product Description The Barracuda Web Application Firewall protects web applications and web services from malicious attacks, and can also increase the performance and scalability of these applications. The Barracuda Web Application Firewall offers every capability needed to deliver, secure and manage enterprise web applications from a single appliance through an intuitive, real-time user interface.

Product Category Network Firewalls

Solution Summary

The Barracuda Web Application Firewall protects your website from attackers leveraging protocol or application vulnerabilities to instigate unauthorized access, data theft, denial of service (DoS), or defacement of your website.

The Barracuda Web Application Firewall provides complete protection of web applications and enforces policies for both internal and external data security standards, such as the Payment Card Industry Data Security Standard (PCI DSS). In addition, the Barracuda Web Application Firewall features a number of traffic management capabilities to improve the performance, scalability and manageability of the most modern and demanding data center infrastructures.

Partner Integration Overview

Authentication Methods Supported RADIUS

RSA SecurID API Version N/A

RSA Authentication Manager Replica Support N/A

Secondary RADIUS Server Support Yes (1)

RSA Authentication Agent Host Type for 7.1 Standard Agent

RSA SecurID User Specification Designated Users

RSA SecurID Protection of Administrative Users No

RSA Software Token and RSA SecurID 800 Automation No

Authentication Agent Configuration

169 All Authentication Agent types for 7.1 should be set to Standard Agent.

To facilitate communication between the Barracuda Web Application Firewall and the RSA Authentication Manager / RSA SecurID Appliance, an Authentication Agent Host record must be added to the RSA Authentication Manager database. The Authentication Agent Host record identifies the Barracuda Web Application Firewall within the RSA Authentication Manager database and contains information about communication and encryption. You will also need to configure a RADIUS client.

To create the Agent Host record, you will need the following information.

Hostname IP Addresses for all network interfaces

When adding the Agent Host Record, you should configure the Barracuda Web Application Firewall as Standard Agent. RSA Authentication Manager uses this setting to determine how to communicate with the Barracuda Web Application Firewall.

To create the RADIUS client record, you will need the following information.

Hostname IP Addresses for all network interfaces RADIUS Secret

Hostnames within the RSA Authentication Manager / RSA SecurID Appliance must resolve to valid IP addresses on the local network.

Please refer to the appropriate RSA Security documentation for additional information about Creating, Modifying and Managing Agent Host, and RADIUS client records.

RSA SecurID Files

RSA SecurID Authentication Files

Files

aceclnt.dll

sdmsg.dll

sdconf.rec

Node Secret (securid)

sdstatus.12

sdopts.rec

Partner Product Configuration

Before You Begin

This section provides instructions for integrating partner products with RSA SecurID Authentication. This document does not necessarily suggest optimum installations or configurations.

To fully benefit, you should have a working knowledge of all products involved, and the ability to perform the tasks outlined in this section. Administrators should rely on product documentation for all relevant products to properly install the required components.

You should verify all vendor products/components are installed and working before proceeding.

Configuring the Barracuda Web Application Firewall for SecurID Authentication

The following configuration steps enable the Barracuda Web Application Firewall to communicate via RADIUS protocol with the RSA Authentication Manager to authenticate users:

Step 1: Create an HTTP Service on the Barracuda Web Application Firewall

1. Log on to the Barracuda Web Application Firewall using a supported web browser by navigating to the web interface on port 443

170 1.

(HTTPS). 2. From the BASIC tab, select the Services page. 3. In the Add New Service section select HTTP as the Type of Service, and fill in the other required information. Click Help on the BASIC > Services page for an explanation of other settings on this page. 4. Click Add to add the new Service.

Figure 1. Creating a New Service

Step 2: Add the RSA SecurID server as an Authentication Service on the Barracuda Web Application Firewall

The RSA Authentication Manager server running RADIUS is called an RSA RADIUS server in the Barracuda Web Application Firewall web interface

1. From the ACCESS CONTROL tab, select the Authentication Services page. 2. Select RSA SecurID under the New Authentication Service section. See Figure 2. 3. For the Server IP, specify the IP address of the RSA RADIUS server used for authenticating users. 4. The Server Port should be the port number of the RSA RADIUS server. The standard port number used for RADIUS is 1812 or 1645. 5. Click Help from the RSA SECURID tab on that page to get details about other field values. 6. Click Add to add the server.

Figure 2. Configure RSA SECURID Authentication Service

Step 3: Bind the appropriate Service(s) on the Barracuda Web Application Firewall with the RSA SecurID Authentication Service

1. From the ACCESS CONTROL tab, select the Authentication page. 2. Under the Authentication Policies section, click Edit next to the Service requiring RSA SecurID authentication. 3. The Edit Authentication Policy window appears, specify values for the following fields: a. Set the Status to On to enable authentication for this Service. b. Select the newly created RSA Authentication Service from the Authentication Service drop-down list. c. Specify values for other parameter(s) as required. For more information on how to configure an authentication policy, click the H elp button. See Figure 4. 4. Click Save Changes.

Figure 3. Authentication Page

171 Figure 4. Configuring Authentication Policy

Step 4: Configure the Authorization Policy for the Service

1. From the ACCESS CONTROL tab, select the Authorization page Specify values for the following fields: a. Service – Select the Service bound to the newly created RSA Authentication Service. b. Policy Name – Specify a name for the Authorization Policy. c. Set the Status to On, and specify values for other parameter(s) as required. For more information on how to configure an authorization policy, click the Help button. 2. Click Add to add the Authorization policy configuration.

Figure 5. Configuring Authorization Policy

172 When there is an attempt to access a protected resource, the Barracuda Web Application Firewall presents a login page to authenticate the user. If URL Match is configured as /*, a login page displays for any request sent to the Service.

End-User Experience

Using a supported web browser, navigate to the configured URL for the Barracuda Web Application Firewall. To receive authorization to view the protected resource, a user must authenticate using RSA SecurID. To begin the authentication process, the user must enter a User Name and Password on the Login form.

The user is then presented with a New PIN challenge.

The user is challenged again to confirm the PIN.

173 When the new PIN is accepted, after entering the new passcode, the user is successfully authenticated and forwarded along to the configured URL. For more information on how to configure RSA Authentication Manager and to verify the setup, see How to Integrate RSA SecurID with the Barracuda Web Application Firewall.

Certification Checklist for RSA Authentication Manager 7.x

How to Configure SMS Passcode Authentication Service en The Barracuda Web Application Firewall supports SMS Passcode’s advanced two factor authentication solution using the mobile phone SMS network. SMS Passcode provides strong authentication security as the passcodes are challenge based, session based and time constrained. Passcode’s are randomly generated and sent via SMS to your mobile phone or to your configured email address.

Configuring the Barracuda Web Application Firewall

1. Create a HTTP/HTTPS Service on the BASIC > Services page. 2.

174 2. Create a RADIUS authentication service on the ACCESS CONTROL > Authentication Services page. Ensure that the Server IP Address is pointing to the Windows RADIUS server that SMS Passcode uses. 3. Navigate to the ACCESS CONTROL > Authentication page, click Edit next to the Service to enable authentication policy and to choose the RADIUS authentication service with SMS Passcode from the Authentication Service drop-down list. 4. If you wish to display a custom challenge page, configure the custom URL and query string fields in the authentication policy. Ensure that your challenge page receives these query string fields and displays the prompt, and includes the user name in its login form (usually as a hidden input). For more information, see How to Set Up a Custom Challenge Page for Authentication. 5. Configure the authorization policy as desired.

Verify the Setup and Authentication Process

1. Navigate to the restricted URL by entering the IP address into the address bar of your web browser. 2. The default authentication page, or the custom login page for authentication if you have configured it on ACCESS CONTROL > Authorization, will be presented. For information on creating a custom login page, see How to Set Up a Custom Login Page for Authentication. You will be prompted to enter your username and password. Enter username and password, click Login. 3. Now, the user is redirected to the default challenge page or custom challenge URL (if configured), and a passcode is sent via SMS to the user’s phone. 4. Enter the passcode and click Login. 5. Now, the user should see the originally requested page.

How to Set Up a Custom Challenge Page for Authentication

How to Set Up a Custom Login Page for Authentication How to Set Up a Custom Challenge Page for Authentication en Setting up a custom challenge page is a three step process:

1. Create a custom challenge page. 2. Deploy the created custom challenge page on your web server. 3. Configure the Barracuda Web Application Firewall to use the custom challenge page.

For the following example, we assume:

A back-end server at 192.168.128.10 needs access restricted to authenticated users. Web application resources residing at "http://192.1 68.128.10/secure" require users to authenticate before gaining access. User authentication uses an SMS Passcode server. Service-1 (10.10.10.2:80) is configured on the Barracuda Web Application Firewall to secure the access to the web application, with 192.168.128.10:80 configured as the server.

Step 1 - Create a custom challenge page

To create a custom challenge page, use a script like CGI Perl, PHP or Java that the back-end server supports. In this example we use a server supported PHP script to create the custom challenge page "challenge.php". It must contain the following:

Form ID = nclogin Name = nclogin Action = "/nclogin.submit" Method = POST Form Fields should include "Challenge User Field" and "Challenge Prompt Field". Note that these field names needs to be configured on the ACCESS CONTROL > Authentication page by editing a Service. For more information, see Configuring the Barracuda Web Application Firewall to use the custom challenge page.

Step 2 - Deploying the created custom page on your web server

To use the "challenge.php" file, deploy it on your web server. For example:

The IP address of the web server is 192.168.128.10 And the “challenge.php” is available by accessing "http://192.168.128.10/challenge.php"

Step 3 - Configuring the Barracuda Web Application Firewall to use the custom challenge page

175 Once the custom challenge page is deployed on your web server, configure the Barracuda Web Application Firewall to use the custom challenge page by doing the following:

1. Configure Authentication Service – Specify the authentication database server (RADIUS) which will be used to authenticate the user's credential. Ensure the IP address of the server is pointing to the SMS Passcode server. See How to Configure Authentication and Access Control (AAA). 2. Configure Authentication Policy – Create an authentication policy for the Service you want to secure. To do this, click Edit next to the relevant Service (Service-1 in this example) on the ACCESS CONTROL > Authentication page. In the Edit Authentication Policy win dow, configure the following: a. Set Status to On. b. Select the Authentication Service from the drop-down list. Note that this is the authentication service created in Step 3 (1). c. Specify values for the following fields: i. Auth Challenge URL – Enter the URL where a user is redirected if the authentication service requires additional credentials such as Passcode or PIN. In this example, it would be “/challenge.php”.

The Auth Challenge URL should be added to the allow list in Global ACLs on the SECURITY POLICIES > Global ACLs page. See Steps to Configure a Global ACL Rule.

ii. Challenge User Field – Enter the name of the query string field passed to the challenge URL which contains the challenged user's username. By default, the value is set to challenge_user. iii. Challenge Prompt Field – Enter the name of the query string field passed to the challenge URL which contains the prompt string received in a RADIUS challenge message. By default, the value is set to challenge_prompt. d. Specify appropriate values for other parameters and click Add. For more information, click Help in the web interface. 3. Configure Authorization Policy – Create an authorization policy indicating which resources become accessible after a successful authentication on the ACCESS CONTROL > Authorization page using the following steps: a. On the ACCESS CONTROL > Authorization page, in the Add Authorization Policy section, specify values for the following: i. Service – Select the relevant service (Service-1 in the example) from the drop-down list. ii. Policy Name – Enter a name for the authorization policy. Example: secure.access iii. URL Match – Enter the URL of the secured part of the web application. In this example the URL is: /secure/ iv. Login Method – Select HTML Form.

The Auth Challenge URL does not support HTTP Basic Authentication.

b. Click Add.

Custom challenge URL is supported ONLY for two factor authentication (SMS Passcode and RSA SecurID).

Steps to Configure a Global ACL Rule

1. Go to the SECURITY POLICIES > Global ACLs page. 2. Select the policy associated with the Service from the Policy Name drop-down list. 3. In the Create Global ACL section, specify values for the following fields: a. URL ACL Name – Enter a name for the URL ACL. b. URL Match – Enter the auth challenge URL, as per the above example it is /challenge.php. c. Action – Set to Allow. 4. Specify values for other parameters as required and click Add.

How to Configure SMS Passcode Authentication Service Traffic Management en The Barracuda Web Application Firewall provides load balancing, caching, and compression of website traffic to improve website performance. It can load balance all TCP traffic in proxy deployments, and using Content Rules can implement Load Balancing, Caching, and Compression of HTTP application layer data for any deployment.

When the Barracuda Web Application Firewall is in proxy mode, all incoming TCP traffic can be distributed to balance the processing load across multiple back-end servers. Persistence is maintained for requests from the same client, and server health is monitored, so requests are served as

176 efficiently as possible.

In addition, for HTTP data, content rules can be used to route requests to servers optimized to handle specific content types. This layer 7 load balancing is available only for HTTP data, and can be used with any deployment configuration of the Barracuda Web Application Firewall. Content rules also provide caching or compression options for matching HTTP data, which can decrease data processing demands on the website.

In this Section

Load Balancing Overview Configuring Load Balancing for a Service Configuring Server Settings How to Add a Real Server Configuring Caching and Compression How to Configure Rate Control Using Connection Pooling: How and Why Content Routing How to Add a Content Rule How to Redirect Traffic to a Different Back-end Server Based on a URL Pattern Content Rewriting How to Allow Internet Access for the Back-end Servers in Two-Arm Proxy Mode Load Balancing Overview en The "Load Balancing" feature is available only in the Barracuda Web Application Firewall 460 and above.

In this section

en In this section Monitoring the Health of the Server In-Band Health Checks Out-Of-Band Health Checks Application Layer Health Check Configuring a Backup Server Content Rule

A load balancer is a networking device that distributes traffic across multiple back-end servers in order to improve website response times. The Barracuda Web Application Firewall can act as a stand-alone load balancer or work in conjunction with other load balancers. Situated in front of back-end servers, it distributes incoming traffic across the servers using the configured algorithm. The Barracuda Web Application Firewall supports load balancing of all types of applications. Load balancing ensures that subsequent requests from the same IP address will be routed to the same back-end server as the initial request. This guarantee of persistence requires an awareness of server health so subsequent requests are not routed to a server which is no longer responding. The Barracuda Web Application Firewall can monitor server health by tracking server responses to actual requests and marking the server as out-of-service when errors exceed a user configured threshold. In addition, the Barracuda Web Application Firewall can perform out-of-band health checks, requests created and sent to a server at configured time intervals to verify its health.

The Barracuda Web Application Firewall includes the following load-balancing features:

Distributes traffic requests among back-end servers according to a user-configured algorithm. Automatically identifies server status to ensure appropriate traffic routing. Adds and removes servers without interrupting network traffic. Provides persistence support allowing a user to maintain connection integrity between client and web service. Provides for configuration of a backup server, used only when all other servers being load balanced are out-of-service.

Load balancing can be configured at two levels:

General (all TCP Traffic--layer 4) Content Rule (HTTP traffic only--layer 7)

The general policy is configured for a service and applies to all TCP requests to the service, while the content rule policy applies to HTTP requests matching the configured content rule only. The general and content rule configuration procedures are identical. There are three steps to configure load balancing on a Barracuda Web Application Firewall:

177 Configure the load balancing algorithm and other general parameters. Configure a persistence method to maintain the integrity of stored state information. Configure a failover method to handle requests for a server which is down.

General load balancing, routing requests to back-end servers based on a user configured algorithm, is configured for a service. From BASIC > Services, choose Edit under Options for the service. Choose the Algorithm, Persistence Method, and Failover Method. The algorithm determines where the first request from a source IP address is routed. Future requests from the same client will be routed to the same server according to the configured Persistence method. Failover Method only applies when the persisted server is “out-of-service”. For detailed instructions to configure load balancing, see online help.

Monitoring the Health of the Server

Load balancing distributes requests to servers, sending subsequent requests from the same client to the same back-end server. To prevent requests from being sent to an unresponsive server, the health of all back-end servers must be monitored. The Barracuda Web Application Firewall monitors server health three ways: using In-Band, Out-of-Band, and Application layer health checks. In-Band and Application Layer Health Checks can only change a server status to out-of-service from an online state; but Out-Of-Band Health Checks, which perform periodic tests of all servers, allow a server state to change from out-of-service to online when the health checks succeed.

In-Band and Application Layer Health Checks are performed only if the parameter Enable OOB Health Checks is set to Yes for Out-Of-Band Health Checks. This prevents Servers from being marked out-of-service indefinitely. Disabling Out-of-Band Health Checks disables monitoring server health.

For detailed configuration instructions, see the online help by clicking Edit for the server on the BASIC > Services page.

In-Band Health Checks

In-Band Health checks monitor a server’s connections and response to user traffic. The In-Band Health Check policy specifies layer 4 and layer 7 error thresholds. The server connections and responses are monitored for errors. When error counts exceed configured thresholds, the server is marked out-of-service.

Servers marked out-of-service no longer receive requests. Traffic is routed to other load balanced servers if possible. When no healthy server is available to serve a request, an error response is sent to the client.

In-band monitoring is enabled by default, and default parameters are provided. The settings can be modified if desired. In-band monitoring is disabled if Out-of-Band Health Checks are disabled.

Out-Of-Band Health Checks

The Barracuda Web Application Firewall also monitors server health by sending requests at configured intervals which are independent of incoming traffic. Out-of-Band health checks performed in addition to user traffic connections. The Out-of-Band Health Check parameters specify layer 4 and layer 7 server monitoring.

If a server health check fails, the server is marked as out-of-service. Out-of-service servers continue to be sent data based on Out-Of-Band Health Check configuration, so when a health check succeeds, the server's status reverts to in-service. An out-of-service server can only be restored to service using out-of-band health checks because in-band checks require user traffic to be sent to the server, and user traffic isn’t sent to an out-of-service server.

A server marked out-of service will revert to in-service as soon as Out-of-Band Health Checks succeed. These checks are performed at configured intervals (by default 10 seconds).

Application Layer Health Check

Application Layer Health Check sends an HTTP request to verify the server is responding correctly. A correct response verifies the server is healthy. Otherwise, the server is marked as out-of-service. The Application Layer Health Check settings specify the HTTP request type (URL, Method, Headers), and healthy response (Status Code, Match Content String).

Configuring a Backup Server

An optional backup web server can be configured to be used only when all other load balanced servers fail. For detailed instructions refer to online help.

178 Content Rule

A website can be further partitioned based on content in the HTTP requests by creating a content rule. A content rule is a collection of one or more rules that specify a pattern in the URL or header fields of the request. For requests matching the rule, the configured content rule policies are applied. Content rules allow management of HTTP traffic flow for a web application.

Configuring a content rule requires the following steps:

Create the content rule for the target web service. Add one or more rules to define match criteria for this content rule. Configure the policies to apply to matching requests.

You can configure settings for a content rule which apply to three traffic management techniques:

Load Balancing (only in Proxy mode) - Sets load balancing policy for the content rule. By default, the parent Web service's load balancing policy is copied into the content rule. Load balancing is tied to a server group, and the Content Rule configuration specifies which server group to use. This allows distribution of requests based on the content type. Caching - Sets caching policy for the content rule (refer to Configuring Caching and Compression). This allows selective caching based on the content type. Compression - Sets compression policy for the content rule. This improves the response time for clients accessing the Web service by compressing Web pages with the specific content type.

Rules are evaluated based on a key comprised of the URL, host, and an optional extended match rule in specified sequential order. In most cases, only host and URL are used to specify a rule. The Barracuda Web Application Firewall optimizes the search for the most common case by implementing a parallel search algorithm on all rules. The matching is determined by a best match algorithm where the best match is the rule with the longest matching host and URL keys. For more information refer to Extended Match and Condition Expressions.

Example: Content Rule for Images

Assume that requests to a service are normally served by servers S1, S2, and S3. To direct all requests for image content from the images directory in the Web server to a different set of servers, say S4 and S5, do the following:

Use Rule for the Service on the BASIC > SERVICES > Services section to create a content rule for requests matching the URL /images/ * as shown below: (For detailed instructions on creating a content rule, refer to online help).

Add one or more servers for this content rule (S4 and S5 in this case) using the Server option under Add. Adding servers for content rules is similar to adding servers for a service. Any future requests matching /images/* will be now directed to one of the servers added to this content rule (S4, S5) instead of being sent to the servers associated with the parent service (S1, S2, S3). By default, the load balancing policy of the parent service is inherited by newly added content groups. To customize the load balancing policy used by the servers for this content rule, Edit the content Rule.

To configure caching for a content rule, create caching rules specifying file extensions and size restrictions for objects that should be cached on the Barracuda Web Application Firewall. These objects will be retrieved from the cache directly to serve future requests, rather than fetching the object content from the back-end servers.

Create compression rules for a content rule, specifying what response content should be compressed by the Barracuda Web Application Firewall to improve available network bandwidth. For more information on configuring compression, see Configuring Caching and Compression.

Configuring Load Balancing for a Service en

179 A load balancing policy allows the Service to distribute the traffic to an appropriate server based on the configured load balancing algorithm. To configure the load balancing policy for a Service, navigate to the BASIC > Services page. Identify the Service in the Services list that you want to configure to load balance, and click Edit next to it. Specify values for the following fields in the Load Balance section:

a. Algorithm – Select the algorithm to be used to distribute incoming requests for the Service. i. Round Robin – Incoming requests are equally distributed among all servers. ii. Weighted Round Robin – Requests are distributed in proportion to server weights which you define when you Add a Server . A server with a higher weight will be sent proportionally more requests. For information on configuring a server, see How to Add a Real Server. iii. Least Requests – Load balances the incoming requests based on the number of outstanding requests to the servers. The requests are distributed to the server with the fewest outstanding requests. b. Persistence Method – Select the Persistence Method to be used to maintain the connection between a client and the first server that it connects to, even for load balanced traffic. Persistence is required when the server needs to maintain state information about every client (for example, login information). i. None – No persistence configured, all requests, regardless of whether they originate from the same client or different are load balanced according to the algorithm. ii. Source IP – Based on the Source IP address of the client, the request is routed to a server. The Source IP Mask defines how to group the client IP addresses. The first request from a group is load balanced and routed to a server. Subsequent requests from the same group are routed to the same server to which the first request was routed. iii. Cookie Insert – The Barracuda Web Application Firewall routes the first request from a client to one of the servers based on the load balancing algorithm. At the same time, it inserts a cookie to identify the client. Subsequent requests from the client include the persistence cookie, so they can be routed to the same server as the first request was. iv. Cookie Passive – Similar to Cookie Insert, only the server inserts the cookie if needed. This provides additional optimization because requests are load-balanced normally unless there is a requirement to persist a session, which is indicated by the presence of a cookie. v. HTTP Header – All incoming HTTP requests are directed to the same Real Server based on the value of the header specified in the Header Name field. The application (e.g. Microsoft Exchange) specifies the header name. Header Name is case-sensitive. vi. URL Parameter – All incoming HTTP requests are directed to the same Real Server based on the value of the parameter specified in the Parameter Name field. Parameter Name is case-sensitive c. Failover Method– Select the method to handle persistent client requests when the server that handled the original request is out-of-service. i. Load Balance – The requests are load balanced between the "alive" servers. ii. Error – Sends out "503 service unavailable" error message. This method is not supported for the persistence method S ource IP. d. Source IP Netmask – Enter a subnet mask to make subsequent connections from clients, from the same subnet go to the same Real Server. 255.255.255.255 means only the client IP address matches. e. Persistence Cookie Name – The name of the cookie that will be used for persistence. This is used when Persistence Method i s set to Cookie Insert. f. Persistence Cookie Path – Enter the path property of the persistency cookie. g. Persistence Cookie Domain – Enter the domain name of the server of a persistency cookie. h. Cookie Age – Specify the expiry age of the persistence cookie in minutes. This ensures sessions are no longer persisted after this interval when "Cookie passive" or "Cookie Insert" is chosen as the Persistence Method. i. Persistence Idle Timeout – Sets the maximum idle time (in seconds) for a persistent connection. A client is directed to the same Real Server unless the connection is inactive for more than the specified number of seconds. Example: Consider a Service is configured with two Real Servers, and Persistence Idle Timeout is set to 1200 seconds (20 minutes). When a client sends a request to this Service, it is directed to the first available Real Server based on the configured load balancing Algorithm. All subsequent requests are forwarded to the same Real Server. If no request is sent for a time exceeding Persistence Idle Timeout, then new requests from the client may be forwarded to either Real Server. j. Header Name – The name of the header for which the value needs to be checked in the HTTP requests. k. Parameter Name – The name of the parameter for which the value needs to be checked in the URL.

Configuring Server Settings en A server hosts the actual content for a Service. You can configure one or more servers to load balance the incoming web traffic. For information on how to add a server, see How to Add a Real Server. The added server is displayed next to the Service or Rule Group with the default security settings in the Services section on the BASIC > Services page. To modify the server security settings, click Edit next to the server. The Server Configuration window appears with the following sections:

Server (Basic Configuration)

180 SSL (Server) In Band Health Checks Out of Band Health Checks Application Layer Health Checks Connection Pooling

Server (Basic Configuration)

Edit the basic configuration settings of a server using the Server (Basic Configuration) section.

a. Server Name – Enter a name to identify the server. b. IP Address – Enter the IP address of the server hosting the Service. c. Port – Enter the port on which the Service resides. d. Status – Select the status for the server from the drop-down list to handle the requests. i. In Service – Denotes the requests can be forwarded to the server. ii. Out of Service All – Denotes requests should not be forwarded to the server. Select this if you wish to terminate all connections to the server immediately. iii. Out of Service Maintenance – Denotes requests should not be forwarded to the server. Select this if you wish to take a server out of service for maintenance or software upgrade, etc. In this case, existing connections are terminated only after the requests in progress are completed. iv. Out of Service Sticky – This applies only when a Persistence Method is selected using Load Balance on the Edit Service page. If selected, persistent client(s) requests are forwarded to the server. e. Backup Server – Set to Yes to designate this server as a last resort server to be used when all other servers configured under the Service fail. f. Weight – Assign a weight for the server. The value indicates the capacity of the server, and is applicable only when the Load Balancing Algorithm is set to Weighted Round Robin (WRR). Requests are passed to servers in the proportion indicated by Weight, so the server with the highest Weighted Round Robin (WRR) weight will get the most requests. For example, consider two servers (server1 with Weight 50 and server2 with Weight 100) for a Service. Server1 will get half the number of requests that server2 gets.

SSL for Servers

To configure SSL for communication between the Barracuda Web Application Firewall and the back-end servers, refer to Configuring SSL for Services and Servers.

In Band Health Checks

Set the threshold to monitor health of the server. In In-band-health monitoring, the Barracuda Web Application Firewall checks the server connections and responses for any network issue/error that is preventing a client from reaching the intended server. If the server error responses exceed the specified number, the server is marked as out-of-service. Servers in the out-of-service state are disregarded as potential servers for serving content. If other servers are defined to load balance requests, traffic will be routed to the other servers. If only one server is defined, and it is in the out-of-service state, it will result in an error response to the browser.

By default, the counter is reset every 1024 requests. If the number of errors exceeds the respective setting (Max HTTP Errors, Max Refused, Max Timeout Failures or Max Other Failures) within the 1024 requests, probing stops and the server is marked as out-of-service.

If Enable OOB Health Checks is set to No in the Out Of Band Health Checks section, the server remains in the out-of-service state and no requests are sent to that server. If set to Yes, the server remains in out-of-service state until the next probe is sent after the specified time interval, and a valid response is received from the server.

a. Max HTTP Errors – Set the maximum number of HTTP error responses to be allowed per 1024 requests before marking the server as out-of-service b. Max Refused – Set the maximum number of connection refused errors to be allowed per 1024 connections before marking the server as out-of-service. c. Max Timeout Failures – Set the maximum number of connection time-out errors to be allowed per 1024 connections before marking the server as out-of-service. d. Max Other Failures – Set the maximum number of other errors to be allowed per 1024 connections before marking the server as out-of-service.

Out of Band Health Checks

Out-of-band health check is performed at Layer 4 and Layer 7. A periodic probe is sent to check the health of the server. If the server health

181 check fails, the server is marked as out-of-service. The server continues to be monitored, so if the server health check succeeds, the server's status reverts to in-service. This is unlike In-Band Health checks, where the server can only be placed in the out-of-service status, but can never revert because no further user traffic is directed towards an out-of-service server. To send periodic probes to check the health of the server, configure the following:

a. Enable OOB Health Checks – Set to Yes to enable Out-of-Band monitoring. Note that disabling Out-of-Band Monitoring means that if a server is marked as out-of-service by In-Band monitoring, it cannot be put back into service without manual intervention. For this reason, In-Band monitoring is disabled when you disable Out-of-Band monitoring. b. Interval – Set the interval (time in seconds) between the probes sent by the Barracuda Web Application Firewall to the server to determine the health status.

Network layer probes involve a series of 3 connection attempts within the interval. Application layer probe involves one HTTP request during the specified interval. This affects how quickly a 'server down' condition will be detected, and also how quickly it will be marked as healthy again.

Application Layer Health Checks

Application Layer health check involves making an HTTP request to see if the server is responding correctly. If the server responds correctly, the server is said to be healthy. Otherwise, the server is marked as out-of-service. The settings for Application Layer determine what kind of HTTP request is made (URL, Method, Headers), and how to determine if the response was a good response (Status Code and Match Content String).

Application layer health check is governed by Out-Of-Band (OOB) module. To enforce application layer health check policy, set Enable OOB Health Checks to Yes.

To enable application layer health check, configure the following fields:

a. URL – Enter the URL to be used in the HTTP request to determine the server health. A URL such as /index.html is recommended which is always expected to be available, and the unavailability of which can only mean that the server is down. b. Method – Select the HTTP method to be used for the request from the drop-down list. c. Additional Headers – Enter any additional headers you want to send with the OOB HTTP request. d. Status Code – Specify the expected HTTP response status code when accessing the URL. Any other status code is considered to be unsuccessful, and will result in setting the server as 'out-of-service'. Typically, a status code of 200 is used to indicate a successful response, but in some cases, 300, 301 and 302 may also be considered successful (these status codes indicate redirect responses). e. Match Content String – Enter the string that needs to be matched in the response. If specified, the response must contain the string. If the response does not contain the string, the probe is deemed unsuccessful, and the server will be marked out-of-service. This helps detect encode errors in the response page. Note: The strings are case sensitive.

Connection Pooling

For information on connection pooling, refer to Using Connection Pooling: How and Why. How to Add a Real Server en You can add a server to a Service or Rule Group to load balance the incoming Web traffic. Perform the following steps to add a real server:

Adding a Real Server to a Service

1. From the BASIC > Services page in the Services section, identify the Service to which you want to add a real server. 2. Click the Server option next to the Service to add the server. The Add Real Server window appears. 3. Specify values for the following: a. Server Name – Enter a name to identify this server. b. IP Version – Select the Internet Protocol Version from the drop-down list. c. IP Address – Enter the IP address of the server. d. Port – Enter the port number of the server. e. Backup Server – Set to Yes if you want this server to be used when all other servers fail, or are out of service. f. Weight – Set the load balancing weight for the server. 4. Click Add.

Adding a Real Server to a Rule Group

182 To configure a Real Server to handle requests matching a Content Rule:

1. From the BASIC > Services page identify the Content Rule to which you want to add a real server. 2. Click the Add Server option next to the rule. The Add Real Server window appears. 3. Specify values for the following: a. Server Name – Enter a name to identify this server. b. IP Version – Select the Internet Protocol Version from the drop-down list. c. IP Address – Enter the IP address of the server. d. Port – Enter the port number of the server. e. Backup Server – Set to Yes if you want this server to be used when all other servers fail, or are out of service. f. Weight – Set the load balancing weight for the server. 4. Click Add.

Back To: How to Redirect Traffic to a Different Back-end Server Based on a URL Pattern Configuring Caching and Compression en en Caching Steps to Configure Caching Content Rules and Dynamic Pages Object Freshness Compression Steps To Configure Compression

Caching

Caching stores commonly used information in local memory for quick retrieval to reduce repeated requests to a web server for the same information. Web pages, graphics files, and other objects can be cached, sometimes dramatically improving performance and reliability. Benefits of caching include:

Reduced latency when retrieving web content. An overall reduction in bandwidth and server load. Automatic identification and replication of site content.

Steps to Configure Caching

Do the following to enable caching for a Service:

1. From the WEBSITES > Traffic Management > Caching section identify the Service for which you want to enable caching, and click Edit next to it. 2. The Caching window appears. Specify values for the following fields: a. Status – Set to On to enable caching policy for the Service. b. File Extensions – Add any file extensions of files you want cached. c. Max Size (KB) – Enter the maximum object size in kilobytes which can be cached. d. Min Size (B) – Enter the minimum object size in bytes which can be cached. e. Ignore Request Headers – If set to Yes, HTTP request cache-control headers are ignored for caching decisions (see Object Freshness). f. Ignore Response Headers – If set to Yes, HTTP response cache-control headers are ignored for caching decisions (see Object Freshness). g. Cache Negative Responses – If set to Yes, HTTP negative responses like 204, 305, 404, 405, 414, 501, 502 and 504 are cached. h. Expiry Age (minutes) – Specify the time in minutes after which the Barracuda Web Application Firewall expires the cached page and goes to the web server for the information requested by the client. 3. Click Save Changes to save the above settings.

Objects larger/smaller than the specified Max/Min Size will not be cached.

Content Rules and Dynamic Pages

Requests are compared to web service content rules and if caching is enabled for the matching rule, the response is cached and served from the

183 cache for subsequent requests. When disabled, each subsequent request is forwarded to the back-end server for the reply.

Caching works well for responses containing static pages which remain unmodified over multiple requests. When response content is likely to change for each request due to context or conditions (for example, when server side scripting is used to generate context-sensitive responses based on URL/form parameters in requests) a dynamic response is required.

A content rule with a URL of /reports/* matches all pages under /reports. If cache is enabled on this content rule, all pages under /repor ts are cached. If the /reports folder also contains dynamic pages that shouldn’t be cached, use one of the following options:

Move all dynamic pages into another folder, for example /reports/cgi_bin, and create a separate content rule for the URL of /repo rts/cgi_bin* disabling caching for this content rule. Disable cache for the original content rule, and do not cache any page under /reports.

Object Freshness

The freshness of cached objects determines their life span and whether to retrieve a newer version from the originating server. A freshness algorithm determines when an object is stale and directs corresponding requests to the originating server. Otherwise, the request is served with the cached copy. An expired cached object is still served from the cache, but the response includes a Warning 110 (response is stale) header.

The table below provides the algorithm which uses the object's age to determine object freshness. Age is calculated as follows: age = (current_time - time_retrieved) + object_age

When both Ignore Request Headers and Ignore Response Headers are Yes, all objects are considered fresh. When Ignore Request Headers is Yes: If Ignore Response Headers is No and the age of an object is greater than cached response max-age (if present), the object is considered stale. When Ignore Request Headers is No: If age is greater than request max-age header (if present), the object is considered stale.

The following table describes how to determine an object's freshness.

If ... Then object freshness is calculated as ...

Ignore Response Headers is Yes. freshness = age - expiry_age

Cached response had an expiration time. freshness = current_time - object_expiration_time

Age of an object is greater than Expiry Age. freshness = age - expiry_age

Cached response has a time last modified header. stale_age = time_object_retrieved + object_age -time_object_last_modified

stale_age = stale_age *age_from_last_modified_percentage / 100)

if age > stale_age, freshness = age - stale_age

Cached response does not have a time last modified header: freshness = age - expiry_age

Staleness < 0, a min-fresh header request is present, and it is set to The object is considered stale. be greater than the staleness value (positive value of it).

Staleness < 0, and a min-fresh header request is not present. The object is considered fresh.

A max-stale header request is present, and it is set to be greater than The object will expire. the staleness.

A max-stale header request is not present. The object is considered stale.

Compression

Compression improves response time for clients by reducing the quantity of data transferred. Web pages that use HTML, JavaScript, Java, and other text-based languages, can be compressed to improve traffic management and significantly reduce download time. Compression can be applied for all client requests, and to specific client requests that match Content Rules. Enabling compression for a Service applies compression to all Service requests.

184 Steps To Configure Compression

1. From the WEBSITES > Traffic Management > Compression section identify the Service for which you want compression enabled. 2. Click Edit next to that Service. The Compression window appears. Specify values for the following fields: a. Status – Set to On to enable compression policy for the Service. b. Content Types – Specify the content type(s) to be compressed. c. Min Size (B) – Specify the minimum size for the response. d. Compress Unknown Content Types – Set to Yes to compress files of unknown content type. These unknown file types can be non text content types such as executable binaries, flash content and so on. 3. Click Save Changes.

Compression should be turned off for back-end web servers. The Barracuda Web Application Firewall will not inspect compressed responses originating from the back-end servers. Instead, back-end servers should send uncompressed content to the Barracuda Web Application Firewall, which can compress content after applying configured security settings. The cache should be cleared when you enable compression to avoid retrieving uncompressed cached objects. How to Configure Rate Control en en Rate Control Before you set up a Rate Control Pool Benefits of a Rate Control Pool Scheduling algorithm for Rate Control Pool Customizing Rate Control Pool Creating Preferred Clients

Rate Control

The Rate Control policy defines shareable policies for controlling the rate of requests to a web application. The Client/HTTP requests are delivered to an application server, or parts of it, which can get overloaded with peak traffic and create high response at times. The Barracuda Web Application Firewall's Rate Control policy prevents application servers from being overloaded. A Rate Control Pool specifies the maximum number of Active Requests and Client Backlogs along with a set of Preferred Clients. A Preferred Client specification defines a range of IP addresses and an associated weight. The Barracuda Web Application Firewall uses these weights to perform a weighted round robin scheduling between queues when forwarding requests to the application server from the rate control pool. You can set a Rate Control pool to limit the client requests. The Barracuda Web Application Firewall collects requests and queues them in the pool. The back-end application servers receive requests from the pool at the rate specified.

A default rate control pool is provided by the Barracuda Web Application Firewall which allows the easy set up of Rate control. Using Edit on the BASIC > Services page or using Edit on the WEBSITES > Advanced Security page, you can select a rate control pool to apply to your Service or URL policy. Edit the desired Service or URL Policy to select a Rate Control Pool. A custom Rate Control Pool can be created on the ADVANC ED > Libraries > Rate Control Pool page by selecting Add Rate Control Pool.

Before you set up a Rate Control Pool

Answer the following questions:

1. What are the maximum simultaneous requests that can be served by the resource being protected? This determines the Maximum Active Requests setting. 2. What, if any, are the bonafide gateways and mega-proxies that will be accessing the protected resources? These are Preferred Clients. If they proxy client requests, assign a suitable weight to the proxy IP address and if they relay a set of client IP addresses, then assign a weight to the range of IP addresses. 3. What is the maximum queue to allow for IP addresses not defined in Step 2? This defines the Maximum per client backlog setting.

Benefits of a Rate Control Pool

A Rate Control Pool helps defend against rate control attacks by:

Throttling attackers attempting to flood the application with DoS attacks. The requests get queued for weighted round robin scheduling, slowing down the request rate seen by the server. Protecting “Load Sensitive” applications, such as search or DBMS intensive applications, from application DoS attacks. Allowing bonafide gateways and mega-proxies access while preventing attacks.

185 Scheduling algorithm for Rate Control Pool

The scheduling algorithm between queues is weighted round robin. Implicitly, the weight of each unconfigured client queue is 1. For example, a Preferred client is defined with weight 5 and at a given time the Barracuda Web Application Firewall has queues for 2 Unconfigured clients with a few requests in each. The Barracuda Web Application Firewall will serve 1 request from each unconfigured client queue followed by 5 requests from the Preferred client queue.

Rate control policies can be specified per service or per URL policy. Rate Control Pools are defined on the ADVANCED > Libraries page. These rate control pools are globally shareable among services or among URL policies or both. Once defined, they can be bound to multiple services on the BASIC > Services page, when you Edit a service. Also they can be bound to multiple URL policies on the WEBSITES > Advanced Security page, when you Edit a URL policy.

Customizing Rate Control Pool

From the ADVANCED > Libraries > Rate Control Pool page use Edit or Add Rate Control Pool to customize a rate control pool. Set the following values:

Rate Control Pool Name – Enter a name for the new rate control pool. Maximum Active Requests – Enter the maximum number of Active Requests processed at a given time by the Barracuda Web Application Firewall. An active request is a request which has not fully completed. Maximum per client backlog – Enter the number of requests per client IP address that will be queued when the Barracuda Web Application Firewall has reached the Maximum Active Requests limit. For example, if Maximum Per Client Backlog is set to 32 and the Barracuda Web Application Firewall is processing the default 100 Maximum Active Requests, then for any given client IP, the Barracuda Web Application Firewall will queue up to 32 requests. Any requests after that will be dropped until a request is deleted from the queue. Maximum Unconfigured Clients – Enter the maximum number of Unconfigured Clients. All clients which are not Preferred Clients are Unconfigured Clients. For each unique client IP, the Barracuda Web Application Firewall will maintain an individual backlog queue. For example, if Maximum Unconfigured Clients is set to 100 and Maximum Per Client Backlog is set to 32, the Barracuda Web Application Firewall will maintain 100 queues each with 32 pending requests, a total of 3200 pending requests.

Click Add to save the configuration.

Use Add Preferred Clients to add a single or range of IP addresses to the pool gets preferred treatment. Each Preferred client has a configured Weight and its own queue containing Max Per Client Backlog times Weight. For example, if Max Per Client Backlog is set to 32 and preferred client Weight is set to 5, then the queue size will be 32 x 5. If he preferred client queue contains a range of IP addresses, the queue will include all requests from all the clients falling within that range.

Creating Preferred Clients

Click Add Preferred Clients, under Options. The Add Preferred Client window appears. Specify values for the following fields:

Name – Enter the name for the client weight. Status – Sets the status of the preference. Enabling this makes the client IP address range a preferred list of IP addresses. Preferred Client IP Range – Enter the IP address or the range of IP addresses (For example: 10.0.0.1 – 10.0.0.10) which will be treated in a preferential manner. Preferred Client is an IP address or a range of IP addresses with an associated weight. Weight – Enter the weight for the range of IP addresses. These IP addresses are evaluated in the order of their weights; the higher the weight the higher the precedence (1 is the lowest priority and 100 the highest priority).

Click Add to save the configuration.

Click Delete to delete the created Rate Control Pool from the list. Using Connection Pooling: How and Why en The Barracuda Web Application Firewall provides connection pooling to speed up request handling. For a server, a pool of connections can be maintained so requests to that server can use an available connection in the pool rather than waiting on initiating a connection. Using existing connections delivers requests to that server faster, and decreases connection set up and tear down overhead. Connection Pooling also reduces the server's load, which frees resources to handle other important tasks. The Barracuda Web Application Firewall supports TCP/IP pooling where a single server connection can support multiple client connections.

Configuring Connection Pooling

186 Connection Pooling is configured per server. You must add a server before you can configure connection pooling. To configure connection pooling, navigate to the BASIC > Services page, click Edit next to the desired server in the Services section. Scroll down to the Connection Pooling section in the Server Configuration window and specify values for the following:

1. Enable Connection Pooling – Select Yes to allow a connection to the server to be used for multiple requests from clients. 2. Keepalive Timeout – Specify the maximum time in milliseconds before expiring an idle connection which was used at least once. This value applies per 1024 connections, when a timeout error occurs before turning off the server. a. Range: 0 to 86400000 b. Recommended: 900000 c. Units: Milliseconds

For more information on configuring a server, see Configuring Server Settings. Content Routing en

In this Section

How to Add a Content Rule How to Redirect Traffic to a Different Back-end Server Based on a URL Pattern

How to Add a Content Rule en The BASIC > Services page allows you to create content rules for a Service. Rules added to the Service allow content-aware processing decisions for Web traffic coming into that Service. Rules can use HTTP request headers to make load balancing and caching policy decisions. To add a content rule to a Service:

1. From the BASIC > Services page in the Services section find the Service to which you want to add a content rule. 2. Click Rule next to the Service. The Add Content Rule window appears. 3. Specify values for the following fields: a. Rule Group Name – Name to identify this rule group. b. Status - Set to On to make this rule group part of the rule match. c. Host Match – Enter the matching criterion for host field in the Request Header. This is either a specific host match or a wildcard host match with a single " * " anywhere in the host name. Specify * if you want the rule to be matched with any host. If the Service hosts multiple applications under different domains and you wish to add the rule only for a particular domain, enter the relevant host name such as - www.example.com or *.example.com. d. URL Match – Enter the matching criterion for URL field in the Request Header. The URL should start with a "/" and can have only one " * " anywhere in the URL. A value of /* means that the ACL applies for all URLs in that domain. Use /* if you want to cover all the URLs in your domain. (Example: /*, /index.html, /public/index.html) e. Extended Match – Enter an expression that consists of a combination of HTTP headers and/or query string parameters. Use '*' to apply to any request, that is, do not apply the Extended Match condition. Refer to Extended Match Syntax Help to find out how to write extended match expressions. f. Extended Match Sequence – Specify a number which will determine the order for matching the extended match rule. The order range is 1 to 1000 (default is 1000). 4. Click Add.

Back To: How to Redirect Traffic to a Different Back-end Server Based on a URL Pattern How to Redirect Traffic to a Different Back-end Server Based on a URL Pattern en This feature is available on all units, however the way to access this feature varies depending on your firmware version.

The WEBSITES > Traffic Management page allows you to define content rules that specify a pattern in the URL or header fields of the request. The Barracuda Web Application Firewall compares URLs and header fields of requests to the rules you define, and applies the content rule policies to matching requests.

Creating a Content Rule

1. For Firmware version 7.6 and higher: a. From the BASIC > Services page in the Services section identify the desired Service. 2. For Firmware versions before 7.6: a.

187 2. a. From the WEBSITES > Traffic Management page in the Services section, identify the desired service. 3. Click the Rule option next to the Service. The Add Content Rule window appears. 4. In the URL Match field, enter the URL of the requests you want to redirect to a different back-end server. Specify appropriate values for other fields and click Add. See How to Add a Content Rule. 5. Click the Server option next to the rule you just created. The Add Real Server window appears. 6. In the IP Address field, enter the destination IP address where matching requests should be redirected. Specify appropriate values for the other fields and click Add. See How to Add a Real Server.

Example:

To redirect incoming requests for "www.barracuda.com/xyz/" to Server1 (192.168.1.1) you would create a content rule as follows:

Rule Group Name – abc Host Match – www.barracuda.com URL Match – /xyz* Extended Match – * (or specify the condition under which the redirection should take place) Extended Match Sequence – 1000

Adding a Server:

IP Address – 192.168.1.1 Port – 80 Status – In Service Content Rewriting en In this article:

en Configuring URL Translation Configuring HTTP Request Rewrite Configuring HTTP Response Rewrite Configuring Request Rewrite and Response Rewrite Rewrite Condition Format Request Rewrite Tokens Response Rewrite Tokens Operations for Request Rewrite and Response Rewrite Conditions Configuring Response Body Rewrite Supported Macros For Request Rewrites For Response Page

This article applies to Barracuda Web Application Firewall Model 460 and higher.

The Barracuda Web Application Firewall allows you to rewrite selected content of requests and responses. This feature can be used to implement website cloaking and translation of URLs and headers in requests and responses. It can translate the internal codes, headers, and cookies so they are concealed from external users. Content rewriting allows you to configure address translation rules for application specific packets sent through the Barracuda Web Application Firewall.

Configuring URL Translation

When a web server returns a URL, sensitive information about the web server may be revealed, which could be used to launch a variety of web attacks against the server. URL translation modifies the prefix, domain, and response body of an internal URL to an externally viewable URL, thus preventing potential attacks.

URL translation can externalize internal applications, which link to internal servers (not defined in the external DNS name space). For example, Company ABC has an internal application registered in the internal DNS as finance.abc. URL translation can make this application available to external partners behind a common public domain such as www.companyabc.com without exposing the internal name space. Through URL translation, Company ABC can map different internal and external prefixes so the internal application is available on the public Internet as www.co mpanyabc.com/finance.abc. To configure URL Translation, use WEBSITES > Website Translations > URL Translations. Click Help on that page for detailed configuration instructions.

Configuring HTTP Request Rewrite

188 HTTP Request Rewrite allows incoming requests to be rewritten or redirected. Headers can be added, removed, or edited on the Barracuda Web Application Firewall before the request is forwarded to the back-end server. The URL can be rewritten to map to a different resource. A redirect response can also be issued to the clients to point them to an updated location or resource. For example, Request Rewrite is used by default to relay the client IP address to the back-end server (in Proxy mode), by inserting the header X-Forwarded-For with the value of the client IP. The back-end server can extract and use this value. Similarly authentication parameters (such as certificate details or user name) could be forwarded by inserting request headers and using macros. See How to Pass Client Certificate Details to a Back-end Server for more details. To configure HTTP Request Rewrite, use WEBSITES > Website Translations > HTTP Request Rewrite. For detailed configuration instructions, click Help on that page. To format a Request Rewrite Condition refer to Format of Request Rewrite and Response Rewrite Conditions below.

Configuring HTTP Response Rewrite

This policy sets rewrite rules for outbound responses. It allows you to add, delete, or rewrite headers. Response Rewrites are used for many purposes. For example, if a response included a header listing the source IP address, response rewrite could delete that header preventing external users from seeing the actual IP address of the server. To configure HTTP Response Rewrite, use WEBSITES > Website Translations > HTTP Response Rewrite. For detailed configuration instructions, click Help on that page.

Configuring Request Rewrite and Response Rewrite

To configure a request rewrite rule, perform the following steps:

1. Go to the WEBSITES > Website Translations page, and in the HTTP Request Rewrite section or HTTP Response Rewritesection, specify values for the following fields: a. Rule Name – Enter a name for the request or response rewrite rule. b. Sequence Number – Set the sequence number for the request or response rewrite policy. This number determines the order of execution for multiple configured policies from highest (1) to lowest (1500). c. Action – Set the action to: Insert Header -Inserts a header to the request; Remove Header - Removes the header from the request; Rewrite Header - Rewrites the value of the existing header in the request. d. Header Name – Enter the relevant Header Name, for example X-Forwarded-For. e. Old Value – Enter the initial request header to be rewritten if the Action is Rewrite Header. An asterisk (*) rewrites all named headers, or specify the value or expression to be rewritten. f. Rewrite Value – Enter the new value of the header to be rewritten when the Action is set to Insert Header or Rewrite Header. Use the macros listed below to specify parameters from the client. When rewriting a header you can specify one or more fields using the separators such as colon (:), semicolon (;), space ( ) and comma (,). In Rewrite Value, the fields can be defined for example: "Name=abc_cookie; Domain=example.com:Path=/". The rewrite-value supports substring addressing of matches, i.e. the matching substrings can be referenced using $1,$2,...$n. See Supported Macros below for a list of macros supported for rewrite values. g. Rewrite Condition – Set the condition under which a rewrite should occur. An asterisk (*) indicates there are no conditions (applies to all). Details on the format of the Rewrite Condition are explained below in Rewrite Condition Format. 2. Click Add to add the above settings.

Rewrite Condition Format

The request Rewrite Condition specifies when a rewrite should occur. The Rewrite Condition is made up of expressions combining Request Rewrite Tokens and Operations on those tokens for Request Rewrites. The Rewrite Condition is made up of expressions combining Respon se Rewrite Tokens and Operations on those tokens for Response Rewrites.These expressions can then be joined with each other using logical or (or, OR, ||) or logical and (and, AND, &&). Examples of Rewrite Conditions: (Header User-Agent co mozilla) , (URI rco /abc*html), (Client-IP eq 10.0.0.1)&&(Method eq POST). An asterisk indicates there are no conditions for rewrite, so the rewrite is done in every case.

Request Rewrite Tokens

These tokens can be used in a request Rewrite Condition:

Header: The HTTP header in the request. The word Header precedes the name of the relevant header or * to indicate all headers. Examples: Header Accept co soap, Header Soap-Action ex. Client-IP:The IP address of the client sending the request. The IP address can be either a host IP address or a subnet specified by a subnet mask. Only operations EQ and NEQ can be combined with this token. Examples: Client-IP eq 192.168.1.0/24 (subnet qualified by a netmask) Client-IP eq 192.168.1.10 (host IP address)

189 Uri: The Uniform Resource Identifier of the resource on which to apply the rule. Example: URI rco /abc*html Method: The HTTP method in the request. Example: Method eq GET Http-Version: The HTTP protocol version of the request. Example: HTTP-Version eq HTTP/1.1 Parameter: The query part of the URL which is passed to the servers as a name-value pair. In addition, the word "$NONAME_PARAM" can be used when the parameter name is absent. Examples: Parameter sid eq 1234, Parameter $NONAME_PARAM co abcd Pathinfo: The portion of URL which contains extra information about the path of the resource on the server. Example: pathinfo rco abc*

Response Rewrite Tokens

These tokens can be used in a response Rewrite Condition:

Header: The HTTP header in the request. The word Header precedes the name of the relevant header or * to indicate all headers. Examples: Header Accept co soap, Header Soap-Action ex. Response-Header: An HTTP header on the response path. The term "Response-Header" should be followed by the name of the header on which the action is to be applied. Example: Response-Header Set-Cookie co sessionid. Status-Code: The status code of the response returned by the servers. Example: Status-Code eq 200

Operations for Request Rewrite and Response Rewrite Conditions

These operations can be combined with Request Rewrite Tokens and Response Rewrite Tokens in a request or response Rewrite Condition:

contains, CONTAINS, co, CO – Token contains the given value. ncontains, nCONTAINS, nco, nCO – Token does not contain the given value. rcontains, rCONTAINS, rco, rCO – Token contains the given value which is interpreted as a regular expression. equals, EQUALS, eq, EQ – Token equals the given value. nequals, nEQUALS, neq, nEQ – Token does not equal the given value. requals, rEQUALS, req, rEQ – Token equals the given value interpreted as a regular expression. exists, EXISTS, ex, EX – Token exists. nexists, nEXISTS, nex, nEX – Token does not exist.

Configuring Response Body Rewrite

This policy sets the rule for searching and replacing any text string in the response body. Only responses whose content-type begins with text/ can be searched, including text/html, text/plain, text/javascript, text/css, text/xml. Neither flash nor applet content can be searched. The search and replace strings should be text rather than regular expressions. Metacharacters cannot be used, such as \r or \n in either search or replace, which means you cannot search and replace any multi-byte charset strings.

To configure Response Body Rewrite, use WEBSITES > Website Translations > Response Body Rewrite. For detailed configuration instructions, click Help on that page.

Supported Macros

For Request Rewrites

$SRC_ADDR Inserts the source (client) IP address. You can use it for the new value (Rewrite Value parameter) when inserting or rewriting a header $URI Should be specified in the new value, if you are rewriting or redirecting the URI. $URI specifies the complete request URI including the query string. $X509_VERSION The client certificate's X509 version string. $X509_SERIAL_NUMBER The serial number of the client certificate. $X509_SIGNATURE_ALGORITHM The Signature Algorithm used in the client certificate. $X509_ISSUER The client certificate's issuer string. $X509_NOT_VALID_BEFORE Time from which the client certificate is valid. $X509_NOT_VALID_AFTER Time after which the client certificate is invalid. $X509_SUBJECT The client certificate's Subject string. $X509_SUBJECT_PUBLIC_KEY_TYPE The X509 Certificate Subject Key Identifier String of the client certificate. $X509_SUBJECT_PUBLIC_KEY Public Key modulus of the client certificate. $X509_SUBJECT_PUBLIC_KEY_RSA_BITS Size of the client certificate's public key, in bits. $X509_EXTENSIONS The client certificate's X509 Extensions String. $X509_HASH The X509 Hash string of the client certificate. $X509_WHOLE The X509 client certificate represented as a string in PEM format.

190 $AUTH_USER Adds the username.* $AUTH_PASSWD Adds the password.* $AUTH_GROUPS Adds the user roles.* *Note:

a. The URL is not protected, i.e. access-control or authentication is off. The value substituted for the above three macros will be the special string NCURLNotProtected. b. The client has not logged in. The value substituted for the above three macros will be the special string NCNoUserSession. c. The user does not belong to any groups. The value substituted for $AUTH_GROUPS will be the special string NCNOUserRoles.

For Response Page

%action-id The attack id of the violation which resulted in this response page being displayed. %host The host which sent this request. %s The URL of the request which caused this violation. %client-ip The Client IP address of the request which caused the violation. %attack-time The time at which the violation occurred. %attack-name The attack name of the violation which resulted in the response page to be displayed. How to Allow Internet Access for the Back-end Servers in Two-Arm Proxy Mode en When the Barracuda Web Application Firewall is deployed in Two-Arm Proxy Mode, all traffic originating from the LAN to the Internet is denied by default. NAT rules must be configured to map internal source IP addresses to routable IP addresses.

The Barracuda Web Application Firewall allows you to configure NAT rules on the ADVANCED > Advanced Networking page.

Configuring Source Network Address Translation Rule

Perform the following steps:

1. From the ADVANCED > Network Firewall page in the Source Network Address Translation section, specify values for the following: a. Pre SNAT Source - Specify the IP Address/Network of your back-end Web server that needs to be translated. b. Pre SNAT Source Mask - Specify the associated network mask for the source IP Address/Network. c. Protocol - Select TCP/UDP as the communication protocol to be used between the hosts. d. Destination Port - Specify the destination port/range of port numbers of the server to which the back-end server wants to connect. e. Outgoing Interface - Select WAN as the outgoing interface for the traffic to pass through. f. Post SNAT Source - Specify the IP Address to which your Web server IP Address should be mapped to access the Internet. 2. Click Add.

If the Post SNAT Source is different from the WAN IP address of the Barracuda Web Application Firewall, you need to add the new IP address in the Custom Virtual Interfaces section on the ADVANCED > Advanced Networking page to associate it to the WAN interface.

If the back-end server needs to connect to the Internet via Barracuda Web Application Firewall, the servers default gateway should be either:

The LAN IP address of the Barracuda Web Application Firewall, OR Custom Virtual Interface configured on the LAN interface of the Barracuda Web Application Firewall. Custom Virtual Interface can be configured using Interface tab on the ADVANCED > Advanced Networking page.

NAT for LAN Servers (Auto SNAT)

You can configure auto SNAT for LAN servers to reach Internet directly without any NAT or ACL rule being configured. Use the ADVANCED > Advanced Networking page to configure NAT for LAN Servers.

Steps To Configure NAT for LAN Servers

Perform the following steps:

1. Go to the ADVANCED > Advanced Networking page. 2. In the Network Configuration section, select System as Network Group and then select the Configuration tab.

191 3. In the NAT for LAN Servers section, set Enable SNAT for LAN Servers to Yes. 4. Click Save Changes.

When Enable SNAT for LAN Servers is set to Yes, all traffic originating from LAN to go out on the WAN is automatically NATted with the WAN interface IP address. The traffic originating from any subnet that belongs to LAN is also NATted. In this case a user is not required to configure SNAT and ACL rule for the real servers, as the Barracuda Web Application Firewall automatically NATs and allows the LAN traffic to go out to the Internet.

If you want more granular access control on the traffic originating from the LAN going out to the Internet, set Enable SNAT for LAN Servers to N o and manually configure the SNAT rule. Logging, Reporting and Monitoring en In this Section

How to Configure Syslog and other Logs How to Make the Client IP Address Available to the Back-end Server in Proxy Mode Configuring Client Impersonation Logging Actual Client IP Address on the Apache Server Logging Actual Client IP Address In the IIS 7 and IIS 7.5 Server How to Mask Sensitive Data in Logs Reporting How to Set Up Barracuda Cloud Control Receiving Trap Messages and System Alerts System Log Messages

How to Configure Syslog and other Logs en The Barracuda Web Application Firewall generates five types of logs which can be exported to configured remote servers using the syslog mechanism. These logs also reside on the Barracuda Web Application Firewall log database, viewable on the GUI on various tabs. In addition, logs can be exported in CSV format to external files. This article describes each element of syslog messages so an administrator can analyze events and understand how the Barracuda Web Application Firewall handled each logged event. The syslog format details can help you use external parsers or other agents, available starting with version 7.0.x of the firmware, to process the syslog messages sent from the Barracuda Web Application Firewall

The following logs are explained briefly below. These logs can be segregated and distributed using the LOCAL 0 through LOCAL 7 facilities, making management of these logs on the external syslog servers easier.

System Logs: Logs events generated by the system showing the general activity of the system. Web Firewall Logs: Logs events which indicate the web firewall activity such as allowing, blocking or modifying the incoming requests and responses as defined in the Barracuda Web Application Firewall rules and policies. Access Logs: Logs events pertaining to traffic activity and various elements of the incoming HTTP request and the responses from the back-end servers. Audit Logs: Logs events pertaining to the auditing events generated by the system including configuration and UI activity by users like admin. Network Firewall Logs: Logs events generated whenever network traffic passing through the interfaces (WAN, LAN and MGMT) matches the configured Network ACL rule.

If you have any questions after reading this document, please contact Barracuda Networks Technical Support.

In this article:

Enabling Syslog Steps To Add a Syslog Server Syslog Facility To configure facilities for different log types To configure log levels for different modules Log Formats Custom Log Format

192 Log Format Separators Steps To Configure Logs Format System Logs Detailed Description Web Firewall Logs Detailed Description Access Logs Detailed Description Audit Logs Detailed Description Network Firewall Logs Detailed Description Table of Log Formats

Enabling Syslog

To export logs to remote syslog servers, navigate to the ADVANCED > Export Logs page. In the Syslog section, enter the name and IP addresses of up to 3 syslog servers where you want to direct the System Events, Web Firewall logs, Access logs, Audit logs and Network Firewall logs. See Steps To Add a Syslog Server. If you are running syslog on a UNIX machine, be sure to start the syslog daemon process with the “-r” option so it can receive messages from external sources. Windows users require additional software to utilize syslog since the Windows OS does not include the syslog capability. Kiwi Syslog is a popular solution, but there are many others to choose from, both free and commercial.

Syslog messages are sent over UDP/TCP/SSL ports. If there are any firewalls between the Barracuda Web Application Firewall and the configured external servers, ensure that the respective port is open on the firewalls.

Steps To Add a Syslog Server

1. Go to the ADVANCED > Export Logs page. 2. In the Syslog section, click Add Syslog Server. The Add Syslog Server window appears, specify values for the following: a. Name – Enter a name for the syslog server. b. IP Address – Enter the IP address of the syslog server. c. Port – Enter the port associated with the IP address of the syslog server. d. Connection Type – Select the connection type to transmit the logs from the Barracuda Web Application Firewall to the Syslog server. UDP is the default port for Syslog communication. UDP, TCP or SSL can be used in case of NG Syslog server. e. Validate Server Certificate – Set to Yes to validate the syslog server certificate using the internal bundle of Certificate Authority's (CAs) certificates packaged with the system. If set to No, any certificate from the syslog server is accepted. f. Client Certificate – When set to Yes, the Barracuda Web Application Firewall presents the certificate while connecting to the syslog server. g. Certificate – Select a certificate for the Barracuda Web Application Firewall to present when connecting to the syslog server. Certificates can be uploaded on the BASIC > Certificates page. For more information on how to upload a certificate, see How to Add an SSL Certificate. 3. Click Add.

Syslog Facility

Syslog receives different types of log messages. In order to differentiate and store them in distinct log files, log messages contain a logging priority and a logging facility in addition to the actual message and IP address.

All log messages are marked with one of the following facilities:

local0 local1 |ocal2 local3 local4 local5 local6 local7

For each configured syslog server, you can associate a specific facility (default = local0) with each log type, so your syslog server can segregate the log of each type into a different file.

193 To configure facilities for different log types

1. Navigate to the ADVANCED > Export Logs page. 2. In the Syslog section, click Syslog Settings. The Syslog Settings dialog box appears. 3. Select the appropriate facility (Local0 to Local7) from the drop-down list for each log type and click Save Changes.

You can set the same facility for all log types. For example, you can set Local0 for System Logs, Web Firewall Logs, Access Logs, Audit Logs and Network Firewall Logs.

To configure log levels for different modules

1. Navigate to the ADVANCED > Export Logs page. 2. In the Module Log Levels section, specify values for the following fields: a. Name – Enter a name for the new setting. b. Module – Select a module name from the drop-down list. c. Log Level – Select a log level for the module from the drop-down list. By default, the log level is set to 0-Emergency. Note that the lower the level, the higher the priority and the more attention the log entry demands. For example, log levels 0-Emergency and 1-Alert are the highest priority situations, demanding more immediate response than 5-Notice or 6-Information. d. Comment – (Optional). Enter comment about the new setting. 3. Click Add to add the above settings.

Module Log Level is an advanced feature, and available only when Advanced Settings is set to Yes on the ADVANCED > System Configuration page.

Log Formats

You can customize the Web Firewall Logs, Access Logs, and Audit Logs formats sent to the syslog sever. You can choose from the predefined log formats (Common Log Format, NCSA Extended Format, W3C Extended Format, or Default), or you can create a Custom Format. Given below are the steps to specify the Custom Format.

Depending upon the configuration, an IP address of a Service, Client IP or Server IP can either be IPv4 or IPv6.

Custom Log Format

To customize the log format for any Log Type (except System Logs)

1. Navigate to ADVANCED > Export Logs page. 2. In the Logs Format section, select Custom Format for any of the log types. The Custom Format can be defined in two ways: a. Specify "%" followed by the alphabet. The alphabets and its meaning are given in the Table of Log Formats for different log types. For example, if you configure "%h %u %t %r %ua %ci" as the custom format, the output will be "Jan 13 16:19:22 wsf 192.168.132.211 /cgi-bin/process.cgi 2010-01-13 05:49:22.350 -0500 "-" "Wget/1.10.2 (Red Hat modified)" 192.168.128.7". OR, b. Specify "name=value" format. For example, if you configure "host=%h url=%u time=%t ref=%r uagent=%ua src=%ci" as the custom format, the output will be "Jan 13 16:19:22 wsf host=192.168.132.211 url=/cgi-bin/process.cgi time=2010-01-13 05:49:22.350 -0500 ref="-" uagent="Wget/1.10.2 (Red Hat modified)" src=192.168.128.7". This format is used by some SEIM vendors such as ArchSight. 3. Click Save Changes to save the settings.

Log Format Separators

When defining log formats you can use space as a separator between each log format for Web Firewall Logs Format, Access Logs Format an d Audit Logs Format.

For Access Logs Format, you could also use pipe (|) or semicolon (;) separators. Log formats can be separated by a single separator or a combination of space, pipe and semicolon separators.

Log formats can use only one separator in each place i.e. space (" "), pipe (|) or semicolon. For example: %h %id|%u;%t %r|%s

194 For information on how to manage these logs please see the documentation available for your syslog server.

Steps To Configure Logs Format

1. Go to the ADVANCED > Export Logs page. 2. In the Logs Format section, specify values for the following fields: a. Syslog Header – Specify a header format, which will be displayed when %header is used in the logs format. For example, consider the header format is "Barracuda", and the defined custom format is "%header %h %u %t %r %ua %ci". The output will be "Barracuda Jan 13 16:19:22 wsf 192.168.132.211 /cgi-bin/process.cgi 2010-01-13 05:49:22.350 -0500 "-" "Wget/1.10.2 (Red Hat modified)" 192.168.128.7". Values: i. ArcSight Log Header – Uses this header format in the logs format. ii. QRadar Log Header – Uses this header format in the logs format. iii. Custom Header – Define a custom header format to be used in the logs format. b. Web Firewall Logs Format – Select the format in which the Web firewall logs should be sent to the syslog server. Values: i. Default – The default Web firewall log format defined by the Barracuda Web Application Firewall ii. CEF:0 (ArcSight) – The Common Event Format (CEF) log used by ArcSight. iii. LEEF1.0 (QRadar) – The Log Event Enhanced Format (LEEF) log used by QRadar. iv. Symantec SIM – The default log format used by Symantec SIM. v. RSA enVision – The default log format used by RSA envision. vi. Splunk – The default log format used by Splunk. vii. Custom Format – Define a custom log format using the values displayed under Web Firewall Logs in the Table of Log Formats. c. Access Logs Format – Select the format in which the access logs should be sent to the syslog server. Values: i. Default – The default access log format defined by the Barracuda Web Application Firewall. ii. Common Log Format – The default format for logged HTTP information. iii. NCSA Extended Format – The Common Log Format appended with referer and agent information. iv. W3C Extended Format – The default log format used by Microsoft Internet Information Server (IIS). v. CEF:0 (ArcSight) – The Common Event Format (CEF) log used by ArcSight. vi. LEEF1.0 (QRadar) – The Log Event Enhanced Format (LEEF) log used by QRadar. vii. Symantec SIM – The default log format used by Symantec SIM. viii. RSA enVision – The default log format used by RSA enVision. ix. Splunk – The default log format used by Splunk. x. Custom Format – Define a custom log format using the values displayed under Access Logs in the Table of Log Formats. d. Audit Logs Format – Select the format in which the audit logs should be sent to the syslog server. Values: i. Default – The default audit logs format defined by the Barracuda Web Application Firewall. ii. CEF:0 (ArcSight) – The Common Event Format (CEF) log used by ArcSight. iii. LEEF1.0 (QRadar) – The Log Event Enhanced Format (LEEF) log used by QRadar. iv. Symantec SIM – The default log format used by Symantec SIM. v. RSA envision – The default log format used by RSA envision. vi. Splunk – The default log format used by Splunk vii. Custom Format – Define a custom log format using the values displayed under Audit Logs in the Table of Log Formats. 3. Click Save Changes.

The sections below describe the formats of the logs and elements sent over in each type of the event generated by the Barracuda Web Application Firewall. Please be aware that syslog implementations vary, and may not display the messages in this exact format. However, these sections should be present in the syslog lines.

System Logs

The default log format for the events generated by the Barracuda Web Application Firewall system is as follows:

%t %un %lt %md %ll %ei %ms

You cannot customize the format of System Logs.

For information on default log formats and their meanings, see the table below.

Example:

2014-05-20 00: 54:44.627 -0700 WAF1 SYS ADMIN_M ALER 51001 Account has been locked for user Kevin because

195 the number of consecutive log-in failures exceeded the maximum allowed

Detailed Description

The following table describes each element of a system log with respect to the above example:

Field Name Example Description

Time 2014-05-20 00: 54:44.627 -0700 The date and time at which the event occurred.

Unit Name WAF1 Specifies the name of the unit which is same as the Default Hostname on the BASIC > IP Configuration page.

Log Type SYS Specifies the type of log: Web Firewall Log, Access Log, Audit Log, Network Firewall Log or System Log.

Values: WF, TR, AUDIT, NF, SYS

Module Name ADMIN_M Denotes the name of the module that generated the logs. Example: STM, SAPD, LB, PROCMON, etc.

Log Level ALER The level of severity.

Values:

EMERGENCY – System is unusable (highest priority). ALERT – Response must be taken immediately. CRITICAL – Critical conditions. ERROR – Error conditions. WARNING – Warning conditions. NOTICE – Normal but significant condition. INFORMATION – Informational message (on ACL configuration changes). DEBUG – Debug-level message (lowest priority).

Event ID 51001 The event ID of the module.

Message Account has been locked for user Kevin Denotes the log message for the event that because the number of consecutive log-in occurred. failures exceeded the maximum allowed.

Web Firewall Logs

All the actions/events on the web firewall are logged under Web Firewall Logs. These logs help the administrator to analyze the traffic for suspicious activity and also fine tune the web firewall policies.

Navigate to the BASIC > Web Firewall Logs page to view the generated log messages. This log data is obtained from the log database on the Barracuda Web Application Firewall itself. As noted above, the external syslog server IP for these logs is specified under ADVANCED > Export Logs > Syslog. Over syslog, every log in the Barracuda Web Application Firewall has a level associated with it, which indicates the severity of the logs. An administrator can configure what level of logs should be recorded for each service by editing the Service under the BASIC > Services pa ge.

The default log format for Web Firewall Logs:

%t %un %lt %sl %ad %ci %cp %ai %ap %ri %rt %at %fa %adl %m %u %p %sid %ua %px %pp %au %r

196 Unit Name, Log Type, and Log ID are not displayed on the BASIC > Web Firewall Logs page.

IPv4 Example:

2014-04-11 10:50:30.411 +0530 wafbox1 WF ALER PRE_1_0_REQUEST 99.99.1.117 34006 99.99.109.2 80 global GLOBAL LOG NONE [POST /index.cgi] POST 99.99.109.2/index.cgi HTTP REQ-0+RES-0 “Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20100101 Firefox/12.0” 99.99.1.117 34005 Kevin http://99.99.109.2/index.cgi

IPv6 Example:

2014-04-11 10:52:01.579 +0530 wafbox1 WF ALER PRE_1_0_REQUEST 2001::117 43655 2001::1:109 80 global GLOBAL LOG NONE [POST /index.cgi] POST 2001::1:109/index.cgi HTTP REQ-0+RES-0 " Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20100101 Firefox/12.0" 2001::117 43654 Kevin http://2001::109/index.cgi

Detailed Description

The following table describes each element of a web firewall log with respect to the above example:

Field Name Example Description

Time 2014-04-11 10:50:30.411 +0530 The time recorded in the following format: "yy yy-mm-dd hh:mm:ss.s" (one or more digits representing a decimal fraction of a second) TZD (time zone designator which is either Z or +hh:mm or -hh:mm)

Unit Name wafbox1 Specifies the name of the unit which is same as the Default Hostname on the BASIC > IP Configuration page.

Log Type WF Specifies the type of log: Web Firewall Log, Access Log, Audit Log, Network Firewall Log or System Log.

Values: WF, TR, AUDIT, NF, SYS

Severity ALER Defines the seriousness of the attack.

Values:

Attack Type PRE_1_0_REQUEST The name of the attack triggered by the request. For detailed information about attack names and description, see Attacks Description - Action Policy.

197 Client IP 99.99.1.117 The IP address of the client sending the OR request. 2001::117 Note that an intermediate proxy or gateway may have overwritten the actual source IP of the client with its own. To retrieve the actual client IP for logging you should configure the Header Name For Actual Client IP under the Edit actions for a service on the BASIC > Services page.

Then the actual client IP can be extracted from the header, (e.g. X-Forwarded-For) logged in this field and used in security policy checks involving the client IP. See also related Proxy IP field below.

Client Port 34006 The port relevant to the client IP address. OR 43655

Service IP 99.99.109.2 The IP address of the service that receives OR the traffic. 2001::1:109

Service Port 80 The port relevant to the IP address of the service.

Rule global The path of the URL ACL that matched with the request. Here "webapp1" is the web application and "deny_ban_dir" is the name of the URL ACL created on the WEBSITES > Allow/Deny page.

198 Rule Type GLOBAL This indicates the type of rule that was hit by the request that caused the attack. The following is the list of expected values for Rule Type:

Global – indicates that the request matched one of the global rules configured under Security Policies.

Global URL ACL – indicates that the request matched one of the global URL ACL rules configured under Security Policies.

URL ACL – indicates that the request matched one of the Allow/Deny rules configured specifically for the given Web site.

URL Policy – indicates that the request matched one of the Advanced Security rules configured specifically for the given Web site.

URL Profile – indicates that the request matched one of the rules configured on the URL Profile.

Parameter Profile – indicates that the request matched one of the rules configured on the Parameter Profile.

Header Profile – indicates that the request matched one of the rules configured on the Header Profile.

Action LOG The appropriate action applied on the traffic.

DENY - denotes that the traffic is denied. LOG - denotes monitoring of the traffic with the assigned rule. WARNING - warns about the traffic.

Follow-up Action NONE The follow-up action as specified by the action policy. It could be either None or Lock ed in case the lockout is chosen.

Attack Details [POST /index.cgi] The details of the attack triggered by the request.

Method POST The HTTP method used by the request. Values: GET, POST, HEAD, etc.

URL 99.99.109.2/index.cgi The URL specified in the request. OR 2001::1:109/index.cgi

Protocol HTTP The protocol used for the request.

Session ID REQ-0+RES-0 The value of the session tokens found in the request if session tracking is enabled. Session Tracking is configured on the WEBS ITES > Advanced Security page.

199 User Agent Mozilla/5.0 (X11; Linux i686; rv:12.0) The value contained in the User-Agent Gecko/20100101 Firefox/12.0 request header. Normally, this information is submitted by the clients which details the browser, operating system, software vendor or software revision, in an identification string.

Proxy IP 99.99.1.117 If the client requests are coming through a OR proxy or gateway, then this field provides the 2001::117 IP address of the proxy.

A client side proxy or gateway changes the source IP of the request to its own and embeds the actual client’s IP in an HTTP header such as X-Forwarded-For or X-Client-IP.

The Barracuda Web Application Firewall, if configured, will ignore the proxy IP and extract the actual client IP from the appropriate header to apply security policies as well as for logging the Client IP field above.

This field preserves the proxy IP address for cases where it is required, e.g. forensics and analytics

Note: The actual client IP header configuration is done using the Header Name For Actual Client IP under the Edit actions for a service on the BASIC > Services page.

Proxy Port 34005 The port of the proxy server whose IP OR address has been logged in the Proxy IP fiel 43654 d above.

Authenticated User Kevin The username of the currently authenticated client requesting the web page. This is available only when the request is for a service that is using the AAA (Access Control) module.

Referrer http://99.99.109.2/index.cgi The value contained in the Referrer HTTP OR request header. It identifies the web resource http://2001::109/index.cgi from which the client was “referred” to the requested URL.

Access Logs

All web traffic activities are logged under the Access Logs. These logs help the administrator to obtain information about the website traffic and performance.

The BASIC > Access Logs page allows you to view the generated log messages stored on the Barracuda Web Application Firewall in a log database.

The default log format for Access Logs:

%t %un %lt %ai %ap %ci %cp %id %cu %m %p %h %v %s %bs %br %ch %tt %si %sp %st

%sid %rtf %pmf %pf %wmf %u %q %r %c %ua %px %pp %au %cs1 %cs2 %cs3

200 Unit Name, Log Type, and Log ID are not displayed on the BASIC > Access Logs page.

IPv4 Example:

2014-04-11 12:04:04.735 +0530 wafbox1 TR 99.99.109.2 80 99.99.1.117 34065 "-" "-" GET HTTP 99.99.106.25 HTTP/1.1 200 2829 232 0 1127 10.11.25.117 80 21 REQ-0+RES-0 SERVER DEFAULT PASSIVE VALID /index.html name=srawat http://99.99.109.2/index.cgi namdksih=askdj "Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20100101 Firefox/12.0" 99.99.1.117 34065 John gzip,deflate 99.99.1.128 keep-alive

IPv6 Example:

2014-04-11 12:11:24.964 +0530 wafbox1 TR 2001::1:109 80 2001::117 43740 "-" "-" GET HTTP 2001::1:109 HTTP/1.1 200 2837 232 0 1008 2001::117 80 10 REQ-0+RES-0 SERVER DEFAULT PASSIVE VALID /index.html name=srawat http://2001::1:109/index.cgi namdksih=askdj "Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20100101 Firefox/12.0" 2001::117 43740 John gzip,deflate 2001::128 keep-alive

Detailed Description

The table below describes each element of an access log with respect to the above example:

Field Name Example Description

Time 2014-04-11 12:04:04.735 +0530 The time recorded in the following format: yyyy-mm-dd hh:mm:ss.s (one or more digits representing a decimal fraction of a second)TZD(time zone designator which is either Z or +hh:mm or -hh:mm)

Unit Name wafbox1 The name of the unit specified as Default Hostname on the BASIC > IP Configuration page.

Log Type TR Denotes the type of log: Web Firewall Log, Access Log, Audit Log, Network Firewall Log or System Log.

Values: WF, TR, AUDIT, NF, SYS

Service IP 99.99.109.2 The IP address of the service that receives OR the traffic. 2001::1:109

Service Port 80 The port relevant to the IP address of the service.

Client IP 99.99.1.117 The IP address of the client sending the OR request. 2001::117 Note that an intermediate proxy or gateway may have overwritten the actual source IP of the client with it’s own. To retrieve the actual client IP for logging you should configure the Header Name For Actual Client IP under the Edit actions for a service on the BASIC > Services page. If the above is configured, the actual client IP is extracted from the header, e.g. X-Forwarded-For and used to populate this field and used in security policy checks involving the client IP as well. See related Pr oxy IP field below as well.

201 Client Port 59589 The port relevant to the client IP address. OR 43646

Login - The login ID used by the client for the request. This is available only when authentication is set to ‘ON’ for the Service whose URL was requested.

Certificate User - The username as found in the SSL certificate when Client Authentication is enforced by the Barracuda Web Application Firewall.

Method GET The request method of the traffic.

Protocol (HTTP or HTTPS) HTTP The protocol used for communication with the web server, either HTTP or HTTPS.

Host 99.99.106.25 The IP address of the host or website OR accessed by the user. 2001::1:109

Version HTTP/1.1 The HTTP version used by the request.

HTTP status 200 The standard response code which helps identify the cause of the problem when a web page or other resource does not load properly.

Bytes Sent 2829 The bytes sent as response by the Barracuda Web Application Firewall to the client.

Bytes Received 232 The bytes received from the client as a part of the request.

Cache Hit 0 Specifies whether the response is served out of the Barracuda Web Application Firewall cache or from the back-end server.

Values:

0 – if the request is fetched from the server and given to the user. 1 – if the request is fetched from the cache and given to the user.

Time Taken (ms) 1127 The total time taken to serve the request from the time the request landed on the Barracuda Web Application Firewall till the last byte given out to the client.

Server IP 10.11.25.117 The IP address of the back-end web server. OR 2001::117

Server Port 80 The port relevant to the back-end web server.

Server Time (ms) 21 The total time taken by the back-end server to serve the request forwarded to it by the Barracuda Web Application Firewall.

202 Session ID REQ-0+RES-0 The value of the session tokens found in the request if session tracking is enabled. Session Tracking is configured on the WEBS ITES > Advanced Security page.

Response Type SERVER Specifies whether the response came from the back-end sever or from the Barracuda Web Application Firewall.

Values: INTERNAL, SERVER.

Profile Matched DEFAULT Specifies whether the request matched a defined URL or Parameter Profile.

Values: DEFAULT, PROFILED.

Protected PASSIVE Specifies whether the request went through the Barracuda Web Application Firewall rules and policy checks.

Values: PASSIVE, PROTECTED, UNPROTECTED.

WF Matched VALID Specifies whether the request is valid or not.

Values: INVALID, VALID.

URL /index.html The URL of the request without the query part.

Query String name-srawat The query part of the request.

Referrer http://99.99.109.2/index.cgi The value contained in the Referrer HTTP OR request header. It identifies the web resource http://2001::1:109/index.cgi from which the client was “referred” to the requested URL.

Cookie namdksih=askdj The cookie as found in the HTTP request headers.

User Agent Mozilla/5.0 (X11; Linux i686; rv:12.0) The value contained in the User-Agent Gecko/20100101 Firefox/12.0 request header. Normally, this information is submitted by the clients which details the browser, operating system, software vendor or software revision, in an identification string.

203 Proxy IP 99.99.1.117 If the client requests are coming through a OR proxy or gateway, then this field provides the 2001::117 IP address of the proxy.

A client side proxy or gateway changes the source IP of the request to its own and embeds the actual client’s IP in an HTTP header such as X-Forwarded-For or X-Client-IP.

This field preserves the proxy IP address for cases where it is required, e.g. forensics and analytics.

Note: The actual client IP header configuration is done using the Header Name For Actual Client IP under the Edit actions for a service on the BASIC > Services page.

Proxy Port 34065 The port of the proxy server whose IP address has been logged in the Proxy IP fiel d above.

Authenticated User John The username of the currently authenticated client requesting the web page. This is available only when the request is for a service that is using the AAA (User Access Control) module.

Custom Header 1 gzip,deflate The header name for which you want to see the value in the Access Logs.

Custom Header 2 99.99.1.128 The header name for which you want to see OR the value in the Access Logs. 2001::128

Custom Header 3 keep-alive The header name for which you want to see the value in the Access Logs.

Audit Logs

The audit logs record the activity of the users logged in to the GUI of the Barracuda Web Application Firewall for the purpose of administration. These logs are visible on the BASIC > Audit Logs page and are also stored on the Barracuda Web Application Firewall in its native database. Additionally, when the administrator chooses an external remote syslog server through the configuration available at ADVANCED > Export Logs, these logs are streamed to the remote syslog servers with the priority as INFO.

The default log format for Audit Logs:

%t %un %lt %an %ct %li %lp %trt %tri %cn %cht %ot %on %var %ov %nv %add

Unit Name, Log Type, and Log ID are not displayed on the BASIC > Audit Logs page.

IPv4 Example:

2014-02-24 09:05:17.764 -0800 wafbox1 AUDIT Adam GUI 10.11.18.121 24784 CONFIG 166 config SET

204 virtual_ip_config_address 99.99.130.45 virtual_ip_config_interface "" "WAN" []

IPv6 Example:

2014-02-24 10:05:17.764 -0800 wafbox1 AUDIT Adam GUI 2001::117 23390 CONFIG 196 config SET virtual_ip_config_address 2001::2:109 virtual_ip_config_interface "" "WAN" []

Detailed Description

The table below describes each element of an audit log with respect to the above example:

Field Name Example Description

Time 2014-02-24 09:05:17.764 -0800 The time recorded in the following format: yyyy-mm-dd hh:mm:ss.s (one or more digits representing a decimal fraction of a second)TZD(time zone designator which is either Z or +hh:mm or -hh:mm)

Unit Name wafbox1 The name of the unit specified in the Default Hostname field on the BASIC > IP Configuration page.

Log Type AUDIT Specifies the type of log: Web Firewall Log, Access Log, Audit Log, Network Firewall Log or System Log.

Values: WF, TR, AUDIT, NF, SYS

Admin Name Adam The name of the logged in user.

Client Type GUI This indicates that GUI is used as client to access the Barracuda Web Application Firewall.

Transaction Type CONFIG Denotes the type of transaction done by the system administrator.

Values: LOGIN, LOGOUT, CONFIG, COMMAND, ROLLBACK, RESTORE, REBOOT, SHUTDOWN, FIRMWARE UPDATE, ENERGIZE UPDATE, SUPPORT TUNNEL OPEN, SUPPORT TUNNEL CLOSED, FIRMWARE APPLY, FIRMWARE REVERT, TRANSPARENT MODE, UNSUCCESSFUL LOGIN, ADMIN ACCESS VIOLATION.

Transaction ID 166 Specifies the transaction ID for the transaction that makes the persistent change. Note: Events that do not change anything do not have a transaction ID. This is indicated by transaction ID of -1.

Command Name config The name of the command that was executed on the Barracuda Web Application Firewall.

205 Change Type SET Denotes the type of change made to the configuration. Values: NONE, ADD, DELETE, SET.

Object Type virtual_ip_config_address The type of the object which is being modified.

Object Name 99.99.130.45 The name of the object type that is being OR modified. 2001::2:109

Variable virtual_ip_config_interface The internal name of the parameter which is under modification.

Old Value - The value before modification.

New Value WAN The value after modification.

Additional Data [] Provides more information on the parameter changed.

Network Firewall Logs

The network traffic passing through the interfaces (WAN, LAN and MGMT) that matches the configured Network ACL rule are logged under Network Firewall Logs. The log entries provide information about every packet that the Barracuda Web Application Firewall has allowed or denied based on the Action specified in the ACL rule. Using this information, you can identify where the network traffic originated and where it was destined for, and the action applied. These log entries can be viewed on the ADVANCED > Network Firewall Logs page.

The default log format for Network Firewall Logs:

%t %un %lt %sl %p %si %sp %di %dp %act %an %dsc

IPv4 Example:

2014-05-20 00: 56:42.195 -0700 WAF1 NF INFO TCP 99.99.1.117 52676 99.99.79.2 80 ALLOW testacl MGMT/LAN/WAN interface traffic:allow

IPv6 Example:

2014-05-20 02: 51:36.455 -0700 WAF1 NF INFO TCP 2001:4528::231 46739 2001:4528:2::79 80 ALLOW testacl MGMT/LAN/WAN interface traffic:allow

Detailed Description

The table below describes each element of a network firewall log with respect to the above example:

Field Name Example Description

Time 2014-04-10 09:37:58.749 -0700 The date and time at which the event occurred. Date format is Year-Month-Day, and time format is Hours: Minutes:Seconds:Milliseconds.

Unit Name WAF1 The name of the unit specified in the Default Hostname field on the BASIC > IP Configuration page.

Log Type NF Specifies whether it is of type Web Firewall Log, Access Log, Audit Log, Network Firewall Log or System Log.

Values: WF, TR, AUDIT, NF, SYS

206 Severity INFO Defines the seriousness of the attack.

Values:

Protocol TCP The layer 3 protocol type of the corresponding packet.

Source IP 99.99.1.117 The IP address of the source that originated OR the network traffic. 2001:4528::231

Source Port 52676 The port number of source that originated the OR network traffic. 46739

Destination IP 99.99.79.2 The IP address of the destination network or OR host. 2001:4528:2::79

Destination Port 80 The port number of the network or host to which the packet was destined.

ACL Policy ALLOW The ACL policy (Allow or Deny) applied to this ACL rule.

ACL Name testacl The name of the corresponding ACL rule.

Interface MGMT/LAN/WAN interface The incoming network interface traffic passes through.

Details traffic:allow The details of the ACL rule.

Table of Log Formats

The following table describes names and values for each log:

System Logs Web Firewall Logs Access Logs Audit Logs

%ei - Event ID %ai - Service IP %ai - Service IP %add - Additional Data

%ll - Log Level %ap - Service Port %ap - Service Port %an - Admin Name

%lt - Log Type %at - Action %au - Authenticated User %cht - Change Type

%un - Unit Name %ad - Attack Type %br - Bytes Received %ct - Client Type

%ms - Message %adl - Attack Details %bs - Bytes Sent %cn - Command Name

%md - Module Name %ag - Attack Group %ch - Cache Hit %seq - Log ID

207 %t - Time %aid - Attack ID %cu - Certificate User %li - Login IP

%au - Authenticated User %ci - Client IP %lp - Login Port

%ci - Client IP %cp - Client Port %lt - Login Type

%cp - Client Port %c - Cookie %nv - New Value

%fa - Follow-up Action %ct - Content Type %on - Object Name

%seq - Log ID %cs1 - Custom Header 1 %ot - Object Type

%lt - Log Type %cs2 - Custom Header 2 %ov - Old Value

%m - Method %cs3 - Custom Header 3 %t - Time

%p - Protocol %h - Host %tri - Transaction ID

%px - Proxy IP %s - HTTP Status %trt - Transaction Type

%pp - Proxy Port %id - Login ID %un - Unit Name

%r - Referer %seq - Log ID %var - Variable

%ri - Rule ID %lt - Log Type %tarc - Epoch/Unix Time Stamp

%rt - Rule Type %m - Method

%sid - Session ID %p - Protocol

%sl - Severity %pf - Protected

%t - Time %px - Proxy IP

%u - URL %pmf - Profile Matched

%ua - User Agent %pp - Proxy Port

%un - Unit Name %q - Query String

%tarc - Epoch/Unix Time Stamp %r - Referer

%rr - Request Referer

%rtf - Response Type

%sid - Session ID

%si - Server IP

%sp - Server Port

%st - Server Time

%t - Time

%tt - Time Taken

%u - URL

%ua - User Agent

%un - Unit Name

%v - Version

%wmf - WF Matched

%tarc - Epoch/Unix Time Stamp

208 How to Make the Client IP Address Available to the Back-end Server in Proxy Mode en When deployed in proxy mode, by default the Barracuda Web Application Firewall appears as the source IP address in the requests it forwards to the back-end servers. For servers on the back-end needing to access the actual client IP address, the Barracuda Web Application Firewall provides two configurable ways to achieve this:

Client Impersonation X-Forwarded-For Header

While both of these options provide the Client IP address to the servers, you should consider the following before deciding which option to use:

Client Impersonation X-Forwarded-For Header

Provides the Client IP address in the Source IP address of the Provides the Client IP address in the Header "X-Forwarded-For" of request. the Request.

Requires a networking change. Requires a logging change.

Performance impact. en This feature is available only when the Barracuda Web Application Firewall is deployed in Proxy Mode.

To Enable Client Impersonation for a Service:

On the Server:

1. Configure the default gateway of your server to: a. The WAN IP address if you have a One-Arm proxy deployment. b. The LAN IP address if you have a Two-Arm proxy deployment.

If the units are in cluster and Client Impersonation is enabled, the default gateway of your server should be pointing to an additional IP address created on:

WAN subnet on the Barracuda Web Application Firewall in One-Arm Proxy deployment, OR LAN subnet on the Barracuda Web Application Firewall in Two-Arm Proxy deployment.

On the web interface of the Barracuda Web Application Firewall:

To Use the Client IP address from the X-Forwarded-For Header

By default, the Client IP Address is inserted by the Barracuda Web Application Firewall in the request Header "X-Forwarded-For" when the request is forwarded to the back-end server.

To use the embedded IP Address with Apache servers or with IIS 7 or IIS 7.5 servers, refer to the following articles:

Logging Actual Client IP Address on the Apache Server Logging Actual Client IP Address In the IIS 7 and IIS 7.5 Server

How to Log Client IP Address when the Barracuda Web Application Firewall is Deployed Behind a Proxy

If the Barracuda Web Application Firewall is deployed behind a Proxy server, all requests have their client IP address as the address of the Proxy server, which is logged as the Client IP on the BASIC > Access Logs page. To log the actual client IP address, specify the header name

209 appended by the Proxy server which contains the actual client IP address in the Header for Client IP Address field on the BASIC > Services pa ge.

Steps To Configure the Header Name:

1. Edit the Service from the BASIC > Services page. 2. Scroll down to the Basic Security section and specify the header name in the Header for Client IP Address field. The standard headers used to store the actual client IP address are:

X-Forwarded-For X-Client-IP Specify values for other fields as required and click Save Changes. For more information on how to edit a Service, see Step 3: Configuring Basic Service Settings.

If the Proxy is appending a custom header, then specify that header in the Header for Client IP Address field.

When a request is received, the Barracuda Web Application Firewall gets the actual client IP address from the specified header and displays it in the Client IP field of the Access Logs.

For example, consider the client IP addresses 174.15.230.2 and 174.15.230.3, and proxy IP address 174.15.230.254. When the client sends a request, the proxy receives the request and stores the IP address of the client in the X-Forwarded-For or X-Client-IP header, and forwards the request to the Barracuda Web Application Firewall. The Barracuda Web Application Firewall extracts the client IP address from the specified header and displays it in the Access Logs.

Scenario 1:

210 Scenario 2:

211 ja Barracuda Web Application FirewallIPIPIP2

X-Forwarded-For

212 IP

X-Forwarded-For

IPIP X-Forwarded-ForIP

en This feature is available only when the Barracuda Web Application Firewall is deployed in Proxy Mode.

To Enable Client Impersonation for a Service:

On the Server:

1. Configure the default gateway of your server to: a. The WAN IP address if you have a One-Arm proxy deployment. b. The LAN IP address if you have a Two-Arm proxy deployment.

If the units are in cluster and Client Impersonation is enabled, the default gateway of your server should be pointing to an additional IP address created on:

WAN subnet on the Barracuda Web Application Firewall in One-Arm Proxy deployment, OR LAN subnet on the Barracuda Web Application Firewall in Two-Arm Proxy deployment.

On the web interface of the Barracuda Web Application Firewall:

X-Forwarded-ForIP

Barracuda Web Application FirewallX-Forwarded-ForIP

ApacheIIS 7/7.5IP

Logging Actual Client IP Address on the Apache Server Logging Actual Client IP Address In the IIS 7 and IIS 7.5 Server

Barracuda Web Application FirewallIP

Barracuda Web Application FirewallIP BASIC > Access Logs Client IPIPIPBASIC > ServicesHeader for Client IP Address

1. BASIC > Services 2. Basic SecurityHeader for Client IP AddressIP

X-Forwarded-For X-Client-IP Save Changes3:

Header for Client IP Address

Barracuda Web Application FirewallIPAccess LogsClient IP

213 IP174.15.230.2174.15.230.3IP174.15.230.254X-Forwarded-ForX-Client-IPIPBarracuda Web Application FirewallBarracuda Web Application FirewallIP

214 Configuring Client Impersonation en This feature is available only when the Barracuda Web Application Firewall is deployed in Proxy Mode.

To Enable Client Impersonation for a Service:

215 On the Server:

1. Configure the default gateway of your server to: a. The WAN IP address if you have a One-Arm proxy deployment. b. The LAN IP address if you have a Two-Arm proxy deployment.

If the units are in cluster and Client Impersonation is enabled, the default gateway of your server should be pointing to an additional IP address created on:

WAN subnet on the Barracuda Web Application Firewall in One-Arm Proxy deployment, OR LAN subnet on the Barracuda Web Application Firewall in Two-Arm Proxy deployment.

On the web interface of the Barracuda Web Application Firewall:

1. From the BASIC > Services page identify the desired Service. 2. Click Edit next to the Server associated with that Service. The Server (Basic Configuration) window appears. 3. Scroll down to the Server (Advanced Configuration) section, and set Client Impersonation to Yes. 4. Click Save Changes. Logging Actual Client IP Address on the Apache Server en To extract and log the actual client IP address from the X-Forwarded-For header of a request using an Apache server, make the following changes to the server:

1. Log into the Apache server. 2. Go to /etc/httpd/conf or /usr/local/apache2/conf path and open the file httpd.conf. 3. Search for the string: “LogFormat “%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined” 4. Change the %h to %{X-Forwarded-For}i. The string now appears as “LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined” 5. Save the file and restart apache or httpd. Logging Actual Client IP Address In the IIS 7 and IIS 7.5 Server en When the Barracuda Web Application Firewall is configured in Proxy mode, it uses the LAN/WAN IP address to communicate with the back-end server. Hence, the back-end server will not see the actual client IP address coming from clients. By default, the Barracuda Web Application Firewall forwards the client IP address as the header X-Forwarded-For.

To log the actual client IP address instead of the WAN IP address (in case of One-Arm Proxy), or LAN IP address (in case of Two-Arm Proxy) of the Barracuda Web Application Firewall in the IIS logs, do the following:

1. Download and Install the Microsoft Advanced Logging extension on the IIS 7.5 server to log the client IP address in IIS 7.5. Alternatively, download the 64bit MSI Package. 2. After installation, open IIS Manager, select the server root and then Advanced Logging.

Select the individual website if you wish to enable and configure advanced logging options at the site level instead of server level.

216 2.

3. Click Enable Advanced Logging under Actions.

4. Click Edit Logging Fields under Actions.

5. On the Edit Logging Fields window, click Add Field and then enter the details as shown in the image below in the Add Logging Field window.

217 5.

The Source name should be same as the value specified in Header for Client IP Address on the BASIC > Services page.

6. Click OK, and then scroll down and verify that the new Logging Field is listed.

7. Click Add Log Definition under Actions.

218 7.

8. On the Log Definition window, enter the Base file name and click Select Fields.

219 8.

9. On the Select Logging Fields window, select the Client IP Header logging field created in step 6 and click OK.

10. Click Apply and then click Return to Advanced Logging under Actions.

11.

220 11. Now, the Client IP Header log definition will be listed on the Advanced Logging window. Select Client IP Header, right click and then select View Log Files.

12. The advanced logs should be available in the default location or the location you specified.

13. Open the log file and view the Client IP address logging.

221 13.

14. If you want to log additional fields, add the required logging fields as mentioned in step 8 and then repeat the steps from 9 to 13.

How to Mask Sensitive Data in Logs en Data masking security of the Barracuda Web Application Firewall obscures sensitive data elements before logging them. Configured parameters like social security numbers, credit card information, or other proprietary data in the URL parameters of a request can be protected from unauthorized exposure in the logs. Data masking is configured for an application using parameter names to specify sensitive data. Logged data appears in BASIC > Access Logs, with the sensitive data overwritten by 'X'es.

222 Masking cannot be applied to sensitive data in custom parameters or custom headers. Once masked, the original data cannot be retrieved, recovered, or restored.

To configure Data Masking, use the Mask Sensitive Data section of the WEBSITES > Advanced Security page.

Edit the service for which masking is necessary. In the Mask Sensitive Data window, enter the names of sensitive parameters. You can provide multiple parameter names separated by commas with no spaces between (e.g.cardId,securityNumber,password). Save Changes. Reporting en You can configure and generate reports of various types, based on all logged information, which helps in managing day-to-day operation. The Barracuda Web Application Firewall reports are broadly classified into four functional groups, each containing a predefined set of report types. Select a Report Group, then a corresponding Report Type from the drop-down list to generate/schedule a report. The four report groups are:

Security and Traffic Reports

Security and Traffic reports contain the Web attack prevention activity performed by the Barracuda Web Application Firewall. Note: Some report types (namely: Top Clients by Bandwidth, Top URL by Bandwidth, Top Domains by Bandwidth, Top Services by Bandwidth, and Top Entry Pages) will not include data corresponding to URLs containing files with extension jpg, png, gif, ico, css, js.

Audit Reports

Audit reports contain server details and the login/logout activities performed by different user roles.

Config Summary Reports

Config Summary reports contain:

Performance of the Barracuda Web Application Firewall features such as Load Balancing, Rate Control, Learning, etc. Details of the digital certificates like issuing date, expiry date, and associated services. Details of accounts, their users, privileges assigned to them, permitted operations, etc. Names of the URL Profiles, Parameter Profiles, Header ACLs and URL ACLs associated with a service.

PCI Reports

PCI reports detail compliance with PCI (Payment Card Industry) standards and display:

Combined details of the PCI attacks such as top attacking Clients, and top attacked Services, Domains, and URLs. Details of the PCI directives and the Barracuda Web Application Firewall compliance with those directives.

Generating Reports

Use BASIC > Reports to choose different reports that can help you keep track of the activity of the Barracuda Web Application Firewall. Generate a report on demand, or configure the Barracuda Web Application Firewall to automatically generate reports on a daily, weekly, or monthly basis, emailing the reports to configured email addresses. For information on aggregating reports across multiple Barracuda Web Application Firewall appliances, see How to Set Up Barracuda Cloud Control. Reports can be based on user-activity, content, or actions.

For detailed descriptions, see the online help on the BASIC > Reports page.

Only one-time reports can be displayed when report processing is done. Scheduled reports are emailed when done.

How to Set Up Barracuda Cloud Control en

223 Barracuda Cloud Control enables administrators to manage, monitor and configure multiple Barracuda Web Application Firewall at one time from one console. The same tabbed pages are available on Barracuda Cloud Control for managing all aspects of your Barracuda Web Application Firewall configuration that you see in each individual web interface, and you can create aggregated reports for multiple devices from the Barracuda Cloud Control console. You can connect one or more Barracuda Web Application Firewalls to Barracuda Cloud Control by doing the following:

1. If you don't already have an account with Barracuda Networks, see Create a Barracuda Cloud Control Account. 2. Make a note of your username (email address) and password. 3. Log into your Barracuda Web Application Firewall as the administrator. From the ADVANCED > Firmware Upgrade page, check to make sure you have the latest firmware installed. If not, download and install it now. 4. From the ADVANCED > Cloud Control page, enter the Barracuda Networks username and password you created and click Yes to connect to Barracuda Cloud Control. Note that your Barracuda Web Application Firewall can connect with only one Barracuda Cloud Control account at a time. 5. Log into Barracuda Cloud Control with your username and password and you will see your Barracuda Web Application Firewall statistics displayed on the BASIC > Status page. To access the web interface of your Barracuda Web Application Firewall, click on the link in the Products column in the Appliance Control Center pane on the left side of the page. Or you can click on the product name in the Product column of the Unit Health pane on the right side of the page. 6. Follow steps 3 and 4 to connect every subsequent Barracuda Web Application Firewall to Barracuda Cloud Control.

To disconnect your Barracuda Web Application Firewall from Barracuda Cloud Control, from the ADVANCED > Cloud Control page, enter the Barracuda Cloud Control username and password and click No for Connect to Barracuda Cloud Control.

For details on using Barracuda Cloud Control, please see Barracuda Cloud Control - Overview. Receiving Trap Messages and System Alerts en From the BASIC > Administration page under Trap Receivers, specify the client IP address and port number to receive trap messages. An alert email is sent to the recipient’s email address, if the email is configured in the Email Notifications section on the BASIC > Administration page.

Trap defines the SNMP trap for generating customized alerts for an event. The default alerts and their descriptions are given in the following table:

Trap Name Object ID Description

TempCritical 1.3.6.1.4.1.20632.8.1.3 Temperature of any one of CPU1, CPU1 VRM, CPU2, CPU2 VRM, board or RAM exceeded its threshold value.

TempHigh 1.3.6.1.4.1.20632.8.1.4 Temperature of any one of CPU1, CPU1 VRM, CPU2, CPU2 VRM, board or RAM is higher than 80C.

SystemFailOver 1.3.6.1.4.1.20632.8.1.5 System failed over to redundant system.

SwitchingToMaintMode 1.3.6.1.4.1.20632.8.1.6 System is switching to Maintenance mode.

FanDead 1.3.6.1.4.1.20632.8.1.7 One of the system fan is dead.

DataPortLinkDown 1.3.6.1.4.1.20632.8.1.8 Data port link (interface1 or interface2) is down.

ServerDown 1.3.6.1.4.1.20632.8.1.9 Server is down.

PeerDown 1.3.6.1.4.1.20632.8.1.10 Peer is down in redundant environment.

DataPortLinkUp 1.3.6.1.4.1.20632.8.1.11 Data port link (interface1 and interface2) is up.

ServerUp 1.3.6.1.4.1.20632.8.1.12 Server is up.

PeerUp 1.3.6.1.4.1.20632.8.1.13 Peer is up in redundant environment.

CookieEncryptionKeyAboutToExpire 1.3.6.1.4.1.20632.8.1.16 Shared secret key is about to expire.

CookieEncryptionKeyExpired 1.3.6.1.4.1.20632.8.1.17 Shared secret key has expired.

224 FirmwareStorageHigh 1.3.6.1.4.1.20632.8.1.18 Firmware storage exceeds 75%.

LogStorageHigh 1.3.6.1.4.1.20632.8.1.19 Log storage exceeds 85%.

RaidDegrading 1.3.6.1.4.1.20632.8.1.20 One of the RAID arrays is degrading.

In addition to the above trap messages, the Barracuda Web Application Firewall sends out emails for the following three system alerts:

Your Energize Update subscription is about to expire. New firmware updates are available. Your system is low on disk space.

Apart from these, you can use the SNMP GET commands to view important statistics of the Barracuda Web Application Firewall. For information on the SNMP GET commands, refer to SNMP GET Commands. System Log Messages en The following is the list of system log messages which includes:

Log Category - The Severity Level of the log. Log ID - The Event ID of the log. Log Message - Description about the log.

Log Category Log ID Log Message

SYSTEM

LOG_NOTICE 1003 Mem Start: SCB , Low , High

LOG_INFO 1012 EVENTID_SYS_SHUTDOWN - Secure Traffic Manager is exiting

LOG_CRIT 1013 System startup failed at initializing: . Switching to maintenance mode

LOG_NOTICE 1024 Activate: Default boot image set to

LOG_ALERT 1119 (System is getting real hot) or (Possible overheating at device temp reading=)

LOG_INFO 1122 This Hardware = is not on the Board

LOG_ALERT 1125 SBC PII temp overshoot.

LOG_ALERT 1126 System highest temp has reached =

LOG_ALERT 1128 In Fan Group Fan is Running at rps which is less than expected

LOG_NOTICE 1130 HW: Changing FAN speed -> TempReadings ( ])

LOG_NOTICE 1203 SBC FAN detected rpm =

225 LOG_WARN 41001 Cookie Encryption Key is going to expire within days", REMAINING_DAYS_FOR_EXPIRY( pSharedKey->keyExpiryTimeout,curTimeInS ecs)

MONITOR

LOG_CRIT 1014 [MON]: Shutting down all services

LOG_NOTICE 1014 [MON]: Shutting down services completed

LOG_NOTICE 1015 [MON]: Restarting services

LOG_NOTICE 1015 [MON]: Restarting services completed

LOG_ERROR 27001 SetMonitorAttributes: NULL monitor id\n

LOG_INFO 27001 SetMonitorAttributes: monitor (id 0x) already exists. Deleting it

LOG_INFO 27002 Monitor (0x - ) status is FEHC_INACTIVE

LOG_INFO 27002 Monitor (0x) to freed

ARP

LOG_WARN 4011 arprequest for failed with no memory

LOG_INFO 4012 ether address is broadcast for IP address

LOG_ERROR 4013 is using my IP address

LOG_ERROR 4014 Failed to find route for arp response to client

LOG_WARN 4015 arp: attempts to modify permanent entry for on

LOG_WARN 4016 arp_rtrequest: bad gateway value

LOG_ERROR 4017 arpresolve: can't allocate info for , rt=

LOG_ERROR 4017 arp_rtrequest: malloc failed

Caching (CACHE)

LOG_NOTICE 6001 System Low on Memory: Adjusting Cache Parameters - Current Max:, High:, Safe

LOG_NOTICE 6001 System Low on Memory: Adjusting Cache Parameters - New Max:, High:, Safe

LOG_NOTICE 6002 Cache Purged

226 LOG_NOTICE 6003 Cache purge failed: instance , thid , table

, target , collected

Load Balancer (LB)

LOG_ALERT 7005 Server : is enabled

LOG_ALERT 7006 Server : is disabled. New mode

LOG_NOTICE 7007 Server : is created

LOG_ALERT 7008 Server : is deleted

WEBLOG

LOG_WARN 9001 Configurations for start or stop time *MAY* not be proper.

LOG_ERROR 9003 Error: Unable to establish control connection.

LOG_ERROR 9004 Error: Unable to establish data connection

LOG_ERROR 9005 Error: Unable to establish ssl control connection

LOG_ERROR 9006 Error: Unable to authenticate the user

LOG_ERROR 9007 Error: Unable to transfer data to ftp server:

LOG_ERROR 9009 Connection to failed, error code =

LOG_ERROR 9009 SSL Connection to failed

LOG_ERROR 9010 Out of memory for formatting logs

LOG_INFO 9011 ---- START OF LOG STATS FOR LOGS EXPORTED TO : ----

LOG_INFO 9011 Connection to failed, error code =

LOG_INFO 9011 Total number of logs:

LOG_INFO 9011 Total number of formatted:

LOG_INFO 9011 Total number of dropped:

LOG_INFO 9011 Total number of long url logs:

LOG_INFO 9011 Total number of control connection attempts to the ftp server:

LOG_INFO 9011 Total number of control connections successes:

LOG_INFO 9011 Total number of data connections:

LOG_INFO 9011 Total number of 4xx errors: < number >

LOG_INFO 9011 Total number of 5xx errors:

LOG_INFO 9011 Total number of ftp failures:

227 LOG_INFO 9011 Total number of requests: , Total duration: secs

LOG_INFO 9011 ---- END OF LOG STATS FOR LOGS EXPORTED TO : ----

LOG_INFO 9012 Web Logging enabled

LOG_NOTICE 9013 Dropping logs, running low on memory

LOG_ERROR 9013 Error in hash generation or encryption

LOG_NOTICE 9014 Logging parameters are set for vip :

LOG_INFO 9017 FTP Session to , status code =

LOG_ERROR 9018 Unable to log the request since FTP server is slow or unreachable

LOG_ERROR 9018 Dropping logs since queue is full

LOG_ERROR 9019 Signature generation of logs failed

Event Manager (EVM)

LOG_ERROR 11001 Event Manager startup failure: could not handle signals

LOG_INFO 11005 Forwarding log messages to syslog host[]=, facility= (socket=)

LOG_ERROR 11007 EnableSyslogService: create socket failed

LOG_ERROR 11008 fopen :

LOG_ERROR 11009 write failed

SAPD

LOG_ERROR 12001 Local GATEWAY_NAME not found

LOG_ERROR 12001 Digest failed

LOG_ERROR 12001 No Monitoring Dispatcher found

LOG_ERROR 12001 To execute this operation, peer node should be non-operational

LOG_ERROR 12001 Configuring Secure Traffic Manager Succeeded

LOG_ERROR 12001 Failed to resolve type of clear stats

LOG_ERROR 12002 IP Interface

LOG_ERROR 12002 Acl

LOG_ERROR 12002 Service

LOG_ERROR 12002 Route

LOG_ERROR 12002 Duplicate route

LOG_ERROR 12002 Duplicate parameter

228 LOG_ERROR 12002 VSite

LOG_ERROR 12002 MAC device

LOG_ERROR 12002 Gateway is not directly reachable on any interface

LOG_ERROR 12002 Ips

LOG_ERROR 12002 Route

LOG_ERROR 12002 Target doesn't exist

LOG_ERROR 12002 Backup

LOG_ERROR 12002 Deleting RuleBackup

LOG_ERROR 12002 RuleBackup delete succeeded

LOG_ERROR 12002 Deleting ServerBackup

LOG_ERROR 12002 ServerBackup delete succeeded

LOG_ERROR 12002 Unable to delete ServerBackup

LOG_ERROR 12002 Deleting Server

LOG_ERROR 12002 Server delete succeeded

LOG_ERROR 12002 Unable to delete Server

LOG_ERROR 12002 Deleting application key

LOG_ERROR 12002 Application key delete succeeded

LOG_ERROR 12002 Unable to delete application key

LOG_ERROR 12002 Deleting QOS class

LOG_ERROR 12002 QOS class delete succeeded

LOG_ERROR 12002 Unable to delete QOS class

LOG_ERROR 12002 Deleting Service

LOG_ERROR 12002 Service delete succeeded

LOG_ERROR 12002 Unable to delete Service

LOG_ERROR 12002 Deleting Acl

LOG_ERROR 12002 Acl delete succeeded

LOG_ERROR 12002 Unable to delete Acl

LOG_ERROR 12002 Deleting Nat entry

LOG_ERROR 12002 Nat entry delete succeeded

LOG_ERROR 12002 Unable to delete Nat entry

LOG_ERROR 12002 Deleting Arp entry

LOG_ERROR 12002 Arp entry delete succeeded

LOG_ERROR 12002 Deleting Route

LOG_ERROR 12002 Route delete succeeded

229 LOG_ERROR 12002 Unable to delete Route

LOG_ERROR 12002 Deleting Arp entry

LOG_ERROR 12002 Arp entry delete succeeded

LOG_ERROR 12002 Unable to delete Arp entry

LOG_ERROR 12002 Deleting Route

LOG_ERROR 12002 Route delete succeeded

LOG_ERROR 12002 Unable to delete Route

LOG_ERROR 12002 Deleting Interface

LOG_ERROR 12002 Interface delete succeeded

LOG_ERROR 12002 Unable to delete Interface

LOG_ERROR 12002 Deleting VirtualHost

LOG_ERROR 12002 VirtualHost delete succeeded

LOG_ERROR 12002 Unable to delete VirtualHost

LOG_ERROR 12002 Adding VirtualHost

LOG_ERROR 12002 VirtualHost add succeeded

LOG_ERROR 12002 Unable to add VirtualHost

LOG_ERROR 12002 Adding Interface

LOG_ERROR 12002 Interface add succeeded

LOG_ERROR 12002 Unable to add Interface

LOG_ERROR 12002 Interface modify succeeded

LOG_ERROR 12002 Unable to modify Interface

LOG_ERROR 12002 Adding Arp entry

LOG_ERROR 12002 Arp entry add succeeded

LOG_ERROR 12002 Unable to add Arp entry

LOG_ERROR 12002 Adding Route

LOG_ERROR 12002 Route add succeeded

LOG_ERROR 12002 Unable to add Route

LOG_ERROR 12002 Adding Arp entry

LOG_ERROR 12002 Arp entry add succeeded

LOG_ERROR 12002 Unable to add Arp entry

LOG_ERROR 12002 Arp entry modify succeeded

LOG_ERROR 12002 Unable to modify Arp entry

LOG_ERROR 12002 Adding Route

LOG_ERROR 12002 Route add succeeded

LOG_ERROR 12002 Unable to add Route

230 LOG_CRIT 12003 Failed to retrieve initial groups

LOG_INFO 12003 Failed to retrieve User’s Realms

LOG_ERROR 12004 Can't store rule ID

LOG_INFO 12004 Adding RuleGroup

LOG_ERROR 12005 Can't get " NEXTSAPID ": missing " SAPID " or error retrieving " SAPID

LOG_ERROR 12007 $NC_INSTALL_ROOT not set

LOG_ERROR 12007 Target doesn't exist

LOG_ERROR 12007 HttpMon

LOG_ERROR 12007 Failed to create server

LOG_ERROR 12007 SetServerConnAttr failed

LOG_ERROR 12007 SetServerRedirectAttr failed

LOG_ERROR 12007 SetServerOutOfBandMonitorAttr failed

LOG_ERROR 12007 SetServerMonitorAttr failed

LOG_ERROR 12007 SetServerLBAttr failed

LOG_ERROR 12007 StartServer failed

LOG_ERROR 12007 SetServerSSLServicePolicy failed

LOG_ERROR 12007 SetServerSSLServiceOn failed

LOG_ERROR 12007 SetServerSSLServiceOff failed

LOG_ERROR 12007 ActiveServerOutOfBandMonitorAttr failed

LOG_ERROR 12007 Failed to delete server

LOG_ERROR 12007 Failed to reset server ip, port or vlan

LOG_ERROR 12007 Failed to look up server

LOG_ERROR 12007 SetServerTcpMonitorAttr failed

LOG_ERROR 12007 EnableServer failed

LOG_ERROR 12007 DisableServer failed

LOG_ERROR 12007 ActiveServerOutOfBandMonitorAttr failed

LOG_ERROR 12007 Failed to delete server

LOG_ERROR 12007 Failed to reset server ip, port or vlan

LOG_ERROR 12007 Failed to look up server

LOG_ERROR 12007 SetServerTcpMonitorAttr failed

LOG_ERROR 12007 EnableServer failed

LOG_ERROR 12007 DisableServer failed

LOG_ERROR 12007 ActiveServerOutOfBandMonitorAttr failed

LOG_ERROR 12007 Server

231 LOG_ERROR 12008 Duplicate server

LOG_ERROR 12008 Attaching server

LOG_ERROR 12008 Attaching server succeeded

LOG_ERROR 12008 Failed to look up back-end server

LOG_ERROR 12008 Detaching server

LOG_ERROR 12008 Detaching server succeeded

LOG_ERROR 12009 OUT OF MEMORY !!! Asserting…

LOG_ERROR 12009 Error in reading ReadXmlFileIntoString

LOG_ERROR 12009 sapIndex.AddFromXMLStr (..., SAP::nsap) failed

LOG_ERROR 12009 Could not find mgmt container

LOG_ERROR 12009 Could not find ports/ethernet container

LOG_ERROR 12009 Could not find hardware container

LOG_ERROR 12009 Could not find box container

LOG_ERROR 12009 Could not find linux interface

LOG_ERROR 12009 Could get local box path

LOG_ERROR 12009 AddSAP for box2SAP failed

LOG_ERROR 12009 RecurAddChldOfAggSAP for box2 failed

LOG_ERROR 12009 SetBoxParametersFromOrgTree failed (box2) !

LOG_ERROR 12009 SetBoxName failed (box2) !

LOG_ERROR 12009 SetBoxParametersFromOrgTree failed !

LOG_ERROR 12009 In SetBoxParametersFromOrgTree. Invalid path specified

LOG_ERROR 12009 Could not find linux interface

LOG_ERROR 12009 There should have been 3 phy. interfaces.

LOG_ERROR 12009 SetParameterValuesUnderPath failed !

LOG_ERROR 12009 in SetBoxParametersFromOrgTree. UpdateDefaultRoute failed !

LOG_ERROR 12009 In GetClearConfTree. SetInitValuesForCC failed !

LOG_ERROR 12009 In UpdateDefaultRoute. Should have matched only one route !

LOG_ERROR 12009 In UpdateDefaultRoute. tmpIdx.GetAggSAP failed !

LOG_ERROR 12009 In UpdateDefaultRoute. sapIndex.GetParamSAP failed !

LOG_ERROR 12009 In UpdateDefaultRoute. tmpIdx.GetParamSAP failed !

232 LOG_ERROR 12009 In UpdateDefaultRoute. tmpIdx.ModifySAP failed !

LOG_ERROR 12009 In GetMD5HashForFile. CheckIfValidFileToRetrieve failed

LOG_ERROR 12009 GetPathForUser failed !

LOG_ERROR 12009 Error. AddFromXMLStr failed !

LOG_ERROR 12009 Cannot modify a read-only node

LOG_ERROR 12009 Couldn't read old bind value

LOG_ERROR 12009 Can't replace the root / (session.cc)in PutSAPTree. GetFatherPath failed

LOG_ERROR 12009 Can't replace the root /

LOG_ERROR 12009 Error invalid operation type

LOG_ERROR 12009 No path provided

LOG_ERROR 12009 Failed due to insufficient user permission

LOG_ERROR 12009 Internal error while adding a child node!

LOG_ERROR 12009 Internal error: while parsing query!

LOG_ERROR 12009 No Parameter found for querying

LOG_ERROR 12009 No path provided

LOG_ERROR 12009 Failed due to insufficient user permission

LOG_ERROR 12009 Internal error while adding a child node!

LOG_ERROR 12009 Parameter must be specified in a Container.

LOG_ERROR 12009 ERROR ! No column names specified!

LOG_ERROR 12009 Invalid or non existent home dir found !

LOG_ERROR 12009 CheckPermForInterNodes failed

LOG_ERROR 12009 GetPathForUser failed

LOG_ERROR 12009 Context doesn't exist !

LOG_ERROR 12009 In CheckPermForQuery. AclMatchAuth failed!

LOG_ERROR 12009 in CheckPermForInterNodes. GetHomeDirForUser failed

LOG_ERROR 12009 In CheckPermForInterNodes. AclMatchAuth failed!

LOG_ERROR 12009 in CheckPermAndSet. GetPermissionForUser failed

LOG_ERROR 12009 GetPathForUser failed !

LOG_ERROR 12009 CheckPermForInterNodes failed

LOG_ERROR 12009 Non-existing path corresponding to global parameters

233 LOG_ERROR 12009 In CheckPermForQuery. AclMatchAuth failed!

LOG_ERROR 12009 Error in SystemBackUp. failed to acquire mutex.

LOG_ERROR 12009 in RecurAddAcl. GetRelativePath failed !

LOG_ERROR 12009 Session::GetCommandsForUser.

LOG_ERROR 12009 Empty peer gateway key

LOG_ERROR 12009 Setting of peer gateway key failed

LOG_ERROR 12009 in CheckReadPermOnParent. GetFatherPath failed

LOG_ERROR 12009 in GetAbsBindPath. GetHomeDirForUser failed !

LOG_ERROR 12009 GetWacBoxVersion failed !

LOG_ERROR 12009 GetInterfaceAddress failed !

LOG_ERROR 12009 CheckPerm failed for path

LOG_ERROR 12009 In GetConfFile. GetConfFileIntoStr failed

LOG_ERROR 12009 In GetClearConfTree. genClearConfig.GetClearConfTree failed

LOG_ERROR 12009 Invalid conf file specified for retrieval

LOG_ERROR 12009 Failed due to insufficient user permission

LOG_ERROR 12009 Unable to allocate memory

LOG_ERROR 12009 OUT OF MEMORY !!! Asserting...

LOG_ERROR 12009 in PutSAPTree. GetHomeDirForUser failed !

LOG_ERROR 12009 In PutSAPTree. Invalid path specified !

LOG_ERROR 12009 In PutSAPTree. Path not found in tmp sapIndex

LOG_ERROR 12009 in PutSAPTree. Invalid node in treediff result

LOG_ERROR 12009 in PutSAPTree. No acl perm

LOG_ERROR 12009 in PutSAPTree.ModifySAP failed

LOG_ERROR 12009 in PutSAPTree. Trying to modify a read-only node

LOG_ERROR 12009 in PutSAPTree.ModifySAP failed

LOG_ERROR 12009 in PutSAPTree.AddChildSAP failed

LOG_ERROR 12009 in PutSAPTree.DeleteSAPTree failed

LOG_ERROR 12009 PutRootSAPTree failed in GetAggSAP

LOG_ERROR 12010 Failed to set SetVipSSLEphemeralKey

234 LOG_ERROR 12010 IP Interface

LOG_ERROR 12010 Policy is bound to more than one QOS class

LOG_ERROR 12010 Rule Group

LOG_ERROR 12010 Duplicate application

LOG_ERROR 12010 Failed to set " SERVICE_APP_PROTOCOL "

LOG_ERROR 12010 Failed to set " SERVICE_APP_PROTOCOL " on

LOG_ERROR 12010 Adding qos class

LOG_ERROR 12010 Setting qos class

LOG_ERROR 12010 Unsetting qos class

LOG_ERROR 12010 Failed to find back-end server in server list

LOG_ERROR 12010 Failed to set " SERVICE_APP_PROTOCOL " off

LOG_ERROR 12010 Failed to set " SERVICE_APP_PROTOCOL " on

LOG_ERROR 12010 Failed to look up Secure Traffic Manager object

LOG_ERROR 12011 Couldn't add paramSAP, name:

LOG_ERROR 12013 Failed to allocate space for integer argument

LOG_ERROR 12013 Failed to allocate space for float argument

LOG_ERROR 12013 Failed to allocate space for long long argument

LOG_ERROR 12013 Failed to allocate space for char string argument

LOG_ERROR 12014 Unable to get import/export handle

LOG_ERROR 12014 Unable to set error handle

LOG_ERROR 12014 Couldn't get file handle

LOG_ERROR 12014 Set file handle failed

LOG_ERROR 12014 Couldn't ready curl for upload

LOG_ERROR 12014 Couldn't set file size

LOG_ERROR 12014 Unsupported method

LOG_ERROR 12014 Couldn't set target

LOG_ERROR 12015 SSL Version 3 enabled

LOG_ERROR 12015 TLS enabled

LOG_ERROR 12015 no key/cert bindings found

LOG_ERROR 12015 Attempt to use unsupported key type

LOG_ERROR 12015 unable to extract certificate

235 LOG_ERROR 12015 unable to extract issuer certificate

LOG_ERROR 12015 unable to extract key

LOG_ERROR 12015 unable to extract exchange key

LOG_ERROR 12015 error extracting trusted certificate

LOG_ERROR 12018 Invalid Path Specified

LOG_ERROR 12018 Internal Error

LOG_ERROR 12018 Invalid Path Specified

LOG_ERROR 12019 Unable to allocate memory

LOG_ERROR 12021 in ParamCmp. Cant modify node attributes

LOG_ERROR 12021 Incorrect permissions given to root role

LOG_ERROR 12021 Cannot modify ACL for root node

LOG_ERROR 12021 Cannot give write permissions for a read-only node.

LOG_ERROR 12021 managementSystemErrorMessage

LOG_ERROR 12021 in TreeDiff::GetDiff. Invalid path passed !

LOG_ERROR 12021 in GetDiff. Retrieved inv. node

LOG_ERROR 12021 managementSystemErrorMessage

LOG_ERROR 12021 in GetDiff. Retrieved inv. node

LOG_ERROR 12021 in GetDiff. inv. node

LOG_ERROR 12021 in GetDiff.AddInterNodes fail!

LOG_ERROR 12021 in GetDiff. inv. node

LOG_ERROR 12021 In GetDiff. invalid return from SAPCmp!

LOG_ERROR 12021 in ParamCmp. Cant modify node attributes

LOG_ERROR 12021 in AggCmp. Cant modify node attributes

LOG_ERROR 12021 Incorrect permissions given to root role

LOG_ERROR 12021 Cannot modify ACL for root node

LOG_ERROR 12021 Cannot give write permissions for a read-only node

LOG_ERROR 12021 in TreeDiff::GetDiff. Invalid path passed !

LOG_ERROR 12021 in GetDiff. Retrieved inv. node

LOG_ERROR 12021 in GetDiff. AddInterNodes fail!

LOG_ERROR 12024 Backup rule group cannot be the same as the primary rule group

LOG_ERROR 12027 Value for " CACHE_SVC_MAX_OBJECT_SIZE " too large

236 LOG_ERROR 12028 Invalid value for " NET_INTERFACE_OPERATION_STATUS " . Using default

LOG_ERROR 12028 Only 1 " BINDING " allowed if

LOG_ERROR 12028 Interface add

LOG_ERROR 12028 failed

LOG_ERROR 12028 Interface add

LOG_ERROR 12028 failed

LOG_ERROR 12028 Interface add

LOG_ERROR 12028 succeeded

LOG_ERROR 12028 Set media mode

LOG_ERROR 12028 failed

LOG_ERROR 12028 Unable to set media-mode

LOG_ERROR 12029 Failed to create http monitor

LOG_ERROR 12030 Failed to look up primary server

LOG_ERROR 12030 Failed to look up backup server

LOG_ERROR 12031 Failed to add route on due to: netmask doesn't match route address

LOG_ERROR 12031 Failed to add route

LOG_ERROR 12031 due to

LOG_ERROR 12031 netmask doesn't match route address

LOG_ERROR 12031 Route add

LOG_ERROR 12031 succeeded (already exists)

LOG_ERROR 12031 not added, already exists

LOG_ERROR 12031 Route delete

LOG_ERROR 12031 failed due to

LOG_ERROR 12031 Route delete

LOG_ERROR 12031 Route(mgmt-port)

LOG_ERROR 12031 (mgmt-port)

LOG_ERROR 12031 (mgmt-port) succeeded

LOG_ERROR 12031 Modify Route: Unsupported operation

LOG_ERROR 12032 Failed to add route

LOG_ERROR 12033 Unsupported operation

LOG_ERROR 12038 Unexpected REN_AGG

LOG_NOTICE 12040 Processing messages in the list

LOG_ERROR 12041 Connection NULL in NC_RemoteCaller::getResponseHandle

237 LOG_CRIT 12049 Peer IP Address is NULL. Exiting

LOG_CRIT 12049 $NC_HEARTBEAT_DIR not set. Exiting

LOG_ERROR 12049 Can not parse cluster info

LOG_NOTICE 12049 Initiating login to Local SAPD after updating configuration

LOG_CRIT 12049 Can not relogin to SAPD. Exiting

LOG_NOTICE 12049 Getting Cluster Information after updating configuration

LOG_INFO 12049 Received SIGTERM

LOG_INFO 12049 Received SIGALRM

LOG_CRIT 12049 Going to maintenance mode

LOG_ERROR 12049 Can not send message to heartbeat. Heartbeat Socket is NULL

LOG_NOTICE 12049 Processing messages in the list failed. Ignoring the error

LOG_NOTICE 12049 Starting main message processing loop

LOG_INFO 12049 Termination requested by the signal handler

LOG_CRIT 12049 $NC_INSTALL_ROOT not set.

LOG_CRIT 12049 Failed to create cluster key. This will shutdown communication with the peer-node

LOG_CRIT 12049 Failed to create peer-gateway key. This will shutdown communication with the peer-node

LOG_CRIT 12049 Failed to create encryption keys for peer-peer communication

LOG_NOTICE 12049 Configuration database versions match. Setting contactPeer flag to true

LOG_NOTICE 12049 Configuration database versions mismatch. Setting contactPeer flag to false.

LOG_ERROR 12050 Heartbeat Client closing socket

LOG_ERROR 12050 Heartbeat Client can not open socket

LOG_ERROR 12050 Heartbeat Client can not read message from Heartbeat Server

LOG_ERROR 12050 Can not send message to Heartbeat

LOG_ERROR 12051 The account has been disabled. Please contact your admin

LOG_ERROR 12051 Only one more day left to expire your password. Please change your password now

LOG_ERROR 12051 Your password is about to expire. Please change your password

238 LOG_ERROR 12053 Failed to bind transResponse socket on 127.0.0.1

LOG_ERROR 12053 Failed to initialize signal handlers

LOG_ERROR 12053 Failed to digest initial configuration

LOG_ERROR 12053 Exec for switchtomaint.sh failed

LOG_ERROR 12053 Termination requested by the signal handler

LOG_ERROR 12054 GetCmdGrpXML failed

LOG_ERROR 12054 sapIndex.AddFromXMLStr(..., \"nc:ncRoot\") failed

LOG_ERROR 12054 Usage: sap_initdb xmlFile

LOG_ERROR 12054 Failed to initialize the sessions DB

LOG_ERROR 12054 Failed to initialize SAP DB

LOG_ERROR 12054 Failed to set System Configuration Timestamp to 0

LOG_ERROR 12054 Failed to set Configuration Tree Timestamp to 0

LOG_ERROR 12057 Can't store vhid

LOG_ERROR 12057 Updating virtual host id is not supported

LOG_ERROR 12057 VirtualHostId

LOG_ERROR 12057 VirtualHost

LOG_ERROR 12058 Sysmon Client closing socket

LOG_ERROR 12058 Sysmon Client can not open socket

LOG_ERROR 12058 Sysmon Client: cannot bind to Socket

LOG_ERROR 12058 Sysmon Client can not read message

LOG_ERROR 12058 Can not allocate memory for sysmon event message

LOG_ERROR 12058 Can not allocate memory for sapd event message

LOG_ERROR 12058 Unknown message received from Sysmon

LOG_ERROR 12058 Unknown message to sysmon

LOG_ERROR 12066 Socket::WritePktToSocket - sockfd == -1

LOG_ERROR 12067 Failed to look up associated application

LOG_ERROR 12067 Adding Application

LOG_ERROR 12067 Rule Group

LOG_ERROR 12067 Duplicate app key

LOG_ERROR 12067 AppKey

LOG_ERROR 12067 No app keys

239 LOG_ERROR 12067 Failed find back-end server in server list

LOG_ERROR 12067 Duplicate app key

LOG_ERROR 12067 Rule Group

LOG_ERROR 12067 No such object

LOG_ERROR 12068 Rule

LOG_ERROR 12068 No rules

LOG_ERROR 12068 Failed find back-end server in server list

LOG_ERROR 12070 Invalid value specified for IPS_COOKIE_MODE),

LOG_ERROR 12073 Duplicate User Realm name: "+authUserRealmName

LOG_ERROR 12073 Failed to write userRealm Name "+authUserRealmName

LOG_ERROR 12073 User Realm name doesn't exist

LOG_ERROR 12073 Failed to delete User Realm name "+ realms_.GetRealmName

LOG_ERROR 12073 Failed to delete User Realm conf file "+ realms_.GetRealmName

LOG_ERROR 12074 InterfaceDependantKey

LOG_ERROR 12081 Finalize succeeded!

LOG_ERROR 12083 Failed to look up Secure Traffic Manager object

LOG_ERROR 12083 No such object

LOG_ERROR 12085 Invalid parameter length " IPS_WEBGATE_START_URL "

LOG_ERROR 12085 Invalid parameter length IPS_WEBGATE_REDIRECT_URL

LOG_ERROR 12085 Invalid parameter length " IPS_WEBGATE_COOKIE_NAME

LOG_ERROR 12085 Invalid parameter length " IPS_WEBGATE_COOKIE_VALUE

LOG_ERROR 12085 Invalid parameter length " IPS_WEBGATE_COOKIE_EXPIRES

LOG_ERROR 12085 Invalid parameter length " IPS_WEBGATE_COOKIE_PATH

LOG_ERROR 12085 Invalid parameter length " IPS_WEBGATE_COOKIE_DOMAIN

LOG_ERROR 12085 Invalid parameter value " IPS_WEBGATE_COOKIE_SECURE

LOG_ERROR 12086 Invalid parameter length " IPS_WEBGATE_START_URL "

240 LOG_ERROR 12086 Invalid parameter length IPS_WEBGATE_REDIRECT_URL

LOG_ERROR 12086 Invalid parameter length " IPS_WEBGATE_COOKIE_NAME

LOG_ERROR 12086 Invalid parameter length " IPS_WEBGATE_COOKIE_VALUE

LOG_ERROR 12086 Invalid parameter length " IPS_WEBGATE_COOKIE_EXPIRES

LOG_ERROR 12086 Invalid parameter length " IPS_WEBGATE_COOKIE_PATH

LOG_ERROR 12086 Invalid parameter length " IPS_WEBGATE_COOKIE_DOMAIN

LOG_ERROR 12086 Invalid parameter value " IPS_WEBGATE_COOKIE_SECURE

LOG_ERROR 12088 Invalid parameter value

LOG_ERROR 12089 Invalid parameter value

LOG_ERROR 12090 Error in ReconfigureSubPolicies mismatch in number of sub-policies

LOG_ERROR 12100 Invalid session ID specified for StartPktTrace

LOG_ERROR 12100 Invalid port specified for Packet dump

LOG_ERROR 12100 Invalid sessionid specified for StartPktTrace

LOG_DEBUG 12100 Packet trace still in progress (not stopped)

LOG_DEBUG 12100 No Packet trace was created

LOG_ERROR 12102 Maximum allowed groups exceeded

LOG_ERROR 12109 Invalid value for (Must be an integer between 0 and 255, inclusive)

LOG_ERROR 12109 Unsupported operation Acl

LOG_ERROR 12197 Failed to start Session Recording

LOG_ERROR 12197 Failed to stop Session Recording

HTTP

LOG_DEBUG 13102 Server prematurely closes the connection

LOG_WARN 13103 OnHttpServerSockRecv: Session timed out from

HTTPSVC

LOG_ERROR 0 Bind failed due to 98 (Unable to connect to the back-end server using the TCP port that the client used while sending the request.).

241 SMTP

LOG_INFO 13201 QUIT command received before EHLO command

LOG_INFO 13202 Backend server supports AUTH

LOG_INFO 13203 Client has not sent EHLO command as the first command

LOG_INFO 13204 AUTH mechanism other than PLAIN/LOGIN has been requested when WSG does user-authentication

LOG_INFO 13205 Using PLAIN authentication mechanism

LOG_INFO 13206 Using LOGIN authentication mechanism

LOG_INFO 13207 User authentication failed

Heartbeat (HB)

LOG_ERROR 15001 Heartbeat events dropped, queue is full

LOG_ERROR 15002 Unable to bind to address

LOG_ERROR 15003 Error sending packet

LOG_INFO 15003 Opening the Heartbeat Connection pci port

LOG_INFO 15003 Closing the Heartbeat Connection pci port

LOG_INFO 15003 Unable to close Heartbeat connection pci port

LOG_INFO 15003 Ignoring Heartbeat Connection close command pci port

LOG_INFO 15003 Received data before initialization

LOG_ERROR 15003 Error receiving data From remote gateway

LOG_ERROR 15004 Attempting to reinitialize the Heartbeat Server before closing

LOG_ERROR 15004 Attempting to send data without Initialization

Certificate (CERT)

LOG_NOTICE 17500 Cert Initialization

SSL

LOG_NOTICE 13200 Can not connect to server () for connection from:

LOG_NOTICE 13200 SSL connection to server for connection from: failed

LOG_NOTICE 13200 Error connecting to server () for connection from:

LOG_NOTICE 13200 Error opening SSL connection to server for connection from:

LOG_NOTICE 13200 SSL accept failed for connection from:

242 LOG_NOTICE 13200 Error switching connection from: to SSL

LOG_NOTICE 13200 Error accepting SSL connection from:

LOG_INFO 13200 QUIT command received before switching to SSL

LOG_NOTICE 16001 : Base 0x - Access denied: received bad certificate signature

LOG_NOTICE 16001 : Base 0x - Access denied: failed to verify certificate signature

LOG_NOTICE 16001 : Base 0x - Access denied: certificate chain too long

LOG_NOTICE 16001 : Base 0x - Access denied: failed to decode certificate

LOG_NOTICE 16001 : Base 0x - Access denied: no certificate

LOG_NOTICE 16001 : Base 0x - Access denied: failed to validate certificate chain

LOG_NOTICE 16001 : Base 0x - Access denied:

LOG_NOTICE 16004 : Base 0x - Sending alert: () from [:]

LOG_NOTICE 16005 : Base 0x - Received alert: () from [:]

LOG_DEBUG 16010 : Base 0x - New SSL socket 0x for

LOG_NOTICE 16012 : Base 0x - No RSA private key available

LOG_NOTICE 16012 : Base 0x - Mismatched key size (expected )

LOG_NOTICE 16012 : Base 0x - Failed to get authority private key

LOG_NOTICE 16012 : Base 0x - Called on a client socket

LOG_NOTICE 16012 : Base 0x - Called on a server

LOG_ERROR 16013 : Out of memory

LOG_ERROR 16013 : Base 0x - Out of memory

243 LOG_ERROR 16013 : Socket 0x - Out of memory

LOG_NOTICE 16014 : Incorrect server name: length should be between 0 and < length >

LOG_ERROR 16016 : Base 0x - Failed to schedule crypto command

LOG_NOTICE 16019 < ssl-function-name >: Cannot configure more than certificate policies

LOG_NOTICE 16020 : Cannot configure more than trusted certificates per service

LOG_NOTICE 16021 : No available SSL version for client socket

LOG_NOTICE 16023 : Ephemeral Key changed

LOG_NOTICE 16024 : Base 0x - No ephemeral key available

LOG_NOTICE 16500 SSL Initialization

LOG_NOTICE 17001 : Trusted certificate expired: CN=, OU=

LOG_NOTICE 17001 : Trusted certificate expired: O= L= S= C=

STM

LOG_ERROR 13100 HttpServerParseRequest: Parse failed; Malformed version

LOG_ERROR 13100 HttpServerParseRequest: Parse failed; Unknown major number

LOG_ERROR 13100 HttpServerParseRequest: Parse failed; Unknown minor number

LOG_ERROR 13100 HttpServerParseRequest: Parse failed; Unknown method:

LOG_ERROR 13100 HttpServerParseRequest: Parse failed; Malformed URL

LOG_ERROR 13100 HttpServerParseRequest: Parse failed; Malformed line end

LOG_ERROR 13101 HttpClientParseResponse: Parse failed; Malformed version

LOG_ERROR 13101 HttpClientParseResponse: Parse failed; Unknown major number

LOG_ERROR 13101 HttpClientParseResponse: Parse failed; Unknown minor number

LOG_ERROR 13101 HttpClientParseResponse: Parse failed; Malformed status code

244 LOG_ERROR 13101 HttpClientParseResponse: Parse failed; Header:

LOG_ERROR 13101 HttpClientParseResponse: Parse failed; Malformed line end

LOG_NOTICE 14001 New Service (ID 0x) Created at :

LOG_ERROR 14001 Failed to Create Service at :

LOG_NOTICE 14002 Service Started :

LOG_ERROR 14003 Failed to Delete Service (ID 0x%08x) at :

LOG_ERROR 14004 Failed to Create Rule at :

LOG_NOTICE 14004 New Rule (ID 0x) Created at : for ID 0x

LOG_NOTICE 14005 Rule: URL [] Header []

LOG_ERROR 14007 Failed to Create Service at :

LOG_NOTICE 14007 New Vapp (ID 0x) Created at : for ID 0x

LOG_NOTICE 14008 Failed to commit Application: Domain [] URL []

LOG_ERROR 14009 Failed to Delete Vapp (ID 0x) at : Domain [] URL []

LOG_INFO 25200 getServerBySrcIPPort: ClntIp 0x ClntPort 0x Svr NULL

LOG_INFO 25200 bindServerBySrcIPPort: SvrIP 0x SvrCookId SvrId

AAA

LOG_INFO 18201 User logged in

LOG_INFO 18202 Password changed successfully for User

LOG_ERROR 18203 Unable to contact the authentication server, (RPC Queue full)

LOG_ERROR 18204 Remote procedure call to authentication server timed out

LOG_ERROR 18205 Login attempt failed for user

LOG_ERROR 18206 Changing password failed for user

245 LOG_NOTICE 18207 Added a realm:

LOG_ERROR 18208 Unable to add realm:

LOG_NOTICE 18209 Deleted a realm:

LOG_DEBUG 18210 Session created for user

LOG_DEBUG 18211 Number of current users sessions =

LOG_DEBUG 18212 Session destroyed for user in realm

LOG_DEBUG 18213 Session exists for user

LOG_DEBUG 18214 Session does not exist for user session id

LOG_ERROR 18215 Error received from webauthd ,

LOG_NOTICE 18216 Insert into ptrie - allocation failed (flags: 0x, mem: ) "Creating AuthzCache - inserting into ptrie failed(nodes: ,

LOG_NOTICE 18217 Client attempted to Logout without login session cookie\n

LOG_WARN 18218 Invalid external policy store configured, realm name =

IPS

LOG_NOTICE 19031 XML Firewall error: ( offset: , code: )",pErr->desc,( int )pErr->offset, pErr->code

LOG_NOTICE 19031 XML Firewall error: Input validation

LOG_NOTICE 19031 XML Firewall error: Attack pattern

LOG_NOTICE 19031 XML Firewall error: Operation denied

LOG_ERROR 19032 Failed to allocate NCFORMINFO buffer

LOG_ERROR 19032 Unable to add session param to NCFORMINFO (no-name param)

LOG_ERROR 19032 Failed to allocate NCFORMINFO buffer(resp)

LOG_ERROR 19032 Unable to add session param to NCFORMINFO (multi-value)

LOG_ERROR 19032 Failed to allocate buffer for response URL rewrite

LOG_ERROR 19032 Failed to allocate buffer for form encryption

LOG_WARN 19500 Could not cloak match for %s. Value of Initial or Trailing Characters to Keep is too large

246 LOG_WARN 19500 POST request with both Content-Length and Transfer-Encoding headers [ url: ], dropped

LOG_WARN 19500 No intrusion information for %d", intrusion

LOG_ALERT 20002 Session cookie decryption failed

LOG_ALERT 20003 Cookie expires: Client

LOG_ALERT 20004 Cookie auth failed: cookiename auth failed

LOG_ALERT 20005 Cookie Length Overflow: Client

LOG_ERROR 20006 Failed to allocate Shared Key context for cookie encryption

FTP Proxy (FTPPXY)

LOG_INFO 21002 :created ftp proxy session client-ip: VhId =

LOG_INFO 21003 Closing server session

LOG_INFO 21004 Control connection established with the FTP server,

LOG_INFO 21005 Back-end FTP server connection has timed out

LOG_INFO 21005 Closing connection to the FTP server

LOG_INFO 21005 FTP server closed the control connection

LOG_INFO 21006 Established data connection to FTP client

LOG_INFO 21008 Established data connection to FTP server

LOG_INFO 21010 Data transfer completed successfully

LOG_ERROR 21011 Error while transferring data

LOG_INFO 21012 Received the FTP command

LOG_WARN 21014 :Invalid client ip-address () specified with the port command, actual client ip-address is ()

LOG_WARN 21014 :Invalid port () specified with the port command, port value must be greater than 1024

LOG_WARN 21014 :Invalid ip-addr () used to connect to listening ftp data socket, expected from ()

LOG_INFO 21015 :Sent the FTP response ()

247 LOG_INFO 21016 Established SSL data connection with the FTP client,

LOG_INFO 21016 Established SSL control connection with the FTP client

LOG_INFO 21018 Established SSL control connection with the FTP server

LOG_DEBUG 21020 Command sent to FTP server

LOG_DEBUG 21021 Client received bytes on control connection

LOG_ERROR 21022 Unable to allocate state control block for a session

LOG_ERROR 21022 Unable to allocate memory for ftp session

LOG_ERROR 21022 Out of memory

LOG_ERROR 21022 :Unable to allocate memory for PORT cmd to FTP server

LOG_ERROR 21022 :Unable to allocate memory for SSL verbs

LOG_ERROR 21022 :Unable to allocate memory for PORT cmd to FTP server

LOG_ERROR 21023 Unable to get an active back-end server

LOG_ERROR 21024 Failed to create new socket

LOG_ERROR 21024 Failed to create SSL socket

LOG_ERROR 21024 Failed to create ssl client socket for data connection

LOG_ERROR 21025 Unable to bind a server for data connection

LOG_ERROR 21025 Unable to setup data connection

LOG_ERROR 21026 Failed to connect to FTP server

LOG_ERROR 21026 Unable to establish SSL control connection with the FTP server

LOG_ERROR 21026 Unable to connect to FTP server

LOG_ERROR 21027 Unable to accept SSL connection from FTP client

LOG_ERROR 21028 Failed to send response to the client

LOG_ERROR 21028 Failed to send control data to the server, because of small TCP windows

LOG_ERROR 21028 Failed to send data to the FTP client on the data connection

LOG_ERROR 21029 Failed to receive data from the FTP client on the data connection

LOG_ERROR 21029 Failed to receive data from FTP server on the data connection

248 LOG_ERROR 21030 Received bad response codes from the FTP server

Compression (COMPRESS)

LOG_ERROR 24001 Compression request errored, ,

LOG_INFO 24004 Part of the response data not submitted for compression

LOG_ERROR 24006 Failed to initialize compression, switching back to no-compression mode

REWRITE

LOG_INFO 26001 Rewrite Module: Low on Memory.

LOG_INFO 26001 : ReqCtx 0x, Error in ncvbuf handling

LOG_ERROR 26051 Rewrite Module: URL rewrite by both Url-Translation and Request Rewrite

LOG_ERROR 26052 Rewrite Module: HTTP header rewrite by both URL-translation and Request Rewrite. Please go over your configuration to see if this can be avoided

LOG_INFO 26053 Response Body Rewrite: Replaced \"\" with \"

ROUTE

LOG_ERROR 3011 rn_addmask: mask impossibly already in tree

LOG_ERROR 3011 Mask for route not entered

LOG_ERROR 3012 rn_delete : Orphaned Mask at

LOG_ERROR 3013 rn_init: radix functions require max_keylen be set

Interface (IF)

LOG_ERROR 3002 failed to attach interface

LOG_NOTICE 3003 : promiscuous mode enabled

ICMP

LOG_INFO 4001 redirect from <-address>: =>

LOG_ERROR 4033 can't find virtual host for route, dst =

LOG_NOTICE 4034 ipflow to reached max refs

TCP

LOG_ALERT 4054 Detected a SYN attack, using SYN cookies

CRYPTO

LOG_DEBUG 5003 Setting Encrypt Context Failed

LOG_DEBUG 5003 Encrypt Update Failed

LOG_DEBUG 5003 Encrypt Failed

LOG_DEBUG 5004 Decrypt Failed

PROCMON

LOG_WARN 44001 'PROCMON' "STM crash detected current state is: state crashes in last "

LOG_WARN 44002 'PROCMON' "Total retries: waiting for before next restart"

LOG_WARN 44003 'PROCMON' "Too many tries to restart unstable STM, switching to Failed state"

LOG_WARN 44004 'PROCMON' "Too many STM crashes switching to Unstable state, will attempt restart in "

LOG_NOTICE 44005 'PROCMON' "Attempting to restart STM and Eventmgr"

LOG_NOTICE 44006 'PROCMON' "Attempting to recreate the log DB"

LOG_ERROR 44007 'PROCMON' "Error : encountered with stm start"

LOG_ERROR 44008 'PROCMON' "STM restart failed: switching to Failed state"

LOG_ERROR 44009 'PROCMON' "STM restart failed: switching to Failed state"

LOG_NOTICE 44010 'PROCMON' "STM restart succeeded: current state: Stable"

LOG_WARN 44011 'PROCMON' "shmget failed

LOG_WARN 44012 'PROCMON' "number of stm worker threads is "

LOG_WARN 44013 'PROCMON' "shmread error "

LOG_WARN 44014 'PROCMON' "STM worker thread seems to be hung. Event count "

LOG_WARN 44015 'PROCMON' "STM seems to be hung. Killing STM"

250 LOG_NOTICE 44016 'PROCMON' "STM alive: switching from to stable state"

LOG_WARN 44017 'PROCMON' " state is "

LOG_ERROR 44018 'PROCMON' "bypass_hbeat.pl is dead restarting gpio and bypass_hbeat"

LOG_ERROR 44019 'PROCMON' "clamd is dead, restarting "

LOG_ERROR 44019 'PROCMON' "snmpd is dead, restarting "

LOG_ERROR 44020 'PROCMON' "profile agent is dead, restarting "

LOG_ERROR 44021 'PROCMON' "collectd is dead, restarting "

LOG_ERROR 44022 'PROCMON' "namemon is dead, restarting namemon"

LOG_ERROR 44023 'PROCMON' "config agent is dead, restarting config_agent and stm"

LOG_CRIT 50003 'PROCMON' "System highest temp has reached = "

LOG_CRIT 50004 'PROCMON' "System is getting real hot = "

LOG_CRIT 50003 'PROCMON' "System highest temp has reached = "

LOG_CRIT 50004 'PROCMON' "System is getting real hot = "

LOG_ALERT 50005 'PROCMON' "One of the CPU fans is dead"

LOG_ALERT 50005 'PROCMON' "One of the System fans is dead"

LOG_ALERT 50007 'PROCMON' "Firmware storage exceeds 85%"

LOG_ALERT 50008 'PROCMON' "Mail storage exceeds 85%"

LOG_ALERT 50009 'PROCMON' "Log storage exceeds 85%"

LOG_ALERT 50010 'PROCMON' "One of the RAID arrays is degrading"

LOG_WARN 44034 'PROCMON' ": link seems down"

LOG_ALERT 44035 'PROCMON' ": link is down"

LOG_NOTICE 44036 'PROCMON' ": link is up"

LOG_NOTICE 44001 'PROCMON' "Checking if configuration needs to be synchronized with peer system"

251 LOG_NOTICE 44001 'PROCMON' "Notifying peer system to check if configuration needs to be synchronized"

LOG_ALERT 44038 'PROCMON' ": link is down"

LOG_ERROR 44039 'PROCMON' "heartbeat.pl is dead , restarting"

LOG_ERROR 44040 'PROCMON' "heartbeat.pl is in state D for tick(s). Ignoring the state"

LOG_ERROR 44041 'PROCMON' "cluster_manager is dead , restarting"

LOG_ERROR 44042 'PROCMON' "cluster_manager is in state D for tick(s). Ignoring the state"

LOG_ERROR 44043 'PROCMON' "Restarting spinal cord process since there may be an issue in connecting to Control Center"

LOG_ERROR 44043 'PROCMON' "Restarting ssh"

LOG_NOTICE 44001 'PROCMON' "Checking if configuration needs to be synchronized with peer system"

LOG_ERROR 44044 'PROCMON' "Configuration dispatcher is dead , restarting"

LOG_ERROR 44045 'PROCMON' "Configuration dispatcher is in state D for tick(s). Ignoring the state"

LOG_ALERT 44046 'PROCMON' "STM seems to be running high on Memory. Please contact to Barracuda Support Center for analysis"

LOG_ALERT 44047 'PROCMON' "Memory Usage exceeds 70%"

LOG_NOTICE 44048 'PROCMON' "Monitoring links: "

LOG_NOTICE 44049 'PROCMON' "Started monitoring"

LOG_EMERG 1105 is not present

LOG_NOTICE 1111 Process mon /proc error ret = comm= pid=

CLUSTER

LOG_NOTICE 43001 'CLUSTER' "We are not yet in cluster mode. Could not calculate destination IP and destination Identity. Exiting.."

LOG_NOTICE 43001 'CLUSTER' "Invalid Role : specified in cluster.conf. Could not determine self role. Exiting.."

LOG_ERROR 43001 'CLUSTER' "cluster.conf file is not existing...Exiting"

UPDATE

252 LOG_ALERT 44401 'UPDATE' "Energize update subscription is about to expire in days"

LOG_ALERT 44402 'UPDATE' "New attack definition version is available"

LOG_ALERT 44403 'UPDATE' "New firmware update is available Current Version = Beta Version = "

LOG_ALERT 44404 'UPDATE' "New firmware update is available Current Version = New Version = "

LOG_ALERT 44402 'UPDATE' "New Attack Def version current_attack_def_version is installed reboot appliance to apply attack def"

BYPASS

LOG_ALERT 44221 'BYPASS' "Unit is switching to bypass mode"

LOG_NOTICE 44222 'BYPASS' "State set to bypass: stopping heartbeat"

LOG_NOTICE 44223 'BYPASS' "State set to normal: starting heartbeat."

LOG_NOTICE 44201 'BYPASS' "Mode change: Hard bypass = Bypass on Failure = "

LOG_NOTICE 44202 'BYPASS' "Mode set to bypass Hard bypass = Bypass on Failure = "

LOG_NOTICE 44203 'BYPASS' "Changing Heartbeat bit state from to "

LOG_NOTICE 44204 'BYPASS' "Mode set to never bypass"

REPORTS

LOG_ERROR 44701 'REPORTS' "Could not open pdf because: "

LOG_ERROR 44702 'REPORTS' "Could not open html '' because: "

LOG_ERROR 44703 'REPORTS' "Report not sent to : ".

LOG_INFO 44720 'REPORTS' ""

STM_WRAPPER

LOG_WARN 45001 'STM_WRAPPER' "Cannot execute Command. Exiting.."

253 LOG_WARN 45002 'STM_WRAPPER' "Configuration agent is not running. Cannot monitor command"

LOG_WARN 45003 'STM_WRAPPER' "command execution status = "

LOG_WARN 45004 'STM_WRAPPER' "Configuration agent crashed. Failed to execute command"

LOG_WARN 45005 'STM_WRAPPER' "Configuration agent is not running....Cannot execute command"

LOG_WARN 45006 'STM_WRAPPER' "Socket between stm wrapper and Configuration agent failed...Cannot execute command"

LOG_ERROR 45007 'STM_WRAPPER' "Failed to initialize STM"

LOG_NOTICE 45008 'STM_WRAPPER' "Successfully initialized STM"

LOG_NOTICE 45008 'STM_WRAPPER' "creatin db snapshot after initwac"

LOG_NOTICE 45009 'STM_WRAPPER' "Successfully stopped STM"

LOG_NOTICE 45010 'STM_WRAPPER' ""

LOG_INFO 45011 'STM_WRAPPER' "Procmon rollback :Loading at from DB snapshotlast successful digest"

LOG_NOTICE 45012 'STM_WRAPPER' "Rollback finished: success"

LOG_ERROR 45013 'STM_WRAPPER' "Rollback failed : Failed to restart STM"

LOG_NOTICE 45014 'STM_WRAPPER' ""

LOG_INFO 45015 'STM_WRAPPER' "Loading at from DB snapshotlast successful digest"

LOG_WARN 45016 'STM_WRAPPER' "[ALERT:] Configuration size is Bytes which exceeds the Bytes safe limit. Please check your configuration."

LOG_INFO 45017 'STM_WRAPPER' "creating db snapshot for stm at because current config.xml = previous config.xml"

LOG_WARN 45018 'STM_WRAPPER' "System in failed state: attempting recovery for config"

LOG_ERROR 45019 'STM_WRAPPER' "STM startup failed. Retrying with blank config"

254 LOG_ERROR 45020 'STM_WRAPPER' "STM startup failed even with blank config. Exiting."

LOG_INFO 45021 'STM_WRAPPER' "STM startup succeeded with blank config"

LOG_NOTICE 45022 'STM_WRAPPER' "Committing UI configuration"

LOG_INFO 45023 'STM_WRAPPER' "creating db snapshot last successful digest at "

LOG_NOTICE 45024 'STM_WRAPPER' "Killing STM for dumping core"

NTP

LOG_INFO 48301 'NTP' "Time synced with the NTP server at time after sync = "

LOG_ERROR 48302 "NTP" "Couldn't connect to NTP server: "

LOG_INFO 48303 'NTP' "Time synced with the NTP server at ntp.barracudacentral.com time after sync = "

PROCESS SCHEDULE

LOG_WARN 49001 'PROCESS SCHEDULE' "Scheduled Backup failed : System has locked key configuration"

High Availability en In this article:

en Introduction Active-Active Setup Active-Standby Setup

Related Articles How to Set Up a High Availability Environment with Two Barracuda Web Application Firewalls Failover and Failback in an Active-Active Cluster How to Remove or Replace Units in a Cluster Updating the Firmware in Clustered Units

Introduction

The ADVANCED > High Availability page allows you to cluster two Barracuda Web Application Firewalls in a high availability setup. Both units must be able to communicate with each other via their WAN ports. The Barracuda Web Application Firewall uses port 8002 to synchronize configuration between the clustered units.

The Barracuda Web Application Firewall supports both Active-Standby and Active-Active configuration. In Active-Standby, one unit serves all requests for the Services in Vsite(s) configured while the other unit is in the Standby state. In Active-Active, both units serve requests for the Services in Vsite(s) that are configured to be active on individual units.

255 Active-Active Setup

If different Vsites are active on each of the unit, and serving requests, the units are in Active-Active setup.

Active-Standby Setup

If all configured Vsites are active on one unit and the other unit is ready to handle traffic, the units are in Active-Standby setup.

A unit can be in Standby state in either of these two scenarios:

If the administrator has configured all Vsite(s) to be active on one unit, and the other unit is ready to handle traffic. If the unit that was active and handling traffic had failed, restores from the Failed state and is ready to resume operation. This can occur only when the units are in Manual mode.

This configuration is available ONLY in 7.7 and above Firmware Versions. For information on High Availability in previous firmware versions, call Barracuda Technical Support.

Active-Active Setup:

256 Each linked Barracuda Web Application Firewall sends a custom “heartbeat” to the other unit using UDP, providing continual status updates. If one of the units fails to send a heartbeat within nine (9) seconds, or sends a status indicating its state as “Failed”, the Active unit assumes all active Services of the failed unit and continues to process traffic.

Each Barracuda Web Application Firewall to be added to a cluster must meet the following requirements:

Have a unique WAN IP address. The Barracuda Web Application Firewalls uses the WAN IP address for joining the units in cluster and configuration synchronization. Have connectivity to (can ping successfully) the other appliance on the WAN interface. Be co-located (WAN Interface) on the same switch (or physical network).

The "heartbeat" packets are sent through the WAN interface for determining the state of the Peer unit in HA by default. The Advanced Cluster Settings section on the ADVANCED > High Availability page provides the administrator an option to configure the interfaces (WAN, LAN or/and MGMT) on which the heartbeat packets needs to be sent. It also provides the flexibility to configure the frequency of heartbeat messages. The Ad vanced Cluster Settings is an advanced feature and is available only when Advanced Settings is set to Yes on the ADVANCED > System Configuration page.

It is recommended to send the heartbeat packets through multiple interfaces to reduce false positives.

To ensure proper routing from the back-end servers in case of failover:

Add a virtual IP address on the LAN interface from the ADVANCED > Network Configuration page. Use this virtual IP address as the routing address for WAN traffic on the real server routing tables (or to the intermediate router's routing tables if the server is in a different subnet).

Do not use the LAN IP address for routing in a HA setup as it is not synchronized or failed over in a cluster. How to Set Up a High Availability Environment with Two Barracuda Web Application Firewalls en The ADVANCED > High Availability feature enables you to cluster two Barracuda Web Application Firewalls as an Active-Standby or Active-Active pair. In Active-Standby setup, one unit serves all requests for the Services in configured Vsite(s) and the other unit is ready to handle the traffic. In Active-Active setup, both units serve requests for only the Services in Vsite(s) configured on the respective unit.

To cluster two Barracuda Web Application Firewalls:

1. For each system follow the instructions in Step 1: Installing the Barracuda Web Application Firewall. Each Barracuda Web Application Firewall in a cluster must have the same firmware version installed. 2. Ensure each system has the following basic configuration settings: a. Unique WAN IP address, LAN IP address and Default Host Name on the BASIC > IP Configuration page. b. The DNS server IP address may be unique for each or the same on both systems. c. If both systems in the cluster are in the same network, ensure they are set to the same Time and Time Zone on the BASIC > Administration page. This prevents configuration synchronization issues. 3. From the ADVANCED > Task Manager page on the Barracuda Web Application Firewall 1, verify that no processes are running. Do the same for Barracuda Web Application Firewall 2. No processes should be running on either appliance when you join systems together. 4. Always initiate the Join Cluster operation from the unit which needs to inherit the configuration. The unit from which the join cluster is initiated will have its configuration overwritten. To ensure that the Backup unit has NO previous configuration settings, invoke Clear Configuration from the ADVANCED > Troubleshooting page to restore the unit to its initial configuration. 5. From the ADVANCED > High Availability page on the Barracuda Web Application Firewall 1, enter the Cluster Shared Secret, and click Save Changes. 6. From the ADVANCED > High Availability page on the Barracuda Web Application Firewall 2, do the following: a. Enter the same Cluster Shared Secret, and click Save Changes. Both units in a cluster must have the same Cluster Shared Secret to communicate with each other. b. In the Clustered Systems section, enter the WAN IP address of the Barracuda Web Application Firewall 1, and click Join Cluster. Never cancel a Join Cluster in progress. The unit from which the Join Cluster is executed becomes the designated Backup unit. That is, Barracuda Web Application Firewall 1 becomes Primary and Barracuda Web Application Firewall 2 becomes Backup. 7. On each Barracuda Web Application Firewall, refresh the ADVANCED > High Availability page, and verify that:

257 7.

a. Each system’s WAN IP address appears in the Clustered Systems list. b. The Status is green for both units. This indicates the communication status. See Status Indicators. 8. The High Availability Status can be viewed on the BASIC > Status page, under Performance Statistics. This shows the role and state of each unit.

When you want to cluster two machines in Bridge mode for High Availability, first put the desired secondary or backup unit in proxy mode. Once you join the two using the above steps, the secondary machine will synchronize its configuration to the primary and revert to Bridge mode. Note that on the BASIC > IP Configuration page, the options Bypass on Failure and Hard Bypass should be set to No in order to cluster two units.

In Proxy mode if Client Impersonation is enabled:

1. Create a virtual interface on the port that is used to connect to the back-end servers. 2. Configure the IP address of the virtual interface as the default gateway on the servers.

Status Indicators

The Status of clustered units:

( ) Active/Standby state - The unit is up and serving incoming service requests (if any), OR the unit is up and ready to assume services (if any). ( ) Failed state – The unit is down due to any of the reasons below: a. Link Down – If Monitor Link for WAN, LAN or Management is selected in the ADVANCED > High Availability page, and the corresponding link is down, the system goes into a Failed state. b. Inability to Serve Traffic – Instability in any traffic processing module which prevents it from serving traffic will cause the system to go into a Failed state. c. Lost Heartbeat – When the Backup unit has not received a heartbeat from the Primary unit for 9 seconds, it concludes that the primary unit is down or dead and it executes failover. ( ) Initializing state – The unit is in initializing state, that is, the JOIN CLUSTER operation is running.

Failover and Failback in an Active-Active Cluster How to Remove or Replace Units in a Cluster Updating the Firmware in Clustered Units Failover and Failback in an Active-Active Cluster en

This configuration is available ONLY in 7.7 and above Firmware Versions. For information on High Availability in previous Firmware Versions, call Barracuda Technical Support.

In this article:

Failover Failover in Automatic Mode Failover in Manual Mode Failback Failback in Automatic Mode Failback in Manual Mode

Failover

Failover is a process of moving active Vsite(s) from the failed unit to the Peer unit when one of the unit serving requests is in Failed state. The Peer unit should be in Active state to take over the active Vsite(s) from the failed unit. On a failover, the Peer unit assumes the active Vsite(s) of the failed unit and continues to process the traffic until the failed unit is restored.

Failover can occur in three ways:

258 1. Link Down – If the parameter Monitor Link for WAN, LAN and Management is selected in the ADVANCED > High Availability page, and when the link is down for any one of the interfaces being monitored, the system goes into a Failed state. 2. Inability to Serve Traffic – Instability in any traffic processing module which prevents it from serving traffic will cause the system to go into a Failed state. 3. Lost Heartbeat – When the backup unit has not received a heartbeat from the primary unit for nine (9) seconds, it concludes that the primary unit is down or dead and it executes failover.

Failover in Automatic Mode

When the unit that is active and handling traffic fails, the active Vsite(s) automatically fails over to the Peer unit. The Peer unit assumes the Services in Vsite(s) from the failed unit and continues to process the traffic until the failed unit is restored.

Failover in Manual Mode

Failover in the manual mode occurs in two ways. They are:

1. When one of the units serving traffic fails. 2. Clicking the Failover button on one of the unit.

The first case is similar to the automatic failover. When the unit that is active and handling traffic fails, the active Vsite(s) automatically fails over to the Peer unit. The Peer unit assumes the Vsite(s) of the failed unit and continues to process the traffic.

In the second case, you can force a failover on one of the unit by clicking the Failover button in the Clustered Systems section. The unit goes to the Standby state and the Peer unit assumes the Services in Vsite(s) from the unit and continues to process the traffic.

Failover is always automatic irrespective of Automatic or Manual mode. In both Automatic and Manual modes, the Failover process cannot take place if the Peer unit is also down.

Failback

Failback restores functioning Vsite(s) that have failed over from the failed unit to the Peer unit. When the failed unit returns from the Failed state to the Active state (that is, it can now actively serve application requests), the Vsite(s) that were Active on the failed unit before failover are automatically failed back (released) from the Peer unit.

Failback in Automatic Mode

When the failed unit recovers from the Failed state and is ready to resume operation, the Vsite(s) that were Active on the failed unit automatically fails back to the restored unit, and continues to serve traffic. The Peer unit continues to serve traffic to the Vsite(s) that are Active on it (if any).

Failback in Manual Mode

Failback in the manual mode occurs in two ways. They are:

1. Clicking the Failback button on the backup unit. 2. If the Peer unit fails and the other unit is in Standby/Active state

In Manual mode, the Peer unit remains Active even if the failed unit restores from the Failed state and is ready to resume operation. You need to click on the Failback button in the Clustered Systems section of the Peer unit to resume operation on the other unit.

In the second case, the other unit automatically resumes operation if the Peer unit fails. This can occur only when the failed unit is not in Failed state and is ready to resume operation.

Manual Failover/Failback

259 In case if both the units (Self and Peer) goes to Active-Failed state in Manual mode due to network issue (or any other issue such as heartbeat lost), the units will recover with the same state they were in before going to Active-Failed state.

For example, consider Unit_1 and Unit_2 are in Active (Self)-Standby (Peer) and Standby (Self)-Active (Peer) state respectively. If due to network issue or loss of heartbeats, the Unit_1 and Unit_2 are unable to communicate with each other, the units will enter to Active (Self)-Failed (Peer) state. Here, both the units assume that they are Active and the other unit is in Failed state. Upon recovery, both the units will enter the same state they were in before going to Active(Self)-Failed(Peer) state, i.e. Unit_1 in Active(Self)-Standby(Peer) and Unit_2 in Standby(Self)-Active(Peer) state.

Automatic Failover/Failback

260 Related Articles

How to Set Up a High Availability Environment with Two Barracuda Web Application Firewalls How to Remove or Replace Units in a Cluster Updating the Firmware in Clustered Units How to Remove or Replace Units in a Cluster en

This configuration is available ONLY in 7.7 and above Firmware Versions. For information on High Availability in previous firmware versions, call Barracuda Technical Support.

Removing a Unit from a Cluster

A Barracuda Web Application Firewall can be removed from a cluster at any time as per the following steps.

Steps to Remove a Unit from a Cluster

1. Take a backup of system configuration on both units. Refer to Backing up and Restoring your System Configuration. 2. Identify the unit that you want to remove from the cluster. 3. From the ADVANCED > High Availability page of the unit that you want to remove, click the Delete button in the Clustered Systems s ection. This removes the Vsite(s) active on the Peer from this unit, and retains Vsite(s) that were configured to be active on this unit. The Services in Vsite(s) that were removed continue to operate on the Peer unit.

If you are removing the unit for an RMA, follow the steps in Replacing a Unit in the Cluster.

Replacing a Unit in the Cluster

Before attempting an RMA, remove the failed unit from the cluster. The unit's serial number is used to identify it in a clustered configuration. A replacement unit with a different serial number will not be able to automatically become part of the cluster; it must go through the clustering procedure.

261 This task should be carried out during a planned maintenance window.

Steps to Replace a Failed Unit in a Cluster with a New Unit

1. Ensure the Active unit is handling traffic for all Vsite(s) that are configured to be active on the failed unit and Self unit. 2. From the ADVANCED > High Availability page of the Active unit, remove the cluster by clicking the Delete button in the Clustered Systems section. This operation removes the failed unit from the cluster and moves all Vsites that were configured to be active-on from the failed unit to the Active unit (Self). 3. Configure a new unit with the failed unit's WAN IP address. 4. Upgrade the firmware version on the new unit to match that of the Active unit. Both units in the cluster should have the same firmware version installed. 5. From the ADVANCED > High Availability page of the new unit or RMAed unit, enter the WAN IP address of the Active unit, and click Jo in Cluster.

Failover and Failback in an Active-Active Cluster How to Set Up a High Availability Environment with Two Barracuda Web Application Firewalls How Barracuda Networks Manages Returned Device Drives Updating the Firmware in Clustered Units Networking en The Barracuda Web Application Firewall provides independent routing entities called Network Groups. Network settings such as routes and ACLs are configured individually for each Network Group.

You can configure one Network Group for Management Path and multiple Network Groups for Data Path in the Barracuda Web Application Firewall.

Management Path is the traffic flow from an administrator’s system or network to the Barracuda Web Application Firewall. A Network Group for the management interface controls management access of the Barracuda Web Application Firewall. Configurations are specific to a unit and are not synchronized with the Peer unit in a High Availability (HA) cluster.

Data Path is the traffic flow from clients to the back-end server which needs to be secured or routed through the Barracuda Web Application Firewall. Multiple network groups can be configured on the Data Path to provide the routing flexibility required to deploy the appliance in complex networks. A Vsite encompasses one Network Group and its associated Services. Administrators can configure multiple Network Groups by configuring multiple Vsites. A network group is automatically created for the system during the initial configuration of the physical interfaces. Network settings in the network groups of the Vsite are evaluated first and then the network settings under System Network Group is evaluated before a packet routing or filtering decision is made. All configuration for data path network groups are synchronized with the Peer unit in the HA cluster.

The routing decisions for the Management Path and Data Path traffic are taken based on the respective routing tables. The Data Path traffic is first matched with the set of routes configured for the specific Vsite. If the traffic does not match any Vsite routing entries, it is compared to System routing entries. If it matches neither Vsite nor System routing entries, the packet is dropped.

The Barracuda Web Application Firewall supports the following routing tables:

Management – Routes to process traffic through the Management interface. System - The main routing table used for processing all Data Path traffic. The System table includes WAN (WAN default gateway) and LAN interfaces configured on the BASIC > Administration page. Vsites – Routes designated for each Vsite configured on the BASIC > Services page. Each Vsite has its own network routing table to which the incoming/outgoing traffic is compared in order to process the traffic.

Accessing External Servers from the Barracuda Web Application Firewall

External servers can be configured on the following web interface pages:

Authentication Services on ACCESS CONTROL > Authentication Services. SNMP Trap Receivers on BASIC > Administration. Email Notification on BASIC > Administration. DNS Configuration on BASIC > IP Configuration. Proxy Server Configuration on BASIC > IP Configuration.

262 Export Logs on ADVANCED > Export Logs. External Authentication Servers on ADVANCED > Admin Access Control. NTP Servers on ADVANCED > System Configuration.

For accessing any of the external servers mentioned above whose IP address does not fall within the network of configured virtual interfaces, the Barracuda Web Application Firewall uses Interface for System Services to forward the packets. You can configure Interface for System Services on the BASIC > IP Configuration page.

If you want the route to be overridden, a host specific static route should be configured within the network group from which the server is accessible.

Example: External server reachable through 'Management' network group.

Consider you have a NTP server that is reachable though 'Management' network group and your Interface for System Services is set to WAN, then a specific static route should be configured for the NTP server within the Management network group on the ADVANCED > Advanced Networking page. Alternatively you can set your Interface for System Services as Management.

Management default gateway is 10.11.25.254 and NTP server IP address is 10.11.17.40 which is reachable via gateway 10.11.25.254, then we can add a static route on Management Network Group as host 10.11.17.40 and gateway as 10.11.25.254.

The ADVANCED > Advanced Networking > Configuration for Network Group section allows you to configure network components.

Select the network group from the Network Group drop-down list to add or modify the network components. The network components are:

Network Address Translation (NAT) Access Control List (ACL) Virtual Local Area Network (VLAN) Routes Interfaces Configuration Network Address Translation (NAT) en Network Address Translation (NAT) maps outbound IP addresses to prevent exposing internal IP addresses.

NAT allows you to:

Conceal the internal IP address from external exposure or access. Reduce the demand for registered IP addresses because internal IP addresses are not revealed to the outside world.

Incoming IP addresses can be translated to correct internal IP addresses.

Source Network Address Translation (SNAT)

Source Network Address Translation (SNAT) maps internal IP (private IP) addresses to an external IP (public IP) address.Source Network Address Translation (SNAT) re-writes the IP address of the computer that originated the packet. SNAT is composed of two steps:

263 The process of translating an internal IP address into an external IP address. The process of undoing the translation for returning traffic, that is, rewriting the IP address of the computer that originated the packet.

For example, consider an internal IP address 10.1.2.27 sends a packet to an external web server. The Barracuda Web Application Firewall translates the internal IP address 10.1.2.27 to an external IP address 209.165.201.10. When the external web server responds, the external IP address 209.165.201.10 receives the packet and sends it to the internal IP address 10.1.2.27.

Following are the SNAT Capabilities Provided by the Barracuda Web Application Firewall:

Dynamic NAT: Sets up a sequential translation between internal IP addresses and external IP addresses. You can specify a range of external IP addresses, and the Barracuda Web Application Firewall dynamically maps the internal IP address to the available external IP address. For example, enter the internal IP address 10.1.2.0 in Pre SNAT Source with subnet mask 255.255.255.0 in Pre SNAT Source Mask and enter a range of external IP addresses (209.165.201.11 - 209.065.201.16) in Post SNAT Source. The Barracuda Web Application Firewall will translate internal source IP addresses to the available external IP address. Static NAT: Sets up a one to one translation between a single internal IP address and a single external IP address. For example, an internal IP address of 10.1.2.27 will always translate to 209.165.201.10.

To add an SNAT rule, click NAT in the Network Configuration section. In the Source Network Address Translation section, click Add SNAT a nd specify values for the fields. For more information, click Help on the relevant web interface page.

Destination Network Address Translation (DNAT)

Destination Network Address Translation (DNAT) re-writes the destination IP address of incoming traffic. Consider you have a server inside your LAN, and you want users outside the network to access that server. This can be accomplished by configuring DNAT rule that directs all the traffic passing through the Barracuda Web Application Firewall to the internal network.

For example, lets say that you have a mail server inside your LAN with the IP address 192.168.2.5 on port 25. Users outside the network cannot access the mail server through the Barracuda Web Application Firewall because routing to a private IP address is not possible. If you want to allow users to access the mail server, you need to configure the DNAT rule for port 25 so that any traffic destined for port 25 on the WAN interface of the Barracuda Web Application Firewall is redirected to 192.168.2.5.

Ensure that you configure an ACL rule along with the DNAT rule to allow the traffic to pass through the Barracuda Web Application Firewall via port 25 or else the firewall will drop the incoming packets.

To add an DNAT rule, click NAT in the Network Configuration section. In the Destination Network Address Translation section, click Add DNAT and specify values for the fields. For more information, click Help on the relevant web interface page. Access Control List (ACL) en Access Control List (ACL) specifies the IP address firewall access rules applied to a packet.The rules are compared to each packet, and if a packet matches a rule, the configured action for that rule is performed. The action ALLOW accepts the packet allowing access; the action DENY drops the packet denying access.

ACLs can constrain the flow of traffic by individual IP address or by a range of IP addresses. ACLs can be bound to specific interfaces (LAN, WAN or MGMT) of the Barracuda Web Application Firewall allowing configuration of distinct restrictions for front-end and back-end traffic.

To create an ACL rule, from the ADVANCED > Advanced Networking page, click the ACL tab in the Network Configuration section. In the Net work ACLs section, click Add ACL and specify values for the fields.

For more information, click Help on the relevant page of the web interface. en ACLs for Forwarded Traffic

Network ACLs configured under "System/Vsites" apply to Service traffic on the Barracuda Web Application Firewall. NAT'ed (SNAT and DNAT) traffic routed through the Barracuda Web Application Firewall from the back-end servers to the internet are controlled using "ACLs for Forwarded Traffic".

264 Auto Created Network ACLs

Auto Created Network ACLs are generated at system boot time and persist on the system across any configuration change. The auto created ACLs include the following predefined allow deny rules:

Allow rules to access support tunnel, DNS server and the secure shell (for CLI). Deny rules to MGMT and WAN interfaces. Any traffic passing through MGMT and WAN interfaces are blocked. The administrator must create ACL rules to allow designated traffic to pass through these interfaces.

By default, the Log Status is set to Off for all auto created network ACLs. Any traffic that matches these ACL rules is not logged under ADVANC ED > Network Firewall Logs. To enable logging, click the Edit icon next to the ACL rule and set the Log Status to On. ACLs for Forwarded Traffic en ACLs for Forwarded Traffic

For example, the Barracuda Web Application Firewall can route or NAT packets from back-end servers in the LAN network to a remote client, reachable through the WAN interface; and vice versa by configuring appropriate static routes and Forward ACL rules with action ALLOW on the Barracuda Web Application Firewall. Virtual Local Area Network (VLAN) en A VLAN (Virtual Local Area Network) is a logical construct, similar to a LAN, which defines a broadcast domain. While a LAN requires all hosts to be physically connected to the same switch, a VLAN allows hosts not connected to the same switch to belong to the same broadcast domain. In addition, the ports on a switch with VLAN capabilities can be divided into multiple independent broadcast domains. Network reconfiguration can be done through software instead of physically relocating devices.

When a VLAN spans multiple switches, the VLAN traffic is routed over trunk ports on the switches. The link between two trunk ports is known as the trunk link. Usually a trunk link is implemented between fast switch ports on two different switches using a crossover cable. A VLAN might have 3 ports on one switch, and 7 ports on another; the inter-switch traffic is routed on the trunk ports.

Traffic for multiple VLANs can be transferred across a single trunk link. This works using VLAN tagging, which tags Ethernet packets with the VLAN ID to which the packet belongs. Alternatively, VLAN ports on the VLAN switch belong to a single VLAN and therefore only see the broadcast traffic of that VLAN.

VLAN Configuration

To route a VLAN through the WAN, LAN, or MGMT interface, a VLAN interface must be added to receive the broadcast traffic from the VLAN and route traffic to the VLAN. To add a VLAN interface, you must specify the VLAN ID, and the IP address and subnet mask for the interface. Based on the destination IP address of network packets, the Barracuda Web Application Firewall routes the packets to the appropriate VLAN interface.

Adding a VLAN interface makes the Barracuda Web Application Firewall aware of that VLAN, and allows it to perform explicit VLAN tagging functions for traffic routed to the VLAN, and to remove VLAN tagging when routing packets from the VLAN to non-VLAN networks.

For example, if all Real Servers reside in VLAN 100, then the LAN port may be connected to a port on the VLAN switch belonging to VLAN 100. Correspondingly a VLAN interface must be added to the LAN interface with VLAN ID 100 and have an available IP address belonging in the VLAN broadcast domain.

To create a VLAN rule, select the VLAN tab in the Network Configuration section. In the VLAN Configuration section, click Add VLAN and specify values for the fields. Click Help for more information.

Routing to Multiple VLANs over an Interface

If any interface on the Barracuda Web Application Firewall has to route to multiple VLANs, it must be connected to the VLAN switch via a trunk (or hybrid) link, since VLAN traffic to multiple VLANs can only be transported over trunk links. In order to route to multiple VLANs via any of the physical interfaces, one VLAN interface must be added to the relevant physical interface per VLAN. If the Real Servers are distributed across

265 multiple VLANs, say 100, 105, and 111, then the LAN port must be connected to a trunk port on the VLAN switch. A VLAN interface must be added for each VLAN on the LAN interface with the corresponding VLAN IDs, 100, 105 and 111. This allows the Barracuda Web Application Firewall to route to the correct VLAN by inserting appropriate VLAN IDs before forwarding on to the trunk link.

Bridge Mode

In Bridge mode, if VLANs are being used, both the LAN and WAN ports must be on the same VLAN and a corresponding VLAN interface must be added on either the WAN or LAN interface. Bridge mode does not currently support configurations with the LAN and WAN connected to different VLANs. If the MGMT port is part of one or more VLANs, then VLAN interfaces must be added on to the MGMT port for the respective VLANs. Routes en To configure traffic routes which determine routing decisions for a specific Network Group, from the ADVANCED > Advanced Networking page of the web interface, select the Network Group and select the Routes tab in the Network Configuration section.

Static Routes

Create a static route to specify the exact route to a remote network. This allows you to route to an interface that is located on a different subnet.

In the Static Routes section, click Add Static Route and specify values for the fields.

IPv6 Static Routes

Create an IPv6 static route using the IPv6 Static Routes section. Click Add IPv6 Static Route and specify values for the fields.

For further information about configuring routes, access the web interface, and click Help in the section where you desire additional details.

Interface Routes

Create an interface route to specify the interface to use for a remote network. This is useful in the bridge mode where the service IP address is not owned by the Barracuda Web Application Firewall.

In the Interface Routes section, click Add Interface Route and specify values for the fields.

IPv6 Interface Routes

Create an IPv6 interface using the IPv6 Interface Routes section. Click Add IPv6 Interface Route and specify values for the fields.

For further information about configuring routes, access the web interface, and click Help in the section where you desire additional details. Interfaces en A configured interface is a logical exit point that allows traffic to flow between the Barracuda Web Application Firewall and the servers.

To configure interfaces, from the ADVANCED > Advanced Networking page, select the Interfaces tab. For additional information on these configurations, from the web interface, click Help in the relevant section.

Service Virtual Interfaces

The Service Virtual Interfaces section displays all Service IP addresses as well as any configured virtual interfaces.

Custom Virtual Interfaces

The Custom Virtual Interfaces section allows you to add virtual interface(s) to the physical port (WAN or LAN) used to communicate with the servers.

To add a custom virtual interface, in the Custom Virtual Interfaces section, click Add Custom Virtual Interface and specify values for the fields.

IPv6 Interfaces

IPv6 Service Virtual Interfaces

The IPv6 Service Virtual Interfaces section displays all IPv6 Service IP addresses as well as any configured virtual interfaces.

266 IPv6 Custom Virtual Interfaces

The IPv6 Custom Virtual Interfaces section allows you to add IPv6 virtual interface(s) to the physical port (WAN or LAN) used to communicate with the servers.

To add an IPv6 custom virtual interface, click Add IPv6 Custom Virtual Interface and specify values for the fields. Configuration en You can enable NAT for LAN servers, configure Stateful Network Firewall and edit Network Interface Card (NIC) settings for the System Network Group. Select System from the Network Group list, and select the Configuration tab to configure the following features. For more information on these features, access the web interface and click Help next to the relevant section.

NAT for LAN Servers

Network Address Translation (NAT) for LAN Servers allows you to automatically NAT all servers on the LAN with a single setting. This option enables all traffic originating from LAN to go out on the WAN, automatically NATted with the WAN interface IP address or with the first available Service IP address.

You are not required to configure SNAT and ACL rule for the LAN servers, as the Barracuda Web Application Firewall automatically NATs and allows the LAN traffic to go out on the WAN. For example, consider the LAN servers with the IP addresses 10.10.10. 24, 192.168.32.10, and 192.168.30.15. To go out on WAN through the Barracuda Web Application Firewall, the traffic from the LAN servers is automatically NATted with the WAN interface IP address (209.165.201.10) or with the first available Service IP address 209.165.201.11.

To enable NAT for LAN servers, in the NAT for LAN Servers section, set Enable SNAT for LAN Servers to Yes.

Stateful Network Firewall

The Barracuda Web Application Firewall uses stateful firewall inspection to prevent network-layer attacks like TCP anomaly and signature attacks. It keeps track of the state of network connections and uses this information to verify the inbound network packets traversing through the firewall.

Use the Stateful Network Firewall section to configure this feature.

Network Interface Card (NIC) Advanced Configuration

NIC (network interface card) is a hardware unit designed to allow computers to communicate over a computer network. This NIC card, when installed on the Barracuda Web Application Firewall, negotiates communication with a switch/router with the right combination of duplexity and speed so they can communicate with one another in both directions.

There are two ways to set the NIC configurations, either manual or automatic. In manual mode, if the speed and duplexity of the card mismatches that of the switch/router, then the negotiations may fail. If Auto-Negotiation Status is set to On the NIC card will automatically match its settings to that of the switch/router to start communication. This is the recommended setting. Click Edit in the Action column, next to the desired interface, to set Auto-Negotiation Status to On.

NIC is configured with predefined values by default for all the three interface ports LAN, WAN and MGMT. To edit the NIC configuration, in the NI C Advanced Configuration section, click Edit next to the interface name. The Edit Advanced NIC Configuration window appears, modify the settings if required and click Save Changes. System Administration and Maintenance en In this Section

Administration and Maintenance of the Barracuda Web Application Firewall may require the following tasks:

Updating Firmware on the Barracuda Web Application Firewall Backing up and Restoring your System Configuration Scheduling Automated FTP Backups Scheduling Automated SMB Backups How to Configure Role Based Administration Using Templates to Save and Import Configuration Objects Updating the Firmware in Clustered Units

267 Barracuda Web Application Firewall Hardware Features How to Clear Configuration on the Barracuda Web Application Firewall Rebooting the System in Recovery Mode Replacing a Failed System Updating Firmware on the Barracuda Web Application Firewall en

To update the firmware in clustered units, refer Updating the Firmware in Clustered Units.

Before updating to a latest firmware version, check the Firmware Storage state under Performance Statistics on the BASIC > Status page. If the status indicator displayed is in red, contact Barracuda Networks Technical Support before proceeding with the firmware upgrade.

If your product is deployed in-line and does not have hard bypass functionality, you should plan your firmware upgrade for a time when your network can tolerate five or more minutes of downtime while the system reboots. Alternately, you can temporarily bypass the unit, physically.

The ADVANCED > Firmware Update page enables you to manually update the firmware version on your system or revert to a previous version. Only revert to a previous firmware version if you have recently upgraded the firmware and encountered unexpected problems. Contact Barracuda Networks Technical Support before reverting to a previous firmware version.

You should use the ADVANCED > Backup > Configuration Backup section to make a backup of the System Configuration to your local machine before updating the firmware. To schedule automated FTP and SMB Backups, see Scheduling Automated FTP Backups and Schedulin g Automated SMB Backups.

Steps to Update the Firmware:

Perform the following steps to update the firmware:

1. Go to the ADVANCED > Firmware Update page. 2. In the Firmware Download section, click Download Now next to the available Latest General Release or Latest Early Release (s).

3. Click OK when the warning message appears. Download Progress showing your download status displays.

4. Once the download is complete, a Firmware successfully downloaded message displays. Click on (view release notes) to review the enhancements and fixes available in the new version. Make changes to the existing configuration if required. 5. Click Apply Now to install the new firmware. When prompted with The system must reboot to apply the new firmware. Do you wish to continue?, click OK. Various status messages appear including: Preparing firmware for installation; System update in progress…; Rebooting system, Please wait…. The installation process takes several minutes to complete, and will automatically reboot the Barracuda Web Application Firewall. 6. Once the reboot completes, the login page appears. Log in and verify that all Services have Green health indicators.

If you encounter any issue after upgrade and wish to revert, refer to Steps to Revert the Firmware.

268 Do not manually Power-Off the Barracuda Web Application Firewall at any time during the upgrade/revert process (unless instructed to do so by Barracuda Technical Support), or you may cause firmware corruption.

Steps to Revert the Firmware

If the units are clustered:

Ensure both the units are in Manual mode Revert should first be performed on the Primary unit, and only then on the Secondary unit.

Perform the following steps to revert the firmware:

1. Go to the ADVANCED > Firmware Update > Firmware Revert section: a. Click Revert next to the Previously Installed Version to revert to the prior version of firmware used by the Barracuda Web Application Firewall, OR b. Click Revert next to the Factory Installed Version to revert to the firmware version installed at the factory. 2. Click OK when prompted with the warning message. The unit reboots and reverts to the previous firmware/factory installed version and configuration settings.

If you had custom patches applied on your box, contact Barracuda Technical Support to re-apply previously installed patches. If the revert option causes any issue, upload the backup you made before upgrading to the latest version.

Scheduling Automated FTP Backups Scheduling Automated SMB Backups Backing up and Restoring your System Configuration en You can back up various system configuration and user settings on your Barracuda Web Application Firewall using the ADVANCED > Backup, C onfiguration Backup section. These files allow you to restore your current system, or duplicate the configuration on another Barracuda Web Application Firewall using the ADVANCED > Backup, Restoring Backups section.

You should create a backup of your system on a regular basis to insure you can restore your configuration in the event of a data corruption.

When you restore a backup file to a new Barracuda Web Application Firewall that is not configured, you need to configure the new system IP address and DNS information on the BASIC > IP Configuration page.

Note the following about the backup file:

Do not edit backup files. Any configuration changes you want will need to be done through the web interface. The configuration backup file contains a checksum that prevents the file from being uploaded to the system if any changes are made. The following information is not included in the backup file: System password System IP address information Scheduling Automated FTP Backups en Perform the following steps to schedule automated configuration backups to an FTP server:

1. From the ADVANCED > Backup page in the Automated Backups section, select FTP from the Server Type drop-down list. 2. Specify values for the following: Server Name/IP – Enter the Fully Qualified Domain Name (FQDN)/IP address of your FTP server. Port – Enter the port number for the FTP server. The default FTP port is 21. Username – Enter the username to authenticate to the FTP server. Password – Enter the password to authenticate to the FTP server. Note: The Barracuda Web Application Firewall uses these credentials (Username and Password) to connect to the FTP server. Make sure this account has read and write privileges to the path specified in Folder/Path.

269 2.

Folder/Path – Enter the path to the directory on the FTP server where you want to save automated backups. 3. Click Save Changes. 4. To test the connection to the FTP server, click the Test Backup Server button. The following window pops up if the test was successful:

5. If the test was successful, proceed and configure the Backup Schedule and Backups to Keep. Backup Schedule – Select the check box next to each component that is to be backed up. Select the day of the week (or Daily) and the time of day you would like each backup to run. Backups to Keep – Set the maximum number of backups to keep on the remote (FTP) server at any one time. When this limit is reached, the oldest backup set will be removed to make room for the newest. 6. Click Save Changes.

Scheduling Automated SMB Backups Scheduling Automated SMB Backups en Perform the following steps to schedule automated configuration backups to an SMB server:

1. From the ADVANCED > Backup page in the Automated Backups section, select SMB from the Server Type drop-down list. 2. Specify values for the following: Server Name/IP – Enter the Network Basic Input/Output System (NetBIOS) name IP address of the SMB server that will receive the automated SMB backups. Port – Enter the port number for the SMB server. The SMB port can either be 139 or 445. Username – Enter the username to authenticate to the SMB server. Password – Enter the password to authenticate to the SMB server. Note: The Barracuda Web Application Firewall uses these credentials (Username and Password) to connect to the SMB server. Make sure this account has read and write privileges to the shared folder specified in Folder/Path. Folder/Path – Enter the shared folder on the SMB server where you would wish to save automated backups. Note: The Barracuda Web Application Firewall is able to connect only to top-level shared folders. The value should be preceded by a slash (\) and cannot contain spaces or special characters. Backup Schedule - Select the check box next to each component that is to be backed up. Select the day of the week (or Daily) and the time of day you would like each backup to run. Backups to Keep – Set the maximum number of backups to keep on the remote (SMB) server at any one time. When this limit is reached, the oldest backup set will be removed to make room for the newest. 3. Click Save Changes.

Note Depending on the SMB version, the Username might need to be formatted in one of these ways:

270 / (Windows Server 2000 only) @ (Windows Server 2003 only)

Scheduling Automated FTP Backups How to Configure Role Based Administration en Role Based Administration (RBA) restricts access to system resources based on the roles assigned to users within an organization. The Barracuda Web Application Firewall is shipped with predefined roles, each with distinct operational and configuration privileges. In addition to predefined roles, the Barracuda Web Application Firewall allows you to create custom roles and define access privileges. The roles can be assigned to users to perform specific job functions. The ‘admin’ role, by default, is assigned to the administrative user who has permission for role management.

The RBA feature in the Barracuda Web Application Firewall introduces the following components:

Roles Users Privileges

en What is a Role? Creating a New Role Users Local Users External Users Privileges Object Privileges Screen and Operation Privileges

What is a Role?

A role is a set of privileges or permissions on the available system resources, created for a specific job function. The ‘admin’ role is allowed to create, modify, and delete roles. A role can be assigned to multiple users within an organization. Assigning a role to a user confers the set of privileges on the system resources included in the role definition. All users who assume that role can operate in the same environment and access the same resources. For example, an administrator assigned to the 'audit-admin' role is only allowed to view logs on the system and is prevented from accessing any other object.

Role Description of Allowed Functions Associated with Role

admin The super-administrator.

All system operations

Note: Only admin can create and assign roles.

audit-manager Viewing Logs

certificate-manager Uploading certificates Creating certificates Uploading Trusted certificates

service-manager Adding Server Creating URL ACLs Configuring Web Site Translation rules Adding URL and Parameter profiles Configuring Traffic Management rules

Note: service-manager cannot create or delete services.

271 policy-manager Managing default and customized security policies Modifying security policies

Note: policy-manager cannot create or delete security policies.

network-manager Advanced IP address configuration Configuring SNAT and ACL's Network Troubleshooting

monitoring-manager View logs Configuring email notifications Exporting System logs, Application Logs and FTP Access Logs Generating and scheduling reports

guest View all configurations

Note: guest may not modify the configuration.

Creating a New Role

In addition to the factory shipped roles, the Barracuda Web Application Firewall enables you to create new roles. You can specify the privileges for these roles, and then assign them to users.

Steps to create a new role:

1. From the ADVANCED > Admin Access Control page in the Administrator Roles section, click Add Administrator Role. The Add Administrator Role window appears. 2. Specify values for the following: a. Role Name – Enter a name for the new administrator role. b. Services – Select the desired access (Read and/or Write check box(es)) next to Services this role will administer. All services configured on the BASIC > Services page are listed. c. Security Policies – Select the desired access (Read and/or Write check box(es)) next to security policies this role will administer. All policies configured on the SECURITY POLICIES > Policy Manager page are listed. d. Authentication Services – Select the desired access (Read and/or Write check box(es)) next to Authentication Services this role requires. All authentication services configured on the ACCESS CONTROL > Authentication Services page are listed. 3. Select the screens and permissions this role requires in the User Interface Privileges section. See Screen and Operation Privileges. 4. Click Create Role to create a new role with the selected privileges.

A role defines access to objects: Services, Security Policies and Authorization Services. See Object Privileges.

Users

Barracuda Web Application Firewall users are assigned roles which determine the allowed operations they can perform. A user may be either 'local' or 'external'. Users must be assigned a role when the user account is created. The user can then access the system. When a user attempts to log in, the Barracuda Web Application Firewall first tries to authenticate the user credentials against the configured local administrators, then queries the configured external authentication service. Once authenticated, the user inherits privileges from the associated role.

Local Users

Local administrators or users are authenticated internally in the Barracuda Web Application Firewall. The admin user can create local users and associate each user with an administrator role. If you delete a local administrator account, that user is denied access to the system.

Steps to create a local administrator:

1. From the ADVANCED > Admin Access Control in the Administrator Accounts section, click Add Local Administrator. The Local Administrator Account window appears. 2. Specify values for the following: a. User Name – Enter a name for the user. b. Password – Enter the password for the user. c. Re-enter Password – Re-enter the password. d. Role – Select a role to be associated with the user from the drop-down list. e. Email Address – Enter the email address of the user. 3. Click Add to add this user as a local administrator.

272 External Users

External administrators or users are part of an external authentication service like the Lightweight Directory Access Protocol (LDAP) or Remote Authentication Dial In User Service (RADIUS). The Barracuda Web Application Firewall enables you to configure an external authentication service, allowing authenticated external users to access the system. An external user cannot be created but is synchronized internally from the LDAP or RADIUS server when a user is successfully authenticated with the configured directory services. You can override the default role association for an external user by editing the user. When an external user is no longer part of the LDAP or RADIUS database, the user must be manually deleted from the Barracuda Web Application Firewall so external authentication fails.

Steps to add an LDAP authentication service and associate a role:

1. Go to the ADVANCED > Admin Access Control page. 2. In the External Authentication Services section, select LDAP from the drop-down list. The Add LDAP Servicewindow appears. Specify values for the following: a. Realm Name – Enter the name of the realm where the Barracuda Web Application Firewall admins are stored (A realm identifies a collection of users and groups. It specifies information, in a flat directory structure, such as where users are located and where groups are located.). b. IP Address – Enter the IP address of the external LDAP server. c. Port – Enter the port of the external LDAP server. d. Encryption– Select the type of encryption the Barracuda Web Application Firewall should use when querying the LDAP database for user authentication and role retrieval. i. None – Establishes plain text connection to the LDAP server. ii. TLS – Uses TLS protocol to establish secure connection to the LDAP server. iii. SSL – Uses SSL protocol to establish secure connection to the LDAP server. e. Bind DN – Enter Distinguished Name (DN) of the user to query the LDAP server. f. Bind Password – Enter the password for the user querying the LDAP server. g. LDAP Search Base – Enter the starting Distinguished Name (DN) specifying the scope of the search in the LDAP directory. h. UID Attribute– Enter the attribute used to identify the user in the LDAP directory. i. For Open LDAP, enter uid ii. For Active Directory, enter sAMAccountName i. Group Filter – Enter the filter attribute to retrieve the user's groups from the LDAP directory. j. Group Name Attribute – Enter the attribute used to identify the name of a group. k. Default Role – Select a default role to associate with the LDAP authentication service from the drop-down list. This role is assigned to all external users who are authenticated on this LDAP database. 3. Click Add.

Steps to add a RADIUS authentication service and associate a role:

1. Go to the ADVANCED > Admin Access Control page. 2. In the External Authentication Services section, select RADIUS from the drop-down list. The Add RADIUS Service window appears. Specify values for the following: a. Realm Name – Enter a name for the realm. A realm is a RADIUS compliant database of authorized user and group records. b. IP Address – Enter the IP address of the RADIUS server. c. Port – Enter the port number of the RADIUS server. Port 1812 is normally used for RADIUS. d. Shared Secret – Enter the secret key which is shared between the Barracuda Web Application Firewall and RADIUS server. Minimum value of the key is 6. e. Timeout – Enter the maximum time in seconds the Barracuda Web Application Firewall will wait for a response from the RADIUS server before retransmitting the packet. f. Default Role – Select a default role to associate with the RADIUS authentication service from the drop-down list. This role is assigned to all external users who are authenticated on this RADIUS database 3. Click Add.

When a default role is associated with the LDAP/RADIUS authentication service, all external users authenticated through the LDAP/RADIUS database are assigned to that role. For example, consider the default role certificate-manager for the configured LDAP server. An external user authenticated through that LDAP database is assigned certificate-manager role, and can perform only certificate management tasks. The ‘admin’ user can change the default role assigned to a user if required.

To change the role assigned to a user:

1. Go to the ADVANCED > Admin Access Control page. 2. In the Administrator Accounts section identify the desired user. 3. Click Edit next to the user. The Edit Administrator Account window appears. 4. Select a role for the user from the Role drop-down list.

273 5. Modify Password and Email Address if required and click Update.

Privileges

A privilege means an access right or permission on a system resource. Privileges are used to control access to the system. You can grant privileges to a role, and then assign the role to one or more users. There are two distinct categories of privileges:

Object Privileges Screen and Operation Privileges

Object Privileges

The following are the key configuration objects that are classified in role based administration:

Object Description Privileges

Services Exhibits all services that are configured on Read: Enables the user to view the the Barracuda Web Application Firewall. configuration of an object, but exempts from modifying the object. Security Policies Exhibits all default and customized security policies. Write: Enables the user to view and modify the configuration of an object, but exempts Authentication Services Exhibits all authentication services such as from deleting the object. Lightweight Directory Access Protocol (LDAP) and Remote Authentication Dial In Read All: Enables the user to view and User Service (RADIUS). modify the configuration of all objects, but exempts from modifying the objects. Write All: Enables the user to view and modify the configuration of all objects, but exempts from deleting the objects.

Screen and Operation Privileges

The Barracuda Web Application Firewall provides several distinct operations. These operations include tasks such as shutting down the system, changing the system time and date, backing up the system configuration, etc. You can grant permission to perform these operations to a role. A role can only execute operations for which it has permission, and is prevented from executing any other operation in the system. For example, when a user is granted ‘appearance’ operation, he can change the system name and reset the image used on the Web interface.

To select an operation, ensure the corresponding Secondary Tab is selected in the Web Interface Privileges section. If you do not select the Secondary Tab, the corresponding operations become inaccessible. The admin user should determine the screens viewable by a user by selecting the Secondary Tabs. Using Templates to Save and Import Configuration Objects en In this article:

Saving Objects Using a Template Importing Objects Add Modify Points to Remember

A template is a collection of configuration components arranged serially in a file. Templates are used to save/import backups of object types like Services, URL profiles, URL Policies, etc., so configuration can be exported to other Barracuda Web Application Firewall boxes in the following scenarios:

Migrate changes from the Barracuda Web Application Firewall in front of QA servers to the Barracuda Web Application Firewall in front of production servers. Import templates provided by Barracuda Web Application Firewall experts to refine policies on standard applications. Patch existing policies. For example, a new OWA template might need an additional Allow Method for a Global ACL. Or a new pattern, like sql-tautology-conditions, might require a refinement to an existing pattern-group. An existing service might require a new keep-alive timeout, already tested and found optimal in the QA network. Take a backup of an application configuration.

274 Saving Objects Using a Template

You can export objects from your configuration by creating a template which includes the objects from the existing configuration, which is saved on your file system.

Use ADVANCED > Templates and select Generate Template as the Template Operation. Select a suitable Template Type and specify the Nam e and Description for the template. Use Exportable Objects to select the parent nodes and child nodes to export using check boxes. Generate t o see your template displayed under Available Templates.

Importing Objects

A saved template can be imported on the configuration tree using Add or Modify. In both cases key parameters are compared to existing objects before they are updated:

Use the Add operation if the key parameters of the imported object do not match an existing object. Duplicate configurations cannot be added. Added objects are added to the selected parent nodes or child nodes of the configuration tree with the saved values. Use the Modify operation when the key parameters match an existing entry. If there is a match, the current values are blindly replaced with values from the imported object. If no object has matching key parameters, nothing is modified. This is considered an error. When a Service template is imported, you can specify an IP address and port for the service created from the template during the Add o peration. Similarly, for a Modify operation, the template modifies an existing service on the box with the specified IP address and port, which makes sense if the source template is generated from a single service. This allows you to incrementally patch a service with template values.

Object Type Key Parameters

Service IP, Port

Server IP, Port

URL Policies Domain, URL, Header, Header Weight

URL Profile URL, Extended Match, Extended Match

Allow/Deny Rules URL, Host Match, Extended Match, Extended Match Sequence

Request Rewrite Rules Request Rewrite Sequence

Response Rewrite Rules Response Rewrite Sequence

Response Body Rewrite Rules Response Body Rewrite Sequence

Security Policy Web Firewall Policy Name

Global ACL URL Match, Extended Match, Extended Match Sequence

Custom Parameter Class Custom Parameter Class Name

Attack Types Attack Type Name

Identity Theft Patterns Identity Theft Pattern Name

Input Types Input Type Name

Add

The Add operation adds the imported object to the selected parent nodes or child nodes, using values from the saved template. An add of an object with duplicate Key Parameters is not allowed. For example, an add of an object of type Server will not succeed if a Server object with a matching Server IP and Server Port already exists. The Add is disallowed.

To add a new template use ADVANCED > Templates and select Import Template as the Template Operation. Select a suitable Template Type and select the Add Operation. Select parent nodes and child nodes you want to add to and click Add. Remove deletes a selection. Browse to locate the Template file path and Import the template file to the selected destination box.

Modify

275 The Modify operation modifies the existing configuration of selected parent nodes or child nodes by using the values from the saved template. Modify only works if an object with matching Key Parameters already exists. If no matching object exists, the Modify is disallowed.

To modify an existing template, use ADVANCED > Templates to select Import Template as the Template Operation. Select a suitable Template Type, then specify the Modify Operation. Select the parent nodes and child nodes where you want to import the modified templates and click Ad d. Remove deletes a selection. Browse to locate the Template file path and Import to patch the existing template.

Points to Remember

1. When importing an SSL based service, note that the service is imported with SSL Status set to On for the front-end and set to Off for the back-end. You need to create relevant certificates, bind them, and set SSL Status to On to complete the service creation. 2. A Modify operation blindly replaces any value of the object's parameters with the values found in the template. However, for the parameters which have multi-valued inputs (for example, Allowed Methods in SECURITY POLICIES > URL Protection), the modify operation results in a union of the existing values and the template values. 3. Template generation does not recursively copy the objects. If you have a policy bound to a service, make sure the policy exists on the destination box before importing the service on the destination box. The most common cases of objects like these within a service are: Policy, Response Pages, Certificates, Parameter Classes, Rate Control pool, Trusted Hosts.

Updating the Firmware in Clustered Units en The firmware can be updated in either Manual Mode or Automatic Mode.

en Updating the Firmware in Manual Mode Updating the Firmware in Automatic Mode Related Articles:

Updating the Firmware in Manual Mode

Use Manual Mode if you intend to update and verify the functionality of the firmware on one unit before upgrading the other unit in the cluster.

When upgrading the firmware version from 7.6.3/7.6.4 to 7.7, Manual mode is recommended for upgrade process.

Perform the following steps to manually update your firmware:

1. Download the new version of the Firmware to both units. 2. From the ADVANCED > High Availability page on the Primary unit, in the Cluster Settings section, change the Failback Mode to Man ual. Wait until the configurations are synchronized, and the Secondary unit changes from Failback Mode to Manual. 3. Ensure the Primary unit is Active and serving requests, and the Secondary unit is in Standby state. 4. From the ADVANCED > Firmware Update > Firmware Download section on the Secondary unit, click Apply Now to apply the new version. This reboots the unit. 5. Once the Secondary unit reboots successfully, click the Failover button on the Primary unit to move all active Services from the Primary unit to the Secondary unit.

- Since the units are using different firmware versions, configuration changes made on one unit will not be synchronized with the other unit.

- When the Secondary unit is upgraded to the higher firmware version and the Primary unit is still in the 7.7 firmware version, then the Failover button will not be available on the Primary unit to manually failover the active Services from the Primary unit to the Secondary unit. If you wish to verify the functionality of the upgraded (higher) firmware version on the Secondary unit before performing an upgrade on the Primary unit, REBOOT the Primary unit to automatically failover all active Services from the Primary unit to the Secondary unit. When successfully verified, update the Primary unit (See step 6 (a)).

6. The Secondary unit now assumes all active Services and serves all requests. Verify functionality of the firmware on the Secondary unit. a. When successfully verified, update the Primary unit. i. From the ADVANCED > Firmware Update > Firmware Download section on the Primary unit, click Apply Now to

276 6. a. i.

apply the latest firmware. This reboots the unit. ii. Once the Primary unit reboots successfully, click the Failback button on the Primary unit to move all active Services from the Secondary unit to Primary unit. iii. Now, change the Failback Mode to Automatic if required. b. If you encounter unexpected problems with the latest firmware version, contact Barracuda Networks Technical Support. Alternatively, revert to the previous firmware version. See Steps to Revert the Firmware in Updating Firmware on the Barracuda Web Application Firewall.

Updating the Firmware in Automatic Mode

Perform the following steps to update the firmware in automatic mode:

1. Download the new version of the Firmware to both units. 2. Ensure the Primary unit is Active and serving requests, and the Secondary unit is in Standby state. 3. From the ADVANCED > Firmware Update > Firmware Download section on the Secondary unit, click Apply Now to apply the new version. This reboots the unit. 4. Once the Secondary unit reboots successfully, it remains in the Standby state. 5. From the ADVANCED > Firmware Update > Firmware Download section on the Primary unit, click Apply Now to apply the new version. This reboots the unit. If the heartbeat from the Primary unit is missed while it is rebooting, all active Services may failover for a short time to the Secondary unit which will assume Services.

High Availability How to Set Up a High Availability Environment with Two Barracuda Web Application Firewalls Failover and Failback in an Active-Active Cluster How to Remove or Replace Units in a Cluster Barracuda Web Application Firewall Hardware Features en System hardware features include front and back panel controls, ports and LED indicators on the Barracuda Web Application Firewall.

Front Panel Features of Model 360 / 460

The following figure shows the front panel components of Model 360 and 460 described in Table 1.

Table 1

Diagram Location Description

1 On/Off button

2 Reset button

3 Power Indicator

4 Disk Activity

5 Management Network Activity

6 Indicates System Bypass Mode

7 Indicates a Failed Status of the System

8 LAN Port

277 9 WAN Port

Back Panel Features of Model 360 / 460

The following figure shows the back panel components described in Table 2.

Table 2

Diagram Location Description

1 Unused USB Port

2 Unused USB Port

3 Unused Network Port

4 Unused USB Port

5 Unused USB Port

6 VGA Display (console)

7 Unused Printer Port

8 Serial Port

9 Mouse

10 Keyboard

11 Power Supply

If your system was shipped during or after January 2013, the Front Panel is as follows:

The components are described in Table 3.

Table 3

Diagram Location Description

1 Disk Activity

2 Power Indicator

3 Reset button

4 On/Off button

278 5 LAN Port

6 WAN Port

The Back Panel is as follows: .

The components are described in Table 4.

Table 4

Diagram Location Description

1 Unused USB Port

2 Unused USB Port

3 Management Port

4 VGA Display (console)

5 DVI Port

6 Unused USB Port

7 Unused USB Port

8 Mouse

9 Keyboard

10 Power Supply

Front Panel Features of Model 660

The following figure shows the front panel components described in Table 5.

Table 5

Diagram Location Description

1 On/Off button

2 Reset button

279 3 Power Indicator

4 Disk Activity

5 Unused LED

6 Indicates System Bypass Mode

7 Indicates a Failed Status of the System

8 WAN Port

9 LAN Port

Back Panel Features of Model 660

The following figure shows the back panel components described in Table 6.

Table 6

Diagram Location Description

1 Management Port 1

2 Management Port 2

3 VGA Display (console)

4 Unused Printer Port

5 Serial Port

6 Unused USB Port

7 Unused USB Port

8 Mouse

9 Keyboard

10 Power Supply

Front Panel Features of Model 86x and 96x

The following figure shows the front panel components of the Model 86x and 96x described in Table 7.

280 Table 7

Diagram Location Description

1 On/Off button

2 Reset button

3 Power Indicator

4 Disk Activity

5 Management Network Activity Port

6 Unused Network Port

7 Unused LED

8 Unused LED

In the Barracuda Web Application Firewall 861, 862, 961 and 962, when the unit is forced into a Bypass on Failure or Hard Bypass st ate, the Bypass LED on the front panel will not be lit.

Back Panel Features of Model 86x and 96x - Ethernet Interface

The following figure shows the back panel components of Model 86x and 96x with ethernet interface described in Table 8.

Table 8

Diagram Location Description

1 WAN Port

2 LAN Port

3 Management Port

4 Unused Network Port

5 VGA Display (console)

6 Unused Printer Port

281 7 Serial Port

8 Unused USB Port

9 Unused USB Port

10 Not Connected

11 Keyboard

12 Mouse

13 Redundant Power Supply

14 Redundant Power Supply

Back Panel Features of Model 86x and 96x - Fiber Interface

The following figure shows the back panel components of Model 86x and 96x with fiber interface described in Table 9.

Table 9

Diagram Location Description

1 Fiber WAN Port

2 Fiber LAN Port

3 Unused Network Port

4 Management Port

5 VGA Display (console)

6 Unused Printer Port

7 Serial Port

8 Unused USB Port

9 Unused USB Port

10 Not Connected

11 Keyboard

12 Mouse

13 Redundant Power Supply

14 Redundant Power Supply

Hardware Compliance

This section contains compliance information for the Barracuda Web Application Firewall hardware.

282 Notice for the USA

Compliance Information Statement (Declaration of Conformity Procedure) DoC FCC Part 15: This device complies with part 15 of the FCC Rules.

Operation is subject to the following conditions:

1. This device may not cause harmful interference, and 2. This device must accept any interference received including interference that may cause undesired operation. If this equipment does cause harmful interference to radio or television reception, which can be determined by turning the equipment off and on, the user in encouraged to try one or more of the following measures:

Reorient or relocate the receiving antenna. Increase the separation between the equipment and the receiver. Plug the equipment into an outlet on a circuit different from that of the receiver. Consult the dealer on an experienced radio/ television technician for help.

Notice for Canada

This apparatus compiles with the Class B limits for radio interference as specified in the Canadian Department of Communication Radio Interference Regulations.

Notice for Europe (CE Mark)

This product is in conformity with the Council Directive 89/336/EEC, 92/31/EEC (EMC).

How to Clear Configuration on the Barracuda Web Application Firewall en To clear the existing configuration and restore the Barracuda Web Application Firewall to its initial configuration, use the Clear Configuration feat ure available on the ADVANCED > System Configuration > Configuration Tools section. This feature clears all system configuration including services, profiles, routes, interfaces etc., but the IP configuration settings on the BASIC > IP Configuration page remains intact.

It is recommended to take a back up of existing configuration before performing the Clear Configuration operation. Rebooting the System in Recovery Mode en If your Barracuda Web Application Firewall experiences a serious issue that impacts its core functionality, you can use diagnostic and recovery tools that are available at the reboot menu to return your system to an operational state.

Before you use the diagnostic and recovery tools, do the following:

Use the built-in troubleshooting tools on the ADVANCED > Troubleshooting page to help diagnose the problem. Perform a system restore from the last known good backup file. Contact Barracuda Networks Technical Support for additional troubleshooting tips.

As a last resort, you can reboot your Barracuda Web Application Firewall and run a memory test or perform a complete system recovery, as described in this section.

283 To perform a system recovery or hardware test:

1. Connect a monitor and keyboard directly to your Barracuda Web Application Firewall. 2. Reboot the system by doing one of the following: a. Click Restart on the BASIC > Administration page. b. Press the Power button on the front panel to turn off the system, and then press the Power button again to turn on the system. The Barracuda splash screen displays with the following three boot options: Barracuda Recovery Hardware_Test 3. Use your keyboard to select the desired boot option, and press Enter. You must select the boot option within three seconds of the splash screen appearing. If you do not select an option within three seconds, the Barracuda Web Application Firewall defaults to starting up in the normal mode (first option).

For a description of each boot option, refer to Reboot Options.

To stop a hardware test, reboot your Barracuda Web Application Firewall by pressing Ctrl-Alt-Del.

Reboot Options

Reboot Options Description

Barracuda Starts the Barracuda Web Application Firewall in the normal (default) mode. This option is automatically selected if no other option is specified within the first three (3) seconds of the splash screen appearing.

Recovery Displays the Recovery Console where you can select the following options:

Barracuda Recovery – Repairs the file system on the Barracuda Web Application Firewall. Full Barracuda Recovery – Restores the factory settings on your Barracuda Web Application Firewall and clears out all configuration information. Enable remote administration – Initiates a connection to Barracuda Central that allows Barracuda Networks Technical Support to access the system. Another method for enabling this troubleshooting connection is to click Establish Connection to Barracuda Central on the ADVANCED >Troubleshooting pag e. Diagnostic memory test – Runs a diagnostic memory test from the operating system. If problems are reported when running this option, we recommend running the Hardware_Test option next. Exit – Exits from the Recovery Console.

Hardware_Test Performs a thorough memory test that shows most memory related errors within a two-hour time period. The memory test is performed outside of the operating system and can take a long time to complete. Reboot your Barracuda Web Application Firewall to stop the hardware test.

Replacing a Failed System en Before you replace your Barracuda Web Application Firewall, use the tools provided on the ADVANCED > Troubleshooting page to try to resolve the problem.

In the event that a Barracuda Web Application Firewall fails and you cannot resolve the issue, customers that have purchased the Instant Replacement service can call Barracuda Networks Technical Support and arrange for a new unit to be shipped out within 24 hours.

284 After receiving the new system, ship the old Barracuda Web Application Firewall back to Barracuda Networks at the address below with an RMA number marked clearly on the package. Barracuda Networks Technical Support can provide details on the best way to return the unit.

Barracuda Networks 3175 S. Winchester Blvd Campbell, CA 95008

To set up the new Barracuda Web Application Firewall so it has the same configuration as your old failed system, restore the backup file from the old system onto the new system, and then manually configure the new system’s IP address information on the BASIC > IP Configuration page. For information on restoring data, refer to Backing up and Restoring your System Configuration. Certificate Management en Certificate Management

Configure the Barracuda Web Application Firewall to use SSL Certificates and Keys using the instructions below:

Introduction to Certificates How to Add an SSL Certificate Using Client Certificates Installing SSL Certificates with Correct Chain Order Creating a Client Certificate

Introduction to Certificates en In this article:

en Overview SSL Implementation and Configuration SSL for Client to Barracuda Web Application Firewall Transmissions SSL for Barracuda Web Application Firewall to Server Transmissions

Overview

The Barracuda Web Application Firewall implements Secure Socket Layer (SSL) encryption using PKI objects, which encrypts transmitted data, and allows authentication of sender and receiver. You can use SSL encryption between a client and the Barracuda Web Application Firewall, and/or between the Barracuda Web Application Firewall and web servers by creating or uploading certificates.

In an SSL transmission between a client and a server, the client requests a secure connection, and the server responds with a certificate, identifying the certificate authority (CA) and the server’s public encryption key. The certificate allows the client to verify the server identity.

The Barracuda Web Application Firewall acts as a server on the front-end (Internet facing), receiving client requests. On the back end, the Barracuda Web Application Firewall acts as a client to the web servers, forwarding requests to them. In each case, you can use SSL to provide end-to-end secure data for requests and responses. The Barracuda Web Application Firewall allows Certificates obtained from a trusted CA to be uploaded, or can create a self-signed certificate to implement SSL.

Digital certificates created using the Barracuda Web Application Firewall are of the standard X.509 format and are considered self-signed.

SSL Implementation and Configuration

SSL for Client to Barracuda Web Application Firewall Transmissions

The Barracuda Web Application Firewall receives requests from clients on behalf of the back-end server. When a request is received from a client, the Barracuda Web Application Firewall acts as a server to the requesting client. It can be configured to provide a certificate (a self signed certificate created on the unit, or a certificate issued by a trusted CA uploaded to the unit) which allows the client to authenticate the request transactions and send them in encrypted form.

For more information on how to generate self-signed certificates, or to upload trusted certificates, see How to Add an SSL Certificate.

285 To configure the Barracuda Web Application Firewall to use SSL in client communications, create an SSL enabled service and refer to Configurin g SSL between a Client and the Service for specific instructions on configuring SSL. Additionally, the Barracuda Web Application Firewall can be configured to require the client to provide a certificate for authentication, denying communication with clients who fail to do so.

SSL for Barracuda Web Application Firewall to Server Transmissions

The Barracuda Web Application Firewall receives and verifies the server’s certificate. The Barracuda Web Application Firewall may provide a certificate in return, if client authentication is required by the back-end server.

To configure the Barracuda Web Application Firewall to use SSL in Server communication, Add a server for the respective service on BASIC > Services, and configure the Barracuda Web Application Firewall to validate the server certificate and optionally to present a client certificate. See Configuring Server Settings. For information on Client Certificates, see Allowing or Denying Client Certificates.

How to Add an SSL Certificate en In this article:

Overview Certificate Components Key Pair Distinguished Name (DN) Token Self-signed Certificate Trusted Certificate Signed Certificate Uploading a Signed Certificate Uploading a Trusted Certificate

Overview

A signed certificate is a digital identity document that enables both server and client to authenticate each other. Certificates are used with HTTPS protocol to encrypt secure information transmitted over the internet. A certificate can be generated or procured from a third party Certificate Authority (CA). Generated certificates can be self-signed or signed by a trusted third-party CA. A certificate contains information such as user name, expiration date, a unique serial number assigned to the certificate by a trusted CA, the public key, and the name of the CA that issued the certificate.

Certificate Components

Key Pair

The Barracuda Web Application Firewall implements an asymmetric methodology for encryption, where two related keys are used in combination. A key pair consists of a public key and a private key which work together, with one of the key pair encrypting messages, and the other decrypting encrypted messages.

Exposure of the public key does not endanger the secure transactions because the private key cannot be derived from it.

Distinguished Name (DN)

The Distinguished Name (DN) in the certificate uniquely identifies the public key owner who issues the certificate.

Token

A token is a cryptographic item used for secure storage and transfer of private interface and certificate. Currently, the Barracuda Web Application Firewall supports only the PKCS #12-type token. The PKCS #12 token can be loaded onto the Barracuda Web Application Firewall from a remote

286 system or saved from the Barracuda Web Application Firewall onto a remote system.

CA Certificate

A trusted certificate is a third-party certificate issued by a Certificate Authority (CA) which can be uploaded and saved on the Barracuda Web Application Firewall. This certificate can be added to a certificate chain, where it is used for encryption and authentication. Browsers requiring certificates from a CA will require the procurement and upload of the certificate before communication between a client and a server can be established.

The Certificates managed by the Barracuda Web Application Firewall:

Self-signed Certificates Trusted Certificates

Self-signed Certificate

A self-signed certificate (also called user certificate) can be generated by the Barracuda Web Application Firewall to provide strong encryption without the cost of purchasing a certificate from a trusted certificate authority (CA). However, web browsers cannot verify the authenticity of the certificate and therefore display a warning every time a user accesses the administration interface. Because of this, self-signed certificates are ideal for test purposes, and may not be desirable as a production solution.

Trusted Certificate

Trusted certificates, issued by trusted Certificate Authorities (CA), are usually recognized by web browsers and no additional configuration is required.

Creating a Self-signed SSL Certificate

A self-signed X.509 digital certificate can be created by the Barracuda Web Application Firewall. The X.509 certificate type is one of the most common, and the International Telecommunication Union (ITU) recommends it, but it is not the industry standard for certificates. So an X.509 certificate generated by the Barracuda Web Application Firewall may or may not be accepted by clients or web servers.

To create a self-signed SSL certificate:

1. Go to the BASIC > Certificates page, and click Create Certificate in the Certificate Generation section. 2. Follow the displayed instructions to fill in all fields. 3. Click Generate Certificate.

Signed Certificate

A self-signed certificate signed by a trusted Certificate Authority (CA) is known as a Signed Certificate. The generated certificates are stored in the Saved Certificates section. A Certificate Signing Request (CSR) is created each time you generate a certificate using the Barracuda Web Application Firewall. It contains information such as organization name, domain name, locality, country and the public key. To convert a self-signed certificate to a signed certificate, download the CSR file and send it to a trusted third party CA such as VeriSign or Thawte for signing. A CA administrator verifies the CSR, signs the request, and returns a signed certificate to be used for SSL based Services.

Steps to Download a CSR:

1. Go to the BASIC > Certificates page. 2. In the Saved Certificates section, identify the certificate that needs to be signed by a third party trusted CA. 3. Click CSR under the Download option. A pop-up window appears. Select Save File to save the file to the location you desire. A CSR file is saved with the extension .csr. 4. You can send this CSR file to a trusted Certificate Authority (CA) for signing. A CA verifies the CSR and returns a signed certificate SSL based Services can use.

Once the CSR is signed and returned, the certificate file is replaced by the new certificate. Extract the key and upload the signed certificate on the Barracuda Web Application Firewall.

Steps to Extract the Key from a Certificate:

1. Click Certificate under the Download option. The Save Token pop-up window appears. 2. Enter the pass phrase in the Encryption Password field and click Save. The certificate gets exported as a PKCS #12 token. 3. Extract the private key from the PKCS #12 token using the same pass phrase. The openssl command used to extract the key is: "openssl pkcs12 -in < pkcs-token > -nocerts -out < key.pem >" 4. Once you extract the private key, you need to upload the certificate on the Barracuda Web Application Firewall.

287 Uploading a Signed Certificate

You can upload a certificate either in PKCS#12 Token or PEM format. Perform the following steps to upload a certificate:

1. Go to the BASIC > Certificates page. 2. In the Upload Certificate section, specify a certificate name, select the certificate type (PKCS12 Token or PEM Certificate) and enter appropriate values in other fields. 3. Click Upload Now.

Uploading a Trusted Certificate

1. Go to the BASIC > Certificates page. 2. In the Upload CA Certificate section, specify a certificate name and select the CA certificate that you want to upload.

Certificate should be uploaded in PEM (*.pem) format.

3. Click Upload Now.

Once a certificate is uploaded on the BASIC > Certificates page, it can be associated with the Services on the BASIC > Services page. Using Client Certificates en en

In this Section:

Allowing or Denying Client Certificates Client Certificate Validation Using OCSP and CRLs How to Pass Client Certificate Details to a Back-end Server

Installing SSL Certificates with Correct Chain Order en

A browser running on a desktop system can build a certificate chain correctly regardless of the order in which certificates are presented. However, a browser running on a mobile device, such as an Android, may require the certificates to be presented in the correct order.

This article explains how to upload the certificate chain in the order that ensures it is properly presented to the client.

Step 1 - Downloading the Certificate

Use the following steps to download the certificate from the Barracuda Web Application Firewall:

1. Log into the Barracuda Web Application Firewall web interface, and go to the BASIC > Certificates page. 2. In the Saved Certificates table, locate the certificate, and click Certificate in the Download column. 3. In the Save Token page, enter a pass phrase in the Encryption Password field, and click Save. 4. The certificate is exported as a PKCS #12 token which includes the private key.

Private Key If you already have the private key, ensure it is decrypted before you upload it to the Barracuda Web Application Firewall.

You can obtain the private key from the device on which the Certificate Signing Request (CSR) was generated, or you can extract it from a previously uploaded certificate.

Open the private key file in a text editor such as WordPad or Notepad++ (do not use Notepad), and if the word ENCRYPTED is present, the private key is encrypted. Refer to Step 2 - Extracting the Private Key point 5 for the private key decryption process.

Step 2 - Extracting the Private Key

288 This section describes how to extract the private key from a certificate using OpenSSL.

If the private key is encrypted, use the following steps to extract the private key from the PKCS #12 token and decrypt the private key on either a Linux system or a Windows system.

OpenSSL Linux generally comes with OpenSSL preinstalled. You can download OpenSSL for Windows from http://downloads.sourceforge.net/gnuwin32/openssl-0.9.8h-1-setup.exe

1. If you are using a Windows system, change the working directory so that you can run OpenSSL from the command line: C:\OpenSSL-Win32\bin\> 2. Enter the following command to simultaneously extract and encrypt the private key: openssl pkcs12 -nocerts -in certificate.pfx -out private_key_encrypted.pem 3. When prompted, enter the password you entered when downloading the .pfx file from the Barracuda Web Application Firewall in point 3 i n the section Step 1 - Downloading the Certificate. 4. When prompted again, enter a password to encrypt the private key. This is necessary to keep the private key secured at all times, even when it is displayed onscreen. 5. Enter the following command to decrypt the encrypted private key: openssl rsa -in private_key_encrypted.pem -out private_key_decrypted.pem 6. When prompted, enter the password you created in point 4 of this section.

Step 3 - Getting the Intermediate and Root Certificates

You can download the intermediate and root certificates of most certificate authorities (CAs) using Microsoft® Internet Explorer ® . However, you may need to follow the support link on the CA site to obtain the correct intermediate and root certificates.

1. On the system where you downloaded the certificate, double-click the downloaded certificate, for example, mycertificate.cer, and click the Certificate Path tab. 2. Double-click each CA in the issuer hierarchy, and note the details including the name of the issuer and the certificate expiry date. These details are helpful in identifying the intermediate and root certificates in the steps that follow. 3. Open Internet Explorer, and go to Tools > Internet Options > Content > Certificates . 4. Click the Intermediate Certification Authorities tab, and select the relevant certificate. 5. Click Export. Follow the instructions in the Wizard, exporting the certificate as Base-64 encoded X.509 (.CER), and saving the export with the appropriate name. 6. In the Certificates page, click the Trusted Root Certification Authorities tab, and select the root certificate. 7. Click Export. Follow the instructions in the Wizard, exporting the certificate as a Base-64 encoded X.509 (.CER), and saving the export with an appropriate name. 8. Because Internet Explorer adds trailing line breaks to files, open each exported file in a basic editing program such as WordPad or Notepad++ (do not use Notepad), and remove any trailing line breaks.

Step 4 - Uploading the Certificate

Use the following steps to upload the certificate chain in the correct order, using the screenshot for reference:

1. In the Barracuda Web Application Firewall web interface, go to the BASIC > Certificates page. 2. In the Upload Certificate section, enter a name for the certificate in the Certificate Name field. 3. Select the Certificate Type as PEM Certificate. 4. Select Yes for Allow Private Key Export, and set Assign Associated Key to No. 5. In the Signed Certificate field, click Browse, and navigate to and select the Server Certificate. 6. In the Certificate Key field, click Browse, and navigate to and select the Private Key. 7. In the intermediary Certificates field, click Browse, and navigate to and select the Intermediate Certificate. 8. Click the plus ( + ) symbol following the Intermediary Certificates field. 9. In the new intermediary Certificates field, click Browse, and add the second Intermediate Certificate. 10. Click the plus ( + ) symbol following the Intermediary Certificates field, navigate to and select the Root Certificate. 11. Click Upload Now to upload the certificate.

289 11.

12. The uploaded certificate displays in the Upload Certificates section of the Saved Certificates table .

Warning Message If a warning message such as Unable to verify issuer certificate displays when uploading the certificates, this means that the Barracuda Web Application Firewall is unable to verify the issuer from its issuer information internal bundle. This Barracuda We b Application Firewall internal bundle contains issuer information updated with each firmware release, and therefore may be incomplete. Conversely, client browsers update issue information dynamically and can verify the issuer from the information presented, so this warning can be ignored.

Creating a Client Certificate en Before creating a client certificate you should create a CA certificate which can be used as the root CA certificate to sign the client certificates. To create a CA certificate for the server designated as SSL CA server, perform the following steps:

1. Generate a Private Key for the CA Certificate 2. Create a CA Certificate using the Private Key 3. Import the CA Certificate to the Barracuda Web Application Firewall 4. Enable Client Authentication on the Barracuda Web Application Firewall 5. Create a Client Certificate 6. Converting PEM File to PKCS #12 Format 7. Import the Client Certificate to the Browser

Step 1 - Generate a Private Key for the CA Certificate

To generate a key for a CA certificate, run the following openssl command on your server:

openssl genrsa 2048 > ca-key.pem

This generates a private key “ca-key” in PEM format.

Step 2 - Create a CA Certificate using the Private Key

Use the private key generated in Step 1 to create the CA certificate for the server. The openssl command to generate a CA certificate is as follows:

openssl req -new -x509 -nodes -days 1000 -key ca-key.pem > ca-cert.pem

You will be prompted to provide certain information which will be entered into the certificate. See the example below:

290 Country Name (2 letter code) [AU]: US State or Province Name (full name) [Some-State]: California Locality Name (eg, city) []: Campbell Organization Name (eg, company) [Internet Widgits Pty Ltd]: Barracuda Networks Organizational Unit Name (eg, section) []: Engineering Common Name (eg, YOUR name) []: barracuda.yourdomain.com Email Address []: [email protected]

This creates the CA certificate with the values above. This certificate acts as a root CA certificate for authenticating the client certificates.

Step 3 - Import the CA Certificate to the Barracuda Web Application Firewall

The created certificate needs to be uploaded in the BASIC > Certificates > Upload Trusted (CA) Certificate section.

Step 4 - Enable Client Authentication on the Barracuda Web Application Firewall

To be able to use the CA certificate for validating client certificates, client authentication should first be enabled.

Steps to enable client authentication:

1. Go to the BASIC > Services page. 2. In the Services section, identify the service for which you want to enable client authentication. 3. Click Edit next to the service. In the Service edit page, scroll down to the SSL section. 4. Set Enable Client Authentication and Enforce Client Certificate to Yes. 5. Select the check box(es) next to the Trusted Certificates parameter. 6. Specify values for other parameters as required, and click Save Changes.

Step 5 - Create a Client Certificate

To create a client certificate, use the following example:

openssl req -newkey rsa:2048 -days 1000 -nodes -keyout client-key1.pem > client-req.pem

Generating a 2048 bit RSA private key writing new private key to 'client-key1.pem'

...... +++

..+++

-----

You are about to be asked to enter information that will be incorporated into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.

-----

Country Name (2 letter code) [AU]: US

State or Province Name (full name) [Some-State]: California

Locality Name (eg, city) []: Campbell

Organization Name (eg, company) [Internet Widgits Pty Ltd]: Barracuda Networks

Organizational Unit Name (eg, section) []: Tech Support

291 Common Name (eg, YOUR name) []: barracuda.mydomain.com

Email Address []: [email protected]

Please enter the following 'extra' attributes to be sent with your certificate request

A challenge password []: Secret123

An optional company name []: -

This creates the private key “client-key1” in PEM format.

Now, use the following example to create a client certificate that will be signed by the CA certificate created in Step 2.

openssl x509 -req -in client-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > client-cert1.pem

Signature ok subject=/C=US/ST=California/L=Campbell/O=Barracuda Networks/OU=Tech Support/CN=barracuda.mydomain.com/[email protected]

Getting CA Private Key

Step 6 - Converting PEM File to PKCS #12 Format

Use the following command to convert the “client-cert1.pem” certificate along with “client-key1.pem” to a Personal Information Exchange file (pfx token).

openssl pkcs12 -export -in client-cert1.pem -inkey client-key1.pem -out client-cert1.pfx

Enter Export Password:secret

Verifying - Enter Export Password: secret

Step 7 - Import the Client Certificate to the Browser

The client certificate created above should be sent to the client to be imported on their browser.

SNMP GET Commands en The following table describes in detail the SNMP GET commands to view important statistics of the Barracuda Web Application Firewall.

Name Object ID Description

TotalApplications 1.3.6.1.4.1.20632.8.2 Total applications configured.

TotalServers 1.3.6.1.4.1.20632.8.3 Total servers configured.

TotalAttacks 1.3.6.1.4.1.20632.8.4 Count of attacks in last one hour.

ActiveApplications 1.3.6.1.4.1.20632.8.5 Total applications configured whose status is ON.

292 ActiveServers 1.3.6.1.4.1.20632.8.6 Total servers whose operational status is in-service.

SystemLoad 1.3.6.1.4.1.20632.8.8 System load in percentage.

CPUFanSpeed 1.3.6.1.4.1.20632.8.9 CPU fan speed in rotations per min.

SystemFanSpeed 1.3.6.1.4.1.20632.8.10 System fan speed in rotations per min.

CPUTemperature 1.3.6.1.4.1.20632.8.11 CPU temperature in degree celsius.

FirmwareStorage 1.3.6.1.4.1.20632.8.12 Firmware storage in percentage.

LogStorage 1.3.6.1.4.1.20632.8.13 Log Storage in percentage.

HighAvailabilityStatus 1.3.6.1.4.1.20632.8.14 High Availability Status.

OperationalMode 1.3.6.1.4.1.20632.8.15 Operation mode.

DataPathStatus 1.3.6.1.4.1.20632.8.16 Data Path Status

LinkStatus 1.3.6.1.4.1.20632.8.17 Link Status.

Extended Match Syntax Help en Extended Match and Condition Expression

Extended Match and Condition Expressions can be configured for various rule types, allowing you to specifically define which requests/responses need the rule applied. You can configure conditions based on parameters or elements of a request/response, combining them in a very flexible manner, and applying the rule security settings only to those that match the defined expression.

A few examples:

Header Host co example.com – match a request whose Host header contains example.com Parameter userid ex – match any request in which the parameter userid is present (Header Host eq www.example.com) && (Client-IP eq 10.0.0.0/24) – match a request whose host header is www.example.com an d whose client IP address is in the 10.0.0.* subnet.

Quick reference

Extended Match Expression: Element Match (Expression) [Join (Expression) ...] Join: &&, || Element Match: Element [Element Name] Operator [Value] Element: Request Elements: Method, HTTP-Version, Client-IP, URI, URI-Path, Header Request Parameters: Parameter, Pathinfo Response Elements: Status-code, Response-Header Operator: Matching: eq, neq, req, nreq Containing: co, nco, rco, nrco Existence: ex, nex

Structure of an Extended Match Expression

An Extended Match expression consists of one or more Element Matches, combined using Join operators AND and OR. Parentheses delimit individual Element Matches when using join operators. Parentheses can be nested.

An Element Match consists of an Element, an optional Element Name, an Operator followed by an optional Value. Some elements (like Header

293 ) require an Element Name (like User-Agent) whereas some elements (like HTTP-Version) require no further qualification. Also, some operators (like eq) require a value, whereas some don't (like ex).

Tokens are delimited by space and the parenthesis characters. Double quotes (") can be used to enclose single tokens which contain parenthesis characters or spaces. The back-slash character can also be used to escape, that is, remove the special meaning of the special characters (space and parenthesis).

Operators

The following are the possible operators in an Element Match. The operators are case insensitive so, for example, eq, Eq and EQ all behave the same.

eq – true if the operand is equal to the given value. A case insensitive string comparison is performed, so a value of "01" does not equal the value "1", whereas the values "one" and "ONE" are equal. neq – true if the operand is not equal to the given value. A case insensitive string comparison is performed. co – true if the operand contains the given value. nco – true if the operand does not contain the given value. rco – true if the operand contains the given value, specified as a regular expression. nrco – true if the operand does not contain the given value, specified as a regular expression. req – true if the operand matches the given value, specified as a regular expression. nreq – true if the operand does not match the given value, specified as a regular expression. ex – true if the operand exists. A value is not required. nex – true if the operand does not exist. A value is not required.

Elements

The following Elements are allowed in an expression. Elements and Element Names are case insensitive, so Method and METHOD behave the same.

Client-IP – The IP address of the client sending the request. The IP address can be either host IP address or subnet IP address specified by a mask. Only eq and neq operations can be used with this element. Examples: (Client-IP eq 192.168.1.0/24), (Client-IP eq 192.168.1.10) Method – The HTTP Method specified in the request. Example: (Method eq GET) HTTP-Version – The version of the HTTP protocol of the request. Example: (HTTP-Version eq HTTP/1.1) URI – The Uniform Resource Identifier in the request. This includes any query parameters in the request. Example: (URI rco /abc.*html?userid=b) URI-path – The path portion of the URI, excluding any query parameters. Example: (URI-path req \/.*copy%20[^/]*) Parameter – A parameter in the query string part of the URL and serves as a name-value pair. The special parameter "$NONAME_PARAM" allows reference to a parameter when the parameter name is absent. Examples: (Parameter sid eq 1234), (Parameter $NONAME_PARAM co abcd) Pathinfo – The portion of the URL considered the PATH_INFO on the server. The Barracuda Web Application Firewall uses a set of known extensions to determine whether a portion of the URL is the Pathinfo or not. For example, if the request URL is /twiki/view.cg i/Engineering, then, /Engineering is considered to be the pathinfo rather than part of the URL. Example: (PathInfo rco abc*) Header – An HTTP header in the request. Requires an Element Name to identify which header, following the word Header. Example: (Header Accept co gzip). This will check if the "Accept:" header contains the string "gzip". X509_OU – The Organizational Unit (OU) stated in the X.509 certificate. Example: (X509_OU eq Engineering Division). When Client Authentication is enabled for a HTTPS service, the certificate presented by the client is matched with the element value. If the request matches the rule, the Barracuda Web Application Firewall executes the specified action.

To Enable Client Authentication, click Edit in the Options column next to the service on the BASIC > Services page in the Services section.

Not all elements are allowed in every expression. The following restrictions apply:

Request rules (ACLs, URL Policy, URL Profiles) allow only the elements Method, HTTP-Version, Header, Client-IP, URI, URI-Path, Pat hInfo, and Parameter. Request Rewrite Condition allows only the elements Method, HTTP-Version, Header, Client-IP, and URI. Response Rewrite Condition allows only the elements Method, HTTP-Version, Header, Client-IP, URI, Status-code and Response-He ader.

Joins

Expressions can be joined using:

294 || – Or, checks if either expression is true. && – And, checks if both expressions are true.

Element Matches can be combined as long as the Element Matches are enclosed in parentheses. You cannot combine Element Matches without parentheses. Example: (Header cookie ex) && (URI rco .*\.html) && (Method eq GET)

Nested sub-expressions can be created by enclosing expressions in parentheses, making the expression more readable as well as unambiguous. Example: (HTTP-Version eq HTTP/1.1) && ((Header Host eq www.example.com) || (Header Host eq website.example.com))

Escaping

The space character and the parentheses characters are special characters which cause the parser to split the string into tokens at these separators. In some cases, you must specify these characters as part of the value itself. For example, the User-Agent header typically contains both spaces and parentheses, as in:

User-Agent: Mozilla/5.0 (Linux i686; en-US; rv:1.8.1.3) Firefox/2.0.0.3

When a value contains space or parenthesis characters, they must be escaped by prefixing them with a back-slash (\), or by enclosing the entire value in double-quotes ("). Examples:

Header User-Agent eq "Mozilla/5.0 (Linux i686; en-US; rv:1.8.1.3) Firefox/2.0.0.3" Header User-Agent eq Mozilla/5.0\ $Linux\ i686;\ en-US;\ rv:1.8.1.3$\ Firefox/2.0.0.3

The double-quote character itself must be escaped with a back-slash. This is true whether or not it is inside a quoted string. Note that the single quote character has no special meaning, and is treated as any other character.

To specify the back-slash character itself, it must be escaped as "\\". This is true whether or not it is within a quoted string.

The back-slash character escapes all characters, not just special characters. Thus, "\c" stands for the character "c" etc. In other words, back-slash followed by any character stands for the character, whether or not that character has a special meaning in the extended match syntax. Attacks Description - Action Policy en The following tables describe the attack actions under each attack group: Protocol Violations: Click here to expand...

Protocol Violations

Attack ID Attack Action Attack Name in Description Severity Attack Type Name Web Firewall Logs

16 Directory DIRECTORY_TRA The user attempted Alert Directory Traversal Traversal Beyond VERSAL_BEYOND to access the files Root _ROOT and commands beyond the document root directory/CGI root directory.

125 Get Request with GET_REQUEST_W The HTTP GET Alert Protocol Exploit Content Length ITH_CONTENT_LE request was NGTH detected with a Content-Length request header.

126 Missing Host MISSING_HOST_H The version HTTP/ Alert Protocol Exploit Header EADER 1.1 request was sent without the mandatory Host request header.

295 121 Invalid Header INVALID_HEADER The request with an Alert Protocol Exploit invalid HTTP request header name-value pair.

118 Invalid Method INVALID_METHOD The request Alert Protocol Exploit invoked with an invalid HTTP method.

77 Invalid or INVALID_OR_MAL The Barracuda Web Alert Protocol Exploit Malformed HTTP FORMED_REQUE Application Firewall Request ST has found an issue in normalizing the URI or header components of the requests, which indicates the request is either invalid or malformed.

129 Parameter Too PARAM_TOO_LAR A HTTP POST Alert Protocol Exploit Large GE method request where the value of a parameter sent as URL-encoded exceeds 1024 KB.

123 Malformed MALFORMED_CO The Content-Length Alert Protocol Exploit Content Length NTENT_LEN request header has values such as Meta characters or alphabetical value instead of numerical value.

124 Malformed Cookie MALFORMED_CO The request Alert Protocol Exploit OKIE contains a cookie that does not conform to the HTTP cookie specifications.

120 Malformed MALFORMED_RE The HTTP request’s Alert Protocol Exploit Request Line QUEST_LINE end of line was specified with a value other than the mandatory /r/n characters.

122 Malformed Header MALFORMED_HEA The header name Alert Protocol Exploit DER_LINE does not conform to the HTTP protocol specifications.

296 128 Malformed MALFORMED_PAR The Barracuda Web Alert Protocol Exploit Parameter AM Application Firewall found an issue in normalizing and parsing the name or the value of a parameter found in the query or the POST body and flagged the request as containing a malformed parameter.

119 Malformed Version MALFORMED_VER The HTTP request Alert Protocol Exploit SION was sent with a protocol version number other than 0.9, 1.0 or 1.1

127 Multiple Content MULTIPLE_CONTE The HTTP request Alert Protocol Exploit Length NT_LENGTH contains more than one Content-Length HTTP request header.

25 Post Without POST_WITHOUT_ The POST request Alert Protocol Exploit Content Length CONTENT_LENGT is without the H mandatory Content-Length HTTP request header.

60 Pre-1.0 Request PRE_1_0_REQUE A HTTP request Alert Protocol Exploit ST sent without a protocol version number, thus implying that it was a HTTP/0.9 request.

Request Policy Violations: Click here to expand...

Request Policy Violations

Attack ID Attack Action Attack Name in Description Severity Attack Type Name Web Firewall Logs

141 Cookie Count COOKIE_COUNT_ The request Alert Buffer Overflow Exceeded EXCEEDED exceeded the maximum number of cookies specified in Max Number of Cookies on the SE CURITY POLICIES > Request Limits p age.

297 32 Cookie Expired COOKIE_EXPIRED The time set for a Warning Cookie Poisoning session cookie in C ookie Max Age on the SECURITY POLICIES > Cookie Security pa ge has expired on the client browser.

41 Cookie Length COOKIE_LENGTH The cookie value in Alert Buffer Overflow Exceeded _EXCEEDED the request exceeded the maximum allowable length specified in Max Cookie Value Length on the SEC URITY POLICIES > Request Limits pa ge.

142 Cookie Name COOKIE_NAME_L The length of the Alert Buffer Overflow Length Exceeded ENGTH_EXCEEDE cookie name D exceeded the maximum allowable length specified in Max Cookie Name Length on the SEC URITY POLICIES > Request Limits pa ge.

31 Cookie Tampered COOKIE_TAMPER A cookie that is Warning Cookie Poisoning ED secured by the Barracuda Web Application Firewall via cookie signing or encryption was found to be tampered in the request. The cookie was validated in the request as Tamper Proof Mode on the SECURITY POLICIES > Cookie Security pa ge is set to Encrypt ed or Signed.

44 Header Count HEADER_COUNT_ The number of Alert Buffer Overflow Exceeded EXCEEDED headers in a request exceeded the maximum allowable count specified in Max Number of Headers on the SE CURITY POLICIES > Request Limits p age.

298 143 Header Name HEADER_NAME_L The length of the Alert Buffer Overflow Length Exceeded ENGTH_EXCEEDE header name D exceeded the maximum allowable length specified in Max Header Name Length on the SEC URITY POLICIES > Request Limits pa ge.

6 Header Value HEADER_VALUE_ The header value Alert Buffer Overflow Length Exceeded LENGTH_EXCEED length in the ED request exceeded the maximum allowable length specified in Max Header Value Length on the SEC URITY POLICIES > Request Limits pa ge.

11 Invalid URL INVALID_URL_EN The characters that Alert Attack Obfuscation Encoding CODING are encoded in the URL do not conform to the URL encoding scheme specified in Default Character Set on the SECURITY POLICIES > URL Normalization pag e. Hence, the Barracuda Web Application Firewall failed to decode the encoded characters in the requested URL.

299 116 Mismatched COOKIE_REPLAY_ The header value Warning Cookie Poisoning Header Cookie MISMATCHED_HE embedded and Replay Attack ADER signed in the incoming cookie which was set to the client does not match the actual header value in one of the subsequent request sent by the client. This attack is detected when Coo kie Replay Protection Type is set to "Custom Headers" or "IP and Custom Headers" on the SECURITY POLICIES > Cookie Security pa ge.

117 Mismatched IP COOKIE_REPLAY_ The IP address Warning Cookie Poisoning Cookie Replay MISMATCHED_IP information included Attack in the cookie does not match the source IP address of the incoming request sent by the client. This attack is detected when Coo kie Replay Protection Type is set to “IP” or “IP and Custom Headers” on the SECURITY POLICIES > Cookie Security pa ge.

14 Slash-dot in URL SLASH_DOT_IN_U A slash was Alert Directory Traversal Path RL followed by a dot (.) in the requested URL. This indicates a potential hidden file disclosure attack. Hence, the Barracuda Web Application Firewall has blocked the request.

300 15 Tilde in URL Path TILDE_IN_URL A tilde was (~) Alert Directory Traversal detected in the requested URL. This indicates a potential hidden file disclosure attack. Hence, the Barracuda Web Application Firewall has blocked the request.

144 Too Many TOO_MANY_SESS The Barracuda Web Alert DoS Attack Sessions for IP IONS_FOR_IP Application Firewall has detected an attempt by the client to append new sessions than what is configured under WEBSITES > Advanced security > Session Tracking.

0 Request Length REQUEST_LENGT The total request Alert Buffer Overflow Exceeded H_EXCEEDED exceeded the maximum allowable length specified in Max Request Length on the SEC URITY POLICIES > Request Limits pa ge. This includes the Request Line and all HTTP request headers (for example, User Agent, Cookies, Referer, etc.).

140 Total Request Line REQUEST_LINE_L The request line Alert Buffer Overflow Length Exceeded ENGTH_EXCEEDE exceeded the D maximum allowable length specified in Max Request Line Length on the SEC URITY POLICIES > Request Limits pa ge.

301 30 Unrecognized UNRECOGNIZED_ The cookie in the Warning Cookie Poisoning Cookie COOKIE incoming request is identified as unrecognized cookie as Allow Unrecognized Cookies is set to N ever or Custom on the SECURITY POLICIES > Cookie Security pa ge. Unrecognized cookies are the cookies that are not encrypted by the Barracuda Web Application Firewall.

42 URL Length URL_LENGTH_EX The URL in the Alert Buffer Overflow Exceeded CEEDED request exceeded the maximum allowable URL length specified in Max URL Length o n the SECURITY POLICIES > Request Limits pa ge.

43 Query Length QUERY_LENGTH_ The length of the Alert Buffer Overflow Exceeded EXCEEDED query string portion of the URL exceeded the maximum allowable length specified in Max Query Length on the SECURITY POLICIES > Request Limits pa ge.

Response Violations: Click here to expand...

Response Violations

Attack ID Attack Action Attack Name in Description Severity Attack Type Name Web Firewall Logs

302 300 CAPTCHA DDOS_CAPTCHA_ The response page Information DDoS Attack Validation SEND_CAPTCHA specified in the Res Required ponse Page field of the identified attack on the SECURITY POLICIES > Action Policy page is sent to the client as the Barracuda Web Application Firewall was unable to reach the back-end server.

62 Custom Error CUSTOM_ERR_RE The custom error Alert Others Response Page SPONSE_PAGE response page specified in the Res ponse Page field of the identified attack on the SECURITY POLICIES > Action Policy page is sent to the client as the Barracuda Web Application Firewall was unable to reach the back-end server.

17 Error Response ERROR_RESPON The response Notice Error Message Suppressed SE_SUPPRESSED received from the Interception back-end server contained 4xx or 5xx response code. Hence, the Barracuda Web Application Firewall blocked the response as “error_response_su ppressed “ as the S uppress Return Code is set to Yes on the SECURITY POLICIES > Cloaking page.

63 Identity Theft IDENTITY_THEFT_ The body (contents) Error Authentication Pattern Matched PATTERN_MATCH of the response Hijacking ED received from the back-end server matches the identity theft pattern defined on the ADVANCED > Libraries page.

303 61 Response Header RESPONSE_HEAD The response Information Error Message Suppressed ER_SUPPRESSED header is Interception suppressed as it matched a header specified in Header s to Filter on the S ECURITY POLICIES > Cloaking page.

Header Violations: Click here to expand...

Header Violations

Attack ID Attack Action Attack Name in Description Severity Attack Type Name Web Firewall Logs

37 Cross-Site CROSS_SITE_SCR The value in a Alert Cross-site Scripting Scripting in IPTING_IN_HEADE header matched a Header R Cross-Site Scripting pattern defined on ADVANCED > View Internal Patterns > Attack Types.

35 Custom Attack CUSTOM_ATTACK The value in a Alert Command Injection Pattern in Header _PATTERN_IN_HE header matched a ADER custom attack pattern defined on ADVANCED > Libraries > Attack Types.

39 Directory DIRECTORY_TRA The value in a Alert Directory Traversal Traversal in VERSAL_IN_HEAD header matched a Header ER Directory Traversal pattern defined on ADVANCED > View Internal Patterns > Attack Types.

7 Metacharacter HEADER_META_VI Metacharacter Alert Command Injection Matched in Header OLATION found in header matched the Denied Metacharacters defined on WEBSIT ES > Header: Allow/Deny Rules.

38 OS Command OS_CMD_INJECTI The value in a Alert Command Injection Injection in Header ON_IN_HEADER header matched an OS Command injection pattern defined on ADVAN CED > View Internal Patterns > Attack Types.

304 36 SQL Injection in SQL_INJECTION_I The value in a Alert SQL Injection Header N_HEADER header matched a SQL injection pattern defined on ADVANCED > View Internal Patterns > Attack Types.

Application Profile Violations: Click here to expand...

Application Profile Violations

Attack ID Attack Action Attack Name in Description Severity Attack Type Name Web Firewall Logs

130 No Domain Match NO_DOMAIN_MAT The domain Alert Forceful Browsing in Profile CH_IN_PROFILE attribute of session cookie does not match the attribute specified on the WE BSITES > Web Site Profiles page. This is enforced when St rict Profile Check and URL Profile is set to Yes.

131 No URL Profile NO_URL_PROFILE The request does Alert Forceful Browsing Match _MATCH not match any of the configured URL Profiles on the WEB SITES > Web Site Profiles page. This is enforced when St rict Profile Check and URL Profile is set to Yes.

URL Profile Violations: Click here to expand...

URL Profile Violations

Attack ID Attack Action Attack Name in Description Severity Attack Type Name Web Firewall Logs

305 40 Content Length CONTENT_LENGT The size of the Alert Buffer Overflow Exceeded H_EXCEEDED content in the request body exceeds the maximum allowable length defined in the URL Profile for the given URL space. Max Content Length specified on:

SECURITY POLICIES > URL Protection exc eeded, OR WEBSITES > Web Site Profiles > URL Profiles excee ded. This is only when Use Profile is set to Yes and URL Profile created.

167 Cross-Site CROSS_SITE_SCR The value in a URL Alert Cross-site Scripting Scripting in URL IPTING_IN_URL matched a Cross-Site Scripting pattern defined on ADVANCED > View Internal Patterns > Attack Types.

171 Custom Attack CUSTOM_ATTACK The value in a URL Alert Others Pattern in URL _PATTERN_IN_UR matched a custom L attack pattern defined on ADVAN CED > Libraries > Attack Types.

5 Forbidden Method METHOD_NOT_AL The HTTP method Alert Protocol Exploit LOWED in the request is denied as it is not configured in the All owed Method list on WEBSITES > Web Site Profiles > URL Profile.

163 No Param Profile NO_PARAM_PROF The request failed Alert Forceful Browsing Match ILE_MATCH to match the configured parameter profiles on WEBSITES > Web Site Profiles for this URL space.

306 168 OS Command OS_CMD_INJECTI The value in the Alert OS Command Injection in URL ON_IN_URL URL matched an Injection OS command injection pattern defined on ADVAN CED > View Internal Patterns > Attack Types.

147 Parameter Name PARAM_NAME_LE The length of the Alert Buffer Overflow Length Exceeded NGTH_EXCEEDED parameter in the request exceeds the maximum allowable length defined either on SECURIT Y POLICIES > URL Protection or WEB SITES > Web Site Profiles > URL Profiles (Only when Use Profile is set to Yes and URL Profile created).

132 Query String not QUERY_STR_NOT The request is Alert Forceful Browsing Allowed _ALLOWED blocked as a query string was detected in the URL and query strings have been disallowed on WEBSITES > Web Site Profile > URL Profiles.

170 Remote File REMOTE_FILE_IN The value in a URL Alert Malicious-File-Exec Inclusion in URL CLUSION_IN_URL matched a Remote ution File Inclusion pattern defined on ADVANCED > View Internal Patterns > Attack Types.

161 Session not Found SESSION_NOT_F The Barracuda Web Alert Forceful Browsing OUND Application Firewall maintains a session for every form and URL fetched by the client when CSRF is enabled. If the request does not have the valid session token embedded in it, the Barracuda Web Application Firewall logs it as session not found.

307 166 SQL Injection in SQL_INJECTION_I The value in a URL Alert SQL Injection URL N_URL matched a SQL injection pattern defined on the ADV ANCED > View Internal Patterns > Attack Types page.

149 Too Many TOO_MANY_PARA The parameters in a Alert Form Tampering Parameters MS GET query string and/or in the request body in a POST request exceeded the maximum number specified in MAX Parameters on the SECURITY POLICIES > URL Protection page.

148 Too Many TOO_MANY_UPLO The request Alert Form Tampering Uploaded Files ADED_FILES exceeds the maximum number of form parameters that can be of file-upload type. Max Upload Files specified on:

SECURITY POLICIES > URL Protection exc eeded, OR WEBSITES > Web Site Profiles > URL Profiles excee ded. This is only when Use Profile is set to Yes and URL Profile created.

26 Unknown Content UNKNOWN_CONT The content type in Alert Attack Obfuscation Type ENT_TYPE the POST body of the URL does not match any of the content types specified in Allowe d Content Types o n WEBSITES > Web Site Profiles > URL Profile.

Parameter Profile Violations: Click here to expand...

Parameter Profile Violations

308 Attack ID Attack Action Attack Name in Description Severity Attack Type Name Web Firewall Logs

165 Cross-Site CROSS_SITE_RE The state parameter Alert Forceful Browsing Request Forgery QUEST_FORGERY ' ncforminfo' inserted by the Barracuda Web Application Firewall was not found or was found tampered in the form that matched the URL profile.

158 Cross-Site CROSS_SITE_SCR The parameter Alert Cross-site Scripting Scripting in IPTING_IN_PARAM contained a Parameter cross-site scripting pattern that matched an attack pattern in the Para meter Class associ ated with the parameter profile on the WEBSITES > Website Profiles p age, or in the SECU RITY POLICIES > Parameter Protection page (if the parameter did not have a parameter profile).

155 Custom Attack CUSTOM_ATTACK The parameter Alert Command Injection Pattern in _PATTERN_IN_PA contained a custom Parameter RAM attack pattern that matched an attack pattern in the Para meter Class associ ated with the parameter profile on the WEBSITES > Website Profiles p age or in the SECU RITY POLICIES > Parameter Protection page (if the parameter did not have a parameter profile).

309 160 Directory DIRECTORY_TRA The parameter Alert Directory Traversal Traversal in VERSAL_IN_PARA contained a Parameter M directory traversal pattern that matched an attack pattern in the Para meter Class associ ated with the parameter profile on the WEBSITES > Website Profiles p age or in the SECU RITY POLICIES > Parameter Protection page (if the parameter did not have a parameter profile).

151 File Upload Size FILE_UPLOAD_SIZ The uploaded file in Alert Form Tampering Exceeded E_EXCEEDED the request exceeds the specified value in Maximum Upload File Size o n the SECURITY POLICIES > Parameter Protection page.

150 Forbidden File FILE_EXTENSION The extension of Alert Form Tampering Extension _NOT_ALLOWED the uploaded file does not match any of the extensions configured in File Upload Extensions on the:

SECURITY POLICIES > Parameter Protection pag e, or WEBSITES > Website Profiles > Parameter Profile section

310 296 Forbidden File FILE_MIME_TYPE The extension of Alert Form Tampering Mime Type _NOT_ALLOWED the uploaded file does not match any of the extensions configured in File Upload Mime Types on the:

SECURITY POLICIES > Parameter Protection pag e, or WEBSITES > Website Profiles > Parameter Profile section

138 Mandatory MISSING_MANDAT The URL in the Alert Form Tampering Parameter Missing ORY_PARAM request does not contain a parameter which is required to be present. The Parameter profile associated with the URL profile has Req uired set to Yes on the WEBSITES > Website Profiles > Parameter Profiles section.

137 Maximum TOO_MANY_PARA The instance of a Alert Form Tampering Instances of M_INSTANCES parameter exceeds Parameter the specified Exceeded threshold in Maximum Instances on the:

SECURITY POLICIES > Parameter Protection pag e, or WEBSITES > Website Profiles > Parameter Profile section.

311 152 Metacharacter in METACHARACTER The parameter Alert Command Injection Parameter _IN_PARAMETER contained a metacharacter that matched an attack pattern in the Para meter Class associ ated with the Parameter profile on the WEBSITES > Website Profiles page, or in the SEC URITY POLICIES > Parameter Protection page (if the parameter did not have a parameter profile).

159 OS Command OS_CMD_INJECTI The parameter Alert OS Command Injection in ON_IN_PARAM contained a OS Injection Parameter command injection pattern that matched an attack pattern in the Para meter Class associ ated with the Parameter profile on the WEBSITES > Website Profiles page, or in the SEC URITY POLICIES > Parameter Protection page (if the parameter did not have a parameter profile).

156 Parameter Input PARAM_INPUT_VA The parameter did Alert Form Tampering Validation Failed LIDATION_FAILED not match the input type validation configured in the W EBSITES > Website Profiles > Parameter Profiles section.

312 154 Parameter Length PARAM_LENGTH_ The parameter Alert Form Tampering Exceeded EXCEEDED value in the request exceeded the maximum allowable length specified in Maximum Parameter Value Length on the:

SECURITY POLICIES > Parameter Protection pag e, or WEBSITES > Website Profiles > Parameter Profile section.

139 Parameter Value PARAM_VAL_NOT The Global Choice Alert Form Tampering not Allowed _ALLOWED parameter had a value that differed from the values configured for this parameter in the Parameter Profile on the WEBSITES > Website Profiles page.

134 Read-Only or READ_ONLY_PAR The read-only Alert Form Tampering Hidden Parameter AM_TAMPERED parameter had a Tampered value that differed from the value learned by the Barracuda Web Application Firewall based on the form sent to the browser.

164 Remote File REMOTE_FILE_IN The parameter Alert Malicious-File-Exec Inclusion CLUSION contained a remote ution file inclusion pattern that matched an attack pattern in the Parameter Class a ssociated with the Parameter profile on the WEBSITES > Website Profiles page, or in the SEC URITY POLICIES > Parameter Protection page (if the parameter did not have a parameter profile).

313 136 Session Choice SESSION_CHOICE The session choice Alert Form Tampering Parameter _PARAM_TAMPER parameter had a Tampered ED value that differed from the value learned by the Barracuda Web Application Firewall based on the form sent to the browser for this session.

162 Session Context SESSION_CONTE The session Alert Form Tampering not Found XT_NOT_FOUND parameter (parameter type=read-only, session-choice or session-invariant) value does not match the learned value in the parameter profile, indicating possible tampering with the session parameter value.

135 Session Invariant SESSION_INVARI The Alert Form Tampering Parameter ANT_PARAM_TAM session-invariant Tampered PERED parameter had a value that differed from the value learned by Barracuda Web Application Firewall based on the form sent to the browser for this session.

157 SQL Injection in SQL_INJECTION_I The parameter Alert SQL Injection Parameter N_PARAM contained an SQL injection pattern that matched an attack pattern in the Para meter Class associ ated with the Parameter profile on the WEBSITES > Website Profiles page.

Advanced Policy Violations: Click here to expand...

Advanced Policy Violations

Attack ID Attack Action Attack Name in Description Severity Attack Type Name Web Firewall Logs

314 146 Brute force from BRUTE_FORCE_F The requests from Alert DoS Attack All Sources ROM_ALL_SOURC all sources are ES blocked when the value specified in Max Allowed Accesses From All Sources is exceeded within the specified Count Window on the WE BSITES > Advanced Security > Edit Bruteforce Prevention section.

145 Brute force from BRUTE_FORCE_F The requests from a Alert DoS Attack IP ROM_IP particular IP address are blocked when the value specified in Max Allowed Accesses Per IP is exceeded within the specified Count Window on the WEBSITES > Advanced Security > Edit Bruteforce Prevention section.

299 Unanswered DDOS_CAPTCHA_ The number of Alert DDoS Attack CAPTCHA Limit MAX_UNANSWER attempts made by Exceeded ED_EXCEEDED the client in fetching the CAPTCHA image without answering exceeded the value specified in Max Unanswered CAPTCHA on the WEBSITES > DDoS Prevention p age.

297 CAPTCHA Attempt DDOS_CAPTCHA_ The number of Alert DDoS Attack Limit Exceeded TRIES_EXCEEDED attempts made by the client in solving a CAPTCHA challenge exceeded the value specified in Max CAPTCHA Attempts on the W EBSITES > DDoS Prevention page.

315 12 Invalid URL INVALID_URL_CH The request Warning Attack Obfuscation Character Set ARSET contained a character that is not valid in the character set. To determine the character set of the request, the Barracuda Web Application Firewall relies on several configuration elements like Default Character Set, Detect Response Charset and Response Charset.

75 Rate Control RATE_CONTROL_I The rate of requests Alert Intrusion NTRUSION exceeds the value specified in Maximu m Active Requests and Maximum Per Client Backlog of the rate control pool associated with the Service is exceeded.

293 Secure Browsing SECURE_BROWSI The Barracuda Web Alert Secure Browsing NG Application Firewall was unable to validate the session key in the request that matched the URL specified in the Secure Browsing policies.

295 Slowloris Attack SLOWLORIS_ATT The request is Alert DDoS Attack ACK detected as slowloris attack when it exceeds the value specified in M ax Request Timeout and Incre mental Request Timeout for the Service in the WEB SITES > DDoS Prevention > Slow Client Prevention s ection.

316 302 Slowloris SLOWLORIS_RES The response is Alert DDoS Attack Response Attack PONSE_ATTACK detected as slowloris response attack when it exceeds the value specified in Max Response Timeout and Incremental Response Timeout for the Service in the WEBSITES > DDoS Prevention > Slow Client Prevention section.

301 URL Encryption URL_ENCRYPTIO The request Alert Forceful Browsing N violated the URL encryption policy configured in the W EBSITES > URL Encryption page.

204 Virus Found VIRUS_IN_POST_ Virus detected in Alert Virus Scan REQUEST the uploaded file. All files uploaded through multipart/form-data messages are scanned for the presence of viruses. Requests containing virus signatures are denied. WEBSITES > Advanced Security > Advanced Security section.

XML Firewall DoS Violations: Click here to expand...

XML Firewall DoS Violations

Attack ID Attack Action Attack Name in Description Severity Attack Type Name Web Firewall Logs

317 185 DTD Found XDOS_DTD An XML service Alert XML Firewall rejected a SOAP message that contained Document Type Definition (DTD). A SOAP message containing DTD reference is NOT allowed by the SOAP standard. A SOAP message is checked for DTD as Block DTDs is set to Yes on the ADV ANCED > XML Protection > XML Validation Settings section.

187 External URI Ref XDOS_EXT_ENTIT The requests Alert XML Firewall Found Y contain external entities including external URI references or external DTDs. A SOAP message is checked for external URI references or external DTDs as Bl ock External Entities is set to Ye s on the ADVANCE D > XML Protection > XML Validation Settings section.

188 Malformed XML XDOS_MALFORM An XML parser Alert XML Firewall ED detected a malformed XML document. An XML document that contains illegal character, mismatched element tags (having a starting tag, but missing the ending tag) or trailing content after the document element is identified as malformed XML document.

318 178 Max Attribute XDOS_MAX_ATTRI The XML document Alert XML Firewall Name Length BUTE_NAME_LEN exceeds the Exceeded GTH maximum attribute name length limit specified in the AD VANCED > XML Protection > XML Validation Settings section.

179 Max Attribute XDOS_MAX_ATTRI The XML document Alert XML Firewall Value Length BUTE_VALUE_LEN exceeds the Exceeded GTH maximum attribute value length limit specified in the AD VANCED > XML Protection > XML Validation Settings section.

182 Max Document XDOS_MAX_FILE_ The XML document Alert XML Firewall Size Exceeded SIZE exceeds the maximum document size limit specified in the ADVANCED > XML Protection > XML Validation Settings section.

177 Max Element XDOS_MAX_ATTRI The XML document Alert XML Firewall Attributes BUTES exceeds the Exceeded maximum allowable attributes of an element specified in the ADVANCED > XML Protection > XML Validation Settings section.

184 Max Element XDOS_MAX_ELEM The XML document Alert XML Firewall Children Exceeded ENT_CHILDREN exceeds the maximum allowable children per node in a tree specified in the ADVANCED > XML Protection > XML Validation Settings section.

175 Max Element XDOS_MAX_ELEM The XML document Alert XML Firewall Name Length ENT_NAME_LENG exceeds the Exceeded TH maximum allowable length for the name of an element specified in the AD VANCED > XML Protection > XML Validation Settings section.

319 176 Max Elements in XDOS_MAX_ELEM The XML document Alert XML Firewall Tree Exceeded ENTS exceeds the maximum allowable number of nodes/elements in a tree specified in the ADVANCED > XML Protection > XML Validation Settings section.

181 Max Text Size XDOS_CDATA_LE The XML document Alert XML Firewall Exceeded NGTH exceeds the maximum allowable size of the XML document.

174 Max Tree Depth XDOS_MAX_ELEM The XML document Alert XML Firewall Exceeded ENT_DEPTH has exceeded the maximum allowable nesting depths of nodes specified in the ADVANCED > XML Protection > XML Validation Settings section.

183 Min Document XDOS_MIN_FILE_ The XML document Alert XML Firewall Size Limit SIZE exceeds the minimum allowable size of the XML document specified in the ADVANCED > XML Protection > XML Validation Settings section.

186 Processing XDOS_PI The request is Alert XML Firewall Instructions containing Found Processing Instructions (PIs). A PI is a text data section that is ignored by the XML parser and is passed on as instructions to applications. A SOAP message is checked for PIs as Block Processing Instructions is set to Yes on the ADVAN CED > XML Protection > XML Validation Settings section.

XML Firewall WSI Assertions: Click here to expand...

XML Firewall WSI Assertions

320 Attack ID Attack Action Attack Name in Description Severity Attack Type Name Web Firewall Logs

211 DOCTYPE Element XML_WSI1007 The SOAP Alert XML Firewall message contains DOCTYPE element in the request. This attack is detected as WSI1007: No DOCTYPE element is set to Yes on the ADVANCED > XML Protection > WS-I Basic Profile Assertions section.

228 WSI conformance XML_WSI1111 The “soap Alert XML Firewall claims are not mustUnderstand” mustunderstand attribute is used in the SOAP header block containing a conformance claim. This attack is detected as WSI111 1: WS-I conformance claims are not mustUnderstand is set to Yes on the A DVANCED > XML Protection > WS-I Basic Profile Assertions section.

227 WSI conformance XML_WSI1110 The request Alert XML Firewall is not well formed message is not a well formed XML. This attack is detected as WSI111 0: WS-I conformance claims are well-formed is set to Yes on the ADVA NCED > XML Protection > WS-I Basic Profile Assertions section.

321 226 WSI conformance XML_WSI1109 Conformance Alert XML Firewall not in soap hdr claims are not carried as SOAP header blocks in the message. This attack is detected as WSI1109: WS-I conformance claims are in soap: header is set to Yes on the ADVANCED > XML Protection > WS-I Basic Profile Assertions section.

219 Atts in soap env XML_WSI1032 Message contains Alert XML Firewall hdr body attributes in the envelope, header and body portion of the data. This attack is detected as WSI1 032: No attributes in SOAP envelope header and body elements is set to Y es on the ADVANC ED > XML Protection > WS-I Basic Profile Assertions section.

240 EncodingStyle in XML_WSI1307 Message contains " Alert XML Firewall Envelope ns soap:encodingStyle Elements " attributes on any elements whose namespace is http:// schemas.xmlsoap.o rg/soap/envelope/. This attack is detected as WSI130 7: No encodingStyle in env namespaced elements is set to Y es on the ADVANC ED > XML Protection > WS-I Basic Profile Assertions section.

322 244 EncodingStyle in XML_WSI1318 The message in an Alert XML Firewall rpc literal grand rpc-literal binding children contains "soap:enco dingStyle" attribute on any element that is a grandchild of “s oap:body”. This attack is detected as WSI1318: No encodingStyle in grandchildren of rpc literal is set to Yes on the ADVAN CED > XML Protection > WS-I Basic Profile Assertions section.

220 Env ns is 1998 XML_WSI1033 The message with Alert XML Firewall an envelope contains the namespace declaration xmlns:x ml=http://www.w3.o rg/XML/1998/name space. This attack is detected as WSI1 033: Envelope namespace is not 1998 is set to Yes o n the ADVANCED > XML Protection > WS-I Basic Profile Assertions section.

245 Envelope and XML_WSI1601 The message with " Alert XML Firewall Body are not soap:envelope" or " XML1.0 soap:body" does not conform to XML 1.0. This attack is detected as WSI160 1: soap:envelope a nd soap:body are good XML 1.0 is set to Yes on the A DVANCED > XML Protection > WS-I Basic Profile Assertions section.

323 246 Envelope does not XML_WSI1701 The message Alert XML Firewall Confirm to whose "soap:envelo Schema pe" does not conform the SOAP schema. This attack is detected as WSI1 701: soap:envelop e conforms to SOAP schema is set to Yes on the A DVANCED > XML Protection > WS-I Basic Profile Assertions section.

242 Envelope have XML_WSI1309 The message Alert XML Firewall children after body contains element children of soap:Envelope following the soap:Body element. This attack is detected as WSI1 309: Envelope does not have children after body is set to Yes on the ADVANCED > XML Protection > WS-I Basic Profile Assertions section.

225 Fault resp is not XML_WSI1107 A fault detected in Alert XML Firewall defined in wsdl the message which binding is not defined in ws dl:binding. A wsdl:bi nding should contain a "soapbind :fault" describing each known fault. This attack is detected as WSI110 7: Fault response is defined in wsdl: binding is set to Ye s on the ADVANCE D > XML Protection > WS-I Basic Profile Assertions section.

324 218 Faults use dot XML_WSI1031 The message Alert XML Firewall notation contains a faultcode element with dot (.) notation. This attack is detected as WSI1 031: Faults do not use dot notation is set to Yes on the A DVANCED > XML Protection > WS-I Basic Profile Assertions section.

221 Good resp is not XML_WSI1100 The SOAP Alert XML Firewall 200ok message does not contain soap:Fault and does not use 200 OK HTTP Status code for responses. This attack is detected as WSI1100: Good response uses 200 OK status is set to Yes on the ADVAN CED > XML Protection > WS-I Basic Profile Assertions section.

206 Message is not XML_WSI1002 The message not Alert XML Firewall HTTP1.0 or sent using HTTP HTTP1.1 version 1.0 or 1.1. This attack is detected as WSI100 2: Message sent using HTTP 1.1 or HTTP 1.0 is set to Y es on the ADVANC ED > XML Protection > WS-I Basic Profile Assertions section.

205 Message is not XML_WSI1001 The message not Alert XML Firewall HTTP1.1 sent using HTTP version 1.1. This attack is detected as WSI1001: Message should be sent using HTTP 1.1 is set to Y es on the ADVANC ED > XML Protection > WS-I Basic Profile Assertions section.

325 207 Message is not XML_WSI1003 The XML schema in Alert XML Firewall UTF8 or UTF16 the request is not using UTF-8 or UTF16 encoding. This attack is detected as WSI100 3: Message is UTF-8 or UTF-16 is set to Yes on the A DVANCED > XML Protection > WS-I Basic Profile Assertions section.

230 Msg body is not XML_WSI1201 The message Alert XML Firewall soap env with ns contains a soap:Envelope with a document element “Envelope”, but the namespace name is not http://sc hemas.xmlsoap.org /soap/envelope/. This attack is detected as WSI120 1:Message body is a soap:envelope w ith namespace is set to Yes on the A DVANCED > XML Protection > WS-I Basic Profile Assertions section.

213 Message does not XML_WSI1009 The message does Alert XML Firewall include allhdrs not contain all the "s oapbind:headers" specified in the WSDL file. This attack is detected as WSI1009:Messa ge includes all specified headers i s set to Yes on the ADVANCED > XML Protection > WS-I Basic Profile Assertions section.

326 212 Message part XML_WSI1008 The name space is Alert XML Firewall accessors have no not defined in the ns incoming soap message. This attack is detected as WSI1008:Messa ge part accessors have proper namespaces is set to Yes on the ADVA NCED > XML Prote ction > WS-I Basic Profile Assertions section.

236 Mustunderstand is XML_WSI1301 The message with a Alert XML Firewall neither 1 nor 0 "soap:mustUnderst and" value is neither 1 nor 0. The value should be either 1 or 0. This attack is detected as WSI130 1:mustUnderstand is 1 or 0 is set to Ye s on the ADVANCE D > XML Protectio n > WS-I Basic Profile Assertions section.

216 No fault for bad XML_WSI1012 A soap:Fault is not Alert XML Firewall env ns generated for a document element named "Envelope" where the namespace name is not "http://schemas. xmlsoap.org/soap/e nvelope/". This attack is detected as WSI1012:soap:f ault generated for bad envelope namespace is set to Yes on the ADVA NCED > XML Prote ction > WS-I Basic Profile Assertions section.

327 223 Non POST req XML_WSI1103 A SOAP message Alert XML Firewall does not get 405 sent as a part of non-POST method request that receives a HTTP response with status code other than 405. This attack is detected as WSI1103:Non POST request gets 405 response is set to Yes on the ADVA NCED > XML Prote ction > WS-I Basic Profile Assertions section.

224 Non XML req does XML_WSI1104 A SOAP message Alert XML Firewall not get 415 sent as a part of non-XML request that receives a HTTP response with status code other than 415. This attack is detected as WSI1104:Non XML request gets 415 response is set to Yes on the ADVA NCED > XML Prote ction > WS-I Basic Profile Assertions section.

214 Oneway resp non XML_WSI1010 An HTTP one-way Alert XML Firewall empty body response contains a SOAP envelope (that is, HTTP entity-body is not empty). This attack is detected as WSI1 010:One way responses have an empty body is set to Yes on the ADVA NCED > XML Prote ction > WS-I Basic Profile Assertions section.

328 235 Part accessors XML_WSI1211 The message with Alert XML Firewall has xsi nil rpc-literal binding contains xsi:nil attrib ute with the a value of “1” or ‘true’ on the part accessors. This attack is detected as WSI1211:Part accessors do not have xsi:nil valued 1 or true is set to Y es on the ADVANC ED > XML Protecti on > WS-I Basic Profile Assertions section.

222 Processed resp XML_WSI1101 The response Alert XML Firewall status is neither message without 200 nor 202 the embedded SOAP message. This attack is detected as WSI110 1:Processed response uses either 200 or 202 status is set to Yes on the ADVANCED > XML Protection > WS-I Basic Profile Assertions section.

215 Request matches XML_WSI1011 The request does Alert XML Firewall wsdl not conform to the WSDL file definition. This attack is detected as WSI101 1:Request content matches WSDL is set to Yes on the A DVANCED > XML Protection > WS-I Basic Profile Assertions section.

208 Request is not XML_WSI1004 The message was Alert XML Firewall HTTP POST not sent using the HTTP POST method. This attack is detected as WSI1 004:Request is an HTTP POST is set to Yes on the ADVA NCED > XML Prote ction > WS-I Basic Profile Assertions section.

329 209 Response has no XML_WSI1005 Wrapper element in Alert XML Firewall wrapper named op the response message does not have a value equal to the name attribute on the wsdl :operation element suffixed with string "Response". A response with a wrapper that is not named after the ws dl:operation name. This attack is detected as WSI100 5:Response has wrapper named after the operation is set to Yes on the ADVANCED > XML Protection > WS-I Basic Profile Assertions section.

217 Response XML_WSI1013 The response does Alert XML Firewall matches wsdl not conform to the WSDL file definition. This attack is detected as WSI101 3:Response content matches WSDL is set to Yes on the ADVANCED > XML Protection > WS-I Basic Profile Assertions section.

231 Soap body XML_WSI1202 The message with a Alert XML Firewall children are not ns child element of the qualified soap:Body element is not namespace qualified. This attack is detected as WSI1202:soap: body children are namespace qualified is set to Y es on the ADVANC ED > XML Protecti on > WS-I Basic Profile Assertions section.

330 241 Soap XML_WSI1308 The message with a Alert XML Firewall encodingStyle in child element of the bodychildren soap:Body element has a soap:encodin gStyle attribute. This attack is detected as WSI130 8:No soap:encodin gStyle on body children is set to Y es on the ADVANC ED > XML Protecti on > WS-I Basic Profile Assertions section.

243 Soap fault children XML_WSI1316 The message Alert XML Firewall are qualified contains a soap:Fault element with a qualified child element. This attack is detected as WSI1 316:soap:fault chil dren are unqualified is set to Yes on the ADVA NCED > XML Prote ction > WS-I Basic Profile Assertions section.

239 Soap faultdoes not XML_WSI1306 The SOAP Alert XML Firewall have allowed message has one children or more soap:Fault children elements that are not standard i.e. the child element(s) is neither soap:faultco de, soap:faultstring, soap:faultactor nor soap:detail. This attack is detected as WSI1306:soap:f ault has only allowed children is set to Yes on the A DVANCED > XML Protection > WS-I Basic Profile Assertions section.

331 232 Soap fault has XML_WSI1203 The soap:Fault Alert XML Firewall envelope ns message contains detail element with qualified attributes but non-foreign namespace. Non-foreign namespace means the namespace should be anything other than “http://sc hemas.xmlsoap.org /soap/envelope/". This attack is detected as WSI101 2:soap:fault gener ated for bad envelope namespace is set to Yes on the ADVA NCED > XML Prote ction > WS-I Basic Profile Assertions section.

238 Soap fault is not in XML_WSI1305 The SOAP fault Alert XML Firewall HTTP500 resp response message does not have "500 Internal Server Error" HTTP status code. This attack is detected as WSI130 5:soap:fault contai ned in HTTP 500 message is set to Y es on the ADVANC ED > XML Protecti on > WS-I Basic Profile Assertions section.

237 Soap faultcode is XML_WSI1302 The message Alert XML Firewall not std contains a faultcode element which is neither the a fault code defined in SOAP 1.1 nor a namespace qualified fault code. This attack is detected as WSI130 2:soap:faultcode i s standard or namespace qualified is set to Y es on the ADVANC ED > XML Protecti on > WS-I Basic Profile Assertions section.

332 229 Soapaction hdr XML_WSI1116 The SOAP Alert XML Firewall does not match op message whose soapaction SOAPAction HTTP header field does not match the WSDL soapAction attribute in soapbind :operation (either the same value or a blank quoted string if not present). This attack is detected as WSI1116:SOAP Action header matches op soapAction is set to Yes on the ADVA NCED > XML Prote ction > WS-I Basic Profile Assertions section.

210 Soapaction hdr is XML_WSI1006 The value of the Alert XML Firewall not quoted "SOAPAction" HTTP header field in a HTTP request is not a quoted string. This attack is detected as WSI100 6:SOAP Action header contains a quoted string is set to Yes on the ADVA NCED > XML Prote ction > WS-I Basic Profile Assertions section.

233 Soapenc arraytype XML_WSI1204 The message soap: Alert XML Firewall attr body contains the s oapenc:arrayType a ttribute. This attack is detected as WSI1 204:No soapenc:ar rayType attribute i s set to Yes on the ADVANCED > XML Protection > WS-I Basic Profile Assertions section.

333 234 XML processing XML_WSI1208 The SOAP Alert XML Firewall instructions in message contains body Processing instructions. This attack is detected as WSI1208:No XML processing instructions in body is set to Yes o n the ADVANCED > XML Protection > WS-I Basic Profile Assertions section.

XML Firewall SOAP Violations: Click here to expand...

XML Firewall SOAP Violations

Attack ID Attack Action Attack Name in Description Severity Attack Type Name Web Firewall Logs

193 Additional soap XML_VALIDATION The SOAP Alert XML Firewall headers rcvd _WSDL_SOAP_UN message contained KNOWN_HEADER additional headers S that are not specified in the WSDL file. This attack is detected as Allow Additional SOAP Headers is set to Y es on the ADVANC ED > XML Protection page

192 Invalid soap body XML_VALIDATION The SOAP Alert XML Firewall _WSDL_SOAP_HE message body does ADERS not conform to the schema defined in the WSDL file. This attack is detected as Validate SOAP body from WSDL schema is set to Ye s on the ADVANCE D > XML Protection page.

190 Invalid soap XML_VALIDATION The SOAP Alert XML Firewall envelope _WSDL_SOAP_EN message with soap: VELOPE envelope does not conform to the SOAP standard. This attack is detected as Validat e SOAP Envelope i s set to Yes on the ADVANCED > XML Protection page.

334 191 Invalid soap XML_VALIDATION The SOAP Alert XML Firewall header _WSDL_SOAP_BO message contained DY a header that does not conform to the policies defined in the WSDL file. This attack is detected as Validate SOAP headers defined in WSDL is set to Yes on the ADVANCED > XML Protection p age.

How to Use IPV6 en This feature is available only with Barracuda Web Application Firewall version 7.6 and above.

Internet Protocol Version 6 (IPv6)

IP version 6 (IPv6) is a new version of the Internet Protocol, the successor of IP version 4 (IPv4). The main advantage of IPv6 is a larger address space than IPv4.

IPv6 uses 128-bit IP addresses compared to 32-bit IP addresses used by IPv4. Version 6 supports varied addressing types (unicast, anycast, multicast, link-local, sitelocal and global). IPv6 addresses can be associated with one or more interfaces.

Address Notation

IPv6 addresses are represented as eight 16-bit hexadecimal block separated by colons (:).

Example: FEDC:0000:0000:0000:FEDC:E4BF:0100:0010

The leading zeros can be omitted within each 16-bit hexadecimal block, and written as 0 instead of 0000, 100 instead of 0100 and 10 instead of 0010. These zeros can be further compressed and replaced with double-colon (::) to make IPv6 address notation less cumbersome. Double-colon can be used only once to compress an IPv6 address, either in the beginning, middle or end.

Example: FEDC::FEDC:E4BF:100:10 is equivalent to FEDC:0000:0000:0000:FEDC:E4BF:100:10

IPv6 Support in Barracuda Web Application Firewall

The Barracuda Web Application Firewall supports Internet Protocol Version 6 (IPv6) along with its predecessor IPv4. The current firmware release (7.6) provides only basic IPv6 features. Before configuring IPv6 Services, read the following:

Enabling IPv6 Configuring the Barracuda Web Application Firewall with IPv6 Addresses

Enabling IPv6

By default, IPv6 is disabled on the Barracuda Web Application Firewall. To enable IPv6, go to the BASIC > IP Configuration > Addresses sectio n and set Enable IPv6 to Yes.

If the units are in cluster, IPv6 configuration does not synchronize if one of the units is IPv6 enabled and the other is disabled. To synchronize IPv6 configuration, set Enable IPv6 to Yes on both the units.

Configuring the Barracuda Web Application Firewall with IPv6 Addresses

335 Before configuring IPv6 services, you need to assign IPv6 addresses to the interfaces on the BASIC > IP Configuration page. Only then can you connect to an IPv6 network. By default, the Barracuda Web Application Firewall accepts traffic only from IPv4 networks, and drops all IPv6 traffic. When IPv6 is enabled, the Barracuda Web Application Firewall accepts both IPv4 and IPv6 traffic. The IPv6 address for interfaces can be configured in the WAN IPv6 Configuration, LAN IPv6 Configuration and Management IPv6 Configuration sections. For detailed configuration instructions, click Help on that page.

Configuring IPv6 Services

You can create new services (IPv4 and IPv6) using BASIC > Services > Add New Service, and then selecting the appropriate version from the Version drop-down list. Specify a name, type of service desired, a Virtual IP (VIP) address, port, and one or more Real Servers. You should configure a global IPv6 address for your Virtual IP address.

The following table lists the various interfaces to Services that can be used when IPv6 is enabled:

Front-end Back-end Use Case

IPv6 IPv6 Used when the complete network setup is being migrated to support IPv6 based addressing.

IPv6 IPv4 Used when you wish to publish IPv6 addresses for web applications without changing the addressing in your internal network.

IPv4 IPv6 Used when third party applications connecting to your applications are not yet ready to communicate via IPv6.

IPv4 IPv4 Used in current deployments without any IPv6 support.

Limitations of IPv6 in the Barracuda Web Application Firewall

The Barracuda Web Application Firewall IPv6 implementation has the following limitations:

Currently, IPv6 based addressing is not supported for the following features: Adaptive Profiling Trusted Hosts Connection to Barracuda Networks Technical Support Center via the support tunnel does not accept IPv6 addresses. If you want to establish connection to the support tunnel, make sure you have IPv4 address configured in the WAN IP Configuration and LAN IP Configuration sections on the BASIC > IP Configuration page. IPv6 addresses cannot be configured via Console configuration. Evaluation Policy and Flow en In this article:

en Evaluation Policies Request Policy Order Response Policy Order Execution Flow HTTP Request HTTP Response Local Allow/Deny Rules URL Policies Rule Matching Rule Match Algorithm Hierarchical Match Sequential Match

336 Evaluation Policies

The Barracuda Web Application Firewall applies policies to evaluate requests and responses.

Request Policy Order

Web application requests have policies applied in the following order:

1. Network ACLs [P1] 2. Barracuda IP Reputation [P2] 3. Geo Location ACLs [P3] 4. SSL Termination and SSL Checks [P4] 5. Protocol Checks and Global Request Limits [P5] 6. URL Encryption Rule [P6] 7. Instant SSL redirect policy [P7] 8. URL normalization [P8] 9. Rule match [P9] 10. Cookie security [P10] 11. Global Allow Deny Rules [P11] 12. Session Tracking [P12] 13. Local Allow Deny Rules [P13] 14. Process Profile or Default URL protection and Parameter protection [P14] 15. Advanced Security [P15] 16. Authentication and Access Control [P16] 17. Caching [P17] 18. Web address translation (WAT) [P18] 19. XML Firewall [P19] 20. Load Balancing [P20]

The following flowchart explains the Request Policy Order:

337 338 339

340 341

Response Policy Order

Web application responses have policies applied in the following order:

1. Cloaking policy [P21] 2. Data Theft Protection policy [P22] 3. Instant SSL rewrite [P23] 4. Web address translation (WAT) [P24] 5. XML Firewall [P25] 6. URL Encryption policy [P26] 7. Compression policy [P27] 8. Caching [P28]

The following flowchart explains the Response Policy Order:

342 343 Execution Flow

The following sections describe how the Barracuda Web Application Firewall processes and evaluates web application requests and responses. (Policies are referenced by the associated number from the preceding lists P1 through P22.)

HTTP Request

The Barracuda Web Application Firewall applies the following policies in order to a request before forwarding it to the back-end server:

1. When a request is received, the Barracuda Web Application Firewall first performs Network Layer checks such as Network ACLs [P1], Barracuda Block list [P2] (i.e. checks if the IP address has been identified as a potential spam, malware or bot originator.), then the Geo Location ACLs [P3]. 2. If the request passes network layer checks, the Barracuda Web Application Firewall then performs SSL checks [P4], and then limit checks [P5] on various components of the HTTP request including URL length, header length, number of headers, and request length. A request exceeding any of these limits is dropped. These checks are performed as request headers are received via one or more TCP packets at the application layer. 3. If the URL Encryption is enabled for the service, the Barracuda Web Application Firewall decrypts the URLs in the request [P6]. 4. If Instant SSL redirect policy is enabled for the application [P7], the request is redirected to the corresponding HTTPS application, with no further policies applied to it. 5. After all headers are received, the URL and domain of the request are normalized [P8] into a temporary local buffer (see Configuring URL Normalization). The normalized URL and domain strings are used by all remaining policies. 6. Next the best matching rule group [P9] is found by comparison to the entire request header. 7.

344 7. Encrypted cookies are then decrypted by applying cookie security policies [P10] (see How to Secure HTTP Cookies). At this point, any cookies inserted by modules such as authentication are also decrypted. If cookie decryption fails, the cookie is removed from the request. This policy never denies a request. 8. Global allow-deny rules [P11] are now enforced taking the corresponding action of any matching rule (allow, deny with log, deny without log or redirect). If session tracking [P12] is enabled, the session is updated. Then the local allow-deny rules [P13], if any, are enforced. 9. If profiles [P14] are enabled, perform profile validations using any matching profile, and continue learning [P14] if configured in the profile and enabled for this request. If profiles are not enabled or no profile matches, perform default URL protection [P14] and parameter protection [P14]. 10. If a URL policy [P15] matches the request, perform the configured validations including virus scan, data theft protection, brute force prevention and/or rate control. 11. If access control is enabled for the request [P16] and it has no authentication cookie, the request is dropped. If access is allowed for the user according to the authentication cookie, the request proceeds to the next policy. A request goes through the authentication process if the request is for the authentication landing or login page. If authentication is successful, the Barracuda Web Application Firewall inserts an authorization cookie. None of the remaining policies apply to authorization requests. 12. If caching policy [P17] is enabled (see Configuring Caching and Compression) and if the request can be retrieved from the cache, the Barracuda Web Application Firewall serves the object from its cache store. If the object is found in the cache, none of the other policies apply to the request. No response policies are applied to a response from the cache. If the object is not found in cache, the request proceeds to the next step. 13. WAT policies [P18] are applied to the request (see Content Rewriting, Content Routing) including request rewrite and URL translation policies. Some portions of the request are rewritten due to this policy. Rewrite might also redirect the request, in which case none of the remaining policies are applied to the request. 14. If XML Firewall [P19] is enabled (see Web Services and XML Firewall Protection) content type is XML and if any matching protected URL is configured, enabled XML protection validations are enforced. The validations can include XML document checks, WS-I basic profile assertions and SOAP validations. 15. Load balancing policy [P20] (see Configuring Load Balancing for a Service) directs the request to the appropriate back-end server. The Barracuda Web Application Firewall might add a connection header at this step.

HTTP Response

The following policies are applied to the back-end server response:

1. If Cloaking policy [P21] is enabled, HTTP headers and return codes are masked before sending the response to the client. 2. If Data Theft Protection policy [P22] is enabled, sensitive data elements are masked before sending the response to the client. 3. If the Instant SSL rewrite policy is enabled [P23], some of the absolute URIs (hyperlinks with domain fields) found by the parsing engine might be rewritten to use the HTTPS protocol, depending on the rewrite domain list in the Instant SSL policy. 4. WAT policies are applied [P24]: a. Response rewrite policy rewrites the response headers (see Content Rewriting). It can add or delete a header conditionally based on other response headers and request URL and domain fields. b. URL translation policy rewrites the content (see Content Routing). If any hyperlink reference in the HTML content recognized by the HTML parsing engine matches a URL translation “inside rule,” the link is rewritten by applying the corresponding “outside rule.” If a page is translated, the response is either encoded using HTTP/1.1 Transfer Chunk Encoding scheme or the underlying TCP connection is closed if the front end used the HTTP/1.0 protocol. 5. If XML Firewall [P25] is enabled and the response matches any protected URL, then XML validations are enforced. 6. If URL Encryption [P26] is enabled for the service, the Barracuda Web Application Firewall encrypts the URLs before sending the response to the client. 7. If the Compression policy [P27] is On for the service/URL, the response page is compressed (see Configuring Caching and Compression ). 8. If the Caching policy [P28] is On for the request URL and if the response headers indicate the object can be cached, a copy of the page is stored in the cache.

Local Allow/Deny Rules

URL ACL rules (step 7 in “HTTP Request”) are applied in the following order. If the ACL mode is set to active, request processing is terminated when a violation of any policy in the ACL is detected. If the ACL mode is set to passive, the violation is logged and request processing continues. (The matching algorithm for URL ACLs and rule groups is the same.)

1. URL ACLs: The incoming request is compared to the list of URL ACLs to find the best match. If no match is found or the action parameter is set to deny, the request is dropped. The request is also compared to the limits and normalization policies, and dropped for any violation of these policies. The comparison is done with the < domain, URL, header > values in that order of precedence. 2. Header ACLs: Each of the headers in the request is compared to the list of header ACLs. If a match is found, the header value is validated by checking for denied metacharacters, denied keywords, and for valid length (compared to configured maximum length) for violations.

345 URL Policies

URL policies (step 8 in “HTTP Request”) are applied in the following order.

1. Virus Scan: The incoming client requests are scanned for viruses. Requests containing virus signatures are denied. 2. Rate Control: The Rate Control Pool is defined to limit client requests to the Barracuda Web Application Firewall. You can add a rate control pool and set a request maximum for that pool. Rate Controls protects applications from being pushed beyond their performance limits, preventing application layer Denial of Service (DoS) attacks. 3. Bruteforce Prevention: Bruteforce prevention protects web applications and websites from bruteforce attacks, which try every possible code, combination, or password to find the right one.

Rule Matching

A rule consists of three patterns: host, URL, and extended match rules. The policies of the “best matching” rule are applied to a request. Host and URL rules are used to match Host and URL fields, respectively. Extended match rules can be compared to any combination of HTTP headers and/or query string parameters in a request. A “*” rule (to be read as a rule consisting of URL “*”) matches any value for that parameter.

The best matching rule is the one with the longest matching host and URL and is the first matching rule in hierarchical order. If more than one extended match rule is configured with the same host and URL keys, the extended match rules are searched based on extended match sequence.

Rule Match Algorithm

Host and URL rules (used for both URL Policies and Rule Groups) are treated as pairs by the rule-match engine:

Prefix rule key is the part of the rule preceding the asterisk (*). The asterisk is treated as a wildcard meaning any value. Suffix rule key is the part of the rule succeeding the asterisk.

If a rule does not have an asterisk, its suffix rule key is NULL.

The following algorithm is used by Rule Match engine:

1. Find best matching Host Prefix Rule Key. Best match is defined as the longest rule matching the HTTP request Host header left to right. The number of characters matched is the length of the Prefix Rule Key. If no Prefix Rule matches, Rule Match engine terminates with failure and the request is dropped. 2. Find the best matching Host Suffix Rule Key. Best match is defined as the longest Suffix Rule Key matching the HTTP request Host header right to left. The number of characters matched is the length of Suffix Rule Key. If a matching rule is found, the current < Prefix, Suffix > pair matches Host Rule Key so go to Step 3. If no Host suffix Rule matches, discard this Prefix Rule Key and go to Step 1 to find the next matching Host Prefix Rule. 3. Find the best matching URL Prefix Rule Key. If none found, discard this Host Rule Key and go to step 1 to find the next matching Host Rule Key. Best matching URL Prefix Key is defined as the longest URL Prefix Rule matching the HTTP Request-URI header left to right. The number of characters matched is the length of URL Prefix Rule Key. 4. Find the best matching URL Suffix Rule Key. Best match is defined as the longest Suffix Rule Key matching the HTTP Request-URI header right to left. If found, the current < Prefix, Suffix > pair is the matching URL Rule Key. We found the best matching Host Rule Key and URL Rule Key and continue at Step 5. If no match is found, discard this Prefix URL Rule and go back to Step 3 to find the next matching URL Prefix Rule. 5. Find the first matching Extended Match Rule. The Extended Match rules are sorted based on the extended match sequence. If a matching rule is found, Rule match engine terminates with success and the HTTP Request follows the policies defined on this rule. If no match is found, discard this Extended Match Rule and go back to Step 4 to find the next matching URL Suffix Rule Key.

A successful search terminates at step 5. An unsuccessful search terminates at step 1.

Hierarchical Match

The hierarchical match first compares the host header in the request to all host matches configured, and takes the best match. Now the ACL list is reduced to this set. Next, it compares the URL path in the request to all URLs in the reduced set of ACLs. This is again a best match. If multiple ACLs match, then each extended match rule is evaluated in ascending order of extended match sequence. The first extended match rule that matches will be the ACL match.

For example, consider the requests given below and see how it is matched with the ACLs in the following table:

ACLs Host Match URL Match Extended Match Extended Match Sequence

346 1 www.abc.com /sales1/* Header User-Agent co 1 IE5.0 1

2 www.abc.com /sales1/* Header User-Agent co 2 Mozilla 2

3 www.abc.com /sales1/* * 3

4 www.abc.com /sales2/* Header User-Agent co 0 wget 0

5 *.abc.com /sales2/* * 0

6 *.abc.com /sales3/* * 0

7 * /sales1/* * 0

8 * * * 0

1. http://www.abc.com/sales1/index.html, from IE5.0 a. Host header is www.abc.com, therefore ACLs 1 to 4 match this request. Also ACLs 4 to 8 match, but 1 to 4 are better matches, since they are more specific. b. URL Path is /sales1/index.html, therefore ACLs 1 to 3 match. c. Evaluate extended match rule for ACL 1 first, since extended match sequence = 1. d. As a result, ACL 1 is matched. 2. http://www.abc.com/sales2/index.html, from IE5.0 a. Host header is www.abc.com, therefore ACLs 1 to 4 match. Also ACLs 4 to 8 match, but this is the best match, since it is most specific. b. URL Path is /sales2/index.html, therefore only ACL 4 matches. c. Evaluate extended match rule for ACL 4. ACL 4 does not match, since User-Agent is expected to be wget, which is not true. d. Thus, no matches in ACLs 1 to 4. e. The next best matching ACLs on the host header are ACLs 5 to 6. f. URL Path matches only ACL 5. g. Evaluate extended match rule for ACL 5. * matches anything. h. As a result, ACL 5 is matched. 3. http://www.abc.com/sales3/index.html a. Host header is www.abc.com, therefore ACLs 1 to 4 match. Also ACLs 4 to 8 match, but this is the best match, since it is most specific. b. URL Path is /sales3/index.html, which does not match any of the URLs in ACLs 1 to 4. c. The next best matching ACLs on the host header are ACLs 5 to 6 d. URL path matches only ACL 6. e. Header rule matches ACL 6. f. As a result, ACL 6 is matched. 4. http://mirror.abc.com/sales4/index.html a. Host header is mirror.abc.com, therefore ACLs 5 and 6 match. b. URL Path does not match any of the URLs in ACLs 5 and 6. c. The next best matching ACLs on the host header are ACLs 7 and 8. d. URL path matches only ACL 8. e. Header rule matches ACL 8. f. As a result, ACL 8 is matched.

Sequential Match

Sequential match completely ignores the host header and URL path. Each extended match rule is evaluated in sequential order based on the extended match sequence. The first rule that matches is the ACL match.

To explain how the rule-match engine selects the best match, consider the following Rule Match table:

ACLs Host Match URL Match Extended Match Rule Extended Match Sequence

347 1 * * Header Host eq 1 www.abc.com && Header User-Agent co IE5.0 && URI req /sales1/*

2 * * Header Host eq 2 www.abc.com && Header User-Agent co Mozilla && URI req /sales1/*

3 * * * * Header Host eq 3 www.abc.com && URI req /sales1/*

4 * * * * Header Host eq 4 www.abc.com && Header User-Agent co wget && URI req /sales2/*

5 * * * * Header Host req 5 .abc.com && URI req /sales2/*

6 * * * * Header Host req 6 *.abc.com && URI req /sales3/*

7 * * * URI req /sales1/* 7

8 * * * 8

1. sales2http://www.abc.com/sales1/index.html, from IE5.0 a. ACLs 1 to 8 match host and URL keys. b. Evaluate extended match rule for ACL 1 first, since extended match sequence = 1. c. As a result, ACL 1 is matched. 2. http://www.abc.com/sales2/index.html, from IE5.0 a. ACLs 1 to 8 match host and URL keys. b. Evaluate extended match rule for ACL 1 to 8 in order. c. Extended match rule for ACL 5 matches. d. As a result, ACL 5 is matched. 3. http://www.abc.com/sales3/index.html a. ACLs 1 to 8 match host and URL keys. b. Evaluate header rules for ACL 1 to 8 in order. c. Header rule for ACL 6 matches. d. As a result, ACL 6 is matched. 4. http://mirror.abc.com/sales4/index.html a. ACLs 1 to 8 match host and URL keys. b. Evaluate header rules for ACL 1 to 8 in order. c. Header rule matches ACL 8. d. As a result, ACL 8 is matched.

Limited Warranty and License en Limited Warranty

Barracuda Networks, Inc., or the Barracuda Networks, Inc. subsidiary or authorized Distributor selling the Barracuda Networks product, if sale is not directly by Barracuda Networks, Inc., (“Barracuda Networks”) warrants that commencing from the date of delivery to Customer (but in case of

348 resale by a Barracuda Networks reseller, commencing not more than sixty (60) days after original shipment by Barracuda Networks, Inc.), and continuing for a period of one (1) year: (a) its products (excluding any software) will be free from material defects in materials and workmanship under normal use; and (b) the software provided in connection with its products, including any software contained or embedded in such products will substantially conform to Barracuda Networks published specifications in effect as of the date of manufacture. Except for the foregoing, the software is provided as is. In no event does Barracuda Networks warrant that the software is error free or that Customer will be able to operate the software without problems or interruptions. In addition, due to the continual development of new techniques for intruding upon and attacking networks, Barracuda Networks does not warrant that the software or any equipment, system or network on which the software is used will be free of vulnerability to intrusion or attack. The limited warranty extends only to you the original buyer of the Barracuda Networks product and is non-transferable.

Exclusive Remedy

Your sole and exclusive remedy and the entire liability of Barracuda Networks under this limited warranty shall be, at Barracuda Networks or its service centers option and expense, the repair, replacement or refund of the purchase price of any products sold which do not comply with this warranty. Hardware replaced under the terms of this limited warranty may be refurbished or new equipment substituted at Barracuda Networks option. Barracuda Networks obligations hereunder are conditioned upon the return of affected articles in accordance with Barracuda Networks then-current Return Material Authorization (“RMA”) procedures. All parts will be new or refurbished, at Barracuda Networks discretion, and shall be furnished on an exchange basis. All parts removed for replacement will become the property of the Barracuda Networks. In connection with warranty services hereunder, Barracuda Networks may at its discretion modify the hardware of the product at no cost to you to improve its reliability or performance. The warranty period is not extended if Barracuda Networks repairs or replaces a warranted product or any parts. Barracuda Networks may change the availability of limited warranties, at its discretion, but any changes will not be retroactive. IN NO EVENT SHALL BARRACUDA NETWORKS LIABILITY EXCEED THE PRICE PAID FOR THE PRODUCT FROM DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES RESULTING FROM THE USE OF THE PRODUCT, ITS ACCOMPANYING SOFTWARE, OR ITS DOCUMENTATION.

Exclusions and Restrictions

This limited warranty does not apply to Barracuda Networks products that are or have been (a) marked or identified as “sample” or “beta,” (b) loaned or provided to you at no cost, (c) sold “as is,” (d) repaired, altered or modified except by Barracuda Networks, (e) not installed, operated or maintained in accordance with instructions supplied by Barracuda Networks, or (f) subjected to abnormal physical or electrical stress, misuse, negligence or to an accident.

EXCEPT FOR THE ABOVE WARRANTY, BARRACUDA NETWORKS MAKES NO OTHER WARRANTY, EXPRESS, IMPLIED OR STATUTORY, WITH RESPECT TO BARRACUDA NETWORKS PRODUCTS, INCLUDING WITHOUT LIMITATION ANY IMPLIED WARRANTY OF TITLE, AVAILABILITY, RELIABILITY, USEFULNESS, MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NONINFRINGEMENT, OR ARISING FROM COURSE OF PERFORMANCE, DEALING, USAGE OR TRADE. EXCEPT FOR THE ABOVE WARRANTY, BARRACUDA NETWORKS PRODUCTS AND THE SOFTWARE IS PROVIDED “AS IS” AND BARRACUDA NETWORKS DOES NOT WARRANT THAT ITS PRODUCTS WILL MEET YOUR REQUIREMENTS OR BE UNINTERRUPTED, TIMELY, AVAILABLE, SECURE OR ERROR-FREE, OR THAT ANY ERRORS IN ITS PRODUCTS OR THE SOFTWARE WILL BE CORRECTED. FURTHERMORE, BARRACUDA NETWORKS DOES NOT WARRANT THAT BARRACUDA NETWORKS PRODUCTS, THE SOFTWARE OR ANY EQUIPMENT, SYSTEM OR NETWORK ON WHICH BARRACUDA NETWORKS PRODUCTS WILL BE USED WILL BE FREE OF VULNERABILITY TO INTRUSION OR ATTACK.

Software License

PLEASE READ THIS SOFTWARE LICENSE AGREEMENT (“AGREEMENT”) CAREFULLY BEFORE USING THE BARRACUDA SOFTWARE. BY USING THE BARRACUDA SOFTWARE YOU ARE AGREEING TO BE BOUND BY THE TERMS OF THIS LICENSE. IF YOU DO NOT AGREE TO THE TERMS OF THIS LICENSE DO NOT USE THE SOFTWARE. IF YOU DO NOT AGREE TO THE TERMS OF THIS LICENSE YOU MAY RETURN THE SOFTWARE OR HARDWARE CONTAINING THE SOFTWARE FOR A FULL REFUND TO YOUR PLACE OF PURCHASE.

1. The software, documentation, whether on disk, in read only memory, or on any other media or in any other form (collectively “Barracuda Software”) is licensed, not sold, to you by Barracuda Networks, Inc. (“Barracuda”) for use only under the terms of this License and Barracuda reserves all rights not expressly granted to you. The rights granted are limited to Barracuda's intellectual property rights in the Barracuda Software and do not include any other patent or intellectual property rights. You own the media on which the Barracuda Software is recorded but Barracuda retains ownership of the Barracuda Software itself.

2. Permitted License Uses and Restrictions. This License allows you to use the Software only on the single Barracuda labeled hardware device on which the software was delivered. You may not make copies of the Software and you may not make the Software available over a network where it could be utilized by multiple devices or copied. You may not make a backup copy of the Software. You may not modify or create derivative works of the Software except as provided by the Open Source Licenses included below. The BARRACUDA SOFTWARE IS NOT INTENDED FOR USE IN THE OPERATION OF NUCLEAR FACILITIES, AIRCRAFT NAVIGATION OR COMMUNICATION SYSTEMS, LIFE

349 SUPPORT MACHINES, OR OTHER EQUIPEMENT IN WHICH FAILURE COULD LEAD TO DEATH, PERSONAL INJURY, OR ENVIRONMENTAL DAMAGE.

3. You may not transfer, rent, lease, lend, or sublicense the Barracuda Software.

4. This License is effective until terminated. This License is automatically terminated without notice if you fail to comply with any term of the License. Upon termination you must destroy or return all copies of the Barracuda Software.

5. YOU EXPRESSLY ACKNOWLEDGE AND AGREE THAT THE USE OF THE BARRACUDA SOFTWARE IS AT YOUR OWN RISK AND THAT THE ENTIRE RISK AS TO SATISFACTION, QUALITY, PERFORMANCE, AND ACCURACY IS WITH YOU. THE BARRACUDA SOFTWARE IS PROVIDED “AS IS” WITH ALL FAULTS AND WITHOUT WARRANTY OF ANY KIND, AND BARRACUDA HEREBY DISCLAIMS ALL WARRANTIES AND CONDITIONS WITH RESPECT TO THE BARRACUDA SOFTWARE, EITHER EXPRESSED OR IMPLIED OR STATUTORY, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES AND/OR CONDITIONS OF MERCHANTIBILITY, OF SATISFACTORY QUALITY, OF FITNESS FOR ANY APPLICATION, OF ACCURACY, AND OF NON-INFRINGEMENT OF THIRD PARTY RIGHTS. BARRACUDA DOES NOT WARRANT THE CONTINUED OPERATION OF THE SOFTWARE, THAT THE PERFORMANCE WILL MEET YOUR EXPECTATIONS, THAT THE FUNCTIONS WILL MEET YOUR REQUIREMENTS, THAT THE OPERATION WILL BE ERROR FREE OR CONTINUOUS, OR THAT DEFECTS WILL BE CORRECTED. NO ORAL OR WRITTEN INFORMATION GIVEN BY BARRACUDA OR AUTHORIZED BARRACUDA REPRESENTATIVE SHALL CREATE A WARRANTY. SHOULD THE BARRACUDA SOFTWARE PROVE DEFECTIVE, YOU ASSUME THE ENTIRE COST OF ALL NECESSARY SERVICING, REPAIR, OR CORRECTION.

6. License. YOU EXPRESSLY ACKNOWLEDGE AND AGREE THAT YOU WILL PROVIDE AN UNLIMITED ZERO COST LICENSE TO BARRACUDA FOR ANY PATENTS OR OTHER INTELLECTUAL PROPERTY RIGHTS UTILIZED IN THE BARRACUDA SOFTWARE WHICH YOU EITHER OWN OR CONTROL.

7. Limitation of Liability. TO THE EXTENT NOT PROHIBITED BY LAW, IN NO EVENT SHALL BARRACUDA BE LIABLE FOR PERSONAL INJURY OR ANY INCIDENTAL SPECIAL, INDIRECT, OR CONSEQUENTIAL DAMAGES WHATSOEVER, INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF PROFITS, LOSS OF DATA, BUSINESS INTERRUPTION, OR ANY OTHER COMMERCIAL DAMAGES OR LOSSES, ARISING OUT OF OR RELATED TO YOUR ABILITY TO USE OR INABILITY TO USE THE BARRACUDA SOFTWARE HOWEVER CAUSED, REGARDLESS OF THE THEORY OF LIABILITY AND EVEN IF BARRACUDA HAS BEEN ADVISED OF THE POSSIBILITY OF DAMAGES. In no event shall Barracuda's total liability to you for all damages exceed the amount of one hundred dollars.

8. Export Control. You may not use or otherwise export or re-export Barracuda Software except as authorized by the United States law and the laws of the jurisdiction where the Barracuda Software was obtained.

Energize Update Software License

PLEASE READ THIS ENERGIZE UPDATE SOFTWARE LICENSE CAREFULLY BEFORE DOWNLOADING, INSTALLING OR USING BARRACUDA NETWORKS OR BARRACUDA NETWORKS-SUPPLIED ENERGIZE UPDATE SOFTWARE.

BY DOWNLOADING OR INSTALLING THE ENERGIZE UPDATE SOFTWARE, OR USING THE EQUIPMENT THAT CONTAINS THIS SOFTWARE, YOU ARE CONSENTING TO BE BOUND BY THIS LICENSE. IF YOU DO NOT AGREE TO ALL OF THE TERMS OF THIS LICENSE, THEN (A) DO NOT DOWNLOAD, INSTALL OR USE THE SOFTWARE, AND (B) YOU MAY RETURN THE SOFTWARE FOR A FULL REFUND, OR, IF THE SOFTWARE IS SUPPLIED AS PART OF ANOTHER PRODUCT, YOU MAY RETURN THE ENTIRE PRODUCT FOR A FULL REFUND. YOUR RIGHT TO RETURN AND REFUND EXPIRES 30 DAYS AFTER PURCHASE FROM BARRACUDA NETWORKS OR AN AUTHORIZED BARRACUDA NETWORKS RESELLER, AND APPLIES ONLY IF YOU ARE THE ORIGINAL PURCHASER.

The following terms govern your use of the Energize Update Software except to the extent a particular program (a) is the subject of a separate written agreement with Barracuda Networks or (b) includes a separate “click-on” license agreement as part of the installation and/or download process. To the extent of a conflict between the provisions of the foregoing documents, the order of precedence shall be (1) the written agreement, (2) the click-on agreement, and (3) this Energize Update Software License.

License. Subject to the terms and conditions of and except as otherwise provided in this Agreement, Barracuda Networks, Inc., or a Barracuda Networks, Inc. subsidiary (collectively “Barracuda Networks”), grants to the end-user (“Customer”) a nonexclusive and nontransferable license to use the Barracuda Networks Energize Update program modules and data files for which Customer has paid the required license fees (the “Energize Update Software”). In addition, the foregoing license shall also be subject to the following limitations, as applicable:

Unless otherwise expressly provided in the documentation, Customer shall use the Energize Update Software solely as embedded in, for execution on, or (where the applicable documentation permits installation on non-Barracuda Networks equipment) for communication with Barracuda Networks equipment owned or leased by Customer; Customer's use of the Energize Update Software shall be limited to use on a single hardware chassis, on a single central processing unit, as applicable, or use on such greater number of chassis or central processing units as Customer may have paid Barracuda Networks the required license fee; and Customer's use of the Energize Update Software shall also be limited, as applicable and set forth in Customer's purchase order or in Barracuda Networks' product catalog, user documentation, or web site, to a maximum number of (a) seats (i.e. users with access to the installed Energize Update Software), (b) concurrent users, sessions, ports, and/or issued and outstanding IP addresses, and/or (c) central processing unit cycles or instructions per second. Customer's use of the Energize Update

350 Software shall also be limited by any other restrictions set forth in Customer's purchase order or in Barracuda Networks' product catalog, user documentation or web site for the Energize Update Software.

General Limitations. Except as otherwise expressly provided under this Agreement, Customer shall have no right, and Customer specifically agrees not to:

1. transfer, assign or sublicense its license rights to any other person, or use the Energize Update Software on unauthorized or secondhand Barracuda Networks equipment, and any such attempted transfer, assignment or sublicense shall be void; 2. make error corrections to or otherwise modify or adapt the Energize Update Software or create derivative works based upon the Energize Update Software, or to permit third parties to do the same; or 3. decompile, decrypt, reverse engineer, disassemble or otherwise reduce the Energize Update Software to human-readable form to gain access to trade secrets or confidential information in the Energize Update Software.

Upgrades and Additional Copies. For purposes of this Agreement, “Energize Update Software” shall include (and the terms and conditions of this Agreement shall apply to) any Energize Update upgrades, updates, bug fixes or modified versions (collectively, “Upgrades”) or backup copies of the Energize Update Software licensed or provided to Customer by Barracuda Networks or an authorized distributor/reseller for which Customer has paid the applicable license fees. NOTWITHSTANDING ANY OTHER PROVISION OF THIS AGREEMENT: (1) CUSTOMER HAS NO LICENSE OR RIGHT TO USE ANY SUCH ADDITIONAL COPIES OR UPGRADES UNLESS CUSTOMER, AT THE TIME OF ACQUIRING SUCH COPY OR UPGRADE, ALREADY HOLDS A VALID LICENSE TO THE ORIGINAL ENERGIZE UPDATE SOFTWARE AND HAS PAID THE APPLICABLE FEE FOR THE UPGRADE; (2) USE OF UPGRADES IS LIMITED TO BARRACUDA NETWORKS EQUIPMENT FOR WHICH CUSTOMER IS THE ORIGINAL END USER PURCHASER OR LESSEE OR WHO OTHERWISE HOLDS A VALID LICENSE TO USE THE ENERGIZE UPDATE SOFTWARE WHICH IS BEING UPGRADED; AND (3) USE OF ADDITIONAL COPIES IS LIMITED TO BACKUP PURPOSES ONLY.

Energize Update Changes. Barracuda Networks reserves the right at any time not to release or to discontinue release of any Energize Update Software and to alter prices, features, specifications, capabilities, functions, licensing terms, release dates, general availability or other characteristics of any future releases of the Energize Update Software.

Proprietary Notices. Customer agrees to maintain and reproduce all copyright and other proprietary notices on all copies, in any form, of the Energize Update Software in the same form and manner that such copyright and other proprietary notices are included on the Energize Update Software. Except as expressly authorized in this Agreement, Customer shall not make any copies or duplicates of any Energize Update Software without the prior written permission of Barracuda Networks. Customer may make such backup copies of the Energize Update Software as may be necessary for Customer's lawful use, provided Customer affixes to such copies all copyright, confidentiality, and proprietary notices that appear on the original.

Protection of Information. Customer agrees that aspects of the Energize Update Software and associated documentation, including the specific design and structure of individual programs, constitute trade secrets and/or copyrighted material of Barracuda Networks. Customer shall not disclose, provide, or otherwise make available such trade secrets or copyrighted material in any form to any third party without the prior written consent of Barracuda Networks. Customer shall implement reasonable security measures to protect and maintain the confidentiality of such trade secrets and copyrighted material. Title to Energize Update Software and documentation shall remain solely with Barracuda Networks.

Indemnity. Customer agrees to indemnify, hold harmless and defend Barracuda Networks and its affiliates, subsidiaries, officers, directors, employees and agents at Customers expense, against any and all third-party claims, actions, proceedings, and suits and all related liabilities, damages, settlements, penalties, fines, costs and expenses (including, without limitation, reasonable attorneys fees and other dispute resolution expenses) incurred by Barracuda Networks arising out of or relating to Customers (a) violation or breach of any term of this Agreement or any policy or guidelines referenced herein, or (b) use or misuse of the Barracuda Networks Energize Update Software.

Term and Termination. This License is effective upon date of delivery to Customer of the initial Energize Update Software (but in case of resale by a Barracuda Networks distributor or reseller, commencing not more than sixty (60) days after original Energize Update Software purchase from Barracuda Networks) and continues for the period for which Customer has paid the required license fees. Customer may terminate this License at any time by notifying Barracuda Networks and ceasing all use of the Energize Update Software. By terminating this License, Customer forfeits any refund of license fees paid and is responsible for paying any and all outstanding invoices. Customer's rights under this License will terminate immediately without notice from Barracuda Networks if Customer fails to comply with any provision of this License. Upon termination, Customer must cease use of all copies of Energize Update Software in its possession or control.

Export. Software, including technical data, may be subject to U.S. export control laws, including the U.S. Export Administration Act and its associated regulations, and may be subject to export or import regulations in other countries. Customer agrees to comply strictly with all such regulations and acknowledges that it has the responsibility to obtain licenses to export, re-export, or import Energize Update Software.

Restricted Rights. Barracuda Networks' commercial software and commercial computer software documentation is provided to United States Government agencies in accordance with the terms of this Agreement, and per subparagraph “(c)” of the “Commercial Computer Software - Restricted Rights” clause at FAR 52.227-19 (June 1987). For DOD agencies, the restrictions set forth in the “Technical Data-Commercial Items” clause at DFARS 252.227-7015 (Nov 1995) shall also apply.

351 No Warranty. The Energize Update Software is provided AS IS. Customer's sole and exclusive remedy and the entire liability of Barracuda Networks under this Energize Update Software License Agreement will be, at Barracuda Networks option, repair, replacement, or refund of the Energize Update Software.

Renewal. At the end of the Energize Update Service Period, Customer may have the option to renew the Energize Update Service at the current list price, provided such Energize Update Service is available. All initial subscriptions commence at the time of sale of the unit and all renewals commence at the expiration of the previous valid subscription.

In no event does Barracuda Networks warrant that the Energize Update Software is error free or that Customer will be able to operate the Energize Update Software without problems or interruptions. In addition, due to the continual development of new techniques for intruding upon and attacking networks, Barracuda Networks does not warrant that the Energize Update Software or any equipment, system or network on which the Energize Update Software is used will be free of vulnerability to intrusion or attack.

DISCLAIMER OF WARRANTY. ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS, AND WARRANTIES INCLUDING, WITHOUT LIMITATION, ANY IMPLIED WARRANTY OR CONDITION OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NONINFRINGEMENT, SATISFACTORY QUALITY OR ARISING FROM A COURSE OF DEALING, LAW, USAGE, OR TRADE PRACTICE, ARE HEREBY EXCLUDED TO THE EXTENT ALLOWED BY APPLICABLE LAW. TO THE EXTENT AN IMPLIED WARRANTY CANNOT BE EXCLUDED, SUCH WARRANTY IS LIMITED IN DURATION TO THE WARRANTY PERIOD. BECAUSE SOME STATES OR JURISDICTIONS DO NOT ALLOW LIMITATIONS ON HOW LONG AN IMPLIED WARRANTY LASTS, THE ABOVE LIMITATION MAY NOT APPLY TO YOU. THIS WARRANTY GIVES YOU SPECIFIC LEGAL RIGHTS, AND YOU MAY ALSO HAVE OTHER RIGHTS WHICH VARY FROM JURISDICTION TO JURISDICTION.

General Terms Applicable to the Energize Update Software License Disclaimer of Liabilities. IN NO EVENT WILL BARRACUDA NETWORKS BE LIABLE FOR ANY LOST REVENUE, PROFIT, OR DATA, OR FOR SPECIAL, INDIRECT, CONSEQUENTIAL, INCIDENTAL, OR PUNITIVE DAMAGES HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY ARISING OUT OF THE USE OF OR INABILITY TO USE THE ENERGIZE UPDATE SOFTWARE EVEN IF BARRACUDA NETWORKS OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. In no event shall Barracuda Networks' liability to Customer, whether in contract, tort (including negligence), or otherwise, exceed the price paid by Customer. BECAUSE SOME STATES OR JURISDICTIONS DO NOT ALLOW LIMITATION OR EXCLUSION OF CONSEQUENTIAL OR INCIDENTAL DAMAGES, THE ABOVE LIMITATION MAY NOT APPLY TO YOU.

This Energize Update Software License shall be governed by and construed in accordance with the laws of the State of California, without reference to principles of conflict of laws, provided that for Customers located in a member state of the European Union, Norway or Switzerland, English law shall apply. The United Nations Convention on the International Sale of Goods shall not apply. If any portion hereof is found to be void or unenforceable, the remaining provisions of the Energize Update Software License shall remain in full force and effect. Except as expressly provided herein, the Energize Update Software License constitutes the entire agreement between the parties with respect to the license of the Energize Update Software and supersedes any conflicting or additional terms contained in the purchase order.

Open Source Licensing

Barracuda products may include programs that are covered by the GNU General Public License (GPL) or other “open source” license agreements. The GNU license is re-printed below for you reference. These programs are copyrighted by their authors or other parties, and the authors and copyright holders disclaim any warranty for such programs. Other programs are copyright by Barracuda Networks.

GNU GENERAL PUBLIC LICENSE, (GPL) Version 2, June 1991

Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

Preamble

The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public

License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundation's software and to any other program whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU Library General Public License instead.) You can apply it to your programs, too.

When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things.

To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it.

For example, if you distribute copies of such a program, whethergratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.

352 We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software.

Also, for each author's protection and ours, we want to make certain that everyone understands that there is no warranty for this free software. If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors' reputations.

Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all.

The precise terms and conditions for copying, distribution and modification follow.

GNU GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION

0. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term "modification".) Each licensee is addressed as "you".

Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does.

1. You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program.

You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee.

2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:

a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.

b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.

c) If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.)

These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.

Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.

In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.

3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:

a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,

b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,

353 c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)

The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.

If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code.

4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.

5. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it.

6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.

7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program.

If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances.

It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice.

This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License.

8. If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License.

9. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.

Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and "any later version", you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.

10. If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally.

354 NO WARRANTY

11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

END OF TERMS AND CONDITIONS

How to Apply These Terms to Your New Programs

If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms.

To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found. one line to give the program's name and an idea of what it does.

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.

Also add information on how to contact you by electronic and paper mail.

If the program is interactive, make it output a short notice like this when it starts in an interactive mode:

Gnomovision version 69, Copyright (C) 19yy name of author Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. This is free software, and you are welcome to redistribute it under certain conditions; type `show c' for details.

The hypothetical commands `show w' and `show c' should show the appropriate parts of the General Public License. Of course, the commands you use may be called something other than `show w' and `show c'; they could even be mouse-clicks or menu items--whatever suits your program.

You should also get your employer (if you work as a programmer) or your school, if any, to sign a "copyright disclaimer" for the program, if necessary. Here is a sample; alter the names:

Yoyodyne, Inc., hereby disclaims all copyright interest in the program `Gnomovision' (which makes passes at compilers) written by James Hacker. signature of Ty Coon, 1 April 1989 Ty Coon, President of Vice

This General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Library General Public License instead of this License.

Barracuda Products may contain programs that are copyright (c)1995-2005 International Business Machines Corporation and others. All rights reserved. These programs are covered by the following License:

"Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, and/or

355 sell copies of the Software, and to permit persons to whom the Software is furnished to do so, provided that the above copyright notice(s) and this permission notice appear in all copies of the Software and that both the above copyright notice(s) and this permission notice appear in supporting documentation."

Barracuda Products may include programs that are covered by the BSD License: "Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

The names of the authors may not be used to endorse or promote products derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE."

Barracuda Products may include the libspf library which is Copyright (c) 2004 James Couzens & Sean Comeau All rights reserved. It is covered by the following agreement: Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS MAKING USE OF THIS LICENSE OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Barracuda Products may contain programs that are Copyright (c) 1998-2003 Carnegie Mellon University. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. The name "Carnegie Mellon University" must not be used to endorse or promote products derived from this software without prior written permission. For permission or any other legal details, please contact Office of Technology Transfer Carnegie Mellon University 5000 Forbes Avenue Pittsburgh, PA 15213-3890 (412) 268-4387, fax: (412) 268-7395 [email protected] .Redistributions of any form whatsoever must retain the following acknowledgment: "This product includes software developed by Computing Services at Carnegie Mellon University (http://www.cmu.edu/computing/)." CARNEGIE MELLON UNIVERSITY DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL CARNEGIE MELLON UNIVERSITY BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

Barracuda products may include programs that are covered by the Apache License or other Open Source license agreements. The Apache license is re-printed below for you reference. These programs are copyrighted by their authors or other parties, and the authors and copyright holders disclaim any warranty for such programs. Other programs are copyright by Barracuda Networks.

Apache License Version 2.0, January 2004 http://www.apache.org/licenses/

TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION

1. Definitions.

"License" shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document.

"Licensor" shall mean the copyright owner or entity authorized by the copyright owner that is granting the License.

"Legal Entity" shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, "control" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity.

356 "You" (or "Your") shall mean an individual or Legal Entity exercising permissions granted by this License.

"Source" form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files.

"Object" form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types.

"Work" shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below).

"Derivative Works" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof.

"Contribution" shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this definition, "submitted" means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as "Not a Contribution."

"Contributor" shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work.

2. Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form.

3. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed.

4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions:

(a) You must give any other recipients of the Work or Derivative Works a copy of this License; and

(b) You must cause any modified files to carry prominent notices stating that You changed the files; and

(c) You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and

(d) If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License.

You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License.

You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License.

5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions.

357 6. Trademarks. This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file.

7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License.

8. Limitation of Liability. In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages.

9. Accepting Warranty or Additional Liability. While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License. However, in accepting such obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your accepting any such warranty or additional liability.

END OF TERMS AND CONDITIONS

APPENDIX: How to apply the Apache License to your work.

To apply the Apache License to your work, attach the following boilerplate notice, with the fields enclosed by brackets "[]" replaced with your own identifying information. (Don't include the brackets!) The text should be enclosed in the appropriate comment syntax for the file format. We also recommend that a file or class name and description of purpose be included on the same "printed page" as the copyright notice for easier identification within third-party archives.

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

Source Code Availability

Per the GPL and other “open source” license agreements the complete machine readable source code for programs covered by the GPL or other “open source” license agreements is available from Barracuda Networks at no charge. If you would like a copy of the source code or the changes to a particular program we will gladly provide them, on a CD, for a fee of $100.00. This fee is to pay for the time for a Barracuda Networks engineer to assemble the changes and source code, create the media, package the media, and mail the media. Please send a check payable in USA funds and include the program name. We mail the packaged source code for any program covered under the GPL or other "open source" license.

358