Linux Security in a Network Environment

It all depends on what the meaning of 'network' is

For the purposes of this guide, I'm defining 'network' as any environment in which your computer is available to an outside (i.e. non-console) user regularly. Whether it's your roommate over the apartment network, or Jane Q. Random from Idaho from over the Internet, if someone from outside your machine can reach it from someplace else when they want, your machine is on a network. It's worth noting that those of you who use ISDN or ADSL connections that stay up 24 hours a day (or do dial-on-demand for outside traffic) are on a network for the purposes of this discussion: your need for network-level security is as great or greater than the professor with a Linux box on the campus network or the programmer with one on his desk at work. This is because the people who use ADSL or ISDN connections often don't realize that their box is accessible to the outside world just as if it were on a T1: just because the name and IP of your box may be dynamic doesn't mean intruders will find it much harder to get to you.

"Foiling the Wily Hacker at the Gate": Restricting Connections to your Machine

One of the easiest ways to prevent breakins to your system is to prevent someone from even connecting to it. One way to do that is with a firewall, if you're protecting multiple hosts on your network--we'll cover firewalls in another section. But if you've just got the one box to protect, stop those connections before they start! Here's what you can do:

1. Decide what you'll offer to the world. There's nothing that says you have to run any outside-accessible services like web servers, FTP servers or mail accounts. The key myth about a lot of these services is that 'give' has nothing to do with 'take': you don't need to have a web server running to browse the web, nor do you need to run an FTP daemon to be able to access FTP services on other servers. It's perfectly fine to run your machine with no outside-accessible servers, but if you want to run them, decide up front what you'll offer and stick to it. By way of providing an example, let's say I've decided to offer FTP to my friends--not anonymous FTP, just FTP for users.
2. Prune /etc/inetd.conf to remove the services you won't offer. My favorite trick, upon hopping onto a new box is to open /etc/inetd.conf, and comment out everything in the file. I'm a vi addict, so I open the file, then use '1,$ s/^/#/' to put a '#' sign at the beginning of every line. Since inetd ignores commented lines, it will start up without the ability to run any services. Since I want to allow FTP for our example, my inetd.conf goes from this fragment:
   
   #ftp stream tcp nowait root /usr/sbin/tcpd /usr/local/sbin/proftpd
   #telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
   #gopher stream tcp nowait root /usr/sbin/tcpd gn
   
   to this one:
   ftp stream tcp nowait root /usr/sbin/tcpd /usr/local/sbin/proftpd
   #telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
   #gopher stream tcp nowait root /usr/sbin/tcpd gn
   
   Once you've made the changes you want to make to this file, save and close it, then restart inetd. You can do this one of two ways: it is perfectly safe to do a 'ps' and check through the output for 'inetd', then 'kill -HUP' the inetd process to restart it, like so:
   [ ROOT ]# ps auxww|grep inetd
   root 227 0.0 0.0 772 68 ? S Jun 28 0:00 inetd
   [ ROOT ]# kill -HUP 227
   [ ROOT ]# ps auxww|grep inetd
   root 227 0.0 0.1 772 224 ? S Jun 28 0:00 inetd
   Others, however, prefer the somewhat longer method of rebooting.
3. Turn off unneeded services in /etc/rc.d! Mike gives some details about doing this in his Dialup system security section: it's often easiest to use the system tools (e.g. /usr/sbin/ntsysv on Red Hat) to edit what will and won't start at boot. The ones you need to make sure you shut down if you are not at this moment actively using them are NFS (nfsfs), the remote communication "r-"services (rusersd and rwhod), sendmail, Print services (lpd), NIS/Yellow Pages (ypbind), the network time daemon (xntpd), SAMBA (smb), portmap, and SNMP services (snmpd). Any and all of those have been victims of remote exploits in the past, and besides, if you're not using them, why waste the memory?
4. Install TCP Wrappers to protect the services you *do* decide to run out of /etc/inetd.conf. As they are almost always installed, TCP Wrappers are actually a single daemon, tcpd, that monitors all of the services in /etc/inetd.conf. When one of these services is requested via traffic on its port (say, telnet), the connection is first passed to tcpd, which checks the connection several different ways to make sure it's secure and permissible. First, it checks the IP address and name of the connecting host, and makes sure they map to each other in DNS. Next, it checks /etc/hosts.allow and hosts.deny to see whether the connection is allowed. Finally, the daemon logs the source of the connection, the service being requested, any errors that might have occurred, and then allows or denies the connection according to the ruleset in place. As an example, let's continue our FTP service from above. I've decided to run an FTP service, but I'll go ahead and 'wrap' all of my services in /etc/inetd.conf: the idea behind a really secure system is that if it breaks, better that it break securely. In this case, if something gets turned on, by accident or deliberately, I want TCP Wrappers to be watching it. So we'll take this fragment of "unadulterated" inetd.conf:
   #ftp stream tcp nowait root /usr/local/sbin/proftpd /usr/local/sbin/proftpd
   #telnet stream tcp nowait root /usr/sbin/in.telnetd in.telnetd
   #gopher stream tcp nowait root /usr/sbin/in.gn gn
   
   and change it to this one:
   ftp stream tcp nowait root /usr/sbin/tcpd /usr/local/sbin/proftpd
   #telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
   #gopher stream tcp nowait root /usr/sbin/tcpd gn
   
   Notice that in each case, the final daemon responsible for the connection hasn't been changed: only the daemon which will handle the call first (/usr/local/sbin/tcpd).
   Having edited inetd.conf and HUPped the inetd daemon, I'm not quite done yet. I'll first edit /etc/hosts.deny:
   ALL : ALL
   That makes the default behavior of the wrappers to deny everyone access to any outside service. Now I have to activate FTP, but only for my friend Bob, who will be coming from his machine www.example.com:
   proftpd : 10.1.2.3
   I could, instead, allow Bob access from anywhere on his network by including a network number with a netmask, like this (for 10.1.2.<X>):
   proftpd : 10.1.2.0/255.255.255.0
   For those network wonks out there, this does support CIDR (Classless InterDomain Routing) and its larger netmasks:
   proftpd : 10.1.2.0/255.255.240.0
   
5. Install SSh, and repeat the mantra:
   There is no telnet.
   There is no rsh.
   There is no rexec.
   There is no rlogin.
   There is only SSh.
   There is no FTP.
   There is only Scp or SFTP,
   depending on your version.
   I won't get into a rant about US cryptography export policies here, so we'll just say that SSh ought to come preinstalled and configured as the only means of remote access after installation on every distribution. It's powerful, it's versatile, and best of all it is highly secure and easy to use. You can get SSh from its FTP site, and read more about it at its homepage, but in a nutshell, SSh replaces telnet, rlogin, rsh, and rexec with a secure means of remote access that transmits all traffic between the two hosts highly encrypted. When you telnet to a machine, you must provide your userID and password, which are then transmitted in the clear over the network: anyone who reads your packets in transmission can read your password. SSh transmits all of that data by first establishing an encrypted 'tunnel' to the other server, through which all your data is passed. It is also capable of replacing FTP and rcp services with 'scp' and, in version 2, 'sftp', which transmit your data through that same encrypted tunnel. In addition, you can configure the client and server to initiate port-forwarding from one machine to the other. This means that you can connect to another machine, start an xterm that is displayed on your desktop, and type away in it with all your data being transmitted to the other machine through the tunnel, rather than via the traditional X11 forwarding. Read the docs and check it out--SSh is all that and a bag of microchips.
6. At this point, your box is fairly well locked down. If you like, you can experiment with IPChains, the newer version of ipfwadm for kernels 2.1.102 and higher. IPChains is essentially firewalling software--it allows you to specify exactly which ports will be allowed and which will be denied, so that the actual daemons running on your system will never see connections that are not from permitted hosts. IPChains is a wonderful piece of software, with some evolving GUI front-ends (it's a command-line-based system), but can be difficult to manage for a newbie, and hard to understand and configure properly if you don't know much about networking. One solution to this problem is to use some of the ready-made shellscripts you can find at freshmeat.net: you run one of these, and it issues ipchains commands to block off well-known exploit ports like the X ports (6000-6003), port 31337, and so forth. In addition, some will block off just about everything that didn't originate with your box, which isn't a bad idea at all. Check out the homepage for more information about it specifically, and also have a look at freshmeat.net for some of the GUI's.

Minimizing Your Risks: Staying Secure *And* Sane

One of the unfortunate side effects of extensive security work (even just locking down your workstation) is that it makes you paranoid: after spending all that work, you would hate to have someone break in and blow all your work down. The only really secure system, though, is one that's been unplugged, sealed in cement and dropped to the bottom of the Marianas Trench. You have to strike balances between usability and security, which is a difficult tightrope to walk. Herewith, some suggestions for keeping your systems secure without totally killing you:

• I thought that people would have learned this one by now, but don't log in as root! Create yourself a normal user account, install sudo, and promise that if you ever, ever have to log in as root from somewhere else to fix a problem, you'll at least use SSh.
• Backups. Lots and lots of backups. We go more into detail about this in the section on backups and disaster recovery, but suffice it to say that something, somewhere, will occur. Be it a hard disk failure or an intruder, you'll be thanking your lucky stars afterwards if you remember to make good backups frequently. Also, remember to test your backups--many an admin has been stymied by a system failure, followed by the discovery that his tape drive heads were bad and all his backups are useless.
• Use Tripwire. Tripwire is a freely-available program that builds a database of your system from top to bottom, doing checksums of all your data. Once you've created the initial database of your system, store it on a floppy or something similar that you can make read-only, so that the database can't be tampered with. The RPM of Tripwire also installs a cron job for root that runs the verification process for Tripwire every night at midnight and email root with the results. You can read more about Tripwire in our tools section.
• Make copies of everything. Not just backups, but copies: intrusions do happen to the most secure systems, and when they do, you'll want to know how the intruder got in, as much as you can about what he did, and, if possible, who he was and where he came from. To do this, use an outside email account (i.e. on another system) to receive a copy of root's email--add a line in /etc/aliases like so:
  root: \root,name@example.com
  Be careful--the '\' is important, since it prevents a really nasty mail loop from occurring. If you have another box to use, consider having the two exchange log files using scp at regular intervals, so that you have copies of your system logs on another machine.
• 'Chroot' is one of the lesser-known and most useful system tricks I know. FTP is the major user of this--most FTP daemons like WU-FTPd or ProFTPd offer the ability to create this. 'Chroot' stands for 'change root', and that's just what it does: it treats the directory you give it as the root directory for the processes that are chrooted, so that they don't even see the rest of your filesystems. The most common use of this is for anonymous FTP: anonymous FTP users are presented with their own set of directories which appear to be the entire system, but doesn't allow them access to any outside system areas. Some FTP daemons (WU-FTPd is among them) actually require you to create a miniature root filesystem within the chroot, including a /bin with a copy of 'ls', an /etc with a passwd if you want userid's listed when you do an 'ls', and a /shlib directory for the C libraries 'ls' needs. Other daemons, like ProFTPd, are capable of providing that dynamically and don't need anything laid out for them like that. Consult your FTP daemon manuals on how to initiate a 'chroot' for a user--generally, they need to belong to a special 'FTP' group and sometimes need a special indicator in their home directory. I'd really strongly consider using this not just for anonymous FTP but for anyone to whom you give FTP access--it seriously reduces the chances of a major compromise if that FTP account is cracked.
• For really mission-critical machines, consider using a tool like Abacus Sentry. This tool and others like it will monitor specified ports (FTP, for example) and if they see evidence of an attack in progress (like a buffer overrun) will pick out the originating IP address, and either drop it into hosts.deny or issue the necessary ipchains commands to drop port service to that host or both, in addition to alerting you to the actions they take. While there exists the possibility of a denial-of-service attack occurring wherein someone discovers you're running this tool and begins systematically hitting it to drop service, you should have alerts going bananas at that point, and further I wouldn't recommend using it on, say, the FTP port (21) of an FTP server--just every other port on that box. Be careful with the use of this, and it will take you a long way.

And Finally, A Few Words From Our Graduates: Things To Remember on Campus Networks

That said, here are some useful extra things to do if you're planning on running a Linux box on your campus network.

1. Since your box will be available to everyone on campus, a little more due diligence is in order. Find any campus resources that you can to help you mingle with other people who can help you in exchange for your help: they may be able to supply information about whom you should talk to in case of an incident, for example. These include, but aren't limited to, newsgroups, mailing lists, LUG's, chat groups, administrators or professors you may know, and, if there is one, OIT literature.
2. Keep up with your box. Don't let it rot under your desk--upgrade software frequently, and log in several times a day just to look around. Read /etc/passwd, /etc/shadow and their ilk often--don't just scan them, really look for any accounts you don't recognize, things that should be locked that aren't, and so forth. A little paranoia is worth a lot of restful sleep.
3. Find out beforehand what you need to do if your system gets compromised. Don't wait until after it happens--ask! Many campuses have established procedures for pursuing institutional and criminal actions against students who crack machines, but that may only come into play if you've saved evidence from the breakin and can offer proof of your lack of negligence on the system.
4. If you decide you're going to offer any publicly-accessible services (shell accounts, FTP access, a webserver, etc.), establish a firm and clear policy about those accounts and their expected activities on your system. Give out hard copies of that policy to everyone who has any sort of account on your system, and provide a very clearly-marked copy of it on the website, so that no one can claim that you didn't make the policies of the system clear to them. Once you've made up your mind, stick to your guns! You could be legally liable if you establish a policy, and then don't follow it and your compromised system affects someone else's. Check with your campus administrators if you feel you need support for your services--they're much more sympathetic about your security problems if you've warned them ahead of time that you'll be, say, providing an FTP server for the music department, and gotten their OK.

With those more common-sense pieces of advice out of the way, let me offer some more technical tips, too:

5. Subscribe to BUGTRAQ (see the resources page) list, and keep a sharp eye out for compromises or buffer overflows in any software or services you run. Upgrade quickly--don't put it off! Many younger, less-experienced crackers are 'script kiddies': they don't know much about real cracking, but have pre-built tools that will exploit a buffer-overrun hole, grab a rootshell, install several root backdoors into the system, wipe the logs, create user accounts, and modify system binaries to prevent anything the cracker does from showing up. Once that happens, a total reinstall is in your future, so upgrade as fast as you can. Unfortunately, many crackers subscribe to BUGTRAQ for tips, and rootkits have been known to be released within a few hours of an exploit being published on BUGTRAQ.
6. Definitely install ipchains (see above), and set it to deny connections to any port you don't have something public running on. If you can get your accepted users down to specific network addresses, then close off all your public ports to any but those users. Many prebuilt ipchains scripts are available for doing this (search freshmeat.net for 'ipchains' and poke through the results), and many will also include harsher commands for closing off ICMP and IP traffic to all ports, to help block portscans.
7. Get a copy of Nessus or similar intrusion-testing tools and run it against your machine, preferably from another box to really test it. Make note of what the reports tell you, and fix problems quickly--this is one really good way to cracker-proof your box in short order, if you use the tools correctly.
8. Be diligent about physical security, too. Let's face it: physical security isn't much of a concern for those with home computers. Most burglars, if they do anything to your computer at all, will just take it. But a terminal left open to a shell (that ever-helpful '#" prompt is always a giveaway...) is too tempting a target for someone just passing by your office door while you stepped out for a moment to get a cup of coffee. This is one case where X is actually more secure than command prompt, since you can't really lock a command prompt, you can only log out (a viable option, by the way). If you're running X, use a screen-locker like xlock or xscreensaver -lockmode to keep your screen secure. As an extra-useful idea, most windowmanagers allow you to remap keys to commands, generally the function keys. Remap a function key to be your xlock key, and hit it as you stand up to leave your desk. The lock will kick in automatically, so all you have to do is make sure you lock your office, and take one extra step--do something with Ctrl-Alt-Backspace. On the default XFree86 configuration, Ctrl-Alt-Backspace is used to kill the X server right now, and drop you out of X to a command prompt. The problem is that anyone who sees you're running X can step in and hit Ctrl-Alt-Backspace. There are two solutions to this problem: one, when you set up your X server, you are generally offered the choice of whether or not to enable that--don't. Secondly, make a shell alias for yourself: (in bash) "alias startx='exec startx'". The exec command replaces your currently running shell with the command--a useful trick for changing shells in a hurry, if you're low on process space--which has the result of logging out that instance of you, while running X as you. Thus, if someone did hit Ctrl-Alt-Backspace, they would be greeted not by a shell prompt but by your login screen.
9. Do yourself and your users a favor: run 'Crack' or 'John' on your password files on a regular basis. The issue of whether or not to email a user if their password is cracked is a hot one--I'm in favor of contacting them personally rather than via email, if for no other reason than that I can breathe down their neck about changing their password right then, no excuses or quarter given. In any case, remember: if you can come up with someone's password, so can anyone else, and 'crack' is freely available.
10. Run some logfile analyzers like 'autobuse' or Abacus Logcheck to keep an eye on your system logs. Many portscanners now will perform their scans very slowly over a long stretch of time so as to bury their queries in the network traffic noise. These log-watching daemons will keep a quiet eye on your system, and if they detect the patterns of an intrusion or odd entries in the log files, will email you the results.
11. Definitely recompile your kernel--even 2.2.25 (shipped with Red Hat 6.0) has some vulnerabilities to denial of service attacks that are well-documented and fixed in later revs. This isn't too hard to keep up with, since a server shouldn't need new hardware support compiled in, so if you keep your ear to the ground and recompile your kernel to fix security holes and problems you hear about, you'll be in pretty good shape.