Session (1) Secure Unix Administration Who is a system administrator? What is his/her job?

Who is a system administrator? A system administrator is the person who installs or manages the installation of both the software and hardware components on all the systems in the unit, then manages and maintains them to achieve maximum service. He/She is a person with organization and management skills. He/She has an extraordinary 6th sense and can determine the problems, almost predict them, before they happen. He/She has authority to give authorized users access to the computing services or take the access away from unauthorized. He/She is a full-time employee who goes to work as a system administrator, works many hours overtime as a system administrator, and dreams as a system administrator.

What does he/she do? Adds or remove users. Makes sure there is a backup of the files on tapes. Restores the deleted or required files from backup files. Think about the files that you may delete by accident. Installs new software and upgrades the existing ones. Answers questions that users may have. Monitors the system activities, disk usage and log files. Troubleshoots the problems with the software and hardware or find the appropriate resource to solve the problems. Keeps up with the advances in the technology and recommend/order the required equipments and software to meet the latest advancements.

Some Common System Administration Tasks Monitors the system security. Assures that the system is as secure as possible and tries to understand the vulnerabilities of the system and finds the fix patches. Adds new systems to the network. Tries to remove the unnecessary files and users to free up disc space. Reboots the system after a crash to make sure everything is working properly. Writes scripts to automate as many of the daily tasks as possible.

What are we going to do in this course? Go through most common administrative tasks: Going through installation of Unix operating systems Practicing some of the administrative activities Setting up network on a Unix System Review some of the security issues Going through some of the security issues and discuss the fixes. Make some recommendations on different issues that system administrators are facing.

Booting and Shutting Down a Unix (Unix-based) System Bootstrapping is the word used in place of “Starting up a computer” During the boot up the normal facilities provided by the OS are not available. Thus, the computer must bring the system up by its own bootstrap. During the boot process, the kernel loaded into memory and begins to execute. Several things can prevent a system from booting up correctly: Error in configuration files Missing or unreliable equipment Damaged file systems

Steps in the boot process Normal bootstraps process are: Loading and initialization of the kernel Kernel : is a program, /unix or /nmunix 1st ROM loads a small boot program into RAM, then this program arranges for kernel to be loaded, and kernel tests to see how much RAM is available the memory locations used by the kernel are reserved Device detection and configuration Creation of spontaneous system processes Operator intervention (only in manual boot) Execution of system startup scripts Multi-user Operation This process is usually done automatically without intervention of the system administrator. However, one can modify the booting process by the system startup scripts.

Hardware Configuration The kernel first determines what hardware is presented. When the kernel for your system is built, it was told what hardware are expected to be in place. Kernel probes the bus then appropriate drivers to obtain the complete information about the devices. Any device with incomplete information will be disabled. Such a device is not accessible even if connected to the system later. The device will be detected in the next bootstrap process. Depending on the initialization process, kernel creates several “spontaneous” processes in user space.

Manual Boot This usually is referred to a single mode boot. In this case the kernel passes a flag to notify the init of the start up procedure. During the start up process user must provide the root password. Once in single-mode, you have the command prompt and the root directory (/). You may need to mount other files or directories. Daemons usually do not run in the single-mode. That includes all the commands that are dependent on the server processes (ex. mail). In most cases, once the system is in single-mode, the root directory is mounted as read-only. Thus, some of the commands such as vi that reside in the /tmp will not run. One can mount the files with appropriate permission at the command prompt or modify the fstab or vfstab to reflect the desired changes.

Linux Boot Loader (LILO) This loader provides many complex facilities that other boot loaders are missing, but is missing some simple features. LILO comes with almost all Linux distributions. LILO is not strictly required for booting Linux, but without it life is much harder. LILO can either be installed into the MBR of the disk or it can be installed into the boot record of the Linux root partition. LILO is configured using the lilo command. The lilo command bases its installation on what it will find in the /etc/lilo.conf file. Any updates must be made in that file and LILO must be rerun to see the new changes.

Sample LILO Configuration File boot=/dev/hda # Put boot loader on MBR root=/dev/hda1 # Specify root partition install=/boot/boot/b map=/boot/map delay=20 # 2 sec for user interrupt image=/vmlinuz # Kernel to boot label=linux read-only image=/vmlinuz-backup #Backup entry label=backup

MBR and another in the The FreeBSD Boot Loader This boot loader has two parts. One part lives in the FreeBSD root partition. These two segments must be installed separately. The MBR portion will be installed using: # boott0cfg –B /dev/wd0 This installs the first-stage boot loader into the MBR of the first IDE disk. Some fine-tuning of the installation of the first-stage boot loader can be done using boott0cfg command. The second portion is installed using: # disklabel –B This refers to /boot/loader.conf, /boot/loader.conf.local, and /boot/defaults/loader.conf to obtain configuration information.

Startup Scripts After you exist the single-mode or when you let the system to boot automatically, init executes the system startup scripts. The system startup script is some shell scripts that are interpreted by sh. In systems descended from BSD, the scripts are kept in the /etc directory and have names starting with the letters rc. In systems driven from System-V, the scripts are kept in the /etc/init.d directory and links to them are made in the directories /etc/rc0.d and /etc/rc1.d. System-V organization is preferred.

Some tasks that are often performed in the startup scripts Setting up the name of the computer Setting the time zone Checking the disks with fsck (only when automatic boot is used) Mounting the system disks Removing old files from the /tmp directory Configuring network interfaces Starting up daemons and network services. Most startup scripts print out a description of everything they are doing. This helps us determine an error that happens during the boot up. If there you need to modify the startup script, it is a good practice not to put them directly in the startup script file. Instead, we can put the changes in a separate configuration file (or files) that the scripts consult.

Startup Scripts System V stem like scripts are very common. The System V init defines 7 “run levels” each representing a complement of services that the system should be running: Level 0 is the level in which the system is completely shut down. Level 1 or S represents single-user mode Levels 2 through 5 are multiuser levels. Level 6 is a “reboot” level. Level 0 and 6 are special because the system leaves them either to shut down or to reboot. In most cases level 2 or 3 are used and in rare occasions levels 4 or 5 are used.

The inittab file This file will tell init what to do at each run levels. Although the file format is different from system to system, this file defines the commands that are to be run (or kept running) when the system enters each level. As the machine boots, init builds its way up from run level 0 to the default run level set in /etc/inittab. The transition between each pair of adjacent levels are spelled out for init in the inittab file. The reverse progression is spelled out for the shutdown process. A system administrator usually do not deal directly with the inittab file.

An example of inittab file

An example of inittab file - continued

The init.d Directory This directory keeps master copies of the startup scripts. This directory usually resides in under the /etc directory. Each script is responsible for one daemon or one particular aspect of the system. The scripts understand the stop and start which is used to halt or initialize a service. Most scripts are written such that the word restart means to stop then to start a service. As a system administrator, you can stop, start, and restart the services listed under the init.d directory.

A sample startup script This script start, stop, and restart sshd. # /bin/sh test –f /usr/local/sbin/sshd || exit 0 Case “$1” in start) echo –n “Starting sshd: sshd” /usr/local/sbin/sshd echo “.” ;; stop) echo –n “Stopping sshd: sshd” kill `cat /var/run/sshd.pid`

This script start, stop, and restart sshd. Continued echo –n “Stopping sshd: sshd” kill `cat /var/run/sshd.pid` echo “.” start) echo –n “Starting sshd: sshd” /usr/local/sbin/sshd ;; *) echo “Usage: /etc/init.d/sshd start/stop/restart” exit 1 esac

Important Notes about the init.d scripts Scripts in init.d directory needs additional information to be sent along with the start, stop, and restart. This information is on the run level and which script to run for the desire run level. init looks at a directory called rclevel.d, where level is the run level to be entered upon execution of the command. For instance, rc0.d, rc1.d, and so on. The rclevel.d directories typically contain symbolic links that points back to the init.d directory. The name of all these symbolic links start with S or K followed by a number and the name of the service that the script controls. For example; S34named. S stands for stop and K for stop (kill).

More on init.d scripts When init transmits from a lower run level to a higher run level, it runs all the scripts that start with S in ascending numerical order with the argument start. When init transmits from a higher run level to a lower run level, it runs all the scripts that start with K in descending numerical order with the argument stop. To tell the system when to start a daemon, we need to make symbolic links into the appropriate directory. Most systems start majority of networking daemons during the run level 2. Example: # ln –s /etc/init.d/sshd /etc/rc2.d/S99sshd (runs with the stop argument) #ln –s /etc/init.d/sshd /etc/rc0.d/K25sshd (runs with the start argument) This starts the sshd during run level 2 and stop the daemon nicely before shutting down. The order (99) put the execution of sshd for the last thing,

Rebooting and shutting down a UNIX system Unix machines are particularly sensitive to the shutdown process. We cannot simply turning the machine off. It is recommended that a UNIX system be shutdown through the shutdown process. When do we shutdown? When a new piece of hardware is added to the machine When a configuration file is modified When the system’s memory is so filled that you no longer can login or processes are extremely slow. Whenever you modify the startup script or have done something that will result in such modifications.

Different ways to shut down a UNIX system Turning off the power (not recommended) Using the shutdown command Using the halt and reboot commands (BSD,, Linux) Sending init a signal to terminate Using telinit to change init’s run level (System V type systems) Killing init There might be several options associated with everyone of these shutdown procedure.

Root Power Every file on a UNIX machine is owned by a user. In general a user does not have access to another user’s files without permission. The file permission is the convenient used to protect users’ files from unauthorized access. All system files and processes are owned by “root” also known as superuser. Root’s properties are protected from other users. No user can assume ownership of files or processes that belong to root, however, root can assume ownership of properties owned users. A file has three permissions: by self, by group, and by others (world)

File Permission In general, file permission are read, write, and execution. A file is owned by a single user but can be accessible by a group of people or by everyone on the system. The User’s IDs are mapped to user names in the /etc/passwd file, the Group IDs are mapped to group names in the /etc/group file. Processes have four identities associated with them. 1) A real and effective UID and a real and effective GID. The real numbers are used for accounting purpose and the effective numbers are used for determination of access permissions. Normally the real and effective numbers are the same. There is an exception to this when the setuid or setgid permission bit of a file is set. We learn about this later.

The Superuser The root’s user ID is 0. A Security Tip: Unix allows root to create other users with UID of 0, but that is not a good idea. You also can give a user the name superuser, that is not a good idea either. Some of the restricted operations that can be done by superuser: Changing the root directory of a process with chroot Creating device files Setting the system clock Raising resource usage limits and process priorities Setting the system’s host name Configuring network interfaces Shutting down the system

Root Password Root password must be at least 8 characters long. Passwords with less number of characters are easier to crack. Root password must be something so that it cannot be easily guessed or discovered. A good password is random combination of lower case letters, uppercase letters, numbers, and special characters in length 8, but due to the fact that such a random string is hard to remember a system administrator may end up doing one of the two that results in insecurity of the system: choose a password that is a word that he/she can remember write the hard password somewhere.

Root Password In general, the best way to choose a password is to use the phrase of “shocking nonsense” defined by Grady Ward: “Shocking nonsense” means to make up a short phrase or sentence that is both nonsensical and shocking in the culture of the user. That is, it contains grossly obscene, racist, impossible or otherwise extreme juxtapositions of ideas. This technique is permissible because the passphrase, by its nature, is never revealed to anyone with sensibilities to offend. Shocking nonsense is unlikely to be duplicated anywhere because it does not describe a matter of fact that could be accidentally rediscovered by someone else. The emotional evocation makes it difficult for the creator to forget. A mild example of such shocking nonsense might be, “Mollusks peck my galloping genitals.” The reader can undoubtedly make up many far more shocking or entertaining examples for him or herself.”

Criteria for changing the root password A system administrator should change the root password: At least every three months or so Every time someone who knows the password leaves your site Whenever you think security may have been compromised When you are not distracted, so you remember how you chose the password When by mistake you left the root screen open for some period of time (even in your own office) After your remote login to the system as root. Of course the assumption is that you did not directly login as root.