Security Quick−Start HOWTO for Linux

expr:id='"post-" + data:post.id' >

The Optimum Configuration
Ideally, we would want one computer as a dedicated firewall and router. This would be a bare bones
installation, with no servers running, and only the required services and components installed. The rest of our
systems would connect via this dedicated router/firewall system. If we wanted publicly accessible servers
(web, mail, etc), these would be in a "DMZ" (De−militarized Zone). The router/firewall allows connections


from outside to whatever services are running in the DMZ by "forwarding" these requests, but it is segregated
from the rest of the internal network (aka LAN) otherwise. This leaves the rest of the internal network in
fairly secure isolation, and relative safety. The "danger zone" is confined to the DMZ.
But not everyone has the hardware to dedicate to this kind of installation. This would require a minimum of
two computers. Or three, if you would be running any publicly available servers (not a good idea initially). Or
maybe you are just new to Linux, and don't know your way around well enough yet. So if we can't do the
ideal installation, we will do the next best thing.
2.2. Before We Start
Before we get to the actual configuration sections, a couple of notes.
First, one of the interesting aspects of Linux, is the different distributions like Caldera, Red Hat, SuSE, and
Debian. While these are all "Linux", and may share certain features, there is surely some differences as to
what utilities they may install as defaults. Most Linux distributions will write their own system configuration
tools as well. And with Linux, there is always more than one way to skin a cat. But for the purposes of our
discussion, we will have to use as generic set of tools as we can. Unfortunately, GUI tools don't lend
themselves to this type of documentation. We will be using text based, command line tools for the most part.
If you are familiar with your distribution's utilities, feel free to substitute those in appropriate places. And if
not, you should learn them or suitable alternatives.
The next several sections have been written such that you can perform the recommended procedures as you
read along. This is the "Quick Start" in the document title!
To get ready, what you will need for the configuration sections below:
A text editor. There are many available. If you use a file manager application , it probably has a built
in editor. This will be fine. pico and mcedit are two relatively easy to use editors if you don't already
have a favorite. There is a quick guide to Text editors in the Appendix that might help you get
started. It is always a good idea to make a back up copy, before editing system configuration files.
·
For non−GUI editors and some of the commands, you will also need a terminal window opened.
xterm, rxvt, and gnome−terminal all will work, as well as others.
·
You should also be familiar with your distribution's method of stopping services from running on
each boot. Also, how they install (and uninstall) packages (rpm, deb, etc). And where to find the
updates for your release. This information is available in your release's documentation, or on your
vendor's web site.
·
We'll be using a hypothetical system here for examples with the hostname "bigcat". Bigcat is a Linux desktop
with a fresh install of the latest/greatest Linux distro running. Bigcat has a full−time, direct Internet
connection. Even if your installation is not so "fresh", don't be deterred. Better late than never.
In this section we will see which services are running on our freshly installed system, decide which we really
need, and do away with the rest. If you are not familiar with how servers and TCP connections work, you
may want to read the section on servers and ports in the Appendix first. If not familiar with the netstat utility,
you may want to read a quick overview of it beforehand. There is also a section in the Appendix on ports, and
corresponding services. You may want to look that over too.
Our goal is to turn off as many services as possible. If we can turn them all off, or at least off to outside
connections, so much the better. Some rules of thumb we will use to guide us:
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.
·
3.1. System Audit
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.
Unfortunately, there is no such things as a standard Linux installation. The wide variety of servers available,
coupled with each particular distribution's installation options, make providing a ready made list impossible.
The best that can be done is show you how to list all running services, and point you in the right general
direction.
Now open an xterm, and su to root. You'll need to widen the window wide so the lines do not wrap. Use this
command: netstat −tap |grep LISTEN. This will give us a list of all currently running servers as
indicated by the keyword LISTEN, along with the "PID" and "Program Name" that started each particular
service.
# netstat −tap |grep LISTEN
*:exec *:* LISTEN 988/inetd
*:login *:* LISTEN 988/inetd
*:shell *:* LISTEN 988/inetd
*:printer *:* LISTEN 988/inetd
*:time *:* LISTEN 988/inetd
*:x11 *:* LISTEN 1462/X
*:http *:* LISTEN 1078/httpd
bigcat:domain *:* LISTEN 956/named
bigcat:domain *:* LISTEN 956/named
*:ssh *:* LISTEN 972/sshd
*:auth *:* LISTEN 388/in.identd
*:telnet *:* LISTEN 988/inetd
*:finger *:* LISTEN 988/inetd
*:sunrpc *:* LISTEN 1290/portmap
3. Step 1: Which services do we really need?
*:ftp *:* LISTEN 988/inetd
*:smtp *:* LISTEN 1738/sendmail: accepting connections
*:1694 *:* LISTEN 1319/rpc.mountd
*:netbios−ssn *:* LISTEN 422/smbd
Note the first three columns are cropped above for readability. If your list is as long as the example, you have
some work ahead of you! It is highly unlikely that you really need anywhere near this number of servers
running.
Please be aware that the example above is just one of many, many possible system configurations. Yours
probably does look very different.
You don't understand what any of this is telling you? Hopefully then, you've read the netstat tutorial in the
Appendix, and understand how it works. Understanding exactly what each server is in the above example,
and what it does, is beyond the scope of this document. You will have to check your system's documentation
(e.g. Installation Guide, man pages, etc) if that service is important to you. For example, does "exec", "login",
and "shell" sound important? Yes, but these are not what they may sound like. They are actually rexec,
rlogin, and rsh, the "r" (for remote) commands. These are antiquated, unnecessary, and in fact, are very
dangerous if exposed to the Internet.
Let's make a few quick assumptions about what is necessary and unnecessary, and therefore what goes and
what stays on bigcat. Since we are running a desktop on bigcat, X11 of course needs to stay. If bigcat were a
dedicated server of some kind, then X11 would be unnecessary. If there is a printer physically attached, 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. If we plan on logging in to bigcat from other hosts, sshd (Secure
SHell Daemon) would be necessary. If we have Microsoft hosts on our LAN, we probably want Samba, so
smbd should stay. Otherwise, it is completely unnecessary. Everything else in this example is optional and
not required for a normally functioning system, and should probably go. See anything that you don't
recognize? Not sure about? It goes!
To sum up: since bigcat is a desktop with a printer attached, we will need "x11", "printer". bigcat is on a LAN
with MS hosts, and shares files and printing with them, so "netbios−ssn" (smbd) is desired. We will also need
"ssh" so we can login from other machines. Everything else is unnecessary for this particular case.
Nervous about this? If you want, you can make notes of any changes you make or save the list of servers you
got from netstat, with this command: netstat −tap |grep LISTEN > ~/services.lst. That
will save it your home directory with the name of "services.lst" for future reference.
This is to not say that the ones we have decided to keep are inherently safe. Just that we probably need these.
So we will have to deal with these via firewalling or other means (addressed below).
It is worth noting that the telnet and ftp daemons in the above example are servers, aka "listeners". These
accept incoming connections to you. You do not need, or want, these just to use ftp or telnet clients. For
instance, you can download files from an FTP site with just an ftp client. Running an ftp server on your end
is not required at all, and has serious security implications.
There may be individual situations where it is desirable to make exceptions to the conclusions reached above.