Lesson 02: Unix Security

Advanced Computer Security

Kushan Sharma
[email protected]
 Topics to be Covered
◼ Security Best Practices
◼ Fresh Installation
◼ File System Configuration
◼ Controlling Access to Files
◼ Use of Secure Software and Services
◼ TCP Wrappers

Prepared by: Kushan Sharma 2

 Exercise 01: Possible Attacking Methods
◼ An attack surface is the total sum of the vulnerabilities in a given computing
device or network that are accessible to a hacker. Briefly list such
vulnerabilities?

Prepared by: Kushan Sharma 3

 Design Goals at Early Stages
◼ Security was not a design goal due to the trust relationship.
◼ Security was not a design goal of the protocols that were being created at the
time, such as FTP, SMTP, and Telnet.
◼ Currently the widespread network is clearly a hostile environment.
◼ Many of these insecure protocols have become deeply rooted and are proving
difficult to replace.

Prepared by: Kushan Sharma 4

 Attacking Surface

Prepared by: Kushan Sharma 5

 Attacking Surface
◼ The combination of software services that an attacker could exploit, through
either vulnerabilities or insecure configurations.
◼ Follow the general principle of “turn off what you don’t need,”
◼ Reduce Attacking Surface Example (Assume that the system is being configured
as a web server.):
◼ Many Unix systems default to run level 5, which provides a nice graphical interface
◼ To run a web server, a graphical console will not be required.
◼ The system should be defaulted to run level 3, which provides a command-line login
capability without all the overhead and vulnerabilities associated with the GUI.

Prepared by: Kushan Sharma 6

 Exercise 02: Server Hardening
◼ What is server hardening?
◼ Server Hardening is the process of enhancing server security through a variety of
means which results in a much more secure server operating environment.
◼ This is due to the advanced security measures that are put in place during the server
hardening process.
◼ Briefly describe the process of server hardening?
◼ Turning off unnecessary software components and securely configuring those that
remain.
◼ Changes the computer from a well-known target that attackers could easily break
into to a system that is able to defend itself.
◼ Make the attacker’s job more difficult—by removing the most common flaws they
know how to exploit.
◼ Do you patch, configure, and secure software that you’ll never use? Briefly
explain your answer?
◼ Get rid of unused software by removing them.
◼ This make s an attacker’s job harder by cutting down on the overall number of
vulnerabilities that can be exploited.
◼ Modern OSs supports many network protocols, applications, and daemons in their
default installation, assuming that they will be used in networked environment.
Prepared by: Kushan Sharma 7
 Security Best Practices
◼ Best practices provide the most significant improvements to the security.
◼ Reduce the attack surface of systems by turning off unneeded services.
◼ Install secure software.
◼ Configure software settings securely.
◼ Patch systems regularly and quickly.
◼ Use firewalls and other network security devices to segment the network into zones
of trust.
◼ Strengthen authentication processes.
◼ Limit the number (and privileges) of administrators.

Prepared by: Kushan Sharma 8

 RHEL/CentOS 7 Minimal Installation
◼ Preferred in Enterprise and production environment

Prepared by: Kushan Sharma 9

 Exercise 03: Start with a Fresh Install
◼ Why should you start with a fresh installation of operating system?
◼ Upgrading today is possible, but to keep the system clean over multiple successive
upgrades requires an uncommonly high level of skill.
◼ A new version of OS may have dropped a particular package from the default system
because it offers duplicate functionality, but such packages will not necessarily be
removed from the system during an upgrade.
◼ Helps to assure that nobody has installed rogue daemons, Trojans, rootkits, or any
other nasty surprises.
◼ Been connected to network, unsupervised users may will remove the guarantee of
not having malicious contents.

Prepared by: Kushan Sharma 10

 Fresh Installation: File System Configuration
◼ Create separate Partition for /tmp
◼ /tmp - a world writable directory used for temporary storage by all users and some
applications.
◼ Avoid the risk of resource exhaustion if it is not bound to a separate partition.
◼ Allows an administrator to set the noexec option on the mount, making /tmp
useless for an attacker to install executable code.
◼ Verify that there is a /tmp file partition in the /etc/fstab file.
# grep "[[:space:]]/tmp[[:space:]]" /etc/fstab

◼ Create separate Partition for /var

◼ /var - used by daemons and other system services to temporarily store dynamic
data.
◼ Avoid the risk of resource exhaustion if it is not bound to a separate partition.
◼ Verify that there is a /var file partition in the /etc/fstab file.
# grep "[[:space:]]/var[[:space:]]" /etc/fstab

Prepared by: Kushan Sharma 11

 Fresh Installation: File System Configuration
◼ Bind mount the /var/tmp directory to /tmp
◼ Binding /var/tmp to /tmp establishes an unbreakable link to /tmp that cannot be
removed.
◼ Allows /var/tmp to inherit the same mount options that /tmp owns, allowing
/var/tmp to be protected in the same /tmp is protected.
◼ Prevent /var from filling up with temporary files as the contents of /var/tmp will
actually reside in the file system containing /tmp
◼ To configure the file system correctly
# mount --bind /tmp /var/tmp
Edit the /etc/fstab file to contain the following line
/tmp /var/tmp none bind 0 0
◼ Perform the following to determine if the system is configured correctly.
# grep -e "^/tmp[[:space:]]" /etc/fstab | grep /var/tmp
/tmp /var/tmp none none 0 0
# mount | grep -e "^/tmp[[:space:]]" | grep /var/tmp
/tmp on /var/tmp type none (rw,bind)

Prepared by: Kushan Sharma 12

 Fresh Installation: File System Configuration
◼ Create separate partition for /var/log
◼ Used by system services to store log data
◼ Reasons to ensure that system logs are stored on a separate partition:
◼ protection against resource exhaustion (since logs can grow quite large)
◼ protection of audit data.
◼ Verify that there is a /var/log file partition in the /etc/fstab file.
# grep "[[:space:]]/var/log[[:space:]]" /etc/fstab

◼ Create separate partition for /var/log/audit

◼ To store stores log data in the /var/log/audit directory
◼ The audit daemon calculates how much free space is left and performs actions based
on the results. If other processes consume space in the same partition as auditd, it
may not perform as desired.
◼ Verify that there is a /var/log/audit file partition in the /etc/fstab file.
# grep "[[:space:]] /var/log/audit[[:space:]]" /etc/fstab

◼ Create separate partition for /home also.

Prepared by: Kushan Sharma 13

 Fresh Installation: When not feasible?
◼ When fresh installation is not feasible:
◼ Option 01: Take an unused server, perform a clean install of your operating system
on it, and use that server to compare files with the target system. Run the below
command on each system:
# find / -ls > /tmp/machine.files
Then use the diff command to get a list of differences:
# diff machine1.files machine2.files > machines.diff

◼ Option 02: Verify Package Integrity Using RPM using below command on RHEL 7 or
CentOS 7. This helps system administrators to detect if package files were changed,
which could indicate that a valid binary was overwritten with a trojaned binary.
# rpm -qVa | awk '$2 != "c" { print $0}'
If any output shows up, you may have an integrity issue with that package

Prepared by: Kushan Sharma 14

 Things to Do After Minimal RHEL/CentOS 7
◼ Configure network with static IP address
◼ To check the IP address #ip addr show
◼ To enable the networking interface at boot time:
# vi /etc/sysconfig/network-scripts/ifcfg-enp0s3
Change ONBOOT = no to ONBOOT = yes
◼ Reboot the server.
◼ Configure a static IP by editing the above script.
◼ Install net-tools to use ifconfig, netstat utilities.

Prepared by: Kushan Sharma 15

 Things to Do After Minimal RHEL/CentOS 7
◼ Set a hostname for the server
◼ To check the hostname # echo $HOSTNAME
◼ To change hostname
# hostnamectl set-hostname <hostname>
◼ Update or upgrade CentOS minimal install
◼ To update:
# yum update && yum upgrade
◼ Install and configure SSH server
◼ Edit the SSH configuration file ‘/etc/ssh/ssh_config‘ to secure the ssh
communication

Prepared by: Kushan Sharma 16

 Things to Do After Minimal RHEL/CentOS 7
◼ FirewallD configuration.
◼ Removes iptables in CentOS 7 and it is installed by default.
◼ To check the status:
# systemctl status firewalld
# firewall-cmd --state
◼ Get a list of all the zones.
# firewall-cmd --get-zones
◼ To get details on a zone before switching.
# firewall-cmd --zone=work --list-all
◼ To list all the services in the zone.
# firewall-cmd --list-services
◼ Install and configure sudo
◼ # usermod -aG wheel username

◼ Configure cron jobs

◼ Password protected GRUB

Prepared by: Kushan Sharma 17

 Use a Software Firewall
◼ iptables allows packet filtering and network address translation via
command-line configuration on some flavors of Linux.

◼ firewalld is available with RHEL/CentOS 7

◼ firewalld is dynamic rather than static because changes to the configuration
can be made at anytime and are immediately implemented.
◼ firewalld configuration files can be edited, written to, backed up, used as
templates for other installations.

Prepared by: Kushan Sharma 18

 RHEL/CentOS 7: firewalld
◼ Differences between firewalld and the
iptables service:
◼ The iptables service stores configuration in
/etc/sysconfig/iptables while firewalld
stores it in various XML files in
/usr/lib/firewalld/ and
/etc/firewalld/.
◼ With the iptables service, every single change
means flushing all the old rules and reading all the
new rules from /etc/sysconfig/iptables
while with firewalld there is no re-creating of
all the rules; only the differences are applied.
◼ Both use iptables tool to talk to the kernel packet
filter.

◼ Separate networks into different zones based on the level of trust.

◼ NetworkManager informs firewalld to which zone an interface belongs.
◼ Note that the /etc/sysconfig/iptables file does not exist as firewalld is installed by default on Red Hat
Enterprise Linux 7.

Prepared by: Kushan Sharma 19

 Review Startup Scripts
◼ Many Unix platforms will scan one or more directories on system startup and
execute all the scripts contained within these directories that match simple
patterns.
◼ Go through the startup directories and examine each file.
◼ If a script starts an application or daemon that you are not familiar with, read the
associated man pages until you understand the service it provides.
◼ To stop a script from executing, rename the script to break the naming
convention by prepending nostart. to the script name; for example,
/etc/rc2.d/nostart.S99dtlogin.
◼ Be careful not to remove scripts that are essential to the operation of the
server.

Prepared by: Kushan Sharma 20

 RHEL/CentOS Startup Scripts & Runlevels
◼ The /etc/rc.d/rc.local script is executed by the init command at boot
time or when changing runlevels
◼ Adding commands to the bottom of this script is an easy way to perform
necessary tasks like starting special services or initialize devices without writing
complex initialization scripts in the /etc/rc.d/init.d/ directory and
creating symbolic links.

◼ The SysV init runlevel system provides a standard process for controlling which
programs init launches or halts when initializing a runlevel.
◼ The configuration files for SysV init are located in the /etc/rc.d/ directory.
◼ Within this directory, are the rc, rc.local, rc.sysinit, and, optionally, the
rc.serial scripts as well as the following directories: init.d/ rc0.d/ rc1.d/
rc2.d/ rc3.d/ rc4.d/ rc5.d/ rc6.d/
◼ Each of the numbered directories represent the six runlevels configured by default

Prepared by: Kushan Sharma 21

 RHEL/CentOS Startup Scripts & Runlevels
◼ Run levels determine whether a system boots up in single-user mode, multiuser
mode, command-line only, or full graphical user interface (GUI).
◼ System should come up to the lowest level required for the functionality
you are building.
◼ The following runlevels are defined by default under Red Hat Enterprise Linux:
◼ 0 — Halt
◼ 1 — Single-user text mode
◼ 2 — Not used (user-definable)
◼ 3 — Full multi-user text mode
◼ 4 — Not used (user-definable)
◼ 5 — Full multi-user graphical mode (with an X-based login screen)
◼ 6 — Reboot
◼ To check the default runlevel
# systemctl get-default
◼ To check runlevel
# who –r
# runlevel
Prepared by: Kushan Sharma 22
 Audit Your Applications
◼ Every application on your system is potentially another hole that can be
exploited by a malicious person.
◼ Best practices to follow:
◼ If you take possession of a server that was created by someone else, do a careful
audit of that server and note everything that is installed.
◼ Keep a list of all of your servers, what applications are installed on each, and which
version of each application is installed.
◼ This list will save you a lot of time and preparation work when it comes time to do
security audits and system patching.
◼ Perform a full backup of your server, and then go through and disable or remove all
applications that are not necessary for that server.
◼ Remove them one at a time and test your server after each change to verify that it
still functions correctly.

Prepared by: Kushan Sharma 23

 Install Secure Software
◼ Unix systems do not usually ship with the most secure software installed.
◼ Depending on requirements, secure software needs to be installed.

◼ Install OpenSSL:
◼ OS do not ship with any SSL libraries, install OpenSSL
◼ OpenSSL suite is a set of encryption libraries and applications to make limited use
◼ Apache uses OpenSSL to serve https web pages
◼ OpenSSH uses OpenSSL as the foundation

◼ Replace Unsecure Daemons with OpenSSH

◼ Many protocols transmit all data without encryption or obfuscation; the data they
wish to send is exactly what they send.
◼ Clear-text data transmission can be eavesdrops by adversaries

Prepared by: Kushan Sharma 24

 SSL/TLS
◼ SSL (Secure Sockets Layer): Cryptographic protocol that enables secure
communications over the Internet.
◼ Is SSL considered as secure protocol now?
◼ SSL session initiation

Prepared by: Kushan Sharma 25

 SSL/TLS
◼ Three main components to TLS:
◼ Encryption: hides the data being transferred from third parties.
◼ Authentication: ensures that the parties exchanging information are who
they claim to be. Server proving its identity to the client via the Public key
of the server.
◼ Integrity: verifies that the data has not been forged or tampered with.
Once data is encrypted and authenticated, it is then signed with a message
authentication code (MAC). The recipient can then verify the MAC to ensure
the integrity of the data.

Prepared by: Kushan Sharma 26

 SSL/TLS

◼ Differences of SSL vs TLS (Still Been Edited within IETF):

◼ In the ClientHello message (first message sent by the client, to initiate the
handshake), the version is {3,0} for SSLv3, {3,1} for TLSv1.0 and {3,2} for TLSv1.1.
◼ The ClientKeyExchange differs.
◼ The Message Authentication Code (MAC)/HMAC differs (TLS uses HMAC whereas SSL
uses an earlier version of HMAC).
◼ The key derivation differs.
◼ The client can send application data can be sent straight after sending the SSL/TLS
Finished message in SSLv3. In TLSv1, it must wait for the server's Finished message.
◼ The list of cipher suites differ (and some of them have been renamed from SSL_* to
TLS_*, keeping the same id number).

Prepared by: Kushan Sharma 27

 Replace Telnet with SSH
◼ Assume computer A in Colombo and we wish to connect to a remote computer
B in London:

◼ Unfortunately with telnet login ID and

password are sent in clear-text halfway
around the world. To a packet sniffer,
the traffic looks like this:

Prepared by: Kushan Sharma 28

 Replace Telnet with SSH Cont.
◼ CentOS 7 and RHEL 7 do not contain telnet in their minimal installation.
◼ To verify the availability of telnet
# rpm -qa | grep telnet

◼ In order to turn Telnet on, packages telnet-server and telnet needs to be

installed.

◼ Many of the unsecured protocols, such as Telnet, FTP, and the r* commands
(rsh, rexec, rlogin, etc.), can be replaced with OpenSSH

Prepared by: Kushan Sharma 29

 Configure SSH on CentOS/RHEL/Ubuntu
◼ Set SSH Protocol to 2
◼ SSH v1 suffers from insecurities that do not affect SSH v2.
◼ Set parameter as Protocol 2 in /etc/ssh/sshd_config file.
◼ Set LogLevel to INFO
◼ The INFO parameter specifies that login and logout activity will be logged.
◼ Set parameter as LogLevel INFO in /etc/ssh/sshd_config file.
◼ Set X11Forwarding to no
◼ Facilitate to tunnel X11 traffic through the connection to enable remote graphic con.
◼ Set parameter as X11Forwarding no in /etc/ssh/sshd_config file.
◼ Set MaxAuthTries to 4
◼ Parameter specifies the maximum number of authentication attempts permitted per
connection. This minimize the risk of successful brute force attacks.
◼ Set parameter as MaxAuthTries 4 in /etc/ssh/sshd_config file.
◼ Set PermitRootLogin to no
◼ Parameter specifies if the root user can log in using ssh.
◼ Limits opportunity for non-repudiation and provides a clear audit trail.
◼ Set parameter as PermitRootLogin no in /etc/ssh/sshd_config file.
Prepared by: Kushan Sharma 30
 Configure SSH on CentOS/RHEL/Ubuntu
◼ Set SSH PermitEmptyPasswords to no
◼ Specifies if the server allows login to accounts with empty password strings.
◼ Set parameter as PermitEmptyPasswords no in /etc/ssh/sshd_config file.
◼ Set SSH PermitUserEnvironment to no
◼ Allows users to present environment options to the ssh daemon.
◼ Potentially allow users to bypass security controls.
◼ Set parameter as PermitUserEnvironment no in /etc/ssh/sshd_config file.
◼ Set SSH Ciphers to aes128-ctr,aes192-ctr,aes256-ctr
◼ Limits the types of ciphers that SSH can use during communication.
◼ Set parameter as Ciphers aes128-ctr,aes192-ctr,aes256-ctr in
/etc/ssh/sshd_config file.
◼ Limit Access via SSH
◼ Several options available to limit which users and group can access the system via SSH.
◼ Edit /etc/ssh/sshd_config file.
◼ AllowUsers <userlist>
◼ AllowGroups <grouplist>
◼ DenyUsers <userlist>
◼ DenyGroups <grouplist>
Prepared by: Kushan Sharma 31
 Controlling Access to Files
◼ In Linux everything considered to be a file.
◼ With DAC, a subject with a certain access
permission is capable of passing or granting
that permission directly or indirectly on to any
other subject.
◼ Once DAC is adopted in Linux, the files are
owned by a user and he has a sole ownership.
◼ DAC can be restricted with a Mandatory
Access Control (MAC) model.
◼ MAC security policy is centrally controlled by a
security policy administrator and users do not
have the ability to override the policy.
◼ Three classes of ownership:

Prepared by: Kushan Sharma 32

 Controlling Access to Files
◼ DAC includes 3 special permission that are available for executable files and
directories. These are SUID permission, SGID permission, Sticky bit
◼ With all these permission types with user, group, and other categories we can
consider permission as a 12 bit number with four octets.
◼ This has been depicted in the table below.

◼ The 12 bit number above can be divided into four octal numbers which denote
special, user, group and other classes.
◼ The table below shows the octal value of each permission.

Prepared by: Kushan Sharma 33

 SUID
◼ SUID permission
◼ The execution context will be different when x become s
of user octet (1st group of rwx) and the group octet
(2nd group of rwx).
◼ When this occurs, the file when executed (if it's a
program and not just a shell script) will run with the
permissions of the owner or the group of the file.

◼ To find the files with SUID se:

# find / -perm /4000 2> /dev/null

◼ To set SUID on a file

# chmod 4555 [path_to_file]

Prepared by: Kushan Sharma 34

 SGID
◼ SGID permission on executable file
◼ SGID permission is similar to the SUID permission, only difference is – when the
script or command with SGID on is run, it runs as if it were a member of the same
group in which the file is a member.

◼ To set SGID on a file

# chmod 2555 [path_to_file]
◼ SGID on a directory
◼ When SGID permission is set on a directory, files created in the directory belong to
the group of which the directory is a member.
◼ For example if a user having write permission in the directory creates a file there,
that file is a member of the same group as the directory and not the user’s group.
◼ This is very useful in creating shared directories.
◼ To set SGID on a directory
# chmod g+s [path_to_directory]
◼ To check files with SUID/SGID set:
# find / -perm /6000 or /u=s,g=s
Prepared by: Kushan Sharma 35
 Exercise 04
◼ /tmp directory in the Linux system are being used by different Linux users to
create temporary files. Users may accidentally or deliberately deletes (or
rename) a file created by some other user in this directory. How does Linux
prevent such delete attempts to ensure the proper functionality of the content
in /tmp directory.

Prepared by: Kushan Sharma 36

 Sticky Bit
◼ A permission bit that is set on a directory that allows only the owner of the file
within that directory or the root user to delete or rename the file.
◼ It is useful for shared directories such as /var/tmp and /tmp because users
can create files, read and execute files owned by other users, but are not
allowed to remove files owned by other users.
◼ Example:
◼ When Sticky bit is set and if user Bob creates a file named /tmp/bob, other user
Tom can not delete this file even when the /tmp directory has permission of 777. If
sticky bit is not set then Tom can delete /tmp/bob, as the /tmp/bob file inherits
the parent directory permissions.
◼ To check files with sticky bit:
# find / -type f -perm /1000 2> /dev/null
◼ To set sticky bit:
# chmod +t [path_to_directory]
or
# chmod 1777 [path_to_directory]
-T refers to when the execute permissions are off.
-t refers to when the execute permissions are on.

Prepared by: Kushan Sharma 37

 TCP Wrappers
◼ A host-based networking access control list
(ACL) system and used to filter network access
to Internet.
◼ An iptables-based firewall filters out
unwelcome traffic within the kernel’s stack.
◼ TCP Wrappers add an additional layer of
protection.
◼ Define which hosts are or are not allowed to
connect to "wrapped" network services.
◼ One such wrapped network service is the
xinetd super server.
◼ xinetd controls connections to a subset of
network services and further refines access
control.

Prepared by: Kushan Sharma 38

 TCP Wrappers
◼ Advantages:
◼ Transparency to both the client and the wrapped network service — Both
the connecting client and the wrapped network service are unaware that TCP
Wrappers are in use. Legitimate users are logged and connected to the requested
service while connections from banned clients fail.
◼ Centralized management of multiple protocols — TCP Wrappers operate
separately from the network services they protect, allowing many server applications
to share a common set of access control configuration files, making for simpler
management.
◼ When a TCP-wrapped service receives a client request, it performs the following
steps:
◼ It references /etc/hosts.allow. — The TCP-wrapped service sequentially parses
the /etc/hosts.allow file and applies the first rule specified for that service. If it
finds a matching rule, it allows the connection. If not, it moves on to the next step.
◼ It references /etc/hosts.deny. — The TCP-wrapped service sequentially parses
the /etc/hosts.deny file. If it finds a matching rule, it denies the connection. If
not, it grants access to the service.
◼ Rules in host.allow take precedence over rules define in host.deny
◼ Rules are read from top down, first matching rule is the only one applied.

Prepared by: Kushan Sharma 39

 TCP Wrappers
◼ When a connection attempt is made to a TCP-wrapped service,
the service first references the host's access files
(/etc/hosts.allow and /etc/hosts.deny) to determine
whether or not the client is allowed to connect.
◼ If a client is allowed to connect, TCP Wrappers release control
of the connection to the requested service and take no further
part in the communication between the client and the server.
◼ Most network services within RHEL are linked to the
libwrap.a library. Some such applications include
/usr/sbin/sshd, /usr/sbin/sendmail, and
/usr/sbin/xinetd.
◼ To determine if a network service binary is linked to
libwrap.a, type the following command as the root user:
# ldd <binary-name> | grep libwrap
◼ Replace <binary-name> with the name of the network
service binary.
# ldd /usr/sbin/sshd | grep libwrap
libwrap.so.0 => /usr/lib/libwrap.so.0
Prepared by: Kushan Sharma 40
 Remove Insecure Software
◼ Consider replace SendMail:
◼ Due to the large code base and the complexity, many exploitable security
vulnerabilities.
◼ So complicated that simple changes are beyond the ability of most people who have
not devoted a large amount of time to learning sendmail.
◼ Must be run as root to work – Due to this restriction, this is a popular target of
attackers.
◼ The only reason your system needs this service is if it will accept inbound e-mail for
local users from the network

◼ Postfix is a sendmail replacement.

◼ Goals were ease of use and security

Prepared by: Kushan Sharma 41

 Do Not Run Processes Using root Privilege
◼ Replace default, open settings with more secure, limited settings.
◼ Many processes do not need any special privileges other than the ability to read
from and possibly write to—the data directory.
◼ Unix security requirements such as only processes run by root can open a
TCP/IP port below 1024, mean that daemons must be started as root to open
their ports.
◼ To address these concerns:
◼ Don’t run these processes at all
◼ If not, create a dedicated user ID to run the daemon, and make it as restrictive as
possible. Make only the directory used by that ID writable by that ID, and give the ID
no special elevated permissions. Then change the startup script so the daemon is
owned by this new user ID.
◼ Example: Apache web services

Prepared by: Kushan Sharma 42

 Example: How Apache Works
◼ Uses a combination of a multiprocessing and a multithreading model
◼ Master process needs to run as root. All the configuration files inside of
/etc/apache2/... are typically owned, as root, and in order to access
(some) SSL private certificate data (/etc/ssl/private/... usually), it will
need superuser power.

◼ Apache's workers actually

handle requests coming in to
the web server, and handle
accessing data on the system
and sending the response to
clients.
◼ Child runs as www-data which
is not an administrator-level
account, and does not have
elevated privileges.

Prepared by: Kushan Sharma 43

 Audit Cron Jobs
◼ Cron is a daemon that executes scheduled commands.
◼ Periodically audit crontab files and review what is being run.
◼ Details of cron jobs can be found from the following locations:
◼ /var/spool/cron/ -> This contains a crontab file for each user who is using crontab.
◼ /etc/crontab
◼ /etc/cron.d/
◼ /etc/cron.daily/
◼ /etc/cron.hourly/
◼ /etc/cron.monthly/
◼ /etc/cron.weekly/

◼ Keep track of your cron jobs and

periodically examine them to see if
any changes have been made.
◼ If something has changed, investigate
it and determine why.

Prepared by: Kushan Sharma 44

 Audit Cron Jobs
◼ Start automatically from /etc/init.d on entering multi-user runlevels.
◼ Searches its spool area (/var/spool/cron/crontabs) for crontab files.
◼ Cron also reads /etc/crontab and files in /etc/cron.d.
◼ Wakes up every minute, examining all stored crontabs, checking each
command to see if it should be run in the current minute.
◼ Any output is mailed to the owner of the crontab.
◼ Debian and Redhat cron treats the files in /etc/cron.d as extensions to the
/etc/crontab.
◼ Crontab is the program used to install, deinstall or list the tables.

Prepared by: Kushan Sharma 45

 Keep . out of Your PATH
◼ As root, you must be positive that the command you think you are running is
what you are really running.
◼ Consider the Scenario:
◼ PATH variable is .:/usr/bin:/usr/sbin:/bin:/sbin.
◼ User A creates a script in his directory named ls that contains these commands:

◼ Now user A calls you and informs you that he is having a problem with something in
his home directory. You, as root, cd to his directory and run ls -l to take a look
around. Suddenly, unknowingly to you, user A now has a shell he can run to gain
root permissions!
◼ Situations like these happen frequently but are easy to avoid. If “.” was not in your
path

Prepared by: Kushan Sharma 46

 Audit Your Scripts
◼ When writing scripts, always specify the full path. Consider the below script:

◼ There are many security holes in the above script:

◼ It does not specify a path.
◼ It does not give the full path to date.
◼ It does not give the full path to find.
◼ It does not give the full path to rm.
◼ It performs no error checking.
◼ It does not verify that the directory is correct.
◼ How do you secure the above script?
◼ When writing a script, always follow these simple rules:
◼ Always specify a path.
◼ Always use the full path to each application called.
◼ Always run error-checking, especially before running a potentially destructive
command such as rm.
Prepared by: Kushan Sharma 47
 Audit Your Scripts
◼ Consider the below script:

◼ cd /directory || exit -1, tells ksh to attempt to cd to /directory.

◼ Then call date by its full name: /usr/bin/date.
◼ Also fully specify /usr/bin/find and /usr/bin/rm. //This make it much harder for
a malicious person to insert a Trojan into the system that you unwittingly run.

Prepared by: Kushan Sharma 48

 Know What Ports Are Open
◼ How do you know what ports are open and accept connections, before you
expose a Linux system to the world?
◼ All the unknown services should be shut down, before outsiders access them.
◼ Many utilities to find open services:
◼ netstat - Netstat command displays various network related information such as
network connections, routing tables, interface statistics, masquerade connections,
multicast memberships etc.,
◼ lsof - list the information about the files that are opened by various processes. In
unix, everything is a file, ( pipes, sockets, directories, devices, etc.). So by using lsof,
you can get the information about any opened files.
◼ nmap - used to discover hosts and services on a computer network, thus creating a
"map" of the network.

Prepared by: Kushan Sharma 49

 Netstat
◼ List All Ports (both listening and non listening ports)
◼ # netstat -a | more - List all ports
◼ # netstat -at - List all tcp ports
◼ # netstat -au - List all udp ports
◼ List Sockets which are in Listening State
◼ # netstat -l - List only listening ports
◼ # netstat -lt - List only listening TCP Ports
◼ # netstat -lu - List only listening UDP Ports
◼ # netstat -lx - List only the listening UNIX Ports
◼ Show the statistics for each protocol
◼ # netstat -s - Show statistics for all ports
◼ # netstat -st/su - Show statistics for TCP (or) UDP ports
◼ Display PID and program names in netstat output using
◼ # netstat -p
◼ Print netstat information continuously
◼ # netstat -c - netstat will print information continuously every few seconds.

Prepared by: Kushan Sharma 50

 lsof
◼ List all open files
◼ # lsof - Simply typing lsof will provide a list of all open files belonging to all active
processes.
◼ List processes which opened a specific file
◼ # lsof /var/log/syslog - You can list only the processes which opened a
specific file, by providing the filename as arguments.
◼ List opened files under a directory
◼ # lsof +D /var/log/ - +D will recurse the sub directories also. If you don’t want
lsof to recurse, then use ‘+d’ option.
◼ List opened files based on process names starting with
◼ # lsof -c ssh -c init - list the files opened by process names starting with a
string, using ‘-c’ option.
◼ List processes using a mount point
◼ # lsof /home
◼ List files opened by a specific user
◼ # lsof -u lakshmanan
◼ List all open files by a specific process
◼ # lsof -p 1753
Prepared by: Kushan Sharma 51
 Configure All Your Daemons to Log
◼ Some daemons create log entries by default, and others do not.
◼ Verify that daemons are set to log information.
◼ Any publicly available daemon needs to be configured to log.
◼ Log needs to be replicated. Replicated logs will be a good archive in case a
server is compromised.
◼ rsyslogd is a tried and true piece of middleware to collect and aggregate
syslogs.
◼ Once aggregated into the central server (which is also running rsyslogd), the
syslog data is periodically bulk loaded into various data backends like
databases, search indexers and object storage systems.
◼ Edit /etc/syslog.conf and determine which messages you wish to replicate. At
the very least, you should replicate the emerg, alert, crit, err, and warning
messages.

Prepared by: Kushan Sharma 52

 Central Log Server
◼ Shut down all other ports and services except syslogd to minimize the chance
of this system being compromised, with the possible exception of a TCP-
wrapped SSH daemon restricted to your workstation for remote access. Then
verify that syslogd will accept messages from remote systems. This varies from
vendor to vendor. Some vendors make the default behavior to accept
messages, and you must turn it off if desired; others make the default to not
accept messages, and you must turn it on.
◼ Create a system for archiving older logs and document it. If your logs are ever
subpoenaed for evidence, you need to be able to prove that they have not
been altered, and you will need to show how they were created.
◼ It is suggested that you compress all logs older than one week and replicate
them to time-stamped, read-only media, such as a CD.

Prepared by: Kushan Sharma 53

 Keep Software Up to Date
◼ Every piece of software has vulnerabilities.
◼ Hackers and Crackers spend a great deal of time trying to discover
vulnerabilities.
◼ In any event, occasionally exploits are found and patches are released to fix
them.
◼ Admins are responsible for looking to see what patches are available.
◼ Many vendors supply a tool to help you keep on top of your system patches.
HP-UX has the Software Update Manager, Solaris has patchdiag and patchpro,
AIX uses SMIT, and so on.

Prepared by: Kushan Sharma 54

 Place Servers into Network Zones
◼ All computers should be separated from each other based on their function,
their sensitivity or criticality, and their exposure to the Internet.
◼ Always assume that Internet-facing systems will eventually become
compromised by attackers and limit their access accordingly.
◼ Use an application-layer (layer seven) firewall to filter traffic between zones.
These firewalls inspect traffic at the application layer and check that
characteristics of traffic match those accepted by the application.

Prepared by: Kushan Sharma 55

 Exercise 04
◼ If an Internet server is compromised, where else can the attacker direct an
attack from that server?

Prepared by: Kushan Sharma 56

 Strengthen Authentication Processes
◼ First, improve security on the network by developing a strong password policy
and a strong training program that teaches users their responsibility to create,
use, and protect strong passwords.
◼ Second, and better yet, use some other form of authentication.
◼ Third, use additional technology and physical security to protect password
databases and authentication material.
◼ Require Strong Passwords
◼ Use Alternatives to Passwords
◼ Limit Physical Access to Systems

Prepared by: Kushan Sharma 57

 Limit Number/Privileges of Administrators
◼ How many people know the root password on your system?
◼ Is it the same password that’s used on all the other systems in your
organization?
◼ Built in administrative accounts are one of the greatest weak points in any
network environment.
◼ The root account bypasses all security mechanisms once it is logged in, and if
other people are able to log in to your system as root, they can do anything
they want to it.
◼ Never log in as root.
◼ Users require to use their own regular account first, and then elevate their
privileges once they’re logged in.
◼ In fact, what you should do is assign a completely random password to the root
account, seal it in an envelope, and keep it around only for emergencies. You
should never have to log in as root in any normal situation.

Prepared by: Kushan Sharma 58

 Linux Containers
◼ LXC (Linux Containers) is an operating-system-
level virtualization method for running multiple
isolated Linux systems (containers) on a control
host using a single Linux kernel.
◼ LXC provides:
◼ cgroups functionality that allows limitation and
prioritization of resources (CPU, memory, block
I/O, network, etc.) without the need for starting
any virtual machines
◼ namespace isolation functionality that allows
complete isolation of an applications' view of the
operating environment, including process trees,
networking, user IDs and mounted file systems

◼ More details will be discussed during Lecture V

Prepared by: Kushan Sharma 59

 Hardening Tips & Tricks
◼ Minimize unnecessary software on your servers.
◼ Disable Unwanted binaries including SUID and SGID Binaries
◼ Use Data Encryption for your Communications
◼ Avoid using insecure protocols that send your information or passwords in plain text.
◼ Keep your operating system up to date, especially security patches.
◼ User Accounts should comply with password policy.
◼ Lock accounts after too many login failures.
◼ SSH Hardening
◼ Unnecessary services should be disabled.
◼ Securing /tmp /var/tmp /dev/shm and Separate partitions in ways that make your system more secure.
◼ Hide BIND DNS Sever Version and Apache version
◼ Hardening sysctl.conf
◼ Server hardening by installing Root Kit Hunter and ChrootKit hunter.
◼ Minimize open network ports to be only what is needed..
◼ Configure the system firewall (Iptables).
◼ Maintain server logs; mirror logs to a separate log server.
◼ Implement log monitoring mechanism.
◼ Limit user accounts to accessing only what they need.
◼ Maintain proper backups.
◼ Don't forget about physical server security.
◼ When using Linux, SELinux should be considered.
◼ Comply with Industry Accepted Standards.
◼ Subscribe to security lists.

60
[email protected]