Linux Security

1. 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)http://publib16.boulder.ibm.com/pseries/en_US/aixbman/security/pam_overview.htm (3)http://www.tldp.org/HOWTO/User-Authentication-HOWTO/x101.html

40. Questions or Comments?