Restricting Services

I l @ ve RuBoard

Restricting the services that allow access to a system reduces the methods by which a system can be attacked . Exploiting vulnerabilities in services is the most common method for gaining access to a system, so if a system has fewer services, then there is less code to contain vulnerabilities.

Anonymous Access

Anonymous access is any access to the service without authenticating an identifier. Historically, there has been a number of anonymous services on UNIX machines. However, as the machines have become more reliable and the need for security has increased, these anonymous information services have dropped away. Today, there are few anonymous services.

Anonymous FTP is a configuration of FTP which allows someone who does not have an account on the machine to FTP files to and from the machine anonymously. This is done by entering either "anonymous" or "ftp" as the user name and anything as a password; by convention, this is the requester's e-mail address. Even though it is called anonymous and there is no user authentication, it is not always anonymous. There are a number of FTP daemons that log file transfer and the location from where the request was made. Some FTP daemons will validate that the given password is a valid user on the system that is making the request.

These transfers are restricted to the home directory tree of the user named "ftp." Anonymous FTP needs a partial file system configured in its home directory since it is a " chroot"ed process. This partial file system includes a password file. Some automated administration scripts, when creating the password file for anonymous FTP, will use the actual password file and set inappropriate permissions. Then a hacker can easily get the password file as follows :

 ftp target  Connected to target.  220 target FTP server ready.  Name (target:hacker):  anonymous  331 Guest login ok, send ident as password.  Password: ******  230  Guest login ok, access restriction apply.  ftp>  get /etc/passwd 

The messages from the FTP server can vary; however, the numeric values are standardized on all implementations .

Proper configuration of FTP is a must. Misconfigured anonymous FTP can open your system to both the theft and destruction of data. Anonymous FTP should be configured as follows:

The anonymous FTP account entry in the system's password file, /etc/passwd , should be similar to

 ftp: DISABLED:500:500::/users/anon_ftp:/bin/false 

The entry in the system's group file, /etc/group , and login group file, /etc/logingroup , should be similar to

 ftp:DISABLED:500: 

If the permissions of the FTP directory tree are not configured correctly, a hacker may be able to add an executable file to the bin directory or put a .rhosts file in the account's home directory and allow himself remote access via the Berkeley Trusted Hosts commands.

The anonymous FTP home directory and its subdirectories should have ownership and permissions as follows:

 drwxr-x---  6  root  ftp  512 Jan 1 08:00 .  drwxr-x---  9  root  bin  512 Jan 1 08:00 ..  drwxr-x---  2  root  ftp  512 Jan 1 08:00 bin  drwxr-x---  2  root  ftp  512 Jan 1 08:00 etc  drwx-wx---  2  root  ftp  512 Jan 1 08:00 incoming  drwxr-x---  2  root  ftp  512 Jan 1 08:00 pub 

If any of these directories is owned by ftp , then an intruder could compromise the system.

The optional incoming directory allows anonymous FTP users to store files on the system. Anonymous FTP is allowed write permission into the incoming directory. This directory has only write and execute permissions, allowing FTP to write into, but preventing FTP from listing, the contents of the directory. Having an incoming directory will allow an anonymous user to fill up your disk space.

FTP's password and group files should contain no information other than the lines for FTP, as in the following examples:

FTP's password file:

 ftp:DISABLED:500:500::: 

FTP's group file:

 ftp: DISABLED:500: 

Any commands in the bin directory should have the permissions --x--x--x so no one can interrogate the binary or replace it.

Trivial FTP , TFTP, is a file transfer program that requires no authentication. No user name or password is requested . This program will send and receive files to or from anyone who asks for them. The program is generally restricted to send only those files that are in the home directory tree of the user named "tftp." TFTP is generally used to boot up network devices such as network terminal servers, network-based printers, and X terminals.

If you do not require TFTP, disable or remove the TFTP daemon, tftpd.

If your system has network access, you should try to get the password file with tftp, because hackers will.

 $      tftp  tftp>  connect target.com  tftp>  get  /etc/passwd /tmp/target.passwd 

Hackers may also be able to place a .rhosts file in the tftp home directory and then use trusted services to gain access to your system. Be sure the secure flag is set on the tftpd daemon in the internet configuration file, and there is a tftp user with a properly secured home directory. This flag will limit TFTP access to the tftp user's home directory. The entry in the internet configuration file should be similar to this:

 tftp dgram udp wait root  /etc/tftpd tftpd -s /u/tftp 

On some systems the secure flag may be "-r". Consult the manual page for TFTP. If your system does not have a secure flag, then try the above commands. If you can get your password file, so can a hacker. If this is the case, contact your vendor for a secure implementation of TFTP.

Since the tftpd daemon is started by inetd, you can use inetd.sec to restrict access to your TFTP services to specific machines.

Services Which Enable Trust

Trust is the situation where one system will trust the security of another system and relinquish control of security to that system. Usually trust is limited to user authentication, so that any user from a trusted system is considered to be trustworthy and no further authentication will take place. This is a user convenience giving users single-login, but it opens the door to hackers. Once one system is compromised, all the other systems in the chain of trust are directly vulnerable.

Berkeley Trusted Hosts is a subsystem that allows global authentication on a group of trusted hosts or equivalent systems. These systems are said to trust each other. Specifically, this means you can have access to all the trusted hosts without having to reenter your password. It also means that if a trusted system is compromised, then all the systems that trust the compromised system must be considered compromised.

Generally, all systems in a trusted host group are similarly managed, often by the same administrator. This is where the hacker is most likely to start to expand his realm. The /etc/hosts.equiv file will show him all the trusted hosts. The trusted hosts will generally all have the same user IDs. The .rhosts files will show him systems that users have added as trusted hosts; these are especially useful to the hacker; since they were added by users and not the system manager, the systems that are being trusted may not have the same level of security. The ".rhosts" files allow a user to define another user ID on another system to use the current system as the current user. Trusted systems are generally reciprocally trusted, so if a user has a .rhosts file on this system allowing access from another system, it is likely that the other system has a similar .rhosts file.

To find the home directories that have a .rhosts file use the following script:

 cut -d: -f6  /etc/passwd  xargs -i ls -l {}/.rhosts 2>/dev/null 

This command is the basis for any tool that needs to locate or process files in a user's home directory. The cut command reads the sixth field of the password file, which is the home directory entry, and then uses xargs to execute a command for each user's home directory.

Trusted telnet is a facility which allows telnet to utilize the Berkeley trusted hosts facilities, so one can log in to a trusted host without using a password. A typical configuration may consist of one or more secure front-end systems and a network of participating hosts. Users who have successfully logged onto the front-end system may telnet directly to any participating system without being prompted for another login. This option supports the TAC User ID (also known as the TAC Access Control System, or TACACS User ID), and uses the same files as rlogin to verify participating systems and authorized users, hosts.equiv, and .rhosts.

Enable the TAC User ID option. The system administrator can enable the TAC User ID option on servers designated as participating hosts by having inetd start telnetd with the -t option in /etc/inetd.conf :

 telnet stream tcp nowait root /usr/lbin/telnetd telnetd -t 

In order for the TAC User ID option to work as specified, the system administrator must assign to all authorized users of the option the same login name and unique user ID (UUID) on every participating system to which they are allowed TAC User ID access. These same UUIDs should not be assigned to non-authorized users.

Users cannot use the feature on systems where their local and remote UUIDs differ , but they can always use the normal telnet login sequence. Also, there may be a potential security breach where a user with one UUID may be able to gain entry to participating systems and accounts where that UUID is assigned to someone else, unless the above restrictions are followed.

Syslogd , the system logging daemon, can receive and store log information from other systems. There is no authentication required to send data to this service, so that any information sent to the syslog daemon will be written in the log files. On Linux systems, the remote logging feature has to be enabled. However, on HP-UX, it is enabled by default and has to be disabled with the "-N" option to disable this anonymous access.

I l @ ve RuBoard


Halting the Hacker. A Practical Guide to Computer Security
Halting the Hacker: A Practical Guide to Computer Security (2nd Edition)
ISBN: 0130464163
EAN: 2147483647
Year: 2002
Pages: 210

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net