[//]: # (werk v2)
# veeam_jobs: Always Monitor Result of Last Backup
key | value
---------- | ---
date | 2024-06-05T14:36:09+00:00
version | 2.3.0p6
class | fix
edition | cee
component | checks
level | 1
compatible | yes
Previously, the check plugin `veeam_jobs` would not always check the result of
the last backup job to determine the monitoring state. If the creation time was
an empty string, it would show `item not found` in case. It will now show all
the information available and the correct monitoring state.
Werk 16347 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# Synthetic monitoring: Fix missing keyword metrics in test services
key | value
---------- | ---
date | 2024-06-03T22:20:51+00:00
version | 2.3.0p6
class | fix
edition | cee
component | checks
level | 1
compatible | yes
Before this werk, certain keyword runtime metrics were missing the output of the RMK test services.
This applied to both high-level and regex-matched keywords.
Specifically, this issue affected keywords nested in a TRY statement.
As a result of this werk, new keyword runtime metrics may appear in the test services.
Also, the names of existing metrics may change due to shifts in the underlying keyword IDs.
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# Synthetic monitoring: Fix missing keyword metrics in test services
key | value
---------- | ---
date | 2024-06-03T22:20:51+00:00
- version | 2.3.0p5
? ^
+ version | 2.3.0p6
? ^
class | fix
edition | cee
component | checks
level | 1
compatible | yes
Before this werk, certain keyword runtime metrics were missing the output of the RMK test services.
This applied to both high-level and regex-matched keywords.
Specifically, this issue affected keywords nested in a TRY statement.
As a result of this werk, new keyword runtime metrics may appear in the test services.
Also, the names of existing metrics may change due to shifts in the underlying keyword IDs.
[//]: # (werk v2)
# notification_rules: auth value should be a required field when auth is enabled
key | value
---------- | ---
date | 2024-06-05T15:51:31+00:00
version | 2.4.0b1
class | fix
edition | cre
component | rest-api
level | 1
compatible | yes
Previously, when you created a notification rule via the REST-API using the
'mail' plugin, the value of the 'auth' field within the "enable_sync_smtp" schema
was not a required field. This is incorrect. If 'auth' is enabled, then
the value of 'auth' should be a required field. This werk now addresses
this issue.
e.g
```
"enable_sync_smtp": {
"state": "enabled",
"value": {
"auth": {
"state": "enabled",
"value": {"method": "plaintext", "password": "1234", "user": "user_a"},
},
"encryption": "ssl_tls",
"port": 25,
"smarthosts": ["abc", "def"],
},
}
```
[//]: # (werk v2)
# notification_rules: encryption type now an enum
key | value
---------- | ---
date | 2024-06-05T15:09:16+00:00
version | 2.4.0b1
class | fix
edition | cre
component | rest-api
level | 1
compatible | no
When creating a notification rule via the REST-API with the plugin
'asciimail', and configuring the 'enable_sync_smtp field', you could
previously set the subfield 'encryption' to any string. Any string
is not a valid encryption type.
This werk addresses this issue by having this field be an enum of two
values which are "ssl_tls" or "starttls". This aligns with the options
found in the UI for the same plugin.
select
[//]: # (werk v2)
# Bruteforce protection for two factor authentication
key | value
---------- | ---
date | 2024-06-06T17:19:18+00:00
version | 2.4.0b1
class | security
edition | cre
component | core
level | 1
compatible | yes
Prior to this werk, Two Factor Authentication failures could not trigger account lockout. All three methods will now count towards failed login attempts against a user's account.
As a result, an attacker could try to brute-force and therefore bypass user's two factor protections without triggering the lockout mechanism.
This vulnerability was identified in a commissioned penetration test conducted by PS Positive Security GmbH.
*Affected Versions*:
* 2.3.0
*Indicators of Compromise*:
Failed two factor authentication attempts can be identified within a Checkmk site's security log file (~/var/log/security.log).
*Vulnerability Management*:
We have rated the issue with a CVSS Score of 5.9 (Medium) with the following CVSS vector: <code>CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N</code>
and assigned CVE <code>CVE-2024-28833</code>.
[//]: # (werk v2)
# notification rules: match_host_tag field update
key | value
---------- | ---
date | 2024-06-07T08:34:37+00:00
version | 2.4.0b1
class | fix
edition | cre
component | rest-api
level | 1
compatible | yes
Due to some format changes on the host tags, the rule notification
REST-API endpoints have also been affected. This werk takes these changes
into account. To do this, the possible enum values for a tag group has
been modified.
The match_host_tags field takes accepts a list of aux_tags or tag_groups.
For tag groups, we now accept two new operators.
Previously, the enum looked like
enum=["is", "is_not"]
and now it looks like
enum=["is", "is_not", "one_of", "none_of"]
In addition, when the operator field is one of the new values, we expect
a list of tag_ids and not a single tag_id.
Tag group using one of the previous enum values (no change here)
'''
{
"operator": "is"
"tag_id": "tagid"
}
'''
Tag group using one of the new new enum values
'''
{
"operator": "one_of",
"tag_ids": ["tagid_1", "tagid2", "tagid3"],
}
'''
Title: Nutanix agent: introduce option to skip TLS verification and resolve broken request helper
Class: feature
Compatible: compat
Component: checks
Date: 1717422187
Edition: cre
Level: 1
Version: 2.2.0p28
Prior to this werk, it was not possible for the user to skip the TLS certificate verification
which subsequently broke the agent for some. This werk introduces the option to toggle the
verification.
[//]: # (werk v2)
# HW/SW inventory: change sorting of numerical columns to natural sort
key | value
---------- | ---
date | 2024-06-06T12:20:55+00:00
version | 2.3.0p6
class | feature
edition | cre
component | inv
level | 1
compatible | yes
The "#Services" and "#Hosts" columns for HW/SW inventory views, for example "Checkmk sites",
used to sort by ASCII order.
Now these two columns use natural sort.