In Part II, I mentioned (briefly) how to close down other services that are not invoked via inetd, the so-called stand-alone daemons.
Now in Part III, I'll discuss some ideas and opinions about how to open certain ports in a secure way, assuming you need or want to. Time constraints don't allow me to discuss more than just a handful of services here. Likewise, this discussion isn't really complete without at least an introductoin to tcp wrappers and to the kernel packet filtering capabilities (ipchains or ipfwadm), but we don't have time to discuss them here. (Jake's page has a quick intro to tcp wrappers, the link is in the resources section, below).
This will be a mix of fact, advice, and opinion, so take it with a grain of salt (I am very opinionated when it comes to security). It is also, of course, incomplete. Comments, suggestions and corrections are welcome.
When a new security hole is found, the reaction from the cracker community is pretty swift. Code to exploit the new vulnerability spreads in a matter of hours, and you can expect active scanning to begin within a day of the discovery. The most recent example is the vulnerability found earlier this month with wu-ftpd Click here for my personal experiences with this, with real log extracts.
So you must pay attention, on an ongoing basis, to sources of information about vulnerabilities affecting the specific services you decide to offer on your machine. This involves periodic checks on each program's home page (if it exists) and also more general security-related sites. In the resources section I give a few examples of the latter.
[ Emily adds: Medusa is one example of a security enhancement to the kernel that can, hopefully, even protect against some yet-to-be-discovered exploits. See also this review in Linux Journal online. ]
Here are a couple of hints on how to reduce your risks if you decide you want to run the Apache web server.
Beware of the default contents of the cgi-bin directory. Apache puts
a few simple scripts in there for testing purposes. Those scripts can,
at the least, give away too much information about your system. At worst,
they can be exploited to gain root access to your machine. The most egregious
of these are no longer distributed with Apache (after some exploits were
found), but the ones that remain are still potentially dangerous. You should
move them out of the cgi-bin after you play around with them a couple of
times to see what they do. [ Steve Brewer comments: recent Apache
distributions turn off the execute bits on these scripts,
which is a good thing. The basic advice still stands: check them
out, then get rid of them ]
Indeed, you may consider removing the cgi-bin directory altogether and replacing it with something else. This requires you to study the Apache configuration file and edit it appropriately.
Secondly, beware of cgi programming in general. It is very easy to write cgi scripts that introduce security holes, and the number of break-ins that result from poorly written cgi programs is huge. So don't run any cgi unless you have a reasonable understanding of writing secure programs (which is not trivial).
Running Apache to serve only static pages, and with cgi disabled (and better yet, with the cgi-bin directory removed entirely) should be reasonably secure. The default Apache configuration file (httpd.conf) has good defaults, so the only area of concern with an out-of-the-box Apache installation is the cgi-bin directory and cgi programming.
The moment you start doing cgi, you potentially open a can of worms. Secure programming is a whole topic in itself, check the resources section for pointers on getting started.
Enabling Apache
Since the Apache daemon does not run under inetd, you have to enable by re-activating it in your startup scripts. This is distribution-specific. In Slackware, if you have a file called /etc/rc.d/rc.httpd, make it executable (chmod 755 /etc/rc.d/rc.httpd) and execute it. It will also, henceforth, be started automatically at boot time.
Under Red Hat, SuSe, Mandrake, Caldera, etc.: you have to (re)-create the appropriate link under the directory /etc/rc.d/rc<number>.d (where <number> is either 3 or 5 depending on your default runlevel).
Caveat: don't count on http password protection
You may have encountered password protected web sites out there. Be aware that for the most part, the protocols used in that case also send usernames with very weak, easily breakable encryption that's basically as good as plain text [thanks to Rich Roth for the correction]. The http protocol also supports so-called "Digest" (really, md5) authentication, and Apache implements it, but most (all?) current browsers do not work with this method. Consequently, the only http authentication scheme that works is the so-called "Basic" method, in which usernames and passwords can be easily sniffed across the wire.
Bottom line: don't serve sensitive files (personal information, the contents of your /etc/passwd, etc.) through Apache, even with "password protection". If you really want to do that, currently your best bet is to run SSL (Secure Sockets Layer) on top of Apache.
What's wrong with them? For starters, passwords are sent in plain text over the wire. Which means that somebody with a packet sniffer can see anything that goes on through these connections. True, in order to sniff you they also need to be on one of the network segments between your machine and the client, but the risk is non-trivial regardless. And you should give a thought to the privacy implications of having your keystrokes sent plainly over the net.
Some people consider the risk of sniffing to be remote. I disagree (at the very least, your ISP has access to your network packets), but there are other problems with these services.
With telnet, for example, somebody can figure out the password of one of your accounts and log in normally into your machine. Once in, they can try one of the myriad local exploits to gain root privileges, and at that point you are screwed.
Passwords can be figured out by a variety of means, including brute force. This is a very real problem, and is a big reason why you really don't want to enable telnet or ftp.
Incidentally, it is sadly true that an awful lot of people choose insecure passwords that can be easily cracked via brute force or by password-cracking programs. If you want to see some suggestions about choosing secure passwords, try:
There are a number of freely available password-cracking programs (one called, oddly enough, "crack"). It would be an interesting exercise to run one of those against the contents of your shadow password file.man passwd
Enabling telnet
If you really want to open telnet, you ought to have your head examined. But having said that, how you do it is by uncommenting the appropriate line in /etc/inetd.conf and restarting inetd.
If you do open telnet (are you crazy?) you should should try at least to use tcp wrappers as a fig leaf, and please, for God's sake, don't ever telnet into your machine as root.
Before you open telnet (you fool) make sure that root telnet is disallowed. This is achieved through the file /etc/securetty
That file contains a list of terminal devices that are considered "secure" (thus allowing root to log in via one of them) and should only contain local terminal devices.
On Linux, your /etc/securetty should look like this:
And nothing else. Beware, some distributions throw more stuff on /etc/securetty. Comment out those other lines by putting a # in front.console tty1 tty2 tty3 tty4 tty5 tty6
Another thing you must do is take a look at /etc/passwd and /etc/shadow to see how many accounts already exist on your machine. You may be surprised at how many there are (although most of them are actually necessary and you probably should not delete them unless you know what you are doing). If you are lucky, all of those will have their passwords disabled, but check nonetheless. One account with an empty password will ruin your day.
CAREFUL. When it comes to /etc/passwd or /etc/shadow, look but don't touch. Editing these files by hand can be a bad thing (although it can be done). You may accidentally lock yourself out of your own machine. Plus it's bad form to edit the files on a multi-user sysem, although you can usually get away with the latter on a stand-alone machine.
If you pull them up with an editor to look at them, make sure you don't inadvertently change them. Better to make a copy of these files and look at the copies instead (but don't forget to delete the copies after you're done).
By the way, if you don't have an /etc/shadow file, that means you are not using the shadow password suite and your system is even more insecure. If you put such a machine on the net, it will be an irresistible target for even the dumbest of crackers, so hopefully, you do have shadow passwords on your system. If not, you simply need to upgrade your distribution.
Here's an example (from /etc/shadow) of an account with no password:
The clue is that what follows the username (bobo) are two :: with nothing between them. Somebody can then telnet into your machine, log in as user bobo with no password.bobo::10937:0:99999:7:::
Here's an example of an account with a disabled password:
Here you see there is a single * in between the first set of :: Some systems put an exclamation point (!) instead of the asterisk, and there are other variations as well. Any string shorter than 13 characters will effectively mean that the password is disabled.nobody:*:9797:0:::::
Should you find accounts with no passwords, disable them immediately with
(that's the letter "el", not the digit "one").passwd -l bobo
If you want more info on shadow passwords, try:
And if you are really curious:man 5 passwd man 5 shadow
NOTE: These examples assume the passwords are encrypted with the traditional crypt(3) algorithm, which is an implementation of DES. There are better alternatives, namely md5 encryption. I don't know of any distributions (currently) that ship with md5 password encryption by default.man 3 crypt
ftp also suffers from the anonymous ftp problem, a service that is very convenient, but very difficult to run securely.
The ftp protocol has some eccentricities that make it very difficult to protect it with ipchains.
Finally, the most popular ftp daemon, wu-ftpd, is an old program and has had many security exploits discovered (the latest was less than a month ago). Most alternatives (ProFTPD, etc.) are derived from the wu-ftpd code and usually suffer from the same problems.
Since ssh gives you the ability to transfer files securely, and given all these other problems, you really should not run ftp either. You may also consider http to offer the ability to transfer files in one direction. There's no real equivalent of an ftp PUT command, unless you use cgi programming. But if you only want to be able to download files from your computer, the http protocol may be a better choice.
Enabling ftp
If you decide you want to run ftp despite all its problems, you uncomment the appropriate line in /etc/inetd.conf and restart inetd.
Like telnet, you should use tcp wrappers around your ftp daemon to gain a measure of security, and you should disable anonymous ftp, which comes enabled by default (agh!) in all the Linux distributions that I know of.
The easiest way is to remove the ftp account. Become root, enter the command
and you're done. No more anonymous ftp. This is, mind you, a little drastic, but I like drastic.userdel ftp
The non-drastic method is to add a line
to your ftpaccess file. Seedefaultserver private
for more information.man 5 ftpaccess
You would want to run smtp only if your machine is permanently connected to the net and you want to act as a mail server (for your own domain, perhaps) or as a mailing list server.
Some risks associated with running a mail or list server
Most current versions of email daemon software turn off the open relay feature by default, but you should definitely double-check. If your machine starts propagating spam you are certain to piss off sysadmins around the world and get your box blacklisted (which will impair your ability to send or receive any email at all). Plus you'll annoy the spam recipients, of course. You can go to www.orbs.org to have your mail server checked for open relays. [ Rich Roth adds: but beware, if you fail the test, your open-relay status will be advertised on their web site. ]
It's easy to script an attack against a mail server that will fill its spool partition with large amounts of bogus email and/or log messages. This is known as a mailbomb; it is not a very clever form of attack, but it happens.
This is more specific to list servers. Various misconfiguration problems in email clients and other smtp daemons can result in "mail loops" where error messages get bounced back and forth between some remote machine and your list server, ad infinitum; with the entire exchange being distributed to the mailing list subscribers, possibly overflowing their mailboxes.Or, somebody could decide to mailbomb one of your mailing lists.
Of course, the MS Outhouse Express "features" that enable the existence of these critters don't directly affect you as a Linux user. But if you run a list server, your machine can unwittingly contribute to the propagation of these things. You should consider the legal implications of this. So far as I know, this is still a theoretical risk; but it's not hard to visualize some lawyer coming after you for negligence, for allowing your machine to be a vector for infection to others. Such a claim would arguably lack technical merit, but a court may not agree.Apart from legal problems, why else should you care if some Windows user gets hit by an email virus? Are you, as a Linux mail administrator, obligated in any way to protect other people from problems that don't affect your operating system? That's an interesting ethical question, and you should give it some thought. Consider the admonition not to place a stumbling block before the blind.
There is a long history of these, including some spectacular hacks (the 1988 internet worm used a hole in sendmail as one of its infection mechanisms). It's a safe bet that more exploits remain to be discovered.
Sendmail is a very old program. It has been continuously maintained since its creation, but its old heritage is problematic in several ways.
Enabling sendmail
Sendmail doesn't run from inetd (although you could force it to) so you enable it via your startup scripts. Not running from inetd also means that you can't easily use tcp wrappers with sendmail --although it's not impossible. postfix, on the other hand, was written by Wietse Venema, who also wrote tcp wrappers, so can be expected to work pretty well with it. I believe that qmail can also easily work behind tcp wrappers.
You must use the latest available version. Don't trust the one that was shipped with your distribution until you have had a look at www.sendmail.org for the current version, and the changes made since your version, if any.
Other mail-related problems
Your mailer daemon (sendmail, qmail, etc.) is not the only piece of software that interacts with incoming email.
Obviously, if you use separate software to run a list server (qmail gives you listserv facilities directly) you must keep up to date on that program as well.
procmail is a very useful and powerful mail filtering facility that is commonly deployed side-by-side with sendmail. (Read the procmail man page for more information). procmail has had its share of exploits (out of necessity, portions of its code also run with root privileges). Therefore you must be running the very latest version. There have been new procmail-related attacks discovered within the past year.
POP3 and IMAP are mailbox transfer protocols that are probably familiar to you. If you want to act as a mailbox server you would need to run one (possibly both) of these, but you really ought to think twice about it.
Both protocols send passwords in clear text (IMAP can now be run through SSL, which eliminates this particular problem).
Worse, the POP3 and IMAP implementations for Linux have a long history of vulnerabilities, so you're buying two new headaches if you decide to run them.
comp.security.unix and comp.os.linux.security contain lively discussions with a fairly good signal-to-noise ratio.
comp.unix.programmer is one of the places where the Secure UNIX Programming FAQ is posted regularly.
securityfocus.com host, among other things, the archives of the BUGTRAQ mailing list (look under "forums"). They also have sections devoted to different OSes (including a Linux section), a number of papers and links to other security resources. It would be my top recommendation, were it not for the fact that their web interface is an abomination.
WeMaLu's very own Jake C. has a Linux security page with lots of good advice and useful information, and a quick introduction to tcp wrappers. Check it out.
There are a number of white hat cracker sites on the net. My two favorites are Fyodor's playhouse (where you can find the nmap portscanner), and L0pht heavy industries. Check them out not so much for day-to-day advisories, but for in-depth security analyses by knowledgeable people; and also for their collection of exploit archives from past and present. phrack is also an interesting place, but they update very sporadically (although this may be changing).
The Linux Security HOWTO contains good information and references, and also covers local security topics.
The SANS Institute is a very good place but is by and for experienced network administrators. A lot of their activity focuses on detection of network attacks, and by and large they take for granted that you already know the basics. Take a special look at their GIAC (Global Incident Analysis Center) section.
This page has a very decent collection of links to articles dealing with secure programming.