|
|
The Answer Guy 37: Simple Security Tips
"The Linux Gazette...making Linux just a little more fun!"
 Simple Security Tips
From John Radcliffe on Mon, 04 Jan 1999
One thing that might make Linux more attractive for the Desktop
market is some clarification of security issues. While I don't
consider myself an expert on desktop computer matters, people keep
coming to me for assistance and advice so I must not be completely
obtuse on the subject. Still I do not understand all that I read
regarding Linux security.
I agree. I'll be giving a talk on this subject:
13 Tips for Securing your Linux System from Common Threats
... at the Silicon Valley Linux Users Group
(http://www.svlug.org) this week.
If I get my act together I'll set up some web pages
with some version of the content of my slides and
notes at http://www.starshine.org/linux/security/tips.html
(I've put a placeholder there until my notes are
presentable).
If you're in the Silicon Valley (San Jose, California)
area --- come to the meeting.
I would like to put together a simplified security guide for
people who are not providing internet content or services, but
wish to use a web browser from the Linux desktop. But I do not
want to give bad advice through my lack of understanding.
The best advice is to disable all local services
(deactivate inetd, sendmail, and the local httpd)
Do a 'netstat -na' command to see what ports are "active"
on your system. If it reports anything in "listen" mode
on any port --- you've still got some networking service
listening.
It's a bit more complicated than that. I'll go into
more detail a bit later.
One thing which I do not understand is how crackers gain access
through SUID root programs. From a look at 'rootshell' and
'bugtraq' there seem to be innumerable ways to do this, and new
ones seem to be found daily. Apparently even 'secure shell' isn't
immune to exploitation. Rather than have the average desktop user
try to keep current with all of these, would it be safe to say
that if Telnet, Shell, and Login are commented out in /etc/inetd
(and file permissions are correct as per the Linux Security HOWTO)
that the desktop users machine would be safe from this type of
attack?
To exploit a bug in an SUID program (whether it's owned/run
as 'root' or any other user) the attacker must first
gain "shell" access or must otherwise trick some service
into executing the program. It must also be able to
supply that SUID program with some sort of degenerate
data (usually input or environment values --- though
some exploits occur through signals, shell aliases,
etc).
If you are assuming a desktop system which is "owned by"
the operator --- that is that you expect any person at
the console to have "root" access --- then your primary
threat vectors are network/remote exploits (disable
services) and trojan horses (or --- very rarely under
Linux --- viruses).
In other words if I can already attain root by rebooting
into single user mode, I don't need to exploit a bug in some
SUID binary to 'get root.' If I get to a shell prompt
remotely --- you've already lost (there are too many
opportunities for me to violate too many security policies
--- so you focus, in the common case for client workstations
should be on prevent remote access to shell services and
remote execution of any code.
You are correct regarding 'secure shell' or 'ssh' as it's
more commonly known. This does nothing to protect a system
from SUID bugs nor from trojan horses. That's not its
purpose. The purpose of ssh is to allow secure remote
access --- which is very difficult to spoof, hijack, sniff,
or otherwise compromise.
ssh is a cryptographically strong version of 'rsh' 'rlogin'
and 'rcp'. It uses RSA public key cryptography to perform
mutual host authentication, and to establish a one-time
session key. It then uses IDEA or some similar (user/admin
configurable) symmetrical key encryption to protect the
contents of the session from sniffing. Since the potential
attacker should not be able to properly encrypt any packets
(no access to the session key) --- this also prevent the
attacker from injecting any forged packets into the
communications stream (a process referred to as "session
hijacking").
There are a number of other encryption packages available
for Linux. They operate over various protocols, serving
different needs and providing different features and
applications. For example SSL is a set of protocols that
are most commonly used for securing web pages and
communications between browsers and web servers (primarily
submission of form's data to CGI scripts). SSL is used
because it is commonly built into the most popular web
browsers. There is a suite of other SSL applications such
as ssltelnet and sslftp (these are client/server packages
--- so your intended host sites must install the appropriate
daemons before your clients will be able to use these
protocols).
I did post a rather lengthy message on free crypto tools
recently --- giving a pretty large list of the tools, though
almost no "HOWTO" coverage of them. The idea was to provide
lots of pointers to the web sites where more info on these
tools (and the tools themselves) could be found.
Naturally, due to the continuing disgrace of U.S. federal
government regulations --- which consititute an obvious and
despicable subversion of our Bill of Rights --- we are
unable to freely provide our crypto software to the world at
large. So free nations elsewhere are required to provide
these. (Please write to your congress critter to let them
know that this is a major votiing issue for all software
enthusiasts --- and follow up by endorsing candidates to
recognize the freedom of speech extends to the expression of
practical mathematics through the art of computer
programming.)
I normally avoid politics in my column. However, this is
one issue on which I cannot be silent. The sheer pettiness
of these regulations (they didn't have the guts to pass them
as laws --- they are "regulations" enacted without direct
congressional action but clearly with plenty of underhanded
political support) is astounding!
The notion that a computer program can be arbitrarily
classified as a "munition" and thus fall under export
control is a slippery slope. It's only a hare's breadth
from the notion that these "munitions" should entail
mandatory registration and "7 day waiting periods" and
ultimately be banned entirely from domestic use. It'll all
start with populist phrases like: "protect the children from
child pornography" and "only drug dealers and mobsters have
secrets to hide from us"
Anyway, back to your subject. Just commenting out
three for four services is not enough. Start by
commenting out everything. Then remove 'inetd'
completely from your startup sequence. That's much
more comprehensive.
However, you may find that you "need" some of those
services. For example, if you do IRC you'll find that
most IRC servers want to do an "auth" call back to the
the 'identd' (identification) server on your system.
You can use TCP Wrappers, and only re-enable a service
(with restrictions that are as tight as feasible
in your /etc/hosts.allow) when you know what it is
doing and why you are enabling it.
That's why I'll be giving this talk. It isn't simple.
Copyright © 1999, James T. Dennis
Published in The Linux Gazette Issue 37 February 1999
![[ Table Of Contents ]](../../gx/indexnew.gif)
![[ Front Page ]](../../gx/homenew.gif)
![[ Previous Section ]](../../gx/back2.gif)
![[ Next Section ]](../../gx/fwd.gif)
|
![[ Answer Guy Index ]](../../gx/dennis/answernew.gif)
