No, you can't. The rule explicitly states, that the line "cmdport 0" must be present in the config file. Please look into the provided links in my original mail regarding rhel9: https://www.stigviewer.com/stig/red_hat_enterprise_linux_9/2023-09-13/finding/V-257947 regarding rhel8: https://www.stigviewer.com/stig/red_hat_enterprise_linux_8/2021-06-14/finding/V-230486 which states what must be configured and how it is checked for this not to be a finding.
It forbids any and all network based monitoring of chrony (by requiring disabling it, completely and unconditionally). Not just badly secured network based monitoring. Regards Am Mo., 2. Sept. 2024 um 08:52 Uhr schrieb MUZZULINI Frank < frank.muzzul...@frequentis.com>: > Hi, > > > > I don’t know how this rules are checked, but if they are checked from the > outside, you could block the port via firewall on anything but loopback. > > This way you’d follow the rule and still can use the UDP port for local > monitoring. > > > > Regards, > > Frank > > > > *From:* Nuß Bratling <nussbratl...@gmail.com> > *Sent:* Wednesday, 21 August, 2024 1:53 PM > *To:* chrony-users@chrony.tuxfamily.org > *Subject:* [chrony-users] (SCAP-Finding) command port has to be closed > > > > **EXTERNAL source** > > > > Hi, > > > > There are these rules: > > RHEL9: > https://www.stigviewer.com/stig/red_hat_enterprise_linux_9/2023-09-13/finding/V-257947 > > RHEL8: > https://www.stigviewer.com/stig/red_hat_enterprise_linux_8/2021-06-14/finding/V-230486 > > > > We do monitoring, and these, above, rules define that the network > monitoring (command) port (with less permissions) has to be closed, so that > we have to connect to the unix socket with more permissions to get the > monitoring metrics. > > I'd argue that those rules make the security of a chrony installation > worse instead of better. > > I don't know if you know about these rules, and if no, would bringt it to > your attention, that this rules perhaps should be changes, or, if you do > know about these rules, I would like to ask what the rationale behind those > are. > > > > Thank you, > > > > Moritz Molle > > >
