Home Menu

Security

Contents

Introduction to Security Issues

Security is significant system administration problem, and may take up more time than any other single problem. So what is security? It is the process of insuring that a computer system is secure in the sense that:

These are very general statements that can cover a multitude of evils: backing up data, disk redundancy, preventing unwanted intrusions, software testing, file consistency checking, etc. This is a topic that could easily consume an entire semester, so we are going to look at some very specific security concerns. First we will look at some very fundamental intrusion issues at this point; as we go along we will consider issues of data protection; finally, we will look at the general category of network security later on.

An unwanted intrusion can be generally classified as one or more people getting access to system resources that they shouldn't have access to. The more highly publicized examples are internet worms and hackers, all of which are the sworm enemy of system administrators and anyone with half a brain. Dealing with intrusion can be roughly divided into the following areas:

Each of these is pretty obvious - keep them out if you can, find out about it as quickly as possible if they get in, and then get rid of them. All of this is best done with minimal pain and suffering for your users, but that is impossible to do in many cases. Prevention is always the best solution, and in the following, we will be looking at several prevention issues.

Securing Access

Access to a system can come from several fronts:

Securing Physical Access

The one thing that you can do to create a level of physical access control to your system is by passwording the boot process. If you edit /etc/grub.conf and add the following:

you can password the boot process. If the password is outside of any particular image, it applies to all processes. If the password is inside of an image definition, it applies to only that image. You can have multiple levels of passwords if you so desire. If you forget your passwords, you are toast.

The password that you supply is not simply a string, it has to be an md5 encrypted password. So you need to run grub-md5-crypt. It will ask you for a password (twice) and give you the string that needs to be pasted into the grub.conf file for the password. For example:

So how do intruders get in?

Securing Passwords

Stealing of passwords generally takes place when people write them down, if they type them in situations where others can watch carefully, or by exploiting some common weaknesses in the networks. So,

Password guessing used to be a problem, but is less so now, because most login systems do things to make it hard. For example, locking an account after a certain number of errors, stretching the time between repeat password entries and notifying system administrators and users when there are large numbers of password errors. If you have a system that doesn't do any of this, look into some packages to improve the situation. Linux does the latter two by default.

Password cracking is more of a problem. The Unix system password file is kept in the clear, which means that it is an unencrypted text file. The passwords in the file are encrypted, but if someone can grab the password file they can run a password cracker against it. This program tries to unencrypt a password until it gets something that looks reasonable. It normally tries words from a standard dictionary, and failing that, simply tries find a match by brute force. What they are doing is taking password guesses and running the crypt program to see if they get the same results as in the password file.

So how serious is this? It is generally assumed that a password of 8 characters can be broken in hours and a 9 character password in weeks. To make it difficult, you can choose longer passwords, and make the character set as large as possible by using upper and lower case letters, special characters (#,@,$,%,&, etc.) and digits. And don't choose something like your name spelled backwards, the brand of a car, the breed of a dog or the name of a supermodel (whatever that means). Good choices are two or three common words put together with some extraneous stuff thrown in, or an acronym. Think of a phrase and then pick the first letter of each word, and then toss in a few other things to confuse the issue.

Shadow Passwords

The obvious weakness in the Unix password file was carried over to Linux, but has now been addressed by Shadow passwords. In this scheme, the passwords are kept in a separate file that is root-accessible only, but the rest of the password file exists as it did before. All that changes is that the shadow password file is used for all password related operations

Fortunately, Red Hat 7.1 and most other new versions of Linux use shadow passwords by default. Look in your system for /etc/shadow. It should be there with permissions of -r--------. If the permissions are not these, change them with chmod 400 /etc/shadow.

If shadow passwords are not installed, you should fix that problem.

Pluggable Authentication Modules

Pluggable Authentication Modules or PAM is a very strong method of user authentication that allows one to use virtually any method desired to authenticate users. PAM is shipped with most recent Linux systems and more applications are allowing its use. An application that is PAM compliant can read the PAM configuration file and determine what method to use to authenticate users. We will take this up later.

Superuser

Superuser is the name given to someone running as root. This is a special situation because this user not only has access to a wide variety of resources that should normally be denied normal users, but also to special and sometimes dangerous commands.

A user is identified to the system by their uid and gid, which are in the password file. Look at /etc/passwd on your system and you will see that the file has the format:

If you have shadow passwords, all of the passwords should be x. But the numbers in the uid and gid fields specify the unique identifier of a user. One and only user should have uid 0 and gid 0, and that is root.

Normally, you should not log in as root, especially across the network, where the password may pass in the clear. Instead, login as a user, and then use the su command to become root. After typing su, it will ask for the root password. If you are logging in across the network, use the Secure Shell (ssh) client/server to encrypt the data stream.

Secure Shell

The default for recent Linux installs is that Secure Shell is installed. This is a service that will encrypt your password (and everything else) that goes across the network. This is very important and you are encouraged to use ssh exclusively to replace Telnet. In order to use ssh, all you do is replace the telnet command, with ssh:

You will be prompted for your password, but everything will be sent encrypted. If you attempt to attach to a new host, you will be given a message telling you that the authenticiy of the host can't be established. You can avoid this by preconfiguring an encryption key on that host, but if you have no reason to be suspicious, just tell it to go ahead.

In addition to ssh, there is a file transfer program, scp, that uses encryption, and more recently a secure ftp, sftp. If you don't have ssh installed, install it.

Securing Services

Since intruders can gain access to your system through services, you should try to prevent that. A service is exactly that, some function that your system provides to people on the system and possibly to those outside of the system. For example, telnet and ftp are services. These services operate by running either continuously or on demand, and when the service is requested, usually via the network, they communicate with the system that has asked for the service.

For example, if you telnet to another host, the telnet daemon (demon) is the program that gets the request and returns the message telling you to login, and then gets your password and if everything is copacetic, it exchanges messages with your telnet client to carry on your session.

That isn't a bad thing, but sometimes services have security weaknesses that can be exploited, and that is the crux of the problem. So it is wise to not run unnecessary services, and to limit access to those services as much as possible. We won't take up the first problem until the next unit, but we can do something about the second one. Recent versions of Linux have two ways of limiting access to services (actually there are three); TCP wrappers and xinetd.

To see a list of services, run the command:

Each service is shown with its status for each of the 7 runlevels. You are interested only in the status for runlevels 3 and 5 for the time being. To change bootup status of a service, you use the command:

on causes a service to run a the given runlevels, off turns it off and reset resets to the state in the init script. For example,

turns off the httpd service at runlevels 3, 4 and 5 and doesn't change it for runlevels 0,1,2 or 6.

chkconfig will impact the services only after a change of runlevel, such as a reboot, but you can also change the current state with the service command.

For example,

halts the httpd service.

TCP Wrappers

TCP wrappers are a simple scheme that uses a couple of files to tell service programs what users are acceptable and which aren't. This is based only on the IP address of the one requesting the service. The two files are:

The deny file is checked first, and then the allow file is checked, allowing the allow to override the deny. Example files are:

hosts.deny hosts.allow
ALL:ALL in.telnetd: localhost .silly.edu
  in.ftpd: localhost .silly.edu barney.mayberry.org
  sshd: putty.silly.edu smurf.blue.org .sunlight.com
  senmail: ALL

The general format of the files is:

This is pretty typical. First, you deny all services to everyone with the hosts.deny file. Then you allow just those that you want to have access for each service.

With recent distributions of Linux, you can choose not to use TCP wrappers because xinetd has taken over much of this effort to protect you from unethical bozos. However, some services, such as sendmail and sshd do use TCP wrappers, and if you create a hosts.allow file, you must put all the services you want in there. This may get better in the future, but for now that's the way it is.

xinetd

xinetd is a fairly new service manager program which replaces inetd. The fact that the name ends in d is an indication that this is a daemon or service in its own right. Normally, when you install, you will get the xinetd daemon running at runlevels 3 and 5. You can check by typing ps ax | grep xinetd. Since there are literally dozens of possible network services, systems were getting swamped with daemons running for each of them. xinetd tries to solve that problem by listening on behalf of the services and then starting the services only when they are needed. This is also a perfect opportunity to control access.

xinetd is controlled by a file named /etc/xinetd.conf, which typically refers to the files in a directory /etc/xinetd.d. A typical xinetd.conf file looks like this: 

#
# Simple configuration file for xinetd
#
# Some defaults, and include /etc/xinetd.d/
 
defaults
{
        instances               = 60
        log_type                = FILE /var/log/xinetd
        log_on_success          = HOST PID USERID DURATION
        log_on_failure          = HOST USERID RECORD
        no_access               = 0.0.0.0/0
        only_from               = 153.90.199.0/21 bees.honey.com
}
 
includedir /etc/xinetd.d

This file can have the complete configuration in it, but it is generally a lot easier to have the defaults here and the service specific stuff in files by themselves. The defaults are those characteristics that apply if nothing else does. In this case:

The include directory has a file for each possible service that might be controlled by xinetd. You can add more, but the typical list might be: 

amanda              daytime-udp         gssftp       linuxconf-web  talk
amandaidx           daytime-udp.rpmnew  imap         ntalk          telnet
amidxtape           dbskkd-cdb          imaps        pop3s          tftp
chargen             echo                ipop2        rexec          time
chargen-udp         echo-udp            ipop3        rlogin         time-udp
chargen-udp.rpmnew  echo-udp.rpmnew     klogin       rsh            wu-ftp
comsat              eklogin             krb5-telnet  rsync          wu-ftpd
daytime             finger              kshell       swat

which is pretty substantial. An example of a service that is used is the telnet service. The contents of telnet might be: 

   # default: on
   # description: The telnet server serves telnet sessions; it uses \
   #       unencrypted username/password pairs for authentication.
   service telnet
   {
           disable = no
           flags           = REUSE
           socket_type     = stream
           wait            = no
           user            = root
           server          = /usr/sbin/in.telnetd
           only_from       += 153.90.199.47 153.90.199.78
   }

These entries mean:

There are nearly 50 possible options here, and any one of them can be used in the default or a service definition. You typically don't need all of them or even most of them.

The default installation for xinetd is that all of the services are disabled, so you will need to go through and allow a small subset for specific addresses. Typically, these would include telnet and ftp (wu-ftpd). For now, you probably don't need anything else.

If you change the xinetd configuration, you need to restart the service. You can do this with the xinetd soft configuration signal: 

   kill -SIGUSR1 pid

where pid is the process identifier of the xinetd process which is the first field in the output of: 

   ps ax | grep xinetd

Or you can restart the daemon with the command: 

   service xinetd restart

This will start xinetd, but it will not automatically start it when you reboot which you want, so enter, 

   chkconfig --levels 345 xinetd on

With xinetd running and configured, go to /var/log and enter the following command: 

   tail -f xinetd

assuming that xinetd is the log file you have specified in xinetd.conf. This command will cause the system to send any new data going to the log file to the stdout as well. Then try to use the service (telnet, ftp, etc.) from a host that is allowed and one that isn't. You should see the appropriate messages regarding success or failure.

iptables

Network Address Translation is an extremely valuable mechanism that Linux includes in the kernel to make it fast and reliable. It treats network traffic (which often includes local applications) as a movement through a series of filters. We will talk about this later in greater detail, but for now, you should be aware that it might impact your ability to allow services to operate. There are two forms of NAT, ipchains and iptables. iptables is the newer version and is currently installed as the default in most distributions. NAT filtering allows you to configure your system to reject or accept traffic based on some very specific characteristics, and it is the basis of firewalling.

If you are running iptables, you may have to modify your rules if you are explicitly filtering traffic that is directed to xinetd, sshd or some other application. If you aren't sure, enter the following commands to see if you are running ipchains or iptables: 

   ipchains -L 
   iptables -L

You will see some output about the rules installed or an error indicating that it isn't installed.

You must keep ipchains or iptables running on your system because of the importance of protecting yourself from the village idiots that think breaking in to your system is fun. This can be an incovenience at times, but you will soon learn to deal with it.

As part of the postinstall process, you will want to look at your iptables and possibly make some changes. To find out more, check out the iptables intro .

So what do you want to allow into your system? The answer is only what you have to have. The more entry points their are in your system the more susceptible you are to exploits. Initially, you probably should allow only ssh in, and only from local hosts. As times goes on, you will add other services and you will need to open other ports, but you should do so only when needed, and only it to the necessary sources.

There isn't any overriding reason to limit output on most systems, unless you need to redirect traffic to a different host or if you want to, for example, limit http access to certain sites.

 

Home Menu