Linux Security

Chapter 21 (section 1-7)

ByYanjun 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 complete solutions by themselves

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.html

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

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

Questions

or

Comments?