Limited Time Offer!

For Less Than the Cost of a Starbucks Coffee, Access All DevOpsSchool Videos on YouTube Unlimitedly.
Master DevOps, SRE, DevSecOps Skills!

Enroll Now
Linux

Complete Referance of Linux Security

September 17, 2021 comments off

Course Outline

  • Introduction To Linux Security
  • Secure Linux Installation
  • Securing The Linux Boot Process
  • User Accounts and Groups
  • File System Security and Permissions

Introduction To Linux Security

  • A bit About Linux
  • Current Security Problems
  • Requirements of a secure OS
  • Which is More Secure: Window vs Linux?
  • Linux Security Features Overview

A Bit About Linux

  • Open Sourse OS with proven track record
  • Alternative to closed Sourse OS
  • Comparable and competitive features
  • Highly secure, dependable OS
  • Wide variety os uses(personal,servers)
  • Comes in many “distributions”
  • Red Hat, Debian, SuSe, Slax, Mandriva
  • Other function-specific distros are built on basic ones to perform specific functions
  • Allows Security to be defined on a role-based function for implementation

Current Security Problems

  • Malware
  • Identity Theft
  • Data Theft
  • Unsafe Internet Use
  • Network/Computer Intrusion

which is more secure: Windows vs Linux?

  • Windows is most popular OS, but is highly attacked and exploited due to popularity
  • Microsoft is improving security in products
  • Windows security fixes can be slow coming,
  • incompatible wirth apps,and closed source
  • Linux can address All of these problems!
  • Linux does not suffer from same proportion of attacks due to lower popularity
  • Still suffers from the same issues!
  • Biggest problem is lack of user knowledge and complacency

Requirements of a Secure OS

  • Protection against intrusion from malicious entities(hackers)
  • Protection aainst malware
  • Secure data transmision capability
  • Secure data storage capability
  • Individually defined users
  • Positive identification and authentication of users and other entities (Computers)
  • Ability to separate users into roles or groups with varying access needs,rights, and privileges.
  • Ability to define access permissions to resources and allow/deny access
  • Ability to audit actions of individuals or processes on computer
  • Flexible security mechanisms to adjust to environment

Overview of Linux Security Features

  • Meets requirements of secure operating systems
  • Can be made to be VERY secure, yet flexible for wide range of needs
  • Wide array of security mechanisms, tools, software, and features.
  • Allows for securing resources with access controls, such as users, groups, and permissions
  • Allows for secure network and internet access by users
  • Built-in tools for securing resources available to network/Internet users
  • Apache, Bastille, Tripwire, PAMs etc.
  • Can be made as secure as desired
  • Lerning curve can be a bit steep

Sercure Linux Installation

  • Selecting the Right Distribution
  • Defining Partitions for Security
  • Intalling Software and Services
  • Installing Secure File Systems
  • Installation Security Configurations
  • Post Install Actions

Selecting the Right Distribution

  • Base selection on security features offered
  • Plan for role of box – workstation, file server, infrastructure server, multi-role server – and install for that role
  • Some distros better suited for different roles – It’s ok to go with multiple distros!
  • Linux can be freely downloaded
  • Unless you trust the download source, possibility exists of trojaned binaries
  • Best download source is usually company that produces distro(RH, Mandriv, SuSe)

Defining Partitions for Security

  • Use multiple partitions rather than putting entire filesystem on single partition
  • Enables separate partitions to have different access permissions/restrictions
  • Prevents attacker from filling up entire disk with garbage, or accessing entire disk
  • Mark some partitions as read only, such as “/”(root)
  • Set some partitions (/tmp, /user, /home) as No SUID or GUID
  • Restrict access to system partitions

Intalling Software and Services

  • Install only necessary software and services – never go with “Everything”!
  • Attack surface is reduced with only minimum installed services
  • Base installed services/software on machine role – dhcp, dns, samba, etc.
  • Install only packages from trusted binaries

Installing Secure File Systems

  • Ensure file system uses a journaling file system, such as ext3/reiserfs
  • Mount “/” as read only and make symbolic links to other trees that are read-write
  • Edit /etc/fstab file to secure mounted file systems
  • Avoid auto mounting file systems if not needed
  • Do not allow all users to mount filesystems

Installation Security Configurations

  • Create other uses than ‘root’
  • Configure Linux Firewall options. Learn about installing a CSF firewall on Linux servers if you require an additional level of security above and beyond what is provided natively, including defense against common DDoS attacks.
  • Choose local login ore NIS login depending upon network configuration
  • Configure computer to start in text only(Runlevel 3) mode instead of GUI

Post Install Actions

  • Patch computer with latest vendor security
  • Virus scan box before connecting to production network
  • Baseline system by running Tripwire

Secure Installation Demonstration

  • Installation of Ubuntu 20.04.3
  • Virtual machine environment using Oracle Virtualbox
  • Non-relevant parts omitted due to time

Securing the Linux Boot Process

  • Securing LILO
  • Securing GRUB
  • Runlevel Security and inittab
  • Partition Mounting and fstab

Securing LILO

  • Single-User mode can be started by typing ‘linux single’ at the LILO boot: prompt
  • Single user mode (runlevel 1) is basic mode of Linux OS that can load with root-level privileges but no root passpord required – bypasses login requirement
  • Single-User mode can protected by requiring password
  • Uses ‘password’ key word in /etc/lilo.conf
  • Can protect all(if placed ‘global’ section of file) boot images or only certain ones if placed in ‘image’ section for selected image.
  • Passing arguments at boot prompt can cause unsecured boot of system
  • Example: LILO boot: init=/bin/bassh causes execution of bash root shell with no login prompts or security checking
  • ‘restricted’ key word used in /etc/lilo.conf can prevent passing of arguments at boot tie unless password is used.
  • Requires ‘password’ keyword to be used.
  • Other options used in file include ‘prompt’ and ‘timeout’ key words to prevent access in event of accidental reboot
  • File permisions for /etc/lilo.conf should be restricted to 600

Securing GRUB

  • Newer boot loader used in Linux
  • Unsecured GRUB can allow unauthenticated users to run commands at boot time
  • GRUB allows bootloader password to be set and encryted using MD5 hash
  • Uses /boot/grub/grub.conf file to configure
  • Create MD5 hshed password using MD5crypt, then pass hash into file
  • Users can no longer view password
  • ‘lock’ command enables you to secure any boot entry for options or multi-boot systems
  • ‘lock’ command also takes its own password entry, so different options have different passwords
  • Restrict access to /boot/grub/grub.conf file by setting file permissions to 600

Runlevel Security and init

  • init process starts and controls system once kernel is started
  • Uses ‘runlevels’ to determin which services start and which users can be login
  • Runlevel is controllerd through /etc/inittab
  • Runlevel 0: system halted
  • Runlevel 1: Single User mode
  • Runlevel 3: Multi-user, network services stated
  • Runlevel 5: Multi-user with X Windows
  • Runlevel 5 is usually default configuration for most linux systems
  • Recommend change in /etc/inittab file to Runlevel 3 then ‘startx’ after boot
  • Prevents X-Windows apps from auto-running (security risk) if not needed

Partition Mounting and fstab

  • Secure mounting of filesystems through use of /etc/fstab text configuration file
  • Some partitions and filesystems should be mounted with special secure configurations
  • Separate system and user files as much as possible on separate filesystems
  • Assign certain filesystems their own partition: /home, /tmp, ‘/'(root) and assign appropriate options
  • Easier to secure/backup many small partitions than one large one
  • Use ‘suid’ ‘sguid’ options sparingly – enable executables to be run as their owner – source of many exploits – use ‘nosuid/nosguid
  • Disable running of executable in some filesytems, such as /home or publicly available filesystems.
  • Enable read only (ro) on selected filesystems containing executables or sensitive data – especially Internet facing systems
  • Do not enable ‘any’ user to mount a partition automatically.

Security With User Accounts and Groups

  • Users and Groups
  • Passwords
  • Use of Privileged Accounts
  • Security User Shells and Profiles
  • All users have accounts, even system users
  • Accounts control access to resources through permissions
  • Groups are groupings of user accpunts that have similar access requirements

Users and Groups

  • User accounts and groups are assigned user IDS(UIDs) and group IDs(GIDs)
  • IDs are unique to user or group
  • IDs assigned by sytem in blocks, or can be assigned by root user when accounts are created
  • Root group:GID 0
  • Select a UID/GID manually,or allow user creation tool/GUI to select
  • Keep same UIDs/GIDs across NFS environment to ensure user can acccess resources across network shares.

Passwords

  • Passwords previously stored encrypted on Unix/Linux systems in /etc/passwd text file, but world readable
  • Now passwords in /etc/passwd removed – replaced with ‘x’ in field to indicate use of shadow passwords file
  • Passwords now stored in /etc/shadow text file in encrypted from (Using MD5 by default)
  • File now readable only by root
  • Passwords can be converted from stc/passwd to shadow using ‘pwconv’
  • Protect /etc/hadow file by assigning permissions of 400 to file – root is ower by default
  • Ensure no ‘+’ character in file to prevent potential unwanted NIS access
  • Secure password must be assigned to user account upon creation – don’t use blank paswords or username as password
  • User can change password using ‘passwd’ command
  • ‘chage’ command used to specify password chaning (age) attributes
  • Use to specify whether
  • Password must be changed on first login
  • Time between password expires
  • Account lockout time after password expiration
  • Advance warning(time) before password expiration
  • Number of days before user must wait to change password
  • Password creation guidelines include:
  • Must be minimum of 8 characters, 14 for privileged accounts
  • Must not contain username
  • Must not contain dictionary or easily guessable word(such as P@$$w0rd)
  • Must contain at least one each of the following types of Characters: lowercase letter, upper case letter, number, and special character
  • Should not contain more of same character 3 times in succession
  • Don’t allow reuse of Same password
  • Password complexity requirements can be enforced using Pluggable Authentication Modules(PAMs)

Use of Privileged Accounts

  • Practice ‘principle of least privilege’
  • Users should only have enough privileges to do job – no more than that
  • Limit remote login of ‘root’ and other privileged accounts
  • Limit direct login of privileged accounts
  • 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
  • Restrict /etc/securetty to prevent unauthorized use of root account
  • Remove unwanted virtual consoles from /etc/securetty file

Securing Shells and Profiles

  • Restrict default user profile settings
  • Change /etc/skel as first step – contains default settings for new users; will not affect previously created users.
  • Global configuration settings can be stored in /etc/profile, /etc/.login,
  • Restrict permissions on these files to 644 and ensure owner is root
  • Local (user) initialization files usually located in user’s home directory
  • Can include .login, .profile, .cshrc, .bash_profile, and others
  • Sets shell settings, path, options, command aliases, etc.
  • Files should be owned by user or root, and permissions set a no more than 740
  • Path variable should not include a ‘.’ or ‘::’ to prevent executing commands in root directory
  • Restrict normal user use of unneeded shells
  • users should not be allowed to use different shells – bash is sufficient
  • Modify /etc/shells file to contain only authorized shells.(example – /bin/bash)
  • Modify /etc/passwd for user’s default shell.

File System Permissions

  • Types of Files
  • Permissions Stucture
  • Special Permission Bits
  • Managimg Permissions

Types of Files

  • Everything in Linux represented by a file
  • File can be:
  • Directories(d)
  • Files(-)
  • Devices(block ‘b’ or character ‘c’)

Permissions Stucture

  • All files can be assigned permissions
  • Permissions dictate what user can do to file
  • 3 basic permissions: read(r) write(w) and execute(x)
  • Read enables reading files and traversing/listing directories
  • Write enables changing and deleting files and adding files(to a directory)
  • Execute enables execution of executable files and scripts
  • Users can have any combination of these 3 permissions
  • Permissions are indicated for 3 classes of users: owner, group, and others(world)
  • Each class can be assigned any different combination of 3 basic permissions
  • User could have read and write only(rw), execute only(x),or all 3 permissions (rwx)
  • Permissions usually listed for all classes
  • Example: -rwxr-xr– indicates owner has all 3, group has read and execute, and all others have only read
  • ‘-‘ indicates users class does not have that permission
  • Permissions also given inoctal notation
  • Numbers represent permissions
  • Read:4
  • Write:2
  • Execute:1
  • In octal notation, numbers are added for each individual permission to give overall value for user class
  • Example: 7 indicates all 3 permissions: 4+2+1=7. 6 Indicates rw only: 4+2=6
  • 0 Indicates no permissions for that class
  • Permissions for all user classes for file given in 3-digit number
  • Example: file has permission of 740 indicates owner has full(rwx or 4+2+1, group has read(r or 4) and others have no permissions (indicated by 0))

Special Permission Bites

  • Special permissions also exist:
  • Set UID(SUID bit)
  • Set GID(SGID bit)
  • Sticky Bit
  • SUID indicates that any user who executes a file does so with permissions of the file ower’s UID – effectively has those permissions
  • GUID indicates that the user executes a file with whatever permissions the group has
  • SUID and SGID set on directories enables files creaed in directories to have the directory owner set as the file owner instead of the user creating the files
  • Use suid and sgid bits with caution – big security risk!
  • Sticky bit is set to protect files from being renamed or deleted in a directory.
  • If bit is set, even user with write permissions canot delete or rename file
  • File can only be renamed/deleted by file owner, directory owner, or root.

Managing Permissions

  • Permissions and use classes for files managed using 3 primary utilities:
  • chmod sets/changes permissions
  • chown sets/changes file owner
  • chgrp sets/changes group
  • chmod sets permissions for files and directories
  • Can use octal or regular natation
  • Can set special permission bits
  • chmod demonstration
  • chown sets owner and group of file
  • Can only be run by root user
  • chown demonstration
  • chgrp sets group for file
  • Can be run by normal (unprivileged) user
  • User can only change group to one which they are a member of
  • chgrp demonstation
Rajesh Kumar
Follow me
Latest posts by Rajesh Kumar (see all)