"Linux Gazette...making Linux just a little more fun!"

Here you go, yet another article on Linux security. Some new tidbits for all to enjoy, reinforcement of some key points, and clarification of some things which I though were a bit misrepresented in previous articles. Note that this is geared towards a slightly novice audience, more experience users will probably find themselves bored out of their minds at times. So you've got your system up and running, connected to the net, maybe running an ftp server or some other service. But you've heard all these nasty stories of people having their computers cracked for no apparent reason, and you're just a tad bit nervous. You want to start securing your system from outside intruders, but where to begin? Contrary to popular belief, securing your system can actually be fun, and if nothing else, informative. So it's time to begin!

First and foremost, stay informed! Jay mentioned reading CERT, but I would argue that this is not enough. CERT does not release information until they have verified that it is a problem and most of the big-name vendors have provided patches to fix the problem. This can often cause lag times of months between a hole being found and the CERT announcement. There are a number of good mailing lists which I would recommend subscribing to, including bugtraq, linux-security, and linux-alert (subscription information is at the end of the article), where security holes are often discussed and found long before CERT starts talking about them - the crackers know about these places, so should you.

Now onto some real meat. The first concern is to try and protect yourself from attacks from unknown outsiders who may stumble upon your system and see it as an invitation to test out their cracking skills. One of the first things you want to check is for unused daemons running on you system. There's really no reason to be running nfsd if you're not NFS serving to anywhere, now is there? There are two places that you will need to check out: the configuration file for the inet super server (typically /etc/inetd.conf), and the system bootup scripts (located in /etc/rc.d, /etc/rc2.d, or some similar directory).

In inetd.conf, comment out with a # the lines for any service you don't really need to provide...the r* services (rlogind, rshd, rexecd, etc) are good candidates, as well as other typically unused ones like echo, daytime, and chargen. For most people, leaving in telnetd, ftpd, and maybe pop3d should be sufficient for the moment. Maybe fingerd too, though be careful, finger can give out a lot of information about your computer which can be to a potential crackers advantage. Once you finish editing your inetd.conf, restart inetd by running "killall -HUP inetd" to get it to reread the configuration.

In your bootup scripts you may see references to things like portmap, ypserv, rpc.mountd, and rpc.nfsd. Unless you are a NFS or NIS server, you have no need for these and should not run them...in many cases the "out of the box" versions of these programs have some pretty nasty security vulnerabilities. Also look for sendmail (if you're not receiving mail directly you don't need to run it), and httpd (only want this if you're running a web server).

So, you've worked hard to get the list of unnecessary servers down... time to start adding/upgrading software again. First and foremost, make sure you are running the most recent version of NetKit, which contains most of the typically network servers for Linux like telnetd, fingerd, etc. The current version as of this writing is 0.09, it is available in ftp://ftp.uk.linux.org/pub/linux/Networking/base. The most recent version fixes a few known security flaws in earlier versions.

In general, you want to try and keep everything else up to date too: check http://www.sendmail.org for updates to sendmail (any time a new version comes out nowadays, it is almost always to fix a security problem), as well as http://www.apache.org for updates to the apache httpd server, etc.

However, there is still the problem of password sniffers grabbing your password if you telnet to your system from some other outside network. Telnet, FTP, POP, and just about any other standard protocol out there will transmit your password in plaintext. There are a couple of ways around this available in external software packages. I'll look at OPIE and ssh here.

First of all there's OPIE, also known as One-time Passwords In Everything, a package created by the US Naval Research Labs and currently maintained by The Inner Net. The idea behind one time passwords is that when you login to a system from remote, it will give you a prompt like this:

 
        stroke login: andy
        otp-md5 271 st6747
        Response:

There's also another pretty popular package, ssh. The ssh package replaces those evil rlogind, rexecd, rshd, etc. programs with sshd, which has the same functionality, but it encrypts all communications, making it very hard in deed for a packet sniffer to get anything useful. More information about the package can be found at http://www.cs.hut.fi/ssh/.

In addition to these two, there are a number of more involved, complicated methods designed for sitewide networks, labs, and the like, which are a tad overkill for one single host (this includes things like Kerberos V and the like).

That about wraps up the protecting yourself from outside crackers, but you still have to worry about other users on your own system (or even outside crackers if they manage to get access to a shell on your system). Typically you will hear a lot about "buffer overflow" security holes. These are essentially times when a binary doesn't check to see if the data it is storing into a character buffer can fit into the memory it is being put into. A carefully written program can take advantage of this and overwrite other parts of memory, causing other programs to be executed. Normally this isn't a problem until you get into setuid root binaries. Since setuid root binaries will initially run with root privileges, then any binary executed by the program will also be run as root. So if there is a buffer overflow which is used to run /bin/sh as root, then blammo, any random joe suddenly has a root shell to do what they please with.

There are also programs which have what are called race conditions, or times when they are doing something which may be used to a crackers advantage if the program happens to be running as root. Through some bit of trickery, it might very well be possible for them to get a root shell. The bottom line: setuid root binaries are not the greatest things in the world, keep the number of setuid root binaries on your system to a bare minimum.

To protect yourself from buffer overflows, there isn't too much you can do but keep up to date with information being made available about possible security holes and fixing them ASAP. If you have some programming experience, you also probably want to actually look through the source code and check for buffer overflows yourself: you just may find one that no one else knows about yet.

Also, an important point: you should very rarely trust binaries that you just get off the net from an untrusted unknown source, especially if you are going to be running those binaries as root. This is how the Bliss "virus" spread, combined with a buffer overflow in some commonly found setuid root games. Under any Unix, root is a very powerful user, so while normal viruses can't exist under Unix because users typically cannot modify system binaries, a program like Bliss is designed to try and exploit known buffer overflows to get root access to be able to modify root owned binaries.

And just as a last reminder, here are some points I can't help but reinforce.If you think you've been compromised, then disconnect from the net immediately, analyze your logs, and replace any binaries which you think may have been compromised, maybe even reinstalling your system (after backing up important data). And always remember to keep your passwords hard to guess and change them regularly. Besides all this, I can't begin to emphasize the importance of GETTING INFORMED and then STAYING INFORMED. There are many good books on the topic of computer security, I'd especially recommend _Computer Security Basics_ from O'Reilly and Associates for those with a beginning interest in security. And keeping current with some of the more popular security mailing lists will do you a world of good. There is also a Linux Security FAQ available online at http://www.aoy.net/Linux/Security/, which is a good source of information. Some final advice: never get the feeling that your system is "perfectly secure" - you're just inviting a break-in that way.

Oh, about those mailing lists I mentioned earlier. Information about linux-alert and linux-security can be found at the Linux Security WWW I just mentioned (http://www.aoy.net/Linux/Security/). Information about bugtraq may be found at http://www.geek-girl.com/bugtraq/index.html. There are also a lot of other things which can be said about security, delving into firewalls and other packet filtering, IP spoofing protection, more fine grained access control to net services, and many other areas, but those are topics for another place and time.

-Andrew Berkheimer [email protected], [email protected]

Summary of Resources Mentioned

 
                  netkit: ftp://ftp.uk.linux.org/pub/linux/Networking/base/
                sendmail: http://www.sendmail.org/
                  apache: http://www.apache.org/
                    opie: ftp://ftp.nrl.navy.mil/pub/security/opie/
                     ssh: http://www.cs.hut.fi/ssh/
      linux security www: http://www.aoy.net/Linux/Security/
   linux-alert list info: http://www.aoy.net/Linux/Security/LinuxAlertList.html
linux-security list info: 
                http://www.aoy.net/Linux/Security/LinuxSecurityList.html
       bugtraq list info: http://www.geek-girl.com/bugtraq/