Slide 1
Most trusted JOB oriented professional program
DevOps Certified Professional (DCP)

Take your first step into the world of DevOps with this course, which will help you to learn about the methodologies and tools used to develop, deploy, and operate high-quality software.

Slide 2
DevOps to DevSecOps – Learn the evolution
DevSecOps Certified Professional (DSOCP)

Learn to automate security into a fast-paced DevOps environment using various open-source tools and scripts.

Slide 2
Get certified in the new tech skill to rule the industry
Site Reliability Engineering (SRE) Certified Professional

A method of measuring and achieving reliability through engineering and operations work – developed by Google to manage services.

Slide 2
Master the art of DevOps
Master in DevOps Engineering (MDE)

Get enrolled for the most advanced and only course in the WORLD which can make you an expert and proficient Architect in DevOps, DevSecOps and Site Reliability Engineering (SRE) principles together.

Slide 2
Gain expertise and certified yourself
Azure DevOps Solutions Expert

Learn about the DevOps services available on Azure and how you can use them to make your workflow more efficient.

Slide 3
Learn and get certified
AWS Certified DevOps Professional

Learn about the DevOps services offered by AWS and how you can use them to make your workflow more efficient.

previous arrow
next arrow

Complete Referance of Linux Security

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
  • 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 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