Takeaway: Operating system images available in IBM SmartCloud Enterprise are more tightly secured than “out-of-the-box” installations.
When you install Red Hat or SUSE Linux from scratch, you get an operational Linux server that is reasonably secure. However, widely accepted best practice suggests that you should take time to further lock down the security of that server before you place it onto an unsecured or public network.
Of course, when an instance is brought up on a public cloud such as IBM SmartCloud Enterprise, it is immediately available on the public Internet, meaning it is potentially a target for hackers from the moment it is first started. Thus, there is a need to ensure that all images are already locked down to a greater extent before they are made available to our customers to be brought up on the Internet.
The process of making a Linux image available to SmartCloud Enterprise customers includes several customizations that minimize the target profile of any new instance:
- The Linux firewall is configured to allow only SSH traffic; all other ports are blocked.
- The sshd configuration is tightened:
-Password authentication is disabled. The only authentication method accepted is by means of a private RSA key held by the customer.
-The less-secure SSH protocol version 1 is disabled.
-SFTP is disabled.
-Only a single non-privileged user account is allowed access.
-Root login is disabled. - Unused services are disabled. For example, http, ftp, and smtp services are all disabled in our Base OS images.
- SELinux is enabled.
- Login to the root account is disabled:
-root’s password is locked.
-root’s shell is set to /bin/nologin. - The user account is added to /etc/sudoers.
- Password complexity requirements are tightened:
-Minimum length is eight characters.
-Must contain at least three character classes (uppercase, lowercase, numerics, specials).
-Must be changed after 90 days.
These changes result in a Linux image that IBM is comfortable making available to our customers for use on the Internet without any further modification.
Astute readers will have noticed that some of these restrictions appear redundant – what is the point of putting password restrictions in place if password authentication is disabled anyway? The reason for this becomes clear when you realize that after an image is brought up, the customer has complete control over it and is free to make any further changes that might be needed or desired. If, for example, the customer needs to install a software product that requires password authentication, and reconfigures ssh to allow such access again, then the instance is still protected by the tighter password requirements and disabling of root access.


You can add to the security the xml firewall at hypervisor level and the datacenter security
…Good post¡¡