10 - Linux Security: restricting SSH users connections

RESTRICTING SSH USERS CONNECTIONS 

- Layout for this exercise:



- At any of the cases studied in this exercise the configuration file to be changed is /etc/ssh/sshd_config:





1 - SSH root restrictions

- By default the authentication for the root is set to PermitRootLogin without-password, meaning that the root is only allowed to SSH login with a key:




- To disable the SSH root login change to PermitRootLogin no:




- Restarting SSH service:




- Now there is no successful access for the root:




- Changing the root permission to yes:




- Now the access is successful:




2 - SSH other users restrictions

- Editing the file /etc/ssh/sshd_config and adding a line with directive AllowUsers to allow johndoe:




- Restarting SSH service:




- SSH connection for johndoe is successful:




- However, SSH access it is not possible for user marie because this user is not included in the line AllowUsers:

- Adding user marie to the directive AllowUsers:




- Restarting SSH service:




- Connecting successfully to user marie:




- Another way to deny a user to connect with SSH (apart of not including into the directive AllowUsers line) is to write an specific DenyUsers directive for the non allowed users. For instance let's take user kevin:




- Restarting SSH service:




- Now user kevin cannot connect to the SSH service:




- Same configurations and directives can be followed for groups in the same way of users.

9 - Linux Security: generating a pair of SSH keys (public/private)

GENERATING A PAIR OF SSH KEYS (PUBLIC/PRIVATE)

- Layout for this exercise:




- Public key cryptography or asymmetrical cryptography is a cryptographic system that uses a pair of keys.

- Public keys may be disseminated widely, and private keys are known only to the owner. 

- This accomplishes two functions: authentication, which is when the public key is used to verify that a holder of the paired private key sent the message, and encryption, whereby only the holder of the paired private key can decrypt the message encrypted with the public key:

https://en.wikipedia.org/wiki/Public-key_cryptography

- Generating a pair of keys (private and public) according to the RSA asymmetric cryptographic algorithm. Notice that a passphrase is optionally asked for:

https://en.wikipedia.org/wiki/RSA_(cryptosystem)




- The two keys are stored into the folder .ssh:




- The private key:




- The public key:




- Checking the IP:

- Copying the  public key so that locally available keys are used to authorize logins on remote machines:




- Trying the SSH connection:




- The passphrase is required to unlock the private key:





- Entering the passphrase (without password !!) the SSH connection is successful:




- Let's see that the public key was actually added:




- The authorized key matches the public key (id_rsa)obtained previously:




- Connecting from other server:

8 - Linux Security: SSH Banner and Message Of The Day

SSH BANNER AND MESSAGE OF THE DAY 

- Layout for this exercise:



- sshd_config is the file where SSH configuration is stored. 

- The banner displayed when connecting via SSH service is located at /etc/issue.net: 








- To display a message of the day (motd) the entry PrintMotd must be enabled to yes:





- Editing /etc/issue.net the default message showing the Linux version can be personalized:






- To personalize the message of the day just edit /etc/motd:







- Replacing the default message:




- Restarting SSH:




- Checking the IP:





- Accessing from a Windows machine with Putty:









- Banner:




- Message Of The Day:






- Accessing from a Linux Kali machine the banner is displayed:




- Also the Message Of The Day is displayed:

7 - Linux Security: privilege escalation manipulating a user's UID

PRIVILEGE ESCALATION MANIPULATING A USER'S UID

- In this exercise a Linux Debian server is used:

- By default the only user with UID=0 is the superuser root:

- However, let's see what happens if a user's UID is manipulated and changed to 0.

- Creating a new user marie:

 - Setting a password for the new user :

- Switching the session to the new user:

- The UID for the new user is 1004:

-  Now here comes the tricky part. A user with enough privileges to edit the /etc/passwd could manipulate this file changing the user's UID from 1004 to 0:

- Going to marie's session, let's see that  the user marie is considered exactly like the superuser root:

-  Now the new user's UID is 0, although the IDs for groups have not been changed::

- Actually there are two users (root and marie) with UID=0:

- The fact of owning an UID=0 (regardless of the name of the user) means that marie has full access to commands and files on the system, what can be considered as an example of privilege escalation.

- To restore the default configuration let's edit again /etc/passwd assigning an UID different to 0 to marie:

- Finally the default configuration is restored:

- As a general rule, and with the goal of avoiding privilege escalation, it is recommendable to check periodically that the only user with UID=0 is the root:




- The previous command performs this task:

a) awk               <- pattern scanning and processing language
b) -F:                 <- field
c) '($3 == "0")    <- if the 3rd field is equal to 0
d) print               <- print the line
e) /etc/paswd     <- scanning this file