"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 (https://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 https://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

				1	2	3	4	5	6	7	8	9	10
				11	12	14	15	16	17	18	19	21	22
				23	28	29	30	31	32	33	34	37	38
39	41	42	43	44	45	46	47	48	49