[//]: # (werk v2)
# agent_kube: requests.SSLError raised on connection using self signed certificates
key | value
---------- | ---
compatible | yes
version | 2.4.0b1
date | 2024-09-02T12:01:17+00:00
level | 1
class | fix
component | checks
edition | cre
Newer versions of `requests` don't take `REQUESTS_CA_BUNDLE` into account, resulting in
```
requests.exceptions.SSLError: \
HTTPSConnectionPool(host='<collector>', port=443): \
Max retries exceeded with url: \
/metadata (Caused by SSLError( \
SSLCertVerificationError(1, \
'[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: \
self signed certificate in certificate chain (_ssl.c:1006)')))
```
being raised if running `agent_kube` against instances using self signed certificates.
This change invokes `session.merge_environment_settings()` to take `REQUESTS_CA_BUNDLE` into
account again.
See
[GitHub: 2807: Use merge_environment_settings method in sessions.send method](https://github.com/psf/requests/issues/2807)
and
[GitHub: 3626: HTTP Proxy with prepared request (honouring env. var.)](https://github.com/psf/requests/issues/3626)
Title: Persist known host keys for checks that use SSH
Class: security
Compatible: compat
Component: checks
Date: 1724662564
Edition: cre
Level: 1
Version: 2.1.0p48
When using the special agent <em>VNX quotas and filesystems</em> or the active check <em>Check SFTP Service</em> the host keys were not properly checked.
If an attacker would get into a machine-in-the-middle position he could intercept the connection and retrieve information e.g. passwords.
As of this Werk the host key check is properly done.
In order to store known host keys a regular <code>known_hosts</code> file is used that is stored in <code>/omd/sites/$SITENAME/.ssh/known_hosts</code>.
If a host key changes an error is now raised that requires manual edit of this file.
This issue was found during internal review.
<em>Affected Versions</em>:
LI: 2.3.0
LI: 2.2.0
LI: 2.1.0
LI: 2.0.0 (EOL)
<em>Vulnerability Management</em>:
We have rated the issue with a CVSS Score of 6.3 Medium CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:L/SA:N and assigned CVE-2024-6572.
Title: Persist known host keys for checks that use SSH
Class: security
Compatible: compat
Component: checks
Date: 1724662564
Edition: cre
Level: 1
Version: 2.2.0p33
When using the special agent <em>VNX quotas and filesystems</em> or the active check <em>Check SFTP Service</em> the host keys were not properly checked.
If an attacker would get into a machine-in-the-middle position he could intercept the connection and retrieve information e.g. passwords.
As of this Werk the host key check is properly done.
In order to store known host keys a regular <code>known_hosts</code> file is used that is stored in <code>/omd/sites/$SITENAME/.ssh/known_hosts</code>.
If a host key changes an error is now raised that requires manual edit of this file.
This issue was found during internal review.
<em>Affected Versions</em>:
LI: 2.3.0
LI: 2.2.0
LI: 2.1.0
LI: 2.0.0 (EOL)
<em>Vulnerability Management</em>:
We have rated the issue with a CVSS Score of 6.3 Medium CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:L/SA:N and assigned CVE-2024-6572.
[//]: # (werk v2)
# agent_kube: requests.SSLError raised on connection using self signed certificates
key | value
---------- | ---
compatible | yes
version | 2.3.0p15
date | 2024-09-02T12:01:17+00:00
level | 1
class | fix
component | checks
edition | cre
Newer versions of `requests` don't take `REQUESTS_CA_BUNDLE` into account, resulting in
```
requests.exceptions.SSLError: \
HTTPSConnectionPool(host='<collector>', port=443): \
Max retries exceeded with url: \
/metadata (Caused by SSLError( \
SSLCertVerificationError(1, \
'[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: \
self signed certificate in certificate chain (_ssl.c:1006)')))
```
being raised if running `agent_kube` against instances using self signed certificates.
This change invokes `session.merge_environment_settings()` to take `REQUESTS_CA_BUNDLE` into
account again.
See
[GitHub: 2807: Use merge_environment_settings method in sessions.send method](https://github.com/psf/requests/issues/2807)
and
[GitHub: 3626: HTTP Proxy with prepared request (honouring env. var.)](https://github.com/psf/requests/issues/3626)
[//]: # (werk v2)
# Support Diagnostics: Include information about the Checkmk Appliance
key | value
---------- | ---
date | 2024-08-30T11:26:26+00:00
version | 2.3.0p15
class | feature
edition | cre
component | wato
level | 1
compatible | yes
The Support Diagnostics dump now contains information about the Checkmk Appliance, when it's
used on an Appliance.
This includes the model and product name of the hardware, and the version of the installed firmware.
Werk 17148 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# Persist known host keys for checks that use SSH
key | value
---------- | ---
date | 2024-08-26T08:56:04+00:00
version | 2.3.0p15
class | security
edition | cre
component | checks
level | 1
compatible | yes
When using the special agent *VNX quotas and filesystems* or the active check *Check SFTP Service* the host keys were not properly checked.
If an attacker would get into a machine-in-the-middle position he could intercept the connection and retrieve information e.g. passwords.
As of this Werk the host key check is properly done.
In order to store known host keys a regular `known_hosts` file is used that is stored in `/omd/sites/$SITENAME/.ssh/known_hosts`.
If a host key changes an error is now raised that requires manual edit of this file.
This issue was found during internal review.
*Affected Versions*:
* 2.3.0
* 2.2.0
* 2.1.0
* 2.0.0 (EOL)
*Vulnerability Management*:
We have rated the issue with a CVSS Score of 6.3 Medium CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:L/SA:N and assigned CVE-2024-6572.
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# Persist known host keys for checks that use SSH
key | value
---------- | ---
date | 2024-08-26T08:56:04+00:00
- version | 2.3.0p14
? ^
+ version | 2.3.0p15
? ^
class | security
edition | cre
component | checks
level | 1
compatible | yes
When using the special agent *VNX quotas and filesystems* or the active check *Check SFTP Service* the host keys were not properly checked.
If an attacker would get into a machine-in-the-middle position he could intercept the connection and retrieve information e.g. passwords.
As of this Werk the host key check is properly done.
In order to store known host keys a regular `known_hosts` file is used that is stored in `/omd/sites/$SITENAME/.ssh/known_hosts`.
If a host key changes an error is now raised that requires manual edit of this file.
This issue was found during internal review.
*Affected Versions*:
* 2.3.0
* 2.2.0
* 2.1.0
* 2.0.0 (EOL)
*Vulnerability Management*:
We have rated the issue with a CVSS Score of 6.3 Medium CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:L/SA:N and assigned CVE-2024-6572.
Werk 17266 was adapted. The following is the new Werk, a diff is shown at the end of the message.
[//]: # (werk v2)
# REST-API: Include links for get hosts by default
key | value
---------- | ---
date | 2024-09-03T13:16:41+00:00
version | 2.4.0b1
class | fix
edition | cre
component | rest-api
level | 1
compatible | no
[Werk #16756](https://checkmk.com/werk/16756) introduced the `include_links`
flag to the `Show all hosts` endpoint
(`GET .../domain-types/host_config/collections/all`). The flag was disabled
by default.
This werk changes the default to enabled again. As this comes with a
performance impact, it is recommended to disable it explicitly, if links are not
needed.
------------------------------------<diff>-------------------------------------------
[//]: # (werk v2)
# REST-API: Include links for get hosts by default
key | value
---------- | ---
date | 2024-09-03T13:16:41+00:00
version | 2.4.0b1
class | fix
edition | cre
component | rest-api
level | 1
compatible | no
- [Werk #16756](https://werks.checkmk.com/16756) introduced the `include_links`
? ------
+ [Werk #16756](https://checkmk.com/werk/16756) introduced the `include_links`
? +++++
flag to the `Show all hosts` endpoint
(`GET .../domain-types/host_config/collections/all`). The flag was disabled
by default.
This werk changes the default to enabled again. As this comes with a
performance impact, it is recommended to disable it explicitly, if links are not
needed.
[//]: # (werk v2)
# REST-API: Introduce include_links and include_extensions to list endpoints
key | value
---------- | ---
date | 2024-09-03T13:25:46+00:00
version | 2.4.0b1
class | feature
edition | cre
component | rest-api
level | 1
compatible | yes
This Werk introduces two flags to most list endpoints.
The first flag `include_links` was already present for list host configs. It
controls whether the links of the individual values should be included.
This flag is enabled by default.
The second flag `include_extensions` toggles the inclusion of the extensions,
which contain most of the attributes. This flag is also enabled by default.
Both of these flags give users options to improve performance and reduce
response sizes.
[//]: # (werk v2)
# REST-API: Include links for get hosts by default
key | value
---------- | ---
date | 2024-09-03T13:16:41+00:00
version | 2.4.0b1
class | fix
edition | cre
component | rest-api
level | 1
compatible | no
[Werk #16756](https://werks.checkmk.com/16756) introduced the `include_links`
flag to the `Show all hosts` endpoint
(`GET .../domain-types/host_config/collections/all`). The flag was disabled
by default.
This werk changes the default to enabled again. As this comes with a
performance impact, it is recommended to disable it explicitly, if links are not
needed.