Bảo mật hệ thống mạng part 44 ppsx

CHAPTER 15 Unix Security Issues 285 Copyright 2001 The McGraw-Hill Companies, Inc. Click Here for Terms of Use. F or much of the history of the Internet, Unix systems provided most of the services available on the network. When hacking started to become a problem on the Internet, it was Unix systems that received most of the attention. To this day, Unix systems are prevalent on the Internet and these systems must be configured properly to prevent them from being hacked. This chapter attempts to provide some basic security suggestions for building and securing a Unix system. Due to the large number of Unix operating systems available, the exact file locations and commands may not be correct for all Unix versions. I will note cor - rect information for Sun Solaris and Linux where possible. SETTING UP THE SYSTEM When a Unix system is built, there are normally vulnerabilities on the system. Most of these default vulnerabilities can be corrected by patching the system or making changes to configuration files. The following sections identify some of the most likely security issues and how to correct them. Startup Files Unix systems configure themselves on startup using the appropriate startup files. Depending on the version of Unix, the startup files will be in different places. For Solaris, the startup files are found in /etc/rc2.d. For Linux, the startup files can be found in /etc/rc.d/rc2.d. A number of services are started in the startup files. Some (such as the network, mounting file systems, and starting logging) are necessary for system operation and should be allowed to remain. Other services are not as necessary and should not be started depending on the way the system will be used. To prevent a service from starting up, simply change the name of the file. Make sure that the new name of the file does not start with an “S” or a “K.” Placing a leading “.” in the filename works fine (and also hides the file from view so that it is not confused for a file that is operational). If the service will not be needed in the future, the file can also be deleted. Services that are generally started by the startup files include: ▼ Sendmail ■ Routed ■ NFS ■ RPC ■ Web servers ■ Inetd ▲ NTP 286 Network Security: A Beginner’s Guide Chapter 15: Unix Security Issues 287 Make sure that you go through the startup files to determine if any unnecessary ser - vices are being started (see the next section to identify unnecessary services). Services to Allow The services that you choose to allow on your Unix systems should depend upon how they are used. Some of these services will be started by startup files; however, a number of services are controlled through inetd and configured within the /etc/inetd.conf file. Below is a standard inetd.conf file. Lines that begin with a “#” are comments. #ident "@(#)inetd.conf 1.27 96/09/24 SMI" /*SVr4.0 1.5 */ # Configuration file for inetd(1M). See inetd.conf(4). # To re-configure the running inetd process, edit this file, then # send the inetd process a SIGHUP. # Syntax for socket-based Internet services: # <service_name><socket_type><proto><flags><user><server_pathname><args> # Syntax for TLI-based Internet services: # <service_name> tli <proto> <flags> <user> <server_pathname> <args> # Ftp and telnet are standard Internet services. ftp stream tcp nowait root /usr/sbin/in.ftpd in.ftpd #telnet stream tcp nowait root /usr/sbin/in.telnetd in.telnetd # # Shell, login, exec, comsat and talk are BSD protocols. #shell stream tcp nowait root /usr/sbin/in.rshd in.rshd #login stream tcp nowait root /usr/sbin/in.rlogind in.rlogind #exec stream tcp nowait root /usr/sbin/in.rexecd in.rexecd #comsat dgram udp wait root /usr/sbin/in.comsat in.comsat #talk dgram udp wait root /usr/sbin/in.talkd in.talkd # #uucp stream tcp nowait root /usr/sbin/in.uucpd in.uucpd # # Tftp service is provided primarily for booting. Most sites run this # only on machines acting as "boot servers." # #tftp dgram udp wait root /usr/sbin/in.tftpd in.tftpd -s /tftpboot # # Finger, systat and netstat give out user information which may be 288 Network Security: A Beginner’s Guide # valuable to potential "system crackers." Many sites choose to disable # some or all of these services to improve security. # #finger stream tcp nowait nobody /usr/sbin/in.fingerd in.fingerd #systat stream tcp nowait root /usr/bin/ps ps -ef #netstat stream tcp nowait root /usr/bin/netstat netstat -f inet # # Time service is used for clock synchronization. #time stream tcp nowait root internal #time dgram udp wait root internal # # Echo, discard, daytime, and chargen are used primarily for testing. #echo stream tcp nowait root internal #echo dgram udp wait root internal #discard stream tcp nowait root internal #discard dgram udp wait root internal #daytime stream tcp nowait root internal #daytime dgram udp wait root internal #chargen stream tcp nowait root internal #chargen dgram udp wait root internal # RPC services syntax: # <rpc_prog>/<vers> <endpoint-type> rpc/<proto> <flags> <user> \ # <pathname> <args> # # <endpoint-type> can be either "tli" or "stream" or "dgram". # For "stream" and "dgram" assume that the endpoint is a socket descriptor. # <proto> can be either a nettype or a netid or a "*". The value is # first treated as a nettype. If it is not a valid nettype then it is # treated as a netid. The "*" is a short-hand way of saying all the # transports supported by this system, ie. it equates to the "visible" # nettype. The syntax for <proto> is: # *|<nettype|netid>|<nettype|netid>{[,<nettype|netid>]} # For example: # dummy/1 tli rpc/circuit_v,udp wait root /tmp/test_svc test_svc # # Solstice system and network administration class agent server #100232/10 tli rpc/udp wait root /usr/sbin/sadmind sadmind # # Rquotad supports UFS disk quotas for NFS clients #rquotad/1 tli rpc/datagram_v wait root /usr/lib/nfs/rquotad rquotad # # The rusers service gives out user information. Sites concerned # with security may choose to disable it. Chapter 15: Unix Security Issues 289 #rusersd/2-3 tli rpc/datagram_v,circuit_v wait root /usr/lib/netsvc/rusers/rpc.rusersd rpc.rusersd # # The spray server is used primarily for testing. #sprayd/1 tli rpc/datagram_v wait root /usr/lib/netsvc/spray/rpc.sprayd rpc.sprayd # # The rwall server allows others to post messages to users on this machine. #walld/1 tli rpc/datagram_v wait root /usr/lib/netsvc/rwall/rpc.rwalld rpc.rwalld # # Rstatd is used by programs such as perfmeter. rstatd/2-4 tli rpc/datagram_v wait root /usr/lib/netsvc/rstat/rpc.rstatd rpc.rstatd # # The rexd server provides only minimal authentication and is often not run #rexd/1 tli rpc/tcp wait root /usr/sbin/rpc.rexd rpc.rexd # # rpc.cmsd is a data base daemon which manages calendar data backed # by files in /var/spool/calendar # Sun ToolTalk Database Server # UFS-aware service daemon #ufsd/1 tli rpc/* wait root /usr/lib/fs/ufs/ufsd ufsd -p # Sun KCMS Profile Server #100221/1 tli rpc/tcp wait root /usr/openwin/bin/kcms_server kcms_server # Sun Font Server fs stream tcp wait nobody /usr/openwin/lib/fs.auto fs # CacheFS Daemon 100235/1 tli rpc/tcp wait root /usr/lib/fs/cachefs/cachefsd cachefsd # Kerbd Daemon #kerbd/4 tli rpc/ticlts wait root /usr/sbin/kerbd kerbd # Print Protocol Adaptor - BSD listener printer stream tcp nowait root /usr/lib/print/in.lpd in.lpd dtspc stream tcp nowait root /usr/dt/bin/dtspcd /usr/dt/bin/dtspcd 100068/2-5 dgram rpc/udp wait root /usr/dt/bin/rpc.cmsd rpc.cmsd #100083/1 tli rpc/tcp wait root /usr/dt/bin/rpc.ttdbserverd /usr/dt/bin/rpc.ttdbserverd The inetd.conf file not only controls services like FTP and telnet but also some RPC services. The inetd.conf file should be examined very carefully to make sure that only necessary services are configured. Once the file has been correctly configured, you must restart inetd by issuing the following command: #kill -HUP <inetd process number> The “kill -HUP” causes inetd to reread its configuration file. Many services that are configured by default on Unix systems should be turned off. These include ▼ Uucp ■ Tftp ■ Finger ■ Systat ■ Netstat ■ Echo ■ Discard ■ Chargen ■ Rusersd ■ Rquotad ■ Sprayd ■ Walld ■ Rexd ▲ Routed In addition, Daytime and SNMPD may be turned off if they are not used. Daytime may be used by some time synchronization systems and SNMPD may be used for system management. As you may have noticed in the inetd.conf file, telnet and FTP are normally config- ured to be on. Both of these protocols allow user IDs and passwords to travel across the network in the clear. It is possible to use encrypted versions of these protocols to protect passwords. Secure Shell (SSH) is recommended over telnet. Some versions of SSH also come with a Secure Copy (SCP) program to transfer files. Network File System Within your organization, you may have a need to use the Network File System (NFS). If not, turn off NFS on any system that does not need it. NFS is used to mount a file system from one system to another. If NFS is not properly configured, it may be possible for someone to gain access to sensitive files. To configure NFS properly, you should edit the /etc/dfs/dfstab file. NOTE: It is not considered wise to allow the export of file systems outside of your organization. 290 Network Security: A Beginner’s Guide TEAMFLY Team-Fly ® Chapter 15: Unix Security Issues 291 DMZ Systems Unix systems used in the DMZ as Web servers, mail servers, or DNS servers should be configured in a more secure manner than those systems used only internally. Such sys - tems are unlikely to require RPC or NFS. Both of these services can be removed through changes to the startup files. Servers vs. Workstations Some organizations use Unix as both servers and desktop workstations. When used as a workstation, the system will often be configured to run X Windows. On Solaris systems, this will also imply the use of ToolTalk (an RPC program used to control the graphical desktop). These services are not needed on servers. Likewise, services such as DNS are not needed on desktop workstations. Make sure that you develop a configuration guide for servers and a different one for workstations if you use Unix systems in this manner. NOTE: ToolTalk is controlled via inetd.conf on Solaris systems. To shut it down, you must comment out the line “100083/1 tli rpc/tcp wait root /usr/dt/bin/rpc.ttdbserverd /usr/dt/bin/rpc.ttdbserverd.” Using TCP Wrappers TCP Wrappers (available from ftp://ftp.porcupine.org/pub/security) can be used to pro- vide additional security if telnet or FTP is to be used. TCP Wrappers does exactly what the name implies—it “wraps” the telnet and FTP services to provide additional access control and logging. To use TCP Wrappers, we need to modify the inetd.conf file so that the telnet and FTP lines look like this: ftp stream tcp nowait root /usr/local/bin/tcpd /usr/sbin/in.ftpd telnet stream tcp nowait root /usr/local/bin/tcpd /usr/sbin/in.telnetd These configuration lines cause inetd to invoke TCP Wrappers (tcpd) whenever someone attempts to telnet or FTP into the system. NOTE: TCP Wrappers can be used on other services such as POP and IMAP as well as telnet and FTP. Just make the appropriate changes to the configuration lines above. TCP Wrappers can be configured to block or allow specific hosts or networks to access the telnet or FTP services. The files to use for these configurations are /etc/hosts.allow and /etc/hosts.deny. The syntax for these files is as follows: <wrapped program name>: <ip address>/<network mask> The following files are sample TCP Wrapper configuration files: hosts.allow: #Allow telnets from my internal network (10.1.1.x) in.telnet: 10.1.1.0/255.255.255.0 #Allow ftp from the world in.ftpd: 0.0.0.0/0.0.0.0 hosts.deny: #Deny telnets from anywhere else in.telnetd: 0.0.0.0/0.0.0.0 The hosts.allow file is evaluated first followed by the hosts.deny file. Therefore, you can configure all of the systems that are allowed to use the various services and then deny everything else in the hosts.deny file. NOTE: You should also make a change to the logging configuration to allow TCP Wrappers to log in - formation on the system. See the “Log Files” section later in this chapter for that change. System Configuration Files There are a number of changes that can be made to a Unix system’s configuration files to increase the overall security of the system. These changes range from warning banners to buffer overflow protection on some systems. Any configuration changes should be made in accordance with your organization’s security policy. Also, keep in mind that different versions of Unix place configuration files in different locations. Consult with the manuals or man pages of your particular version of Unix to be sure that the changes you make are appropriate for your version of Unix. Banners Login banners can be used to display legal statements before a user is allowed to login. The banner should contain language that is approved by your organization’s Legal department. The login message is stored in /etc/motd (the name stands for “message of the day”). However, this message displays after a user has logged into the system, not before. Most legal notices should be displayed before the user logs in. There is a way to make a message display before the user logs in. In Solaris, the prelogin notice is stored in /etc/default/telnetd. A login banner for use with FTP can also be created by editing /etc/default/ftpd. To create the banner, add a line similar to the following to the file: BANNER="\n\n<Enter Your Legal Message Here\n\n" The “\n” in the line above indicates a new line. You may have to experiment with the new line characters in order to get the message to display the way you want it to. 292 Network Security: A Beginner’s Guide Chapter 15: Unix Security Issues 293 On Linux systems, two files are used for telnet banners—/etc/issue and /etc/ issue.net. The issue file is used for directly connected terminals while the issue.net is used when someone telnets into the system across the network. Unfortunately, editing these files will not accomplish the creation of the banner as these files are re-created each time the system boots. However, the startup script that creates these files can be modified. The files are created in the /etc/rc.d/rc.local startup script. To prevent the auto - matic creation of /etc/issue and /etc/issue.net, comment out the following lines of /etc/rc.d/rc.local: # This will overwrite /etc/issue at every boot. So, make any changes you # want to make to /etc/issue here or you will lose them when you reboot. echo "" > /etc/issue echo "$R" >> /etc/issue echo "Kernel $(uname -r) on $a $SMP$(uname -m)" >> /etc/issue After you have done this, you can edit /etc/issue and /etc/issue.net with the appro - priate legal text. Password Settings There are actually three steps to proper password management on a Unix system: ▼ Setting up proper password requirements ■ Preventing logins without passwords ▲ Establishing appropriate password content requirements Setting Up Proper Password Requirements Password aging and length requirements are established on Unix systems by editing a configuration file. On Solaris, this file is /etc/default/passwd. The file has the following lines that should be edited to conform with your organization’s security policy: #ident "@(#)passwd.dfl 1.3 92/07/14 SMI" MAXWEEKS=7 MINWEEKS=1 PASSLENGTH=8 Be careful when providing values for the maximum and minimum ages as the system is looking for the number of weeks, not days. On Linux systems, the password requirements can be found in /etc/login.defs. The following lines of the /etc/login.defs show the configurable settings: # Password aging controls: # # PASS_MAX_DAYS Maximum number of days a password may be used. # PASS_MIN_DAYS Minimum number of days allowed between password changes. # PASS_MIN_LEN Minimum acceptable password length. # PASS_WARN_AGE Number of days warning given before a password expires. # PASS_MAX_DAYS 45 PASS_MIN_DAYS 1 PASS_MIN_LEN 8 PASS_WARN_AGE 7 Keep in mind that on Linux systems, the minimum and maximum ages are in days. Linux also gives you the option of having the system warn users some number of days be - fore the password will expire. Preventing Logins Without Passwords Programs like rlogin, rsh, and rexec allow users to login to a system from certain other systems without re-entering their passwords. This is not a good idea as it allows an intruder who compromises one system to gain access to many systems. Besides removing the rlogin, rsh, and rexec services from /etc/inetd.conf, you should also make sure you have found and removed /etc/host.equiv and any .rhost files on the system. Make sure to look into each user’s home directory as well. Establishing Appropriate Password Content Requirements Preventing users from choosing bad passwords is one of the best ways to improve the security of your system. Unfortu - nately, until recently there have been few easy ways to do this on Unix systems. Programs like passwd+ and npasswd are available for Linux but not for Solaris. Both of these pro- grams allow you to specify password strength requirements, and they will force users to choose passwords that conform to your rules. With the release of Solaris 2.6 and more recent distributions of Linux, there now exists a better tool for monitoring the strength of user passwords. This tool is called PAM. More information on PAM and how to build password filters can be found at http://www.sun.com/solaris/pam/. NOTE: Some versions of Unix, notably HPUX, come with default settings for strong password secu - rity. These include lockouts set on accounts if there are too many failed login attempts. File Access Control On a Unix system, access to files is controlled by a set of permissions. For the owner of the file, the group that owns the file, and the world, you can set read, write, and execute privi - leges. Permissions on files are changed by using the chmod command. It is generally not good practice to allow users to create world-readable or world-writable files. Such files may be read or written to by any user on the system. If an intruder were to gain access to a user ID, he or she would be able to read or write any of these files. Since it is hard to convince all of our users to change the access on a file when it is cre - ated, we will want to create a default mechanism to set the appropriate permissions when the file is created automatically. We can do this with the umask parameter. On Solaris systems, this parameter is found in the /etc/default/login file. On Linux systems, the pa - rameter is found in /etc/profile. The command is used as follows: umask 077 294 Network Security: A Beginner’s Guide [...]... file /etc/ftpusers on both Solaris and Linux is used to list the accounts that are not allowed to FTP into the system Make sure that root is in the list Buffer Overflow Protection Buffer overflows are particularly dangerous vulnerabilities in a system Solaris provides a way to disable the ability of buffer overflow attacks to execute commands off the stack 295 296 Network Security: A Beginner’s Guide . place configuration files in different locations. Consult with the manuals or man pages of your particular version of Unix to be sure that the changes you make are appropriate for your version. allowed to login. The banner should contain language that is approved by your organization’s Legal department. The login message is stored in /etc/motd (the name stands for “message of the day”). However,. the system. Make sure that root is in the list. Buffer Overflow Protection Buffer overflows are particularly dangerous vulnerabilities in a system. Solaris provides a way to disable the ability