Securing the Barracuda Web Security Gateway

1. Overview ...... 3 1.1 Release Notes ...... 4 1.1.1 Barracuda Web Security Gateway Web Application Definitions Release Notes ...... 17 1.2 Deployment Options ...... 18 1.2.1 Inline Pass-Through (Transparent) Mode Deployment ...... 19 1.2.2 Forward Proxy Deployment of the Barracuda Web Security Gateway ...... 21 1.2.3 High Availability - Clustering the Barracuda Web Security Gateway ...... 23 1.2.3.1 Linked Management Versus Barracuda Cloud Control ...... 25 1.2.4 Inline Pass-through With Pre-existing Proxy Deployment ...... 27 1.2.5 Connecting Inline to your Network with a Pre-existing Proxy Server ...... 28 1.2.6 Deploying the Barracuda Web Security Gateway with a Peer Proxy ...... 30 1.2.7 Policy-Based Routing ...... 31 1.2.8 Source-Based Routing ...... 35 1.2.9 Dual Bridge Deployment 7.0 ...... 36 1.2.10 VLAN Deployments ...... 37 1.2.11 Virtual Deployment ...... 40 1.2.11.1 How to Deploy Barracuda Web Security Gateway Vx Images ...... 41 1.2.11.2 Allocating Cores, RAM, and Hard Disk Space for Your Barracuda Web Security Gateway Vx ...... 44 1.2.11.3 Barracuda Web Security Gateway Vx Quick Start Guide ...... 46 1.2.11.4 Directing Traffic to the Barracuda Web Security Gateway Vx ...... 48 1.2.11.5 Backing Up Your Virtual Machine System State ...... 49 1.2.12 WCCP Deployment ...... 50 1.2.12.1 WCCP Deployment With the Cisco ASA ...... 54 1.2.13 Proxying Web Traffic Using a PAC File ...... 56 1.2.14 Filtering Traffic for Offsite and Mobile Users ...... 58 1.2.14.1 Release Notes - Barracuda Web Security Agent for Macintosh ...... 59 1.2.14.2 Release Notes - Barracuda Web Security Agent for Windows ...... 61 1.2.14.3 Barracuda Safe Browser Setup Guide - With Barracuda Web Security Gateway ...... 65 1.2.14.4 How to Get and Configure the Barracuda Chromebook Security Extension ...... 67 1.2.14.5 How to Troubleshoot the Barracuda Chromebook Security Extension ...... 76 1.2.15 How to Load Balance Barracuda Web Security Gateway With the Barracuda Load Balancer ADC ...... 78 1.2.16 How to Configure a Transparent Redirection from a Barracuda NextGen Firewall F-Series ...... 79 1.3 Getting Started ...... 84 1.3.1 Step 1 - Network Considerations ...... 85 1.3.1.1 Using Static Routes ...... 87 1.3.2 Step 2 - Installation ...... 88 1.3.3 Step 3 - Configure the Barracuda Web Security Gateway ...... 91 1.3.4 Step 4 - Configure and Secure the Web Interface ...... 94 1.3.5 Step 5 - Connect the Barracuda Web Security Gateway to Your Network ...... 96 1.3.6 Barracuda Web Security Gateway 30 Day Evaluation Guide ...... 98 1.4 Securing the Barracuda Web Security Gateway ...... 100 1.5 Managing Policies ...... 101 1.5.1 Best Practices in Configuring Policy ...... 102 1.5.2 BLOCK/ACCEPT Order of Precedence - Barracuda Web Security Gateway ...... 105 1.5.3 Block Messages ...... 106 1.5.4 Block Pages, SSL Inspection and HTTPS Filtering ...... 108 1.5.5 Using Custom Categories ...... 109 1.5.6 Typosquatting Protection ...... 110 1.5.7 Web and Desktop Application Control ...... 112 1.5.8 How to Configure Web Application Monitoring version 6.x - 7.x ...... 114 1.5.9 Exception Policies Version 7 and Above ...... 117 1.5.10 Policy Rule Checking ...... 120 1.5.11 Barracuda Web Security Gateway for Education ...... 121 1.5.11.1 How to Configure Dropbox Business Support ...... 123 1.5.12 How to Restrict YouTube Content On Your Network ...... 124 1.5.13 How to Enable Safe Search ...... 126 1.5.14 Suspicious Keyword Tracking ...... 127 1.5.15 Temporary Access for Education ...... 129 1.5.16 How to Use Temporary Access for Students - Teacher's Guide ...... 135 1.5.17 Captive Portal Terms and Conditions Page ...... 140 1.5.18 Creating Block and Accept Policies ...... 141 1.5.19 How to Disable Auto-Complete for Popular Search Engines ...... 144 1.6 Encrypted Traffic Filtering With the Barracuda Web Security Gateway ...... 145 1.6.1 Using SSL Inspection With the Barracuda Web Security Gateway ...... 146 1.6.1.1 How to Configure SSL Inspection Version 12 and Above ...... 148 1.6.1.2 How to Configure SSL Inspection Version 10 and Above ...... 151 1.6.1.3 SSL Accelerator Hardware ...... 154 1.6.1.4 How to Configure SSL Inspection Version 8.1 to 9.1 ...... 155 1.6.1.5 How to Configure SSL Inspection Version 7.1 ...... 158 1.6.1.6 How to Configure SSL Inspection 7.0 ...... 160 1.6.1.7 How to Configure SSL Inspection for Google Chrome Browser ...... 161 1.6.1.8 How to Create and Install a Self-Signed Certificate for SSL Inspection ...... 162 1.6.1.9 How to Use the Barracuda Default Certificate for SSL Inspection ...... 163 1.6.1.10 Client-side SSL inspection for Mac OS X ...... 165 1.6.1.11 Barracuda Web Security Gateway Update for SSL Inspection Certificate Handling ...... 166 1.6.1.12 SSL Inspection With the Barracuda Web Security Agent ...... 167 1.6.1.13 Facebook Control Over HTTPS ...... 168 1.6.1.14 Client-side SSL inspection for Windows ...... 171 1.6.2 Google Restrictions With SSL Inspection ...... 172 1.6.2.1 G Suite Control Over HTTPS ...... 174 1.6.2.2 YouTube Control Over HTTPS Version 7.x and Above ...... 177 1.6.3 HTTPS Filtering With the Barracuda Web Security Gateway ...... 179 1.6.4 How to Allow a Specific Video on YouTube ...... 180 1.6.5 How to Configure Web Application Monitoring Version 8.x and Above ...... 182 1.6.6 SSL Certificates Explained ...... 185 1.7 Managing Users and Groups ...... 186 1.7.1 Creating Users and Groups ...... 187 1.7.2 How to Choose Your Authentication Mechanisms ...... 189 1.7.2.1 How to Configure Google Directory Services ...... 190 1.7.2.2 How to Configure Kerberos Authentication ...... 192 1.7.2.3 How to Enable LDAP Domain User Authentication ...... 194 1.7.2.4 How to Enable NTLM Domain User Authentication ...... 195 1.7.3 How to Integrate the Barracuda Web Security Gateway With a User Authentication Service ...... 197 1.7.4 How to Configure Proxy Authentication ...... 198 1.7.5 About the Barracuda DC Agent ...... 199 1.7.5.1 How to Get and Configure the Barracuda DC Agent ...... 200 1.7.5.2 Using the Barracuda DC Agent With Microsoft Network Policy Server ...... 204 1.7.5.3 How to Uninstall or Update the Barracuda DC Agent ...... 205 1.7.6 Role-based Administration Version 7 and Above ...... 206 1.7.7 Wireless Access Point Integration With the Barracuda Web Security Gateway ...... 208 1.7.7.1 How to Integrate the Aerohive Wireless AP With the Barracuda Web Security Gateway ...... 209 1.7.7.2 How to Integrate the Meru Wireless AP With the Barracuda Web Security Gateway ...... 211 1.7.7.3 How to Integrate the Ruckus Wireless AP With the Barracuda Web Security Gateway ...... 212 1.8 Advanced Configuration ...... 213 1.8.1 Advanced Threat Protection Configuration ...... 214 1.9 Monitoring the System ...... 215 1.9.1 Basic Monitoring Tools ...... 216 1.9.1.1 Audit Log of Configuration Changes ...... 219 1.9.1.2 How to Customize the Dashboard Page ...... 220 1.9.1.3 How to Use the Barracuda Malware Removal Tool ...... 221 1.9.2 How to Size the Barracuda Web Filter For Your Network ...... 222 1.9.3 Reporting With the Barracuda Web Security Gateway Version 11 and Above ...... 224 1.9.4 Reporting with the Barracuda Reporting Server ...... 226 1.9.4.1 Migrating Reports to the Barracuda Reporting Server ...... 228 1.9.5 Reporting Version 7 and Above ...... 229 1.9.6 How to Set Up Alerts and SNMP Monitoring ...... 231 1.9.6.1 Barracuda Reference MIB ...... 232 1.9.6.2 Barracuda Web Security Gateway SNMP MIB ...... 233 1.9.7 How to Set Up Barracuda Cloud Control ...... 240 1.9.8 Syslog and the Barracuda Web Security Gateway ...... 241 1.9.8.1 Accepted Syslog Formats From Wireless APs ...... 246 1.9.9 Barracuda Web Security Gateway API Guide ...... 247 1.9.10 Troubleshooting ...... 261 1.10 Maintenance ...... 263 1.10.1 How to Back Up and Restore Your System Configuration ...... 264 1.10.1.1 Restoring a Backup to Version 6.0 or Above From Early Versions ...... 265 1.11 Web Use Categories ...... 266 1.12 About the Barracuda Web Security Gateway Hardware ...... 271 Barracuda Web Security Gateway Administrator's Guide - Page 3

Overview

The Barracuda Web Security Gateway is an integrated content filtering, application blocking and malware protection solution that is powerful, easy to use and affordable for businesses and educational institutions of all sizes. It enforces Internet usage policies on and off network by blocking access to websites and Internet applications that are not related to business or education, and it easily and completely eliminates spyware and other forms of malware from your organization. Unlimited remote user licenses are included to enforce content and access policies for mobile devices outside of the corporate network.

Where to Start

You can deploy the Barracuda Web Security Gateway inline with your core network components or you can deploy the system as a forward proxy. Refer to Deployment Options for more information.

Device Deployment on-premises

Supports all Barracuda Web Security Gateway features, and is the only solution that supports inline deployment. With inline deployment, you can filter web-based and non-web based application traffic (e.g. Facebook, Twitter, Skype, BitTorrent, etc.) as well as HTTP/HTTPS traffic.

Barracuda Web Security Gateway Quick Start Guide – Download a copy of the Barracuda Web Security Gateway Quick Start Guide t hat was packed with your appliance. Getting Started – Detailed installation and configuration steps. The 30 Day Evaluation Process – A roadmap for your product evaluation (optional). Managing Policies – Best practices, precedence of block/accept policies, authentication schemes.

Virtual Deployment

Supports only Forward Proxy deployment, which does not support filtering web-based or non-web based application traffic (e.g. Facebook, Twitter, Skype, BitTorrent, etc.); Forward Proxy configuration only supports filtering of HTTP/HTTPS traffic.

Barracuda Web Security Gateway Vx Virtual Deployment The 30 Day Evaluation Process – A roadmap for your product evaluation (optional). Managing Policies – Best practices, precedence of block/accept policies, authentication schemes.

Key Features

Regulates web application activity, including G Suite Granular, user-aware policies Monitor and archive social-network messages (Barracuda Message Archiver required for archival of alert messages) Content filtering, with HTTP/HTTPS support and URL filtering by category for various types of users and groups. Simplifies CIPA compliance for schools. Comprehensive network threat protection. Cloud based URL lookup utilizing Barracuda’s Web Categorization Service (WCS), featuring dynamic page scanning and classification. SSL Inspection of HTTPS traffic with the model 410 and higher, running version 7.1.0 and higher. See Using SSL Inspection With the Barracuda Web Security Gateway for system requirements. LDAP integration, Single Sign-on user authentication – See How to Choose Your Authentication Mechanisms.

Safe Browsing for Schools and Remote Users

Barracuda Web Security Gateway for Education – A suite of features to regulate use of social media applications, provide alerts on cyberbullying and to provide safe browsing and content delivery for the classroom Filtering Traffic for Offsite and Mobile Users – A policy enforcement solution for BYOD, campus-issued laptops, Chromebooks and iOS devices

Release Notes

Important: Please Read Before Upgrading Make a backup first. Before installing any firmware version, back up your configuration and read all release notes that apply to versions more recent than the one currently running on your system.

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

Upgrading to or reverting from Version 12.x When reverting from version 12.0 to version 11.0, if you are using the Barracuda Chromebook Security Extension, the configuration file created on the Chromebook Extension tab of the ADVANCED > Remote Filtering page needs to be re-uploaded to the Google Admin console.

When upgrading a Barracuda Web Security Gateway to version 11.0 or higher, please note the following:

For the Barracuda Web Security Gateway Vx, make sure the virtual machine has 4GB of RAM or more BEFORE upgrading. See also Allocating Cores, RAM, and Hard Disk Space for Your Barracuda Web Security Gateway Vx. The virus checking feature as configured on the BASIC > Virus Checking page now offers blocking files based on file type, no t just MIME type as in previous versions. Barracuda recommends that the admin select file types to block with virus checking and/or ATP on that page after upgrading. If you are using NTLM authentication, you now need to specify a Realm, which is your Windows administrative domain name. The default setting after upgrade is the Default Domain you configure for the Barracuda Web Security Gateway on the BASIC > Administration page. To change this default value, configure on the USERS/GROUPS > Authentication page on the NTL M tab.

Only backups from version 7.1 and higher are accepted by version 9.0 and higher. If you have a backup from version 7.0.x or earlier, please contact Barracuda Technical Support for assistance.

Firmware Version 12.0 (Early Release)

What's New in Version 12.0

Policies Dropbox Web Application Support - Added support for Dropbox for business. Configure on the BLOCK/ACCEPT -> Web App Control page. HotSpot Shield & Anonymous proxy protection - Configure on the BLOCK/ACCEPT -> Web App Control page. Typosquatting Protection - Typosquatting relies on mistakes like typographical errors made by web users when typing a URL or clicking on a misspelled website address in the browser. This feature checks for common typos in a clicked or manually typed URL domain name. When a common typo is discovered, the service redirects the user to a web page indicating that this might not be the legitimate site they intended to access, and provides the correct URL. Includes Dashboard statistics. Configure on the BLOCK/ACCEPT > Configuration page. SSL Inspection Simplified configuration on the ADVANCED > SSL Inspection page. No need to specify Transparent or Proxy mode. SSL Inspection certificate wizard simplifies selection, creation and upload of SSL certificates. Options to exempt domains from inspection, inspect traffic from specific networks, and inspect traffic for specific users/groups. Restriction on number of domains that can be inspected on lower models is removed. ECDSA keys are now accepted for uploaded root certificates. Configure on the ADVANCED > SSL Inspection page. Barracuda Chromebook Security Extension Added Google admin LDAP service support. Provides the ability to associate Google Directory Service users and groups to your organization's local Active Directory. Supports lookup Google Directory Service on Reports, Exceptions, SSL Inspection page, and Temporary Access. Configure on the USERS/GROUPS > Authentication page. Support for Temporary Access feature. Support for time-based policies. Virus Scanning Advanced Threat Protection (ATP) enhancements - New statistics display on BASIC > Dashboard page as well as local caching of results. Improved speed of detection and block rate for subsequent downloads of infected files in the network. Miscellaneous Application log now includes Username and Destination IP address.

Fixed in Version 12.0

If session parameters are changed, logged off users appear as offline as expected on the USERS/GROUPS > Account View page.

[BNYF-12777] When the SSL Inspection feature is set to Off, Dashboard performance statistics display as expected. [BNYF-12741] Null SMB password vulnerability (CVE-1999-0519). [BNYF-12771] Suspicious keywords are reported in email alerts as expected. [BNYF-12437] Empty suspicious keyword alert emails are no longer sent at the end of an hour when a user searches for non-suspicious keywords. [BNYF-12535] Checking Hide Custom Categories from reports on the BASIC > Reports page works as expected for the Web Requests Log report. [BNYF-12528]

Version 12.0.0.010

The secure administration certificate is regenerated when upgrading to version 12.0.0.008. If you are using the Barracuda Chromebook Security Extension, you will need to update the certificate in Chromebook browsers. See the ADVANCED > Secure Administration pag e. [BNYF-13207] Chrome browser version 58 does not support matching the Common Name in certificates. Certificates that rely on this deprecated behavior will now be rejected with: ERR_CERT_COMMON_NAME_INVALID. To avoid this issue, the administrator must re-generate the certificate to include a Subject Alternative Name extension, or to enable an option in Chrome to allow them. [BNYF-13168] NTLM join domain is successful with authentication. [BNYF-13181] Added Microsoft Edge browser for Windows 10 to the Applications to Filter (All Ports) defaults on the Web Security Agent tab of the ADVANCED > Remote Filtering page for Barracuda WSA. [BNYF-10285] Policy Alerts are sent as expected when a delegated admin email address is specified in the Policy Alerts Email Address field on the B LOCK/ACCEPT > Exceptions page. [BNYF-12926] Blocked Encrypted Archives are displayed in the Web Log as 'Encrypted Archive', not 'Virus Download'. [BNYF-13128] Added for Barracuda Web Security Gateway 410Vx - simplified configuration on the ADVANCED > SSL Inspection page. No need to specify Transparent or Proxy mode. [BNYF-13177]

Firmware Version 11.0

What's New in Version 11.0

Virus Scanning Advanced Threat Protection (Available on 310 and higher) - Advanced Threat Protection (ATP) is a subscription-based service that detects and blocks advanced malware, zero-day exploits, and targeted attacks that are not detected by the Barracuda Web Security Gateway virus scanning features. The ATP service includes sandboxing capabilities and analyzes web traffic for viruses in a separate, secured cloud environment. Configure on the BASIC > Virus Checking page after subscribing. For more information, see Advanced Threat Protection Configuration. To subscribe, see the Subscription Status section of the BASIC > Dashboard page. Configure Scanning by file type - Ability to configure virus scanning by file types rather than MIME types on the BASIC > Virus Checking page. You can also configure virus scanning by MIME types if desired. This feature applies both to the Barracuda Web Security Gateway virus scanning feature as well as the subscription-based ATP scanning feature. When upgrading to version 11.0, selected MIME types will be migrated to corresponding file types. Similarly disabled MIME types will result in corresponding file types disabled after the upgrade. Chromebook Support Barracuda Chromebook Security Extension - Barracuda Chromebook Security Extension is installed as a browser extension for Chromebooks to enforce web browsing policies you configure on the Barracuda Web Security Gateway. The extension supports SSL inspection on Chromebooks and filters all web traffic for authenticated Chromebook users. Browsing policies you configure on the Barracuda Web Security Gateway are applied by the extension to this web traffic. As of this early release, the Barracuda Chromebook Security Extension is available from the Google App Store at no cost and is configured in the Google Admin console. For more information, see How to Get and Configure the Barracuda Chromebook Security Extension. Reporting Barracuda Reporting Server integration - The Barracuda Reporting Server is a hardware appliance that offers a faster, more accurate reporting option that can integrate with the Barracuda Web Security Gateway. This integration offloads reporting resources from the Barracuda Web Security Gateway, resulting in improved web filtering performance. The Barracuda Reporting Server can also provide an aggregate view of data for customers with multiple Barracuda Web Security Gateways. For more information, see Barracuda Reporting Server - Overview. SNI Support Ability to detect SNI and to use that in the clientHello message sent to the server. This reduces disconnections from servers such as Amazon Web Services which require SNI to be able to serve the correct certificate. SNI detection prevents the need to contact the server to see its certificate. Clients whose browsers do not implement SNI are presented with a default certificate and hence are likely to receive certificate warnings. SSL Inspection SSL acceleration hardware - New support for SSL hardware accelerator included in specific appliance models. For more information about supported models, see SSL Accelerator Hardware. Exempted Domains - Optionally add any domains you want to bypass SSL Inspection. For example, if you have enabled any of the Safe Search categories in the Safe Browsing section of the BLOCK/ACCEPT > Content Filter page, you might want to exempt one or more domains. There is no limit to the number of domains that you can exempt from SSL Inspection, and there is

no impact on system performance. Remote Filtering Client-side SSL inspection with the WSA for Mac - The Barracuda Web Security Agent (WSA) for Mac can provide client-side SSL Inspection directly on the client computer, offloading resource-intensive processing from the Barracuda Web Security Gateway. This configuration is highly scalable in terms of number of users, consuming fewer resources on the Barracuda Web Security Gateway and improving system performance. For more information, see Client-side SSL inspection for Mac OS X. Authentication mechanism supporting multiple certificates for Barracuda Web Security Agent - For web browsing scenarios where remote Mac users may connect to the Barracuda Web Security Gateway over possibly hostile networks, such as an unencrypted conference or other public WiFi. Create self-signed or upload trusted certificates on the ADVANCED > Remote Filtering page and configure the Barracuda WSA on each Mac with the certificate hash. This secure authentication mechanism enables the Barracuda WSA to verify the identity of the Barracuda Web Security Gateway and ensure that administrative traffic is encrypted and secure. Includes ability to store and manage multiple certificates on the Barracuda Web Security Gateway to provide for seamless transition from an expiring certificate to a new one. See Authentication with the Barracuda Web Security Gateway and the Barracuda WSA for details. Miscellaneous Syslog Support for W3C format - Support for sending system logs to the external syslog server in W3C extended Log file format. Configure on the ADVANCED > Syslog page. The Google Apps Regulations section of the BLOCK/ACCEPT > Configuration page has been removed since YouTube For Schools was discontinued in July, 2016. The YouTube for Schools setting in the BLOCK/ACCEPT > Content Filter page has also been removed for the same reason. To restrict YouTube content, see How to Restrict YouTube Content On Your Network. SMTP Authentication support - If your SMTP server requires authentication, and you configure email notifications (alerts) on the BASIC > Administration page, you can enter the Username and Password required by your SMTP server.

Fixed in Version 11.0

Web Interface The configured external backup server shows as expected in the web interface. [BNYF-8188] The BASIC > Dashboard page renders properly when changing the Language drop-drown to Francais / French. [BNYF-8226] The Spyportal redirect message and suspicious keyword alert notification each show the correct System Name of Barracuda Web Security Gateway if the System Name default value on the ADVANCED > Appearance Page was never changed. [BNYF-8757] Syslog Large syslog traffic/data from Access Point does not stall processing. [BNYF-10592] Security High severity vulnerability: unauthenticated, denial of service (DoS) [BNSEC-296 / BNYF-8892] High severity vulnerability: persistent XSS, authenticated [BNSEC-261 / BNYF-6117] Medium severity vulnerability: information disclosure, insufficient authorization [BNSEC-4230 / BNYF-8596] Medium severity vulnerability: persistent XSS, authenticated [BNSEC-1738 / BNYF-7331]

Version 11.0.0.024

Possible high system load that was related to automated daily refresh of the BASIC > Dashboard statistic reports is no longer an issue. [BNYF-13102] Chrome browser version 58 does not support matching the Common Name in certificates. Certificates that rely on this deprecated behavior will now be rejected with: ERR_CERT_COMMON_NAME_INVALID. To avoid this issue, the administrator must re-generate the certificate to include a Subject Alternative Name extension, or to enable an option in Chrome to allow them. [BNYF-13168] * Fixed separately in Version 12.0

Version 11.0.0.022

The ADVANCED > Remote Filtering page does not give a Temporarily Unavailable 500 error. [BNYF-12825] Suspicious Keywords reports do not show "no data available" if no email address is configured for Sensitive Keywords Alert Email Address. [BNYF-12762] For the Barracuda Web Security Agent, the Source IP Address and Username in the Web Log page display correctly when accessing HTTPS sites in non-PLO mode. [BNYF-11937] CA bundle update. [BNYF-11091] The Match Any search term exception works as expected. [BNYF-12759] Advanced Threat Protection (ATP) continues functioning as expected when idle for more than 24 hours. [BNYF-12896] The cache manager is accessible to LAN hosts. [BNYF-13016] New proxy version disables the ACL related to X-forwarded For by default. [BNYF-12979]

Version 11.0.0.019

On the Barracuda Web Security Gateway 1010/11, after firmware update to 11.0, Barracuda Web Security Gateway always responds to ping and passes traffic if Hard Bypass is enabled. [BNYF-12616] When secure block page is enabled, policy look-up for the Barracuda WSA in PLO mode works as expected. [BNYF-12630] On the BASIC > ATP Log page, the Scan Completed column displays the correct timestamp for Error Status log entries. [BNYF-12640]

Version 11.0.0.016

When SSL Inspection is enabled, domains contained in *.google.com.hk are now included in alternative names for google.com, avoiding errors when browsing. [BNYF-12002] Host verification from an inline client succeeds when the port is included with the domain in the verification command. [BNYF-12343] Resolved ICAP protocol errors caused by lack of enough ICAP servers.[BNYF-12409] Client IP addresses added in the Proxy Authentication Exemptions section of the ADVANCED > Proxy page are exempt as expected for basic authentication. [BNYF-12103] When one Barracuda Web Security Gateway is configured to act as a reporting server for another Barracuda Web Security Gateway, the reporting server now shows logged events for browsing spyware sites, just as the other system does. [BNYF-12441]

Version 11.0.0.014

Kerberos authentication works as expected after upgrading to 11.0.0.014 and higher. [BNYF-12203] On the BASIC > Dashboard page, the Total Threats / Viruses feature of the page does not cause a high system load when there is a high amount of data. [BNYF-12232] Added the following CAs to the ca-bundle.trust.crt file: [BNYF-12242] GeoTrust DV SSL CA - G3 COMODO RSA Organization Validation Secure Server CA Configuration changes on the ADVANCED > Remote Filtering page do not result in an unrelated warning message. [BNYF-12085] On the BASIC > Reports page of the Barracuda Web Security Gateway 310(appliance and Vx) and 410Vx, the list of reports show as expected in the Productivity and Administrative sections. [BNYF-12234] Suspicious keyword alerts are sent as expected when there is more than one email address configured in the Sensitive Keywords Alert Email Address field. [BNYF-12188] Suspicious keyword alert emails display content properly when SSL Inspection is enabled. [BNYF-12142] ATP reports in PDF format display values properly in the Status column. [BNYF-12253] The Trusted Authentication feature on the USERS/GROUPS > Configuration page works as expected with version 11.0.0.014. [BNYF-12255] Updated per Yahoo Certifcate updates, preventing domain mismatch. [BNYF-12270] Reports generated for NTLM Groups do not return "No Data Available" error. [BNYF-12078] On the Secure Administration page, if the user is uploading a certificate and bundles that have a validation year after 2038, the cert will appear as not trusted because the chain is expired. [BNYF-12303] Added definition of Clear button on BASIC > Dashboard page. [BNYF-8464] Added that Advanced Threat Protection (ATP) only applies to certain models. [BNYF-12180]

Version 11.0.0.010

After upgrading to version 11.0.0.009, if Kerberos authentication is configured, user can browse without receiving cache errors or pop-ups. [BNYF-12203] The graph on the BASIC > Dashboard showing the total number of viruses detected by the ATP service and the Barracuda Web Security Gateway virus scanner in the past 30 days displays accurate data. [BNYF-12206] After upgrading to version 11.0.0.009, the LDAP configuration continues to appear as expected in the web interface, with the LDAP options showing as available on the BASIC > Reports and in the BLOCK/ACCEPT > Exceptions pages. [BNYF-12191] When Pass Client IP addresses through WAN port is enabled, HTTPand HTTPS pages load as expected. [BNYF-12190]

Firmware Version 10.1

What's New in Version 10.1

Barracuda Chromebook Security Extension

Barracuda Chromebook Security Extension is installed as a browser extension for Chromebooks to enforce web browsing policies you configure on the Barracuda Web Security Gateway. The extension supports SSL inspection on Chromebooks and filters all web traffic for authenticated Chromebook users. Browsing policies you configure on the Barracuda Web Security Gateway are applied by the extension to this web traffic. The Barracuda Chromebook Security Extension is available from the Google App Store at no cost and is configured in the Google Admin console. For details on how the extension works and configuration, see How to Get and Configure the Barracuda Chromebook Security Extension.

Fixed in Version 10.1

Reporting

Categories and domain names appear in proper columns in associated reports. [BNYF-10702]

SSL Inspection

For the Barracuda Web Security Gateway 410 with SSL Inspection enabled, Ultrasurf application blocking works as expected. [BNYF-8667]

When SSL Inspection is enabled in Transparent Mode and IP-based URLs are blocked, HTTPS websites are accessible as expected. [ BNYF-10494]

Authentication

Usernames are logged correctly in the Web Log for associated web traffic. [BNYF-10807] When creating an exception, lookup on Groups where a group name contains an underscore ( _ ) works as expected when NTLM authentication is configured. [BNYF-9750], [BNYF-8416]

Miscellaneous

When a domain is unknown or part of a cached categorization entry in the Barracuda Web Security Gateway, the system will use the cached categorization results if the WCS response is lost or delayed. [BNYF-10793] When connected to the Barracuda Control Server (BCS), graphs for the Barracuda Web Security Gateway display properly on the BASI C > Dashboard page of BCS. [BNYF-11183] When the Barracuda Web Security Gateway is joined to the Barracuda Cloud Control (BCC), the Content Filter Lookup feature on the BL OCK/ACCEPT > Content Filter page works as expected. [BNYF-7374] The Time Zone for Moscow, Russia as configured on the BASIC > Adminstration page is accurate. [BNYF-9271] The help file for the BLOCK/ACCEPT > Configuration page has been updated to reflect that Captive Portal sessions automatically time out after 24 hours. [BNYF-10757]

Version 10.1.0.004

Barracuda Chromebook Security Extension

Enhancement: Added the ability to associate Google domain users in the Barracuda Chromebook Security Extension with local LDAP Server/Active Directory. [BNYF-11561] Fix: The Shared Secret value configured for the extension is not exposed in the browser "View page source" window, nor can it be read from the command line. [BNYF-11180] Fix: During policy lookups, the Barracuda Chromebook Security Extension authenticates the user over a secure connection to the Barracuda Web Security Gateway. [BNYF-11326]

Miscellaneous

Enhancement: When the Reset button is pressed on the Barracuda Web Security Gateway appliance, the unit reboots. The IP address cannot be changed by pressing the Reset button. [BNYF-10968]

Firmware Version 10.0

What's New in Version 10.0

Important Note: SSL Inspection is resource intensive, and enabling it will have an impact on system performance. The actual impact will depend on the amount of HTTPS traffic that your unit is handling. If your unit does not provide satisfactory performance after enabling SSL Inspection, contact your Barracuda sales representative to learn about hardware refresh options.

SSL Inspection

The Barracuda Web Security Gateway 310 appliance (not Vx) now supports SSL Inspection with inline or forward proxy deployments for Safe Browsing. Configure on the BLOCK/ACCEPT > Configuration page. The Barracuda Web Security Gateway 410 appliance (not Vx) now supports Transparent Mode for SSL Inspection and the creation of self-signed certificates for SSL Inspection. If SSL Inspection is enabled on a Barracuda Web Security Gateway 410 before upgrading to version 10.0, then after upgrading, SSL Inspection will be enabled in Transparent Mode. Configure on the ADVANCED > SSL Inspection page. See Using SSL Inspection With the Barracuda Web Security Gateway for information about Transparent Mode. The 410 appliance (not Vx) also now supports capture and archiving of suspicious content or sensitive data patterns in chat, email, and other social media communications. Configure on the BLOCK/ACCEPT > Web App Monitor page. The Barracuda Web Security Gateway 810 now supports specifying particular domains and/or categories with SSL Inspection. Configure on the ADVANCED > SSL Inspection page.

See How to Configure SSL Inspection Version 10 and Above for a reference of SSL Inspection features by model.

User Interface

The Barracuda Web Filter has been rebranded to the Barracuda Web Security Gateway. The BASIC > Dashboard page now shows Recent Flagged Terms instead of Recent Search Queries for the Barracuda Web Security Gateway 410. This reflects availability of the Web Application Monitoring feature on the 410 with this version.

Secure Administration

Enhancement: Added the following certificates to SSL CA bundle - GeoTrust Global CA. [BNYF-10803]

Thawte dv SSL CA - G2. [BNYF-10802] DigiCert SHA2 High Assurance Server CA. [BNYF-10828]

Virtualization

Enhancement: On the Barracuda Web Security Gateway Vx, if Energize Updates are disabled, expired, or terminated, all traffic is allowed regardless of policy settings. [BNYF-10322].

Fixed in Version 10.0

NIC drivers are updated to avoid packet loss in certain models of the Barracuda Web Security Gateway. [BNYF-10426] Scheduling backups or performing a Test Configuration of an SMB server for reporting works as expected if the username specified does not have access to the default WORKGROUP. [BNYF-8855] For Barracuda Web Security Gateways connected to Barracuda Appliance Control (BAC): the Unit Health section of the STATUS page in BAC displays correct information about the unit when the CPU Temperature in the BWSG Performance Statistics section on the BASI C > Dashboard page shows 0.0 degrees Centigrade. [BNYF-9893] The BASIC > Application Log no longer shows the Destination IP in the Source IP column for certain applications. [BNYF-5333]

Version 10.0.0.020

Application control is supported for the Barracuda Web Security Gateway 310 and higher. Barracuda no longer provides the Barracuda Malware Removal Tool for any model. Web Application Control (BLOCK/ACCEPT > Web App Control) is supported for the Barracuda Web Security Gateway 310 and higher.

Version 10.0.0.018

If you enabled the Barracuda Chromebook Security Extension while running version 9.1 or earlier, and then upgrade to version 10.0, the configuration for the extension is present as expected. [BNYF-11933] When synchronizing configuration changes across a cluster, the Barracuda Web Security Gateway does not reboot or re-load an older configuration. [BNYF-11930] Proper handling of null "x-forwarded-for" header. [BNYF-11873] Policy requests now time out, if necessary, rather than waiting a long time. [BNYF-11870] Improved management of WCS lookups when there are timeouts, resulting in fewer "timeout" messages in the WCS log. [BNYF-11844] Updates to CFDEF (category definitions) are enabled as expected when the WCS service is enabled. [BNYF-11832] DNS name "=*.yimg.com" should be added under "subject alternative names" by the Barracuda Web Security Gateway to be able to fully load https://www.yahoo.com when SSL inspection is enabled. [BNYF-11759] The Power button works as expected on older Barracuda Web Security Gateway appliances when upgrading to version 10.0. [BNYF-11749] Barracuda WSA users no longer get a block page when SSL inspection mode is set to Transparent and web-based email is blocked for un-authenticated users, but allowed for authenticated users. [BNYF-11647] Peer Proxy works as expected for HTTPS sites. [BNYF-11587] The Barracuda Web Security Gateway ensures that Proxy and Web Application Monitoring services do not use the same port when SSL Inspection is enabled in Transparent mode, avoiding issues on some higher models. [BNYF-11576] CFDEF updates are downloaded regularly even when the WCS service is enabled on the Barracuda Web Security Gateway. [BNYF-11558] The "Configuration updated" message is only displayed in the web interface when a configuration change is made. [BNYF-10947] Policy Lookup Only (PLO) mode supports Google Consumer Apps. [BNYF-10314]

Version 10.0.0.016

This version addresses an issue in manufacturing newer Barracuda Web Security Gateways with upgraded hardware.

Firmware Version 9.1

What's New in Version 9.1

Ability to block Google consumer accounts while allowing Google hosted organizational accounts to be accessed for a specified list of Google applications. See G Suite Control Over HTTPS and Exception Policies Version 7 and Above for examples. Ability to categorize domains dynamically in real time. New option on BASIC > Reports page that allows hiding custom categories on reports. Barracuda Malware Removal Tool is no longer provided with the Barracuda Web Security Gateway version 9.1 and above.

Fixed in Version 9.1

Enhancement: Back-end improvements to the Barracuda policy engine, especially related to application blocking. [BNYF-10148, BNYF-10151, BNYF-10166, BNYF-10294] Enhancement: The Barracuda Web Security Gateway now uses the Web Categorization Service by default unless previously disabled. [BNYF-10601]

Enhancement: Content filtering performance. [BNYF-8228, BNYF-10294, BNYF-10274, BNYF-10175] Fix: Reporting issues related to data unavailability/inaccuracy. [BNYF-9248, BNYF-9448, BNYF-9705, BNYF-9842, BNYF-9984, BNYF-10132, BNYF-10210, BNYF-10246] Fix: When updating a Barracuda Web Security Gateway using Barracuda Cloud Control from version 9.0.0.003 to version 9.1.0.001, the Barracuda Web Security Gateway now remains connected to Barracuda Cloud Control. [BNYF-10663] Fix: On the BASIC > Application Log page, entries that erroneously displayed 'spysiteIN=br0' in the Details column now show correctly as 'Spyware Website'. [BNYF-10292] Fix: Reports with more than 10 records show all records in the table and a maximum of 10 records in the chart. [BNYF-9181] Fix: The Weekly Performance Summary report runs automatically as a Scheduled Report for version 9.1 and above. [BNYF-10521] Fix: Policy engine improvement during configuration reload. [BNYF-10645] Fix: The Barracuda Web Security Gateway communication with the WCS lookup is contiguous without interruption. [BNYF-10764]

Firmware Version 9.0

What's New in Version 9.0

New underlying application blocking engine. Version 1.0.130 or above of the Application Definition Updates is required (See the ADV ANCED > Energize Updates page). Consequences are: Improved performance of application blocking and strength of signature-based application detection, including service recognition, e.g. chat, video, voice and file-transfer. More accurate identification of applications, with frequent updates. Higher accuracy of real-time detection capabilities. Blocking of over 200 additional protocols and applications. Blocking of the following applications is no longer supported: ASProxy uTorrent Twitterrific Freegate HotspotShield IPShield Icecast (in Communications group). However, the IceCast app in the Multimedia group can still be blocked. The following apps will appear in the web interface with the associated name changes: Real Time Streaming Protocol will now display as RTSP. iChat AV, VoIP Stunt, and VoIP Buster will now display as SIP. Authentication Added support for Aerohive Wireless Access Point (WAP) authentication integration. Configure on the USERS/GROUPS > Configuration page. Energize Updates Added Access Point Definition Updates, released on a regular basis by Barracuda Central and for use with the Barracuda Web Security Gateway. Configure on the ADVANCED > Energize Updates page.

Fixed in Version 9.0

Feature: The Barracuda Web Security Gateway can be configured to accept traffic on non-native tagged VLAN 1. See the ADVANCED > Advanced Networking page. [BNYF-6551] Fix: When the Captive Portal feature is enabled and an Allow exception is created for a set of users, those users now see the Captive Portal agreement page when visiting allowed sites. [BNYF-8662] Fix: A large scheduled report no longer fails to generate when you try to run the same report before the original report finishes. [BNYF-9688] Fix: If a group is added to an Active Directory OU, the Barracuda Web Security Gateway now detects updates to that group. [BNYF-9260] Fix: Scheduled Reports in HTML format to an SMB server (configured on the ADVANCED > External Servers page) now correctly organize sets of reports in a directory or folder as specified. [BNYF-9161] Fix: If custom categories are created and exceptions are created for those categories, and the Barracuda Web Security Gateway logs traffic for those categories, the captured Daily/Hourly statistics will continue to display on the BASIC > Dashboard page if those categories are then deleted. [BNYF-9063] Fix: When accessing the Barracuda Web Security Gateway web interface from the BCS, clicking on the Release Notes link on the BASI C > Dashboard page displays the notes as expected, and does not give a Temporarily Unavailable page. [BNYF-9394] Fix: When using G Suite for Education with Chromebooks, it is necessary to NOT inspect specific Google subdomains in order to prevent certificate errors. These subdomains will not be ssl inspected in proxy mode if Chromebook Compatibility is enabled. [BNYF-8763] Fix: The YouTube For Schools feature now works when the Streaming Media category is set to Monitor. [BNYF-9090] Fix: Apple iOS7 users are now able to log in and proceed as Guest when the Captive Portal feature is enabled. [BNYF-8943] Fix: HTTPS redirection with WCCP deployments now works whether or not HTTPS Filtering is enabled. [BNYF-8902] Fix: Reports that contain spyware sites are no longer blocked by the Barracuda Spam Firewall because the reports no longer include actual URL links to the sites. [BNYF-4221] Fix: When the Clear Cache button is pressed in the Caching Options section of the ADVANCED > Caching page, the transaction is now

logged in the Audit Log. [BNYF-3000] Fix: Active Directory Group lookup is successful when Kerberos is configured for Authentication. [BNYF-9378] Fix: If an OU name contains special characters, scheduled reports based on the OU execute successfully. [BNYF-9281] Fix: Policy Rule Checks now recognize upper case letters when testing entered URL or Domain against the domain black/whitelist on the ADVANCED > Troubleshooting page. [BNYF-9349]

Version 9.0.0.003

Fix: Reverting to a factory firmware version on a Barracuda Web Security Gateway (Vx and appliance). [BNYF-8703] Fix: Accessing scholar.google.com with transparent SSL Inspection. [BNYF-10166]

Version 9.0.0.002

Fix: Captive portal exclusion now works as expected for an IP subnet group when a user initiates a session by opening a phone application (before using the browser) that accesses a particular domain. [BNYF-9438] Fix: The Log In button on the Temporary Access portal page works as expected after a custom category that includes a comma (,) is created. [BNYF-9871] Fix: The user no longer encounters an error page when, after triggering a time-based quota exception, browses a Warn page. [BNYF-9880] Fix: Domains and subdomains added to Custom Categories are properly categorized. BNYF-9883] Fix: Resolved issue in which the user was unable to download a page in proxy mode if the DNS response had CNAME instead of IP address. [BNYF-9885] Fix: When using Google Chrome browser, inline traffic to all Google sites, including YouTube, is blocked or allowed as expected per policy. [BNYF-9889] Fix: Manual Backup to Local Destination as configured on the ADVANCED > Backups page works as expected. [BNYF-9997] Fix: Updated Trusted CA bundle with additional certificates. [BNYF-10018]

Firmware Version 8.1.0, Platform 2 and Platform 3

What's New in Version 8.1.0

Enable Port Auth Exemption - Allows exemption of traffic proxied to port 8080 from NTLM and Kerberos authentication. If you have a combination of a terminal server environment using either NTLM or Kerberos authentication and Windows desktop units using LDAP, for example, this feature enables a hybrid of authentication mechanisms. Windows desktop users can then authenticate via your LDAP server while terminal users can authenticate via NTLM or Kerberos in a forward proxy configuration. Make sure that LDAP and/or unauthenticated user traffic runs over port 8080.

Fixed in Version 8.1.0

Data correctly displays in chronological order for the Web Requests Log report type in HTML, PDF, Text, or CSV formats. [BNYF-8973] Login override, which provides login fields in the Spyware block page for authenticated users or the Captive Portal page (when Captive Portal feature is enabled) now works as expected. [BNYF-8962] When clustering two or more Barracuda Web Security Gateway Vx virtual machines, making a change in the configuration of one now propagates correctly to the other. [BNYF-8895] When the timezone is set within 30 minutes of GMT, performance statistics and charts on the BASIC > Status page render correctly. [BNYF-8869] Creating exceptions based on Safe Search does not result in an error message. [BNYF-8831] Provisioning the Barracuda Safe Browser on a device with the Barracuda Web Security Gateway is successful when bookmarks configured on the ADVANCED > Remote Filtering page contain special characters. [BNYF-8834] Scheduled reports with a large time frame complete correctly. [BNYF-8777] Editing the Custom Keyword Categories on the BLOCK/ACCEPT > Web App Monitor page saves modifications as expected. [BNYF-8694] With the Captive Portal feature enabled, when an Allow exception is created for a set of users, those users now receive the Captive Portal agreement page as expected when they try to visit the allowed sites. [BNYF-8662] Authenticated policy rules are no longer applied to Unauthenticated Captive Portal users. [BNYF-8483] On the ADVANCED > Backup page, the Cloud option is available for Scheduled Backups. [BNYF-8591] When multiple Barracuda Web Security Gateways are connected to Barracuda Appliance Control, reports generated from the group node view include data from all connected Barracuda Web Security Gateways. [BNYF-8578]

Version 8.1.0.005

Fix: Updated OpenSSL to address CVE-2015-0204 (commonly known as "FREAK"), CVE-2015-0286, CVE-2015-0287, CVE-2015-0289, CVE-2015-0292, CVE-2015-0293, CVE-0209, and CVE-2015-0288. Fix: Added CA certificates for trust chain verification, additional checks with errors for self-signed certificates and expired certificates. [BNYF-7863] Fix: YouTube Safe Search: Safe Search can only be enforced when the user is browsing as "guest". This means that uploading and similar actions tied to a user account will not work with YouTube Safe Search enabled. [BNYF-9323]

Fix: Active Directory Group Lookup now works as expected when using Kerberos authentication. [BNYF-9378] Fix: Self-signed certificates created on the Barracuda Web Security Gateway 410 for use with SSL Inspection are now correctly created with an expiration date 3 years from date of creation. Self-signed certificates for all other Barracuda Web Security Gateway models expire in 1 year from date of creation. [BNYF-9362]

Version 8.1.0.003

Feature: Automatic scheduling of the Performance Summary report when you upgrade to version 8.1.0.003. A PDF version of the report will run weekly and be delivered by email to the address entered in the System Alerts Email Address field on the BASIC > Administration page. To remove the report from the schedule, go to the BASIC > Reports page and remove it from or disable it in the S chedule Reports table. Fix: Further mitigated risk of SSLv3 related POODLE vulnerability on the internal interface of the Barracuda Web Security Gateway. If you have a legacy browser or web client inside the organization that is being SSL inspected and supports only SSLv3 or below, you could possibly experience an outage. If that is the case, call Barracuda Technical Support to resolve this issue. Note that with this fix, the external interface of the Barracuda Web Security Gateway is not affected in any way. [BNYF-9355] Fix: SSLv3 is disabled when the Local Redirect IP address is configured to be the same as the System IP address. This is to mitigate CVE-2014-3566 (SSL POODLE). [BNYF-9333] Fix: Self-signed SSL certificates created on the ADVANCED > SSL Inspection page expire one year from date of creation, as expected. [BNYF-9362]

Version 8.1.0.002

Enhancement: New Performance Summary report with graphs of throughput, system load, TCP connections and Active Users. This report is a tool for quickly assessing whether your Barracuda Web Security Gateway is performing at sustainable levels for your organization's current needs. Overall system performance is represented by a horizontal bar that indicates where your system is with respect to maximum thresholds. Recommended, average and peak values are provided. Use this report to help gauge whether your organization has outgrown your Barracuda Web Security Gateway and you should consider upgrading to another model. Fix: Port 3130 is reserved ONLY for HTTPS traffic through the Barracuda Web Security Gateway when the SSL Inspection feature is enabled. [BNYF-9082] Fix: When re-ordering policy exceptions on the BLOCK/ACCEPT > Exception page, exceptions with text patterns that include meta-characters now remain unaffected if they change order. [BNYF-9187] Fix: LDAP users are now able to log in using LDAP Proxy Authentication regardless of whether the Bind DN contains a backslash '\' . [BNYF-9165] Fix: SSLv3 has been disabled in the Web interface to mitigate CVE-2014-3566 (SSL POODLE). [BNYF-9226] Fix: When a user is removed from an LDAP group in AD, periodic automatic synchronization of group information with the Barracuda Web Security Gateway works as expected. [BNYF-8532] Fix: Exceptions for LDAP groups continue to be applied as expected after making changes to the exception when Aggregate All Active Directory Domains is also set to Yes on the USERS/GROUPS > Authentication page. [BNYF-9150]

Upgrading to Version 8.0

After upgrading to version 8.0, you'll notice that some Hourly/Daily reports on the BASIC > Statu s (dashboard) page will initially show No Data Available until the first web request is made after the upgrade. All of the data required to run reports still exists on the Barracuda Web Security Gateway and new data will begin to appear on the default dashboard as the Barracuda Web Security Gateway begins to process traffic after the upgrade.

Firmware Version 8.0

What's New in Version 8.0

Authentication

Proxy Authentication - The Proxy Authentication feature has been expanded to allow selection of LDAP groups for proxy authentication. Previously, only local users were supported. In 8.0, Administrators can apply LDAP authentication to remote/mobile users who are in the LDAP server, but are browsing outside of the network. This means that the Barracuda Web Security Gateway can be configured such that there are no unauthenticated users. See the USERS/GROUPS > Configuration page to configure. Wireless Access Point (WAP) Support - The WAP integration feature enables end users to surf as authenticated users via the Barracuda Web Security Gateway after authenticating against their WAP. This means that the user only needs to enter their credentials once as opposed to entering their credentials once for the WAP and then a second time to authenticate against the Barracuda Web Security Gateway. Each WAP can be configured to send its syslogs to the Barracuda Web Security Gateway on the network, which can then parse the logs for username and IP address of each authenticated user. This enables reporting on user browsing activity, bandwidth use, and more. See the USERS/GROUPS > Configuration page to configure.

User Interface

Data Pattern Categorization - As data leaves the corporate network through a variety of web based applications, the network administrator can monitor data patterns for sensitive information to ensure compliance with corporate policies. This entails the monitoring

and alerting of flagged specific data elements such as credit card numbers, social security numbers, privacy terms, and HIPAA compliance terms. See the BLOCK/ACCEPT > Web App Monitor page to configure. Customizable Dashboards - In addition to the wealth of information available on the default dashboard (BASIC > Status page), the administrator can now also create multiple dashboards with summaries of just the information about web traffic and user activity that is of top priority. Choose from various reports showing specific user browsing, bandwidth and malware statistics in drag and drop layouts.

Virtualization

Support for Microsoft Hyper-V - See Hypervisor Compatibility and Deployment - VHD Package.

Fixed in Version 8.0

YouTube Safety Search works to match Google's new implementation of enforced Safety Mode as of March 2014. [BNYF-8537] Log reports now show data in ascending order by date. [BNYF-8530] Limiting reports to All Logged Users no longer generates reports with No Data Available message. [BNYF-8458] Reports can now be generated that include users found in nested organizational units (OU's) in the Active Directory structure. [BNYF-8379] Application Exceptions can now be set for specific IP groups. For example, FTP traffic can now be blocked based on the IP group of a particular user or set of users. [BNYF-8519] Temporary Access administrators can now log in to bypass block pages using their LDAP credentials even if the LDAP group they belong to is named with upper case letters. Previously, LDAP group names had to be in lower case. [BNYF-8504] Port 22 is no longer open for SSH access on the Barracuda Web Security Gateway. [BNYF-8175]

Firmware Version 7.1.0

What's New in Version 7.1.0

SSL Inspection

The Barracuda Web Security Gateway 610 and 810 now support inline SSL Inspection. In previous releases, SSL Inspection was supported only in forward proxy deployments. Moreover, applications selected on the BLOCK/ACCEPT > Web App Control and Web App Monitor pages are now subject to SSL Inspection when the feature is enabled. See How to Configure SSL Inspection Version 7.1 f or details. See the ADVANCED > SSL Inspection page in the Barracuda Web Security Gateway web interface to configure. The Barracuda Web Security Gateway 910, 1010, and 1011 now SSL inspects applications selected on the BLOCK/ACCEPT > Web App Control and BLOCK/ACCEPT > Web App Monitor pages. Previously, only domains and categories (in forward proxy) specified on the ADVANCED > SSL Inspection page were subject to SSL Inspection. The Barracuda Web Security Gateway 410 now supports SSL Inspection with inline or forward proxy deployments for Safe Browsing and YouTube for Schools. The Barracuda Web Security Agent (WSA) supports SSL Inspection in non-Policy Lookup Only Mode, to inspect the traffic proxied by the agent. See Barracuda Web Security Agent - How it Works 7.1.

Fixed in Version 7.1.0

RAID status tools provide correct and consistent RAID status on the BASIC > Status page. [BNYF-8186] When a delegated admin is limited to a group, and that admin runs a report, the filter for Limit Access To (defined on the ADVANCED > Delegated Admin page) is correctly applied. [BNYF-7335] The process of exporting to a CSV file from the BASIC > Web Log page does not time out if the export takes more than 5 minutes. [BNYF-8178] The Manage and Monitor roles as defined on the ADVANCED > Delegated Admin page can create scheduled reports. [BNYF-8288] Backups created on older firmware versions will not work on the 7.1.0 release. The retrieval and backup works as expected as long as the backup files have been created with 7.1.0 release. [BNYF-8127]

Version 7.1.0.003

Synchronized help page in web interface for ADVANCED > Temporary Access page. [BNYF-8425] Logging into the web interface with admin credentials, or getting redirected to a block page in a maximized IE8 browser does not cause the browser to crash. [BNYF-7982] The Warn block page triggered by a MIME type includes a Proceed button as expected. [BNYF-8450] The Windows Safari browser gets filtered as expected by the Barracuda WSA with the default option 'Filter Specified Applications And Allow All Others' configured on the ADVANCED > Remote Filtering page. [BNYF-8221] When a website is blocked for the reason of spyware, all buttons and the option to run the Barracuda Malware Removal Tool are present. [BNYF-8361]

Firmware Version 7.0.1

What's New in Version 7.0.1

Captive Portal

See the BLOCK/ACCEPT > Configuration page for settings. Option to apply Captive Portal to one or more IP Subnet/Groups (as defined on the USERS/GROUPS > IP Subnets/Groups p age) as well as to unauthenticated users. Captive Portal access to the network can allow users to browse: Using their existing LDAP credentials to log in and be subject to Authenticated policies, OR Only as a Guest, OR Based on their choice, selecting either Guest or as Authenticated when presented with the Captive Portal splash/login page. Option to present a Logout button for the user on a block page that displays when a policy prevents the user from accessing a requested website or application. This allows for changing users/logins. Ability to exclude IP group(s) from Captive Portal. Temporary Access for Teachers, Students Admin has option to allow teachers to bypass block pages with login credentials instead of, or in addition to, using tokens to provide student access to requested websites. Teacher still has option to hand out tokens to students. Admin can designate entire LDAP groups as Temporary Access administrators. For example, the admin might create a group for the Science Dept. and assign all teachers in that group Temporary Access administrator rights. SSL inspection Configure on ADVANCED > SSL Inspection page. Ability to limit SSL Inspection of web traffic to specific users/groups. This new option provides 2 benefits: - Enables the admin to better manage this resource-intensive feature. - Prevents unauthenticated or guest users from getting certificate warnings when browsing over HTTPS because they do not have the root certificate installed in their browser. Option to allow end users to download a root SSL certificate from their browsers. May also require authentication for certificate download. This option is useful if you choose to create a self-signed certificate on the Barracuda Web Security Gateway which needs to be pushed out to client browsers, instead of uploading a trusted certificate you buy from a certificate authority. Rather than pushing the self-signed certificate to browsers, you can enable users to download it. Reporting - Two new summary reports, aggregating existing reports for meaningful snapshots of network activity and Internet activity for the specified time frame.

Fixed in Version 7.0.1

Significant performance improvement in rendering reports and statistics Faster reporting interface Faster rendering of statistics on the BASIC > Status page Faster log in to the web interface Status page Performance Statistics display and align properly. [BNYF-7742, BNYF-7750] Delay in page loading at Admin login fixed. [BNYF-7994] When Daily is selected in the Hourly Web Security Gateway Statistics section of the page, the list data is updated and displays the Top 10 records. [BNYF-7837, BNYF-7928] Reporting Network Activity Summary adhoc report in PDF format loads and displays correctly. [BNYF-8004] Top Users by Requests to Spyware Sites adhoc HTML report (Users by Spyware Requests report in version 6.0.1) shows accurate data when drilling down by Hour or Domains [BNYF-7771] Sessions by Users report is present. [BNYF-7747] Barracuda Cloud Control When managing the Barracuda Web Security Gateway from Barracuda Appliance Control (BAC): The Web Application Control page now displays blocked applications for both single and group view. [BNYF-7988] The BASIC > Status page correctly displays statistics. [BNYF-6233, BNYF-7295, BNYF-7413, BNYF-7412, BNYF-7750, BNYF-7795, BNYF-7837, BNYF-7876, BNYF-7874] The BASIC > Reports page aligns with the Barracuda Appliance Control display. [BNYF-7355, BNYF-7349, BNYF-7893] Adhoc reports in HTML format display records correctly. [BNYF-7348] The User/Group Lookup button works properly on the BLOCK/ACCEPT > Exceptions page. [BNYF-6974] Policy remains as selected (either Unauthenticated or Authenticated) on BLOCK/ACCEPT > Web App Control page. [BNYF-7988] Miscellaneous Block page now renders with correct background color when user visits blocked websites. [BNYF-7993] Block page and log in process work properly with maximized window in the IE8 browser. [BNYF-7982]

Firmware Version 7.0

Upgrading to Version 6.x and 7.x

After upgrading to version 6.0, reverting back to the previous firmware version or to the factory installed version is not possible. Note that the BASIC > WebLog and BASIC > Application Log pages get cleared on updating from 6.0.0 to 6.0.1, but the log data is still intact and will still appear in reports.

WARNING: If you are currently using port 8080 as a proxy port for your client connections, note that this port is no longer available to use for proxy connections with version 7.0 and higher. Please alter the port to 3128 on your clients by modifying your GPO or PAC file.

What's New in Version 7.0

User Interface New look and feel - The new Barracuda Web Security Gateway web interface is cleaner with a new color scheme, but is functionally the same with no changes to navigation. Enhanced Dashboard - View live feed of current TCP connections and graphs of blocked requests, user browse times and bandwidth usage for a quick picture of web traffic on your network. New controls for viewing logs and switching graph content type on-screen. Recent Flagged Terms - (Available on 610 and higher) This new section displays a list of the most used suspicious keyword terms in social media and search engine activities per settings on the BLOCK/ACCEPT > Web Application Monitor page. These terms are categorized in a suspicious keywords lexicon provided by Barracuda Networks and can be added to by creating a custom list on the BLOCK/ACCEPT > Web Application Monitor page. Improved reporting presentation tools as described below. Limited support for Barracuda Appliance Control (BAC). The new web interface includes several key enhancements, especially around the dashboard (BASIC > Status page). Future versions of the Barracuda Web Security Gateway firmware will fully support the new web interface. You can still join your Barracuda Web Security Gateway running version 7.0 to Barracuda Appliance Control, with limited feature support. Temporary Access for Teachers, Students - This feature replaces the Temporary Whitelist role. For research projects and other classroom needs, the Temporary Access Portal enables teachers to obtain student access, for a specified time period, to websites that are typically regulated by administrators. Administrators either create credentials for teachers, or teachers simply log into the portal via LDAP. From the portal teachers can request domains and/or categories of domains for temporary student access. The Temporary Access Portal issues a token for each request that the teacher can then give to students for bypassing block pages. To configure, see A DVANCED > Temporary Access. The BASIC > Temporary Access Requests log tracks activity by teachers who have been given credentials to request temporary access for their students. The log displays the status of tokens teachers create by username and date, including expiration date and time of tokens. Web Application Monitoring (Available on 610 and higher) Suspicious Keyword Alerts - Applies to terms categorized as related to cyberbullying, profanity, adult or terrorism in social media interactions. Barracuda Networks provides a lexicon of keywords you want the Barracuda Web Security Gateway to flag for generating email alerts when they appear in user social media interactions or search engine activities. You can add your own categories and lists of keywords as well. See the BLOCK/ACCEPT > Web App Monitor page for details and to configure. The BASIC > Status page includes a listing of the Recent Flagged Terms (Suspicious Keywords) identified in filtered traffic. New Web App Monitor Log page - This new page on the BASIC tab displays a log of all archived chat, email, user registrations and social media interaction traffic processed by the Barracuda Web Security Gateway. Configure which kinds of activities you want to capture on the BLOCK/ACCEPT > Web App Monitor page. Use the BASIC > Web App Monitor Log pa ge to view these captured application interactions by date, source IP address, username and associated details. Enhanced HTTPS Filtering SSL Inspection - In addition to Forward Proxy deployments with the Barracuda Web Security Gateway 610 or higher, now also available for inline deployments on certain models. See the ADVANCED > SSL Inspection page. Provides for granular control of web 2.0 applications over HTTPS as described above within Facebook, G Suite, YouTube and more. HTTPS Block Page - A block page is presented when users attempt to visit a website over HTTPS that either poses a security risk, violates policy, or that falls under the Warn policy action. Using the HTTP block page template on the BLOCK/ACCEPT > Block Messages page, you can customize the text on the web page displayed by the Barracuda Web Security Gateway. Reporting New reporting engine with enhanced performance for fast response times. Enhanced PDF and HTML presentation with informative header, footer and easy-to-read layout. New report set- Organized for Productivity, Safety & Liability, Web Activity, Infection Activity and Administrative (Temporary Access Requests), including: Top Facebook Users by Browse Time Top Users by Bandwidth on Streaming Media Sites Top Gaming Domains by Requests Top Users by Requests to Spyware Sites Top Facebook Users by Browse Time Top Social Networking Domains by Requests Top Streaming Media Domains by Requests Top Streaming Media Domains by Bandwidth Top Users by Bandwidth on Gaming Sites Top Users by Blocked Requests Top Users by Browse Time on Gaming Sites Top Users by Browse Time on Streaming Media Sites Top Users by Browse Time on Social Networking Sites Top Users by Requests to Adult/Pornography/Nudity Sites Top Users by Requests to Anonymizer Sites Top Users by Requests to File Sharing/P2P Sites

Top Users by Requests to Intolerance and Hate Sites Top Users by Requests to Weapons/Violence and Terrorism Sites Top Suspicious Keywords Suspicious Keywords by Users Top YouTube Users by Bandwidth Top YouTube Users by Browse Time Audit Log Temporary Access Request Log Categories By Temporary Access Requests Domains By Temporary Access Requests Users By Temporary Access Requests New Audit Log - The Barracuda Web Security Gateway maintains a log of events including logins/logouts and changes to configuration settings in conjunction with role-based administration. The new BASIC > Audit Log page lists these events including date, source IP address, username, role and associated details. Policy Rule Checking - From the ADVANCED > Troubleshooting page you can test policy rules applied to traffic on specified servers. You can verify access restrictions and exceptions that you define in the pages on the BLOCK/ACCEPT tab. The Policy Rule Check returns a list of all of the rules that would apply to traffic and actions (Monitor, Warn, or Deny) that would be taken based on the rule. Support for External ICAP servers - Ability to redirect traffic from the Barracuda Web Security Gateway to a 3rd party server. Select DLP, Antivirus, or other dedicated ICAP server on the ADVANCED > External Servers page. The Barracuda Web Security Gateway will first apply all configured policies to inbound or outbound traffic, and then forward the traffic to the specified ICAP server for DLP scanning, antivirus scanning or other processing.

Fixed in Version 7.0.0

Version 7.0.0.022

Reordering of exceptions in the List of Exceptions table on the BLOCK/ACCEPT > Exceptions page works and displays properly. [BNYF-7940]

Version 7.0.0.021

Improved performance by resolving issues with increased CPU usage. [BNYF-7678] Resolved issue with increased memory usage when running reports. [BNYF-7807]

Barracuda Web Security Gateway Web Application Definitions Release Notes

Version 1.0.176

Added Hotspot Shield Servers to be blocked

Fixed issue with Adobe Update not being blocked

Improved Appblocker blocking capacity

Version 1.0.175

New V2 Detection with latest library (WSG 12.0+)

Initial icon support for application logging

Added Dropbox for Business support (WSG 12.0+)

Improved WAM rules for Facebook, Yahoo, Viber, Bittorrent

Removed web applications Yahoo Toolbar, Skydrive

Improved support for BWB offline update

Improved blocking rules and performance

Version 1.0.167

Improved detection mechanism

Version 1.0.163

Appblocker fix for exempted IP addresses (BNYF-10593)

Deployment Options

You can deploy your Barracuda Web Security Gateway so it is inline with your core network components or you can deploy the system as a forward proxy. The following sections provide a brief overview of inline and forward proxy deployment types, including virtual machine deployment. For maximum security, Barracuda recommends placing your Barracuda Web Security Gateway behind a corporate firewall.

If you have remote clients, you can filter traffic for them and apply policies by deploying the Barracuda Web Security Agent on each client and configuring the Remote Filtering feature (see the ADVANCED > Remote Filtering page).

Barracuda Networks recommends reviewing and determining the best deployment option for your network before continuing with installation. As you determine the best deployment for your organization, please also see Step 1 - Network Considerations.

Inline Pass-Through (Transparent) Mode Deployment

For maximum security, Barracuda recommends placing your Barracuda Web Security Gateway behind a corporate firewall.

Inline pass-through is the recommended type of deployment for the Barracuda Web Security Gateway appliance (not supported by the Barracuda Web Security Gateway Vx virtual machine) because it provides the strongest level of protection against spyware. In this deployment, the Barracuda Web Security Gateway is directly inline with your core Internet network components, and all network traffic to the Internet passes through the Barracuda Web Security Gateway. In this mode, your Barracuda Web Security Gateway is able to:

Filter and scan all Internet traffic requests Perform content filtering and scan downloads for spyware and viruses Filter web-based and non web-based applications Detect and block outbound spyware protocol requests Scan all outbound traffic for spyware activity on all ports to detect infected clients Perform SSL Inspection – i.e. scanning of HTTPS traffic at the URL level - see Using SSL Inspection With the Barracuda Web Security Gateway for details and requirements. Available on the Barracuda Web Security Gateway 410 and higher.

Use case: A hybrid of forward proxy and inline deployment Note that you can deploy a hybrid of forward proxy and inline for specific use cases. A typical example is a mixed environment of terminals and desktops. If you want to apply different browsing policies to each group of users, you can proxy traffic from the terminals to the Barracuda Web Security Gateway IP address on port 3128, while connecting the desktops inline using the LAN/WAN bridge, enabling filtering of application traffic from the desktops as well as HTTP and HTTPS traffic. See also Forward Proxy Deployment of the Barracuda Web Security Gateway. In this scenario you can also use different authentication mechanisms for each group, as described in Hybrid Authentication Mechanisms.

Inline pass-through deployment requires you to have an understanding of your network topology because even though the Barracuda Web Security Gateway acts as a proxy, it does not participate in routing protocols. As a result, you may need to set up static routes in your Barracuda Web Security Gateway so it knows how to properly route traffic.

Per Figure 1 below, you’ll typically route traffic from your switch or router, via the Barracuda Web Security Gateway, to the internal IP address of your firewall or another device used for routing on the WAN side of the Barracuda Web Security Gateway.

The following table describes the advantages and disadvantages of deploying your Barracuda Web Security Gateway in inline pass-through mode.

Advantages Disadvantages

Supports application blocking. May require setting up static routes in your Barracuda Web Security Gateway.

Supports automatic pass-through mode in the event of a system Initial setup requires an interruption to network traffic while you make failure (model 310 and above). necessary cabling changes.

Does not require users to configure proxy server settings in their web browser.

Uses perimeter transparency mode that exposes client IP addresses (supports corporate firewall rules).

Figure 1: Inline Pass-through Deployment.

Forward Proxy Deployment of the Barracuda Web Security Gateway

For maximum security, Barracuda recommends placing your Barracuda Web Security Gateway behind a corporate firewall.

A key advantage of this deployment is that initial setup does not require any interruptions to your network traffic. However, be aware that, in a forward proxy deployment, only HTTP/HTTPS Internet traffic passes through the Barracuda Web Security Gateway. As such, in this mode the Barracuda Web Security Gateway does not scan non-HTTP traffic for viruses and spyware, nor does it block applications. See the section Limitati ons of this Deployment Type below for more details. Note that you must use either this deployment or WCCP Deployment for the Barracuda Web Security Gateway Vx.

How This Deployment Works

The Forward Proxy deployment uses a proxy, the Barracuda Web Security Gateway, as an intermediary between a client and the Internet to protect the client from being visible from the Internet. After the Barracuda Web Security Gateway processes clients' HTTP/HTTPS requests, it sends the requests out directly to the Internet. When deployed as a forward proxy, the Barracuda Web Security Gateway shows all HTTP/HTTPS traffic as coming from its own IP address instead of from the individual client IP addresses as is done in the inline pass-through deployment.

Barracuda Networks recommends deploying the Barracuda Web Security Gateway in forward proxy mode in the following situations:

You need to replace an existing forward proxy (such as Microsoft ISA Server) with the Barracuda Web Security Gateway. You do not want the Barracuda Web Security Gateway to reside inline with all your network traffic and are satisfied with the system only scanning HTTP/HTTPS traffic for viruses and spyware.

Note that you can deploy a hybrid of forward proxy and inline for specific use cases such as, for example:

A mixed environment of terminals and desktops. You can proxy traffic from the terminals to the Barracuda Web Security Gateway IP address as described below, while connecting the desktops inline using the LAN/WAN bridge, enabling filtering of application traffic from the desktops as well as HTTP and HTTPS traffic from both the desktops and the terminals. See Inline Pass-Through (Transparent) Mode Deployment for more information on inline deployment.

The figure below illustrates a basic installation using the Forward Proxy Deployment.

Configuring Forward Proxy Mode

To set up the Barracuda Web Security Gateway as a forward proxy without placing it inline, you must manually direct all outgoing web traffic you want filtered through the Barracuda Web Security Gateway. You can specify specific types of traffic to bypass the Barracuda Web Security Gateway either manually in the browser proxy settings, or by pushing out a PAC file with a GPO.

To configure Forward Proxy Mode:

1. Connect either the WAN or LAN port of the Barracuda Web Security Gateway to the same switch as the network gateway (just one network hop away). 2. Do one of the following to proxy traffic from client computers to the Barracuda Web Security Gateway: a. In the Advanced/Network settings of client browsers, using the manual proxy setting, enter the IP address of the Barracuda Web Security Gateway as the HTTP Proxy and 3128 for the port.

If you wish to use a different port, you can change the Proxy Port setting on the ADVANCED > Proxy page of the Barracuda Web Security Gateway web interface. OR b. Create a PAC file and use a GPO to push it out to all client browsers. The PAC file provides lots of flexibility as to which traffic is filtered and can provide load balancing. See Using a PAC File below. 3. From the BASIC > IP Configuration page of the web interface, set the Operating Mode to Active. Note that Audit mode does not apply to this deployment; in either Audit or Active modes, traffic will be logged and policy will be applied.

Limitations of this Deployment Type

Because the Barracuda Web Security Gateway only scans outbound HTTP/HTTPS traffic in this deployment, the system cannot perform the following functions in Forward Proxy mode:

Block access to applications listed on the BLOCK/ACCEPT > Applications pages. Block access to applications that use the destination IP address specified on the BLOCK/ACCEPT > IP Block/Exempt page. Block access to applications that use the destination port specified on the BLOCK/ACCEPT > IP Block/Exempt page. Inspect outbound traffic for spyware infection activity. Scan non-web based traffic for viruses and spyware.

Proxying Web Traffic Using a PAC File

You can create a custom Proxy Auto-Configuration (PAC) file and use a windows GPO to push out proxy settings for some or all HTTPS traffic to client browsers. This method of proxying web traffic to the Barracuda Web Security Gateway has the following advantages:

You can automatically configure all client browsers with proxy instructions rather than manually configuring them. A PAC file affords lots of flexibility since you can optionally proxy specific traffic - domains, URLs, internal versus external traffic - to a specific Barracuda Web Security Gateway, or directly to the internal or external internet. You can set up load balancing of web traffic and failover (with multiple Barracuda Web Security Gateways) in case one system is not available.

See Proxying Web Traffic Using a PAC File for details and examples of what you can do with a PAC file.

High Availability - Clustering the Barracuda Web Security Gateway

For maximum security, Barracuda recommends placing your Barracuda Web Security Gateway behind a corporate firewall.

Using the Linked Management feature you can cluster, or link two or more Barracuda Web Security Gateways together to provide synchronized configuration and policy settings across all systems. You can also use this feature to provide high availability, or failover, in case one system fails.

For High Availability, the following must be true:

Multiple Barracuda Web Security Gateways are in the same network All Barracuda Web Security Gateways are always active Web traffic is only directed through one Barracuda Web Security Gateway at a time Failover is handled by other network equipment All Barracuda Web Security Gateways must be the same model running the same version of firmware

For automatically synchronizing most configuration and policy settings across all systems, linked Barracuda Web Security Gateways can be geographically dispersed and do not need to be co-located on the same network. All Barracuda Web Security Gateways must be the same model running the same version of firmware in this use case as well.

Note that Linked Management does not provide load-balancing functionality.

The Barracuda Web Security Gateway uses port 8002 to synchronize configuration between linked systems. Use the ADVANCED > Linked Management page to link multiple Barracuda Web Security Gateways. This feature is available on the Barracuda Web Security Gateway 410 and above.

Linked Management Means the Same Policies for Each System

Some network environments may not be suitable to linking multiple Barracuda Web Security Gateway systems together. For example, if you have multiple network segments that each require different policies, it may be better to provide a dedicated, unlinked Barracuda Web Security Gateway for each segment. This way you can configure each Barracuda Web Security Gateway without the configuration settings propagating to the other systems. See Barracuda Cloud Control for information about managing multiple Barracuda Web Security Gateways (and/or other Barracuda Networks products) with unique configuration and policy settings on each system.

Also see:

Forward Proxy Deployment How to Create and Install a Self-Signed Certificate for SSL Inspection

Important for WCCP Deployments If you are using a WCCP Deployment, please contact Barracuda Networks Technical Support to confirm that your configuration of linked Barracuda Web Security Gateways is correct.

High Availability Deployment Options

Consider the following methods for deploying linked Barracuda Web Security Gateways for failover and, in some cases, load balancing, depending on your OS and network configuration:

Method 1: Use a PAC file with a GPO. Create a PAC file on your network and use Windows GPO to tell client browsers where to locate the PAC file. The PAC file indicates the proxy server URL (Barracuda Web Security Gateway) to which the browsers are to proxy user requests. In the PAC file you can also specify URL exceptions that won’t accept proxied requests. The advantages of this method are:

In the PAC file you can specify a primary and secondary Barracuda Web Security Gateway IP address so that if one is unavailable, the browser will proxy to the other.

You can specify URL exceptions in the PAC file for which you want user requests to bypass the Barracuda Web Security Gateway. These exceptions might include intranet sites or other sites that accept connections from particular ‘allowed’ IP addresses.

Method 2: Use a PAC file with autodetection via DHCP or DNS. This is an alternative to using a Windows GPO to propagate PAC file information to client browsers.With DHCP, updates to your clients can include PAC file location information along with dynamically assigned IP addresses and other attributes. Configure this in your DHCP server settings. With DNS, you can add a hostname wpad (web proxy auto discovery) to your domain name in the DNS server. The wpad contains the IP address where the PAC file is hosted on the network.

Method 3: Use a Barracuda Load Balancer or Barracuda Load Balancer ADC. This deployment makes sense if your network requires dynamic traffic load balancing. In this case, your client browsers will proxy traffic to a virtual IP address - the load balancing device - which then load balances traffic to the Barracuda Web Security Gateways. The Barracuda Load Balancer provides failover and dynamic traffic load balancing.

Method 4: Use Multiple A Records. For each Barracuda Web Security Gateway in the cluster, make an A record in your DNS server with the same hostname. Depending on what IP address to which the user',s machine resolved the hostname, they may get a proxy error.

Data Propagated to the Linked Systems

Linking systems together not only makes it easier to manage multiple Barracuda Web Security Gateways, but it also provides 100 percent redundant coverage of the propagated configuration and policy (Block/Accept) data. Table 2.2 identifies the data that is propagated to the other linked systems when a new system joins.

Propagated Data Data Not Propagated

System settings (global and domain) configured through the web System IP configuration (IP address, subnet mask, default interface. This includes the block/accept filters. gateway, and DNS server) configured on the BASIC > IP Configuration page. System password and time zone as configured on the BASIC > Administration page. Cluster hostname and cluster local host map configured on the ADVANCED > Linked Management page. Static route settings as configured on the BASIC > IP Configuration page. Branding image and image URL as configured on the ADVANC ED > Appearance page. VLAN configuration settings as configured on the ADVANCED > Advanced Networking page. Source-based routes as defined using the IP Routing feature. See the ADVANCED > Advanced Networking page. SSL Inspection Certificates as configured on the ADVANCED > SSL Inspection page. Kerberos and NTLM settings on the USERS/GROUPS > Authentication page.

Switching a System to Standby Mode

You can also use the ADVANCED > Linked Management page to switch a linked system from Active to Standby mode. When a system is in S tandby mode, it does not synchronize its configuration with the other active systems in the cluster.

Barracuda recommends switching a system to Standby mode when you need to:

Upgrade the firmware of all systems in a cluster. If a system is part of a cluster, Barracuda recommends changing the system’s mode to Standby before you upgrade its firmware, and then repeat this process on each system in the cluster. After the firmware on each system has been upgraded, you can then change the mode on each system back to Active. Changing a linked system to Standby mode before upgrading prevents a system on a more recent firmware version from trying to synchronize its configuration with a system on an earlier firmware version.

Perform maintenance that requires a system to be powered down or disconnected from your network. For example, if you need to physically move a Barracuda Web Security Gateway, you should change its mode to Standby so the other systems in the cluster do not try to synchronize their configuration while the system is down.

Linked Management Versus Barracuda Cloud Control

This article lists basic use cases for managing multiple Barracuda Web Security Gateways using either:

High Availability / Linked Management Barracuda Cloud Control

High Availability - Using Linked Management with the Barracuda Web Security Gateway

Using the Linked Management feature you can cluster, or link two or more Barracuda Web Security Gateways together to provide high availability. Additionally, linking multiple Barracuda Web Security Gateways automatically synchronizes most configuration settings and policies among the systems.This kind of deployment works well if you want all Barracuda Web Security Gateways in the cluster to use the same settings and policies.

1. Most configuration variables and policies are duplicated across cluster; you cannot have different settings except for those noted in the D ata Not Propagated list in High Availability - Clustering the Barracuda Web Security Gateway. 2. If both/all Barracuda Web Security Gateways are on the same network, then if one system goes down, the other system can continue to filter all web traffic if deployed with the proper network equipment. 3. All Barracuda Web Security Gateways in the cluster must be same model running the same firmware version.

See the ADVANCED > Linked Management page of the Barracuda Web Security Gateway web interface to configure. See also High Availability - Clustering the Barracuda Web Security Gateway.

Barracuda Cloud Control

Barracuda Cloud Control (BCC) is a comprehensive cloud-based service that enables administrators to monitor and configure multiple Barracuda Networks products from a single console. A key difference between BCC and Linked Management is that, with BCC management, you cannot duplicate exceptions (policies) across all Barracuda Web Security Gateways in a group automatically; you must configure policies on each system manually.

Some network environments may not be suitable to linking multiple Barracuda Web Security Gateway systems together as described above. For example:

If you have multiple Barracuda Web Security Gateways that are different models, you cannot use Linked Management, but you can manage them all with Barracuda Cloud Control.

if you have multiple network segments that each require different policies, it may be better to provide a dedicated, unlinked Barracuda Web Security Gateway for each segment. This way you can configure each Barracuda Web Security Gateway with unique policies and configuration settings.

For example, a university might have one or more Barracuda Web Security Gateways that allow most or all traffic for staff and faculty, and another Barracuda Web Security Gateway (or more) to filter student web traffic, blocking adult and gambling sites.

This is a typical use case for managing multiple Barracuda Web Security Gateways with Barracuda Cloud Control (BCC).

With Barracuda Cloud Control, you can check the health of all connected devices, configure different policies on each system, run reports that are generated by gathering data from all the devices, and assign roles with varied permissions to different types of users.

1. Useful for managing multiple Barracuda Web Security Gateways where you want to allow different configuration settings or policies. 2. Useful for viewing aggregated traffic statistics (via the dashboard) across all Barracuda Web Security Gateways. 3. You can mix multiple Barracuda Web Security Gateway models in this configuration.

When you have more than one of a Barracuda Networks product type connected to Barracuda Cloud Control, and you view the settings of all of them as a group (with one web interface), a yellow Exception ( ) icon displays if the value of the setting is not the same on all devices in the group. When you hover the mouse over the icon, Barracuda Cloud Control clearly indicates what the values for that setting are on each device, so that you can change the settings if desired. For example:

Before you can connect your Barracuda Networks products to Barracuda Cloud Control, you must first create an account, which is easy and free. See Create a Barracuda Cloud Control Account.

Inline Pass-through With Pre-existing Proxy Deployment

This deployment type is much less common than either Inline mode or Forward Proxy mode, and involves deploying the Barracuda Web Security Gateway as an inline device that uses a pre-existing proxy server on your network. This type of deployment is not recommended because infection reports do not display the IP addresses of infected clients.

Instead, Barracuda Networks recommends that you remove your pre-existing proxy server and deploy the Barracuda Web Security Gateway inline as described in Inline Pass-Through (Transparent) Mode Deployment.

The Barracuda Web Security Gateway can be placed on the client or the server side of the existing proxy server. If the existing proxy server is performing user authentication, then the Barracuda Web Security Gateway must be placed on the server side of the proxy. In this deployment, the Barracuda Web Security Gateway detects all network traffic. The proxy server connects directly to the Barracuda Web Security Gateway LAN port. This connection may require a crossover cable. No special port or IP address is required.

The Barracuda Web Security Gateway scans for all inbound and outbound HTTP traffic from the proxy server. All outbound traffic on other ports is scanned for normal spyware communication. However, since the proxy server will most likely hide user identity, the Barracuda Web Security Gateway cannot apply any user, group or IP based policies. Figure 1 below illustrates this deployment type.

Alternatively, the Barracuda Web Security Gateway can be placed inline on the client side of the existing proxy server. The LAN Switch can be connected to the LAN port of the Barracuda Web Security Gateway and the WAN port of the Barracuda Web Security Gateway can be connected to the Proxy Server. This will ensure that the Barracuda Web Security Gateway can identify users before the requests are proxied. In this configuration, you may have to ensure that the Barracuda Web Security Gateway passes client IP addresses through to the proxy server or that the proxy server can handle requests coming from the Barracuda Web Security Gateway’s IP address. However, this configuration may not work when the proxy server is performing strong user authentication.

The placement of your pre-existing proxy server and its functionality will have an impact on the Barracuda Web Security Gateway deployment. Some configurations may require technical assistance from Barracuda Networks Technical support. Please see Contacting Barracuda Networks Technical Support. To connect your Barracuda Web Security Gateway with this deployment mode, see Connecting Inline to your Network with a Pre-existing Proxy Server.

Figure 1: Inline Passthrough with Pre-existing Proxy Server Deployment.

Connecting Inline to your Network with a Pre-existing Proxy Server

This article follows Inline Pass-through With Pre-existing Proxy Deployment.

To set up the Barracuda Web Security Gateway inline with your existing proxy server, place the proxy server between the Barracuda Web Security Gateway and your internal network switch.

If you have a proxy server, most HTTP requests are routed from your internal network through the proxy server to the Barracuda Web Security Gateway. When a website responds, the responding traffic goes through the Barracuda Web Security Gateway, which filters any spyware and viruses before allowing the traffic to go through the proxy server and back to the clients.

The Barracuda Web Security Gateway has been tested with Microsoft ISA and Squid proxy servers.

To connect your Barracuda Web Security Gateway and existing proxy server to your network:

1. Connect your LAN port from your proxy server to the Uplink port of your internal network switch.

Figure 1: Proxy Behind the Barracuda Web Security Gateway.

2. Connect the Ethernet cable from your WAN port of your proxy server to the LAN port on the Barracuda Web Security Gateway. Note that

you do not need to configure the WAN port. The Barracuda Web Security Gateway creates an Ethernet bridge between the WAN and LAN ports.

A crossover cable may be needed if your corporate firewall does not have a switchable port and therefore cannot switch between RX and TX. Another solution is to place a switch between the corporate firewall and the Barracuda Web Security Gateway.

3. Connect an Ethernet cable from the WAN port on the Barracuda Web Security Gateway to the LAN port on your firewall. 4. Go to the BASIC > IP Configuration page in the web interface, and set the Operating Mode to Active.

Deploying the Barracuda Web Security Gateway with a Peer Proxy

In this deployment, the Barracuda Web Security Gateway is deployed inline or as a proxy and is configured to forward all port 80 traffic to a pre-existing proxy server. The proxy server can be anywhere on or off the network, and it sends filtered traffic from the Barracuda Web Security Gateway to the Internet. The Barracuda Web Security Gateway just needs to be configured with the IP address and port of the proxy server as described below.

Note: When the Barracuda Web Security Gateway is deployed inline, HTTP traffic will be forwarded to the peer proxy and HTTPS traffic will NOT be forwarded to the peer proxy.

For this deployment, configure the following on the ADVANCED > Proxy page of the Barracuda Web Security Gateway web interface:

1. Peer Proxy IP: Enter the IP address of a pre-existing proxy server which will forward traffic from the Barracuda Web Security Gateway to the Internet. 2. Peer Proxy Port: If you have a pre-existing proxy server, enter the port number used for HTTP requests.

Using SSL Inspection

If you have this feature enabled on the Barracuda Web Security Gateway, to protect sensitive data, it is recommended to only use SSL Inspection if the peer proxy server is deployed inside the firewall. To use SSL Inspection, see How to Configure SSL Inspection 6.x or How to Configure SSL Inspection 7.0.

Using Authentication

Authentication is supported with a peer proxy if the Barracuda Web Security Gateway is deployed in a proxy configuration. See Forward Proxy Deployment of the Barracuda Web Security Gateway.

Policy-Based Routing

Hidden as of 4/17/14 per Fleming - old

Support for policy-based routing applies to the Barracuda Web Security Gateway running version 6.x only.

Transparently Routing Web Traffic to the Barracuda Web Security Gateway

This article demonstrates how to route traffic to the Barracuda Web Security Gateway as a proxy without requiring proxy rules to be pushed out to all clients on the network. This method allows the Barracuda Web Security Gateway to forward HTTPS (443) traffic in addition to standard HTTP traffic, which cannot be done using other methods of transparent proxy routing.

The example shown in this article assumes a configuration with a Cisco Router with built-in Firewall Security Module (FWSM), but it should work with any routing equipment supporting Policy-Based Routing (PBR).

Run this command on the router Text in yellow boxes shows commands that need to be run on the router.

Installation of the Barracuda Web Security Gateway

For this configuration, you will need to connect the Barracuda Web Security Gateway LAN interface to its own dedicated port on the router. Give the Barracuda Web Security Gateway an IP address in its own dedicated IP subnet, and assign a gateway IP to the router interface that it is connected to. An example network is shown here:

Barracuda IP Address: 10.100.3.2/30 gateway 10.100.3.1

Internal Ranges: 10.100.1.0/24 (VLAN_1) 10.100.2.0/24 (VLAN_2)

Router Configuration

Step 1. Define 2 access lists

You must define two access lists because you need to create a route-map for both the internal and external interfaces of the router. These rules describe which clients will be routed to the Barracuda Web Security Gateway. Your routing rules will be different based on whether this is outbound or inbound traffic.

Run these commands on the router [ Inbound ] ip access-list extended HTTP(S)_Proxy_Inbound permit udp any eq domain 10.100.0.0 0.0.255.255 permit tcp any eq 443 10.100.0.0 0.0.255.255

[ Outbound ] ip access-list extended HTTP(S)_Proxy_Outbound permit tcp 10.100.0.0 0.0.255.255 any eq www permit tcp 10.100.0.0 0.0.255.255 any eq 443

Note that this is routing inbound DNS traffic back through the Barracuda Web Security Gateway. This is the key to making policy-based routing work for HTTPS traffic.

Step 2. Create route maps

Match these route-maps to the access lists you just created. Any traffic matching those lists will have the “match” rule applied to it. In this case, you are modifying the next-hop for the packet to the Barracuda Web Security Gateway's IP address. Note that you need two route-maps—one for inbound traffic, and one for outbound traffic.

Run these commands on the router [ Inbound ] route-map HTTP(S)_Proxy_Inbound permit 10

match ip address HTTP(S)_Proxy_Inbound set ip next-hop 10.100.3.2

[ Outbound ] route-map HTTP(S)_Proxy_Outbound permit 20 match ip address HTTP(S)_Proxy_Inbound set ip next-hop 10.100.3.2

Step 3. Apply route-maps to the interfaces on your router

The inbound route-map you created is applied to the outside (WAN-side) interface on your router/firewall. The outbound route-maps are applied to any internal interfaces on your router/firewall. This includes any sub-interfaces that are connected to client networks that need filtering.

[ Inbound ] interface FastEthernet0/1 description Test WAN ip address 1.1.1.2 255.255.255.0 ip access-group Inbound_Rules in no ip redirects no ip unreachables ip nat outside

Run this command on the router ip policy route-map HTTP(S)_Proxy_Inbound duplex auto speed auto

[ Outbound ] Note that there are two interfaces listed here—one for each VLAN on the test network. The outbound route-map rule needs to be enabled for each internal interface or sub-interface to be filtered. Start with one and test. interface FastEthernet0/0.1 description VLAN_1 encapsulation dot1Q 1 ip address 10.100.1.1 255.255.255.0 ip nat inside

Run this command on the router ip policy route-map HTTP(S)_Proxy_Outbound interface FastEthernet0/0.2 description VLAN_2 encapsulation dot1Q 2 ip address 10.100.2.1 255.255.255.0 ip nat inside

Run this command on the router ip policy route-map HTTP(S)_Proxy_Outbound

Sample Cisco IOS Configuration

! version 12.2 service timestamps debug uptime service timestamps log uptime service password-encryption ! hostname cisco ! boot system flash slot1:c3660-ik9o3s-mz.122-32.bin no logging monitor enable secret 5 ********** !

Copyright © 2017, Barracuda Networks Inc. Barracuda Web Security Gateway Administrator's Guide - Page 33 username seadmin privilege 15 password 7 ********** ip subnet-zero ip wccp web-cache redirect-list WCCP !! ip ftp username ********** ip ftp password 7 ********** ip domain-name ********** ! ip audit notify log ip audit po max-events 100 !! call rsvp-sync ! !! !! fax interface-type fax-mail mta receive maximum-recipients 0 !! ! interface FastEthernet0/0 description Test LAN no ip address ip nat inside duplex auto speed auto ! interface FastEthernet0/0.1 description Barracuda Systems encapsulation dot1Q 1 ip address 10.100.1.1 255.255.255.0 ip nat inside ip policy route-map HTTP(S)_Proxy_Outbound ! interface FastEthernet0/0.2 description Other OS (Windows, Mac, Linux...) encapsulation dot1Q 2 ip address 10.100.2.1 255.255.255.0 ip nat inside ! interface FastEthernet0/0.100 encapsulation dot1Q 100 native ! interface FastEthernet0/1 description CudaSE.net WAN ip address 1.1.1.3 255.255.255.0 secondary ip address 1.1.1.2 255.255.255.0 ip access-group Inbound_Rules in no ip redirects no ip unreachables ip nat outside ip policy route-map HTTP(S)_Proxy_Inbound duplex auto speed auto ! interface FastEthernet2/0 description HTTP(S) Proxy ip address 10.100.3.1 255.255.255.0 duplex auto speed auto ! ip nat inside source list Outbound_NAT interface FastEthernet0/1 overload ip classless ip route 0.0.0.0 0.0.0.0 1.1.1.1

Copyright © 2017, Barracuda Networks Inc. Barracuda Web Security Gateway Administrator's Guide - Page 34 no ip http server ! ! ip access-list extended HTTP(S)_Proxy_Inbound permit udp any eq domain 10.100.0.0 0.0.255.255 permit tcp any eq 443 10.100.0.0 0.0.255.255 ip access-list extended HTTP(S)_Proxy_Outbound permit tcp 10.100.0.0 0.0.255.255 any eq www permit tcp 10.100.0.0 0.0.255.255 any eq 443 ip access-list extended Inbound_Rules permit icmp any any echo permit icmp any any echo-reply permit icmp any any source-quench permit icmp any any packet-too-big permit icmp any any time-exceeded permit udp any any gt 1023 permit tcp any any ack deny ip any any ip access-list extended Outbound_NAT permit ip 10.100.1.0 0.0.0.255 any permit ip 10.100.2.0 0.0.0.255 any permit ip 10.100.3.0 0.0.0.255 any deny ip any any route-map HTTP(S)_Proxy_Inbound permit 10 match ip address HTTP(S)_Proxy_Inbound set ip next-hop 10.100.3.2 ! route-map HTTP(S)_Proxy_Outbound permit 20 match ip address HTTP(S)_Proxy_Outbound set ip next-hop 10.100.3.2 !! dial-peer cor custom ! !! !! line con 0 line aux 0 line vty 0 4 privilege level 15 login local transport input telnet ssh line vty 5 15 privilege level 15 login local transport input telnet ssh ! end

Source-Based Routing

This configuration is available with any type of Barracuda Web Security Gateway deployment.

See also:

Forward Proxy Deployment of the Barracuda Web Security Gateway Inline Pass-Through (Transparent) Mode Deployment Directing Traffic to the Barracuda Web Security Gateway Vx WCCP Deployment

If you have clients or networks that you want to route to the Internet via a different gateway than the default set for the Barracuda Web Security Gateway, you can configure routing by specifying the source and destination IP addresses and gateways using the IP Routing feature. See the ADVANCED > Advanced Networking page to set up source based routing.

For example, assume your organization has multiple physical locations. The server dedicated to Sales services and resources is located in Los Angeles, and a user in the Sales department at the Atlanta office needs to access those resources on the corporate intranet. Rather than use the default route to the cloud, the user has a secondary exit point (172.32.0.254) that handles all intranet activity across a dedicated connection to the 10.1.0.0/16 (Corporate Resources) network.

The Barracuda Web Security Gateway can look at traffic from the user’s machine (client) and direct the traffic to the appropriate gateway based on the source / destination of the traffic. If the packet is bound for a corporate resource, in this instance the Barracuda Web Security Gateway will route it out via the internal router, and all other traffic will proceed to the Internet via the Firewall.

Figure 1: Source Based Routing Provided by the Barracuda Web Security Gateway.

To set up the Barracuda Web Security Gateway per the above example, go to the IP Routing section of the ADVANCED > Advanced Networking page and configure the following settings. This example configures the Barracuda Web Security Gateway so that all client traffic from the 172.32.0.0 subnet routes to the specified Destination IP Address via the Gateway Address.

The IP addresses used in this example are just that - example addresses for demonstration purposes. Make sure to obtain the correct IP address and netmask values for your network for the actual configuration.

Setting Meaning and example value

Source IP Address IP address of client or network to be routed to the alternate gateway. Enter 172.32.0.0 for the subnet the client is coming from.

Source Netmask Netmask of client or network to route to the alternate gateway; enter 255.255.0.0.

Destination IP Address Alternate gateway (the corporate intranet, in this case) to which you want to route the client(s) or network. Enter 10.1.0.0.

Destination Netmask Netmask of alternate gateway. Enter 255.255.0.0.

Gateway Address Gateway address through which you're routing these clients/networks to the Internet - this would be the address of the Internal Router as shown above. Enter 172.32.0.254.

Dual Bridge Deployment 7.0

This deployment type is much less common than either Inline mode or Forward Proxy mode and is only available with the Barracuda Web Filter 910 or 1010 running version 7.0 and higher. For organizations wishing to filter two separate traffic streams through one Barracuda Web Filter, this deployment operates in Active/Active mode. The Barracuda Web Filter 910 and 1010 each have two LAN and WAN ports on the chassis. Traffic routed from two separate switches, for example, can each be routed to one LAN. Each LAN and WAN can be assigned different IP addresses.

IP config page from 1010 - need to get 7.0 from Bhavin when he has it, after release of 6.0.1.012 >

Deployment emulates two Barracuda Web Filters, where all settings except for the IP addresses of both ports are the same as applied to both traffic streams.

Figure 1: Dual Bridge Deployment

VLAN Deployments

VLAN - Bridge Configuration

The Barracuda Web Security Gateway can filter and route tagged traffic for multiple VLANs to the Internet, preserving the segregation of the VLANs on the WAN port (to the Firewall). In a VLAN deployment, the LAN and WAN ports behave like trunk ports much like a switch or router. For cases in which multiple VLANs need to send traffic through the Barracuda Web Security Gateway to the Internet, and you want to preserve the segregation of these VLANs, use the Bridge VLAN deployment, connecting multiple VLANs to the LAN side of the Barracuda Web Security Gateway.

You can also use this deployment configuration to route multiple networks (not VLANs, but untagged traffic) sending outbound traffic through the Barracuda Web Security Gateway.

Important Notes Barracuda recommends testing your VLAN deployment during low traffic periods or outside of regular business hours. Note that transporting multiple VLANs across the same Ethernet connection requires a trunk line. Bridge VLAN deployment is the most common. If you need to contact technical support you should have the Barracuda Web Security Gateway connected to see traffic into the unit. Also, having a network diagram available to show Barracuda Technical Support will greatly assist in understanding your deployment configuration. The Barracuda Web Security Gateway needs to be part of a VLAN to pass tagged 802.1Q traffic. To set up for 802.1Q traffic, you will need: A list of all VLANs that pass through the Barracuda (name and number). The Subnet mask for each VLAN. Corresponding Default Gateway IP addresses for each VLAN. An unused IP address within each VLAN that is exempt from DHCP.

For more details about VLAN configuration, click the Help button on the ADVANCED > Advanced Networking page.

Figure 1: Bridge VLAN Deployment.

To configure, from the web interface, navigate to the ADVANCED > Advanced Networking page. In the VLAN Configuration section, first select Bridge for VLAN Interface.You will need to create a name and ID for each VLAN. For example, if the marketing department is on one VLAN and the finance department is on another, call them MRK_VLAN and FIN_VLAN. Each ID should be unique, in the range specified on the ADVANCE D > Advanced Networking page.

Every VLAN or subnet that you are routing to the Barracuda Web Security Gateway needs to be associated with a valid IP address, and you make that association by creating a virtual interface. In the Virtual Interfaces section of the ADVANCED > Advanced Networking page, you will need to enter the IP address and associated information for each VLAN or subnet. Click the Help button on the page for details on VLAN configuration.

VLAN Deployment - LAN Configuration

If you have multiple VLANs or subnets and you want to filter the traffic but not expose the traffic outside of your network, use the LAN configuration of a VLAN deployment. In this case, all VLAN or subnet traffic is NAT'ed by the Barracuda Web Security Gateway and requests are proxied via the WAN port to the Internet.

Figure 2: LAN-VLAN Deployment.

To configure, from the web interface, navigate to the ADVANCED > Advanced Networking page. In the VLAN Configuration section, first select LAN for VLAN Interface. You will need to create a name and ID for each VLAN. Then, using the Virtual Interfaces section of the page, associate each VLAN with a Virtual Interface which is defined with an IP address, a Netmask and a Gateway address.

For example, if the marketing department is on one VLAN and the finance department is on another, you might name your VLANs "MRK_VLAN" and "FIN_VLAN". Each ID should be unique, in the range specified on the ADVANCED > Advanced Networking page. Click Help on the page for more details on VLAN configuration.

VLAN Deployment - System Configuration

Use the System VLAN when the Barracuda Web Security Gateway does NOT reside in the native VLAN. The system is now only accessible from its own VLAN. Set System VLAN to one of the VLAN Interfaces you added in the VLAN CONFIGURATION section of the ADVANCED > Advanced Networking page.

Virtual Deployment

Requirement This virtual appliance requires a 64-bit capable host.

The Barracuda Web Security Gateway combines spyware, malware, and virus protection with an Internet policy and reporting engine. It includes the following features:

Controls access to web sites, applications, and Web 2.0 platforms based on users, groups, time, bandwidth, and other criteria. Provides SSL-filtering and inspection to enforce policies on social-media and search platforms. Blocks spyware and virus downloads and restricts requests to malicious websites. Provides Safe Search and YouTube for Schools compatibility. Filters remote client Internet activity with the same policies for on-network users.

Deployment Considerations

Before setting up your Barracuda Web Security Gateway Vx, consider the best deployment option for your network configuration:

Forward proxy deployment. WCCP cache engine on a network with a WCCP-capable core routing platform.

Because the Barracuda Web Security Gateway Vx does not support inline deployments, application filtering is not supported. All other features and functions of the Barracuda Web Security Gateway appliance are supported by the Vx.

Deploying Your Barracuda Web Security Gateway Vx

Complete the following steps to deploy your Barracuda Web Security Gateway Vx:

1. Deploy the Barracuda Web Security Gateway Vx image. 2. Allocate the cores, RAM, and hard disk space for your Barracuda Web Security Gateway Vx. 3. Set up the Barracuda Web Security Gateway Vx with the Vx Quick Start Guide. 4. Direct traffic to the Barracuda Web Security Gateway Vx.

Managing Your Virtual Machine

Backing Up Your Virtual Machine System State VMware Tools

How to Deploy Barracuda Web Security Gateway Vx Images Barracuda offers the following types of images for the Barracuda Web Security Gateway Vx deployment. Follow the instructions for your hypervis or to deploy the Barracuda Web Security Gateway Vx appliance.

Image Type Supported Hypervisors

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

VMX VMware Server 2.x VMware Fusion 3.0, Player 3.x, and Workstation 6.x

XVA Citrix XenServer 5.5+

VHD Microsoft Hyper-V 8, 8.1, 2008 R2, 2012, 2012 R2, and 10

30 Day Evaluation For a 30 day evaluation:

1. Visit https://www.barracuda.com/purchase/evaluation. 2. Choose the Barracuda Web Security Gateway VX, and then choose the model size. Default size is Barracuda Web Security Gateway Vx 310. 3. Download the image for your hypervisor, as specified below, from the Barracuda Virtual Appliance Download page. After the download is complete, extract the files from the ZIP folder.

Deploy OVF Images

VMware ESX and ESXi (vSphere Hypervisor) 4.x

Use the OVF file ending in -4x. ovf for this hypervisor.

1. Download and expand the Barracuda Web Security Gateway Vx ZIP folder. 2. From the File menu in the vSphere Client, select Deploy OVF Template. 3. Select Import from file, navigate to the extracted folder, and locate the Barracuda Web Security Gateway Vx OVF file. Click Next. 4. Enter a name for the virtual appliance. 5. Set the network to point to the target network for this virtual appliance. 6. Follow the recommendations in Allocating Cores, RAM, and Hard Disk Space for Your Barracuda Web Security Gateway Vx. 7. Right-click the virtual appliance, select Open Console, and click the green arrow to power it on. 8. Follow the Barracuda Web Security Gateway Vx Quick Start Guide instructions to set up your virtual appliance.

VMware ESX and ESXi (vSphere Hypervisor) 5.x and 6.x

Use the OVF file ending in -5x.ovf or -6x.ovf for this hypervisor.

1. Download and expand the Barracuda Web Security Gateway Vx ZIP folder. 2. From the File menu in the vSphere Client, select Deploy OVF Template. The vSphere Client launches the Deploy OVF Template wizard. 3. Click Browse, navigate to the extracted folder, and locate the Barracuda Web Security Gateway Vx OVF file. Click Next. 4. Verify that you are installing the correct Barracuda virtual appliance. Click Next. 5. Enter a name for the virtual appliance. Click Next. 6. Select the destination storage for the virtual machine. Click Next. 7. Select a disk format. To ensure maximum stability when deploying your Barracuda Vx appliance, specify the disk format as Thick Provision Eager Zeroed. Click Next. 8. Map the network to the target network for this virtual appliance. Click Next. 9. Review the deployment options. Click Finish to deploy the virtual appliance. 10. Follow the recommendations in Allocating Cores, RAM, and Hard Disk Space for Your Barracuda Web Security Gateway Vx. 11. Locate the appliance within the appropriate virtual machine and resource pool. Select it and power it on by clicking the green arrow. 12. Click the Console tab. You can monitor the appliance as it is prepared for use. 13. Follow the Barracuda Web Security Gateway Vx Quick Start Guide instructions to set up your virtual appliance.

Sun/Oracle VirtualBox and VirtualBox OSE 3.2 Use the OVF file ending in -4x. ovf for this hypervisor.

1. Download and expand the Barracuda Web Security Gateway Vx ZIP folder.

2. From the File menu in the VirtualBox client, select Import Appliance. 3. Navigate to the extracted folder and locate the Barracuda Web Security Gateway Vx OVF file. 4. Select the file and click Next. 5. On the Import Settings screen, follow the recommendations in Allocating Cores, RAM, and Hard Disk Space for Your Barracuda Web Security Gateway Vx . Click Finish. 6. Start the appliance. 7. Follow the Barracuda Web Security Gateway Vx Quick Start Guide instructions to set up your virtual appliance.

Deploy VMX Images

VMware Server 2.x

Use the .vmx and .vmdk files for this hypervisor.

1. Download and expand the Barracuda Web Security Gateway Vx ZIP folder. 2. Navigate to the extracted folder and move the files ending in .vmx and .vmdk into a folder in your datastore (which you can locate from the Datastores list on your server's summary page). 3. From the VMware Infrastructure Web Access client's Virtual Machine menu, select Add Virtual Machine to Inventory. 4. Navigate to the folder in your datastore used in step 2 and select the file ending in .vmx. Click OK. 5. Follow the recommendations in Allocating Cores, RAM, and Hard Disk Space for Your Barracuda Web Security Gateway Vx. 6. Start the appliance. 7. Follow the Barracuda Web Security Gateway Vx Quick Start Guide instructions to set up your virtual appliance.

VMware Fusion 3.x, Player 3.x, and Workstation 6.x

Use the .vmx file for this hypervisor.

1. Download and expand the Barracuda Web Security Gateway Vx ZIP folder. 2. From the File menu, select Open a Virtual Machine. 3. Navigate to the extracted folder and select the file ending in .vmx. 4. Use the default settings and click Finish. 5. Follow the recommendations in Allocating Cores, RAM, and Hard Disk Space for Your Barracuda Web Security Gateway Vx. 6. Start the appliance. 7. Follow the Barracuda Web Security Gateway Vx Quick Start Guide instructions to set up your virtual appliance.

Deploy XVA Images

Citrix XEN Server 5.5+

Use the .xva file for this hypervisor. For XEN Server, you first import the virtual appliance template and then create a new virtual appliance based on that template. Step 1. Import the virtual appliance template:

1. Download and expand the Barracuda Web Security Gateway Vx ZIP folder. 2. From the File menu in the XenCenter client, select Import. 3. Click Browse, navigate to the extracted folder, and select the file ending in .xva. Click Next. 4. Select a server for the template. Click Next. 5. Select a storage repository for the template. Click Import. 6. Select a virtual network interface for the template. Click Next. 7. Review the template settings. Click Finish to import the template. Step 2. Create a new virtual appliance:

1. Right-click the virtual appliance template and select New VM wizard. 2. Select the virtual appliance template. Click Next. 3. Enter a name for the virtual appliance. Click Next. 4. For the DVD drive, select . Click Next. 5. Select a home server. Click Next. 6. Specify the number of virtual CPUs and memory for the virtual appliance. Follow the recommendations in Allocating Cores, RAM, and Hard Disk Space for Your Barracuda Web Security Gateway Vx. Click Next. 7. Select a virtual disk. Click Next. 8. Select a virtual network interface. Click Next. 9. Review the virtual appliance settings. Click Create Now. 10. When the virtual appliance is ready, right-click it and then click Start. 11. Follow the Barracuda Web Security Gateway Vx Quick Start Guide instructions to set up your virtual appliance.

Deploy VHD Images

Microsoft Hyper-V 8, 8.1, 2008 R2, 2012, 2012 R2, and 10

Use the .vhd file for this hypervisor.

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

To take advantage of Microsoft's VHDX support on Hyper-V 2012, 2012 R2, and 10, follow the instructions in How to Convert and Replace a Barracuda Virtual Appliance VHD File with a VHDX Format File.

Allocating Cores, RAM, and Hard Disk Space for Your Barracuda Web Security Gateway Vx Barracuda recommends the following settings for the initial deployment of your virtual appliance or when upgrading existing installations.

Cores, RAM, and Hard Disk Space for the Barracuda Web Security Gateway Vx

Model Cores RAM - Recommended Hard Disk - Recommended Minimum Minimum

310 Vx 2 4 GB 200 GB

410 Vx 4 8 GB (1) 200 GB

610 Vx 6 (2) 16 GB 500 GB

Note:

(1) To enable SSL Inspection on the Barracuda Web Security Gateway 410, you must have a minimum of 4 GB of RAM.

(2) To increase the performance of this model, you should plan on adding 2 GB of RAM for each additional core. Also plan to add additional hard disk space. To purchase licenses for additional cores, contact your Barracuda sales representative.

Allocating Cores

In your hypervisor, specify the number of cores to be used by the Barracuda Web Security Gateway Vx. Each Barracuda Web Security Gateway Vx model can use only the number of cores specified in the table above. For example, if you assign 4 cores to the Barracuda Web Security Gateway 310 Vx (which supports only 2 cores), the hypervisor disables the 2 extra cores that cannot be used.

To add cores to your appliance:

1. Shut down the Barracuda Web Security Gateway Vx in your hypervisor. 2. In the virtual machine CPU settings, add cores.

Your hypervisor license and version might limit the number of cores that you can specify for your appliance. In some cases, you must add cores in multiples of two. For example, if your system has 4 CPU sockets and each socket has a quad core CPU, you could allocate 2 cores for each of the CPUs (8 cores in total). You might need to increase the RAM to compensate for the additional cores. If you allocate more cores than are available to the hardware, the system does not allocate additional resources.

Allocating Hard Disk Space

Barracuda requires a minimum of 200 GB of hard disk space to run your Barracuda Web Security Gateway Vx. From your hypervisor, you can specify the size of the hard disk or add a hard disk.

To specify the allocated hard disk space or add a hard disk to your appliance:

1. Shut down the Barracuda Web Security Gateway Vx in your hypervisor. 2. Take a snapshot of the virtual machine. 3. In the virtual machine settings, specify the new size for the hard disk or add a new hard disk. 4. Restart the virtual machine. As the appliance is booting up, view the console for Barracuda Web Security Gateway Vx. When the blue Barracuda console screen appears and asks if you want to use the additional hard disk space, enter Yes.

If you do not respond to the prompt in 30 seconds, the answer defaults to No . Resizing can take several minutes, depending on the amount of hard disk space specified.

Next Step

For instructions on how to set up the Barracuda Web Security Gateway Vx, see the Barracuda Web Security Gateway Vx Quick Start Guide.

Barracuda Web Security Gateway Vx Quick Start Guide Use the steps in this article to set up your Barracuda Web Security Gateway Vx.

For Forward Proxy mode deployment limitations, refer to Limitations of this Deployment Type in the article Forward Proxy Deployment of the Barracuda Web Security Gateway .

Before You Begin

Deploy the Barracuda Web Security Gateway Vx on your hypervisor . You will need only a single virtual NIC on your virtual appliance.

Step 1. Configure Your Firewall

You need to configure your network firewall to allow ICMP traffic to outside servers as well as opening port 443 to updates.cudasvc.com. You also need to make sure that your DNS servers can resolve updates.cudasvc.com.

Step 2. Start the Virtual Appliance, Configure Networking, and Enter the License

You should have received your Barracuda Vx license token via email or from the website when you downloaded the Barracuda Web Security Gateway Vx package. If not, you can request an evaluation on the Barracuda website https://www.barracuda.com/purchase/evaluation or purchase one from https://www.barracuda.com/purchase/index. The license token looks similar to the following: 01234-56789-ACEFG.

1. In your hypervisor client, start the virtual appliance and allow it to boot up. 2. Log in to the console as admin with the password admin. 3. Arrow down to TCP/IP Configuration. Set the System IP Address, Subnet Mask, Default Gateway, Primary DNS Server, and Secon dary DNS Server for your virtual appliance. These fields can later be edited if needed from the BASIC > IP Configuration page in the product web interface. 4. Arrow down to Licensing and enter your Barracuda License Token and default domain to complete provisioning. 5. Arrow down to Save Changes and press Enter. The appliance will reboot at this time as a part of the provisioning process. 6. After the virtual appliance has finished rebooting, go to http://:8000 to access the web interface and finalize configuration.

Step 3. Accept the End User License Agreement and Verify Configuration

1. Go to http://:8000 to access the web interface. 2. Read through the End User License Agreement. Scroll down to the end of the agreement. 3. Enter the required information: Name, Email Address, and Company (if applicable). Click Accept. You are redirected to the Login page. 4. Login to the Barracuda Web Security Gateway Vx web interface as the administrator: Username: admin Password: admin 5. Go to the BASIC > IP Configuration page and enter values for Default Hostname and Default Domain. For example, enter barracuda as the Default Hostname and as the Default Domain. These names will be associated with anti-spyware email notification messages from the virtual appliance. 6. Note that, unlike the Barracuda Web Security Gateway appliance, there is no need or facility to set Operating Mode for the Barracuda Web Security Gateway Vx. This is because, in Forward Proxy deployment, Audit mode works just like Active mode; traffic is logged and policies are applied. 7. Click the Save Changes button to save all of the information.

Step 4. Update the Firmware

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

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

Step 5. Update the Category Definitions

Barracuda recommends that you update the web content category definitions on a newly installed Barracuda Web Security Gateway Vx (this step is not necessary on a physical appliance). The content categories are used to block web sites.

Navigate to the ADVANCED > Energize Update page.

1. Scroll down to the Category Definitions Update section. 2. Click Update to get the latest web category definitions.

Step 6. Change the Administrator Password

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

Next Step

Continue with Directing Traffic to the Barracuda Web Security Gateway Vx. See also Allocating Cores, RAM, and Hard Disk Space for Your Barracuda Web Security Gateway Vx.

Directing Traffic to the Barracuda Web Security Gateway Vx There is no need to shut down your virtual machine when making changes to network connections. On your hypervisor, go to Networks and choose from available networks on your switches. If adding a network adaptor to the virtual machine, you must first shut it down.

For Forward Proxy mode deployment limitations, refer to Limitations of this Deployment Type in the article Forward Proxy Deployment of the Barracuda Web Security Gateway.

Determine Your Deployment Scenario

The Barracuda Web Security Gateway Vx can be deployed in any configuration except for inline. Deploy your Vx:

1. Using a Forward Proxy Deployment. You can deploy the Barracuda Web Security Gateway Vx in forward proxy mode via PAC file or GPO. This is the most common deployment scenario. See Forward Proxy Deployment of the Barracuda Web Security Gateway. 2. As a WCCP cache engine on a network with a WCCP capable core routing platform. 3. With the Barracuda Web Security Agent installed on remote Windows and Macintosh machines. See Using the Barracuda WSA With the Barracuda Web Security Gateway.

Once you have installed your Barracuda Web Security Gateway Vx and configured your firewall, you can test the configuration using the ADVAN CED > Troubleshooting page in the web interface to ping updates.barracudacentral.com.

Backing Up Your Virtual Machine System State

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

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

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

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

WCCP Deployment

For maximum security, Barracuda recommends placing your Barracuda Web Security Gateway behind a corporate firewall.

The Barracuda Web Security Gateway 410 and 410 Vx and above can be deployed as a WCCP cache engine on a network with a WCCP capable core routing platform. Because the WCCP control router or layer 3 switch transparently redirects content requests, you don't need to configure end users' browsers to use the Barracuda Web Security Gateway as an HTTP proxy. Note the two different deployment diagrams for filtering HTTP traffic only versus filtering both HTTP and HTTPS traffic. HTTPS support with this deployment requires running the Barracuda Web Security Gateway 6.0.1 or higher.

In addition to compatibility with other WCCP capable routers, the Barracuda Web Security Gateway supports a Cisco layer 3 switch with at least one VLAN, WCCPv2, GRE encapsulation, and the HASH routing method. Layer 2 masks are not supported. Check your Cisco Systems documentation for the recommended router/switch/firewall interface configurations; also see examples below.

Using a Cisco Adaptive Security Appliance (ASA) This article refers to deployment with a WCCP-enabled router or layer 3 switch. If you are using WCCP with a Cisco Adaptive Security Appliance (ASA), see WCCP Deployment With the Cisco ASA to configure your ASA to work with the Barracuda Web Security Gateway.

Make sure to use the Barracuda Web Security Gateway LAN port to connect to your WCCP enabled router or switch. If you are using the Barracuda Web Security Gateway 1010 or 1011, you must use the LAN1 port.

High Availability and Load Balancing

Enabling WCCP on your Barracuda Web Security Gateway allows you to take full advantage of your WCCP capable Cisco router’s ability to provide for failover and load balancing for multiple Barracuda Web Security Gateways connected to the router in a proxy configuration. For large installations requiring high availability and fault tolerance, this is an attractive deployment option. Other ways to achieve high availability with or without using WCCP are discussed in High Availability - Clustering the Barracuda Web Security Gateway.

Considerations when using the WCCP deployment

WCCP allows Cisco routers/switches to forward non-HTTP traffic to web cache servers, but the Barracuda Web Security Gateway only accepts HTTP/HTTPS traffic (port 80/443) in this configuration. WCCP also allows multiple Cisco routers to be connected to the same web cache server. The Barracuda Web Security Gateway does not support this feature and can only be connected to one WCCP router/switch. However, as always, multiple Barracuda Web Security Gateways can be connected to a single router/switch.

Also note the following:

NTLM and Kerberos authentication mechanisms will not work because they both require that the Barracuda Web Security Gateway be a trusted host in the Windows Domain and that it receive traffic directly from users (as a proxy). In WCCP deployments, the Barracuda Web Security Gateway receives outgoing traffic via the Cisco Router. Application blocking will not work. Outbound spyware will not be blocked.

HTTPS traffic will be also be filtered if (if you are running version 6.0.1 or higher) if Enable HTTPS Filtering is set to Yes on the BLOCK/ACCEP T > Configuration page.To filter HTTPS traffic in this mode, make sure to configure the Cisco WCCP services as follows:

Enable Service ID 80 for HTTPS Enable Service ID 90 for DNS UDP traffic Enable Service ID 91 for DNS TCP traffic Enable Service ID 0 for web cache

Figure 1 shows deployment with a WCCP router for filtering HTTP traffic only. For filtering HTTP and HTTPS traffic, see Figure 2. See the BASIC > IP Configuration page to select and configure WCCP deployment.

Figure 1: WCCP Deployment for filtering HTTP traffic only

Figure 2 below shows deployment with a WCCP router for filtering both HTTP and HTTPS traffic. In this deployment, the Barracuda Web Security Gateway uses a physically separate gateway to the internet relative to the WCCP router. This configuration is appropriate if your switch does not support VLANs and you want to filter both HTTP and HTTPS traffic with your WCCP router. See the BASIC > IP Configuration page to select and configure WCCP deployment.

Figure 2: WCCP Deployment for filtering HTTP and HTTPS traffic with a separate gateway for the Barracuda Web Security Gateway.

Figure 3 below shows deployment with a WCCP router for filtering both HTTP and HTTPS traffic, and a high availability (HA) deployment of two Barracuda Web Security Gateways. In this deployment, each Barracuda Web Security Gateway connects to your enterprise-class switch via a separate VLAN. This configuration is appropriate if your switch supports VLANs and you want to filter both HTTP and HTTPS traffic with your WCCP router. See the BASIC > IP Configuration page to select and configure WCCP deployment. Note that you can filter both HTTP and HTTPS traffic with just one Barracuda Web Security Gateway or with multiple, as shown in this example.

Figure 3: WCCP Deployment for filtering HTTP and HTTPS traffic with the Barracuda Web Security Gateway on a separate VLAN.

WCCP Deployment With the Cisco ASA WCCP is a method by which a Cisco Adaptive Security Appliance (ASA) firewall can redirect traffic to a WCCP caching engine through a generic routing encapsulation (GRE) tunnel. In this case, the WCCP caching engine is the Barracuda Web Security Gatewy. If you're using a WCCP-enabled router, see WCCP Deployment. This article focuses on configuring the ASA for a WCCP deployment with the Barracuda Web Security Gatewy. After configuring your ASA, refer to WCCP Deployment for notes on configuring the Barracuda Web Security Gateway for WCCP. This deployment is supported by the Barracuda Web Security Gateway 410 and 410 Vx and higher.

Limitations and Requirements of a WCCP Deployment With an ASA

The ASA needs to be configured to exempt Barracuda IP ranges from redirection. Specifically, Barracuda subnet 64.235.144.0/20 should be exempted from WCCP redirection. For example, you could configure access-list wccp-traffic extended deny ip any 64.235.144.0 255.255.240.0 . Check your ASA documentation for correct syntax. The only topology that the adaptive security appliance (ASA) supports is when both the client and the cache engine (the Barracuda Web Security Gatewy, in this case) are behind the same interface of the ASA and the cache engine can directly communicate with the client without going through the adaptive security appliance.

You should choose the WCCP Router ID IP address as the highest IP address configured on the ASA. If that IP address happens to be in the DMZ interface, or in the outside interface, that IP address must be routable to the Barracuda Web Security Gatewy. In other words, the Barracuda Web Security Gateway has to have a route to get to that Router-ID address pointing to the ASA's interface. See the WCC P RouterID IP setting on the BASIC > IP Configuration page in the Barracuda Web Security Gateway web interface. Due to the Cisco ASA limitations on redirecting DNS responses, the Barracuda Web Security Gateway is not able to log all HTTPS traffic. The only traffic that can be logged is HTTPS traffic that is being inspected and the HTTPS URLs that are blocked.

How WCCP Works With the Barracuda Web Security Gateway and the ASA

When a client makes a request to a website, the ASA receives the request and redirects it to the Barracuda Web Security Gateway in an encapsulated GRE packet to avoid any modifications to the original packet. The Barracuda Web Security Gateway receives the packet, applies policies, and routes the request to the ASA or to the Internet.

How to Configure Your ASA for a WCCP Deployment With the Barracuda Web Security Gatewy

1. Configure an access-list containing all Barracuda Web Security Gatewys on your network. In this example, there is only one Barracuda Web Security Gateway deployed.

ASA(config)#access-list wccp-servers permit ip host any

2. Create an access-list of the traffic that needs to be re-directed to the Barracuda Web Security Gatewy.

ASA(config)#access-list wccp-traffic permit ip any

3. Enable WCCP on the ASA.

ASA(config)#wccp web-cache group-list wccp-servers redirect-list wccp-traffic

4. Enable WCCP redirection on the inside interface (internal network). The standard service is web-cache, which intercepts TCP port 80 (HTTP) traffic and redirects that traffic to the Barracuda Web Security Gatewy.

ASA(config)#wccp interface inside web-cache redirect in

5. Enable WCCP to redirect HTTP traffic to the Barracuda Web Security Gateway using service web-cache. Verify with the WCCP router provider (e.g. Cisco) regarding service IDs that are supported.

ASA(config)#wccp interface inside service web-cache redirect in

6. Configure the ASA to redirect HTTPS traffic: ASA(config)#wccp 80 group-list wccp-servers redirect-list wccp-traffic

ASA(config)#wccp 90 group-list wccp-servers redirect-list wccp-traffic

ASA(config)#wccp 91 group-list wccp-servers redirect-list wccp-traffic

ASA(config)#wccp 70 group-list wccp-servers redirect-list wccp-traffic

ASA(config)#wccp interface inside 80 redirect in

ASA(config)#wccp interface inside 90 redirect in

ASA(config)#wccp interface inside 91 redirect in

Barracuda Web Security Gateway Administrator's Guide - Page 55

ASA(config)#wccp interface inside 70 redirect in

Enable SSL Inspection on the Barracuda Web Security Gateway version 8 - 10:

For the Barracuda Web Security Gateway 610 and higher, select Transparent for the SSL Inspection Method on the ADVANCED > SSL Inspection page of the Barracuda Web Security Gateway web interface. See How to Configure SSL Inspection Version 7.1 for details on configuration. For the Barracuda Web Security Gateway 410, set Enable SSL Inspection to Yes on the BLOCK/ACCEPT > Configuration page of the Barracuda Web Security Gateway web interface.

Enable SSL Inspection on the Barracuda Web Security Gateway version 11:

For the Barracuda Web Security Gateway 410 and higher, select Transparent for the SSL Inspection Method on the ADVANCED > SSL Inspection page of the Barracuda Web Security Gateway web interface. See How to Configure SSL Inspection Version 10 and Above for details on configuration. For the Barracuda Web Security Gateway 310, set Enable SSL Inspection to Yes on the BLOCK/ACCEPT > Configuration page of the Barracuda Web Security Gateway web interface.

Finally, follow instructions in the WCCP Deployment article to configure the Barracuda Web Security Gateway.

Show and Debug Commands

Use these commands to help with configuration and debugging of the deployment. show wccp web-cache show wccp interface debug wccp event debug wccp packets

Proxying Web Traffic Using a PAC File

Whether connecting your Barracuda Web Security Gateway Inline or in Forward Proxy configuration, you might want to use a Proxy Auto-Configuration (PAC) file to distribute a set of rules for where to route/proxy web traffic from client browsers to the Barracuda Web Security Gateway, to intranets or to the internet.

You can create a custom PAC file and use a windows Group Policy Object (GPO) to push out proxy settings to client browsers. This method of proxying web traffic to the Barracuda Web Security Gateway has the following advantages:

You can automatically configure all client browsers with proxy instructions rather than manually configuring them. A PAC file affords a lot of flexibility since you can optionally proxy specific traffic - domains, URLs, internal versus external traffic - to one or more specific Barracuda Web Security Gateways, or directly to the internal or external internet. You can set up load balancing of web traffic and failover (with multiple Barracuda Web Security Gateways) in case one system is not available.

How a PAC File Works

A PAC file is a specialized JavaScript function definition that a browser calls to determine how web requests are handled. The web browser fetches this PAC file before retrieving other pages. The JavaScript function "FindProxyForURL(url, host)" in the PAC file returns a string with one or more access method specifications. These specifications cause the user agent to either use a particular proxy server or to connect directly to the internet. The examples below give various scenarios in which you might want to proxy certain web traffic, while routing other web traffic directly to the internet or intranet.

Examples of PAC File Commands

In Example1 below, you want client browsers to manually proxy certain SSL traffic (https://mail.google.com, for example) to port 3128 of your Barracuda Web Security Gateway, and you'll use a PAC file like this example to define this for the browsers.

Example 1

When the client makes a request to a website, the web browser refers first to the PAC file. If the client is using a local network address, the specified proxy server (Barracuda Web Security Gateway) is used on the specified port. If the client is not using a local network address (example: a user is connecting from a hotel), the PAC file instructs the web browser to connect directly to the Internet. proxy.pac

function FindProxyForURL(url,host)

{ if (isInNet(myIpAddress(), "10.175.175.0","255.255.255.0")) { return "PROXY 10.170.2.252:3128";

} else { return "DIRECT";

}

Example 2

In a PAC file, you can provide for failover by specifying multiple Barracuda Web Security Gateways to proxy traffic to in order of precedence. Or you could load balance traffic by indicating in the PAC file that traffic to ODD IP addresses should proxy to BarracudaWebFilter1 and traffic to EVEN IP addresses should proxy to BarracudaWebFilter2. This example PAC file includes these and other scenarios of proxying specific traffic to a particular Barracuda Web Security Gateway or directly to the internal or external internet. function FindProxyForURL(url, host) {

// Array of domains not to send to a proxy: these domains, for example, would be domains you trust and don't need to filter. var no_proxy = new Array("barracuda.com", "barracudanetworks.com", "mydomain.com", "yourdomain.org");

// If URL has no dots in host name, send traffic direct. if (isPlainHostName(host)) { return "DIRECT"; } // If specific URL needs to bypass proxy, send traffic direct. for(var i=0;i < no_proxy.length; i++)

{ if (shExpMatch(url, no_proxy[i])) { return "DIRECT"; } }

// If you don't want to filter internal web traffic: // If IP address is internal or hostname resolves to internal IP, send direct.

var resolved_ip = dnsResolve(host);

if (isInNet(resolved_ip, "10.0.0.0", "255.0.0.0") || isInNet(resolved_ip, "172.16.0.0", "255.240.0.0") || isInNet(resolved_ip, "192.168.0.0", "255.255.0.0") || isInNet(resolved_ip, "127.0.0.0", "255.255.255.0")) { return "DIRECT"; } // If you want to load balance traffic, you can, for example, send odd IPs to one Barracuda Web Security Gateway // and even IPs to 2nd Barracuda Web Security Gateway. // Each PROXY command specifies two Barracuda Web Security Gateways; if one is not available, traffic goes to the other one (fail-over). var proxy; var myip=myIpAddress(); var ipbits=myip.split("."); var myseg=parseInt(ipbits[3]);

//based on the 4th octet being even or odd we'll change proxy priority if (myseg==Math.floor(myseg/2)*2) { // Even proxy = "PROXY gbobarwebv02.yourdomain.org:3128; PROXY gbobarwebv01.yourdomain.org:3128; DIRECT"; } else { // Odd proxy = "PROXY gbobarwebv01.yourdomain.org:3128; PROXY gbobarwebv02.yourdomain.org:3128; DIRECT";

} return proxy; }

Filtering Traffic for Offsite and Mobile Users

Remote Filtering enables your IT department to provide and control content security beyond the perimeter of the IT infrastructure. For satellite offices, remote and mobile workers, and students, the Remote Filtering feature allows secure web browsing access from laptops, Chromebooks, remote desktops, iPhones and iPads from any location. Web traffic from these devices is subject to the same web access and security policies of the organization. The Remote Filtering feature is available for use with the Barracuda Web Security Gateway model 410 and higher, and is also available with the Barracuda Web Security Service cloud solution.

Barracuda provides the following solutions for filtering remote traffic so you can choose how you protect your remote and mobile users online:

Laptops and desktops – On each remote Windows desktop, laptop or Macintosh OS X computer, deploy the Barracuda Web Security Agent (WSA) to do one of the following: Proxy all web traffic over the Internet through a specific Barracuda Web Security Gateway, which can monitor traffic and apply web security policies before routing that traffic to the internet. With the Barracuda Web Security Gateway version 10 and higher, SSL Inspection is also available for these deployments on the Barracuda Web Security Gateway 310 and higher. OR Look up and apply company policies to client web traffic before routing it to the internet, without passing traffic through the Barracuda Web Security Gateway. For this option, see Policy Lookup Only Mode With the Barracuda Web Security Agent.

Important When Policy Lookup Only mode is enabled, traffic is not routed through the Barracuda Web Security Gateway, so S SL Inspection cannot be applied to HTTPS traffic from remote computers.

Chromebooks – The Barracuda Chromebook Security Extension can be installed on Chromebooks to enforce security policies provided by the Barracuda Web Security Gateway. The extension provides control and visibility over both HTTP and HTTPS traffic, and does not send any user generated traffic through the Barracuda Web Security Gateway, but instead, synchronizes policy and report data between the Chromebook and the Barracuda Web Security Gateway. You can configure Barracuda Chromebook Security Extension on the ADVA NCED > Remote Filtering page. See How to Get and Configure the Barracuda Chromebook Security Extension. iOS Devices – Barracuda Mobile Device Manager: Manage mobile devices from the cloud, and deploy applications and resources to mobile devices. The Barracuda Mobile Device Manager Service provides a web interface for the administrator to configure the service, along with and the Barracuda Mobile Companion application for end users. Protect and apply secure browsing policies for groups of students, employees, and guests who are using their personal mobile devices inside or outside of your network, or manage business or institutionally owned devices within your network. Barracuda Safe Browser: Deploy on iOS mobile devices in place of the native browser, applying the same security policies as those applied by the Barracuda Web Security Gateway to other users in the rest of your network. If you have a Barracuda Web Security Gateway running version 6.x or higher, you can deploy and use the Barracuda Safe Browser on mobile devices running on and off of the network.

Release Notes - Barracuda Web Security Agent for Macintosh Barracuda Web Security Agent for Macintosh requires Mac OS X 10.9 or later.

What's New in Version 2.0.1.6

Fixed: Web pages load as expected without delays. Fixed: The Barracuda WSA does not fail open/closed after a blocked request. Fixed: Barracuda WSA does not create duplicate entries in Barracuda Web Security Gateway web logs. Improvements to diagnostics and profiling.

What's New in Version 2.0

Client-side SSL inspection - Configured on the Barracuda Web Security Gateway, client-side SSL inspection offloads this processing-intensive feature to the Mac, resulting in improved overall performance of the Barracuda Web Security Gateway. See Client-s ide SSL inspection for Mac OS X for details. This feature requires running MacOS X 10.9 or later. Enhanced authentication mechanism with the Barracuda Web Security Gateway - The Barracuda iWSA can use certificates you create on, or upload to, the Barracuda Web Security Gateway to verify the identity of the Barracuda Web Security Gateway and ensure that administrative traffic (configuration, policy requests, and logging) is encrypted, both on the local intranet and when roaming on untrusted networks. See Authentication with the Barracuda Web Security Gateway and the Barracuda WSA for details. This feature requires running MacOS X 10.9 or later.

What's New in Version 1.5.2

Running version 1.5.1 of the Barracuda Web Security Agent (iWSA) requires MacOS X 10.6 (Snow Leopard) or later; however, MacOS X 10.9 (Mavericks) or later is recommended. This update, or 2.0, is recommended for all users of WSA for Macintosh.

Fully tested against MacOS X 10.11 "El Capitan". Fixes bug in "Check for Updates" on MacOS X 10.6. Additional security to settings and log files.

What's New in Version 1.5.1

This update is recommended for all users of WSA for Macintosh.

Local and network security improvements Updated default administrative handshake Anonymized version reporting for product planning

What's New in Version 1.5.0

Added support for MacOS X 10.10 (Yosemite) Compatible with service hosts patched for HeartBleed and SSL POODLE New Barracuda branding

Fixed in version 1.5.0

Improved compatibility with Google Apps and iCloud Improved compatibility with built-in MacOS services Faster policy lookups and network connections Faster recovery from network failures Fixes issues with Policy Lookup Only mode

What's New in Version 1.4.0

Running version 1.4.0 of the Barracuda Web Security Agent (iWSA) requires MacOS X 10.6 (Snow Leopard) or later.

Host Fallback feature - The Barracuda WSA checks the current response times of all Barracuda Web Security Service hosts and ranks them accordingly. Rankings are viewable by the admin, and the admin can choose to have the Barracuda WSA automatically switch hosts to the fastest or to set the service host manually. See Fallback Service Hosts and the Barracuda Web Security Service for details. NOTE: This feature is not active by default; you must set it to be active in the profile and sync with clients. Improved compatibility with IPv6 services.

Fixed in Version 1.4.0

Works as expected with AirDrop file sharing tool on MacOSx. Barracuda Web Security Agent installer works as expected. Reduced administrative traffic between the client and service host. Increased security in proxy process.

What's New in Version 1.3.1

Added support for MacOS X 10.9 Mavericks and the most recent version of Safari browser. Improved compatibility with Flash networking requests.

Fixed in Version 1.3.1

Temporary server error is no longer treated as a hard network failure.

What's New in Version 1.3.0

General Availability: 8/2/13

Added support for secure Barracuda Web Security Service connections over port 8443. Improved HTTP 1.1 compatibility.

Fixed in Version 1.3.0

The YouTube for Schools feature works in Policy Lookup Only (PLO) mode. Works with PLO mode when the Barracuda Web Security Gateway is unreachable. Resolved connection issue after correcting an invalid Barracuda Web Security Service auth key. IPv6 requests do not trigger fail open.

What's New in Version 1.2.2

General Availability: 07/06/12 The Barracuda Web Security Agent for Mac now passes along applicable LDAP credentials in the request headers.

Fixed in Version 1.2.2

Improved logging for administrative requests and resolved startup problems which occurred on some systems.

Mac OS X 10.6/10.7/10.8 will no longer be supported after May 31, 2016. If you are running any of these versions, please upgrade to Mac OS X 10.9 or later.

Release Notes - Barracuda Web Security Agent for Windows

Important If you have the Barracuda Web Security Agent (WSA) version less than 4.4.3.15 and auto update is currently disabled, you must first manually upgrade to version 4.4.4 or higher if you intend to re-enable auto update. This is necessary in order to comply with higher security standards recently instituted by Microsoft for signing certificates used by the Barracuda WSA.

When upgrading your system from Windows 7 (or lower) to Windows 8 (or later), the Barracuda WSA needs to be reinstalled unless you upgrade to version 4.4.6. IMPORTANT: Follow these steps in order:

Uninstall the Barracuda WSA from the Windows machine. Upgrade your OS to Windows 8 or later. Re-install the Barracuda WSA on the Windows machine.

Note: Windows XP/Vista/Server 2003 versions are no longer supported for the Barracuda WSA. If you are running any of these versions, please upgrade to a supported Windows operating system.

What's New in Version 4.4.6

Ability to override use of LSP interception technology with WFP for Windows 7 users. Choosing WFP over LSP can mitigate compatibility issues between the Barracuda WSA and 3rd party applications such as antivirus applications, resulting in better stability. You can choose WFP at installation time or using the Configuration Tool for Barracuda WSA Windows Client. Does not apply for Windows 8+, which uses WFP by default. Barracuda uses SHA-256 code signing for all Barracuda binaries for all supported platforms and OS versions. If you are running Windows 7 and want to be able to use WFP or Tamper Protection, you must install the Microsoft Security Advisory 3033929 security patch. Some Windows 7 installations may run into difficulties when using Tamper Protection or switching between LSP and WFP drivers for traffic interception. These features will not work as expected, as Windows 7 needs the patch to trust the SHA-256 signed kernel-mode drivers. Fail Open/Fail Closed trigger granularity - Previously, connectivity (health) checks were triggered by system events including log on, sync, network address changes, etc. This version provides more granular connectivity checking based on internal connection errors, resulting in more accurate triggering of Fail Open and Fail Closed modes as well as recovery from Fail Open / Fail Closed modes.

Fixed in 4.4.6

Fixed: Updated installer to mitigate issue of IE crashing in some scenarios. [BNWSA-1375] Fixed: The Barracuda WSAMonitor icon no longer appears when in silent mode when auto updated from 4.4.5.39. [BNWSA-1685] Fixed: Toggling the Auto Update state to ON no longer requires a re-login / reboot of the machine in order to be applied. [BNWSA-1799] Fixed: In some cases, the Barracuda WSA would go to Inline Mode, even if not behind a Barracuda Web Security Gateway. [BNWSA-1851]

What's New in Version 4.4.5

Important: When auto-upgrading on silent installation, the Barracuda WSA Monitor icon can, in some cases, show on the client after the update is complete. To avoid this issue, Barracuda recommends pushing the upgrade by GPO or doing a manual installation.

Fail Open/Fail Closed behavior customization option - The administrator can override the default behavior of the FailOpen/FailClosed feature in terms of: Retry interval Timeout of connectivity test requests

This customization option is available as an override via registry key only. The override can be pushed out to clients via GPO, and must be applied AFTER an update or installation of the Barracuda WSA has completed and the Barracuda WSA has been started up at least once on the client. For details about using the customization option, please contact Barracuda Technical Support.

Fixed in Version 4.4.5

Barracuda Web Security Service Deployments

The WSAMonitor icon state does not show as active in FailOpen or FailClose mode. [BNWSA-1635, BNWSA-1603] The Barracuda WSA FailOpen function behaves as expected. [BNWSA-1301] The Barracuda WSA gets disabled as expected when the user account profile is disabled on the REMOTE FILTERING > Web Security Agent page in the Web Security Agent Central Management Activation section. [BNWSA-1628] The client context menu always shows the current host on the host list. [BNWSA-1639] In the Configuration tool, the Service Port setting is disabled since it is configured automatically by the Barracuda Web Security Service. [BNWSA-1627] Save-Settings function does not fail on Fallback. [BNWSA-1404] High CPU usage mitigated when the Barracuda WSA is connected with the Barracuda Web Security Service. [BNWSA-1623]

Barracuda Web Security Gateway and Barracuda Web Security Service Deployments

Fixed heap corruption issue in BarracudaWSA service. [BNWSA-1539] Fixed compatibility issues with VS2012 Express (WDExpress) when opening "Attach to process" dialog. [BNWSA-1542] Chrome.exe is not filtered if it’s not specified in the Applications to Filter setting. [BNWSA-1638] Fixed issue loading websites on Chrome browser. [BNWSA-1484, BNWSA-1558] WSAMonitor icon does not display after system restart when the Barracuda WSA is configured for silent installation. [BNWSA-1511] In the Configuration Tool, the Service Host field reflects changes as expected. [BNWSA-1368]

Fixed in Version 4.4.4.9

When Central Management is disabled, WSA clients connected to the Barracuda Web Security Service do not fail open or request synchronization of the configuration every 30 seconds. When the WSA is installed on the client, applications connect properly to their web service as expected.

What's New in Version 4.4.3

Upgraded signing certificate: Users download the Barracuda WSA installer file with the IE browser seamlessly. Application compatibility: IP addresses added to the Bypass Filter no longer appear in logs and are no longer intercepted by the Barracuda Web Security Agent in order to avoid incompatibilities at the protocol level.

Fixed in Version 4.4.3

Fixed issues with handling split DNS setup for Barracuda Web Security Gateways. Stability and performance fixes.

What's New in Version 4.4.2 Overall stability, installation and performance improvements Added the ability to hop between networks while using the WSA [BNWSA-178]

Fixed in Version 4.4.2

Improved connection to the Barracuda Web Security Gateway. [BNWSA-1184, BNWSA-1194] Stabilized the running of the agent on host systems. [BNWSA-1197] Improved uninstallation process for agent. [BNWSA-1199, BNWSA-1192] Stabilized upgrade process between versions. [BNWSA-1218] Update notifications can be disabled effectively. [BNWSA-1231, BNWSA-1217] Microsoft VPN and IE compatibility changes. [BNWSA-1189, BNWSA-17]

What's New in Version 4.4.1

Added Windows 10 support, including the new Microsoft Edge browser. [BNWSA-943] Security fixes for Barracuda WSA service at endpoint, as found by Kevin Fairchild [developmentgeek.com]. [BNSEC-6147] Improved security with transfer of password between the Barracuda Web Security Gateway or Barracuda Web Security Service and Barracuda WSA services.

Fixed in Version 4.4.1

Update Manager and Settings Management

Improved auto-update functionality to resolve a high severity vulnerability and enhanced security for Barracuda WSA service related to user policy information, as found by Kevin Fairchild [developmentgeek.com]. [BNSEC-5990] Improved uninstall process to remove traces of Barracuda WSA agent.

What's New in Version 4.4.0.72

Barracuda recommends updating to this version as it resolves stability issues found in version 4.4.0.

Barracuda WSA stability fixes upon continuous browsing. [BNWSA-1142] The Barracuda WSA Utilities Developer logs are disabled. [BNWSA-1145]

What's New in Version 4.4

Improved User Experience

Silent installations do not prompt for an update Anonymized version reporting for product planning Opt-out functionality for anonymous data reporting Stability improvements during settings reload and synchronization events Backward compatibility of Policy Lookup Mode to Barracuda Web Security Gateway version 8.1.005

Enhanced Security

Policy lookup requests to the Barracuda Web Security Gateway are now encrypted Enforced additional best practices from Microsoft Other security fixes that include verifying signature of installers and improved encryption of data between the Barracuda WSA and the Barracuda Web Security Gateway

Fixed in Version 4.4

Fallback Hosts (Applies to Barracuda Web Security Service)

Existing connections do not drop when changing service host or when ranking hosts After switching service hosts, existing connections continue to use the previous host while new connections are switched to the currently selected host

What's New in Version 4.3.1

Updated branding.

Fixed in Version 4.3.1

Resolved issue in which, under certain conditions, the Barracuda WSA would give a 'Service unavailable' error. [BNWSA-631]

Synchronization

Resolved .NET framework 4.0 version compatibility issues with the Barracuda WSA by updating the minimum requirements for Microsoft .NET Framework by Windows OS version. See Requirements for the Barracuda Web Security Agent With Windows in the Barracuda TechLibrary. Upgrading to the correct version of the Microsoft .NET Framework ensures that the Barracuda WSA operates correctly with SQL Server, LogRhythm and other applications and synchronizes seamlessly with the host.

User Interface

The WSAMonitor icon displays a red exclamation mark, as expected, with a message when in Fail Open state. [BNWSA-21] Ports higher than 42008 or 32767 no longer cause an "unable to Open settings- Value is either to small or too large for Int16" error. [BNWSA-469] Advanced button is now displayed with ... extension (GUI convention). [BNWSA-491]

Fallback hosts

When the selected host is the last one from a list of array fallback hosts, ranking works as expected and doesn't toggle the Barracuda WSA to fail open. [BNWSA-478]

Miscellaneous

Resolved issue when, after making multiple configuration changes and clicking the Save button, the following error was displayed: "Object Synchronization method was called from an unsynchronized block of code". [BNWSA-466]

What's New in Version 4.3.0

Fixed in Version 4.3.0

Removed default forced restart after installation complete, which could cause issues when installing via Windows GPO. [BNWSA-258] Improvements in filtering on Windows 8 / 8.1 systems using WFP. [BNWSA-222] Updated LSP component to address Windows .Net 4.5 incompatibility issues with Non-IFSLSPs. [BNWSA-169] Warn page can now also be shown for local redirect address set to external Barracuda Web Security Gateway IP address. [BNWSA-108] For SSL Traffic, fixed handling of TLS 2.1 to improve HTTPS Filtering. Fixed issues occurring in Policy Lookup Mode (Barracuda Webfilter), where monitored pages are not displayed correctly [BNWSA-257] The WSATraffic.log and WSA.log files are now limited to a maximum size of 3 MB each. When the Barracuda WSA client is uninstalled, all related log files are removed from the system. [BNWSA-34]

Version 4.3.0.26

This version replaces version 4.3.0.24

Fixed: If Fail Open is disabled, the Barracuda Web Security Agent now only fails closed when there is no good connection available to the service host. [BNWSA-472] Fixed: The default setting on the Barracuda Web Security Agent client Fail Open mode is no longer disabled; the default is now that Fail Open is enabled before initial successful sync with the host service. This ensures that traffic between the client and the Internet continues to flow even if no connection to the Barracuda Web Security Service or the Barracuda Web Security Gateway can be made.

Version 4.3.0.24

If the Fallback feature is enabled (see Fallback Service Hosts and the Barracuda Web Security Service), the Barracuda WSA no longer fails open/closed if the first fallback host is not available; rather, the next available fallback host is automatically selected. [BNWSA-465]

What's New in Version 4.2.5.0

The Update options have been re-enabled (backend): This relates to Auto-Update and Allow Users to Check for Updates Options, configurable on the Remote Filtering tab of the Barracuda Web Security Gateway. The Barracuda Web Security Service only has Allow updates, which has the same effect as Auto-Update on the Barracuda Web Security Gateway. It does not include the second configuration option on the Remote Filtering tab. Therefore, for the Barracuda Web Security Service, the Check for Updates option in the Context Menu is not available by default. Update server: d.barracuda.com. If the Update option is enabled, make sure that access to this server is available through your firewall. Sync settings now available from the Context Menu: Any user can trigger the config synchronization with Service (Barracuda Web Security Gateway / Barracuda Web Security Service) at any point of time. Before this version, this option was only available to users having access to the Local Configuration Tool or synchronization on specific events like logon/startup. The Admin can now configure the Temporarily Disable option using command line / GPO deployment option: Default:

a. After 5 minutes, any temporarily disabled Barracuda WSA client will be re-enabled and proxy web traffic to the Barracuda Web Security Gateway / Barracuda Web Security Service. b. The user can disable the client 3 times and must restart the client machine in order to reset this count. Configurable via command line / GPO on installation time:

a. TDT (in ms): The length of time (timeout) the client will be disabled b. TDC: The number of times that the user can temporarily disable the client before needing to reboot the machine c. Example for cmd line config / GPO for custom timeout = 30 mins, timeout count = 5 (=> disable for 30 mins; you can do this 5 times before need to reboot the machine): BarracudaWSASetup.exe /s /v" /qn AUTH_KEY=[YOUR_AUTHKEY] SERVICE_URL=[YOUR_SERVICE_URL] ALLOW_REMOVE=1 TDT=1800000 TDC=5

The CPU monitor is now by default enabled for Barracuda Web Security Service users and disabled for Barracuda Web Security Gateway users. This configuration can now be only overridden at the time of installation, using command line / GPO deployment: Enabled: CPU=1 Disabled: CPU=0 Example for cmd line config / GPO for disabling CPU monitor for BWFS: BarracudaWSASetup.exe /s /v" /qn AUTH_KEY=[YOUR_AUTHKEY] SERVICE_URL=[YOUR_SERVICE_URL] ALLOW_REMOVE=1 CPU=0

What's New in Version 4.2.4.47

Scheduled reboot after installation to ensure that the Barracuda Web Security Agent (WSA) is running. CPU monitor for BarracudaWSA.exe to address intermittent high CPU Loads with cloud-based web content filtering.

Fixed in Version 4.2.4.47

Barracuda WSA components no longer flagged as viruses by MS Windows antivirus scanners

Fixed in previous versions:

The Barracuda WSA tests for Barracuda Web Security Gateway and Barracuda Web Security Service availability on each tap of the Star t Service option in the tool-tip menu. Resolved issues when already in 'Fail Open' mode. Timeout for service availability check was shortened from 60s to 30s.

Barracuda Safe Browser Setup Guide - With Barracuda Web Security Gateway

If you have a Barracuda Web Security Gateway running version 6.0.1 or higher, you can deploy and use the Barracuda Safe Browser on mobile devices running on and off of the network.The Barracuda Safe Browser version 3.0 supports iOS 9 and higher.

See also:

Barracuda Safe Browser - FAQ Barracuda Safe Browser User Guide

You can deploy and use the Barracuda Safe Browser on mobile devices in place of the native browser, applying the same security policies as those applied by the Barracuda Web Security Gateway to other users in the rest of your network. The Barracuda Safe Browser communicates with the Barracuda Web Security Gateway to provide web security to mobile users, per settings configured on the ADVANCED > Remote Filtering page and per policies you configure on the BLOCK/ACCEPT pages.

Figure 1: iOS devices with the Barracuda Safe Browser installed are protected by the Barracuda Web Security Gateway

Basic Setup on the Barracuda Web Security Gateway

To configure and install the Barracuda Safe Browser:

1. Log into your Barracuda Web Security Gateway as admin and navigate to the ADVANCED > Remote Filtering page. 2. Under the Host Configuration section, enter the External IP Address/Hostname (the external IP address or hostname of the Barracuda Web Security Gateway that will handle web traffic proxied from remote iOS devices running the Barracuda Safe Browser), and the Destination Port to which you want the Barracuda Safe Browser to direct web traffic from mobile devices. You need to create a port forward rule on your firewall to this port and the External IP Address/Hostname. 3. Under the Client Configuration section, click the Safe Browser for iOS tab. Select an authentication option and other other settings specific to the Barracuda Safe Browser. Click on Help for additional information about the available settings.

Basic Setup of the iOS Mobile Device

1. From within your Wi-Fi network, launch the Safari browser on your iOS device and visit the Apps Store to fetch the Barracuda Safe Browser application. 2. Select the application for iPad or the iPhone and touch Install. Enter your Apple ID Password if prompted. When the application has downloaded, you'll see the Barracuda Safe Browser icon on the display. There are two options for the intial launch and provisioning of the Barracuda Safe Browser: a. The administrator can send an email to the email address configured on the device with a link to provision the Barracuda Safe Browser. The link format is: bsb://provision?mode=appliance&wanip=xx.xx.xx.xx:xxxx, where xx.xx.xx.xx:xxxx represents the E xternal IP Address/Hostname of your Barracuda Web Security Gateway and :xxxx represents the Destination Port as entered on the ADVANCED > Remote Filtering page. Then the user can simply open the email message on the mobile device and touch the link in the email. The Barracuda Safe Browser will automatically be provisioned and will launch. b. If the administrator has not sent the email, then under the orange Provision button, select the Web Security Gateway option, then Done. In the Host textbox, the enter the IP address and port that was entered by the administrator on the Barracuda Web Security Gateway ADVANCED > Remote Filtering page as mentioned above. Use the format per this example: 111.222.333.444:8280 3. If the Session Authentication field on the ADVANCED > Remote Filtering page is set to Forced Authentication, the user will be prompted to provide LDAP credentials to log in. Alternatively one can tap the Continue as Guest button. Note: If you want to use the device with a different Barracuda Web Security Gateway account, you must unprovision the device. When you connect to the other account, the device will be re-provisioned. 4. To enable the BASIC > Remote Devices page to report the physical location of the mobile device, touch OK when prompted to 'Use Your Current Location". 5. Enable Restrictions for the Safari browser locally on the device through Settings > Restrictions, or using an MDM or Apple Configurator. 6. Once the local browser is restricted, the icon for that browser will disappear from the UI on the mobile device, and the user is ready to run Barracuda Safe Browser with policies you've configured in Barracuda Web Security Gateway. Your Barracuda Web Security Gateway policy will now be applied to all traffic from the Barracuda Safe Browser and will be reflected in reports.

Managing the Application in iOS

View Bookmarks: From the Bookmarks button at the bottom of the iOS display, you can view bookmarks provisioned to the device by

Barracuda Web Security Gateway as well as the bookmarks added by the user.

Log Out, Unprovision and Clear History: From the Settings button at the bottom of the iOS display you can view the Username, Hostname, Auth Key, Device ID and Version. If you need to log out the current user if the device will be shared, you can Log Out, Unprovision the device and Clear History. When the next user runs the Barracuda Safe Browser, the device will be re-provisioned and the user will be prompted to log in per the configuration by Barracuda Web Security Gateway.

Advanced Setup

1. On the ADVANCED > Remote Filtering page, in the WSA / Safe Browser Configuration section, configure the following settings on the Safe Browser for iOS tab:

Session Authentication: If you want to require users to log in with LDAP credentials before browsing, select Forced Authentication. Sel ecting Optional Authentication will give the user the choice of either logging in and browsing with assigned polices, or browsing as a guest under a different set of policies. Select None if you don’t want the user to be presented with a log in option – the user will only browse as a guest.

Note: If you configure LDAP authentication in Barracuda Web Security Gateway for your Barracuda Safe Browser users, you can apply user-specific policies for each mobile user. Otherwise you can only apply global policies to all mobile users. To configure LDAP authentication, you'll need to expose your LDAP server to the Internet by port forwarding from your Barracuda Web Security Gateway ext ernal IP address to port 389 (non-secure) or port 636 (secure) for your LDAP server. Currently Barracuda Web Security Gateway supports Microsoft Active Directory.

Session Timeout: If you have configured LDAP authentication for your mobile users, use this setting to specify the amount of time, in minutes, that is allowed to elapse before a user's login expires and re-authentication is required. To disable session expiration (so that a session does not expire until the user logs off), set this value to 0 hours or minutes. The recommended setting is 24 hours. Idle Timeout - If you have configured LDAP authentication for your mobile users, use this setting to specify the amount of time, in minutes, that a user's session is allowed to remain idle before that login session automatically expires. To disable session expiration based on idle time, set this value to 0 hours or minutes. The recommended setting is 8 hours. Password: Creating a password means that the user (or the administrator of the mobile device) can enter it to bypass all filtering by pressing the Bypass action button on their mobile device. Bypass Filter: Enter any IP addresses that you want to bypass filtering by Barracuda Web Security Gateway. Fail Open: Set to Yes if you want the Barracuda Safe Browser to allow all web requests if the mobile device cannot reach Barracuda Web Security Gateway for some reason. Setting to No means that all requests would be blocked in that case. Enable Geolocation: Setting to Yes means that the last location from which the user of the device logged in, or that the settings were synchronized, will be displayed in Barracuda Web Security Gateway. If this feature is enabled, then on the Remote Filtering > Safe Browser > Last Seen Devices page, you'll see the username, the domain, the Device ID, the IP address, the last-seen location and time/date that the user last made a web request. This feature is useful for locating lost or stolen devices. Allow Temporary Bypass Filtering: Enabling this feature allows the administrator or user to temporarily bypass filtering by Barracuda Web Security Gateway for up to 5 minutes, at which point filtering automatically resumes. If the user is connecting from an Internet cafe or hotel portal, for example, and needs to temporarily disable the Barracuda Safe Browser so that they can connect to their network, they can do so for the 5 minute period. Only 3 temporary disables are allowed once the Barracuda Safe Browser is installed. The Password, configured per above, is not required. Allow Bypass Filtering: Users who have administrative rights on their mobile devices will be able to bypass filtering indefinitely in their Barracuda Safe Browser. The Password, configured per above, is required.

How to Get and Configure the Barracuda Chromebook Security Extension This feature is available for the Barracuda Web Security Gateway 410 and 410 Vx and higher, running version 11.0 and above.

With the Barracuda Chromebook Security Extension installed on Chromebooks, users are identified and policy is applied based on the user whether they are inside your network or accessing the Internet from a public or private network. For example, this feature provides security for students, even when they take their Chromebooks home. Additionally, user generated traffic is logged and recorded for reporting purposes, providing administrators insight into all user activity.

The extension provides:

Enforcing of security policies provided by the Barracuda Web Security Gateway Control and visibility over both HTTP and HTTPS traffic, without sending any user generated traffic through the Barracuda Web Security Gateway Synchronizing of policy and report data between the Chromebook and the Barracuda Web Security Gateway

Note that the extension, not the Barracuda Web Security Gateway, applies block/allow policies for G Suite on the Chromebook.

The Barracuda Chromebook Security Extension is available from the Google Chrome Web Store at no cost, and can be configured in the Google Admin console. Follow the instructions below to get and configure the Barracuda Chromebook Security Extension.

Features supported on the Barracuda Web Security Gateway

In addition to the ability to block HTTPS sites, the extension supports these features:

With the Barracuda Web Security Gateway version 11.x:

Content Filtering Domain Filtering Custom Categories Web Logs Exceptions (Limited to Content Filtering and Domain filtering). Reporting, limited to features listed here

Note that application blocking is supported through Chromebook Management (admin.google.com). The following do not apply for Chromebook web traffic with the extension installed:

Settings on the BLOCK/ACCEPT > Web App Control page; i.e. block/allow for applications listed on the page. Settings on the BLOCK/ACCEPT > Web App Monitor page; i.e. social media content monitoring and suspicious keyword alerts. Interactive block pages, which allow for login bypass or temporary access tokens, for example.

With the Barracuda Web Security Gateway version 12.x:

All the features supported by the Barracuda Web Security Gateway 11.x Chromebook Granular Controls: Option to set the frequency with which the extension attempts to sync traffic log data with the Barracuda Web Security Gateway. Option to set the frequency with which the extension attempts to fetch and sync policy changes made by the administrator. Option to configure Request Types to Filter - For example, not filtering stylesheets, images, or other object types reduces the processing load on the Chromebook. Time based policies Temporary Access Token features Google Directory Services

The following do not apply for Chromebook web traffic with the extension installed:

How the Barracuda Chromebook Security Extension Works

When installed on a Chromebook, the Barracuda Chromebook Security Extension queries the Barracuda Web Security Gateway for block/accept policies and applies them to all Chromebook web traffic. The extension is configured using the Google Admin console and can optionally use the Google Active Directory Sync(GADS) and G Suite Password Sync (GAPS) to synchronize Chromebook user logins with the Barracuda Web Security Gateway for user-based exception policies.

If you do not configure GADS/SSO, you can create local users with matching usernames, which will automatically match users coming from the google domains.

About web logs for Chromebook traffic Unlike regular proxy traffic, Chromebook web traffic is not displayed immediately on the BASIC > Web Log page in the Barracuda Web Security Gateway web interface – it may take a few minutes for the log data display. If the Barracuda Web Security Gateway goes offline, and if the user already has the Barracuda Chromebook Security Extension installed, web traffic from that device will continue to be filtered based on the policies that were downloaded by the extension before the Barracuda Web Security Gateway went offline. In this scenario, the web logs are stored on the client machine and are displayed when the Barracuda Web Security Gateway is online again.

Authentication for Chromebook Users

How to Download and Use the Barracuda Chromebook Security Extension

Step 1. Prepare the Chromebook configuration file using the Barracuda Web Security Gateway.

Start by generating a text file that specifies the Barracuda Web Security Gateway you want your Chromebooks to sync with for security policies. To create the file:

1. Log into the Barracuda Web Security Gateway web interface as admin and go to the ADVANCED > Remote Filtering page. 2. In the Client Configuration section, click the Chromebook Extension tab and configure the following: a. Set Enable Chromebook Compatibility to Yes. Port 3128 is opened by default when this option is set to Yes. b. Create a shared secret, or password, which is used by the Barracuda Chromebook Security Extension on the Chromebook to communicate with this Barracuda Web Security Gateway. Do not use the "/" or "\" slash characters in the shared secret. It is important to use a text editor, such as Notepad, that does not add any markup to the text. For example: 17$k2Y4! Enter in the Shared Secret field. c. Click Create configuration file for Barracuda Chromebook Security Extension as shown below.

Barracuda Web Security Gateway Administrator's Guide - Page 69

3. You will see a popup with the required fields to generate the configuration file:

With the Barracuda Web Security Gateway version 11.0, the fields are as follows: a. IP Address - This is the same as the IP Address on the BASIC > IP Configuration page.

If Chromebooks are to be used outside of the network, you should use a domain name that resolves to the Barracuda Web Security Gateway both within and outside of the network.

b. Web Interface HTTPS/SSL Port - This is the same as the Web Interface HTTPS/SSLPort setting on the ADVANCED > Secure Administration page. c. Shared Secret - Re-enter the shared secret you created on the ADVANCED > Remote Filtering page. Click Generate.

d. Save the chromebook_config.json file on your local system or network.

With the Barracuda Web Security Gateway version 12.x, the fields are as follows: a. IP Address - This is the same as the IP Address on the BASIC > IP Configuration page.

If Chromebooks are to be used outside of the network, you should use a domain name that resolves to the Barracuda Web Security Gateway both within and outside of the network.

b. Web Interface HTTPS/SSL Port - This is the same as the Web Interface HTTPS/SSL Port setting on the ADVANCED > Secure Administration page. c. Log Sync Frequency (minutes) - Frequency with which the extension attempts to sync traffic log data with the Barracuda Web Security Gateway. Minimum setting should be 15. d. Policy Sync Frequency(minutes) - Frequency with which the extension attempts to fetch and sync policy changes made by the administrator. Minimum setting should be 15. e. Re-enter Shared Secret - Re-enter the shared secret you created on the ADVANCED > Remote Filtering page. f. Request Types to Filter - If you click Select, you will see options you can check for the extension to filter or not filter. For example, not filtering stylesheets or other object types reduces the processing load on the Chromebook.

g. Click Generate to create the configuration file, and save the chromebook_config.json file on your local system or network.

Step 2. Configure the Barracuda Chromebook Security Extension in the Google Admin console.

1. Log into Google Admin console as an administrator and add all managed devices per Google instructions here: Enroll Chrome devices. 2. Go to Device Management > Chrome Management > App Management and search for Barracuda Chromebook Security

Extension. 3. Click on Barracuda Chromebook Security Extension to configure the extension in the Google Admin console. 4. Click on User Settings. Modify the settings for: Allow installation, Force installation, and Pin to taskbar b ased on your setup requirements.

5. Upload the chromebook_config.json file you created in Step 1. above to the Google Admin console. In the User Settings window, under Configure, click UPLOAD CONFIGURATION FILE as shown below. You'll be prompted to select the text file that you created.

Barracuda Web Security Gateway Administrator's Guide - Page 71

6. Go to Device Management > Chrome Management > User Settings and scroll down to the Content section and, in the URL Blocking section, add these URLs to the URL Blacklist: chrome://policy chrome://extensions

7. Go to Device Management > Chrome Management > User Settings > Apps and Extensions > Allow or Block All Apps and Extensions. Disable options for the user to install extensions by selecting Block all apps and extensions except the ones I allow.

Barracuda Web Security Gateway Administrator's Guide - Page 72

8. Go to Device Management > Chrome Management > User Settings > User Experience > Developer Tools. Disable options for Developer Mode for users by selecting Never allow use of built-in developer tools.

9. Go to Device Management > Chrome Management > User Settings > Content > Safe Search and Restricted Mode. Enable Safe Search under Device Management by selecting Always use Safe Search for Google Web Search.

10. Go to Device Management > Network > General Settings and make sure that Auto-connect is not checked.

Step 3. Configure an SSL encryption certificate on the Barracuda Web Security Gateway.

Create a self-signed certificate for SSL encryption and download it from the Barracuda Web Security Gateway:

1. On the Barracuda Web Security Gateway, go to the ADVANCED > Secure Administration page. On this page, you can create or

upload an SSL certificate to use for SSL encryption of web traffic. Click Help on that page to read more about using SSL certificates. 2. In the SSL Certificate Configuration section, select the Certificate Type as Private(Self-Signed) and fill in the details with the Comm on Name as the Barracuda Web Security Gateway IP address (or a hostname that resolves to that IP address) , and Key Size as 2048. Click Save.

3. Reload the page, and then download the Private Root Certificate. 4. On the Google Admin console, go to Device Management > Network > Certificates. Click Add Certificate and upload the certificate. 5. Select Use this certificate as an HTTPS certificate authority. Click Save.

Step 4. Proxy web traffic to the Barracuda Web Security Gateway

1. Log into Google Admin console as an administrator and go to Device Management > Network > Wi-Fi. Select the Wi-Fi network to manage. 2. Make sure the last row Apply network is per device.

3. Change proxy settings to Manual Proxy Configuration. 4. Check Use this proxy server for all protocols. 5. Enter the host IP address or hostname for HTTP proxy host and 3128 for the Port.

6. Click Apply.

Set Up Single Sign-on for Active Directory (AD) to Sync With Google Accounts This setup is optional.

1. Download the Google Active Directory Sync (GADS) https://support.google.com/a/answer/6120989?hl=en 2. In the Google Admin console, go to Domains > Add/remove Domains and enter your public domain name into your admin.google.com account. 3. Follow instructions at https://support.google.com/a/answer/6123891 to configure GADS to sync your user configuration for LDAP. 4. Follow instructions at https://support.google.com/a/answer/2611842?hl=en to use G Suite Password Sync (GAPS) to sync user passwords with your LDAP.

When Using SSL Inspection

If you enable the SSL Inspection feature on the Barracuda Web Security Gateway (set to 'On' on the ADVANCED > SSL Inspection page), you must add the following domains to the Exempted Domains section of the page: accounts.google.com accounts.gstatic.com accounts.youtube.com clients1.google.com clients2.google.com clients3.google.com clients4.google.com commondatastorage.googleapis.com cros-omahaproxy.appspot.com dl.google.com dl-ssl.google.com gweb-gettingstartedguide.appspot.com m.google.com omahaproxy.appspot.com pack.google.com safebrowsing-cache.google.com safebrowsing.google.com

Copyright © 2017, Barracuda Networks Inc. Barracuda Web Security Gateway Administrator's Guide - Page 75 ssl.gstatic.com storage.googleapis.com tools.google.com www.googleapis.com www.gstatic.com cache.pack.google.com chrome.google.com clients2.googleusercontent.com lh3.ggpht.com lh4.ggpht.com lh5.ggpht.com lh6.ggpht.com

How to Update the Barracuda Chromebook Security Extension

When there is a new version of the extension available, the user must log out of the Chromebook and log in again to get the latest version. Any time the user logs in, the latest version of the extension is in place.

How to Troubleshoot the Barracuda Chromebook Security Extension The Barracuda Chromebook Security Extension is available for the Barracuda Web Security Gateway 410 and 410 Vx and higher, running version 11.0 and above. For more information, see:

How to Get and Configure the Barracuda Chromebook Security Extension How to Configure Google Directory Services

The Barracuda Chromebook Security Extension Support Log is a good tool for troubleshooting configuration of the extension. Click on the icon for the extension in the task tray in the Chromebook, and then click View Support Log.

When you click View Support Log, you'll see something like this:

In the Support Log, click Troubleshoot Extension to see a more specific error message (see table below for possible messages).

The following table lists possible error messages related to configuring the Barracuda Chromebook Security Extension. The BWSG refers to the Barracuda Web Security Gateway.

Test Error Message

BWSG Settings There is an issue with the extension configuration file. Please generate the configuration file from the Barracuda Web Security Gateway ADVANCED > Remote Filtering page and re-upload to the Google Admin console.

BWSG Availability Make sure Barracuda Web Security Gateway is accessible over HTTPS (Enter https://[bwsg_address] in the browser). There should no be SSL error when accessing the Barracuda Web Security Gateway. The SSL certificate from the ADVANCED > Secure Administration page Common Name should be in the Barracuda Chromebook Security Extension configuration file. This certificate should be uploaded to the Google Admin console and marked as Trusted.

BWSG Trusted Authentication Make sure the shared key stored in the Google Admin console and the Shared Secret entered in the Barracuda Web Security Gateway on the ADVANCED > Remote Filtering page match.

WCS Categorization Availability Make sure the Barracuda WCS service is accessible within your network.

How to Load Balance Barracuda Web Security Gateway With the Barracuda Load Balancer ADC

This article details how to load balance multiple instances of the Barracuda Web Security Gateway (hardware appliances only), where the Barracuda Web Security Gateway is deployed in forward proxy mode. The Barracuda Load Balancer ADC must be running version 6.0.0.008 or higher.

Step1. Set up the Barracuda Load Balancer ADC 1. Configure the MGMT IP address, Netmask, Gateway, and DNS server address via the console interface. 2. Log in to the Barracuda Load Balancer ADC web Interface as admin. 3. Add a Custom Virtual Interface. The Barracuda Load Balancer ADC uses this interface to communicate to Barracuda Web Security Gateway instances. Go to the NETWORK > Interfaces page. Give the interface a Name and enter an IP Address, Netmask and select the Network Interface (example: ge-1-1). Click Save. 4. Add a default Gateway. Go to the NETWORK > Routes page and enter an IP Address (0.0.0.0), Netmask (0.0.0.0), Gateway Address and select a Network Interface (example: ge-1-1). Click Save. 5. Create a Service on the Barracuda Load Balancer ADC. Go to the BASIC > Services tab and click Add Service.

a. Enter the following example values for the new Service:

Name Service Group IP Service Netmask Interface Session Load Type Address Port Timeout Balancing Section

WSGProx Layer (optional) The proxy 3128 255.255.2 Interface 1200 Persistenc ySVC 4-TCP IP address 55.255 to which e Type: So to which client web urce IP

all clients traffic Persistenc will send should be e Time: 12 their web sent: 00 traffic. ge-1-1

b. Click Create. 6. Click Add Server. Add the IP address of ( one of ) the Barracuda Web Security Gateway instance(s) to the Barracuda Web Security Gateway WSGProxySVC Service. 7. Enter the IP address of the Barracuda Web Security Gateway and port as 3128. 8. Select Enable for the Direct Server Return and click Create.

Repeat the above step for each Barracuda Web Security Gateway instance to be load balanced.

Step 2. Configure the Barracuda Web Security Gateway

1. Ensure that the Barracuda Web Security Gateway firmware is on 10.0.0.015 or above. 2. Configure the Barracuda Web Security Gateway for Forward Proxy Deployment. 3. Create a Virtual Interface to receive traffic from the Barracuda Load Balancer ADC. Go to the ADVANCED > Advanced Networking pag e and enter the IP Address of the Service you created on the Barracuda Load Balancer ADC. Enter the Netmask as 255.255.255.255. Set Device as Loopback Port. You do not need to enter a Gateway. Click Add.

Repeat the above steps on each Barracuda Web Security Gateway instance.

Step 3. Monitor the Service on the Barracuda Load Balancer ADC

1. Log in to the web Interface of the Barracuda Load Balancer ADC as admin. 2. Go to the BASIC > Services page and select the Barracuda Web Security Gateway WSGProxySVC. 3. The Service must show a green tick icon for each of the Barracuda Web Security Gateways added as a server.

Step 4. Verify the Configuration

At this point, client browsers should be configured with the proxy settings using the Barracuda Web Security Gateway WSGProxySVC IP address and port 3128. When the client accesses any website such as cnn.com, traffic from the client will go the Barracuda Web Security Gateway WSGProxySVC on the Barracuda Load Balancer ADC. The Barracuda Load Balancer ADC will then send the traffic to one of the Barracuda Web Security Gateway instances configured as Servers.

If all the Barracuda Web Security Gateway instances are not the same model, you can modify the weights for each server to match its capability. Higher model instances should have higher weights. By default, weights are set to 1, which means all instances of the Barracuda Web Security Gateway are of equal capacity.

How to Configure a Transparent Redirection from a Barracuda NextGen Firewall F-Series

The Barracuda NextGen Firewall F-Series can transparently redirect all HTTP and HTTPS traffic to a Barracuda Web Security Gateway located in a DMZ. The Barracuda Web Security Gateway can then process the HTTP/HTTPS request using the original source and destination IP addresses. After the Barracuda Web Security Gateway applies all local policies and collects the statistics, the web traffic is then forwarded to the Internet via the Firewall F-Series. This configuration allows the Barracuda Web Security Gateway to apply all policies as if it were directly connected to the client, and allows it to create meaningful statistics and connection information.

Before your Begin

Verify that the Forwarding Firewall service is using Feature Level 7.0 or higher. The Firewall F-Series and the Barracuda Web Security Gateway must be connected to the same subnet (within the same ARP domain). Optional: Configure the Firewall F-Series for SSL inspection. See How to Configure SSL Inspection in the Firewall. The Barracuda Web Security Gateway should be running version 10.0 or higher and be configured for SSL Inspection in Transparent Mode. See How to Configure SSL Inspection Version 10 and Above. The Barracuda Web Security Gateway must be connected to a different subnet than the clients, and the Firewall F-Series must be the default gateway for the Barracuda Web Security Gateway.

Step 1. Create a transparent redirect Dst NAT access rule on the Barracuda NextGen Firewall F-Series

Create the Dst NAT access rule to forward all traffic to the Barracuda Web Security Gateway.

1. Go to CONFIGURATION > Configuration Tree > Box > Virtual Servers > your virtual servers > Firewall > Forwarding Rules. 2. Click Lock. 3. Create an access rule to forward selected traffic coming from your clients: Action – Select DNAT. Source – Select Trusted Networks. Alternatively, enter the network the client using the Barracuda Web Security Gateway is in. Destination – Select Internet. Services – Select HTTP+S. Target List – Enter the IP address of the Barracuda Web Security Gateway without a port. E.g.. 172.16.0.10

Do not use network objects containing host names (DNS objects). The firewall does not redirect traffic to a hostname or FQDN.

Fallback/Cycle – If you have defined multiple target IP addresses, select how the firewall distributes the traffic between the IP addresses. Fallback – The connection is redirected to the first available IP address in the list. Cycle – New incoming TCP connections are distributed evenly over the available IP addresses in the list on a per-source IP address basis. The same redirection target is used for all subsequent connections of the source IP address. UDP connections are redirected to the first IP address and not cycled. List of Critical Ports – Enter a space-delimited list of ports used. Connection Method – Select Original Source IP. Application Policy (optional) – Enable Application Control and SSL Inspection to gain deeper insight on the traffic redirected to the Barracuda Web Security Gateway.

Barracuda Web Security Gateway Administrator's Guide - Page 80

4. In the left menu, click Advanced. 5. In the Miscellaneous section, set Transparent Redirect to Enable.

6. Click OK. 7. Drag and drop the access rule so that it is the first rule that matches the traffic that you want it to forward. Ensure that the rule is located above the BLOCKALL rule; rules located below the BLOCKALL rule are never executed. 8. Click Send Changes and Activate.

Step 2. Create an pass access rule for the Barracuda Web Security Gateway to access the Internet

1. Go to CONFIGURATION > Configuration Tree > Box > Virtual Servers > your virtual servers > Firewall > Forwarding Rules. 2. Click Lock. 3. Create a PASS rule to allow the HTTP proxy to access the Internet: Action – Select Pass. Source – Enter the IP address of the Barracuda Web Security Gateway. Destination – Select Internet. Service – Select HTTP+S.

Barracuda Web Security Gateway Administrator's Guide - Page 81

Connection Method – Select Dynamic NAT. Application Policy (optional) – Select Application Control policies.

4. In the left menu, click Advanced. 5. In the Dynamic Interface Handling section, set Source Interface to Any. 6. Click OK. 7. Click Send Changes and Activate.

Step 3. Create a Pass access rule for the HTTP proxy to access the client network

To allow the Barracuda Web Security Gateway to access the client, you must create a PASS rule:

Action – Select Pass. Source – Enter the IP address of the Barracuda Web Security Gateway . Destination – Select Trusted Networks. Service – Select HTTP+S. Connection Method – Select Original Source IP. Application Policy (optional) – Select Application Control policies.

Step 4. Configure the Barracuda Web Security Gateway

In order to successfully send the connection from the proxy to the Internet, you must configure the device:

Route to the Internet using the Firewall F-Series as the default gateway. Route to the internal client network using the Firewall F-Series as the gateway. Traffic must use the IP address of the Barracuda Web Security Gateway as the source IP address for outgoing connections. The Barracuda Web Security Gateway must accept the HTTP and HTTPS connections on the same port as the firewall.

Step 5. Import the Barracuda Web Security Gateway's root certificate

If you are running SSL Inspection on the NextGen Firewall F-Series, you must add the root certificate used for SSL Inspection on the Barracuda Web Security Gateway to the Trusted Root Certificates. For details about configuring SSL Inspection and certificates on the Barracuda Web Security Gateway, see How to Configure SSL Inspection.

Download the root certificate from the Barracuda Web Security Gateway

On the Barracuda Web Security Gateway, go to ADVANCED > SSL Inspection and Download the Root Certificate for Browsers. You now have the webfilter.barracuda.pem file containing the root certificate on the client running NextGen Admin.

1. On the Firewall F-Series, go to CONFIGURATION > Configuration Tree > Box > Virtual Servers > your virtual servers > Firewall > Security Policy Settings. 2. Click Lock. 3. Click + in the Trusted Root Certificates list and select Import from PEM File. A file dialog opens.

4. Select the file containing the root certificate you previously exported from the Barracuda Web Security Gateway. 5. Enter a Name. 6. Click OK. 7. Click Send Changes and Activate.

The certificate is now listed in the Trusted Root Certificates list.

Next Steps

Import the root certificates from the NextGen Firewall F-Series and the Barracuda Web Security Gateway on the clients to avoid SSL certificate errors. If SSL Inspection is only enabled on one of the devices, then you only need to install the root certificates on the clients for that device.

Getting Started

Barracuda Networks recommends first reviewing Deployment Options. When you've determined the right deployment, you're ready to install and configure the Barracuda Web Security Gateway. For maximum security, Barracuda recommends reviewing Securing the Barracuda Web Security Gateway after installation.

Recommended Steps

If you already installed your Barracuda Web Security Gateway using the Barracuda Web Security Gateway Quick Start Guide which is shipped with your appliance, start with Step 3 - Configure the Barracuda Web Security Gateway. If you are using the Barracuda Web Security Gateway Vx, start with Virtual Deployment.

Step 1 - Network Considerations Step 2 - Installation Step 3 - Configure the Barracuda Web Security Gateway Step 4 - Configure and Secure the Web Interface Step 5 - Connect the Barracuda Web Security Gateway to Your Network Barracuda Web Security Gateway 30 Day Evaluation Guide

Step 1 - Network Considerations

The Barracuda Web Security Gateway is designed for low-risk deployment because it is intended to be a bridge within your network. The Barracuda Web Security Gateway can view Internet traffic that passes through the network but does not affect its routing. To reduce the risk of interfering with important network traffic, initially set the Barracuda Web Security Gateway to monitor and log the spyware activity only. Determine which internal servers and clients to exclude from spyware and virus scans.

For maximum security, Barracuda recommends placing your Barracuda Web Security Gateway behind a corporate firewall.

The following pre-installation considerations may help you understand some of the issues that may occur, and Barracuda Networks recommends reading and understanding the Deployment Options for the Barracuda Web Security Gateway before proceeding.

Routers

Make sure the default gateway is properly set to reach the Internet. Also, if you are testing the Barracuda Web Security Gateway in one portion of your network and move to another portion of the network for deployment, make sure that you check the default gateway and make changes as necessary.

External DNS

Some of the considerations regarding DNS include the following issues:

Optimal DNS query response time: When the Barracuda Web Security Gateway is in Active mode, it proxies all Internet requests for the clients. As a result, the Barracuda Web Security Gateway needs to resolve website hostnames to IP addresses while proxying the HTTP requests made by the users. The response for web server DNS queries needs to be optimal to allow the Barracuda Web Security Gateway to look up and quickly process these requests. A slow DNS server will cause the Barracuda Web Security Gateway to respond slowly to clients, which adds latency to their Internet access.

Requests for fully qualified Web application server names: If a user attempts to browse to a website by specifying a web server name which is not a fully qualified name that includes the domain name, the Barracuda Web Security Gateway automatically appends the string barracuda.com to the unqualified name in order to resolve the request. For example, if the user enters the server name myserver instead of myserver.mydomain.com, the Barracuda Web Security Gateway resolves the request using the hostname myserver.barracuda.com.

HTTPS Filtering: The Barracuda Web Security Gateway relies on DNS responses when filtering HTTPS traffic. In order for the rules to be applied properly for HTTPS requests, DNS queries and responses should go through Barracuda Web Security Gateway. This requires doing the following:

1. On the BASIC > IP Configuration page, set the primary DNS server to an external one. 2. Set the DNS server in all clients to the same primary DNS server.

Internal DNS

If you have an internal server that is only resolvable via an internal DNS, make sure that this DNS server is used by the Barracuda Web Security Gateway as a secondary DNS.

Enterprise class Layer 3 switch, VLANS, VPN concentrators

These device types are normally capable of handling multiple subnets and providing default routes to clients. However, they may affect the Barracuda Web Security Gateway deployment in the following ways:

A Layer 3 switch can also be set up to have multiple VLANs (Virtual Local Networks) using port assignments. There is no side effect by having VLAN tags in the traffic that is visible to the Barracuda Web Security Gateway (see also VLAN Deployments). However, when the Barracuda Web Security Gateway is set up to a single subnet, it needs to have routes to process requests for other subnets. Although all VLAN operations are in Layer 2, most of the Layer 3 switches have better control since they offer a management user interface. Layer 2 "Smart" switches offer VLAN support as well. Layer 3 switches primarily differ from their capabilities of routing in IPv4 and IPv6, so it acts more like a router which is beyond normal switching hardware can do. A standard solution is to add static routes to these foreign subnets. All Layer 3 switch subnets should use its IP address as the gateway. In the case of a VPN concentrator, use the IP of the concentrator as the default gateway for all the networks aggregated by that VPN concentrator.

Other considerations:

On the Basic > IP Configuration page, set Enable proxy on WAN to Yes if you are routing traffic through the WAN interface of the Barracuda Web Security Gateway. In the case of a VPN concentrator, you should typically use the IP address of the core switch as the default gateway for all the networks aggregated by that VPN concentrator. Alternatively, you may need to use the IP address of the concentrator (or firewall) as the default gateway for all the networks aggregated by that VPN concentrator. This will allow all of the VPN traffic to be filtered with the Barracuda Web Security Gateway being on the internal network.

Firewall DMZ

Servers in the demilitarized zone (DMZ) are accessible from the internet. Servers inside this zone, such as mail servers, for example, may be configured to access certain servers within an internal network with their own security rules set up. The Barracuda Web Security Gateway should not be deployed to protect these machines. The Barracuda Web Security Gateway is not designed to protect servers but, rather, to protect end user machines. For maximum security, Barracuda recommends placing your Barracuda Web Security Gateway behind a corporate firewall.

Internal Servers In most organizations, internal servers are protected by corporate firewalls that use port forwarding rules to limit access to the servers. Port forwarding rules define the ports that can be used to access the servers (such as HTTP, FTP, and mail servers). These servers should have optimal response time.

As a result, the server traffic must not be interrupted. Barracuda Networks recommends that you exempt or bypass these servers from the Barracuda Web Security Gateway. To reduce Layer 2 bridging overhead, place a switch between the firewall and the Barracuda Web Security Gateway and connect your server farm on a different port on the switch. In this case, set up the servers parallel to the Barracuda Web Security Gateway instead of behind it, and then configure the IP and Port Exemptions feature on the BLOCK/ACCEP T > IP Block/Exempt page to exclude these IP addresses from filtering

Caching and the Current Time Setting

Caching provides faster access to repeatedly requested content by storing content locally on the Barracuda Web Security Gateway. Data is handled using an LRU (Least Recently Used) algorithm. You can enable or disable content caching, and specify domains to exempt from content caching, on the ADVANCED > Caching page. Note that the time value entered in the Current Time field on the BASIC > Administration page must be accurate since the Barracuda Web Security Gateway uses the current time to ensure accurate cache updates.

QoS/Packet Reconfiguration (Quality of Service, Packet Shapers)

There are many products available that can control traffic in a LAN environment, specify priorities, and size these different traffic types. Normally, this is done using a Layer 7 device on different types of applications. The Barracuda Web Security Gateway deployment is affected when the Barracuda Web Security Gateway is placed in front of these devices to benefit from the shaped data. Place the Barracuda Web Security Gateway close to the Internet to help reduce noise and overhead on both the Layer 2 bridging and HTTP proxy.

Mounting and cabling considerations

To install the Barracuda Web Security Gateway you need to:

Mount it on a rack or shelf, unless you have a desktop model and don't need to rack it. Cable it to other network devices

The Barracuda Web Security Gateway is designed to be installed in a data center with other networking devices and servers. Depending on the model, its dimensions are suitable for a 19-inch rack, or can be adapted to a rack with the mounting kit. You must position it within cabling distance of any switches or other devices that access the network segments that you want to protect. The appliance can be mounted facing either direction in your rack, so consider which side will have access to the ports. You may need access to the ports during installation, and you may need to use the back panel during initial configuration.

Continue with Step 2 - Installation.

Using Static Routes For an inline deployment, static routes are necessary to enable the Barracuda Web Security Gateway to protect any client machines that are at IP addresses outside of the native subnet of the Barracuda Web Security Gateway.

For example, suppose your Barracuda Web Security Gateway is assigned the IP address 172.20.0.6 and a subnet mask of 255.255.255.0

If you needed to create a static route to reach client machines in the 192.168.2.x range, the Netmask value would need to be 255.255. 255.0 . If you needed to create a static route to reach client machines in the 192.x.x.x range, the Netmask value would need to be 255.0.0.0 .

In both cases, the IP/Network Address would need to be outside the 172.20.0.x network of the Barracuda Web Security Gateway, and the Gate way Address would need to be inside 172.20.0.x.

To use static routing, from the BASIC > IP Configuration page, you would set up the following:

IP/Network Address - IP address of a host or network located outside of the native subnet of the Barracuda Web Security Gateway. Netmask - Subnet mask for the destination host or network. Gateway Address - IP address of the next hop that can be used to reach the destination host or network. When the Barracuda Web Security Gateway receives ingress web traffic for client machines in the specified IP range, it forwards the packets to the router at the IP address you specify in this field. Therefore, this IP address must be on the same subnet as the Barracuda Web Security Gateway. If another IP address is used outside the range of the Barracuda Web Security Gateway, there could be latency issues because the Barracuda Web Security Gateway is a layer 2 device and does not route traffic.

Note: The core switch or router typically contains routing statements for the entire network.

Step 2 - Installation

Checklist for Unpacking

Before installing your Barracuda Web Security Gateway, make sure you have the following equipment:

Barracuda Web Security Gateway (check that you have received the correct model) AC power cord Ethernet cables Mounting rails and screws (available for the Barracuda Web Security Gateway 610, 810, and 910 only) VGA monitor (recommended) PS2 keyboard (recommended)

Install the Barracuda Web Security Gateway

For maximum security, Barracuda recommends placing your Barracuda Web Security Gateway behind a corporate firewall.

1. If you have a desktop Barracuda Web Security Gateway, you do not need to install it in a rack, but if you wish to do so, use the rack-mount kit (sold separately) for Rack Installation. 2. Fasten the Barracuda Web Security Gateway to a standard 19-inch rack or other stable location. Do not block the cooling vents located on the front and rear of the unit or, for the Barracuda Web Security Gateway 210, the top of the unit. 3. Connect a CAT5 Ethernet cable from your network switch to the LAN port on the back of your Barracuda Web Security Gateway 210, or to the front of your Barracuda Web Security Gateway 310 and higher, as shown in the following figure.

Figure 1: Connecting the Barracuda Web Security Gateway 310 and higher to your network.

The Barracuda Web Security Gateway supports 10BaseT, 100BaseT and, on the 610 and higher, 1xGigabit Ethernet.

If your switch records the MAC address of an external device, make sure you delete all pre-existing MAC address records from your switch.

Do not connect any other cables to the unit. The connectors on the back panel are for diagnostic purposes.

3. Connect the following hardware to your Barracuda Web Security Gateway:

Power cord VGA monitor PS2 or USB keyboard

After you connect the AC power cord, the Barracuda Web Security Gateway may power on for a few seconds and then power off. This is standard behavior

4. Press the Power button located on the front of the unit. The login prompt for the administrative console displays on the monitor and the power light on the front of the Barracuda Web Security Gateway turns on.

Configure the IP Address and Network Settings

The Barracuda Web Security Gateway is assigned a default IP address of 192.168.200.200. You can change the address in one of three ways:

Use the administrative console as described below. Press and hold the RESET button on the front panel. Holding RESET for eight seconds changes the IP address to 192.168.1.200. Holding the button for 12 seconds changes the IP address to 10.1.1.200. Log into the web interface as described in Step 3 - Configure the Barracuda Web Security Gateway and change it on the BASIC > IP Configuration page.

Choose an IP address that is on the same subnet as the devices connected to the WAN and LAN ports of the appliance.

To set a new IP address from the administrative console:

1. With your keyboard and monitor connected directly to the Barracuda Web Security Gateway, at the barracuda login prompt, enter admin for the login and admin for the password. The User Confirmation Requested window displays the current IP configuration of the Barracuda Web Security Gateway. 2. Using your Tab key, select Change and click Enter to change the IP configuration. 3. Enter the new IP Address and Subnet Mask for your Barracuda Web Security Gateway. For proper Default Gateway setup, note that the Default Gateway is the IP address of the next outbound hop from the Barracuda Web Security Gateway, which sends all egress traffic to this gateway via the WAN port. For Forward Proxy deployment, use the same Default Gateway that is used by hosts on the network. Your firewall must be on the same subnet as the Barracuda Web Security Gateway. 4. The Primary DNS and Secondary DNS fields are required to resolve to Barracuda support servers upon initial setup to log into the administrative web interface. 5. Select Save to enter your changes. 6. Select Exit.

The new IP address and network settings are applied to your Barracuda Web Security Gateway.

Configure Your Corporate Firewall

For maximum security, Barracuda recommends placing your Barracuda Web Security Gateway behind a corporate firewall. If your Barracuda Web Security Gateway is located behind the firewall, refer to the table below for the ports that need to be opened on your corporate firewall to allow communication between the Barracuda Web Security Gateway and remote servers.

Port Direction Protocol Description

22 In/Out TCP Remote diagnostics and technical support services

25 Out TCP Email and email bounces

53 Out TCP/UDP DNS (Domain Name Server)

80 Out TCP Virus, spyware, category definition updates, and firmware updates

123 In/Out UDP NTP (Network Time Protocol)

8000 In/Out TCP See Initial Configuration of the System.

8002 In/Out TCP Synchronization between linked systems. For more information, see

High Availability - Clustering the Barracuda Web Security Gateway

In addition to the ports listed above, you may have to configure your corporate firewall to allow the Barracuda Web Security Gateway to email system alerts and reports. Some organizations create firewall rules that only allow emails to be sent from the IP address of their email server. In this case, you should configure your corporate firewall to allow emails to be sent from the Barracuda Web Security Gateway as well.

If your Barracuda Web Security Gateway is located in a DMZ, you may need to configure your corporate firewall to allow the Barracuda Web Security Gateway to send notifications to your internal email server. In this case, if your email server requires credentials for authentication, configure the Username and Password in the Email Notifications section of the BASIC > Administration page in the Barracuda Web Security Gateway web interface.

Continue with Step 3 - Configure the Barracuda Web Security Gateway.

Step 3 - Configure the Barracuda Web Security Gateway

After choosing the IP address of the Barracuda Web Security Gateway and opening the necessary ports on your corporate firewall, configure the Barracuda Web Security Gateway from the web interface per the instructions below. Make sure the computer from which you are configuring the Barracuda Web Security Gateway is connected to the same network and that the appropriate routing is in place to allow connection to the Barracuda Web Security Gateway’s IP address via a web browser.

By default, HTTPS filtering and SSL inspection are disabled on the Barracuda Web Security Gateway due to the fact that both features require additional configuration steps in order to operate properly. Barracuda recommends enabling at least one of these features in order to provide visibility and control of HTTPS traffic, which continues to increase in usage. To understand and enable these features, please see HTTPS Filtering With the Barracuda Web Security Gateway and Using SSL Inspection With the Barracuda Web Security Gateway.

Understanding Operating Modes

Before you configure the Barracuda Web Security Gateway to filter traffic, it is recommended to become familiar with the possible operating modes and how they affect which traffic can be filtered and blocked. For initial configuration with an inline deployment, you should set the Operati ng Mode to Audit from the BASIC > IP Configuration page, and note how traffic is logged.

Operating modes include:

Active - The Barracuda Web Security Gateway actively protects your network by detecting spyware-infected machines on your network, using transparent HTTP proxy scanning to block and log non-HTTP spyware traffic, and using filters to block and log web traffic that conflicts with your organization's Internet usage policy. Note: In this mode, the system operates in Active Bridging Mode to manage connections between network devices and the Barracuda Web Security Gateway. Audit - In this mode, for an inline deployment, HTTP traffic is logged but not blocked, and downloads over HTTP will NOT be scanned for viruses or spyware. Use this mode to preview how your currently configured Internet policies would be applied, but without disturbing production traffic. For forward proxy deployments, traffic is logged and policies are applied, just as in Active mode.

For non-HTTP traffic, the following configured policies DO apply: Application blocking IP Block/Exempt rules (Exempt traffic is logged) Outbound spyware activity is blocked

For non-HTTP traffic, the following does NOT apply:

Content Filter settings MIME-type blocking Domains - blocked and allowed rules URL Patterns - logged only Categories - logged only Exceptions

In Audit mode, access to spyware sites and spyware downloads is not blocked but is logged. Note: If the Barracuda Web Security Gateway is deployed as a web traffic monitoring device (as opposed to a web traffic filtering device), the system monitors traffic sent through any mirrored (spanned) port on your switches.

Safe - This mode can only be entered automatically by the Barracuda Web Security Gateway and is not configurable via the web interface. When the System Load exceeds normal thresholds for an extended period, as indicated on the BASIC > Dashboard screen, the device shifts to Safe mode until the System Load returns to normal levels. Note: In this mode, traffic is neither filtered nor logged. Safe mode does not apply if the Barracuda Web Security Gateway is deployed in a WCCP configuration.

Configure the Barracuda Web Security Gateway

1. From a web browser, enter the IP address of the Barracuda Web Security Gateway followed by port. For example: http://192.168.200.200:8000 2. To log into the web interface, enter admin for the username and admin for the password.

For maximum security, Barracuda recommends changing the administrator password in the Password Change section of the BASIC > Administration page. After confirming the password, click Save Password.

3. Go to the BASIC > IP Configuration page and perform the following steps. Click Help on the right side of each section title for additional online help. a. Enter the IP address of your Barracuda Web Security Gateway that you chose in the steps above. Enter the Subnet Mask that is used to define this area of your network, and the Default Gateway, which is the IP address of the next outbound hop from the Barracuda Web Security Gateway. The Barracuda Web Security Gateway sends all egress traffic to the default gateway via the WAN port on the front of the appliance. b.

Barracuda Web Security Gateway Administrator's Guide - Page 92

b. Enter the IP address of your primary and secondary DNS servers (if these have not yet been set up). c. Set Operating Mode to Audit. d. Set Enable Proxy on WAN to No to protect against WAN-side proxy requests if the Barracuda Web Security Gateway is deployed outside of the corporate firewall. e. Enter the Default Hostname which will be displayed in alerts, notifications, and messages sent by the Barracuda Web Security Gateway. f. Enter the Default Domain which will be displayed in alerts, notifications, and messages sent by the Barracuda Web Security Gateway. g. Click Save.

If the IP address of your Barracuda Web Security Gateway on the BASIC > IP Configuration page is changed, you are disconnected from the web interface. If this occurs, log in again using the new IP address.

Activate Your Subscriptions

After installation, your Energize Updates and other optional subscriptions must be activated for the Barracuda Web Security Gateway to be fully enabled and to continue to receive the latest updates to all spyware, virus and category definitions from Barracuda Central. The Energize Updates service is responsible for downloading these updates to your Barracuda Web Security Gateway.

Product Activation

1. At the top of every page, you may see the following warning:

2. Click on the designated link to open up the Product Activation page in a new browser window. 3. On the Product Activation page, fill in the required fields and click Activate. A confirmation page opens to display the terms of your subscription. 4. Return to the Barracuda Web Security Gateway web interface and navigate to the BASIC > Dashboard page. In the Subscription Status section, verify that the word Current appears next to Energize Updates, Instant Replacement Service (if purchased) and Premi um Support (if purchased):

There may be a slight delay of a few minutes for the display to reflect your updated subscription status. If the status is still showing as not activated, click Refresh in the Subscription Status section.

If your subscription status does not change to Current within an hour, and you have ensured that all required network ports are open, or if you have trouble filling out the Product Activation page, please call your Barracuda Networks sales representative.

Update the Barracuda Web Security Gateway Firmware

Prior to upgrading the firmware on your Barracuda Web Security Gateway, it is always recommended that you read the release notes. To update the firmware on the Barracuda Web Security Gateway:

1. From the web interface, select ADVANCED > Firmware Update. 2. Read the release notes to learn about the latest features and fixes provided in the new firmware version. 3. Click Download Now next to Latest General Release. Download Now is disabled if the Barracuda Web Security Gateway is already up-to-date with the latest firmware version. The Barracuda Web Security Gateway begins downloading the latest firmware version. You can view the download status by clicking Ref resh. A message displays once the download is complete. It is important to not power-cycle the unit during the download. Updating the firmware may take several minutes. Do not turn off the unit during this process. 4. Click Apply Now when the download completes. The Barracuda Web Security Gateway will apply the firmware and automatically reboot. It is important to not power-cycle the unit during this process. A Status page displays the progress of the reboot. Once the reboot is complete, the login page appears.

Update Definitions

To apply the newest definitions provided by Energize Updates:

1. Select ADVANCED > Energize Updates. 2. Select On for Automatically Update. The recommended setting is On for all available definitions. 3. Check to see if the current version is the same as the latest general release. If the rules are up-to-date, proceed to the next section. If the rules are not up-to-date, continue to the next step. 4. Click Update to download and install the latest available definitions onto the Barracuda Web Security Gateway.

Continue with Step 4 - Configure and Secure the Web Interface.

Step 4 - Configure and Secure the Web Interface

Controlling Access to the Web Interface

Use the BASIC > Administration page to perform the following tasks for initial setup:

1. For maximum security, assign a new administration password to the Barracuda Web Security Gateway. This step is highly recommended. 2. Make sure the local time zone is set correctly. Time on the Barracuda Web Security Gateway is automatically updated via NTP (Network Time Protocol). It requires that port 123 is opened for inbound and outbound UDP (User Datagram Protocol) traffic on your firewall (if the Barracuda Web Security Gateway is located behind one). It is important that the time zone is set correctly because this information is used to determine the delivery times for messages and is displayed in certain mail reading programs. The current time is also used to deliver accurate cache updates if caching is enabled (see the ADVANCED > Caching page). 3. If desired, change the port number used to access the Barracuda Web Security Gateway Web interface. The default port is 8000. 4. Enter the amount of time for the Session Expiration Length (in minutes) of your Web interface session. If the session expires, you are required to log back into the web interface. 5. Specify your local SMTP server information. Enter the email address for your Administrator to receive system and threat email alerts and notifications. 6. Click Save Changes.

Customizing the Appearance of the Web interface

The ADVANCED > Appearance page allows you to customize the default images used on the web interface. You can also give the Barracuda Web Security Gateway a name (e.g. “Science Library Web Security Gateway”) that will appear in the login page above the login panel that contains the Language selector and the Username and Password prompts. The ADVANCED > Appearance page is only displayed on the Barracuda Web Security Gateway 410 and above.

Changing the Language of the Web Interface

You can change the language of the web interface by selecting a language from the drop-down menu in the upper right corner of the page near the Log Off link and the breadcrumbs. Supported languages include Chinese, Japanese, Spanish, French, and others. The language you select is only applied to your individual web interface. No other user’s web interface is affected.

Enabling SSL for Administrators and Users

SSL (Secure Socket Layer) ensures that your passwords are encrypted and that all data transmitted to and received from the web interface is encrypted as well. All Barracuda Web Security Gateways support SSL access without any additional configuration. However, some sites may wish to enforce using a secured connection to access the web interface, or prefer to use their own trusted certificates.

To enforce SSL-only access:

1. On the ADVANCED > Secure Administration page, select Yes to enable HTTPS/SSL Access Only to the web interface. Setting this to No will still allow the Barracuda Web Security Gateway to accept non-SSL connections. 2. Enter your desired Web Interface HTTPS/SSL port for the web interface. The default is 443. 3. Click Save.

If you wish to change the certificate that is used, you can either create a self-signed certificate or upload a certificate you purchase from a trusted Certificate Authority (CA) to the Barracuda Web Security Gateway. Changing the Certificate Type in the SSL Certificate Configuration section of the ADVANCED > Secure Administration page allows you to either create a self-signed certificate with your organization information, or create a Certificate Signing Request (CSR) to purchase a trusted certificate. Click the Help button on the ADVANCED > Secure Administration page for instructions to create and/or upload a certificate. The Barracuda Web Security Gateway supports the following types of certificates:

Default (Barracuda Networks) certificates are signed by Barracuda Networks. On some browsers, these may generate some benign warnings which can be safely ignored. No additional configuration is required to use these certificates, which are provided free of charge as the default type of certificate. Private (self-signed) certificates provide strong encryption without the cost of purchasing a certificate from a trusted Certificate Authority (CA). These certificates are created by providing the information requested in the Private (self-signed) section of the page. You may also want to download the Private Root Certificate and import it into your browser, to allow it to verify the authenticity of the certificate and prevent any warnings that may come up when accessing the web interface. Trusted (signed by a trusted CA) certificates are issued by trusted Certificate Authorities (CA), and must be purchased from them separately with a Certificate Signing Request (CSR). The CSR can be downloaded from the Barracuda Web Security Gateway after providing the information requested in the Trusted (Signed by a trusted CA) section of the page. Once you have received the certificate and key from the CA, you must upload both items to the Barracuda Web Security Gateway from this section of the page. The certificate will be in effect as soon as the upload is complete.

Continue with Step 5 - Connect the Barracuda Web Security Gateway to Your Network.

Step 5 - Connect the Barracuda Web Security Gateway to Your Network

Begin by choosing either inline or forward proxy deployment. For details about each option, see Inline Pass-Through (Transparent) Mode Deployment and Forward Proxy Deployment of the Barracuda Web Security Gateway.

Inline Deployment

1. Connect the Ethernet cable from your corporate firewall to the WAN port on the front panel of the Barracuda Web Security Gateway. This step may require disconnecting your internal network switch from the corporate firewall. A crossover cable may be needed if your corporate firewall does not have a switchable port and therefore cannot switch between RX and TX. Another solution is to place a switch between the corporate firewall and the Barracuda Web Security Gateway. You do not need to configure the WAN port. The Barracuda Web Security Gateway creates an Ethernet bridge between the WAN and LAN ports. 2. Connect the LAN port of the Barracuda Web Security Gateway to your internal network switch, router or hub.

3. Select the BASIC > IP Configuration page in the web interface, and set the Operating Mode to Audit and test out your current policy settings as described below in Set the Operating Mode.

Forward Proxy Deployment

1. Connect either the WAN or LAN port of the Barracuda Web Security Gateway to the same switch as the network gateway (just one network hop away). 2. Configure your clients’ HTTP proxy settings from their browser to access the Internet. See Forward Proxy Deployment of the Barracuda Web Security Gateway for more information.

Determine if You Need to Set Up Static Routes

If necessary, set up Static Routes on the BASIC > IP Configuration page. Setting up static routes is often required in more complex networks so that the Barracuda Web Security Gateway knows the proper route for returning client traffic to your network's next device (which the Barracuda Web Security Gateway is connected to), in order for that device to handle routing the traffic back to the client(s).

Using static routes enables the Barracuda Web Security Gateway to protect any client machines that have IP addresses outside of the native

Copyright © 2017, Barracuda Networks Inc. Barracuda Web Security Gateway Administrator's Guide - Page 97 subnet of the Barracuda Web Security Gateway. For example, if the Barracuda Web Security Gateway is assigned an IP address of 172.20.0.6 and a subnet mask of 255.255.255.0 and uses the default gateway at 172.20.0.9, you will need to create a static route to reach client machines in the 192.168.2.x range with a netmask value of 255.255.255.0. The Gateway Address should be inside 172.20.0.x. See Using Static Routes for more information.

Test and adjust the Barracuda Web Security Gateway

After connecting your Barracuda Web Security Gateway to the network, verify connectivity. Open your web browser from a machine on your network. If you cannot browse the web, review the installation steps to make sure your Barracuda Web Security Gateway is properly configured and connected to your corporate firewall and network switch.

If you can browse the web without any issues, you are ready to adjust the settings on the Barracuda Web Security Gateway. The most common adjustment to make is to create filters that determine what traffic and applications the Barracuda Web Security Gateway blocks and accepts. For more information about the available filters, refer to Monitoring the System.

Set the Operating Mode

Inline deployment:

1. Set the Operating Mode to Audit from the BASIC > IP Configuration page, and note how traffic is logged. In Audit mode, traffic is only logged, not blocked. As you configure policies on the BLOCK/ACCEPT pages, with the Barracuda Web Security Gateway in Audit mode , you can see how your users surf the web and adjust policies accordingly. 2. When you are ready to block traffic based on those policies, for an inline deployment, change the Operating Mode to Active. Now traffic will be blocked per polices you have set, as well as being logged.

Forward proxy deployment:

In this deployment, Audit and Active modes behave the same way; traffic is logged and is blocked per policies you set. See Understandi ng Operating Modes in Step 3 - Configure the Barracuda Web Security Gateway for more information on these modes.

Exempt Specific IP Addresses or Clients

Go to the BLOCK/ACCEPT > IP Block/Exempt page and use the IP and Port Exemption section to bypass scanning or filtering for clients or targeted servers. To avoid accidentally specifying a broader than intended exemption range, be sure to apply the proper subnet mask.

Filtering HTTPS Traffic

HTTPS traffic can be detected by content category filters and domain filters, as well as by blocking exceptions for all web traffic, content category filters, and domain filters. This option is disabled by default, go to the BLOCK/ACCEPT > Configuration page to enable HTTPS filtering. Note that the Barracuda Web Security Gateway relies on DNS responses when filtering HTTPS traffic. In order for the rules to be applied properly for HTTPS requests, DNS queries and responses should go through Barracuda Web Security Gateway. This requries doing the following:

1. On the BASIC > IP Configuration page, set the primary DNS server to an external one. 2. Set the DNS server in all clients to the same primary DNS server.

When first enabling HTTPS filtering, any client PCs that had previously established an HTTPS session will not be blocked. In this situation, the HTTPS website's IP address remains in the user's local DNS cache (as well as in the DNS table on the core router or domain controller) until the DNS request time-to-live (TTL) expires. This can take up to a day or two, depending upon how the HTTPS sites configure TTL. What this means is that, until the user performs another DNS lookup of a website's domain name, the Barracuda Web Security Gateway won't automatically know which domain is associated with the IP address and won't be able to perform any domain blocks on those connections.

To avoid this issue, you can manually clear the DNS cache on your network's DNS servers.

For a secure deployment, Barracuda recommends reviewing Securing the Barracuda Web Security Gateway.

Barracuda Web Security Gateway 30 Day Evaluation Guide

Where to start

Please begin with the Getting Started guide to review deployment types and safely install and configure your Barracuda Web Security Gateway. If you have the Barracuda Web Security Gateway Vx virtual appliance, start with Virtual Deployment, then return to this page for hints and guidelines for your 30 day evaluation process.

If you have a model 610 or higher, you automatically have a Barracuda sales engineer assigned to help you make the most of your 30 evaluation of the Barracuda Web Security Gateway. Simply call your reseller or sales representative if you have not yet been contacted by a sales engineer.

Evaluation Methodology

When evaluating the Barracuda Web Security Gateway, it is preferable to address two aspects separately:

Functional testing Sizing for production environment: Size the Barracuda Web Security Gateway based on throughput, concurrent users and active TCP connections. Use the BASIC > Dashboard page to view and monitor these statistics.

It is recommended that you first evaluate device functionality on a sub-set of network traffic before deploying the Barracuda Web Security Gateway in a production environment. This will allow you to characterize your network better and familiarize yourself with the product before addressing production concerns.

Common Use Cases

Use Case: Reporting

1. If possible, deploy the Barracuda Web Security Gateway inline as described in Inline Pass-Through (Transparent) Mode Deployment. This deployment does not require setting a proxy in client browsers. You can either set up the Barracuda Web Security Gateway inline with your computer for initial testing, or follow steps 3 and 4 to configure users and authentication for testing policies. 2. Set the Barracuda Web Security Gateway Operating Mode on the BASIC > Administration page to Audit. This mode logs traffic but doesn't warn or block users from accessing any URL. In Audit mode, for inline deployments, HTTP traffic is logged but not blocked, and downloads over HTTP are NOT scanned for viruses or spyware. Use this mode to preview how your currently configured Internet policies would be applied, but without disturbing production traffic. In Forward Proxy deployment, Audit mode works just like Active mode; traffic is logged and policies are applied. 3. Configure authentication as needed using your LDAP server, Kerberos or NTLM. See How to Choose Your Authentication Mechanisms f or more information and to get started. 4. Create a set of Users and Groups if you want to assign block and allow policies to Authenticated users. 5. Use the filters on the BLOCK/ACCEPT pages to set policies for what you want to block, monitor, warn users about, or allow in web traffic for Authenticated or Unauthenticated users. See Best Practices in Configuring Policy for guidelines in setting up your traffic filtering policies. 6. After you have had the Barracuda Web Security Gateway running for a while, run reports on user activity, bandwidth usage, most visited domains, and other metrics from the BASIC > Reports page. 7. After reviewing reports, you'll have a good idea of what browsing activities or web 2.0 applications you want to warn, monitor, block or allow. Use the BLOCK/ACCEPT pages to adjust policies according to your organization's needs. 8. When you are ready to begin blocking specific web traffic, set the Barracuda Web Security Gateway Operating Mode on the BASIC > Administration page to Active.

Use Case: Social Media Regulation and Monitoring

The Barracuda Web Security Gateway 410 and higher enables granular control over Web 2.0 applications running over HTTPS. For example you can allow access to Facebook messages but block games, chat, posts etc. You can provide safe access to YouTube videos by simply enabling the Safe Browsing feature on the BLOCK/ACCEPT > Content filter page. Since most social media applications such as Facebook and G Suite typically run over HTTPS, you must configure the SSL Inspection feature on the Barracuda Web Security Gateway, which is available on the 410 and higher. It is recommended to work with your sales engineer to configure SSL Inspection.

With the Web Application Monitoring feature and SSL Inspection, you can capture and archive the content of social media interactions.

1. For the Barracuda Web Security Gateway 410 and higher, enable SSL Inspection. See Using SSL Inspection With the Barracuda Web Security Gateway for details. 2. Follow steps 2-5 above. 3. See the BLOCK/ACCEPT > Web App Monitor page in the Barracuda Web Security Gateway web interface to configure. See How to Configure Web Application Monitoring for more information and examples.

For schools, using SSL Inspection and Web Application Monitoring provides powerful benefits with common use cases such as these:

G Suite Control Over HTTPS - Granular regulation of G Suite tools over HTTPS (Business Gmail as opposed to personal Gmail, and more) Facebook Control Over HTTPS - Granular regulation of Facebook applications (chat, posting, games, etc.) Alert authorities of emerging cases of cyberbullying, harassment, or loss of confidential data using the Suspicious Keyword Tracking feat ure. Monitor social messaging in real time, with keyword alert emails to teachers or administrators. This feature does not require the use of SSL Inspection unless you want to monitor HTTPS traffic content, and is available on the Barracuda Web Security Gateway 610 and higher.

With the Barracuda 210 and 310, you can block or allow websites and subdomains as well as some applications, but you cannot capture the content of social media interactions as described above. To simply block or allow applications like Facebook Games, Flickr upload, LinkedIn Email and many more, see the BLOCK/ACCEPT > Web App Control page in the web interface.

Use Case: Remote Filtering for Students and Offsite Users

Remote Filtering with the Barracuda Web Security Gateway enables your IT department to provide and control content security beyond the perimeter of the IT infrastructure. To learn about options for managing and applying filtering policies to remote laptops, iOS devices and other computers, see Filtering Traffic for Offsite and Mobile Users.

1. Begin by deploying the Barracuda Web Security Gateway in your network, selecting your authentication mechanism, and testing out policies as described above. 2. After you have configured and tested block and allow policies and authentication, you're ready to test extending this protection to your remote laptop or iPad, for example. If your use case is: Chromebooks - Configure the Barracuda Chromebook Security Extension using your G Suite admin console. Remote laptops, PC and Macintosh computers – Install the Barracuda Web Security Agent on one of these devices, which synchronizes them with the Barracuda Web Security Gateway policies. See Barracuda Web Security Agent - How it Works and How to Install the Barracuda WSA with the Barracuda Web Security Gateway to get started. Students with school issued iPads – Install the Barracuda Safe Browser to direct traffic from the iOS device to the Barracuda Web Security Gateway. 3. Test your block and allow policies with one remote device before extending to all remote devices.

For use case examples specific to students, see:

Facebook Control Over HTTPS G Suite Control Over HTTPS Barracuda Web Security Gateway for Education

Creating Exceptions to Policies

If you want to exempt certain users from block and allow policies, such as HR, Finance, Students, Teachers, etc.:

1. Create users and assign them to groups of users on the USERS > Users and Groups pages. 2. Set up your authentication mechanism as described above for users and groups. 3. Use the BLOCK/ACCEPT pages as described above to create policies. 4. Use the BLOCK/ACCEPT > Exceptions page to create exceptions to policies. See Exception Policies for more information and examples.

Securing the Barracuda Web Security Gateway

Secure Deployment

You can deploy your Barracuda Web Security Gateway either behind your corporate firewall or in front of your corporate firewall in the DMZ. However, for maximum security, Barracuda Networks recommends deploying the Barracuda Web Security Gateway behind a corporate firewall. See Deployment Options.

Securing Network Access

To secure your Barracuda Web Security Gateway on your network, begin by locking down the user interface ports. Barracuda Networks recommends using the non-standard port 8000 for internal access to the web interface, which is configured on the BASIC > Administration pag e. From that page you can also further limit access to the web interface by IP address with the Administrator/IP Range setting. If no IP address is specified in this field, all systems are granted access with the correct administrator password.

You can secure external access to the Barracuda Web Security Gateway with the Web Interface HTTPS/SSL Port setting on the ADVANCED > Secure Administration page. The recommended port is 443 because it is a standard HTTPS/SSL port used for secure web browser communication and because the identity of the remote-connected server can be verified with significant confidence. When this what is 'this'? is enabled, all non-SSL connection requests coming through the web interface HTTP port (as designated on the BASIC > Administration page) ar e automatically re-directed to the Web Interface HTTPS/SSL Port you designate. To configure SSL-only access to the web interface, see How to Enable SSL for Administrators and Users.

SSL Certificates

As described above, limiting user interface access to HTTPS provides further security and can also be configured on the ADVANCED > Secure Administration page along with the use of SSL certificates. There are three types of SSL certificates to choose from:

Default (Barracuda Networks) Private (self-signed) Trusted certificate - a certificate signed by a trusted certificate authority (CA)

For more information about the types of certificates and how to configure them, click Help on the ADVANCED > Secure Administration page.

Limiting Access to the API

The Barracuda set of APIs provides for remote administration and configuration of the Barracuda Web Security Gateway. By using the Barracuda Web Security Gateway APIs, IT administrators can easily manage large blocks of usernames, create local or IP groups, and configure some single global variables. For more information, see Barracuda Web Security Gateway API Guide.

To limit access to the API, use the Allowed SNMP and API IP/Range setting on the BASIC > Administration page. The IP addresses you enter in that field can also establish an SNMP connection to the system.To secure use of the API, you must also create an API password, which can be entered on the same page.

Managing Policies

Begin creating filtering policies which you can assign to specific users and/or groups by following recommended Best Practices in Configuring Policy. The next few articles cover the basics of creating block and allow (accept) policies. You can test most of the block/accept policies you create as described in Policy Rule Checking.

The BLOCK/ACCEPT pages in the web interface provide a wide range of filters that enhance the default spyware and virus detection capabilities of the Barracuda Web Security Gateway. Note that application filtering is supported by the Barracuda Web Security Gateway appliance, but not by the Barracuda Web Security Gateway Vx virtual machine.

In this Section

Best Practices in Configuring Policy BLOCK/ACCEPT Order of Precedence - Barracuda Web Security Gateway Block Messages Block Pages, SSL Inspection and HTTPS Filtering Using Custom Categories Typosquatting Protection Web and Desktop Application Control How to Configure Web Application Monitoring version 6.x - 7.x Exception Policies Version 7 and Above Policy Rule Checking Barracuda Web Security Gateway for Education How to Restrict YouTube Content On Your Network How to Enable Safe Search Suspicious Keyword Tracking Temporary Access for Education How to Use Temporary Access for Students - Teacher's Guide Captive Portal Terms and Conditions Page Creating Block and Accept Policies How to Disable Auto-Complete for Popular Search Engines

Best Practices in Configuring Policy

Begin creating filtering policies which you can assign to specific users and/or groups by following the best practices listed below. The BLOCK/ACCEPT pages in the web interface provide a wide range of filters that enhance the default spyware and virus detection capabilities of the Barracuda Web Security Gateway. Note that application filtering is supported by the Barracuda Web Security Gateway appliance, but not by the Barracuda Web Security Gateway Vx virtual machine.

Users and Groups for Authentication

You can apply domain, IP address, pattern, content, application, and MIME type blocking filters to authenticated and/or unauthenticated users. The first step in creating your policy should be deciding which categories your users will not be allowed to visit (Adult Content, Game Playing & Game Media, Streaming Media, etc.). You can later override this policy using exception policies to grant either additional or more restrictive access for individual users or groups. Before you create or modify a filter, make sure to use the drop-down menu on the right side of the web interface page to select which type of user you want the filter applied to (authenticated or unauthenticated).

Use the USERS/GROUPS pages to manage users and authentication.

Exception Policies for Specific Access

Exceptions are useful for creating policies that allow a subset of your users to access content that is blocked for other users. On the BLOCK/ACC EPT > Exceptions page, you can create policies to override filters you have created on a per-user or group basis. For example, if you configure your content filters to block access to auction sites for both authenticated and unauthenticated users, but a member of your purchasing department requires access to these sites, you can create an exception policy that allows access to only this user. Or you could create an exception for the entire purchasing department (a 'Group') using the LDAP organizational unit in your Active Directory server.

Exception policies are applied in the order in which they are listed in the table on the BLOCK/ACCEPT > Exceptions page of the web interface. You can drag and drop exceptions to re-order them in the table. See Exception Policies Version 7 and Above for details.

Block Pages and Authorized Logins

When a user tries to access content that is blocked by one of the assigned filters, the user receives a block message (see Figure 1 below) that may contain login fields, depending on how you configure authentication on your Barracuda Web Security Gateway. If you want to hide the login fields because you have not created any exception policies that allow users to bypass the block filter, go to the BLOCK/ACCEPT > Configuration page and change the Enable Login Override of Block Pages setting to No. Note that remote users who access the Barracuda Web Security Gateway via the Remote Filtering (WSA) feature or via the Barracuda Safe Browser on their mobile devices will not see login fields on block pages.

Figure 1: Block Message with Login Fields

The Barracuda Web Security Gateway will recognize specific types of block and accept rules in the order they are listed (from top to bottom). If conflicting rules are created, the rule listed first will be honored. Block rules take precedence over Allow rules of the same type. The exception to this is whitelists, such as, for example, domains or URL patterns: whitelists take precedence in this case.

Custom Categories

When a custom category a URL belongs to is set to Allow, that means that the custom category will not cause a block, but the URL is still checked against other categories. If the URL belongs to a blocked category, then URL is blocked.

This rule can be overridden by one of the following:

Using the Recategorize Domains option when creating the custom category on the BLOCK/ACCEPT > Custom Categories page. Creating an exception (BLOCK/ACCEPT > Exceptions page) for the custom category to make sure the rule configured for the custom category will take precedence.

The different rules, configured under the BLOCK/ACCEPT tab, are applied in this order:

1. IP Block/Exempt 2. Exceptions 3. Applications 4. MIME Type Blocking 5. Domains 6. URL Patterns 7. Content Filter

You can use the Policy Rule Check feature on the ADVANCED > Troubleshooting page to test your block and accept rules as well as exceptions. See Policy Rule Checking for details.

Policy Alerts: You can specify email alerts to be sent to an administrator or other roles when one or more users violate content filtering policies (Block, Warn or Monitor Actions) more than a specified number of times. See Policy Alerts for more information.

BLOCK/ACCEPT Order of Precedence - Barracuda Web Security Gateway

The BLOCK/ACCEPT pages in the Barracuda Web Security Gateway web interface provide a wide range of filters that enhance the default spyware and virus detection capabilities of the Barracuda Web Security Gateway. Note that application filtering is supported by the Barracuda Web Security Gateway appliance but not by the Barracuda Web Security Gateway Vx virtual machine. See also Best Practices in Configuring Policy for guidelines on planning and creating your Block/Accept rules, and Creating Block and Accept Policies for details on filters available.

Order of Precedence of Block/Accept Rules

The Barracuda Web Security Gateway will recognize specific types of block and accept rules in the order they are listed below (from top to bottom). If conflicting rules are created, the rule listed first will be honored. Whitelist or Allow rules take precedence over Block rules of the same type.

1. BLOCK/ACCEPT > IP Block/Exempt - Use this section to exempt traffic from all filtering - including spyware filtering - based on IP address criteria. You can exempt certain ports, portions of your network, or external application servers. 2. Temporary Whitelist - This applies to websites which administrators or teachers request to allow for access by students, employees, etc. for a temporary time period, as specified with the Temporary Access tool. 3. BLOCK/ACCEPT > Exceptions - Use the Exceptions page to manage policy exceptions for specific users or groups. An exception rule grants selected users - local users or groups, domain users or groups, or all users (authenticated or unauthenticated) - exceptions to a Barracuda Web Security Gateway policy for a specific period of time. 4. BLOCK/ACCEPT > Applications - Available for Inline deployments only. Use this feature to block or allow specific application traffic. You can select from a pre-defined list of non-HTTP web applications including IM clients, media programs, common PC tools, software updates, and peer-to-peer software. 5. BLOCK/ACCEPT > MIME Type Blocking - Use the MIME Type Blocking page to blacklist standard MIME types. You can create a MIME type blacklist for either unauthenticated or authenticated users. These rules are useful when content is not easily blocked by other methods.

Note the mimetype blocking only applies to HTTP responses, and therefore will not be observed for requests that are blocked due to other rules, including category-based content filtering.

6. BLOCK/ACCEPT > Domains - Use this section to specify a domain that should be blocked, warned, or monitored. This blocking filter will operate in addition to those defined in other filtering categories. 7. BLOCK/ACCEPT > URL Patterns - Use this section to specify a pattern or keyword to match parts of a URL that should be blocked, warned, or monitored. 8. BLOCK/ACCEPT > Content Filter - Use the Content Filter page to manage your users' Internet access based on the web site content being requested. You can apply content category filters to either unauthenticated or authenticated users.

Barracuda does not recommend using IP block/exempt rules for blocking traffic to websites or for specific applications. IP block/exempt rules are generally used to control access to and from particular client computers or external web servers (such as email servers or update servers). However, you can use this feature to control access by specifying destination IP/port combinations. Keep in mind that these rules have precedence over all other block/accept rules.

Block Messages

When the Barracuda Web Security Gateway blocks access to a website, it presents a block page with a message that informs the user why that site is being blocked as shown in Figure 1. The Barracuda Web Security Gateway blocks a website if it contains spyware, a virus, content that has been blocked due to policies you set, or a blacklisted URL. You can optionally choose to have the Barracuda Web Security Gateway redirect blocked users to any other URL, such as a custom block page, search engine page, etc. If Enable Typosquatting Protection is set to Yes on the BLOCK/ACCEPT > Configuration page, users who type or click on misspelled URLs will receive a block page as described in Typosquatting Protection.

If you are using the Barracuda Web Security Gateway built-in block page, use the BLOCK/ACCEPT > Block Messages page to perform the following tasks:

Select the language that the block message is displayed in for all users. Customize the message in case the default text is insufficient.

Figure 1. Block Message with Login Fields.

For a list of special characters you can use to customize block message text, go to the the BLOCK/ACCEPT > Block Messages page in the web interface, and click Help.

With the Barracuda Web Security Gateway 610 and higher: If you enable the Temporary Access feature for teachers and students to gain access to specific websites for classroom research, students can enter a token given by the teacher to temporarily bypass block pages. Alternatively, you can allow teachers to use log in credentials to gain access to those sites for a limited time. See Temporary Access for Education for details about this feature, which offloads temporary access management from the system administrator to the teacher.

Remote users logged in with the Barracuda Web Security Agent (WSA) will not have the option to bypass block pages with a login.

External Block Page

You can choose to redirect the user to a custom block page which you provide/design (or any URL) instead using the Barracuda Web Security

Gateway block page when a policy prevents the user from accessing a requested website or application. To use this option you must enable the Use External Block Page feature and specify an External Block Page URL on the BLOCK/ACCEPT > Configuration page.

The Barracuda Web Security Gateway will redirect the blocked user to the URL you specify, which can be your own page/site, a search engine, etc.

Terms and Conditions Page (Captive Portal)

Hotels, Internet cafes and BYOD mobile devices are typical use cases for this feature, which provides a portal with a customized Terms and Conditions page for unauthenticated or authenticated users. The user is required to agree to specified terms and conditions before they can begin browsing the web via the Barracuda Web Security Gateway, unless the user has LDAP credentials and the correct configuration applies per settings on the BLOCK/ACCEPT > Configuration page.

See Captive Portal Terms and Conditions Page for details.

Block Pages, SSL Inspection and HTTPS Filtering

If you only need to apply block policies by domain and/or domain (content) categories, you can enable HTTPS filtering on the 210 and higher as opposed to using SSL Inspection. Unlike SSL Inspection, HTTPS filtering does not decrypt the encrypted portion of URLs. This prevents monitoring or capturing of social media interactions such as posts, chat, comments, shares, etc. Note the occasional condition when a block page is not served per policy when HTTPS Filtering is enabled AND SSL Inspection is enabled in Transparent mode:

*If HTTPS filtering already blocked traffic, it will not reach the proxy and no block page will be served.

See also Block Messages and Using SSL Inspection With the Barracuda Web Security Gateway.

Using Custom Categories

You can create custom categories to filter traffic from specific domains, specific categories, or combinations of domains and categories. Go to the Block/Accept > Custom Categories page and complete the following:

1. Specify a name for your custom category in the Custom Category Name field. 2. Enter the names of the domains to include in this category in the Domains to be included field. 3. Check Recategorize Domains to associate the specified domains with the new custom category. The domains will no longer be associated with their previously assigned category. 4. Select items from the Existing Categories To Be Included list and click << Add to include them in the new custom category. 5. Click Add at the bottom of the page to create the new custom category.

Use the custom categories in the same ways as the default categories, applying the same rules or exceptions.

Typosquatting Protection

The Typosquatting Protection service protects users from accessing URLs that may be misspelled and, therefore, misrepresented, by typosquatting.

What is Typosquatting?

Typosquatting is a common trick used by hackers to fool users into thinking they are visiting a valid domain, but the domain name is misspelled. When a user clicks on a typosquatted URL, the user is taken to a different domain that may be spoofing the expected domain. The Typosquatting Protection feature checks for common typos in a clicked or manually typed URL domain name. When a typosquatted domain is either clicked or manually miss-typed, the user is directed to a block page that indicates that this may not be the website they believe they are visiting, and provides a link to the legitimate URL, directing the user to the proper website.

For example, if the URL https://www.tripadivsor.com (where the 'i' and 'v' positions are switched in the domain name) appears on a website, or if the user types that URL, the service detects the typo and provides a block page with a link to the valid domain https://www.tripadivsor.com. The user can then click the legitimate link to visit the proper website.

How to Enable Typosquatting Protection

1. Log into the Barracuda Web Security Gateway as admin. 2. Go to the BLOCK/ACCEPT > Configuration page. 3. In the Typosquatting Protection section, set Enable Typosquatting Protection to Yes.

Barracuda Typosquatting Protection works with the Barracuda Web Categorization Service (WCS) to determine misspelled domain names. See Web Use Categories for more information about the Barracuda WCS. If you want to allow any misspelled domains, you can recategorize the domain using the BLOCK/ACCEPT > Custom Categories page.

Typosquatting Block Page

If a user types a URL or clicks a link that is typosquatted, for example: facebookk.com, the Barracuda Web Security Gateway serves the following block page to the user, warning of fraud and providing a link to the correct domain:

How to Customize the Block Page

The administrator can create a custom message for the block page shown above using the tool on the BLOCK/ACCEPT > Block Messages pag e.

False Positives

If a domain is reported and blocked for the user as Typosquatted, but the domain is valid, you can recategorize that domain on the BLOCK/ACC EPT > Content Filters page under a category that is allowed. Use the Typosquatting Log report for a list of domains by category that were determined to be typosquatted, by user.

Web and Desktop Application Control

Desktop Applications Versus Web-Based Applications

The Barracuda Web Security Gateway offers administrators control over both desktop and web based applications. Common desktop applications include iTunes, Real Player and Jabber, which use both standards based and proprietary communication protocols. Web based applications include Facebook and LinkedIn and are primarily presented through a web browser. This article defines how the administrator can create block/allow policies and archive social media interactions with the Barracuda Web Security Gateway.

Managing Desktop (Non Web-Based) Applications

In the case of desktop applications, the Barracuda Web Security Gateway enables administrators to define block/allow policies on popular applications using the BLOCK/ACCEPT > Applications page. For instance, file sharing sites such as BitTorrent and communication apps such as AOL IM can be blocked as per corporate policy. These policies can be defined against authenticated and unauthenticated users to offer more access to a given set of users.

Further, entire protocols can be blocked such as FTP, POP, and SSH. See Application Filtering for Non Web Based Applications.

Managing Web-Based Applications

The Web Application Control feature offers administrators fine grained control over web applications. What this means is that, when the SSL Inspection feature is enabled on the Barracuda Web Security Gateway 410 and higher, administrators can create policies such as:

Block certain portions of web based applications such as Facebook Chat and Facebook Sharing, while allowing users access to the rest of Facebook. Block access to Google Consumer Apps such as Google personal email accounts, but allow access to Google business (or education) email accounts. This feature requires Barracuda Web Security Gateway version 9.1 or higher. Because of the way Google now handles SSL certificates, there are currently some restrictions with SSL Inspection on Google sub domains. For details, see Google Restrictions With SSL Inspection. For examples of block/allow policies with Google business/education versus consumer accounts, see G Suite Control Over HTTPS and How to Restrict YouTube Content On Your Network. For Chromebooks users, if you are running the Barracuda Web Security Gateway 10.1 or above, see How to Get and Configure the Barracuda Chromebook Security Extension.

With the Facebook example, the administrator can define what they deem permissible on their network without having to block all of Facebook. As shown in Figure 1 below, the Facebook Twitter app and Games have been added to the list on the right of Blocked Applications. See the BL OCK/ACCEPT > Web App Control page for more information and to configure.

If you have a Barracuda Web Security Gateway 210, which doesn't provide SSL Inspection, you can alternatively block some or all HTTPS traffic by domain or by content category, but without granular control over web applications. This is also a common use case for the Barracuda Web Security Gateway 310 (running version 10.0 or above), since it offers limited SSL Inspection (only for Safe Search). For information on how to block/allow HTTPS traffic by domain or content category (does not include decryption of the URL contents), see HTTPS Filtering With the Barracuda Web Security Gateway.

Figure 1. Facebook is generally allowed, but the Facebook Twitter app and Games have been blocked by the administrator.

Monitoring Social Media Content

A powerful feature for meeting CIPA requirements and protecting students is the Web Application Monitoring function. This feature captures web activities such as comments and posts and packages the content in SMTP messages for email notifications and/or archiving. The monitoring feature allows administrators to track suspicious keywords that may signal potentially harmful behavior from a particular user. For more information about this feature, see How to Configure Web Application Monitoring. This feature is available:

With the Barracuda Web Security Gateway 610 and higher running version 7.0 and above OR With the Barracuda Web Security Gateway 410 and higher running version 10.0 and above

To configure, see the BLOCK/ACCEPT > Web App Monitor page in the Barracuda Web Security Gateway web interface.

The Barracuda Web Security Gateway receives periodic updates to its application and web application definitions to quickly react to the dynamics of the market. See Using SSL Inspection With the Barracuda Web Security Gateway and How to Configure SSL Inspection for details.

How to Configure Web Application Monitoring version 6.x - 7.x

This feature applies to the Barracuda Web Security Gateway 610 and higher running firmware version 6.0 and higher. Some features, as noted below, are only available with version 8.0 and higher; see also How to Configure Web Application Monitoring Version 8.x and Above.

See also:

Using SSL Inspection Web and Desktop Application Control Application Filtering for Non Web Based Applications

IMPORTANT Due to recent vulnerabilities discovered with the SSL protocol, Barracuda strongly recommends that you upgrade to 8.1.0.005 before using SSL Inspection. See the Barracuda Networks Security Updates blog post around this topic: Barracuda delivers updated SSL Inspection feature. Available with the Barracuda Web Security Gateway 310 (limited) and higher.

Capture and Archive Suspicious Content or Data Patterns in Chat, Email, and Other Social Media Communications

The Barracuda Web Security Gateway can inspect and catalog outbound content and forward it to an email address or external message archiver, like the Barracuda Message Archiver. These messages can be fully indexed and tied to Active Directory credentials of users. The archived content is then as easy to search as MS Exchange emails. This process ensures that social media communications from corporate networks are always available for access and retrieval for eDiscovery and audits as well as to create alerts for proactive monitoring.

Specific data patterns such as credit card numbers, Social Security numbers (U.S.), HIPAA, and privacy information can also be detected to help prevent data leakage.

Use this feature to capture and archive chat, email, user registrations and other social media communications on social media portals. Set alerts to be sent to the administrator email address if certain data patterns are detected in outbound traffic, such as Social Security or credit card numbers, or HIPAA related content.

Figure 1: Web Activity Monitoring

How Archiving and Searching Monitored Web Activity Works

On the BASIC > Web App Monitor page, you can specify a Web Activity Archiving Email Address for archiving selected actions such as logins, chat, posts, comments and associated content. The Barracuda Web Security Gateway packages each interaction as an SMTP message and emails it to this address. This content is then marked for archiving. Archived messages are indexed and can be searched by source or content. Alerts can be generated per policy you set in your archiving solution, or specifically based on specific data patterns. For information about searching archived messages and using policy alerts with the Barracuda Message Archiver, see Understanding Basic and Advanced Search and Policy Alerts.

NOTE: If you want actions shown with an asterisk (*) on the BLOCK/ACCEPT > Web App Monitor page to be archived, you must enable SSL Inspection. Example actions include:

Facebook user registration and login Google chat message Twitter send tweet, login, direct message, user registration

For a complete list of actions for which SSL Inspection must be enabled for capture, see the BLOCK/ACCEPT > Web App Monitor page. For more information about SSL Inspection, see Using SSL Inspection With the Barracuda Web Security Gateway and How to Configure SSL Inspection 6.x.

How to Configure Social Media Archiving

As an example scenario, you might want to allow users in the organization to use Facebook to view and make comments and use messaging, but you want to capture the content. You might also want to block games and/or other Facebook apps to protect your network from viruses and malware.

If you want to regulate web 2.0 applications over HTTPS, then you must configure SSL Inspection from the ADVANCED > SSL Inspection page and set up SSL certificates. See How to Configure SSL Inspection 7.0.

To configure Web Application Monitoring for archiving social media interactions, first set up your block/accept policies for social media. Here's the process for the example mentioned above:

1. On the BLOCK/ACCEPT > Web App Control page, in the Application Navigator, ensure that Social Media is checked. In the Allowed Applications list box, hold the CTRL key and click Facebook Games and Facebook apps. Click Block. Those applications then appear in the Blocked Applications list box.

Detecting Sensitive Data Patterns

Social media and other application communications as noted above may also be searched for data patterns such as:

Credit card numbers Social security numbers Privacy terms HIPAA compliance terms

To help defend against potential data breaches, use the Data Pattern Categories to Monitor section to select applicable data patterns to detect in web applications that you enable on the BLOCK/ACCEPT > Web App Monitor page. To configure this feature:

Enter a Suspicious Keywords Alert Email Address in the Web Activity Notification section of the BLOCK/ACCEPT > Web App Monitor page if you want to receive an alert when these data patterns are detected in the applications you select. If you also want to archive these communications, enter a Web Activity Archiving Email Address in the Web Activity Notification sec tion of the page. After you enable any actions on the page, the Barracuda Web Security Gateway will capture the content from each action in which the selected data patterns are detected, package it as an SMTP message and email it to that email address.

Web App Monitor Log

The BASIC > Web App Monitor Log lists all chat, email, user registrations and other social media interaction traffic it processes per settings you

Date – Date and time of the request. Source IP – IP address of the client that originated the request. Username – The name of the user that sent the request. Summary – The action represented in the request. For example, Facebook Comment. Destination – URL visited in the request. Details – Detailed information about the actions: search engine keywords, word from a Facebook Comment, etc.

Exception Policies Version 7 and Above

This articles applies to the Barracuda Web Security Gateway running firmware version 7.0 and higher. For examples blocking Google Consumer Apps, see G Suite Control Over HTTPS.

Once you have created desired block and accept policies, use the BLOCK/ACCEPT > Exceptions page to create exceptions to these rules for specific users or groups so they can override the filters that block, warn or monitor access to applications and websites. You can create exception policies for the following types of filters:

Domains URL Patterns Content, including Safe Search Applications Web 2.0 applications Search terms (found anywhere in the URL) All web traffic

Exceptions are useful for creating exception policies, or rules, that allow a subset of your users to access content that is blocked for other users. See Examples below.

How Exceptions Work

When a user tries to access content that is blocked by one of the Barracuda Web Security Gateway policies, the user receives a block message. If the user is not authenticated with NTLM and is not using the Barracuda WSA agent, the block page will contain login fields as shown below:

Figure 1. Block page with login fields

If an exception policy exists for the blocked content, the user can enter their username and password (LDAP credentials, if configured) for the account that was assigned to the exception policy. The block page also includes a Temporary Access Token field where a student can enter a code they've been given by a teacher to allow temporary access to a particular website or category of websites for classroom research. See Tem porary Access for Education for details. After the user enters the correct account information, the Barracuda Web Security Gateway applies the effective policy for that authenticated user.

Policy Alerts

You can configure the Barracuda Web Security Gateway to send an email alert to one or more email addresses when a content filter rule is triggered more than a specified number of times. For example, say you block the Propriety and Commerce categories on the BLOCK/ACCEPT > Content Filter page and one or more authenticated users browses sites under those categories (such as Adult Content and Shopping content

Copyright © 2017, Barracuda Networks Inc. Barracuda Web Security Gateway Administrator's Guide - Page 118 types respectively). A Policy Alert email can be sent at a predefined interval (hourly, etc.), summarizing the top number of users violating the bloc k policy for these categories.

Where to configure Policy Alerts

See the BLOCK/ACCEPT > Exceptions page to enable/disable and configure policy alerts, and to specify the action, user(s) or group(s) to include as well as the content category and threshold for when to send alerts. You can alternatively specify the email addresses to which policy alerts should be sent by role using the ADVANCED > Delegated Admin page. Configure policy alerts format (HTML, PDF, etc.) and frequency of notification emails from the BLOCK/ACCEPT > Configuration page.

Limiting Access by Time frames, Time Quotas and Bandwidth Quotas

Use the Time Quota and Bandwidth Quota exception types on the BLOCK/ACCEPT > Exceptions page to assign browsing limits by domain, URL, content category and/or application to specific groups or individual users. Time based quotas can be based upon periods of time or a calculation of time used. Periods of time are exact, for example: 1-2 pm; however, if you choose to limit time by calculation, the user's session time logic is used to determine the amount of time spent. For more information about how session times and browse times are calculated, see Re porting Version 7 and Above.

The bandwidth quotas are based on the amount of transferred data. Bandwidth quotas include both download and upload traffic. The allow and monitor actions are available for both time and bandwidth quotas. When groups are used, quotas are applied to each individual within the group, not the group as a whole.

Quotas can be configured to be in effect during the Time Frame you specify.

Examples of Using Exceptions

Example 1 – Limiting access to job search websites

Your organization configures their content filters to block access to Job Search and Career Development sites like Monster.com. However, your Human Resources department requires access to such sites. In this case, you would do the following to create the policy:

1. Go to the USERS/GROUPS > Local Groups page. Enter HR in the Group Name field group and click Add. Assign appropriate users to this group from the USERS/GROUPS > Account View or New Users page. 2. Create a Block policy for Authenticated users on the BLOCK/ACCEPT > Content Filter page. 3. On the BLOCK/ACCEPT > Exceptions page, select Allow for the Action. 4. Select Local Group for Applies To, and select HR from the dropdown to make an exception for the HR Group. 5. Select the Content Filter Exception Type. 6. Select Job Search and Career Development in the Content Type dropdown. 7. Click the Add button to create the policy.

Example 2: Suppose you want to limit access to chat sites to 30 minutes per day during business hours.

1. First create a block policy for this content category on the BLOCK/ACCEPT > Content Filter page. 2. Next, on the BLOCK/ACCEPT > Exceptions page, create an Allow action for a time quota of 30 minutes for a particular user or group between the hours of 6:00 (6am) and 18:00 (6pm) for the Content Filter Exception Type and the Gaming Content Type, and check each box for Monday - Friday. Note: Exceptions are applied in the order in which they are listed in the table on the BLOCK/ACCEPT > Exceptions page. For example, if you want to block access to all web traffic for unauthenticated users but allow access to selected websites, first create the block excepti on and then create the allow exception. You can re-order exception rules once they are created by dragging and dropping exceptions in the table.

Example 3: You might want to allow limited access to gaming sites during lunch time.

1. Create a block policy on the BLOCK/ACCEPT > Content Filter page for the Game Playing category. 2. On the BLOCK/ACCEPT > Exceptions page, create an Allow action for a particular user or group between the hours of 12:00 (12pm) and 1:00 (1pm) for the Content Filter Exception Type and the Gaming Content Type. To prevent excessive bandwidth usage (uploading or downloading), begin by creating a Block policy on the BLOCK/ACCEPT > Content Filter page for the Streaming Media category. 3. On the BLOCK/ACCEPT > Exceptions page, create an Allow action for a particular user or group for the Content Filter Exception Type and the Streaming Media Content Type, which includes the following:

Audio or video streaming services Internet TV and radio Webcam services VoIP (Voice over IP) or telephone services via your computer

Specify the bandwidth limit to allow for these types of traffic in kb and select Daily, Weekly or Monthly from the drop-down. Use the B ASIC > Reports page to create reports on time and/or bandwidth usage by user, group, application, content type, domain or URL.

Google Consumer Accounts - Creating Policies and Exceptions

Google has some restrictions when applying policy to HTTPS traffic for some Google consumer accounts applications. The Barracuda Web Security Gateway version 9.1 and above offers a Google Consumer Accounts Category Filter on the BLOCK/ACCEPT > Web App Control pag e which you can use to create block/allow policies. This category allows you to specify some or all Google Consumer Accounts apps when creating policy. See G Suite Control Over HTTPS for examples of creating policies and exceptions for these apps. For details about Google restrictions related to SSL filtering, see Google Restrictions With SSL Inspection.

If you are running the Barracuda Web Security Gateway version 10.1 or above, for blocking Google sites for Chromebook users, see How to Get and Configure the Barracuda Chromebook Security Extension.

Safe Browsing / Safe Search - Limiting to Specific Users

If you have disabled the Safe Browsing feature on the BLOCK/ACCEPT > Content Filter page, all users will be able to browse freely with the listed search engines. If you enabled Safe Browsing, users will not see search engine content that contains objectionable thumbnail images in the search results; only filtered thumbnails are displayed in the search results. For instructions on limiting safe browsing to a group such as, for example, students, see How to Enable Safe Search.

Policy Rule Checking

Policy Rule Checking allows you to test block/allow policies you create on the BLOCK/ACCEPT pages for any or all of the following (each test is optional):

URL or domain Originating IP address Time (i.e. a hypothetical time of day that a policy should apply, such as during lunch hour, for example) MIME Type - see the examples in the MIME Type column on the BLOCK/ACCEPT > MIME Types page

You can optionally select the Realm/Username for LDAP, Local or other authentication set to which the policy should apply. Note that you may receive multiple results; if so, be aware that rules and exceptions to rules are listed in order of precedence. This means that the top entry takes precedence over entries below. Make sure your block/allow rules and your exceptions agree.

In this example, testing the URL www.youtube.com reveals two results: two different exceptions that were created on the BLOCK/ACCEPT > Exceptions page, and each one takes different actions with this URL.

The first exception, or rule, takes a Deny, or block action for Authenticated users for URLs that fall into the Streaming Media content category (see the BLOCK/ACCEPT > Content Filter page). In the second exception, which takes an Allow action, the same URL is allowed as a domain, and this exception applies to All users. The first rule or exception, which blocks the URL, is the action that will be taken because it is higher on the list of exceptions.

Barracuda Web Security Gateway for Education

The Barracuda Web Security Gateway provides powerful tools for K-12 and beyond to easily address the complex challenges of content and mobile security facing today’s school-based network administrators.

Tools for Administrators

Filtering traffic for mobile devices, Chromebooks and laptops

With iPad Initiatives (school issued iPads) and campus-issued laptops and Chromebooks emerging as a standard throughout the U.S. educational system, school network administrators need to track devices on and off network as well as ensure safe browsing and enforcement of school policies regarding content. For remote users with laptops, Mac OSX computers, desktops and iOS devices, the Barracuda Web Security Gateway detects location and applies the same policies enforced on local users by deploying one of the following tools, which each provide:

Location detection Tamper proof use Safe browsing

Web Security Agent (WSA)

Deployed on each remote desktop or laptop, the Barracuda Web Security Agent proxies all web traffic over the Internet to a specified Barracuda Web Security Gateway, which is configured to recognize each remote client by traffic signed by the Barracuda Web Security Gateway. The same security policies apply to both remote users and local users. See Overview for more information.

Barracuda Chromebook Security Extension

With this extension installed in the Chromebook browser, users are identified and policy is applied based on the user whether they are inside your network or accessing the Internet from a public or private network. Additionally, user generated traffic is logged and recorded for reporting purposes, providing administrators insight into all user activity. Requires Barracuda Web Security Gateway version 10.1 and above. See How to Get and Configure the Barracuda Chromebook Security Extension for more information.

For Chromebook users with the Barracuda Chromebook Security Extension installed, policies for G Suite web traffic are configured on the G Suite Admin Console, not on the Barracuda Web Security Gateway. Also note that the settings on the BLOCK/ACCEPT > Web App Control and BLOCK/ACCEPT > Web App Monitor pages do not apply to Chromebooks running the Barracuda Chromebook Security Extension.

Barracuda Safe Browser (BSB)

Deploy and use the Barracuda Safe Browser on iOS mobile devices in place of the native browser, applying the same Barracuda Web Security Gateway security policies to remote users and local users. See Barracuda Safe Browser Setup Guide - With Barracuda Web Security Gateway.

Educational Tools, Educational Content

Restricting YouTube Content On Your Network – Access thousands of free high quality educational videos on YouTube in a controlled environment for your students. Temporary Access for Education to websites for student research – A portal to the Barracuda Web Security Gateway where teachers can request and manage temporary access for students to specified domains or categories of domains that are typically blocked by school policy.

Social Networking and Web 2.0 - Regulating Use of Applications

The Barracuda Web Security Gateway 610 and higher enables granular control over Web 2.0 applications with the SSL Inspection feature. For example, you can allow access to Facebook messages but block games, chat, posts etc. You can provide safe access to YouTube videos that provide rich educational content. With Web Application Monitoring, you can capture and archive the content of social media interactions. See Ho w to Configure Web Application Monitoring.

The SSL inspection feature is required to filter any applications that users access over HTTPS. For schools this provides powerful benefits with common use cases like these:

G Suite Control Over HTTPS – Granular regulation of G Suite tools over HTTPS (Business Gmail as opposed to personal Gmail, and more) YouTube Control Over HTTPS – Granular regulation of YouTube over HTTPS Facebook Control Over HTTPS – Granular regulation of Facebook applications (chat, posting, games, etc.) Suspicious Keyword Tracking – Monitor social messaging in real time, with keyword alert emails to teachers or administrators to trigger immediate responses to emerging cases of bullying, harassment, or loss of confidential data. This feature does not require the use of SSL Inspection unless you want to monitor HTTPS traffic content, and is available on the Barracuda Web Security Gateway 610 and higher.

Safe Search over HTTPS

Note that SSL inspection is an opt-in, resource-intensive feature that requires the Barracuda Web Security Gateway 410 and above. See How to Configure SSL Inspection for deployment requirements.

CIPA Compliance Content filtering is central to providing CIPA compliance. The Barracuda Web Security Gateway provides 95 content categories including: Destructive sites such as those promoting violence, illegal drugs, or criminal activity Sexual sites that may contain adult material or pornographic content Gaming/gambling sites Leisure sites (i.e. tobacco and alcohol)

Specific sites can also be blocked or allowed using explicit block and allow lists, and downloads can be limited to only specific approved file types. The Barracuda Web Security Gateway provides additional cutting edge tools like URL rewriting, which can automatically enforce Safe Search tags for sites like Google images and video, preventing children from circumventing protection policies through the media caches of popular search engines.

Safe Browsing / Safe Search - Limiting to Students

You can enable the Safe Browsing feature on the BLOCK/ACCEPT > Content Filter page so that the group of users you specify will not see search engine content that contains objectionable thumbnail images in the search results; only filtered thumbnails are displayed in the search results. To limit Safe Browsing only to students, but allow appearance of all thumbnail images in search results for teachers and staff, see How to Enable Safe Search.

Delegated Administration

The administrator of the Barracuda Web Security Gateway can choose to delegate certain administrative tasks such as scheduling or running reports, viewing system status, load and log pages, or creating exceptions to policy. For example, school districts can maintain system level control while providing restricted access to individual schools to manage policies or generate reports for teachers. See Role-based Administration for details.

General Web Security Gatewaying on the Campus Network

Blocking access to proxy servers students might try to use to circumvent web security gatewaying policies. IT administrators must know the IP addresses of any proxies to block as part of school policy. Ability to add new URLs daily as reported by teachers or other trusted sources. Ability to create custom categories of domains for specific filtering. Ability to report bad URLs to Barracuda Networks. Newly reported URLs to block and improved content filtering rules are updated to your Barracuda Web Security Gateway on a daily basis. Sophisticated application control - block, monitor, warn, allow on Skype, Spotify, gaming software, communications, etc. See How to Configure Web Application Monitoring.

Tools for Teachers

Temporary Access for Students (see above) - For school research projects or other classroom needs, with an easy to use web interface. See How to Use Temporary Access for Students - Teacher's Guide Suspicious Keyword Tracking and Cyberbullying Alerts (teachers can submit new keywords, keyword categories to their system administrator) How to Restrict YouTube Content On Your Network

safe browsing, student, youtube, campus, school, cyber, you tube, bully, remote user, ios

How to Configure Dropbox Business Support This feature applies to the Barracuda Web Security Gateway 310 and higher running firmware version 12.0 and higher. Note that you must configure SSL Inspection on the ADVANCED > SSL Inspection page to block HTTPS applications.

To block the Dropbox Web/Desktop Client:

1. Log into the Barracuda Web Security Gateway as admin. 2. Go to the BLOCK/ACCEPT > Web App Control page. 3. In the Allowed Applications column, make sure the Dropbox Business Apps category filter is unchecked (not Allowed). 4. Click Block >> . The Dropbox Business Apps > Dropbox Web/Desktop Client category filter should move to the Blocked Applications b ox.

To create exceptions with the Dropbox Web/Desktop Client:

For example, create an exception to allow only members of the Faculty Local Group to use Dropbox Business Apps.

1. Log into the Barracuda Web Security Gateway as admin. 2. Follow instructions above to block Dropbox Business Apps. 3. Go to the BLOCK/ACCEPT > Exceptions page. 4. Select the Allow Action. 5. Select Faculty for the Local Group in the Applies To field. 6. Select Web App Control for Exception Type. 7. Select Dropbox Business Apps for Web App Name. 8. In the Allowed IDs field, enter valid Dropbox Team IDs. See your Dropbox administrator. 9. Enter other exception policies and then click Add.

How to Restrict YouTube Content On Your Network

YouTube For Schools has been deprecated by Google, and Google now provides alternative methods to enforce safe search and restrict YouTube content: see the Google article Manage your YouTube settings.

The Barracuda Web Security Gateway works with the Google URL parameter rewrite method by appending “safe=strict” to all search string URLs. Because YouTube utilizes the HTTPS protocol, the SSL Inspection feature must be enabled and configured on the Barracuda Web Security Gateway to use this approach. The only other required step is to enable YouTube Safe Search as described in this article.

An alternative method to restrict YouTube content uses DNS redirection, which can be accomplished with an internal DNS server or solutions such as Barracuda NextGen firewalls.

How to Enable YouTube Safe Search

To restrict YouTube content on your network:

1. Log into the Barracuda Web Security Gateway web interface as admin. 2. Go to the BLOCK/ACCEPT > Content Filter page. On the top right of the page, for Policy, select either Authenticated or Unauthentic ated. 3. Scroll to the bottom of the page and click Enable for YouTube Safe Search. 4. Click Save.

Important It is important to understand that with YouTube Safe Search enabled, the Barracuda Web Security Gateway does not control the results returned to the user; this is controlled by YouTube. The Barracuda Web Security Gateway ensures that web traffic is directed to the Safe portal on YouTube, which provides limited results.

Figure 1. Blocked YouTube video.

Figure 2. Admin view of restricted video content. Note that the admin can click "Approve" to allow the video.

Controlling Access to Google Consumer Apps

For more information about restricting access to Google consumer apps, and examples, see G Suite Control Over HTTPS.

How to Enable Safe Search

Safe Search mode prevents a web search engine from displaying objectionable thumbnail images in search results; only filtered thumbnails are displayed in the search results. You can enable Safe Search with the Safe Browsing feature on the BLOCK/ACCEPT > Content Filter page. This will limit search results to filtered thumbnails in Yahoo, Bing, Google, YouTube and other applications that return video and photo thumbnail search results.

Important Since Google and some other search engines always use HTTPS, Barracuda recommends enabling the SSL Inspection feature when using Safe Search for searching YouTube videos and other web content. To enable SSL Inspection, you must have:

A Barracuda Web Security Gateway 410 running version 7.1 or above: see How to Configure SSL Inspection Version 7.1, O R A Barracuda Web Security Gateway 310 or above running version 10.0 or above: see How to Configure SSL Inspection Version 10 and Above

How to Enable Safe Search For All Users

1. Enable SSL Inspection if you want to enforce Safe Search over HTTPS, which is recommended. a. Barracuda Web Security Gateway 610 and higher: Enable SSL Inspection on the ADVANCED > SSL Inspection page and install a secure certificate in all client browsers. b. Barracuda Web Security Gateway 410 running 7.1 and higher: Enable SSL Inspection on the BLOCK/ACCEPT > Configuration page and install a secure certificate in all client browsers. 2. Go to the BLOCK/ACCEPT > Content Filter page. At the top of the page next to Policy on the right, select either Authenticated or Un authenticated. 3. In the Safe Browsing section, select the category/search engine for which you want to enable Safe Search. If you are were previously using the YouTube For Schools feature, see How to Restrict YouTube Content On Your Network. 4. Click Save.

Important With the Barracuda Web Security Gateway version 9 and above, when YouTube Safe Search is enabled, the user can only browse YouTube as a guest, and not as a logged in user. This means that private videos will not be visible, nor can videos be uploaded. The user can, however, log into Google or Gmail as usual.

If you Enable Safe Search, it will limit the thumbnails returned in search results for images and videos for ALL Authenticated or Unauth enticated users, depending on which Policy you choose per the steps above. If you want to limit Safe Search to certain users or group(s) of users, you should Disable Safe Search on the BLOCK/ACCEPT > Configuration page and create one or more Exceptions for those users. The following example illustrates the process to do that.

Use Case: Safe Browsing for Students

To limit Safe Search to a specific group of users, such as students, for example, but allow appearance of all thumbnail images in search results for teachers and staff, create an exception using the Enable action, like this example:

1. Enable SSL Inspection if you want to enforce Safe Search over HTTPS. a. Barracuda Web Security Gateway 610 and higher: Enable SSL Inspection on the ADVANCED > SSL Inspection page and install a secure certificate in all client browsers. b. Barracuda Web Security Gateway 410 running 7.1 and higher: Enable SSL Inspection on the BLOCK/ACCEPT > Configuration page and install a secure certificate in all client browsers. 2. On the USERS/GROUPS > Local Groups page, create a new group called Students. 3. On the USERS/GROUPS > New Users page, add the students' usernames on the Barracuda Web Security Gateway to the Students gr oup, following instructions in the online help for that page. 4. On the BLOCK/ACCEPT > Content Filter page, in the table under Safe Browsing, select Disable for each search engine listed in the table, or click the All link. 5. On the BLOCK/ACCEPT > Exceptions page, create the policy: a. For Applies To, select Local Group, and then in the next drop-down, select Students. b. Select the Exception Type as Content Filter. c. For Content Type, scroll down and select Safe Browsing. d. Select the Enable action (it may be automatically selected) above. e. Click the Add button to see the exception added to the List of Exceptions table on the page.

Suspicious Keyword Tracking

IMPORTANT Enabling the SSL Inspection feature is necessary to use the Suspicious Keyword Tracking option. See Using SSL Inspection With the Barracuda Web Security Gateway and related articles to understand this feature and what is required to use it safely. Using SSL inspection involves creating and/or installing SSL certificates in the Barrracuda Web Security Gateway and, for self-signed certificates, in all client browsers.

Due to recent vulnerabilities discovered with the SSL protocol, Barracuda strongly recommends that you upgrade to 8.1.0.005 before using SSL Inspection. For more information, see the Barracuda Networks Security Updates blog post around this topic: Barracuda Delivers Updated SSL Inspection Feature.

Suspicious Keyword Tracking is available with the Barracuda Web Security Gateway 610 and higher running version 7.0 and higher.

The Barracuda Web Security Gateway can identify, track and report on suspicious keywords in filtered social media traffic for notification and reporting purposes. For identifying cyberbullying, profanity, terrorism, adult content and other suspicious social media communications, Barracuda Networks employs a suspicious keywords lexicon to which you can add custom keywords you want the Barracuda Web Security Gateway to scan for and flag in captured social media traffic.

You can configure alerts, as described below, to be sent when these keywords are detected in captured traffic. Social media activity monitored/captured with this feature is available:

On the Web App Monitor Log page In reports In alert emails, configured on the BLOCK/ACCEPT > Web App Monitor page (see Figure 1 for an example alert email) In SMTP messages emailed to an email address or archiving solution, configured on the BLOCK/ACCEPT > Web App Monitor page

How to Configure Suspicious Keyword Tracking

1. From the BLOCK/ACCEPT > Web App Monitor page , enable web application monitoring for specific actions you select in Facebook, Twitter, Google and other popular social media portals. Granularity of actions includes chat, login, wall post, user registration, sending email and more. 2. Optionally specify a Web Activity Archiving Email Address on the page, and the Barracuda Web Security Gateway will package each interaction as an SMTP message and email it to that address. Archived messages can then be indexed and searched by source or content, and alerts can be generated per policy you set in your archiving solution. For information about searching archived messages and using policy alerts with the Barracuda Message Archiver, see Understanding Basic and Advanced Search and Policy Alerts. 3. Enable tracking and flagging of suspicious keywords by selecting the keyword categories you want to scan for in the web applications and actions enabled on the page. Click Save after making your selections to update the configuration. A report summarizing content policy violations based on the selected Suspicious Keyword Categories will be emailed to the Suspicious Keywords Alert Email Address you define in this section.

Figure 1: Example alert message to the administrator

4. Optionally create your own custom keyword categories and associated words to scan for in searches and social media activities. For each custom keyword category, enter your own words, each on a new line, that you wish to include in the keyword group. Click Add. The new keyword category is added to the table.

5. Enable SSL Inspection on the ADVANCED > SSL Inspection page and create or upload an SSL certificate. Follow instructions in How to Configure SSL Inspection Version 8.1 to 9.1 to choose the best way to set up your SSL certificate.

Suspicious Keywords Shown on the Dashboard page

The BASIC > Dashboard page includes a section showing Recent Flagged Terms from the suspicious keywords lexicon that were identified in captured social media interactions, as shown in Figure 2 below. Click the Show All Flagged Terms link to see the BLOCK/ACCEPT > Web App Monitor Log page, listing all recent flagged terms and details.

Figure 2: Recent Flagged Terms (suspicious keywords) in captured social media interactions

slang, pornography, terrorism, cyberbullying, cyber, bullying

Temporary Access for Education

This articles applies to the Barracuda Web Security Gateway running firmware version 7.0 and higher.

For additional information, refer to:

How to Use Temporary Access for Students - Teacher's Guide Exception Policies - for administrators Role-based Administration Version 7 and Above

The Temporary Access feature provides a portal where teachers can request and manage temporary access for students to specified domains or categories of domains that are typically blocked by school policy. In this way, students can access web content that may be useful for research projects or other classroom needs on a temporary basis.

If the teacher's requested domains are approved, the Barracuda Web Security Gateway issues a security token to the teacher to give to students to bypass block pages when browsing specific websites.The teacher can specify a time frame during which security tokens are valid, and can disable tokens at will. The administrator can revoke access for any security token, and can grant or revoke access to the Temporary Access portal to teachers. Certain domains or categories of domains can be prohibited by the administrator from ever being granted temporary access.

With version 7.0.1 and higher, the administrator can choose to provide teachers with the option of simply using their network (LDAP, for example) credentials to input to block pages for temporary bypass, rather than requiring the use of tokens.

Workflow for Administrators

Administrators have full visibility into teacher and student browsing activity via the BASIC > Temporary Access Requests log page in the Barracuda Web Security Gateway web interface. The teacher has a log of requests they've made and tokens assigned for accessing approved websites as shown in Figure 8.

1. Begin by enabling the Temporary Access portal for teachers from the ADVANCED > Temporary Access page in the Barracuda Web Security Gateway web interface. From this page you can also: a. Create a list of teachers, or specify LDAP Groups (as defined on the USERS > Users/Groups page) and configure whether the teachers log in with their LDAP credentials, or with credentials you create on the ADVANCED > Temporary Access page. b. Specify maximum time frame the teacher can use for student access tokens to remain valid. If you enable Allow Direct Override, then no token is needed and the maximum time frame determines how long a teacher's login is valid for temporary access to the previously blocked website. c. List domains and or categories that will always be prohibited from temporary access. d. Specify maximum number of domains or categories that can be requested by a teacher. e. Use the Limited To field to limit who can use the Temporary Access feature based on local or LDAP users, groups, LDAP organization units (OUs) or IP addresses. See the ADVANCED > Temporary Access page for details about the configuration. 2. Make sure that the email address contact you want attached to the ContactIT link on the Temporary Access portal (see Figure 1 below) is entered in the System Alerts Email Address in the Email Notifications section of the BASIC > Administration page. 3. Copy and paste the URL for the Temporary Access Portal from the ADVANCED > Temporary Access page into an email to the teacher. The URL is defined as https://YourWebFilterIPAddress/portal . Include in the email the credentials you created on the page for the teacher, or instruct them to use their LDAP credentials if you checked the Use LDAP Authentication checkbox. Also include a link to the article How to Use Temporary Access for Students - Teacher's Guide, which has step-by-step instructions for the teacher to request domains and get tokens to give their students. This article is also linked from within the help file that appears upon clicking the Help butto n on the Temporary Access Portal pages. If you enable Allow Direct Override, then instruct the teacher that no token is needed - they simply log in to bypass block pages. 4. Use the BASIC > Temporary Access Requests page to monitor activity of tokens by teacher username and date/time. You can also revoke tokens on that page.

Prohibited Categories and Domains

If you have specified, from the ADVANCED > Temporary Access page, any categories or domains that are prohibited from temporary student access, be sure to let the teacher know which ones are prohibited; otherwise, if the teacher requests those domains or categories, he/she will receive an error message in the Temporary Access Portal.

Workflow for the Teacher

The workflow documented here helps the administrator to understand how to use the ADVANCED > Temporary Access page to configure this feature, and answers some questions the teachers might have about getting and managing security tokens to give students to access specific websites. For a set of instructions to give to teachers, see How to Use Temporary Access for Students, which can also be printed out as a PDF.

1. The teacher receives an email from the system administrator containing: URL for the Temporary Access Portal Either credentials for logging into the portal, or instructions to use their LDAP credentials 2. The teacher sees this login page upon browsing the URL and logs in as instructed.

Figure 1: Temporary Access Portal Login page

3. Once the teacher logs in, the Temporary Access Portal home page appears. In this case, the Display Name entered on the ADVANCED > Temporary Access page for the teacher who is logged in is bjones.

Figure 2: Temporary Access Portal Welcome page

4. The teacher clicks Submit New Temporary Access Request to begin requesting domains for temporary student access from the Temporary Access Portal Home page.

Figure 3: Temporary Access Portal Home page

Barracuda Web Security Gateway Administrator's Guide - Page 131

Via the portal, the teacher can enter domains and/or select from a list of sub-categories (not categories ) as defined on the BLOCK/AC CEPT > Content Filter page, including any custom categories you have defined. In the example shown in Figure 4, the teacher has requested the Tripadvisor.com domain and is about to request Expedia.com. If the teacher had selected the Travel sub-category (where the category is Leisure) , those domains would have been included along with lots of other domains categorized as 'Travel'. But if the teacher only wants the students to be able to access these two travel domains, then only the explicit domains should be requested. Discussing the Lookup Category option with teachers and educating them about categorization of domains may better prepare them to use it safely.

Figure 4: In this example, the teacher has selected Tripadvisor.com and is about to select Expedia.com for temporary student access.

The teacher cannot actually select an entire category; only sub-categories, as shown below. However, to simplify instructions for teachers, the documentation will refer to selection of categories for an entire set of websites. After selecting the requested domains and/or sub-categories for temporary student access, the teacher selects the time frame for access and optionally enters a comment, such as the reason for access to these domains. All of this data is logged by date and username for the administrator to monitor on the B ASIC > Temporary Access Requests page. The domains, sub-categories and comments (if any) entered by the teacher will appear in the Details popup linked to that page.

Figure 5: The teacher has clicked Lookup Category for the domain Expedia.com. Travel is a sub-category of the Leisure category.

Barracuda Web Security Gateway Administrator's Guide - Page 132

5. After the teacher makes a request for access to one or more sub-categories and/or domains and clicks Submit Request, the Barracuda Web Security Gateway returns a token (as shown in Figure 6), and the teacher can click the Make Another Request link at the bottom of the page for more additions. The teacher gives the domain names and token to the students, who input the token to block pages when accessing those domains.

Alternatively, you can grant the teachers the ability to simply use their temporary access (or LDAP) credentials to bypass block pages, removing the need for tokens. Do this by checking the Allow Direct Override box in the Temporary Access Administrators section of the ADVANCED > Temporary Access page. This simplifies the process, and the same limited time frames for student access are applied after the teacher logs in.

Figure 6: Getting a token that is associated with access to all domains and/or sub-categories in a request.

When the student tries to access a typically blocked website, he or she can enter the token as shown below to bypass the block page and browse the site for the temporary time frame requested by the teacher. If Allow Direct Override is enabled, as mentioned above, the teacher can click the Temporary Access Using User Credentials link as shown in Figure 7, and then log in with their credentials instead of entering a token.

Figure 7: The student enters the token to bypass the block page for sites the teacher has requested

Barracuda Web Security Gateway Administrator's Guide - Page 133

Managing Temporary Access Requests and Tokens

When the teacher logs into the Temporary Access Portal, they can view a list of their temporary access requests on the home page. To view this list from another page, the teacher clicks Home in upper right of the portal. For each request, the status and expiration dates are displayed for the associated tokens.

From this page the teacher can disable a token before it expires, if necessary, by selecting the Disable check box, or can click the Copy l ink to make a co py of the original request to renew it. Clicking Details for a request displays associated domains, categories, and comments.

The administrator can view the same detail about tokens and revoke tokens from the BASIC > Temporary Access Requests page.

Figure 8: List of temporary access requests made by bjones in the last week

Barracuda Web Security Gateway Administrator's Guide - Page 134

How to Use Temporary Access for Students - Teacher's Guide

This article applies to the Barracuda Web Security Gateway running firmware version 7.0 and higher.

With the Temporary Access feature of the Barracuda Web Security Gateway, you can let your students temporarily access websites that are blocked by school policy. You can create a list of domains (websites) that you want students to access and specify how long this access should be granted. The maximum allowed time frame is determined by your system administrator.

To get temporary access for your students, use the Temporary Access Portal. In the portal, you can request temporary access to certain domains for a specific period of time. When you submit your list of domains (or category of domains), you will receive a temporary access token for your students, or your administrator will advise you to just log in with credentials they provide you (or your network login) to bypass block pages. When your students browse any of the domains in your list, they can use the token to bypass block pages or you can log in. The token, as well as your login, has an expiration time and date, after which the domains in your list be blocked again per school policy.

In the Temporary Access Portal, you can view the status and expiration dates of the tokens (or login) for your temporary access requests. You can also choose to disable tokens before they expire.

Choosing Domains and Categories of Domains

You can request temporary access for specific domains, as well as entire categories of domains. Domains, or websites, are commonly categorized into groups so that schools and other organizations can create safe browsing policies for their users. For example, travel websites would be in the Travel category. To let students access travel websites when planning a school trip, you can request that they be granted temporary access to this category. However, use caution when allowing an entire category. Verify with your system administrator that the category does not have objectionable content.

Prohibited Categories and Domains

If your system administrator has prohibited any categories or domains from temporary student access, you will receive an error message if you request access to them. Before submitting your list of domains for temporary access, it is recommended that you let your system administrator review your list for any prohibited categories or domains.

Steps to Request Temporary Access for Students

When you have a list of domains or categories of domains that you want students to temporarily access, log into the Temporary Access Portal to submit your request and get access for your students.

1. If you do not have a URL or a login and password for the Temporary Access Portal, request this information from your system administrator. If you did not receive a login and password, you might have been instructed to use your regular network (LDAP) login and password. The URL for the Temporary Access Portal will look something like this: https://10.1.1.1/portal 2. Go to the URL for the Temporary Access Portal, enter the credentials that you received from your administrator, and click Login.

Figure 1. Temporary Access Portal Login page.

3. On the Welcome page, click Submit New Temporary Access Request.

Figure 2. Temporary Access Portal Welcome page.

4. In the Website section of the New Access Request form, you can add domains and categories for domains. To add a domain, enter the domain name in the text field and click Add. To add a category for a domain, enter the domain name in the text field and then click Lookup Category to see what category the domain belongs to. When the category displays, select it and then click Add.

When allowing an entire category, verify with your system administrator that the category does not include domains that have objectionable content.

In the example shown in Figure 3, the teacher has requested the Tripadvisor.com domain and is about to request Expedia.com.

Figure 3. Requested site(s) for temporary access.

In the example shown in Figure 4, the category has been looked up for Expedia.com.

Figure 4. After clicking Lookup Category for the domain Expedia.com, the Travel category is displayed.

Barracuda Web Security Gateway Administrator's Guide - Page 137

If the teacher had selected the Travel category, both the Tripadvisor.com and Expedia.com domains would have been included along with lots of other domains categorized as Travel. But if the teacher only wants the students to be able to access these two travel domains, then only those domains must be added. 5. After you enter all of the domains and categories for temporary student access, specify how long this access should be granted and optionally enter a comment that describes why access to these domains is being granted.

Enter as much time as students will need from the moment you submit the request until you want the temporary access to expire. When you submit the request and receive a token, the time for the token immediately begins running down. If your administrator has advised you, you may just use your login credentials instead of tokens; however, the time frame limit still applies.

6. Click Submit Request. The Barracuda Web Security Gateway returns a token (as shown in Figure 5). Give the token and list of allowed domain names to your students, or use your login credentials if advised.

Figure 5. Getting a token that is associated with access to all domains and/or categories in a request.

7. To make another temporary access request, click Make Another Request at the bottom of the page. 8. To see a list of any other temporary access requests that you made over the past week, click Home in the upper right of the page.

How Students Gain Temporary Access to Regulated Websites

When your students try to access a blocked website for which you have requested temporary access, an Access Denied page displays.

If your administrator instructed you to use tokens, give your students the token to enter to bypass the block page as shown in Figure 6. If your administrator has instructed you to use your login credentials instead of tokens, click the Temporary Access Using User Credentials as shown in Figure 6. The popup will refresh and you can then log in.

Students can now browse the site for the time frame that you specified when you submitted your temporary access request.

Figure 6. The student enters the token to bypass the block page.

Managing Temporary Access Requests and Tokens

When you log into the Temporary Access Portal, you can view a list of your temporary access requests on the home page. To view this list from another page, you can return to the home page by clicking Home in upper right of the portal. For each request, you can view the status and expiration dates of the associated tokens.

From the list of temporary access requests, you can manage tokens or view more information about the request:

To disable a token before it expires, select the Disable check box. To extend the access time frame, click Copy to make a copy of the original request. To view more details for a request, click Details to view domains, categories, and comments.

Figure 7. List of temporary access requests made by bjones in the last week.

Captive Portal Terms and Conditions Page

The Captive Portal feature gives you control over user access to the Internet or other networks. When enabled, this feature presents a ‘terms and conditions’ page to which the user must agree before getting access to browse the web. The Captive Portal feature can be enabled and configured on the BLOCK/ACCEPT > Configuration page.

Common Use Cases

Hotel or Internet cafe guests – These users tend to be unauthenticated and will browse based as 'guests' based on policies you create for unauthenticated users. Employees who bring personal devices to work – BYOD users can use their LDAP credentials to log into the portal and continue to browse based on policies you apply to authenticated users. You can also configure so that these users can browse as guests (unauthenticated) when using these devices.

User Experience and Authentication

With Captive Portal enabled, the first request from every user will be served a splash page displaying customized terms and conditions, which you configure on the BLOCK/ACCEPT > Block Message page. Once the user agrees or, for LDAP users, logs in, the page is not presented again for the duration of the browsing session and the user can view content that is not blocked for that user based on Captive Portal settings and block/accept policies.These settings allow for applying this feature to certain IP groups and unauthenticated ('guest') users. You can apply different policies depending on whether the user identifies with LDAP credentials or as a guest. Exclusions for IP groups are also configurable.

All traffic is logged, and the session will time out automatically in 24 hours.

Creating Block and Accept Policies

To create exceptions to block and accept policies by user, group, or time frame, see Exception Policies.

Content filtering

Barracuda web security products employ a comprehensive database of frequently updated categories of website content types. Use the BLOCK/ ACCEPT > Content Filter page to control user access to categories of websites that should be blocked, warned, monitored, or allowed based on content. When you block a category, you block all HTTP and HTTPS traffic to the associated URLs in that category.

For example, http://mail.yahoo.com is categorized as a web-based email site. If you want to block users from accessing their web-based email accounts, block the Web-based Email category.

See Web Use Categories for a listing and definition of content classification.

Safe Search

Safe Search mode prevents a web search engine from displaying objectionable thumbnail images in search results; only filtered thumbnails are displayed in the search results. To limit Safe Search to specific users, create an exception using the BLOCK/ACCEPT > Exceptions page. For details, see How to Enable Safe Search. The entries in this category include search engines which allow users to enable or disable Safe Search mode for image searches. If you enable Safe Search through the Barracuda Web Security Gateway, users cannot use the search engine settings to override this mode. If you only want to enable Safe Search for certain users, select Disable for each search engine listed in the table, or click the All link. On the BLOCK/ACCEPT > Exceptions page, create an Enable exception for the user or group of users for whom you want to enable Safe Search.

Important: Safe Search will not work if the search request is encrypted unless the Barracuda Web Security Gateway is configured to inspect or 'scan' SSL traffic. Google Safe Search requires SSL inspection as searches are encrypted. Using Google Safe Search requires enabling the SSL Inspection feature, which is available for the Barracuda Web Security Gateway 310 and higher. See Using SSL Inspection With the Barracuda Web Security Gateway for details.

Make sure your Barracuda Web Security Gateway is running version 8.1.0.005 or higher before turning on SSL inspection.

Safe Browsing for Schools

For educational institutions wishing to restrict YouTube access, the procedure to configure the Barracuda Web Security Gateway is detailed in How to Restrict YouTube Content On Your Network. See also the Google article Manage your YouTube settings. See Temporary Access for Education for how to give teachers and students temporary access to websites, for classroom research, that are typically blocked.

Application Filtering

Non Web-Based Applications

Use the BLOCK/ACCEPT > Applications page to block or allow specific application traffic over the HTTP (and HTTPS) protocol that is not browser-based. For example: Skype, Pandora, Adobe Acrobat, FTP. This type of filtering does NOT scan for content. If you need to scan and filter content, you must enable SSL Inspection.

Note that the SSL Inspection feature is only available on the Barracuda Web Security Gateway 310 (limited) and higher, and requires more system resources and installation of SSL certificates to configure. The Barracuda Web Security Gateway 410 and higher is required to block/allow specific functions that run within web applications, such as Facebook games or Skype chat. Configure on the B LOCK/ACCEPT > Web App Control page.

For a user to download or use an application, the user’s application needs to communicate with an external server. When you select to block an application, the Barracuda Web Security Gateway searches for traffic that contains data associated with an application server and then blocks that traffic.

Virtual Machine Support for Application Filtering and Monitoring The Barracuda Web Security Gateway 610 Vx virtual machine and higher supports application filtering, social media monitoring, and suspicious keyword alerts.

Exceptions to policies can be created for a specific user or group based on bandwidth quotas, time of day and/or days of the week. For example, you might want to allow employees to access certain applications such as Skype, for example, ONLY during lunch hours. See Limiting Access by Time frames, Time Quotas and Bandwidth Quotas. You can use the applications filter as a pre-emptive measure to protect your network against malware.

Social Media and Other Web-Based Applications

From the BLOCK/ACCEPT > Web App Control page you can block or allow specific web-based application traffic. For example: Facebook, LinkedIn, MySpace, Twitter, and others. You can allow or block the entire application or only specific functions that run within these web applications. For example, you might allow Facebook, but want to block Facebook games and Facebook apps to protect against viruses and malware.

As another example, you may want to block the IRC application because this type of application can present a security risk to the network. An infected PC may communicate with the "hacker" through an IRC channel, and the hacker can send commands to the channel instructing bots to launch an attack. IRC could also be used by a disgruntled employee to launch attacks on other networks or to communicate sensitive information outside of the network.

You can also use the application blocking feature when you hear about a virus spreading over a specific IM service or tool. In this case, you can proactively protect your network from the infection by blocking that particular service until the threat has been resolved.

Web Application Monitoring

Use this feature to capture and archive chat, email, user registrations and other social media interactions. The archiving repository can be your Barracuda Message Archiver, your Microsoft Exchange Server journaling tool or, for example, a system administrator email address.

For example, you might want to allow users in the organization to use Facebook to view and make status updates and use chat, but you want to capture the content. You might also want to block games, shares and other Facebook apps to protect your network from viruses and malware.

To configure Web Application Monitoring, you'll want to first set up your block/accept policies for web-based applications. Here's the process for this example:

1. From the BLOCK/ACCEPT > Web App Control page, in the Application Navigator, check Facebook to allow some or all Facebook applications. 2. Select the Facebook actions to block and allow and save your changes. In this example, you'd leave chat and status update in the Allow ed Applications list, moving other applications you want to block, such as shares, games and other apps, to the Blocked Applications list. Save your changes. 3. From the BLOCK/ACCEPT > Web App. Monitor page, enable the application actions whose content you want to archive. In this example, you would enable Facebook Wall Posts, Chat Message and Private Message. Once you enable any actions on the page, the Barracuda Web Security Gateway will capture the content from each action, package it as an SMTP message and email it to the Notifica tion Email Address you specify.

Domain filtering

Use the BLOCK/ACCEPT > Domains page to blocklist (block), warn, monitor or whitelist (allow) traffic to specific domains and subdomains. Use domain whitelists to allow access to domains that belong to categories that are generally blocked. Note that domains that are whitelisted ARE subject to the MIME type blocking rules you create (see below).Use domain blocklists to restrict access to domains in addition to those specified in other filtering categories.

Tip To control access to a domain and all its associated URLs, make sure you enter the domain identifier. For example, www.example.co m will control access only to the specific URL but example.com will control access to all URLs under the domain.

URL pattern filtering

Use the BLOCK/ACCEPT > URL Patterns page to enter regular expressions or keywords that, if matched to a URL, will block (blocklist), warn, monitor, or allow (whitelist) that URL. For more information about using regular expressions, refer to Regular Expressions. Note that URLs that are whitelisted ARE subject to the MIME type blocking rules you create (see below).

Examples:

1. You want to block all websites that contain porn in the URL - enter porn as a blocked pattern. Sometimes spyware applications use different hostnames but the same domain name, so the URLs appear to be from different hosts. In this case you can enter the domain name as a pattern to block all URLs on that domain. 2. You want to allow access to example.com but want to block maps.example.com. In this case, specify example.com as an allowed patt ern and specify maps.example.com as a blocked URL.

Tip Run a test on your regular expressions with special characters before you encode them in a pattern filter.

Custom categories filtering

Use the BLOCK/ACCEPT > Custom Categories page to create a custom filter, which can consist of the domain names or built-in web content

You can apply a custom category to either authenticated or unauthenticated users. You can define a user- or group- specific exception rule to a custom category policy.

After you define a custom category, allow between five and ten minutes for the Barracuda Web Security Gateway to compile and then fully activate the new category. To verify that a newly created custom category is active, you can use the Content Filter Lookup facility in the BLOCK /ACCEPT >Content Filter page, as described in the online help for the BLOCK/ACCEPT > Custom Categories page.

MIME type blocking

Use the BLOCK/ACCEPT > MIME Blocking page to specify standard MIME types that you want to block. Note that websites that are whitelisted ARE subject to the MIME type blocking rules you create. Many organizations choose to block Internet radio and streaming media because they add load to the internal network, as well as executable files because they can install viruses and various other malware. Some examples of MIME Type blocking:

To block Internet radio, which uses MPEG (.mpg, mpega, or .abs) or Microsoft audio (.wav) files, enter audio/x-mpeg or audio/x-wav as blocked MIME types. To block streaming media, which uses MPEG video, enter video/mpeg or video/x-msvideo as blocked MIME types. To block access to executables (.exe), enter application/octet-stream as a blocked MIME type.

For more examples of MIME types, click Help on the BLOCK/ACCEPT > MIME Blocking page.

IP-based exemption

If you want to exempt certain clients or sub-networks from all filtering (including spyware filtering), you can use the BLOCK/ACCEPT > IP Block/Exempt page and specify the source IP address for those clients under IP and Port Exemptions. For example, if you want to exempt an executive’s client machine from all filtering, you can do so using the IP address of the client. Similarly, if you want to exempt certain external devices (such as trusted servers outside the protected network), from all filtering, you can specify the destination IP address and specific port under IP and Port Exemptions.

Exempted IP addresses will bypass the following block filters:

Content filtering IM blocking All types of download blocking

Exempted IP Addresses will bypass ALL filters including spyware and virus filters.

IP-based blocking

To block ALL IP-based URLs, set Block IP Based URLs to Yes on the BLOCK/ACCEPT > URL Patterns page. The default and recommended value for this setting is No.

If you want to block certain clients or sub-networks from all access, you can use the BLOCK/ACCEPT > IP Block/Exempt page and specify the source IP address for those clients under IP and Port Exemptions. For example, if you want to block traffic from a suspicious client machine or email servers or internal web servers, you can do so using the IP address of the client. Similarly, if you want to block certain external devices, you can specify the destination IP address and specific port under IP and Port Exemptions. Note that when the Barracuda Web Security Gateway is deployed as a forward proxy, IP block/accept rules based on request destination are not applied.

How to Disable Auto-Complete for Popular Search Engines

Blocking these URL patterns disables auto-complete for each search engine. Add these patterns manually on the BLOCK/ACCEPT > URL Patterns page if you want to disable auto-complete:

Search Engine URL Pattern to Block

Google www.google.com/complete/

Yahoo search.yahoo.com/sugg/

Bing www.bing.com/AS/Suggestions?

For example, the following two URL pattern entries on the BLOCK/ACCEPT > URL Patterns page disable auto-complete for Google and Yahoo.

Encrypted Traffic Filtering With the Barracuda Web Security Gateway

Most common web applications such as Twitter and Facebook, and search engines like Google now only serve encrypted web traffic (over HTTPS instead of HTTP). Since block pages cannot always be served when just using HTTPS filtering, using SSL Inspection almost guarantees presentation of a block page when needed. The Barracuda Web Security Gateway provides the administrator with choices for monitoring and blocking HTTPS traffic, depending on the Barracuda Web Security Gateway model, and on use cases such as:

Monitoring/Blocking and/or capturing social media chat, posts, comments and other interactions (use SSL Inspection, Barracuda 610 and higher). Protecting users of Chromebooks by monitoring and blocking specific HTTPS traffic based on decrypted content filtering (use SSL Inspection, Barracuda 610 and higher). Providing Safe Search and YouTube for Schools content (use SSL Inspection, Barracuda 410 and higher). Simply blocking HTTPS traffic from specific domains or content categories without decrypting web URL content (use HTTPS Filtering, Barracuda 210 and higher).

See https://www.nsslabs.com/news/press-releases/nss-labs-research-finds-ssl-traffic-causes-significant-performance-problems-next for more about the growing need for SSL Inspection.

In This Section:

SSL Inspection – enabling the Barracuda Web Security Gateway to decrypt, inspect and re-encrypt web traffic at the URL level, administrators have fine grained control over the use of web-based applications. This means that administrators can choose to block certain portions of web based applications such as Facebook Chat, or Twitter. Also provides security for YouTube for Schools, which is served over HTTPS. HTTPS Filtering – Provides ability to block some or all HTTPS traffic by URL pattern (ex: *adult.com*), domain name or by content category. A less resource-intensive tool than SSL Inspection. Unlike SSL Inspection, this feature does not decrypt and inspect the URL content; rather it identifies domains and content categories for use in creating block/warn/allow policies.

Using SSL Inspection With the Barracuda Web Security Gateway

IMPORTANT Due to recent vulnerabilities discovered with the SSL protocol, Barracuda strongly recommends that you upgrade to 8.1.0.005 before using this feature. See the Barracuda Networks Security Updates blog post around this topic: Barracuda delivers updated SSL Inspection feature. Available with the Barracuda Web Security Gateway 310 (limited) and higher.

For configuration steps, see How to Configure SSL Inspection. This feature is supported for the Barracuda Web Security Gateway version 7.0 and higher. For information about SSL Inspection features supported for appliances and Vx models, see the documentation for the version you are running.

Why SSL Inspection Is Important

Social media sites like Facebook and YouTube are now typically accessed over HTTPS, the encryption protocol used to protect online banking sessions and user logins for services of all kinds on the web.

By enabling the Barracuda Web Security Gateway to decrypt, inspect and re-encrypt web traffic at the URL level, administrators have fine grained control over the use of web-based applications. This allows administrators to choose to block certain portions of web based applications such as Facebook Chat and Facebook Sharing, while enabling other portions, such as the rest of Facebook. Since Facebook, Twitter, various search engines such as Google, and many web-based applications run over HTTPS, SSL Inspection is required for this level of monitoring and blocking. With this control the administrator can define what they deem permissible on their network and need not block all of Facebook, Twitter, G Suite and other popular web-based applications.

Additionally, since block pages cannot always be served when just using HTTPS filtering, using SSL Inspection almost guarantees presentation of a block page when needed.

How SSL Inspection Works

With SSL Inspection, the content of a URL over HTTPS can be scanned. This allows the Barracuda Web Security Gateway to apply policies and detect malware and viruses at the URL level for traffic you designate for SSL Inspection.

The Barracuda Web Security Gateway acts as a secure intermediary between user HTTPS web requests and the destination web server (i.e. Facebook.com, YouTube.com, yourdomain.com, etc.). HTTPS content in user web requests is decrypted and scanned by the Barracuda Web Security Gateway, which then detects malware and enforces web policies configured on the BLOCK/ACCEPT pages. After processing, this HTTPS traffic will be re-encrypted on the fly by the Barracuda Web Security Gateway and routed to the destination web server as shown in Figure 1.

Figure 1: SSL Inspection

To use this feature, the administrator installs a root certificate in client browsers from the Barracuda Web Security Gateway. The Barracuda Web Security Gateway can then intercept and inspect the HTTPS connections by presenting the client a CA derived from this root CA. If you have a high availability deployment, you must install the same root certificate on each Barracuda Web Security Gateway.

SSL Inspection Versus HTTPS Filtering

If you only need to block by domain and/or domain (content) categories, you can enable HTTPS filtering on the 210 and higher. See HTTPS Filtering With the Barracuda Web Security Gateway for details. Unlike SSL Inspection, HTTPS filtering does not decrypt the encrypted portion of URLs. This prevents monitoring or capturing of social media interactions such as chat, comments, shares, etc. HTTPS Filtering is a good choice when:

You have a Barracuda Web Security Gateway 210, which currently does not support SSL Inspection. You have a Barracuda Web Security Gateway 310, which supports limited SSL Inspection (Safe Search). Your organization policies only require blocking web traffic over HTTPS by domain or domain categories.

Saving system resources for traffic processing other than SSL Inspection is important for your application. HTTPS filtering is a much less resource intensive option than SSL Inspection.

SSL Accelerator Hardware

SSL functions are offloaded to an SSL accelerator card if included in your Barracuda Web Security Gateway appliance model. Presence and enabling of this hardware results in improved overall system performance. See SSL Accelerator Hardware for details and to determine if your Barracuda Web Security Gateway appliance includes this hardware.

Popular Use Cases of SSL Inspection

Use case: Suspicious Keyword Tracking on Social Media

Monitor social messaging over HTTP/HTTPS in real time, with keyword alert emails to teachers or administrators to trigger immediate responses to emerging cases of bullying, harassment, or loss of confidential data. The Suspicious Keyword Tracking feature only requires the use of SSL Inspection if traffic is over HTTPS (which is typical for Facebook, G Suite, etc.) and is available on the Barracuda Web Security Gateway 410 and higher. Database of keywords is embedded in the Barracuda Web Security Gateway, is frequently updated, and can be customized. See the BLO CK/ACCEPT > Web App Monitor page to configure.

Use case: G Suite Control Over HTTPS

Perform granular regulation of G Suite tools over HTTPS; for example, allow business Gmail account access, but block personal Gmail account access. See G Suite Control Over HTTPS. For Chromebooks, see How to Get and Configure the Barracuda Chromebook Security Extension.

Use case: Facebook Control Over HTTPS

Regulate and archive Facebook application interactions (chat, posting, games, etc.). See Facebook Control Over HTTPS.

Use cases: Safe Search Over HTTPS

Users or groups you specify will not see search engine content that contains objectionable thumbnail images in the search results; only filtered thumbnails are displayed in the search results. See Creating Block and Accept Policies. Available with the Barracuda Web Security Gateway 310 and higher. See also How to Configure SSL Inspection.

Use case: Secure Uploads and Downloads Via Web-Based Email

Popular for schools. Allow access to web-based email applications, but prevent potentially dangerous uploads and downloads.

How to Configure SSL Inspection Version 12 and Above This article applies to the Barracuda Web Security Gateway 310 and higher running version 12.0 and above. For background information, see Using SSL Inspection With the Barracuda Web Security Gateway. If you are using Google Chrome browser, see H ow to Configure SSL Inspection for Google Chrome Browser to prevent certificate errors users might encounter.

IMPORTANT: If you want to use SSL Inspection with Google consumer apps, see G Suite Control Over HTTPS.

Use the Barracuda Web Security Gateway as a secure intermediary between HTTPS requests and destination web servers to apply granular control to applications and sub applications you want to block or allow. If you only need to block domains and content categories, then you can use the HTTPS Filtering feature instead. See HTTPS Filtering With the Barracuda Web Security Gateway.

Configure SSL Inspection for Barracuda Web Security Gateway 310

The Barracuda Web Security Gateway 310 Vx virtual machine does NOT support SSL Inspection.

1. Log in to the Barracuda Web Security Gateway web interface, and go to the BLOCK/ACCEPT > Configuration page. 2. Set Enable SSL Inspection to Yes. 3. Select whether to use the default Barracuda root certificate or create your own self-signed certificate. Barracuda recommends creating your own self-signed certificate. To create one, click Create Certificate and follow instructions.

4. Click the Download button next to Root Certificates For Browsers, and save the file to the Trusted Root Certificate path. If the certificate is installed to the personal path, it will not work correctly. The certificate must be installed on all remote devices that will be SSL inspected.

As an administrator you may have methods of pushing the certificate to managed remote devices. For unmanaged devices, you may want to enable users to install the certificate in their browsers themselves. In this case you will need to provide them access to the certificate file. You can do so by emailing the certificate, or posting it on an internal network share, or posting it on a public or private web server.

5. Install the certificate file in all client browsers. If you want to enable users to install the certificate in their browsers, see the note above.

SSL Inspection will then apply to any Safe Search selections you make on the BLOCK/ACCEPT > Content Filters page.

Configure SSL Inspection for Barracuda Web Security Gateway 410 and higher

1. Log in to the Barracuda Web Security Gateway web interface, and go to the ADVANCED > SSL Inspection page. 2. Set Enable SSL Inspection to Yes. 3. Select whether to use the default Barracuda root certificate or create your own self-signed certificate; Barracuda recommends creating your own self-signed certificate. To create one, click Create Root Certificate under Available Certificates and follow instructions in the wizard. If you are deploying multiple Barracuda Web Security Gateways, you can upload a root certificate from one Barracuda Web Security Gateway to the others in the cluster. Use Upload Certificate to install the certificate.

Barracuda Web Security Gateway Administrator's Guide - Page 149

4. Click the Download button in the table under Client Certificate for the certificate you want to install on clients and save the file to your trusted root certificate path. If the certificate is installed to the personal path, it will not work correctly. The certificate must be installed on all remote devices that will be SSL inspected. 5. Install the certificate file in all client browsers. If you want to enable users to install the certificate in their browsers, set Enable Browser Certificate Download to Yes. To require users to authenticate before downloading the certificate, set Enable Browser Certificate Download to Yes. 6. In most use cases, no further configuration is necessary for the Barracuda Web Security Gateway to SSL inspect sites and applications you specify on the BLOCK/ACCEPT > Web App Control page and the BLOCK/ACCEPT > Web App Monitor page. However, you can also choose to enter specific domains to exempt from SSL Inspection, and/or specific users, domains, networks or content filter categories to SSL inspect.

When to select specific domains or categories to SSL inspect You only need to specify specific domains or categories in the Domains or Content Filter Categories sections of the ADVAN CED > SSL Inspection page if

you need to SSL inspect web traffic for a domain that is not associated with any applications on the BLOCK/ACCEPT > Web App Control page.

7. Optional: configure specific application of or exemption from SSL Inspection. Click Help on the ADVANCED > SSL Inspection page for more configuration details. Inspected Domains – Enter domain names that you want inspected and filtered at the URL level. You only need to specify domains to inspect if you want to show entire URLs in reports on web requests. Content Filter Categories – Using the check boxes in the Categories List, you can add or remove content filter categories to/from the list of categories that you want to be inspected. Inspected Users/Groups – If you want to add specific domains to inspect, you must first choose one or more users or groups (e.g. All Users, Authenticated Users, etc.) for which you want to apply SSL Inspection. Note that If you choose Unauthenticat ed Users, SSL Inspection will not be applied to Barracuda WSA clients, as they are always authenticated with the Barracuda Web Security Gateway. Additionally, if you select an LDAP group, any Barracuda WSA users not in that group will not be subject to SSL Inspection. Inspected Networks – Enter the IP address and Netmask in the table for any network(s) for which you want to ssl inspect traffic. Exempt Domains – Optionally add any domains you want to bypass SSL Inspection. For example, if you have enabled any of the Safe Search categories in the Safe Browsing section of the BLOCK/ACCEPT > Content Filter page, you might want to exempt one or more domains from Safe Search.

SSL Inspection Modes by Model

Table 1.

MODEL 310 410 410 Vx 610 610 Vx 810 910 1010 / 1011 COMPARIS ON

Remote - X X X X X X X Filtering Tab (WSA)

Safe Search X(1) X X X X X X X

Web - X X X X X X X Application Control

Web - X X X X X X X Application Monitoring

(1) Available with version 10.0 and above

The Barracuda Web Security Gateway 310 Vx does NOT support SSL Inspection, and the 610 Vx supports only Proxy Mode inspection, including adding domains and categories.

Using SSL Inspection With the Barracuda Web Security Agent

If you have remote users with Macs or Windows laptops outside the network running the Barracuda Web Security Agent (WSA) with the Barracuda Web Security Gateway, you can configure the Barracuda Web Security Gateway to SSL Inspect HTTPS traffic. See SSL Inspection With the Barracuda Web Security Agent.

How to Configure SSL Inspection Version 10 and Above

IMPORTANT This article applies to the Barracuda Web Security Gateway running version 10.0 or above. SSL Inspection is a resource intensive feature and is configured differently by model as shown in this article. For background information, see Using SSL Inspection With the Barracuda Web Security Gateway. If you are using Google Chrome browser, see How to Configure SSL Inspection for Google Chrome Browser to prevent certificate errors users might encounter. The Barracuda Web Security Gateway 310 Vx does NOT support SSL Inspection, and the 610 Vx supports only Proxy Mode inspection, including adding domains and categories.

IMPORTANT: If you want to use SSL Inspection with Google consumer apps, see:

G Suite Control Over HTTPS For Chromebook users, see How to Get and Configure the Barracuda Chromebook Security Extension

Configure SSL Inspection for Barracuda Web Security Gateway 310

The Barracuda Web Security Gateway 310 Vx virtual machine does NOT support SSL Inspection.

1. Log in to the Barracuda Web Security Gateway web interface and go to the BLOCK/ACCEPT > Configuration page. 2. Set Enable SSL Inspection to Yes. 3. Select whether to use the default Barracuda root certificate or create your own self-signed certificate. Barracuda recommends creating your own self-signed certificate. To create one, click Create Certificate and follow instructions.

5. Install the certificate file in all client browsers. If you want to enable users to install the certificate in their browsers, see the note above.

SSL Inspection will then apply to YouTube for Schools access and to any Safe Search selections you make on the BLOCK/ACCEPT > Content Filters page.

Configure SSL Inspection for Barracuda Web Security Gateway 410 and higher

1. Log in to the Barracuda Web Security Gateway web interface, and go to the ADVANCED > SSL Inspection page. 2. Select the SSL Inspection Method.

Transparent – Use with inline deployments. This inspection method is more resource intensive than the Proxy inspection method. If you have a Barracuda Web Security Gateway Vx virtual appliance, you must select Proxy since the Vx does not support inline deployment .

CAUTION: This is a resource intensive feature, and Transparent inspection can, under certain configurations, result in a large impact on performance.

Barracuda Web Security Gateway 410 and 610 deployed inline: Note that you cannot select specific domains or categories for SSL Inspection in Transparent mode (see step 3 for details). However, SSL Inspection will automatically be applied to Safe Search, Google searches and applications and features you configure on the BLOCK/ACCEPT > Web App Monitor and Web App Control pages. Barracuda Web Security Gateway 910 and higher: Note that you cannot select specific content filter categories to inspect with this method. Proxy – Use with Forward Proxy deployments. This mode is less resource intensive than the Transparent inspection method. Configure all client web browsers with the IP address of the Barracuda Web Security Gateway as their forward proxy server. Select this method if you have a Barracuda Web Security Gateway Vx virtual appliance . With the Barracuda Web Security Gateway 410 and 610, you can select specific domains and categories for SSL Inspection (see step 3 for details). If you are using the Chrome browser, also see How to Configure SSL Inspection for Google Chrome Browser. Off – Disable SSL Inspection of HTTPS traffic. This means that the Barracuda Web Security Gateway will not decrypt HTTPS traffic at the URL level. You will be able to block/allow HTTPS domains, but you will not be able to archive actions users take on social media sites such as Facebook chat content, logins on Twitter or Yahoo!, etc. as defined on the BLOCK/ACCEPT > Web App Monitor page. 3. Optionally enter specific domains or content filter categories to SSL inspect. In most use cases, no further configuration is necessary for the Barracuda Web Security Gateway to SSL inspect sites and applications you specify on the BLOCK/ACCEPT > Web App Control pa ge and the BLOCK/ACCEPT > Web App Monitor page.

you need to SSL inspect web traffic for a domain that is not associated with any applications on the BLOCK/ACCEPT > Web App Control page.

Because enabling SSL Inspection increases the load on system resources, you should only specify inspection domains and/or content filter categories that meet the needs of your organization. With the Barracuda Web Security Gateway 410 and 610 using Transparent Mode, you cannot select domains and categories to inspect.

If you do need to specify domains or categories on the ADVANCED > SSL Inspection page: Inspected Domains – Enter up to 5 domain names that you want inspected and filtered at the URL level. You will see the entire HTTPS URL in reports for these domains. Content Filter Categories – Using the Add and Remove buttons, from the Categories List, you can add or remove content filter categories to/from the list of categories that you want to be inspected. You must use the Proxy inspection method to inspect categories. 4. Required: Create a self-signed SSL certificate and install it in client browsers. Click Create Certificate and follow instructions. 5. Click the Download button next to Root Certificates For Browsers, and save the file to the Trusted Root Certificate path. If the certificate is installed to the personal path, it will not work correctly. The certificate must be installed on all remote devices that will be SSL inspected. For details, see How to Create and Install a Self-Signed Certificate for SSL Inspection.

SSL Inspection Modes by Model With Version 10 and Above

Table 1.

Model 310 410 410 Vx 610 610 Vx 810 910 1010 / 1011 Compariso n

Proxy Mode X X X X X X X

Add up to 5 X - X X X(3) X X domains

Add X - X X X X X categories

Transparen X(1) X(1) X(1) X(1) X(2) X (2) X(2) t Mode

Add up to 5 - - - - X X X domains

Add ------categories

Remote X X X X X X X Filtering Tab (WSA)

Safe Search X(3) X X X X X X X

Web X(3) - X X X X X Application Control

Web X(3) - X X X X X Application Monitoring

Notes:

(1) In Transparent mode, you cannot configure domains or categories. If you currently use Proxy inspection and are switching to Transparen t inspection, any domains or categories you have specified for SSL Inspection are DISABLED. If you switch back to Proxy inspection, domains and categories are restored.

(2) In Transparent mode, you can configure domains, not categories. Test SSL Inspection with a few domains to ensure system performance is satisfactory. If you currently use Proxy inspection and are switching to Transparent inspection, any categories you have specified for SSL Inspection are DISABLED. If you switch back to Proxy inspection, categories are restored. To prevent system overload, after switching to Tra nsparent inspection, you cannot add more domains.

(3) Available with version 10.0

The Barracuda Web Security Gateway 310 Vx does NOT support SSL Inspection, and the 610 Vx supports only Proxy Mode inspection, including adding domains and categories.

Using SSL Inspection With the Barracuda Web Security Agent

SSL Accelerator Hardware SSL accelerator hardware for Barracuda Web Security Gateway appliances on some models. With this hardware enabled, SSL functions are offloaded to an SSL accelerator card, resulting in improved overall system performance. This hardware is available in Barracuda Web Security Gateway appliance models 610, 810, 910, 1010 and 1011 shipping as of October, 2016. In most cases there is no visual representation of the hardware because it is an internal component. After installing firmware 11.x on your Barracuda Web Security Gateway, if the hardware is included, you will see an indication on the BASIC > Dashboard page that the SSL accelerator hardware is present and activated as shown below.

If you have not upgraded to firmware 11.x and want more information, to determine if your Barracuda Web Security Gateway appliance is equipped with SSL decryption hardware, or to discuss upgrade options, contact your Barracuda sales representative or reseller.

How to Configure SSL Inspection Version 8.1 to 9.1

IMPORTANT SSL Inspection is a resource intensive feature and is configured differently by model as shown in this article. It is extremely important that you run firmware version 8.1.0.005 or above on your Barracuda Web Security Gateway in order to use SSL Inspection safely, if you decide to turn on the feature. For background information, see Using SSL Inspection With the Barracuda Web Security Gateway. If you are using Google Chrome browser, see How to Configure SSL Inspection for Google Chrome Browser to prevent certificate errors users might encounter.

IMPORTANT: If you want to use SSL Inspection with Google consumer apps, see G Suite Control Over HTTPS.

Configure SSL Inspection for Barracuda Web Security Gateway 410

5. Install the certificate file in all client browsers. If you want to enable users to install the certificate in their browsers, see the note above.

SSL Inspection will then apply to YouTube for Schools access and to any Safe Search selections you make on the BLOCK/ACCEPT > Content Filters page.

Configure SSL Inspection for Barracuda Web Security Gateway 610 and higher

1. Log in to the Barracuda Web Security Gateway web interface, and go to the ADVANCED > SSL Inspection page. 2. Select the SSL Inspection Method. Transparent – Use with inline deployments. This inspection method is more resource intensive than the Proxy inspection method. If you have a Barracuda Web Security Gateway Vx virtual appliance, you must select Proxy since the Vx does not support inline deployment .

CAUTION: This is a resource intensive feature, and Transparent inspection can, under certain configurations, result in a large impact on performance.

Barracuda Web Security Gateway Administrator's Guide - Page 156

Barracuda Web Security Gateway 610 and 810 deployed inline: Note that you cannot select specific domains or categories for SSL Inspection in Transparent mode (see step 3 for details). However, SSL Inspection will automatically be applied to Safe Search, Google searches and applications and features you configure on the BLOCK/ACCEPT > Web App Monitor and Web App Control pages. Barracuda Web Security Gateway 910 and higher: Note that you cannot select specific content filter categories to inspect with this method. Proxy – Use with Forward Proxy deployments. This mode is less resource intensive than the Transparent inspection method. Configure all client web browsers with the IP address of the Barracuda Web Security Gateway as their forward proxy server. Select this method if you have a Barracuda Web Security Gateway Vx virtual appliance . With the Barracuda Web Security Gateway 610 and 810, you can select specific domains and categories for SSL Inspection (see step 3 for details). If you are using the Chrome browser, also see How to Configure SSL Inspection for Google Chrome Browser. Off – Disable SSL Inspection of HTTPS traffic. This means that the Barracuda Web Security Gateway will not decrypt HTTPS traffic at the URL level. You will be able to block/allow HTTPS domains, but you will not be able to archive actions users take on social media sites such as Facebook chat content, logins on Twitter or Yahoo!, etc. as defined on the BLOCK/ACCEPT > Web App Monitor page. 3. Optionally enter specific domains or content filter categories to SSL inspect. In most use cases, no further configuration is necessary for the Barracuda Web Security Gateway to SSL inspect sites and applications you specify on the BLOCK/ACCEPT > Web App Control pa ge and the BLOCK/ACCEPT > Web App Monitor page.

you need to SSL inspect web traffic for a domain that is not associated with any applications on the BLOCK/ACCEPT > Web App Control page.

Because enabling SSL Inspection increases the load on system resources, you should only specify inspection domains and/or content filter categories that meet the needs of your organization. With the Barracuda Web Security Gateway 610 and 810 using Transparent Mode, you cannot select domains and categories to inspect.

SSL Inspection Modes by Model

Table 1.

MODEL 410 410 Vx 610 610 Vx 810 910 1010 / 1011 COMPARISO N

Proxy Mode Auto Auto X X X X X

Add up to 5 - - X X X X X domains

Add - - X X X X X categories

Transparent Auto Auto X(1) X(1) X(1) X (2) X(2) Mode

Add up to 5 - - - - - X X domains

Add ------categories

Remote X X X X X X X Filtering Tab (WSA)

Safe Search X X X X X X X

Web - - X X X X X Application Control

Web - - X X X X X Application Monitoring

Notes:

Using SSL Inspection With the Barracuda Web Security Agent

How to Configure SSL Inspection Version 7.1

SSL Inspection is a resource intensive feature which is supported by the Barracuda Web Security Gateway as follows:

410 and above, running version 7.1 and above. After enabling SSL Inspection, all applications you select on the BLOCK/A CCEPT > Web App Control and Web App Monitor pages are automatically subject to SSL Inspection. 310 and above, running version 10.0 and above.

For background information about this feature, see Using SSL Inspection With the Barracuda Web Security Gateway. If you are using Google Chrome browser, after reading this article, see How to Configure SSL Inspection for Google Chrome Browser to prevent certificate errors users might encounter.

Work Flow to Enable and Configure SSL Inspection

If you have a Barracuda Web Security Gateway 410, simply enable SSL Inspection on the BLOCK/ACCEPT > Configuration page, then download the Barracuda root certificate from the page as shown in Figure 1. The certificate needs to be installed on all remote devices that will be inspected. As an administrator you may have methods of pushing the certificate to managed remote devices. For unmanaged devices, you may want to enable users to install the certificate in their browsers themselves. In this case you will need to provide them access to the certificate file. You can do so by emailing the certificate, or posting it on an internal network share, or posting it on a public or private web server. SSL Inspection will then be applied to any Safe Search selections you make on the BLOCK/ACCEPT > Content Filter page. To further restrict YouTube content, see How to Restrict YouTube Content On Your Network.

Figure 1: Download a secure certificate for browsers from the BLOCK/ACCEPT > Configuration page

If you have a Barracuda Web Security Gateway 610 or higher, follow these steps:

1. Go to the ADVANCED > SSL Inspection page and set SSL Inspection Method to one of the following: Transparent – This inspection method is more resource intensive than the Proxy inspection method. This method works with inline deployments, where the Proxy method does not. If you have a Barracuda Web Security Gateway Vx virtual appliance, you must select Proxy since the Vx does not support inline deployment.

CAUTION: This is a resource intensive feature, and Transparent inspection can, under certain configurations, result in a large impact on performance.

Barracuda Web Security Gateway 610 and 810 deployed inline: Note that you cannot specify domains or categories for SSL Inspection in Transparent mode. However, SSL Inspection will automatically be applied to Safe Search, Google searches and applications and features you configure on the BLOCK/ACCEPT > Web App Monitor and Web App Control pages. Barracuda Web Security Gateway 910 and higher: Note that you cannot inspect content filter categories with this method - just domains that you specify. Proxy – This method works with Forward Proxy deployments only and is less resource intensive than the Transparent inspectio n method. Configure all client web browsers with the IP address of the Barracuda Web Security Gateway as their forward proxy

Barracuda Web Security Gateway Administrator's Guide - Page 159

server. Select this method if you have a Barracuda Web Security Gateway Vx virtual appliance. With the Barracuda Web Security Gateway 610 and 810, you can select domains and categories for SSL Inspection. If you are using the Chrome browser, also see How to Configure SSL Inspection for Google Chrome Browser. Off – Disable SSL Inspection of HTTPS traffic. This means that the Barracuda Web Security Gateway will not decrypt HTTPS traffic at the URL level. You will be able to block/allow HTTPS domains, but you will not be able to archive actions users take on social media sites such as Facebook chat content, logins on Twitter or Yahoo!, etc. as defined on the BLOCK/ACCEPT > Web App Monitor page. 2. Specify domains and content filter categories where you want to apply SSL inspection. Because enabling SSL Inspection increases the load on system resources, you should only specify domains and/or content filter categories to inspect that meet the needs of your organization. With the Barracuda Web Security Gateway 610 and 810 using Transparent inspection, you cannot select domains and categories to inspect as described above. Configure one or both of the following settings for applying SSL Inspection: Domains to Be Inspected – Enter up to 5 domain names that you want inspected and filtered at the URL level. Content Filter Categories – Using the Add and Remove buttons, from the Categories List, you can add or remove content filter categories to/from the list of categories that you want inspected. You must use the Proxy inspection method to inspect categories.

Any domains or URL categories not specified on this page will not be subject to SSL Inspection, except for those configured on the BLOCK/ACCEPT > Web App Monitor and Web App Control pages, Safe Browsing selections you make on the BLOCK/A CCEPT > Content Filter page. 3. Select and install an SSL certificate to use with client browsers. Barracuda recommends using the Barracuda Default Certificate for SSL Inspection which you can download from the Barracuda Web Security Gateway and install on client browsers. See How to Use the Barracuda Default Certificate for SSL Inspection. Alternatively, you can create and download your own self-signed certificate from the Barracuda Web Security Gateway and install it in client browsers. This method is simple and you can do everything from the ADVANCED > SSL Inspection page, except for installing the certificate in client browsers. See How to Create and Install a Self-Signed Certificate for SSL Inspection.

SSL Inspection With the Barracuda Web Security Agent (WSA)

The Barracuda WSA client does NOT perform SSL inspection; rather, the web traffic routed from the Barracuda WSA is inspected on the Barracuda Web Security Gateway.

If you have remote users outside the network running the Barracuda WSA on their laptops or Macs, you can configure SSL Inspection as follows:

1. Enable SSL Inspection on the Barracuda Web Security Gateway as described above, 2. Go to the ADVANCED > Remote Filtering page and set Policy Lookup Only Mode to No - this is required when using SSL Inspection, because in that mode, web traffic is not routed through the Barracuda Web Security Gateway. 3. On the WSA client, sync the settings. To do so manually from the WSA client, click on the agent in the toolbar tray and click Sync.

See Using the Barracuda WSA With the Barracuda Web Security Gateway Version 7.1 and Above for additional information.

How to Configure SSL Inspection 7.0

SSL Inspection is supported by the Barracuda Web Security Gateway version 7.0 as follows:

Barracuda Web Security Gateway 610 and 810 in Forward Proxy mode. Barracuda Web Security Gateway 910 and 1010 in Forward Proxy or Inline deployments.

The Barracuda Web Security Gateway 410 and above are supported in either inline or forward proxy mode running version 7.1.0 and above. See How to Configure SSL Inspection Version 7.1 if you are running this version. For version 8.x and above, see How to Configure SSL Inspection Version 8.1 to 9.1.

Work Flow to Enable and Configure SSL Inspection

1. On the ADVANCED > SSL Inspection page, set SSL Inspection Method to one of the following: Transparent – Available on the Barracuda Web Security Gateway 910 and 1010 as noted above. This inspection method is more resource intensive than the Proxy inspection method. This method works with inline deployments.

CAUTION: Because this is a resource intensive feature, Transparent inspection can, under certain configurations, result in a large impact on performance. Note that you cannot inspect content filter categories with this method - just domains that you specify.

Proxy – Available for the Barracuda Web Security Gateway 610 and above. This method works with Forward Proxy deployments only and is less resource intensive than the Transparent inspection method. Configure all client web browsers with the IP address of the Barracuda Web Security Gateway as their forward proxy server. If you are using the Chrome browser, also see How to Configure SSL Inspection for Google Chrome Browser. Off – Disable SSL Inspection of HTTPS traffic. This means that the Barracuda Web Security Gateway will not decrypt HTTPS traffic at the URL level. You will be able to block/allow HTTPS domains, but you will not be able to archive actions users take on social media sites such as Facebook chat content, logins on Twitter or Yahoo!, etc. as defined on the BLOCK/ACCEPT > Web App Monitor page. 2. Specify domains and content filter categories where you want to apply SSL inspection. Because enabling SSL Inspection increases the load on system resources, you should only specify the domains and/or content filter categories to inspect that meet the needs of your organization.

Configure one or both of the following settings for applying SSL Inspection: Domains to Be Inspected – Enter up to 5 domain names that you want to be inspected and filtered at the URL level. Content Filter Categories – Using the Add and Remove buttons, from the Categories List, you can add or remove content filter categories to/from the list of categories that you want to be inspected. You must use the Proxy inspection method if you want to inspect categories.

Any domains or URL categories that are not specified on the page will not be subject to SSL Inspection. 3. Select and install an SSL certificate to use with client browsers. Barracuda recommends using the Barracuda Default Certificate for SSL Inspection that you can download from the Barracuda Web Security Gateway and install on client browsers. See How to Use the Barracuda Default Certificate for SSL Inspection. You can alternatively create and download your own self-signed certificate from the Barracuda Web Security Gateway and install it in client browsers. This method is simple and you can do everything from the ADVANCED > SSL Inspection page, except for installing the certificate in client browsers. See How to Create and Install a Self-Signed Certificate for SSL Inspection.

How to Configure SSL Inspection for Google Chrome Browser Use the steps in this article to configure SSL certificates for Chrome browser on non-Chromebook devices.

IMPORTANT Due to recent vulnerabilities discovered with the SSL protocol, Barracuda strongly recommends that you upgrade to version 8.1.0.005 before using this feature. See the Barracuda Networks Security Updates blog post around this topic: Barracuda Delivers Updated SSL Inspection Feature.

Because the Google Chrome browser adheres to stringent security checks for client protection, the user may get certificate errors when SSL inspection is enabled on the Barracuda Web Security Gateway. These errors cause browser activity to stop without an opportunity to bypass or override the error, and the session is disconnected. Users may encounter these errors when visiting Google.com, Twitter.com or other sites over HTTPS.

To avoid these certificate errors, download a root CA (SSL certificate) from the Barracuda Web Security Gateway and install it on each Chrome client browser. To do so, follow these steps:

1. Log into the Barracuda Web Security Gateway as admin. 2. If you are running version 7.1 or higher and you have a Barracuda Web Security Gateway 310, enable SSL Inspection on the BLOCK/A CCEPT > Configuration page. Otherwise skip to step #3. Click Download to get the Root Certificate For Browsers. Save the file on your local system or network. Skip to step 7. 3. Go to the ADVANCED > SSL Inspection page and select your SSL Inspection Method at the top of the page. 4. Scroll down to the Certificate Creation section of the page and select Create Certificate. 5. In the Certificate Generation section below, fill in your organization information, following the instructions on the page, or in the Help file, and then click Create Certificate. 6. In the Available Certificates section below, click Download for the Root Certificate for Browsers. 7. In your Chrome browser, go to Settings. 8. Search on 'Certificates'. 9. Click Manage Certificates. 10. In the Certificates window, click Import... 11. Follow the instructions in the wizard to browse your local drive or network and upload the .der certificate file you downloaded from the Barracuda Web Security Gateway. 12. Click Next. 13. Select where you want to store the certificate, or allow Chrome to automatically select the certificate store. 14. Continue with the wizard to finish. 15. Close the Certificates window.

Successful installation is indicated by an Import Successful message.

How to Create and Install a Self-Signed Certificate for SSL Inspection

Note that the Firefox browser does not store certificates, nor does it use the default store in Windows the way Chrome and Internet Explorer do. Additionally, Firefox uses its own separate proxy configuration settings. Barracuda recommends enforcing a supported browser policy, in addition to enforcing browser control at the firewall using Barracuda NG firewalls.

Barracuda Web Security Gateway 310 running version 7.1 and higher - Download the Barracuda Default root certificate from the BLOCK/ACCEPT > Configuration page. See How to Configure SSL Inspection Version 7.1 for details. Barracuda Web Security Gateway 410 and higher - Either download the Barracuda Default root certificate or create and download your own self-signed certificate from the Barracuda Web Security Gateway and install it in client browsers, as described in this article. Barracuda recommends creating a self-signed certificate.

To install a self-signed certificate on the Barracuda Web Security Gateway 310, specifically for use with the SSL Inspection feature:

1. Go to the BLOCK/ACCEPT > Configuration page and, in the SSL Inspection section, click Generate Certificate and follow the instructions. 2. Install the certificate file in all client browsers. If you want to enable users to install the certificate in their browsers, you can email the certificate, post it on an internal network share or post it on a public or private web server.

SSL Inspection will then be applied when accessing YouTube for Schools and when using any Safe Search selections you make on the BLOCK/ACCEPT > Content Filters page.

To create and install a self-signed certificate on the Barracuda Web Security Gateway 410 and higher (running version 7.1 and higher), specifically for use with the SSL Inspection feature:

1. Go to the ADVANCED > SSL Inspection page and, in the Certificate Creation section, click Create Certificate. 2. In the Certificate Generation section of the page, fill in the Organization Info fields, and then click Create Certificate. Your certificate appears in the Available Certificates section of the page. 3. Now you have two options:

Either push or manually install the certificate on client browsers. Next to Root Certificate For Browsers, click Download to obtain the certificate file, and then install the certificate on each client browser. Enable users to download and install the certificate in their browsers. Do this by setting Enable Browser Certificate Download to Yes. Click the Save Changes at the top of the page. Next, send users an email message, paste in the URL displayed next to Enable Browser Certificate Download on the page, and include instructions to upload the certificate from this URL to their browsers. Or you can embed the URL in the block page by customizing the content on the BLOCK/ACCEPT > Block Messages page. Typically the client browser provides a wizard to guide the install of the certificate. If you choose this option, you can also require users to authenticate via LDAP before downloading the certificate.

Configure other SSL Inspection settings as needed on the ADVANCED > SSL Inspection page.

For High Availability Systems (Linked Management/Clustering)

If you have a high availability (Linked Management) deployment, you must install a certificate on each Barracuda Web Security Gateway in the cluster. You must also install a browser certificate in all client browsers. In this example, there are three Barracuda Web Security Gateways in the cluster: B1, B2, and B3.

1. Go to the ADVANCED > SSL Inspection page of the Barracuda Web Security Gateway B1 and follow the instructions above to create a self-signed certificate. 2. Next to Root Certificate For Web Security Gateway, click Download and store the file on your system. 3. Now you have two options: a. Either push or install the certificate on client browsers. Next to Root Certificate For Browsers, click Download to obtain the certificate file, and then install the certificate on each client browser. b. Enable users to download and install the certificate in their browsers. Do this by setting Enable Browser Certificate Download to Yes. Click Save Changes at the top of the page. Next, send users an email message, paste in the URL displayed next to Ena ble Browser Certificate Download on the page, and include instructions on how to upload the certificate from this URL to their browsers. Typically the browser provides a wizard to guide the install of the certificate. If you choose this option, you can also require users to authenticate via LDAP before downloading the certificate. 4. On Barracuda Web Security Gateways B2 and B3: a. In the Certificate Creation section of the page, select Upload Certificate for the Certificate Creation Method. b. In the Certificate Generation section, click Browse next to Certificate Authority. Find the root certificate file for the Barracuda Web Security Gateway that you downloaded from B1 in step 2. c. Click Upload Certificate to install the root certificate on the Barracuda Web Security Gateway B2 and B3.

Configure other SSL Inspection settings as needed on the ADVANCED > SSL Inspection page of each Barracuda Web Security Gateway in the cluster.

How to Use the Barracuda Default Certificate for SSL Inspection

When you enable SSL Inspection on the Barracuda Web Security Gateway, a default SSL certificate is provided which you can download from the Barracuda Web Security Gateway and install on client browsers. Note that, with the Barracuda Web Security Gateway 610 and higher, you can alternatively Create and Install a Self-Signed Certificate for SSL Inspection with your organization information from the ADVANCED > SSL Inspection page.

Follow these steps to use the Barracuda default certificate on the Barracuda Web Security Gateway specifically for use with the SSL Inspection feature.

See also:

How to Configure SSL Inspection Version 8.1 to 9.1 How to Configure SSL Inspection Version 7.1 How to Configure SSL Inspection 6.x Create and Install a Self-Signed Certificate for SSL Inspection Using SSL Inspection

Barracuda Web Security Gateway 410 and higher running version 7.1 and higher:

1. Download the Barracuda Default root certificate from the BLOCK/ACCEPT > Configuration page. 2. Either manually install the certificate on client browsers, or push to browsers using a Windows GPO. 3. Enable SSL Inspection on the BLOCK/ACCEPT > Configuration page.

Barracuda Web Security Gateway 610 and higher:

1. Go to the ADVANCED > SSL Inspection page. 2. You have two options for getting and distributing the default Root Certificate from the Barracuda Web Security Gateway to client browsers. In the Available Certificates section of the page, do one of the following: a. Push or manually install the certificate on client browsers. Next to Root Certificate For Browsers, click Download to obtain the certificate file, and then install the certificate on each client browser, either manually or with a GPO. b. Enable users to download and install the certificate in their browsers. i. Set Enable Browser Certificate Download to Yes. Click Save Changes at the top of the page. ii. Send users an email message, paste in the URL displayed next to Enable Browser Certificate Download on the page, and include instructions to upload the certificate from this URL to their browsers. Or you can embed the URL in the block page by customizing the content on the BLOCK/ACCEPT > Block Messages page.Typically the client browser provides a wizard to guide the install of the certificate. If you choose this option, you can also require users to authenticate via LDAP before downloading the certificate. 3. Configure other SSL Inspection settings as needed on the ADVANCED > SSL Inspection page.

With version 7.0.1 and higher, you cannot remove the Barracuda Root Certificate. You can, however, overwrite it with a self-signed certificate.

For High Availability System (Linked Management/Clustering)

Example: You might have three Barracuda Web Security Gateways in the cluster: B1, B2, and B3.

1. Go to the ADVANCED > SSL Inspection page of the Barracuda Web Security Gateway B1 and enable SSL Inspection. 2. Follow instructions above to download the Barracuda Web Security Gateway root certificate. 3. Next to Root Certificate For Web Security Gateway, click Download and store the file on your system. 4. Now you have two options: a. Either push or install the certificate on client browsers. Next to Root Certificate For Browsers, click Download to obtain the certificate file, and then install the certificate on each client browser. b. Enable users to download and install the certificate in their browsers. Do this by setting Enable Browser Certificate Download to Yes. Click the Save Changes at the top of the page. Next, send users an email message, paste in the URL displayed next to Enable Browser Certificate Download on the page, and include instructions on how to upload the certificate from this URL to

b. Barracuda Web Security Gateway Administrator's Guide - Page 164

their browsers.Typically the browser provides a wizard to guide the install of the certificate. If you choose this option, you can also require users to authenticate via LDAP before downloading the certificate. 5. On Barracuda Web Security Gateways B2 and B3: a. In the Certificate Creation section of the page, select Upload Certificate for the Certificate Creation Method. b. In the Certificate Generation section of the ADVANCED > SSL Inspection page, click Browse next to Certificate Authority. Find the root certificate file for the Barracuda Web Security Gateway that you downloaded from B1 in step 2. c. Click Upload Certificate to install the root certificate on the Barracuda Web Security Gateways B2 and B3.

Configure other SSL Inspection settings as needed on the ADVANCED > SSL Inspection page of Barracuda Web Security Gateway B1 - aside from the SSL certificates, SSL Inspection settings will propagate to the other systems in the cluster.

Client-side SSL inspection for Mac OS X Client-side SSL Inspection is supported by the Barracuda Web Security Gateway 410 and higher running version 11.0 and higher. Client-side SSL Inspection is currently available for the Barracuda WSA version 2.0 and higher for Mac, and does not support Web Application Monitoring. If you are using that feature, then do not enable client-side SSL Inspection; rather, configure SSL Inspection on the Barracuda Web Security Gateway, and all web traffic from any Barracuda WSA installations will be SSL inspected.

Enabling client-side SSL Inspection on the client computer offloads resource-intensive processing from the Barracuda Web Security Gateway. This configuration is highly scalable in terms of number of users, consuming fewer resources on the Barracuda Web Security Gateway and improving system performance.

Before configuring this option, Barracuda recommends reading and understanding these articles:

Using SSL Inspection With the Barracuda Web Security Gateway How to Configure SSL Inspection Version 10 and Above How to Configure SSL Inspection Version 12 and Above

About using client-side SSL Inspection:

SSL Inspection must be enabled: For version 11.x: By selecting either Transparent or Proxy mode on the ADVANCED > SSL Inspection page, depending on your Barracuda Web Security Gateway deployment. SSL Certificates must also be configured as instructed in that page. For version 12.x: By setting SSL Inspection to On on the ADVANCED > SSL Inspection page. SSL Certificates must also be configured as instructed in that page. Client-side SSL Inspection with the Barracuda WSA works with the same features as the Barracuda Web Security Gateway except for Web Application Monitoring (see the BLOCK/ACCEPT > Web App Monitor page), which is not currently supported with this feature. Client-side SSL inspection requires setting Policy Lookup Mode to Yes on the Barracuda Web Security Gateway. Using client-side SSL Inspection offloads a certain amount of processing from the Barracuda Web Security Gateway. Note that, with Policy Lookup Mode set to Yes, the Barracuda Web Security Gateway does not process the web traffic from remote clients, but provides policy lookups that are applied by the Barracuda WSA. This configuration results in higher performance and more available resources on the Barracuda Web Security Gateway. The Barracuda WSA creates a local private key to use with the SSL certificate you create or select on the Barracuda Web Security Gateway. The certificate is the same, but the key is unique to each remote client. See How to Configure SSL Inspection Version 10 and Above for information on creating and installing SSL certificates.

How to Configure Client-Side SSL Inspection

For the Barracuda Web Security Gateway version 11.x:

1. On the ADVANCED > SSL Inspection page, read and understand the information about SSL Inspection, required certificates and Trans parent and Proxy modes. 2. Configure the Barracuda Web Security Gateway as instructed in How to Configure SSL Inspection Version 10 and Above for your model (410 and above). 3. On the ADVANCED > Remote Filtering page, set Client Side SSL Inspection to Yes. 4. Install and enable the Barracuda WSA on remote Macs for which you want web traffic to be SSL inspected. If the Barracuda WSA is disabled, Client Side SSL Inspection is disabled automatically.

For the Barracuda Web Security Gateway version 12.x:

1. On the ADVANCED > SSL Inspection page, read and understand the information about SSL Inspection, required certificates and associated options. 2. Configure the Barracuda Web Security Gateway as instructed in How to Configure SSL Inspection Version 12 and Above for your model (410 and above). 3. On the ADVANCED > Remote Filtering page, set Client Side SSL Inspection to Yes. 4. Install and enable the Barracuda WSA on remote Macs for which you want web traffic to be SSL inspected. If the Barracuda WSA is disabled, Client Side SSL Inspection is disabled automatically.

Logging

All events are logged on the Web Log, in all configuration modes, just as with SSL inspection performed on the Barracuda Web Security Gateway.

Barracuda Web Security Gateway Update for SSL Inspection Certificate Handling Barracuda Networks has released a security update to the Barracuda Web Security Gateway with version 8.1.0.005. This update addresses recently discovered implementation weaknesses in features that use SSL Inspection. For more information on this topic, visit http://www.cert.org/blogs/certcc/post.cfm?EntryID=221.

This article applies to customers who currently enable, plan to enable, or have previously enabled SSL Inspection on a Barracuda Web Security Gateway.

Barracuda recommends installing version 8.1.0.005 on your Barracuda Web Security Gateway. After you upgrade, if you use a default certificate provided by the Barracuda Web Security Gateway, you should re-create and deploy new certificates to your clients. Installing the certificates will require a brief interruption of service. For information about working with SSL certificates, see How to Create and Install a Self-Signed Certificate for SSL Inspection and How to Use the Barracuda Default Certificate for SSL Inspection.

You can verify whether your Barracuda Web Security Gateway has an old certificate in its trust store, that needs replacement by a new certificate from version 8.1.0.005. Visit http://certcheck.barracudalabs.com and follow instructions to do the check.

Should you choose not to upgrade, it is recommended that you turn off the SSL Inspection feature as described below.

To disable SSL Inspection for the Barracuda Web Security Gateway 610 and above:

Navigate to the ADVANCED > SSL Inspection page. In the SSL Inspection section, set SSL Inspection Method to Off. Click Save on the top right of the screen. SSL Inspection is now off.

To disable SSL Inspection for the Barracuda Web Security Gateway 410:

Navigate to the BLOCK/ACCEPT > Configuration page. Set SSL Inspection to Off. Click Save on the top right of the screen. SSL Inspection is now off.

If you have any questions or concerns, please feel free to contact Barracuda Networks Technical Support at +1 408 342 5300.

CBE-2015-0961 CBE-2015-0962

SSL Inspection With the Barracuda Web Security Agent SSL Inspection for web traffic from the Barracuda Web Security Agent for Mac and Windows is supported with the Barracuda Web Security Gateway version 7.1 and above. If you are running version 11.0 or above of the Barracuda Web Security Gateway, you can enable client-side SSL Inspection on the Barracuda iWSA (version 2.0 or higher) for Mac. See Client-side SSL inspection for Mac OS X for details. The benefit of client-side SSL inspection is offloading the processing-intensive inspection to the client, resulting in improved system performance of the Barracuda Web Security Gateway.

This article applies to configuring SSL Inspection performed by the Barracuda Web Security Gateway on Barracuda WSA/iWSA traffic.

If you are not running version 11.0 or above of the Barracuda Web Security Gateway, you can apply the steps in this article to configure the Barracuda Web Security Gateway perform SSL inspection on Barracuda iWSA/WSA traffic.

To configure SSL inspection of Barracuda WSA/iWSA traffic on the Barracuda Web Security Gateway:

1. Enable SSL Inspection on the Barracuda Web Security Gateway as described in How to Configure SSL Inspection. 2. Go to the ADVANCED > Remote Filtering page and set Policy Lookup Only Mode to No - this is required when using SSL Inspection, because in that mode, web traffic is not routed through the Barracuda Web Security Gateway. 3. On the Barracuda WSA client, sync the settings. To do so manually from the Barracuda WSA, click on the agent in the toolbar tray and click Sync. Or simply shut down and restart the Barracuda WSA.

Facebook Control Over HTTPS The Barracuda Web Security Gateway can be configured for scanning of HTTPS traffic at the URL level when the SSL Inspection feature is enabled. This means that the administrator has granular control over what applications are blocked or allowed on websites like Facebook.com. The administrator can control Facebook traffic, for example, by specifying domain/sub-domain patterns associated with Facebook applications to be inspected over HTTPS. With SSL Inspection, the Barracuda Web Security Gateway can apply policies granularly to HTTPs traffic at the URL level as well as detect malware and viruses. For more information about this feature, see Using SSL Inspection With the Barracuda Web Security Gateway. This article provides several use cases as examples.

SSL Inspection of HTTPS traffic for this use case is available:

With either WCCP or Forward Proxy deployments on the Barracuda Web Security Gateway 610 and higher, running version 6.x and higher, or the Barracuda Web Security Gateway 410 running version 10 and higher. With either inline, WCCP, or Forward Proxy deployments on the Barracuda Web Security Gateway 910 and 1010 running version 7.0 and higher.

Use Case #1 – Blocking Facebook Apps

Suppose you want allow access to Facebook.com for students, but want to ONLY allow Facebook Applications (Apps) during school lunch time. Using the URL pattern for Facebook Apps (https://apps.facebook.com, https://www.facebook.com/appcenter/ ), you would first configure SSL Inspection, then create a policy on the BLOCK/ACCEPT > Exceptions page.

Step 1. Enable and configure SSL Inspection:

1. Log into the Barracuda Web Security Gateway web interface as an administrator. 2. On the ADVANCED > SSL Inspection page, set Enable SSL Inspection to Yes. 3. In the Inspected Domains field, enter Facebook.com and click Add. 4. Install an SSL certificate. There are two recommended options:

Select Create to generate your own signed SSL certificate and download it to install in or push out to each client browser. If you don't, users will see a warning each time they browse an HTTPS site when SSL Inspection is enabled. For detailed instructions on creating and installing the certificate, see How to Create and Install a Self-Signed Certificate for SSL Inspection. Use the Barracuda Default Certificate for SSL Inspection, available on the ADVANCED > SSL Inspection page. This is the simpler of the two methods. If you are only using one Barracuda Web Security Gateway (as opposed to clustering two or more systems using Linked Management), the private key is more secure as it never leaves the device. If you have a high availability deployment, you will need to install the same root certificate on each Barracuda Web Security Gateway. For detailed instructions on installing the certificate, see How to Use the Barracuda Default Certificate for SSL Inspection.

Step 2. Create the policy:

1. On the BLOCK/ACCEPT > Exceptions page, in the Add Exceptions section, select the Allow Action. See Figure 1 below. Select the type of users you want to allow (Authenticated, Local Group, etc.) in the Applies To field. In this case we've chosen Authenticated users. If your set of authenticated users includes teachers, you might want to create a group for students using the USERS/ GROUPS pages and then select the student group for Applies To. 2. Select URL Pattern as the Exception Type. 3. Enter https://apps.facebook.com, https://www.facebook.com/appcenter as the URL pattern (make sure to include a comma between URLs). 4. Set the Time Frame from 12:00 - 13:00 Mon. - Fri., or whatever constitutes 'lunch hour'.

Barracuda Web Security Gateway Administrator's Guide - Page 169

Figure 1: Creating a limited Allow policy for Facebook applications during school lunch hours

5. Select the Protocol as HTTPS. Enter a message if you like to describe what the policy is about. 6. Configure policy alerts as needed. With Enable Policy Alerts set to On, the Barracuda Web Security Gateway will send an email summarizing content policy violations to the email address(es) entered in the Policy Alerts Email Address field. 7. Click Add. You have now created your policy.

Use Case #2 – Blocking Facebook Chat for students

Suppose you want allow access to all Facebook activities except chat for students. Using the URL pattern for Facebook Messages ( https://w ww.facebook.com/messages ), you would first configure SSL Inspection, then create a policy on the BLOCK/ACCEPT > Exceptions page.

Step 1. Enable and configure SSL Inspection (if not already done):

Step 2. Create the policy:

1. On the BLOCK/ACCEPT > Exceptions page, in the Add Exceptions section, select the Block Action. See Figure 2 below. Select the type of users you want to allow (Authenticated, Local Group, etc.) in the Applies To field. In this example we've created a group called Students from the USERS/ GROUPS > Local Groups page, and here, we have selected that group for Applies To. 2. Select URL Pattern as the Exception Type. 3. Enter https://www.facebook.com/messages as the URL pattern. 4. There is no need to set a time frame unless you want to allow access to Facebook chat OUTSIDE the hours you're blocking.

Barracuda Web Security Gateway Administrator's Guide - Page 170

Figure 2: Creating a Block policy for Facebook chat

5. Select the Protocol as HTTPS. Enter a message if you like to describe what the policy is about. 6. Configure policy alerts as needed. In this example, the Message field explains that Policy Alerts were purposely not enabled. 7. Click Add. You have now created your policy.

Client-side SSL inspection for Windows Client-side SSL Inspection is supported by the Barracuda Web Security Gateway 410 and higher running version 12.0 and higher. Client-side SSL Inspection currently does not support Web Application Monitoring. If you are using that feature, then do not enable client-side SSL Inspection; rather, configure SSL Inspection on the Barracuda Web Security Gateway, and all web traffic from any Barracuda WSA installations will be SSL inspected.

Before configuring this option, Barracuda recommends reading and understanding these articles:

Using SSL Inspection With the Barracuda Web Security Gateway How to Configure SSL Inspection Version 12 and Above

About using client-side SSL Inspection:

SSL Inspection must be enabled on the ADVANCED > SSL Inspection page. SSL Certificates must also be configured as instructed in that page. Client-side SSL Inspection with the Barracuda WSA works with the same features as the Barracuda Web Security Gateway except for Web Application Monitoring (see the BLOCK/ACCEPT > Web App Monitor page), which is not currently supported with this feature. Client-side SSL inspection requires setting Policy Lookup Mode to Yes on the Barracuda Web Security Gateway. Using client-side SSL Inspection offloads a certain amount of processing from the Barracuda Web Security Gateway. Note that, with Policy Lookup Mode set to Yes, the Barracuda Web Security Gateway does not process the web traffic from remote clients, but provides policy lookups that are applied by the Barracuda WSA. This configuration results in higher performance and more available resources on the Barracuda Web Security Gateway. The Barracuda WSA creates a local private key to use with the SSL certificate you create or select on the Barracuda Web Security Gateway. The certificate is the same, but the key is unique to each remote client. See How to Configure SSL Inspection Version 12 and Above for information on creating and installing SSL certificates.

How to Configure Client-Side SSL Inspection

1. On the ADVANCED > SSL Inspection page, read and understand information about SSL Inspection configuration. 2. Configure the Barracuda Web Security Gateway as instructed in How to Configure SSL Inspection Version 12 and Above for your model (410 and above). 3. On the ADVANCED > Remote Filtering page, set Client-side SSL Inspection to Yes. 4. Install and enable the Barracuda WSA on remote Windows PCs and laptops for which you want web traffic to be SSL inspected. If the Barracuda WSA is disabled, client-side SSL Inspection is disabled automatically.

Logging

All events are logged on the Web Log, in all configuration modes, just as with SSL inspection performed on the Barracuda Web Security Gateway.

Google Restrictions With SSL Inspection

Important Note that you cannot rely solely on the HTTPS Filtering feature to block Google over HTTPS. This is because SSL inspection is required to properly identify some Google domains.

SSL Inspection and Google Consumer Apps

When the SSL Inspection feature is enabled on the Barracuda Web Security Gateway, the administrator has granular control over what applications are blocked or allowed on websites like Facebook, Twitter or Google. In these use cases, administrators can typically apply block/allow policies by specifying domain/sub-domain patterns associated with the website to be inspected over HTTPS. However, with Google consumer apps, there are currently some limitations due to the way in which Google deals with SSL certificates. These limitations, and the Barracuda solution for correct identification and filtering of Google domains and sub-domains over HTTPS, are addressed in this article.

For instructions and examples on how to block Google consumer apps over HTTPS, see G Suite Control Over HTTPS.

To filter Google consumer apps traffic for Chromebooks, see How to Get and Configure the Barracuda Chromebook Security Extension. The extension requires upgrading to the Barracuda Web Security Gateway version 11 or above.

Google Restrictions on Identifying Google sub-domains Over HTTPS

Google has been moving more of its services to encrypted (HTTPS) connections for additional security, and is tending towards moving all of their sites to use HTTPS by default. In some cases, when SSL inspecting web traffic to Google sites, the only information the Barracuda Web Security Gateway has to evaluate over the encrypted connection is the IP address and the certificate name, which in most cases, including Google, is a wildcard certificate (*.google.com) identifying the domain name but not the specific host. Additionally, many schools and other institutions still use older versions of Windows and various browsers.

These issues result in limited ability to completely identify certain Google sub-domains, and to apply differentiated policies such as, for example:

Allow an encrypted connection to Google drive but block the connection to mail.google.com Allow an encrypted connection to Google business accounts, but block the connection to Google consumer accounts

Limited Abilities for Some Mobile Devices With SSL Inspection

With the introduction of mobile devices and specialized apps such as the Google Play Store on Android or the Google Drive app for Windows, limitations in SSL inspecting this web traffic are also an issue due to varied support for SSL Inspection tools in these specialized apps. Some versions of the apps support SSL Inspection tools needed to specifically determine the identity of certain Google sites over HTTPS, and some do not. This means that some selective policies based on service can’t be applied to that web traffic

These issues are causing difficulties for schools in applying granular policy to student web browsing and to other organizations when applying policies. Google is working to make changes on their side to resolve them.

For schools that have not adopted G Suite for Education, and are not widely using Android-based mobile devices, these issues may not be a problem.

Safe Solutions

Use the Barracuda Chromebook Security Extension For Chromebook users, you can download the Barracuda Chromebook Security Extension and install it on each device to enforce security policies configured on the Barracuda Web Security Gateway: The extension provides control and visibility over both HTTP and HTTPS traffic, and does not send any user generated traffic through the Barracuda Web Security Gateway, but instead, synchronizes policy and report data between the Chromebook and the Barracuda Web Security Gateway. See How to Get and Configure the Barracuda Chromebook Security Extension. The extension requires upgrading to the Barracuda Web Security Gateway version 11 or above.

Deploy the Barracuda Web Security Gateway in Proxy Mode

This deployment allows for full access to the URL that the user is accessing and can fully identify the resource and make differentiated policy decisions. See Forward Proxy Deployment of the Barracuda Web Security Gateway.

Use the Google Consumer Apps Category Filter

Use the Google Consumer Apps content category in the Barracuda Web Security Gateway and create Exceptions to block or allow certain users or groups access to all or some Google Consumer Apps:

Applications list box. Click Save. 3. On the BLOCK/ACCEPT > Exceptions page, create block/allow exceptions by user(s) and/or group(s).

See G Suite Control Over HTTPS for examples.

G Suite Control Over HTTPS

Important SSL Inspection is a resource intensive feature which is supported by the Barracuda Web Security Gateway as described in Using SSL Inspection With the Barracuda Web Security Gateway. Because of the way Google handles SSL certificates, Barracuda provides a Category Filter on the BLOCK/ACCEPT > Web App Control page for Google Consumer Apps, which must be selected in order to identify and to SSL-inspect certain Google domains and sub-domains. This feature requires version 9.1 or higher of the Barracuda Web Security Gateway.

For information about limitations in blocking Google over HTTPS, see Google Restrictions With SSL Inspection.

For Chromebook users with the Barracuda Chromebook Security Extension installed, policies for G Suite web traffic are configured on the Google Admin Console, not on the Barracuda Web Security Gateway. Also note that the settings on the BLOCK/ACCEPT > Web App Control and BLOCK/ACCEPT > Web App Monitor pages do not apply to Chromebooks running the Barracuda Chromebook Security Extension.

When the SSL Inspection feature is enabled on the Barracuda Web Security Gateway, the administrator has granular control over what applications are blocked or allowed on websites like Google.com. This article explains how to apply block/allow policies by selecting some or all Google Consumer Apps to be inspected over HTTPS.

How to Block and Allow Google Consumer Apps

Step 1. Enable and Configure SSL Inspection

This is the first step required for SSL inspecting HTTPS traffic.

1. Log into the Barracuda Web Security Gateway web interface as an administrator. 2. On the ADVANCED > SSL Inspection page: a. For inline deployments on the 910 and above, set SSL Inspection Method to Transparent. b. For forward proxy deployments on the 610 and above, set SSL Inspection Method to Proxy. 3. In the Inspected Domains field, enter Google.com and click Add. 4. Install an SSL certificate. There are two recommended options:

Step 2. Block or Allow Google Consumer Apps

The Google Consumer Apps content category is used to block or allow traffic from Google domains and sub-domains. You can then create Exc eptions to these policies for certain users or groups for access to all or some Google Consumer Apps.

1. From the BLOCK/ACCEPT > Web App Control page, in the Allowed Applications box, select Google Consumer Apps under Categ ory Filter. 2. In the list box, you can either select Google Mail or Google Consumer Apps, and click the Block button to move it to the Blocked Applications list box. Click Save. 3. On the BLOCK/ACCEPT > Exceptions page, create block/allow exceptions by user(s) and/or group(s). See example use cases in this article.

How to Block/Allow Google Hangout

To block Google Hangouts, you must block both of the following:

https://plus.google.com/hangouts https://plus.google.com

Use Case #1 – Allow Google Consumer Apps, While Blocking Google Wallet Students

This scenario allows access to Google Gmail and most other Google Consumer Apps, which are accessed via HTTPS. Exception to this policy is blocking Google Wallet over HTTPS. Since no time frame is specified on the BLOCK/ACCEPT > Exceptions page in this example, these policies would be enforced by the Barracuda Web Security Gateway 24/7 if configured as shown here. Step 1. Configure SSL Inspection as described above.

Step 2. Create the Block policy for Google Wallet.

Figure 1: Blocking Google Wallet for the Students group

4. In the Web App Name box, select Google Wallet (all). 5. From the Protocol drop-down, select HTTPS. 6. Click Add.

Use Case #2 – Restricting Use of Google Mail During Business Hours

This example requires version 9.1 or higher of the Barracuda Web Security Gateway.

You may want to allow managers access to G Suite business mail, while blocking Gmail access to non-managers. Here are the basic steps.

Step 1. Configure SSL Inspection as described above.

Step 2. Create the Block policy for Gmail.

1. Create a group called Managers on the USERS > USERS/GROUPS page. Assign appropriate users to this group. 2. Go to the BLOCK/ACCEPT > Web App Control page and, in the Allowed Applications box, select Google Consumer Apps under C ategory Filter. 3. In the list box, you can either select Google Mail or Google Consumer Apps (to block ALL Google Consumer Apps), and click the Bloc k button to move it to the Blocked Applications list box. Click Save.

Step 3. Create the Allow policy for business Gmail for Managers.

1. Go to the BLOCK/ACCEPT > Exceptions page and select the Allow action. 2. Select the Local Group in the Applies To field. In the dropdown to the right, select Managers. 3. Select the Web App Control Exception Type. 4. Select Google Mail for the Web App Name. 5. In the Allowed Domains text box, enter, separating by commas, the Google sub domain(s) from which managers can access Google Mail. This will be the domain(s) with which they log into their business Google accounts. 6. Click the Add button to see the exception added to the List of Exceptions table below.

Use Case #3 – Blocking Personal Gmail, While Allowing Business Gmail Access to All Users

This example requires version 9.1.0 of the Barracuda Web Security Gateway.

Suppose you want to allow access for Authenticated Users to G Suite business mail 24/7, but block personal gmail during business hours.

Step 1. Configure SSL Inspection as described above under Enable and Configure SSL Inspection.

Step 2. Create the block policy for Gmail.

1. Go to the BLOCK/ACCEPT > Web App Control page and, in the Allowed Applications box, select Google Consumer Apps under C ategory Filter. 2. In the list box, select Google Mail, and click the Block button to move it to the Blocked Applications list box. Click Save.

Step 3. Create the Allow policy for business Gmail for Authenticated Users 24/7.

1. Go to the BLOCK/ACCEPT > Exceptions page and select the Allow action. 2. Select Authenticated in the Applies To field. 3. Select the Web App Control Exception Type. 4. Select Google Mail for the Web App Name. 5. In the Allowed Domains text box, enter, separating by commas, the Google sub-domain(s) from which users can access their business Google Mail accounts. This example uses mycompany.com and limits authenticated users to only access Gmail accounts with logins from that domain. 6. Click the Add button to see the exception added to the List of Exceptions table.

Step 4. Create the Allow policy for personal Gmail account access OUTSIDE of business hours.

1. Follow #1-4 in Step 3 above. 2. Select a Time Frame of Monday - Friday, 17:00 - 08:00 (or whatever constitutes hours outside of typical business hours). 3. Click the Add button to see the exception added to the List of Exceptions table.

YouTube Control Over HTTPS Version 7.x and Above The Barracuda Web Security Gateway can be configured for scanning of HTTPS traffic at the URL level when the SSL Inspection feature is enabled. This means that the administrator has granular control over what applications are blocked or allowed on websites like YouTube.com. The administrator can control YouTube traffic, for example, by specifying domain/sub-domain patterns associated with YouTube to be inspected over HTTPS. For more information about this feature, see Using SSL Inspection With the Barracuda Web Security Gateway. This article provides several use cases as examples.

To configure the Barracuda Web Security Gateway for YouTube for Schools, see How to Restrict YouTube Content On Your Network.

SSL Inspection is supported by the Barracuda Web Security Gateway as follows:

Barracuda Web Security Gateway 610 and higher, running firmware version 6.0.1 and higher (see How to Configure SSL Inspection 6.x) with ability to block or monitor many web-based applications and domains over HTTPS. Barracuda Web Security Gateway 410 running firmware version 10.0 and higher (see How to Configure SSL Inspection Version 10 and Above) with ability to block or monitor many web-based applications and domains over HTTPS. Barracuda Web Security Gateway 310 running firmware version and higher with inline or forward proxy deployments for Safe Browsing.

IMPORTANT: Barracuda strongly recommends that you upgrade to version 8.1.0.005 before using this feature.

Use Case #1: Blocking Channels

Suppose you want allow access to YouTube, but block access to YouTube channels for users in your organization during working hours Monday through Friday. Using the URL pattern for channels, https://youtube.com/channels, you will create a policy on the BLOCK/ACCEPT > Exceptions page.

Step 1. Enable and configure SSL Inspection:

1. Log into the Barracuda Web Security Gateway web interface as an administrator. 2. On the ADVANCED > SSL Inspection page, set Enable SSL Inspection to Yes. 3. In the Inspected Domains field, enter youtube.com and click Add. 4. Install an SSL certificate. There are two options:

a. Select Upload to upload a trusted certificate signed by a CA or from your organization's CA server. Once you install the trusted certificate on the Barracuda Web Security Gateway, your users can browse HTTPS sites without any warnings when SSL Inspection is enabled. If you have a high availability deployment, you will need to install the same root certificate on each Barracuda Web Security Gateway. Note: If you use this option, make sure to upload both the private and public key files. Formats supported include .pem, der, pkcs12, pkcs7, pfx, but not .jks (java key store). b. Select Create to generate your own SSL certificate and download it to install in or push out to each client browser. If you don't, users will see a warning each time they browse an HTTPS site when SSL Inspection is enabled. On the other hand, if you create the certificate on the Barracuda Web Security Gateway, the private key is more secure as it never leaves the device. If you have a high availability deployment, you will need to install the same root certificate on each Barracuda Web Security Gateway. Follow instructions in the online help to create and install the certificate(s).

Step 2. Create the policy:

1. On the BLOCK/ACCEPT > Exceptions page, in the Add Exceptions section, select the Block Action. See Figure 1. 2. Select the type of users you want to block (Authenticated, Local Group, etc.) in the Applies To field. In this case we've chosen Authentic ated users. 3. Select URL Pattern as the Exception Type. 4. Enter https://www.youtube.com/channels as the URL pattern. 5. Set the Time Frame from 8:00 - 17:00 Mon. - Fri. , or whatever constitutes 'working hours'.

Figure 1: Creating a Block policy for YouTube channels during working hours

Barracuda Web Security Gateway Administrator's Guide - Page 178

6. Select the Protocol as HTTPS. Enter a message if you like to describe what the policy is about. 7. Configure policy alerts as needed. With Enable Policy Alerts set to On, the Barracuda Web Security Gateway will send an email summarizing content policy violations to the email address(es) entered in the Policy Alerts Email Address field. 8. Click Add. You have now created your policy.

Use Case #2: Blocking All YouTube Channels Except a Particular Video

1. Follow instructions in Step 1. above to enable and configure SSL Inspection in the Barracuda Web Security Gateway web interface. 2. On the BLOCK/ACCEPT > Exceptions page, in the Add Exceptions section, select the Block Action. 3. Select the type of users you want to block (Authenticated, Local Group, etc.) in the Applies To field. In this case we've chosen Authentic ated users. 4. Select URL Pattern as the Exception Type. 5. Enter https://www.youtube.com as the URL pattern. 6. If desired, set a Time Frame for when you want to block YouTube. 7. Getting the correct URL pattern to use to create the Allow action takes several steps. Follow instructions in How to Allow a Specific Video on YouTube to find and allow the specific YouTube video URL.

HTTPS Filtering With the Barracuda Web Security Gateway

This feature is an effective alternative to SSL Inspection for the following cases:

For the Barracuda Web Security Gateway 210, 310 and 410 if you want to block some or all HTTPS traffic by domain or by content category. The Barracuda Web Security Gateway 210 and 310 do not support SSL Inspection, and limited SSL Inspection is available on the Barracuda Web Security Gateway 410, only for Safe Search and YouTube for Schools. For the Barracuda Web Security Gateway 410 and higher, as a less resource-intensive tool than SSL Inspection if you only need to block some or all HTTPS traffic by domain or by domain/content category.

You can create block, warn and monitor exceptions for HTTPS web traffic on the BLOCK/ACCEPT > Exceptions page with content category filters, and/or domain filters. Unlike SSL Inspection, this feature does not decrypt and inspect the URL content; rather it identifies domains and content categories for use in creating block/warn/allow policies. You can also use URL pattern filters with Exceptions applied to the HTTPS protocol, but only the unencrypted portion of the requested URL can be checked.

Example: Block authenticated users from all domains that contain a specific URL pattern, accessed over HTTPS.

This option is disabled on the Barracuda Web Security Gateway by default. To enable, go to the BLOCK/ACCEPT > Configuration page and set Enable HTTPS Filtering to Yes.

How to Allow a Specific Video on YouTube

If your organization's policy is to typically block access to YouTube with your Barracuda Web Security Gateway, it is possible to allow one specific video to be accessed. The address of every YouTube video contains a unique id string. The string begins with ?v= and ends with &featured. You will need the string contained in between, as shown below.

Examples:

Complete URL ID string

http://www.youtube.com/watch?v=hhyAnz0oYWw&feature= hhyAnz0oYWw related

http://www.youtube.com/watch?v=bV4D4kcKHKM&feature= bV4D4kcKHKM related

In addition, every YouTube video has a serial number for the actual streaming content. The video request is redirected separately from the initial YouTube request, and the URL contains c.youtube.com per the example below. This URL can be observed in the BASIC > Web Log page of your Barracuda Web Security Gateway when the video begins to load in a browser.

Examples: r11---sn-a5m7lnez.c.youtube.com r19---sn-a5m7ln7y.c.youtube.com

To allow one of these specific YouTube videos:

1. Go to the BLOCK/ACCEPT > URL Patterns page of the web interface of your Barracuda Web Security Gateway. 2. From the original video URL, find the unique ID string that follows ?v=. For example: http://www.youtube.com/watch?v=hhyAnz 0oYWw&feature=related

The unique URL pattern for the above address is hhyAnz0oYWw. Enter this string in the Allowed Regular Expressions (Whitelist) sec tion. Remember; URL patterns use regular expressions and require regular expression syntax.

3. Next, attempt to access the specific YouTube video in your web browser. The page will load, but the video will not stream. Go to the BAS IC > Web Log page of your Barracuda Web Security Gateway web interface. Look for a blocked request which contains the serial number of the video.

r11---sn-a5m7lnez.c.youtube.com

For instance, the above example URL contains a specific serial number for the streaming video content. 4. Next, go to the BLOCK/ACCEPT > Domains page. This entire domain name needs to be added to the Allowed Domains (Whitelist) section of the page.

Additional Notes In order for pages to render properly, the Content Server content filter category must be Allowed on the BLOCK/ACCEPT > Content Filter page. Alternately, the YouTube content server can specifically be allowed by creating a domain Allow rule on the BLOCK/ACCE PT > Domains page for ytimg.com.

Some videos on YouTube are age restricted and require a user to log in to access the content. Because of the required authentication (and thus navigating to another page on YouTube), this method of exemption will not work with such videos.

This solution only applies to YouTube over HTTP. When accessing YouTube over HTTPS (https://www.youtube.com/), this solution requires that SSL Inspection be enabled, because the Barracuda Web Security Gateway is otherwise unable to see the full URL path. See Using SSL Inspection With the Barracuda Web Security Gateway.

How to Configure Web Application Monitoring Version 8.x and Above

This feature applies to the Barracuda Web Security Gateway 610 and higher running firmware version 6.0 and higher. Some features, as noted below, are only available with version 8.0 and higher. NOTE: For Chromebook users with the Barracuda Chromebook Security Extension installed:

Settings on the BLOCK/ACCEPT > Web App Control and BLOCK/ACCEPT > Web App Monitor pages do not apply, an d Block/allow actions for G Suite are controlled by the Barracuda Chromebook Security Extension, not the Barracuda Web Security Gateway.

Capture and Archive Suspicious Content or Data Patterns in Chat, Email, and Other Social Media Communications

The Barracuda Web Security Gateway can inspect and catalog outbound content and forward it to an email address or external message archiver, like the Barracuda Message Archiver. These messages can be tied to the users' Active Directory credentials and fully indexed, making them as easy to search as MS Exchange emails. This ensures that social media communications from corporate networks are always available for access and retrieval for eDiscovery and audits as well as to create alerts for proactive monitoring.

Specific data patterns such as credit card numbers, Social Security numbers (U.S.), HIPAA and privacy information can also be detected to help prevent data leakage.

Figure 1: Web Activity Monitoring

How Archiving and Searching Monitored Web Activity Works

From the BLOCK/ACCEPT > Web App Monitor page, you can specify a Web Activity Archiving Email Address for archiving selected actions such as logins, chat, posts, comments and associated content. The Barracuda Web Security Gateway will package each interaction as an SMTP message and email it to this address, which can then be marked for archiving. Archived messages can then be indexed and searched by source or content, and alerts can be generated per policy you set in your archiving solution, or, specifically based on specific data patterns. For information about searching archived messages and using policy alerts with the Barracuda Message Archiver, see Understanding Basic and Advanced Search and Policy Alerts.

NOTE: SSL Inspection must be enabled for actions shown with an asterisk (*) on the BLOCK/ACCEPT > Web App Monitor page to be archived. Examples include:

Facebook user registration and login Google chat message Twitter send tweet, login, direct message, user registration

For a complete list of actions for which SSL Inspection must be enabled for capture, see the BLOCK/ACCEPT > Web App Monitor page.

For more information about SSL Inspection, see Using SSL Inspection With the Barracuda Web Security Gateway and How to Configure SSL Inspection.

Example of Social Media Archiving

You might want to allow users in the organization to use Facebook to view and make comments and use messaging, but you want to capture the content. You might also want to block games and/or other Facebook apps to protect your network from viruses and malware.

To configure Web Application Monitoring, you'll want to first set up your block/accept policies for social media. Here's the process for the example mentioned above:

1. From the BLOCK/ACCEPT > Web App Control page, in the Application Navigator, make sure that Social Media is checked. In the Allowed Applications list box, hold the CTRL key and click Facebook Games and Facebook apps. Click Block. Those applications will move to the Blocked Applications list box.

2. Save your changes. In this example, you have left chat, comment, and other Facebook apps in the Allowed Applications list, moving the applications you want to block, such as apps and games to the Blocked Applications list. 3. From the BLOCK/ACCEPT > Web App Monitor page, enable the application actions whose content you want to archive. In this example, you would Enable Facebook Comments and Message for monitoring. After you enable any actions on the page, the Barracuda Web Security Gateway will capture the content from each action, package it as an SMTP message and email it to the Web Activity Archiving Email Address you specify on the page. 4. Select either pre-defined categories of suspicious keywords to monitor and/or archive using the built-in Barracuda database, and/or specify custom words in the Create New Custom Keyword Category section. Suspicious keyword categories include pornography, cyberbullying and terrorism, for example. 5. Define a Suspicious Keywords Alert Email Address to which the Barracuda Web Security Gateway should send alerts when selected content is detected in traffic from the web-based applications you select on the page.

Detecting Sensitive Data Patterns

(Available with version 8.0 and higher)

Social media and other application communications as noted above may also be searched for data patterns such as credit card numbers and HIPAA compliance terms, for example.

To configure this feature:

Select from a predefined set of filters to quickly set up data pattern categorization policies against the web-based applications listed on the page, such as Facebook and Twitter. These predefined filters include the following: Credit Card – AMEX, DINER, DISCOVER, ENROUTE, CHASE, MC, VIS, VOYAGER Social Security – Social Security Number (United States format) Privacy – birth date, Driver’s License (United States format), expiration date, phone number HIPAA – address, birth date, Driver’s License, expiration date, phone number Enter a Suspicious Keywords Alert Email Address in the Web Activity Notification section of the BLOCK/ACCEPT > Web App Monitor page if you want to receive an alert when these data patterns are detected in the applications you select. If you also want to archive these communications, enter a Web Activity Archiving Email Address in the Web Activity Notification sec tion of the page. After you enable any actions on the page, the Barracuda Web Security Gateway will capture the content from each action in which the selected data patterns are detected, package it as an SMTP message and email it to that email address.

Web App Monitor Log

The BASIC > Web App Monitor Log lists all chat, email, user registrations and other social media interaction traffic it processes per settings you configure on the BLOCK/ACCEPT Web App Monitor page. Fields logged are:

Date - Date and time of the request. Source IP - IP address of the client that originated the request. Username - The name of the user that sent the request. Summary - The action represented in the request. For example, Facebook Comment. Destination - URL visited in the request. Details - Detailed information about the actions: search engine keywords, word from a Facebook Comment, etc.

SSL Certificates Explained

This article applies to using SSL certificates when you enable SSL Inspection on the Barracuda Web Security Gateway.

Barracuda Web Security Gateway Certificates

When the Barracuda Web Security Gateway intercepts an SSL session, it creates two SSL tunnels: one between the client and Barracuda Web Security Gateway, and another between the Barracuda Web Security Gateway and the remote server. Since the Barracuda Web Security Gateway is the endpoint for the client SSL session, it needs to present an SSL certificate to the client that the client will accept AND that the Barracuda Web Security Gateway can use to decode the traffic so that it can inspect the data. In order to accomplish this, the Barracuda Web Security Gateway acts as a Certificate Authority (CA) and creates a signed server certificate for that domain.

For example, if the client is trying to connect to https://www.example.com, the Barracuda Web Security Gateway will present the client with a certificate that states the Barracuda Web Security Gateway has issued the certificate to www.example.com. If the client browser does not trust the Barracuda Web Security Gateway to be an issuer of certificates, or if the Barracuda Web Security Gateways certificate doesn't have the right attributes that denote it as an issuer, the browser will show an error to the end user indicating an SSL handshake issue. Some browsers, such as Chrome, are very security-conscious, and will return an error to the user if any part of this transaction is not performed exactly right and will sever the HTTPS connection. The FireFox browser, conversely, provides the ability to let the user override this behavior and manually accept the certificate.

Third party CAs and subordinate certificates

Third party 'Trusted' certificates are issued by designated providers, or Certificate Authorities, who must adhere to local laws on encryption methods. Note that a public root CA such as Verisign will not provide you with a subordinate certificate; they will only provide you with a server certificate, which cannot be used to issue other certificates. The reason for this is that you could use a subordinate CA certificate to issue SSL certificates for any site you wanted to, and since Verisign gave you the certificate, they would be stating that they trusted you to issue SSL certificates to anyone you wanted to. Verisign and other public root CAs will not do this, in order to avoid the possibility of you issuing SSL certificates to "bad" websites with Verisign (or other public root CA) seen as trusting those sites, even though they have no knowledge of the sites.

Another scenario is that you could use that certificate to intercept SSL traffic for any user anywhere, since almost every web browser in the world trusts Verisign, for example, and you could intercept all users' traffic and have unauthorized access to all of their previously encrypted data.

Since you cannot purchase a subordinate certificate from Verisign or third party root CA, you can use a local CA program to act as a Root Certificate Authority, and use that to generate a subordinate certificate, such as with Microsoft PKI server. As long as your clients trust that local root, you could install any subordinate certificate generated by that root and use it for SSL interception on the Barracuda Web Security Gateway. If your clients do not trust that root CA, they will get errors when browsing which indicate that the SSL certificate is signed by an "untrusted issuer."

A self-signed certificate on the Barracuda Web Security Gateway can also be used for SSL interception without the need to retrieve a certificate from a root CA, but would need to be installed in each end user browser as a Trusted Root Certification Authority.

For more information on using SSL certificates with the Barracuda Web Security Gateway, see also:

How to Create and Install a Self-Signed Certificate for SSL Inspection How to Use the Barracuda Default Certificate for SSL Inspection Barracuda Web Security Gateway Update for SSL Inspection Certificate Handling Using SSL Inspection With the Barracuda Web Security Gateway

Managing Users and Groups

In this Section

Creating Users and Groups How to Choose Your Authentication Mechanisms How to Integrate the Barracuda Web Security Gateway With a User Authentication Service How to Configure Proxy Authentication About the Barracuda DC Agent Role-based Administration Version 7 and Above Wireless Access Point Integration With the Barracuda Web Security Gateway

Creating Users and Groups

The Barracuda Web Security Gateway distinguishes between two basic classes of the users who access websites and web applications from client machines that it has been configured to protect: local users and domain users.

You can apply filtering and blocking policies as well as exception rules to both classes of users, and, with several user authentication methods to chose from in the Barracuda Web Security Gateway, you can apply such rules and policies to specific users, groups, LDAP organizational units (OUs) or machines. Authentication options are addressed below.

You can also view the following information about both local users and domain users:

Account details Traffic Log Applications Log Warned Activity Reports output

Local users are shown as anonymous until they authenticate in the Barracuda Web Security Gateway system by providing login information in order to proceed to a blocked or warned web page or application.

Domain users are shown as anonymous until they become authenticated in the Barracuda Web Security Gateway system by providing credentials to their respective authentication service that has been integrated with the Barracuda Web Security Gateway. Authenticated domain users are shown by username, client IP address, and group membership.

In some cases, you may need to create local accounts as well as enable your Barracuda Web Security Gateway to look up domain accounts. For example, if your regular employees have LDAP accounts but contract employees do not, then you might need to create local accounts for the contractor employees.

Local Users

You can define Local users by listing their existing usernames in the USERS/GROUPS > New Users page. The Barracuda Web Security Gateway authenticates these users from its local database. To apply Web Security Gatewaying policies (and exception rules to your filtering policies) to multiple local users, you can assign local users to local groups that you define in the USERS/GROUPS > Local Groups page.

You can also create IP subnet-based groups - i.e. groups of users who access websites and web applications from client machines within specific ranges of IP addresses. Define IP subnet-based groups of local users in the USERS/GROUPS > IP Groups page.

Domain Users

The Barracuda Web Security Gateway can authenticate domain users using your existing authentication service. You can integrate the Barracuda Web Security Gateway with any of the following types of authentication servers:

LDAP NTLM Kerberos

Doing so enables you to apply Web Security Gatewaying policies and policy exceptions to your domain users without having to re-create local accounts for these users.

Creating Local User Accounts

Use the USERS/GROUPS > New Users page to create a local database of users that the Barracuda Web Security Gateway will authenticate. If you want users to be authenticated using your existing user authentication service instead, go to the USERS/GROUPS > Authentication page and enter the information for your authentication server.

Local user accounts cannot be used to log into the web interface. You can only use the default admin account to log into the web interface.

If you want a new user account to be a member of a group, be sure the group already exists on the USERS/GROUPS > Local Groups page.

Viewing and Managing Accounts

The USERS/GROUPS > Account View page displays all the user accounts that have either been created locally on your Barracuda Web Security Gateway or which reside in your LDAP database. This page lets you view details about each account and make the following changes to any locally created accounts:

Edit a local account by assigning it to a group or enabling/disabling the account Change the password of a local account Delete a local account

To quickly locate a specific account, use the filter feature at the top of the page to search for specific patterns in the account details.

Creating Local Groups

Use the USERS/GROUPS > Local Groups page to create groups for your local users. The most common reason to create a group is so you can apply an exception policy to multiple users at the same time instead of to individual users. For example, you can create a Finance group and create a policy that allows members of that group to browse financial sites, while blocking those sites from other users on the network.

To create a group, enter the group name in the provided field and click Add. To assign an existing user to this group, go to the USERS/GROUPS > Accounts View page and click Edit next to the account that you want to join the group. A user can belong to multiple groups.

When you navigate to the USERS/GROUPS > Local Groups page, the Barracuda Web Security Gateway will only display groups for which you have created an exception. For this reason, it is possible that you won't always see all groups associated with users. To refresh the Groups list, click the Sync Now button in the Group Membership Synchronization section of the USERS/GROUPS > Aut hentication page.

Note that the Sync Now button will only be displayed on that page if you have configured an LDAP, NTLM or Kerberos server..

Creating IP Address Groups

The USERS/GROUPS > IP Subnets/Groups page lets you create a group for a single or range of IP addresses. The most common reasons to create an IP group is to apply an exception policy to:

Multiple users on the same subnet. In this case, enter the subnet mask for the subnet in the provided field. A static IP address. In this case, enter the static IP address in the provided field.

After you enter the IP address or subnet mask and click Add, you can assign an exception policy to the IP group on the BLOCK/ACCEPT > Exceptions page.

Assigning Policy to LDAP Organizational Units

If you are using an Active Directory or other LDAP server, you can create policy exceptions for individual members of an organizational unit or for the entire unit. The Barracuda Web Security Gateway can lookup the organizational units defined on your server after you have configured the server(s) on the USERS/GROUPS > Authentication page. See the Applies To field on that page in the Add Exception section. You can select the server, then click the Lookup button to view OUs in your server.

How to Choose Your Authentication Mechanisms

In this Section

How to Configure Google Directory Services How to Configure Kerberos Authentication How to Enable LDAP Domain User Authentication How to Enable NTLM Domain User Authentication

Below are some use case scenarios to help you decide which authentication scheme(s) to configure on your Barracuda Web Security Gateway. Each example addresses a particular type of environment. Note that LDAP authentication supports multiple domains on one Barracuda Web Security Gateway, but NTLM and Kerberos authentication mechanisms only support one domain per Barracuda Web Security Gateway.

Example 1: Fat clients (standard desktops) using Active Directory

Step 1: Configure LDAP authentication, as described in How to Enable LDAP Domain User Authentication, on the Barracuda Web Security Gateway and synchronize group membership information with your domain controllers (Active Directory servers). This provides a manual way for users to authenticate on the Barracuda Web Security Gateway so you can track user browsing activity.

Step 2: If you want to use single sign-on, install and configure the DC Agent on every domain controller as described in How to Get and Configure the Barracuda DC Agent. For an overview, see About the Barracuda DC Agent.

Example 2: Using only Citrix or other terminal environments

Step 1: Configure NTLM or Kerberos so that the Barracuda Web Security Gateway can join the domain. Reasons for choosing NTLM versus Kerberos are discussed below.

Step 2. Force users to use the Barracuda Web Security Gateway as a proxy server that provides authentication and single sign-on. See Forward Proxy Deployment of the Barracuda Web Security Gateway for details on proxy deployment.

Example 3: Mix of fat clients and Citrix or other terminal environments

Configure per examples 1 and 2. The articles in this section, linked above, further explain reasons and requirements for employing these various authentication schemes.

Exempting selected LDAP domain users from filtering

To exempt LDAP domain users from policy engine processing, on the USERS/GROUPS > Authentication LDAP tab, navigate to the DC Agent Configuration section where exempt user names can be entered. An example use case for this feature is to prevent traffic caused by script logic or other background users from appearing in the traffic log.

NTLM Versus Kerberos

Kerberos is an authentication protocol that provides mutual authentication; i.e. both the user and the server verify each other's identity. For this reason, Kerberos is considered a more secure authentication protocol than NTLM. Implementing Kerberos-based authentication within your network will allow the Barracuda Web Security Gateway to associate outgoing web requests with Active Directory users, log user activity, and apply user-specific or group-specific policies to outgoing connections without requiring users to log into the Barracuda Web Security Gateway.

Kerberos is useful when a Microsoft domain controller is running in native mode. It is a Forward Proxy authentication scheme and the Barracuda Web Security Gateway need not verify each authentication request against a domain controller. See How to Configure Kerberos Authentication fo r more information about Kerberos.

If your network uses an NT LAN Manager (NTLM) authentication server, your NTLM domain users transparently become authenticated in the Barracuda Web Security Gateway using their Microsoft Windows credentials. This single sign-on (SSO) method of access control is provided by transparent proxy authentication against the your NTLM server.

To enable transparent proxy authentication against your NTLM server, you must join the Barracuda Web Security Gateway to the NTLM domain as an authorized host. The process of joining the domain also synchronizes NTLM group information from your domain controller to the Barracuda Web Security Gateway. Configure NTLM authentication on the USERS/GROUPS > Authentication page NTLM tab. See How to Enable NTLM Domain User Authentication for more information about NTLM.

How to Configure Google Directory Services This solution applies to the Barracuda Web Security Gateway running firmware version 12.x and higher.

When to use Google Directory Services

For all Chromebook deployments, when using the Barracuda Chromebook Security Extension, configure Google Directory Services as the authentication service the Barracuda Web Security Gateway will use to apply policies to Chromebook users and groups. Make sure to configure the Chromebook extension for your users on the ADVANCED > Remote Filtering page. See How to Get and Configure the Barracuda Chromebook Security Extension for details on configuration.

Requirements for using a Google Directory Services

Before you integrate with Google Directory Services, do the following:

1. Make sure you or your organization has a Google account with read access to Google Directory Services. 2. Edit the hosts file on the machine you use to log into and configure the Barracuda Web Security Gateway: For Windows: Open a text editor that does not add extra characters and edit the hosts file, which is located in C:\Windows\Sy stem32\drivers\etc For Unix/Linux/MacOS : Edit the hosts file, which is located in /etc

In the hosts file, add a line with the IP address of the Barracuda Web Security Gateway, followed by one space, and then the URL mywsg.barracuda.com. For example: 10.1.1.1 mywsg.barracuda.com 3. Save the hosts file.

Either before or after setting up Google Directory Services, you must configure the Barracuda Chromebook Security Extension as mentioned above.

Configure Google Directory Services on the Barracuda Web Security Gateway

1. Log into the Barracuda Web Security Gateway web interface as admin. 2. Go to the USERS/GROUPS > Authentication page. Follow instructions to configure an Alias by which to refer to the GDS authentication service and your Google domain (you must have read access to GDS for this domain). You will use the alias to select all Chromebook users when creating and assigning policies on the Barracuda Web Security Gateway.

3. Click Setup Google Directory Service. In the Configure Localhost popup, assuming you have already edited your hosts file as described above, click Continue.

4. You are redirected to a Google page in your browser, prompting you to select and log into your Google account. 5. You are then prompted by Google to allow the Barracuda Web Security Gateway permissions to access users and groups of users on your Google domain. Click Allow.

You are then redirected to the USERS/GROUPS > Authentication page on the Barracuda Web Security Gateway. You should see the alias of the GDS instance you created in the Existing Authentication Services table on the page.

To disconnect from GDS, click Delete for the GDS instance (alias) in the table.

How to Configure Kerberos Authentication This solution applies to all Barracuda Web Security Gateways running firmware version 4.2 and higher. Windows 2000 and later platforms use Kerberos as the native authentication method. Note that Kerberos is not supported for multiple domains on one Barracuda Web Security Gateway.

When to use Kerberos Authentication

Use Kerberos with the Barracuda Web Security Gateway in any of the following scenarios:

Clients are behind a NAT-enabled router — Requests from users on client machines behind a NAT-enabled router would appear to the Barracuda Web Security Gateway to be sent from the same reusable NAT Router IP address. Windows Terminal Services — Requests from users using Windows Terminal Services to access remote data and applications on another client machine would appear to the Barracuda Web Security Gateway to be sent from the Windows terminal IP address. Citrix Presentation Services — Requests from users accessing remote data and applications on a Citrix Presentation Server would appear to the Barracuda Web Security Gateway to be sent from the Citrix Presentation Server.

Requirements for using a Kerberos authentication server

Before you integrate with a Kerberos authentication server, please verify the following requirements:

The Barracuda Web Security Gateway is typically deployed as a forward proxy when using Kerberos authentication. However, in certain use cases where the Barracuda Web Security Gateway is deployed inline, traffic from users who authenticate via Kerberos can be proxied to the Barracuda Web Security Gateway. A common scenario for this use case is transitioning from one deployment/configuration to another, where some users are on a Citrix server, for example, and other users are on desktops using LDAP authentication. LDAP is the only other authentication service you may configure when using Kerberos authentication with the same Barracuda Web Security Gateway. This is called Hybrid Authentication. For more information on deploying your Barracuda Web Security Gateway as a forward proxy, please refer to Forward Proxy Deployment of the Barracuda Web Security Gateway. No Barracuda DC Agents are required if only using Kerberos authentication, but will be required if using LDAP authentication in addition to Kerberos. Web browsers must support Kerberos (Internet Explorer version 7 or Firefox version 3) and must be configured to use the Barracuda Web Security Gateway as an HTTP proxy via port 3128. Client workstations and the Barracuda Web Security Gateway must have properly configured DNS resolution mechanisms. DNS servers must be able to resolve IP addresses in both forward and reverse. All host machine clocks must be synchronized within 5 minutes of the Kerberos server clock. All users must have domain logon credentials, generally speaking; however, non-domain machines can use Kerberos authentication provided that Kerberos is configured correctly on those machines.

Implementing Kerberos

Follow these steps to create your Kerberos service on the Barracuda Web Security Gateway:

1. Set your Default Domain and Default Hostname on the BASIC > IP configuration page. On your DNS server(s), add an entry (both forward and reverse mappings) for your Barracuda Web Security Gateway. 2. On the Kerberos tab of the USERS/GROUPS > Authentication page, enter the Realm, or Windows administrative domain name. 3. On that page, in the KDC field, enter the fully qualified domain name (FQDN) of the Key Distribution Center server for the realm you specified. This is typically the FQDN of your domain controller. 4. Enter the Username and Password of an account that has administrative privileges on your Active Directory server. Do not include the domain name in the Username entry. For example, if the Username is administrator, simply enter administrator. 5. Click the Add button to create the new Kerberos service. Once you do this, the service should appear as type Kerberos in the Existing Authentication Services table on the USERS/GROUPS > Authentication page on the Kerberos tab. 6. Ensure that the Barracuda Web Security Gateway's FQDN (not the IP) and port 3128 are configured as an HTTP proxy on all users' browsers.

Important If you have installed the Barracuda DC Agent software on your domain controller(s) for use with clients authenticating via LDAP, ( see About the Barracuda DC Agent ) make sure to do the following when adding users in terminal environments who will be authenticating with either Kerberos or NTLM:

1. Run the Barracuda DC Agent monitor and click on the Filters tab. 2. Specify any IP addresses for which the DC Agent should not capture and send login information (for LDAP logins) to your Barracuda Web Security Gateway. This includes Citrix or other terminal servers used when implementing Kerberos or NTLM authentication mechanisms, while you also have PCs using LDAP and utilize a Barracuda DC Agent. These IP addresses are exceptions and associated login events (for LDAP logins) will be ignored by the Barracuda DC Agent.

Note that implementing Kerberos Authentication will restrict some configuration options, as follows:

No login override of blocked pages: When a policy on the Barracuda Web Security Gateway blocks Internet access for a user, that user will not be offered login fields at the bottom of the block message page, even if Allow Login Override of Blocked Pages is enabled on the BLOCK/ACCEPT > Configuration page. No logout option: Users cannot log out when proceeding to a blocked page in order to surf anonymously. More precisely, when a policy on the Barracuda Web Security Gateway blocks Internet access for user, that user will not be offered a logout option at the bottom of the block message page, even if the Offer Logout option on the BLOCK/ACCEPT > Configuration page is enabled. Users are not displayed in the USERS/GROUPS > Account View page when authenticated via Kerberos.

About Kerberos Authentication

How to Enable LDAP Domain User Authentication If your network uses a Lightweight Directory Access Protocol (LDAP) or Active Directory authentication (AD) server, your LDAP domain users can use the LDAP or AD authentication service to be authenticated in the Barracuda Web Security Gateway system. The Barracuda Web Security Gateway can also enable you to look up users by organizational units you have defined on your LDAP server when creating exceptions to block/accept policy.

To enable LDAP user authentication, from the USERS/GROUPS > Authentication page, in the LDAP tab, provide information about connecting to the LDAP server, binding to the LDAP server, encryption type and LDAP attributes. Click the Help button on the page for detailed steps.

To configure proxy authentication through LDAP for remote users such as students with Chromebooks, and other off-network users, see How to Configure Proxy Authentication.

How to Enable NTLM Domain User Authentication If your network uses an NT LAN Manager (NTLM) authentication server, your NTLM domain users transparently become authenticated in the Barracuda Web Security Gateway using their Microsoft Windows credentials. This single sign-on (SSO) method of access control is provided by transparent proxy authentication against the your NTLM server. Note that you can configure NTLM authentication in conjunction with LDAP as well as running the Barracuda DC Agent on your domain controller(s).

NTLM is not supported for multiple domains on one Barracuda Web Security Gateway.

To enable transparent proxy authentication against your NTLM server, you must join the Barracuda Web Security Gateway to the NTLM domain as an authorized host. The process of joining the domain also synchronizes NTLM group information from your domain controller to the Barracuda Web Security Gateway. For details on how to set up NTLM and configuration, see the USERS/GROUPS > Authentication page NTL M tab in the Barracuda Web Security Gateway web interface.

For details on integrating with your existing user authentication server, see How to Integrate the Barracuda Web Security Gateway With a User Authentication Service.

Windows Support for NTLM authentication

Windows Server 2000 and Windows 2003 with Active Directory (in mixed mode) run the NTLM authentication protocol by default. In a native mode Active Directory domain, Windows Server 2003 runs the Kerberos authentication protocol.

Starting with Windows Vista, and also with Windows Server 2008 and Windows 7, both LM and NTLM are de-activated by default. Microsoft specifies Kerberos as the preferred authentication protocol for Windows 2003 and Windows Server 2008 Active Directory domains. Kerberos is typically used when a client belongs to a Windows Server domain, or if a trust relationship with a Windows Server Domain is established in some other way. For more on Kerberos, see How to Configure Kerberos Authentication. However, NTLM can still be used in the following situations:

The client is authenticating to a server using an IP address The client is authenticating to a server that belongs to a different Active Directory forest, or doesn’t belong to a domain at all No Active Directory domain exists

For detailed descriptions of these scenarios, click the Help button on the USERS/GROUPS > Authentication page.

Requirements for using an NTLM Authentication Server

Before you integrate with an NTLM authentication server, verify the following requirements:

The Barracuda Web Security Gateway must be deployed as a forward proxy. Kerberos authentication is not already configured. Web browsers must be configured to use the Barracuda Web Security Gateway as the HTTP proxy.

For detailed descriptions of these requirements, click Help on the USERS/GROUPS > Authentication page.

1. Run the Barracuda DC Agent monitor and click on the Filters tab. 2. Specify any IP addresses for which the Barracuda DC Agent should not capture and send login information (for LDAP logins) to your Barracuda Web Security Gateway. This includes Citrix or other terminal servers used when implementing Kerberos or NTLM authentication mechanisms, while you also have PCs using LDAP and utilize a Barracuda DC Agent. These IP addresses are exceptions and associated login events (for LDAP logins) will be ignored by the Barracuda DC Agent.

Limitations when using an NTLM Authentication Server

The following limitations apply when using an NTLM authentication server with the Barracuda Web Security Gateway:

No login override of blocked pages for NTLM domain users who encounter a block message. No logout option for NTLM domain users who proceed to a blocked web page. NTLM domain users are not listed in the Account View page. NTLM realm is not listed for users listed in the syslog output.

For detailed descriptions of these restrictions, click Help on the USERS/GROUPS > Authentication page.

If an Active Directory Group object does not have any members (i.e. the group is empty), the group will not display in the Lookup field on any page in the Barracuda Web Security Gateway web interface where you can select an authentication mechanism. Conversely, when using LDAP, empty Active Directory groups are displayed if they exist.

How to Integrate the Barracuda Web Security Gateway With a User Authentication Service

Granular Policies By Users, Groups or Machines

By integrating the Barracuda Web Security Gateway with your existing authentication server, you can configure usage policies at several levels of granularity; policies can apply to the whole organization or to specific users, machines, or groups. Using LDAP, NTLM, or Kerberos authentication , or a combination of them, you can apply policies and generate reports directly on users, LDAP organizational units (defined on your LDAP server) or groups you define without the need to create local user accounts on the Barracuda Web Security Gateway.

Note that neither NTLM or Kerberos are typically supported for multiple domains on one Barracuda Web Security Gateway; however, if this is required for your configuration, please contact Barracuda Networks Technical Support.

Applying Web Access Policy by Groups

Typically, computer users in a network are grouped along organizational, departmental, physical or functional boundaries. As the administrator, you can create secure accounts for network users and also group them as appropriate. Users then supply their login credentials from their workstations to activate their network privileges. This allows the administrator to control Internet access privileges separately for each user or group of users. For example, a school can apply a more restrictive browsing policy for students than for teachers and staff, or an organization can allow access to job sites only to the Human Resources department (which you may have defined as an organizational unit on your LDAP server).

If you do not integrate with your LDAP, NTLM or Kerberos authentication server, you can apply filtering policy exceptions only to local users and groups that you create in the USERS/GROUPS tab.

Terminal Environments and Authentication

Kerberos and NTLM authentication schemes work well with Citrix terminal environments and Windows terminal services environments. The Barracuda Web Security Gateway can also support various user groups using different authentication schemes to provide different types of user access and policy control. For example, if your organization has a group of Windows desktop users who authenticate against an LDAP server and another group using a Citrix terminal environment or Windows terminal services environment, you can configure both groups with one Barracuda Web Security Gateway.

Using a 'hybrid' authentication deployment, Windows desktop users can authenticate inline via your LDAP server, while the terminal users can authenticate via NTLM or Kerberos in a forward proxy configuration.

To use a hybrid authentication scheme:

1. Add your LDAP and NTLM or Kerberos services as described in the following articles: How to Choose Your Authentication Mechanisms How to Enable NTLM Domain User Authentication How to Configure Kerberos Authentication 2. Go to the ADVANCED > Proxy page. 3. Set Enable Port Auth Exemption to Yes. This means that port 8080 traffic is exempt from NTLM/Kerberos authentication. 4. Proxy Windows desktop traffic to port 8080 on the Barracuda Web Security Gateway.

Detailed procedural help is also available on the ADVANCED > Proxy page.

LDAP Authentication

LDAP users are authenticated when credentials are provided in order to proceed to a blocked or warned web page or application. LDAP users can also be authenticated by single sign-on access if you install the Barracuda DC Agent software on your domain controller(s) – see Barracuda DC Agent for User Authentication for details, or see the Help on the USERS/GROUPS > Authentication page. NTLM and Kerberos users are authenticated by single sign-on access against the NTLM or Kerberos authentication service, so they are transparently authenticated in the Barracuda Web Security Gateway using their Microsoft Windows credentials. Authenticated domain users are known by username, client IP address, and group membership:

Usernames and client IP addresses of authenticated LDAP domain users are visible in the USERS/GROUPS > Account View page, the Web Log page, the Application Log page and in reporting output. Group membership information about authenticated domain users is available by opening the Lookup facility (accessed by clicking Look up button in the BLOCK/ACCEPT > Exceptions page) and using the Active Directory User/Group section of that window.

Note: Domain users that are unauthenticated in the Barracuda Web Security Gateway appear as anonymous users.

How to Configure Proxy Authentication

This article applies to the Barracuda Web Security Gateway running version 8.0 and higher.

Protecting User Browsing Off Network

This feature enables you to prevent remote users (students for example) from accessing objectionable material when off campus by routing their Internet requests through the Barracuda Web Security Gateway, regardless of where they access the Internet. When users attempt to access the Internet remotely, they are required to provide their LDAP credentials first.

With this configuration, you can require LDAP authentication for users who are either local or have accounts on your LDAP server. For Chromebo oks, use the Barracuda Chromebook Security Extension. For Windows and Macintosh computers, install the Barracuda Web Security Agent to proxy web traffic.

When LDAP users, such as students with Chromebooks, go off network and their browsers are configured to proxy traffic to the Barracuda Web Security Gateway, they are prompted for their network credentials each time they open a browser. Proxy Authentication supports the aliased LDAP servers that you configure on the USERS/GROUPS > Authentication page.

Configure Proxy Authentication Users Off Network

Complete the following steps to configure proxy authentication for users when they access the Internet while off campus:

1. Configure the browser on each device to proxy traffic to the Barracuda Web Security Gateway. To do so, you have two options: a. In the Advanced/Network settings of client browsers, using the manual proxy setting, enter the IP address of the Barracuda Web Security Gateway as the HTTP Proxy and 3128 for the port. If you wish to use a different port, you can change the Proxy Port s etting on the ADVANCED > Proxy page of the Barracuda Web Security Gateway web interface. OR b. Create a PAC file and use a GPO to push it out to all client browsers. The PAC file provides lots of flexibility as to which traffic is filtered and can provide load balancing. For details, see Proxying Web Traffic Using a PAC File. 2. On the USERS/GROUPS > Authentication page, define an LDAP server with an alias (for example, StudentLDAP). 3. On the USERS/GROUPS > Configuration page, select this alias from the Enable Basic Authentication list.

When individuals attempt to access the Internet using their computers while off campus (for example, while at home or at a cafe with wireless Internet access), they are prompted to log in with their LDAP credentials. After they log in, their activity is logged by username on the Barracuda Web Security Gateway and is included in reports, even though they are connecting from a public access point outside their campus network.

Delegated Administrators (Read-only, Manage, Monitor, Support) are not allowed to enable Proxy Authentication. The USER/GROUPS tab is disabled for these users.

Block All Unauthenticated Traffic

After setting up authentication for your Chromebook and other remote and mobile users, you can now decide to block all unauthenticated traffic if necessary. On BLOCK/ACCEPT pages, select Unauthenticated and create block policies for content types, URL patterns, etc.

About the Barracuda DC Agent

You can install the Barracuda DC Agent either on the domain controller or on a dedicated Windows PC on the office network. The Barracuda DC Agent periodically checks the domain controller for login events and to obtain a record of authenticated users. The IP addresses of authenticated users are mapped to their username and group context. The list of authenticated users is provided to the Barracuda Session Manager on your Barracuda Networks product, allowing true single sign-on capabilities.

For iOS Users Due to the way Apple devices authenticate users with Windows Active Directory, the Barracuda DC Agent is unable to pick up Mac user logins to Windows Active Directory. The Barracuda DC Agent can, however, capture user logins from wireless devices such as iPads or iMacs if the user is authenticating via WAP against a RADIUS server.

A typical use case scenario: Alice comes into her office in the morning and logs into her workstation. She enters her user credentials and is authenticated by the domain controller. The Barracuda DC Agent recognizes that Alice has authenticated herself within the corporate network domain and forwards this information to all connected Barracuda Networks products. These systems now give Alice access to services or network areas for which a valid user or Microsoft Active Directory group context is required. Alice does not need to re-enter any credentials because her initial authentication by Active Directory is reused.

Exclusions

The Barracuda DC Agent lets you manually exclude IP addresses of user client PCs or known multi-user computer systems and provides a "learning mode" that proposes the exclusion of suspicious systems. Due to the complexity of today's network environments and multi-user computer systems, a user-to-IP association is not always possible or required. For example, you can exclude the HTTP Proxy and Terminal Server because they allow multiple users and use a single IP address for authentication against domain controllers.

If you install the Barracuda DC Agent on your domain controller(s) for use with clients authenticating via LDAP, and then later add users in terminal environments using Kerberos or NTLM authentication, you must exclude the IP addresses of these terminal servers in the DC Agent monitor Filters tab. These IP addresses are exceptions and associated login events (for LDAP logins) should be ignored by the Barracuda DC Agent. See How to Get and Configure the Barracuda DC Agent for details.

Remote Monitoring

If you install the Barracuda DC Agent on a dedicated computer system instead of the Active Directory server, you can also remotely monitor Active Directory.

How to Get and Configure the Barracuda DC Agent

The Barracuda DC Agent version 7.1.x replaces all previous versions published. Barracuda recommends using the latest version of the Barracuda DC Agent. Download the latest version in the Barracuda Download Portal.

For iOS users: Due to the way Apple devices authenticate users with Windows Active Directory, the Barracuda DC Agent is unable to pick up Mac user logins to Windows Active Directory. The Barracuda DC Agent can, however, capture user logins from wireless devices such as iPads or iMacs if the user is authenticating via WAP against a RADIUS server.

For the Barracuda Web Filter Only: The Barracuda DC Agent 7.1.x and higher does not support Windows Server 2003. If you are running Windows Server 2003, please contact Barracuda Networks Technical Support. Otherwise, download the Barracuda DC Agent from the USERS/GROUPS > Authentication page of the Barracuda Web Security Gateway web interface as described below.

System Requirements

Before configuring the Barracuda DC Agent, make sure that your system meets the following requirements:

Local Installation – Microsoft Windows Server 2008, 2008 R2, 2012, 2012 R2 or 2016. Windows Server Core is not supported for local installation and monitoring. The DC Agent can, however, communicate with a domain controller that is running Windows Server Core. In this case, you could install the DC Agent on a server running Microsoft Windows Server 2008, 2008 R2, 2012, 2012 R2, or 2016 and configure it to remotely monitor a domain controller that is running on a Windows Server Core machine. Remote Installation – Microsoft Windows 2008 and higher. Also note that, for the remote installation of DC Agent, you MUST be a domain member to query the server.

For remote monitoring of domain controllers, the Barracuda DC Agent Active Directory Profile must be provided with a domain controller user with administrative privileges.

Get and Install the Barracuda DC Agent Version 7.x

You can install the Barracuda DC Agent directly on the domain controller or on a dedicated Windows PC within your network environment. To monitor wireless device logins using Windows Network Policy Server (NPS) log events, see Using the Barracuda DC Agent with Microsoft Network Policy Server.

For the Barracuda Web Security Gateway:

1. Log into the web interface as admin and download the Barracuda DC Agent from the USERS > Authentication page using the Barracuda DC Agent (Download/Install) link at the bottom of the screen. 2. To launch the installation file (DCAgent.exe), RIGHT CLICK on it and select Run as administrator. 3. Follow the instructions in the wizard. When going through the steps in the installation wizard, all settings normally should be left at default. The required settings to configure should be: Your domain information The IP address of the allowed Barracuda Web Security Gateway 4. Confirm that Logon Events are monitored by your domain controller: a. Open Domain Controller Security Policy (Start > Programs > Administrative Tools). b. Click Local Policies. c. For Audit account logon events and Audit logon events, make sure that the Policy Settings column displays Success.

For the NextGen Firewall F-Series:

1. Get the Barracuda DC Agent from your Barracuda Cloud Control Account. 2. While logged into your account, go to the Support > Downloads page. 3. From the Product list, select Barracuda NG Firewall. 4. Select Fulltext, enter Barracuda DC Agent, and then click Search. 5. Download the latest Barracuda DC Agent version that is compatible with your system. 6. To launch the installation file (DCAgent.exe), RIGHT CLICK on it and select Run as administrator. 7. Confirm that Logon Events are monitored by your domain controller: a. Open Domain Controller Security Policy (Start > Programs > Administrative Tools). b. Click Local Policies. c. For Audit account logon events and Audit logon events, make sure that the Policy Settings column displays Success.

Configure the Barracuda DC Agent

After the Barracuda DC Agent is installed and running correctly, launch the application and complete the following steps. Note: Your entries in the DC Agent interface will NOT be saved until you click the Save button.

1. Define location and login credentials for your Active Directory. Click the Active Directories tab and click the green + sign to add a domain. a. Select Local if you installed the DC Agent on the Domain Controller; select Remote if you installed on another machine on the network. b. If you selected Remote, enter the Fully Qualified Domain Name (FQDN) in the Host field. c. Enter a name for referring to the domain, e.g. 'Finance', 'Salesnet', etc. d. The Username should be associated with permissions to run WMI queries on the domain controller. Enter that user's Password and click OK.

For remote monitoring of domain controllers, the Barracuda DC Agent Active Directory Profile must be provided with a domain controller user with administrative privileges.

e. Click Test to verify connectivity with the domain controller.

2. Add the internal IP Address and a Description for each Barracuda Networks appliance (Barracuda Web Security Gateway, NG Firewall, etc. – hardware or virtual) with which you want to use the DC Agent. 3. On the Filters tab, specify any IP Address, User, or Group for which you don't want the DC Agent to capture and send login information to your Barracuda Networks products. These are exceptions and associated login events will be ignored by the DC Agent. Here are the formats you can use to specify IP address exemptions:

Single IP address (Example: 192.168.0.1)

IP Range/CIDR notation (Example: 192.168.0.0/24)

IP Range/Subnet mask (Example: 192.168.0.0/255.255.255.0)

Important: For the Barracuda Web Filter If you install the Barracuda DC Agent software on your domain controller(s) for use with clients authenticating via LDAP, ( see

Barracuda Web Security Gateway Administrator's Guide - Page 202

About the Barracuda DC Agent ) and you later add users to your Barracuda Web Security Gateway in Citrix or other terminal environments who will be authenticating with either Kerberos or NTLM, make sure to do the following:

a. Run the Barracuda DC Agent monitor and click on the Filters tab. b. Specify the IP addresses of the terminal servers where users will authenticate via Kerberos or NTLM. These are IP addresses for which the DC Agent should not capture and send login information to your Barracuda Web Security Gateway.

4. On the Settings tab, configure the following: Appliance Listening Port – If required, you can change the TCP listening port. Make sure that you also specify the same port on all configured Barracuda Networks products. Default is port 5049. Debug Log Level: Errors Only = log errors only Info = informational Debug = verbose (most information logged) Group Options (Barracuda Next Firewalls only) – select which option best fits your logging requirements. If group information is required for authenticated users, select one of these group name types. Cache groups for: Amount of time, in minutes, to allow the DC Agent to rely on cached login information. Since users will most likely log in once/workday, the default time is 480 minutes, or 8 hours. The shorter this time is, the more often the DC Agent will retrieve login event information from the domain controller and pass it to the Barracuda Networks product, which requires more processing overhead.

DC Agent Logging

Typically you'll only need the Log upon first install of the DC Agent to make sure everything is working as expected. Note that, if you were previously running another version of the DC Agent, that data logged while the old agent was running will no longer show in the user interface log window. That data is still, however, in the database and will appear in reports as usual. To monitor wireless device logins using Windows Network Policy Server (NPS) log events, see Using the Barracuda DC Agent with Microsoft Network Policy Server.

Configure your Barracuda Networks Product

To ensure that your Barracuda Web Security Gateway or NextGen Firewall can communicate with the Barracuda DC Agent, you must configure the product as well.

For the Barracuda Web Security Gateway, see the online help on the USERS > Authentication page in the web interface. For the Barracuda NG Firewall, see How to Configure the MSAD DC Client.

How to Uninstall the Barracuda DC Agent

1. Verify that the Barracuda DC agent service is not running. 2. Use the Add/Remove Programs or Programs and Features tool in the Windows Control Panel to uninstall the Barracuda DC Agent.

Using the Barracuda DC Agent With Microsoft Network Policy Server Microsoft Network Policy Server (NPS) performs centralized authentication, authorization, and accounting for wireless, authenticating switch, remote access dial-up and virtual private network (VPN) connections. With the Barracuda DC Agent, you can also log the IP addresses and AD identities of wireless users in the organization by monitoring the NPS logs if the following requirements are met:

The Barracuda DC Agent is installed locally on the NPS server. The wireless access points (WAPs) in the environment are configured to use RADIUS authentication against the NPS server on which the DC Agent is installed. The WAPs must be configured to send RADIUS accounting information, i.e. not merely RADIUS authentication information. The reason is that the framed IP address attribute of the RADIUS session contains the user's IP address, and that information is only contained in the accounting information. The NPS log must be in the default location (C:\Windows\system32\LogFiles) and in the default format ("ODBC (Legacy)"), with the log file rotation set to Monthly, or the Barracuda DC Agent will not be able to monitor the log. To change the logging properties, see How to access configuration of the NPS log file properties below.

Note that normal operation of the DC Agent allows for installation either locally or remotely, and this configuration requires local installation on the NPS server. The NPS server does not need to be a domain controller (DC). If you also want to pick up logins from workstations and other sources, you will need to either install the DC Agent on a DC or add a remote Active Directory (AD) connection to the instance of the DC Agent running on the NPS server.

Configure your Barracuda appliances (e.g.Barracuda Web Security Agent, Barracuda NG Firewall, etc.) as you normally would so that the device can collect the logins harvested from the NSP log by the DC Agent.

This feature is automatically enabled in the DC Agent – if it finds NPS logs, it will automatically monitor them. Log entries for NPS-related events are prefixed with "NPS: ", and increasing the log verbosity (Debug Log Level) will log additional NPS-related information for troubleshooting purposes. The only necessary configuration to perform in the DC Agent interface is to configure the properties of the NPS log file in which you want to store the accounting data.

How to access configuration of the NPS log file properties

1. Open the NPS console or the NPS Microsoft Management Console (MMC) snap-in. 2. In the console tree, click Accounting. 3. In the details pane, in Log File Properties, click Change Log File Properties. The Log File Properties dialog box opens. Barracuda recommends using the default settings. See http://technet.microsoft.com/en-us/library/ee663944(v=ws.10).aspx for more information.

Due to limitations in the RADIUS protocol, the DC Agent does not track when a user "logs out" of the wireless environment, so the IP address associated with that wireless user will remain associated with them until it is re-used by a new AD user or until the appliance times out the session. This timeout interval is configurable on the appliance.

Note also that there may be a delay in between when a user authenticates to RADIUS and when a user's identity is available to their appliance(s) since many devices have a RADIUS accounting interval.

How to Uninstall or Update the Barracuda DC Agent

Uninstall the Barracuda DC Agent

Perform the following steps to update the Barracuda DC Agent software running on a device:

1. Stop the Barracuda DC Agent service under Windows services. 2. Uninstall the old version of the Barracuda DC Agent software using either the Control Panel or the same executable used to install the old version of the Barracuda DC agent.

Update the Barracuda DC Agent

Perform steps 1 and 2 above, and then the additional steps to update the Barracuda DC Agent software running on a device:

1. Navigate to the C:\Program Files folder (or the folder where the Barracuda DC agent was installed) and rename the Barracuda folder to Barracuda.old. 2. To Install the new DC agent software (DCAgent.exe), right click and RUN as ADMIN. When going through the steps in the installation wizard, all settings should typically be left at default. The required setting to configure should be: A. The Domain information is added for your domain and saved, and B. The IP address of the allowed Barracuda Web Security Gateway in the Appliance tab/page of the Barracuda DC Agent. 3. Ensure that the Barracuda DC Agent service is started under Windows services.

It is important to install the Barracuda DC Agent on any new domain controllers or when updating the operating system on existing domain controllers.

Role-based Administration Version 7 and Above

This article applies to the Barracuda Web Security Gateway running firmware version 7 and higher. For information that applies to version 6.x, see Role-based Administration 6.x.

The administrator of the Barracuda Web Security Gateway might choose to delegate certain administrative tasks such as scheduling and/or running reports, viewing Dashboard and log pages, or creating exceptions to policy.

On the ADVANCED > Delegated Admin page, you can create and manage account roles for existing users. You can use the Limit Access To s etting to further restrict access for an account to data associated with local users, local groups and/or IP groups. The roles are enumerated below. To enable users with these roles to log into the Barracuda Web Security Gateway using their LDAP credentials, check the Use LDAP Authentication box on the page. Alternatively, you can assign a username and password to the role when you create it on the ADVANCED > Delegated Admin page.

The Policy Alerts feature enables you to have the Barracuda Web Security Gateway send an email alert to any role you specify, summarizing authenticated users who violate policy. The message will summarize actions (Warn, Block or Monitor) by the top violators of policies configured on the BLOCK/ACCEPT > Content Filter page and on the BLOCK/ACCEPT > Exceptions page. For details on configuration, see Policy Alerts .

Roles and Permissions

Administrator

The administrator role has all permissions and is the only role that can create policies. The Limit Access To setting does not apply.

Read Only

This is the most restricted role, including access to all tabs in read-only mode and viewing (running, but not scheduling) reports. The Limit Access To setting does not apply. This role does not enable changing any settings.

Manage

The Manage role can view Dashboard and Log pages, view and schedule reports and create exceptions on the BLOCK/ACCEPT > Exceptions page. All other BLOCK/ACCEPT tabs are read-only. The following pages are disabled:

USERS/GROUPS ADVANCED BASIC > IP Configuration BASIC > Administration

The Limit Access To setting applies.

Monitor

This role can view Dashboard and Log pages and can view and schedule reports. All BLOCK/ACCEPT pages are read-only. The following pages are disabled:

USERS/GROUPS ADVANCED BASIC > IP Configuration BASIC > Administration

The Limit Access To setting applies.

Support

For users in a helpdesk type of position, the Support role enables viewing Dashboard and Log pages as well as reports, but this role cannot schedule reports. The Support role can create exceptions on the BLOCK/ACCEPT > Exceptions page, but all other BLOCK/ACCEPT tabs are read-only. The following pages are disabled:

USERS/GROUPS ADVANCED BASIC > IP Configuration BASIC > Administration

Use Cases for Various Roles

Monitoring and Reporting: Use the Read Only role for the user who will be monitoring status and running (but not scheduling) reports on the Barracuda Web Security Gateway. This role cannot change any settings. Monitoring, Reporting and Creating Exceptions: The Support role is designed for the Helpdesk person in the organization who

provides daily reporting and monitoring of set policies for the administrator who has delegated these tasks. Unlike the Read Only role, this role can also create exceptions to policies as directed by the administrator. Users are blocked from websites they need to access: The Manage role can create exceptions to policy for block, warn, monitor or allow actions that have been set for various domains or categories of domains. For example, job search websites may be blocked for most employees, but certain members of the HR department need to access them. This role can make an Allow exception for a Local Group such as HR Managers (see USERS/GROUPS > New Users and USERS/GROUPS > Local Groups to assign users to groups) to access the Job Search & Career Development sub category of domains . Support for performance or connectivity issues: The Support role can view the DASHBOARD page to check performance statistics and note if there are any red indicators on throughput, system load or report/log storage.

Audit Log

Wireless Access Point Integration With the Barracuda Web Security Gateway

The Barracuda Web Security Gateway 310 and above running version 9.0 and above currently supports the following wireless access points (wireless APs) using RADIUS authentication:

Aerohive Aruba Cisco AP Clearpass Meru Ruckus

The Barracuda Web Security Gateway 310 and above running version 7.x - 8.x currently supports only the Meru and Ruckus wirele ss access points. For accepted syslog outputs from these devices, see Accepted Syslog Formats From Wireless APs.

Wireless APs have become ubiquitous around corporate and academic campuses. These access points are typically connected to an authentication service such as a RADIUS server, for example, which enables end users to authenticate and gain access to a corporate or campus network. You can integrate one or more wireless APs with the Barracuda Web Security Gateway so that users surf the web as authenticated users after authenticating against their wireless AP. This means that the user only needs to enter their credentials once, and also that they are subject to policies you configure on the Barracuda Web Security Gateway.

Delegated administrators (Read-only, Manage, Monitor, Support) do not have permissions to enable Wireless AP Integration on the Barracuda Web Security Gateway. The USER/GROUPS tab is disabled for these users, so this feature is not visible.

How Wireless AP Integration Works

Each wireless AP can be configured to send its syslogs to the Barracuda Web Security Gateway on the network. With Wireless AP Integration enabled, the Barracuda Web Security Gateway listens for system logs coming from each wireless AP, and then parses the data for the username and IP address of the user that logged in. Policies you configure on the Barracuda Web Security Gateway are applied to these users by username, group (if applicable) and/or IP address, and report data reflects username and IP address pairs for all logged web traffic.

How to Configure Wireless AP Integration on the Barracuda Web Security Gateway

Use the following steps to configure all wireless APs to send syslogs to the Barracuda Web Security Gateway:

1. Go to the USER/GROUPS > Configuration page and, in the Access Point Configuration section, select the wireless provider in the A ccess Point Provider drop-down for the wireless AP that should send logs to the Barracuda Web Security Gateway. 2. The Barracuda Web Security Gateway automatically listens for syslogs from that wireless AP and parses them to authenticate users that log in. 3. Configure your Wireless AP device to stream syslog data containing the authentication information collected to the Barracuda Web Security Gateway. Find instructions for your device:

Meru Ruckus Aerohive

How to Disable Wireless AP Integration

1. Go to the USER/GROUPS > Configuration page, and select None from the Access Point Provider drop-down. 2. The Barracuda Web Security Gateway will stop listening and accepting syslogs from any wireless APs. 3. If there are any users still logged in from the wireless AP, after disabling wireless AP integration, those users remain logged in to the Barracuda Web Security Gateway.

Specific Policies Applied to Groups of Users

When users authenticate to the wireless AP, the username and IP address of the user is forwarded to the Barracuda Web Security Gateway to provide the user a similar browsing experience regardless of the device being used, and without the need to for authenticating to multiple systems. User policies are applied by user name, IP address or group membership as described above, and user data is consolidated for reporting purposes.

How to Integrate the Aerohive Wireless AP With the Barracuda Web Security Gateway The Barracuda Web Security Gateway 310 and above running version 9.0 and above currently supports Aerohive wireless access points (wireless APs) using RADIUS authentication. After configuring the Barracuda Web Security Gateway as described in Wireless Access Point Integration, continue with the instructions in this article.

Reference Devices/Versions:

Aerohive AP230 802.11ac Wireless AP Version 6.4r1a Aerohive Networks HiveManager Online 6.4r1

To authenticate users connected to Aerohive access points, you must stream the syslog containing the authentication data to the Barracuda Web Security Gateway. To do so:

Step 1. Enable syslog streaming on the Aerohive AP

1. Log into the Aerohive Networks HiveManager. 2. Go to Configuration > Advanced Configuration > Management Services > Syslog Assignments.

3. Click New and configure syslog streaming: Syslog Server – Select the IP address of the Barracuda Web Security Gateway from the dropdown. Severity – Select Info from the dropdown. 4. Click Apply. 5. Click Save.

Barracuda Web Security Gateway Administrator's Guide - Page 210

Step 2. Add syslog configuration to Network Policy

After your syslog server is configured, it must be added to the Network Policy you are using for your access points.

1. In Aerohive management, select your network policy. 2. Continue to Configure interfaces and User Access under Additional Settings. Select the syslog server you just defined. 3. Continue to Configure and update devices. Select the specific wireless AP(s) to update, and then send the configuration change.

Step 3. Verify that the Barracuda Web Security Gateway is receiving the syslog data

1. Have a user authenticate against the wireless AP and generate some web traffic. 2. On the Barracuda Web Security Gateway, go to BASIC > Web Log and look for the username in the User column. This will display the authentication service used as you named it in the configuration and the username. For example: ldap0:user1

How to Integrate the Meru Wireless AP With the Barracuda Web Security Gateway

The Barracuda Web Security Gateway 310 and above running version 7.x and above currently supports the Meru and Ruckus wireless access points (wireless APs) using RADIUS authentication. After configuring the Barracuda Web Security Gateway as described in Wireless Access Point Integration With the Barracuda Web Security Gateway, continue with the instructions in this article.

To authenticate users connected to Meru access points, you must forward the syslog from the Meru controller containing the authentication data to the Barracuda Web Security Gateway. These instructions use the command line interface to set the destination for syslog stream.

Step 1. SSH to the Meru controller IP address and enter the following commands to set the remote syslog host:

meru1550cntrl(15)# configure terminal meru1550cntrl(15)(config)# syslog-host 10.1.0.221 meru1550cntrl(15)(config)# exit meru1550cntrl(15)# copy running-config startup-config

Step 2. Save the configuration, and verify the setting in the Meru controller web interface as shown in the image below.

Step 3. Verify that the Barracuda Web Security Gateway is receiving the syslog data

How to Integrate the Ruckus Wireless AP With the Barracuda Web Security Gateway The Barracuda Web Security Gateway 310 and above running version 7.x and above currently supports the Ruckus and Meru wireless access points (wireless APs) using RADIUS authentication. After configuring the Barracuda Web Security Gateway as described in Wireless Access Point Integration With the Barracuda Web Security Gateway, continue with the instructions in this article.

To authenticate users connected to Ruckus access points, you must stream the syslog containing the authentication data to the Barracuda Web Security Gateway. To do so:

Step 1. Enable Client Association in the Ruckus debug log settings.

1. Go to Administer > Diagnostics. 2. In the Debug Logs section, enable Client Association. 3. Click Apply.

Step 2. Enable Syslog Streaming on the Ruckus Wireless AP

1. Go to Configure > System Log Settings. 2. Click Enable reporting to remote syslog server. 3. Enter the IP address of the Barracuda Web Security Gateway.

4. Click Apply.

Step 3. Verify that the Barracuda Web Security Gateway is receiving the syslog data

Advanced Configuration

Virus Protection

By default, virus scanning is automatically enabled on the Barracuda Web Security Gateway, and the virus definitions are updated on a regular basis (hourly by default) using Energize Updates.

When virus scanning is enabled, all traffic processed by the Barracuda Web Security Gateway is scanned for viruses and any traffic that contains a virus is blocked. If you already have anti-virus software protecting your web traffic, you can turn off virus scanning on the Barracuda Web Security Gateway using the BASIC > Virus Checking page. Otherwise, it is recommended to leave this feature turned on. This feature includes the option to block encrypted archives such as zip, tar, and rar files that are password protected, as viruses. The maximum encrypted file/archive size that can be scanned and blocked is 10Mbytes.

With version 11.0 and higher, when a virus is detected by ATD or the enhanced virus checking engine, the user will be presented with a block page per the example below. Note that, unlike other block pages, this block page is not configurable in the Barracuda Web Security Gateway web interface.

Viruses detected by the basic virus scanning feature on the Barracuda Web Security Gateway (i.e. when Enable Virus Protection is set to Yes on the BASIC > Virus Checking page) will result in the block page customizable on the BLOCK/ACCEPT > Block Messages page.

Advanced Threat Detection

With version 11.0 and higher, the Barracuda Web Security Gateway provides subscription-based access to the Advanced Thread Detection (ATD) service to analyze web traffic for viruses in a separate, secured cloud environment. Beyond the basic Barracuda Web Security Gateway virus scanning, the ATD service detects new threats and determines whether to block scanned files that are found to be infected. Also configured on the BASIC > Virus Checking page. See Advanced Threat Protection Configuration for details.

Proxy Settings

Use the ADVANCED > Proxy page to configure proxy settings for peer proxies, headers, HTTP and HTTPS ports as well as exceptions to proxy authentication by source IP address, domain name, header pattern or destination IP address. Note that peer proxy only works with inline deployments - for details, see Deploying the Barracuda Web Security Gateway with a Peer Proxy.

Web Caching

Web caching on the Barracuda Web Security Gateway can accelerate web page downloads and also reduce traffic on the external network connections. For these reasons, it is recommended to keep web caching enabled. Use the ADVANCED > Caching page to enable or disable web caching, to clear the cache or to create exceptions for domains you don’t want the Barracuda Web Security Gateway to cache.

Advanced Threat Protection Configuration

The Barracuda Web Security Gateway leverages Advanced Threat Protection (ATP) to provide for safe use of online applications and tools without exposure to web-borne ransomware and other threats.

Traditional signature-based anti-virus solutions are no longer sufficient to defend against new breed of malware attacks. This has resulted in the emergence of heuristic-based anti-virus solutions and advanced threat protection solutions with sandboxing capabilities. Advanced Thread Protection (ATP) is a subscription-based service that detects and blocks advanced malware, zero-day exploits, and targeted attacks that are not detected by the Barracuda Web Security Gateway virus scanning features. The ATP service analyzes web traffic for viruses in a separate, secured cloud environment.

ATP Subscription

You can subscribe to the ATP service just as you do with Energize Updates. Your ATP subscription either expires when your Energize Updates subscription does, or before. In order to purchase an ATP subscription, you must have a valid Energize Updates subscription. Subscription status for ATP is shown on the BASIC > Dashboard page.

How to Get and Use ATP:

1. Subscribe by clicking on Click here to activate on the BASIC > Dashboard page as shown below.

2. Go to the BASIC > Virus Checking page. Set Enable Advanced Threat Protection (ATP) to Yes. You can also select No to disable ATP scanning while keeping your subscription active. 3. Configure scanned file types and MIME types as shown on the page. Click Help for details. 4. Click Save.

How ATP Works

ATP analyzes attachment files (based on file types you specify on the BASIC > Virus Checking page) in the Barracuda ATP cloud and assigns a risk score. Infected files are blocked by ATP when the service is enabled. An alert is sent to the Threat Alerts Email Address defined on the BA SIC > Administration page when:

A file reaches the user before the ATP scan is complete, and the file is then determined to be infected. The maximum encrypted file/archive size that can be scanned and blocked, 10Mbytes, is exceeded. In this case, the file is not scanned and will be delivered.

Additionally, when you subscribe to the ATP service, you can view infected traffic on the BASIC > ATP Log page. The log provides the option to manually export a file in CSV format.

ATP Statistics

You can view statistics on files scanned and determined to be infected by the ATP service on the DASHBOARD page.

Monitoring the System

The Barracuda Web Security Gateway incorporates hardware and software fail-safe mechanisms that are indicated via system alerts and logs. The powerful reporting engine provides a broad spectrum of web traffic statistics and user-level activity reports which can be created ad-hoc, emailed to administrators or sent to an FTP or SMB server. You can monitor multiple Barracuda Web Security Gateways using Barracuda Cloud Control (BCC), a centralized management web interface for managing, configuring and reporting on multiple devices from one central web console. These articles describe the tools and monitoring tasks you can use via the web interface and the front panel of the Barracuda Web Security Gateway to track system performance and configure system alerts.

In this Section

Basic Monitoring Tools How to Size the Barracuda Web Filter For Your Network Reporting With the Barracuda Web Security Gateway Version 11 and Above Reporting with the Barracuda Reporting Server Reporting Version 7 and Above How to Set Up Alerts and SNMP Monitoring How to Set Up Barracuda Cloud Control Syslog and the Barracuda Web Security Gateway Barracuda Web Security Gateway API Guide Troubleshooting

Basic Monitoring Tools

Performance statistics for the Barracuda Web Security Gateway are presented on the BASIC > Dashboard page for IT administrators to monitor the health of the system and to make sure traffic is flowing as expected. Web requests by users on the network are tracked and presented as raw data in the web logs as described below, but that data is also packaged and presented in an easy-to-read format in the reports module. In general, the reports listed on the BASIC > Reports page should serve the needs of both managers and IT administrators regarding user productivity, bandwidth usage, infection/malware detection and more. For more about the Barracuda Web Security Gateway reporting engine, see the Reporting article. For details about configuring and scheduling reports, see the online help in the BASIC > Reports page.

Viewing performance statistics

The BASIC > Dashboard page provides an overview of the health and performance of your Barracuda Web Security Gateway. You can create and customize the layout and content of multiple dashboards as described in How to Customize the Dashboard Page. The following statistics are included on the default Dashboard:

Filtering statistics (such as threats blocked by the filtering rules, blocked visits to known spyware websites, blocked downloads of spyware or viruses) for the past day and hour, as well as total statistics since installation (or last reset) of the Barracuda Web Security Gateway. Performance statistics, such as CPU temperature, throughput, system load and TCP connections. Statistics displayed in red signify that the value exceeds the normal threshold. Protection Status – The current Operating Mode of the Barracuda Web Security Gateway. Operating Mode is configured on the BASI C > IP Configuration page. Possible modes are: Active: Traffic is logged and policies are applied. Audit: In inline mode, traffic is logged only. Policies are not applied. In forward proxy deployment, traffic is logged and policies are applied, just like they are in Active mode. Safe: Note that this mode is systematically set if the system load on your Barracuda Web Security Gateway is excessive because either the maximum number of TCP connections allowed on your model is exceeded, or the reporting engine is processing a large volume of data. Safe mode cannot be triggered over the web interface and is not applicable if the Barracuda Web Security Gateway is deployed in WCCP configuration. In Safe mode the device will pass web traffic through without filtering and logging. The Barracuda Web Security Gateway will send a notification email to the System Alerts Email Address that is specified on the BASIC > Administration page indicating the reason the device is experiencing a load issue. If the number of current TCP connections and/or the load on the reporting engine returns to normal range, the Barracuda Web Security Gateway will resume Active mode; otherwise the device will remain in Safe mode and traffic will not be filtered or logged. At this point it is recommended that you place the Barracuda Web Security Gateway in Audit mode and troubleshoot the problem. For further assistance, please contact Barracuda Networks Technical Support. Throughput gauges the total volume of traffic that is passing through the Barracuda Web Security Gateway and is measured in Mb/s. TCP Connections indicates number of concurrent TCP connections used by the Barracuda Web Security Gateway to service Internet traffic. TCP Connection usage can be monitored while in Audit mode as well as in Active mode without affecting production traffic. A single user typically requires 1 to 1.5 active TCP connections; however, the peak number of TCP connections can significantly increase with heavy Web browsing or with bandwidth-intensive Internet applications such as voice, instant messaging (IM) or other streaming media applications. Cloud Control indicates whether or not this Barracuda Web Security Gateway is connected to the Barracuda Cloud Control (BCC) management tool. For general information about Barracuda Cloud Control, see Overview. For details about connecting the Barracuda Web Security Gateway to the BCC, see How to Set Up Barracuda Cloud Control. System Load represents an estimate of CPU and disk load on the system. It is not unusual for the load to reach 100%, especially when the incoming queue is large. 100% load for long periods of time indicates trouble in the system, especially if the incoming queue continues to increase in size. If the System Load exceeds 50% for more than 5 minutes, the Operating Mode will automatically shift to Safe mode (unless the Barracuda Web Security Gateway is deployed in WCCP configuration) and will pass traffic without filtering or logging until normal operation can be resumed. See the online help for the BASIC > Dashboard page for more information. Cache Hit Ratio indicates the percentage of requests handled by the cache. Subscription status for Energize Updates, Instant Replacement, and Premium Support. Lists of infected clients and blocked web requests. A set of bar graphs that illustrate an hourly breakdown of requests made by your users in the last 24 hours, and a set of bar graphs that illustrate a daily breakdown of requests made by your users in the last 30 days. Both sets of graphs illustrate the following data: Number of requests blocked Number of requests received Number of kilobytes per second used by the requests allowed Each bar graph is accompanied by two Top Ten lists: domains represented in the graph and web content categories represented in the graph. LAN, WAN and AUX port connection details are associated with icons in the Link Status section, displaying connectivity where applicable (version 6.0.1 and higher). Hover the mouse over the LAN icon, for example, to see LAN connection details (MAC address, IP address, throughput). If the AUX port is configured, the icon will be displayed with details for that port in addition to icons for either or both the WAN and LAN. On the Barracuda Web Security Gateway Vx, only the LAN port icon and details are displayed.

To customize one or more dashboards, displaying only the data that matters to the administrator, see How to Customize the Dashboard Page.

Logs for Web Traffic and Syslog

Web Traffic Log

The BASIC > Web Log page displays a list of system logs for your Barracuda Web Security Gateway. On a regular basis you should view the Web Log page to monitor the web and spyware traffic (both HTTP and non-HTTP) passing through your Barracuda Web Security Gateway. The page also has a button used to clear all traffic logs as needed. Use this page to view the following information about each entry in this log:

Date and time the Barracuda Web Security Gateway processed the request. IP address of the client that originated the request. IP address of the requested website or application For search engine requests, the search keyword(s) entered by the user Type of file contained in the request, as designated by the HTTP header. For a list of common MIME types, see the help page for the MIME Type Blocking feature. The user name or group that sent the request. The action taken by the Barracuda Web Security Gateway (Allowed, Detected, Warned, Monitored, Blocked). The reason the Barracuda Web Security Gateway performed the action. Detailed information about the actions. Number of bytes of data processed for this request.

You can perform the following operations on the Web Log page:

Apply filters to locate specific log entries Refresh to update the log. The most recent entry is at the top of the list. Clear the log to purge all the current entries. Export the displayed entries to a CSV file.

Application log

The BASIC > Application Log page displays the log of web application traffic blocked by the Barracuda Web Security Gateway. Note that the Barracuda Web Security Gateway Vx virtual machine does not block applications. Use this page to view the following information about each entry in this log:

Date and time the Barracuda Web Security Gateway blocked the request. IP address of the client that initiated the request. Name of the application that was blocked.

You can perform the following operations in the Application Log page:

Customize the appearance of the display Update the contents displayed in this page Clear the contents of the traffic log itself Filter the entries displayed Export the displayed entries to a CSV file

Using a Syslog Server to Centrally Monitor System Logs

Syslog is a standard UNIX/Linux tool for sending remote system logs and is available on all UNIX/Linux systems. The Barracuda Web Security Gateway provides syslog data for both web traffic and system events. Use the ADVANCED > Syslog page to specify servers to which the Barracuda Web Security Gateway sends each type of syslog data.

Syslog servers are also available for Windows platforms from a number of free and premium vendors. Barracuda Networks has tested with a Windows freeware syslog server from Kiwi Enterprises (www.kiwisyslog.com). Barracuda Networks makes no guarantees that your Barracuda Web Security Gateway will be completely compatible with this syslog server. Note that syslog support is not available on the Barracuda Web Security Gateway 210.

For details about syslog output from the Barracuda Web Security Gateway, see Syslog and the Barracuda Web Security Gateway.

Warned Activity List

The BASIC > Warned Activity page displays the list of all warned activity that is in effect for the client machines protected by the Barracuda Web Security Gateway system. Use this page to view the following information about each entry in this log: Date and time that the warned activity was triggered.

IP address of the client machine that triggered the warned activity. Username that triggered the warned activity. This field indicates whether the user account is from the local, LDAP or NTLM realm. The URL that the user was attempting to access when the warned activity triggered. The domain names that triggered the warned activity. The Web content category that triggered the warned activity.

You can perform the following operations in the Warned Activity page:

View details about a warned activity Clear all warned activity

A warned activity remains in effect until it times out (as configured in the BLOCK/ACCEPT > Configuration page) or until it is explicitly removed by the Administrator (using the BASIC > Warned Activity page). If the user attempts to access the same website after a warned activity times out or is deleted, the user must click the Proceed button to re-acknowledge the warning and then access the website again.

List of Infected Clients

The BASIC > Infection Activity page displays outbound activity monitored by the Barracuda Web Security Gateway to sites/IP addresses that are known to be malicious, and displays a list of clients in the network that are infected with a virus or with spyware. Check this page for activity by client hostname or IP address to determine if further investigation should be performed on the client. The data in the log includes:

Spyware – Names of the threats blocked by the Barracuda Web Security Gateway. Count – Number of times that the Barracuda Web Security Gateway blocked this threat. Last Seen – Date and time this threat type was last detected on this client. Port – The port over which the infection was detected.

Remote Devices Tracking by Time and Location

(version 6.0.1. and higher)

The Barracuda Web Security Gateway maintains a log of remote user and mobile devices seen by the Barracuda Web Security Agent (WSA) and the Barracuda Safe Browser. Logged data includes the date, time and location from which a remote user logged in or a mobile device was synchronized with Barracuda Web Security Gateway settings. See the ADVANCED > Remote Devices page to view and configure. Logged fields include:

Username – Username created for the device user login. Domain – Domain the user is logged into Device Name – Name given to the mobile device for identification Device Type – Mobile device type, for example: iPad, iPhone, etc. IP Address – IP address of the mobile device Location – GPS coordinates of the mobile device Last Seen – Date and time of the last user login or device synchronization with the Barracuda Web Security Gateway

Task Manager

The ADVANCED > Task Manager page provides a list of system tasks that are in the process of being performed and also displays any errors encountered when performing these tasks. Some of the tasks that the Barracuda Web Security Gateway tracks include:

Linked management setup Configuration restoration

If a task takes a long time to complete, you can click Cancel next to the task name and then run the task at a later time when the system is less busy. The Task Errors section will list an error until you manually remove it from the list. Note that the errors are not phased out over time.

Audit Log of Configuration Changes The BASIC > Audit Log page displays updates to the configuration settings of the Barracuda Web Security Gateway in conjunction with Role-ba sed Administration. This log provides the following information:

Date and time the Barracuda Web Security Gateway processed the operation. The name of the user that did the operation. The role assigned to the user that did the operation. The action performed by the user that did the operation: add- Added a value for a field in the configuration. set - Set a value for a field in the configuration. del - Deleted a value for a field in the configuration. The scope, or area of the Barracuda Web Security Gateway affected by the operation: global - Applies to global level variables in the configuration. domain - Applies to a variable associated with a particular domain. user - Applies to a particular Barracuda Web Security Gateway user account. policy - Operation was done to a variable for which you can select a Policy of either Authenticated or Unauthenticated users. For example, BLOCK/ACCEPT > Content Filters, or BLOCK/ACCEPT > Applications. Detailed information about the operation. Which configuration variable affected by the operation, if any. Original value before the operation Changed value after the operation.

Log data can be exported to CSV file, and the rate of data streaming to the log can be adjusted.

How to Customize the Dashboard Page

This feature is available on the Barracuda Web Security Gateway 610 and above.

The BASIC > Dashboard page of the Barracuda Web Security Gateway provides overall performance statistics for the Barracuda Web Security Gateway for IT administrators to monitor the health of the system and to make sure traffic is flowing as expected. However, you might want to customize and limit or change the content displayed on the Dashboard. You can create multiple custom dashboards by clicking the Manage Dashboards link at the top of the page:

After you create one or more customized dashboards, clicking the Show Dashboards link displays links to all other dashboards.

Example: Create a dashboard to show web traffic related to social media activity in the Marketing department.

1. Click Manage Dashboards on the BASIC > Dashboard page. 2. In the Manage Dashboards window, name the dashboard Social Media Activity. 3. Give the dashboard a Description of Facebook, Twitter and Gaming Activities. 4. Choose Marketing for the LDAP Group. 5. For Dashboard Elements, you might choose: Top 10 Facebook Users Top 10 Twitter Users Top 10 Users on Social Networking Sites Top 10 Users on Gaming Sites

As you select each dashboard element, which is essentially a set of report data, you can drag and drop these elements where you want them to appear in the screen layout. For details on designing your custom dashboard, click Help on the BASIC > Dashboard page to view the help page.

How to Use the Barracuda Malware Removal Tool The Barracuda Malware Removal tool is no longer provided with the Barracuda Web Security Gateway.

How to Size the Barracuda Web Filter For Your Network

Whether purchasing your first Barracuda Web Filter or making a decision to expand your system, this article will guide you in evaluating your specific network traffic filtering needs. The Barracuda Web Filter has a built-in SNMP trap agent which can send alerts to the administrator when certain performance metrics are exceeded. As shown in this article, the agent can also be used to measure loads and throughput on the Barracuda Web Filter in your network, informing you as to whether the unit is properly sized to the network traffic needs. T

You should have a basic understanding of SNMP monitoring tools before using this guide.

Step 1. Configure SNMP on the Barracuda Web Filter

1. Log into the Barracuda Web Filter web interface as the administrator:

Use Username: admin Password: admin 2. Go to the BASIC > Administration page and set Enable SNMP Agent to Yes in the SNMP Manager section. See the screenshot below. 3. Click Help in the page for instructions on configuring SNMP.

Important For security purposes, use the Allowed SNMP IP/Range to limit which IP address(es) are allowed to connect to the Barracuda Web Filter via SNMP.

4. Click Save Changes on the page after enabling and configuring the SNMP agent.

Step 2. Monitor System Metrics to Size the Barracuda Web Filter

Use the following tools with your SNMP monitor to determine your system performance.

Step 2a. Estimate CPU Load

This measurement helps to understand the overall performance of the Barracuda Web Filter. Sizing for CPU load means ensuring that the CPU is queuing up jobs beyond 1.5 jobs per core. (1min, 5min, 15min) load / # of cores;

Example: 96 / 48 cores on a Barracuda Web Filter 1010 = 2. This ration of jobs to number of cores exceeds 1.5 and, therefore, represents a taxing level for the system.

To get this load information with your SNMP monitor, use these OIDs:

1.3.6.1.4.1.2021.10.1.3.1 (1min) 1.3.6.1.4.1.2021.10.1.3.2 (5min) 1.3.6.1.4.1.2021.10.1.3.3 (15min)

Step 2b. Estimate Throughput

Measure the current flow of traffic that is passing through the Barracuda Web Filter, in Mbytes/second. With your SNMP monitor, use these OIDs:

1.3.6.1.4.1.20632.3.1.3 (current throughput) 1.3.6.1.4.1.20632.3.2.3 (high throughput)

Examples:

Model Throughput

Barracuda Web Filter 1010 2000mbps (2gb)

Barracuda Web Filter 610Vx* 150mbps

*Note that, since the 610Vx is a virtual machine, throughput numbers will depend on the computer resources available to your hypervisor.

Step 2c. Estimate the number of TCP Connections

Measure the number of concurrent TCP connections used by the Barracuda Web Filter to service Internet traffic. Use this metric to size your Barracuda Web Filter while Operating Mode is set to Audit (as opposed to Active mode) to avoid affecting production traffic. With your SNMP monitor, use these OIDs:

1.3.6.1.4.1.20632.3.1.2 (Current) 1.3.6.1.4.1.20632.3.2.2 (High)

Examples:

Model TCP connections

Barracuda Web Filter 1010 307200

Barracuda Web Filter 610Vx* 8000

*Note that, since the 610Vx is a virtual machine, the number of current or high TCP connections will depend on your hypervisor deployment.

Reporting With the Barracuda Web Security Gateway Version 11 and Above

This article addresses the built-in reporting feature of the Barracuda Web Security Gateway, configurable on the BASIC > Reports page. Note that the Barracuda Web Security Gateway stores approximately 6 months worth of reporting data, and this may vary with the amount of internet traffic.

If you are running the Barracuda Web Security Gateway version 11.0 and higher, you may also purchase and connect a Barracuda Reporting Server. The Barracuda Reporting Server generates more accurate, customizable reports that offloads processing from the Barracuda Web Security Gateway, resulting in performance gains in filtering capacity. You can also connect multiple Barracuda Web Security Gateways to have an aggregate view of reporting data on the Barracuda Reporting Server.

See the Barracuda Reporting Server for more information about the product. If you have purchased a Barracuda Reporting Server and are ready to connect it to the Barracuda Web Security Gateway, see Reporting with the Barracuda Reporting Server.

For reporting purposes, Barracuda recommends a maximum Active Directory (AD) group size of 1000 users.

Use the BASIC > Reports page to choose from more than 80 different system reports that can help you keep track of activity performed by the Barracuda Web Security Gateway. You can either generate a system report on-demand or configure the Barracuda Web Security Gateway to automatically generate the system reports on an hourly, daily, weekly, or monthly basis and email the reports to specific email addresses or send them to an FTP or SMB server.

Important Some reports may contain URLs that are on block lists. If your Barracuda Web Security Gateway is sending reports via email through an email security product, such as the Barracuda Email Security Gateway or Barracuda Essentials for Email Security service, make sure to add the IP address of the Barracuda Web Security Gateway to the IP and Port Exemptions list on the BLOCK/ACCEPT > IP Block/Exempt page. This prevents bad URLs from causing the emailed report to be blocked. If you are sending reports through another spam filtering device or service, make sure to specifically allow the IP address of the Barracuda Web Security Gateway on that solution.

Reports can be anchored on user activity, content, or bandwidth usage and are grouped as follows:

For Human Resources, Teachers, and Managers

These reports are user-friendly, easy-to-read, and provide the following critical information:

Productivity reports reflecting user activity with social networking and other applications; for example: Top Users by Browse Time on Gaming Sites Top Social Networking Domains by Requests – May determine which domains you want to block, warn, or monitor Top YouTube Users by Bandwidth Top Facebook Users by Browse Time Top Users by Browse Time on Social Networking Sites Safety and Liability reports; for example: Top Users by Requests to Intolerance and Hate Sites Top Users by Requests to Anonymizer Sites. An anonymizer is a tool that attempts to make activity on the Internet untraceable. It is a proxy server computer that acts as an intermediary and privacy shield between a client computer and the rest of the Internet, hiding the client computer's identity (IP address). Suspicious Keywords by Users – For detection of possible cyberbullying, or mention of weapons or terrorism. See the BLOCK/A CCEPT > Web App Monitor page for details.

For IT and System Administrators

These report types show infection activity, blocked virus downloads, bandwidth usage by time frame, and many other system performance-related reports, such as:

Infection Activity Malware Blocks – IP addresses from which requests were made to known spyware sites. Virus Blocks – A list of blocked virus downloads during the specified time frame. Web Activity Session time or browse time, by hour, or by time of day. Popular IP addresses to which requests were made. Categories (e.g., adult, gaming, leisure) by bandwidth, number of requests, browse time, and more. Users by session time, browse time, bandwidth, and more. Administrative Audit Reports for the Web Security Gateway track logins and logouts to the web interface, as well as changes to the configuration by role. Temporary Access Request Log – Log of activity by teachers who have been given credentials to request temporary access for their students to domains that are typically regulated by system administrators. See Temporary Access for Education.

Temporary Access Requests by Domains, Users, or Categories. Network Activity TCP Connection Usage Daily Bandwidth Web Requests Log Summary Internet, Network, and User activity summaries Total Usage

For a complete list and detailed descriptions of the system reports, see the online help on the BASIC > Reports page.

Accurately Reporting User Browsing Times

Embedded web content is intelligently detected by the Barracuda Web Security Gateway to maximize reporting accuracy. For example, a site such as cnn.com embeds requests to Facebook, Twitter, and other social networks. While a user visiting the news site might not explicitly click on any of the embedded links, the embedded content still makes periodic web requests. On a report, this could appear as if the user visited CNN, Facebook, and Twitter and spent 15 minutes on each site.

While this is technically accurate, it can misrepresent the user’s actions on reports that are reviewed by the Human Resources department, for example. In most cases, the Barracuda Web Security Gateway can make the distinction between such embedded requests – also known as “referred requests” – and actual user visits, but there are some limitations due to the behavior of some client applications. Consequently, reports reflect estimates of actual user browse and session times.

Important In calculating browse times, the Barracuda Web Security Gateway uses the HTTP referrer (sic) header to make the distinction between embedded requests and user visits. However, it is important to note that there are various client applications that limit the accuracy of calculating browse times. Here are several examples:

Javascript that downloads assets from another site and may not set the referral; iOS apps that request web assets and do not set the referral; Android apps that request web assets place the app package name in the referral.

Session Time Versus Browse Time

Session time is the time calculated for each browsing session generated, with an idle timeout value of about 3 minutes. So if, for example, a user visits cnn.com, but does not click anything else for more than 3 minutes, that is one session of 3 minutes for that user on cnn.com. If the user does click around cnn.com within the 3 minute time frame, the session continues to increase in length until there is a 3-minute idle time.

Browse time as shown in reports is the sum of all estimated session times in a particular grouping (domain, category, user, etc).

Additional Notes on Reporting

Maximum AD Group Size: For reporting purposes, Barracuda recommends a maximum Active Directory (AD) group size of 1000 users. Bar Graphs versus Line Graphs: When creating HTML reports: bar graphs are used for graphs containing 50 records or fewer. line graphs are used for graphs containing over 50 records Clearing Traffic Logs: Navigate to the BASIC > Web Log page and click Clear Log.

Reporting with the Barracuda Reporting Server

If you are running the Barracuda Web Security Gateway version 11.0 and higher, you have the option to purchase and use a Barra cuda Reporting Server appliance for a faster, more accurate reporting system that can offload processing from the Barracuda Web Security Gateway. The result is better overall system performance, and, if you are clustering multiple Barracuda Web Security Gateways, this solution provides an aggregate view of reporting data on one system. See the Barracuda Reporting Server for more information about the product.

Just like the Barracuda Web Security Gateway reporting feature, the Barracuda Reporting Server lets you choose from more than 80 system reports that can help you track activity performed by the Barracuda Web Security Gateway. You can either generate a system report on-demand or configure the Barracuda Reporting Server to automatically generate the system reports on an hourly, daily, weekly, or monthly basis. You can configure the system to email the reports to specific email addresses or send them to an FTP or SMB server (see Working with External Servers f or more information).

Important Some reports may contain URLs that are on block lists. If your Barracuda Web Security Gateway is sending reports via email through an email security product such as the Barracuda Email Security Gateway or Barracuda Essentials for Email Security service, make sure to add the IP address of the Barracuda Web Security Gateway to the IP and Port Exemptions list on the BLOCK/ACCEPT > IP Block/Exempt page. This prevents bad URLs from causing the emailed report to be blocked. If you are sending reports through another spam filtering device or service, make sure to specifically allow the IP address of the Barracuda Web Security Gateway on that solution.

How to Connect to the Barracuda Reporting Server

For details about deployment of the Barracuda Reporting Server, see the Barracuda Reporting Server Deployment guide.

To enable the Barracuda Reporting Server, do the following:

1. Configure the Barracuda Reporting Server. You will create a Shared Secret that you then enter in the Barracuda Web Security Gateway on the BASIC > Administration page. 2. Log in to the Barracuda Web Security Gateway as admin. 3. Go to the BASIC > Administration page as shown below. In the Barracuda Reporting Server section, do the following: a. Set Connect to Barracuda Reporting Server to Yes. b. Enter the IP Address of the Barracuda Reporting Server to which you want to connect. c. Enter the Shared Secret you created in the Barracuda Reporting Server.

d. Click Save. If the Barracuda Reporting Server you specified is not online or is otherwise unreachable, you receive the following error message:

When you successfully connect the Barracuda Web Security Gateway to the Barracuda Reporting Server, you receive the green success message as shown below. You can now use the Barracuda Reporting Server to create reports.

Barracuda Web Security Gateway Administrator's Guide - Page 227

Note: You will no longer be able to access the BASIC > Reports page on the Barracuda Web Security Gateway. If you click on Reports from the BASIC tab, this message displays:

Click OK to view the BASIC > Dashboard page of the Barracuda Web Security Gateway. From this point forward, to work with reports, log into the Barracuda Reporting Server.

Disconnecting from the Barracuda Reporting Server

To disconnect from the Barracuda Reporting Server and resume using the Barracuda Web Security Gateway for reporting:

1. Log in to the Barracuda Web Security Gateway as admin. 2. Go to the BASIC > Administration page. In the Barracuda Reporting Server section: a. Set Connect to Barracuda Reporting Server to No. b. Click Save. The Barracuda Web Security Gateway disconnects from the Barracuda Reporting Server. 3. Go to the BASIC > Reports page and configure reports.

Migrating Reports to the Barracuda Reporting Server

When you connect one or more Barracuda Web Security Gateway devices to the Barracuda Reporting Server, your scheduled reports in the connected devices are automatically migrated to the Barracuda Reporting Server. The migration process begins when you enter the Barracuda Reporting Server connection information within Barracuda Web Security Gateway, as described in Reporting With the Barracuda Web Security Gateway Version 11 and Above.

All Barracuda Web Security Gateway reports remain on the device, even after it is connected to the Barracuda Reporting Server. Reports created with the Barracuda Reporting Server include data from the time the report is migrated to the Barracuda Reporting Server. Historical data, gathered by the Barracuda Web Security Gateway before its connection to the Barracuda Reporting Server, is not migrated to the Barracuda Reporting Server.

Migrating Scheduled Reports to the Barracuda Reporting Server

Step 1: Viewing Migrated Reports

To complete the migration process:

1. In the Barracuda Reporting Server, navigate to the BASIC > Administration page. 2. In the Connected Devices section, locate the newly connected device and click View Migrated Reports. 3. The Migrated Scheduled Reports dialog appears. It displays the Report Name, Frequency, and Time Frame to help you identify the reports. The Migration Status column shows whether the report was migrated successfully. Occasionally, errors occur during migration. 4. For reports showing an error, click View Details to see the issues with migrating that report.

No Migrated Reports

The are some cases in which the Migrated Scheduled Reports dialog might not display any reports. A message informs you why there are no reports to display.

For details, refer to Troubleshooting.

Step 2: Verifying and Enabling Migrated Reports

After migration is complete, you must enable the migrated reports. This is an opportunity to double-check the report information for errors before the reports are generated.

To enable migrated reports:

1. Navigate to the REPORTS page. 2. In the Scheduled Reports section at the bottom of the page, locate a newly migrated report. It will display as Disabled. 3. Click Edit for the migrated report. Scroll to the top of the page and verify that the information is correct for the migrated reports. 4. In the Schedule Report section, select Enabled, then click Save Changes in the top right corner. In the Scheduled Reports section, the report appears with the status of Enabled.

Disconnecting Devices and Associated Reports

If you choose to disconnect a Barracuda Web Security Gateway from the Barracuda Reporting Server, the reports you originally created on the B arracuda Web Security Gateway are re-enabled with their original settings. You can again manage reports within the Barracuda Web Security Gateway. Any updates you might have made to those original reports or any new reports you created in Barracuda Reporting Server are not migrated back to the disconnected Web Security Gateway.

If you choose to disconnect the Barracuda Web Security Gateway from the Barracuda Reporting Server, reports created or migrated to Barracuda Reporting Server, and report modifications made within Barracuda Reporting Server, remain within Barracuda Reporting Server and can continue to be managed there.

If you have scheduled reports on the Barracuda Reporting Server, those reports continue to be sent out per the schedule you configured, even after you disconnect the Barracuda Web Security Gateway. If you want to disable scheduled reports, you must do so manually on the Barracuda Reporting Server.

Reporting Version 7 and Above

Some of the reports and features noted in this article are specific to the Barracuda Web Security Gateway version 7 and higher. No te: For reporting purposes, Barracuda recommends a maximum Active Directory (AD) group size of 1000 users.

Report Set Grouped by Use Cases

Use the BASIC > Reports page to choose from more than 50 different system reports that can help you keep track of activity performed by the Barracuda Web Security Gateway. You can either generate a system report on-demand or configure the Barracuda Web Security Gateway to automatically generate the system reports on an hourly, daily, weekly or monthly basis and email the reports to specific email addresses or send them to an FTP or SMB server.

Important Some reports may contain URLs that are on block lists. If your Barracuda Web Security Gateway is sending reports via email through a Barracuda Email Security Gateway, make sure to add the IP address of the Barracuda Web Security Gateway to the IP and Port Exemptions list on the BLOCK/ACCEPT > IP Block/Exempt page to prevent bad URLs from causing the emailed report to be blocked. If you are sending reports through another spam filtering device or service, make sure to whitelist the IP address of the Barracuda Web Security Gateway on that solution.

Reports can be anchored on user activity, content or bandwidth usage and, in version 7.0 and higher, are grouped as follows:

For Human Resources, Teachers and Managers

These reports are user friendly, easy to read and provide the following critical information:

Productivity reports reflecting user activity with social networking and other applications; for example: Top Users by Browse Time on Gaming Sites Top Social Networking Domains by Requests - may determine which domains you want to block, warn or monitor Top YouTube Users by Bandwidth Top Facebook Users by Browse Time Top Users by Browse Time on Social Networking Sites ... and many more Safety and Liability reports; for example: Top Users by Requests to Intolerance and Hate Sites Top Users by Requests to Anonymizer Sites - An anonymizer is a tool that attempts to make activity on the Internet untraceable. It is a proxy server computer that acts as an intermediary and privacy shield between a client computer and the rest of the Internet, hiding the client computer's identity (IP address). Suspicious Keywords by Users - for detection of possible cyberbullying, mention of weapons,terrorism. See the BLOCK/ACCEP T > Web App Monitor page for details.

For IT, system administrators

These report types show infection activity, blocked virus downloads, bandwidth usage by time frame and many other system performance-related reports, such as:

Infection Activity Malware Blocks – IP addresses from which requests were made to known spyware sites. Virus Blocks – A list of blocked virus downloads during the specified time frame. Web Activity Session time, browse time by hour or time of day. Popular IP addresses to which requests were made. Categories (i.e. adult, gaming, leisure, etc.) by bandwidth, number of requests, browse time. Users by session time, browse time. Administrative Audit Log for tracking logins and logouts to the web interface, as well as changes to the configuration by role. Temporary Access Request Log – Log of activity by teachers who have been given credentials to request temporary access for their students to domains that are typically regulated by system administrators. See Temporary Access for Education. Temporary Access Requests by Domains, Users or Categories. Network Activity TCP Connection Usage Daily Bandwidth Web Requests Log Summary Internet, Network and User activity summaries Total Usage

For a complete list and detailed descriptions of the system reports, see the online help for the BASIC > Reports page.

Accurately Reporting User Browsing Times

While this is technically accurate, it can misrepresent the user’s actions on reports that are reviewed by the Human Resources department, for example. The Barracuda Web Security Gateway can make the distinction between such embedded requests – also known as “referred requests” – and actual user visits in most cases, but there are some limitations due to the behavior of some client applications. Consequently, reports reflect estimates of actual user browse and session times.

Important In calculating browse times, the Barracuda Web Security Gateway uses the HTTP refererr (sic) header to make the distinction between embedded requests and user visits. However, it is important to note that there are various client applications that limit the accuracy of calculating browse times. Here are several examples:

Javascript that downloads assets from another site and may not set referral; iOS apps that request web assets and do not set the referral; Android apps that request web assets place the app package name in the referral.

Session Time Versus Browse Time

Browse time as shown in reports is the sum of all estimated session times in a particular grouping (domain, category, user, etc).

Additional Notes on Reporting

Maximum AD Group Size: For reporting purposes, Barracuda recommends a maximum Active Directory (AD) group size of 1000 users. Bar Graph versus Line Graph: When creating HTML reports with graphs which contain more than 50 records, a line graph is displayed. For 50 records or less, a bar graph is displayed. To Clear Traffic Logs: See the BASIC > Web Log page.

How to Set Up Alerts and SNMP Monitoring

Alerts and Notifications

Emailed System Alerts

Use the BASIC > Administration page to configure the Barracuda Web Security Gateway to automatically email system alerts to the email addresses you specify. System alerts notify you when:

Your Energize Update subscription is about to expire New virus definitions are available New firmware updates are available Your system is low on disk space The Barracuda Web Security Gateway Operating Mode changes to Safe Mode. Threat Alerts

When any virus downloads or spyware downloads are detected in the HTTP data path, threat alerts can be sent to the email address(es) you specify in the Email Notifications section of the BASIC > Administration page.

Setting up SNMP Query, Alerts and Traps

While the Barracuda Web Security Gateway will send email alerts to the System Alerts Email Address as specified on the BASIC > Administration page, these alerts are limited and do not include latency, inqueue sizes, and other system health information. To monitor more specific information on a Barracuda Web Security Gateway, Barracuda Networks recommends using SNMP monitoring with an SNMP server. The Barracuda Web Security Gateway 410 and higher offers the ability to monitor various settings via SNMP alerts or traps, including system statistics such as:

System Load Averages (1m/5m/15m) Memory Utilization System Uptime Raid Status CPU idle times

To query the Barracuda Web Security Gateway for these statistics via SNMP, you must do the following in the SNMP Manager section of the BA SIC > Administration page:

1. Set Enable SNMP to Yes. 2. Enter the SNMP Community String. 3. Select the SNMP Version. The Barracuda Web Security Gateway supports both SNMP version v2c and v3. Select version v3 for more secure transmission. Version v3 provides the following options for additional security (make sure that the settings you select are supported by your SNMP monitor): - Authentication methods MD5 or SHA, where SHA is the more secure method. - Encryption methods DES or AES, where AES is the more secure method. 4. Enter the IP address of the server that will be making the SNMP connection in the Allowed SNMP and API IP/Range section of the page. IP addresses entered in this field are allowed to access the Barracuda Web Security Gateway via SNMP queries to retrieve error information, or via the API to configure the device.

You can configure SNMP traps by listing one or more IP addresses to which the Barracuda Web Security Gateway has access for sending SNMP traps as configured by a client.

SNMP MIBs

Click to download the Barracuda Web Security Gateway SNMP MIB and the Barracuda Reference MIB. You can monitor objects included in these MIBs either from custom scripts or from your SNMP monitor.

Barracuda Reference MIB Missing the language English in this article! Please add the language, otherwise this article can not be displayed properly.

Barracuda Web Security Gateway SNMP MIB You can monitor objects included in this MIB either from custom scripts or from your SNMP monitor. See also Barracuda Reference MIB.

Barracuda-SPYWARE DEFINITIONS ::=BEGIN

IMPORTS

MODULE-IDENTITY, OBJECT-TYPE, INTEGER

FROM SNMPv2-SMI

barracuda

FROM Barracuda-REF;

bspyware MODULE-IDENTITY

LAST-UPDATED "201011040000Z"

ORGANIZATION "Barracuda Networks, Inc."

CONTACT-INFO

Barracuda Networks Inc.

3175 S. Winchester Blvd.

Campbell, CA 95008

DESCRIPTION

Barracuda Web Filter MIB.

Provides:

Objects:

* 1.3.6.1.4.1.20632.3.1.2 -- ActiveTCPConnections

* 1.3.6.1.4.1.20632.3.1.3 -- Throughput

* 1.3.6.1.4.1.20632.3.1.4 -- PolicyBlocks

* 1.3.6.1.4.1.20632.3.1.5 -- SpywareWebHitBlocks

* 1.3.6.1.4.1.20632.3.1.6 -- SpywareDownloadBlock

* 1.3.6.1.4.1.20632.3.1.7 -- VirusDownloadBlock

* 1.3.6.1.4.1.20632.3.1.8 -- SpywareProtocolBlocks

* 1.3.6.1.4.1.20632.3.1.9 -- HTTPTrafficAllowed

* 1.3.6.1.4.1.20632.3.1.10 -- system

* 1.3.6.1.4.1.20632.3.1.10.1 -- cpuFanSpeed

* 1.3.6.1.4.1.20632.3.1.10.2 -- systemFanSpeed

* 1.3.6.1.4.1.20632.3.1.10.3 -- cpuTemperature

* 1.3.6.1.4.1.20632.3.1.10.4 -- systemTemperature

* 1.3.6.1.4.1.20632.3.1.10.5 -- firmwareStorage

* 1.3.6.1.4.1.20632.3.1.10.6 -- logStorage

* 1.3.6.1.4.1.20632.3.1.11 -- SystemUpTime

Traps:

* 1.3.6.1.4.1.20632.3.2 -- traps

* 1.3.6.1.4.1.20632.3.2.2 -- ActiveTCPConnectionsHigh

* 1.3.6.1.4.1.20632.3.2.3 -- ThroughputHigh

* 1.3.6.1.4.1.20632.3.2.4 -- cpuTempHigh

* 1.3.6.1.4.1.20632.3.2.5 -- sysTempHigh

* 1.3.6.1.4.1.20632.3.2.6 -- cpuFanDead

* 1.3.6.1.4.1.20632.3.2.7 -- sysFanDead

* 1.3.6.1.4.1.20632.3.2.8 -- firmwareStorageHigh

* 1.3.6.1.4.1.20632.3.2.9 -- logStorageHigh

* 1.3.6.1.4.1.20632.3.2.10 -- lanStatus

* 1.3.6.1.4.1.20632.3.2.11 -- wanStatus

::= { barracuda 3 }

-- Objects

ActiveTCPConnections OBJECT-TYPE

SYNTAX INTEGER

MAX-ACCESS read-only

STATUS current

DESCRIPTION

"Web Filter active tcp connections."

::= { bspyware 2 }

Throughput OBJECT-TYPE

SYNTAX INTEGER

MAX-ACCESS read-only

STATUS current

DESCRIPTION

"Web Filter throughput."

::= { bspyware 3 }

PolicyBlocks OBJECT-TYPE

SYNTAX INTEGER

MAX-ACCESS read-only

STATUS current

DESCRIPTION

"Web Filter policy blocks"

::= { bspyware 4 }

SpywareWebHitBlocks OBJECT-TYPE

SYNTAX INTEGER

MAX-ACCESS read-only

STATUS current

DESCRIPTION

"Web Filter spyware web hit blocks"

::= { bspyware 5 }

SpywareDownloadBlock OBJECT-TYPE

SYNTAX INTEGER

MAX-ACCESS read-only

STATUS current

DESCRIPTION

"Web Filter spyware download block"

::= { bspyware 6 }

VirusDownloadBlock OBJECT-TYPE

SYNTAX INTEGER

MAX-ACCESS read-only

STATUS current

DESCRIPTION

"Web Filter virus download block"

::= { bspyware 7 }

SpywareProtocolBlock OBJECT-TYPE

SYNTAX INTEGER

MAX-ACCESS read-only

STATUS current

DESCRIPTION

"Web Filter spyware protocol block"

::= { bspyware 8 }

HTTPTrafficAllowed OBJECT-TYPE

SYNTAX INTEGER

MAX-ACCESS read-only

STATUS current

DESCRIPTION

"Web Filter HTTP traffic allowed"

::= { bspyware 9 }

system OBJECT-GROUP

OBJECTS {

cpuFanSpeed,

systemFanSpeed,

cpuTemperature,

systemTemperature,

logStorage,

firmwareStorage

}

STATUS current

DESCRIPTION

"System parameters."

::= { bspyware 10 }

cpuFanSpeed OBJECT-TYPE

SYNTAX Integer32

MAX-ACCESS read-only

STATUS current

DESCRIPTION

"CPU fan speed in RPM."

::= { system 1 }

systemFanSpeed OBJECT-TYPE

SYNTAX Integer32

MAX-ACCESS read-only

STATUS current

DESCRIPTION

"System fan speed in RPM."

::= { system 2 }

cpuTemperature OBJECT-TYPE

SYNTAX Integer32

MAX-ACCESS read-only

STATUS current

DESCRIPTION

"CPU temperature in degrees Celsius."

::= { system 3 }

systemTemperature OBJECT-TYPE

SYNTAX Integer32

MAX-ACCESS read-only

STATUS current

DESCRIPTION

"CPU temperature in degrees Celsius."

::= { system 4 }

firmwareStorage OBJECT-TYPE

SYNTAX Integer32

MAX-ACCESS read-only

STATUS current

DESCRIPTION

"Firware storage utilization in percentage."

::= { system 5 }

logStorage OBJECT-TYPE

SYNTAX Integer32

MAX-ACCESS read-only

STATUS current

DESCRIPTION

"Log storage utilization in percentage."

::= { system 6 }

SystemUpTime OBJECT-TYPE

SYNTAX INTEGER

MAX-ACCESS read-only

STATUS current

DESCRIPTION

"Web Filter system uptime."

::= { bspyware 11 }

-- Traps

bspywaretraps OBJECT IDENTIFIER ::= { bspyware 2 }

ActiveTCPConnectionsHigh NOTIFICATION-TYPE

STATUS current

DESCRIPTION

"Number of active tcp connections are high than threshold."

::= { bspywaretraps 2 }

ThroughputHigh NOTIFICATION-TYPE

STATUS current

DESCRIPTION

"Throughput is high."

::= { bspywaretraps 3 }

cpuTempHigh NOTIFICATION-TYPE

STATUS current

DESCRIPTION

"CPU temperature exceeded its threshold."

::= { bspywaretraps 4 }

sysTempHigh NOTIFICATION-TYPE

STATUS current

DESCRIPTION

"System temperature exceeded its threshold."

::= { bspywaretraps 5 }

cpuFanDead NOTIFICATION-TYPE

STATUS current

DESCRIPTION

"CPU fan is dead."

::= { bspywaretraps 6 }

sysFanDead NOTIFICATION-TYPE

STATUS current

DESCRIPTION

"System fan is dead."

::= { bspywaretraps 7 }

firmwareStorageHigh NOTIFICATION-TYPE

STATUS current

DESCRIPTION

"Firmware storage exceeded its threshold."

::= { bspywaretraps 8 }

logStorageHigh NOTIFICATION-TYPE

STATUS current

DESCRIPTION

"Log storage utilization exceeded its threshold."

::= { bspywaretraps 9 }

lanStatus NOTIFICATION-TYPE

STATUS current

DESCRIPTION

"Current LAN Status for web filter."

::= { bspywaretraps 10 }

wanStatus NOTIFICATION-TYPE

STATUS current

DESCRIPTION

"Current WAN Status for web filter."

::= { bspywaretraps 11 }

END

How to Set Up Barracuda Cloud Control

Barracuda Cloud Control enables administrators to manage, monitor and configure multiple Barracuda Web Security Gateways (firmware version 4.3 and higher) at one time from one console. The same tabbed pages are available on Barracuda Cloud Control for managing all aspects of your Barracuda Web Security Gateway configuration that you see in each individual web interface, and you can create aggregated reports for multiple devices from the Barracuda Cloud Control console. You can connect one or more Barracuda Web Security Gateways to Barracuda Cloud Control by doing the following:

1. If you don't already have an account with Barracuda Networks, see Create a Barracuda Cloud Control Account. 2. Make a note of your username (email address) and password. 3. Log into your Barracuda Web Security Gateway as the administrator. From the ADVANCED > Firmware Upgrade page, check to make sure you have the latest firmware installed. If not, download and install it now. 4. From the ADVANCED > Cloud Control page, enter the Barracuda Networks username and password you created and click Yes to connect to Barracuda Cloud Control. Note that your Barracuda Web Security Gateway can connect with only one Barracuda Cloud Control account at a time. 5. Log into Barracuda Cloud Control with your username and password and you will see your Barracuda Web Security Gateway statistics displayed on the BASIC > Dashboard page. To access the web interface of your Barracuda Web Security Gateway, click on the link in the Products column in the Appliance Control Centerpane on the left side of the page. Or you can click on the product name in the Product column of the Unit Health pane on the right side of the page. 6. Follow steps 3 and 4 to connect every subsequent Barracuda Web Security Gateway to Barracuda Cloud Control.

To disconnect your Barracuda Web Security Gateway from Barracuda Cloud Control, from the ADVANCED > Cloud Control page, enter the Barracuda Cloud Control username and password and click No for Connect to Barracuda Cloud Control.

For details on using Barracuda Cloud Control, please see Overview.

Syslog and the Barracuda Web Security Gateway

What is the Barracuda Syslog?

The Barracuda Web Security Gateway generates syslog messages as a means of logging both changes to the web interface configuration and what happens to each traffic request performed by your users. The syslog messages are stored in text file format on the Barracuda Web Security Gateway and can be sent to a remote server configurable by the administrator. There are two syslog outputs you can monitor: the Web Interface syslog and the Web Traffic syslog.

This article describes each element of a syslog message so you can better analyze why your Barracuda Web Security Gateway performs a particular action for each traffic request. If you are using wireless AP devices in your network, see also Accepted Syslog Formats From Wireless APs.

How to Enable Syslog

To enable syslog reporting on your Barracuda Web Security Gateway:

1. Log into the web interface as admin and navigate to the Advanced > Syslog page. 2. For both the Web Traffic Syslog and Web Interface Syslog, enter the IP address of the syslog server to which you want to direct messages. 3. If you are running syslog on a UNIX machine, be sure to start the syslog daemon process with the “-r” option so that it can receive messages from sources other than itself.

Windows users must install a separate program to use syslog because the Windows OS does not include syslog capabilities. Kiwi Syslog is a popular solution, but many others are available that are both free and commercial.

How Syslog Messages are Delivered

Syslog messages are, by default, sent to the standard syslog UDP port 514. However, if your syslog server blocks UDP and/or communicates via TCP protocol, the Barracuda Web Security Gateway will transmit syslog data via TCP. If there are any firewalls between the Barracuda Web Security Gateway and the server receiving the syslog messages, be sure that port 514 is open on the firewalls. The syslog messages arrive on the mail facility at the debug priority level. As the Barracuda Web Security Gateway uses the syslog messages internally for its own message logging, it is not possible to change the facility or the priority level. For more information about where the syslog messages will be placed, refer to the documentation of your syslog server.

Barracuda Syslog Format

Each syslog message contains three types of information:

Section 1: Basic Information Section 2: Transparent Proxy Information Section 3: Policy Engine Information

The graphic below identifies each element of the syslog based on the following example:

Sep 19 17:07:07 2016 barracuda https_can[3365]: 1158710827 1 10.1.1.8 172.27.72.27 text/html 10.1.1.8 http://www.purple.com/index.css 2704 BYF ALLOWED CLEAN 2 1 0 1 3 (-) 1 adult 0 - 0 sex.com adult,porn ANON http:.//www.sex.com/index.html sex.com adult 1

How to Parse the Syslog

The following table describes each element of a syslog message, as illustrated above.

Field Name Example Description

Epoch Time 1158710827 Seconds since 1970, UNIX timestamp.

Src IP 10.1.1.8 IP address of the client (source).

Dest IP 172.27.72.27(72.32.54.242) IP address for the page (destination) that was blocked by the Barracuda Web Security Gateway.

Content Type text/html HTTP header designated content type.

Src IP 10.1.1.8 IP address of the (source).

Destination URL http://www.sex.com The URL the client tried to visit.

Data Size 2704 The size of the content.

Action BYF ALLOWED Action performed by the transparent proxy. "BYF" is a static string. The type of actions include:

• ALLOWED: Traffic was processed by the transparent proxy and no virus or spyware was detected.

• BLOCKED: Traffic was blocked by the transparent proxy most likely because the proxy detected virus or spyware.

• DETECTED: Another process detected outbound spyware activity.

Reason CLEAN Reason for the action:

• CLEAN: Traffic does not contain any virus or spyware.

• VIRUS: Traffic was blocked because it contains a virus.

• SPYWARE: Traffic was blocked because it contains spyware.

Details Stream=>Eicar-Test-Signature FOUND If traffic was blocked, this field is populated with the name of the virus or spyware that (only for blocked traffic) was detected, and appended to the Reason field. If no virus or spyware was found, this field is not displayed.

Format Version 2 The version of the policy engine output.

Match flag 1 Indicates whether an existing policy matched the traffic.

1: Yes

0: No

TQ flag 0 Indicates whether the rule is time-qualified. For example, during work hours 9am - 5pm.

1: Yes

0: No

Action Type 1 The action performed by the policy engine on this request:

0 : allowed

1 : denied

2 : redirected

3 : rewritten by add/set a new parameter in query

4 : rewritten by deleting an existing parameter in query

5 : matched a rule and allowed but marked as monitored

6 : branched to another rule set.

Src Type 3 If matched by source, what is its type:

0 : always, matches any source

1 : group, matched by group id

2 : ipv4addr, matched by an Ipv4 address

3 : login, matched by login

4 : login any, matched any authenticated user

5 : min_score, matched due to minimum infection threshold breached.

Src Detail - Any detail related to the matched source.

Dst Type 1 If matched by destination, what is its type:

0 : always, matched any destination

1 : category, matched a particular category

2 : category any, matched any category

3 : domain, matched due to domain or subdomain

4 : mimetype, matched due to mime-type

5 : spyware hit, matched due to spyware hit

6 : uri path regex, matched URI path

7 : uri regex, matched any part of the URI

8 : application, matches an application characteristics

Dst Detail adult Detail of the matched destination. In this case it is the first matched category, which is adult.

Spy Type 0 If it is a spyware hit, what is its type:

0: allow

1: block

2: infection

Spy ID - The name of the spyware if matched due to spyware hit.

Infection Score 0 Weight of the infection. Currently, mostly 0.

Matched Part sex.com The part of the rule that matched.

Matched Category adult,porn The policy category that matched the traffic.

User Info ANON User information:

• ANON: Anonymous, unauthenticated users

• ldap: Username: LDAP user info

• username: Non-LDAP user info (users created in the admin interface).

Referer URL http://www.purple.com/purple.html If enabled, displays URL of referer. If disabled, displays a dash '–' .

Referer Domain purple.com If enabled, displays domain of referer. If disabled, displays a dash '–' . http://www.cnn.com/ www.cnn.com

Referer Category news, adult, If enabled, displays the category to which the referer domain belongs. If disabled, displays hosted-personal-pages a dash '–'.

WSA Remote User Type 1 If traffic comes from a remote device, indicates whether it came from a Barracuda WSA client (Windows or Macintosh), or the Barracuda Safe Browser (an iOS device).

0: local (inline) traffic

1: remote traffic from the Barracuda WSA

2: traffic from the Barracuda Safe Browser

Syslog Examples

Example 1. Clean, policy-allowed traffic

The following example shows a syslog message for clean traffic from a Barracuda WSA client going to an allowed website (cnn.com). The term “clean” represents traffic that does not contain viruses or spyware.

Sep 19 17:06:59 2015 barracuda http_scan[3365]: 1158710819 1 10.1.1.8 64.236.16.139 image/gif 10.1.1.8 http://i.cnn.net/cnn/.element/img/1.3/ video/tab.middle.on.gif 1744 BYF ALLOWED CLEAN 2 0 0 0 0 - 0 - 0 - 0 cnn.net news ANON http://www.cnn.com www.cnn.com news 1

Example 2: Clean, policy-denied traffic

The following example shows “clean” traffic from a Barracuda Safe Browser client on a mobile device, going to a website that is blocked by one of the Barracuda Web Security Gateway policies.

Sep 19 17:07:07 2016 barracuda http_scan[3365]: 1158710827 1 10.1.1.8 172.27.72.27 text/html 10.1.1.8 http://www.sex.com/ 2704 BYF BLOCKED CLEAN 2 1 0 1 3 - 1 adult 0 - 0 sex.com adult,porn ANON http://www.sex.com/index.html www.sex.com adult 2

Example 3: Virus-infected traffic blocked by the Barracuda Web Security Gateway

The following example shows inline traffic that has been blocked by the Barracuda Web Security Gateway because the traffic contains a known virus.

Sep 19 17:08:00 2016 barracuda http_scan[3365]: 1158710880 1 10.1.1.8 127.0.0.1 - 10.1.1.8 http://www.eicar.org/download/eicar.com.txt 0 BYF BLOCKED VIRUS stream=>Eicar-Test-Signature FOUND 2 0 0 0 0 - 0 - 0 - 0 eicar.org computing-technology ANON http://www.somedomai n.com/index.html somedomain.com news 0

Example 4: Inline traffic showing simple content

Nov 28 20:13:35 2016 barracuda http_scan[30041]: 1480360415 1 10.1.2.200 52.37.201.150 - 10.1.2.200 https://self-repair.mozilla.org/ 7652 BYF ALLOWED CLEAN 2 0 0 0 0 (-) 0 - 0 - 0 self-repair.mozilla.org computing-technology,CUSTOM-142556317732606,CUSTOM-1425889735316,CUSTOM-1425890081323,CUSTOM-1425890385330,CUSTO M-1425890704337,CUSTOM-1425890996342 [[email protected]] https://self-repair.mozilla.org - - 0

Sending System Logs to an External Syslog Server in W3C Format

If you are running the Barracuda Web Security Gateway version 11.0 or higher, you can send system logs to your external syslog server in W3C extended log file format. Configure on the ADVANCED > Syslog page.

Accepted Syslog Formats From Wireless APs This article includes examples from the specific wireless AP devices from which the Barracuda Web Security Gateway can accept syslog data. Since the manufacturers of these devices may change the format from time to time, Barracuda recommends consulting with your device manufacturer to verify the current syslog output format.

The only fields required in syslog output from wireless AP devices by the Barracuda Web Security Gateway are shown in bold face. These fields identify the wireless AP device and the user for the syslog on the Barracuda Web Security Gateway.

Example syslog format for Meru

ALARM: 1388445713l | system | info | ALR | Station Info Update : MAC-Address : 74:e5:0b:b9:63:46, User-Name: dnoble, AP-Id: 1, AP-Name: Meru-AP, BSSID: 00:0c:e6:02:86:ae, ESSID: Meru, IP-Type: discovered, IP-Address: 184.15.21.123, L2-Mode: 802.1x, L3-Mode: clear, Vlan-Name: None, Vlan-Tag: 0

Example syslog format for Ruckus

Mar 3 18:32:13 stamgr: stamgr_send_log_v4():operation=add;seq=3;sta_ip=10.1.0.123;sta_mac=d8:30:62:8b:71:e0;zd/ap=24:c9:a1:24:ae :c8/54:3d:37:29:c2:a0;sta_ostype=iOS;sta_name=adnoble;stamgr_handle_remote_ipc

Example syslog format for Aerohive

INFO AUTH 12/9/2014 11:39:43 AM 10.1.0.184 10.1.0.184 ah_auth: Station 74e5:0bb9:6346 ip 10.1.31.123 username dnoble hostname BenZ570 OS n/a

Example syslog format for Aruba

Format 1:

Oct 2 13:02:34 authmgr[3785]: <522008> |authmgr| User Authentication Successful: username=dnoble MAC=c4:62:ea:c1:e7:3f I P=10.213.50.$i role=ADMON_USER VLAN=15 AP=THE.GYM.1 SSID=CNG_WIRELESS AAA profile=CNG_WIRELESS-aaa_prof auth method=802.1x auth server=RADIUSCNG2"

Format 2:

Jul 25 13:25:25 stm[1454]: <501199> |AP [email protected] stm| User authenticated, mac-18:af:61:5f:0d:27, username-rmathe ws, IP-10.6.124.216, method-4, role-affinity

Example syslog format for Clearpass

08-18-2014 10:42:43 Local1.Debug 192.168.100.27 2014-08-18 10:42:42,650 192.168.100.27 For Cuda Grab 78 1 0 Common.Username =dnoble,Common.Service=Ancillae_802.1x_Wireless,Common.Roles=Ancillae_FAC_STAFF_STU, [User Authenticated],Common.Host-MAC-Address=e4ce8f1d29de,RADIUS.Acct-Framed-IP-Address=10.50.45.103,Common.NAS-IP-Address= 192.168.100.27,Common.Request-Timestamp=2014

Barracuda Web Security Gateway API Guide

IT administrators can easily manage large blocks of usernames, create local or IP groups, and configure most global settings using the Barracuda Web Security Gateway APIs. The APIs allow remote administration to set single variables and to simplify data-intensive tasks such as:

Quickly add, update, list or delete usernames and passwords in bulk Create IP Subnet/Groups Assign users to groups Get and set single global variables

This guide includes examples of the XML-RPC code to execute various tasks, along with example Perl scripts. Any API call requires a password that you securely configure on the Barracuda Web Security Gateway BASIC > Administration page when logged in as the administrator.

The Barracuda APIs allow remote administration and configuration of the Barracuda Web Security Gateway version 5.x and higher.

How the Barracuda API Works

The framework of the API allows a programmer to get or set variables inside an XML-RPC request corresponding to field values in the configuration database of the Barracuda Web Security Gateway. Some languages, Perl is one example, provide wrappers for XML-RPC requests, providing an interface to form the request.

What Can Be Configured With the APIs

The APIs work through manipulation of variables inside the system configuration database. Variables that meet the following criteria can be manipulated by these APIs:

All global variables with a simple setting that are not policy-related. This includes most settings you can set by clicking the Save button in the Barracuda Web Security Gateway web interface. For example, from the BASIC > IP Configuration page, you can enable or disable Virus Protection for the Barracuda Web Security Gateway and then click the Save Changes button:

What Cannot be Configured With the APIs

Any variables on any page on the BLOCK/ACCEPT tab with the Policy dropdown at the top:

Variables with a list of associated values; for example, you cannot use an api to create a custom category and add a list of related domains. Deleting any policy or configuration which is part of a list. For example: exceptions, custom categories. Most things that correspond to “action” buttons in the web interface. For example, from the BASIC > Administration page, you can click a button to restart the system or shut it down, but you cannot execute these “actions” via the APIs. An exception to this is the Reload feat

ure/button, which has an API that re-applies the system configuration.

Secured Access to the APIs

Access to these APIs are limited to IP addresses on a trusted IP address list configured on the BASIC > Administration page in the Allowed API IP/Range section of the Barracuda Web Security Gateway web interface. Be sure you enter the IP address(es) where you will access the APIs in this section of the web interface before using the APIs. Attempts to call these APIs from any IP address not listed as an allowed API IP address are denied. All calls to the APIs require you to use the API password, set on this same page and section of the web interface.

XML-RPC Model

In the APIs, action parameters are received as XML strings that comply with the XML-RPC specification, which can be viewed here: http://www.X MLrpc.com/spec. So requests for all actions must be in the form of an HTTP POST request. All actions roll into one CGI script (for example: api.cgi) and map to an XML-RPC method, with those parameters needed for the action to complete.

For example, the get action maps to the config.get XML-RPC method and all parameters needed for the get are sent in the XML body. The Perl module XML::RPC (note that this is not a part of the standard Perl distribution) is used by api.cgi to retrieve the requested method and parameters. Then the action is performed and the response is sent back to the client. When there is an error, a response complying with the fault response of the XML-RPC specification is sent (see examples below). The error response contains both a fault code and a meaningful fault string. See Appendix 1 of this guide for a list and explanation of fault codes.

The XML-RPC Request and Response

The XML script is called from a Perl script or other scripting language. Each API takes its own set of parameters which are submitted in the XML body of the request. Examples of possible XML output are shown below, both for a successful request and for a request that returns an error. The single-value request / response involves a single variable value. Responses containing multiple values send the values back as an XML-RPC array.

To make the request, use the base URL of the Barracuda Web Security Gateway you use for connecting to the web interface, and append the script name you wish to use. For example, if your script is called 'api.cgi', your URL might look something like this:

http://barracuda.mydomain.com:8000/cgi-mod/api.cgi

Typical parameters used to build the request include some or all of the following:

variable :: A required parameter that tells the API which variable to return from the configuration. For example, the configuration variable 'alerts_email_address' represents the global System Alerts Email Address, set on the BASIC > Administration page in the web interface. To get or set this variable value, put 'alerts_email_address' in the XML request body specified as a variable:

variable

password :: A required parameter used to authenticate access to a page and set by the administrator on the BASIC > Administration p age in the API Password field. For example:

# API Password my $password = "1234"; my $url = " http://$cuda_ip:8000/cgi-mod/api.cgi?password=$password ";

See the contents of 'my $url' in the Perl example under How to get the current value of a global variable below, which uses a password of '1234'.

type :: A parameter that specifies the class/scope of a variable. The "scope" of variables you can set with these APIs is always 'global'.

Success Responses

The output of a successful call where no variable is being returned is a simple '200 OK' as shown below. Otherwise, successful responses with returned values are shown with each example.

Result

Error Responses

Error responses use the XML-RPC faultCode and faultString formats. The error code is the value of the faultCode member and the error string is the value of the faultString member. See Appendix 1 for a list of faultCodes and descriptions of possible errors. Here is an example of an error response, showing the XML:

faultCode <500> faultString No such variable in configuration

How to List Variables in the Configuration

The examples in this guide demonstrate getting and setting some of the variables in the configuration database. Some examples use variable names in the method calls, while other examples use explicit values, just to demonstrate both ways of making API calls. The config.varlist is a utility that provides information on scope of configuration variables to help you understand how to access and use them. Calling this method prior to using the other APIs will provide a good reference of the configuration variables.

Config.varlist There are no arguments for this API.

Sample Request:

config.varlist

Perl code for this example: use strict; use warnings; use XML::RPC;

# IP Address of your Barracuda Web Security Gateway my $cuda_ip = "10.5.7.211";

# API Password my $password = "1234"; my $url = "http://$cuda_ip:8000/cgi-mod/api.cgi?password=$password";

#Create the XML::RPC object my $xmlrpc = XML::RPC->new ($url); my $result;

$result = $xmlrpc->call ('config.varlist', { });

# show the response from the Barracuda Web Security Gateway print "--- RESPONSE ---"; print $xmlrpc->xml_in(); # END

How to Access Variables in the Configuration

To determine the name of the variable you want to configure, log into the Barracuda Web Security Gateway web interface as admin. On the page where you configure the setting, highlight the value field, right click and select Inspect Element. The typically contains the name of the configuration variable. See the blue highlight in the figure below: the part of the after UPDATE_ is the variable name. In this case, it is alerts_email_address.

How to get the current value of a global variable

Getting the current value of a system variable uses the config.get method. This example gets the value of the System Alerts Email Address variable, typically set from the BASIC > Administration page.

Arguments:

type: global variable: alerts_email_address

The name of the variable, alerts_email_address , is shown in the , to the right of Update_.

XML code for this example

Note that the tag indicates that the API applies to a single variable in the configuration. The tag indicates that the expected value of that variable is a string, and takes the variable name noted above, alerts_email_address, as the input.

config.get variable type

Perl code for this example:

Be sure to use single quotes to surround literal values in your calls, and use double quotes to surround variables.

use strict; use warnings;

use XML::RPC;

# IP Address of your Barracuda Web Security Gateway my $cuda_ip = "10.5.7.211";

# API Password my $password = "1234";

my $url = " http://$cuda_ip:8000/cgi-mod/api.cgi?password=$password ";

#Create the XML::RPC object my $xmlrpc = XML::RPC->new ($url); my $result;

$result = $xmlrpc->call ('config.get', { type => 'global', variable => 'alerts_email_address', });

# show the response from the Barracuda Web Security Gateway print "--- RESPONSE ---"; print $xmlrpc->xml_in(); # END

XML response returned by Perl script:

Here is the XML response returned after running the above Perl script, returning [email protected] as the System Alerts Email Address:

--- RESPONSE ---

How to set the value for a single variable

Use the config.set method to set a value for a single variable. This example sets the Session Expiration Length, which specifies the elapsed time allowed before a user login expires and re-authentication is required. Minimum setting for this value is 1 minute. This variable is set on the BASIC > Administration page.

The variable name can be changed to make other configuration changes. In this example, the Session Expiration Length is set to 30 minutes.

Arguments

type : 'global' variable : http_session_length => '30'

XML code for this example Note that, with the config.set method, the tag indicates the name of the single variable in the configuration. The tag indicates that the value of that variable is an integer, and explicitly sets that value to '30' as the input.

config.set http_session_length type

Perl code for this example:

use strict; use warnings; use XML::RPC;

# IP Address of your Barracuda my $cuda_ip = "10.5.7.211"; # API Password my $password = "1234"; my $url = "http://$cuda_ip:8000/cgi-mod/api.cgi?password=$password";

#Create the XML::RPC object my $xmlrpc = XML::RPC->new ($url); my $result = $xmlrpc->call('config.set',

{ type => 'global', http_session_length => '30', }

); print $xmlrpc->xml_in();

XML response returned by Perl script:

Here is the XML response returned after running the above Perl script indicating success.

--- RESPONSE --- Result

How to set values for several global variables

This example modifies multiple global variables using the config.set method, setting the Web Interface HTTP Port (http_port) to 8000 and Se ssion Expiration Length (http_session_length) to 20 (minutes). These variables are set on the BASIC > Administration page. To set several variables at once, simply list the variable names and values to set, separated by commas, as shown in the variable list:

Arguments:

type: 'global' variable list: http_session_length => '20', http_port => '8000'

Perl code for this example:

use strict; use warnings; use XML::RPC;

# IP Address of your Barracuda my $cuda_ip = "10.5.7.211"; # API Password my $password = "1234"; my $url = "http://$cuda_ip:8000/cgi-mod/api.cgi?password=$password";

#Create the XML::RPC object my $xmlrpc = XML::RPC->new ($url); my $result = $xmlrpc->call('config.set',

{ type => 'global', http_session_length => '100', http_port => '8000', }

); print $xmlrpc->xml_in();

Use Cases

Reloading the configuration

Use the config.reload method to re-apply the system configuration, corresponding to the Reload button on the BASIC > Administration pag e of the web interface.

Perl code for this example:

use strict; use warnings;

use XML::RPC;

# IP Address of your Barracuda Web Security Gateway my $cuda_ip = "10.5.7.211";

# API Password my $password = "1234";

my $url = "http://$cuda_ip:8000/cgi-mod/api.cgi?password=$password";

#Create the XML::RPC object my $xmlrpc = XML::RPC->new ($url); my $result;

$result = $xmlrpc->call ('config.reload', { });

# show the response from the Barracuda Web Security Gateway print "--- RESPONSE ---"; print $xmlrpc->xml_in(); # END

Response indicating success:

--- RESPONSE ---

Result

Managing user accounts

These APIs allow the following:

Create users Remove users Update users (change password, etc.)

Note that the user.create , user.update and user.remove methods do not require the type parameter.The output of a successful call is simply '200 OK'.

Create a local user

This example creates the user 'xyzuser' with a password of 'BWFpwd' and assigns the user to the local group 'Students', as configured on the BL OCK/ACCEPT > New Users page. The Force Password Change On Next Signon option, represented by the 'force_password_change' variable, is left out in this example since it is optional, and the default is No.

Arguments:

user: xyzuser password: BWFPwd groups: Students

use strict; use warnings; use XML::RPC;

# IP Address of your Barracuda Web Security Gateway my $cuda_ip = "10.5.7.211";

# API Password my $password = "1234";

my $url = " http://$cuda_ip:8000/cgi-mod/api.cgi?password=$password "; #Create the XML::RPC object my $xmlrpc = XML::RPC->new($url); my $result = $xmlrpc->call('user.create',

{ user => 'xyzuser', password => 'BWFPwd', groups => 'Students', change => 'No', }

); # show the response from the Barracuda Web Security Gateway print "--- RESPONSE ---"; print $xmlrpc->xml_in(); # END

Remove a local user

This example removes the user 'xyzuser'.

Arguments:

user: xyzuser

use strict; use warnings; use XML::RPC;

# IP Address of your Barracuda Web Security Gateway my $cuda_ip = "10.5.7.211";

# API Password my $password = "1234";

my $url = " http://$cuda_ip:8000/cgi-mod/api.cgi?password=$password "; #Create the XML::RPC object my $xmlrpc = XML::RPC->new($url); my $result = $xmlrpc->call('user.remove',

{ user => 'xyzuser', }

); # show the response from the Barracuda Web Security Gateway print "--- RESPONSE ---"; print $xmlrpc->xml_in(); # END

Update a local user

This example updates the password for user “xyzuser” and adds the user to two groups, 'Faculty' and 'Staff'.

Arguments:

user: xyzuser password: BWFPwd groups: Faculty\nStaff

use strict; use warnings; use XML::RPC;

# IP Address of your Barracuda Web Security Gateway my $cuda_ip = "10.5.7.211";

# API Password my $password = "1234";

my $url = " http://$cuda_ip:8000/cgi-mod/api.cgi?password=$password "; #Create the XML::RPC object my $xmlrpc = XML::RPC->new($url); my $result = $xmlrpc->call('user.update',

{ user => 'xyzuser', password => 'BWFPwd', groups => "Faculty\nStaff", change => 'No', }

); # show the response from the Barracuda Web Security Gateway print "--- RESPONSE ---"; print $xmlrpc->xml_in(); # END

The following results display in the Barracuda Web Security Gateway web interface on the USERS/GROUPS > Account View page by clicking E dit for user 'xyzuser'. The USER INFORMATION popup shows the associated groups you added for 'xyzuser':

List all user accounts

The user.list method simply lists all user accounts currently on the system, as displayed on the USERS/GROUPS > Account View page.

use strict; use warnings; use XML::RPC;

# IP Address of your Barracuda Web Security Gateway my $cuda_ip = "10.5.7.211";

# API Password my $password = "1234";

my $url = "http://$cuda_ip:8000/cgi-mod/api.cgi?password=$password"; #Create the XML::RPC object my $xmlrpc = XML::RPC->new ($url); my $result; $result = $xmlrpc->call ('user.list', { }); # show the response from the Barracuda Web Security Gateway print "--- RESPONSE ---";print $xmlrpc->xml_in(); # END

Response

The successful response lists the two configured user accounts, 'new_user' and 'xyz_user'.

< /value>

Creating a New IP Subnet/Group

This example creates a new IP Subnet/Group called facilities with an IP address of 10.20.30.0 and a netmask of 255.255.255.0. This setting is configured on the USERS/GROUPS > IP Subnets/Groups page. The most common reason to create an IP group is to apply an exception policy to multiple users on the same IP network. Note that remote users whose web traffic is filtered via the Barracuda Web Security Agent (WSA) cannot be included in these groups.

This API is a bit more complex, with additional parameters used to build the request since this is an application of 'tied variables'. These are variables that are dependent upon, or "tied to" a key variable. In this example, the two variables LDAP_groups_IP_netmask and LDAP_grou ps_IP_comment are dependent upon the LDAP_groups_IP_address.

Arguments: The following arguments are used by the config.create method:

parent_type :: A required parameter that tells the API about the class/scope of the parent container. In this case, the scope is 'global'. parent_path :: A required parameter that is the qualified name of a parent object under which a new object will be created. In this case, this variable is left blank. type :: A required parameter that specifies the key variable that the other variables are tied to. name :: A required parameter that specifies the explicit value of the key variable.

variable list :: An optional parameter that tells the API which variable(s) to set, including explicit values.

use strict; use warnings; use XML::RPC;

# IP Address of your Barracuda Web Security Gateway my $cuda_ip = "10.5.7.211";

# API Password my $password = "1234";

my $url = " http://$cuda_ip:8000/cgi-mod/api.cgi?password=$password "; #Create the XML::RPC object my $xmlrpc = XML::RPC->new($url); my $result;

$result = $xmlrpc->call ('config.create',

{ parent_type=>'global', parent_path => '', name => '10.20.30.0', type => 'LDAP_groups_IP_address', LDAP_groups_IP_netmask => '255.255.255.0', LDAP_groups_IP_comment => 'faciliies', }); # show the response from the Barracuda Web Security Gateway print "--- RESPONSE ---"; print $xmlrpc->xml_in(); # END

Response indicating success:

--- RESPONSE --- Result

Appendix 1

See the Error Response format under The XML-RPC Request and Response above for an example of how the faultCodes (error codes), shown below, are returned with the XML response.

Error (Fault) Codes Fault Code Description Example Fault Strings

400 Required arguments are missing Too few arguments:

401 Machine does not have access rights Your machine does not have access rights to administer...

402 Domain name error Domain already exists

Domain is not a valid domain

403 Access error Access denied

406 API was called with incorrect parameters Incorrect parameters for API call

411 Account error User account does not exist

412 Account error User account already exists

421 Account error Unable to validate account

425 Input object or variable is not valid Config: Error: Invalid variable: Config: Error: variable not recognized

Config: Error: Invalid object type:

Config: Error: is not tied to

Config: Error: does not belong to any class

Config: Error: does not belong to

Config: Error: is not of type

426 Invalid operation Config: Error: invalid operation for variable

Config: Error: Cannot add values to tied variable

Config: Error: Cannot remove values from tied variable

427 The object does not exist in the database Config: Error: Could not find tied object: , []

Config: Error: Could not find scoped object: , [global]

Config: Error: Could not find scoped object: , [, ]

428 Input value being set is not valid Config: Error: Could not find values to delete in :

429 Required variable is missing Variable required to create object of type

450 The method you used is unknown Unknown method called

499 Unknown error An unknown error has occurred

500 Unknown error An unknown error has occurred

Troubleshooting

The Barracuda Networks backup process does NOT back up your SSL certificates, therefore, if you do not manually back up SSL certificates, you must redeploy using a new certificate.

Basic Troubleshooting Tools

The ADVANCED > Troubleshooting page provides various tools that help troubleshoot network connectivity issues that may be impacting the performance of your Barracuda Web Security Gateway.

Examples include:

Test the connection between the Barracuda Web Security Gateway to Barracuda Central to make sure it can successfully download the latest virus and spyware definitions. Ping or telnet to devices from the Barracuda system Perform a traceroute from the Barracuda system to a destination server Run a packet capture Test what action the Barracuda Web Security Gateway would take with particular URLs, domains, MIME types, etc. based on block/accept polices and exceptions you create. See Policy Rule Checking.

Connect to Barracuda Support Servers

In the Support Diagnostics section of the ADVANCED > Troubleshooting page, you can initiate a connection between your Barracuda Spam Firewall and the Barracuda Networks Technical Support Center which will allow technical support engineers to troubleshoot any issues you may be experiencing.

Rebooting the System in Recovery Mode

If your Barracuda Web Security Gateway experiences a serious issue that impacts its core functionality, you can use diagnostic and recovery tools that are available at the reboot menu to return your system to an operational state.

Before you use the diagnostic and recovery tools, do the following:

Use the built-in troubleshooting tools on the ADVANCED > Troubleshooting page to help diagnose the problem. Perform a system restore from the last known good backup file. Contact Barracuda Networks Technical Support for additional troubleshooting tips.

As a last resort, you can reboot your Barracuda Web Security Gateway and run a memory test or perform a complete system recovery, as described in this section.

To perform a system recovery or hardware test:

1. Connect a monitor and keyboard directly to your Barracuda Web Security Gateway. 2. Reboot the system by doing one of the following: - In the web interface: Go to the BASIC > Administration page, navigate to the System Reload/Shutdown section, and click Restart. - At the front panel of the Barracuda Web Security Gateway: Press the Power button on the front panel to turn off the system, and then press the Power button again to turn the system on.

The splash screen displays with the following three boot options:

Barracuda

Recovery

Hardware_Test 3. Use your keyboard to select the desired boot option, and press the Enter key. You must select the boot option within three seconds after the splash screen appears. If you do not select an option within three seconds, the Barracuda Web Security Gateway starts up in Normal mode (first option). For a description of each boot option, refer to Reboot Options below.

To stop a hardware test, reboot your Barracuda Web Security Gateway by pressing the Ctrl-Alt-Del keys.

Reboot options

The table below describes the options available at the reboot menu.

Reboot Options Description

Barracuda Starts the Barracuda Web Security Gateway in the normal (default) mode. This option is automatically selected if no other option is specified within the first three seconds of the splash screen appearing.

Recovery Displays the Recovery Console, where you can select the following options:

Perform file system repair—Repairs the file system on XFS-based Barracuda Web Security Gateway. Select this option only if the serial number on your Barracuda Web Security Gateway is below 24364; otherwise select the Perform Full System Re-image option. Perform full system re-image—Restores the factory settings on your Barracuda Web Security Gateway and clears out the configuration information. Select this option if the serial number on your Barracuda Web Security Gateway is 24364 or above. Enable remote administration—Turns on reverse tunnel that allows Barracuda Networks Technical Support to access the system. Another method for enabling remote administration is to click Establish Connection to Barracuda Support Center on the ADVANCED > Troubleshooting page. Run diagnostic memory test—Runs a diagnostic memory test from the operating system. If problems are reported when running this option, we recommend running the Hardware_Test option next.

Hardware_Test Performs a thorough memory test that shows most memory related errors within a two-hour time period. The memory test is performed outside of the operating system and can take a long time to complete.

Reboot your Barracuda Web Security Gateway to stop the hardware test.

Replacing a failed system

Before you replace your Barracuda Web Security Gateway, use the tools provided on the ADVANCED > Troubleshooting page to try to resolve the problem.

Barracuda Instant Replacement Service

In the event that a Barracuda Web Security Gateway system fails and you cannot resolve the issue, customers who have purchased the Instant Replacement service can call Barracuda Networks Technical Support and receive a new unit within 24 hours.

After receiving the new system, ship the failed Barracuda Web Security Gateway back to Barracuda Networks at the address below with an RMA number marked clearly on the package. Barracuda Networks can provide details on the best way to return the unit.

Barracuda Networks

3175 S. Winchester Blvd

Campbell, CA 95008

attn: RMA #

To set up the new Barracuda Web Security Gateway so it has the same configuration as your old failed system, restore the backup file from the old system onto the new system, and then manually configure the new system’s IP information on the BASIC > IP Configuration page. For information on restoring data, refer to How to Back Up and Restore Your System Configuration.

Maintenance

Release Notes and Updating the Barracuda Web Security Gateway Firmware

Important Before updating the firmware on your Barracuda Web Security Gateway, Barracuda recommends reading the Release Notes. For a description of new features in a release, see What's New in the Barracuda Web Security Gateway.

Use the ADVANCED > Firmware Update page to manually update the firmware version of the system or revert to a previous version. The only time you should revert back to an old firmware version is if you recently downloaded a new version that is causing unexpected problems. In this case, call Barracuda Networks Technical Support before reverting back to a previous firmware version.

Updating the Firmware of Linked Systems

If a system is part of a cluster, we recommend changing the system’s Mode in the Clustered Systems section of the ADVANCED > Linked Management page to Standby before you upgrade its firmware, and then repeat this process on each system in the cluster. Once the firmware on each system has been upgraded, you can then change the mode on each system back to Active.

Changing a linked system to Standby mode before upgrading prevents a system on a more recent firmware version from trying to synchronize its configuration with a system on an earlier firmware version. If you have the latest firmware version already installed, the Download Now button on the ADVANCED > Firmware Update page is disabled.

Applying a new firmware version results in a temporary loss of service. For this reason, you should apply new firmware versions during non-business hours.

Updating the Spyware, Virus, Category, Application and Security Definitions

Use the ADVANCED > Energize Updates page to manually or automatically update your Barracuda Web Security Gateway with the most current spyware, virus, category, application and security definitions. Barracuda Networks recommends that the Automatic Updates setting for your spyware and virus definitions be set to On so your Barracuda Web Security Gateway receives the latest definitions as soon as new threats are identified by Barracuda Central.

This should be one of settings the administrator configures in the initial installation of the Barracuda Web Security Gateway.

Reloading, Restarting, and Shutting Down the System

Use the System Reset/Shutdown section on the BASIC > Administration page to shutdown, reset, and reload the Barracuda Web Security Gateway. Shutting down the system powers off the unit. Restarting the system reboots the unit. Reloading the system re-applies the system configuration.

You can also simply reboot the system by pressing the RESET button on the front panel of the system.

How to Back Up and Restore Your System Configuration

Backing Up and Restoring Your System Configuration

The ADVANCED > Backup page lets you back up and restore the configuration of your Barracuda Web Security Gateway. You should back up your system on a regular basis in case you need to restore this information on a replacement Barracuda Web Security Gateway or in the event your current system data becomes corrupted.

If you are restoring a backup file on a new Barracuda Web Security Gateway that is not yet configured, you first need to assign your new system an IP address and DNS information on the BASIC > IP Configuration page. Note the following about the backup file:

Do not edit backup files. Any configuration changes you want to make need to be done via the web interface. The configuration backup file contains a checksum that prevents the file from being uploaded to the system if any changes are made. The firmware version running on the system when the backup file was generated should match the firmware version on the system you are restoring onto. If it does not match, you will see a warning at the top of the page when you attempt to restore. The backup of the configuration includes most global (system-wide) and domain settings, along with all user account information. However, the following are NOT included in this type of backup:

System password All settings on the following pages: BASIC > IP Configuration, including: System IP address Proxy system password ADVANCED > Appearance, including logos (**) ADVANCED > Linked Management (**)

(**) Applicable only for models that support this feature.

Restoring a Backup

Restoring a backup simply requires browsing your local system with the click of a button on the ADVANCED > Backup page and selecting a backup file. Click the Help button on that page for details about restoring backups. Please note that restoring a backup will overwrite the current configuration.

Caution Do not restore a configuration file onto a machine that is currently part of a cluster. All cluster information will be lost and the units will need to be re-clustered if this happens.

If you need to restore a backup from one Barracuda Web Security Gateway model to a different model, please contact Barracuda Technical Support before proceeding. Note that settings on one model may not apply to a different model.

Restoring a Backup to Version 6.0 or Above From Early Versions

Barracuda does not recommend restoring a backup created from a Barracuda Web Filter version previous to 6.0 to a Barracuda Web Filter version 6.0 or above. The best option is to reconfigure your newer Barracuda Web Filter version with the same settings you employed on your older Barracuda Web Filter version. However, if you wish to pursue restoring a backup from a version prior to 6.0 to a newer version, you must do the following:

1. Obtain the backup file from the Barracuda Web Filter running the firmware version previous to 6.0, and note the firmware version with which it was created. 2. Call Barracuda Networks Technical Support for assistance.

Web Use Categories

The Barracuda Web Security Gateway URL filtering engine uses one of the most extensive content definition databases, covering some of the highest risk websites on the Internet.

The websites in the Barracuda Networks database are organized into content categories (subcategories) which are grouped below by supercategories. When you create rules that block categories of websites, you can choose a supercategory to block, or you can drill down and block websites at the subcategory level.

Dynamic Site Categorization with the Barracuda WCS

With the Barracuda Web Security Gateway version 9.1 and above, dynamic website categorization is provided by the Barracuda Web Categorization Service (WCS) in the Barracuda Cloud. The Barracuda Content Definition database (CFDEF) contains over 15 million categorized sites and is stored in the cloud. For best performance, only the top 2 million of those sites are downloaded on a regular basis to each Barracuda Web Security Gateway. If a user visits a website outside of that 2 million, then the Barracuda Web Security Gateway simply queries the WCS in the cloud for the category. The WCS service then does one of two things:

Returns the category to the Barracuda Web Security Gateway based on a lookup into the Barracuda CFDEF database in the Barracuda Cloud Deploys web crawlers to scour the site and analyze content text and images to determine the category the site belongs to. The Barracuda WCS then passes that information to the Barracuda Web Security Gateway, which stores this categorization in a local cache for later use. This categorization also goes into the CFDEF database so that a human can analyze the results and verify that the categorization is correct. This enables Barracuda to constantly improve on the learning of the WCS service, thereby improving the accuracy of this process.

Important Note As one of a number of sources and methods for making security decisions, Barracuda Web Content Security uses the Blacklists UT1 from Université Toulouse 1 Capitole, managed by Fabrice Prigent, with modifications by Barracuda's content intelligence team, under a Creative Commons license (link: http://creativecommons.org/licenses/by-sa/4.0/). No endorsement of our product by Université Toulouse 1 Capitole is expressed or implied by our use of their data.

Bandwidth

Websites delivering content that can use large amounts of network resources.

Category Criteria

Streaming Media Websites that provide streaming audio and video, or software and tools for streaming media.

Streaming Radio/TV Websites that provide streaming radio or TV.

Advertisements & Popups Websites that host or serve advertisements or provide software that serves advertisements.

Media Downloads Websites that provide downloads of music and video content in any format.

Media Sharing Websites that allow posting and sharing of music and video content in any format.

Commerce

Websites that contain business information or facilitate commercial transactions.

Category Criteria

Auctions & Classifieds Websites that allow bidding and selling of items and services. Does not include non-selling related advertising.

Business Websites that provide business-related overview, planning and strategy information.

Finance & Investment Websites that provide financial information or access to online banking.

Real Estate Websites that provide residential and commercial property sales and rental information, listings and services.

Shopping Websites that sell goods and services, but not marketing or ordering websites for single products.

Stock Trading Websites that allow monitoring, purchase, or sale of stocks.

Communications

Websites that let users communicate through web browsers.

Category Criteria

Chat Websites that provide Web-based messaging and chat rooms, including IRC and social networking chat functions.

Peer-to-Peer Websites that distribute file sharing software or allow the exchange of files between users.

Web-based Email Websites that enable sending, reading and archiving of email.

Instant Messaging Websites that provide instant messaging software such as instant messaging clients or chat clients that are not Web-based.

Messaging Websites that allow users to send and receive messages, e.g. SMS,MMS, voice mail, or FAX.

Mobile Communications Websites that provide support information for mobile communication devices.

Online Meetings Websites that enable multiple users to interact transparently with each other through messaging, audio or video connections.

Web-based Telephony Websites that enable voice communication over the Web.

Information

Websites that provide searching, general news and information, including business content.

Category Criteria

Education & Reference Websites that provide academic information about schools or education related topics.

Forums & Newsgroups Websites containing user-generated Web logs, discussion forums or wikis.

Government & Legal Websites maintained by domestic and foreign government and military agencies.

Health & Medicine Websites that provide health and wellness material or information about health products and service providers.

History Websites that provide historical content.

Job Search & Career Development Websites that enable users to search for job openings and career opportunities, either with specific companies or job boards.

Motor Vehicles Websites containing information and marketing for cars, auto parts and services.

News Websites that contain general news information on a local, national and international level.

Advocacy/NGO Websites for groups that promote or defend specific causes.

Religion Websites that include content related to spirituality, religion, and philosophy.

Moderated Forums Websites monitored by an authority who can prevent posting of inappropriate material.

Political Issues Websites that contain opinion and political information, groups and discussions.

Professional Networking The subset of social networking websites which includes content intended exclusively for businesses or professionals.

Public Information Websites allowing search and access of the public records of people or organizations.

Technical/Business Forums Websites which allow discussions or posting of user-generated content related to business or technical development.

Usenet News Websites providing access to Usenet news groups or other bulletin boards.

Leisure

Entertainment and personal websites that are normally not business-related.

Category Criteria

Marketing & Merchandising Websites that provide information about products and services not available on the Web.

Blogs & Wikis Websites allowing users to post content, edit and re-post frequently.

Arts & Society & Culture Websites that display art galleries, information about artists and ethnic and cultural heritage.

Comics & Humor & Jokes Websites containing comical or funny content.

Entertainment Websites providing information on theater arts, movies, concerts, tv, radio and other amusements, or about celebrities of those venues.

Food & Dining Websites with information, reviews, and online ordering for restaurants, bars, and catering.

Game Playing & Game Media Websites that provide video game information or enable the online playing of games.

Hobbies & Recreation Websites dedicated to recreational activities and hobbies, or organizations and businesses dedicated to recreation, such as amusement parks.

Kids Sites Websites that are family-oriented and geared toward children.

Personals & Dating Websites that enable users to meet and interact with each other for the purposes of dating or making friends.

Social Networking Websites that enable friends to interact and share information, but not for the purposes of dating.

Sports Websites with information and news about amateur and professional sports.

Travel Websites that provide information about travel destinations or allow online booking of travel plans.

Digital Cards Websites that enable the sending and receiving of digital postcards and greeting cards.

Fashion & Beauty Websites that provide information or products related to fashion and beauty.

Hosted Personal Pages Websites which allow users to design and post personal websites.

Liability

Users may be committing crimes or exposing the organization to legal liability with these sites.

Category Criteria

Criminal Activity Websites that provide information on how to commit illegal activities, perpetrate scams or commit fraud.

Illegal Drugs Websites that provide information on the manufacturing or selling of illegal drugs or prescription drugs obtained illegally.

Illegal Software Websites that provide information about or downloads of pirated software.

Academic Cheating Websites that advocate or assist plagiarism or provide or sell questionable educational material.

Propriety

Websites that are intended for mature or adult users only.

Category Criteria

Text/Audio Only Websites that contain text or audio only, but no pictures.

Adult Content These websites include content intended for legitimate reproductive science and sexual development educational material.

Alcohol & Tobacco Websites that promote or sell alcoholic beverages or tobacco products.

Gambling Websites that provide gambling odds and information or allow online betting.

Intimate Apparel & Swimwear Websites containing revealing images such as swimsuits and modeling, but not nudity.

Intolerance & Hate Websites encouraging bigotry or discrimination.

Pornography Any website that contains sexually suggestive, explicit or erotic content.

Tasteless & Offensive Websites portraying horror or perverse content.

Violence & Terrorism Websites encouraging, instructing, or portraying extreme violence to people or property.

Weapons Websites that contain information about making, buying, or obtaining any sort of weapons.

Extremely Offensive Websites containing content that is shocking, gory, perverse, or horrific in nature.

Gambling Related Websites providing information or promoting services, techniques or accessories related to gambling.

Game/Cartoon Violence Websites containing graphically violent animated content.

Historical Opinion Websites dedicated to subjective analysis of historical events, especially partisan or agenda-driven analysis.

Incidental Nudity Websites which include nude images because they are part of a broader category of art or education.

Nudity Websites containing bare images of the human body which are not suggestive or explicit.

Profanity Websites which contain excessive use of profanity or obscenities.

Security

Websites that are security risks or sources of malware, or that allow users to circumvent policies.

Category Criteria

Hacking Websites that contain instructions and information for how to commit fraud or steal information through computer security vulnerabilities.

Phishing & Fraud Websites that are known to be distributed as links in phishing emails.

Proxies Websites that enable users to hide their browsing destinations, IP address, or username to avoid detection and bypass Web filters.

Spam Websites delivering unwanted or unsolicited electronic messages.

Spyware Websites that are accessed from spam message clicks, which distribute programs to gather user information, or covertly send information to third party websites.

Proxy Utilities Websites providing users with resources to help them avoid detection or bypass Web filters.

Information Security Websites that provide information about protecting personal or business data.

Malicious Sites Websites that provide or display content which intends harm to users or their computer systems.

Suspicious Sites Suspect websites whose malicious intent cannot be confirmed.

Technology

Websites that allow users to access search engines, portals and various technologies.

Category Criteria

Computing & Technology Websites that provide technical support information, but not of a security nature.

Content Server Includes domains that host websites of other types and are often sources of security threats.

Downloads Websites that distribute copies of free and shared software.

Parked Sites For sale or expired websites that display links or advertisements.

Visual Search Websites that provide image searching and matching technology.

Search Engines & Portals Websites that aggregate disparate information or allow users to search across large amounts of data.

Software/Hardware Websites that provide access to software or hardware technology.

Interactive Web Applications Websites that provide access to groupware or interactive conference rooms.

Online Services Websites that provide access to Web-based services.

Online Storage Websites that allow the uploading of files and backups for remote data storage.

Remote Access Websites that provide access to resources from a remote locations.

Resource Sharing Websites that allow posting and sharing of resources and downloads to a network of people.

Technical Information Websites that provide information on technical details of technologies.

Translators Websites that provide translation services.

URL Redirectors Websites that automatically forward the user from the requested URL to another URL.

About the Barracuda Web Security Gateway Hardware

The illustrations in this article are based on current hardware models; however, models differ based on release date and may change in the future. If your appliance connections differ from those shown in this article, contact Barracuda Technical Support for additional information.

Barracuda Web Security Gateway 210

Barracuda Web Security Gateway 210 Front Panel

The following figure illustrates the Barracuda Web Security Gateway 210 power and disk activity indicator lights.

Note that the WAN and LAN ports are located on the back of the unit.

The following table describes the Barracuda Web Security Gateway 210 front panel power and disk activity indicator lights.

Component Name Description

Power Button Powers the Barracuda Web Security Gateway on or off

Reset Button Resets the Barracuda Web Security Gateway

Power Light Displays solid blue when the power is on.

Disk Light Displays hard disk activity

Barracuda Web Security Gateway 210 Rear Panel

The following image illustrates the Barracuda Web Security Gateway 210 rear panel ports and connectors.

The following table describes the Barracuda Web Security Gateway 210 rear panel ports and connectors.

Port/Connector Name Description

Mouse Port Optional. Mouse connection

Keyboard Port Optional. PS2 keyboard connection

VGA Port Recommended. Video graphics array (VGA) monitor connection

HDMI Port Optional. HDMI video connection.

USB Ports (4) Optional. USB device connection

Network Port Network Port

Microphone Optional. Microphone line-in connection

Line In/Line Out Jack Optional. Audio input/output connections

Power Supply Power supply input

Serial Number Appliance serial number

WAN/LAN Ports WAN/LAN ports

Barracuda Web Security Gateway 310 and 410

Barracuda Web Security Gateway 310 and 410 Front Panel

The following figure illustrates the Barracuda Web Security Gateway 310 and 410 power and disk activity indicator lights.

The following table describes the Barracuda Web Security Gateway 310 and 410 power and disk activity indicator lights.

Component Name Description

WAN port Port for WAN Connection

LAN port Port for LAN Connection

Power Button Powers the Barracuda Web Security Gateway on or off

Reset Button Resets the Barracuda Web Security Gateway

Power Indicator Displays solid blue when the power is on

Disk Activity Blinks when the Barracuda Web Security Gateway processes traffic

Barracuda Web Security Gateway 310 and 410 Rear Panel

The following image illustrates the Barracuda Web Security Gateway 310 and 410 rear panel ports and connectors.

The following table describes the Barracuda Web Security Gateway 310 and 410 rear panel ports and connectors.

Component Name Description

Power Supply Connection for the AC power cord, standard

Mouse port Connection for the mouse

Keyboard port Connection for the keyboard

USB ports (4) Connection for USB devices

Dual Link DVI-D Port Optional. Digital monitor connection

VGA Port Recommended. Video graphics array (VGA) monitor connection.

Network Port Network port

Barracuda Web Security Gateway 610

Barracuda Web Security Gateway 610 Front Panel

The following figure illustrates the Barracuda Web Security Gateway 610 power and disk activity indicator lights.

The following table describes the Barracuda Web Security Gateway 610 power and disk (RAID) activity indicator lights.

Diagram Location Component Name Description

1 Hard Disk Drive #1 Location of #1 disk drive

2 Hard Disk Drive Inactivity Displays when the hard disk is inactive

3 Hard Disk Drive Activity Displays when the hard disk drive is active

4 Hard Disk Drive #2 Location of #2 hard disk drive

5 Hard Disk Drive Inactivity Displays when the hard disk is inactive

6 Hard Disk Drive Activity Displays when the hard disk is active

7 Spyware Activity Displays spyware activity

8 Spyware or Virus Downloads Displays spyware or virus download activity

9 Internet Activity Displays normal Internet activity

10 WAN port Port for WAN connection

11 Hard Disk Displays hard disk activity

12 LAN Port Port for LAN connection

13 Power Indicator Light Displays a solid green when the system is powered on

14 Reset button Resets the Barracuda Web Security Gateway

15 Power button Powers the Barracuda Web Security Gateway on or off

Barracuda Web Security Gateway 610 Rear Panel

The following image illustrates the Barracuda Web Security Gateway 610 rear panel ports and connectors.

The following table describes the Barracuda Web Security Gateway 610 rear panel ports and connectors.

Diagram Location Component Name Description

1 Fan Location of the fan

2 Power Supply Connection for the AC power cord, standard power supply

3 Mouse port Connection for the mouse

4 Keyboard port Connection for the keyboard

5 USB ports (2) Connection for USB devices

6 Serial port Connection for the serial console cable

6 Parallel Port Connection for the parallel cable

7 Monitor Port Connection for the monitor

8 Auxiliary Port Web interface management

Barracuda Web Security Gateway 810 and 910

Barracuda Web Security Gateway 810 and 910 Front Panel

The following figure illustrates the Barracuda Web Security Gateway 810 and 910 power and disk (RAID) activity indicator lights.

The following table describes the Barracuda Web Security Gateway 810 and 910 power and disk activity indicator lights.

Diagram Location Component Name Description

0 Hard Disk Drive #0 Location of #0 disk drive

1 Hard Disk Drive #1 Location of #1 disk drive

2 Hard Disk Drive #2 Location of #2 disk drive

3 Hard Disk Drive #3 Location of #3 disk drive

4 Hard Disk Drive #4 Location of #4 disk drive

5 Hard Disk Drive #5 Location of #5 disk drive

6 Hard Disk Drive #6 Location of #6 disk drive

7 Hard Disk Drive #7 Location of #7 disk drive

8 Hard Disk Drive Locks Each drive has a lock/release button

9 Spyware Activity Displays spyware activity

10 Spyware or Virus Downloads Displays spyware or virus download activity

11 Network activity Displays normal web traffic

12 Network activity Displays normal web traffic

13 Hard disk light Displays hard disk activity

14 Power light Displays a solid green when the system is powered on

15 Reset button Resets the Barracuda Web Security Gateway

16 Power button Powers the Barracuda Web Security Gateway on or off

17 WAN port Port for WAN connection

18 LAN port Port for LAN connection

Barracuda Web Security Gateway 810 and 910 Rear Panel

The following image illustrates the Barracuda Web Security Gateway 810 and 910 rear panel ports and connectors.

The following table describes the Barracuda Web Security Gateway 810 and 910 rear panel ports and connectors.

Diagram Location Component Name Description

1 Hot Swappable Power Supplies (2) Connection for the AC power cord, standard power supply

2 Mouse port Connection for the mouse

3 Keyboard port Connection for the keyboard

4 Not used Not used

5 USB ports (2) Connection for USB devices

6 Serial port Connection for the serial console cable

7 Monitor Port Connection for the monitor

8 Auxiliary Port Web interface management

9 Not used Not used

10 Power Indicator Lights Displays:

Green light when the system is powered on and the power supply is healthy. Orange/Amber light = The power supply is degraded. For example, one of the two PSUs is not functioning. Pushing the Reset button may solve the problem; otherwise one of the PSUs should be replaced. No light = the power supply is not working.

Barracuda Web Security Gateway 1010

Barracuda Web Security Gateway 1010 Front Panel

The following image illustrates the Barracuda Web Security Gateway 1010 front panel and disk activity indicator lights.

The following table describes the Barracuda Web Security Gateway 1010 power and disk activity indicator lights.

Diagram Location Component Name Description

0 Hard Disk Drive #0 Location of #0 disk drive

1 Hard Disk Drive #1 Location of #1 disk drive

2 Hard Disk Drive #2 Location of #2 disk drive

3 Hard Disk Drive #3 Location of #3 disk drive

4 Hard Disk Drive #4 Location of #4 disk drive

5 Hard Disk Drive #5 Location of #5 disk drive

6 Hard Disk Drive #6 Location of #6 disk drive

7 Hard Disk Drive #7 Location of #7 disk drive

8 Hard Disk Drive Locks Each drive has a lock/release button

9 Spyware or Virus Downloads Displays spyware or virus download activity

10 Spyware Activity Displays spyware activity

11 Network activity Displays normal web traffic

12 Network activity Displays normal web traffic

13 Hard Disk Displays hard disk activity

14 Power Light Displays a solid green when system is powered on

15 Reset button Resets the Barracuda Web Security Gateway

16 Power button Powers the Barracuda Web Security Gateway on or off

Barracuda Web Security Gateway 1010 Rear Panel

The following image illustrates the Barracuda Web Security Gateway 1010 rear panel ports and connectors.

The following table describes the Barracuda Web Security Gateway 1010 rear panel ports and connectors.

Component Name Description

Hot Swappable Power Supplies (2) Connection for the AC power cord, standard power supply

Power Indicator Lights Displays:

Mouse port Connection for the mouse

Keyboard port Connection for the keyboard

USB ports (2) Connection for USB devices

Serial port Connection for the serial console cable

VGA Port Connection for the monitor

Management Port Port for web interface management.

WAN 1, WAN 2 WAN port connections

LAN 1, LAN 2 LAN port connections