Considerations for LAN and Internet Security

Gary C. Kessler and Carol A. Monaghan
February 1997

An edited version of this paper is scheduled to appear in the Handbook on Local Area Networks, to be published by Auerbach in August, 1997. © Auerbach, 1997.

Introduction

In an ideal world there would be no need for network or computer security. There would be no threats to your information. No one would be trying to break into any of your systems. There would be no disgruntled employees, competitors would not be trying to steal your secrets, and people with the smarts necessary to break into computer systems and create viruses would be working on more constructive endeavors. Unfortunately we do not live in an ideal world and, therefore, we do have to be concerned with security, possible break-ins, viruses, attacks from the Internet, and even security breaches from inside our own network.

Life today runs on information. As a resource for business, academics, government, personal finance, or leisure activities, up-to-date, correct information is key to any successful endeavor. While this has been true for hundreds of years, it has never as true as in the last half of the 20th century, with the invention of the modern digital computer.

In the not so distant past, the most common computing scenario at a corporation or university was to have a single mainframe computer. The system was locked away in a special room in a fairly secure building. Only authorized personnel were allowed to be anywhere near the machine. Computing policies were created centrally by the appropriate administration and implemented by the system administrator.

With the advent of minicomputers, individual smaller systems found their way to the departmental level. But even then, they were usually tucked away in a locked room and someone was the designated system manager. In most cases, the minicomputers were not connected to each other nor to the central mainframe.

All of this changed with the vast proliferation of microcomputers in the 1980s. Personal computers (PCs¹) landed on people's desktops, providing more efficient computing than central minicomputers and mainframes. At this point we see that every user has, in essence, become a system manager.

But PCs are most effective when interconnected and the late-1980s saw the proliferation of local area networks (LANs). It is very hard to implement centralized policies for every host on a LAN since only the servers are generally administered by the network manager; in a peer-to-peer LAN, central administration may be impossible since every host can be a server. And what most users do not realize — because it is not generally pointed out to them — is that if even a single user violates the security policies, all systems on the network may be put at risk.

As the Internet grew in popularity within the commercial arena in the early 1990s, there was explosive growth in the number of LANs connected to the Internet; a new network is connected to the Internet roughly every half-hour. The problem of Internet vulnerability is considerably greater than that of a single organization's network. First, no one owns the Internet. Second, there is no central Internet authority to create, much less enforce, any particular policies. The Internet is a collection of over 100,000 individual networks, comprising over 16 million host computers; the compromise of a single one puts all others at risk.

The "security" problem, then, is one of protecting our information assets, both private and public. Providing solutions and safeguards is relatively easy. The harder problem is educating users about the risks and consequences if information is stolen, compromised, or lost; their role in a secure environment; and the tools that are available. Many users think that all this fuss about security is the result of paranoia or the system/network manager's attempt to wield additional power. But not just money and jobs are at stake; in some cases, deliberate information compromise has resulted in loss of life.

This chapter will discuss issues related to LAN security. Rather than focusing only on the LAN and/or the Internet, we will provide a broad look at several aspects of security. First, many users and even site administrators think that the only serious security threat is from the outside; while protecting the LAN from external threats is critical, that is only one aspect of a more general site security vision. TCP/IP, the "language" of the Internet, is the source of many potential security vulnerabilities which are discussed. Firewalls are an important tool in protecting a private network connected to the Internet. And passwords, the most common form of "security" today in many environments, is examined.

Site Security Policies

Before implementing any security tools, software, or hardware, you must have some sort of site security plan. The plan may be short and sweet or long and involved, but having such a plan is essential. When setting out to develop your site security plan, you must consider a number of different factors. First, what is it you are trying to protect? Second, what you are protecting it from? Finally, how much of a threat is there? After you have determined your risks and exposures, you can then create a site security plan. Once your plan is in place you must make sure that it does not become static; it should be reviewed frequently and modified where appropriate.

Determining what you are protecting should be a fairly straight forward process; public-domain information mirrored on your Web server is not as much of an exposure as your corporate and client records on the LAN server. You must then examine your environment to determine what you are protecting your network from. In days past the norm was to have a large centralized computer locked away in a computer center. Dumb terminals were connected to that large computer, so you just had to be concerned with the security of a single system, usually in a single room. In addition, there were few connections to sites outside of your own. In today's world of distributed computing, things are quite different. In most cases there is no longer just one machine to protect (although servers are often co-located in a just a few areas) and with the success of the Internet, many sites now have access to the world outside of their network.

When examining your site to determine the level of threat and possible exposure, one place to start is with the physical risks. Is your building secure? Are the rooms where you store your most vital equipment secure? Do you have locks on the doors or can anyone walk into those rooms? Are the systems themselves protected? Are the keyboards locked? Do you need a password before you can extract or change any information?

Intertwined with your examination of your network is the idea of risk analysis. You must determine the risks of a security breach and a cost-effective way to address those risks. You must make sure that what you are protecting is worth the amount of money that you will be spending to protect it. If, for example, a security breach would mean a possible loss of life (such as hospital life support systems or a 911 service) then that site should invest more into their security than an office that can tolerate some possible down time while the situation is addressed.

Once you have determined what you need to protect and the level of protection that you need, you can create a site security policy. One important aspect in this process is to have the backing of upper management. If you establish a thorough, well thought out policy that no one follows and that you cannot enforce, you are no better off than having no policy at all. By having a buy-in from management, you will have more support in exercising the policies. In addition, there must be a consequence for users that do not follow the policies; otherwise, the policy document becomes an option which users will choose to follow or not — mostly not. It may be prudent to include a member of management in the policy making team.

Request for Comments (RFC) 1244 is a site security handbook, an excellent place to start when developing a site security policy. This RFC provides guidance to site administrators on how to deal with security issues on the Internet. The guidelines for a plan, however, can be used even in the absence of a connection to any public network.

One of the many reasons to create a site security policy is so that when you are in the middle of a security emergency, you have one source to go to which spells out what actions you should take; the middle of a crisis is hardly the ideal time to be making policy decisions. Having policies set forth ahead of time will ensure that the proper actions are taken in a timely fashion, and is particularly useful if the site manager is not around when the problem occurs.

Additional reasons for having a policy on hand is that users know the acceptable use policies for network resources, users know what role they can play in protecting everyone's information assets, and customers can see that you are serious about protecting their information. Issues ranging from allowing users to share accounts to whether they can attempt to break into other accounts or other networks should be addressed in the plan. You may want to include information about the appropriate use of copyrighted or licensed material. Without written policies, it will be more difficult to take action against a user who has performed an act that you deem contrary to the acceptable use of the resources. The consequence of a user's violation of the security policies should be clearly spelled out in your document.

If a security breach does occur, your document should spell out who must be contacted. Depending on the severity of the incident, law enforcement officials and the press may become involved. The interaction with these organizations and others should be addressed in your plan.

One aspect of a security breach that you should address is whether you want to track down the offender or if your primary response is just to shut the offender out. Cooperating with law enforcement officials or the FBI may involve leaving the door open, so to speak, so that the attacker can be brought to justice. This approach, however, can pose risks to your site while evidence is gathered about the attacker's activities. You should pre-determine, then, which course of action you will take and under what circumstances. You should also be aware of what legal recourse you have, in any case, and what computer crime laws might apply to you. Remember that on the Internet, your local laws may not apply to the locale from where the attack is launched.

Once your document is complete it should be widely publicized within your organization. Users should have the ability to provide feedback on the policy. After the comments have been addressed and any necessary changes have been made, the policy should again be circulated to all users. Any new employees of the company should receive a copy of the plan. It should not be simply filed away as a completed project but should be viewed as a living document.

Now that you have established your security policies, what steps should you take to help protect your environment? One of the most basic and widely used forms of security is through the use of passwords. Passwords are only as effective as the weakest link, however; if users choose very simple passwords or write them down, they can serve as an easy entry into a system. In some environments, password protection is supplemented with devices that provide additional identification, such as smart cards (which may provide you with a one-time password) to fingerprint or retinal scanners. A more detailed discussion of passwords is presented later on in this chapter.

Another major consideration at your site is that of viruses. Viruses are spread today in many ways and a virus can be obtained by opening an executable file received in e-mail, on a disk, downloaded from a bulletin board system (BBS), or obtained from the Internet. The best way to protect against viruses is to make virus scanning software available to every user, make sure that it is updated as often as possible, and make sure that people use that tool properly. In addition, write-access to critical servers should be limited where possible and virus-scanning rules strictly adhered to on those systems.

One popular defense against possible attacks from the Internet is called a firewall. Just as a firewall in a building helps to protect areas behind it against the spread of flames, a firewall in a networking environment serves to protect the machines behind it against an attack from the outside. The basic idea of a firewall is that all access to and from your network is conducted through a single machine or set of machines. If an attack is being launched against your site, the firewall should be able to keep the attack from reaching any systems inside your network. Furthermore, the network administrator has only to tightly secure the firewall(s) to provide an adequate level of security rather than have to depend upon the ability and willingness of every user to protect their systems. A more detailed discussion of firewalls is presented later in this chapter.

Another component that is sometimes overlooked is system backups. It is essential that backups are performed and verified on all of your systems, particularly any repositories with critical information. Backups not only protect you against any hardware errors or natural disasters that may occur, but also allow you to go back to an uncompromised state if an intrusion occurs. In addition, it can serve as a way to track an intruders' actions on your systems.

Now that your policy is in place, and you have examined and modified your security, how do you determine if there has been a security breach? One method is to monitor your systems using some sort of auditing tool, which allows you to monitor the access to, and activity of, your systems. Examining the audit trail will allow you to get a good picture of how your system is used on a day to day basis, so you will be able to recognize something abnormal. User logs should be examined frequently. In some cases, the information in the logs may be tampered with by an intruder and the only clue to an intrusion is noticing that the logs have been suspiciously modified.

Even at a site that has extensive security measures in place, a break-in may occur. With a policy in place, at least you will have a clear plan of action; not only will this spell out what needs to be done and by whom, but it can also minimize the damage. During the time after the incident is detected, you should keep a journal of all events that have occurred and all actions that have been taken. This will be vital if the attacker is caught and brought before a court.

The system logs and written journal will help you to review the attack, evaluate your responses and policies, and re-visit your level of protection. After the incident is resolved, you can review your site security policy and determine how effective it was. Were there parts that were missing that you can now fill in? Were there contact names that should have been in the document? Are there entire sections that should be rewritten entirely now that you have a greater understanding of what is needed? Whatever the case may be, you should learn from the experience and be more prepared for the future.

Security Weaknesses Associated With TCP/IP

The Transmission Control Protocol/Internet Protocol (TCP/IP) suite is the common bond of all systems on the Internet. Therefore, when a LAN is attached to the Internet, every system on the LAN that is to have Internet access must run TCP/IP.

In most cases today, TCP/IP is not the communications protocol already in use on the LAN; Apple's AppleTalk, Microsoft's NetBIOS (Network Basic Input/Output System), and Novell's NetWare are far more common. To obviate the need for the user to select the communications protocol at boot time, most LAN-based systems today employ a dual stack, where a native LAN protocol and TCP/IP are both supported. A protocol manager, such as Microsoft's NDIS (Network Driver Interface Specification) or Novell's ODI (Open Data link Interface), is employed so that the communications protocol actually being used for any particular application is transparent to the user.

But TCP/IP, by it's nature, is not currently a secure protocol suite.² This is not due to lack of ability on the part of the protocol designers, but was due to the desire to have open, flexible communications capabilities. TCP/IP was also designed for a "friendly" network, namely, the ARPANET. As more and more users have connected to the Internet, however, the 'Net has become a more hostile environment and some nefarious individuals have taken advantage of a number of potential weaknesses in the TCP/IP protocols themselves and/or vendors' implementations. Some of the documented weaknesses of TCP/IP include:

• Passwords sent in the clear: In many TCP/IP applications, such as Telnet (remote host access), File Transfer Protocol (FTP), and Post Office Protocol (POP), the password is sent in an unencrypted fashion over the LAN and Internet. An eavesdropper can potentially obtain usernames and passwords.
• Buffer overflow: Several applications, such as sendmail (UNIX), finger (returns information about a remote host or user), and Hypertext Transfer Protocol (HTTP, the protocol for the World Wide Web), do not ensure that user input fits into the buffer that the program allocates. It is possible, in some situations, to send more data to an application than the buffer was designed to accept; if that data is substitute code, the attacker can gain control of the server. This form of attack was the basis for the Internet worm that brought the Internet down for several days in November 1988.
• IP address spoofing/TCP Initial Sequence Number (ISN) guessing: Every IP packet contains the host addresses of the sender and intended receiver. Some applications only accept packets from "trusted" hosts, a determination made by examining the source address carried in the packet. Unfortunately, there is little in most TCP/IP software implementations that would prevent someone from placing any address that they want in the packet's Source Address field. Thus, any host can pretend to have any address. Of course, for a TCP connection, spoofing the host address is not sufficient; the attacker has to be able to establish a virtual connection with the target host. When a virtual circuit is created in a TCP environment, the two hosts need to synchronize the Initial Sequence Number of the bytes to be exchanged; this value is almost never 0 and, in fact, changes over time. Due to the vagaries of TCP implementations, however, the ISN can be guessed by an attacker. Using a combination of IP address spoofing and TCP ISN guessing, an attacker can gain privileged access to a server even though the initial packets never get back to the attacker's system. This type of attack was the basis for the now infamous episode in late-1994 and early-1995 when Kevin Mitnick allegedly broke into Tsutomu Shimomura's systems at the San Diego Supercomputer Center (SDSC).
• TCP Synchronization (SYN) flooding: When a TCP virtual circuit is being established, a "three-way handshake" is performed; the initiating host sends a request to establish the connection, the destination responds with a "half" acknowledgment, and the first host responds with a confirmation that the connection is set. The destination host waits for this final confirmation; if none is forthcoming within a few seconds, the destination deallocates buffers and will accept other connections. In a SYN flooding attack, the attacking host continuously sends thousands of setup requests each second, usually with a spoofed source address. The destination host, meanwhile, responds with an acknowledgment for every request that it can and waits for the confirmations that are never going to come in. The target host is essentially frozen; it is spending all of its processing time and resources trying to respond to what it does not know are illegitimate requests, and could not effectively handle a legitimate connection, even if one were to get through. This type of denial-of-service attack was launched against Panix, an Internet service provider in New York, in September 1996.
• Small fragments: Many router and firewall filters only act on the first part (fragment) of a larger message and take no action on any fragment that contains the remainder of the message; the thought here is that if the first fragment is accepted, then the rest of the message is also acceptable and if the first fragment was discarded, the rest of the message is meaningless. But if an attacker sends an IP datagram that is so short as to not contain any higher layer information, it may erroneously be passed through the filers.
• World Wide Web spoofing: In this attack, a user's WWW traffic is maliciously re-routed to a bogus WWW server that pretends to be the legitimate target system. The bogus server can collect username, password, and other information. As a "person-in-the-middle" attack, the bogus system may collect the information without ever disturbing either the user or the legitimate target server.

The vulnerabilities described above are well-known and are, indeed, weaknesses in the protocols that are being (and, in some cases, have been) fixed. But some of the perceived "weaknesses" are part of TCP/IP's design philosophy. Consider e-mail spoofing, shown in Figure 1. In this scenario, a user connects to the Simple Mail Transfer Protocol (SMTP) port at host mail.foo.com, identifies itself (ramp.able.net), and then sends mail reportedly from the President of the United States. Why does this work? Because SMTP does not verify the identity of the sender.

> telnet mail.foo.com 25
SMTP spoken here...
SMTP> helo ramp.able.net
Pleased to meet you...
SMTP> mail from: <president@whitehouse.gov>
Sender ok...
SMTP> rcpt to: <g.kessler@hill.com>
Recipient ok...
SMTP> data
Enter mail, end with "."
Hi Gary. Thanks for your vote. Bill.
.
SMTP> quit
>

FIGURE 1. Sample SMTP e-mail dialogue.

But is this a bug or a feature? As a "bug," it lets anyone send mail pretending to be anyone else. As a "feature," it allows a host to forward to another host mail that did not originate locally, providing a tremendous amount of flexibility and robustness. Again, recall that this capability was designed when the Internet was a smaller, safer place.

Firewalls

As suggested above, firewalls may be used to protect a local network from purposeful or accidental intrusions from the outside. Although most closely associated with the Internet, firewalls can be used for more protocols than just TCP/IP and, therefore, could have applicability to a variety of network interconnection scenarios.

For purposes of a LAN connected to the Internet, firewalls can be generally classified into three types:

• Packet filters block packets based upon the protocol, address, and/or port identifier
• Application gateways filter traffic using application-specific rules.
• Circuit gateways act as a TCP relay; an external remote host connects to a TCP port at the gateway and the gateway, in turn, establishes a TCP connection to the intended destination on the internal local network. One type of circuit gateway is a proxy server, which can act transparently as an agent for one or more services, allowing the real server(s) and real data to be protected while only exposing the proxy system.

In practice, more than one of these gateway types may be used together. Figure 2 shows one possible configuration of Internet information servers and firewall implementations. The user's network is divided into two subnetworks, the so-called outside network and inside network. The outside network, or demilitarized zone (DMZ), only has public Internet information servers attached to it. These public servers are "sacrificial" systems because they do not contain critical information and they do provide access to the user's inside network. The Bastion host (probably with proxy agents for all supported applications) acts as a gateway for all incoming and outgoing traffic between the user's trusted systems (which are all attached to the inside network; the servers on the outside network are not trusted) and the Internet. This configuration provides a moderate level of security; both more and less secure (and costly) firewall/Bastion host/server configurations are possible.

                              |  ---------------    |  ----
     ()                       |  |   Public    |    |--|PC|
    (  )                      |--|"Sacrificial"|    |  ----
   (    )                     |  | Information |    |
  (      )                    |  |   Server    |    |  ----
 (        )                   |  ---------------    |--|PC|
(          )      ----------  |                     |  ---- 
( Internet )------| Router |--|                     |
(          )      ----------  |                     |  -------------
 (        )                   |                     |  |  Private  |
  (      )                    |       ---------     |--|Information|
   (    )                     |-------|Bastion|-----|  |  Server   |
    (  )                      |       | Host  |     |  -------------
     ()                       |       ---------     |
                              |                     |

                           Outside                Inside
                           Network                Network

FIGURE 2. One possible configuration of public and private Internet information servers, a firewall, and corporate LAN.

A detailed examination of firewalls is beyond the scope of this chapter, but it is instructive to describe some packet filtering rules because of the widespread use of this mechanism. Packet filtering, most often implemented directly in the router connecting the LAN to the Internet, offers a deceptively simple protection mechanism; while it is easy to install a set of packet filtering rules, it is often difficult to define the correct set of rules in the first place.

permit  in   icmp  any                    192.168.210.0/24
permit  out  icmp  192.168.210.0/24        any

permit  in   tcp  any                     192.168.210.5/32 eq www
permit  out  tcp  192.168.210.5/32 eq www  any                     estab

permit  in   tcp  any             eq www  192.168.210.0/24         estab
permit  out  tcp  192.168.210.0/24         any             eq www

FIGURE 3. Sample packet filtering rules for ICMP and World Wide Web traffic.

Figure 3 shows a small subset of packet filtering rules that might be implemented at a router. Each rule contains the following information:

• Whether a packet matching the rule will be allowed through (permit) or blocked (deny).
• Whether the rule applies to packets coming into the LAN from the outside (in) or going out from the LAN (out).
• The protocol to which the rule applies (e.g., IP, TCP, UDP, ICMP).
• The source address and, optionally, the port number indicating the higher layer application at the source, followed by the destination address and, optionally, the port number indicating the higher layer application at the destination. The addresses may refer to any 32-bit address (any) or to a specific IP address with an indication of the number of relevant bits to examine for this rule.
• Flags, such as an indication of checking to be sure that a virtual circuit is already in place (estab).

Given this information, how would the rules in Figure 3 be interpreted? In these examples, assume that the local network has an IP class C address³ of 192.168.210.0 and that the network's public WWW server has the address 192.168.210.5.

• The first rule pair refers to the Internet Control Message Protocol (ICMP), a companion protocol to IP that notifies hosts of miscellaneous information or errors. This rule pair allows ICMP packets through the router in both directions; inbound packets can come from any IP host as long as they are addressed to some host in the 192.168.210.0 domain and outbound packets can go to any IP host as long as they come from a host in the 192.168.210.0 domain.
• The second set of rules allow any WWW packets ("eq www") to come in from any Internet host as long as they are directed to the local Web host (192.168.210.5). In addition, the Web server can send WWW packets to the outside out as long as the packet is part of a connection has already been established; what this means is that the local server cannot initiate a connection to the outside but must respond to prompting from the outside (a security protection).
• The final rule pair allows WWW traffic from any local host to any Web server on the Internet. Note that incoming WWW traffic is only allowed if the logical connection has been established so that an external Web server cannot initiate a connection with an internal host; as above, this is a security consideration.

Note that TCP/IP protocols and applications are being used on the corporate private information servers maintained on the inside network. Use of TCP/IP for private information servers has led to a new buzzword, namely intranet. In general, intranets are private and protected from outside users. Of course, there may be information on an internal server that you would like to make known to the outside; this has given rise to yet another new term, extranet, or extended intranet.

The information presented above is fine for information servers that can be accessed via TCP/IP protocols. But what about the original LAN servers running non-TCP/IP protocols? A potential thorn in the security manager's side is the issue of placing Internet servers on the LAN and/or placing LAN servers on the Internet. Many firewall products, although created originally to serve the TCP/IP market, also have the capability to handle the communications protocols associated with AppleTalk and NetWare; this is particularly true with the packet filtering capabilities of most routers.

Another approach, commonly known as an air gap is to totally segregate the Internet servers and LAN servers, at least in a protocol sense. In this approach, Internet servers only use TCP and the LAN servers only use the LAN protocols. In this way, the LAN servers may be safe even if an attacker does gain control over a TCP/IP system since the TCP/IP system does not have the LAN's communications protocols. Note, however, that an air gap is not as solid as a firewall and there are a number of ways in which an attacker can get around this, such as downloading the LAN's communications protocols and installing them on the compromised system!

Passwords And Secure Communications

Passwords are the most common mechanism used to control access to computer systems and applications. Passwords are widely used because they are simple, inexpensive, and convenient to use and implement. But they are also well-known as being an extremely poor form of protection; it is estimated that over 80% of the Internet's security incidents are related to poorly chosen passwords. The problem is a large one on the Internet because a skillful intruder may break into one system and never harm it, using it instead as a platform for attacks on many other systems.

RFC1244, as part of the site security plan, offers a number of guidelines for selecting and maintaining passwords. Unfortunately, users are notoriously bad about choosing passwords; some studies suggest that simple password guessing will succeed 90% of the time on a system with as few as 16 user accounts. Rules of thumb for selecting passwords include:

• Never use the name of yourself, your spouse, your significant other, your children, your friend, or your pet, or any other easily obtainable information about you, in any form.
• Never use a word from any language as a password.
• Use at least six characters in your password, employ mixed-case characters, and include at least two non-alphanumeric characters.
• Never tell anyone your password.

The system manager should also take an active role in managing passwords to do more than just assign them. If the mechanism exists, passwords should have an expiration date; a 90-day period is common although some sites expire passwords monthly. When changed, passwords should not be able to be reused for at least some number of years. If available, a blacklisting mechanism — which shuts off an account after some small number of invalid login attempts — should be employed to deter, and limit the success, of password-guessing.

Be careful when using programs that automatically generate passwords. One such system assigned one of the authors of this chapter the password hqTtZ2w and could not be changed; it also couldn't be remembered! Another such system assigned the password red*zoo which is surprisingly easy to remember and relatively safe. The bottom-line is that hard-to-remember passwords will be written down and can become as much, or more, of a threat as a poorly user-selected password.

As a final note, properly chosen passwords can provide extraordinary protection. Most systems store passwords in some encrypted form; in effect, then, the password is a key to a cryptographic system. The security of a cryptographic systems increases as the key size increases, suggesting that passwords are more secure as they grow longer.

While there is mathematical truth in this observation, it must be balanced with the weaknesses due to the limitations imposed by some computer systems and the way in which people choose their passwords. Most Unix systems, for example, limit passwords to eight characters in length, but only use the seven most significant bits of each character as the encryption key. NetWare's passwords, as another example, are case-insensitive, eliminating the benefit of mixing upper and lower case.

The limitations imposed by the operating systems must be coupled with the types of passwords chosen by the users. Most people do not use control characters or non-alphanumeric characters in their passwords; in fact, most users only use lowercase letters. Many people choose a name or word as a password, yielding an even more limited set of encryption keys, in a statistical sense.

Why does any of this matter? Because if your password file is stolen, such as from a directory without adequate protection, an off-line attack can be launched by encrypting every possible word and looking for a match; this is called a dictionary attack. Table 1 shows the amount of time required to perform an exhaustive search of all possible keys with a processor able to examine one million keys per second. Clearly, longer passwords provide better protection than shorter ones. But care must be taken so that a wider combination of character combinations are used to obtain the best possible protection. A truly random 8-character password, for example, might withstand an attack for over a half-billion years, but the password patterns of most users suggest that an 8-character password is only safe for a month.

Better protection can be provided by use of secure protocols over the local network or the Internet. Secure protocols offer a variety of functions:

• Authentication, the process of proving one's identity. In any secure communication, both parties must prove to the other that they are who they purport to be. The primary forms of host-to-host authentication on the Internet today are name-based or address-based, both of which are notoriously weak.
• Privacy, or confidentiality, to ensure that only the intended receiver can read the message.
• Integrity, to assure the receiver that the message has not been altered in any way.
• Authorization, the mechanism used to ensure that only users or hosts with permission access network or other information resources.⁴
• Non-repudiation, the ability to prove that the sender really sent the message.
• Audit, the ability to track and record all messages sent in the network.

A variety of cryptographic schemes are used to provide the functions listed above. Cryptographic algorithms are generally classified as follows:

• Hash functions: Also called message digests, hash functions perform one-way encryption, taking a message and mathematically transforming it in such a way that the original message cannot be recovered from the hash value.
• Secret-key cryptography: Also called single-key or symmetric cryptography, these schemes uses a single key to both encrypt and decrypt messages.
• Public-Key cryptography: Also called asymmetric cryptography, these schemes require two keys, one to encrypt messages and the other to decrypt messages. One of the keys is kept secret by the user and called the private key, while the other is publicly distributed and called the public key.

Table 2 summarizes some of the more common protocols used for secure communications. The underlying mathematics for all of these protocols are well-documented in the literature and that is one of the reasons that these schemes are believed to be secure; well-known algorithms have received a great deal of scrutiny and age is the best test of a cryptographic algorithm. In general, users are advised to not trust "secret" cryptographic protocols; a high level of cryptographic security is provided by the choice of the key, not the secrecy of the algorithm.

Conclusion

As the number of people using your corporate computing and communications resources grows, so does your vulnerability. When you attach your LAN to the public Internet, your exposure increases even more. Computer and network managers should employ as much security as is affordable, determined by putting a price tag on the level of risk, the amount of exposure, and the cost of the corruption, theft, or loss of your organization's data. In particular, critical information must be protected as much as possible. Internal and external information servers should be isolated from each other. And all users should be made to understand their role in helping to keep the site secure and the information safe.

When connecting a LAN to the public Internet, some form of firewall protection, such as packet filtering and/or proxy servers, should be employed. Be forewarned, however, that many sites employ a "security through obscurity" philosophy; they maintain a low profile on the Internet, don't advertise host names, don't advertise user names, etc. This approach is doomed to fail in the long run since there are very few secrets on the Internet.

While this discussion of security has emphasized the Internet, do not be lulled into a false sense of security because the firewall is in place. Indeed, some studies have concluded that the vast majority — up to 80% — of the break-ins at a site are inside jobs. While the firewall may protect you from the outside, all of the potential problems that existed before the LAN was connected to the Internet are still present. Organizations must still take adequate precautions to physically protect your computer and network site, and take steps to stop unauthorized access to facilities and network resources. Indeed, the thief who stole a computer from the headquarters building of Visa International in November 1996 may have done more potential damage than a hacker could have given Visa's generally tight network security. Physical site security is a particular concern at academic sites where the public has access to terminals and PCs, and only the network or computer may be able to stop the unauthorized user.

Remember: There are no secure sites, only vigilant ones.

References And Further Reading

Bellovin, S.M. "Security Problems in the TCP/IP Protocol Suite." Computer Communications Review, May 1989.

Chapman, D.B. and E.D. Zwicky. Building Internet Firewalls. Sebastopol (CA): O'Reilly & Associates, 1995.

Cheswick, W.R. and S.M. Bellovin. Firewalls and Internet Security: Repelling the Wily Hacker. Reading (MA): Addison-Wesley, 1994.

Cohen, F.B. Protection and Security on the Information Superhighway. New York: John Wiley & Sons, 1995.

Farmer, M. and W. Venema. "Improving the Security of Your Site by Breaking Into It." URL: http://www.alw.nih.gov/Security/Docs/admin-guide-to-cracking.101.html. Last accessed: 24 January 1997. URL: ftp://ftp.win.tue.nl/pub/security/admin-guide-to-cracking.101.Z. Last accessed: 24 January 1997.

Feit, S. TCP/IP: Architecture, Protocols, and Implementation with IPv6 and IP Security, 2nd ed. New York: McGraw-Hill, 1997.

Holbrook, P. and J. Reynolds, Editors. Site Security Handbook. FYI 8, RFC 1244, CICNet, ISI, July 1991. (Available on the Internet at ftp://ds.internic.net/rfc/rfc1244.txt.)

Icove, D., K. Seger, and W. VonStorch. COMPUTER CRIME: A Crimefighter's Handbook. Sebastopol (CA): O'Reilly & Associates, 1995

Kaufman, C., R. Perlman, and M. Speciner. Network Security: Private Communication in a Public World. Englewood Cliffs (NJ): Prentice Hall PTR, 1995.

Kessler, G.C. "Build Great Firewalls." Network VAR, June 1995. (A version of this paper titled "Firewall Routers and Packet Filtering" is available on the Internet at http://www.hill.com/library/firewall.html.)

_____. "An Overview of TCP/IP Protocols and the Internet. URL: http://www.hill.com/library/tcpip.html. Last accessed: 1 February 1997.

_____. "Passwords — Strengths and Weaknesses." In: Cavanaugh, J. (ed.). Internet and Internetworking Security. Boston: Auerbach, 1997. (A version of this paper is available on the Internet at http://www.hill.com/library/password.html.)

Macgregor, R.S., A. Aresi, and A. Siegert. www.security: How to Build a Secure World Wide Web Connection. Upper Saddle River (NJ): Prentice Hall PTR, 1996.

National Computer Security Association. "U.S. Computer Crime Law Web Pages." URL: http://www.ncsa.com/ncsalaws/. Last accessed: 6 December 1996.

Pethia, R., S. Crocker, and B. Fraser. Guidelines for the Secure Operation of the Internet. RFC 1281, Software Engineering Institute, Trusted Information Systems, Software Engineering Institute, November 1991. (Available on the Internet at ftp://ds.internic.net/rfc/rfc1281.txt.)

RSA Laboratories. "FAQ 3.0 on Cryptography." URL: http://www.rsa.com/rsalabs/newfaq/home.html. Last accessed: 28 January 1997

Schneier, B. Applied Cryptography, 2nd ed. New York: John Wiley & Sons, 1996.

Shimomura, T. with J. Markoff. Takedown: The Pursuit and Capture of America's Most Wanted Computer Outlaw - By the Man Who Did It. New York: Hyperion, 1996. (See also http://www.takedown.com on the World Wide Web.)

Siyan, K. and C. Hare. Internet Firewalls and Network Security. Indianapolis: New Riders Publishing, 1995.

Spafford, E.H. "The Internet worm program: An analysis." Computer Communications Review, January 1989.

Stevens, W.R. TCP/IP Illustrated, Volume I: The Protocols. Reading (MA): Addison-Wesley, 1994.

Stoll, C. The Cuckoo's Egg: Tracking a Spy Through the Maze of Computer Espionage. New York: Doubleday, 1989.

About The Authors: Gary C. Kessler is a Senior Member of Technical Staff and Director of Information Technology at Hill Associates. Carol A. Monaghan is the Network Administrator at Hill Associates. Their e-mail addresses are kumquat@hill.com and c.monaghan@hill.com, respectively.

Appendix : Security-Related Sites On The Web

COAST Hotlist: Computer Security, Law & Privacy
http://www.cs.purdue.edu/homes/spaf/hotlists/csec-plain.html

Computer Emergency Response Team (CERT)
http://www.cert.org

Computer Security Resource Clearinghouse
http://csrc.ncsl.nist.gov

Forum of Incident Response and Security Teams (FIRST)
http://www.first.org

Jessica Kelley's Computer Security Information Page
http://www.alw.nih.gov/Security/security.html

Marcus Ranum's Security Page
http://www.clark.net/pub/mjr/pubs/index.htm

Mitre's Security Information Resources Page
http://www.mitre.org:80/resources/centers/infosec/public-security-index.html

National Computer Security Association (NCSA)
http://www.ncsa.com

National Security Institute's Security Resource Net
http://www.nsi.org

Raptor Systems' Security Library
http://www.raptor.com/library/library.html

The Rotherwick Firewall Resource
http://www.zeuros.co.uk/firewall/

Sandcastle's Security Page
http://www.sandcastle-ltd.com/security.html

Symantec's Virus Information Database
http://www.symantec.com/avcenter/vinfodb.html

Trend Micro's Virus Emergency Room
http://www.anitivirus.com

Footnotes

1. Read PC to include DOS-based and Macintosh computers, as well as other microprocessor-based systems. [Back to main text]
   
   
2. The current version of IP is called "IP version 4" (IPv4). A new version, IPv6, will have more security, and other, features. IPv6 is the topic of another paper at http://www.hill.com/library. [Back to main text]
   
   
3. Recall that an IPv4 address is 32 bits in length. In a class C address, the first 24 bits refer to the Network Identifier and the remaining 8 bits are the Host Identifier.[Back to main text]
   
   
4. Authentication is often confused with authorization; the former means that you are who you say you are while the latter refers to what you are allowed to do. E.g., if a user claiming to have the username gary logs onto the server and executes the command to delete HOSTS.TXT, the server has to deal with two issues: is this user really gary (authentication) and is Gary allowed to delete the HOSTS.TXT file (authorization)? [Back to main text]