Date post: | 28-Dec-2015 |
Category: |
Documents |
Upload: | silvester-gilbert |
View: | 228 times |
Download: | 2 times |
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?