Unix System Resilience

1 Resilence for a System

After evaluating the risk of a Data Breach with a relative penalty in EU zone (4% of the annual worldwide turnover), then Decision Makers must run for cover and use for example the defense in depth composed by three elements:

• employees: who are educated and can watch also for perimeter protection,
• technology: eg  IDS / IPS, Firewall, Honeypot, ACL, TCP reset, Detect 0x90/Polimorphyc Shellcode, antivirus,
• operating modes: such as SW Patching, OS Update and Upgrade, Penetration Test, BC / DR: all periodic and repetitive activities.

Last but not least: documenting, documenting and finally documenting everything.

1.1 PurposeThe goal of this work is to define the process to obtain a resilient and secure basic configuration for operating systems (Unix). The indications provided are independent of the particular installed version of the Operating System, and are considered minimum measures the implementation of which is necessary to contain, within acceptable limits, the risk of compromises of confidentiality, integrity, and availability of the Information Resources.These instructions constitute the basic requirements that must be met and that, by virtue of the specific characteristics of the operating context to which they apply, can be increased in cases where higher levels of protection are required and must necessarily be followed also by the Platform Providers ITC.1.2 ScenarioThe following described technical instructions have been applied to a Solaris system, scanned by Nessus (free tools for up to 16 nodes), installed on Windows 7, from which to perform the penetration tests on the Solaris virtual node, installed using  Oracle VM VirtualBox. 2 Installation and updating of operating systemsBelow are the instructions to follow for the proper configuration and management of the Unix systems.The installation and initial configuration of any Operating System are operations of particular importance, since their execution may have implications on the security features of the same.Each Operating System must be installed respecting the security specifications required by the peculiarities of the platform and which may vary depending on:

• the applications that must be performed;
• the security level of data processed by the system;
• the type of service: development, test (or testing), production.

Any variation in the configuration of a system must be previously tested in development environments (when applicable) and testing, prior to its application in production environments. The installation of the Operating System must follow the procedures recommended by the supplier and in any case guarantee the "minimum installation" principle, according to which:

• each Operating System must be installed according to specifications for the hardware and software platform;
• only components that are strictly operational, functional and monitoring must be installed;
• only drivers necessary for the operation of the hardware must be installed;
• only kernels provided by the manufacturer must be used.

3 Patching

Once the initial installation has been completed, an adequate system security check must be guaranteed over time to verify its initial implementation within defined and acceptable levels for the Service platform. For the purposes of maintaining an adequate level of security the following activities must be carried out:

• periodic updating through system upgrades and patch installation, performed according to validated and controlled implementation standards immediately to avoid introducing new installation-specific variables;

• periodic checks and validations;

• continuous monitoring of the functions of each individual Operating System, platform or site;

• creation of system and data backup, according to the requested MTD;

• conservation of monitor data (eg system logs and accountability logs) for the fixed period of time and in accordance with current regulations on personal data protection.

3.1 Prerequisites

• The root user is required to execute the main Unix commands for the installation of the packages,

  Eg: on Solaris 10 pkgadd, (11 pkg), on Ubuntu / Debian apt-get, on RedHat / Centos yum, on HP swinstall, on AIX update_all

• The server connected to the internet in order to easily download the available updates directly from and on the server concerned.

• Make sure there are no defeated CPU / ram on the server, or failed drives.

• It is necessary to check the consistency of the FILESET and also the space available to perform the update, which can be analyzed using the pkgchk on Sun10, on 11 pkg in the dry run, and df commands for all.

• The compatibility of the kernel level must always be verified with the Operating System FIX, which must be compatible with the installed Firmware.

• The system to be updated must be backed up. For more details see the link:

Sun: https://docs.oracle.com/cd/E56341_01/html/E53705/filesystem-2.html#scrolltoc

Ubuntu: http://wiki.ubuntu-it.org/AmministrazioneSistema/BackupDelSistema

https://help.ubuntu.com/community/BackupYourSystem

RH: https://access.redhat.com/solutions/17525

HP-UX: https://docstore.mik.ua/manuals/hp-ux/en/5992-4165/ch04s03.html#cihhggfe

AIX: http://publib16.boulder.ibm.com/pseries/

If the server is configured with mirroring, you have to physically disconnect a system HD that is part of the mirroring pool or disable one, because, in the event of a failure of the system patches update procedure, you have the possibility to restart the server, reconnecting the HD preserved precautionary before the update intervention. If server belongs to a cluster, you have to disable the cluster and unhook it from the balancer.

To receive update notifications and download updates, the system administrator must create an account to access the website set up for this purpose

The installation of updates/upgrades, if available, must take place in the following chronological order :

• Firmware

• Kernel,

• OS

4 BC/DR

To guarantee service continuity, we need to design the dual or clustered architecture of the systems providing the service itself, the mirrored HDs and the replicated DBs, one in R / W, the other in Read only to balance the load of work, all in the event of a disaster, in order to perform a fast and reliable recovery.

In the specific case, the systems were cloned, an Oracle Box function.

5 Access Control/Hardening

To avoid potential vulnerabilities on Unix servers, you need to disable those services that allow the transmission of data in clear, such as the Rexecd daemon, which allows remote commands to be executed without encryption, as well as to delete vulnerable software or correct them with the appropriate patches.

It is also mandatory to use software for encrypting sensitive data in the databases, so for example when data is exported in Ascii format are not intelligible.

Another topic that falls into the vulnerabilities is that on passwords, not only must comply with the security requirements, ie length, at least one special character, a capital letter, etc. but it is absolutely forbidden to communicate them by email or leave them pinned on an unattended sheet on the desk, since 60% of cyber attacks occur inside own walls of work.

According to the "NIST directives", passwords must be longer than 14 char if multiple authentication tools such as tokens, otps, smartcards, and biometers are not used and must be changed every 45/60 days.

The login as an administrator must be from a client not connected to the internet, or from which you do not "surf," you can not read E-mail and you can not edit office documents.

Therefore direct access to Unix servers with the root user must be blocked.

However, we must pay attention to this stratagem, that is, if we use a transient user from which to make the user root switch, this user must not have  its home directory under /home, because if by mistake a third user uploads a huge file that saturates the file system /home, then no user who is not superuser can log in, as long as space is not freed up under the same /home but from the console itself.

Then minimum precaution, the Unix users present in the servers of an environment (eg Testing), must not have the same password to access the Production and/or Development servers.

You need to configure the system to register a log entry and warnings when a Unix account is added or removed from the domain administrators group, or when a new administrator account is created. Also, report any failed login attempts from a user administrator.

The root user access must be enabled on explicit request specifying the motivation and timing of use.