Security

The following section covers all security services provided by the next generation firewall. These are available as submenus under the main “Security” menu in the portal as shown below. The options are as follows:

  • Firewall (IP, port and application access control and URL Filtering)

  • Security Profiles – Antivirus, URL Filtering, IPS Vulnerability, IP Filtering

  • NAT (Static and Destination NAT)

  • Decryption

  • SSL Certificates

  • DDoS (IP based DoS policy creation)

  • Secure log forwarding

Security 01

Firewall

The Firewall Management provides users with the ability to create, view, edit and capture log files for IP and application traffic between LAN, WAN and DMZ zones. In addition, traffic rules can be created for Local Internet Breakout (LIB) or over the SD WAN overlay network. These rules can apply to traffic inbound and outbound to the LAN and DMZ.

Management of Firewall rules via the SD WAN Portal is dependent on user role and if the site has a Firewall enabled.

Not all rules are visible. Bespoke rules can be provisioned directly into the Versa Director due to specific customer requirements outside the current SD WAN product description. Bespoke rules can be made visible, but editing those roles isn’t possible by using the rule naming convention ‘COLT-’.

Not all sites will have the LIB and SD WAN Firewall enabled and will depend on the configuration and service requirements at each site.

On delivery there is a single unchangeable rule that denies all traffic from the LAN to the Internet. Rules can be added above it to allow or deny access to the internet, based on application, protocol, addresses and port numbers.

Pre-created, or existing rules can be enabled, disabled or deleted. Likewise logging can be enabled or disabled by slide buttons associated with each rule. Log files can be viewed as text or downloaded in CSV format files.

Existing rules can also be edited by selecting them and using the edit button.

Firewall 01

After this first step you can add source and destination ports, as well as the IP addresses which the rule applies to, and then specify the action you would like to take upon that, either allowing, denying or rejecting traffic. If no addresses or ports are added the rule will apply to all for that protocol. Where addresses are added they must specify a subnet, e.g. 10.1.1.0/24. For a single rule multiple address ranges/subnet can be added with the ‘ADD +’ button. Ports can be added as a single port, e.g. 45000, or a range, e.g. 45000-50000.

Rules are applied after the “Add” button is clicked. There is a short period of time (a few seconds) before the rule is submitted and it take effect at the site.

Firewall 02

You can always add new rules to apply by clicking on the ‘Add New Firewall Rule’ button or delete them by clicking on the trash bin.

You can change the priority of rules by dragging them holding the mouse left button and dropping them where required in the list off rules.

Rules can be duplicated using the duplicate icon as shown below.

Firewall 03

You can revert to an older rule set by clicking the drop down in the top centre of page title ‘Current’ and select a version and click revert.

IPv6: There is the chance to verify IPv6 is present in Summary page under LAN and VRF’s section. User can enter an IPv6 address wherever IP address is allowed, except under Internet Traffic.

Click on ‘Add new Firewall (for SD WAN traffic only)’ / ‘Add new Policy’ to create a rule with IPv6 addresses.

Firewall rules can be created using the ‘Add new Firewall rule’ button. New rules can be created for Internet Inbound and Outbound traffic or SD WAN Inbound and Outbound traffic. Mandatory options for new Firewall rules require the following fields to be completed:

  • Name – Representative name, no spaces

  • Source Networks

  • Destination Networks

  • Action – Allow, deny traffic with this rule

Specific match criteria for the rule can be added, otherwise the default behaviour will allow or deny any traffic from the selected VPN depending on the direction of the traffic. In general, the match traffic can be:

  • Source IP – IP address or range, multiple address or ranges can be added

  • Destination – IP address or range, multiple address or ranges can be added

  • Protocol – Protocol per IP address match

  • Application – Selected from the drop down list

Once created, submitted, and committed, the Firewall rule logging is disabled by default. Firewall log rules can be enabled using the slide button option. Firewall log files can be viewed by selecting the “View Logs” icon for each rule, which displays a tabular view that can be downloaded as a CSV file.

Firewall 04
Firewall 05
log file space is limited to 10,000 per customer and therefore high usage of log file collection may result in records being overwritten or lost.

Security Profiles

Anti-virus

To enable Anti-virus profiles, they should first be created under the “Security Profiles” tab, and then subsequently associated to a specific firewall rule. Anti-virus is a chargeable feature under the name ‘Security+’ (together with IPS Vulnerability). The feature needs to be purchased before the functionality will be visible in the Portal.
Anti virus 01

Versa SD WAN supports an Anti-virus capability. This is selected from the ‘Security’ tab and under this the ‘Security Profiles’ tab. After the entire file is received, extracted and buffered, the file is transferred to the destination except the last data packet. Once the virus scan is performed the rest of the file is transferred or blocked to the destination depending upon the action defined in the policy.

Anti virus 02

Following are the requirements to be referred for development of Antivirus solution

  • Name: Name of the rule being defined

  • Description: Description of the rule being defined

  • Direction: The user needs to select the antivirus scanning of file extracting only from Upload or Download direction, or both.

  • Action: The user needs to define the action taken on the file type in question, either Allow, Deny, Reject or Alert. This also needs to be defined for when the disk is full.

  • Action on disk full: As above but in the situation that the disk is full.

  • File Types: The user selects the file type that the extraction should apply to, for example ppptx, torrent, appleplist, doc, jpeg, msi and many others.

  • Protocols: The user selects the protocols that the extraction should apply to, for example FTP, HTTP, IMAP, POP3, SMTP.

URL Filtering

To enable URL Filtering profiles, they should first be created under the “Security Profiles” tab, and then subsequently associated to a specific firewall rule.

The SD WAN Portal allows users to create and manage rules that override the default behaviour for each category of URL. These rules are created by defining URL filtering profiles which are then associated with firewall rules.

URL Filtering 01

In order to start the process of adding or editing URL filters user has to: Edit the site, select Add or edit firewall rule, select outbound rules and select action apply security profile to configure URL filtering:

URL Filtering 02

A default action can be enabled for all URL, categories or threats with exceptions being added as individual Whitelist, Blacklist, Category or Reputation rules. The actions available are as follows:

  • Alert: Allow the URL and generate an entry in the URL filtering log.

  • Allow: Allow the URL without generating an entry in the URL filtering log.

  • Ask: The browser presents an information page that allows the user to either cancel the operation by clicking Cancel or continue with the operation by clicking OK (for HTTP and HTTPS).

  • Block: Block the URL and generate an entry in the URL filtering log. No response page is displayed, and the user cannot continue with the website.

  • Justify: The browser presents an information page that allows the user to either cancel the operation by clicking Cancel or continue with the operation after entering a justification message and clicking OK (for HTTP and HTTPS).

For HTTPS (encrypted) websites, a block or captive portal page is only displayed when SSL decryption is enabled. If SSL decryption is not enabled, blocked HTTPS connections are reset or dropped.
Actions specific to category and reputation will take precedence over the default action. If any of the URLs are categorized or have certain reputation selected for filtering, then the highest severity action will be used for traffic filtering. The customer can choose to apply either a single filtering methodology or to utilize multiple filtering options like category, reputation, blacklist, whitelist.
Regex expressions are provided by the user. There are several reference guides providing lists and usage of regex. An example of which, can be found here.

Black and White list rules can be created for single URL or expressions as shown below, with options that override the default – Alert, Allow, Block. Multiple strings or patterns can be added for the same rules. The definition of Black and Whitelist behaviours are as follows:

Blacklisted URLs:

  • You can specify either fixed strings or regex patterns to match the blacklist URL. Specify the blacklist action that you want to enforce for all the matching HTTP flows. If the blacklist action is not configured, the default drop session action is enforced.

Whitelisted URLs:

  • For whitelist URLs, you can specify either fix strings or PCRE patterns to match the whitelist URLs. The URLs that match the whitelist configuration are allowed without enforcing any security actions. Optionally, you can enable logging in the whitelist configuration to receive whitelisted URLs access.

The following table defines the behaviour of the URL Filtering and Captive Portal policy, action and the end user devices.

CP -Working Conditions URLF-Policy CP action-Ask/Justify SSL Decryption policy Certificate installed in End user system

Captive portal works

Yes

Yes

Yes

Captive portal Not work

No

No

No

No

Yes

Yes

No

No

Yes

Yes

No

No

Yes

Yes

No

Patterns and strings can be entered in list form or pasted into the list view so that multiple URL and patterns can be configured in a single URL Filter.
URL Filtering 03

With pattern matches, the regular expression is validated and warning is shown if expressions are invalid.

URL Filtering 04

Likewise, URL category and reputation can be set as shown in the screen shot below.

The order of precedence is based on the following priority value, with the highest value taking precedence:

{ 1, VP_POLICY_ACTION_ALLOW },
{ 2, VP_POLICY_ACTION_INFORM },
{ 3, VP_POLICY_ACTION_ASK },
{ 4, VP_POLICY_ACTION_JUSTIFY },
{ 5, VP_POLICY_ACTION_OVERRIDE },
{ 6, VP_POLICY_ACTION_BLOCK },
{ 7, VP_POLICY_ACTION_RST_CLNT_SRVR },
{ 8, VP_POLICY_ACTION_DROP_PKT },
{ 8, VP_POLICY_ACTION_DROP_SESS },
URL Filtering 05

URL Filter logging of Allow URLs can be enabled or disabled per rule in the same way as Firewall or DDOS rules are. To View URL Filter log files´ rules, select and search for the period of log file history from Day, Week, Month or Custom Date.

The URL log file is presented in a text based tabular view as shown below. They can be downloaded as CSV files.

URL Filtering 06

Decryption Bypass in URL Filtering:

You can create Custom URL Categories that will appear in the URL Categories tab for URL filtering with possible actions of Allow and Alert.

Use URL Categories in URL Filtering profiles: Security > Security Profiles > URL Filtering

Decryption Bypass 09
Decryption Bypass 04

You can make use of decryption bypass in a URL Filtering profile, by referencing a User Defined URL category that has been created in the Objects tab.

IDS/IPS Vulnerability

To enable IPS Vulnerability profiles, they should first be created under the “Security Profiles” tab, and then subsequently associated to a specific firewall rule. IPS Vulnerability is a chargeable feature under the name ‘Security+’ (together with Anti-virus). The feature needs to be purchased before the functionality will be visible in the Portal.

Versa FlexVNF provides the IDP feature to defend against the malicious exploitation of vulnerabilities within various underlying software/hardware within the customer´s network. It will be supported from Next Generation Firewall service enabled CPEs. Currently the following functionality is supported:

  • User-Defined vulnerability profile: User-Defined vulnerability profiles have many attributes and options which can be customized as per the user’s requirements. It uses a user-defined signature database for vulnerability protection. The signature database is constantly updated via the Security package. Colt update the Security package frequently.

  • Predefined vulnerability profile: Predefined vulnerability profiles are predefined and cannot be modified. Predefined vulnerability profiles use their own set of signatures for vulnerability protection. The predefined profile can be directly attached to the Security access policy. The signature database keeps updated via the Security package. Colt update the Security package frequently.

    Currently supported predefined vulnerabilities by Versa:

    • All Anomaly Rules—This profile loads all the anomaly signatures.

    • All Attack Rules— This profile loads all attack signatures.

    • Client Protection— This profile loads all client-side attack detections.

    • Database Profile—This profile loads the oracle database server vulnerability signatures.

    • ICS Profile—This profile loads the Industrial Control System (ICS) vulnerability signatures.

    • Linux OS Profile—This profile detects all attacks specific to Linux OS.

    • MAC OS Profile—This profile detects all attacks specific to MAC OS.

    • Malware Profile—This profile detects all antivirus attacks.

    • Server Protection—This profile detects server-side attack detections.

    • Windows OS Profile—This profile detects attacks specific to all windows OS.

    • Versa Recommended Profile

  • Override the Vulnerability profile: Override profile is used to modify the action defined in the predefined vulnerability profile. If the action type in predefined profile is rejected, it can be changed to alert using the override profile.

  • Predefined Signature: Versa provides the predefined signature via security package updates. Colt shall update the package accordingly

  • Unified Threat Monitoring / Analytics: The SD WAN Portal shall display the top threats and vulnerabilities with signature IDs from different sources/destinations.

To create an IDS profile the user should select Security – Security Profiles – IPS Vulnerability as shown below from which the addition of User Defined or Predefined Override Profiles can be selected:

IDS IPS Vulnerability 01

If the user would like to add a new User Defined Profile, they need to click on "+ Add new profile", then "+ Add new rule" and the following window opens:

IDS IPS Vulnerability 02

The user then needs to insert the following details:

  • Name: Name of the rule being defined

  • Action: Action on match – either Allow, Alert, Drop Packet, Drop Session, Reject

  • Direction: Client, Server or both

    • Client Protection: Client requests which gets initiated to a host server, hosting web, mail, file service etc. are protected to prevent the user from downloading a virus and/or preventing intrusions.

    • Server Protection: For those customers who wish to publish their services to the internet, protection can be applied for such incoming malicious attempts. In such case the protection can be applied in the firewall rule where access is enabled for the server. In this example all incoming traffic to the services are inspected through IDP & AV and the clean traffic gets forwarded to the server.

  • CVSS Scores: The Common Vulnerability Scoring System (CVSS) provides a way to capture the principal characteristics of a vulnerability and produce a numerical score reflecting its severity. The numerical score can then be translated into a qualitative representation (such as low, medium, high, and critical) to help organizations properly assess and prioritize their vulnerability management processes.

  • Confidences: This metric measures the degree of confidence in the existence of the vulnerability and the credibility of the known technical details. Sometimes only the existence of vulnerabilities is publicised, but without specific details. For example, an impact may be recognized as undesirable, but the root cause may not be known. The vulnerability may later be corroborated by research which suggests where the vulnerability may lie, though the research may not be certain. Finally, a vulnerability may be confirmed through acknowledgment by the author or vendor of the affected technology. The urgency of a vulnerability is higher when a vulnerability is known to exist with certainty. This metric also suggests the level of technical knowledge available to would-be attackers.

  • General: CVE Years, Class Types - CVE stands for Common Vulnerabilities and Exposures. A unique, alphanumeric identifier assigned by the CVE Program. Each identifier references a specific vulnerability. A CVE ID enables automation and multiple parties to discuss, share, and correlate information about a specific vulnerability, knowing they are referring to the same thing. Class types generally refer to the type of vulnerability.

  • OS/Product: CVE Years, Class Types – as above.

  • Application: Details about specific applications

  • Reference Severity: Any details about the reference severity.

Additionally, the user can define exception rules (Select "+ Add new rule" and then click on the "Exceptions" tab) which will open the window below.

IDS IPS Vulnerability 03

After selecting ‘Exception Details’ tab, specified IP addresses can be added under the exception list and they will be bypassed.

IP Filtering

To enable IP Filtering profiles, they should first be created under the “Security Profiles” tab, and then subsequently associated to a specific firewall rule.

Traffic passing through the network may have IP addresses that are associated with a bad reputation and that may pose a security risk to your network. It is part of Colt’s IPS feature to block these IP addresses. This can be done based on IP address reputation and IP address metadata such as geolocation. You can configure IP address filtering profiles and then associate them with a security policy.

IP filtering is based on the reputation associated with an IP address and its geolocation where you can filter traffic based on IP reputation and IP address metadata (that is, geolocation). Versa Networks provides an IP reputation feed that is updated through SPACK updates. This will be supported from Next Generation Firewall (NGFW)service enabled CPEs.

Next Generation Firewall policy with IP filtering profile:

We should be able to configure one or more IP-filtering profiles under the NGFW access policy rules. This is enforced only for the traffic that matches that rule. IP filtering Profiles support user defined profiles where you are allowed to create rules for both IP reputation and Geolocation based filtering. Each IP filtering profile consists of the following:

  1. Rules for geolocation-based actions- It will be supported with either one or multiple actions in one profile

  2. Rules for IP reputation–based actions -It will be supported with either one or multiple actions in one profile

IP reputation:

IP filter profile supports using the following predefined IP reputations:

  • BotNets

  • Denial of service

  • Phishing

  • Proxy

  • Reputation

  • Scanners

  • Spam sources

  • Web attacks

  • Windows exploits

Geolocation:

Colt provides a list of predefined regions that offered by Versa, that you can use to create IP filter profiles based on geolocation. In addition, this will support matching the IP address based on the following match criteria:

  • Source IP address

  • Destination IP address

  • Source or destination IP address

  • Source and destination IP address

You can enforce the following actions when a session’s IP address matches the conditions in the IP filtering profile:

  • Allow

  • Alert

  • Drop packet

  • Drop session

  • Reset

The default action will be in effect, if the user-defined actions are not matched for the customer traffic, similar to URLF. The IP filtering profile will override the URL filtering profiles (URLF), even if they match the same traffic pattern. Therefore, it must be created accordingly to meet customer requirements through the SDWAN portal.

NAT Rules

Static/DNAT is available for Advanced Firewall services and for Internet inbound and outbound traffic. The NAT rules are viewed and configured through a separate menu of options as shown below. The NAT rules are for DNAT and Static NAT. Each option provides the ability to view, edit and add.

NAT Rules 01

DNAT rules

DNAT rules apply to traffic inbound from the Internet WAN link and is supported as standard on single CPE. A single CPE with multiple Internet links only supports DNAT on the primary Internet link.

DNAT/SNAT is not supported for Dual CPE in the SD WAN portal but is available as a bespoke solution.

Rules can be viewed and edited as other Firewall rules by selecting the rule and then selecting "Edit" to make changes. New rules can be added using the "+ Add new rule" button. When the DNAT rule is created, the access control rule has to be created manually with allow action for the set of IP addresses, port and protocol. Please see screenshot below.

NAT Rules 02
  • Precedence levels can be set for the same NAT IP addresses, but different protocol or port mapping (see DNAT-2 below)

  • WAN Interface IP addresses cannot be used for NAT. WAN Subnet and additional WAN Subnets can be used

  • DNAT addresses are supported for IPv4 WAN to IPv4 only

  • DNAT rules can be added for traffic between WAN-LANx and WAN-DMZx zones

  • DNAT is not available between LAN- DMZ

The following fields are configured for DNAT:

  • Name: Rule name to reference or describe the rule

  • VPN: Private subnet the NAT target address will come from

  • Source IP: Source IP address and subnet from the Internet to the LAN

  • Public IP: WAN IP address that should be matched to translate the IP address

  • Protocol: Protocol type (drop down list) and port number to be matched by the inbound Internet traffic. The port number can be single or a range

  • Private LAN/DMZ IP: Target IP address and subnet for DNAT to translate public to private

  • Private LAN/DMZ Port: Target Port or Port range for DNAT to translate public to private

  • Action: Allow or deny the traffic

  • Direction: The DNAT can be applied for to traffic flowing both inbound and outbound to the LAN VPN

The screen shots below show the fields.

NAT Rules 03

Static NAT

Static NAT rules apply to traffic inbound from the Internet WAN link and is supported as standard on single CPE or dual CPE with single Internet WAN link.

SNAT is not support for Dual CPE in the SD WAN portal but is available as a bespoke solution.

The Static NAT provides the ability to translate an IPv4 address assigned as either part of the WAN subnet or an additional IPv4 WAN subnet address pool to a single IP address on either the LAN or DMZ zones.

NAT Rules 04
  • Precedence levels can be set for the same NAT IP addresses, but different protocol or port mapping.

  • WAN Interface IP address cannot be used for static NAT. WAN Subnet or separate WAN Subnet can be sued for NAT

  • Static address static NAT supported for IPv4 WAN to IPv4 only

  • Static NAT rules can be added for traffic between WAN-LANx and WAN-DMZx zones

  • Static NAT is not available between LAN- DMZ

  • Dual CPE with Multiple Internet WAN links are bespoke solutions and require a specific design.

New rules can be added by selecting add new rule, the key fields are:

  • Name: Reference or description of rule (no blanks or spaces)

  • VPN: LAN/DMZ subnet that the NAT IP address will come from

  • Precedence: Order and priority to assign to this NAT, i.e. the same IP address can be used but with a different translation

  • NAT IP: Public IP address as a single IP with /32 as the mask

  • Internal LAN/DMZ IP: Single IP address from the AN or DMZ private subnet assigned to the VPN

Restricted Remote IP – This is an optional field that helps to limit access by IP address (/32) when enabled with static NAT. This restriction will be applicable for bi-directional communication between client and server.

Decryption

The decryption option allows rules for when decryption is and isn’t applied. This is only possible once a certificate has been created or uploaded. Users will be prompted to create a certificate if none are present.

It is worth noting that the following behaviours, that are outside the Colt´s control, might occur. Therefore please note the following:

  • With decryption on, some websites might take longer to load.

  • With certain decryption settings, websites with expired or invalid certificate might load incorrectly or not load at all.

  • If a trusted website which needs to be accessed regularly is showing problems with decryption enabled, it is advisable to make an exception on decryption for that/those websites.

For the captive portal to work, you must enable SSL decryption in order to redirect URL requests to the captive portal pages. If you do not enable SSL decryption, the SSL connection is allowed if the captive portal action is set to Inform, and the connection is reset if the action is set to Block, Ask, Justify, or Override.
Captive portal related actions ask and justify should only be enabled in combination with an existing certificate and decryption rule

There are two types of certificates which are supported in the SDWAN portal.

  • Self- signed certificate

  • Customer CA signed certificate.

SSL decryption profile required certificate which can be generated in the customer CPE(FlexVNF) itself as self-signed certificate in SDWAN portal. Customer signed certificate has to be uploaded to the SD WAN portal to proceed with configuring SSL decryption policy in SDWAN portal.

In case of customer signed certificate, Root CA certificate should be required for ssl decryption which might have basic CA attribute (Subject type= CA, Path length = None/Zero). Password/Passphrase will not be supported for private key.

Once certificates have been created decryption rules appear as for Local Internet and SDWAN as shown below. Rules can be enabled or disabled by slider as well as edited, duplicated and deleted once the site enabled for editing.

Decryption 01

If a certificate is created, but no rules are added the default behaviour is that no decryption is performed.

Rules can be added to match source and Source/Destination IP addresses and Services and to Decrypt or No-Decrypt. These rules can be applied to Self-Signed or Customer Managed SSL certificates. In addition the rule can be for outbound or inbound and applied to a specific protocol.

Decryption 02

On top of this, Predfined and User Defined URL Categories are available for the Decryption rule that applies a "No-Decrypt" action.

Decryption 05

In addition, to control and filtering of valid certificates, those that are invalid can be managed by selecting an action: Allow, Alert or Block. These actions are by default disabled as shown in the screenshot below.

Decryption 03
A Decryption rule with a Decrypt action (from LAN to INT) can reference a URL Filtering Profile in “URL Filtering Profile Override” to action the Decrypt Bypass.
Decryption Bypass 07
A Decryption rule with a No decrypt action (from LAN to INT) can reference a Predefined or User Defined URL Categories Object.
Decryption Bypass 08

SSL Certificates

A customer can choose to generate self-signed certificates or upload their own CA certificates using the SSL Certificate menu option. Once selected the user will be able to see a list of current certificates and their status.

Self-signed certificates, which are time limited, will be displayed as a red cross under availability to indicate tha the certificate is either invalid or expired.

A new self-signed certificate can be generated by clicking on the icon on the far right of the “Self-Signed Certificate” line. This will reveal all the fields and conditions needed to generate a certificate, as shown below, including expiry conditions and key length.

SSL Certificates 01
  1. Customers with dual CPE have to generate a SSL key for each CPE. In the screenshot below, the slider button will automatically do this if enabled. However this won’t be visible in the SDWAN Portal for single CPE customers.

  2. In Dual CPE and Self-Signed Certificate scenarios, both certificates (from primary and secondary CPEs) need to be uploaded into the end devices.

SSL Certificates 02

Likewise, customer managed certificates can be uploaded by file or string and pasted into the certificate window as well as the Private key. Note that for SSL rules, these can’t be bulk copied between sites.

SSL Certificates 03

After upgrading VD to version 22, CA Chain certificates will also need to be uploaded as an extra security step that comes with this upgrade.

SSL Certificates 04

DDoS Management

DDoS is not supported for Dual CPE in the SD WAN portal but is available as a bespoke solution.

DDoS profiles can be created, edited and deleted. Logging can be enabled independently on each rule.

DDoS Management 01

DDoS policies may be added by using the "+ Add new rule" button and the fields can be populated as shown below, with threshold value for activation, alarm and drop periods being defined by Portal users. The key fields are:

  • Name: Descriptive reference

  • Flood Protection Protocol: Identify which protocol DDoS protection rule applies too

  • Source IP: IP address and subnet DDoS traffic may originate (IPv4 or IPv6)

  • Destination IP: WAN IP or LAN/DMZ Address and Subnet being protected (IPv4 or IPv6)

  • Destination Port: Single or port range

  • Alarm Rate: The threshold rate at which to generate a DoS alarm, in packets per second.

  • Activate Rate: The threshold rate at which to activate a DoS response, in packets per second

  • Maximal Rate: The threshold rate of incoming packets, in packets per second. When this threshold is exceeded, all packets are dropped.

For an aggregate DDoS protection profile, this limit applies to all the traffic processed by the DDoS protection rule with which this DDoS protection profile is associated.

For a classified DDoS protection profile, this limit applies to the traffic on a classified basis (based on the source IP address, destination IP address, or both), for the traffic processed by the DDoS protection rule with which this DDoS protection profile is associated.

DDoS Management 02

The “Add” button creates a rule which can be edited, and logging enabled.

DDoS logging can be enabled by slide button as shown below:

DDoS Management 03

DDOS Log files can be searched for, by selecting the “Show DDOS logs” button to show a search by Day, Week, Month or Custom date range.

image160

If log files are available they can be viewed in tabular form or downloaded as a CSV file. The tabular view shows the site name, date type of attack/protocol, attacked IP address and action.

DDoS Management 05

The Log files can also be viewed in Chart form by selecting the Chart View option.

DDoS Management 06

Secure Log Forwarding

There is a growing demand for streaming logs to third party collectors in many products. For SD WAN, customers subscribing to firewall features may require firewall service logs for audit and compliance perspective. As such, this feature allows CPE firewall log delivery to a Third Party collector for a branch site.

For Secure Log Forwarding we are not supporting the collector being hosted in the Internet. If the customer site has local internet breakout enabled, to ensure logs are forwarded securely, it is highly recommended to configure a deny firewall rule before any existing rules and also should match LAN-Zone(s) and the destination log collector IP. See the portal screenshots on the next page:
When configuring collectors for Secure Log Forwarding (SLF) and NetFlow on the same server, please make sure that the combination of Destination Address and Destination Port is unique for each collector. This means you cannot use the same IP address and port combination for both SLF and NetFlow collectors.
Secure Log Forwarding 01

The rule should be established as below:

Secure Log Forwarding 02

To configure CPE log forwarding for a specific site, first the customer needs to select the ‘Security’ tab in the main menu and then underneath this, the ‘Secure Log Forwarding’ tab as shown below.

Secure Log Forwarding 03

The customer will need to take the following steps to configure CPE log forwarding:

  • Click on the ‘Edit Site’ button at the top right of the screen

Input the various attributes associated:
Firstly click ‘Add new collector’ – the following input dialogue opens:

Secure Log Forwarding 04

The following data needs then to be inputted by the user:

  • VPN / Routing instance: The network needs to be defined i.e. LAN1, LAN2

  • IP Address: The collector server IPv4 address

  • Port: The destination port which will be used to establish a session

  • Protocol: Select ‘TCP’ or ‘UDP’. Note that With Protocol UDP, only one collector is allowed. With TCP, customer can configure two collectors. If two collectors are chosen then the user should select one as a primary and an additional option is provided to suspend the backup collector if preferred

  • Log type: Select whether ‘IPFix’ or ‘Syslog’ as appropriate

After this then the logging event settings can be defined: Start / End / Both. Once this is selected then the ‘Enable Secure Log Forwarding’ needs to be pressed and the settings saved to enable the feature.

By default this profile is then applied to all firewall rules and security features that have logging enabled. Additional firewall rules and security features can be added and will have the Secure Log Forwarding profile added by default if the user selects logging when the rule is established.

Versa SASE (Secure Access Servide Edge)

We are introducing Versa SASE - Secure Access Service Edge (SASE) integration into the SDWAN Portal. This integration standardizes the connectivity between Colt Versa SDWAN sites and the SASE services offered by Versa. SASE is a network security feature, that has cloud-based security appliances and streamlined traffic routing to SASE Gateways through the public Internet. This feature ensures a safe and secure online experience, by offering:

  • Comprehensive Security Features: SASE delivers a comprehensive set of security features for internet, cloud services, and private applications.

  • Access Control: Manage and control user access to ensure only authorized users gain entry.

  • Threat Protection: Guards against online threats, providing protection from malicious activities and cyberattacks.

  • Data Security: Ensures the confidentiality and safety of your data.

  • Security Monitoring: Monitors online activities, offering real-time insights and alerts for suspicious events.

  • Acceptable Use Control: Enforces policies regarding internet and application usage to align with organizational rules.

With the growing importance of SASE as a service choice for our customers, it’s important that your SDWAN Portal reflects the SASE characteristics.

The SDWAN Portal has been updated to support this integration. It can now offer the capability to:

  • Identify SASE-Enabled Sites: Easily discern which sites have SASE capability.

Versa SASE 01
  • Tunnel Visibility: The portal displays SASE tunnel details and their status, providing a comprehensive overview of your network’s security infrastructure.

Versa SASE 02
  • CLI Commands: A console interface allows you to execute CLI commands associated with your SASE interfaces.

Versa SASE 03
  • Analytics View: Insights on DIA (Direct Internet Access)

Versa SASE 04

The user must navigate to the Versa SASE button from the ribbon, which takes them to the Concerto portal, in order to configure the desired policies.

Versa SASE 05

For the configuration the following principles apply:

  • 2 IPsec tunnels, Primary and Backup, are necessary.

  • In single CPE scenarios SASE can be enabled if at least 1 IPsec tunnel is up.

  • In dual CPE scenarios SASE can be enabled if only 1 IPSec tunnel is up in the primary CPE.

  • Traffic is only available over Internet interfaces, not MPLS.

  • All internet-based traffic is forwarded through the SASE tunnel by default, but users still have the option to define specific traffic flows to go through the LIB or CIB.

After Colt configures the tunnels for SASE in the SD WAN portal, the user can refresh the page in order to see the updated status of the tunnels and also use the Versa SASE breakout button to activate/deactivate SASE.

This button does not affect the tunnels, but only dictates the traffic. The button is located under the “Site Settings” tab.
Versa SASE 06
Versa SASE 07

In addition, it’s essential to understand how traffic behaves when LIB or CIB is activated in the context of Versa SASE, specifically LIB, CIB and Versa SASE: When LIB is enabled for a site along with SASE, traffic by default will always be sent over the preferred SASE GW. In the event that the routes from SASE GW are not available, traffic will be sent over LIB. If CIB is also enabled for customers, there will be an additional backup default route. However, for the traffic to reach the Internet via LIB or CIB, the users need to configure the appropriate firewall and Internet traffic steering rules via the SD WAN portal. Last, if the user wishes to remove SASE, it´s recommendable that LIB or CIB are active with the appropriate Firewall rules in order to avoid potential issues on the traffic.

If there is an app steering policy created, then the above default behaviour can be overriden and the path followed can be the one set via the policy.

ZScaler SSE (Security Service Edge)

We are introducing Zscaler SSE integration into the SDWAN portal that brings in a significant enhancement, enabling the integration of SDWAN with Zscaler’s Security Service Edge solution. SSE, is a set of comprehensive security features designed to safeguard your access to the internet, cloud services, and private applications. These features ensure a safe and secure online experience, by offering:

  • Access Control: SSE helps manage who can access what, ensuring that only authorized users get in.

  • Threat Protection: It stands guard against online threats, protecting you from malicious activities and cyberattacks.

  • Data Security: SSE keeps your data safe. Your information remains confidential.

  • Security Monitoring: It keeps an eye on your online activities, providing real-time insights and alerts if something suspicious is happening.

  • Acceptable Use Control: SSE helps enforce policies about how the internet and applications can be used, making sure everything is in line with your organization’s rules.

Zscaler, a cloud-based security-as-a-service offering requires the establishment of GRE tunnels between Versa CPE and Zscaler (Zen) Nodes to efficiently route customer traffic through its cloud-based security appliances. To meet this demand and reflect the crucial tunnel details on the SDWAN Portal, we’ve introduced several key capabilities:

  • Identify Zscaler SSE sites: Easily discern which sites have Zscaler SSE capability.

ZSCALER SSE 01
  • Tunnel Visibility: The portal displays Zscaler tunnel details and their status, providing a comprehensive overview of your network’s security infrastructure.

ZSCALER SSE 02
  • CLI Commands: A console interface allows you to execute CLI commands associated with your SSE interfaces.

ZSCALER SSE 03
  • Analytics View: Insights on DIA (Direct Internet Access)

ZSCALER SSE 04

The user must navigate to the ZScaler SSE button from the ribbon, which takes them to the ZScaler portal, in order to configure the desired policies.

ZSCALER SSE 05

For the configuration the following principles apply:

  • 2 GRE tunnels, Primary and Backup, are necessary.

  • ZEN node traffic is only available over Internet interfaces, not MPLS.

  • BGP routing into the customer LAN is possible, involving the redistribution of static routes.

  • All internet-based traffic is forwarded through the tunnel by default, but users still have the option to define specific traffic flows via LIB.

After Colt configures the tunnel for SSE in the SD WAN portal, the customer can use the Zscaler SSE breakout button to activate/deactivate SSE.

This button does not affect the tunnels, but only dictates the traffic. The button is located under the “Site Settings” tab.
ZSCALER SSE 06
ZSCALER SSE 07

In addition, it’s essential to understand how traffic behaves when LIB or CIB is activated in the context of Zscaler SSE, specifically LIB, CIB and Zscaler SSE: When LIB is enabled for a site along with SSE, traffic by default will always be sent over the preferred SSE GW. In the event that the routes from SSE GW are not available, traffic will be sent over LIB. If CIB is also enabled for customers, there will be an additional backup default route. However, for the traffic to reach the Internet via LIB or CIB, the users need to configure the appropriate firewall and internet traffic steering rules via the SD WAN portal.