Configuring and Managing the Barracuda WAF solution with Puppet

Contents:

• Introduction


• About the Puppet module for Barracuda WAF


• Handling Dependencies on the Puppet Master


• Handling Dependencies on the Puppet Agent


• Additional Resources

Introduction

Automating the management of network devices is extremely crucial in agile environments and Puppet modules can be used build on the existing framework using the Puppet Device feature to provide support for administering the Barracuda WAF.



There is no need to install an agent on the WAF with this approach, and takes advantage of the Puppet Device subcommand that’s operated from a standalone Puppet Agent that communicates with the Barracuda WAF REST API v3.





Barracuda WAF can be configured to process traffic for a Web Application, block malicious traffic, Load balance backend servers etc, using this module.



Puppet bridges the gap between an UI driven management process and a script driven API invocation and provides some inherent benefits that are part of the Puppet Enterprise suite to the forefront for a barracuda WAF administrator.



This includes querying the WAF for custom facts using the Facter daemon, using the Puppet resource subcommand to query the WAF for a particular piece of configuration.



In this blog post, we will explain the process of installing the cudawaf module, configuring the connectivity and using Puppet manifests to manage the WAF.



The Puppet device subcommand is a feature in Puppet that allows managing devices that cannot install Puppet agents on themselves.



The following diagram shows the process of communication:

The WAF units are managed through intermediate proxies which are actually Agents connected to the Puppet Master.



The agent has the certificate for the WAF unit to be managed and authenticates on behalf of the WAF to apply the catalog rendered from the Puppet master.

About the Puppet module for Barracuda WAF

You may download the module using the following command:

“puppet  module install barracuda/cudawaf”

The default location for the module would be /etc/puppetlabs/code/environments/production/modules/

For installing the module in a specific environment, use the following command:

“puppet  module install barracuda/cudawaf –environment=<env name>”

You may also access the Barracuda Networks github account, to get the development release for the module. With this approach, please ensure that you rename the module upon downloading to “cudawaf”

Handling Dependencies

Handling dependencies is critical to work with the module. We need to install the dependencies on both the master and the agents before running the puppet commands.

Handling dependencies on the Puppet Master:

Install typhoeus v1.3.0 and rest-client v1.8.0

/opt/puppetlabs/bin/puppetserver  gem install typhoeus –v 1.3.0

/opt/puppetlabs/bin/puppetserver  gem install rest-client –v 1.8.0

Also, install the gems using the puppet agent gem binary:

/opt/puppetlabs/puppet/bin/gem  install typhoeus –v 1.3.0

/opt/puppetlabs/puppet/bin/gem  install rest-client –v 1.8.0

Changing the permissions for the gemspec files

In some cases, external dependencies can cause errors such as "Error in retreiving resource statement". Increasing read and execute permissions to the gemspec on the master can help solve this problem.

Default Location of the ‘gemspec’ files

/opt/puppetlabs/puppet/lib/ruby/gems/2.0.1/specifications

To change permissions:

chmod 777  rest-client-1.8.0.gemspec

chmod 777 typhoeus-1.* 

Please note: After you are changing permissions, please remember to restart the puppetserver daemon.

/opt/puppetlabs/bin/puppetserver  stop

/opt/puppetlabs/bin/puppetserver  start 
 

Handling dependencies on the Puppet agent:

The best way to handle these is to use the 'Package' resource and run the puppet agent command on the target node. Sample manifest of the Package resource:

  package { 'typhoeus' :

    ensure => present,

    provider => 'puppet_gem',

  }

    package { 'rest-client' :

    ensure => '1.8.0',

    provider => 'puppet_gem',

  }

This manifest can be uploaded to the manifests directory in the cudawaf module. Please note that this directory has to be manually created in the module. For example,

mkdir  /etc/puppetlabs/code/environments/production/modules/cudawaf/manifests/

Setting up the communication channel on the agent

To use the module, first configure a Puppet agent that is able to run puppet device. This agent will be used to act as a "proxy system" for the puppet device subcommand.

Create a ‘device.conf’ file on the Puppet Agent node:

The location of the file is:

/etc/puppetlabs/puppet/device.conf

device.conf is organized in INI-like sections, with one section per device: 

Example "device.conf" file

[waf-1]

   type cudawaf

   url http://admin:<password>@<ip_address>:8000/

The name of each section should be the name that will be used with Puppet device to access the device.



The body of the section should contain a type directive (use cudawaf) and a url directive (which should be an HTTP URL pointing to port 8000 to the device’s interface, typically the WAN interface).

WAF configuration manifest

                    cudawaf_service  { 'DemoService2':

                      ensure                               => present,

                      name              => 'MyService2',

                      type              => 'HTTP',

                      ip_address        => '10.11.2.2',

                      port              => 8000,

                      group             => 'default',

                      vsite             => 'default',

                      status            => 'On',

                      address_version   => 'IPv4',

                      comments          => 'Demo service',

                    }

        cudawaf_cloudcontrol  {  'CloudControl':

          ensure            => present,

          state             => 'not_connected',

          connect_mode      => 'cloud',

          username          => 'user@domain.com',

          password          => 'password' 

        }

        cudawaf_rule_group {  'RuleGroup-1':

          ensure            => present,

          name              => 'ContentRule1',

          service_name      => 'MyService2',

          url_match         => '/testing.html',

          host_match        => 'www.example.com' 

        }

        cudawaf_rule_group_server  { 'RuleGroupServer-1':

          ensure        => absent,

          name          => 'rgServer1',

          service_name  => 'MyService2',

          rule_group_name => 'ContentRule1',

          identifier    => 'Hostname',

          hostname      => 'barracuda.com' 

        }

 

With this manifest, a service with the name “Myservice2” will be created on the WAF under which there will be a content rule called “ContentRule1” and a backend server for the content rule called “rgServer1”. The WAF is also connected to the Barracuda Cloud Control for the administrator to use other additional cloud services available on the BCC portal.

You may visit the WAF documentation website, campus.barracuda.com for more information on each of these configuration items.

Command to run puppet device

puppet device -v --user=root

At this point, you may login to the Barracuda WAF web interface to verify if the configuration has been updated as per the manifest.

You may also reach out to our team for any concerns regarding this module by sending an email to puppet_support@barracuda.com

Additional resources

https://github.com/barracudanetworks/barracuda-cudawaf

https://forge.puppet.com/barracuda/cudawaf

https://campus.barracuda.com