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, it traditional 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 maintainence 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 maintanence.

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 enable, 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 imaging themselves with the configured settings.

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

• Many bugfixes