Checkmk werks level1

checkmk-werks-lvl1@lists.checkmk.com

1 participants
15873 discussions

[2.4.0] Checkmk Werk 16662 created: Rest API: change host rename wait for completion endpoint to GET

by Checkmk werks level 1

[//]: # (werk v2) # Rest API: change host rename wait for completion endpoint to GET key | value ---------- | --- date | 2024-07-11T14:16:49+00:00 version | 2.4.0b1 class | fix edition | cre component | rest-api level | 1 compatible | no The wait-for-completion endpoint for host renames was using the POST method. This caused some issues and was inconsitent with other such endpoints. This werk changes the endpoint to be GET, just like the other ones.

2 months

[2.4.0] Checkmk Werk 16991 created: Extraneous characters in rule representation

by Checkmk werks level 1

[//]: # (werk v2) # Extraneous characters in rule representation key | value ---------- | --- date | 2024-07-15T07:23:03+00:00 version | 2.4.0b1 class | fix edition | cre component | multisite level | 1 compatible | yes With long rulesets, the rule representation (Export this rule for API) often would display extraneous characters such as newlines or whitespace. This did not affect the functionality of the feature, but could be confusing, so now these characters are no longer displayed.

2 months

[2.4.0] Checkmk Werk 16990 created: NagVis: Updated to 1.9.42 (fix security issues)

by Checkmk werks level 1

[//]: # (werk v2) # NagVis: Updated to 1.9.42 (fix security issues) key | value ---------- | --- date | 2024-07-10T11:06:29+00:00 version | 2.4.0b1 class | security edition | cre component | packages level | 1 compatible | yes NagVis has been updated to version 1.9.42. This update fixes the following security issues: - Fix various XSS issues (CVSS score: 8.8 CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H) - Fix potential RCE - Fix insecure password hashing algorithm for dedicated NagVis users (CVSS score 5.1 CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N) - Fix leak of installation path in error messages - Fix Make cookie hash comparison timing safe

2 months

[2.4.0] Checkmk Werk 17073 created: Siemens PLC agent configuration: Take timeout parameter into account

by Checkmk werks level 1

[//]: # (werk v2) # Siemens PLC agent configuration: Take timeout parameter into account key | value ---------- | --- date | 2024-07-12T10:47:29+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes When configuring the Siemens PLC agent, users could configure a per-device timeout. However, the configured values had no effect. Instead, the agent always used a default value of 10 seconds. As of this werk, users can instead configure one global timeout value, which is taken into account by the agent.

2 months

[2.4.0] Checkmk Werk 17155 adapted: Microsoft Teams: Use workflows instead of connectors

by Checkmk werks level 1

Werk 17155 was adapted. The following is the new Werk, a diff is shown at the end of the message. [//]: # (werk v2) # Microsoft Teams: Use workflows instead of connectors key | value ---------- | --- date | 2024-07-15T08:57:21+00:00 version | 2.4.0b1 class | fix edition | cre component | notifications level | 1 compatible | no Since Microsoft announced the deprecation of connectors, the notification plugin for Microsoft Teams was adjusted to use workflows. Deprecation note: https://devblogs.microsoft.com/microsoft365dev/retirement-of-office-365-con… To configure a workflow within Microsoft Teams: * Click the 3 dots on a channel and select “Workflows” * Choose "Post to a channel when a webhook request is received" * Choose name for the workflow, e.g. "Checkmk" * Select team and channel where the webhook should post to * Copy webhook URL For further informations please see section "How do I transition from Office 365 connectors to Workflows?" in the deprecation note. To configure the notification plugin within Checkmk: * Post copied webhook URL to "Webhook URL" of your notification rule for MS Teams If you used custom "Details for host notifications" or "Details for service notifications", the line break " " has to be replaced by "\\u00A0\\n". As we now use Adaptive Cards instead of Message Cards, we can no longer use colors. ------------------------------------<diff>------------------------------------------- [//]: # (werk v2) # Microsoft Teams: Use workflows instead of connectors key | value ---------- | --- date | 2024-07-15T08:57:21+00:00 version | 2.4.0b1 class | fix edition | cre component | notifications level | 1 compatible | no Since Microsoft announced the deprecation of connectors, the notification plugin for Microsoft Teams was adjusted to use workflows. Deprecation note: https://devblogs.microsoft.com/microsoft365dev/retirement-of-office-365-con… To configure a workflow within Microsoft Teams: * Click the 3 dots on a channel and select “Workflows” * Choose "Post to a channel when a webhook request is received" * Choose name for the workflow, e.g. "Checkmk" * Select team and channel where the webhook should post to * Copy webhook URL For further informations please see section "How do I transition from Office 365 connectors to Workflows?" in the deprecation note. To configure the notification plugin within Checkmk: * Post copied webhook URL to "Webhook URL" of your notification rule for MS Teams If you used custom "Details for host notifications" or "Details for service - notifications", the line break "<br\>" has to be replaced by "\\u00A0\\n". ? ^ ^^ + notifications", the line break " " has to be replaced by "\\u00A0\\n". ? ^^^^ ^^^^ As we now use Adaptive Cards instead of Message Cards, we can no longer use colors.

2 months

[2.2.0] Checkmk Werk 17002 created: Support Azure Databases for MySQL flexible server

by Checkmk werks level 1

Title: Support Azure Databases for MySQL flexible server Class: feature Compatible: compat Component: checks Date: 1720519796 Edition: cre Level: 1 Version: 2.2.0p31 Microsoft is retiring the Azure resource "Database for MySQL single server" (see https://learn.microsoft.com/en-us/azure/mysql/migrate/whats-happening-to-my…). With this Werk we now support monitoring the recommended Azure resource "Database for MySQL flexible server". In the rule "Microsoft Azure" under "Azure services to monitor" users can now select the new option "Database for MySQL flexible server". (Note that the former option "Database for MySQL" was renamed to "Database for MySQL single server" and stays in place.) The metrics monitored for flexible servers correspond to those monitored for single servers and the same checks are used. See the <a href="https://checkmk.com/integrations?distributions%5B%5D=check_mk&distribut…">check plugin catalog</a> for more details.

2 months, 1 week

[2.2.0] Checkmk Werk 16431 adapted: omd restore: Fix RuntimeError: Failed to determine site version

by Checkmk werks level 1

Werk 16431 was adapted. The following is the new Werk, a diff is shown at the end of the message. Title: omd restore: Fix RuntimeError: Failed to determine site version Class: fix Compatible: compat Component: omd Date: 1718107423 Edition: cre Level: 1 Version: 2.2.0p32 Due to a regression introduced by <a href="https://checkmk.com/werk/16422">Werk #16422</a>, the command `omd restore <NEW_SITE> <ARCHIVE_PATH>` could fail: C+: File "/omd/versions/2.3.0p6.cee/lib/python3/omdlib/main.py", line 3522, in _restore_backup_from_tar old_site.replacements(), ^^^^^^^^^^^^^^^^^^^^^^^ File "/omd/versions/2.3.0p6.cee/lib/python3/omdlib/contexts.py", line 136, in replacements raise RuntimeError("Failed to determine site version") C-: The failure only occured, if the user provided a site name, which differed from the original name, and the original site did no longer exist. This crash also affected the `Migrate existing Site` function of the appliance. If you are affected by this crash, but are unable to update, then you can start be restoring the site without a new name. The site can then be renamed with `omd mv`. ------------------------------------<diff>------------------------------------------- Title: omd restore: Fix RuntimeError: Failed to determine site version Class: fix Compatible: compat Component: omd Date: 1718107423 Edition: cre Level: 1 - Version: 2.2.0p29 ? - + Version: 2.2.0p32 ? + Due to a regression introduced by <a href="https://checkmk.com/werk/16422">Werk #16422</a>, the command `omd restore <NEW_SITE> <ARCHIVE_PATH>` could fail: C+: File "/omd/versions/2.3.0p6.cee/lib/python3/omdlib/main.py", line 3522, in _restore_backup_from_tar old_site.replacements(), ^^^^^^^^^^^^^^^^^^^^^^^ File "/omd/versions/2.3.0p6.cee/lib/python3/omdlib/contexts.py", line 136, in replacements raise RuntimeError("Failed to determine site version") C-: The failure only occured, if the user provided a site name, which differed from the original name, and the original site did no longer exist. This crash also affected the `Migrate existing Site` function of the appliance. If you are affected by this crash, but are unable to update, then you can start be restoring the site without a new name. The site can then be renamed with `omd mv`.

2 months, 1 week

[2.2.0] Checkmk Werk 17092 adapted: Fix missing CSRF token issues

by Checkmk werks level 1

Werk 17092 was adapted. The following is the new Werk, a diff is shown at the end of the message. Title: Fix missing CSRF token issues Class: fix Compatible: compat Component: wato Date: 1719997630 Edition: cre Level: 1 Version: 2.2.0p32 Werk #17090 in Checkmk 2.3.0p8 and 2.2.0p29 introduced additional CSRF token checks in the GUI. This caused some buttons to not work anymore because the CSRF token was missing, including, but likely not limited to: LI: "Synchronize users" in Setup > Users to manually trigger the LDAP sync (the background sync still runs) LI: "Show analysis" and "Show bulks" in Setup > Events > Notifications LI: Reordering notification rules via drag-and-drop in the same view LI: "Bake agents" in the agent bakery (as a workaround, use "Bake and sign agents") LI: "Acknowledge last baking result" when a bake job failed (as a workaround, delete the failed job instead) This Werk fixes the issues by adding the token. ------------------------------------<diff>------------------------------------------- Title: Fix missing CSRF token issues Class: fix Compatible: compat Component: wato Date: 1719997630 Edition: cre Level: 1 - Version: 2.2.0p30 ? ^ + Version: 2.2.0p32 ? ^ Werk #17090 in Checkmk 2.3.0p8 and 2.2.0p29 introduced additional CSRF token checks in the GUI. This caused some buttons to not work anymore because the CSRF token was missing, including, but likely not limited to: LI: "Synchronize users" in Setup > Users to manually trigger the LDAP sync (the background sync still runs) LI: "Show analysis" and "Show bulks" in Setup > Events > Notifications LI: Reordering notification rules via drag-and-drop in the same view LI: "Bake agents" in the agent bakery (as a workaround, use "Bake and sign agents") LI: "Acknowledge last baking result" when a bake job failed (as a workaround, delete the failed job instead) This Werk fixes the issues by adding the token.

2 months, 1 week

[2.2.0] Checkmk Werk 17011 adapted: Fix local IP restriction of internal HTTP endpoints

by Checkmk werks level 1

Werk 17011 was adapted. The following is the new Werk, a diff is shown at the end of the message. Title: Fix local IP restriction of internal HTTP endpoints Class: security Compatible: compat Component: wato Date: 1718804769 Edition: cre Level: 1 Version: 2.2.0p32 Checkmk has some complex functionalities that are hidden behind an internal HTTP endpoint page. These pages are only meant to be accessed by internal processes, e.g. a cron runner or creating diagrams for notifications. Therefore these pages are protected to be only accessible locally. In order to recognize the client IP through the usage of a reverse proxy Checkmk uses the <code>X-Forwarded-For</code> header. That header is added and complemented by <code>mod_proxy</code> and usually trustworthy. When the site apache is exposed directly to the network though (e.g. the default docker setup) no proxy apache is there to curate this header. To mitigate this the site apache is supposed to filter these internal page URIs to be only accessible by localhost. This mitigation failed due to some outdated configuration and wrong configuration ordering. This only affects systems which expose the site apache port to the network typically 5000. If you run Checkmk behind a reverse proxy (the default if you installed a installation package) you are not affected! This vulnerability was identified in a commissioned penetration test conducted by PS Positive Security GmbH. Affected Versions: LI: 2.3.0 LI: 2.2.0 LI: 2.1.0 LI: 2.0.0 (probably older versions as well) Mitigations: You can add the following configuration to the site apache configuration, e.g. <code>etc/apache/conf.d/zzz_werk17011.conf</code>: C+: <Location "/###SITE###/check_mk/run_cron.py"> Order deny,allow Deny from all Require local Satisfy any </Location> # Webservice for graph images used by notifications <Location "/###SITE###/check_mk/ajax_graph_images.py"> Order deny,allow Deny from all Require local Satisfy any </Location> C-: Indicators of Compromise: You can check the apache access log <code>var/log/apache/access_log</code> for calls to <code>run_cron.py</code> or <code>ajax_graph_images.py</code> from network hosts. E.g. <code>grep --extended-regexp "^[^-].+(run_cron|ajax_graph_images.py)" var/log/apache/access_log</code> Vulnerability Management: We have rated the issue with a CVSS Score of 5.3 (Medium) with the following CVSS vector: <code>CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N</code>. We assigned CVE-2024-6163 to this vulnerability. Changes: This Werk fixes the configuration syntax and ordering. ------------------------------------<diff>------------------------------------------- Title: Fix local IP restriction of internal HTTP endpoints Class: security Compatible: compat Component: wato Date: 1718804769 Edition: cre Level: 1 - Version: 2.2.0p31 ? ^ + Version: 2.2.0p32 ? ^ Checkmk has some complex functionalities that are hidden behind an internal HTTP endpoint page. These pages are only meant to be accessed by internal processes, e.g. a cron runner or creating diagrams for notifications. Therefore these pages are protected to be only accessible locally. In order to recognize the client IP through the usage of a reverse proxy Checkmk uses the <code>X-Forwarded-For</code> header. That header is added and complemented by <code>mod_proxy</code> and usually trustworthy. When the site apache is exposed directly to the network though (e.g. the default docker setup) no proxy apache is there to curate this header. To mitigate this the site apache is supposed to filter these internal page URIs to be only accessible by localhost. This mitigation failed due to some outdated configuration and wrong configuration ordering. This only affects systems which expose the site apache port to the network typically 5000. If you run Checkmk behind a reverse proxy (the default if you installed a installation package) you are not affected! This vulnerability was identified in a commissioned penetration test conducted by PS Positive Security GmbH. Affected Versions: LI: 2.3.0 LI: 2.2.0 LI: 2.1.0 LI: 2.0.0 (probably older versions as well) Mitigations: You can add the following configuration to the site apache configuration, e.g. <code>etc/apache/conf.d/zzz_werk17011.conf</code>: C+: <Location "/###SITE###/check_mk/run_cron.py"> Order deny,allow Deny from all Require local Satisfy any </Location> # Webservice for graph images used by notifications <Location "/###SITE###/check_mk/ajax_graph_images.py"> Order deny,allow Deny from all Require local Satisfy any </Location> C-: Indicators of Compromise: You can check the apache access log <code>var/log/apache/access_log</code> for calls to <code>run_cron.py</code> or <code>ajax_graph_images.py</code> from network hosts. E.g. <code>grep --extended-regexp "^[^-].+(run_cron|ajax_graph_images.py)" var/log/apache/access_log</code> Vulnerability Management: We have rated the issue with a CVSS Score of 5.3 (Medium) with the following CVSS vector: <code>CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N</code>. We assigned CVE-2024-6163 to this vulnerability. Changes: This Werk fixes the configuration syntax and ordering.

2 months, 1 week

[2.2.0] Checkmk Werk 17078 adapted: MS Exchange: Use consistent units (ms/s) in rules & graphs

by Checkmk werks level 1

Werk 17078 was adapted. The following is the new Werk, a diff is shown at the end of the message. Title: MS Exchange: Use consistent units (ms/s) in rules & graphs Class: fix Compatible: compat Component: checks Date: 1720433457 Edition: cre Level: 1 Version: 2.2.0p32 The checks msexch_isclienttype, msexch_isstore, msexch_rpcclientaccess reported their values in ms in the summary/ruleset but displayed the same value as seconds in the graph. With this werk, all MS Exchange checks now report their values consistently. ------------------------------------<diff>------------------------------------------- Title: MS Exchange: Use consistent units (ms/s) in rules & graphs Class: fix Compatible: compat Component: checks Date: 1720433457 Edition: cre Level: 1 - Version: 2.2.0p31 ? ^ + Version: 2.2.0p32 ? ^ The checks msexch_isclienttype, msexch_isstore, msexch_rpcclientaccess reported their values in ms in the summary/ruleset but displayed the same value as seconds in the graph. With this werk, all MS Exchange checks now report their values consistently.

2 months, 1 week

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Checkmk werks level1