Assignment for Week 3: Security and Putting Your Machine on the Network

Description

Often a freshly-installed system is not safe to put on the network. This is because the versions of network services provided on an operating system installation CD tend to be out of date with current security fixes, and frequently many unnecessary services are enabled or poorly configured by default.

In the first part of this assignment, you'll investigate what happens when your system boots, and how processes are started after booting.

Using that information, you'll be making your machine safe to put on the network by disabling nearly all network services -- if they can't be reached from the network, they can't be exploited from the network. I'll be inspecting your machine with you to ensure your machine is secure before giving you your network cable.

Once your machine is functioning on the network, you will then download and install any security patches and updates available from your operating system distributor, document which patches and updates were applied and the procedure for doing updates, and come up with a for regularly updating your system as necessary when your OS distributor provides security updates.

What you need to do

1. Each member of your group should create a personal account of his or her own on your machine. From now on, whenever possible, individual group members should use their own accounts for access to the system, and use "su" to become root only as needed, rather than logging in as root directly. If creating non-privileged accounts is not part of the installation procedure for your OS, there is usually a utility with a name like adduser or useradd that can be used to create new accounts.
2. Boot your system and get a list of all the system processes (via ps -efl for System V-like UNIXen, or ps alx for BSD-like UNIXen). Using that listing identify how every process was started and what started it: the kernel, an init script (name the specific init script responsible), another process, or what?.
3. Using that information, figure out how to disable all network servers on your system (except sshd, if it is already installed). Once you have disabled them, try using netstat -a to show whether any network ports are still in use.
4. Once you think you've disabled these services, have someone in your group make an appointment with me to come see your machine. I'll ask you to reboot it (to make sure the services have been properly disabled at boot time) and look over the network status and processes on your machine. If it looks OK to me, I'll give you the network cable for your machine; if not, I'll let you know what other things you need to turn off before you can put it on the network.
5. Finish your machine's network configuration. Do not re-enable any externally-reachable network services other than sshd. Test your network configuration by seeing if you can connect to another system on the Internet where you have an account.

   Network configuration information:

   IP addresses for each assigned machine are shown on the lab map.

   You can pick your own hostname; your domain name will be ilab.cs.uoregon.edu.

   Your netmask is 255.255.255.0 (which implies that your network address is 128.223.203.0 and your broadcast address is 128.223.203.255).

   Your gateway address (router) is 128.223.203.1.

   Your /etc/resolv.conf file should look something like this:

   search ilab.cs.uoregon.edu
   nameserver 128.223.203.2
   nameserver 128.223.6.9
   nameserver 128.223.32.35

6. Check with your operating system distributor to see if they have security patches or updates for your release, and install them. Be sure to document the set of updates that you applied at this time. Based on your distributor's methods and policies, develop a plan for regularly checking and updating your system as they release new security updates. Again, do not re-enable services, even if you have patched them. In your next assignment you will re-enable some services.
7. If they have not already been installed or enabled, install and enable ssh and sshd on your system for more secure remote access. If your operating system doesn't come with ssh and sshd, (which is unlikely), you can get source code from http://openssh.com/portable.html. If your system comes with a version of OpenSSH previous to 3.4p1, you may want to upgrade it. If you have trouble finding SSH for your system, let me know and I'll give you a hand.

What to turn in

Please follow the assignment submission guidelines when turning in material.

1. The /etc/passwd entries for the personal accounts of your group.
2. The list of processes started on your system at boot time, and a description of how each one was started.
3. A list of the security advisories for your version of your OS, and the patches and updates you have installed.
4. Your plan for regularly checking for and applying updates from your OS distributor.

All of the above may be turned in by email or on paper by class time on Monday, July 14.

Please do the initial disabling of your network servers and make the appointment with me to inspect your machine and put it on the network by Thursday, July 10. Also choose a hostname for your machine by that time so I can make DNS entries for it (under the ilab.cs.uoregon.edu domain).

Each group member should also email to me separately their estimate of the percentage of the total work each group member (including themselves) contributed to this assignment, looking something like:

Alice: 40%
Bob: 30%
Carol: 30%

Class presentation/discussion

On Monday, July 14 I will take some time in class to have each group speak briefly about their experience with this assignment. Please discuss what was required to secure your initial operating system installation and the number of patches you had to apply to bring your system up to a current state.

Evaluation

This assignment is more vague than the last one, since it depends greatly on your choice of operating system. Also, it is mandatory that by the due date, you have your machine properly secured and functioning on the network.

You should be able to determine how all running processes on your system got started, and indicate specifically which system script or process created each one.

I may double-check your list of security updates against the documentation from your OS distributor, and evaluate your update plan based on their policies for providing updates.