Linuxsec3e PPT ch06

CHAPTER 6
Securing
Services
Copyright © 2024 by Jones & Bartlett Learning, LLC an Ascend Learning Company. www.jblearning.com.
Learning Objective(s) and Key Concepts
Learning Objective(s) Key Concepts
Copyright © 2024 by Jones & Bartlett Learning, LLC an Ascend Learning Company. www.jblearning.com
 Explain user account management,  Starting a hardened system
configure file permissions and
 Managing and hardening services
filesystem settings, enforce
encryption, and secure Linux  Using mandatory access controls
services.
 Protecting against development
tools
Starting a Hardened System (1 of 4)
 Hardening
 The process of locking down a system to protect it and any resources that
may reside on it
 Includes data, services, and the system itself
 Minimal installation
 No graphical user interface (GUI)
 Provides fewer ways for an attacker to access a system
 Additional software can be added later, if needed (easier than paring down
software after installing a complete system )
 Red Hat Package Manager (RPM)

 Doesn’t handle automatic installation of dependencies
 Tells you what you were missing
 Yellowdog Updater, Modified (yum)
 Downloads RPM files from a network site
 Identifies packages that must be installed before the package you want is
installed
 Installs everything, in the correct order
 When you install a package on a Red Hat–based system using yum or dnf, you
end up with a list of all the packages you need to ensure the one package you
want functions properly.
 This can have a cascading effect, however.
 If package A has a dependency for package B, but package B requires both
packages C and D, the installation of package A will require the installation of
packages B, C, and D.
 When trying to protect yourself, especially on systems that face the Internet, the
best approach is to start with a minimal installation and add only software that is
absolutely necessary.
OpenJava JDK Dependencies
Select Minimal Install
 A minimal installation provides a console without a graphical interface.
 A “workstation” installation provides a GUI and everything needed for a system
that can do workstation/desktop-related tasks.
 Installing the workstation adds many packages because each of these software
packages has a large number of dependencies.
 If you want more control over the dependencies that will be installed, you can
build everything by hand after you have a minimal system build and a set of
development tools, such as a compiler and a make utility (just as a starting
point).
Service Management
 Starting up services
 Ensuring those services all start up correctly
 Manually starting and stopping services
SysV Init (1 of 3)
 Runlevels
 Way of categorizing functionality by determining in which mode a system
will operate and which services will be available
 Different runlevels used for different purposes
 init
 Master process that starts all services
 Linux Standard Base (LSB)
 Specification calls for seven runlevels
 Bourne Again Shell (Bash
 Command interpreter used to issue text commands
Runlevel Definitions
RUNLEVEL PURPOSE
0 Shutdown—Setting the runlevel to 0 will shut the system down.
1 Single user—This is commonly used for administrative purposes.
Multiuser mode, no network—Users will have to log in, but no network
2
interfaces are configured.
Multiuser mode with network—The system will require you to log in, and
3
you will have network interfaces configured.
4 Not used.
5 Multiuser with network and GUI—The GUI is started automatically.
6 Reboot—If you set the system to this runlevel, the system will reboot.
SysV Init (2 of 3)
 Starting services manually is as easy as running a script in /etc/init.d/ or the link

in a runlevel directories.
 This has to be done as an administrative user, either as root directly or using
sudo to temporarily get administrative privileges.
 To start the Postfix mail server, for example, you would issue the command
/etc/init.d/postfix start.
 To stop the service, you issue the command /etc/init.d/postfix stop.
SysV Init (3 of 3)
 There are easier ways to perform the same functions, though.
 Rather than typing the path to the script and then the script name, it’s easier to
use the service command.
 The service utility passes commands to the service scripts without having to call
the service script directly.
 To restart the Postfix service, you just pass the name of the service along with
the restart command.
Using the Service Command to Start Postfix
Systemd
 Used by Red Hat for system startup beginning with RHEL 7
 Ubuntu migrated to systemd in lieu of Upstart beginning 2015
 First process that starts on a system is systemd rather than init
 Provides a foundation for management of entire system
 Provides better security to services
 Uses feature-rich configuration files
 No scripting in configuration files, only settings related to service
Hardening Services
 Force system to run with a limited set of permissions
 Limit network communication from remote hosts
 Restrict interfaces on which service listens
 Implement access control lists (ACLs) and/or authentication to control access to
network services
 Example: Apache web server supports user authentication before allowing access
to the pages served up by the web server
Listening Ports
Using Mandatory Access Controls
 Mandatory access controls

 Set of policies and permissions established at the system level
 Users cannot change the permissions
 SELinux and AppArmor
 Discretionary access controls
 Access can be modified by users
Security Enhanced Linux (SELinux)
 Developed by National Security Agency (NSA)
 Red Hat has completed a lot of development work on it
 Provides a lockdown on filesystem files
 Implements labels to provide more granularity with permissions on files
 Permissions can be set to permissive or enforcing mode
 In enforcing mode, kernel modules prevent unauthorized access
 Users cannot make changes to permissions
 If a process doesn’t have the right content, it won’t bind to the port
AppArmor
 Developed for the Linux distribution, Immunix
 Currently used in Ubuntu and its derivatives
 apparmor_status command provides a list of profiles in enforce mode
 Supports both enforce and complain modes
 Can be configured on a per-application basis to either complain or enforce
 Installed application must have an associated AppArmor profile
 Provides a comprehensive way to restrict all permissions associated with any
executable on the system if a profile is created
Servers Versus Desktops
Server Desktop
 Limited set of services exposed to  More packages installed
the outside world
 Different services installed
 The only running services should
 Has only one interface
be the primary services the server
needs and is there to provide  May use the Network File System
 Administrative services should (NFS) service to connect to file
servers or other desktop systems
exist on separate interface and
not be exposed  May have other services
 May have multiple network associated with remote access
interfaces
Protecting Against Development Tools (1 of 3)
 Having development tools installed on the system was considered a risk

because if an attacker was able to break into a system, that person could use
the tools build any attack tool he or she wanted and then deploy it.
 Command injection attack
 An attacker sends a shell command into a web application and has the
operating system execute it.
 Then, the attacker can have the system download the source code for an
attack tool, build the tool, and use it—all from the vulnerable web page.
 Allows an attacker to open a shell remotely that they could use to further
take advantage of the system.
 If build tools aren’t installed on target system, attack tool can’t be built.
 Operating system
 If the primary CPU in use is an Intel compatible and the system is Linux,
you can build any tool you want and just grab a prebuilt binary to run on the
target system.
 If Linux is the operating system (and most Linux systems run on Intel
systems), an attacker can build any Linux tool ahead of time and put it on
the target system when needed.
 Most Linux systems have package-management systems in which tools can be

easily installed from a package repository.
 If you have the distribution, you know which package-management system you
are dealing with, and you can install anything you want—including development
tools.
 The more packages you have installed, the more risk you assume.
 Most systems have some form of scripting language installed that can be
exploited to create a variety of attack tools. Limit scripting languages, if
possible.
Summary
 Starting a hardened system
 Managing and hardening services
 Using mandatory access controls
 Protecting against development tools

Linuxsec3e PPT ch06

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Linuxsec3e PPT ch06

Uploaded by

Copyright:

Available Formats

CHAPTER 6

Learning Objective(s) Key Concepts

 Red Hat Package Manager (RPM)

 A minimal installation provides a console without a graphical interface.

 Starting services manually is as easy as running a script in /etc/init.d/ or the link

 There are easier ways to perform the same functions, though.

 Used by Red Hat for system startup beginning with RHEL 7

 Force system to run with a limited set of permissions

 Mandatory access controls

 Developed by National Security Agency (NSA)

 Developed for the Linux distribution, Immunix

 Having development tools installed on the system was considered a risk

 Most Linux systems have package-management systems in which tools can be

 Starting a hardened system

You might also like