Computer security is a topic that many people are shockingly
complacent about. Consider that people have computers for which the
administrator or root account doesn't even have a password or people who
run Windows on an unfirewalled internet connection. Here are my little
tips for securing a linux computer to at least some degree against
intrusion. I am writing this based on dealing a gateway server for a small home
network, so keep that in mind. This is NOT an enterprise setup!
Tip 1: GCC Stack Smashing Protector! One of the most common ways for hackers to break into a system is through buffer overflows. Really, really short version: Stack starts at high memory addrs and grows down, static strings & buffers start lower and grow up. Write past the maximum allocated index (int b; a[10]; a[10]=5; //You just overwrote b with 5), and you overwrite previously declared variables. Keep writing and you'll eventually overwrite the return address of the function. If you can overwrite it with the address of malicious code, program gets pwn3ed when the function returns. SSP will substantially negate this by inserting a word between the variables and return address; Before returning, it checks this value. If it's wrong, the program crashes. Therefore, an otherwise successful buffer overflow would crash a system service rather than exploit it.
For instructions on using GCC-SSP, follow the above link. My installation on this server was as follows:
1) Download/unpack GCC-3.4.4; since I'm running an antique version of Mandrake, this was an upgrade as well.
2) Unpack protector-3.4.4-1.tar.gz into gcc-3.4.4/
3) Patch
4) ./configure --prefix=/usr --enable-stack-protector; make; make install (the --enable makes including the stack protector the default)
5) Begin recompiling, reinstalling, and restarting system services.
Like any other piece of security software, this is not a silver bullet. It's just another layer that makes attempts to intrude your system via buffer overflows a lot more difficult. It is absolutely, positively NOT an excuse to leave ports open or run known-vulnerable software or do other stupid things.
Tip 2: On install, set default security level
to 'high'
This will help enormously by doing many of the things discussed below
automatically (logging, auto security checks, etc).
Tip 3: Strong Passwords
The best defense against unauthorized access is still one of the
oldest. Using a password that cannot easily be guessed or decrypted
will go miles to stopping crackers. Don't choose something obvious,
like your name, car brand, or a color. And don't enter less than 6 or
7 characters. Put two or three odd, unrelated words together, for example
"heaterbackdoorcathode". Then mix the words with upper and lower case
letters: "HeateRBackdooRCathodE". Finally, throw in a number or two
for good measure, "1HeateR2BackdooR3CathodE", or (if you're so
inclined) rewrite the password in leet-speak,
"H3473RB4ckd00RC47h0d3". Such a password cannot be broken by a brute
force or dictionary attack, because it is far too long (Decrypting it
would take centuries). It will not be guessed because with a quarter
million words in the Oxford dictionary, 3 random words strung together
makes for roughly 12.5 quadrillion combinations.
Tip 4: Don't install unneeded software
This is a server you are setting up. You don't need KDE, you don't
need OpenOffice. Unless you plan to serve content up for a personal
website, you don't need ftpd or httpd either. Unless you want remote
access, you don't need sshd. All complex software (and even some
not-so-complex software) has bugs and
security holes. The more software you install, the more likely you are
to be opening yourself up to an attack. If all you want is a router to
the internet, you don't need much more than modem connectivity
software, a firewall, and routing instructions. In Mandrake, when you
install you get a nice GUI that offers to let you choose individual
packages. Do so. Then explicitly deselect everything from 'office' and 'games'
and choose not to install KDE or Gnome (There goes a gigabyte of
binaries). Then go through and select the following: xpdf (PDF
reader), apache (if you want to serve a web page), proftpd (if you
want to offer FTP access), ssh (if you want remote access), the
lightweight window managers (GUI without the desktop), shorewall
(firewall), cups (if you also want a printer server), lynx (console
internet browser), as well netstat and dig. (geeks, e-mail me with
other essentials)
Tip 5: Daily security checks
Daily security checks won't really help stop an intruder, but they
will tell you want damage has been done. Mandrake Linux's drakconf
gives you a nice GUI to configure all manner of daily security
checks (Though it's really just a frontend to a series of crontab
jobs). For example, daily checksumming of all system binaries, network
card promiscuity checks, watching for modified config files, and
more. Even if someone does break in, you might have some hope of
undoing any damage that was done.
The first time I tried ethereal, I found out that the promiscuity
check works - all my terminals immediately spat out "WARNING:
INTERFACE IN PROMISCUOUS MODE" in big, red letters.
Tip 6: Extensive system logging
Like daily checks, extensive system logging is great tool to see if
someone has attacked your system and to see what damage may have been
done. If you're using Mandrake, use Drakconf and tell the system to
log EVERYTHING.
Tip 7: Firewall
A firewall is absolutely essential to handle the crapflood of garbage
that will hit your server's internet side. Unless you're serious, you
probably only need a handful of ports open to the internet: 80 (http),
20/21 (ftp), 22 (ssh). Instruct the server to sliently drop any packets
inbound to a closed port. To do this on Mandrake, start drakconf and
then go to Network&Internet -> Internet Connection Sharing ->
enable and follow the dialogs. After, install the package 'shorewall' if it's not already
installed. This will provide you with a default setup that provides
masqueraded internet access to everything on one chosen ethernet card
through another. The next step is to rewrite /etc/shorewall/rules to
lock the system down. Open it with your editor of choice and read
through the mini-tutorial on top. If the system is thus far set up
with a wise default policy (deny unless explcitly allowed), you will
need to add ACCEPT entries for net to firewall, firewall to net, local
to firewall, and firewall to local. Because we are using IP
masquerading, the outside is NOT allowed direct access to the lan,
period. Now were are at a decision gate: Is this a server serving to
the internet, or only a gateway? If it's a gateway only, do not allow
any connections from net to fw: Noone has any businness accessing the
server remotely. You will want to allow common programs bidirectional
access between the firewall and local: ports 80, 21, 22, 443 and 631
are a start. You will also want to allow those ports outgoing access
to the net in any case. If the system is also a server, you will need
to allow incoming connections (ALLOW net fw ...). Choose wisely, for
that will determine what remote users can access: you only need port
80 on TCP for apache.
Tip 6: Intrustion Detection Programs
There are many intrusion detection programs out there that will help
either thwart attackers or catch whatever they may have
done. (Google for any of these) chkrootkit, as the name implies, runs
a multitude of tests for rootkits that may have been used on your
system (then again, if the logs suddenly stop growing, that's a
giveaway too...). It's a good idea to pull it down fresh and run it
once and a while. rkdet is another good program that runs continuously
and watches for signs of intrustion. Most usefully, if someone tries
to kill it, it can be told to stop the network or even shut down the
machine. There is also Tripwire, which is a suite of programs that
lock down the system, check all binaries on a regular basis, and
more. Bastille Linux is a series of scripts that help harden a
system. Do some research on all of them and decide what's best for you.
Tip 7: De-Rooting
One thing you will notice in a lot of default system installations is
that many files that have no business being owned by root or in root's
group (apache files, ftp files, etc) are in fact owned by
root:root. To find out, go to the directory in question and, in your
shell, enter 'ls -la' to find out the owner of every file in the
directory. In my case, everything in /var/www/html/ and /var/www/ftp/
was root:root. The command to fix that is almost as short at the
command to find out: Go to the root of the directory to be fixed, and
enter 'chown -R user:group ./', changing user and group
to who is to own the file. Beware, these extremely powerful programs
often lack safety locks and will do whatever you tell them to do
blindly - don't accidently replace ./ with / or you will never get the
system fixed.
Another common default is for many of the system's most powerful
programs (httpd, ftpd, cupsd, sshd, etc) to run under user root. The
danger of this should be obvious: If a cracker ever hacks into a
program with the permissions of the user running the
program, you're screwed. Therefore, you should create non-priveleged
users/groups to run these services under. Mandrake Linux, for example,
comes with a user 'apache' for httpd. Create similar users for your
ftp, ssh, cups, and other services as appropriate. The next trick is
getting the services to actually run under the new users - not as easy
as it sounds.
First (as root), try starting the server with 'sudo -u [username]
[command]'. Most likely you will get some error stating that it cannot
open log files. Change the logfile's owner to the new user, and try
again. In my case, Apache threw an error stating it couldn't write to
/var/run/. Since a multitude of programs need write access to this
directory, the solution is not as simple. Create a group (call it
'varrun') and make the affected service-users part of it (eg make
apache & co part of the group varrun). Then change the group of
/var/run to group varrun with 'chmod -R :varrun /var/run/'. When you
try starting apache this time, it will give no obvious signs of
failure but 'ps aux' will not show any httpd processes running. If you
look at the Apache logfile, it will say that it couldn't bind to port
80: Only priveleged root programs can open ports below 1024.
The solution to this is routing magic. If you use Mandrake, you can
edit /etc/shorewall/rules. This file controls where your system routes
traffic. You will need to add rules like these:
REDIRECT net 6666 tcp 80
REDIRECT fw 80 tcp 6666
These will redirect incoming http requests to port 6666, and httd
packets from the server (on port 6666) to port 80. At this point, you
also need to close off port 80 and open 6666. Then edit your apache
configuration file (probably /etc/httpd/conf/httpd.conf) to have it listen on port 6666 instead of 80, restart
your firewall (On Mandrake, 'service shorewall restart'), and try
starting apache again. 'ps aux' should show processes named httpd
running under user apache, and 'netstat -peena' should show Apache
listening on port 6666. Now repeat for other important services!
Tip 8: Watch for anomalies
This is not so much a tip as one of the bases of computer security -
things should happen in a certain way. You know how it is. You just keep doing what it
looks like you're supposed to be doing, no matter how crazy it
seems. If things stop happening in this routine, then you should
figure that there's something screwy going on. Either the system has
been broken into and corrupted in some way, or a process has crashed
and interrupted the normal flow of data. Both of these are
bad!
For example, I noticed earlier today that Apache has been failing to
log all requests to access_log. It's 2/28, and the log stopped at
2/22. Now that this happened once, I know to run a check every day to
confirm that all the logs are growing - I may not get *much* traffic,
but I don't go more than a day without anyone hitting my site or
trying to break in via SSH.
So... have scripts that confirm that the logs grow so you can catch
attempts to disable system accounting. Check for changes in running
processes - there should be some differences between checks, but
nothing that you didn't start.
Understand that this page is a work in progress. If you have
additional suggestions, send them to ejkeever AT nerdshack DOT com.