Linux Security

Chapter 21 (section 1-7)

By
Yanjun Zuo
“Morris” worm
 Robert Morris, a graduate student
at Connell university, released an
Internet worm in 1988
 This worm made use of the open
nature of mail transport agents (a
debug program) to spread
 Since then, computer security
entered a new stage
Security
 A recent survey (by CSI/FBI in April
2001) showed 91% of organizations
have reported security breaches in the
past 12 months
 95% of these reporting organizations
used security tools such as commercial
firewalls
 This facts at least teach us security is a
complicated issue and some
commercial security products are not
Linux security
 Like other OS, Linux is not secure
 - Linux is optimized for convenience and
doesn’t make security easy or nature
 - Linux security is effectively binary: all
or nothing in term of power. Facilities
such as setuid execution tend to give a
way in the middle
 - Linux is developed by a large
community of programmers and is open
source
Linux security
 The most important security issues
to consider for a Linux system
 - Packet filtering: there must be a
packet filtering router or firewall
between the Linux system and the
outside world (iptables)
 - Unnecessary services (examine
the contents of /etc/inetd.conf)
Linux security
 - Software patches: update software
security patches regularly and as soon
as possible
 - Backups: any other methods may fail
so it is important to make backups
 - Passwords: it is no longer secure to
send plaintext reusable passwords on
line. Use SSH or other authentication
systems
How security is
compromised
 Unreliable wetware: human users
and administrators may be the
weakest link in the chain of
security
 Software bugs: user programs,
system, and network
vulnerabilities
 Open doors: many software are
configured as “not-so-secure” by
default
/etc/passwd and
/etc/shadow files
 These two files are the system’s
first line of defense against
intruders
 It is very important to regularly
check every login has a password
 Pseudo-users such as “daemon”
who own files but never login
should have a star (*) in their
encrypted password field
/etc/passwd and
/etc/shadow files
 The command
perl –F: -ane `print if not $F[1];` /etc/shadow
can be used to find null passwords
 Use the cron program to run this
command and send mail to you
about any null password
/etc/passwd and
/etc/shadow files
 /etc/shadow is read only by root
 /etc/passwd and /etc/group should
be written only by root
 Passwords chosen by users should
be at least 8 character long and
should include numbers,
punctuation, or changes in case
PAM: pluggable
authentication module
 PAM can be used to integrate login
services with different
authentication technologies, such
as RSA, DCE, Kerberos, S/Key, and
smart card based authentication
systems [1]
PAM: pluggable
authentication module
 Applications enabled to make use of
PAM can be plugged-in to new
technologies without modifying the
existing applications. This flexibility
allows administrators to do the
following:
 Select any authentication service on the system for an
application
 Use multiple authentication mechanisms for a given service
 Add new authentication service modules without modifying
existing applications
 Use a previously entered password for authentication with
multiple modules [2]
PAM: pluggable
authentication module
 The concept of Linux-PAM: programs
that require authentication only need to
know that there is a module available
that will perform the authentication for
them
 PAM is set up so that modules can be
added,deleted, and reconfigured at any
time- it is not necessary for modules to
be linked in at the time a utility is
compiled
PAM: pluggable
authentication module
 It is the purpose of the Linux-PAM
project to separate the
development of privilege granting
software from the development of
secure and appropriate
authentication schemes. This is
accomplished by providing a
library of functions that an
application may use to request
that a user be authenticated [3]
Format of PAM
configuration file entries
 Configuration file for PAM is in the
directory of /etc/pam.d
- entry of the configure file has the
format:
module-type control-flag module-path
arguments
Format of PAM
configuration file entries
 Module-type field: auth, account,
session, or password
 Control-flag field: required,
requisite, sufficient, or optional
 Module-path: pathname for the
dynamically loaded module object
 Argument: the argument for the
dynamically loaded module object
An example of PAM
 Additions to /etc/pam.d/passwd to
enable the passwd to perform
strong password checking by using
a PAM module derived from the
crack library might look like this:
password required pam-cracklib.so retry=3
password required pam_pwdb.so use_authtok
Group logins and shared
logins
 Don’t recommend to allow users to
share logins with family or friends
 Recommend to use sudo program
to control access to rootly power
Rootly entries
 A common way for hackers to install a
back door once they have obtained a
root shell is to edit new root logins into
/etc/passwd
 The following script can be used to find
any lines in the passwd file that have
null or 0 UIDs
perl –F: -ane `print if not $F[2];` /etc/passwd
Setuid programs
 The setuid commands distributed with
Linux are theoretically secure; but they
have security holes
 Try to minimize the number of setuid
programs
 Although a shell spawned to execute a
script doesn’t necessarily read the
user’s shell configuration files, it can be
influenced by the user’s environment,
by the contents of the current directory,
or by the manner in which the script is
invoked
Setuid program
 A setuid program can be run as a
pseudo user instead of root
 Use a low UID for the pseudo user,
put a star in the passwd field, and
make the pseudo user’s home
directory be /etc/null
Setuid programs
 Setuid and Setgid execution on
individual filesystem can be
disabled through use of the –o
nosuid option to mount
Setuid programs
 It is useful to scan disks periodically to
look for new setuid programs
 A hacker who has breached the security
of your system will sometimes create a
private setuid shell or utility to facility
repeat virists
 The command can find and a list of all
setuid files and mail to the “admin” user
find ~user root –perm –4000 –print | mail –s “Setuid
root files” admin
Important file permissions
 /dev/kmem should only be readable by
the owner and group, never by the
world since this file allows access to the
kernel’s own virtual address space
 If your /dev/kmem file is publicly
readable, a competent programmer can
then look for things like unencrypted
passwords in the kernel data structures
and buffers. Change that not allow
world readable
Important file permissions
 Directories that are accessible through
anonymous FTP should not be publicly
writable
 Such directories create a nest for
hackers to distributed illegally copied
software and other sensitive files
 Setting up anonymous FTP usually
involves copying a skeleton password
file into ~ftp/etc/passwd so that ls will
work correctly
Important file permissions
 Having read or write permission on a
disk device file is essentially the same
as having read or write permission on
every file in the filesystem it represents
 Only root should have both read and
write permission
 The group owner is sometimes given
read permission to facilitate backups,
but there should be no permissions for
the world
Remote event logging
 Forward log information to a file, a list
of users, or another host on the network
 Set up a secure host that acts as a
central logging machine and print out
security violations
 This precaution prevents hackers from
covering their tracks by rewriting or
erasing log files
Secure terminals
 Linux can be configured to restrict
root logins to specific “secure”
terminals
 It is good idea to disable root
logins on channels such as dial-up
modems
 Network pseudo-terminals are
often set to disable root logins
Secure terminals
 The secure channels are specified as a
list of TTY devices in the configuration
file /etc/securetty
 It is also possible to restrict nonroot
logins to particular locations with
entries in the file
/etc/security/access.conf or to particular
times with entries with entries in the file
/etc/security/time.conf
/etc/hosts.equiv and
~/.rhosts
 These two files define hosts as being
administratively “equivalent” to one
another
 rshd and rlogind, the server processes
that read .rhosts and hosts.equiv, are
recommended to be disabled
 The functionalities of telent, rlogin, rsh,
or rcp can be replaced with high-
security equivalents such as SSH
rexecd and tftpd
 Rexecd is another remote command
execution daemon, which is the server
for the rexec library routine
 Requests send to rexecd include a
plaintext password
 Tftpd is a server for the Trivial File
Transfer Protocol
 It allows machines on the network to
request files from your hard disks.
Hence it is a potential security hole
fingerd
 finger is a Linux command that
prints a short report about a
particular user
 Information collected from finger is
potentially useful to hackers
 It is recommended to disable
fingerd in /etc/inetd.conf
Security and NIS
 NIS maintains and distributes files
such as /etc/group, /etc/passwd,
and /etc/hosts
 NIS’s very nature of “easy
information access” makes it tasty
hacker bait
 A late replacement is NIS+
Security and NFS
 Access to NFS volumes is granted by
/etc/exports
 This is a weak form of security because
the server trusts the clients to tell it
who they are
 It is easy to make clients lie about their
identities
 The TCP wrappers package can help
limit the hosts that can access NFS
filesystems (through /etc/hosts.deny)
Security and NFS
 File-level access control to NFS
filesystems is managed according
to UID, GID, and file permissions
 Once again, the NFS sever trusts
the client to tell it who is accessing
files
 It is strongly recommended to use
globally unique UIDs and the
root_squash option
Security and NFS
 It is a good idea to block access to
TCP and UDP ports 2049 (used by
NFS) when configuring firewalls
 You should also block access to the
portmap daemon, which normally
listens on TCP and UDP ports 111
Security and sendmail
 Sendmail is a massive network
system and a large part of it runs
as root
 Sendmail accepts arbitrary user-
supplied input and deliver it to
local users, files, or shells
 It has often been subject to the
attacks
 Numerous vulnerabilities have
been exposed over time
Trojan horses
 Programs aren’t what they seem to
be
 It is remarkable how few Trojan
hose incidents there have been
References
(1)http://java.sun.com/security/jaas/doc/pam.htm
l

(2)http://publib16.boulder.ibm.com/pseries/en_U
S/aixbman/security/pam_overview.htm

(3)http://www.tldp.org/HOWTO/User-
Authentication-HOWTO/x101.html
Questions
or
Comments?