Checkmk werks level1 April 2024

checkmk-werks-lvl1@lists.checkmk.com

1 participants
306 discussions

[2.1.0] Checkmk Werk 15198 adapted: Brute-force protection ineffective for some login methods

by Checkmk werks level 1

Werk 15198 was adapted. The following is the new Werk, a diff is shown at the end of the message. Title: Brute-force protection ineffective for some login methods Class: security Compatible: compat Component: wato Date: 1712665452 Edition: cre Level: 1 Version: 2.1.0p43 Prior to this Werk, the mechanism to lock user accounts after too many failed login attempts was only effective for the web form login method. Login attempts via the REST API and basic authentication did not count towards the lockout mechanism. As a result, an attacker could try to brute-force user passwords without triggering the lockout mechanism. This Werk adds the same locking mechanism to login via the REST API and basic authentication for human user accounts. Note that automation accounts are remain unaffected by the lockout mechanism to avoid having them locked by malicious intent. It is therefore important to use long, random automation secrets. This issue was found during internal review. Affected Versions: LI: 2.3.0 (beta) LI: 2.2.0 LI: 2.1.0 LI: 2.0.0 (EOL) Mitigations: If updating is not possible, the brute-force attempts can be hindered by using a strong password policy. 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-28825</code>. ------------------------------------<diff>------------------------------------------- Title: Brute-force protection ineffective for some login methods Class: security Compatible: compat Component: wato Date: 1712665452 Edition: cre Level: 1 - Version: 2.1.0p42 ? ^ + Version: 2.1.0p43 ? ^ Prior to this Werk, the mechanism to lock user accounts after too many failed login attempts was only effective for the web form login method. Login attempts via the REST API and basic authentication did not count towards the lockout mechanism. As a result, an attacker could try to brute-force user passwords without triggering the lockout mechanism. This Werk adds the same locking mechanism to login via the REST API and basic authentication for human user accounts. Note that automation accounts are remain unaffected by the lockout mechanism to avoid having them locked by malicious intent. It is therefore important to use long, random automation secrets. This issue was found during internal review. Affected Versions: LI: 2.3.0 (beta) LI: 2.2.0 LI: 2.1.0 LI: 2.0.0 (EOL) Mitigations: If updating is not possible, the brute-force attempts can be hindered by using a strong password policy. 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-28825</code>.

4 months, 4 weeks

[2.1.0] Checkmk Werk 16197 adapted: quantum_libsmall_*: Improve SNMP detection

by Checkmk werks level 1

Werk 16197 was adapted. The following is the new Werk, a diff is shown at the end of the message. Title: quantum_libsmall_*: Improve SNMP detection Class: fix Compatible: compat Component: checks Date: 1709035896 Edition: cre Level: 1 Version: 2.1.0p43 Currently the SNMP detection for <code>quantum_libsmall_status</code> and <code>quantum_libsmall_door</code> checks if "linux" and "library" are contained in the sysDescr and sysLocation OIDs. To make the detection more reliable, the sysObjectID is checked against the linux object identifier and the libraryProductName .1.3.6.1.4.1.3697.1.10.10.1.10.0 against "Quantum Small Library Product". ------------------------------------<diff>------------------------------------------- Title: quantum_libsmall_*: Improve SNMP detection Class: fix Compatible: compat Component: checks Date: 1709035896 Edition: cre Level: 1 - Version: 2.1.0p42 ? ^ + Version: 2.1.0p43 ? ^ Currently the SNMP detection for <code>quantum_libsmall_status</code> and <code>quantum_libsmall_door</code> checks if "linux" and "library" are contained in the sysDescr and sysLocation OIDs. To make the detection more reliable, the sysObjectID is checked against the linux object identifier and the libraryProductName .1.3.6.1.4.1.3697.1.10.10.1.10.0 against "Quantum Small Library Product".

4 months, 4 weeks

[2.1.0] Checkmk Werk 15841 adapted: The configuration is correctly loaded by RRD helper processes

by Checkmk werks level 1

Werk 15841 was adapted. The following is the new Werk, a diff is shown at the end of the message. Title: The configuration is correctly loaded by RRD helper processes Class: fix Compatible: compat Component: core Date: 1711447383 Edition: cee Level: 2 Version: 2.1.0p43 This change ensures the reloading of the configuration by already running RRD processes, thereby guaranteeing that those processes are using the correct configuration. SUP-17787 CMK-16318 ------------------------------------<diff>------------------------------------------- Title: The configuration is correctly loaded by RRD helper processes Class: fix Compatible: compat Component: core Date: 1711447383 Edition: cee Level: 2 - Version: 2.1.0p42 ? ^ + Version: 2.1.0p43 ? ^ This change ensures the reloading of the configuration by already running RRD processes, thereby guaranteeing that those processes are using the correct configuration. SUP-17787 CMK-16318

4 months, 4 weeks

[2.1.0] Checkmk Werk 15843 adapted: mk_oracle(ps1): Follow-up to privilege escalation fix

by Checkmk werks level 1

Werk 15843 was adapted. The following is the new Werk, a diff is shown at the end of the message. Title: mk_oracle(ps1): Follow-up to privilege escalation fix Class: fix Compatible: incomp Component: checks Date: 1712314947 Edition: cre Level: 2 Version: 2.1.0p42 You might be affected by this Werk if you use <tt>mk_oracle</tt> on Windows. Werk <a href="https://checkmk.com/werk/16232">Werk #16232</a> introduced a regression, thereby disrupting Oracle monitoring on Windows. This Werk addresses above mentioned issue that affects versions 2.1.0p41, 2.2.0p24, and 2.3.0b4. Since this release, Oracle monitoring on Windows is fully supported under either of the following conditions: 1. The monitoring is performed using an account without administrator rights. 2. Specific Oracle executable binaries — namely, <tt>sqlplus.exe</tt>, <tt>tnsping.exe</tt> and, if presented, <tt>crsctl.exe</tt> - are not modifiable by non-admin users. If you are still unable to monitor Oracle, for example, you can't use an unprivileged account for monitoring and changing of permission is not possible, consider one of the following actions: 1. Enable <tt>Run as local group</tt> for group <tt>Administrators</tt> in <tt>Run plugins and local checks using non-system account</tt> ruleset. 2. Adjust <tt>Oracle Binaries Permissions Check</tt> settings in <tt>ORACLE databases (Linux, Solaris, AIX, Windows)</tt> ruleset. More information about can be found at <a href="https://checkmk.atlassian.net/wiki/x/AQA1B">here</a>. ------------------------------------<diff>------------------------------------------- Title: mk_oracle(ps1): Follow-up to privilege escalation fix Class: fix Compatible: incomp Component: checks Date: 1712314947 Edition: cre Level: 2 Version: 2.1.0p42 You might be affected by this Werk if you use <tt>mk_oracle</tt> on Windows. Werk <a href="https://checkmk.com/werk/16232">Werk #16232</a> introduced a regression, thereby disrupting Oracle monitoring on Windows. This Werk addresses above mentioned issue that affects versions 2.1.0p41, 2.2.0p24, and 2.3.0b4. - Since this release, Oracle monitoring on Windows is fully supported under ? - + Since this release, Oracle monitoring on Windows is fully supported under - condition you use an account without administrator rights or the certain - executable binaries, <tt>sqlplus.exe</tt>, <tt>tnsping.exe</tt> and, if - presented, <tt>crsctl.exe</tt> are write-protected, with the possible - exception being the Administrator. + either of the following conditions: + 1. The monitoring is performed using an account without administrator rights. + 2. Specific Oracle executable binaries — namely, <tt>sqlplus.exe</tt>, + <tt>tnsping.exe</tt> and, if presented, <tt>crsctl.exe</tt> - are not modifiable + by non-admin users. - If you are unable or prefer not to use an unprivileged account then you may - need to adjust permissions for above mentioned binaries: remove <tt>Write</tt>, - <tt>Full Control</tt> and <tt>Modify</tt> permissions for any non-Administrator - user and group. + If you are still unable to monitor Oracle, for example, you can't use an + unprivileged account for monitoring and changing of permission is not possible, + consider one of the following actions: + 1. Enable <tt>Run as local group</tt> for group <tt>Administrators</tt> in + <tt>Run plugins and local checks using non-system account</tt> ruleset. + 2. Adjust <tt>Oracle Binaries Permissions Check</tt> settings in <tt>ORACLE databases (Linux, + Solaris, AIX, Windows)</tt> ruleset. More information about can be found at <a href="https://checkmk.atlassian.net/wiki/x/AQA1B">here</a>.

4 months, 4 weeks

[2.2.0] Checkmk Werk 16696 created: Respect site filter in summary dashlets

by Checkmk werks level 1

Title: Respect site filter in summary dashlets Class: fix Compatible: compat Component: multisite Date: 1713780113 Edition: cre Level: 1 Version: 2.2.0p26 If you used the "Site" filter in a dashboard with a host or service summary dashlet, the filter was ignored.

4 months, 4 weeks

[2.2.0] Checkmk Werk 16633 created: Logfile pattern analyzer: Fix crash for first rule without regex pattern

by Checkmk werks level 1

Title: Logfile pattern analyzer: Fix crash for first rule without regex pattern Class: fix Compatible: compat Component: multisite Date: 1713341414 Edition: cre Level: 1 Version: 2.2.0p26 The "Logfile pattern analyzer" page crashed when the first "Logfile pattern" rule in place did not hold a regex pattern and a later rule did hold a regex pattern. The rendering of the table of rules would crash with C+: Internal error: list index out of range C-: This is fixed and all rules are rendered as expected.

4 months, 4 weeks

[2.2.0] Checkmk Werk 16554 created: df: Wrong handling of lower levels for free space

by Checkmk werks level 1

Title: df: Wrong handling of lower levels for free space Class: fix Compatible: compat Component: checks Date: 1713530112 Edition: cre Level: 1 Version: 2.2.0p26 This is a regression since Checkmk 2.2.0. When configuring the Service Monitoring Rule "Filesystems (used space and growth)", configured levels for free space were evaluated incorrectly. As a result, affected services erroneously showed up as CRIT. This happened because of a wrong rounding while evaluating the levels, and only affected small filesystems with a size below 1MB.

4 months, 4 weeks

[2.3.0] Checkmk Werk 16800 created: Fix crash in SNMPv1 and SNMPv2 connection tests

by Checkmk werks level 1

[//]: # (werk v2) # Fix crash in SNMPv1 and SNMPv2 connection tests key | value ---------- | --- date | 2024-04-19T15:28:03+00:00 version | 2.3.0b6 class | fix edition | cre component | wato level | 1 compatible | yes When running the SNMP connection tests for a host that has SNMPv3 credentials configured, the SNMPv1 and SNMPv2 connection tests crashed. With the Inline SNMP backend, the corresponding error message read "argument 2 must be str, not tuple". With the Classic backend, there was no error message at all.

4 months, 4 weeks

[2.4.0] Checkmk Werk 15329 created: mk_oracle: fix two parse errors

by Checkmk werks level 1

[//]: # (werk v2) # mk_oracle: fix two parse errors key | value ---------- | --- compatible | yes version | 2.4.0b1 date | 2024-04-09T06:01:31+00:00 level | 1 class | fix component | checks edition | cre Due to fixes introduced with <a href="https://checkmk.com/werk/16232">Werk #16232</a> new error messages have been introduced to sections which previously had not to handle any errors. Now <tt>oracle_processes</tt> and <tt>oracle_recovery_area</tt> services can handle the new error messages.

4 months, 4 weeks

[2.4.0] Checkmk Werk 15328 created: mk_oracle: Follow-up to privilege escalation fix: sqlnet.ora

by Checkmk werks level 1

[//]: # (werk v2) # mk_oracle: Follow-up to privilege escalation fix: sqlnet.ora key | value ---------- | --- compatible | no version | 2.4.0b1 date | 2024-04-05T09:38:28+00:00 level | 1 class | fix component | checks edition | cre You are affected by this Werk if you use mk_oracle agent plugin on unix. <tt>mk_oracle</tt> only works if it can find a <tt>sqlnet.ora</tt> in your <tt>$TNS_ADMIN</tt> folder. In the past, <tt>mk_oracle</tt> executed all oracle binaries as root, so <tt>sqlnet.ora</tt> was alwas readable. With <a href="https://checkmk.com/werk/16232">Werk #16232</a> the oracle binaries are executed with a low privileged user, so it might be the case, that <tt>sqlnet.ora</tt> can not be read by this user. <tt>mk_oracle</tt> will exit early if it can not read <tt>sqlnet.ora</tt>. The error message might look like: <code> /etc/check_mk/sqlnet.ora can not be read by user "oracle"! Either use 'sqlnet.ora permission group' bakery rule, or directly modify permissions of the file. </code> The error message will also be visible in the <tt>oracle_instance</tt> check. If you use the agent bakery to roll out mk_oracle to unix servers using <tt>.rpm</tt>, <tt>.deb</tt> or Solaris <tt>.pkg</tt> packages, you have to use the 'sqlnet.ora permission group' bakery rule to adapt the group of the <tt>sqlnet.ora</tt> file, otherwise your permission changes might be overwritten by updating the agent. Otherwise it is sufficient to adapt the permissions. If you install the agent on Unix using the <tt>tgz</tt> package, you will have to manually adjust the permissions of the <tt>sqlnet.ora</tt> file.

4 months, 4 weeks

← Newer
1
...
6
7
8
9
10
11
12
...
31
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Checkmk werks level1 April 2024