WAF0201 - Barracuda Web Application Firewall - Advanced Features - Student Guide

Barracuda Web Application Firewall
WAF0201 - Barracuda Web Application Firewall – Advanced

Features
Training Video Transcript
Barracuda Web Application Firewall

WAF0201 - Barracuda Web Application Firewall –
Advanced Features
StudentGuide
Official learning material for Barracuda Campus training courses.
Table of Contents
Dummy Slide
• Dummy Slide - needed for Student Guide PDF → Table of
Content
– Add Table of content manually under “VIEW” > “Notes Page”
– Hide this slide when you create the Handout-PDF.
WAF02038 - Allow / Deny / Redirect Rules
– Delete the slide after you added the pptx to
Instructor package.
3
WAF02019 - Website Profiles 7
WAF02020 - Application DDos Protection 14
WAF02029 - Advanced System Management 19
WAF02041 – API Security 34
WAF02039 - Web Application and CloudGen Firewall
Integration 67
WAF02025 - Vulnerability Reports Integration 70
WAF02026 - Barracuda Vulnerability Manager 76
WAF02027 - Barracuda Vulnerability Remediation Service 80
WAF02040 - Client Side Protection 100
2
WAF02038 - Allow-Deny-Redirect Rules

Introducing Allow-Deny-Redirect Rules
Welcome, my name is Christoph, and I am a technical trainer at Barracuda Campus. If you want to limit user
access to certain parts of you web application, or if you want to enforce users to be logged in when accessing
other parts, or simply want to redirect from one page to another without changing the URL, then Allow , Deny
and Redirect Rules are the go-to tool for you.
© Barracuda Networks Inc., Revision: 7/18/2022 3

Allow/Deny Rules
• Define strict access control
rules for the services
Public Private – Rules are service-specific and
cannot be shared
• Cannot be shared among
Access Control services
Payments
• Two types of rules:
– Allow/Deny rules for URLs
– Allow/Deny rules for headers
Web Application
Allow, Deny, and Redirect rules allow you to define strict control rules for your web applications.
These rules allow you to specify the criteria that a specific request must fulfill before it can access a specific part
of your web application. Or, you can use the rules to redirect a user from one page to another.
Since these rules are configured per service, they can contain very granular security settings.
So a specific rule will be tailored to a specific part of your web application. But these rules cannot be shared
between different services.
There are two types of rules that you can create.
You can use allow/deny rules for URLs, and allow/deny rules for headers.

Allow/Deny Rules
Request
Tommy Application
Response Server
So where do we fit our allow/deny rules in our execution workflow? Well, allow/deny rules and redirect rules are
executed right after session tracking, if it is enabled, or right after global ACLS if session tracking is disabled.
If you compare Global ACLs with Allow / Deny / Redirect rules, the logic might seem very similar.
Both of these features allow you to create to access rules for your web applications. So you can define what can
be accessed or cannot be accessed with other requirements. So what's the difference between Global ACLs and
allow/deny rules? Well Global ACLs is a sub-policy of the security policy. This means that these policies are
shared, or can be shared, between multiple services.
So you should keep the configuration of global ACLs as generic as possible.
If you want to forbid the access to a specific file, for example, the php.info file, then Global ACLs is the place
where you can configure this because this is a general configuration. You will never access that file from the web
application itself.
On the other hand, if you want to strictly control who can access the checkout page of your web application with
all the requirements that the request must have to access that part of the web application, you can't use Global
ACLS because, again, they are for general configuration. So this is when you use Allow / Deny / Redirect Rules.

Allow/Deny Rules for Headers

• Enforce strict limitations on incoming headers
• Sanitize HTTP headers containing:
– Sensitive information identifying the client
– Some application-specific state information
• Prevent configured attack types
• Stop potentially malicious metacharacters and keywords
Allow/Deny and Redirect rules for headers allow you to specify the requirements of the HTTP headers that a
request must possess in order to access that specific part of your web app.
This will allow you to be more restrictive in the requirements for these headers, since you are not creating
general rules, but you are creating rules for specific parts or portions of your web application.
You can also use these rules to sanitize your HTTP headers
that might contain some specific information, and also to protect your web app against a text that might use
HTTP headers as vectors for SQL injections and so on↓.
And finally, you can restrict the metacharacters and keywords that are perfectly fine for the rest of your web app,
but that might be dangerous for the part of the web application that you're trying to protect.

WAF02019 - Website Profiles

Introducing Website Profiles
Welcome, my name is Christoph and I am a technical trainer at Barracuda Campus.

Website profiles is a very powerful feature of the Barracuda Web Application Firewall. They allow you to create
fine-tuned security rules for your web applications. Website profiles are defined for your services using URL
profiles, which means that every page that needs a custom configuration will have its URL profile and parameter
profile configured in the system.

Website Profiles
Request
Tommy Application
Server
Response
URL and parameter profiles are part of every website profile and compliment the URL and parameter protection
sub-policies.
Several settings can be configured for URL profiles, and inside URL profiles you will have your parameter profiles.
Parameter profiles define what should be allowed or expected for your parameters on your pages. The
configuration of website profiles is not mandatory. The Barracuda Web Application Firewall will protect your web
applications regardless of whether profiles are configured or not.

Website Profiles Overview

• Specific rules to fine-tune the security settings of a service
– URL profiles
– Parameter profiles
URL Profile Parameter Profile

First Name
• Input Field
First Name: Tommy
• Type Alpha
/cgi-bin/reg.cgi Last Name: Reed /cgi-bin/reg.cgi
• Max Char 16
Submit Last Name
Tommy Application
Reed • Input Field Server
/cgi-bin/reg.cgi • Type Alpha
WAF • Max Char 16
In other words, website profiles allow you to fine-tune the security settings of a service by defining what kind of
parameters you expect on each URL.
You can also define what you exactly expect from those parameters.
In this diagram, the Web Application Firewall is protecting the registration page of a web application.
This page is located in the CGI-bin directory and it's called reg.cgi. As you can see, there are 2 input fields in this
page: the first name and the last name input field, plus we have a submit button. Our user in this case, Tommy
Reed, wants to register with this web application. So he will fill in the first name and last name input fields
accordingly. We have configured a URL profile for this page inside our website profile.
We have created two parameter profiles, one for the first name and the second one for the last name input field.
They are both defined as input fields, and both parameters should only accept letters and a maximum number of
16 characters.
For the web application, this means that if a user tries to use numbers in the first name or last name input fields,
or if he tries to insert more than 16 characters, the WAF will block the request.

Website Profiles Modes

• Active - Validates requests; blocks and logs requests
violations
– Use URL profile and corresponding parameter profile(s) settings
• Passive - Validates the requests and logs violations
• Learning - Learns the web application structure
There are three different modes that you can use with website profiles.
In Active mode, the WAF inspects the request and blocks any requests that generate a violation. Blocked requests
will also be logged in the web firewall logs.
You can also use the Passive mode. In Passive mode, the WAF validates requests, and if there are any violations,
they will be logged in the web firewall logs. However, the request will go through to the real servers. Passive
mode allows you to configure
website profiles without interfering with the traffic that is going through the WAF.
The third mode that you can use with website profiles is called Learning mode. As the name suggests, Learning
mode allows the Barracuda Web Application Firewall to learn your web applications structure. We will talk about
Learning mode a bit later in this video.

Website Profiles - Strict Profile Check

• Enforce the positive or negative security model
• Strict Profile Check enabled:
– Validates requests and denies the requests that do not match the URL
profiles and parameter profiles
• Strict Profile Check disabled:
– Validates requests, and if they do not match the URL profiles and
parameter profiles, the requests are validated against the global security
policy
An additional benefit of having website profiles is the ability to enforce a positive model or a negative model for
specific URLs for your web applications.
The positive model will ensure that you have the highest level of protection for your web applications.
However, it is also very hard to configure and to maintain. To enforce a positive model, you only need to enable
the strict profile check. When it is enabled, the WAF will validate the request against your URL and parameter
profiles. If the request doesn’t match any URL or parameter profile, then the request is blocked.
If strict profile check is disabled, the WAF will validate the request against the website profiles, and if the request
does not match any of the URL profiles or parameter profiles, the WAF will go back to the security policy and
validate the request against the parameter and URL protection of your security policy.

Adaptive Profiling
• Automatically learns the structure of a web application
– Based on requests and/or responses
• Creates the website profile based on the learned structure
URL Profile Parameter Profile

First Name
• Input Field
First Name: Tommy
• Type Alpha
/cgi-bin/reg.cgi Last Name: Reed /cgi-bin/reg.cgi
Last Name
Tommy • … Application
Reed Server
/cgi-bin/reg.cgi
WAF
Adaptive profiling automatically learns your web application structure and creates all the necessary URL and
parameter profiles.
Bear in mind that the Barracuda Web Application Firewall does not have a crawler that automatically fetches the
information to create your profiles from your web application. Instead, the WAF analyze HTTP requests and
responses.
Based on the requests and responses, the WAF creates URL profiles and profiles for you.
In this diagram, we have Tommy, who is generating traffic to our web application.
The WAF will inspect all the requests and all the responses, and it will create all the necessary profiles.
You will then have the option to review all the profiles and change them before they are applied.
Usually, it is not a good idea to let the WAF learn the structure of your web apps from traffic that is coming from
users on the internet that you don't even really know. For this reason, you can use a trusted host to train the
adaptive profiling engine. Using a trusted host allows you to specify the sources of your traffic, so that the WAF
will only learn from requests and responses that are generated from these particular work stations.

Profile Optimizers
• Reduce the number of URL or Parameter profiles to
manage
• URL Optimizers: merge multiple URL profiles into one
• Parameter Optimizers: merge multiple Parameter profiles into one
/abc/page1.html
/abc/page2.html
/abc/page3.html Learning and optimizing…
/abc/page4.html
/abc/page*.html
param1
param2 param*
param3
param4
WAF
There are some situations where you have a web application that has very similar pages. In this case, it does not
make sense to create a specific URL profile for each one of the pages. The same goes for parameters. That's why
you can use profile optimizers to make sure that only one profile will be created for those specific pages, and
only one profile will be created for parameters, which are basically the same.
Using profile optimizers allows you to reduce the number of URL and parameter profiles that you have to
manage in your system. If you do not do this, the number of profiles can grow exponentially.
For example, say you have 10 pages that are identical, and for each page you have 100 parameters that again are
identical. You will end up having 1000 parameter profiles to manage in your system.
Profile optimizers can work with the adaptive profiling engine.
You just have to configure the optimizers before you start the learning process. The WAF will automatically learn
the structure of your web app and merge all the profiles that can be merged.
If your WAF already has some profile configured in the system, you can still use profile optimizers. You just have
to specify the requirement to merge all the profiles, and then you can run them after the creation of your profile.
The WAF will then merge all the profiles that match your criteria.

WAF02020 - Application DDoS Protection

Introducing Application DDoS Protection
Welcome, my name is Christoph, and I am technical trainer at Barracuda Campus. In some cases, attackers don’t
try to infiltrate or steal data from a web application. Instead, they just want to make it unreachable for their users.
They can do so by launching a large number of requests from many different sources. This is called a denial-of-
service attack. Of course, the Barracuda WAF offers features to protect your web application against such attacks.

IP Reputation Filter
• Filters traffic from specific geographic regions / categories
to a service
– Geo pool
– Barracuda Reputation
– TOR nodes
– Anonymous proxy
Requests blocked
– Satellite provider
WAF Backend Servers
The first feature that we are going to cover for the distributed denial-of-service attack protection is called the IP
reputation filter.
With the IP reputation filter, you can choose the allowed traffic sources that are trying to access your web
applications. This will allow you to filter not only which geographic regions can access your systems, but also
what kind of source can access your systems.
Using the IP reputation filter and locking down specific geographic regions or collections of regions will prevent
distributed attacks on your systems from being successful from these regions. Moreover, if your web application
is designed to work only for specific countries, you can configure the Barracuda Web Application Firewall to
accept traffic only from those specific countries. The system has a Geo IP database that is continuously updated
via your Energize Updates subscription. This database compares the source IP address with the relative source in
the g. This specific geographic location. You can also use the Barracuda reputation block list list is created and
maintained by Barracuda. It is a list of IP addresses that are identified as potential originators of malware or that
could be used by Bots.
You can also filter traffic that is coming from Tor nodes or that is going through anonymous proxies or coming
from satellite providers. In the last two cases, IP addresses are compared to a MaxMind database to determine if
the requestor is a known anonymizer or an ISP address.

Slow Client Attack Prevention

• Prevents:
– Slow HTTP headers vulnerability (Slowloris)
– Slow HTTP POST vulnerability (R-U-Dead-Yet, or RUDY)
– Slow read DoS attack
• Enforces requests / responses timeouts
• Enforces requests / responses minimum data transfer rates
The second feature of denial-of-service attack prevention is called slow client attack prevention.
This feature specifically addresses the prevention of attacks such as Slowris, Rudy, and also slow read denial of
service attacks. Bear in mind that these kind of attacks are layer 7 denial of service attacks. So, typically, they are
legitimate from a protocol or compliance point of view and, therefore, they are not usually detected by a network
layer security device or by IPS. These attacks are very slow, and typically they don't consume any significant
amount of bandwidth on your network. This is why they remain undetected.
It's not very easy to have adequate protection against such attacks.
With a Barracuda Web Application Firewall, we can set specific limits for request and response time outs and also
for the minimum data transfer rates.

DDoS Policies
• Passively evaluate the clients to determine whether they are
suspicious
• The client tagged as suspicious will be forced to answer a
CAPTCHA
JS
WAF
Web Server
BOT
C4PtcH4
Requests blocked
Another feature that you can use to prevent distributed denial of service attacks is Distributed Denial of Service
policies. When DDOS policies are enabled, the WAF will try to find out if the source of the request comes from a
regular browser or a crawler.
In order to discriminate the source of the traffic, you can tell the WAF to challenge all sources with CAPTCHA or
reCAPTCHA.
An alternative way is to evaluate the client. In this case,
the WAF will send JavaScript challenges in the responses that are are going back to the client. If a client does not
process the script and does not provide an answer to the WAF in the subsequent requests, the client will be
marked as suspicious. Subsequently, the client will be forced to answer a CAPTCHA challenge before it can
access that specific URL space. The source IP address of the suspicious client will be tracked and challenged with
a CAPTCHA image for a specific length of time. The client will not be allowed to access any resource until the
CAPTCHA is answered. Only if the client answers the CAPTCHA will access to that specific URL space be granted.

reCaptcha Integration
• Domains
• Site Key
• Site Secret
Service
Tommy Web Application

WAF
Speaking of CAPTCHA, as of the FW10,
you can also use Google’s reCAPTCHA service in addition to the WAF’s captcha.
Once the domain is registered at Google,
you can enable reCAPTCHA for the service and provide the domain name, the site
key, and the site secret that you received during registration. That’s all you need to
use it.

WAF02029 - Advanced System Management

Introducing Advanced System Management
Welcome, my name is Christoph, and I am a technical trainer at Barracuda Campus. In this video we will focus on
features that don’t affect the security of you web application but will help you manage the Barracuda Web
Application Firewall.

Content
• Role Based Administration
• Cloud Control
• Configuration Backup & Templates
• Default Patterns
• Encryption Key Settings
• Response Pages
In this video you will learn about
Role Admninistration,
how to integrate your Barracuda WAF with Barracuda Cloud Control and
how to create configuration backups and templates and how to use them.
You will also learn about default patterns,
the different encryption key seeting and
what response pages are.

WAF02029 – Advanced System Management

Role-Based Administration

Role-Based Administration
• Restricts access to system resources based on roles assigned to users
– Eight roles already preconfigured (cannot be deleted)
Objects
• Services
LDAP / RADIUS / SAML V2 Operations
• Security Policies
• Auth. Services
• Read
User Role
• Write
• Web Interface
Internal DB
In some companies, you have different roles in your security team. Some of these roles should be able to
configure the WAF, while others should only be allowed to monitor its status or generate reports.
With role-based administration you create multiple administrators in the Barracuda Web Application Firewall with
different permissions and privileges.
The system is configured with eight predefined roles that cannot be deleted or modified.
If you want, you can analyze the configuration of these roles and use them, or you can create additional roles.
But in order to use these roles, you have to add more administrator accounts into the system. To add
administrator accounts, you have two options. You can either connect the Barracuda Web Application Firewall
with an external user database (for example, an LDAP server, SAML V2 or a RADIUS server), or you can create a
local admin.
Once you have added a new account, you can link it with the roles.
Each role is made of different objects and operations. The first type, operations, lets you read or write the
configuration and the security policies or authentication services.
The second type, objects, is related to the web interface.

In a role, you can define which sections and which pages should be displayed to the user that is logged into the
WAF with that specific role.


Cloud Control

Cloud Control
• Monitor and configure multiple Barracuda Networks
products from one cloud interface
• The same tabbed pages are available for managing all
aspects of your Barracuda Networks product
WAF
Barracuda Admin
Browser
Cloud Control
If you own other Barracuda products, such as the Essentials or Backup, you might already be familiar with Cloud
Control.
If not, Cloud Control is a web UI that allows you to monitor and manage certain Barracuda products from a
single web UI.
That means, if you connect several products to the same Cloud Control account, you can manage all of them
with a single login. The UI will be very similar, if not the same, for each product.


Configuration Backup & Templates

Configuration Backup
• Can be used for backup purposes
• Upload to another Barracuda Web Application Firewall
• Cloud
• FTP /
Every
FTPS
day
WAF • SMB
5:00 a.m.
• Local
System • AWS S3
Destinations
Configuration
You can create a backup of the configuration of a Barracuda Web application Firewall that you can use in case
something happens to the system.
A backup can be generated from any system, be it a physical appliance, a virtual appliance, or a cloud instance.
These Backups can also be uploaded to other Barracuda WAFs for easier configuration.
Your private keys of your certificate are exportable, so these items will also be included in the configuration
backup. For this reason, as well as others, it is possible to encrypt these backups with an encryption key.
The only way to restore encrypted backups is to use the encryption key. You have to make sure that you note
down this encryption key and keep it in a safe place. If you lose this key, nobody - not even Barracuda - will be
able to restore an encrypted backup.
When you are backing up the configuration of the WAF, you can choose to save it to our Barracuda Cloud. This
only applies if your system is connected to Barracuda Cloud Control. Or, you can upload the file to an FTP server
or an SMB share. You can also download the configuration of the system locally from the workstation that are
you using to access the web UI.
And, finally, if your system is deployed in AWS, you can back up the configuration into an S3 bucket.
You can also configure scheduled backups, for example, every day at 5:00 a.m. This only applies if you have
destinations configured in the system.

Templates
• A collection of configuration components arranged serially in a file
• Can be used as a model across policy revisions or across
units
Service1 Service1
URL Policies URL Policies
Service2
Composite Full
URL Policies Template
Template
WAF_Dev WAF_Prod
A template is a collection of configuration components that can be reused in the same system or exported and
reused in another system.
Templates allow you to define baseline configuration settings that you can use as a model across multiple
services or multiple units↓. Apart from streamlining the configuration across multiple entities, templates will also
allow you to prevent manual errors that might occur when you are replicating the configuration in different
systems or in different services.
There are three different types of templates: full, partial, and composite templates.
A full template contains the configuration of a specific object.
For example, you can create a full template for a service that includes anything that you select, from URL profiles,
to URL ACLs, and so on.
Partial templates contain only part of a configuration object. You can create a partial template for the SSL
certificates that are assigned to a service. You can then reapply this template to the other services in order to
apply the same certificate.
And finally, we have the composite template, which is essentially a group of full templates of the same type of
objects. For example, we can export a composite template for the URL policies created for service one and then
re-import them into the same WAF.


Default Patterns

Default Pattern Mode
ADVANCED > System Configuration
ADVANCED > View Internal Patterns
The Barracuda Web Application Firewall patterns are updated automatically by your Energize Updates
subscription.
Once the new patterns are downloaded, they will be activated immediately.
By default, all new patterns will be set in passive mode.
Whereas all the patterns that are updated will be set in active mode.
The operating mode that we are referring to here is the operating mode that is specified in the attack types of
the View Internal Patterns page. So, for example, if we are going to publish a new pattern today for the cross-site
scripting vulnerability, this pattern will be installed in the system in passive mode.
It is your responsibility then to check the web firewall logs to see if these new patterns are interfering with your
web application. And if there are no false positives and there is no interference, you can set these new patterns to
active.


Encryption Key Settings

Encryption Key Settings
Key Value
WAF
Key Expiration
Time
The encryption key configured in the Barracuda Web Application Firewall is used for different purposes. For
example, if the cookie tamper-proof policy is set to encryption, all your cookies will be encrypted using this
encryption key.
The URL encryption feature also uses this feature.
So taking care of your encryption key is extremely important. Actually, an encryption key is made up of a value
with the actual encryption key and an expiration time.


Response Pages

Response Pages
Status Response Response

Code Headers Body WAF
Browser
Response Message
Error
Captcha
Access Control
Other
Pages
The Barracuda WAF has a collection of response pages that are already pre-configured. These response pages
are used when a security violation occurs and is denied.
Then, one of these response page is sent within the response. They are also used when responses should contain
captures or for authentication pages used by the access control module.
You can customize or configure additional pages in the system. Response pages are divided into different types.
There are pages for security violations. Capture pages are used for captures. Access Control pages are used for
authentication. And Other means that you can use this page in any module.

WAF02022 - JSON Security
WAF02041 – API Security

Introducing API Security
Welcome, my name is Christoph, and I am a technical trainer at Barracuda Campus. As the number of services
on the internet grow, they are also becoming more and more targeted by attackers. Most of these services use
an API to communicate with each other. However, these APIs can then be an attack vector for hackers, which
makes it very important to protect them with the Barracuda Web Application Firewall.

Agenda
• API Services
• API Discovery
• JSON Security
• GraphQL
• XML Firewall
• JWT Validation
• API Attack Actions
We will start with a very short introduction on API services,
since understanding how these services work is crucial for being able to protect them.
Then I will introduce you to the API Discovery features built into the WAF.
These features will help you protect your APIs with the Barracuda Web Application Firewall.
Then I will introduce you to the JSON Securtiy features provided.
Followed by an introduction on how you can protect your GraphQL APIs.
You can also protect XML firewalls.
Since access control is also very important for APIs, you can validate JSON web tokens with the WAF.
And by the end of this course, i will introduce you to the attack actions available for the APIs.


API Services

WAF02021 - XML Firewall
API Services
Software systems designed to support interoperable machine-
to-machine interaction over a network (W3C)
• JSON
• GraphQL
• XML
HTTP Request
Web
Service
Application A Application B
DB: Oracle HTTP Response DB: MSSQL
Linux + JAVA Windows + ASP
A web service as defined by the w3c is a software system designed to support interoperable machine-to-machine
interaction over a network.
The systems facilitate the sharing of information between two applications. Normally, it's not possible to directly
query information that is contained in a company database. Companies will typically protect such information
and allow you to access only specific parts. We have already seen this in web applications, but in a web
application world, the client is a web browser. Whereas in the web services world, the client is another
application. Let's assume, for example, that you have a website that will allow you to search for flights from other
sources. We’ll call this website application A. This website is created using a specific language and is hosted on a
specific operating system, and it’s using a specific database technology. When application A has to retrieve
information about flights from other applications, it has to know how to speak with these other applications.
Application B has the information that application A needs. Application B may be written using a different
language, or it might be hosted on a different operating system using a different database technology.
Nevertheless, application A is able to speak with application B using web services.
So the company that is running application B doesn't have to expose the database to application A. It just needs
to expose how application A can fetch the information from application B.

REST Services
REST => Representational State Transfer
XML
JSON
HTTP [any method] Request GraphQL
…
XML
Service Service
JSON
Requester HTTP Provider
GraphQL
… Response
There is a type of web services, which are called REST services.
REST stands for representational state transfer, and it needs a way to manipulate web resources using a
predefined set of stateless operations. Rest web services are also known as restful APIs.
There are several architectural constraints that define these web services, which are beyond the scope of this
course. REST web services might be using XML, JSON, GraphQL or other languages to transfer information
between the service requester and the service provider, and vice versa.
Moreover, HTTP is one of the protocols that can be used for rest web services. But in fact, you can use other
protocols to implement these web services and therefore you can use any supported method used in the HTTP
request. So we're not limited to the POST method like in a SOAP based services.

API Services
HTTP/S REST API
Tommy
Front-end Application Back-end Application
Attacker Payload
Another very common use for APIs today is the communication between the front end and back end of a web
application.
The user interacts only with front-end applications via a UI, But the front-end application fetches the data from
the back-end application via an API call.
This means that there are actually two targets for attackers. One being the front-end application, the other being
the back-end application through the front-end application. The attacker can, for example, inject malicious code
in the URL or use a malicious payload to attack the back-end application.

API Services
• Separate service for front end and back end
• Front-end application communicates with Service 2
Service 1 Front-end Application
Tommy WAF Service 2
Back-end Application
This means that you have to protect both the front-end application and the backend-application with the WAF.
The best way is to have one service protecting the front-end applciation, in our case service 1.
And a second service protecting the backend application.
In this case, the front-end application needs to be configured to communicate with Service 2 and not with the
back-end application directly.

API Security on the Barracuda WAF

1. SSL/TLS Security
2. API Message Security
3. Protocol Security
4. Access Control 5. Cloaking
API Server
Inbound Outbound
Inspection Inspection
WAF as API Proxy
As with regular services the WAF check in and Outbound traffic. These are the checks for inbound traffic:
As for every other request, the Barracuda WAF enforces SSL/TLS Securtiy.
But it can also perform security checks on the API message. For example, by checking for specific attack patterns,
but also by
enforcing limits on the content.
The integrity of the protocol being used.
And by using JWT, we can perform access control on the APIs.
For outbound traffic,

The WAF performs cloaking, so no information that might be used in an attack is delivered to clients.

JSON Security
Request
Tommy Application
Server
Response
If we take a look at the execution workflow, we will see that API security is applied after the other policies.
So, essentially, the Barracuda Web Application Firewall will use this module only after the HTTP request has
passed all the previous modules.
This ensures that the Barracuda Web Application Firewall will use its resources API security only for HTTP
requests that do not generate a violation in the previous modules.


API Discovery

API Discovery Wizard

• Upload API spec
– Swagger
– Open API • JSON Policy
– Google API • JSON Key Profiles
• Authentication and
Authorization
WAF
Administrator API Spec
There are two options to use API discovery, the first option which we are discussing first, comes with the WAF
license. If you are in posession of the API spec, you can simply upload into the WAF using the API Discovery
Wizard.
The supported formats are Swagger, Open API nd Google API.
Once uploaded the WAF will automatically create JSON Policies, JSON Key Profiles and setting for Authetication
and Authorization.

Endpoint Discovery
• Requires ABP license
• Automatically identifies API endpoints
– Review endpoints • JSON Policies
– Fine-tune parameter • JSON Key Profiles
• URL Profiles
• Header ACLs
• DDoS Prevention
WAF
Web Application Web Application
Configuring API security can be a challenging task, especially if you don‘t knwo the structure of the web
application you are protecting.
If you own the advanced bot protection license,
The Barracuda Web Application Firewall can automatically identify API endpoints by analyzing traffic. These can
be reviewed and if necessary, parameters can be fine tuned.
Now, if endpoint discovery is enabled, the Barracuda WAF learns from the access logs,
It not only learns the endpoints but is also able to automatically create JSON profiles, URL profiles, Header ACLs
from the analyzed traffic. Addionally, you can also turn on Application DDoS Prevention from the API Discovery
Wizard.


JSON Security
JSON is a very common data format that is used by many applications, including mobile applications, to
exchange data with the servers. JSON-based applications can be attacked in multiple ways. For example, by
sending improper data format or embedding attack vectors in the data. That's why it is important to validate the
JSON format before it's been processed. In this video, you’ll be learning how you can protect applications using
JSON with the Barracuda Web Application Firewall.

JSON REST API
HTTP [any method] Request JSON
Application JSON Application

HTTP Response
JSON rest API applications exchange information via any HTTP method. Depending on the method, the message
body contains a JSON payload or simply contains the request within the URL.
The other application will answer again using a HTTP response, that might or might not contain a JSON payload

JSON Security
• Ensures that attacks are not tunneled inside HTTP requests
with JSON content
• Easy Open API integration Requests blocked
– Upload API specs SQL injection in JSON data
{“firstname”: “tommy”, “lastname”: “ ‘ OR 1=1 -- “}

WAF
Attacker Application/JSON
Web Server
The Barracuda Web Application Firewall JSON security is a feature that performs deep inspection of incoming
packets and requests for web applications that use the JSON protocol to exchange data over HTTP.
This way attacks can be blocked before reaching the real servers.
It can also be easily integrated with open API, which allows you to upload your API specs to the WAF.

JSON Profile
• Enforces input validations and additional security checks
• Manual creation or generated from uploaded API specs
HTTP Request
Service
Application/JSON
JSON Profile
JSON Policy
WAF
Every time a service is created, a default JSON profile is automatically created by the system for that service. The
default profile configuration is applied to the whole URL space. However, you can create multiple JSON profiles
with different URL spaces within the service. The JSON profile will then perform input validation and security
checks.
In the JSON profile, you can specify the blocked attack types that the system should use when it is analyzing
JSON data.
You also have to associate a JSON policy to the JSON profile.
The profiles and the policies can either be generated manually or when you choose to upload the API specs to
the WAF, the WAF can automatically create the profiles and policies for you.

JSON Policy
{
“firstname”: “tommy”,
Max Keys “lastname”: “reed”,
“age”: 35 Max Number Value
“contacts”: [
“phoneNumbers”: [
{
"type": "office",
"number": “456 555-7897"
Max Tree Depth }, Max Array Elements
{
"type": "mobile",
"number": "123 456-7890"
}
],
“address”: { Max Value Length (string)
"streetAddress": “Lost street 23",
Max Siblings "city": “Campbell",
"state": “CA", Max Key Length
"postalCode": "10041-4100"
},
]
}
JSON File
A JSON policy is a collection of limits that JSON data must respect. These limits are used to validate the request
before it is processed any further. If an HTTP request contains JSON data that crosses one of these limits, then
the request is blocked. These limits include
the maximum keys that a JSON file can have,
the maximum value,
the maximum array element,
the tree depth,
and so on.

JSON Key Profile

{
“firstname”: “tommy”,
“lastname”: “reed”,
“age”: 35
Key Profiles
“contacts”: [
“phoneNumbers”: [ First Name
{ • key=firstname
"type": "office", • Type=string
"number": “456 555-7897"
},
• MaxLength=1024
{ • Class=Alpha
"type": "mobile", Age
"number": "123 456-7890" • key=age
} WAF • Type=number
],
“address”: { • MaxLength=2
"streetAddress": “Lost street 23", • Class=Integer
"city": “Campbell",
"state": “CA",
"postalCode": "10041-4100"
},
]
}
JSON File
For each key a JSON key profile can be crated.
These key profiles define the expected boundaries of the key values. Like in our example here:
For the key First Name, the profile contains the key name, which is firstname. We’re expecting a string value, that
can’t be longer then 1025 bytes and the expected character class is Alpha. So only letters will be allowed.
The age key is a number type. The lengths is two bytes but that also means that the maximum age would be 99
as the length for 100 and everything above would be 3 bytes. And the character class can only be integer, so
letter will not be allowed.
By narrowing down the possible content of the keys many attacks can be mitigated.


GraphQL

GraphQL
HTTP GET Request
HTTP POST Request JSON

Application Application
JSON
HTTP Response
GraphQL is an open-source data query and manipulation language for APIs that is served over HTTP.
GraphQL requests are either sent within URL paramters using the GET method,
or the POST method. In the second scenario, a JSON payload is delivered in the message body.

GraphQL vs REST API

REST API GraphQL
GET REQUEST GraphQL Query
REST JSON
REST JSON
The big advantage of GraphQL, as oppsed to other REST APIs, is that it allows you to query multiple resources
from a single endpoint, so clients can fetch only the information they are interested in.
For example, with a regular REST API request, you can only query a full element. Like in this example, with REST
API, you can only fetch the full information of user1.
With GraphQL, on the other hand, you can specifically query the first and the second name of that user.

Common Attacks
• Injection
– SWL and NoSWL injection
– OS command injection
– SSRF / request smuggling
• DoS
• Exposure of sensitive data
Although GraphQL lets you create flexible APIs, it involves complex configurations that may expose the
applications to various security vulnerabilities, such as injection attacks
like SWL and NoSWL injection, Operating System injection attacks, server-side request forgery, or request
smuggeling.
DoS Attacks are also quite common.
And as always, working with GraphQL can lead to an exposure of sensitive data.
And as always, the expose of sensitive data is a serious issue when working with GraphQL.

GraphQL Security
• Attack Signature checks

Requests blocked
• DoS Protection
• Size Limits SQL injection in JSON data
• Rate Limits
GraphQL WAF
Attacker
Web Server
To protect your GraphQL API,
the Barracuda WAF performs attack-signature checks, and also provides denial of service protection by enforcing
limits on the maximum query depth and on the file size of both the JSON payload and the complete request
payload.


XML Firewall

XML Web Services Vulnerabilities
<XML>
• Schema Poisoning
• XML Parameter Tampering
HTTP • Inadvertent XDoS
• External Entity Attack
• Processing Instructions Service Provider
Attacker
• ….
Due to their structure, XML web services are vulnerable to most of the same attacks as other web applications.
However, they also face additional vulnerabilities.
Some of these vulnerabilities are found in the SOAP schema, such as schema poisoning, , where the web
services schemas are manipulated to alter data that is processed by the application.
Other attacks will try to inject malicious scripts or content into XML parameters, or inject external entities in the
XML file to force an XML parser to get input from untrusted sources. There are also more traditional attacks like
an SQL injection attack hiding inside a SOAP message.
For these reasons, it is important that web services are protected in the same way as web applications are.

SOAP Web Services

SOAP => Simple Object Access Protocol
HTTP POST Request

XML
Service XML Service

Requester HTTP Response Provider
Both interactions between application A and application B are done using HTTP.
The interactions between applications can be done using different protocols. The SOAP or simple object access
protocol is one of them.
This protocol contains the specifications to exchange information in SOAP web services. The main features of
SOAP are neutrality and independence. You can literally run SOAP on almost any operating system, including
Windows and Linux. The language that SOAP uses to create its messages is XML.
XML is a markup language that defines how documents should be written. These documents will be both human
readable and machine readable. Due to its nature, this language is very easy and clear to understand. But that
also means that it is very easy for attackers to discriminate the data’s structure within an XML document.
Now how does a web service fetch information from a provider?
In particular, our web service requester, our client, will generate an HTTP post request to our web service
provider.
This request contains an XML file. The service provider will then answer with an HTTP response that also contains
an XML File. To understand each other, both services must follow certain specifications.

XML Firewall
Requests blocked External URI Reference Found
<XML>
<>…</> Service
HTTP
<user>http://hackerland.com</
user><>…</> XML Firewall Service
Attacker Provider
WAF
In our case, the Barracuda Web Application firewall has a special feature called an XML Firewall that is designed
to protect web services. The XML Firewall is designed to understand XML traffic and to also understand the
nature of SOAP services.
Multiple validation checks are performed on web service traffic before it is forwarded to the web service provider
and block the request if a violation is found.
These checks will not only look for attacks in the XML data, but they will also know how your web service works
by parsing the WSDL file or the schema file.

XML Firewall Configuration
Schema
Schema XML
<XML> Schemas Validations
http://bigfishinc.org/v1/service SOAP
Message
WSDL
WS-I
Service
Validations
http://bigfishinc.org/api/users/reg <XML>
SOAP
Validations
XML Firewall
WAF
The XML Firewall can be activated in the Barracuda Web Application Firewall only for HTTP and HTTPS web
services. You can use this feature to protect SOAP web services or just to parse XML data.
If you want to protect SOAP services, you must first upload the WSDL file associated with your web services. You
can also import the XML schemas associated with that web service. If you use both, just make sure that you first
upload all the XML schemas and then your WSDL files.
Then, you will need to tell the system what kind of validations you want to perform on this specific traffic. There
are three different types of adaptations: XML validations, WSI validations, and SOAP validations.
XML validations allow you to specify hard limits in your XML files and what kind content that can or cannot be
included in your XML file. Then we have the WSI validations. These are based on the WSI basic profile and allow
the Barracuda Web Application Firewall to perform the basic profile test during the runtime validation of SOAP
messages.
And finally, we have the SOAP validations, which address the SOAP message envelope headers and body.

XML Validations
<breakfast_menu>
<food category=“breakfast">
Max Tree Elements <name>Belgian Waffles</name>
<price>$5.95</price>
<description>Two of our famous Belgian
Waffles</description>
Max Tree Depth <calories>650</calories>
</food> Max Attribute Name Length
<food category=“breakfast">
<name>Strawberry Belgian Waffles</name>
<price>$7.95</price>
Max Element Name Length
<description>Light Belgian waffles</description>
<calories>900</calories>
</food>
</breakfast_menu>
With XML validations, you can set custom validation criteria for XML requests and responses. These are hard
limits that you can specify, for example,
for the maximum element,
the maximum tree depth,
name length ,
or maximum attribute name length,
etc. You can also filter out information that you do not want in your XML file, like processing instructions or
external entities.
However, the configuration of these settings is not done per service. So it is a global configuration that will be
applied to all your XML traffic.


JWT Validation

WAF01015 - Access Control
Web Token Validation

• Used for API authorization
– Token present in header
– WAF verfies JWT claims
• External or internal endpoints External Endpoint
WAF
Host: www.cudau.og
URL: /cgi-bin/badsore.cgi
API
JSON Web Token Profile
Internal Endpoint
JSON Web Tokens are a tool that allow you to validate JSON web tokens on your web applications API. To do
that the Barracuda WAF inserts a JSON web token into the header.
This token has to be presented to the browser in every follow-up request. Furthermore, the WAF verifies the
claims of the JWT, like the issuer, the expiry date and others.
For token validation, you can use external endpoints for authorization. In this case the WAF doesn‘t validate itself,
but rather communicates to the external authorization servers to validate if the requestor has the necessary
privileges.
If a persisting connection to the authorization server is not possible, you can use an internal endpoint. In this
case, the WAF validates the authorization. However, you will need to download the information like the public
key configuration, key ids, and public keys from the external endpoint and provide it to the WAF.
For specifying which part of the web app the JWT should be performed on, you can use a JSON Web Token
Profile.


API Attack Actions

API Attack Actions

• Attached to security policy
– Shared access security policies
• Response page should match application
– E.g., JSON response page
• Define follow-up action
– Use tarpit instead of CAPTCHA
Within the action policy, there are some attack actions that have been specifically created for APIs.
Since they belong to the action policy, they are shared across the services that use the same security policy. So
you should be aware that changing the attack actions might have an influence on multiple services.
Within the attack actions, you can define what kind of response should be sent to the client. This response must
be understood by the client. So it should be of the same kind as the application. For example, if your application
is a JSON application, the response page should be the JSON response page.
You can also set follow-up actions for attack actions. The same follow-up actions are available as within the rest
of the system, but be aware that you shouldn’t use CAPTCHA to challenge the clients because the client’s
communication with APIs are mostly services. So they won’t be able to answer them. You should use tarpits
instead.

WAF02039 - Web Application and CloudGen Firewall Integration
WAF02039 - Web Application and CloudGen Firewall

Integration
Barracuda CloudGen Firewall Integration
Welcome, my name is Christoph, and I am a technical trainer at Barracuda Campus.

In a typical situation, the Barracuda Web Application Firewall is normally deployed behind a network firewall. If it
is a Barracuda CloudGen Firewall, it can be integrated with the Barracuda WAF to block IPs for the WAF.

CloudGen Firewall Integration

Attack blocked
Action Policy – Block IP for 2 min
HTTP Requests
Attacker WAF
Firewall Web Servers
198.51.100.254
API
Offender IP 198.51.100.254
Traffic
Dropped
Due to its nature, the network firewall will not be able to block web application attacks. It will just forward the
traffic to the Barracuda WAF. On the other hand, as we have seen many times, The Barracuda Web Application
Firewall will block web application attacks.
You can also configure the Barracuda WAF to block the offending IP address for certain amount of time.
You can do this by using features like Allow Deny and Redirect rules or Global ACLs, or by changing the default
configuration of the action policies. When an attack is detected, the WAF will essentially drop the traffic and lock
the traffic if the service is set to active. For example, let's assume that the WAF detects a SQL injection in a
parameter. You can change the action policy for this specific violation and create a follow-up action that will
block the source IP address for a certain amount of time.
Let’s say, two minutes. From that moment on that the IP address will not be able to connect to our service. So,
essentially, the WAF filters the traffic like a network firewall.
After the timeout value has expired, our two minutes, the WAF will allow the IP address again to connect to our
services. If the Barracuda Web Application Firewall is deployed behind a Barracuda CloudGen Firewall, the
filtering of the traffic can be performed by the CloudGen Firewall.
The WAF still detects web application attacks and it will make the decision to block an IP address for a certain
amount of time. But instead of using its own resources, it delegates the blocking of that IP address to the
CloudGen Firewall.

Prerequisites
• CloudGen Firewall • Web Application Firewall
– Firmware 7.0+ – Firmware 9.0+
– Admin user for accessing the – Able to reach the CloudGen
REST API Firewall
– REST API engine configured and – Configured to use the
running CloudGen Firewall as upstream
– App Redirect rule to allow the firewall
WAF – Action Policies set to block IP
to access the REST engine as follow-up action
– Access rule with source
CustomExternalObject4 set to
block/drop
There are some prerequisites that must be met by both the CloduGen Firewall and the Web Application Firewall.
The CloudGen Firewall must run firmware 7.0 or above. An admin user for accessing the REST API engine must
be added to the system. The REST API engine itself must be configured and running. An app redirect rule is
needed to allow the WAF to access the CGF’s REST engine.
And finally, you have to pre-create the access rule that will block or drop the traffic. The source of this access
rule must contain the custom external object, which is an object that is reserved for the integration between the
CGF and the WAF.
The Web Application Firewall must run firmware 9.0 or above. It has to be able to reach the CloudGen Firewall. It
has to be configured to use the CGF as an upstream firewall. And, finally, you have to configure your action
policies to block the IP address as a follow-up action or any other feature that will allow you to use a follow-up
action. The follow-up action must be configured to block the IP address for a specific amount of time.

WAF02025 - Vulnerability Reports Integration

Introducing Vulnerability Reports Integration
The Barracuda Web Application Firewall can easily be integrated with web application vulnerability scanners.
This will allow you to easily identify and address web application vulnerabilities detected by the scanning tools.
You can import reports generated by these scanning tools into the Barracuda Web Application Firewall.
The WAF will then analyze the report and give you recommendations on how to address the vulnerabilities.

Vulnerability Scanners Integration

• Vulnerability Scanners detect and report vulnerabilities
• Vulnerabilities can then be mitigated by importing the
report
Scan
Report WAF
Scanner Web App
The Barracuda Web Application Firewall can easily be integrated with web application vulnerability scanners.
This will allow you to easily identify and address web application vulnerabilities detected by the scanning tools.
You can import reports generated by these scanning tools into the Barracuda Web Application Firewall.
The WAF will then analyze the report and give you recommendations on how to address the vulnerabilities.

Currently Supported Scanners

• Barracuda Vulnerability • IBM AppScan v9.0
Manager • ThreadFix
• Cenzic Hailstorm v6.6 • Immuniweb
• HPE Security WebInspect • Rapid 7
• HPE Security Fortify On
Demand
• IBM AppScan v7.9
The Barracuda Web Application Firewall supports a large number of vulnerability scanners.
The list includes the Barracuda Vulnerability Manager, Cenzic Hail Storm, HPE Web Inspect and Fortify On
Demand, IMB AppScan, Threat Fix, Immunity Web, and Rapid 7.
One thing to note about this list is that Threat Fix can be integrated with additional scanners such as Kinetics and
Quail. Essentially, you can run these scanners through Thread Fix Export. This report will be understood by the
Barracuda WAF.

New Open Format

Allows scanners to integrate with the BWAF
WAF
Vulnerability Scanners
Barracuda has created a new open format that allows scanners to integrate with the Barracuda Web Application
Firewall.
A company creating web application vulnerability scanners can easily follow the specifications of this format their
product.
It will then be automatically compatible with the Barracuda Web Application Firewall.

Vulnerability Reports
Assessment
XML Report Service

Vulnerability
Scanner
Security
Recommendations
When you create a report from your vulnerability scanner, you have to create an XML report. You can then easily
import this XML report into the WAF.
From the imported report, the WAF will create an assessment. You can have multiple assessments created in the
WAF.
Viewing an assessment will allow you to see all the vulnerabilities that a vulnerability scanner has found. If you
want to mitigate the vulnerability contained in an assessment, you have to assign a service to it.
After you assign a service to the assessment, you are ready to review your recommendations.

Recommendations
Recommendations
Pending Applied Rejected
By default, these recommendations are in a pending state.
That means that they are ready to be reviewed. You can then decide to apply the recommendation.
Once you do so, the system will change its configuration according to what it is suggested.
You can reject a recommendation.
In that case, the system will just record that you have rejected that specific suggestion.

WAF02026 - Barracuda Vulnerability Manager

Introducing Barracuda Vulnerability Manager
Configuring the Barracuda WAF can be overwhelming, which is why you can use the Barracuda Vulnerability
Manager to find attack vectors on you web application and then use reports to configure your Barracuda Web

Barracuda Vulnerability Manager

Free scanner
Scan
Admin
Barracuda Internet Web App
Report Vulnerability Manager
WAF
The Barracuda Vulnerability Manager is a free web application vulnerability management solution.
You can use this tool to automatically identify and mitigate web application security risks such as the OWASP top
10 vulnerabilities like SQL injections, cross-site scripting, cross-site request forgery, and other vulnerabilities.
The Barracuda Vulnerability Manager is a free, stand-alone product.
You can use this product to scan any web application that is available on the internet.
You can then evaluate the results of the scanner and change your code accordingly.
If the web application is protected by a Barracuda Web Application Firewall, you can export a report from the
Barracuda Vulnerability Manager.
The Barracuda WAF can then ingest this report and help you to mitigate these vulnerabilities.

The Scanner
Barracuda
Vulnerability Manager
Scanner
General Settings Crawler Authentication Exclusions
The configuration of the scanner of the Barracuda Vulnerability Manager is divided into 4 different parts. In the
general settings, you have to specify information, such as if you want to start the scan immediately, if you want to
schedule the scan, what the maximum length of a scan is, and so on.
In the crawler configuration, you have to specify how the system presents itself to the web application. So, for
example, what kind of user agent is used, and other limits like the requests per second, the maximum crawl depth
and so on.
In the authentication part, you have to configure all the settings needed for authentication in your web
application. Depending on the method that you use, you have to specify different information. You can use
different methods, such as HTTP basic authentication, HTTP digest authentication, or HTML form-based
authentication. All these different methods will have different settings that you need to specify in the scanner.
In the exclusions, you configure all the parts of the web application you don't want to include in this scan.

Reports
• Online reports are interactive
• Actions on issues can be tracked
Barracuda Report Admin

Vulnerability Manager
Once the scan has finished, you can view reports of the scan online.
These reports are very detailed and contain information on any vulnerability found. Reports can be exported as
PDF files, which makes them very useful for reporting. However, what makes them even more useful is that they
can be exported as XML files. These XML files can then be imported into the Barracuda Web Application Firewall.
As mentioned before, the WAF can give you recommendation on how to mitigate the vulnerabilities found.
Actions taken on the found vulnerabilities can be tracked.

WAF02027 - Barracuda Vulnerability Remediation Service

Introducing Barracuda Vulnerability Remediation Service
Welcome, my name is Christoph, and I am a technical trainer at Barracuda Campus. Configuring a web
application Firewall is a time-consuming task. But your work isn’t finished once the configuration is complete. Due
to changes to the web application and newly found vulnerabilities, it is an ongoing task. With the Barracuda
Vulnerability Remediation service, you can automize this process.

Barracuda Vulnerability Remediation Service

Enables automatic scanning, remediation, and maintenance of
web application policies.
Scan
WAF
Barracuda Internet Physical/Virtual/Cloud
Web App
Vulnerability Remediation
Service
WAF Configuration & Profiles
The Barracuda Vulnerability Remediation Service
allows you to scan your web application for vulnerabilities,
and when any are found, it will automatically reconfigure the Barracuda Web Application Firewall to mitigate
these vulnerabilities.
A scan can be run manually or scheduled over time. You might want to adjust the scan within the release circle
of your web applications.

WAF Configuration
Barracuda Barracuda Cloud

Vulnerability Remediation Control
Service
Configuration
WAF
Web App
In order to use the Barracuda Vulnerability Remediation Service, you first have to deploy your Barracuda Web
This can either be a physical appliance, a virtual machine, or a cloud instance. Then, you have to do an initial
configuration of the system and the service configuration.
The final step is to connect your Barracuda Web Application Firewall to the Barracuda Cloud Control.
Once this is done, you will be able to see your Barracuda Web Application Firewall in the Barracuda Vulnerability
Remediation Service scan settings.

Mitigation – Security Policy
Change the assigned policy Service

OR Security Policy
Create a new policy
Barracuda
Service WAF
You must first consider how you want to configure your security policies. You can let the service change the
policy that is currently assigned to your service.
This means that the policy would be irreversibly changed unless you have a template or you created a manual
copy of the policy before.
Or, you can ask the Barracuda Vulnerability Remediation Service to create a new policy for you.
In that case, the system creates a brand new policy for your service that would only change this new policy. You
can then easily revert back any changes by switching from the new policy to the previously in assigned policy.

Vulnerability Mitigation – Manual mode
Scan finished
Report generated
Mitigate SQL
Admin
in email field
Online Vulnerability Report
Barracuda
Service
Changing WAF Configuration
WAF
Web App
After the security policy settings, you have to choose how the Barracuda Vulnerability Remediation service will
mitigate any vulnerability found in your web application. There are three different ways that the system can act to
mitigate your vulnerabilities. You can use the manual mode, the passive mode or the active mode.
In manual mode, the administrator triggers the mitigation of a vulnerability manually.
After a scan is finished, the service generates an online vulnerability report.
In this report, you can choose which vulnerabilities you want to mitigate and also how the system should change
the WAF configuration.
You can decide to change the configuration and setting it to passive mode so you can review your logs before
enforcing the new configuration. Or, you can decide to activate a configuration immediately after its changed.

Vulnerability Mitigation – Passive Mode
Enforcing
Logs
Service (active)
Security Settings (active)
Users Traffic New Security

Settings (passive) Web App
WAF
Barracuda Scan Finished

Changing WAF Configuration
Service
Another vulnerability mitigation option is passive mode.

When you select passive mode, the Barracuda Vulnerability Remediation Service will automatically change the
WAF configuration after the scan is finished and vulnerabilities are found.
The new security settings will mitigate the found vulnerabilities, but they will be set in passive mode. This means
that any traffic that causes a security violation in these new settings will be allowed but will be logged in the web
firewall logs.
Using passive mode will allow you to have time to review the WAF logs. And then, if you're satisfied, you can
apply the new configuration.

Vulnerability Mitigation – Active Mode
Enforcing
Logs
Service (active)
New Security
Users Traffic
Settings (active) Web App
WAF
Barracuda Scan Finished

Service Changing WAF Configuration
The last vulnerability mitigation option is active mode. In active mode, the Barracuda Vulnerability Remediation
Service will automatically change the WAF configuration according to the vulnerabilities that were found after the
scan.
The new configuration will mitigate these vulnerabilities and enforce them immediately. This means that any
traffic that causes a security violation will be immediately blocked.
The violation will then be logged in the web firewall logs.

Notifications
Email
Barracuda
Admin
Service
You can be notified when the Barracuda Vulnerability Remediation service finishes the scan. This can be done
using an email message
or a SLACK notification.
If you choose to use the email message, you can specify multiple recipients in the web UI of this service. If you
choose to use SLACK, you have to make sure that you have an incoming webhook configured for your SLACK
channel.

The Scanner
Barracuda
Service
Scanner
General
Crawler Scan Elements Authentication Exclusions
Settings
The first thing that you configure in the scanner are the general settings. In the general settings, you specify
things like the maximum length of the scan and when it should run. If it is a manual scan or if it's a scheduled
scan, you have to configure the crawler. The crawler will allow you to specify the configuration regarding the user
agent: how deep you will want go with the scan, how many requests per seconds the system should perform,
and so on.
After the crawler, you have to select which elements the system should use when it's performing the scanning.
For example, you can tell the system to specifically search for SQL injection vulnerabilities, cross-site scripting
vulnerabilities, or any kind of vulnerabilities regarding your web server.
Then, the authentication part allows the scanner to authenticate with your web application. This also lets you
scan the parts of your web application that are behind the authentication module.
And finally, there are the exclusions. With exclusions, you remove from the scope any kind of host names or IP
addresses that the crawler has found or any patterns that are harmful to your web application.

Interference Prevention
Scan
Barracuda Network Firewall IDS/IPS

Internet WAF Web App
Service
Whitelist
Source IP Addresses
• 64.235.153.133
• 64.235.153.134
• 64.235.153.135
• 64.235.153.136
• 64.235.150.121
Before starting the scanner, you have to make sure that no security device between the Barracuda Vulnerability
Remediation Service and your web application interferes with the scan.
The list of source IP addresses that the Barracuda vulnerability Remediation Service will use is displayed on this
slide and it's also available on Campus.
Make sure that these IP addresses are allowed in your security devices, such as your network firewall, IDS, IPS,
or web application firewall.
If you are compliant with PCI DSS requirements and you're concerned about this procedure, please check the
latest version of the PCI DSS document.
Since the Barracuda Vulnerability Remediation Service is an approved scanning vendor, you have to make sure
that you have all the arrangements to allow the scan of your web application through your network.

Scan with WAF Bypass

• Scans web app without security checks of WAF
• VRS is set up as trused host
Service (active)
Scan
Trusted hosts
Service WAF
If your web application is protected by a Barracuda Web Application Firewall, the Barracuda Vulnerability
Remediation Service can automatically configure the Barracuda WAF to allow traffic from its source IP addresses
without the need of putting the service in passive mode.
The service will automatically create a new trusted hosts group that contains its IP addresses.
It will then automatically reconfigure the service to use this new trusted host group.

Scan without WAF Bypass

• Scans web app through WAF
– Checks security settings of WAF
Enforcing
Scan
Service (active)

Service WAF
On the other hand, if your intentions are to test the security settings of the Barracuda Web Application Firewall,
You can scan the web application without bypassing the web.
This will essentially keep the service in active mode, and no trusted host group will be created for the Barracuda
Vulnerability Remediation Service IP addresses.


VM and VRS Domain Verification
Welcome, my name is Christoph, and I am a technical trainer at Barracuda Campus.

Before you can use the Barracuda Vulnerability Manager or the Barracuda Vulnerability Remediation Service, you
must first verify that you are the owner of the domain you are about to scan. In this video, we will discuss how
you can verify your domain.

Domain Verification
Prevents unlawful scans on a web application (website)
without express permission from its owner or operator
TXT Record Email (preferred)
META Tag File

Barracuda
Service Manual Verification
Barracuda WAF
Verification Methods
The Barracuda Vulnerability Remediation Service ↓allows you to scan your web application for vulnerabilities,
and when any are found, it will automatically reconfigure the Barracuda Web Application Firewall to mitigate
these vulnerabilities. Domain verification prevents misuse of the Barracuda Vulnerability Scanner and
Remediation Serv ice.
It can be done using six different methods: using email, by copying the file into the root directory of a web server,
using txt records, creating a metatag in the DNS, by adding a page using the Barracuda Web Application
Firewall, or finally by using the manual verification method. All of these verification methods, exempt for the
verification through the WAF, are available for both the Vulnerability Manager and the Vulnerability Remediation
Service.
A scan can be run manually or scheduled over time. You might want to adjust the scan within the release circle
of your web applications.

Email Verification Method
Scan www.bigfishinc.org
Email
Barracuda
admin@bigfishinc.org
Admin
https://[verificationlink]
When using the email verification, the system will send an email message to an email address belonging to the
domain that you want to scan.
The recipient of this email message will then have to navigate to a verification link,
which is contained in the body of the message. Opening the link is sufficient for verifying the domain.

File Verification Method
Create xyz.txt with abc as content

Barracuda
Admin
GET http://www.bigfishinc.org/xyz.txt xyz.txt
Web Server
When using the file verification method, the system will give you a file name and a string that this file should
contain.
You then have to place the file in the root directory of your web server.
The system will then try to fetch the file using the domain that you have specified, along with the file name.
After that, it will compare the content of the file with the expected string. If the content matches, the domain will
be verified.

META Tag Verification Method
Add META Tag

Barracuda
Admin
<html>
<head>
<meta name: “bvm-site-verification content=“abcdefg”>
GET http://www.bigfishinc.org/index.html
~~~~~~~~
index.html
With the metatag verification method, you have to insert a metatag into the header of the default page of your
web application.
The information regarding the tag name and its content are specified in the web UI of the Barracuda
Vulnerability Remediation Service or the Vulnerability Manager.
The system will then get the default page of your web app and then search for the specific metatag and compare
the content of the tag with its expected string.
If the content matches, the domain will be verified.

TXT Record Verification Method
Add TXT Record

Barracuda
Admin
DNS
dig bigfishinc.org txt
bigfishinc.org |TXT| bmv-site-verification=abcdefg
When using the txt record verification method, you have to add a txt record in the DNS configuration for the
domain that you want to scan.
The information on the content of the txt record is found in the web UI.
The system performs a DNS query for this specific txt record. If the record is found and the content matches the
expected string, the domain will be verified.

Requesting a Manual Domain Verification

Email BVM_Support@barracuda.com or
VRS_Support@barracuda.com and include:
– Your Barracuda Cloud Control email address
– The domain(s) you want to scan
– An explanation of the ownership of the domain
You can also verify the domain manually. In this case, you have to send an email to the email addresses you can
see here. Be aware that there’s a different one for each service. In this email, you have to specify the email
address that you use to access Barracuda Cloud Control, the domains that you want to scan, and a brief
explanation regarding the ownership of this domain. After you've completed the settings for the domain
verification process, you are ready to continue with the configuration of the scan.

Barracuda WAF Verification Method

Vulnerability Remediation Service only
GET www.bigfishinc.org/[randomstring] Admin
Barracuda
Vulnerability Remediation WAF
Service
Internet
Access Logs
Check for [randomstring]
The final verification method is only available for the Barracuda Vulnerability Remediation Service.
In this scenario, you use the Barracuda Web Application Firewall linked to the Cloud Control to verify your
domain.
The Barracuda Vulnerability Remediation Service will then generate some traffic to your domain, adding a
random string to it.
It will then check the access logs of the Barracuda WAF for this random string. If the string is found and it
matches the expected content, the domain will be verified.

WAF02040 - Client Side Protection

Introducing Client Side Protection
Welcome, my name is Christoph and I am a technical trainer at Barracuda Networks. Most of the WAFs Features
are designed to protect your web application against attacks. But what if the attack is not directed towards your
web application but to your users? With Client Side Protection the WAF allows you to use known standards to
protect your users against attacks.
100
Content
• Why client-side protection?
• Content Security policy
• Sub-resource integrity
First, we are going to discuss why it is important to use client-side protection and what kind of attacks it protects
against.
And then we are going to take a look at the two standards the WAF uses to protect your users.
Content Policies
and Sub-resource Integrity .
101
WAF2040 – Client-Side Protection

Why Client-Side Protection?
So why is client-side protection important?
102

• Prevents XSS
• Prevents man-in-the-middle attacks
• Prevents supply-chain attacks
– Ensures third-party resources are not compromised
– Images
– JavaScript
– Stylesheets
Client-Side Protection is a shield against a large number of attacks that are directed against your users. These
attacks can be anything from
Cross-Site Scripting and injection attacks,
Man-in-the-middle attacks, like fiddler or Pinapple,
to malware distribution
and supply chain attacks. The WAF ensures that third-party resources such as images, JavaScript and Stylesheets
aren‘t compromised.
103
Third-party
open-
source
repository
Barracuda WAF
Browser
Web server
Ensuring the integrity of third-party resources is very important since you have no control over their security.
Imagine the third-party repository has a security breach and attackers are now able to alter the resources on
that repository.
Until the owner of that repository finds out that they have been hacked, attackers can use the repository however
they want to. They could, for example, inject a piece of code into the repository’s resources that mines bitcoins
for them. And since your web application is using these resources, that would mean that attackers would use
your application to further spread the mining to your users’ PCs.
Or they could perform cross-site scripting attacks on your users and steal their data.
The Barracuda WAF can mitigate these types of attacks by implementing two W3C standards to ensure the
integrity of the third-party resources used.
104

Content Security Policy
The first thing we are going to take a look at are content security policies.
105

• Inline script injection
• Referencing attacks
• Injection into dynamic script code generation
• Prevents attackers from injecting code into HTML/JS
– Read access to content
– Can create further HTTP requests and responses
– Forging and interacting with UI elements
– Run scripts in browsers
Content security policies prevent against inline script injection.
Referencing attacks can also be mitigated. In this case, attackers change the reference to a resource that is
controlled by them.
CSP also mitigates dynamic script injection.
And finally, it prevents attackers from injecting code directly into the code of your HTML and Java Scripts. This
also prevents them from accessing content, from creating requests and responses and malicious interaction with
the UI elements of you web application, as well as from running scripts in browsers.
106

• Defines allowed content and its sources
• Adds the Content Security Policy header
– Controls what browser is allowed to load
• Defines allowed sources
• Two modes
– Report only
– Block
So how does the content policy do that? By defining what kind of content you want to allow and from what
sources.
The WAF adds the Content-Security-Policy header to the HTML. This header controls what the browser is allowed
to load.
It also allows you to specify the sources of the content that you want to allow within your web application. This
prevents attackers from referencing attacks, for example.
On the WAF, you can use CSP in two modes. Report only, in which case the WAF will allow undefined sources
but will also create a report. This mode is preferred while setting up Content Security Policies in the WAF and
while testing. When the configuration is set up, you can then switch the CSP into block mode. From that moment
on, the WAF will start blocking sources that do not conform with your configuration.
107
CSP Example
Content = default-src 'self‘; campus.barracuda.com;
Directive Source Allowed Hosts
On this page you see an example of the CSP header’s content.
In this case the directive used is the default source. Which is also used as a fallback for undefined sources.
The allowed source is “self”. This means that the CSP allows sources from the same source origin of the HTML
document, for example, our own web server.
And at the end we see the allowed hosts.

As you can see, the header consists of three elements: the directive, the source and the allowed hosts.
108
CSP Directive
Default for all directives, e.g., JavaScript, CSS,
Default-src
AJAX, frames or HTML 5 media
Script-src Defines sources for JavaScript
Style-src Defines sources for Stylesheets
Defines sources for plugins, e.g., <object>,

Object-src
<embed> or <applet>
Report-uri URI to send reports
On this page you see some common directives that I will go over.
The Default-scr is the default source. This is the default for all directives such as JavaScript, Content Style Sheets,
Ajax, frames or HTML 5 media.
The Script-scr directive defines the sources we want to allow for JavaScript.
While Style-scr defines the sources we want to allow for our stylesheets.
The object-scr directive allows you to specify from which sources you want to allow plugins. So resources that
have the object, embed, or applet tag.
The report-uri directive specifies where reports about violations of any of the directives should be sent to.
109
CSP Sources
None Blocks content from all sources
All Allows content from all sources
Allows content from the same source as the origin,

Self
e.g., the web server
Allows loading of data sources,

Data
e.g., pictures, videos, files
Alllows usage of inline code like style attributes,

Unsave-Inline
eventhandler, and element-noted JavaScript
Unsave-eval Allows unsecure dynamic code
Here you see some of the sources that can be defined with the Barracuda Web Application Firewall.
None blocks content from all sources.
All allows content from all sources. For security reasons, you should avoid using this source because it would
render the CSP useless.
Self allows content from the same source as the HTML document. This could be the web server, for example.
The Data source specifies whether data such as pictures, videos, and files is allowed to load.
When the Unsave Inline attribute is used, the usage of inline code like style attributes, event handlers and
element-noted JavaScript are allowed.
And Unsave Eval allows the usage of unsecure dynamic code.
110

Sub-Resource Integrity
The second mechanism used by the WAF is sub-resource integrity.
111
Sub-Resource Integrity
Third party opensource
• Creates integrity token for third-party resources repositories
• JavaScript modules etc.
– Header inserted into response
– E.g., JS, CSS,… # sha256-PgrwROwuZhlsVg
• Browser verifies token

– Unverified resource does not load
Barracuda WAF
Browser
Web server
Sub-resource integrity is all about ensuring the integrity of resources of third parties you use on your web
application. These resources can be anything from media or style sheets to java script.
For each of the third-party resources you use, the WAF creates an integrity token or hash. The WAF then injects a
header including the hash into the HTTP response.
The browser can then compare the hash with the resource. This way, the browser is able to verify if the resource
has been altered.
If they don‘t match, the browser can prevent the resourced from loading.
These are the two standards the WAF uses for client-side protection.
112
Thank You
Thanks for watching!
113

WAF0201 - Barracuda Web Application Firewall - Advanced Features - Student Guide

Uploaded by

Document Information

Original Title

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

WAF0201 - Barracuda Web Application Firewall - Advanced Features - Student Guide

Uploaded by

Copyright:

Available Formats

Barracuda Web Application Firewall

WAF0201 - Barracuda Web Application Firewall – Advanced

Training Video Transcript

Barracuda Web Application Firewall

WAF02038 - Allow-Deny-Redirect Rules

Training Video Transcript

© Barracuda Networks Inc., Revision: 7/18/2022 3

Training Video Transcript

There are two types of rules that you can create.

© Barracuda Networks Inc., Revision: 7/18/2022 4

Training Video Transcript

© Barracuda Networks Inc., Revision: 7/18/2022 5

Allow/Deny Rules for Headers

Training Video Transcript

© Barracuda Networks Inc., Revision: 7/18/2022 6

WAF02019 - Website Profiles

Training Video Transcript

Welcome, my name is Christoph and I am a technical trainer at Barracuda Campus.

© Barracuda Networks Inc., Revision: 7/18/2022 7

Training Video Transcript

© Barracuda Networks Inc., Revision: 7/18/2022 8

Website Profiles Overview

URL Profile Parameter Profile

Training Video Transcript

© Barracuda Networks Inc., Revision: 7/18/2022 9

Website Profiles Modes

Training Video Transcript

© Barracuda Networks Inc., Revision: 7/18/2022 10

Website Profiles - Strict Profile Check

Training Video Transcript

© Barracuda Networks Inc., Revision: 7/18/2022 11

URL Profile Parameter Profile

Training Video Transcript

© Barracuda Networks Inc., Revision: 7/18/2022 12

Training Video Transcript

© Barracuda Networks Inc., Revision: 7/18/2022 13

WAF02020 - Application DDoS Protection

Training Video Transcript

© Barracuda Networks Inc., Revision: 7/18/2022 14

WAF Backend Servers

Training Video Transcript

© Barracuda Networks Inc., Revision: 7/18/2022 15

Slow Client Attack Prevention

Training Video Transcript

© Barracuda Networks Inc., Revision: 7/18/2022 16

Training Video Transcript

An alternative way is to evaluate the client. In this case,

© Barracuda Networks Inc., Revision: 7/18/2022 17

Tommy Web Application

Training Video Transcript

Speaking of CAPTCHA, as of the FW10,

© Barracuda Networks Inc., Revision: 7/18/2022 18

WAF02029 - Advanced System Management

Training Video Transcript

© Barracuda Networks Inc., Revision: 7/18/2022 19

Training Video Transcript

In this video you will learn about

You will also learn about default patterns,

the different encryption key seeting and

what response pages are.

© Barracuda Networks Inc., Revision: 7/18/2022 20

WAF02029 – Advanced System Management

Training Video Transcript