Chap 05 Linux Native Security Tools

Sommaire

Basic Commands and Configurations

Managing Users

Adding New User process

Commands

User Settings

Generate Encrypted Password

Application

[root@redhat ~]# openssl passwd -crypt 
Password:
Verifying - Password:
uyOvQmy1a9v/.


[root@redhat ~]# adduser user6 -p uyOvQmy1a9v/.
[root@redhat ~]# cat /etc/shadow

[root@lab ~]# adduser user3 -c "Eninam BAGNABANA" -e 2023-07-01 -p uyOvQmy1a9v/. -s /bin/bash
[root@lab ~]# adduser user4 --comment "Eninam BAGNABANA" --expiredate 2024-07-01 --password uyOvQmy1a9v/. --shell /bin/sh

Files

/etc/default/useradd : adduser command default settings File

Users Files and Directories

/etc/default/useradd : adduser command default settings File

Managing Passwords

In environments with multiple users, it is very important to use shadow passwords provided by the shadow-utils package to enhance the security of system authentication files.

For this reason, the installation program enables shadow passwords by default

Files

Other Commands

The su Command

Commands

su command users

Files

VI Improved (vim)

VI IMproved

The version of vi that is shipped with Red Hat Enterprise Linux 7 is called vim. vim stands for VI IMproved, as vim comes with many features not found in the original vi, while still remaining (mostly) backward-compatible. Among the new features are popular options, such as

• syntax highlighting,
• completion modes,
• and spell-checking.

Syntax

Execution modes

Editing Steps

When you first start working with a file, you are in command mode. Here, you can issue commands that allow you to move around your file without actually inserting text into the file.

When you’re ready to insert text into the file, you can use i or a to move into insert mode, enabling you to insert text at the cursor location. To move out of insert mode back into command mode, just press the Esc key.

The last mode you can enter is last line mode, which you enter by typing a colon (:). In this mode, you can issue additional commands to save, quit, and do even more.

Commands mode

Last line mode

Permissions

Permissions

Configuration

UMASK

Displaying umask

Default Permissions Determination

Modify umask

Ownership

chown Command [+]

Access List

POSIX Access list

Commands

Examples

Mask settings show the maximum permissions possible for all named users, the group-owner and named groups.

Autoriser user1 a editer le fichier/root/LAB-DIR/file1. NB il faudrait qu il ait les permissions sur /root/ et /root/LAB-DIR/

Autoriser les membres du groupe INGENIEURS a editer le fichier/root/LAB-DIR/file1. NB il faudrait qu ils aient les permissions sur /root/ et /root/LAB-DIR/

Delete all ACl on file2

Delete specific ACL

[root@redhat SCRIPTS]# ls -la
total 20
drwxr-xr-x. 2 root root   55 Mar 26 11:33 .
dr-xr-x---. 7 root root 4096 Mar 21 22:29 ..
-rwxrwxrwx. 1 root root  182 Mar 21 22:55 table
-rwxrwxrwx+ 1 root root  163 Mar 26 11:33 table2
-rw-r--r--. 1 root root    0 Mar 21 23:59 test
-rwxrwxrwx. 1 root root  102 Mar 22 00:16 testor

SSH

Secure Shell (SSH)

Accessing remote prompt

Secure Shell (SSH)

Authentication Methods

1. Password Authentication
2. SSH Key-based Authentication without passphrase
3. SSH Key-based Authentication with passphrase

Configuring SSH Key-based Authentication

Les utilisateurs peuvent authentifier les connexions SSH sans mot de passe en utilisant l'authentification par clé publique. Ssh permet aux utilisateurs de s'authentifier à l'aide d'un schéma de clé public-privé. Cela signifie que deux clés sont générées, une clé privée et une clé publique. Le fichier de clé privée est utilisé comme authentification, informations d'identification, et comme un mot de passe, doit être gardé secret et sécurisé. La clé publique est copiée dans les systèmes sur lesquels l'utilisateur veut se connecter, et est utilisé pour vérifier la clé privée. La clé publique n'a pas besoin d'être secrète. Un serveur SSH disposant de la clé publique peut lancer un défi qui ne peut être géré que par un système contenant votre clé privée. Par conséquent, vous pouvez vous authentifier en utilisant la présence de votre clé. Cela vous permet d'accéder aux systèmes d'une manière qui ne nécessite pas de taper un mot de passe à chaque fois, mais qui reste sécurisée.

1. Ensure for Key Based Authentication configuration on server
   
   
   /etc/ssh/sshd_config

   PubkeyAuthentication yes
   
   
   
2. Keys generation
   
   Keys generation is done using the ssh-keygen command. This generates
   • the private key ~/.ssh/id_rsa
   • the public key ~/.ssh/id_rsa.pub
   You can generate keys with or without passphrase. Generate keys without passphrase is useful for automation actions (Just enter when prompt asks you for passphrase)

   Once the SSH keys have been generated, they are stored by default in the .ssh/ directory of your home directory. Permissions should be 600 on the private key and 644 on the public key.

   
   
   
   
3. Check your keys
   
   Comparer les empreintes des clés
   Pour confirmer qu'une clé publique est valide et correspond à une clé privée, comparez leurs empreintes :
   
   - Empreinte de la clé privée
   # ssh-keygen -lf ~/.ssh/id_rsa
   
   - Empreinte de la clé publique
   # ssh-keygen -lf ~/.ssh/id_rsa.pub
   
   Si les empreintes sont identiques, la clé privée correspond bien à la clé publique.
   
   
   
4. Copy key to SSH Server system user
   
   

   Before key-based authentication can be used, the public key needs to be copied to the Destination system. This can be done with ssh-copy-id.

   # ssh-copy-id remote-user@remote-host
   When the key is copied to another system using ssh-copy-id, it copies the ~/.ssh/id_rsa.pub file by default.
   
   On Server authorized connections keys are stored in ~/.ssh/authorized_keys file
   
   
   
5. Initiate your ssh connection
   
   # ssh remote-user@remote-host -i pub_key_file

Customizing SSH Service Configuration

Prohibit the root user from logging in using SSH

Prohibit password authentication using SSH

Only allowing key-based logins to the remote command line has various advantages:

Firewall

Red hat firewall

If a server is connected to the Internet, it needs to be protected against unauthorized access. SELinux is one part of this protection, and a firewall is the second part. The Linux kernel implements firewalling via the netfilter framework. To configure which packets are allowed and which are not, firewalld is the default solution in RHEL 7.

Firewalld was developed as a complete new solution for managing Linux firewalls. It uses the firewalld service to manage the netfilter firewall configuration. The firewalld service is incompatible with the iptables service. Do not ever use firewalld and iptables on the same system; they are mutually exclusive.

The RHCSA objective does not define which tool you should use to create firewall rules. It just mentions that you should be able to create firewall rules by using iptables, firewall-config, or firewall-cmd. So, you do not have to be able to work with each of these tools; you just have to be able to configure a firewall with the tool that works best for you.

Understanding Firewalld Zones

Firewalld is making firewall management easier by working with zones. A zone is a collection of rules that are applied to incoming packets matching a specific source address or network interface. Firewalld applies to incoming packets only by default, and no filtering is happening on outgoing packets.

The use of zones is particularly important on servers that have multiple interfaces. On such servers, zones allow administrators to easily assign a specific set of rules. On servers that have just one network interface, you might very well do with just one zone, which is the default zone. Every packet that comes into a system is analyzed for its source address, and based on that source address, firewalld analyzes to see whether the packet belongs to a specific zone. If that is not the case, the zone for the incoming network interface is used. If no specific zone is available, the packet is handled by the settings in the default zone.

Firewall GUI tool

Firewalld Default Zones

Zone name Default Settings

Block Incoming network connections are rejected with an “icmp-host-prohibited” message. Only network connections that were initiated on this system are allowed.

Dmz For use on computers in the demilitarized zone. Only selected incoming connections are accepted, and limited access to the internal network is allowed.

Drop Any incoming packets are dropped and there is no reply.

External For use on external networks with masquerading (Network Address Translation [NAT]) enabled, used especially on routers. Only selected incoming connections are accepted.

Home For use with home networks. Most computers on the same network are trusted, and only selected incoming connections are accepted.

Internal For use in internal networks. Most computers on the same network are trusted, and only selected incoming connections are accepted.

Public For use in public areas. Other computers in the same network are not trusted, and limited connections are accepted. This is the default zone for all newly created network interfaces.

trusted All network connections are accepted.

work For use in work areas. Most computers on the same network are trusted, and only selected incoming connections are accepted.

Firewalld Zones

Listing Zones

The Default Zone

The Default Zone is the zone affected to unconfigured interfaces. By default, the default zone is "public". It's possible to change the default zone.

Assigning a Network Interface to a Zone

Assigning a Default Zone to a Network Connection

Creating a New Zone

Firewalld Services

The second key element while working with firewalld is the service. Note that a service in firewalld is not the same as a service in systemd. In firewalld, some default services are defined, which allows administrators to easily allow or deny access to specific ports on a server.

Behind each service is a configuration file that explains which UDP or TCP ports are involved, and if so required, which kernel modules must be loaded. To get a list of all services available on your computer, you can use the command firewall-cmd --get-services .

Services Files

Service files are stored in the directory /usr/lib/firewalld/services or /etc/firewalld/services.

It is possible, especially on remote systems, that an incorrect setting results in a user locking themselves out of a machine. To prevent such situations, use the --timeout option. After a specified amount of time, any change reverts to its previous state. Using this options excludes the --permanent option.

Disabling All Traffic in Case of Emergency using CLI

In an emergency situation, such as a system attack, it is possible to disable all network traffic and cut off the attacker.

Allow Traffic on ports:

SELINUX

Introduction

Since the earliest days of Linux, file permissions have been the standard method of securing Linux systems. In some cases, file permissions are just not enough for getting a secured server. Let’s take a look at an example:

One morning I found out that my server was hacked. An intruder had broken through a bad script on my web server and had obtained shell access as the httpd user. Using this file access, he managed to create thousands of little PHP scripts that were involved in a massive DDoS attack.

From a security perspective, it is interesting that nothing really was wrong with the security settings on this server. All permissions were set in a decent way, and the httpd user, like any other user on a Linux server, does have permissions to create files in /var/tmp, as in /tmp. So, what would have been a good solution to prevent this kind of problem?

You could, of course, argue that the administrator of the web server should have been doing a better job and should have been watching what the scripts on the server were doing. But that is not how Linux servers are normally used. The Linux server administrator does not know all the applications running on his server, and the application administrator does not understand enough about Linux to ensure that something like this can never happen.

Another solution is to apply further security measures. For instance, this specific situation would have been prevented if the permission to run program files from the /tmp and /var/tmp directory would have been taken away by using the noexec mount option. But even if that would have worked for this specific situation, it is not a good overall security solution that prevents applications from doing things they are not supposed to be doing.

That is why SELinux was invented. SELinux provides mandatory access control to a Linux server, where every system call is denied unless it has been specifically allowed. This chapter explains how to use SELinux to make sure that serious security incidents will never happen on your server.

Security Enhanced Linux (SELinux)

Understanding SELinux Working and Modes

If SELinux is enabled and nothing else has been configured, all system calls are denied. To specify what exactly is allowed, a policy is used. In this policy, rules define which source domain is allowed to access which target domain.

The source domain is the object that is trying to access something. Typically, this is a process or a user.

The target domain is the object that is accessed. Typically, that is a file, directory, or a network port to define exactly what is allowed; context labels are used. Using these labels is the essence of SELinux because these labels are used to define access rules.

SELinux Core Elements

On a Linux system, you can choose to enable or disable SELinux. When SELinux is enabled, kernel support for SELinux is loaded, and some applications that are SELinux aware change their behavior, because specific libraries are used on a system that has SELinux enabled. If SELinux is disabled, no SELinux activity will be happening at all. Changing between SELinux enabled and SELinux disabled mode requires a reboot of your system. This is because SELinux is a feature that is deeply interwoven with the Linux kernel.

If on a system SELinux is enabled, you can select to put SELinux in enforcing mode or in permissive mode. In enforcing mode, SELinux is fully operational and enforcing all SELinux rules in the policy. If SELinux is in permissive mode, all SELinuxrelated activity is logged, but no access is blocked. This makes SELinux permissive mode an excellent mode to do troubleshooting. Permissive mode is also a great way to do something and see the result from an SELinux perspective. That can help in building new and more efficient policies.

Principe

SELinux (Security Enhanced Linux) est un système de contrôle d’accès obligatoire (Mandatory Access Control) qui s’appuie sur l’interface Linux Security Modules fournie par le noyau Linux. Concrètement, le noyau interroge SELinux avant chaque appel système pour savoir si le processus est autorisé à effectuer l’opération concernée.

SELinux s’appuie sur un ensemble de règles (policy) pour autoriser ou interdire une opération. Ces règles sont assez délicates à créer, mais heureusement deux jeux de règles standards (targeted et strict) sont fournies pour éviter le plus gros du travail de configuration.

SELinux security Concept

Security Enhanced Linux (SELinux) is an additional layer of system security. A primary goal of SELinux is to protect user data from system services that have been compromised.

Configuration files and directories

SELinux context

SELinux Identities

SELinux Running Modes

Commands

semanage command

Installation

Commands

[root@lab ~]# semanage login -l liste les correspondances existantes entre identifiants d’utilisateurs et identités SELinux. Si un utilisateur n’a pas de correspondance explicite, il aura l’identité indiquée en face de __default__.

[root@lab ~]# semanage login -a -s user_u utilisateur va associer l’identité user_u à l’utilisateur.

[root@lab ~]# semanage login -a -s xguest_u utilisateur va associer l’identité xguest_u à l’utilisateur.

[root@lab ~]# semanage login -d utilisateur va retirer la correspondance affectée à l’utilisateur.

Chaque module SELinux fournit un ensemble de règles d’étiquetage des fichiers mais il est également possible de rajouter des règles d’étiquetage spécifiques afin de les adapter à un cas particulier. Ainsi pour rendre toute l’arborescence /srv/www/ accessible au serveur web on pourrait exécuter

La première commande enregistre la nouvelle règle d’étiquetage et la deuxième restaure les bonnes étiquettes en fonction des règles enregistrées. D’une manière similaire, les ports TCP/UDP sont étiquetés afin que seuls les démons correspondants puissent y écouter. Ainsi, si l’on veut que le serveur web puisse également écouter sur le port 8080, il faut exécuter la commande

[root@lab ~]# semanage port -m -t http_port_t -p tcp 8080

chcon Command

Commands

Exercise: Manipulating SELinux Modes

1. Open a root console on your server and type getenforce . You’ll normally see that SELinux is in enforcing mode.

2. Type setenforce 0 and type getenforce again. SELinux now switches to permissive mode.

3. Open the file /etc/sysconfig/selinux with an editor and change the line SELINUX= so that it reads SELINUX=disabled . Reboot your server.

4. After rebooting, log in to a root shell again and type getenforce . You’ll see that SELinux is now in disabled mode.

5. Try using the command setenforce 1 . You’ll see the message “setenforce: SELinux is disabled.” You cannot switch between disabled and enforcing mode without rebooting your server.

6. Open the file /etc/sysconfig/selinux again and change the line SELINUX=disabled back to SELINUX=enforcing . Reboot your system again.

7. After rebooting, type sestatus -v and read current status information about SELinux.

Exercise 21.2 Setting a Context Label on a Nondefault Apache Document Root

Secure and Troubleshoot Boot

Resetting the Root Password

1. On system boot, press e when the GRUB 2 boot menu is shown.

2. Enter rd.break as boot argument to the line that loads the kernel and press Ctrl+X to boot with this option.

3. You’ll now be dropped at the end of the boot stage where initramfs is loaded, just before a mount of the root file system on the directory /.

4. Type mount -o remount,rw /sysroot to get read/write access to the system image.

5. At this point, make the contents of the /sysimage directory your new root directory by typing chroot /sysroot .

6. Now you can enter passwd and set the new password for the user root.

7. Because at this very early boot stage SELinux has not been activated yet, the context type on /etc/shadow will be messed up. If you reboot at this point, no one will be able to log in. So you must make sure that the context type is set correctly. To do this, at this point you should load the SELinux policy by using load_policy -i .

8. Now you can manually set the correct context type to /etc/shadow. To do this, type chcon -t shadow_t /etc/shadow .

9. Reboot. You can now log in with the changed password for user root. systemctl reboot

PROTECTING GRUB 2 WITH A PASSWORD

• Password is required for modifying menu entries but not for booting existing menu entries;
• Password is required for modifying menu entries and for booting one, several, or all menu entries.

Configuring GRUB 2 to Require a Password only for Modifying Entries

To require password authentication for modifying GRUB 2 entries, follow these steps: Run the grub2-setpassword command as root:

Following this procedure creates a /boot/grub2/user.cfg file that contains the hash of the password. The user for this password, root, is defined in the /boot/grub2/grub.cfg file. With this change, modifying a boot entry during booting requires you to specify the root user name and your password.

Configuring GRUB 2 to Require a Password for Modifying and Booting Entries (RHEL 7)

menuentry 'Red Hat Enterprise Linux Server (3.10.0-327.18.2.rt56.223.el7_2.x86_64) 7.2 (Maipo)' --class red --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-3.10.0-327.el7.x86_64-advanced-c109825c-de2f-4340-a0ef-4f47d19fe4bf' {
        load_video
        set gfxpayload=keep

Manual changes to the /boot/grub2/grub.cfg persist when new kernel versions are installed, but are lost when re-generating grub.cfg using the grub2-mkconfig command. Therefore, to retain password protection, use the above procedure after every use of grub2-mkconfig.

If you delete the --unrestricted parameter from every menu entry in the /boot/grub2/grub.cfg file, all newly installed kernels will have menu entry created without --unrestricted and hence automatically inherit the password protection. Passwords Set Before Updating to Red Hat Enterprise Linux 7.2

The grub2-setpassword tool was added in Red Hat Enterprise Linux 7.2 and is now the standard method of setting GRUB 2 passwords. This is in contrast to previous versions of Red Hat Enterprise Linux, where boot entries needed to be manually specified in the /etc/grub.d/40_custom file, and super users - in the /etc/grub.d/01_users file.

Booting entries without the --unrestricted parameter requires the root password. However, GRUB 2 also enables creating additional non-root users that can boot such entries without providing a password. Modifying the entries still requires the root password. For information on creating such users, see the GRUB 2 Manual.

Open LDAP

Lightweight Directory Access Protocol (LDAP)

LDAP (Lightweight Directory Access Protocol ; http://www.openldap.org)

Les Annuaires sont des Bases de Données particulières spécialisées dans la recherche de l'information, pas dans le traitement

Évolutivité : on peut facilement ajouter des informations à un objet d'un annuaire (structure et contenu)

La dernière version LDAPv3 propose chiffrement (SSL, ...) et authentification (SASL) pour sécuriser l'accès aux informations

OpenLDAP est un annuaire dérivé de LDAP de l'Université du Michigan

Configuration Files