Linux Security 101

Partitions:
- Mount "/" (root) partition read only and make symbolic links to other trees that are read-write
- Enable read only (ro) on selected file systems such as /boot (which does not change much),
  that way even the root user cannot modify the files without remounting the file system as rw
- Set partitions like (/tmp, /usr, /home) as no SUID or GUID partitions
  This also allows to restore parts of the filesystem without affecting the other parts.
- Allow users to work on system and access files on system and use applications on system,
  but never have access to the core operating system partitions and assoiciated file system within it.
- Edit /etc/fstab file to secure mounted file systems
- Ensure that file system uses a journaling system, such as ext3/reiserfs
- Avoid auto-mounting file systems if not needed.
 - Hackers might mount a floppy drive/usb/jazz drive on the system
 - Users might remount the ro (read-only) file systems into rw (read-write)
 - Lock down users mounting capabilities by controlling the /etc/fstab file
- Do not allow all users to mount file systems
- Disable running of executables in some filesystems, such as /home or publicly available filesystems.

Software:
- Install only what is required.
- By default Linux is going to install that will make it as usable as possible.
- Dont install development tools unless you plan to develop software
  - These include compilers, kernel source files, scripting engines, etc.
  - Installing a program from source will require compiler, kernel source files, etc which will be required to build that software.
    In such case, one should make it a standard practice to build the software on another system and upload the binaries.
    Keeping the production system free from all the development software.
  - Hackers can hack into the system write a malicious software and compile a binary if dev tools exist!
- Install packages from trusted binaries only.

* NO DEVELOPMENT SOFTWARE ON PRODUCTION SYSTEM!

Installation Security Configuration:
- Configure system to start in text only (Runlevel 3) mode instead of GUI
- Configure linux firewall options

Post Install Actions:
- Patch the system with latest vendor security patches and updates.
  - If you have kernel updates on the system that need to be installed, its important to wait till after the system successfully boots once to a user session
    before you install that particular upgrade or it could cause some issues with the bootloader or some of the configurations there.
  - So, if you want to update a kernel, do it before you install the OS or after a successful boot into a user session.
- Virus scan box before connecting to production network
- Do not have the system connected to the network until it has virus scanning capabilities
- Install other system protection suits
- Baseline the system after all the installations are done. This will include doing backups, verifying config and finally running Tripwire.
  After the baseline, Tripwire can monitor the system for changes.

Securing GRUB:
-Unsecured GRUB can allow unauthenticated users to run commands at boot time.
-GRUB allows bootloader password to be set and encrypted using MD5 hash
-/boot/grub/grub.conf

Security with User Accounts and Groups:
- Root UID = 0
- System UIDs: 1-100 (or 1-500 is some distros)
- User IDs upto 65536 possible
- Root group: GID = 0
- Secure the /etc/shadow files by assigning permissions of 400 to file - root is owner by default
shell > la /etc/*shad*
-r-------- 1 root shadow 656 May 23 11:51 /etc/gshadow
-r-------- 1 root shadow 993 May 23 11:57 /etc/shadow

-Force users to change passwords during first logons and then regularly within certain time intervals

Password Guidelines:
- Minimum 8 characters because anything less than 7 can be pattern identifiable.
- Minimum 14 characters for privileged accounts, this can push brute force attacks into years to crack them.
- Must not contain username in any shape or form and it should not contain any dictionary or guessable words (like P@$$w0rd)
- Must contain at least one each of the following types of characters: lowercase letter, uppercase letter, number and special character.
- Should not contain more of same character 3 times in succession.
- Passwords should be changed frequently (90 days)
- Do not allow users to change passwords again immediately after a password change
  - force a delay between changes (say 5 days) so that they just cannot cycle back through all of their previous passwords.
- Dont allow reuse of same password (hackers can wait for the same password pattern to reappear to attack)
- All the above complex requirements can be enforced using PAM (Pluggable Authentication Modules)

Use of Privileged Accounts:
- Practice 'principle of least privilege'
- Users should only have enough privileges to do a job - nothing more than that
- Limit remote login of root and other privileged accounts because we dont want to pass the password over the network.
  It could be sniffed.
- Limit direct login of privileged accounts.
  - Because there could be auto startup processes which are probably going to be executed under that user's privileges and rights.
    So, if we login with root, we open ourselves up to a lot of automatic startup issues that could affect the system.
  - We want to stick to the principle of least privilege
  - On an average work week sys admins do not require root privileges for a lot of things.
- Use 'su' or 'sudo' commands; sudo is preferred due to tighter security.
  - Using this we can temporarily gain privileged access to complete one or more tasks and then drop back.
  - This prevents unauthorized use / abuse of a privileged account.
- Authorized users and tasks for sudo are located in /etc/sudoers file
- Use of sudo is logged for accountability in syslog file
- Users should 'su' or 'sudo' to root or other privileged account, perform task, and then switch back to non-privileged account.
  - The syslog file is protected in a secure links configuration
- Restrict /etc/securetty to prevent unauthorized use of root account. We can limit the number of terminals available to be logged in by root.
  - Remove unwanted virtual consoles from /etc/securetty file. By default there are many.
  - tty = teletypewriter - it refers to the terminal that is running the process. (man tty)
  - pts = pseudo terminal - similar to above. (man pts)
  - When someone telnets into your system, linux sets up a pair of terminals - a master and a slave.
    The terminals live in the directory /dev/pts/ of the appropriate host and is named for the terminal number. i.e. /dev/pts/0

Securing Shells and Profiles:
- There are a lot of profile settings enabled by default for default users that are probably not necessary.
  Remove all the unnecessary things and only provide whats needed.
- Change /etc/skel as first step as it contains default settings for new users; will not affect previously created users.
- Global configuration settings can be stored in /etc/profile and /etc/environment.
  - Restrict permissions on these files to 644
- Local (user) initialization files usually located in user's home directory. They are responsible for cranking up components.
  Make sure to restrict them so that users are not going to startup software or other malicious components.
  - .login, .profile, .cshrc, .bashrc, .bash_profile, .bash_aliases, etc
   - These things control the shell settings, the path to the startup shell, any startup options associated with that as well as command aliases
     that might be used by that user. This is something that can greatly affect the security of your system because of the large scope of effect it
     can have when that user session is activated.
   - We should keep tight control over this and be aware what is contained in these files.
   - Files should be owned by user or root, and permissions set as no more than 740 to prevent unauthorized modifications of those files
     and to ensure that we can maintain them as root.
  - Path variables should not include a '.' or '::' to prevent executing commands in root directory.
    - The '.' or '::' generally indicate jumping over to a different directory. We should lock them down to the associated pass with the user and not allow
      to traverse as directories into less secure areas.
- Restrict use of unnecessary shells.
  - Users dont need access to several different shells, bash is sufficient.
  - Modify /etc/shells file to only contain authorized shells (ex: /bin/bash)
  - We should not have installed any additional shells in the first place! So, we should restrict those software packages.
  - We can also restrict certain users from logging in by specifying /bin/false as default shell