SYLS101: Securing Your Linux System 101
Sections:
Physical Security
System Security
User Security
Network Security
Mental Security
Instructor: John E. Jasen
E-mail: jjasen1@umbc.edu
Class URL: http://www.gl.umbc.edu/~jjasen1/unix/linux.html
Class Schedule: Available
Here
Previous Version of Syllabus: Old Linux
Security Guide
Before we begin, let me make perfectly clear that no level of security is
guaranteed to keep a determined hacker out, except for grinding the
computer into a micro-fine dust, mixing it into bricks and scattering them
to the four corners of the planet. However, there are those who claim that
this method affects useability and that we must compromise.
Seriously, systems security involves trying to determine the level of risk
and trying to determine what to expend countering, controlling and
eliminating that risk. This cannot be done remotely, nor by some
BogoMatic mathematical formula. It is determined on a case by case basic
by the systems administrator.
That said, consider the following aspects of security.
Physical Security
Physical security is the most important aspect of of securing your system.
Once "the bad guy (TBG)" sits down in front of it, only time and TBG's
mind limit what he can do. This cannot be emphasized
enough. TBG could boot from CD or floppy, accessing the filesystem through
that method. TBG could possibly wipe BIOS settings, eliminating any
obstacles presented by a boot password. TBG could remove the hard drive
and mount it on another system, circumventing the BIOS and the root
password. Or, at last resort, TBG could remove whatever he wants from your
system [ram, hard drive, cd-rom, network card, etc] and go home.
So, make sure you have some way of controlling access to your machine. At
home, make sure your doors and windows are secure. [duh!] At work, make
sure that the offices are locked tight at night, hopefully there are
guards or security equipment present, and hopefully strangers wandering
about during the day are stopped and questioned. Security doors, keyvards,
locking office doors and other such things are always a good measure, as
well.
If for some reason, these methods cannot be used, consider using such
things as cable locks, locking screws and bolts for the computer cases,
BIOS passwords to prevent access, denying floppy or cd-rom booting, etc.
However, such measures are 'delaying tactics', much like The Club [tm] is
to a car thief -- it either deters TBG from attacking the system in that
manner, or it delays him, so that hopefully a "good guy" will be able to
catch him and intervene.
Systems Security
Installation
Examining inetd.conf
Examining /etc/rc.d/
Examining ps aux
Installing Patches
You should be thinking about your systems security even before you put in
your Linux floppies or CD, meaning that you should have a grasp of what
packages will need to be installed, what daemons you will be running, what
kind of network connections you will have, what services you will
require from other machines, whether or not you need a firewall, and so
forth.
Installation:
I prefer installing from CD and/or floppies, without an initial network
connection. Could be paranoia, but that's in the job description. I
believe that this offers protection to a machine, while it is still in a
fragile state [without patches applied, without TCP_wrappers installed,
without a root password].
Before I begin the installation, I record any network information I will
need, namely: IP address, hostname, gateway, DNS servers, NFS server and
directories required, NIS/YP server, as well as a list of packages to
install/not to install. From there, I boot the machine and begin the
installation process.
During the installation process, I always weed out such things as: NFS
server, NIS server, mail server, http server, Samba, Netatalk, ftp server,
foo server or any other server I won't use or have no idea what it does.
WARNING: I, purportedly, know what I am doing and can do this without fear
and trepidation. For the average user, I recommend not installing
anything that you know you won't be using, such as:
- NFS server -- unless you will be exporting filesystems
- NIS/YP server -- unless you know what it is and will use it. [It's a
standard method for sharing account information across machines. Bad, bad
security mojo.]
- mail server -- unless you will actually receive mail on this machine,
feel free to ditch it.
- http server -- unless you will be hosting your own web site
- ftp server -- unless there is really a need for it.
- Samba -- unless you will be serving or connecting to Wintel
machines.
- Netatalk -- unless you will be serving Apple Macintoshes
I also don't install games, optional editing packages and a lot of
the other 'add-ons', but this is more towards individual taste.
During the installation process, you must select a root password. Pick a
nice, complicated one that you can remember!. Not recommended:
your social security number, phone number, IP address, pet names, curse
words, the name of the machine, 'password', 'linux', words found in a
dictionary. Recommended: 8 characters or more [if supported], mixture of
upper and lowercase letters, numbers and special characters. 'fluffy' is
bad. 'Ap*1=-.v' is better, but now that it's published, is unusable. NOTE:
With the availability of 'crack' and other such password-cracking
programs, you can safely assume that your password will be discovered,
given sufficient time and processing power. Change passwords often!
Examining inetd.conf
After installing the system and rebooting, it is time to examine the
/etc/inetd.conf file. The average file looks something like this:
#
# inetd.conf This file describes the services that will be available
# through the INETD TCP/IP super server. To re-configure
# the running INETD process, edit this file, then send the
# INETD process a SIGHUP signal.
#
# Version: @(#)/etc/inetd.conf 3.10 05/27/93
#
# Authors: Original taken from BSD UNIX 4.3/TAHOE.
# Fred N. van Kempen,
#
# Modified for Debian Linux by Ian A. Murdock
#
# Modified for RHS Linux by Marc Ewing
#
#
#
# Echo, discard, daytime, and chargen are used primarily for testing.
#
# To re-read this file after changes, just do a 'killall -HUP inetd'
#
#echo stream tcp nowait root internal
#echo dgram udp wait root internal
#discard stream tcp nowait root internal
#discard dgram udp wait root internal
#daytime stream tcp nowait root internal
#daytime dgram udp wait root internal
#chargen stream tcp nowait root internal
#chargen dgram udp wait root internal
#
# These are standard services.
#
ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd -l -a
telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
gopher stream tcp nowait root /usr/sbin/tcpd gn
# do not uncomment smtp unless you *really* know what you are doing.
# smtp is handled by the sendmail daemon now, not smtpd. It does NOT
# run from here, it is started at boot time from /etc/rc.d/rc#.d.
#smtp stream tcp nowait root /usr/bin/smtpd smtpd
#nntp stream tcp nowait root /usr/sbin/tcpd in.nntpd
#
# Shell, login, exec and talk are BSD protocols.
#
shell stream tcp nowait root /usr/sbin/tcpd in.rshd
login stream tcp nowait root /usr/sbin/tcpd in.rlogind
#exec stream tcp nowait root /usr/sbin/tcpd in.rexecd
talk dgram udp wait root /usr/sbin/tcpd in.talkd
ntalk dgram udp wait root /usr/sbin/tcpd in.ntalkd
dtalk stream tcp waut nobody /usr/sbin/tcpd in.dtalkd
#
# Pop and imap mail services et al
#
pop-2 stream tcp nowait root /usr/sbin/tcpd ipop2d
pop-3 stream tcp nowait root /usr/sbin/tcpd ipop3d
imap stream tcp nowait root /usr/sbin/tcpd imapd
#
# The Internet UUCP service.
#
#uucp stream tcp nowait uucp /usr/sbin/tcpd /usr/lib/uucp/uucico -l
#
# Tftp service is provided primarily for booting. Most sites
# run this only on machines acting as "boot servers." Do not uncomment
# this unless you *need* it.
#
#tftp dgram udp wait root /usr/sbin/tcpd in.tftpd
#bootps dgram udp wait root /usr/sbin/tcpd bootpd
#
# Finger, systat and netstat give out user information which may be
# valuable to potential "system crackers." Many sites choose to disable
# some or all of these services to improve security.
#
# cfinger is for GNU finger, which is currently not in use in RHS Linux
#
finger stream tcp nowait root /usr/sbin/tcpd in.fingerd
#cfinger stream tcp nowait root /usr/sbin/tcpd in.cfingerd
#systat stream tcp nowait guest /usr/sbin/tcpd /bin/ps -auwwx
#netstat stream tcp nowait guest /usr/sbin/tcpd /bin/netstat -f inet
#
# Time service is used for clock syncronization.
#
time stream tcp nowait nobody /usr/sbin/tcpd in.timed
time dgram udp wait nobody /usr/sbin/tcpd in.timed
#
# Authentication
#
auth stream tcp nowait nobody /usr/sbin/in.identd in.identd -l -e -o
#
# End of inetd.conf
This has some problems, and some good things. One good thing, right off
the bat, is TCP_wrappers. Another is identd. Let's review some of the
good, the bad and the ugly:
ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd -l -a
telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
gopher stream tcp nowait root /usr/sbin/tcpd gn
Personally, I hate telnet and ftp, having found true
enlightenment in SSH. However, if
you won't be accessing your home machine remotely, you don't need telnet
or ftp running at all! Comment them out.
# Shell, login, exec and talk are BSD protocols.
#
shell stream tcp nowait root /usr/sbin/tcpd in.rshd
login stream tcp nowait root /usr/sbin/tcpd in.rlogind
#exec stream tcp nowait root /usr/sbin/tcpd in.rexecd
UNIX r* services are unconditionally bad news, and entirely too easy to
abuse. Even if you remotely feel that you have a use for r* services,
reconsider. If you will be accessing this machine over the network, again,
SSH will server your needs more securely. If you won't be accessing this
machine remotely, comment them out.
#
talk dgram udp wait root /usr/sbin/tcpd in.talkd
ntalk dgram udp wait root /usr/sbin/tcpd in.ntalkd
dtalk stream tcp waut nobody /usr/sbin/tcpd in.dtalkd
#
Again, the standard prohibitions regarding "Am I going to use this?"
apply. I prefer not to, so these quickly go into the can.
# Pop and imap mail services et al
#
pop-2 stream tcp nowait root /usr/sbin/tcpd ipop2d
pop-3 stream tcp nowait root /usr/sbin/tcpd ipop3d
imap stream tcp nowait root /usr/sbin/tcpd imapd
Use At Your Own Risk. You Have Been Warned. Other Scary Warnings.
Security-wise, POP is an accident that already happened. [telnet to port
110 on your pop server one day, type 'username myusername', then when it
prompts you, type 'pass mypassword'. Scared yet?] IMAP is slightly more
sane, although it does seem to suffer from a security bug of the week.
finger stream tcp nowait root /usr/sbin/tcpd in.fingerd
Ditch it. RedHat has this to say:
# Finger, systat and netstat give out user information which may be
# valuable to potential "system crackers." Many sites choose to disable
# some or all of these services to improve security.
If you really want to use finger, replace it with safe_finger
from the TCP_wrappers package.
# Time service is used for clock syncronization.
#
time stream tcp nowait nobody /usr/sbin/tcpd in.timed
time dgram udp wait nobody /usr/sbin/tcpd in.timed
Again, the standard prohibitions regarding "Am I going to use this?"
apply. I've used ntp [network time protocol] services before, and so
am indifferent.
# Authentication
#
auth stream tcp nowait nobody /usr/sbin/in.identd in.identd -l -e -o
Actually, even if you just dial in from home, I generally recommend having
some version of identd running. Many systems interrogate this service to
verify information when you telnet/ftp/smtp/ssh/etc, which can be a good
thing if there is an 'incident'. On the other hand, remote systems try to
collect your username if you telnet/ftp/smtp/ssh/etc.
Examining /etc/rc.d/
Under RedHat, /etc/rc.d is broken into numerous subdirectories:
init.d and rc0.d through rc6.d. The 0-6 corresponds to the runlevel
specified in /etc/inittab [usually 3]. cd to the appropriate directory,
and do an 'ls'. You should get something that looks like:
X K08autofs
* K10named
* K15httpd
* K15postgresql
* K20bootparamd
* K20nfs
* K20rusersd
* K20rwalld
* K20rwhod
* K25innd
* K25news
X K28amd
X K30mcserv
X K30sendmail
* K30ypbind
* K33yppasswd
* K35dhcpd
* K35smb
* K35ypserv
* K40snmpd
K55routed
X K60mars-nwe
X qK75gated
* K95nfsfs
S01kerneld
S10network
S20random
S30syslog
X S40atd
X S40crond
X S40portmap
X S45pcmcia
X S50inet -- if you run absolutely nothing out of inetd, you can kill this.
X S60lpd
S75keytable
S85gpm
S85sound
S99local
The '*'-ed ones can probably be removed without reservation, unless you
know what you are doing. The 'X'-ed ones, you should probably check to see
what they do, and decide from there. However, don't just take my word for
it -- if you don't recognize, investigate. If you don't want, remove.
Examining ps aux
Finally, wrap up systems security by bringing the machine down to
single-user mode and back up to initlevel 3, then running 'ps aux' and
examining the output carefully. Any process running that you don't
understand or recognize should be thoroughly investigated. If you don't
want it running, you have to find out where it starts from, comment it out
and kill the service.
Installing Patches
Patches for Redhat 5.0 can be found at
ftp://ftp.redhat.com/pub/redhat/updates/5.0/. Install these, and check
back regularly for new contributions.
User Security
Shadow Password Package
User Accounts and Passwords
Using the Root Account
UNIX is a multi-user system, where there are two types of account: users
and superusers. The difference should be obvious -- superusers can do
more. This is not necessarily a benefit.
Shadow Password Package
Take your web browser, and go to http://sunsite.unc.edu/LDP/HOWTO/Shadow-Password-HOWTO.html.
There, you will find extensive documentation on Shadow Password Files, as
well as links to source code. You really want to install this if you ever
attach to a network, share your system with friends, etc. PROTECT
THE PASSWORDS! Keep the shadow file with minimal permissions --
400 works really well.
User Accounts and Passwords
UNIX restricts and allows access to files and devices, based on user ID
and group ID. An account with user or group ID of "0" has access to
everything and can override all permissions. Other user or group IDs only
have the access allowed to them, or the access allowed to the 'world'.
Make sure that you use user and group IDs to tightly regulate access
between different users and user groups.
Passwords need to be long, difficult to crack and changed regularly.
- By long, the UNIX standard is 8 characters. Use more, if your
OS will allow it.
- By difficult to crack, don't use easy to guess
words,
names and numbers. It is better to use a random combination of upper-case
and lower-case letters, numbers and special characters. 'Fluffy' is not a
good password. 'Ap*1=-.v' would be a good password, except crackers have a
habit of adding published examples to their dictionary attacks.
- Change
your passwords often -- Cracking programs will be able to recover a
password, given enough time and effort. This is not an "if." This is a
"when."
Using the Root Account
Root-level (user ID "0" or group ID "0") accounts are very powerful, and
prone to abuse. Thus, root-level power should be used infrequently, only
when necessary and with extreme care. Examples of when to use root:
systems configuration, installing a daemon that uses a priveledged port,
creating and deleting users, installing software for multiple users,
etc. Examples of when not to use root: reading news, sending e-mail,
browsing the web, playing games, writing a term paper, etc.
For root level tasks, familiarize yourself with 'su'. Consider using
'sudo' to aid in delegating root tasks, such as shutting down the system,
killing errant print jobs, etc.
Network Security
Examining TCP_Wrappers
Examining identd
Examining syslog
Examining SSH
ipfw: Packet Filtering for Linux
If you're going to be attaching to a network through a network card or
ppp, you should probably examine SSH and identd. If you will be opening
your machine up for remote access, you will want to take a closer look at
TCP_Wrappers and the SSH daemon. If you will be connecting a network to
the Internet, you may wish to take a peek at ipfw, a firewall solution for
linux.
Examining TCP_Wrappers
If you are running a current RedHat linux, TCP_wrappers have already been
provided for you. If you aren't running RedHat, TCP_Wrappers and other
tools can be had by going to ftp://ftp.cert.org/pub/tools/.
The inetd service runs, listening to all the ports specified in
/etc/inetd.conf. When it detects a connection to one of the ports, it
executes the program that corresponds to it. The tcpd program acts as a
proxy for those programs, checking its rulesets (usually in
/etc/hosts.allow and /etc/hosts.deny) to ensure that the requesting system
is allowed access. If the incoming request isn't allowed, the request is
dropped. If it is allowed, tcpd then allows the normal program to execute
and hande the request.
The tcpd package is good for regulating access -- to only your roommates,
for example. Or, perhaps, to completely deny access to someone who is
abusing your system.
Examining identd
The identd service runs on port 113. It allows remote systems to
interrogate yours, to try and find out who is trying to access them.
Generally, it does not do much to increase your security and you are
giving information away, but it is 'polite' and will give you a starting
point if hostile systems administrators call about a security incident. I
generally use pidentd, which is findable at ftp://ftp.uu.net/networking/ident/servers/.
Examining syslog
While identd is good for helping remote sites figure out who did what,
syslog is the first line of defense for figuring out who did what to you.
It is configurable through /etc/syslog.conf, and runs as 'syslogd'. How
much you want to keep in a logfile depends on your paranoia.
Most log files can be found in /var/log or /var/adm, depending on how you
configure things.
Examining SSH
SSH. Look at it. Install it. Learn it. Love it. It's that simple. SSH is a
drop-in, encrypted replacement for the r* tools. It has its own daemon,
which can be run 'stand alone' or from inetd [not recommended].
SSH can be compiled with support for syslogging, TCP_Wrappers, replacing
the r* tools completely, support for X, port redirection, login completion
-- did someone ask for a Swiss Army Knife?
Source can be had: http://www.cs.hut.fi/ssh.
ipfw: Packet Filtering for Linux
This, actually, is something that I've never mucked around with under
Linux. However, be forewarned, firewalls require a lot of care and
feeding, and you will have to dedicate a machine to this purpose. An
intoductory FAQ can be had at: http://www.redhat.com/linux-info/ldp/HOWTO/Firewall-HOWTO.html.
Mental Security
FAQs and Information
Mailing Lists
Recommended USENET News Groups
Patches
Tools
Maintenance
Think securely. This means, take the time to browse the mailing lists,
USENET groups, security FAQs, log files, patch directories and the results
of "attacks" you run against your system.
FAQs and Information
Mailing Lists
- BugTraq:
Subscribe to BugTraq by sending a mail message to: listserv@netspace.org with the BODY of the
message reading
SUBSCRIBE bugtraq firstname lastname
Substitute your name where appropriate.
- Linux-Announce:
Subscribe to Linux-Announce by sending e-mail to: linux-announce-request@redhat.com
with the word 'subscribe' as the SUBJECT of the message.
Recommended USENET News Groups
- comp.security.unix
- comp.security.misc
- comp.security.announce
- comp.unix.admin
Patches
Tools
Maintenance
Security is not something that is done once, then forever is complete.
Being secure means being constantly on guard, trying new tools, reading
the logfiles, running portscans against your machine, running crack on the
passwords, goint to Rootshell and
trying out exploit code, keeping up on the information, applying the
patches as they come out, investigating anything 'strange' and generally
BEING ALERT.