CNT-2311-Chapter 10 Notes

Configuring SSH (page 499)

Secure Shell (SSH) is the preferred remote login tool.

SSH Basics (page 499)

Linux supports remote login access through several different servers including Telnet, VNC and even X. They all transfer data over the network in unencrypted form. SSH encrypts the password exchange and all subsequent data transfers. SSH provides file transfer features & the ability to tunnel other network protocols Several SSH servers are available, the most popular is the OpenSSH server OpenSSH can be launched using a super script or with a SysV startup script (preferred) Configuring Basic SSH Features (page 500) The main configuration file for the OpenSSH server is /etc/ssh/sshd_config The default settings work for most systems. You might want to check or modify: Protocol Level: Version 2.0 is preferred due to known vulnerabilities in earlier versions. Permit_Root_Login: The default is yes, but this is a security risk. X11_Forwarding: (X tunneling features) The default is no If you make changes to the configuration file, be sure to restart the server.

SSH Keys (page 501)

SSH uses a security system that involves two keys: a Private Key and Public Key All parties that engage in an SSH communication have their own keys. These keys are mathematically linked so that data encrypted with a Public Key may only be decrypted with the matching Private Key. On the server, there are normally 4 to 6 keys and they are stored in /etc/ssh If keys are not present, you can generate them with the ssh-keygen command On the client, keys are stored in the ~/.ssh/known_hosts file. You can pre-populate this file on the client to prevent security warnings.

Controlling SSH Access (page 503)

You may restrict access to an SSH server by requiring password authentication You may be able to limit access by IP Address with TCP Wrappers You can use a firewall to restrict access to the SSH server to port 22 only. If you have the file /etc/nologin on the server, only root may log in.

Copying Files via SSH (page 503)

SSH includes a file-copying command: scp It works like cp but you must specify the target computer You must use a colon at the end of this command to prevent renaming the file

Configuring Logins without Passwords (page 504)

SSH can be configured to allow logins without passing a password A security risk is if someone gains access to your account on the client, then they have your access to the server. To do this, you must generate a special key pair on the client, transfer the Public Key to the server, and place it in the ~/.ssh/authorized_keys file.

Using ssh-agent (page 505)

Another SSH authentication option is to use the ssh-agent program. This program requires a password to start a connection, but remembers the password for the remainder of the session. It is configured using a slight variation to the no-password method.

Using SSH Login Scripts (page 505)

SSH text-mode login sessions run the user’s configured shell. That runs the shell’s defined login scripts. The OpenSSH server supports its own login script – sshrc

Setting Up SSH Port Tunnels (page 505)

SSH has the ability to encrypt other protocols and thus protect them in transit On the server side, must make sure that the /etc/ssh/sshd_config file has the option AllowTCPForwarding set to yes On the client side, you must establish a special SSH connection using the -N, -f, and the -L options.

SSH Security Considerations (page 507)

SSH can be a security liability. If you need to use SSH, you should consider: - Only accept protocol level 2 connections - Refuse direct root logins - If X forwarding is not necessary, disable it - Use TCP Wrappers or a firewall to limit the machines that can connect - Keep SSH up to date - Protect the keys

Using GPG (page 507)

GPG or Gnu Privacy Guard is a tool for encrypting e-mail. GPG can encrypt an entire message or digitally “sign” a message.

Generating and Importing Keys (page 508)

GPG keys are similar to SSH keys in that you need a Public and Private key. You can sign a message with your Private key and readers can verify it with your Public key. You can encrypt a message with the readers Public key and they can decrypt it with their Private key. To encrypt e-mail, you must obtain the Public key from others. Then you can add their keys to your keyring, which is a file that contain the e-mail address and corresponding keys that you have imported from others.

Encrypting and Decrypting Data (page 509)

This section explains the command syntax for encrypting data with GPG. You can encrypt an entire file and attach it to your text-based e-mail message. You can use the --armor option to create ASCII output which can be cut and pasted into a message. When you receive a message that was encrypted with your Public key, you can reverse the encryption with the --decrypt option.

Signing Messages and Verifying Signatures (page 510)

GPG can be used to sign messages and to verify signatures. The –sign option creates a new file encrypted with your Private key. The --clearsign option leaves the message unencrypted but adds an encrypted signature that can be decrypted with your Public key. If you receive a signed message, you can verify it with the --verify option.

Administering Network Security (page 476)

The two simplest ways to prevent unwanted acces to computers is by shutting down access to network servers or controlling network ports that are used. You can also disable servers that aren't being used and check for open ports. Use Super Server restrictions to limit acces.

Using Super Server Restrictions (page 477)

A super server listens for network connections on behalf of another program and after a connection is found hands off control to the intended server. Super servers can reduce memory load because it handles many small seldom used servers. Usually only one or two of the servers that it handles are in memory. Security checks can be launched from the super server to protect all servers that it manages. The two major super servers are: inetd and xinetd.

Configuring inetd (page 477-479)

Type ps ax | grep inetd to see wether inetd or xinetd is running on your system.The output should have either an inetd or xinetd command. Servers that launch via inetd are controlled through the /etc/inetd.conf file or files within /etc/inetd.d directory. Newer versions of inetd allow you to split configurations into several files instead of using a single /etc/inetd.conf file. This allows you to easily add or delete server configurations by adding or deleting their configuration files. After modifying inetd.conf you have to restart the inetd super server. In order to to restart the server type in a command similar to this one: #/etc/rc.d/init.d/inetd restart. Instead of using SysV startup scripts the kill or killall command can be used.

Controlling Access via TCP Wrappers (page 479)

The TCP Wrapper package includes a program known as tcpd. Instead of calling a server directly inetd calls tcp which checks wheter a client is authorized to access a server and if the client has authorization tcp calls the server. /etc/hosts.allow and /etc/.hosts.deny are the two files that TCP Wrappers are configured through.The allow file specifies computers that are allowed access to a system where as the deny filelists computers that aren't allowed access. If a computer is listed in both the allow and deny files the allow fule takes precedence. Both files consist of the same daemon-list : client-list format. The daemon=-list is a list of servers, and the client-list is a list of computers to be granted or denied acces to specified servers (daemons).

Configuring xinetd (page 480-481)

xinetd provides functions of inetd plus security options similar to TCP Wrappers. The /etc/xinetd.conf file controls xinetd. Info that goes in either an xinetd.conf file or an xinetd directory it contains similar information that's in an inetd.conf file. However the info in an xinetd configuration file is spread across multiple lines and lables it more explicitly. xinetd is generally not used with TCP Wrappers because it has similar functionality. An important parameter in xinetd is disable = yes. If this is included in a service entry xinetd ignores the entry. To restart xinetd after configuring it type a similar command to this one: #/etc/rc.d/init.d/xinetd restart. The other option to restarting xinetd is to use the kill or killall command.

=== Controlling Access via xinetd (page 481-482) Security is handled on a server by server basis with the use of parameters.These parameters are in either the xinetd.conf file or the server-specific configuration files. Some options are similar to the function of hosts.allow and hosts.deny. You can use the bind option with bind = (use a specific router number) to tell xinetd to listen to only one network interface. Use the only_from option to specify which computers, networks or IP address connections xinetd accepts. The no_access option tells xinetd which computers, networks or IP address not to accept. Use the access_times option to set times during which users can access the server.

Disabling Unused Servers (page 483)

Begin by locating unwanted servers. Several tools can be used to help do this this such as: netstat, lsof, and remote network scanners. You can disable servers by uninstalling the package or reconfiguring the server.

Using netstat (page 483)

netstat can help network activity or open ports on a computer. To spot unnecessary servers you can use netstat's -a and -p options: # netstat -ap If a server or port is't actively connected its local and foreign address will show up with an * in place of an address. Type netstat -ap | less to to see a list of servers listaning for connections and servers with established connections. Servers that have LISTEN in the State column of output are lestening for a connection. Type -ap | grep ssh to find connections involving SSH.