UNIX Computing Security/Remote access
Suggested topics: modems, ftp, rlogin, ssh, UUCP, NFS, Samba, and Apache.
Telnet
editTelnet 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 telnet 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 telnet 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 telnet is to configure it to run as a Kerberos client, when this functionality is available. The Kerberos 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 telnet, 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 rlogin. This reduces the risk of back-door access methods of the later commands.
The telnet 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
editThe /etc/securetty 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 console 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 su - to become root. In fact this is a recommended method as it allows usage of the root account to be logged.
When the /etc/securetty file is created it should be properly restricted to prevent modification from any accounts except root. Thus an owner and group of root:sys and a file mode of 640 would effectively secure this file.
ftp
editThe 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 ftp 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 ftp 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 sftp command equivalent does not have as rich a set of supported commands as does the standard version of ftp.
There are several other features of ftp that can present a security issue for the System Administrator. The first of these is the use of the .netrc 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 .netrc are in an unencrypted form. So if an unauthorized person is able to gain read access to the .netrc 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 .netrc 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 ~ftp/etc/passwd file should not include encrypted password information, and only the ls command should be in the ~ftp/usr/bin/ 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
editThe sendmail 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 sendmail, and to apply the latest security patches to this product as they become available.
On each system where it is loaded, sendmail reads a file that is used to store a list of mail aliases. These aliases are e-mail addresses that the sendmail 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 sendmail daemon executes the /usr/local/bin/record_bug.sh 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 smrsh shell. When the sendmail process is configured to use smrsh 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 sendmail.cf configuration file using the Mprog option.
Under construction...