Next Previous Contents

4. Host Security

The next thing to take a look at is the security in your system against attacks from local users. Did we just say local users? Yes!

Getting access to a local user is one of the first things that system intruders attempt, while on their way to exploiting the root account. With lax local security, they can then ``upgrade'' their normal user access to root access using a variety of bugs and poorly setup local services. If you make sure your local security is tight, then the intruder will have another hurdle to jump.

Local users can also cause a lot of havoc with your system even (especially) if they really are who they say they are. Providing accounts to people you don't know or have no contact information for is a very bad idea.

4.1 Delete Unnecessary Packages

If you know you are not going to use some particular package, you can also delete it entirely. /bin/rpm -e <packagename> under the Red Hat distribution will erase an entire package. Under debian /bin/dpkg likely does the same thing.

If you are configuring a new machine to be installed on the network, only initially install the packages that are necessary for its normal operation.

Removing unnecessary setuid and setgid binaries should be a priority. You should always be aware of which ones are available on your system. You can do this using the following:

                        user@myhost$ find / -type f -perm +6000

This will find all the setuid and setgid binaries on your system. You can find more about the setuid and setgid permissions in the File System Security section.

4.2 Default System Configuration

The default Linux system installation is generally far more secure than other operating systems, due to not having to conform to older standards and traditions.

However, installing any operating system, and connecting it to the network is a foolish idea. Many system defaults are still more lenient than is intended to be used in a production network system.

Spend some time to customize it to your environment. Be sure to follow these guidelines, as well as the ones refered to herein, including disabling any services that are not necessary, configuring auditing, etc, before connecting a machine to the network.

4.3 Make a Full Backup of Your Machine

Discussion of backup methods and storage is beyond the scope of this document, but a few words relating to backups and security:

If you have less than 650Mb of data to store on a partition, a CD-R copy of your data is a good way to go (as it's hard to tamper with later, and if stored properly can last a long time). Tapes and other re-writable media should be write protected as soon as your backup is complete and verified to prevent tampering. Make sure you store your backups in a secure off line area. A good backup will ensure that you have a known good point to restore your system from.

A six-tape cycle is an easy one to maintain. This includes four tapes for during the week, one tape for even Friday's, and one tape for odd Friday's. Perform an incremental backup every day, and a full backup on the appropriate Friday tape. If you make some particular important changes or add some important data to your system, a backup might well be in order.

4.4 Backup Your Red Hat or Debian File Database

In the event of an intrusion, you can use your RPM database like you would use tripwire, but only if you can be sure it too hasn't been modified. You should copy the RPM database and /bin/rpm executable to a floppy or Zip disk, and keep this copy off-line at all times. The Debian distribution likely has something similar. (Would someone fill me in here, until I get Debian re-installed?) See the section on Integrity Checking for further information, and instructions on how to do this.

4.5 Make Use of Your System Accounting Data

It is very important that the information that comes from your system accounting files has not been compromised, and is installed and configured properly. Making the files in /var/log, /var/run/utmp, and /var/log/wtmp readable, and writable only by the root user is a good start. Knowing which tools to use at what times is a good practice.

You can find more information on this in the User and System Accounting section.

4.6 Apply All New System Updates

Most Linux users install from a CDROM. Due to the fast paced nature of security fixes, new (fixed) programs are always being released. Before you connect your machine to the network, it's a good idea to check with your distribution's ftp site (ftp.Red Hat.com for example) and get all the updated packages since you received your distribution CDROM. Many times these packages contain important security fixes, so it's a good idea to get them installed.

4.7 Creating New Accounts

You should make sure to provide user accounts with only the minimal requirements for the task they need to do. If you provide your secretary, or another general user, with an account, you might want them to only have access to a word processor or drawing program, but be unable to delete data that is not his or hers.

Several good rules of thumb when allowing other people legitimate access to your Linux machine:

Many local user accounts that are used in security compromises are ones that have not been used in months or years. Since no one is using them they provide the ideal attack vehicle.

4.8 Root Security

The most sought-after account on your machine is the superuser account. This account has authority over the entire machine, which may also include authority over other machines on the network. Remember that you should only use the root account for very short specific tasks and should mostly run as a normal user. Running as root all the time is a very very very bad idea.

Several tricks to avoid messing up your own box as root:

If you absolutely positively need to allow someone (hopefully very trusted) to have superuser access to your machine, there are a few tools that can help. sudo allows users to use their password to access a limited set of commands as root. sudo keeps a log of all successful and unsuccessful sudo attempts, allowing you to track down who used what command to do what. For this reason sudo works well even in places where a number of people have root access, but use sudo so you can keep track of changes made.

Although sudo can be used to give specific users specific privileges for specific tasks, it does have several shortcomings. It should be used only for a limited set of tasks, like restarting a server, or adding new users. Any program that offers a shell escape will give the user root access. This includes most editors, for example. Also, a program as innocuous as /bin/cat can be used to overwrite files, which could allow root to be exploited. Consider sudo as a means for accountability, and don't expect it to replace the root user yet be secure.

4.9 Workstations and DialUp Security

User of computers to connect to the Internet via a dial-up line, or workstations that otherwise offer no services to external hosts can also improve their security with relatively easy modifications to the stock Linux installation.

If there is never have a need to connect to your machine from another one on the network, the quickest solution is to simply disable /usr/sbin/inetd from even being started. This is the master Internet daemon, which controls some normal server services, such as telnet, ftp, etc. If you retrieve your mail from a remote host, and your Internet Service Provider is hosting your web page, then most likely there is not a need to enable these services.

On stock Red Hat systems, the file /etc/rc.d/rc3.d/S50inet controls the starting and stopping of the inetd server. Simply rename the S50inet file to s50inet to disable it, or see your Red Hat administration manual for further information.

Alternatively, if you are a home dialup user, it is also possible to deny all incoming connections using TCP Wrappers. TCP Wrappers, /usr/sbin/tcpd, also logs failed attempts to access services, so this can give you an idea that you are under attack. If you add new services, you should be sure to configure it to use tcp_wrappers TCP based. For example, a normal dial-up user can prevent outsiders from connecting to your machine, yet still have the ability to retrieve mail, and make network connections to the Internet. To do this, you might add the following to your /etc/hosts.allow:

ALL: 127.

(including the ending period) And of course /etc/hosts.deny would contain:

ALL: ALL

which will prevent external connections to your machine, yet still allow you from the inside to connect to servers on the Internet. TCP Wrappers can be combined with several other services, such as sendmail and sshd to give even further control over access. See the respective documentation for further information.

4.10 X11, SVGA and display security

X11

It's important for you to secure your graphical display to prevent attackers from doing things such as grabbing your passwords as you type them without you knowing it, reading documents or information you are reading on your screen, or even using a hole to gain superuser access. Running remote X applications over a network also can be fraught with peril, allowing sniffers to see all your interaction with the remote system.

X has a number of access control mechanisms. The simplest of them is host based. You can use xhost to specify what hosts are allowed access to your display. This is not very secure at all. If someone has access to your machine they can xhost + their machine and get in easily.

When using xdm (X Display Manager) to login, you get a much better access method: MIT-MAGIC-COOKIE-1. A 128bit cookie is generated and stored in your .Xauthority file. These cookies need to be transferred in confidence, and you really don't gain anything if your home directory is shared via NFS. If you need to allow a remote machine access to your display, you can use the xauth command and the information in your .Xauthority file to provide only that connection access. See the Remote-X-Apps mini-howto, available at http://sunsite.unc.edu/LDP/HOWTO/mini/Remote-X-Apps.html.

You can also use ssh (see ssh, below) to allow secure X connections. This has the advantage of also being transparent to the end user, and means that no un-encrypted data flows across the network.

Take a look at the Xsecurity(1) man page for more information on X security. The safe bet is to use xdm(1) to login to your console and then use ssh to go to remote sites you wish to run X programs off of.

SVGA

SVGAlib programs are typically setuid-root in order to access all your Linux machine's video hardware. This makes them very dangerous. If they crash, you typically need to reboot your machine to get a usable console back. Make sure any SVGA programs you are running are authentic, and can at least be somewhat trusted. Even better, don't run them at all.

GGI (Generic Graphics Interface project)

The Linux GGI project is trying to solve several of the problems with video interfaces on Linux. GGI will move a small piece of the video code into the Linux kernel, and then control access to the video system. This means GGI will be able to restore your console at any time to a known good state. They will also allow a secure attention key, so you can be sure that there is no Trojan horse login program running on your console. http://synergy.caltech.edu/~ggi/

4.11 identd

identd is a small program that typically runs out of your inetd. It keeps track of what user is running what tcp service, and then reports this to whoever requests it.

Many people misunderstand the usefulness of identd, and so they disable it or block all off site requests for it. identd is not there to help out remote sites. There is no way of knowing if the data you get from the remote identd is correct or not. There is no authentication in identd requests.

Why would you want to run it then? Because it helps you out, and is another data-point in tracking. If your identd has not been compromised, then you know it is telling remote sites the user-name or user-ID of people using TCP services. If the admin at a remote site comes back to you and tells you a user was trying to hack into their site, you can easily take action against that user at your site who is misusing a service. If you are not running identd, you will have to look at lots and lots of logs, figure out who was on at the time, and in general take a lot more time to track down the user.

The identd that ships with most distributions is more configurable than many people think. You can disable identd for specific users (they can make a .noident file), you can log all identd requests, which is recommended, and identd can return a uid instead of a user name or even NO-USER. Keep in mind it is really only useful is on a network where nobody hostile has root access. Then it can help in catching mail forgeries, for instance.


Next Previous Contents