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 ------------------------------

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,

Can't thank you enough, Marcus. I will feed back with the detail you have provided and come back if needed. Thanks again, Dave. ------------------------------ Dave Nelson ------------------------------

Been hardening Informix servers (RH 7/8/9 and Informix 12.x and 14.x) based on the recommendations from CIS-CAT scans. They don't highlight anything to do with Informix specifically. The only push back I get is from the root installation, but changing from a root install to a non-root install is a non-trivial activity and has, to date, always allowed me to get an exception Cheers Paul

Thanks, Paul. Really good to know. Appreciate you taking the time to reply. Cheers, Dave. ------------------------------ Dave Nelson ------------------------------

Hello, CIS as a standard has two levels for server and not knowing which one, level 1 or 2 your referencing makes recommendations a bit nuanced. Talking them through about how a system could/would be impacted with an experienced Linux System Administrator is recommended. To be honest CIS assumes a very narrow worst-case scenario (a lone gazelle in the open safari surrounded by lions). CIS 1 does have recommendations on /tmp that could interfere with v12< Informix installations due to mount attributes. (1.1.3 no exec) this can be changed during installation/upgraded but might require a server boot depending on its configuration. CIS 1 also has recommendations on tightening user umask that could impact an organization and how staff have used local Informix user. (5.4.5 umask & 6.1.8 world writable files) for intake/publishing data/logs/etc. Advanced FACL is a good middle ground. If your organization uses ldap (2.2.6 ldap disabled) for OS and DB logins, you have to understand how those interplay with the CIS guidance. Lastly the audit subsytem could be a factor of performance degradation (4.1.13 audit file delete events) if your org does a lot fast & tiny temp file deletion in your pipeline or local UIDs > "1000" Good luck! J ------------------------------ Joseph Foss ------------------------------