UNIX Computing Security/Remote access

Suggested topics: modems, ftp, rlogin, ssh, UUCP, NFS, Samba, and Apache.

Telnet
Telnet was once an extremely popular method of remote access. However, it has been almost entirely replaced by SSH. Perhaps the only remaining legitimate use of Telnet is low-level debugging of other internet protocols such as HTTP and SMTP.

The  command is used to establish a connection with another host that can be accessed via the network, and communicate with it using the TELNET protocol. Typically  is used to connect to a user login via the standard TELNET port. For the default configuration, the login password is sent across the network in clear-text form. That is to say, if the network packets between the two hosts are being read by some intermediary, then the password string will appear in the packets in a readable form. Likewise any data sent through during the session will also appear in readable form, including any other secure information sent to the remote hosts.

Normally, if you want to maintain the security of your communications, the default configuration of telnet should only be employed on network segments that you are highly confident are secure. Establishing such a network is becoming increasingly difficult, however, unless of course it is kept physically isolated. (Even then it is never possible to be 100% certain.)

A method of securing the password using  is to configure it to run as a   client, when this functionality is available. The  client will support secure authentication, and help maintain the secrecy of the password string. However this will not provide an encrypted session, so data transmission subsequent to the login will remain vulnerable to interception.

Something that can be said in favor of, from a security perspective, is that it typically lacks the means to bypass the login sequence that is available to the Berkeley remote login commands, such as. This reduces the risk of back-door access methods of the later commands.

The  service can normally be configured to display a text banner prior to the presentation of the login prompt. This banner can be useful for presenting a carefully-worded warning to anybody accessing the system. So in this sense it is like a "Do Not Trespass" sign on a piece of property. If somebody is presented this warning prior to login, then they can not claim ignorance of what they were trying to access. The presence and consistent use of a login banner can be useful in the event that a prosecution of an individual for unauthorized access becomes necessary.

/etc/securetty
The  file is used to enable login security. When the file exists, the root account is only allowed to login via the listed devices in the file, one per line. To prevent direct remote connection via the root account, a recommended practice is to only include the single entry  within this file. Note that this does not prevent a System Administrator from connecting to the system via their user account and then executing an  to become root. In fact this is a recommended method as it allows usage of the root account to be logged.

When the  file is created it should be properly restricted to prevent modification from any accounts except root. Thus an owner and group of  and a file mode of   would effectively secure this file.

ftp
The File Transfer Protocol is intended to allow the reliable transmission of files between two systems on the network. It has two network ports, usually 20 and 21, and uses tcp for reliable packet transfer. (Port 20 is employed for data transfer, while port 21 is used for session control.)

Connecting to a remote system via  requires a login at the destination. However unless a secure authentication system such as kerberos has been enabled, the password will be transmitted across the network in the clear. That is, anybody using a packet sniffer to intercept the session packets will be able to read the password. In addition, any data files are also sent in unencrypted form. This uprotected version of  should only be used across a secure network, or in cases where security is not an issue. (See anonymous ftp below.) For encrypted login and file transmission, the Secure Shell software can be used. However, at least at present, the  command equivalent does not have as rich a set of supported commands as does the standard version of.

There are several other features of  that can present a security issue for the System Administrator. The first of these is the use of the  file in a user's home directory. This file can be configured to allow automatic connection to a remote site without the need to provide an account name or password. However, any passwords stored in  are in an unencrypted form. So if an unauthorized person is able to gain read access to the  file (such as by compromising the system) they may also be able to gain access to other remote systems. To prevent this situation, many System Administrators will regularly search their systems for  files and then either remove them or check their contents.

The ftp daemon can be configured to allow a form of access that is known as "anonymous ftp". This allows any individual from a remote site to connect by typing "anonymous" at the login prompt, then entering any string as a password. (By convention the password is usually entered in the form of an e-mail address, but this is a courtesy only.) An improperly configured anonymous ftp capability can present a host of weaknesses that can be exploited by an intruder.

The instructions for how to properly configure an anonymous ftp account are usually given in the manual pages for the ftp daemon. If this service is required, great care should be taken to follow the documented instructions. In particular, the  file should not include encrypted password information, and only the ls command should be in the   directory and have 111 permissions.

More here...

Many vendors have adopted the wu-ftpd flavor of the File Transfer Protocol. This incorporates additional features in the ftp configuration, many of which can be used to enhance the security of a system.

More to come...

Sendmail
The  program is used to send, relay, and receive electronic mail using SMTP (Simple Mail Transfer Protocol). Unfortunately it has had a spotted history with respect to security vulnerabilities and exploits. For this reason it is important to take advantage of any security features that have been added to, and to apply the latest security patches to this product as they become available.

On each system where it is loaded,  reads a file that is used to store a list of mail aliases. These aliases are e-mail addresses that the  program translates into another form, such as a distribution list of e-mail addresses. One of the built-in features of the alias list is the ability to execute a shell command using a prog mailer.

Here is an example of just such an entry: save_debug_message  : "|/usr/local/bin/record_bug.sh",debug_log

When an e-mail message is sent to the save_debug_message address on this server, its  daemon executes the   command and passes the mail message to the script as standard input.

As you might expect, this capability can readily introduce security vulnerabilities into the system. Messages with arbitrary content can be sent to this address, and if it does not securely process the data a suitably-formatted e-mail could potentially be used to compromise the system. Likewise if the script is not securely protected, users on the system can modify it for their own purposes. A user with a terminated account might even be able to regain access by this means.

A capability that was introduced to try and limit the amount of damage that an aliased command could introduced was the use of the  shell. When the  process is configured to use   as the prog mailer, it limits the capabilities of the script being executed. The System Administrator can restrict the commands that can be run in the script to a small set of "safe" commands. The prog mailer is configured in the  configuration file using the   option.

Under construction...