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

6 - Linux security: handling usage restrictions for CRON / CRONTAB services

HANDLING USAGE RESTRICTIONS FOR CRON / CRONTAB SERVICES

- Layout for this exercise:




- cron is a time-based job scheduler in Unix-like computer operating systems.

- cron can be used to schedule jobs (commands or shell scripts) to run periodically at fixed times, dates, or intervals. 

- It typically automates system maintenance or administration though its general purpose nature makes it useful for things like downloading files from the Internet and downloading email at regular intervals.

- cron is driven by a crontab (cron table) file, a configuration file that specifies shell commands to run periodically on a given schedule. 

- The crontab files are stored where the lists of jobs and other instructions to the cron daemon are kept. 

- Users can have their own individual crontab files and often there is a system wide crontab file (usually in /etc or a subdirectory of /etc) that only system administrators can edit.

https://en.wikipedia.org/wiki/Cron

- Reference for cron: 







- Reference for crontab:






- These two files play an important role:

/etc/cron.allow - if this file exists it must contain username for using cron jobs.

/etc/cron.deny - if the cron.allow file does not exist but the /etc/cron.deny file does exist then, to use cron jobs, the user must not be listed in the /etc/cron.deny file.

 - If neither of these files exist then, depending on site-dependent configuration parameters, either only the super user can use cron jobs, or all users can use cron jobs. 

- However, it is important to notice that root is always allowed to setup a crontab:




- Creating a cron.allow file to include the user johndoe:






- Going back to johndoe user account:




- Editing crontab for johndoe:






- Let's see what files are related with cron:




- Removing cron.allow:




- Specifically denying crontab access to johndoe by creating cron.deny:






- Now, johndoe is not allowed to use crontab:

5 - Linux Security: disabling the ROOT login

DISABLING THE ROOT LOGIN

- In this exercise a Linux Debian server is used:





- The goal of this exercise is to show how to prevent the users to login as a root, blocking full access to the system so that the chances of compromising the server are dramatically reduced.

- Editing the /etc/passwd file and focusing on the first line:

- Replacing that line with this new one:




- Going to the user johndoe now it is not possible to switch to the root user:






- Same thing applies to the roch user:






- Returning to the original configuration is possible because roch has the corresponding sudoers privileges to perform that operation, as seen in the previous exercise. From the roch user account the file /etc/passwd can be changed to its previous content:






- This exercise must be performed carefully, always ensuring that before disabling access to the root login there is at least one user (in this case roch) with enough privileges to be able to return to the previous configuration in case of need. Otherwise the system configuration would be impossible to be changed because nobody is going to be allowed to do it.