14.1.0 Changelog

Overview

14.1 is a major new release.

New Intrusion Prevention

Intrusion Prevention (IPS) has been newly designed and implemented.

While many security technologies can fall under the description of "Intrusion Prevention" typically, traditionally IPS refers to a mass-signature based approach to detect commonly known attacks. Unlike many of the other security technologies in Untangle, this has always presented an issue for Untangle because it is not by its nature a "set and forget" technology. It usually requires routine maintenance and diligent reading of the logs and tuning to get any positive return on investment. Lack of this effort often results in negative value, and misconfiguration through inexperience with IPS systems can often result in even more negative value.

In our effort to "keep things simple" we have redesigned our implementation of IPS to hopefully provide more power, yet easier maintenance.

Rules and Signatures

What was previously called "rules" are now called "signatures"

Our upstream source of signatures (currently Emerging Threats) provides a large and frequently updated signature set. Signatures can detect anything from major attacks, interesting activity, or just downright mundane things like ping, http, etc. These signatures come with a recommended state from the provider. Either enabled (log/alert) or not enabled by default. Contrary to popular belief, no signature actions are set to block or drop from the signature providers.

Now there is a new concept of a rule that is a post-processor of all signatures that will can override/set the action of the signatures. For example, you could create a rule that you want to set the action to "Block" of all signatures in the certain category or that affect a certain protocol.

The new rules determine which signatures are enabled and their associated actions if enabled. These rules can be crafted to maintain the signature set and actions, even across continual updates of the signatures.

Some examples:

• An admin can create a rule to set block "web-application-attacks" that were enabled from the provider. If the provider releases a new web-application-attacks signature that is enabled - it will be set to block automatically.
• An admin can create a rule to set log on all "critical" signatures. If new critical signatures are released, they will be set to log.
• Ad admin can create a rule to set block on signature SID 1234, If the definition of SID 1234 changes in an update, the rule will set block on the new SID 1234 signature.
• Ad admin can create a rule that references system memory as a variable, allowing for creation of rulesets that take system memory into account, making sharing the same ruleset across an install base with command center easier even in scenarios where system memory varies.

Suricata

We've switch the IPS engine from snort to suricata. This change will be mostly invisible to the network admin.

The reason for the switch was purely technical. Suricata has some nice features, good performance, better upstream packaging and management, and is more memory efficient.

Power Users

While these changes will hopefully bring benefits to those looking for an easier way to maintain signatures. We expect it will also provide new challenges.

For example, rules provide an easy way to set all signatures or many signatures to block, which can and will cause massive network connectivity issues. Many signatures are very broad, many have false positives, and many just detect very mundane regular network activity not "attacks".

We have encountered many users frustrated with this before and had to hide functionality that allowed for easy mass-enabling of signatures.

Hopefully the rules based approach will provide the power to power users but not encourage wreckless behavior to the crowd that just want things to work but are curious. In the meantime, if you have customized your IPS rules, when troubleshooting network issues we would recommend disabling IPS during the process so it can be eliminated as a source of the issue.

Zero Touch Provisioning

14.1 adds support for the new "zero touch" provisioning process. If enabled in Command Center, when using official Untangle appliances, they will self-provision themselves with subscriptions and configuration when deployed at the customer site through Command Center. This allows admins to ship appliances set to be zero-touch provisioned to customer sites and have the customer just plug them in. They will register and image themselves with the configured settings.

Here is how Zero Touch Provisioning works:

• At the installation site, a designated person receives the hardware appliance and connects the power and Internet cable based on the instructions from the setup guide.
• When the appliance is powered, it attempts to obtain an IP address via DHCP and connect to the Internet.
• If the appliance establishes connectivity, it registers to Command Center.
• The user copies the serial number from the label on the device and communicates it to the administrator.
• The administrator logs in to Command Center and adds the appliance based on the serial number.
• Once the appliance is added to Command Center, the administrator can remotely manage the configuration and subscriptions.

New Certificate Management

The process/UI for managing Untangle certificates has been improved.

Managing and understanding certificates is difficult. Buying a certificate from a provider is not easy.

The new UI aims to simply this process a little by providing several ways for admins to upload the certs, keys, and intermediate certs provided from the certificate authority to your Untangle server.

Other

• Ability to search large settings grids (Application Control Application List, Web Filter Categories, etc)
• Many bugfixes