Hi,
CIS harding does remove a number of services and makes sure certain access rights are set and
a number of authentication related procedures are enforced.
Also, it would require apparmor or similar (not sure about SUSE) to be enforcing.
You need to run through the list in order to sort out the services which do not affect IDS.
In general, with some adjustments, IDS should work in a CIS hardened image when
the kernel and library constraints of IDS are matched (e.g libaio) and the system settings
for shared memory are big enough, which applies to all IDS systems.
My first thought would be that the internal creation of the INFORMIXTMP folder in root could
maybe violate the standard.
The enforced not-presence of graphical environment, webserver, dns service etc. is ok from my point of view,
when talking about a dedicated DB server instance.
It might be a little work to define apparmor profiles (or SELinux, whatever).
Using a backup agent might require additional setup (AIDE, Apparmor/SELinux etc).
In case you are using rsync for some mirroring of scripts the CIS setup would not allow this by default.
Same for NFS ...
In order to centrally manage the instance, a solution like ansible would be recommended, which does
not require an agent, but works with ssh and sudo.
LDAP client (or SSSD) might be a requirement in your environment, which is also removed in CIS in the standard, you need to
add an exception.
The CIS hardenened network configuration should not affect IDS connections.
Firewall should allow only incoming connections on the IDS ports + ssh. This makes sense.
CIS has different approaches here (nft, ufw, iptables), in all rulesets the setup should not be very complex
for a dedicated DB server.
Outgoing connections should be restricted to an update server and a central syslog server,
normally the database does not need to establish a new connection (maybe for a remote backup).
Auditing in general does not prevent the functionality of IDS, we have it activated on all systems.
Same for AIDE, you just need to list which binaries have open TCP ports.
Securing the /var/log could be an issue, maybe put the online.log/console.log in a different location (separate volume).
On some systems, the logind.conf needs to be modified (RemoveIPC=no) and a sysctl parameter needs
to be adjusted (fs_protected_regular, at least for IDS14, did not test with IDS 12).
This is a security relevant parameter which affects the ability to overwrite files in a directory which has the "t" flag
(INFORMIXTMP has this setting). Informix when started as root (oninit has suid flag) will prepare some files there
and then switch to informix user, and then tries to write this prepared files, which is denied when the parameter
is not set).
This might break some security constraints of CIS, you might need to check with your Suse recommendations.
Hope this helps.
Best,
Original Message:
Sent: 4/26/2023 3:31:00 AM
From: Dave Nelson
Subject: CIS Hardened SUSE Image and Informix 12.10
Hey all,
Firstly, I will apologise if this post is in the wrong group. Hopefully not, but apologies if so.
I am just looking for some information (be it docs or user experience) around any issues that people may have come across when using Informix upon a SUSE Linux OS image that has been CIS hardened.
Being perfectly honest, I am not an expert in either SUSE or Informix (I'm an infra architect by trade operating mainly in the WINTEL space) but we have some software that relies heavily on Informix and with cloud migrations on the go for my company, we're looking at CIS hardened SUSE OS images with various cloud providers.
Any words of wisdom welcome and any experiences (good or bad) would also be grand so I can feed back to our Dev team.
Thank you,
Dave.
------------------------------
Dave Nelson
------------------------------