Linux Security

• Linux server security: Three steps to secure each system

Auditing
To audit a Linux system we use our open source tool Lynis and perform a system scan. It runs on almost all Unix and Linux based systems and only requires a shell and root permissions. After the scan all findings will be reported and additional information will be stored in the log files (/var/log/lynis.log). Also a hardening index will be displayed, to give the auditor a first impression on how well the system is hardened.

Hardening
After running Lynis it’s time to deal with the findings.

Compliance
maintain the effect or earlier security efforts, it’s important to keep measuring your security level and compare them with baselines.Every system should be checked on a regular base and deviations to your standard should be detected as soon as possible. By determining the risk level of this deviations, it will be much easier to take an appropriate action or implement different security measures.
https://linux-audit.com/linux-server-security-three-steps-to-secure-each-system/

• the su command requires you to enter the password of the target user.

There's another way to switch to the root user: run the 'su -' command:

Now, what's the difference between 'su' and 'su -' ? Well, the former keeps the environment of the old/original user even after the switch to root has been made, while the latter creates a new environment (as dictated by the ~/.bashrc of the root user), similar to the case when you explicitly log in as root user from the log-in screen.
The optional argument - may be used to provide an environment similar to what the user would expect had the user logged in directly.

So, you'll agree that logging in with 'su -' makes more sense. But as the 'su' command also exists, one might wonder when that's useful.
the benefits and pitfalls of the 'su' command

It sometimes can be advantageous for a system administrator to use the shell account of an ordinary user rather than its own. In particular, occasionally the most efficient way to solve a user's problem is to log into that user's account in order to reproduce or debug the problem.
However, in many situations it is not desirable, or it can even be dangerous, for the root user to be operating from an ordinary user's shell account and with that account's environmental variables rather than from its own. While inadvertently using an ordinary user's shell account, root could install a program or make other changes to the system that would not have the same result as if they were made while using the root account. For instance, a program could be installed that could give the ordinary user power to accidentally damage the system or gain unauthorized access to certain data.

-, -l, --login
Provide an environment similar to what the user would expect had the user logged in directly.

When - is used, it must be specified as the last su option. The other forms (-l and --login) do not have this restriction.

su -c
It lets you provide a command that you want to run after switching to the target user.


Sudo vs Su
The primary difference between the two is the password they require: while 'sudo' requires current user's password, 'su' requires you to enter the root user password
Quite clearly, 'sudo' is a better alternative between the two as far as security is concerned.
For example, consider the case of computer being used by multiple users who also require root access. Using 'su' in such a scenario means sharing the root password with all of them

Moreover, in case you want to revoke the superuser/root access of a particular user, the only way is to change the root password and then redistribute the new root password among all the other users.

With Sudo, on the other hand, you can handle both these scenarios effortlessly. Given that 'sudo' requires users to enter their own password, you don't need to share the root password will all the users in the first place. And to stop a particular user from accessing root privileges, all you have to do is to tweak the corresponding entry in the 'sudoers' file.

The other difference between the two commands is in their default behavior. While 'sudo' only allows you to run a single command with elevated privileges, the 'su' command launches a new shell, allowing you to run as many commands as you want with root privileges until you explicitly exit that sell.

So the default behavior of the 'su' command is potentially dangerous given the possibility that the user can forget the fact that they are working as root

Logging
Although commands run through 'sudo' are executed as the target user (which is 'root' by default), they are tagged with the sudoer's user-name. But in case of 'su', it's not possible to directly trace what a user did after they su'd to the root account.

Flexibility
The 'sudo' command is far more flexible in that you can even limit the commands that you want the sudo-ers to have access to. In other words, users with access to 'sudo' can only be given access to commands that are required for their job. However, with 'su' that's not possible - either you have the privilege to do everything or nothing.

Sudo su
some Linux distributions - like Ubuntu - disable the root user account by default.

In case you want to enable the root account on your system
sudo passwd root

https://www.howtoforge.com/tutorial/sudo-vs-su/

• If sudo has been configured to allow the user to run root's shell, the user can run sudo -s or sudo -i to mimic su or su -l, respectively, and supply his own password or no password rather than root's password. Similarly, sudo -u john -i mimics su -l john if you are allowed to run john's shell

The default behavior of su is to remain within the current directory and to maintain the environmental variables of the original user (rather than switch to those of the new user).

it is advisable that administrative users, as well as any other users that are authorized to use su (and it is suggested that there be very few, if any) acquire the habit of always running the su command with the -l/--login option. It has two effects:
     switches from the current directory to the home directory of the new user (e.g., to /root in the case of the root user) by logging in as that user
    changes the environmental variables to those of the new user as dictated by their ~/.bashrc. That is, the current directory and environment will be changed to what would be expected if the new user had actually logged on to a new session (rather than just taking over an existing session).

su and wheel
BSD su allows only members of the "wheel" group to assume root's identity by default. This is not the default behavior of GNU su, but this behavior can be mimicked using PAM. Uncomment the appropriate line in /etc/pam.d/su and /etc/pam.d/su-l:

https://wiki.archlinux.org/index.php/Su

•  Configuring and Using Chroot Jails

 A chroot operation changes the apparent root directory for a running process and its children. It allows you to run a program with a root directory other than /. The program cannot see or access files outside the designated directory tree. Such an artificial root directory is called a chroot jail, and its purpose is to limit the directory access of a potential attacker. The chroot jail locks down a given process and any user ID that it is using so that all they see is the directory in which the process is running. To the process, it appears that the directory in which it is running is the root directory
 The chroot mechanism cannot defend against intentional tampering or low-level access to system devices by privileged users. For example, a chroot root user could create device nodes and mount file systems on them. A program can also break out of a chroot jail if it can gain root privilege and use chroot() to change its current working directory to the real root directory. For this reason, you should ensure that a chroot jail does not contain any setuid or setgid executables that are owned by root
 https://docs.oracle.com/cd/E37670_01/E36387/html/ol_cj_sec.html

•  the chroot “Jail” we built to watch his activities

 With these holes he could often subvert the uucp and bin accounts in short order, and then root.
 We added a few fake services, and I wrote a script to scan the logs daily.

 FTP: The scanner produces a report of all login names that were attempted.
 It also reports the use of a tilde (a possible probe of an old FTP bug), all attempts to obtain FTP’s /etc/passwd and /etc/group files, and a list of all files stored in the
pub directory.

 Telnet/login:All login attempts are logged and reviewed daily

 Guest/visitor accounts:A public computer account is the first thing a cracker looks for.
 The cracker can also get a list of hosts trusted by this machine from the /etc/hosts.equiv and various personal .rhosts files

 Finger: Finger provides a lot of information useful to crackers: account names, when the account was last used, and a few things to try as passwords.

 http://www.cheswick.com/ches/papers/berferd.pdf

• How do I change the root directory of a command?

How do I change the root directory of a process such as web-server using a chroot command to isolate file system?
How do I use a chroot to recover password or fix the damaged Linux/Unix based environment?
Each process/command on Linux and Unix-like system has current working directory called root directory of a process/command.
You can change the root directory of a command using chroot command, which ends up changing the root directory for both current running process and its children.
A process/command that is run in such a modified environment cannot access files outside the root directory. This modified environment is commonly known as “jailed directory” or “chroot jail”.
Only a privileged process and root user can use chroot command

    Privilege separation for unprivileged process such as Web-server or DNS server.
    Setting up a test environment.
    Run old programs or ABI in-compatibility programs without crashing application or system.
    System recovery.
    Reinstall the bootloader such as Grub or Lilo.
    Password recovery – Reset a forgotten password and more.

https://www.cyberciti.biz/faq/unix-linux-chroot-command-examples-usage-syntax/

• Chroot is an operation that changes the apparent root directory for the current running process and their children. A program that is run in such a modified environment cannot access files and commands outside that environmental directory tree. This modified environment is called a chroot jail.

Changing root is commonly done for performing system maintenance on systems where booting and/or logging in is no longer possible. Common examples are:

    Reinstalling the bootloader.
    Rebuilding the initramfs image.
    Upgrading or downgrading packages.
    Resetting a forgotten password.
    Building packages in a clean chroot, see DeveloperWiki:Building in a Clean Chroot.
https://wiki.archlinux.org/index.php/change_root

A chroot is basically a special directory on your computer which prevents applications, if run from inside that directory, from accessing files outside the directory. In many ways, a chroot is like installing another operating system inside your existing operating system.
https://help.ubuntu.com/community/BasicChroot

• ‘sudo‘ is a root binary setuid, which executes root commands on behalf of authorized users and the users need to enter their own password to execute system command followed by ‘sudo‘.

https://www.tecmint.com/su-vs-sudo-and-how-to-configure-sudo-in-linux/

• Sudo (sometimes considered as short for Super-user do) is a program designed to let system administrators allow some users to execute some commands as root (or another user).

Auditing/logging: when a sudo command is executed, the original username and the command are logged.
For the reasons above, switching to root using sudo -i (or sudo su) is usually deprecated because it cancels the above features.
https://wiki.debian.org/sudo