by Mark R. Brown
Even the big boys get their noses tweaked now and then. In the summer of 1996, both the U.S. Central Intelligence Agency and the U.S. Department of Justice--organizations that one would think would have pretty tight security--had their Web sites vandalized. The CIA became the "Central Stupidity Agency" and DOJ became the "Department of Injustice." Both sites had their pages populated with diatribes against the Communications Decency Act, as well as Nazi images and pornographic pictures. Both organizations lost much face over the incidents.
The fact is, no one is immune to Internet treachery. You need to be aware of the risks and the ways in which you can protect your network resources.
If you connect a computer to a network, you expose that computer and the data it contains to security threats. That is the unavoidable truth.
Recall the 1996 movie Mission: Impossible. In that movie, the Impossible Missions squad had to steal information from a supersecure computer at CIA headquarters. Why was that computer so secure? Because it was kept in a locked room and connected to no network. To steal data from the machine, the squad had to break into the room and copy information onto a disk. Though they succeeded (naturally, for the sake of the plot), their efforts went far beyond what most wired evildoers are willing to undertake.
The advantages of having Internet-connected employees far outweigh the risks associated with exposing private information to unwelcome prying eyes. You shouldn't shun Internet connectivity because you fear security breaks. But sometimes the bad guys win. You can't beat them all the time. It's part of doing business online. However, you need to protect yourself as much as possible.
When you start connecting computers to a network, particularly the Internet, you should be aware of the bad things that can befall your system and the data it holds. Security breaches fall into four general categories:
In planning your protection, you should decide what level of security you want to achieve. This should depend upon several factors, including:
Once you've decided what you have to protect and the resources available for protecting it, you have to decide upon a target degree of security--again keeping in mind that you can't win all the battles all the time.
Most people are content to keep their sensitive information isolated from the Internet through the use of a firewall (covered later in this chapter), some password protection, and intelligent use of their server's standard security software. Others take a more extreme approach--using multiple layers of cryptography and advanced protection schemes like proxy servers. Still others rely on the good nature of human beings and take practically no precautions. The decision is up to you.
Since the Michaelangelo virus scare of 1993, computer viruses have been the subject of popular and technical news reports. They sound terrifying--malicious little programs replicating themselves all over the place, wreaking havoc on hard drives, and playing hob with Windows. The Internet has provided viruses with a whole new way to spread.
In truth, viruses are scary and they really can shut down a system in a hurry, destroying critical data in the process. But they're not as widespread as the popular and industry media might lead you to believe. Like any other security threat, you need to be informed about what viruses are and how they work in order to protect your data from them.
Viruses are computer programs gone wrong. Usually, they do some kind of malicious deed, such as deleting files or displaying an annoying message, without anyone's assistance and without the knowledge of the victim, until it is too late.
There are several kinds of viruses:
Viruses are bad news, but they're not an insurmountable problem. There are a couple of things you can do to protect yourself from them, and neither of these preventatives are especially difficult to implement.
Common Sense Protecting your computer from viruses is like protecting yourself from colds. A little bit of common sense goes a long way toward limiting your machine's exposure. Just like you shouldn't shake hands with someone who is sneezing frequently, don't install unknown software on your computer, and particularly not on your Web server. Try to limit the software you install to shrink-wrapped programs straight from a software retailer (though once in a while, they too will carry viruses). Freeware and shareware often carry viruses, so be sure to scan such programs with anti-virus programs before putting them to work. This goes double for games and other entertainment software packages, which sometimes are fronts for Trojan horses and other malicious software.
Anti-Virus Software The virus-protection industry is a huge one. Equip your server with one of the commercially available virus-protection software packages (Symantec Norton Anti-Virus is the top seller) and keep your chosen package updated by installing the manufacturer's update modules regularly (usually once every quarter).
Much of what you can do to prevent unwanted intrusions into your systems is quite simple. In just an hour or two, you can implement these changes and make your system significantly less attractive to casual electronic vandals.
Taking these security precautions is like putting a security system on your car. Sure, an enterprising criminal could defeat your computer security precautions, just as an ambitious thief could break into your car despite your security system. It's an issue of the ease with which a bad guy could get at your stuff--an electronic vandal might move on to easier targets if he saw your site was protected, even a little bit. The following are some of the most cost- and time-effective security precautions you can take.
Don't make a stupid mistake and leave sensitive files in locations where they might be happened upon by the wrong people. Don't laugh--it happens.
Keep all your sensitive files in private folders, preferably on a computer protected by a firewall. You'll learn more about firewalls later in this chapter.
Many server operating systems, including Windows NT 4.0 Server, come from the factory with a preconfigured Guest account. That is, they have a username defined as Guest (often with no password) that gives certain access to anyone who wants it. Though Guest privileges usually are extremely limited, they sometimes are enough to provide a toehold for people looking to get other privileges for nefarious purposes.
Delete your server's Guest account. If someone wants limited access for a short time, make them contact you and ask for a special account. If you must have a generic account for all temporary users, at least make the username something other than "Guest." That way, you'll keep the bad guys guessing and maybe inspire them to move on to easier targets.
Figure 41.1 shows the warning you get when you delete the Guest account on a Windows NT 4.0 system.
Deleting the Guest account in Windows NT 4.0 brings up this dialog.
Similarly, most operating systems for networked computers include a preconfigured account for the person in charge of maintaining that system. Almost without variation, this account has the username "Administrator."
This is bad, because when a bad guy is breaking into a system, he or she is supposed to have to guess at least two things: a username and a password. By leaving your computer configured with an all-powerful user with the username Administrator, you're giving away half of the secret.
So, you should rename your Administrator account. Make it "BorisSpider0175" or some name that only you know. Just don't make it something obvious (your name or your electronic mail address) and don't leave it as Administrator. Changing the account name in any operating system takes five minutes, if that long.
Figure 41.2 shows the dialog box used to configure usernames and passwords in Windows NT 4.0.
Configuring usernames and passwords in Windows NT 4.0 is done from within this dialog box.
You've probably heard this advice before, but its importance is magnified on a Web server and it bears repeating. Do not allow users to have obvious passwords. Don't let them use any of the following as their passwords:
It's also a good idea to disallow any standard word in any language as a password. Doing this prevents potential intruders from running through a dictionary (automatically, very fast) in search of a password.
A better way to choose a password is to choose a sequence of letters, numbers, and symbols that appears random but in fact is easily memorable. Don't forget to mix upper- and lowercase letters, too. For example, a password might be based on the sentence, "My second child, Judy, weighs 40 pounds." That could be translated into the seemingly inscrutable password "m2cJw40#." No one would ever guess that, and it would take a long time to figure it out by brute force. However, make sure that you choose a password that you can remember, or your system administrator will learn to hate you.
Also, make sure passwords get changed frequently--every month at least, and more frequently if you suspect that someone is trying to intrude. Many systems have an option, Force User to Change Password that you should use. However, don't adopt a simple password changing scheme, such as simply adding one to your password every month.
Finally, never, ever write your password down, especially in an insecure location. Bottom line--make sure your password is kept as securely as the system it is supposed to protect.
You can't break into a computer via Telnet if that computer doesn't support the Telnet protocols. If you have no use for a particular Internet service on a particular machine, disable that service. You can reenable it if you ever need to use it, and meanwhile, you're preventing intruders from using that service to their advantage.
Keep track of which services people are using on which computers and disable the unused services promptly.
System administrators have the ability to define which users can do what with the system. Among the most valuable privileges is the Write privilege--the ability to save information on the hard disk. Any user lacking this privilege may be able to read information (look at Web documents, for example) but is not able to write anything.
This prevents several problems, including:
Figure 41.3 shows an administrator configuring access privileges in Windows NT 4.0.
Configuring access privileges in Win- dows NT 4.0.
Most Web server software packages allow you, the administrator, to enable and disable a feature that allows Web surfers to browse through folders on your server's hard disk, as if your Web server were an FTP server. When this feature is disabled, surfers are limited to viewing pages and cannot see the contents of directories.
Always keep your server software's directory browsing feature turned off. Doing so makes it that much harder for outsiders to see things you don't want them to see.
Also your system's root directory and the root URL of your Web site should never be the same. Keep all private files in nonpublic server directories.
Every operating system suitable for use on a server keeps a log of system events. Usually, system logs make note of who logs on and when, who tries to log on and fails, and who tries to access which pieces of data on the system. System logs also record errors and other technical failures.
You should review your system log regularly--every other day at least. Look for indications that someone is trying to gain access or privileges illegally. You'll often have time to pick up on these goings-on because the process of breaking into a computer is a time-consuming one and may require efforts spread over several days. Figure 41.4 shows a typical system log, this one from Windows NT 4.0.
NOTE: You can always tell where your pages and images are being accessed from by looking at the referrer log of your Web server. If there are requests for images that didn't come from your domain, it usually means that someone at the requesting domain has a URL link to one of your images on their Web page.
This is a Windows NT 4.0 event log.
If you recognize a pattern that indicates someone is trying to do something they shouldn't be doing (look for repeated login failures and overly long Telnet sessions), you need to take preemptive action. Block all access from the offending domain, if the attacks are coming from outside. Send the user a note that says you're aware of what's going on and that you'll revoke privileges if the misbehavior continues, if he or she is from your system. Lots of administrators will pull the plug on a user first and then tell him or her why. Disabling the user's account prevents damage from occurring after you reprimand the user. It also illustrates a certain willingness to play hardball.
As interactivity grows in the online world, the activity on our networks is becoming increasingly complex. As a rule, it's tougher to secure a complex system than a simple one. So, as the Web gets more complex with the addition of programming and scripting languages, the opportunities for ne'er-do-wells to take advantage of flaws in the system proliferate.
Other network programming languages, however, present some real opportunities for dastardly deeds to be done. ActiveX Controls are so complex as to be only minimally secure. Common Gateway Interface (CGI) routines have been around a while, but since they offer access to the server's processor, they have the potential to do harm.
This section gives you an overview of the security inherent in several of the most popular network programming and scripting languages.
The people who designed Java at Sun Microsystems did so with security in mind. They wanted to make it impossible to write a virus in Java and impossible for any Java program to do harmful things to a computer on which it was running.
They succeeded. Java lacks many of the low-level memory-management routines that characterize other object-oriented programming languages, such as C++. The absence of these routines has two main effects--one of which is to make it impossible for bad guys to use low-level memory-management tricks to break into programs. The other effect is that Java programs are much simpler to write than C++ programs.
Recently, Java has come out of its sandbox. With the latest versions of Netscape Navigator and Microsoft Internet Explorer, you can give Java permission to write to your disk drive or network. This has already given rise to security questions regarding Java applets on the Web. There are a number of active forums on the Web which discuss Java security issues. The Princeton University Web site at http://pantheon.yale.edu/~dff/java.html provides links to many of the best.
Common Gateway Interface (CGI) routines are programs that run on the server to provide interactivity and intelligence to Web surfers. Because they use the server's CPU to perform operations, there is the possibility that a person could fool the CPU into thinking that a certain stream of data was a CGI request, when in fact it was a virus or other unauthorized program being sent in for processing.
The easiest and most popular way to defeat CGI attacks is to configure your processor to terminate all CGI activity that continues for more than three seconds or so. This way, legitimate users have CGI access to the processor, while the people trying to break in, whose routines likely will require extra time, will be cut off. You may also want to keep CGI scripts in nonpublic folders or use CGI wrappers (programs that encrypt CGI data streams) to protect against intrusions.
Plug-ins and ActiveX controls do most of their stuff on the client side, so any harm they do likely will be there.
But the concern for client-side harm is real, since plug-ins and especially ActiveX Controls are very complicated and very difficult to secure.
The best way to protect against plug-in and ActiveX Control harm on the client side is to remind people to use the same precautions in selecting ActiveX Controls and plug-ins that they would use in selecting other software. Remind them to use plug-ins and ActiveX Controls only from reputable sources and to always use anti-virus software.
Encryption in and of itself is interesting, but its application to Internet transactions makes it relevant to this discussion. There are two leading protocols for conducting secure transactions on the Internet, both of which can use RSA encryption. They are Secure Sockets Layer (SSL), developed by Netscape, and Secure HTTP (SHTTP), developed by Enterprise Integration Technology (EIT). These two protocols are usually referenced with respect to online commerce, but they are really just mechanisms for secure communication and could also be put to use for transmitting other sensitive information. SSL is a separate protocol from HTTP, the communications protocol of the Web, while SHTTP is an extension of the HTTP protocol. Let's look at the two in turn and see what they do and how they work.
SSL is the most common Web security protocol. It was developed by Netscape, and it is supported by all major browsers, including Netscape Navigator and Microsoft Internet Explorer. SSL allows for various methods of encryption to be used, with various levels of strength. The encryption algorithm used is negotiated by a client and server at the time of a transaction.
Currently, Netscape Navigator implements several types of SSL encryption with several encryption key sizes, from a relatively weak 40-bit encryption key to a practically unbreakable 192-bit encryption key.
Most commercial Web server software supports SSL. Check your server documentation for information on how it works in your setup. Most noticeably, URLs for accessing a document securely begin with https://, rather than http://.
Secure HTTP (SHTTP) is identical to SSL from the surfer's standpoint. The browser and server establish the encryption algorithms that they will use to make the transaction, and information is transmitted securely using those algorithms.
SHTTP differs from SSL in that it is an extension of the HTTP protocol, as opposed to an entirely separate protocol running concurrently with HTTP.
SHTTP isn't used a lot, since SSL technology was out first and thereby collected a large share of the transaction-security market. Though many servers and browsers support SHTTP, its popularity is steadily dwindling.
NOTE: Yes, once, a man in Europe decrypted a single message that had been encoded with 40-bit SSL (the weakest kind of SSL) as part of a contest sponsored by Netscape Communications. Here are some facts about what he pulled off:
- He had 120 workstations and two parallel supercomputers running nonstop for eight days. The computer time he used cost about $10,000.
- He did not crack SSL itself, only the one message. Since SSL uses a different encryption algorithm for every encrypted message, theoretically one would need another eight days with 120 workstations and two parallel supercomputers to crack just one more message.
If this had been real life and not a contest, the information he decrypted would have to have been worth more than $10,000 in order for the decryption process to have been cost-effective. I don't know what your credit limit is, but it's clear from this example that going through the hassle of decrypting an SSL transmission is just not worth it to get a credit card number.
Remember, the encryption that was broken in the contest was 40-bit SSL. It would have taken over 1,000,000,000,000 (one trillion) times more computing power to solve a message encrypted with 128-bit SSL.
Authentication, which is essential to secure transactions, is the process of making sure people really are who they claim to be. User names and passwords serve authentication purposes for system-access purposes, but certificates serve to ensure authentication when two machines or sites try to communicate with one another. That's important when online transactions are going on.
Certificates are electronic documents that contain digitally signed pieces of information that authenticate a secure server by verifying the connection between a server's encryption scheme and the server's identification. Cryptographic checks, using digital signatures, ensure that the validity of certificates can be absolutely trusted.
Certificates are issued by third parties called certificate authorities. To obtain a certificate for your site, you must contact a certificate authority and register with it. The authority will verify that you are who you claim to be and then will create a digital certificate that is unique to you. There is usually a fee associated with this for businesses. For more information on certificates, check out the VeriSign Web site at http://www.verisign.com.
A public-domain encryption scheme, Pretty Good Privacy, developed by Phil Zimmerman of the Massachusetts Institute of Technology is, as the name implies, good enough for most personal online data-encryption needs, including encrypted electronic mail. To date, PGP has been used mainly for encrypted electronic mail, but its use may expand now that a conflict between the U.S. government and Zimmerman (the government claimed that PGP is so powerful, it could be used by subversive foreign powers without the knowledge of the U.S. authorities) has finally been straightened out. You can get more information and PGP software at http://www.pgp.com/.
Like the carpet-defending mother who made you take your shoes off outside after playing in the mud, firewalls protect your network from the dangers of tracked-in data. Named for the fireproof barrier between the engine compartment and passenger cabin of an automobile or airplane, network firewalls form a barrier that's supposed to be (and is, if you do it right) impervious to attempts to get through it.
A firewall is a computer through which all data entering or leaving a local area network (LAN) en route to or from the Internet must pass. In their role as gatekeepers, firewalls work like two-way filters, allowing certain data to pass out of the LAN and allowing other data (usually much more restricted) to pass from the Internet into the LAN.
For example, a firewall might be set up to protect an intranet. People logged on to the intranet could do whatever they wanted on the Internet--their Web requests would pass out through the firewall and data could come into the intranet in response to those requests. Users could send Internet electronic mail out through the firewall. They also could send out Gopher, Telnet, and FTP requests through the firewall and receive data in response to those requests.
But the firewall's filter is much less porous in the other direction. In most cases, firewalls are configured to allow nothing but electronic mail to come inside the firewall unsolicited. Everything else, such as Telnet and Web data, must enter in response to a request that went out from a legitimate user inside the network.
In cases in which an organization's public Web server is protected by a firewall, the firewall needs to be configured to allow Web data requests to pass from the Internet to the public Web server.
ON THE WEB: For more information about firewalls, look at the Firewalls FAQ at http://faq.sph.umich.edu/faq/files/firewalls-faq, or at Kathy Fulmer's list of firewall tools developers at http://www.greatcircle.com/firewalls/vendors.html.
The key to implementing a firewall lies in the configuration files of the computer (usually a packet router) that functions as the physical firewall.
So, to set up a firewall, you need to install a dedicated router between the network you're protecting and the potentially hostile network (the Internet, most often) so all data passing between the two networks must pass through the router. This is a physical process--make sure all the wires coming into your network bearing Internet data pass through the router first.
Second, you need to set the router's configuration files to correspond to the rules you've set up for data exchange. A typical set of data-exchange rules looks like this:
Forewarned is forearmed--an old saw that holds true for computer networks more than in any other field. Once you've installed a security system, don't sit back and assume your information is safe. The bad guys aren't getting any dumber. Instead, constantly test and refine your security system to make sure it will stand up against the latest break-in techniques.
There are several techniques for testing the security of a site. Some of the most popular are described in this section.
On the logic that the best way to get site administrators to improve their sites' security is to make their security weaknesses blindingly obvious to everyone, SATAN (Security Administrator's Tool for Analyzing Networks) was released to the public.
SATAN looks at any UNIX-based network site and points out ways in which evil-minded people could circumvent security and illegally exploit system resources. SATAN derives its knowledge from publicized information of bugs in systems and so will refer you to fixes for any troubles it detects, if any fixes are available to you. SATAN features a friendly interface, giving output as HTML documents that are viewable with practically any Web browser.
Incidentally, Dan Farmer, the author of SATAN, did an informal security survey of about 2,200 Web sites in January 1997. He found that about three-quarters of the surveyed sites--many of them bank sites and other high-profile sites--had "serious security flaws."
ON THE WEB: http://www.interaus.net/1995/6/satan.html You can read more about SATAN here.
SATAN is a useful tool for administrators trying to flush out security weaknesses, but it detects only fairly well-known security flaws. What happens when your site is crackable, but only by a very skilled operator with highly specialized and current information? Generally, you won't find out about a security breach until it's too late.
That's why many organizations, mainly those with lots of valuable information to protect, hire people to try to break into their systems and, when they succeed (and they usually do), tell the organizations how to head off similar attacks in the future. The "Tiger Teams"--ultra-secret, cracking squads employed by the National Security Agency and Department of Defense--regularly challenge Pentagon computers.
If you have sufficiently valuable information on your network, there's no more certain way to test its safety than with a trained break-in artist.
© Copyright, Macmillan Computer Publishing. All rights reserved.