Working with Failover Cluster Nodes and Storage

The previous entries in this section have gone through the most complex sections of Failover Cluster Manager as it applies to Hyper-V. Most of the tool’s remaining functions deal with the supporting infrastructure for a cluster and are much less involved with the virtual machines. If you’re building up and configuring a brand new cluster, these areas are where you’ll spend a lot of your initial time. For a functioning cluster, they still contain useful information but won’t be frequently accessed.

How to Manage Hyper-V Cluster Nodes in Failover Cluster Manager

In the left pane underneath the cluster that you wish to work with, the second tree item is Nodes. This is where you’ll find the physical systems that perform the virtualization hosting for your cluster. If you have hosts that perform other roles for this cluster but are not cluster members, such as storage nodes, they should not appear here.

While it is technically possible for a single cluster to operate multiple roles, such as Hyper-V and Scale-Out File Server (SOFS), a single cluster cannot serve as both the storage platform and the virtualization platform for the same Hyper-V guests. Differing host types should be placed in separate clusters. The only secondary role supported in a Hyper-V cluster is the Hyper-V Replica Broker.

The typical node view should look something like the following. In this cluster, all nodes are present with a status of Up:

There are two context menus to work with in this section. As with all other aspects of Failover Cluster Manager, you can access an object’s context menu by either right-clicking it or by left-clicking it and looking in the panes at the far right.

For the Nodes tree object itself, there is only one unique item: Add Node. Clicking this will take you through the same screens that you saw in the first section of this application’s tour, except that the outcome will be the addition of a new node to an existing cluster rather than the creation of an all-new cluster. If you proceed through the wizard, you’ll be notified of the need to perform a cluster validation. Remember that you might need an up-to-date validation report if you contact Microsoft support.

The other items on the Roles tree node’s context menu are standard. You can customize the columns that appear in the center pane by selecting Customize, which is the only option in the View sub-tree. By default, you are shown the Assigned Vote and Current Vote columns, which give you the status of the cluster’s quorum. There is also an Information column that is usually empty, but will contain a preview of any error states. The last menu option allows you to Refresh the center pane to have Failover Cluster Manager re-check the status of the nodes. Finally, you can click Help to see Failover Cluster Manager’s MMC help window.

The context menu for a node is more complex, although not nearly to the same degree as what you saw for virtual machines in the Roles node.

Node Context Menu: Pause

Pausing a node makes it an ineligible target for role migrations. The node is still given a vote for quorum and remains in full communication with the other nodes. This is an ideal state if you wish to perform short-term manual maintenance operations on the node. This menu has two sub-menu items: Drain Roles and Do Not Drain Roles.

If you opt to perform a drain, the cluster will attempt to move all roles on that node to other nodes in the cluster based on its own balancing algorithms. Active guests with a priority of Medium or higher will be Live Migrated; all others will be Quick Migrated. Even if the drain operation is not fully successful, the node will be paused in order to prevent it from accepting any new roles.

Node Context Menu: Resume

The Resume option has the same options as the Pause menu in reverse: Fail Roles Back and Do Not Fail Roles Back. If you choose to perform failback, all roles that were migrated as part of the initial drain operation are retrieved after the node is resumed. Otherwise, they are left where they are.

Node Context Menu: Remote Desktop

This menu option starts the Remote Desktop Client, automatically targeted at the node.

Node Context Menu: Information Details

If any operation resulted in an error status, the Information column will show a short preview. Use this menu item to display the complete error message.

Node Context Menu: Show Critical Events

This menu item will spawn a minimalist event viewer window that shows critical events related to node and quorum management. Despite the implications in the context menu and the spawned window’s title bar text, the events are for all nodes.

Node Context Menu: More Actions

The More Actions menu gives you three sub-items. The first two are Stop Cluster Service and Start Cluster Service. In the current version of Failover Clustering, the outcome of stopping the cluster service in this fashion is very similar to the drain operation, with the exception that the cluster service (clussvc.exe) is gracefully halted. All of the node’s roles are drained and it cannot receive any incoming roles. The node will retain its quorum vote, although Dynamic Quorum may choose to rescind it.

The Start Cluster Service option will not restore drained roles. It will start the service, reattach the node to the cluster, and, if necessary, restore its quorum vote.

The final option on the More Actions menu is Evict. This should only be used when a node is being decommissioned or has failed entirely. In earlier versions of Failover Clustering, evicting a node was a fairly common troubleshooting step. It should no longer be necessary in current versions. Evicting a node does cause configuration information to be lost, so, even if rejoined, pre-existing validation reports may become invalidated.

How to Manipulate Storage for Hyper-V in Failover Cluster Manager

The storage node of Failover Cluster Manager allows you to work with cluster-controlled storage. Hyper-V does work perfectly well with virtual machines that are placed on file servers running SMB (storage message block) protocol version 3 or later. Version 3 debuted with Windows Server 2012. These storage locations are not controlled by the cluster and cannot be managed through Failover Cluster Manager. It can only work with standard cluster disks and Cluster Shared Volumes.

The Storage node has two sub-nodes of its own: Disks and Pools. Pools are used with Scale-Out File Servers
(SOFS). It is technically possible to run Hyper-V roles and SOFS on the same cluster, but the virtual machines cannot be placed on space used by the same cluster’s SOFS. In addition to being unsupported, the system will error if you attempt to create such a “loopback” configuration.

Disks

For a Hyper-V cluster, the Disks sub-node is typically of much greater use. The only situation in which it would not contain any information is if you are not using a disk witness for quorum and all guests are stored on SMB 3 storage. In order for this section to be of any use, you must have connected shared storage to every one of the nodes using common direct-attached storage through an external SCSI interface, an iSCSI link, or a fibre channel link.

Each shared storage location must be formatted with NTFS or ReFS. A disk to be used for quorum must be formatted with NTFS. The details of preparing storage are not part of this tour. Storage will be talked about in more detail in a later article, but you can find detailed guidance on how to connect storage to a Hyper-V system here. Making the connections on the nodes will not automatically make them available to the cluster. That can be done through this section of Failover Cluster Manager.

To begin, select the Disks node in the left pane and access its context menu. The very first item is Add Disk. If there is no unused storage connected to every node, you’ll receive a dialog indicating as much:

If one or more disks are available, you’ll see something like the following:

The cluster automatically determines the Resource Name by using the text “Cluster Disk” and incrementing a number. Disk Info helps you to identify what is being connected, as it does not read volume information such as labels. The signature can also be used to identify the disk; it’s retrievable by using Get-Disk. When adding several disks at once that are of equal size, be certain to match them when accessing this screen as it will not be so readily available after being attached to the cluster. Check the box(es) for the disk(s) you’d like to add and click OK. Each disk should then appear in the center pane:

The next item in the Disks sub-node’s context menu is Move Available Storage. Its sub-options are the same for virtual machine migrations: Best Possible Node and Select Node. These items operate only on standard cluster disks; quorum disks and Cluster Shared Volumes are unaffected. Every single cluster disk is moved if possible.

The remaining options in this node are the standard View, Refresh, and Help items which work as they do elsewhere in Failover Cluster Manager.

Disk Items Context Menu

The items in the center pane represent the disk-based storage assigned to the cluster. They have a dynamic context menu. Each item is presented below in alphabetical order.

Add to Cluster Shared Volumes: This option is only available for standard cluster disks. Once used, the disk is converted to a CSV. It no longer appears as a separate disk attached to a singular cluster node but becomes an entity underneath C:\ClusterStorage on all nodes. A folder named Volume# will be created to represent this disk. It can be renamed, but doing so after virtual machines are placed on it will cause those virtual machines to break. Any virtual machines that were on the cluster disk before it was converted will also be broken.
Bring Online: This returns an offline object to online status. All disk types are eligible.
Information Details: If the previous operation on this item in this console resulted in an error, this entry will become active. Clicking it will spawn a dialog with details about the error.
Move: The Move option is only available for Cluster Shared Volumes. It reassigns ownership to another node, either automatically with the sub-item Best Possible Node or by manual selection using Select Node.
More Actions: As with the menu it’s found in, this displays a dynamic menu with the following possible options:
- Assign to another role: In a Hyper-V cluster, this menu item is not useful. You do have the ability to assign it directly to a virtual machine role, but that doesn’t grant any special abilities to the virtual machine that it doesn’t already have. Virtual machines can already use any cluster disk as a pass-through disk. Using this menu item could help visually reinforce that a particular virtual machine is using it as pass-through storage.
- Repair: This item becomes active for a disk in an offline state. This menu item is to be used In the event that the disk is offline because it has permanently failed and you are replacing it. The replacement disk must be attached to storage but must not have been added as a cluster disk; if it was added, remove it. Upon clicking Repair, a dialog will appear with all available storage. Choose the item that will replace the failed disk.
  
  Upon selecting the replacement item, it will be added into the cluster with the name of the disk that was replaced. You will be prompted to bring it online to complete the repair.
- Show Dependency Report: This item is of little use in a Hyper-V cluster as disk resources are not assigned directly to roles. For CSVs, it will display the underlying Cluster Disk resource.
- Simulate Failure: Triggers the configured failure action for a standard cluster disk or the quorum disk.
- Turn off Maintenance Mode: Restores a disk object that was previously placed in Maintenance Mode to normal operation.
- Turn on Maintenance Mode: This mode removes protections against tools such as CHKDSK from running against the volume and disables the cluster’s automated health checks. When activated against a Cluster Shared Volume, you receive a warning that roles will be taken offline; this is not true for virtual machines. However, the volume’s representation under C:\ClusterStorage will disappear and virtual machines in that space cannot be Live Migrated until Maintenance Mode is ended.
Properties: A properties dialog will be displayed that will change depending upon the selected item. These will be explored after this list.
Remove: The selected standard cluster disk is removed from cluster disks. Virtual machines on it will instantly crash.
Remove from role: If a cluster disk is assigned to a role, a menu item will appear allowing you to return it to Available Storage.
Remove from Cluster Shared Volumes: The selected CSV is returned from CSV status to standard disk status. Any hosted virtual machines will instantly crash.
Show Critical Events: A minimal event viewer dialog is shown with any available critical events about the selected resource.
Take Offline: use this to take any disk resource offline. Any active virtual machines using this storage will instantly crash.

Properties Dialog for Cluster Shared Volumes

Of the three cluster disk types, the properties dialog for a CSV is the simplest:

The only modifiable control is the Name. This name is only used by Failover Cluster Manager and Failover Clustering. It does not change the way that virtual machines refer to their storage. You can change this at any time. The list box shows four sets of information. Volume is the logical path that the CSV is referred to on each node. This can be renamed using traditional file system commands and tools, but doing so after virtual machines are created on it will cause their links to break. Redirected Access indicates if the volume is in Redirected Access mode. Capacity shows the total space on the disk and Free Space displays how much of that space is unused.

Properties Dialog for Standard Cluster Disks and Quorum Disks

The properties dialog is identical for the other two types. It contains a series of tabs. The first is the General tab and it looks very similar to the properties dialog for the CSV:

You can use this page to rename the cluster disk. As with a CSV, nothing is harmed by performing this operation. This dialog shows the cluster’s disk number, which can be referenced with the text-based tools and Disk Management. The center pane shows similar information to that of a CSV, although instead of a symbolic link path, the Volume is the drive letter, if one is assigned, or a raw volume identifier. Since cluster disks do not support Redirected Access mode, that column is not present.

The Dependencies tab will not show anything for the typical cluster disk in a Hyper-V environment since they are not commonly attached to roles. The Policies, and Advanced Polices tabs are identical in content and function to those for other cluster resources and were examined in the two preceding articles in this series.

The unique item on this dialog is the Shadow Copies tab. This setting is node independent and should be used instead of the traditional setting in Windows Explorer.

Details Pane

When a single cluster disk is selected in the center pane, that center pane will be divided into upper and lower sections. The lower section will show a quick summary of the item:

You can quickly see the space utilization for the volume and its drive letter or raw volume identifier (standard cluster disks and quorum disks) or its symbolic link (CSVs). In this pane, the item has a single-item context menu. A quorum or standard cluster disk will have the option to Change Drive Letter, which displays a very simple dialog allowing you to clear the drive letter or assign a new one from the available letters. A Cluster Shared Volume will give you the option to Turn On Redirected Access Mode if it is off or turn it on otherwise.

How to Manage Hyper-V-Related Cluster Networks in Failover Cluster Manager

The next cluster tree item after Disks is Networks. This section gives access to the networking resources as managed by the cluster. Clicking this tree node will display all of the networks that the cluster is aware of in the center pane. By default, the cluster names them as Cluster Network 1, Cluster Network 2, etc.

The way that Failover Clustering identifies a network is by subnet. Every unique subnet discovered on each host will be displayed here. If a host has two or more adapters in the same subnet, only one of them will be displayed. If any host does not have an adapter in a subnet that can be found on other nodes, that network will be considered Partitioned. Configuring the subnets is a topic that’s tackled in the Networking article. As this is just a tour of the tool, it’s assumed that all of your subnets are already configured as desired.

The tree node itself has only a single unique item: Live Migration Settings. The others are the standard View, Refresh, and Help items. Clicking the Live Migration Settings item will display a dialog box similar to the following:

This dialog allows you to prioritize how Live Migration will utilize available networks. It should be used judiciously to prevent Live Migrations from drowning out other types of communication. Live Migration traffic will only be allowed on networks that are checked (those networks must also be marked to allow cluster traffic, which will be demonstrated shortly). Items at the top of the dialog will be given preference when networks are selected. If the sending and receiving nodes are both set to use SMB for Live Migration and SMB multichannel is active, all selected networks will carry Live Migration traffic.

Networks List Entries and Context Menus

The center pane of the Networks section of Failover Cluster Manager looks like the following:

The upper portion shows the name, status, and allowed traffic for each network. The context menu for these items contains only three entries: Information Details, Show Critical Events, and Properties. As is common to previously discussed objects in Failover Cluster Manager, the Information Details link shows a pop-up dialog with details about any error message caused in this session and Show Critical Events displays any error events involving the selected item. Properties opens the properties dialog for the item:

The first changeable control is the name. A network can be safely renamed at any time. The most common use of this feature is to give a meaningful description to the network.

The second control group indicates how the network is to be used.

Allow cluster network communication on this network grants the ability for cluster communications, such as heartbeat, Redirected Access, and Live Migrations to utilize the selected network.
Allow clients to connect through this network is not as meaningful in a Hyper-V cluster as for other cluster types. The network that the cluster name object (CNO) appears on should be marked for client access. Clustered Hyper-V does not expose its virtual machine roles through this network the way that other clustered roles do, so this check box serves no other purpose.
Do not allow cluster network communication on this network prohibits the cluster from using the network at all. This will prevent Live Migration traffic even if the network’s box is checked for Live Migration as shown in the preceding sub-section.

The remainder of this dialog shows the status of the network and the subnets that have been detected on it.

Details Pane

The initial dialog for this section showed the Summary pane for the details section. It displays the name of the network and its detected subnets. There is also a Network Connections tab which shows the adapters in the subnet:

If a network is partitioned, this can help you determine which node(s) have lost connectivity or have failed adapters. It can also help you to verify that adapters have been assigned to the correct subnet. The displayed name (Onboard in the above image) is the same name that the host’s management operating system shows for the adapter. These items have a context menu with the options Information Details and Show Critical Events.

Cluster Events

The final cluster tree node is Cluster Events. This contains a display that is very similar to that of the standard Windows Event Viewer. It has been automatically filtered to contain a specific subset of the cluster-related events. Not all possible events are shown. The default view appears below:

The Cluster Events node does have a context menu, displayed on the right in the above screenshot. It will not be discussed in detail here, as it is quite similar to that found in the traditional Event Viewer. One item to point out to those that are not familiar with that interface is Query. Clicking this will show the following dialog, which you can use to tailor what appears here:

Other items in the context menu can be used to further manipulate the query, if you so desire.

A second notable item in this list is Reset Recent Events. This clears the view, but it does not remove the events themselves. It also has the effect of resetting the icon that Failover Cluster uses for the cluster back to its default as shown below:

Wrapping up in the GUI

This concludes the tour of Failover Cluster Manager and the unit on the built-in graphical tools to manage Hyper-V and Failover Clustering. These sections have taken a very thorough look at these tools and their capabilities and will serve as a reference as you work through the rest of the material and in into the future.

Source :
https://www.altaro.com/hyper-v/failover-cluster-manager/nodes-storage/

web-based tool can help identify server applications that may be affected by the Log4Shell (CVE-2021-44228, CVE-2021-45046) vulnerability

This web-based tool can help identify server applications that may be affected by the Log4Shell (CVE-2021-44228, CVE-2021-45046) vulnerability.

It allows you to generate a request that you can run in your environment and test if the server is vulnerable.

There are three options for using this tool:

Use the generated JNDI snapshot and add that entry to any of the form fields on the site or add this to the HTTP Header for User-Agent.
- Your unique JNDI snapshot is ${jndi:ldap://log4j-tester.trendmicro.com:1389/b64c656f-ffcb-4fda-a06b-a4b8753e03cb}
For Internal Server: Generate a quick curl command to test your servers.
For Public Facing Server: Just provide the address of the server and we will try to create a simulated query. Make sure you are hitting some API endpoint/form which eventually does an action in the backend. If the unique ID provided here shows up in the results section below, the server may be vulnerable and should be investigated further. If it does not show up, it does not guarantee that the server is not vulnerable.

To learn more on how to use this tool, please visit https://www.youtube.com/watch?v=7uix6nDoLBs. The use of this tool is subject to the Trend Micro Free Tools Terms and Conditions.

Testing

Use the following tool to test your application endpoints. GET POST with User-Agent HTTP Headerwith X-Api-Version Headerwith URL Parameterswith Form Datawith custom HTTP HeaderObfuscate data

System environment variables
System properties
Lower/Upper
Lower special

Send request

You can use the generated cURL command below for testing:URL

curl...

Windows Mac/Linux

Results

If you submit and see results here, that means the server may be vulnerable and should be investigated further. If there are no results, it does not guarantee that the server is not vulnerable. This table will be refreshed every 10 seconds.

Next refresh in 4 seconds.

Unique ID	Timestamp

Information

CVE-2021-44228

“Log4Shell” and “Logjam.” Apache Log4j2 <=2.14.1 is vulnerable to remote code execution by downloading code from LDAP server using JNDI.Read more

CVE-2021-45046

Apache Log4j 2.15.0 is vulnerable to a denial of service (DOS) attack when using ThreadContext values and context lookups.Read more

Protection and Investigation

Analysis and Advisory – From Trend Micro Threat ResearchRead more

Credits

Trend Micro’s vulnerability scanner is based on the following projects:

HOWTO: Disable weak protocols, cipher suites and hashing algorithms on Web Application Proxies, AD FS Servers and Windows Servers running Azure AD Connect

Most Microsoft-based Hybrid Identity implementations use Active Directory Federation Services (AD FS) Servers, Web Application Proxies and Azure AD Connect installations. In this series, labeled Hardening Hybrid Identity, we’re looking at hardening these implementations, using recommended practices.

Note:
This blogpost assumes all Web Application Proxies, AD FS servers and Azure AD Connect installations run Windows Server 2016.

Why harden

Hardening provides additional layers to defense in depth approaches. It changes the default behavior of products and services to make them more resilient to unauthorized changes and compromise.

REASONS WHY

Protocols, cipher suites and hashing algorithms are used to encrypt communications in every Hybrid Identity implementation. Typically, ciphers and algorithms to use are based on a negotiation between both ends of a communications channel. The purpose is to use the most secure protocols, cipher suites and hashing algorithms that both ends support. To use the strongest ciphers and algorithms it’s important to disable the ciphers and algorithms you no longer want to see used.

Microsoft recommends organizations to use strong protocols, cipher suites and hashing algorithms. For Azure Active Directory, they are changing the negotiation settings on their systems regularly, to avoid downgrades in encryption standards.

POSSIBLE NEGATIVE IMPACT (WHAT COULD GO WRONG?)

When the systems of an Hybrid Identity implementation are improperly hardened, there will be no communication between Azure Active Directory and the systems of the implementation, and/or between the systems of the Hybrid Identity implementation.

This may affect authentications directly when using Active Directory Federation Services (AD FS) or Pass-through Authentication as authentication method in the Hybrid Identity implementation. This may cause diminished functionality, when Password Hash Sync (PHS) is used as the authentication method. Also, this may cause certificates to expire, monitoring to halt and/or backups to fail. It may also mean admins will no longer be able to (remotely) manage the systems.

When using the Remote Desktop Protocol (RDP) to manage the Windows Server installations of the Hybrid Identity implementation, the default security layer in RDP is set to Negotiate which supports both SSL (TLS 1.0) and the RDP Security Layer. Open Remote Desktop Session Host Configuration in Administrative Tools and double-click RDP-Tcp under the Connections group. If it is set to SSL (TLS 1.0) and you are running Windows Server 2008, make sure that you have installed TLS 1.1 and 1.2 support.

For Hybrid Identity implementations featuring Azure AD Connect’s Seamless Single Sign-on (3SO), do not disable RC4_HMAC_MD5 at this time, as this may break.

Getting Ready

To disable weak protocols, cipher suites and hashing algorithms on Web Application Proxies, AD FS Servers and Windows Servers running Azure AD Connect, make sure to meet the following requirements:

SYSTEM REQUIREMENTS

Make sure all systems in scope are installed with the latest cumulative Windows Updates. Also make sure you run the latest stable version of Azure AD Connect.

PRIVILEGE REQUIREMENTS

Make sure to sign in with an account that has privileges to create and/or change and link Group Policy objects to the Organizational Unit (OU) in which the systems in scope reside.

WHO TO COMMUNICATE TO

When intending to make changes to systems in the Hybrid Identity implementation, make sure to send a heads-up to these people and/or teams in your organization:

Load balancers and networking guys and gals
The Active Directory team
The people responsible for backups, restores and disaster recovery
The people going through the logs, using a SIEM and/or a TSCM solution
The monitoring team

One of the challenges you can easily avoid through communications is that multiple persons and/or teams make changes to the configuration. When it breaks, you don’t want to roll-back a bunch of changes, just the one that broke it. Make sure you have the proper freeze/unfreeze moments to achieve that.

Determining weak protocols, cipher suites and hashing algorithms

Encryption methods are comprised of:

A protocol, like PCT, SSL and TLS
A key exchange method, like ECDHE, DHE and RSA
A cipher suite, like AES, MD5, RC4 and 3DES

PROTOCOLS

For the purpose of this blogpost, I’ll stick to disabling the following protocols:

PCT v1.0
SSL v2
SSL v3
TLS v1.0
TLS v1.1

Note:
PCT v1.0 is disabled by default on Windows Server Operating Systems.
SSL v2 is disabled, by default, in Windows Server 2016, and later versions of Windows Server.

CIPHER SUITES AND HASHING ALGORITHMS

For the purpose of this blogpost, I’ll stick to disabling the following ciphers suites and hashing algorithms:

RC2
RC4
MD5
3DES
DES
NULL
All cipher suites marked as EXPORT

Note:
NULL cipher suites provide no encryption.

Note:
The above list is a snapshot of weak ciphers and algorithms dating July 2019. Please consult the SSL Labs Documentation for actual guidance on weak ciphers and algorithms to disable for your organization.

Protocols, cipher suites and hashing algorithms and the negotiation order to use

For the purpose of this blogpost, I’ll stick with the following protocols, cipher suites and hashing algorithms, in the following negotiation order:

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

This list provides a preference to cipher suites that offer Perfect Forwarding Secrecy (PFS) with the elliptic curve Diffie-Hellman key exchange (ECDHE_*).

How to disable weak protocols

As the systems in scope may or may not be of Active Directory Domain Services, may or may not run Server Core and may or may not allow downloading 3rd party tools, but in all cases you can disable weak protocols using Windows PowerShell with the following scripts:

Note:
As SSL v2 is disabled and removed from Windows Server 2016, and up, and SSL v3 is disabled by default in Windows Server 2016, and up, these protocols do not need to be disabled on Windows Server 2016, and newer versions of Windows Server.

ENABLE TLS 1.2

To enable TLS 1.2, run the following Windows PowerShell script in an elevated PowerShell window on each of the Windows Server installations in scope of the Hybrid Identity implementation:

Note:
The DisabledByDefault registry value doesn’t mean that the protocol is disabled by default. It means the protocol isn’t advertised as available by default during negotiations, but is available if specifically requested.

$SChannelRegPath = “HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols”

New-Item $SChannelRegPath”\TLS 1.2\Server” -Force

New-Item $SChannelRegPath”\TLS 1.2\Client” -Force

New-ItemProperty -Path $SChannelRegPath”\TLS 1.2\Server” `
-Name Enabled -Value 1 -PropertyType DWORD

New-ItemProperty -Path $SChannelRegPath”\TLS 1.2\Server” `
-Name DisabledByDefault -Value 0 -PropertyType DWORD

New-ItemProperty -Path $SChannelRegPath”\TLS 1.2\Client” `
-Name Enabled -Value 1 -PropertyType DWORD

New-ItemProperty -Path $SChannelRegPath”\TLS 1.2\Client” `
-Name DisabledByDefault -Value 0 -PropertyType DWORD

CONFIGURING .NET APPLICATIONS TO USE TLS 1.1 AND TLS 1.2

Now, we need to configure .Net applications to use either TLS 1.1 or TLS 1.2. This is important for built-in Windows functionality and 3rd party applications and services. Run the following Windows PowerShell script in the same elevated PowerShell window as the previous one:

$RegPath1 = “HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319”

New-ItemProperty -path $RegPath1 `
-name SystemDefaultTlsVersions -value 1 -PropertyType DWORD

New-ItemProperty -path $RegPath1 `
-name SchUseStrongCrypto -value 1 -PropertyType DWORD

$RegPath2 = “HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319”

New-ItemProperty -path $RegPath2 `
-name SystemDefaultTlsVersions -value 1 -PropertyType DWORD

New-ItemProperty -path $RegPath2 `
-name SchUseStrongCrypto -value 1 -PropertyType DWORD

DISABLE TLS 1.0 AND TLS 1.1

To disable TLS 1.0 and TLS 1.1, run the following Windows PowerShell script in the same elevated PowerShell window as the previous Windows PowerShell script on each of the Windows Server installations in scope of the Hybrid Identity implementation:

New-Item $SChannelRegPath -Name “TLS 1.0”

New-Item $SChannelRegPath”\TLS 1.0″ -Name SERVER

New-ItemProperty -Path $SChannelRegPath”\TLS 1.0\SERVER” `
-Name Enabled -Value 0 -PropertyType DWORD

New-Item $SChannelRegPath”\TLS 1.1\Server” –force

New-Item $SChannelRegPath”\TLS 1.1\Client” –force

New-ItemProperty -Path $SChannelRegPath”\TLS 1.1\Server” `
-Name Enabled -Value 0 -PropertyType DWORD

New-ItemProperty -Path $SChannelRegPath”\TLS 1.1\Server” `
-Name DisabledByDefault -Value 0 -PropertyType DWORD

New-ItemProperty -Path $SChannelRegPath”\TLS 1.1\Client” `
-Name Enabled -Value 0 -PropertyType DWORD

New-ItemProperty -Path $SChannelRegPath”\TLS 1.1\Client” `
-Name DisabledByDefault -Value 0 -PropertyType DWORD

Restart the server after these configuration changes.

How to disable weak ciphers and algorithms

The systems in scope may or may not be of Active Directory Domain Services, may or may not run Server Core and may or may not allow downloading 3rd party tools. In all cases you can disable weak cipher suites and hashing algorithms by disabling individual TLS cipher suites using Windows PowerShell.

Note:
The below lines of PowerShell do not change the negotiation order of the cipher suites and hashing algorithms. It merely disables individual combinations of unwanted cipher suites and hashing algorithms. This also eliminates the need to keep up with the cipher suites in Windows Server between Windows Server version releases and even between updates.
A win-win situation if you’d ask me!

Tip!
To get an overview of the current negotiation order, use the following line of PowerShell:

Get-TlsCipherSuite | Format-Table Name

Use the following lines on Windows Server 2016 installations to remove weak cipher suites and hashing algorithms:

Disable-TlsCipherSuite -Name “TLS_DHE_RSA_WITH_AES_256_CBC_SHA”
Disable-TlsCipherSuite -Name “TLS_DHE_RSA_WITH_AES_128_CBC_SHA”
Disable-TlsCipherSuite -Name “TLS_RSA_WITH_AES_256_GCM_SHA384”
Disable-TlsCipherSuite -Name “TLS_RSA_WITH_AES_128_GCM_SHA256”
Disable-TlsCipherSuite -Name “TLS_RSA_WITH_AES_256_CBC_SHA256”
Disable-TlsCipherSuite -Name “TLS_RSA_WITH_AES_128_CBC_SHA256”
Disable-TlsCipherSuite -Name “TLS_RSA_WITH_AES_256_CBC_SHA”
Disable-TlsCipherSuite -Name “TLS_RSA_WITH_AES_128_CBC_SHA”
Disable-TlsCipherSuite -Name “TLS_RSA_WITH_3DES_EDE_CBC_SHA”
Disable-TlsCipherSuite -Name “TLS_DHE_DSS_WITH_AES_256_CBC_SHA256”
Disable-TlsCipherSuite -Name “TLS_DHE_DSS_WITH_AES_128_CBC_SHA256”
Disable-TlsCipherSuite -Name “TLS_DHE_DSS_WITH_AES_256_CBC_SHA”
Disable-TlsCipherSuite -Name “TLS_DHE_DSS_WITH_AES_128_CBC_SHA”
Disable-TlsCipherSuite -Name “TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA”
Disable-TlsCipherSuite -Name “TLS_RSA_WITH_RC4_128_SHA”
Disable-TlsCipherSuite -Name “TLS_RSA_WITH_RC4_128_MD5”
Disable-TlsCipherSuite -Name “TLS_RSA_WITH_NULL_SHA256”
Disable-TlsCipherSuite -Name “TLS_RSA_WITH_NULL_SHA”
Disable-TlsCipherSuite -Name “TLS_PSK_WITH_AES_256_GCM_SHA384”
Disable-TlsCipherSuite -Name “TLS_PSK_WITH_AES_128_GCM_SHA256”
Disable-TlsCipherSuite -Name “TLS_PSK_WITH_AES_256_CBC_SHA384”
Disable-TlsCipherSuite -Name “TLS_PSK_WITH_AES_128_CBC_SHA256”
Disable-TlsCipherSuite -Name “TLS_PSK_WITH_NULL_SHA384”
Disable-TlsCipherSuite -Name “TLS_PSK_WITH_NULL_SHA256”

Testing proper hardening

After hardening it’s time to test the hardening. Everyone should sign off (not literally, unless that’s procedure) on the correct working of the Windows Servers running Azure AD Connect. Does authentication to cloud applications still work? Does rolling over the certificate still work? Does monitoring still work? Can we still make back-ups? Can we still restore the backups we make?

Typically, hardening is rolled out to one Windows Server. When testing the hardening of the functionality behind the load balancer, make sure that the load balancer points you to the hardened system, not another one. In an environment with a Staging Mode Azure AD Connect installation, the hardening can be performed on this Windows Server installation and tested with the normal Staging Mode (imports only) synchronization cycles. When hardening is approved upon, the actively synchronizing Azure AD Connect installation can be switched, or hardened, too.

Note:
The registry changes are step 2 of two steps to harden protocols, cipher suites and hashing algorithms of the Hybrid Identity implementation. Make sure to Enforce Azure AD Connect to use TLS 1.2 only on the Windows Servers running Azure AD Connect, before testing.

ROLLING BACK HARDENING

To roll back hardening, use the following lines of Windows PowerShell:

$SChannelRegPath = “HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols”

Remove-Item –Name “TLS 1.0” –Path $SChannelRegPath
Remove-Item –Name “TLS 1.1” –Path $SChannelRegPath
Remove-Item –Name “TLS 1.2” –Path $SChannelRegPath

Enable-TlsCipherSuite -Name “TLS_DHE_RSA_WITH_AES_256_CBC_SHA”
Enable-TlsCipherSuite -Name “TLS_DHE_RSA_WITH_AES_128_CBC_SHA”
Enable-TlsCipherSuite -Name “TLS_RSA_WITH_AES_256_GCM_SHA384”
Enable-TlsCipherSuite -Name “TLS_RSA_WITH_AES_128_GCM_SHA256”
Enable-TlsCipherSuite -Name “TLS_RSA_WITH_AES_256_CBC_SHA256”
Enable-TlsCipherSuite -Name “TLS_RSA_WITH_AES_128_CBC_SHA256”
Enable-TlsCipherSuite -Name “TLS_RSA_WITH_AES_256_CBC_SHA”
Enable-TlsCipherSuite -Name “TLS_RSA_WITH_AES_128_CBC_SHA”
Enable-TlsCipherSuite -Name “TLS_RSA_WITH_3DES_EDE_CBC_SHA”
Enable-TlsCipherSuite -Name “TLS_DHE_DSS_WITH_AES_256_CBC_SHA256”
Enable-TlsCipherSuite -Name “TLS_DHE_DSS_WITH_AES_128_CBC_SHA256”
Enable-TlsCipherSuite -Name “TLS_DHE_DSS_WITH_AES_256_CBC_SHA”
Enable-TlsCipherSuite -Name “TLS_DHE_DSS_WITH_AES_128_CBC_SHA”
Enable-TlsCipherSuite -Name “TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA”
Enable-TlsCipherSuite -Name “TLS_RSA_WITH_RC4_128_SHA”
Enable-TlsCipherSuite -Name “TLS_RSA_WITH_RC4_128_MD5”
Enable-TlsCipherSuite -Name “TLS_RSA_WITH_NULL_SHA256”
Enable-TlsCipherSuite -Name “TLS_RSA_WITH_NULL_SHA”
Enable-TlsCipherSuite -Name “TLS_PSK_WITH_AES_256_GCM_SHA384”
Enable-TlsCipherSuite -Name “TLS_PSK_WITH_AES_128_GCM_SHA256”
Enable-TlsCipherSuite -Name “TLS_PSK_WITH_AES_256_CBC_SHA384”
Enable-TlsCipherSuite -Name “TLS_PSK_WITH_AES_128_CBC_SHA256”
Enable-TlsCipherSuite -Name “TLS_PSK_WITH_NULL_SHA384”
Enable-TlsCipherSuite -Name “TLS_PSK_WITH_NULL_SHA256”

Concluding

Get rid of old protocols, cipher suites and hashing algorithms in your Hybrid Identity implementation, so they cannot be used to negotiate the security of the connections down.

Source :
https://dirteam.com/sander/2019/07/30/howto-disable-weak-protocols-cipher-suites-and-hashing-algorithms-on-web-application-proxies-ad-fs-servers-and-windows-servers-running-azure-ad-connect/

SECURITY ALERT: Apache Log4j “Log4Shell” Remote Code Execution 0-Day Vulnerability (CVE-2021-44228, CVE-2021-45046 and CVE-2021-45105)

SUMMARY

Updated on 12/29/2021 @ 2:00PM GMT with updated information about Trend Micro Log4Shell Vulnerability Assessment Tool and new CVE-2021-44832.

Jump directly to information on affected/not-affected Trend Micro Products

On December 9, 2021, a new critical 0-day vulnerability impacting multiple versions of the popular Apache Log4j 2 logging library was publicly disclosed that, if exploited, could result in Remote Code Execution (RCE) by logging a certain string on affected installations.

This specific vulnerability has been assigned CVE-2021-44228 and is also being commonly referred to as “Log4Shell” in various blogs and reports. Versions of the library said to be affected are versions 2.0-beta 9 to 2.14.1.https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-core/2.15.0/.

On December 14, 2021, information about a related vulnerability CVE-2021-45046 was released that recommended that users upgrade to at least version 2.16.0+ of Log4j 2.

Based on our analysis, the rules and protections listed below for CVE-2021-44228 are also effective against CVE-2021-45046.

On December 18, 2021, information about a potential “3rd wave” and version 2.17.0 has been released and assigned CVE-2021-45105. Information about protection is below and ZDI has a technical blog about it here: https://www.zerodayinitiative.com/blog/2021/12/17/cve-2021-45105-denial-of-service-via-uncontrolled-recursion-in-log4j-strsubstitutor .

On December 28th, yet another RCE (CVE-2021-44832) was discovered and disclosed. Although not as critical as the initial vulnerabilities (CVSS 6.6), it is still recommended that administrators do their due diligence to update to the latest version available (2.17.1).

Background

Log4j is an open-open source, Java-based logging utility that is widely deployed and used across a variety of enterprise applications, including many cloud services that utilize Apache web servers.

The vulnerability (assigned as CVE-2021-44228) is a Java Naming and Directory Interface^TM(JNDI) injection vulnerability in the affected versions of Log4j listed above. It can be triggered when a system using an affected version of Log4j 2 includes untrusted data in the logged message – which if this data includes a crafted malicious payload, a JNDI lookup is made to a malicious server. Depending on the information sent back (response) a malicious Java object may be loaded, which could eventually lead to RCE. In addition, attackers who can control log messages or their parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled.

The challenge with this vulnerability is widespread use of this particular logging utility in many enterprise and cloud applications. JDNI lookups support multiple protocols, but based on analysis so far, exploitability depends on the Java versions and configurations. From a practical standpoint, just because a server has implemented an affected version of Log4j 2, it does not automatically mean it is vulnerable depending on its configuration.

Trend Micro Research is continuing to analyze this vulnerability and its exploits and will update this article as more information becomes available. A comprehensive blog with more background information can be found here .DETAILS

Protection Against Exploitation

First and foremost, it is always highly recommended that users apply the vendor’s patches when they become available.

A new version of Log4j 2 has been released which reportedly resolves the issue: Version 2.17.1 is now availableand is the suggested update. Users with affected installations should consider updating this library at the earliest possible time.

Note: due to additional waves of new exploits, the previous manual mitigation steps published have proven not to be sufficient and have been removed.

Trend Micro Protection and Investigation

In addition to the vendor patch(s) that should be applied, Trend Micro has released some supplementary rules, filters and detection protection that may help provide additional protection and detection of malicious components associated with this attack servers that have not already been compromised or against further attempted attacks.

The following demo video highlights ways in which Trend Micro can help customers discover, detect and provide protection: https://www.youtube.com/watch?v=r_IggE3te6s.

Using Trend Micro Products for Investigation

Trend Micro Log4j Vulnerability ScannerTrend Micro Research has created a quick web-based scanning tool that can help users and administrators identify server applications that may be affected but the Log4Shell vulnerability.The tool can be found at: https://log4j-tester.trendmicro.com/ and a demo video can be found at: https://youtu.be/7uix6nDoLBs.

Trend Micro Log4Shell Vulnerability Assessment ToolTrend Micro also has created a free assessment tool that can quickly identify endpoints and server applications that may have Log4j using the power of Trend Micro Vision One.This quick and easy self-serve security assessment tool leverages complimentary access to the Trend Micro Vision One threat defense platform, so you can identify endpoints and server applications that may be affected by Log4Shell. The assessment instantly provides a detailed view of your attack surface and shares next steps to mitigate risks.

The free assessment tool can be found at: https://resources.trendmicro.com/Log4Shell-Vulnerability-Assessment.html .

Please note, if you are already a Trend Micro Vision One customer, you do not need to complete the form. Simply log into your console and you will be provided instructions to complete the assessment of your exposure.

Trend Micro Vision One™

Trend Micro Vision One customers benefit from XDR detection capabilities of the underlying products such as Apex One. In addition, depending on their data collection time range, Trend Micro Vision One customers may be able to sweep for IOCs retrospectively to identify if there was potential activity in this range to help in investigation.

Vision One Threat Intelligence Sweeping

Indicators for exploits associated with this vulnerability are now included in the Threat Intelligence Sweeping function of Trend Micro Vision One. Customers who have this enabled will now have the presence of the IOCs related to these threats added to their daily telemetry scans.

The first sweep, “Vulnerable version of log4j….” is slightly different than the others in that instead of specific IOCs, it is looking for specific instances of log4j libraries on systems which can help a customer narrow down or give additional insights on potentially vulnerable systems.

The results of the intelligence scans will populate in the WorkBench section of Vision One (as well as the sweep history of each unfolded threat intelligence report).

Please note that customers may also manually initiate a scan at any time by clicking the 3 dots at the right of a rule and selecting the “Start Sweeping” option.

Vision One Search Queries for Deep Security Deep Packet Inspection

Customers who have Trend Micro Cloud One – Workload Security or Deep Security may utilize the following search query to identify hosts and then additional queries can be made with a narrowed timeframe on those hosts as additional information is learned about exploits.

eventName:DEEP_PACKET_INSPECTION_EVENT AND (ruleId:1008610 OR ruleId:1011242 OR ruleId:1005177) AND ("${" AND ("lower:" OR "upper:" OR "sys:" OR "env:" OR "java:" OR "jndi:"))

Trend Micro Cloud One™ – Conformity

Trend Micro Cloud One – Conformity allows gives customers central visibility and real-time monitoring of their cloud infrastructure by enabling administrators to auto-check against nearly 1000 cloud service configuration best practices across 90+ services and avoid cloud service misconfigurations.

The following rules are available to all Trend Micro Cloud One – Conformity customers that may help provide more insight to customers looking to isolate affected machines (more information can be found here for rule configuration):

Lambda-001 : identifies all Lambdas that are running Java which may be vulnerable.

Approved/Golden AMIs (EC2-028) : can be used to look for vulnerable AMIs that are running Java.

Unrestricted Security Group Egress (EC2-033) : identifies security groups that may be associated with, for example, an EC2 that may be compromised and then has the ability to communicated externally.

Preventative Rules, Filters & Detection

A demo video of how Trend Micro Cloud One can help with this vulnerability can be found at: https://youtu.be/CorEsXv3Trc.

Trend Micro Cloud One – Workload Security and Deep Security IPS Rules

Rule 1011242 – Log4j Remote Code Execution Vulnerability (CVE-2021-44228)

This rule is recommended by default, and please note that the port lists may need to be updated for applications running on non-default ports.

Rule 1005177 – Restrict Java Bytecode File (Jar/Class) Download
Rule 1008610 – Block Object-Graph Navigation Language (OGNL) Expressions Initiation In Apache Struts HTTP Request

Rule 1008610 is a SMART rule that can be manually assigned to assist in protection/detection against suspicious activity that may be associated with this threat. This is not a comprehensive replacement for the vendor’s patch.

Please also note that rule 1008610 is shipped in DETECT, and must be manually changed to PREVENT if the administrator wishes to apply this. Also, please be aware that due to the nature of this rule, there may be False Positives in certain environments, so environment-specific testing is recommended.

Rule 1011249 – Apache Log4j Denial of Service Vulnerability (protects against CVE-2021-45105)

Trend Micro Cloud One – Workload Security and Deep Security Log Inspection

LI Rule 1011241 – Apache Log4j Remote Code Execution Vulnerability (CVE-2021-44228)
A custom LI rule can also be created to detect patterns as discovered in the future. More information can be found here.

Trend Micro Apex One Integrated Vulnerability Protection (iVP) Rules

Rule 1011242 – Log4j Remote Code Execution Vulnerability (CVE-2021-44228)
Rule 1011249 – Apache Log4j Denial of Service Vulnerability (protects against CVE-2021-45105)

Trend Micro Deep Discovery Inspector (DDI) Rules

Rule 4280: HTTP_POSSIBLE_USERAGENT_RCE_EXPLOIT_REQUEST
Rule 4641 : CVE-2021-44228 – OGNL EXPLOIT – HTTP(REQUEST)
Rule 4642 : POSSIBLE HTTP HEADER OGNL EXPRESSION EXPLOIT – HTTP(REQUEST)
Rule 4643: POSSIBLE HTTP BODY OGNL EXPRESSION EXPLOIT – HTTP (REQUEST) – Variant 2

Trend Micro Cloud One – Network Security and TippingPoint Recommended Actions

Filter 40627 : HTTP: JNDI Injection in HTTP Header or URI

This was released in Digital Vaccine #9621 and has replaced CSW C1000001 that was previously released.

Trend Micro recommends customers enable this filter in a block and notify posture for optimal coverage. Starting with Digital Vaccines released on 12/21/2021, it will be enabled by default. Since it may not be enabled in your environment, Trend Micro strongly recommends you confirm the filter is enabled in your policy.

Filter 40652: HTTP: Apache Log4j StrSubstitutor Denial-of-Service Vulnerability (ZDI-21-1541)
- Covers CVE-2021-45105

What other controls can be used to disrupt the attack?

This attack is successful when the exploit is used to initiate a transfer of a malicious attack payload. In addition to the filter above, these techniques can help disrupt that chain:

Geolocation filtering can be used to reduce possible attack vectors. Geolocation filtering can block inbound and outbound connections to any specified country, which may limit the ability for attackers to exploit the environment. In cases where a business only operates in certain regions of the globe, proactively blocking other countries may be advisable.
For TippingPoint IPS, TPS, and vTPS products
Trend Micro also recommends enabling DNS and URL reputation as a proactive means of securing an environment from this vulnerability. Leveraging Trend Micro’s rapidly evolving threat intelligence, TippingPoint appliances can help disrupt the chain of attack destined to known malicious hosts.

Additionally, Reputation filtering can be leveraged to block Anonymous proxies that are commonly used in exploit attempts. Any inbound or outbound connections to/from an anonymous proxy or anonymizer service can be blocked by configuring a reputation filter with “Reputation DV Exploit Type” set to “Tor Exit” to a Block action.
For Cloud One – Network Security
Anonymous proxies are also an independent, configurable “region” that can be selected as part of Geolocation filtering. This will block any inbound or outbound connection to/from an anonymous proxy or anonymizer service, which can be commonly used as part of exploit attempts.

Domain filtering can also be used to limit the attack vectors and disrupt the attack chain used to exploit this vulnerability. In this case, any outbound connection over TCP is dropped unless the domain being accessed is on a permit list. If the attacker’s domain, e.g. http://attacker.com, is not on the permit list, then it would be blocked by default, regardless of IPS filter policy.

Trend Micro Malware Detection Patterns (VSAPI, Predictive Learning, Behavioral Monitoring and WRS) for Endpoint, Servers, Mail & Gateway (e.g. Apex One, Worry-Free Business Security Services, Worry-Free Business Security Standard/Advanced, Deep Security w/Anti-malware, etc.)

Web Reputation (WRS): Trend Micro has added over 1700 URLs (and growing) to its WRS database to block that are linked to malicious reporting and communication vectors associated with observed exploits against this vulnerability.
Ransomware Detection – there have been observations about a major ransomware campaign (Khonsari) being utilized in attacks and Trend Micro detects components related to this as Ransom.MSIL.KHONSARI.YXBLN.
VSAPI (Pattern) Detections: the following detections have been released in the latest OPR for malicious code associated with exploits –
- Trojan.Linux.MIRAI.SEMR
- HS_MIRAI.SMF
- HS_MIRAI.SME
- Trojan.SH.CVE20207961.SM
- Backdoor.Linux.MIRAI.SEMR
- Trojan.SH.MIRAI.MKF
- Coinminer.Linux.KINSING.D
- Trojan.FRS.VSNTLB21
- Trojan.SH.MALXMR.UWELI
- Backdoor.SH.KIRABASH.YXBLL
- Backdoor.Linux.MIRAI.SMMR1
- Coinminer.SH.MALXMR.UWEKG
- Coinminer.Linux.MALXMR.SMDSL64
- Backdoor.Linux.GAFGYT.SMMR3
- Coinminer.Win64.MALXMR.TIAOODGY
- Rootkit.Linux.PROCHID.B
- ELF_SETAG.SM
- Backdoor.Linux.TSUNAMI.AMZ
- Coinminer.PS1.MALXMR.PFAIQ
- Trojan.SH.TSUNAMI.A
- Trojan.PS1.METERPRETER.E
- Coinminer.Linux.MALXRMR.PUWENN

Trend Micro Cloud One – Application Security

Trend Micro Cloud One – Application Security can monitor a running application and stop unexpected shell commands from executing. The product’s RCE configuration can be adjusted to help protect against certain exploits associated with this vulnerability using the following steps:

Log into Trend Micro Cloud One and navigate to Application Security.
Select “Group;s Policy” in the left-hand menu and find your application’s Group.
Enable “Remote Command Execution” if not already enabled.
Click the hamburger icon for “Configure Policy” and then click the ” < INSERT RULE > ” icon.
Input (?s).* in the “Enter a pattern to match” field and hit “Submit” and “Save Changes.”
Double-check that “Mitigate” is selected in your “Remote Command Execution” line item.

Trend Micro Cloud One – Open Source Security by Snyk

Trend Micro Cloud One – Open Source Security by Snyk can identify vulnerable versions of the log4j library across all organization source code repositories with very little integration effort. Once installed, it can also monitor progress on updating to non-vulnerable versions.

TXOne Preventative Rules for Edge Series Products

Several rules for the TXOne Edge Series of products can be found here: https://www.txone-networks.com/blog/content/critical-log4shell-vulnerability .

Trend Micro is continuing to actively research the potential exploits and behavior around this vulnerability and is actively looking for malicious code that may be associated with any exploit attempts against the vulnerability and will be adding additional detection and/or protection as they become available.

–

Impact on Trend Micro Products

Trend Micro is currently doing a product/service-wide assessment to see if any products or services may be affected by this vulnerability. Products will be added to the lists below as they are validated.

Products Confirmed Not Affected (Including SaaS Solutions that have been patched):

5G Mobile Network Security	Not Affected
ActiveUpdate	Not Affected
Apex Central (including as a Service)	Not Affected
Apex One (all versions including SaaS, Mac, and Edge Relay))	Not Affected
Cloud App Security	Resolved / Not Affected
Cloud Edge	Not Affected
Cloud One – Application Security	Not Affected
Cloud One – Common Services	Not Affected
Cloud One – Conformity	Not Affected
Cloud One – Container Security	Not Affected
Cloud One – File Storage Security	Not Affected
Cloud One – Network Security	Not Affected
Cloud One – Workload Security	Not Affected
Cloud Sandbox	Not Affected
Deep Discovery Analyzer	Not Affected
Deep Discovery Email Inspector	Not Affected
Deep Discovery Inspector	Not Affected
Deep Discovery Web Inspector	Not Affected
Deep Security	Not Affected
Endpoint Encryption	Not Affected
Fraudbuster	Not Affected
Home Network Security	Not Affected
Housecall	Not Affected
Instant Messaging Security	Not Affected
Internet Security for Mac (Consumer)	Not Affected
Interscan Messaging Security	Not Affected
Interscan Messaging Security Virtual Appliance (IMSVA)	Not Affected
Interscan Web Security Suite	Not Affected
Interscan Web Security Virtual Appliance (IWSVA)	Not Affected
Mobile Secuirty for Enterprise	Not Affected
Mobile Security for Android	Not Affected
Mobile Security for iOS	Not Affected
MyAccount (Consumer Sign-on)	Not Affected
Network Viruswall	Not Affected
OfficeScan	Not Affected
Password Manager	Not Affected
Phish Insight	Not Affected
Policy Manager	Not Affected
Portable Security	Not Affected
PortalProtect	Not Affected
Public Wifi Protection / VPN Proxy One Pro	Not Affected
Rescue Disk	Not Affected
Rootkit Buster	Not Affected
Safe Lock (TXOne Edition)	Not Affected
Safe Lock 2.0	Not Affected
Sandbox as a Service	Resolved / Not Affected
ScanMail for Exchange	Not Affected
ScanMail for IBM Domino	Not Affected
Security for NAS	Not Affected
ServerProtect (all versions)	Not Affected
Smart Home Network	Not Affected
Smart Protection Complete	Not Affected
Smart Protection for Endpoints	Not Affected
Smart Protection Server (SPS)	Not Affected
TippingPoint Accessories	Not Affected
TippingPoint IPS (N-, NX- and S-series)	Not Affected
TippingPoint Network Protection (AWS & Azure)	Not Affected
TippingPoint SMS	Not Affected
TippingPoint Threat Management Center (TMC)	Resolved / Not Affected
TippingPoint ThreatDV	Not Affected
TippingPoint TPS	Not Affected
TippingPoint TX-Series	Not Affected
TippingPoint Virtual SMS	Not Affected
TippingPoint Virtual TPS	Not Affected
TMUSB	Not Affected
Trend Micro Email Security & HES	Resolved / Not Affected
Trend Micro Endpoint Sensor	Not Affected
Trend Micro ID Security	Not Affected
Trend Micro Remote Manager	Not Affected
Trend Micro Security (Consumer)	Not Affected
Trend Micro Virtual Patch for Endpoint	Not Affected
Trend Micro Web Security	Resolved / Not Affected
TXOne (Edge Series)	Not Affected
TXOne (Stellar Series)	Not Affected
Vision One	Resolved / Not Affected
Worry-Free Business Security (on-prem)	Not Affected
Worry-Free Business Security Services	Not Affected

Affected Products:

Deep Discovery Director

Affected

Please click here for more info

References

Trend Micro Blog – Patch Now: Apache Log4j Vulnerability Called Lof4Shell Actively Exploited
Demo Video on Trend Micro Protection Against Log4Shell
Demo Video on Trend Micro Cloud One Protection
Demo Video on Using Trend Micro’s Log4j Vulnerability Scanning Tool
ZDI Blog on CVE-2021-45105

Source :
https://success.trendmicro.com/solution/000289940?mkt_tok=OTQ1LUNYRC0wNjIAAAGBUlOzNGxvi_7Cbd5hCo7M1KS9OoANyeARcT0Crf9e3bFO1dVGLCxVdccyh8RMRHxGqwXi0k9r967Rv5_FYxQM5l0UeQJXzwl8xR3_Jfab4XyH87irwjo

What is a Keylogger and How to Detect One

What is a keylogger?

A keylogger, which is also known as a keystroke logger or a keyboard capturer, is a piece of software or hardware developed to monitor and record everything you type on a keyboard. In this article, we dive into everything you need to know about them and teach you how to protect yourself from them!

Is a keystroke logger a virus?

It depends. Keyloggers were designed for legitimate purposes. They were originally used for computer troubleshooting, employee activity monitoring, and as a way to discover how users interact with programs so their user experience could be enhanced. However, they’ve since been used by hackers and criminals as a tool for stealing sensitive data such as usernames, passwords, bank account information, and other confidential information.

Generally, a keylogger is insidiously installed alongside an otherwise legitimate program. As a result, users are almost always unaware that their keystrokes a being monitored. Oftentimes, when a user’s computer is infected with a keylogger trojan, the malicious software will keep track of their keystrokes and save the information to their computer’s local drive. Later the hacker will retrieve the stored data. For this reason, keyloggers pose a serious threat to computer security and data privacy.

Keyloggers are separated into the following categories, based on how they work:

API-based

These keyloggers Application programming interfaces (APIs) allow software to communicate with hardware. API-based keyloggers intercept every keyboard input sent to the program you’re typing into.. This type of keylogger registers keystroke events as if it was a normal aspect of the application instead of malware. Each time a user presses or releases a key it is recorded.

Form grabbing-based

Form grabbing-based keyloggers log web form submissions by recording the inputted data when they are submitted. When a user submits a completed form, usually by clicking a button or pressing enter, their data is recorded even before it is passed over the Internet.

Kernel-based

These keyloggers work their way into a system’s core, allowing them access to admin-level permissions. These loggers have unrestricted access to everything entered into a computer system.

Javascript-based

A malicious script tag is injected into a targeted web page and it listens for keyboard events. Scripts can be injected using a variety of methods, including cross-site scripting, man-in-the-browser, and man-in-the-middle attacks, or when a website’s security is compromised.

How do keyloggers get on computers?

Most of the time, they infect computers with outdated antivirus software and ones without any antivirus software at all.

There are several scenarios that you need to be aware of:

Keyloggers can be installed through web page scripts. Hackers utilize web browser vulnerabilities and embed malicious code on a webpage that silently executes the installation or data hijacking.
Phishing. Keyloggers can be installed after users click on a nefarious link or open a malicious attachment in a phishing email.
Social engineering. Some criminals use psychological manipulation to fool unsuspecting people into installing a keylogger by invoking urgency, fear, or anxiety in them.
Unidentified software downloaded from the internet. Sometimes cracked software or applications from unidentified developers will secretly install a keylogger on a computer system.

How to detect a keylogger on my computer?

At this point, you might be interested in learning how you can detect a keylogger on your computer. The truth is, keyloggers are not easy to detect without the help of security software. Running a virus scan is necessary to detect them.

Trend Micro Housecall is an online security scanner that detects and removes viruses, worms, spyware, and other malicious threats such as keyloggers for free.

How to prevent keystroke logging malware?

Keyloggers are dangerous. Preventing them from ever being installed on your computer is a top priority. It is necessary to be proactive in protecting your computer to ensure that your data doesn’t get stolen.

Here are several tips to follow:

Carefully inspect user agreements for software before agreeing to them. There should always be a section covering how your data is used.
Install a trusted antivirus app such as TrendMicro Maximum Security. Always keep your antivirus on and regularly run scheduled scans of your device.
Make sure your security software is up to date.
Make sure your operating system is up to date and all the security patches are installed.
Avoid visiting suspicious websites and don’t click on any unusual links or e-mail attachments from unknown senders.
Only download and install software from trusted developers and sources.

Source :
https://news.trendmicro.com/2021/12/28/what-is-a-keylogger-and-how-to-detect-one/

10 Tips for a Safe and Happy Holiday

They’re not interested in peace on earth, a hippopotamus or their two front teeth. You won’t find them decking the halls, dashing through the snow or even up on the housetop. But that doesn’t mean cybercriminals aren’t out in force this time of year — and they’re relying on you being too wrapped up in your holiday preparations to see them coming.

They’re successful far too often: The last quarter of 2020 saw by far the most ransomware, with attacks in November reaching an all-time high in an already record-breaking year. If 2021 follows suit, this could be the worst holiday season for ransomware SonicWall has ever recorded — but fortunately, there are many things you can do to minimize your risk:

It’s the Most Wander-ful Time of the Year: Travel Tips

Roughly 63% of American adults plan to travel for the holidays this year — a nearly 40% jump over last year, and within 5% of 2019 levels. While it’s easy to become preoccupied by traffic jams, flight delays and severe weather, don’t forget that attackers love to leverage this sort of chaos. Follow these five travel best practices to keep cybercriminals grounded this holiday season.

1. Free Wi-Fi =/= Risk-Free Wi-Fi

When you stop for a coffee during your layover, or stumble into a greasy spoon on hour nine of your road trip back home, you might be tempted to log on to the free Wi-Fi. But unless your organization has implemented zero-trust security, beware. Try bringing a novel and coloring books to keep everyone occupied on the road, and if you must connect, use a VPN to access employer networks and avoid logging in to your bank, email or other sensitive accounts. Because some devices may try to connect to these networks automatically, you may need to disable auto-connect to fully protect against man-in-the-middle and other attacks.

2. Put Your Devices on Lockdown

Due to border restrictions finally beginning to ease in countries such as Canada, Australia, India and South Korea, and the United States, international travel is expected to be robust. In the U.S., roughly 2 million travelers are expected to pass through airports each day over the Christmas holiday. In crowds like this, it’s easy for a device to be misplaced, left behind or stolen. To limit potential damage from smartphones, laptops, tablets, etc. falling into the wrong hands, ensure they’re protected with facial recognition, fingerprint ID or a PIN. (This doesn’t just protect against data theft, it can also help combat regular theft: One study found that locked devices were three times more likely to be returned to their owners.)

3. Don’t Let Criminals Track You

Nearly 43% of Americans and 42% of Brits feel more comfortable traveling this year — but this doesn’t mean they should be comfortable with everyone knowing they’re traveling. Any location data you share on social media can be tempting to those wanting to break into homes or hotel rooms — whether to steal and exfiltrate data, or steal gaming consoles, jewelry, medications or even gifts under the tree.

4. Use Only Your Own Cords/Power Adapters

In our mobile-dependent society, it’s no surprise that cybercriminals have learned how to install malware in airport kiosks, USB charging stations and more. And while that “forgotten” iPhone charge cable might look tempting when your device is running on empty, even those can harbor malware. If you can’t find a secure charging area, ensure your device is powered off before plugging it in.

‘Tis the Season for Giving: Online Safety Tips

Even if you’re not traveling this year, chances are you’re buying gifts. While supply-chain challenges, pandemic considerations and more have made for a unique holiday shopping season, it’s important to put safety first when shopping online. Here are six things to look out for:

1. Holiday Phishing Emails

Perhaps you’ve received an invite to the Jones’ holiday party, a gift card or coupon, or an email from HR with details of an unexpected holiday bonus. If there’s an attachment, exercise extreme caution: It may harbor malware.

2. Spoofed Websites

Unfortunately for your wallet, emails boasting huge discounts at popular retailers are likely bogus. Walmart isn’t offering 70% off, and nobody is selling PlayStations for $100, not even during the holidays. If you enter your info into one of these lookalike retail (or charity) sites, the only thing you’re likely to get is your credentials stolen.

3. Fake Shipping Invoices

You’ve finished your shopping, and your gifts are on their way! But now FedEx is emailing to say your packages may not arrive in time and referring you to updated tracking information. Or your retailer is sending you a shipping label for returns, or verifying your gifts are being sent … to a completely different address. Look closely before you click: These emails usually aren’t from who they say they are.

4. Counterfeit Apps

Is that really the Target app or just a lookalike? Better double-check before you download and enter your payment information. Apple’s App Store and Google Play have safeguards in place to stop counterfeit apps, but some still occasionally get through.

5. Gift Card Scams

These originally took the form of “You’ve won a free gift card! Click here to claim!” In recent years, however, they’ve become more targeted, and may appear to offer gift cards as a bonus from your employer or a holiday gift from a friend. The easiest way to avoid being scammed? If you weren’t expecting a gift card from someone, ask them about it.

6. Santa’s Little Helpers

There are many services designed to send your child a letter from Santa for a small fee. But many times, these so-called “Santas” are really cybercriminals attempting to get you to click on a link and enter your payment information. A recent variation has scammers offering kits designed to take the stress and mess out of your elf’s holiday shenanigans (just move your elf and call it good!)

While the holiday season offers more than its share of scams, many can be put on ice with a little extra due diligence. Keep these holiday best practices in mind, and have a safe and happy holiday!

Source :
https://blog.sonicwall.com/en-us/2021/12/10-tips-for-a-safe-and-happy-holiday/

2021 VMware Major Developments, Releases, Updates & More!

Following a year that the world will remember for a long time to come (and mostly not for good reasons), we wrap up 2021 with a plethora of events happening in the tech industry. In the meantime, we certainly hope that you are doing well and staying safe during this upcoming festive period. In this article, we’ll recap the most important VMware news stories of the year and have a look ahead at what 2022 has in store. Let’s get going!

Company Growth

A lot has been going on this year in the VMware space, not only in a technical aspect but also with major changes within the company’s structure and management.

Financially, the company keeps doing very well with projected revenue of over $12.8 billion, an increase of around 9% compared to last year with expected significant growth in the SaaS area.

One of the axes VMware is also working on to generate revenue is the partner incentives program based on the customer life cycle. The new incentives reward partners that deliver PoCs, customers’ assessments and “sell-through” partners working together.

Acquisitions

VMware acquired a dizzying number of companies over the course of the previous year (2020). However, mergers are time-consuming and are never straightforward when it comes to restructuring teams, merging products into existing portfolios… VMware has put a lot of resources into integrating previous years’ acquisitions into their existing portfolios such as Carbon Black, Salt or Datrium.

This might be the reason why they only acquired one company in 2021 with Mesh7. Let’s have a closer look at what it is.

Mesh7

VMware acquired Mesh7 at the end of the first quarter of 2021. Their technology helps customers improve application resiliency, reliability and reduce blind spots through the integration of deep Layer 7 insights with cloud, host, and reputation data. They offer a distributed API Security Mesh solution (API Firewall and API Gateway) which is focused on securing the application layer at its core in Kubernetes environments.

VMware acquired Mesh7 at the end of March 2021 to further secure Tanzu Service Mesh

VMware uses Envoy as an open-source Layer 7 proxy in Tanzu Service Mesh and Mesh7’s API gateway is being integrated into the solution to further secure the Kubernetes connectivity solution.

VMworld 2021

As usual, let’s quickly recap what happened during VMworld 2021 which was, once again, a virtual event. We will only skim over the surface of what was announced as a lot of other areas were covered such as Security, Networking, End-User services… For more information about the announcements made during this event, head over to our dedicated VMworld 2021 Round-up Article.

Strong focus on multi-cloud

VMware followed the trend set in the previous year with a strong push towards multi-cloud and managed cloud services. VMware Cross-Cloud services will offer a bunch of multi-cloud services you can pick and choose from in a flexible manner to facilitate and accelerate customers’ adoption.

“VMware Cross-Cloud services aims at simplifying the shift to a multi-cloud SDDC”

VMware Sovereign Cloud tackles the issues around how sensitive data is dealt with through partnerships with Cloud providers. The goal is to offer those public entities and large organizations a data sovereignty seal of approval in a multi-cloud world.

Other announcements in the Cloud space included VMware Cloud on AWS Outpost and improvements to the disaster recovery as a service (DRaaS) offering.

Tanzu gets ever closer to maturity

VMware Tanzu, the company’s implementation of Kubernetes is being built upon ever since the portfolio was announced at VMworld 2019. The big reveal of this year’s event was Tanzu Community Edition, a free and open-source release of the solution aimed at learners and users.

Other Tanzu related announcements included VMware Cloud with Tanzu Services, managed Tanzu Kubernetes Grid (TKG), Tanzu Mission Control Essentials and a free tier with Tanzu mission control Starter.

“VMware Tanzu Community Edition is full-featured but free and open-source”

Lots of projects in development

VMware always has a bunch of projects with codenames in the works that later become actual products when they reached maturity. Remember how Tanzu used to be known as Project Pacific. In 2021, the company revealed no less than 9 major projects in various areas such as Edge computing, AI/ML, Security, multi-cloud, tiered memory for vSphere, Kubernetes…

Again, you can find the details about these projects in our VMworld 2021 roundup.

Edge Computing

The other area that was largely covered was Edge computing with the announcement of VMware Edge Compute Stack, a purpose-built and integrated stack offering HCI and SDN for small-scale VM and container workloads to effectively extend your SDDC to the Edge.

“VMware Edge compute Stack helps solve use cases for a wide variety of challenges”

While a lot of good things went their way, 2021 was an eventful year for VMware. Several big announcements were made that will change the face of the company and a few vSphere related crises the company’s TAMs had to navigate.

VMware and DellEMC Split

Probably the biggest announcement of the year was the split from DellEMC which was the majority stakeholder with 81% shares in the company. This separation comes 5 years after Dell acquired EMC in September of 2016 for a whopping $67 billion, EMC being VMware’s controlling stakeholder at the time. On November 1^st 2021, VMware becomes a standalone company for the first time since EMC acquired it in 2004, albeit after paying $11.5 billion in dividends to the shareholders.

In a news article, VMware’s new CEO Raghu Raghuram (more on that later) officialized the split and kept emphasizing their multi-cloud strategy with the goal of becoming “the Switzerland of the cloud industry”:

“As a standalone company, we now have the flexibility to partner even more deeply with all cloud and on-premises infrastructure companies to create a better foundation that drives results for our customers. And the increased flexibility we will have to use equity to complete future acquisitions will help us remain competitive. “

VMware has a new CEO

A number of top officers over at VMware left the building and were replaced by new top profiles. Among those, we find the CEO of the company himself. Pat Gelsinger, who led VMware between 2012 and 2021 gave his notice in February to become Intel’s new CEO after spending 30 years as a top profile between 1979 and 2009 for the blue team, a very impressive resume if you ask me.

VMware replaced him with Raghu Raghuram, the previous COO who’d been climbing up the corporate ladder since 2003, clocking over 18 years of employment to reach the top of the pyramid.

Raghu Raghuram succeeds to Pat Gelsinger as VMware’s CEO

vSphere 7 Update 3 removed

On a more technical note, 2021 was a rather turbulent year for vSphere 7.0. The year started with many customers encountering purple screens on vSphere hypervisors installed on SD cards or USB sticks, which eventually led VMware to pull support for these boot devices. This wasn’t received particularly well among the customer base as many were taken by surprise and now have to plan for it, which will be a large piece of work and investment depending on the size of the environment.

Following this shaky start, customers started having problems with vSphere 7 Update 3 causing PSOD in some instances. In order to fix it, VMware released patches that ended up breaking vSphere HA for many customers using a certain type of Intel adapters. VMware eventually decided to stop the haemorrhage by removing vSphere 7 Update 3 from distribution altogether, just over a month after its release.

“vSphere 7 Update 3 was crippled with issues since its initial release”

Needless to say that customers were pretty unhappy with how this unfolded. Many blamed the 6 months release cycle and quality control being put to the side in favor of shiny new Cloud or Tanzu features. Let’s hope the scission from DellEMC will entice VMware to regain a certain level of quality control and that organizations won’t put the deployment of security patches on hold as a result.

VMware Cloud Universal

As you can tell, VMware is very keen to push Cloud subscriptions to its customers and VMware Cloud Universal, which was released in April 2021, was another testimony of that. A subscription offering that offers access to multi-cloud resources, be it infrastructure, compute, storage, networking, modern apps…

The idea is to be able to flexibly deploy VMware Cloud Infrastructure across private and public clouds. VMware Cloud Universal includes VCF-Subscription (also released in 2021), VMware Cloud on AWS and VMware Cloud on DellEMC.

Now, I’ll admit that it is getting a bit tricky to make sense of the many cloud offerings proposed by VMware with VMC, VMC on AWS, VMware Cloud Universal, VMware Cross-Cloud services and then the subtleties in each one of them.

“VMware Cloud Universal allows customers to establish a flexible commercial agreement with VMware to commit once and consume dynamically”

Ransomware Attacks Targeting vSphere ESXi

In 2021, we, unfortunately, witnessed no curb in the infamous growing trend of vSphere Ransomware attacks. While most encrypting ransomware attacks were historically focused on Windows and Linux instances, vSphere is now being targeted as well. Bad actors will try to gain access to the virtual infrastructure and initiate encryption of the datastores to claim a ransom, hence impacting every single VMs in the environment.

Fortunately, most companies are now investing large amounts of resources to mitigate the risks and protect the customers, for instance, Altaro has been doing it for a long time now.

A Look Ahead to 2022

I wrapped up last year’s roundup with “Watch for 2021 as it is without a doubt that it will be a year packed with major events”. Well, I think it is safe to say that it turned out to be true. VMware’s split from DellEMC will give the company absolute autonomy over its market strategy and path to a multi-cloud world. 2022 will see a maturing of these core cloud technologies alongside VMware doubling down on its acquisition strategy of key technologies that will solidify its commitment to this direction.

While we are eager to find out what it brings in terms of novelties, we are equally looking forward to a return to a more sensible release cycle and the distribution of a stable version of the historic hypervisor (well that’s my main hope at least!) I’d love to hear your thoughts, so feel free to take your bet in the comment section as to what 2022 will bring!

Source :
https://www.altaro.com/vmware/2021-vmware-developments/

Best Practices for setting up Altaro VM Backup

This best practice guide goes through the Altaro VM Backup features explaining their use and the optimal way to configure them in order to make the best use out of the software.

You will need to adapt this to your specific environment, especially depending on how much resources you have available, however this guide takes you through the most important configurations that are often overlooked too.

Setting up the Altaro VM Backup Management Console

The Altaro VM Backup Management Console can be utilised to add and manage multiple hosts in one console. However these hosts must be in the same LAN and at the same physical site (same building). Setups with multiple physical sites must have an instance of Altaro VM Backup at each site.

To manage these multiple installations, you can utilise the ‘Central Monitoring Console’ where you’ll be able to monitor as well as manage these Altaro VM Backup installations remotely.

A single Altaro VM Backup instance can manage both Hyper-V & VMware hosts.

For optimal results, Altaro runs some maintenance specific tasks using (multiple) single threaded operations. For this reason installing on a machine which has a CPU with a higher single thread performance would yield better results than installing on a machine which has a CPU with more cores and lower single thread performance.

Thus for the fastest results, installing Altaro VM Backup on a machine with a higher single thread CPU speed would be best.

Backup Locations

Make sure Opportunity Locks (Oplocks) are disabled if the backup location is a NAS.

If your backup location is a Windows machine, the equivalent to Oplocks is: Set-SmbServerConfiguration -EnableLeasing 0

Run the above command via Powershell.

Offsite Copies

With Altaro VM Backup, you are provided with the functionality of an Offsite Copy Location, which is a redundant/secondary copy of your backups. You can even backup your VM’s to 2 different offsite copy locations for further redundancy of your data, so you can pick a cloud location as well as an Altaro Offsite Server for instance.

There are multiple options for setting this up:

You can choose a Physical Drive connected to the management console (the best practice for offsites is to have them located in another building/location).
Drive Rotation/Swap which allows you to set up a pool of drives/network paths.
A Network Path (LAN Only) or else to an offsite location via a WAN/VPN/Internet connection, which is an ideal tool for Disaster Recovery purposes. Please note that the latter situation (non-LAN) requires use of the Altaro Offsite Server
Backup to Microsoft Azure, Amazon S3 or Wasabi.

Setting up an offsite copy location is as crucial as setting up backups to a primary location. Apart from the obvious reason that you’ll have a redundant set of backups to restore from, should the local backups become unusable due to disk corruption or other disk failures. Having a secondary copy of your backup sets also allows you to keep a broader history for your VM backups on your secondary location and you’ll be able to go further back when restoring if required.

Deduplication

Altaro VM Backup makes use of Augmented In-line Deduplication. Enabling this is highly recommended and is done from the ‘Advanced Settings’ screen as this will essentially ensure that any common data blocks across virtual machines are only written to the backup location once. This helps by saving a considerable amount of space and also makes backups much quicker since common information is only transferred once.

Boot From Backup

The Boot From Backup drive feature comes along with 2 options, either ‘Verification Mode’ or ‘Recovery Mode’. This is a very good option for getting your RTO down since you’re able to boot up the VM immediately from a backup location and start a restore in the background as well.

However it’s very important that if you are planning to do this, you’ll need a fast backup location that can handle the I/O of a booted VM that’s essentially going into production. Please note that when the VM has finished restoring, it’s suggested to restart the restored VM as soon as you get a chance in order to switch to the restored drives, which would have faster I/O throughput.

Notifications

E-mail notifications are a simple and effective method of monitoring the backup status, yet it’s often overlooked. Setting up these notifications will provide you with a quick overview of the status over your of your backup jobs, hence – you won’t need to login into the Altaro Management console every day to confirm the backup status.

This way you’ll be alerted of any backup failures, allowing you to address said issues before the next backup schedule. Thereby ensuring that you always have a restorable backup point; so as a general best practice, always monitor your backup notifications.

Master Encryption Key

The Master Encryption Key in Altaro is utilised to encrypt the backups using AES 256-bit. It’s used if you choose to encrypt the local backups from the ‘Advanced Settings’ screen, while if you’re configuring offsite copies it must be used as offsite copies must be encrypted.

Altaro VM Backup will require the encryption key upon restoring, so it’s critical that you either remember it or take note of it in a secure password manager as there is no method of recovery for the master encryption key.

Scheduled Test Drills

Altaro VM Backup has the ability to run manual or automated verification of your backup data. This allows you to run scheduled verification jobs that will check the integrity of your backups on your backup location, or schedule full VM restores so that you can actually boot up the VM and confirm that everything works as expected. The VM will be restored with the NIC disabled so as to avoid IP conflicts with the production machine as well.

Failure of storage devices is not uncommon, therefore scheduling test drills is strongly advised for added peace-of-mind. Full instructions on configuring test drills.

Other General Best Practices

Backups and production VM’s should not be placed on the same drive.
Make sure Opportunity Locks (Oplocks) are disabled if the backup location is a NAS.
Backups should not be placed on a drive where an OS is running.
Altaro uses the drive it’s installed on as temporary storage and will require a small amount of free space (varying according to the size of the VMs being backed up).
Keep at least 10% of the backup location free.
The main Altaro VM Backup installation should not be installed on a machine that is also a domain controller (DC).
Directories/files inside the Altaro backup folder should not be tampered with, deleted or moved.
Do not take snapshots DFSR databases: “Snapshots aren’t supported by the DFSR database or any other Windows multi-master databases. This lack of snapshot support includes all virtualization vendors and products. DFSR doesn’t implement USN rollback quarantine protection like Active Directory Domain Services.” Source.

Best Practices for Replication

Exclude Page File from Backup

As you’re aware Altaro VM Backup will take note of all changes since the last backup and transfer over all of the blocks that changed to the backup location. The page file will be changing very often and potentially causing your replication jobs to take longer.

Therefore, excluding the page file from backup equals, less transferred changes and as a result the replication jobs takes less time. This can be done by placing the page file onto a separate VHDX/VMDK file from the VM itself and then you can follow the steps here, in order to exclude the VHDX/VMDK file.

High Disk IO and Hypervisor Performance

Replication needs to make use of CDP (Continuous Data Protection), in order to take a backup every couple of minutes/hours, which makes Replication possible.

It’s important to note however that you should only enable high-frequency CDP (15 minutes or less) on VM’s that you really need to. This will ensure that the VM’s you really need to will be able to achieve the selected maximum frequency and in order not to have an impact your Hypervisor’s performance.

Source :
https://help.altaro.com/support/solutions/articles/43000467315-best-practices-for-setting-up-altaro-vm-backup

Altaro Dealing with “volsnap” errors in the System event log

The volsnap source errors are events that are listed in the Windows System event log. Such events usually contain relevant troubleshooting information as to why the shadow copy got dismounted and as a result causes the backups to fail.

You can refer to this article showcasing the error seen in Altaro.

Below you can find a couple of ‘volsnap’ events that we’ve encountered along with their solutions:

Error Message:

volsnap Event ID 25
The shadow copies of volume D: were deleted because the shadow copy storage could not grow in time. Consider reducing the IO load on the system or choose a shadow copy storage volume that is not being shadow copied.

Solution:

This error is logged due to the source drive experiencing a high IO load and thereby it causes the shadow copy to dismount, as a result causing a backup failure. In this case you can choose to re-schedule the backup job when there is less IO on the source disk. In addition to that something that will help alleviate the IO on the source disk is placing the shadow copies onto another drive completely.

You’ll need to ensure that you have a disk with enough (10% of the original source) and it should also be a disk with on-per performance as the source.

You can run the following command on the host in order to place the shadow copy on another disk; drive letters need to be changed accordingly:

vssadmin add shadowstorage /For=D: /On=E: /MaxSize=UNBOUNDED
vssadmin resize shadowstorage /For=D: /On=E: /MaxSize=UNBOUNDED

Text

Adjusting the page file to 1.5 times the amount of RAM can also help the situation. Note that if you set the it to the maximum page file available, you will be required to restart the machine. Increases (not going up to the maximum) do not typically require a restart.

Error Message:

volsnap Event ID 16
The shadow copies of volume D: were aborted because volume D:, which contains shadow copy storage for this shadow copy, was force dismounted.

volsnap Event ID 14
The shadow copies of volume D: were aborted because of an IO failure on volume D:

Solution:

These two events are usually coupled together. This usually points to a disk issue on the drive being referenced and there should be ‘Disk’ or ‘Ntfs’ events at the same time that give more information on the issue.

Error Message:

volsnap Event ID 24
There was insufficient disk space on volume D: to grow the shadow copy storage for shadow copies of D:. As a result of this failure all shadow copies of volume D: are at risk of being deleted.

volsnap Event ID 35
The shadow copies of volume D: were aborted because the shadow copy storage failed to grow.

Solution:

These two events are usually coupled together. In this case it means that the shadow copy was dismounted due to insufficient disk space on the volume. Please ensure that you have at least 10% free space on the source drives and then run the backup again.

Error Message:

volsnap Event ID 36
The shadow copies of volume D: were aborted because the shadow copy storage could not grow due to a user imposed limit.

Solution:

This particular volsnap error means that the current limit imposed is limiting the shadow copy from growing any larger and hence it’s causing the shadow copy to dismount and cause the backup to fail. To resolve this error you can run the following commands to expand the ShadowStorage; drive letters need to be changed accordingly:

vssadmin add shadowstorage /For=D: /On=D: /MaxSize=UNBOUNDED
vssadmin resize shadowstorage /For=D: /On=D: /MaxSize=UNBOUNDED

Text

Also note that in case you’re using a CSV (Clustered Shared Volume), instead of a drive letter being listed in the event log, there will be an empty space.

Source :
https://help.altaro.com/support/solutions/articles/43000494972

What are the system requirements for Altaro VM Backup?

update november 2023

Version 9

The VM Backup Management Console can be utilized to add and manage multiple hosts in one console. However these hosts must be in the same LAN and at the same physical site (same building). Setups with multiple physical sites must have an instance of VM Backup at each site.

Supported Hypervisors (Hosts)

Microsoft Hyper-V

Windows Server 2008 R2 SP1 (Only with .NET Framework 4.8 or higher)
Windows Hyper-V Server 2008 R2 SP1 (core installation) (Only with .NET Framework 4.8 or higher)
Windows Server 2012
Windows Hyper-V Server 2012 (core installation)
Windows Server 2012 R2
Windows Hyper-V Server 2012 R2 (core installation)
Windows Server 2016
Windows Server 2016 (desktop experience)
Windows Hyper-V Server 2016 (core installation)
Windows Server 2019
Windows Hyper-V Server 2019 (core installation)
Windows Server 2022
Windows Hyper-V Server 2022 (core installation)
Azure Stack HCI

VMware

vSphere: 5.5 / 6.0 / 6.5 / 6.7 / 7.0 / 8.0
vCenter: 5.5 / 6.0 / 6.5 / 6.7 / 7.0 / 8.0
ESXi: 5.5 / 6.0 / 6.5 / 6.7 / 7.0 / 8.0

Note: vSphere/vCenter/ESXi 5.0/5.1 are no longer supported in V9

It’s important to note the version combination between ESXi and vCenter.

Note that the Free version of VMware ESXi is not supported as it lacks components required by VM Backup.

When making use of the NBD Transport mode, virtual disks cannot be larger than 1TB each. More information here.

Pass-through or RDM (Raw Device Mappings) are not backed up.

Supported Operating Systems

The VM Backup products can be installed on the following OS’s:

VM Backup

Windows Server 2008 R2 SP1 (Only with .NET Framework 4.8 or higher)
Windows Hyper-V Server 2008 R2 SP1 (core installation) (Only with .NET Framework 4.8 or higher)
Windows Server 2012
Windows Hyper-V Server 2012 (core installation)
Windows Server 2012 R2
Windows Hyper-V Server 2012 R2 (core installation)
Windows Server 2016
Windows Server 2016 (desktop experience)
Windows Hyper-V Server 2016
Windows Server 2019
Windows Hyper-V Server 2019
Windows Hyper-V Server 2019 (core installation)
Windows Server 2022
Azure Stack HCI

Note that hosts must be in the same LAN and at the same physical site (same building). Setups with multiple physical sites must have an instance of VM Backup at each site.

Management Tools (UI)

Windows 2008 R2 SP1 (Only with .NET Framework 4.8 or higher)
Windows Server 2012
Windows Server 2012 R2
Windows Server 2016 (desktop experience)
Windows Server 2019
Windows Server 2022
Azure Stack HCI
Windows 7 (64-Bit)
Windows 8 (64-Bit)
Windows 10 (64-Bit)
Windows 11 (64-Bit)

Offsite Backup Server

Windows 2008 R2 SP1 (Only with .NET Framework 4.8 or higher)
Windows Hyper-V Server 2008 R2 SP1 (core installation) (Only with .NET Framework 4.8 or higher)
Windows Server 2012
Windows Hyper-V Server 2012 (core installation)
Windows Server 2012 R2
Windows Hyper-V Server 2012 R2 (core installation)
Windows Server 2016
Windows Server 2016 (desktop experience)
Windows Hyper-V Server 2016
Windows Server 2019
Windows Hyper-V Server 2019
Windows Server 2022
Azure Stack HCI

Replication Support

[Hyper-V] A Windows Server OS is required for replication. The Offsite Backup Server needs to be installed on a Windows Server OS that’s matching the source host OS, where the production VMs are running. Below you can find a list supported OS’s that you can replicate to:

Host OS	Supported Replication Offsite Backup Server OS
2012	to 2012
2012R2	to 2012R2
2016	to 2016
2019	to 2019
2022	to 2022
Azure Stack HCI	Azure Stack HCI

[VMware] The host added to the Offsite Backup Server must be the same OS as the source host being replicated from. Below you can find a list supported OS’s that you can replicate to:

Host OS	Supported Replication Host OS
5.5	to 5.5
6.0	to 6.0
6.5	to 6.5
6.7	to 6.7
7.0	to 7.0
8.0	to 8.0

Required Hardware Specifications

VM Backup

Minimum of i5 (or equivalent – minimum 4 cores recommended) processor
2 GB RAM + an additional 25MB RAM for every 100GB of data being backed up
1 GB Hard Disk Space (for VM Backup Program and Settings) + 15 GB (for temporary files created during backup operations)
Minimum of 10% free disk space on each volume holding live VM data to be used for Microsoft Volume Shadow Copy
Minimum of 10% free disk space on each backup location holding backup data to ensure smooth operation

Hyper-V Host Agent

1 GB RAM
2 GB Hard Disk Space

Offsite Backup Server

Minimum of i5 (or equivalent – minimum 4 cores recommended) processor
2 GB RAM + an additional 25MB RAM for every 100GB of data being backed up
For Replication, ensure that it has enough resources to boot your VMs

Software Prerequisites

MS .NET Framework 4.8
Minimum screen resolution for the Management console: 1280×800
One of the listed supported Operating Systems must be used (Windows client operating systems are not supported unless specified)
The main VM Backup installation cannot be installed on a machine that is also a domain controller (DC)

Communication Ports

Below is a list of the default TCP ports used by our software and their purpose. All these ports must be allowed.

36014 : Communication between Management Console UI and VM Backup

36015 : Communication from VM Backup to API Service

36021 & 36022 : Communication between the Host Agents and VM Backup

36023 : Communication from VM Backup to Host Agents

36070 : Communication for the Deduplication Service

36000 & 36001 : Communication from v9 Clients with the Offsite Backup Server

36050 : Communication from Offsite Backup Server UI to Offsite Backup Server

36100 : Communication from VM Backup to the Offsite Backup Server for Replication

36075: Communication for the Deduplication Service for the Offsite Backup Server

36200 – 36220 : Communication from VM Backup to Agents for Boot From Backup

80 & 443 : For Offsite copies to Azure Storage Accounts, Amazon S3 & Wasabi

443 & 7444 & 902 : Communication to VMware Hosts

Supported Backup Locations

USB External Drives
eSata External Drives
USB Flash Drives
Fileserver Network Shares using UNC Paths
NAS devices (Network Attached Storage) using UNC Paths
PC Internal Hard Drives (recommended only for evaluation purposes)
RDX Cartridges
Offsite Backup Server (incl. Replication)
Azure Cloud Storage Account
Amazon S3
Wasabi Cloud Storage Account

Note: The backup locations must be in the same LAN and at the same physical site (same building) as the VM management machine and the hosts, with the exception of the Offsite Backup Server/Cloud locations.

Note: Target storage partitions must be either of the below:

NTFS/ReFS formatted
Network Paths and accessible by SMB3.0

Note: Please ensure that the backup location chosen does not perform any sort of deduplication outside that of VM Backup.

Note: SMB file shares in Cloud locations (such as Azure Files) are not supported as a backup location.

Boot from Backup Requirements

For Hyper-V Windows Server 2012 Host OS and onward are supported for Boot from Backup Drive. The Microsoft iSCSI Initiator Service has to be running on the machine you’re attempting to boot to.
VMware requires ports 36200 – 36220 open on the firewall and it also requires an iSCSI Storage Adapter. More information on that here.
The datastore chosen for must be VMFS.
VMs with Storage Spaces volumes are not supported.

File Level/Exchange Item Level Restore Requirements

The partition must be NTFS / ReFS (through Instant Mount – only for File Level Restores) formatted
The partition must be formatted as ‘Basic’ and not ‘Dynamic’
If the VM has Windows Data Deduplication role enabled, the role must also be enabled where the VM Backup machine is installed (through Instant Mount)
The files must NOT be encrypted or compressed at guest OS (VM) level
Exchange Item Level Restores are only supported from NTFS formatted partitions
Storage Spaces volumes are not supported for file level recovery
The following Microsoft Exchange versions are supported:
- 2007 (up to SP3)
- 2010 (up to SP3)
- 2013 (from RTM up to CU21, with the exception of CU 2, 3 and 4)
- 2016 (up to CU22)
- 2019 (up to CU11)

Hyper-V Restore Version Compatibility

Virtual Machines backed up from Windows Server 2008 R2 SP1 and 2012 hosts have to be restored to hosts running Windows Server 2016 build 1607 or older.

Virtual machines backed up from Windows Server 2012 R2 and newer can be restore to hosts running up to Windows Server 2019. While VMs backed up from WS2016 and newer can be restored to hosts running WS 2022.

Naturally, you can restore to a newer operating system, but not to an older one i.e. you will be able to restore a VM backed up from a 2008 R2 SP1 host to a 2012 one, but not the other way round.

Please note that this also applies when restoring a single virtual hard disk as well.

Version 8

Supported Hypervisors (Hosts)

Microsoft Hyper-V

Windows Server 2008 R2 SP1
Windows Hyper-V Server 2008 R2 SP1 (core installation)
Windows Server 2012
Windows Hyper-V Server 2012 (core installation)
Windows Server 2012 R2
Windows Hyper-V Server 2012 R2 (core installation)
Windows Server 2016
Windows Server 2016 (desktop experience)
Windows Hyper-V Server 2016 (core installation)
Windows Server 2019
Windows Hyper-V Server 2019 (core installation)
Windows Server 2022
Windows Hyper-V Server 2022 (core installation)
Azure Stack HCI

VMware

vSphere: 5.0 / 5.1 / 5.5 / 6.0 / 6.5 / 6.7 / 7.0
vCenter: 5.0 / 5.1 / 5.5 / 6.0 / 6.5 / 6.7 / 7.0
ESXi: 5.0 / 5.1 / 5.5 / 6.0 / 6.5 / 6.7 / 7.0

It’s important to note the version combination between ESXi and vCenter.

Note that the Free version of VMware ESXi is not supported as it lacks components required by VM Backup.

When making use of the NBD Transport mode, virtual disks cannot be larger than 1TB each. More information here.

Pass-through or RDM (Raw Device Mappings) are not backed up.

Backing up VMs that have fault tolerance enabled is not supported because when FT is enabled, it is not possible to take snapshots of those virtual machines, which is one of the criteria for AVMB to be able to take a backup of a VM.

Restoring to a vVol (VMware Virtual Volume) Datastore is not supported.

Supported Operating Systems

The VM Backup products can be installed on the following OS’s:

VM Backup

Windows Server 2008 R2 SP1
Windows Hyper-V Server 2008 R2 SP1 (core installation)
Windows Server 2012
Windows Hyper-V Server 2012 (core installation)
Windows Server 2012 R2
Windows Hyper-V Server 2012 R2 (core installation)
Windows Server 2016
Windows Server 2016 (desktop experience)
Windows Hyper-V Server 2016
Windows Server 2019
Windows Hyper-V Server 2019
Windows Hyper-V Server 2019 (core installation)
Windows Server 2022
Windows Hyper-V Server 2022
Windows Hyper-V Server 2022 (core installation)
Azure Stack HCI

Note that hosts must be in the same LAN and at the same physical site (same building). Setups with multiple physical sites must have an instance of VM Backup at each site.

Management Tools (UI)

Windows 2008 R2 SP1
Windows Server 2012
Windows Server 2012 R2
Windows Server 2016 (desktop experience)
Windows Server 2019
Windows Server 2022
Azure Stack HCI
Windows 7 (64-Bit)
Windows 8 (64-Bit)
Windows 10 (64-Bit)

Offsite Backup Server

Windows 2008 R2 SP1
Windows Hyper-V Server 2008 R2 SP1 (core installation)
Windows Server 2012
Windows Hyper-V Server 2012 (core installation)
Windows Server 2012 R2
Windows Hyper-V Server 2012 R2 (core installation)
Windows Server 2016
Windows Server 2016 (desktop experience)
Windows Hyper-V Server 2016
Windows Server 2019
Windows Hyper-V Server 2019
Windows Server 2022
Windows Hyper-V Server 2022
Azure Stack HCI

Replication Support

Host OS	Supported Replication Offsite Backup Server OS
2012	to 2012
2012R2	to 2012R2
2016	to 2016
2019	to 2019
2022	to 2022
Azure Stack HCI	Azure Stack HCI

[VMware] The host added to the Offsite Backup Server must be the same OS as the source host being replicated from. Below you can find a list of supported OS’s that you can replicate to:

Host OS	Supported Replication Host OS
5.5	to 5.5
6.0	to 6.0
6.5	to 6.5
6.7	to 6.7
7.0	to 7.0

Required Hardware Specifications

VM Backup

Minimum of i5 (or equivalent – minimum 4 cores recommended) processor
1 GB RAM + an additional 25MB RAM for every 100GB of data being backed up
1 GB Hard Disk Space (for VM Backup Program and Settings) + 15 GB (for temporary files created during backup operations)
Minimum of 10% free disk space on each volume holding live VM data to be used for Microsoft Volume Shadow Copy

Hyper-V Host Agent

500 MB RAM

Offsite Backup Server

Minimum of i5 (or equivalent – minimum 4 cores recommended) processor
1 GB RAM + an additional 25MB RAM for every 100GB of data being backed up
For Replication, ensure that it has enough resources to boot your VMs

Software Prerequisites

MS .NET Framework 4.7.2
Minimum screen resolution for the Management console: 1280×800
One of the listed supported Operating Systems must be used (Windows client operating systems are not supported unless specified)

Communication Ports

Below is a list of the default TCP ports used by our software and their purpose. All these ports must be allowed.

35106 : Communication for VMware 6.5, Backup and Restore operations.

35107 : Communication between Management Console UI and VM Backup

35108 : Communication from VM Backup to Hyper-V Host Agents

35113 : Communication from VM Backup to API Service

35114 : Communication for the Deduplication Service

35116 & 35117 : Communication from v8 Clients with the Offsite Backup Server

35119 : Communication from Offsite Backup Server V8 UI to Offsite Backup Server

35120 : Communication from VM Backup to the Offsite Backup Server for Replication

35121 : Communication for the Deduplication Service for Amazon S3/Wasabi offsite locations

35221 : Communication between the Hyper-V Host Agents and VM Backup

35200 – 35220 : Communication from VM Backup to Agents for VMware Boot From Backup

80 & 443 : For Offsite copies to Azure Storage Accounts, Amazon S3 & Wasabi

443 & 7444 & 902 : Communication to VMware Hosts

Supported Backup Locations

USB External Drives
eSata External Drives
USB Flash Drives
Fileserver Network Shares using UNC Paths
NAS devices (Network Attached Storage) using UNC Paths
PC Internal Hard Drives (recommended only for evaluation purposes)
RDX Cartridges
Offsite Backup Server (incl. Replication)
Azure Cloud Storage Account
Amazon S3
Wasabi Cloud Storage Account

Note: Target storage partitions must be either of the below:

NTFS/ReFS formatted
Network Paths and accessible by SMB3.0

Note: Please ensure that the backup location chosen does not perform any sort of deduplication outside that of VM Backup.

Note: SMB file shares in Cloud locations (such as Azure Files) are not supported as a backup location.

Boot from Backup Requirements

For Hyper-V Windows Server 2012 Host OS and onward are supported for Boot from Backup Drive. The Microsoft iSCSI Initiator Service has to be running on the machine you’re attempting to boot to.
VMware requires ports 35200 – 35220 open on the firewall and it also requires an iSCSI Storage Adapter. More information on that here.
The datastore chosen must be VMFS.
VMs with Storage Spaces volumes are not supported.

File Level/Exchange Item Level Restore Requirements

The partition must be NTFS / ReFS (through Instant Mount – only for File Level Restores) formatted
The partition must be formatted as ‘Basic’ and not ‘Dynamic’
If the VM has Windows Data Deduplication role enabled, the role must also be enabled where the VM Backup machine is installed (through Instant Mount) (only for File Level)
The files must NOT be encrypted or compressed at guest OS (VM) level
Exchange Item Level Restores are only supported from NTFS formatted partitions
Storage Spaces volumes are not supported for file level recovery
The following Microsoft Exchange versions are supported:
- 2007 (up to SP3)
- 2010 (up to SP3)
- 2013 (from RTM up to CU21, with the exception of CU 2, 3, and 4)
- 2016 (up to CU23)
- 2019 (up to CU13)

Hyper-V Restore Version Compatibility

Virtual Machines backed up from Windows Server 2008 R2 SP1 and 2012 hosts have to be restored to hosts running Windows Server 2016 build 1607 or older.

Virtual machines backed up from Windows Server 2012 R2 and newer can be restored to hosts running up to Windows Server 2019. While VMs backed up from WS2016 and newer can be restored to hosts running WS 2022.

Naturally, you can restore to a newer operating system, but not to an older one i.e. you will be able to restore a VM backed up from a 2008 R2 SP1 host to a 2012 one, but not the other way round.

Please note that this also applies when restoring a single virtual hard disk as well.

Have more questions? Submit a request

Source :
https://support.hornetsecurity.com/hc/en-us/articles/19687996547601