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.

Using lsof (page 485-486)

lsof can identify what files are open in a directory, and find who's accessing them. To locate servers that are in use using lsof type the -i parameter: # lsof -i. Connections are identified by the existence of two hostnames in the NAME column and by the keyword ESTABLISHED in the same column. You can restrict the output of lsof by entering an address after the -i option. You can search for connections associated with an FTP port by typing: # lsof -i :ftp. If their ar not FTP connections than the command won't return an output. For a shortcut to find active servers type: # lsof -i | grep LISTEN.

Using Remote Network Scanners (page 487)

Nmap and Nessus are two network scanners that can scan for open ports on the local computer or other computers. Nessus which is a more sophisticated scanner can check for known vulnerabilities so you can tell if a server will be comprimised if you leave it running. To perform a basic check for open ports using Nmap enter the -sT parameter and the name of the target system. $ nmap -sT seeker.rodsbooks.com. The -sT option only scans for TCP ports if you want to scan for UDP ports type: nmap -sU hostname. Scanning for UDP ports requires root privilages.

Administering Local Security (P. 490)

Passwords are a very important part of securing your network. Linux Configurations rely heavily on passwords. Even if your physical network is completely secured, weak passwords present a problem. People near-by could guess them or hackers on the other side of the planet could crack them.

Requirements for a Strong Password (P. 490)

• Upper and lower case letters
• Numbers
• Special Characters (!@#$%^&*())
• At least 8 Characters
• Change password frequently
• Use Passwords from /etc/shadow
• Never reveal your password to anybody
• Use Secure login protocols (SSH)
• Don’t use same password twice
• Be alert to shoulder surfing and social engineering

Password Cracking (P. 491)

Attackers can use cracking programs such as Crack to crack almost any password. Some passwords include network interfaces, bank login, facebook, email, hash files, wifi, system passwords.

Password Managers (P. 493)

Password Managers are more secure than using the standard password hash file.

Linux password hashs are stored in the /etc/passwd file. But Linux has a built in password manager called Shadow which places the very secure file in /etc/shadow

Shadow has more attributes to its hash file such as aging and account expiration.

Limit Root Access (P. 494)

Root can do anything on a linux machine. It can even delete every single file on your operating system without verification. Only let people who need and have common sense and knowledge have access to sudo. The sudoers file is located in /etc/sudoers In this file you can choose which commands the sudoers can have access to.

Login, Process, and Memory Limits (P. 495-496)

Allows you to create limits on how many users can log in, how much of the cpu they consume, how much RAM they can consume, and other hardware vitals.

To do so you edit the configuration file which is located at /etc/security/limits.conf Four fields must be edited domain, type, item, value

Fields:

• Domain – what the limitation applies to (user or group)
• Type – Hard or soft. Hard is imposed by the system administrator and cannot be exceeded by any means. Soft may be temporarily exceeded by a user.
• Limited item – cpu, ram, hdd space, video mem, logins
• Value – Limited value applied to limited item.