31 – Linux Security

December 5, 2009 – 10:17 pm

Please note… This information no longer exists at the referenced locations.  This is only a copy of what was available in 2003.

Basic Linux Training™

Linux Security

Henry White

A reasonable level of computer security is not difficult to maintain on a home machine. Due to the open, volunteer nature of Linux development, security fixes often come out much faster than they do on commercial operating systems, making Linux a very pragmatic choice when security is a requirement.

Kevin Fenzi and Dave Wreski categorized 6 common types of Bad Guys in their ‘Linux Security HOWTO’:

There are several types of intruders, and it is useful to keep their different characteristics in mind as you are securing your systems.The Curious – This type of intruder is basically interested in finding out what type of system and data you have.

The Malicious – This type of intruder is out to either bring down your systems, or deface your web page, or otherwise force you to spend time and money recovering from the damage he has caused.

The High-Profile Intruder – This type of intruder is trying to use your system to gain popularity and infamy. He might use your high-profile system to advertise his abilities.

The Competition – This type of intruder is interested in what data you have on your system. It might be someone who thinks you have something that could benefit him, financially or otherwise.

The Borrowers – This type of intruder is interested in setting up shop on your system and using its resources for his own purposes. He typically will run chat or irc servers, porn archive sites, or even DNS servers.

The Leapfrogger – This type of intruder is only interested in your system to use it to get into other systems. If your system is well-connected or a gateway to a number of internal hosts, you may well see this type trying to compromise your system.

And as Hal Burgis wrote in his ‘Security Quick-Start HOWTO for Linux’:

Step 1: Turn off any and all unnecessary services.Step 2: Make sure that any services that are installed are updated and patched to the current, safe version — and then stay that way. Every server application has potential exploits. Some have just not been found yet.

Step 3: Limit connections to us from outside sources by implementing a firewall and/or other restrictive policies. The goal is to allow only the minimum traffic necessary for whatever our individual situation may be.

Awareness. Know your system, and how to properly maintain and secure it. New vulnerabilities are found, and exploited, all the time. Today’s secure system may have tomorrow’s as yet unfound weaknesses.

No doubt about it, ‘awareness’ is the key! Not denial, not blowing it off as something *other* people might have to do.

Ancient Chinese proverb: If you’re not just a little bit paranoid, then you obviously haven’t been paying attention.

By reading the available documentation about security matters, subscribing to the security alert mailing lists – particularly for your distribution of choice, and routinely keeping your installed packages up-to-date, you can do a lot towards securing your machine.

If you pay attention to your log files and run something like tripwire regularly, you can do even more.

Amazingly enough, you can set up a network server, workstation, or stand-alone machine from your Linux CDs. That coupled with the mad rush to give their distribution an edge in ‘ease of installation’ and in being ‘user friendly’ has inadvertently created way too much confusion about which packages you need and how much is enough ;-) Some of the distributions are inherently more stable and secure right out of the box – but that is still not good enough any longer in the RealWorld(tm).

Even if you followed the recommended installation, and have not been mucking around with configuration beyond getting your Internet connection and email set up, some of the packages that were installed may not be necessary, others may have been setup in a very insecure mode to make things easier for you to get started, etc. The assumption is that there is no such thing as as ‘one size fits all’ and that you will be making changes incrementally as you learn more about the system, customizing everything to suit your needs and preferences, etc. So don’t get ticked off because your distribution of choice included something you don’t need or want, or left the configuration less than optimal ;-)

While there is a great deal more urgency in security than most Windows users can grasp, that urgency does NOT mean you have to get it all done by sundown ;-) By now you have resigned yourself to what I told you before you signed up for the course – you’re going to have to do a LOT of reading, and it’s obvious that security is one of the biggest stumbling blocks since it is something entirely new. Sort of a continuation of file modes, permissions and ownership, only on steroids this time ;-)

Since Unix does not make changes to configuration files without first informing you and generally asking your permission beforehand, we can use the files themselves – particularly the modes, date, and size – to detect some unauthorized activity. Two problems with this – first you aren’t intimately familiar with what’s normal activity and what isn’t so you may have some suspected activity that turns out to be a weekly or monthly crontab for example; second the Bad Guys generally (but not always) are smart enough to cover their tracks, so the file size and date may be carefully disguised to camouflage their entry. Almost always they will leave a quick re-entry for themselves.

There are a boatload of security scanners available on your CD to get unauthorized access to your machine or unauthorized privileges. What you have to understand from the beginning is that if these scanners report a vulnerability and you don’t fix it, the Bad Guys can come in, run the same program and the scanner will tell *them* exactly where you’re vulnerable! (I suggest you go back and read that last sentence again very slowly, and very carefully. That needs to be hardwired into synapses and will undermine everything else you do if you don’t understand it.) Another thing you have to understand is that some of these utilities do a much better job in some aspects than other aspects, so it really pays to double-up and have redundancies – similar to using more than one anti-virus program to catch those critters that might slip past one or the other; also, as with the choice of differing anti-virus programs you have to know a little about how they work – if the algorithms take a completely different approach, they work much better in tandem.

First the system scanners (a/k/a keeping unauthorized users out of places they shouldn’t have access): COPS was one of the first security scanners and is rather dated but still does a good job finding areas where you’re giving away too much information. Tiger is probably a better choice (Texas A&M; updated it 1999 to work better with Linux). Nabou is another; it doesn’t work as a crontab but does have some checks the others don’t.

The network scanners (a/k/a keeping the Bad Guys from getting access to your system over the Internet): Klaxon (Auburn; runs from inetd); Courtney (Lawrence Livermore National Labs; in response to Satan); Scanlogd; PortSentry (not only detects scans but also takes action against the source).

Things have gotten to the point where it’s also practically almost necessary to harden your system – that is to make your system more secure than the default. Bastille is one of the most tested and proven approaches. You can set Bastille to automagically make assumptions for you, or you can run it in interactive mode. It’s not just for Red Hat any more, and you no longer have to run it immediately after a fresh install. LIDS (Linux Intrusion Detection System) is another, however it requires a kernel patch, as does Openwall Linux Patch.

All things considered, you might want to start with tiger, portsentry and bastille.

It’s really a sub-specialty but worth mentioning here – if you have a spare machine, you might want to use it as a firewall. You can also put a password on your BIOS, disable your floppy or put up a password on it (makes more sense to me than disabling it), add shadow passwords, MD5, etc.

Again, the learning curve is steep enough as it is, so don’t get the impression you have to do this all today ;-) After you get more comfortable with Linux, say in 3-6 months or a year, you’ll probably want to re-partition and do a fresh install to take advantage of some of the GoodIdeas(tm) and neat tricks you come across in the meantime. (It’s all part of the learning process.)

[From the 'Security Quick-Start HOWTO for Linux' (http://www.linuxdoc.org/HOWTO/Security-Quickstart-HOWTO/)]It is perfectly possible to have a fully functional Internet connection with no servers running that are accessible to outside connections. Not only possible, but desirable in many cases. The principle here is that you will never be successfully broken into via a port that is not opened because no server is listening on it. No server == no port open == not vulnerable. At least to outside connections.

If you don’t recognize a particular service, chances are good you don’t really need it. We will assume that and so we’ll turn it off. This may sound dangerous, but is a good rule of thumb to go by.

Some services are just not intended to be run over the Internet – even if you decide it is something you really do need. We’ll flag these as dangerous, and address these in later sections, should you decide you do really need them, and there is no good alternative.

I certainly agree with that! It’s all too common for new users to overload their system with stuff they’re never going to need, use, or even look at ;-) (Also one fundamental reason I do not recommend some of the other ‘popular’ documentation for new users – RUTE for example recommends loading everything in sight just so you can follow the discussion! TMWOT that’s foolishness of the first order!)

[Some of the distributions are going to require some sort of http/https server for the online documentation - usually apache since it's an international favorite across platforms and the de facto standard. In that case it is prudent to simply check that it is NOT acessible from outside your system.]

So what is really running on our system anyway? Let’s not take anything for granted about what “should” be running, or what we “think” is running.”

From the commandline, type

        netstat -tap > listening.services

to get a list.

Then

        less listening.services

You’ll get something similar to the following:

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address
State
tcp        0      0 *:8000                  *:*         LISTEN
tcp        0      0 *:kshell                *:*         LISTEN
tcp        0      0 *:exec                  *:*         LISTEN
tcp        0      0 *:imaps                 *:*         LISTEN
tcp        0      0 *:cvspserver            *:*         LISTEN
tcp        0      0 *:login                 *:*         LISTEN
tcp        0      0 *:shell                 *:*         LISTEN
tcp        0      0 *:pop3s                 *:*         LISTEN
tcp        0      0 *:printer               *:*         LISTEN
tcp        0      0 *:100                   *:*         LISTEN
tcp        0      0 *:dict                  *:*         LISTEN
tcp        0      0 *:time                  *:*         LISTEN
tcp        0      0 *:5865                  *:*         LISTEN
tcp        0      0 *:discard               *:*         LISTEN
tcp        0      0 localhost:427           *:*         LISTEN
tcp        0      0 *:2317                  *:*         LISTEN
tcp        0      0 *:daytime               *:*         LISTEN
tcp        0      0 *:finger                *:*         LISTEN
tcp        0      0 *:www                   *:*         LISTEN
tcp        0      0 *:ssmtp                 *:*         LISTEN
tcp        0      0 *:auth                  *:*         LISTEN
tcp        0      0 *:24374                 *:*         LISTEN
tcp        0      0 *:nntp                  *:*         LISTEN
tcp        0      0 *:telnet                *:*         LISTEN
tcp        0      0 *:ipp                   *:*         LISTEN
tcp        0      0 *:eklogin               *:*         LISTEN
tcp        0      0 *:smtp                  *:*         LISTEN
tcp        0      0 *:https                 *:*         LISTEN
tcp        0      0 *:7741                  *:*         LISTEN
tcp        1      0 localhost:2154          localhost:ipp
CLOSE_WAIT

This is just an example. You may see many additional ones, for example:

  *:x11                *:*        LISTEN    1462/X
  *:http               *:*        LISTEN    1078/httpd
  bigcat:domain        *:*        LISTEN    956/named
  bigcat:domain        *:*        LISTEN    956/named
  *:ssh                *:*        LISTEN    972/sshd
  *:sunrpc             *:*        LISTEN    1290/portmap
  *:ftp                *:*        LISTEN    988/inetd
  *:1694               *:*        LISTEN    1319/rpc.mountd
  *:netbios-ssn        *:*        LISTEN    422/smbd

Be honest now! How many of these do you recognize? Probably login, shell, printer, finger, telnet, smtp, ftp. On this particular machine pop3s, ssmtp, https are simply more secure versions of pop3, smtp, http respectively.

It’s time to get a pencil and paper to take notes! If you get a little too eager, you might remove something your system really needs. As I’ve said before, taking notes as you go along is the cheapest ‘insurance’ you can find. If you hose your system, the notes may not be all that clueful to you to work your way out, but they *will* give the rest of us something to work with so we can help you. Otherwise we’re as much in the dark about what/why/how as you will be. Since none of us are psychic, you’re up the creek without a paddle ;-)

The telnet and ftp daemons in the above example are *servers*, aka “listeners”. These accept *incoming* connections to your machine. You do not need these just to use ftp or telnet clients! For instance, you can download files from an FTP site with just an ftp *client*. If you want the outside world to have access to telnet into your box, fine – generally it’s a major security risk you can do without.

Also remember that there almost always a dozen or more ways to do any given task in Unix – some of the older packages from a more civil era have been deprecated in favor of more secure ones; a good example of this is the r* packages (remote access). You’re not familiar with which is which so you’re going to have to a little homework and read the docs ;-) For example, if there is a printer physically attached your machine, the printer (lp) daemon should stay. Otherwise, it goes. Print servers may sound harmless, but are potential targets too since they can hold ports open.

Whatever you do do NOT overwrite this list of services by updating it as you remove packages or disable services

Again, from the ‘Security Quick-Start HOWTO for Linux’:

The following is a list of services that should not be run over the Internet. Either disable these (see below), uninstall, or if you really do need these services running locally, make sure they are the current, patched versions and that they are effectively firewalled. And if you don’t have a firewall in place now, turn them off until it is up and verified to be working properly. These are potentially insecure by their very nature, and as such are prime cracker targets.NFS (Network File System) and related services, including nfsd, lockd, mountd, statd, portmapper, etc. NFS is the standard Unix service for sharing file systems across a network. Great system for LAN usage, but dangerous over the Internet. And its completely unnecessary on a stand alone system.

The so-called r* (for “remote”, i.e. Remote SHell) services: rsh, rlogin, rexec, rcp etc. Unnecessary, insecure and potentially dangerous, and better utilities are available if these capabilities are needed. ssh will do everything these command do, and in a much more sane way. See the man pages for each if curious. These will probably show in netstat output without the “r”: rlogin will be just “login”, etc.

telnet server. There is no reason for this anymore. Use sshd instead.

ftp server. There are better, safer ways for most systems to exchange files like scp or via http (see below). ftp is a proper protocol only for someone who is running a dedicated ftp server, and who has the time and skill to keep it buttoned down. For everyone else, it is potentially big trouble.

BIND (named), DNS server package. With some work, this can be done without great risk, but is not necessary in many situations, and requires special handling no matter how you do it. See the sections on Exceptions and special handling for individual applications.

Mail Transport Agent, aka “MTA” (sendmail, exim, postfix, qmail). Most installations on single computers will not really need this. If you are not going to be directly receiving mail from Internet hosts (as a designated MX box), but will rather use the POP server of your ISP, then it is not needed. You may however need this if you are receiving mail directly from other hosts on your LAN, but initially it’s safer to disable this. Later, you can enable it over the local interface once your firewall and access policies have been implemented.

This is not necessarily a definitive list. Just some common services that are sometimes started on default Linux installations. And conversely, this does not imply that other services are inherently safe.

The next step is to find where each server on our kill list is being started. If it is not obvious from the netstat output, use ps, find, grep or locate to find more information from the “Program name” or “PID” info in the last column.

If the service name or port number do not look familiar to you, you might get a real brief explanation in your /etc/services file.

The ultimate objective is not just to stop the service now, as you would for normal maintenance (read ‘change in configuration’), but to make sure it is stopped permanently! So whatever steps you take here, be sure to check after your next reboot.

System services are typically either started by “init” scripts, or by inetd. (The location of the init scripts will vary from distribution to distribution.)

The normal way to stop a service for maintenance is to run (with root privileges):

        /etc/init.d/<$SERVICE_NAME> stop

and restart it with:

        M # /etc/init.d/<$SERVICE_NAME> start

Your distribution will have utilities available for controlling which services are started at various runlevels. Debian based systems have update-rc.d for this, and Redhat based systems have chkconfig. If you are familiar with these tools, do it now, and then check again after the next reboot. If you are not familiar with these tools, see the man pages and learn it now! This is something that you need to know. For Debian (where $SERVICE_NAME is the init script name):

Thus you’ll use this on Red Hat:

        chkconfig $SERVICE_NAME off

or this on Debian:

        update-rc.d -f $SERVICE_NAME remove

A little thought should reveal the obvious simple alternative! Since you don’t need the service you can uninstall the package through the package manager ;-)

Assignments

Terms and Concepts:

Files and Directories

Online:

Copyright © 1997-2003 Henry White. All Rights Reserved.
Reproduction or redistribution without prior written consent is strictly prohibited. Address comments and inquiries to info@basiclinux.net

Sorry, comments for this entry are closed at this time.

Proudly powered by WordPress. Entries (RSS) and Comments (RSS). Silver Light 3-Column theme by Bob, modified by Ms. Crafty.