1. Chapter 21 (section 1-7) By Yanjun Zuo
Linux Security
Chapter 21 (section 1-7) By
Yanjun Zuo

2. “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

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

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

5. 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)

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

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

8. /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

9. /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

10. /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

11. 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]

12. 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]

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

14. 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]

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

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

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

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

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

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

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

22. Setuid programs
Setuid and Setgid execution on individual filesystem can be disabled through use of the –o nosuid option to mount

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

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

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

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

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

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

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

30. /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

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

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

33. 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+

34. 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)

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

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

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

38. Trojan horses Programs aren’t what they seem to be
It is remarkable how few Trojan hose incidents there have been

39. References (1)http://java.sun.com/security/jaas/doc/pam.html
(2)
(3)

40. Questions or
Comments?