LPI Linux Certification/LPIC2 Exam 202/System Security

Section Overview

Configuring a router
Securing FTP servers
Secure shell (OpenSSH)
TCP_wrappers
Security tasks

Configuring a router

Overview

Description: The candidate should be able to configure ipchains and iptables to perform IP masquerading, and state the significance of Network Address Translation and Private Network Addresses in protecting a network. This objective includes configuring port redirection, listing filtering rules, and writing rules that accept or block datagrams based upon source or destination protocol, port and address. Also included is saving and reloading filtering configurations, using settings in /proc/sys/net/ipv4 to respond to DOS attacks, using /proc/sys/net/ipv4/ip_forward to turn IP forwarding on and off, and usingtools such as PortSentry to block port scans and vulnerability probes.

Key files, terms, and utilities include:

/proc/sys/net/ipv4 
/etc/services 
ipchains 
iptables
routed

Configuring a router

There are numerous steps you should take to configure a router connected to insecure networks like the Internet First of all, identify what services you need, and have a policy of blocking everything else ! This minimize your exposure to security breaches.

Common steps for routers are :

Log all dropped/rejected packets (and limit the rate at which you log, to avoid logfiles size explosion) Use NAT whenever you can – unroutable addresses are more difficult to hack Define a default policy for TCP/UDP block ports answers: drop/reject/reset ?

Dropping isn't really helpful, scanners nowadays detect it easily. Rejecting may still show that a firewall is blocking access, resetting acts as if nothing is listening (i.e the « normal » way)

Unless you know you need it, drop (and log + limit) all ICMP packets except the most useful : dest-unreachable, time-exceeded and echo-reply

Protect against known attacks, i.e : anti-spoofing of IP addresses, disable source_route packets, disable icmp_redirect, log « martians » IP addresses (i.e addresses which appear on an interface they don't belong to), disable syn_cookies, disable ECN (Explicit Congestion Notification), disable TCP timestamps, ICMP broadcasts and ICMP bogus errors

Exercises

.

Securing FTP servers

Overview

Description: The candidate should be able to configure an anonymous download FTP server. This objective includes configuring an FTP server to allow anonymous uploads, listing additional precautions to be taken if anonymous uploads are permitted, configuring guest users and groups with chroot jail, and configuring ftpaccess to deny access to named users or groups.

Key files, terms, and utilities include:

ftpaccess, ftpusers, ftpgroups 
/etc/passwd 
chroot

Securing an FTP server will include :

FTP Warning Banner customization
FTP Greeting Banner customization
Securing, denying and restricting User Accounts
Securing Anonymous Access
Securing Anonymous Upload

FTP protocol

The File Transport Protocol (FTP) is an older TCP protocol designed to transfer files over a network. Because all transactions with the server, including user authentication, are unencrypted, it is considered an insecure protocol and should be carefully configured.

wu-ftpd FTP server

We will focus on the wu-ftpd FTP server from Washington University

Wu-ftpd's main configuration files are in /etc : ftpusers,ftpaccess and ftpconversions the ftpusers file contains a list of all those users who are not allowed to log into your FTP server. As you can imagine, user root should be listed here. You should also make sure that other special user accounts such as lp, shutdown, mail, etc. are included here.

the ftpaccess file is used to configure issues such as security, user definitions, etc. It's actually the general configuration file. Some interesting settings that you can establish here are: loginfails [number]

    where number is a number that stands for the amount of times that a user is allowed to fail to authenticate before being totally disabled.

shutdown [filename]

    where filename is the name of a file that, if it exists, automatically shuts down the FTP server without a need to actually close the port in the /etc/inetd.conf file and then restarting inetd.

Finally, the ftpconversions file is used to allow the clients special "on-the-fly" conversions of files, i.e automatic decompression of files on download

FTP Warning Banner

Returning a customized banner to FTP clients when they connect is a good idea, as it helps disguise what system the FTP server is running on. ou can send banners to incoming connections either using TCP wrappers, or as described below.

Add the following line to its configuration file, /etc/ftpaccess : banner /etc/banners/warning.msg

The contents of the banner file should look something like this : Hello, all activity on ftp.example.com is logged.

FTP Greeting Banner

After login, all users are presented with a greeting banner. By default, this banner includes version information useful to crackers trying to identify weaknesses in a system.. To change the greeting banner for wu-ftpd, add the following directive to /etc/ftpusers: greeting text <insert_greeting_here> Securing FTP servers

Because FTP passes unencrypted usernames and passwords over insecure networks for authentication, it is a good idea to deny system users access to the server from their user accounts. To disable user accounts in wu-ftpd, add the following directive to /etc/ftpusers: deny-uid * To disable specific user accounts in wu-ftpd, add the username to /etc/ftpusers

Anonymous Access

The best way to setup anonymous FTP is by configuring a chroot jail : instead of allowing total access to the system, this will limit access to a given directory. In other words, after an anonymous user logs into the system she will only have access to the user ftp's home directory and nothing else. If she enters cd /, which in most other cases should take her to the system's root directory, it will only take her to /home/ftp most likely (it's the default home directory for the user ftp).

Most distributions like RedHat provide an anonymous ftp package, to help prepare the chroot jail It's important to give to your strictly FTP users no real shell account on the Linux system. In this manner, if for any reasons someone could successfully get out of the FTP chrooted environment (see below for definition), it would not have the possibility of executing any user tasks since it doesn't have a bash shell. First, create new users for this purpose. This has to be separate from a regular user account with unlimited access because of how the chroot environment works. Chroot makes it appear from the user's perspective as if the level of the file system you've placed them in is the top level of the file system.

Setup these new users with a shell as /dev/null, and add /dev/null in the list of allowed shells, /etc/shells. Make sure also that in /etc/passwd, their home dir is listed as /home/./ftp (for user ftp), even though the real dir is /home/ftp

Setup a chroot user environment : what you're essentially doing is creating a skeleton root file system with enough components necessary, binaries, password files, etc. to allow Unix to do a chroot when the user logs in. Note that wu-ftpd may be compiled with the --enable-ls option, in which case the /home/ftp/bin, and /home/ftp/lib directories are not required since this new option allows Wu-ftpd to use its own ls function. We still continue to demonstrate the old method for people that prefer to copy /bin/ls to the chroot'd FTP directory, /home/ftp/bin and create the appropriated library related tools. The following are the necessary steps to run Wu-ftpd software in a chroot jail: first create all the necessary chrooted environment directories:

[root@deep ] /# mkdir /home/ftp/dev
[root@deep ] /# mkdir /home/ftp/etc
[root@deep ] /# mkdir /home/ftp/bin
[root@deep ] /# mkdir /home/ftp/lib

Change the new directories permission to 0511 for security reasons: The chmod command will make our chrooted dev, etc, bin, and lib directories readable and executable by the super-user root and executable by the user-group and all users :

[root@deep ] /# chmod 0511 /home/ftp/dev/
[root@deep ] /# chmod 0511 /home/ftp/etc/
[root@deep ] /# chmod 0511 /home/ftp/bin
[root@deep ] /# chmod 0511 /home/ftp/lib

Copy the /bin/ls binary to /home/ftp/bin directory and change the permission of the ls program to 0111. You don't want users to be able to modify the binaries:

[root@deep ] /# cp /bin/ls /home/ftp/bin
[root@deep ] /# chmod 0111 /bin/ls /home/ftp/bin/ls

Find the shared library dependencies of the ls Linux binary program: :

[root@deep ] /# ldd /bin/ls
   libc.so.6 => /lib/libc.so.6 (0x00125000)
   /lib/ld-linux.so.2 =7gt; /lib/ld-linux.so.2 (0x00110000)

Copy the shared libraries identified above to your new lib directory under /home/ftp directory:

[root@deep ] /# cp /lib/libc.so.6 /home/ftp/lib/
[root@deep ] /# cp /lib/ld-linux.so.2 /home/ftp/lib/

Create your /home/ftp/dev/null file:

[root@deep ] /# mknod /home/ftp/dev/null c 1 3
[root@deep ] /# chmod 666 /home/ftp/dev/null

Copy the group and passwd files in /home/ftp/etc directory. This should not be the same as your real ones. For this reason, we'll remove all non FTP users except for the super-user root in both of these files, passwd and group.

Edit the passwd file, vi /home/ftp/etc/passwd and delete all entries except for the super-user root and your allowed FTP users. It is very important that the passwd file in the chroot environment has entries like:

root:x:0:0:root:/:/dev/null
ftpadmin:x:502:502::/ftpadmin/:/dev/null

(notice two things here: first, the home directory for all users inside this modified passwd file are now changed to reflect the new chrooted FTP directory i.e. /home/ftp/./ftpadmin/ begins /ftpadmin/, and also, the name of the user's login shell for the root account has been changed to /dev/null) Edit the group file, vi /home/ftp/etc/group and delete all entries except for the super-user root and all your allowed FTP users. The group file should correspond to your normal group file:

root:x:0:root
ftpadmin:x:502:

Now we must set passwd, and group files in the chroot jail directory immutable for better security.

[root@deep ] /# cd /home/ftp/etc/
[root@deep ] /# chattr +i passwd

Set the immutable bit on group file:

[root@deep ] /# cd /home/ftp/etc/
[root@deep ] /# chattr +i group

Configure your /etc/pam.d/ftp file to use pam authentication by creating the /etc/pam.d/ftp file and add the following lines:

#%PAM-1.0
auth    required /lib/security/pam_listfile.so item=user sense=deny \ file=/etc/ftpusers onerr=succeed
auth    required /lib/security/pam_pwdb.so shadow nullok
auth    required /lib/security/pam_shells.so
account required /lib/security/pam_pwdb.so
session required /lib/security/pam_pwdb.so

Anonymous Upload

If you want to allow anonymous users to upload, it is recommended you create a write-only directory within /var/ftp/pub/. To do this type:

mkdir /var/ftp/pub/upload

Next change the permissions so that anonymous users cannot see what is within the directory by typing:

chmod 744 /var/ftp/pub/upload

A long format listing of the directory should look like this:

drwxr--r--    2 root     ftp          4096 Aug 20 18:26 upload

=== Exercises ===.

Secure Shell (OpenSSH)

Overview

Description: The candidate should be able to configure sshd to allow or deny root logins, enable or disable X forwarding. This objective includes generating server keys, generating a user's public/private key pair, adding a public key to a user's authorized_keys file, and configuring ssh-agent for all users. Candidates should also be able to configure port forwarding to tunnel an application protocol over ssh, configure ssh to support the ssh protocol versions 1 and 2, disable non-root logins during system maintenance, configure trusted clients for ssh logins without a password, and make multiple connections from multiple hosts to guard against loss of connection to remote host following configuration changes.

Key files, terms, and utilities include:

ssh, sshd
/etc/ssh/sshd_config 
~/.ssh/identity.pub, ~/.ssh/identity
~/.ssh/authorized_keys 
.shosts, .rhosts

OpenSSH

OpenSSH is a free, open source implementation of the SSH (Secure SHell) protocols. It replaces telnet, ftp, rlogin, rsh, and rcp with secure, encrypted network connectivity tools. OpenSSH supports versions 1.3, 1.5, and 2.0 of the SSH protocol.

If you use OpenSSH tools, you are enhancing the security of your machine. All communications using OpenSSH tools, including passwords, are encrypted. Telnet and ftp use plaintext passwords and send all information unencrypted. The information can be intercepted, the passwords can be retrieved, and then your system can be compromised by an unauthorized person logging in to your system using one of the intercepted passwords. The OpenSSH set of utilities should be used whenever possible to avoid these security problems. Another reason to use OpenSSH is that it automatically forwards the DISPLAY variable to the client machine. In other words, if you are running the X Window System on your local machine, and you log in to a remote machine using the ssh command, when you execute a program on the remote machine that requires X, it will be displayed on your local machine. This is convenient if you prefer graphical system administration tools but do not always have physical access to your server.

The ssh command is a secure replacement for the rlogin, rsh, and telnet commands. It allows you to log in to and execute commands on a remote machine.

Logging in to a remote machine with ssh is similar to using telnet. To log in to a remote machine named penguin.example.net, type the following command at a shell prompt: ssh penguin.example.net

The first time you ssh to a remote machine, you will see a message similar to the following: The authenticity of host 'penguin.example.net' can't be established.

DSA key fingerprint is 94:68:3a:3a:bc:f3:9a:9b:01:5d:b3:07:38:e2:11:0c.
Are you sure you want to continue connecting (yes/no)? 
Type yes to continue. This will add the server to your list of known hosts as seen in the following message:
Warning: Permanently added 'penguin.example.net' (DSA) to the list of known hosts.

Next, you'll see a prompt asking for your password for the remote machine. After entering your password, you will be at a shell prompt for the remote machine. If you use ssh without any command line options, the username that you are logged in as on the local client machine is passed to the remote machine. If you want to specify a different username, use the following command:

ssh -l username penguin.example.net

You can also use the syntax ssh username@penguin.example.net. The ssh command can be used to execute a command on the remote machine without logging in to a shell prompt. The syntax is ssh hostname command. For example, if you want to execute the command ls /usr/share/doc on the remote machine penguin.example.net, type the following command at a shell prompt:

ssh penguin.example.net ls /usr/share/doc

After you enter the correct password, the contents of /usr/share/doc will be displayed, and you will return to your shell prompt.

The scp command can be used to transfer files between machines over a secure, encrypted connection. It is similar to rcp.

The general syntax to transfer a local file to a remote system is scp localfile user@hostname:/newfilename. The localfile specifies the source, and the group of user@hostname:/newfilename specifies the destination. To transfer the local file shadowman to your account on penguin.example.net, type the following at a shell prompt (replace user with your username):

scp shadowman user@penguin.example.net:/home/user

This will transfer the local file shadowman to /home/user/shadowman on penguin.example.net. The general syntax to transfer a remote file to the local system is scp user@hostname:/remotefile /newlocalfile. The remotefile specifies the source, and newlocalfile specifies the destination.

Multiple files can be specified as the source files. For example, to transfer the contents of the directory /downloads to an existing directory called uploads on the remote machine penguin.example.net, type the following at a shell prompt:

scp /downloads/* username@penguin.example.net:/uploads/

The sftp utility can be used to open a secure, interactive FTP session. It is similar to ftp except that it uses a secure, encrypted connection. The general syntax is sftp username@hostname.com. Once authenticated, you can use a set of commands similar to using FTP. Refer to the sftp manual page for a list of these commands. To read the manual page, execute the command man sftp at a shell prompt. The sftp utility is only available in OpenSSH version 2.5.0p1 and higher.

Generating Key Pairs

If you do not want to enter your password every time you ssh, scp, or sftp to a remote machine, you can generate an authorization key pair.

Note: Separate Authorization Key Pairs You must have separate authorization key pairs for SSH Protocol 1 (RSA) and SSH Protocol 2 (DSA).

Warning : Each User Needs Their Own Key Pair !

Keys must be generated for each user. To generate keys for a user, follow the following steps as the user who wants to connect to remote machines. If you complete the following steps as root, only root will be able to use the keys.

Use the following steps to generate a DSA key pair. DSA is used by SSH Protocol 2 and is the default for Red Hat. 1. To generate a DSA key pair to work with version 2.0 of the protocol, type the following command at a shell prompt:

ssh-keygen -t dsa

Accept the default file location of ~/.ssh/id_dsa. Enter a passphrase different from your account password and confirm it by entering it again.

(A passphrase is a string of words and characters used to authenticate a user. Passphrases differ from passwords in that you can use spaces or tabs in the passphrase. Passphrases are generally longer than passwords because they are usually phrases instead of just a word.)

2. Change the permissions of your .ssh directory using the command chmod 755 ~/.ssh.

3. Copy the contents of ~/.ssh/id_dsa.pub to ~/.ssh/authorized_keys2 on the machine to which you want to connect. If the file ~/.ssh/authorized_keys2 doesn't exist, you can copy the file ~/.ssh/id_dsa.pub to the file ~/.ssh/authorized_keys2 on the other machine.

Use the following steps to generate a RSA key pair for version 2.0 of the SSH protocol.

1. To generate a RSA key pair to work with version 2.0 of the protocol, type the following command at a shell prompt:

ssh-keygen -t rsa

Accept the default file location of ~/.ssh/id_rsa. Enter a passphrase different from your account password and confirm it by entering it again. [1]

2. Change the permissions of your .ssh directory using the command chmod 755 ~/.ssh.

3. Copy the contents of ~/.ssh/id_rsa.pub to ~/.ssh/authorized_keys2 on the machine to which you want to connect. If the file ~/.ssh/authorized_keys2 doesn't exist, you can copy the file ~/.ssh/id_rsa.pub to the file ~/.ssh/authorized_keys2 on the other machine.

Use the following steps to generate an RSA key pair, which is used by version 1 of the SSH Protocol.

1. To generate an RSA (for version 1.3 and 1.5 protocol) key pair, type the following command at a shell prompt:

ssh-keygen

Accept the default file location (~/.ssh/identity). Enter a passphrase different from your account password. Confirm the passphrase by entering it again.

2. Change the permissions of your .ssh directory and your keys with the commands chmod 755 ~/.ssh and chmod 644 ~/.ssh/identity.pub.

3. Copy the contents of ~/.ssh/identity.pub to the file ~/.ssh/authorized_keys on the machine to which you wish to connect. If the file ~/.ssh/authorized_keys doesn't exist, you can copy the file ~/.ssh/identity.pub to the file ~/.ssh/authorized_keys on the remote machine.

=== Exercises ===.

TCP_wrappers

Overview

Description: The candidate should be able to configure tcpwrappers to allow connections to specified servers from only certain hosts or subnets.

Key files, terms, and utilities include:

inetd.conf, tcpd 
hosts.allow, hosts.deny 
xinetd

TCP_wrappers

The TCP wrapper is a system to control access to network services For each service protected by TCP wrappers, the tcpd program is used and consults 2 files where access rights are defined, in search order :

/etc/hosts.deny: if a rule here is met, access is denied
/etc/hosts.allow: if a rule here is met, access is allowed

Rules are constructed to match all services or specific services. If no match occurs in the two files, access is granted.

It is common to set specific rules in /etc/hosts.allow, and provide a blanket denial in /etc/hosts.deny (i.e deny everything except when specifically allowed) Rules format are :

[list of services] : [list of hosts]

i.e : deny all incoming requests except FTP from the local domain

/etc/hosts.allow :
ftp : LOCAL

/etc/hosts.deny :
ALL : ALL

=== Exercises ===.

Security tasks

Overview

Description: The candidate should be able to install and configure kerberos and perform basic security auditing of source code. This objective includes arranging to receive security alerts from Bugtraq, CERT, CIAC or other sources, being able to test for open mail relays and anonymous FTP servers, installing and configuring an intrusion detection system such as snort or Tripwire. Candidates should also be able to update the IDS configuration as new vulnerabilities are discovered and apply security patches and bugfixes.

Key files, terms, and utilities include:

Tripwire 
nessus
netsaint
snort
telnet 
nmap

Security tasks

Task: Install and Configure Kerberos

Installing:

Configuration files:

Kerberos Reference:

Use atelnet client to test/debug your servers This implies you know a little about the protocol used : read the corresponding RFCs Check security mailing lists such as Bugtraq, CERT, et al. regularly Patch your systems ASAP !

Run a security scanner on your system regularly Network security scanners Nessus and Netsaint are widely used, highly considered and open-source Bastille Linux is a great host-based security scanner Use some Intrusion Detection Systems (IDS), both network- and hosts-based Tripwire Snort

Don't forget : security is a never-ending process, not a state or a product !