Maximum Security:

A Hacker's Guide to Protecting Your Internet Site and Network

Previous chapterNext chapterContents


5

Is Security a Futile Endeavor?

Since Paul Baran first put pen to paper, Internet security has been a concern. Over the years, security by obscurity has become the prevailing attitude of the computing community.

These principles have not only been proven faulty, but they also go against the original concepts of how security could evolve through discussion and open education. Even at the very birth of the Internet, open discussion on standards and methodology was strongly suggested. It was felt that this open discussion could foster important advances in the technology. Baran was well aware of this and articulated the principle concisely when, in The Paradox of the Secrecy About Secrecy: The Assumption of A Clear Dichotomy Between Classified and Unclassified Subject Matter, he wrote:

Without the freedom to expose the system proposal to widespread scrutiny by clever minds of diverse interests, is to increase the risk that significant points of potential weakness have been overlooked. A frank and open discussion here is to our advantage.

Security Through Obscurity

Security through obscurity has been defined and described in many different ways. One rather whimsical description, authored by a student named Jeff Breidenbach in his lively and engaging paper, Network Security Throughout the Ages, appears here:

The Net had a brilliant strategy called "Security through Obscurity." Don't let anyone fool you into thinking that this was done on purpose. The software has grown into such a tangled mess that nobody really knows how to use it. Befuddled engineers fervently hoped potential meddlers would be just as intimidated by the technical details as they were themselves.

Mr. Breidenbach might well be correct about this. Nevertheless, the standardized definition and description of security through obscurity can be obtained from any archive of the Jargon File, available at thousands of locations on the Internet. That definition is this:

alt. 'security by obscurity' n. A term applied by hackers to most OS vendors' favorite way of coping with security holes--namely, ignoring them, documenting neither any known holes nor the underlying security algorithms, trusting that nobody will find out about them and that people who do find out about them won't exploit them.

Regardless of which security philosophy you believe, three questions remain constant:

Why Is the Internet Insecure?

The Internet is insecure for a variety of reasons, each of which I will discuss here in detail. Those factors include

Each of these factors contributes in some degree to the Internet's current lack of security.

Lack of Education

Do you believe that what you don't know can't hurt you? If you are charged with the responsibility of running an Internet server, you had better not believe it. Education is the single, most important aspect of security, one aspect that has been sorely wanting.

I am not suggesting that a lack of education exists within higher institutions of learning or those organizations that perform security-related tasks. Rather, I am suggesting that security education rarely extends beyond those great bastions of computer-security science.

The Computer Emergency Response Team (CERT) is probably the Internet's best-known security organization. CERT generates security advisories and distributes them throughout the Internet community. These advisories address the latest known security vulnerabilities in a wide range of operating systems. CERT thus performs an extremely valuable service to the Internet. The CERT Coordination Center, established by ARPA in 1988, provides a centralized point for the reporting of and proactive response to all major security incidents. Since 1988, CERT has grown dramatically, and CERT centers have been established at various points across the globe.


Cross Reference: You can contact CERT at its WWW page (http://www.cert.org). There resides a database of vulnerabilities, various research papers (including extensive documentation on disaster survivability), and links to other important security resources.

CERT's 1995 annual report shows some very enlightening statistics. During 1995, CERT was informed of some 12,000 sites that had experienced some form of network-security violation. Of these, there were at least 732 known break-ins and an equal number of probes or other instances of suspicious activity.


Cross Reference: You can access CERT's 1995 annual report at http://www.cert.org/cert.report.95.html.

12,000 incidents with a reported 732 break-ins. This is so, even though the GAO report examined earlier suggested that Defense computers alone are attacked as many as 250,000 times each year, and Dan Farmer's security survey reported that over 60 percent of all critical sites surveyed were vulnerable to some technique of network security breach. How can this be? Why aren't more incidents reported to CERT?


Cross Reference: Check out Dan Farmer's security survey at http://www.trouble.org/survey.

It might be because the better portion of the Internet's servers are now maintained by individuals who have less-than adequate security education. Many system administrators have never even heard of CERT. True, there are many security resources available on the Internet (many that point to CERT, in fact), but these may initially appear intimidating and overwhelming to those new to security. Moreover, many of the resources provide links to dated information.

An example is RFC 1244, the Site Security Handbook. At the time 1244 was written, it comprised a collection of state-of-the-art information on security. As expressed in that document's editor's note: This FYI RFC is a first attempt at providing Internet users guidance on how to deal with security issues in the Internet. As such, this document is necessarily incomplete. There are some clear shortfalls; for example, this document focuses mostly on resources available in the United States. In the spirit of the Internet's `Request for Comments' series of notes, we encourage feedback from users of this handbook. In particular, those who utilize this document to craft their own policies and procedures.

This handbook is meant to be a starting place for further research and should be viewed as a useful resource, but not the final authority. Different organizations and jurisdictions will have different resources and rules. Talk to your local organizations, consult an informed lawyer, or consult with local and national law enforcement. These groups can help fill in the gaps that this document cannot hope to cover.

From 1991 until now, the Site Security Handbook has been an excellent place to start. Nevertheless, as Internet technology grows in leaps and bounds, such texts become rapidly outdated. Therefore, the new system administrator must keep up with the security technology that follows each such evolution. To do so is a difficult task.


Cross Reference: RFC 1244 is still a good study paper for a user new to security. It is available at many places on the Internet. One reliable server is at http://www.net.ohio-state.edu/hypertext/rfc1244/toc.html.

The Genesis of an Advisory

Advisories comprise the better part of time-based security information. When these come out, they are immediately very useful because they usually relate to an operating system or popular application now widely in use. As time goes on, however, such advisories become less important because people move on to new products. In this process, vendors are constantly updating their systems, eliminating holes along the way. Thus, an advisory is valuable for a set period of time (although, to be fair, this information may stay valuable for extended periods because some people insist on using older software and hardware, often for financial reasons).

An advisory begins with discovery. Someone, whether hacker, cracker, administrator, or user, discovers a hole. That hole is verified, and the resulting data is forwarded to security organizations, vendors, or other parties deemed suitable. This is the usual genesis of an advisory (a process explained in Chapter 2, "How This Book Will Help You"). Nevertheless, there is another way that holes are discovered.

Often, academic researchers discover a hole. An example, which you will review later, is the series of holes found within the Java programming language. These holes were primarily revealed--at least at first--by those at Princeton University's computer science labs. When such a hole is discovered, it is documented in excruciating detail. That is, researchers often author multipage documents detailing the hole, the reasons for it, and possible remedies.


Cross Reference: Java is a compiled language used to create interactive applications for use on the World Wide Web. The language was created by efforts at Sun Microsystems. It vaguely resembles C++. For more information about Java, visit the Java home page at http://java.sun.com/.

This information gets digested by other sources into an advisory, which is often no more than 100 lines. By the time the average, semi-security literate user lays his or her hands on this information, it is limited and watered-down.

Thus, redundancy of data on the Internet has its limitations. People continually rehash these security documents into different renditions, often highlighting different aspects of the same paper. Such digested revisions are available all over the Net. This helps distribute the information, true, but leaves serious researchers hungry. They must hunt, and that hunt can be a struggle. For example, there is no centralized place to acquire all such papers.

Equally, as I have explained, end-user documentation can be varied. Although there should be, there is no 12-set volume (with papers by Farmer, Venema, Bellovin, Spafford, Morris, Ranum, Klaus, Muffet, and so on) about Internet security that you can acquire at a local library or bookstore. More often, the average bookstore contains brief treatments of the subject (like this book, I suppose).

Couple with these factors the mind-set of the average system administrator. A human being only has so much time. Therefore, these individuals absorb what they can on-the-fly, applying methods learned through whatever sources they encounter.

The Dissemination of Information

For so many reasons, education in security is wanting. In the future, specialists need to address this need in a more practical fashion. There must be some suitable means of networking this information. To be fair, some organizations have attempted to do so, but many are forced to charge high prices for their hard-earned databases. The National Computer Security Association (NCSA) is one such organization. Its RECON division gathers some 70MB per day of hot and heavy security information. Its database is searchable and is available for a price, but that price is substantial.


Cross Reference: To learn more about NCSA RECON, examine its FAQ. NCSA's database offers advanced searching capabilities, and the information held there is definitely up-to-date. In short, it is a magnificent service. The FAQ is at http://www.isrecon.ncsa.com/public/faq/isrfaq.htm. You can also get a general description of what the service is by visiting http://www.isrecon.ncsa.com/docz/Brochure_Pages/effect.htm.

Many organizations do offer superb training in security and firewall technology. The price for such training varies, depending on the nature of the course, the individuals giving it, and so on. One good source for training is Lucent Technologies, which offers many courses on security.


Cross Reference: Lucent Technologies' WWW site can be found at http://www.attsa.com/.


NOTE: Appendix A, "How to Get More Information," contains a massive listing of security training resources as well as general information about where to acquire good security information.

Despite the availability of such training, today's average company is without a clue. In a captivating report (Why Safeguard Information?) from Abo Akademi University in Finland, researcher Thomas Finne estimated that only 15 percent of all Finnish companies had an individual employed expressly for the purpose of information security. The researcher wrote:

The result of our investigation showed that the situation had got even worse; this is very alarming. Pesonen investigated the security in Finnish companies by sending out questionnaires to 453 companies with over 70 employees. The investigation showed that those made responsible for information security in the companies spent 14.5 percent of their working time on information security. In an investigation performed in the UK over 80 percent of the respondents claimed to have a department or individual responsible for information technology (IT) security.

The Brits made some extraordinary claims! "Of course we have an information security department. Doesn't everyone?" In reality, the percentage of companies that do is likely far less. One survey conducted by the Computer Security Institute found that better than 50 percent of all survey participants didn't even have written security policies and procedures.

The Problems with PC-Based Operating Systems

It should be noted that in America, the increase in servers being maintained by those new to the Internet poses an additional education problem. Many of these individuals have used PC-based systems for the whole of their careers. PC-based operating systems and hardware were never designed for secure operation (although, that is all about to change). Traditionally, PC users have had less-than close contact with their vendors, except on issues relating to hardware and software configuration problems. This is not their fault. The PC community is market based and market driven. Vendors never sold the concept of security; they sold the concept of user friendliness, convenience, and standardization of applications. In these matters, vendors have excelled. The functionality of some PC-based applications is extraordinary.

Nonetheless, programmers are often brilliant in their coding and design of end-user applications but have poor security knowledge. Or, they may have some security knowledge but are unable to implement it because they cannot anticipate certain variables. Foo (the variable) in this case represents the innumerable differences and subtleties involved with other applications that run on the same machine. These will undoubtedly be designed by different individuals and vendors, unknown to the programmer. It is not unusual for the combination of two third-party products to result in the partial compromise of a system's security. Similarly, applications intended to provide security can, when run on PC platforms, deteriorate or otherwise be rendered less secure. The typical example is the use of the famous encryption utility Pretty Good Privacy (PGP) when used in the Microsoft Windows environment.

PGP PGP operates by applying complex algorithms. These operations result in very high-level encryption. In some cases, if the user so specifies, using PGP can provide military-level encryption to a home user. The system utilizes the public key/private key pair scenario. In this scenario, each message is encrypted only after the user provides a passphrase, or secret code. The length of this passphrase may vary. Some people use the entire first line of a poem or literary text. Others use lines in a song or other phrases that they will not easily forget. In any event, this passphrase must be kept completely secret. If it is exposed, the encrypted data can be decrypted, altered, or otherwise accessed by unauthorized individuals.

In its native state, compiled for MS-DOS, PGP operates in a command-line interface or from a DOS prompt. This in itself presents no security issue. The problem is that many people find this inconvenient and therefore use a front-end, or a Microsoft Windows-based application through which they access the PGP routines. When the user makes use of such a front-end, the passphrase gets written into the Windows swap file. If that swap file is permanent, the passphrase can be retrieved using fairly powerful machines. I've tried this on several occasions with machines differently configured. With a 20MB swap file on an IBM compatible DX66 sporting 8-16MB of RAM, this is a formidable task that will likely freeze the machine. This, too, depends on the utility you are using to do the search. Not surprisingly, the most effective utility for performing such a search is GREP.


NOTE: GREP is a utility that comes with many C language packages. It also comes stock on any UNIX distribution. GREP works in a way quite similar to the FIND.EXE command in DOS. Its purpose is to search specified files for a particular string of text. For example, to find the word SEARCH in all files with a *.C extension, you would issue the following command:

GREP SEARCH *.C

There are free versions of GREP available on the Internet for a variety of operating systems, including but not limited to UNIX, DOS, OS/2, and 32-bit Microsoft Windows environments.


In any event, the difficulty factor drops drastically when you use a machine with resources in excess of 100MHz and 32MB of RAM.

My point is this: It is by no fault of the programmer of PGP that the passphrase gets caught in the swap. PGP is not flawed, nor are those platforms that use swapped memory. Nevertheless, platforms that use swapped memory are not secure and probably never will be.


Cross Reference: For more information about PGP, visit http://web.mit.edu/network/pgp.html. This is the MIT PGP distribution site for U.S. residents. PGP renders sufficiently powerful encryption that certain versions are not available for export. Exporting such versions is a crime. The referenced site has much valuable information about PGP, including a FAQ, a discussion of file formats, pointers to books, and of course, the free distribution of the PGP software.

Thus, even when designing security products, programmers are often faced with unforeseen problems over which they can exert no control.


TIP: Techniques of secure programming (methods of programming that enhance security on a given platform) are becoming more popular. These assist the programmer in developing applications that at least won't weaken network security. Chapter 30, "Language, Extensions, and Security," addresses some secure programming techniques as well as problems generally associated with programming and security.

The Internet's Design

When engineers were put to the task of creating an open, fluid, and accessible Internet, their enthusiasm and craft were, alas, too potent. The Internet is the most remarkable creation ever erected by humankind in this respect. There are dozens of ways to get a job done on the Internet; there are dozens of protocols with which to do it.

Are you having trouble retrieving a file via FTP? Can you retrieve it by electronic mail? What about over HTTP with a browser? Or maybe a Telnet-based BBS? How about Gopher? NFS? SMB? The list goes on.

Heterogeneous networking was once a dream. It is now a confusing, tangled mesh of internets around the globe. Each of the protocols mentioned forms one aspect of the modern Internet. Each also represents a little network of its own. Any machine running modern implementations of TCP/IP can utilize all of them and more. Security experts have for years been running back and forth before a dam of information and protocols, plugging the holes with their fingers. Crackers, meanwhile, come armed with icepicks, testing the dam here, there, and everywhere.

Part of the problem is in the Internet's basic design. Traditionally, most services on the Internet rely on the client/server model. The task before a cracker, therefore, is a limited one: Go to the heart of the service and crack that server.

I do not see that situation changing in the near future. Today, client/server programming is the most sought-after skill. The client/server model works effectively, and there is no viable replacement at this point.

There are other problems associated with the Internet's design, specifically related to the UNIX platform. One is access control and privileges. This is covered in detail in Chapter 17, "UNIX: The Big Kahuna," but I want to mention it here.

In UNIX, every process more or less has some level of privilege on the system. That is, these processes must have, at minimum, privilege to access the files they are to work on and the directories into which those files are deposited. In most cases, common processes and programs are already so configured by default at the time of the software's shipment. Beyond this, however, a system administrator may determine specific privilege schemes, depending on the needs of the situation. The system administrator is offered a wide variety of options in this regard. In short, system administrators are capable of restricting access to one, five, or 100 people. In addition, those people (or groups of people) can also be limited to certain types of access, such as read, write, execute, and so forth.

In addition to this system being complex (therefore requiring experience on the part of the administrator), the system also provides for certain inherent security risks. One is that access privileges granted to a process or a user may allow increased access or access beyond what was originally intended to be obtained. For example, a utility that requires any form of root access (highest level of privilege) should be viewed with caution. If someone finds a flaw within that program and can effectively exploit it, that person will gain a high level of access. Note that strong access-control features have been integrated into the Windows NT operating system and therefore, the phenomenon is not exclusively related to UNIX. Novell NetWare also offers some very strong access-control features.

All these factors seriously influence the state of security on the Internet. There are clearly hundreds of little things to know about it. This extends into heterogeneous networking as well. A good system administrator should ideally have knowledge of at least three platforms. This brings us to another consideration: Because the Internet's design is so complex, the people who address its security charge substantial prices for their services. Thus, the complexity of the Internet also influences more concrete considerations.

There are other aspects of Internet design and composition that authors often cite as sources of insecurity. For example, the Net allows a certain amount of anonymity; this issue has good and bad aspects. The good aspects are that individuals who need to communicate anonymously can do so if need be.

Anonymity on the Net

There are plenty of legitimate reasons for anonymous communication. One is that people living in totalitarian states can smuggle out news about human rights violations. (At least, this reason is regularly tossed around by media people. It is en vogue to say such things, even though the percentage of people using the Internet for this noble activity is incredibly small.) Nevertheless, there is no need to provide excuses for why anonymity should exist on the Internet. We do not need to justify it. After all, there is no reason why Americans should be forbidden from doing something on a public network that they can lawfully do at any other place. If human beings want to communicate anonymously, that is their right.

Most people use remailers to communicate anonymously. These are servers configured to accept and forward mail messages. During that process, the header and originating address are stripped from the message, thereby concealing its author and his or her location. In their place, the address of the anonymous remailer is inserted.


Cross Reference: To learn more about anonymous remailers, check out the FAQ at http://www.well.com/user/abacard/remail.html. This FAQ provides many useful links to other sites dealing with anonymous remailers.

Anonymous remailers (hereafter anon remailers) have been the subject of controversy in the past. Many people, particularly members of the establishment, feel that anon remailers undermine the security of the Internet. Some portray the situation as being darker than it really is:

By far the greatest threat to the commercial, economic and political viability of the Global Information Infrastructure will come from information terrorists... The introduction of Anonymous Re-mailers into the Internet has altered the capacity to balance attack and counter-attack, or crime and punishment.1


1Paul A. Strassmann, U.S. Military Academy, West Point; Senior Advisor, SAIC and William Marlow, Senior Vice President, Science Applications International Corporation (SAIC). January 28-30, 1996. Symposium on the Global Information Infrastructure: Information, Policy & International Infrastructure.

I should explain that the preceding document was delivered by individuals associated with the intelligence community. Intelligence community officials would naturally be opposed to anonymity, for it represents one threat to effective, domestic intelligence-gathering procedures. That is a given. Nevertheless, one occasionally sees even journalists making similar statements, such as this one by Walter S. Mossberg:

In many parts of the digital domain, you don't have to use your real name. It's often impossible to figure out the identity of a person making political claims...When these forums operate under the cloak of anonymity, it's no different from printing a newspaper in which the bylines are admittedly fake, and the letters to the editor are untraceable.

This is an interesting statement. For many years, the U.S. Supreme Court has been unwilling to require that political statements be accompanied by the identity of the author. This refusal is to ensure that free speech is not silenced. In early American history, pamphlets were distributed in this manner. Naturally, if everyone had to sign their name to such documents, potential protesters would be driven into the shadows. This is inconsistent with the concepts on which the country was founded.

To date, there has been no convincing argument for why anon remailers should not exist. Nevertheless, the subject remains engaging. One amusing exchange occurred during a hearing in Pennsylvania on the constitutionality of the Communications Decency Act, an act brought by forces in Congress that were vehemently opposed to pornographic images being placed on the Internet. The hearing occurred on March 22, 1996, before the Honorable Dolores K. Sloviter, Chief Judge, United States Court of Appeals for the Third Circuit. The case was American Civil Liberties Union, et al (plaintiffs) v. Janet Reno, the Attorney General of the United States. The discussion went as follows:

Q: Could you explain for the Court what Anonymous Remailers are?

A:
Yes, Anonymous Remailers and their -- and a related service called Pseudonymity Servers are computer services that privatize your identity in cyberspace. They allow individuals to, for example, post content for example to a Usenet News group or to send an E-mail without knowing the individual's true identity.

The difference between an anonymous remailer and a pseudonymity server is very important because an anonymous remailer provides what we might consider to be true anonymity to the individual because there would be no way to know on separate instances who the person was who was making the post or sending the e-mail.

But with a pseudonymity server, an individual can have what we consider to be a persistent presence in cyberspace, so you can have a pseudonym attached to your postings or your e-mails, but your true identity is not revealed. And these mechanisms allow people to communicate in cyberspace without revealing their true identities.

Q: I just have one question, Professor Hoffman, on this topic. You have not done any study or survey to sample the quantity or the amount of anonymous remailing on the Internet, correct?

A:
That's correct. I think by definition it's a very difficult problem to study because these are people who wish to remain anonymous and the people who provide these services wish to remain anonymous.

Indeed, the court was clearly faced with a catch-22. In any case, whatever one's position might be on anonymous remailers, they appear to be a permanent feature of the Internet. Programmers have developed remailer applications to run on almost any operating system, allowing the little guy to start a remailer with his PC.


Cross Reference: If you have more interest in anon remailers, visit http://www.cs.berkeley.edu/~raph/remailer-list.html. This site contains extensive information on these programs, as well as links to personal anon remailing packages and other software tools for use in implementing an anonymous remailer.

In the end, e-mail anonymity on the Internet has a negligible effect on real issues of Internet security. The days when one could exploit a hole by sending a simple e-mail message are long gone. Those making protracted arguments against anonymous e-mail are either nosy or outraged that someone can implement a procedure that they cannot. If e-mail anonymity is an issue at all, it is for those in national security. I readily admit that spies could benefit from anonymous remailers. In most other cases, however, the argument expends good energy that could be better spent elsewhere.

Proprietarism

Yes, another ism. Before I start ranting, I want to define this term as it applies here. Proprietarism is a practice undertaken by commercial vendors in which they attempt to inject into the Internet various forms of proprietary design. By doing so, they hope to create profits in an environment that has been previously free from commercial reign. It is the modern equivalent of Colonialism plus Capitalism in the computer age on the Internet. It interferes with Internet security structure and defeats the Internet's capability to serve all individuals equally and effectively.

ActiveX

A good example of proprietarism in action is Microsoft Corporation's ActiveX technology.


Cross Reference: Those users unfamiliar with ActiveX technology should visit http://www.microsoft.com/activex/. Users who already have some experience with ActiveX should go directly to the Microsoft page that addresses the security features: http://www.microsoft.com/security/.

To understand the impact of ActiveX, a brief look at HTML would be instructive. HTML was an incredible breakthrough in Internet technology. Imagine the excitement of the researchers when they first tested it! It was (and still is) a protocol by which any user, on any machine, anywhere in the world could view a document and that document, to any other user similarly (or not similarly) situated, would look pretty much the same. What an extraordinary breakthrough. It would release us forever from proprietary designs. Whether you used a Mac, an Alpha, an Amiga, a SPARC, an IBM compatible, or a tire hub (TRS-80, maybe?), you were in. You could see all the wonderful information available on the Net, just like the next guy. Not any more.

ActiveX technology is a new method of presenting Web pages. It is designed to interface with Microsoft's Internet Explorer. If you don't have it, forget it. Most WWW pages designed with it will be nonfunctional for you either in whole or in part.

That situation may change, because Microsoft is pushing for ActiveX extensions to be included within the HTML standardization process. Nevertheless, such extensions (including scripting languages or even compiled languages) do alter the state of Internet security in a wide and encompassing way.

First, they introduce new and untried technologies that are proprietary in nature. Because they are proprietary, the technologies cannot be closely examined by the security community. Moreover, these are not cross platform and therefore create limitations to the Net, as opposed to heterogeneous solutions. To examine the problem firsthand you may want to visit a page established by Kathleen A. Jackson, Team Leader, Division Security Office, Computing, Information, and Communications Division at the Los Alamos National Laboratory. Jackson points to key problems in ActiveX. On her WWW page, she writes:

...The second big problem with ActiveX is security. A program that downloads can do anything the programmer wants. It can reformat your hard drive or shut down your computer...

This issue is more extensively covered in a paper delivered by Simon Garfinkel at Hot Wired. When Microsoft was alerted to the problem, the solution was to recruit a company that created digital signatures for ActiveX controls. This digital signature is supposed to be signed by the control's programmer or creator. The company responsible for this digital signature scheme has every software publisher sign a software publisher's pledge, which is an agreement not to sign any software that contains malicious code. If a user surfs a page that contains an unsigned control, Microsoft's Internet Explorer puts up a warning message box that asks whether you want to accept the unsigned control.


Cross Reference: Find the paper delivered by Simon Garfinkel at Hot Wired at http://www.packet.com/packet/garfinkel/.

You cannot imagine how absurd this seems to security professionals. What is to prevent a software publisher from submitting malicious code, signed or unsigned, on any given Web site? If it is signed, does that guarantee that the control is safe? The Internet at large is therefore resigned to take the software author or publisher at his or her word. This is impractical and unrealistic. And, although Microsoft and the company responsible for the signing initiative will readily offer assurances, what evidence is there that such signatures cannot be forged? More importantly, how many small-time programmers will bother to sign their controls? And lastly, how many users will refuse to accept an unsigned control? Most users confronted with the warning box have no idea what it means. All it represents to them is an obstruction that is preventing them from getting to a cool Web page.

There are now all manner of proprietary programs out there inhabiting the Internet. Few have been truly tested for security. I understand that this will become more prevalent and, to Microsoft's credit, ActiveX technology creates the most stunning WWW pages available on the Net. These pages have increased functionality, including drop-down boxes, menus, and other features that make surfing the Web a pleasure. Nevertheless, serious security studies need to be made before these technologies foster an entirely new frontier for those pandering malicious code, viruses, and code to circumvent security.


Cross Reference: To learn more about the HTML standardization process, visit the site of the World Wide Web Consortium (http://www.w3.org). If you already know a bit about the subject but want specifics about what types of HTML tags and extensions are supported, you should read W3C's activity statement on this issue (http://www.w3.org/pub/WWW/MarkUp/Activity). One interesting area of development is W3C's work on support for the disabled.

Proprietarism is a dangerous force on the Internet, and it's gaining ground quickly. To compound this problem, some of the proprietary products are excellent. It is therefore perfectly natural for users to gravitate toward these applications. Users are most concerned with functionality, not security. Therefore, the onus is on vendors, and this is a problem. If vendors ignore security hazards, there is nothing anyone can do. One cannot, for example, forbid insecure products from being sold on the market. That would be an unreasonable restraint of interstate commerce and ground for an antitrust claim. Vendors certainly have every right to release whatever software they like, secure or not. At present, therefore, there is no solution to this problem.

Extensions, languages, or tags that probably warrant examination include

JavaScript is owned by Netscape, and VBScript and ActiveX are owned by Microsoft. These languages are the weapons of the war between these two giants. I doubt that either company objectively realizes that there's a need for both technologies. For example, Netscape cannot shake Microsoft's hold on the desktop market. Equally, Microsoft cannot supply the UNIX world with products. The Internet would probably benefit greatly if these two titans buried the hatchet in something besides each other.

The Trickling Down of Technology

As discussed earlier, there is the problem of high-level technology trickling down from military, scientific, and security sources. Today, the average cracker has tools at his or her disposal that most security organizations use in their work. Moreover, the machines on which crackers use these tools are extremely powerful, therefore allowing faster and more efficient cracking.

Government agencies often supply links to advanced security tools. At these sites, the tools are often free. They number in the hundreds and encompass nearly every aspect of security. In addition to these tools, government and university sites also provide very technical information regarding security. For crackers who know how to mine such information, these resources are invaluable. Some key sites are listed in Table 5.1.

Table 5.1. Some major security sites for information and tools.

Site Address
Purdue University http://www.cs.purdue.edu//coast/archive/
Raptor Systems http://www.raptor.com/library/library.html
The Risks Forum http://catless.ncl.ac.uk/Risks
FIRST http://www.first.org/
DEFCON http://www.defcon.org/

The level of technical information at such sites is high. This is in contrast to many fringe sites that provide information of little practical value to the cracker. But not all fringe sites are so benign. Crackers have become organized, and they maintain a wide variety of servers on the Internet. These are typically established using free operating systems such as Linux or FreeBSD. Many such sites end up establishing a permanent wire to the Net. Others are more unreliable and may appear at different times via dynamic IP addresses. I should make it clear that not all fringe sites are cracking sites. Many are legitimate hacking stops that provide information freely to the Internet community as a service of sorts. In either case, both hackers and crackers have been known to create excellent Web sites with voluminous security information.

The majority of cracking and hacking sites are geared toward UNIX and IBM-compatible platforms. There is a noticeable absence of quality information for Macintosh users. In any event, in-depth security information is available on the Internet for any interested party to view.

So, the information is trafficked. There is no solution to this problem, and there shouldn't be. It would be unfair to halt the education of many earnest, responsible individuals for the malicious acts of a few. So advanced security information and tools will remain available.

Human Nature

We have arrived at the final (and probably most influential) force at work in weakening Internet security: human nature. Humans are, by nature, a lazy breed. To most users, the subject of Internet security is boring and tedious. They assume that the security of the Internet will be taken care of by experts.

To some degree, there is truth to this. If the average user's machine or network is compromised, who should care? They are the only ones who can suffer (as long as they are not connected to a network other than their own). The problem is, most will be connected to some other network. The Internet is one enterprise that truly relies on the strength of its weakest link. I have seen crackers work feverishly on a single machine when that machine was not their ultimate objective. Perhaps the machine had some trust relationship with another machine that was their ultimate objective. To crack a given region of cyberspace, crackers may often have to take alternate or unusual routes. If one workstation on the network is vulnerable, they are all potentially vulnerable as long as a relationship of trust exists.

Also, you must think in terms of the smaller businesses because these will be the great majority. These businesses may not be able to withstand disaster in the same way that larger firms can. If you run a small business, when was the last time you performed a complete backup of all information on all your drives? Do you have a disaster-recovery plan? Many companies do not. This is an important point. I often get calls from companies that are about to establish permanent connectivity. Most of them are unprepared for emergencies.

Moreover, there are still two final aspects of human nature that influence the evolution of security on the Internet. Fear is one. Most companies are fearful to communicate with outsiders regarding security. For example, the majority of companies will not tell anyone if their security has been breached. When a Web site is cracked, it is front-page news; this cannot be avoided. When a system is cracked in some other way (with a different point of entry), press coverage (or any exposure) can usually be avoided. So, a company may simply move on, denying any incident, and secure its network as best it can. This deprives the security community of much-needed statistics and data.

The last human factor here is curiosity. Curiosity is a powerful facet of human nature that even the youngest child can understand. One of the most satisfying human experiences is discovery. Investigation and discovery are the things that life is really made of. We learn from the moment we are born until the moment that we die, and along that road, every shred of information is useful. Crackers are not so hard to understand. It comes down to basics: Why is this door is locked? Can I open it? As long as this aspect of human experience remains, the Internet may never be entirely secure. Oh, it will be ultimately be secure enough for credit-card transactions and the like, but someone will always be there to crack it.

Does the Internet Really Need to Be Secure?

Yes. The Internet does need to be secure and not simply for reasons of national security. Today, it is a matter of personal security. As more financial institutions gravitate to the Internet, America's financial future will depend on security. Many users may not be aware of the number of financial institutions that offer online banking. One year ago, this was a relatively uncommon phenomenon. Nevertheless, by mid-1996, financial institutions across the country were offering such services to their customers. Here are a few:

The threat from lax security is more than just a financial one. Banking records are extremely personal and contain revealing information. Until the Internet is secure, this information is available to anyone with the technical prowess to crack a bank's online service. It hasn't happened yet (I assume), but it will.

Also, the Internet needs to be secure so that it does not degenerate into one avenue of domestic spying. Some law-enforcement organizations are already using Usenet spiders to narrow down the identities of militia members, militants, and other political undesirables. The statements made by such people on Usenet are archived away, you can be sure. This type of logging activity is not unlawful. There is no constitutional protection against it, any more than there is a constitutional right for someone to demand privacy when they scribble on a bathroom wall.

Private e-mail is a different matter, though. Law enforcement agents need a warrant to tap someone's Internet connection. To circumvent these procedures (which could become widespread), all users should at least be aware of the encryption products available, both free and commercial (I will discuss this and related issues in Part VII of this book, "The Law").

For all these reasons, the Internet must become secure.

Can the Internet Be Secure?

Yes. The Internet can be secure. But in order for that to happen, some serious changes must be made, including the heightening of public awareness to the problem. Most users still regard the Internet as a toy, an entertainment device that is good for a couple of hours on a rainy Sunday afternoon. That needs to change in coming years.

The Internet is likely the single, most important advance of the century. Within a few years, it will be a powerful force in the lives of most Americans. So that this force may be overwhelmingly positive, Americans need to be properly informed.

Members of the media have certainly helped the situation, even though media coverage of the Internet isn't always painfully accurate. I have seen the rise of technology columns in newspapers throughout the country. Good technology writers are out there, trying to bring the important information home to their readers. I suspect that in the future, more newspapers will develop their own sections for Internet news, similar to those sections allocated for sports, local news, and human interest.

Equally, many users are security-aware, and that number is growing each day. As public education increases, vendors will meet the demand of their clientele.

Summary

In this chapter, I have established the following:

Those things having been established, I want to quickly examine the consequences of poor Internet security. Thus, in the next chapter, I will discuss Internet warfare. After covering that subject, I will venture into entirely new territory as we begin to explore the tools and techniques that are actually applied in Internet security.


6

A Brief Primer on TCP/IP

This chapter examines the Transmission Control Protocol (TCP) and the Internet Protocol (IP). These two protocols (or networked methods of data transport) are generally referred to together as TCP/IP.

You can read this chapter thoroughly to gain an in-depth understanding of how information is routed across the Internet or you can use this chapter as an extended glossary, referring to it only when encountering unfamiliar terms later in this book.

The chapter begins with fundamental concepts and closes with a comprehensive look at TCP/IP. The chapter is broken into three parts. The first part answers some basic questions you might have, including

The second portion of the chapter addresses how TCP/IP actually works. In that portion, I will focus on the most popular services within the TCP/IP suite. These services (or modes of transport) comprise the greater portion of the Internet as we know it today.

The final portion of this chapter explores key TCP/IP utilities with which each user must become familiar. These utilities are of value in maintenance and monitoring of any TCP/IP network.

Note that this chapter is not an exhaustive treatment of TCP/IP. It provides only the minimum knowledge needed to continue reading this book. Throughout this chapter, however, I supply links to documents and other resources from which the reader can gain an in-depth knowledge of TCP/IP.

TCP/IP: The Basics

This section is a quick overview of TCP/IP. It is designed to prepare you for various terms and concepts that arise within this chapter. It assumes no previous knowledge of IP protocols.

What Is TCP/IP?

TCP/IP refers to two network protocols (or methods of data transport) used on the Internet. They are Transmission Control Protocol and Internet Protocol, respectively. These network protocols belong to a larger collection of protocols, or a protocol suite. These are collectively referred to as the TCP/IP suite.

Protocols within the TCP/IP suite work together to provide data transport on the Internet. In other words, these protocols provide nearly all services available to today's Net surfer. Some of those services include

There are two classes of protocol within the TCP/IP suite, and I will address both in the following pages. Those two classes are

Network-Level Protocols

Network-level protocols manage the discrete mechanics of data transfer. These protocols are typically invisible to the user and operate deep beneath the surface of the system. For example, the IP protocol provides packet delivery of the information sent between the user and remote machines. It does this based on a variety of information, most notably the IP address of the two machines. Based on this and other information, IP guarantees that the information will be routed to its intended destination. Throughout this process, IP interacts with other network-level protocols engaged in data transport. Short of using network utilities (perhaps a sniffer or other device that reads IP datagrams), the user will never see IP's work on the system.

Application-Level Protocols

Conversely, application-level protocols are visible to the user in some measure. For example, File Transfer Protocol (FTP) is visible to the user. The user requests a connection to another machine to transfer a file, the connection is established, and the transfer begins. During the transfer, a portion of the exchange between the user's machine and the remote machine is visible (primarily error messages and status reports on the transfer itself, for example, how many bytes of the file have been transferred at any given moment).

For the moment, this explanation will suffice: TCP/IP refers to a collection of protocols that facilitate communication between machines over the Internet (or other networks running TCP/IP).

The History of TCP/IP

In 1969, the Defense Advanced Research Projects Agency (DARPA) commissioned development of a network over which its research centers might communicate. Its chief concern was this network's capability to withstand a nuclear attack. In short, if the Soviet Union launched a nuclear attack, it was imperative that the network remain intact to facilitate communication. The design of this network had several other requisites, the most important of which was this: It had to operate independently of any centralized control. Thus, if 1 machine was destroyed (or 10, or 100), the network would remain impervious.

The prototype for this system emerged quickly, based in part on research done in 1962 and 1963. That prototype was called ARPANET. ARPANET reportedly worked well, but was subject to periodic system crashes. Furthermore, long-term expansion of that network proved costly. A search was initiated for a more reliable set of protocols; that search ended in the mid-1970s with the development of TCP/IP.

TCP/IP had significant advantages over other protocols. For example, TCP/IP was lightweight (it required meager network resources). Moreover, TCP/IP could be implemented at much lower cost than the other choices then available. Based on these amenities, TCP/IP became exceedingly popular. In 1983, TCP/IP was integrated into release 4.2 of Berkeley Software Distribution (BSD) UNIX. Its integration into commercial forms of UNIX soon followed, and TCP/IP was established as the Internet standard. It has remained so (as of this writing).

As more users flock to the Internet, however, TCP/IP is being reexamined. More users translates to greater network load. To ease that network load and offer greater speeds of data transport, some researchers have suggested implementing TCP/IP via satellite transmission. Unfortunately, such research has thus far produced dismal results. TCP/IP is apparently unsuitable for this implementation.

Today, TCP/IP is used for many purposes, not just the Internet. For example, intranets are often built using TCP/IP. In such environments, TCP/IP can offer significant advantages over other networking protocols. One such advantage is that TCP/IP works on a wide variety of hardware and operating systems. Thus, one can quickly and easily create a heterogeneous network using TCP/IP. Such a network might have Macs, IBM compatibles, Sun Sparcstations, MIPS machines, and so on. Each of these can communicate with its peers using a common protocol suite. For this reason, since it was first introduced in the 1970s, TCP/IP has remained extremely popular. In the next section, I will discuss implementation of TCP/IP on various platforms.

What Platforms Support TCP/IP?

Most platforms support TCP/IP. However, the quality of that support can vary. Today, most mainstream operating systems have native TCP/IP support (that is, TCP/IP support that is built into the standard operating system distribution). However, older operating systems on some platforms lack such native support. Table 6.1 describes TCP/IP support for various platforms. If a platform has native TCP/IP support, it is labeled as such. If not, the name of a TCP/IP application is provided.

Table 6.1. Platforms and their support for TCP/IP.

Platform TCP/IP Support
UNIX Native
DOS Piper/IP By Ipswitch
Windows TCPMAN by Trumpet Software
Windows 95 Native
Windows NT Native
Macintosh MacTCP or OpenTransport (Sys 7.5+)
OS/2 Native
AS/400 OS/400 Native

Platforms that do not natively support TCP/IP can still implement it through the use of proprietary or third-party TCP/IP programs. In these instances, third-party products can offer varied functionality. Some offer very good support and others offer marginal support.

For example, some third-party products provide the user with only basic TCP/IP. For most users, this is sufficient. (They simply want to connect to the Net, get their mail, and enjoy easy networking.) In contrast, certain third-party TCP/IP implementations are comprehensive. These may allow manipulation of compression, methods of transport, and other features common to the typical UNIX TCP/IP implementation.

Widespread third-party support for TCP/IP has been around for only a few years. Several years ago, for example, TCP/IP support for DOS boxes was very slim.


TIP: There is actually a wonderful product called Minuet that can be used in conjunction with a packet driver on LANs. Minuet derived its name from the term Minnesota Internet Users Essential Tool. Minuet offers quick and efficient access to the Net through a DOS-based environment. This product is still available free of charge at many locations, including ftp://minuet.micro.umn.edu/pub/minuet/.

One interesting point about non-native, third-party TCP/IP implementations is this: Most of them do not provide servers within their distributions. Thus, although a user can connect to remote machines to transfer a file, the user's machine cannot accept such a request. For example, a Windows 3.11 user using TCPMAN cannot--without installing additional software--accept a file-transfer request from a remote machine. Later in this chapter you'll find a list of a few names of such additional software for those who are interested in providing services via TCP/IP.

How Does TCP/IP Work?

TCP/IP operates through the use of a protocol stack. This stack is the sum total of all protocols necessary to complete a single transfer of data between two machines. (It is also the path that data takes to get out of one machine and into another.) The stack is broken into layers, five of which are of concern here. To grasp this layer concept, examine Figure 6.1.


The TCP/IP stack.

After data has passed through the process illustrated in Figure 6.1, it travels to its destination on another machine or network. There, the process is executed in reverse (the data first meets the physical layer and subsequently travels its way up the stack). Throughout this process, a complex system of error checking is employed both on the originating and destination machine.

Each layer of the stack can send data to and receive data from its adjoining layer. Each layer is also associated with multiple protocols. At each tier of the stack, these protocols are hard at work, providing the user with various services. The next section of this chapter examines these services and the manner in which they are associated with layers in the stack. You will also examine their functions, the services they provide, and their relationship to security.

The Individual Protocols

You have examined how data is transmitted via TCP/IP using the protocol stack. Now I want to zoom in to identify the key protocols that operate within that stack. I will begin with network-level protocols.

Network-Level Protocols

Network protocols are those protocols that engage in (or facilitate) the transport process transparently. These are invisible to the user unless that user employs utilities to monitor system processes.


TIP: Sniffers are devices that can monitor such processes. A sniffer is a device--either hardware or software--that can read every packet sent across a network. Sniffers are commonly used to isolate network problems that, while invisible to the user, are degrading network performance. As such, sniffers can read all activity occurring between network-level protocols. Moreover, as you might guess, sniffers can pose a tremendous security threat. You will examine sniffers in Chapter 12, "Sniffers."

Important network-level protocols include

I will briefly examine each, offering only an overview.


Cross Reference: For more comprehensive information about protocols (or the stack in general), I highly recommend Teach Yourself TCP/IP in 14 Days by Timothy Parker, Ph.D (Sams Publishing).

The Address Resolution Protocol

The Address Resolution Protocol (ARP) serves the critical purpose of mapping Internet addresses into physical addresses. This is vital in routing information across the Internet. Before a message (or other data) is sent, it is packaged into IP packets, or blocks of information suitably formatted for Internet transport. These contain the numeric Internet (IP) address of both the originating and destination machines. Before this package can leave the originating computer, however, the hardware address of the recipient (destination) must be discovered. (Hardware addresses differ from Internet addresses.) This is where ARP makes its debut.

An ARP request message is broadcast on the subnet. This request is received by a router that replies with the requested hardware address. This reply is caught by the originating machine and the transfer process can begin.

ARP's design includes a cache. To understand the ARP cache concept, consider this: Most modern HTML browsers (such as Netscape Navigator or Microsoft's Internet Explorer) utilize a cache. This cache is a portion of the disk (or memory) in which elements from often-visited Web pages are stored (such as buttons, headers, and common graphics). This is logical because when you return to those pages, these tidbits don't have to be reloaded from the remote machine. They will load much more quickly if they are in your local cache.

Similarly, ARP implementations include a cache. In this manner, hardware addresses of remote machines or networks are remembered, and this memory obviates the need to conduct subsequent ARP queries on them. This saves time and network resources.

Can you guess what type of security risks might be involved in maintaining such an ARP cache? At this stage, it is not particularly important. However, address caching (not only in ARP but in all instances) does indeed pose a unique security risk. If such address-location entries are stored, it makes it easier for a cracker to forge a connection from a remote machine, claiming to hail from one of the cached addresses.


Cross Reference: Readers seeking in-depth information on ARP should see RFC 826 (http://www.freesoft.org/Connected/RFC/826).


Cross Reference: Another good reference for information on ARP is Margaret K. Johnson's piece about details of TCP/IP (excerpts from Microsoft LAN Manager TCP/IP Protocol) (http://www.alexia.net.au/~www/yendor/internetinfo/index.html).

The Internet Control Message Protocol

The Internet Control Message Protocol handles error and control messages that are passed between two (or more) computers or hosts during the transfer process. It allows those hosts to share that information. In this respect, ICMP is critical for diagnosis of network problems. Examples of diagnostic information gathered through ICMP include


TIP: Perhaps the most widely known ICMP implementation involves a network utility called ping. Ping is often used to determine whether a remote machine is alive. Ping's method of operation is simple: When the user pings a remote machine, packets are forwarded from the user's machine to the remote host. These packets are then echoed back to the user's machine. If no echoed packets are received at the user's end, the ping program usually generates an error message indicating that the remote host is down.


Cross Reference: I urge those readers seeking in-depth information about ICMP to examine RFC 792 (http://sunsite.auc.dk/RFC/rfc/rfc792.html).

The Internet Protocol

IP belongs to the network layer. The Internet Protocol provides packet delivery for all protocols within the TCP/IP suite. Thus, IP is the heart of the incredible process by which data traverses the Internet. To explore this process, I have drafted a small model of an IP datagram (see Figure 6.2).


The IP datagram.

As illustrated, an IP datagram is composed of several parts. The first part, the header, is composed of miscellaneous information, including originating and destination IP address. Together, these elements form a complete header. The remaining portion of a datagram contains whatever data is then being sent.

The amazing thing about IP is this: If IP datagrams encounter networks that require smaller packages, the datagrams bust apart to accommodate the recipient network. Thus, these datagrams can fragment during a journey and later be reassembled properly (even if they do not arrive in the same sequence in which they were sent) at their destination.

Even further information is contained within an IP datagram. Some of that information may include identification of the protocol being used, a header checksum, and a time-to-live specification. This specification is a numeric value. While the datagram is traveling the void, this numeric value is constantly being decremented. When that value finally reaches a zero state, the datagram dies. Many types of packets have time-to-live limitations. Some network utilities (such as Traceroute) utilize the time-to-live field as a marker in diagnostic routines.

In closing, IP's function can be reduced to this: providing packet delivery over the Internet. As you can see, that packet delivery is complex in its implementation.


Cross Reference: I refer readers seeking in-depth information on Internet protocol to RFC 760 (http://sunsite.auc.dk/RFC/rfc/rfc760.html).

The Transmission Control Protocol

The Transmission Control Protocol is the chief protocol employed on the Internet. It facilitates such mission-critical tasks as file transfers and remote sessions. TCP accomplishes these tasks through a method called reliable data transfer. In this respect, TCP differs from other protocols within the suite. In unreliable delivery, you have no guarantee that the data will arrive in a perfect state. In contrast, TCP provides what is sometimes referred to as reliable stream delivery. This reliable stream delivery ensures that the data arrives in the same sequence and state in which it was sent.

The TCP system relies on a virtual circuit that is established between the requesting machine and its target. This circuit is opened via a three-part process, often referred to as the three-part handshake. The process typically follows the pattern illustrated in Figure 6.3.


The TCP/IP three-way handshake.

After the circuit is open, data can simultaneously travel in both directions. This results in what is sometimes called a full-duplex transmission path. Full-duplex transmission allows data to travel to both machines at the same time. In this way, while a file transfer (or other remote session) is underway, any errors that arise can be forwarded to the requesting machine.

TCP also provides extensive error-checking capabilities. For each block of data sent, a numeric value is generated. The two machines identify each transferred block using this numeric value. For each block successfully transferred, the receiving host sends a message to the sender that the transfer was clean. Conversely, if the transfer is unsuccessful, two things may occur:

When an error is received, the data is retransmitted unless the error is fatal, in which case the transmission is usually halted. A typical example of a fatal error would be if the connection is dropped. Thus, the transfer is halted for no packets.

Similarly, if no confirmation is received within a specified time period, the information is also retransmitted. This process is repeated as many times as necessary to complete the transfer or remote session.

You have examined how the data is transported when a connect request is made. It is now time to examine what happens when that request reaches its destination. Each time one machine requests a connection to another, it specifies a particular destination. In the general sense, this destination is expressed as the Internet (IP) address and the hardware address of the target machine. However, even more detailed than this, the requesting machine specifies the application it is trying to reach at the destination. This involves two elements:

inetd: The Mother of All Daemons

Before you explore the inetd program, I want to briefly define daemons. This will help you more easily understand the inetd program.

Daemons are programs that continuously listen for other processes (in this case, the process listened for is a connection request). Daemons loosely resemble terminate and stay resident (TSR) programs in the Microsoft platform. These programs remain alive at all times, constantly listening for a particular event. When that event finally occurs, the TSR undertakes some action.

inetd is a very special daemon. It has been called many things, including the super-server or granddaddy of all processes. This is because inetd is the main daemon running on a UNIX machine. It is also an ingenious tool.

Common sense tells you that running a dozen or more daemon processes could eat up machine resources. So rather than do that, why not create one daemon that could listen for all the others? That is what inetd does. It listens for connection requests from the void. When it receives such a request, it evaluates it. This evaluation seeks to determine one thing only: What service does the requesting machine want? For example, does it want FTP? If so, inetd starts the FTP server process. The FTP server can then process the request from the void. At that point, a file transfer can begin. This all happens within the space of a second or so.


TIP: inetd isn't just for UNIX anymore. For example, Hummingbird Communications has developed (as part of its Exceed 5 product line) a version of inetd for use on any platform that runs Microsoft Windows or OS/2. There are also non- commercial versions of inetd, written by students and other software enthusiasts. One such distribution is available from TFS software and can be found at http://www.trumpton.demon.co.uk/software/inetd.html.

In general, inetd is started at boot time and remains resident (in a listening state) until the machine is turned off or until the root operator expressly terminates that process.

The behavior of inetd is generally controlled from a file called inetd.conf, located in the /etc directory on most UNIX platforms. The inetd.conf file is used to specify what services will be called by inetd. Such services might include FTP, Telnet, SMTP, TFTP, Finger, Systat, Netstat, or any other processes that you specify.

The Ports

Many TCP/IP programs can be initiated over the Internet. Most of these are client/server oriented. As each connection request is received, inetd starts a server program, which then communicates with the requesting client machine.

To facilitate this process, each application (FTP or Telnet, for example) is assigned a unique address. This address is called a port. The application in question is bound to that particular port and, when any connection request is made to that port, the corresponding application is launched (inetd is the program that launches it).

There are thousands of ports on the average Internet server. For purposes of convenience and efficiency, a standard framework has been developed for port assignment. (In other words, although a system administrator can bind services to the ports of his or her choice, services are generally bound to recognized ports. These are commonly referred to as well-known ports.)

Please peruse Table 6.2 for some commonly recognized ports and the applications typically bound to them.

Table 6.2. Common ports and their corresponding services or applications.

Service or Application Port
File Transfer Protocol (FTP) 21
Telnet 23
Simple Mail Transfer Protocol (SMTP) 25
Gopher 70
Finger 79
Hypertext Transfer Protocol (HTTP) 80
Network News Transfer Protocol (NNTP) 119

I will examine each of the applications described in Table 6.2. All are application-level protocols or services (that is, they are visible to user and the user can interact with them at the console).


Cross Reference: For a comprehensive list of all port assignments, visit ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers. This document is extremely informative and exhaustive in its treatment of commonly assigned port numbers.

Telnet

Telnet is best described in RFC 854, the Telnet protocol specification:

The purpose of the Telnet protocol is to provide a fairly general, bi-directional, eight-bit byte-oriented communications facility. Its primary goal is to allow a standard method of interfacing terminal devices and terminal-oriented processes to each other.

Telnet not only allows the user to log in to a remote host, it allows that user to execute commands on that host. Thus, an individual in Los Angeles can Telnet to a machine in New York and begin running programs on the New York machine just as though the user were actually in New York.

For those of you who are unfamiliar with Telnet, it operates much like the interface of a bulletin board system (BBS). Telnet is an excellent application for providing a terminal-based front end to databases. For example, better than 80 percent of all university library catalogs can be accessed via Telnet. Figure 6.4 shows an example of a Telnet library catalog screen.


A sample Telnet session.

Even though GUI applications have taken the world by storm, Telnet--which is essentially a text-based application--is still incredibly popular. There are many reasons for this. First, Telnet allows you to perform a variety of functions (retrieving mail, for example) at a minimal cost in network resources. Second, implementing secure Telnet is a pretty simple task. There are several programs to implement this, the most popular of which is Secure Shell (which I will explore later in this book).

To use Telnet, the user issues whatever command necessary to start his or her Telnet client, followed the name (or numeric IP address) of the target host. In UNIX, this is done as follows:

#telnet internic.net

This command launches a Telnet session, contacts internic.net, and requests a connection. That connection will either be honored or denied, depending on the configuration at the target host. In UNIX, the Telnet command has long been a native one. That is, Telnet has been included with basic UNIX distributions for well over a decade. However, not all operating systems have a native Telnet client. Table 6.3 shows Telnet clients for various operating systems.

Table 6.3. Telnet clients for various operating systems.

Operating System Client
UNIX Native
Microsoft Windows 95 Native (command line), ZOC, NetTerm, Zmud, WinTel32, Yawtelnet
Microsoft Windows NT Native (command line), CRT, and all listed for 95
Microsoft Windows 3.x Trumptel Telnet, Wintel, Ewan
Macintosh NCSA Telnet, NiftyTelnet, Comet
VAX Native

File Transfer Protocol

File Transfer Protocol is the standard method of transferring files from one system to another. Its purpose is set forth in RFC 0765 as follows:

The objectives of FTP are 1) to promote sharing of files (computer programs and/or data), 2) to encourage indirect or implicit (via programs) use of remote computers, 3) to shield a user from variations in file storage systems among Hosts, and 4) to transfer data reliably and efficiently. FTP, though usable directly by a user at a terminal, is designed mainly for use by programs.

For over two decades, researchers have investigated a wide variety of file-transfer methods. The development of FTP has undergone many changes in that time. Its first definition occurred in April 1971, and the full specification can be read in RFC 114.


Cross Reference: RFC 114 contains the first definition of FTP, but a more practical document might be RFC 959 (http://www.freesoft.org/Connected/RFC/959/index.html).

Mechanical Operation of FTP

File transfers using FTP can be accomplished using any suitable FTP client. Table 6.4 defines some common clients used, by operating system.

Table 6.4. FTP clients for various operating systems.

Operating System Client
UNIX Native, LLNLXDIR2.0, FTPtool
Microsoft Windows 95 Native, WS_FTP, Netload, Cute-FTP, Leap FTP, SDFTP, FTP Explorer
Microsoft Windows NT See listings for Windows 95
Microsoft Windows 3.x Win_FTP, WS_FTP, CU-FTP, WSArchie
Macintosh Anarchie, Fetch, Freetp
OS/2 Gibbon FTP, FTP-IT, Lynn's Workplace FTP
VAX Native

How Does FTP Work?

FTP file transfers occur in a client/server environment. The requesting machine starts one of the clients named in Table 6.4. This generates a request that is forwarded to the targeted file server (usually a host on another network). Typically, the request is sent by inetd to port 21. For a connection to be established, the targeted file server must be running an FTP server or FTP daemon.

FTPD FTPD is the standard FTP server daemon. Its function is simple: to reply to connect requests received by inetd and to satisfy those requests for file transfers. This daemon comes standard on most distributions of UNIX (for other operating systems, see Table 6.5).

Table 6.5. FTP servers for various operating systems.

Operating System Client
UNIX Native (FTPD)
Microsoft Windows 95 WFTPD, Microsoft FrontPage, WAR FTP Daemon, Vermilion
Microsoft Windows NT Serv-U, OmniFSPD, Microsoft Internet Information Server
Microsoft Windows 3.x WinQVT, Serv-U, Beames & Whitside BW Connect, WFTPD FTP Server, WinHTTPD
Macintosh Netpresenz, FTPD
OS/2 Penguin

FTPD waits for a connection request. When such a request is received, FTPD requests the user login. The user must either provide his or her valid user login and password or may log in anonymously.

Once logged in, the user may download files. In certain instances and if security on the server allows, the user may also upload files.

Simple Mail Transfer Protocol

The objective of Simple Mail Transfer protocol is stated concisely in RFC 821:

The objective of Simple Mail Transfer protocol (SMTP) is to transfer mail reliably and efficiently.

SMTP is an extremely lightweight and efficient protocol. The user (utilizing any SMTP- compliant client) sends a request to an SMTP server. A two-way connection is subsequently established. The client forwards a MAIL instruction, indicating that it wants to send mail to a recipient somewhere on the Internet. If the SMTP allows this operation, an affirmative acknowledgment is sent back to the client machine. At that point, the session begins. The client may then forward the recipient's identity, his or her IP address, and the message (in text) to be sent.

Despite the simple character of SMTP, mail service has been the source of countless security holes. (This may be due in part to the number of options involved. Misconfiguration is a common reason for holes.) I will discuss these security issues later in this book.

SMTP servers are native in UNIX. Most other networked operating systems now have some form of SMTP, so I'll refrain from listing them here.


Cross Reference: Further information on this protocol is available in RFC 821 (http://sunsite.auc.dk/RFC/rfc/rfc821.html).

Gopher

The Gopher service is a distributed document-retrieval system. It was originally implemented as the Campus Wide Information System at the University of Minnesota. It is defined in a March 1993 FYI from the University of Minnesota as follows:

The Internet Gopher protocol is designed primarily to act as a distributed document-delivery system. While documents (and services) reside on many servers, Gopher client software presents users with a hierarchy of items and directories much like a file system. In fact, the Gopher interface is designed to resemble a file system since a file system is a good model for locating documents and services.


Cross Reference: The complete documentation on the Gopher protocol can be obtained in RFC 1436 (http://sunsite.auc.dk/RFC/rfc/rfc1436.html).

The Gopher service is very powerful. It can serve text documents, sounds, and other media. It also operates largely in text mode and is therefore much faster than HTTP through a browser. Undoubtedly, the most popular Gopher client is for UNIX. (Gopher2_3 is especially popular, followed by Xgopher.) However, many operating systems have Gopher clients. See Table 6.6 for a few.

Table 6.6. Gopher clients for various operating systems.

Operating System Client
Microsoft Windows (all) Hgopher, Ws_Gopher
Macintosh Mac Turbo Gopher
AS/400 The AS/400 Gopher Client
OS/2 Os2Gofer

Typically, the user launches a Gopher client and contacts a given Gopher server. In turn, the Gopher server forwards a menu of choices. These may include search menus, pre-set destinations, or file directories. Figure 6.5 shows a client connection to the University of Illinois.


A sample gopher session.

Note that the Gopher model is completely client/server based. The user never logs on per se. Rather, the client sends a message to the Gopher server, requesting all documents (or objects) currently available. The Gopher server responds with this information and does nothing else until the user requests an object.

Hypertext Transfer Protocol

Hypertext Transfer Protocol is perhaps the most renowned protocol of all because it is this protocol that allows users to surf the Net. Stated briefly in RFC 1945, HTTP is

...an application-level protocol with the lightness and speed necessary for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods (commands). A feature of HTTP is the typing of data representation, allowing systems to be built independently of the data being transferred.


NOTE: RFC 1945 has been superseded by RFC 2068, which is a more recent specification of HTTP and is available at ftp://ds.internic.net/rfc/rfc2068.txt.

HTTP has forever changed the nature of the Internet, primarily by bringing the Internet to the masses. In some ways, its operation is much like Gopher. For example, it too works via a request/response scenario. And this is an important point. Whereas applications such as Telnet require that a user remain logged on (and while they are logged on, they consume system resources), protocols such as Gopher and HTTP eliminate this phenomenon. Thus, the user is pushed back a few paces. The user (client) only consumes system resources for the instant that he or she is either requesting or receiving data.

Using a common browser like Netscape Navigator or Microsoft Internet Explorer, you can monitor this process as it occurs. For each data element (text, graphic, sound) on a WWW page, your browser will contact the server one time. Thus, it will first grab text, then a graphic, then a sound file, and so on. In the lower-left corner of your browser's screen is a status bar. Watch it for a few moments when it is loading a page. You will see this request/response activity occur, often at a very high speed.

HTTP doesn't particularly care what type of data is requested. Various forms of multimedia can be either embedded within or served remotely via HTML-based WWW pages. In short, HTTP is an extremely lightweight and effective protocol. Clients for this protocol are enumerated in Table 6.7.

Table 6.7. HTTP clients for various operating systems.

Operating System HTTP Client
Microsoft Windows (all) Netscape Navigator, WinWeb, Mosaic, Microsoft Internet Explorer, WebSurfer, NetCruiser, AOL, Prodigy
Macintosh Netscape Navigator, MacMosaic, MacWeb, Samba, Microsoft Internet Explorer
UNIX Xmosaic, Netscape Navigator, Grail, Lynx, TkWWW, Arena
OS/2 Web Explorer, Netscape Navigator

Until recently, UNIX alone supported an HTTP server. (The standard was NCSA HTTPD. Apache has now entered the race, giving HTTPD strong competition in the market.) The application is extremely small and compact. Like most of its counterparts, it runs as a daemon. Its typically assigned port is 80. Today, there are HTTP servers for nearly every operating system. Table 6.8 lists those servers.

Table 6.8. HTTP server for various operating systems.

Operating System HTTP Server
Microsoft Windows 3.x Website, WinHTTPD
Microsoft Windows 95 OmniHTTPD, Server 7, Nutwebcam, Microsoft Personal Web Server, Fnord, ZB Server, Website, Folkweb
Microsoft Windows NT HTTPS, Internet Information Server, Alibaba, Espanade, Expresso, Fnord, Folkweb, Netpublisher, Weber, OmniHTTPD, WebQuest, Website, Wildcat
Macintosh MacHTTP, Webstar, Phantom, Domino, Netpresenz
UNIX HTTPD, Apache
OS/2 GoServe, OS2HTTPD, OS2WWW, IBM Internet Connection Server, Bearsoft, Squid & Planetwood

Network News Transfer Protocol

The Network News Transfer Protocol is one of the most widely used protocols. It provides modern access to the news service commonly known as USENET news. Its purpose is defined in RFC 977:

NNTP specifies a protocol for the distribution, inquiry, retrieval, and posting of news articles using a reliable stream-based transmission of news among the ARPA-Internet community. NNTP is designed so that news articles are stored in a central database allowing a subscriber to select only those items he wishes to read. Indexing, cross-referencing, and expiration of aged messages are also provided.

NNTP shares characteristics with both Simple Mail Transfer Protocol and TCP. Similarities to SMTP consist of NNTP's acceptance of plain-English commands from a prompt. It is similar to TCP in that stream-based transport and delivery is used. NNTP typically runs from Port 119 on any UNIX system.


Cross Reference: I refer readers seeking in-depth information on NNTP to RFC 977 (http://andrew2.andrew.cmu.edu/rfc/rfc977.html).
You may also wish to obtain RFC 850 for examination of earlier implementations of the standard (http://sunsite.auc.dk/RFC/rfc/rfc850.html).

Concepts

You have examined TCP/IP services and protocols individually, in their static states. You have also examined the application-level protocols. This was necessary to describe each protocol and what they accomplish. Now it is time to examine the larger picture.

TCP/IP Is the Internet

By now, it should be apparent that TCP/IP basically comprises the Internet itself. It is a complex collection of protocols, many of which remain invisible to the user. On most Internet servers, a minimum of these protocols exist:

Now, prepare yourself for a shock. These are only a handful of protocols run on the Internet. There are actually hundreds of them. Better than half of the primary protocols have had one or more security holes.

In essence, the point I would like to make is this: The Internet was designed as a system with multiple avenues of communication. Each protocol is one such avenue. As such, there are hundreds of ways to move data across the Net.

Until recently, utilizing these protocols called for accessing them one at a time. That is, to arrest a Gopher session and start a Telnet session, the user had to physically terminate the Gopher connection.

The HTTP browser changed all that and granted the average user much greater power and functionality. Indeed, FTP, Telnet, NTTP, and HTTP are all available at the click of a button.

Summary

In this chapter, you learned about TCP/IP. Relevant points about TCP/IP include

Now that know the fundamentals of TCP/IP, you can progress to the next chapter. In it, you will explore some of the reasons why the Internet is not secure. As you can probably guess, there will be references to TCP/IP throughout that chapter.


7

Birth of a Network: The Internet

Readers already familiar with the Internet's early development may wish to bypass this little slice of history. The story has been told many times.

Our setting is the early 1960s: 1962, to be exact. Jack Kennedy was in the White House, the Beatles had just recorded their first hit single (Love Me Do), and Christa Speck, a knock-out brunette from Germany, made Playmate of the Year. Most Americans were enjoying an era of prosperity. Elsewhere, however, Communism was spreading, and with it came weapons of terrible destruction.

In anticipation of impending atomic disaster, The United States Air Force charged a small group of researchers with a formidable task: creating a communication network that could survive a nuclear attack. Their concept was revolutionary: a network that had no centralized control. If 1 (or 10, or 100) of its nodes were destroyed, the system would continue to run. In essence, this network (designed exclusively for military use) would survive the apocalypse itself (even if we didn't).

The individual largely responsible for the creation of the Internet is Paul Baran. In 1962, Baran worked at RAND Corporation, the think tank charged with developing this concept. Baran's vision involved a network constructed much like a fishnet. In his now-famous memorandum titled On Distributed Communications: I. Introduction to Distributed Communications Network, Baran explained:

The centralized network is obviously vulnerable as destruction of a single central node destroys communication between the end stations. In practice, a mixture of star and mesh components is used to form communications networks. Such a network is sometimes called a `decentralized' network, because complete reliance upon a single point is not always required.


Cross Reference: The RAND Corporation has generously made this memorandum and the report delivered by Baran available via the World Wide Web. The documents can be found at http://www.rand.org/publications/electronic/.

Baran's model was complex. His presentation covered every aspect of the proposed network, including routing conventions. For example, data would travel along the network by whatever channels were available at that precise moment. In essence, the data would dynamically determine its own path at each step of the journey. If it encountered some sort of problem at one crossroads of the Net, the data would find an alternate route. Baran's proposed design provided for all sorts of contingencies. For instance, a network node would only accept a message if that node had adequate space available to store it. Equally, if a data message determined that all nodes were currently unavailable (the all lines busy scenario), the message would wait at the current node until a data path became available. In this way, the network would provide intelligent data transport. Baran also detailed other aspects of the network, including


In essence, Baran eloquently articulated the birth of a network in painstaking detail. Unfortunately, however, his ideas were ahead of their time. The Pentagon had little faith in such radical concepts. Baran delivered to defense officials an 11-volume report that was promptly shelved.

The Pentagon's shortsightedness delayed the birth of the Internet, but not by much. By 1965, the push was on again. Funding was allocated for the development of a decentralized computer network, and in 1969, that network became a reality. That system was called ARPANET.

As networks go, ARPANET was pretty basic, not even closely resembling the Internet of today. Its topology consisted of links between machines at four academic institutions (Stanford Research Institute, the University of Utah, the University of California at Los Angeles, and the University of California at Santa Barbara).

One of those machines was a DEC PDP-10. Only those more mature readers will remember this model. These are massive, ancient beasts, now more useful as furniture than computing devices. I mention the PDP-10 here to briefly recount another legend in computer history (one that many of you have never heard). By taking this detour, I hope to give you a frame of reference from which to measure how incredibly long ago this was in computer history.

It was at roughly that time that a Seattle, Washington, company began providing computer time sharing. The company reportedly took on two bright young men to test its software. These young men both excelled in computer science, and were rumored to be skilled in the art of finding holes within systems. In exchange for testing company software, the young men were given free dial-up access to a PDP-10 (this would be the equivalent of getting free access to a private bulletin board system). Unfortunately for the boys, the company folded shortly thereafter, but the learning experience changed their lives. At the time, they were just old enough to attend high school. Today, they are in their forties. Can you guess their identities? The two boys were Bill Gates and Paul Allen.

In any event, by 1972, ARPANET had some 40 hosts (in today's terms, that is smaller than many local area networks, or LANs). It was in that year that Ray Tomlinson, a member of Bolt, Beranek, and Newman, Inc., forever changed the mode of communication on the network. Tomlinson created electronic mail.

Tomlinson's invention was probably the single most important computer innovation of the decade. E-mail allowed simple, efficient, and inexpensive communication between various nodes of the network. This naturally led to more active discussions and the open exchange of ideas. Because many recipients could be added to an e-mail message, these ideas were more rapidly implemented. (Consider the distinction between e-mail and the telephone. How many people can you reach with a modern conference call? Compare that to the number of people you can reach with a single e-mail message. For group-oriented research, e-mail cannot be rivaled.) From that point on, the Net was alive.

In 1974, Tomlinson contributed to another startling advance. He (in parallel with Vinton Cerf and Robert Khan) invented the Transmission Control Protocol (TCP). This protocol was a new means of moving data across the network bit by bit and then later assembling these fragments at the other end.


NOTE: TCP is the primary protocol used on the Internet today. It was developed in the early 1970s and was ultimately integrated into Berkeley Software Distribution UNIX. It has since become an Internet standard. Today, almost all computers connected to the Internet run some form of TCP. In Chapter 6, "A Brief Primer on TCP/IP," I closely examine TCP as well as its sister protocols.

By 1975, ARPANET was a fully functional network. The groundwork had been done and it was time for the U.S. government to claim its prize. In that year, control of ARPANET was given to an organization then known as the United States Defense Communications Agency (this organization would later become the Defense Information Systems Agency).

To date, the Internet is the largest and most comprehensive structure ever designed by humankind. Next, I will address some peripheral technological developments that helped form the network and bring it to its present state of complexity. To do this, I will start with C.

What Is C?

C is a popular computer programming language, often used to write language compilers and operating systems. I examine C here because its development (and its relationship to the UNIX operating system) is directly relevant to the Internet's development.

Nearly all applications designed to facilitate communication over the Internet are written in C. Indeed, both the UNIX operating system (which forms the underlying structure of the Internet) and TCP/IP (the suite of protocols used to traffic data over the Net) were developed in C. It is no exaggeration to say that if C had never emerged, the Internet as we know it would never have existed at all.

For most non-technical users, programming languages are strange, perplexing things. However, programming languages (and programmers) are the very tools by which a computer program (commonly called an application) is constructed. It may interest you to know that if you use a personal computer or workstation, better than half of all applications you now use were written in the C language. (This is true of all widely used platforms, including Macintosh.) In this section, I want to briefly discuss C and pay some homage to those who helped develop it. These folks, along with Paul Baran, Ken Thompson, and a handful of others, are the grandparents of the Internet.

C was created in the early 1970s by Dennis M. Ritchie and Brian W. Kernighan. These two men are responsible for many technological advancements that formed the modern Internet, and their names appear several times throughout this book.

Let's discuss a few basic characteristics of the C programming language. To start, C is a compiled as opposed to an interpreted language. I want to take a moment to explain this critical distinction because many of you may lack programming experience.

Interpreted Programming Languages

Most programs are written in plain, human-readable text. This text is made up of various commands and blocks of programming code called functions. In interpreted languages, this text remains in human-readable form. In other words, such a program file can be loaded into a text editor and read without event.

For instance, examine the program that follows. It is written for the Practical Extraction and Report Language (Perl). The purpose of this Perl program is to get the user's first name and print it back out to the screen.


NOTE: Perl is strictly defined as an interpreted language, but it does perform a form of compilation. However, that compilation occurs in memory and never actually changes the physical appearance of the programming code.

This program is written in plain English:

#!/usr/bin/perl
print "Please enter your first name:";
$user_firstname = <STDIN>;
chop($user_firstname);
print "Hello, $user_firstname\n"
print "Are you ready to hack?\n"

Its construction is designed to be interpreted by Perl. The program performs five functions:


Interpreted languages are commonly used for programs that perform trivial tasks or tasks that need be done only once. These are sometimes referred to as throwaway programs. They can be written quickly and take virtually no room on the local disk.

Such interpreted programs are of limited use. For example, in order to run, they must be executed on a machine that contains the command interpreter. If you take a Perl script and install it on a DOS-based machine (without first installing the Perl interpreter), it will not run. The user will be confronted with an error message (Bad command or file name). Thus, programs written in Perl are dependent on the interpreter for execution.

Microsoft users will be vaguely familiar with this concept in the context of applications written in Visual Basic (VB). VB programs typically rely on runtime libraries such as VBRUN400.DLL. Without such libraries present on the drive, VB programs will not run.


Cross Reference: Microsoft users who want to learn more about such library dependencies (but don't want to spend the money for VB) should check out Envelop. Envelop is a completely free 32-bit programming environment for Windows 95 and Windows NT. It very closely resembles Microsoft Visual Basic and generates attractive, fully functional 32-bit programs. It, too, has a set of runtime libraries and extensive documentation about how those libraries interface with the program. You can get it at ftp://ftp.cso.uiuc.edu/pub/systems/pc/winsite/win95/programr/envlp14.exe

The key advantages of interpreted languages include


Interpreted languages are popular, particularly in the UNIX community. Here is a brief list of some well-known interpreted languages:


The pitfall of using an interpreted language is that programs written in interpreted languages are generally much slower than those written in compiled languages.

Compiled Languages

Compiled languages (such as C) are much different. Programs written in compiled languages must be converted into binary format before they can be executed. In many instances, this format is almost pure machine-readable code. To generate this code, the programmer sends the human-readable program code (plain text) through a compilation process. The program that performs this conversion is called a compiler.

After the program has been compiled, no interpreter is required for its execution. It will run on any machine that runs the target operating system for which the program was written. Exceptions to this rule may sometimes apply to certain portions of a compiled program. For example, certain graphical functions are dependent on proprietary graphics libraries. When a C program is written using such graphical libraries, certain library components must be shipped with the binary distribution. If such library components are missing when the program is executed, the program will exit on error.

The first interesting point about compiled programs is that they are fast. Because the program is loaded entirely into memory on execution (as opposed to being interpreted first), a great deal of speed is gained. However, as the saying goes, there is no such thing as a free lunch. Thus, although compiled programs are fast, they are also much larger than programs written in interpreted languages.

Examine following the C program. It is identical in function to the Perl program listed previously. Here is the code in its yet-to-be-compiled state:

#include <stdio.h>
int main()
{
char name[20];
printf("Please enter your first name:   ");
scanf("%s", &name);
printf("Hello, %s\n", name);
printf("Are you ready to hack?\n");
return 0;
}

Using a standard C compiler, I compiled this code in a UNIX operating system environment. The difference in size between the two programs (the one in Perl and the one in C) was dramatic. The Perl program was 150 bytes in size; the C program, after being compiled, was 4141 bytes.

This might seem like a huge liability on the part of C, but in reality, it isn't. The C program can be ported to almost every operating system. Furthermore, it will run on any operating system of a certain class. If compiled for DOS, it will work equally well under all DOS-like environments (such as PC-DOS or NDOS), not just Microsoft DOS.

Modern C: The All-Purpose Language

C has been used over the years to create all manner of programs on a variety of platforms. Many Microsoft Windows applications have been written in C. Similarly, as I will explain later in this chapter, nearly all basic UNIX utilities are written in C.

To generate programs written in C, you must have a C compiler. C compilers are available for most platforms. Some of these are commercial products and some are free to the public. Table 7.1 lists common C compilers and the platforms on which they are available.

Table 7.1. C compilers and their platforms.

Compiler Platform
GNU C (free) UNIX, Linux, DOS, VAX
Borland C DOS, Windows, Windows NT
Microsoft C DOS, Windows, Windows NT
Watcom C DOS, Windows, Windows NT, OS/2
Metrowerks CodeWarrior Mac, Windows, BeOS
Symantec Macintosh, Microsoft platforms

Advantages of C

One primary advantage of the C language is that it is smaller than many other languages. The average individual can learn C within a reasonable period of time. Another advantage is that C now conforms to a national standard. Thus, a programmer can learn C and apply that knowledge on any platform, anywhere in the country.

C has direct relevance to the development of the Internet. As I have explained, most modern TCP/IP implementations are written in C, and these form the basis of data transport on the Internet. More importantly, C was used in the development of the UNIX operating system. As I will explain in the next section of this chapter, the UNIX operating system has, for many years, formed the larger portion of the Internet.

C has other advantages: One is portability. You may have seen statements on the Internet about this or that program being ported to another operating system or platform, and many of you might not know exactly what that means. Portability refers to the capability of a program to be re-worked to run on a platform other than the one for which it was originally designed (that is, the capability to take a program written for Microsoft Windows and port it to the Macintosh platform). This aspect of portability is very important, especially in an environment like the Internet, because the Internet has many different types of systems running on it. In order to make a program available networkwide, that program must be easily conformable to all platforms.

Unlike code in other languages, C code is highly portable. For example, consider Visual Basic. Visual Basic is a wonderful rapid application development tool that can build programs to run on any Microsoft-based platform. However, that is the extent of it. You cannot take the raw code of a VB application and recompile it on a Macintosh or a Sun Sparcstation.

In contrast, the majority of C programs can be ported to a wide variety of platforms. As such, C-based programs available for distribution on the Internet are almost always distributed in source form (in other words, they are distributed in plain text code form, or in a form that has not yet been compiled). This allows the user to compile the program specifically for his or her own operating system environment.

Limitations of C and the Creation of C++

Despite these wonderful features, C has certain limitations. C is not, for example, an object-oriented language. Managing very large programs in C (where the code exceeds 100,000 lines) can be difficult. For this, C++ was created. C++ lineage is deeply rooted in C, but works differently. Because this section contains only brief coverage of C, I will not discuss C++ extensively. However, you should note that C++ is generally included as an option in most modern C compilers.

C++ is an extremely powerful programming language and has led to dramatic changes in the way programming is accomplished. C++ allows for encapsulation of complex functions into entities called objects. These objects allow easier control and organization of large and complex programs.

In closing, C is a popular, portable, and lightweight programming language. It is based on a national standard and was used in the development of the UNIX operating system.


Cross Reference: Readers who want to learn more about the C programming language should obtain the book The C Programming Language by Brian W. Kernighan and Dennis M. Ritchie. (Prentice Hall, ISBN 0-13-110370-9). This book is a standard. It is extremely revealing; after all, it is written by two men who developed the language.

Other popular books on C include

C: A Reference Manual. Samuel P. Harbison and Guy L. Steele. Prentice-Hall. ISBN 0-13-109802-0. 1987.

Teach Yourself C in 21 Days. Peter Aitkin and Bradley Jones. Sams Publishing. ISBN 0-672-30448-1.

Teach Yourself C. Herbert Schildt. Osborne McGraw-Hill. ISBN 0-07-881596-7.


UNIX

The UNIX operating system has a long and rich history. Today, UNIX is one of the most widely used operating systems, particularly on the Internet. In fact, UNIX actually comprises much of the Net, being the number one system used on servers in the void.

Created in 1969 by Ken Thompson of Bell Labs, the first version of UNIX ran on a Digital Equipment Corporation (DEC) PDP-7. Of course, that system bore no resemblance to modern UNIX. For example, UNIX has been traditionally known as a multiuser system (in other words, many users can work simultaneously on a single UNIX box). In contrast, the system created by Thompson was reportedly a single-user system, and a bare bones one at that.

When users today think of an operating system, they imagine something that includes basic utilities, text editors, help files, a windowing system, networking tools, and so forth. This is because the personal computer has become a household item. As such, end-user systems incorporate great complexity and user-friendly design. Alas, the first UNIX system was nothing like this. Instead, it was composed of only the most necessary utilities to operate effectively. For a moment, place yourself in Ken Thompson's position. Before you create dozens of complex programs like those mentioned previously, you are faced with a more practical task: getting the system to boot.

In any event, Thompson and Dennis Ritchie ported UNIX to a DEC PDP-11/20 a year later. From there, UNIX underwent considerable development. Between 1970 and 1973, UNIX was completely reworked and written in the C programming language. This was reportedly a major improvement and eliminated many of the bugs inherent to the original implementation.

In the years that followed, UNIX source code was distributed to universities throughout the country. This, more than any other thing, contributed to the success of UNIX.

First, the research and academic communities took an immediate liking to UNIX. Hence, it was used in many educational exercises. This had a direct effect on the commercial world. As explained by Mike Loukides, an editor for O'Reilly & Associates and a UNIX guru:

Schools were turning out loads of very competent computer users (and systems programmers) who already knew UNIX. You could therefore "buy" a ready-made programming staff. You didn't have to train them on the intricacies of some unknown operating system.

Also, because the source was free to these universities, UNIX was open for development by students. This openness quickly led to UNIX being ported to other machines, which only increased the UNIX user base.


NOTE: Because UNIX source is widely known and available, more flaws in the system security structure are also known. This is in sharp contrast to proprietary systems. Such proprietary software manufacturers refuse to disclose their source except to very select recipients, leaving many questions about their security as yet unanswered.

Several years passed, and UNIX continued to gain popularity. It became so popular, in fact, that in 1978, AT&T decided to commercialize the operating system and demand licensing fees (after all, it had obviously created a winning product). This caused a major shift in the computing community. As a result, the University of California at Berkeley created its own version of UNIX, thereafter referred to as the Berkeley Software Distribution or BSD. BSD was (and continues to be) extremely influential, being the basis for many modern forms of commercial UNIX.

An interesting development occurred during 1980. Microsoft released a new version of UNIX called XENIX. This was significant because the Microsoft product line was already quite extensive. For example, Microsoft was selling versions of BASIC, COBOL, Pascal, and FORTRAN. However, despite a strong effort by Microsoft to make its XENIX product fly (and even an endorsement by IBM to install the XENIX operating system on its new PCs), XENIX would ultimately fade into obscurity. Its popularity lasted a mere five years. In contrast, MS-DOS (released only one year after XENIX was introduced) took the PC world by storm.

Today, there are many commercial versions of UNIX. I have listed a few of the them in Table 7.2.

Table 7.2. Commercial versions of UNIX and their manufacturers.

UNIX Version Software Company
SunOS & Solaris Sun Microsystems
HP-UX Hewlett Packard
AIX IBM
IRIX Silicon Graphics (SGI)
DEC UNIX Digital Equipment Corporation

These versions of UNIX run on proprietary hardware platforms, on high-performance machines called workstations. Workstations differ from PC machines in several ways. For one thing, workstations contain superior hardware and are therefore more expensive. This is due in part to the limited number of workstations built. PCs are manufactured in large numbers, and manufacturers are constantly looking for ways to cut costs. A consumer buying a new PC motherboard has a much greater chance of receiving faulty hardware. Conversely, workstation buyers enjoy more reliability, but may pay five or even six figures for their systems.

The trade-off is a hard choice. Naturally, for average users, workstations are both impractical and cost prohibitive. Moreover, PC hardware and software are easily obtainable, simple to configure, and widely distributed.

Nevertheless, workstations have traditionally been more technologically advanced than PCs. For example, onboard sound, Ethernet, and SCSI were standard features of workstations in 1989. In fact, onboard ISDN was integrated not long after ISDN was developed.

Differences also exist depending upon manufacturer. For example, Silicon Graphics (SGI) machines contain special hardware (and software) that allows them to generate eye-popping graphics. These machines are commonly used in the entertainment industry, particularly in film. Because of the extraordinary capabilities of the SGI product line, SGI workstations are unrivaled in the graphics industry.

However, we are only concerned here with the UNIX platform as it relates to the Internet. As you might guess, that relationship is strong. As I noted earlier, the U.S. government's development of the Internet was implemented on the UNIX platform. As such, today's UNIX system contains within it the very building blocks of the Net. No other operating system had ever been so expressly designed for use with the Internet. (Although Bell Labs is currently developing a system that may even surpass UNIX in this regard. It is called Plan 9 from Bell Labs; Plan 9 is covered in Chapter 21, "Plan 9 from Bell Labs.")

Modern UNIX can run on a wide variety of platforms, including IBM-compatible and Macintosh. Installation is typically straightforward and differs little from installation of other operating systems. Most vendors provide CD-ROM media. On workstations, installation is performed by booting from a CD-ROM. The user is given a series of options and the remainder of the installation is automatic. On other hardware platforms, the CD-ROM medium is generally accompanied by a boot disk that loads a small installation routine into memory.

Likewise, starting a UNIX system is similar to booting other systems. The boot routine makes quick diagnostics of all existing hardware devices, checks the memory, and starts vital system processes. In UNIX, some common system processes started at boot include


After the system boots successfully, a login prompt is issued to the user. Here, the user provides his or her login username and password. When login is complete, the user is generally dropped into a shell environment. A shell is an environment in which commands can be typed and executed. In this respect, at least in appearance, basic UNIX marginally resembles MS-DOS. Navigation of directories is accomplished by changing direction from one to another. DOS users can easily navigate a UNIX system using the conversion information in Table 7.3.

Table 7.3. Command conversion table: UNIX to DOS.

DOS Command UNIX Equivalent
cd <directory> cd <directory>
dir ls -l
type|more more
help <command> man <command>
edit vi


Cross Reference: Readers who wish to know more about basic UNIX commands should point their WWW browser to http://www.geek-girl.com/Unixhelp/. This archive is one of the most comprehensive collections of information about UNIX currently online.
Equally, more serious readers may wish to have a handy reference at their immediate disposal. For this, I recommend UNIX Unleashed (Sams Publishing). The book was written by several talented UNIX wizards and provides many helpful tips and tricks on using this popular operating system.

Say, What About a Windowing System?

UNIX supports many windowing systems. Much depends on the specific platform. For example, most companies that have developed proprietary UNIX systems have also developed their own windowing packages, either partially or completely. In general, however, all modern UNIX systems support the X Window System from the Massachusetts Institute of Technology (MIT). Whenever I refer to the X Window System in this book (which is often), I refer to it as X. I want to quickly cover X because some portions of this book require you to know about it.

In 1984, the folks at MIT founded Project Athena. Its purpose was to develop a system of graphical interface that would run on workstations or networks of disparate design. During the initial stages of research, it immediately became clear that in order to accomplish this task, X had to be hardware independent. It also had to provide transparent network access. As such, X is not only a windowing system, but a network protocol based on the client/server model.

The individuals primarily responsible for early development of X were Robert Scheifler and Ron Newman, both from MIT, and Jim Gettys of DEC. X vastly differs from other types of windowing systems (for example, Microsoft Windows), even with respect to the user interface. This difference lies mainly in a concept sometimes referred to as workbench or toolkit functionality. That is, X allows users to control every aspect of its behavior. It also provides an extensive set of programming resources. X has often been described as the most complex and comprehensive windowing system ever designed. X provides for high-resolution graphics over network connections at high speed and throughput. In short, X comprises some of the most advanced windowing technology currently available. Some users characterize the complexity of X as a disadvantage, and there is probably a bit of merit to this. So many options are available that the casual user may quickly be overwhelmed.


Cross Reference: Readers who wish to learn more about X should visit the site of the X Consortium. The X Consortium comprises the authors of X. This group constantly sets and improves standards for the X Window System. Its site is at http://www.x.org/.


NOTE: Certain versions of X can be run on IBM-compatible machines in a DOS/Windows Environment.

Users familiar with the Microsoft platform can grasp the use of X in UNIX by likening it to the relationship between DOS and Microsoft Windows 3.11. The basic UNIX system is always available as a command-line interface and remains active and accessible, even when the user enters the X environment. In this respect, X runs on top of the basic UNIX system. While in the X environment, a user can access the UNIX command-line interface through a shell window (this at least appears to function much like the MS-DOS prompt window option available in Microsoft Windows). From this shell window, the user can perform tasks, execute commands, and view system processes at work.

Users start the X Window System by issuing the following command:

startx

X can run a series of window managers. Each window manager has a different look and feel. Some of these (such as twm) appear quite bare bones and technical, while others are quite attractive, even fancy. There is even one X window manager available that emulates the Windows 95 look and feel. Other platforms are likewise emulated, including the NeXT window system and the Amiga Workbench system. Other windowing systems (some based on X and some proprietary) are shown in Table 7.4.

Table 7.4. Common windowing systems in UNIX.

Window System Company
OpenWindows Sun Microsystems
AIXWindows IBM
HPVUE Hewlett Packard
Indigo Magic Silicon Graphics

What Kinds of Applications Run on UNIX?

Many types of applications run on UNIX. Some of these are high-performance applications for use in scientific research and artificial intelligence. I have already mentioned that certain high-level graphics applications are also common, particularly to the SGI platform. However, not every UNIX application is so specialized or eclectic. Perfectly normal applications run in UNIX, and many of them are recognizable names common to the PC and Mac communities (such as Adobe Photoshop, WordPerfect, and other front-line products).

Equally, I don't want readers to get the wrong idea. UNIX is by no means a platform that lacks a sense of humor or fun. Indeed, there are many games and amusing utilities available for this unique operating system.

Essentially, modern UNIX is much like any other platform in this respect. Window systems tend to come with suites of applications integrated into the package. These include file managers, text editors, mail tools, clocks, calendars, calculators, and the usual fare.

There is also a rich collection of multimedia software for use with UNIX, including movie players, audio CD utilities, recording facilities for digital sound, two-way camera systems, multimedia mail, and other fun things. Basically, just about anything you can think of has been written for UNIX.

UNIX in Relation to Internet Security

Because UNIX supports so many avenues of networking, securing UNIX servers is a formidable task. This is in contrast to servers implemented on the Macintosh or IBM-compatible platforms. The operating systems most common to these platforms do not support anywhere close to the number of network protocols natively available under UNIX.

Traditionally, UNIX security has been a complex field. In this respect, UNIX is often at odds with itself. UNIX was developed as the ultimate open system (that is, its source code has long been freely available, the system supports a wide range of protocols, and its design is uniquely oriented to facilitate multiple forms of communication). These attributes make UNIX the most popular networking platform ever devised. Nevertheless, these same attributes make security a difficult thing to achieve. How can you allow every manner of open access and fluid networking while still providing security?

Over the years, many advances have been made in UNIX security. These, in large part, were spawned by governmental use of the operating system. Most versions of UNIX have made it to the Evaluated Products List (EPL). Some of these advances (many of which were implemented early in the operating system's history) include


UNIX is used in many environments that demand security. As such, there are hundreds of security programs available to tune up or otherwise improve the security of a UNIX system. Many of these tools are freely available on the Internet. Such tools can be classified into two basic categories:


Security audit tools tend to be programs that automatically detect holes within systems. These typically check for known vulnerabilities and common misconfigurations that can lead to security breaches. Such tools are designed for wide-scale network auditing and, therefore, can be used to check many machines on a given network. These tools are advantageous because they reveal inherent weaknesses within the audited system. However, these tools are also liabilities because they provide powerful capabilities to crackers in the void. In the wrong hands, these tools can be used to compromise many hosts.

Conversely, system logging tools are used to record the activities of users and system messages. These logs are recorded to plain text files or files that automatically organize themselves into one or more database formats. Logging tools are a staple resource in any UNIX security toolbox. Often, the logs generated by such utilities form the basis of evidence when you pursue an intruder or build a case against a cracker. However, deep logging of the system can be costly in terms of disk space. Moreover, many of these tools work flawlessly at collecting data, but provide no easy way to interpret it. Thus, security personnel may be faced with writing their own programs to perform this task.

UNIX security is a far more difficult field than security on other platforms, primarily because UNIX is such a large and complicated operating system. Naturally, this means that obtaining personnel with true UNIX security expertise may be a laborious and costly process. For although these people aren't rare particularly, most of them already occupy key positions in firms throughout the nation. As a result, consulting in this area has become a lucrative business.

One good point about UNIX security is that because UNIX has been around for so long, much is known about its inherent flaws. Although new holes crop up on a fairly regular basis, their sources are quickly identified. Moreover, the UNIX community as a whole is well networked with respect to security. There are many mailing lists, archives, and online databases of information dealing with UNIX security. The same cannot be so easily said for other operating systems. Nevertheless, this trend is changing, particularly with regard to Microsoft Windows NT. There is now strong support for NT security on the Net, and that support is growing each day.

The Internet: How Big Is It?

This section requires a bit more history, and I am going to run through it rapidly. Early in the 1980s, the Internet as we now know it was born. The number of hosts was in the hundreds, and it seemed to researchers even then that the Internet was massive. Sometime in 1986, the first freely available public access server was established on the Net. It was only a matter of time--a mere decade, as it turned out--before humanity would storm the beach of cyberspace; it would soon come alive with the sounds of merchants peddling their wares.

By 1988, there were more than 50,000 hosts on the Net. Then a bizarre event took place: In November of that year, a worm program was released into the network. This worm infected numerous machines (reportedly over 5,000) and left them in various stages of disrupted service or distress (I will discuss this event in Chapter 5, "Is Security a Futile Endeavor?"). This brought the Internet into the public eye in a big way, plastering it across the front pages of our nation's newspapers.

By 1990, the number of Internet hosts exceeded 300,000. For a variety of reasons, the U.S. government released its hold on the network in this year, leaving it to the National Science Foundation (NSF). The NSF had instituted strong restrictions against commercial use of the Internet. However, amidst debates over cost considerations (operating the Internet backbone required substantial resources), NSF suddenly relinquished authority over the Net in 1991, opening the way for commercial entities to seize control of network bandwidth.

Still, however, the public at large did not advance. The majority of private Internet users got their access from providers like Delphi. Access was entirely command-line based and far too intimidating for the average user. This changed suddenly when revolutionary software developed at the University of Minnesota was released. It was called Gopher. Gopher was the first Internet navigation tool for use in GUI environments. The World Wide Web browser followed soon thereafter.

In 1995, NSF retired entirely from its long-standing position as overseer of the Net. The Internet was completely commercialized almost instantly as companies across America rushed to get connected to the backbone. The companies were immediately followed by the American public, which was empowered by new browsers such as NCSA Mosaic, Netscape Navigator, and Microsoft Internet Explorer. The Internet was suddenly accessible to anyone with a computer, a windowing system, and a mouse.

Today, the Internet sports more than 10 million hosts and reportedly serves some 40 million individuals. Some projections indicate that if Internet usage continues along its current path of growth, the entire Western world will be connected by the year 2001. Barring some extraordinary event to slow this path, these estimates are probably correct.

Today's Internet is truly massive, housing hundreds of thousands of networks. Many of these run varied operating systems and hardware platforms. Well over 100 countries besides the United States are connected, and that number is increasing every year. The only question is this: What does the future hold for the Internet?

The Future

There have been many projections about where the Internet is going. Most of these projections (at least those of common knowledge to the public) are cast by marketeers and spin doctors anxious to sell more bandwidth, more hardware, more software, and more hype. In essence, America's icons of big business are trying to control the Net and bend it to their will. This is a formidable task for several reasons.

One is that the technology for the Internet is now moving faster than the public's ability to buy it. For example, much of corporate America is intent on using the Internet as an entertainment medium. The network is well suited for such purposes, but implementation is difficult, primarily because average users cannot afford the necessary hardware to receive high-speed transmissions. Most users are getting along with modems at speeds of 28.8Kbps. Other options exist, true, but they are expensive. ISDN, for example, is a viable solution only for folks with funds to spare or for companies doing business on the Net. It is also of some significance that ISDN is more difficult to configure--on any platform--than the average modem. For some of my clients, this has been a significant deterrent. I occasionally hear from people who turned to ISDN, found the configuration problems overwhelming, and found themselves back at 28.8Kbps with conventional modems. Furthermore, in certain parts of the country, the mere use of an ISDN telephone line costs money per each minute of connection time.


NOTE: Although telephone companies initially viewed ISDN as a big money maker, that projection proved to be somewhat premature. These companies envisioned huge profits, which never really materialized. There are many reasons for this. One is that ISDN modems are still very expensive compared to their 28.8Kbps counterparts. This is a significant deterrent to most casual users. Another reason is that consumers know they can avoid heavy-duty phone company charges by surfing at night. (For example, many telephone companies only enforce heavy charges from 8:00 a.m. to 5:00 p.m.) But these are not the only reasons. There are other methods of access emerging that will probably render ISDN technology obsolete. Today's consumers are keenly aware of these trends, and many have adopted a wait-and-see attitude.

Cable modems offer one promising solution. These new devices, currently being tested throughout the United States, will reportedly deliver Net access at 100 times the speed of modems now in use. However, there are deep problems to be solved within the cable modem industry. For example, no standards have yet been established. Therefore, each cable modem will be entirely proprietary. With no standards, the price of cable modems will probably remain very high (ranging anywhere from $300 to $600). This could discourage most buyers. There are also issues as to what cable modem to buy. Their capabilities vary dramatically. Some, for example, offer extremely high throughput while receiving data but only meager throughput when transmitting it. For some users, this simply isn't suitable. A practical example would be someone who plans to video-conference on a regular basis. True, they could receive the image of their video-conference partner at high speed, but they would be unable to send at that same speed.


NOTE: There are other more practical problems that plague the otherwise bright future of cable modem connections. For example, consumers are told that they will essentially have the speed of a low-end T3 connection for $39 a month, but this is only partially true. Although their cable modem and the coax wire it's connected to are capable of such speeds, the average consumer will likely never see the full potential because all inhabitants in a particular area (typically a neighborhood) must share the bandwidth of the connection. For example, in apartment buildings, the 10mps is divided between the inhabitants patched into that wire. Thus, if a user in apartment 1A is running a search agent that collects hundreds of megabytes of information each day, the remaining inhabitants in other apartments will suffer a tremendous loss of bandwidth. This is clearly unsuitable.


Cross Reference: Cable modem technology is an aggressive climate now, with several dozen big players seeking to capture the lion's share of the market. To get in-depth information about the struggle (and what cable modems have to offer), point your Web browser to http://rpcp.mit.edu/~gingold/cable/.

Other technologies, such as WebTV, offer promise. WebTV is a device that makes surfing the Net as easy as watching television. These units are easily installed, and the interface is quite intuitive. However, systems such as WebTV may bring an unwanted influence to the Net: censorship. Many of the materials on the Internet could be characterized as highly objectionable. In this category are certain forms of hard-core pornography and seditious or revolutionary material. If WebTV were to become the standard method of Internet access, the government might attempt to regulate what type of material could appear. This might undermine the grass-roots, free-speech environment of the Net.


NOTE: Since the writing of this chapter, Microsoft Corporation has purchased WebTV (even though the sales for WebTV proved to be far less than industry experts had projected). Of course, this is just my personal opinion, but I think the idea was somewhat ill-conceived. The Internet is not yet an entertainment medium, nor will it be for some time, largely due to speed and bandwidth constraints. One wonders whether Microsoft didn't move prematurely in making its purchase. Perhaps Microsoft bought WebTV expressly for the purpose of shelving it. This is possible. After all, such a purchase would be one way to eliminate what seemed (at least at the time) to be some formidable competition to MSN.


Cross Reference: WebTV does have interesting possibilities and offers one very simple way to get acquainted with the Internet. If you are a new user and find Net navigation confusing, you might want to check out WebTV's home page at http://www.webtv.net/.

Either way, the Internet is about to become an important part of every American's life. Banks and other financial institutions are now offering banking over the Internet. Within five years, this will likely replace the standard method of banking. Similarly, a good deal of trade has been taken to the Net.

Summary

This chapter briefly examines the birth of the Internet. Next on the agenda are the historical and practical points of the network's protocols, or methods of data transport. These topics are essential for understanding the fundamentals of Internet security.


8

Internet Warfare

The Internet is an amazing resource. As you sit before your monitor, long after your neighbors are warm and cozy in their beds, I want you to think about this: Beyond that screen lies 4,000 years of accumulated knowledge. At any time, you can reach out into the void and bring that knowledge home.

There is something almost metaphysical about this. It's as though you can fuse yourself to the hearts and minds of humanity, read its innermost inspirations, its triumphs, its failures, its collective contributions to us all. With the average search engine, you can even do this incisively, weeding out the noise of things you deem nonessential.

For this reason, the Internet will ultimately revolutionize education. I'm not referring to home study or classes that save time by virtue of teaching 1,000 students simultaneously. Although these are all useful techniques of instruction that will undoubtedly streamline many tasks for teachers and students alike, I am referring to something quite different.

Today, many people have forgotten what the term education really means. Think back to your days at school. In every life there is one memorable teacher: One person who took a subject (history, for example) and with his or her words, brought that subject to life in an electrifying display. Through whatever means necessary, that person transcended the identity of instructor and entered the realm of the educator. There is a difference: One provides the basic information needed to effectively pass the course; the other inspires.

The Internet can serve as a surrogate educator, and users can now inspire themselves. The other night, I had dinner with a heavy-equipment operator. Since his childhood, he has been fascinated with deep space. Until recently, his knowledge of it was limited, primarily because he didn't have enough resources. He had a library card, true, but this never provided him with more than those books at his local branch. Only on two occasions had he ever ordered a book through inter-library loan. At dinner, he explained that he had just purchased a computer and gone online. There, he found a river of information. Suddenly, I realized I was no longer having dinner with a heavy-equipment operator; I was dining with an avid student of Einstein, Hawking, and Sagan. His talk was so riveting that I went away hungry for lack of having eaten.

So this much is true: The Internet is a an incredible resource for information. However, it is also an incredible resource for communication and basic human networking. Networking from a human standpoint is different from computer networking; human networking contains an added ingredient called action. Thus, individuals from all over the world are organizing (or I should say, crystallizing) into groups with shared interests. Women are organizing for equality, voters are organizing for representation, and parents are organizing for legislation to protect their children.

Inherent within this process is the exchange of opinions, or more aptly put, ideology. Ideology of any sort is bound to bring controversy, and controversy brings disagreement. Whether that disagreement occurs between two nations or between two individuals is irrelevant. When it occurs on the Internet, it often degenerates into warfare. That is what this chapter is about.

Much like the term information warfare, the term Internet warfare is often misunderstood. To understand Internet warfare, you must know that there are different classifications of it. Let's start with those classifications. From there, we can discuss warfare at its most advanced levels. The classifications are

More generally, Internet warfare is activity in which one or more participants utilize tools over the Internet to attack another or the information of another. The objective of the attack may be to damage information, hardware, or software, or to deny service. Internet warfare also involves any defensive action taken to repel such an attack.

Such warfare may be engaged in by anyone, including individuals, the general public, corporations, or governments. Between these groups, the level of technology varies (by technology, I am referring to all aspects of the tools required, including high-speed connections, software, hardware, and so forth). In general, the level of technology follows an upward path, as expressed in Figure 8.1.


The level of technology in Internet warfare.


NOTE: The categories Public and Individual may seem confusing. Why are they not included together? The reason is this: A portion of the public fails to meet the requirements for either corporate forces or individuals. This portion is composed of middle-level businesses, ISPs, universities, and so on. These groups generally have more technologically advanced tools than individuals, and they conduct warfare in a different manner.

As you might guess, there are fundamental reasons for the difference between these groups and the tools that they employ. These reasons revolve around economic and organizational realities. The level of technology increases depending upon certain risks and demands regarding security. This is graphically illustrated in Figure 8.2.


Risks and demands as they relate to various levels of technology.

Naturally, government and corporate entities are going to have more financial resources to acquire tools. These tools will be extremely advanced, created by vendors who specialize in high-performance, security-oriented applications. Such applications are generally more reliable than average tools, having been tested repeatedly under a variety of conditions. Except in extreme cases (those where the government is developing methods of destructive data warfare for use against foreign powers), nearly all of these tools will be defensive in character.

Public organizations tend to use less powerful tools. These tools are often shareware or freeware, which is freely available on the Internet. Much of this software is designed by graduate students in computer science. Other sources include companies that also sell commercial products, but are giving the Internet community a little taste of the quality of software available for sale. (Many companies claim to provide these tools out of the goodness of their hearts. Perhaps. In any event, provide them they do, and that is sufficient.) Again, nearly all of these tools are defensive in character.

Private individuals use whatever they come across. This may entail shareware or freeware, programs they use at work, or those that have been popularly reviewed at sites of public interest.

The Private Individual

The private individual doesn't usually encounter warfare (at least, not the average user). When one does, it generally breaks down to combat with another user. This type of warfare can be anticipated and, therefore, avoided. When a debate on the Net becomes heated, you may wish to disengage before warfare erupts. Although it has been said a thousand times, I will say it again: Arguments appear and work differently on the Internet than in person. E-mail or Usenet news messages are delivered in their entirety, without being interrupted by points made from other individuals. That is, you have ample time to write your response. Because you have that time, you might deliver a more scathing reply than you would in person. Moreover, people say the most outrageous things when hiding behind a computer, things they would never utter in public. Always consider these matters. That settled, I want to examine a few tools of warfare between individuals.

The E-Mail Bomb

The e-mail bomb is a simple and effective harassment tool. A bomb attack consists of nothing more than sending the same message to a targeted recipient over and over again. It is a not-so-subtle form of harassment that floods an individual's mailbox with junk.

Depending upon the target, a bomb attack could be totally unnoticeable or a major problem. Some people pay for their mail service (for example, after exceeding a certain number of messages per month, they must pay for additional e-mail service). To these individuals, an e-mail bomb could be costly. Other individuals maintain their own mail server at their house or office. Technically, if they lack storage, one could flood their mailbox and therefore prevent other messages from getting through. This would effectively result in a denial-of-service attack. (A denial-of-service attack is one that degrades or otherwise denies computer service to others. This subject is discussed in Chapter 14, "Destructive Devices.") In general, however, a bomb attack (which is, by the way, an irresponsible and childish act) is simply annoying. Various utilities available on the Internet will implement such an attack.

One of the most popular utilities for use on the Microsoft Windows platform is Mail Bomber. It is distributed in a file called bomb02.zip and is available at many cracker sites across the Internet. The utility is configured via a single screen of fields into which the user enters relevant information, including target, mail server, and so on (see Figure 8.3).


The Mail Bomber application.

The utility works via Telnet. It contacts port 25 of the specified server and generates the mail bomb. Utilities like this are commonplace for nearly every platform. Some are for use anywhere on any system that supports SMTP servers. Others are more specialized, and may only work on systems like America Online. One such utility is Doomsday, which is designed for mass mailings over AOL but is most commonly used as an e-mail bomber. The entire application operates from a single screen interface, shown in Figure 8.4.


The Doomsday mail bomber.


NOTE: For several years, the key utility for AOL users was AOHELL, which included in its later releases a mail-bomb generator. AOHELL started as a utility used to unlawfully access America Online. This, coupled with other utilities such as credit-card number generators, allowed users to create free accounts using fictitious names. These accounts typically expired within two to three weeks.

On the UNIX platform, mail bombing is inanely simple; it can be accomplished with just a few lines. However, one wonders why someone skilled in UNIX would even entertain the idea. Nevertheless, some do; their work typically looks something like this:

#!/bin/perl
$mailprog = `/usr/lib/sendmail';
$recipient = `victim@targeted_site.com';
$variable_initialized_to_0 = 0;
while ($variable_initialized_to_0 < 1000) {
open (MAIL, "|$mailprog $recipient") || die "Can't open $mailprog!\n";
print MAIL "You Suck!";
close(MAIL);
sleep 3;
$variable_initialized_to_0++;
}

The above code is fairly self-explanatory. It initializes a variable to 0, then specifies that as long as that variable is less than the value 1000, mail should be sent to the targeted recipient. For each time this program goes through the while loop, the variable called $variable_initialized_to_0 is incremented. In short, the mail message is sent 999 times.

Mail bombing is fairly simple to defend against: Simply place the mailer's identity in a kill or bozo file. This alerts your mail package that you do not want to receive mail from that person. Users on platforms other than UNIX may need to consult their mail applications; most of them include this capability.

UNIX users can find a variety of sources online. I also recommend a publication that covers construction of intelligent kill file mechanisms: Teach Yourself the UNIX Shell in 14 Days by David Ennis and James Armstrong Jr. (Sams Publishing). Chapter 12 of that book contains an excellent script for this purpose. If you are a new user, that chapter (and in fact, the whole book) will serve you well. (Moreover, users who are new to UNIX but have recently been charged with occasionally using a UNIX system will find the book very informative.)

Oh yes. For those of you who are seriously considering wholesale e-mail bombings as a recreational exercise, you had better do it from a cracked mail server. A cracked mail server is one that the cracker currently has control of; it is a machine running sendmail that is under the control of the cracker.

If not, you may spend some time behind bars. One individual bombed Monmouth University in New Jersey so aggressively that the mail server temporarily died. This resulted in a FBI investigation, and the young man was arrested. He is reportedly facing several years in prison.

I hope that you refrain from this activity. Because e-mail bombing is so incredibly simple, even crackers cast their eyes down in embarrassment and disappointment if a comrade implements such an attack.

List Linking

List linking is becoming increasingly common. The technique yields the same basic results as an e-mail bomb, but it is accomplished differently. List linking involves enrolling the target in dozens (sometimes hundreds) of e-mail lists.

E-mail lists (referred to simply as lists) are distributed e-mail message systems. They work as follows: On the server that provides the list service, an e-mail address is established. This e-mail address is really a pointer to an executable program. This program is a script or binary file that maintains a database (usually flat file) of e-mail addresses (the members of the list). Whenever a mail message is forwarded to this special e-mail address, the text of that message is forwarded to all members on the list (all e-mail addresses held in the database). These are commonly used to distribute discussions on various topics of interest to members.

E-mail lists generate a lot of mail. For example, the average list generates 30 or so messages per day. These messages are received by each member. Some lists digest the messages into a single-file format. This works as follows: As each message comes in, it is appended to a plain text file of all messages forwarded on that day. When the day ends (this time is determined by the programmer), the entire file--with all appended messages--is mailed to members. This way, members get a single file containing all messages for the day.

Enrolling a target in multiple mailing lists is accomplished in one of two ways. One is to do it manually. The harassing party goes to the WWW page of each list and fills in the registration forms, specifying the target as the recipient or new member. This works for most lists because programmers generally fail to provide an authentication routine. (One wonders why. It is relatively simply to get the user's real address and compare it to the one he or she provides. If the two do not match, the entire registration process could be aborted.)

Manually entering such information is absurd, but many individuals do it. Another and more efficient way is to register via fakemail. You see, most lists allow for registration via e-mail. Typically, users send their first message to an e-mail address such as this one:

list_registration@listmachine.com

Any user who wants to register must send a message to this address, including the word subscribe in either the subject line or body of the message. The server receives this message, reads the provided e-mail address in the From field, and enrolls the user. (This works on any platform because it involves nothing more than sending a mail message purporting to be from this or that address.)

To sign up a target to lists en masse, the harassing party first generates a flat file of all list- registration addresses. This is fed to a mail program. The mail message--in all cases--is purportedly sent from the target's address. Thus, the registration servers receive a message that appears to be from the target, requesting registration to the list.

This technique relies on the forging of an e-mail message (or generating fakemail). Although this is explained elsewhere, I should relate something about it here. To forge mail, one sends raw commands to a sendmail server. This is typically found on port 25 of the target machine. Forging techniques work as follows: You Telnet to port 25 of a UNIX machine. There, you begin a mail session with the command HELO. After you execute that command, the session is open. You then specify the FROM address, providing the mail server with a bogus address (in this case, the target to be list-linked). You also add your recipient and the message to be sent. For all purposes, mail list archives believe that the message came from its purported author.

It takes about 30 seconds to register a target with 10, 100, or 500 lists. What is the result? Ask the editorial offices of Time magazine.

On March 18, 1996, Time published an article titled "I'VE BEEN SPAMMED!" The story concerned a list-linking incident involving the President of the United States, two well-known hacking magazines, and a senior editor at Time. Apparently, a member of Time's staff was list-linked to approximately 1,800 lists. Reportedly, the mail amounted to some 16MB. It was reported that House Leader Newt Gingrich had also been linked to the lists. Gingrich, like nearly all members of Congress, had an auto-answer script on his e-mail address. These trap e-mail addresses contained in incoming messages and send automated responses. (Congressional members usually send a somewhat generic response, such as "I will get back to you as soon as possible and appreciate your support.") Thus, Gingrich's auto-responder received and replied to each and every message. This only increased the number of messages he would receive, because for each time he responded to a mailing list message, his response would be appended to the outgoing messages of the mailing list. In effect, the Speaker of the House was e-mail bombing himself.

For inexperienced users, there is no quick cure for list linking. Usually, they must send a message containing the string unsubscribe to each list. This is easily done in a UNIX environment, using the method I described previously to list-link a target wholesale. However, users on other platforms require a program (or programs) that can do the following:

There are other ways to make a target the victim of an e-mail bomb, even without using an e-mail bomb utility or list linking. One is particularly insidious. It is generally seen only in instances where there is extreme enmity between two people who publicly spar on the Net. It amounts to this: The attacker posts to the Internet, faking his target's e-mail address. The posting is placed into a public forum in which many individuals can see it (Usenet, for example). The posting is usually so offensive in text (or graphics) that other users, legitimately and genuinely offended, bomb the target. For example, Bob posts to the Net, purporting to be Bill. In "Bill's" post, an extremely racist message appears. Other users, seeing this racist message, bomb Bill.

Finally, there is the garden-variety case of harassment on the Internet. This doesn't circumvent either security or software, but I could not omit mention of it. Bizarre cases of Internet harassment have arisen in the past. Here are a few:

These cases pop up with alarming frequency. Some have been racially motivated, others have been simple harassment. Every user should be aware that anyone and everyone is a potential target. If you use the Internet, even if you haven't published your real name, you are a viable target, at least for threatening e-mail messages.

Internet Relay Chat Utilities

Many Internet enthusiasts are unfamiliar with Internet Relay Chat (IRC). IRC is an arcane system of communication that resembles bulletin board systems (BBSs). IRC is an environment in which many users can log on and chat. That is, messages typed on the local machine are transmitted to all parties within the chat space. These scroll down the screen as they appear, often very quickly.

This must be distinguished from chat rooms that are provided for users on systems such as AOL. IRC is Internet-wide and is free to anyone with Internet access. It is also an environment that remains the last frontier of the lawless Internet.

The system works as follows: Using an IRC client, the user connects to an IRC server, usually a massive and powerful UNIX system in the void. Many universities provide IRC servers.


Cross Reference: The ultimate list of the world's IRC servers can be found at http://www.webmaster.com/webstrands/resources/irc/#List of Servers.

Once attached to an IRC server, the individual specifies the channel to which he or she wishes to connect. The names of IRC channels can be anything, although the established IRC channels often parallel the names of Usenet groups. These names refer to the particular interest of the users that frequent the channel. Thus, popular channels are

There are thousands of established IRC channels. What's more, users can create their own. In fact, there are utilities available for establishing a totally anonymous IRC server (this is beyond the scope of this discussion). Such programs do not amount to warfare, but flash utilities do. Flash utilities are designed to do one of two things:

Flash utilities are typically small programs written in C, and are available on the Internet at many cracking sites. They work by forwarding a series of special-character escape sequences to the target . These character sequences flash, or incapacitate, the terminal of the target. In plain talk, this causes all manner of strange characters to appear on the screen, forcing the user to log off or start another session. Such utilities are sometimes used to take over an IRC channel. The perpetrator enters the channel and flashes all members who are deemed to be vulnerable. This temporarily occupies the targets while they reset their terminals.

By far, the most popular flash utility is called flash. It is available at hundreds of sites on the Internet. For those curious about how the code is written, enter one or all of these search strings into any popular search engine:

flash.c
flash.c.gz
flash.gz
megaflash

Another popular utility is called nuke. This utility is far more powerful than any flash program. Rather than fiddle with someone's screen, it simply knocks the user from the server altogether. Note that using nuke on a wholesale basis to deny computer service to others undoubtedly amounts to unlawful activity. After some consideration, I decided that nuke did not belong on the CD-ROM that accompanies this book. However, for those determined to get it, it exists in the void. It can be found by searching for the filename nuke.c.

There are few other methods by which one can easily reach an individual. The majority of these require some actual expertise on the part of the attacker. In this class are the following methods of attack:

Although these are extensively covered later in this book, I want to briefly treat them here. They are legitimate concerns and each user should be aware of these actual dangers on the Net.

Virus Infections and Trojan Horses

Virus attacks over the Internet are rare but not unheard of. The primary place that such attacks occur is the Usenet news network. You will read about Usenet in the next section. Here, I will simply say this: Postings to Usenet can be done relatively anonymously. Much of the information posted in Usenet these days involves pornography, files on cracking, or other potentially unlawful or underground material. This type of material strongly attracts many users and as such, those with malicious intent often choose to drop their virus in this network.

Commonly, viruses or malicious code masquerade as legitimate files or utilities that have been zipped (compressed) and released for general distribution. It happens. Examine this excerpt from a June 6, 1995 advisory from the Computer Incident Advisory Capability Team at the U.S. Department of Energy:

A trojaned version of the popular, DOS file-compression utility PKZIP is circulating on the networks and on dial-up BBS systems. The trojaned files are PKZ300B.EXE and PKZ300B.ZIP. CIAC verified the following warning from PKWARE:

"Some joker out there is distributing a file called PKZ300B.EXE and PKZ300B.ZIP. This is NOT a version of PKZIP and will try to erase your hard drive if you use it. The most recent version is 2.04G. Please tell all your friends and favorite BBS stops about this hack.

"PKZ300B.EXE appears to be a self extracting archive, but actually attempts to format your hard drive. PKZ300B.ZIP is an archive, but the extracted executable also attempts to format your hard drive. While PKWARE indicated the trojan is real, we have not talked to anyone who has actually touched it. We have no reports of it being seen anywhere in the DOE.

"According to PKWARE, the only released versions of PKZIP are 1.10, 1.93, 2.04c, 2.04e and 2.04g. All other versions currently circulating on BBSs are hacks or fakes. The current version of PKZIP and PKUNZIP is 2.04g."

That advisory was issued very quickly after the first evidence of the malicious code was discovered. At about the same time, a rather unsophisticated (but nevertheless destructive) virus called Caibua was released on the Internet. Many users were infected. The virus, under certain conditions, would overwrite the default boot drive.


Cross Reference: Virus attacks and defenses against them are discussed in Chapter 14, "Destructive Devices." However, I highly recommend that all readers bookmark http://ciac.llnl.gov/ciac/CIACVirusDatabase.html. This site is one of the most comprehensive virus databases on the Internet and an excellent resource for learning about various viruses that can affect your platform.

Here's an interesting bit of trivia: If you want to be virus-free, use UNIX as your platform. According to the CIAC, there has only been one recorded instance of a UNIX virus, and it was created purely for research purposes. It was called the AT&T Attack Virus.


Cross Reference: If you want to see an excellent discussion about UNIX and viruses, check out "The Plausibility of UNIX Virus Attacks" by Peter V. Radatti at http://www.cyber.com/papers/plausibility.html.

Radatti makes a strong argument for the plausibility of a UNIX virus. However, it should be noted that virus authors deem UNIX a poor target platform because of access-control restrictions. It is felt that such access-control restrictions prevent the easy and fluid spread of the virus, containing it in certain sectors of the system. Therefore, for the moment anyway, UNIX platforms have little to fear from virus authors around the world.

Nonetheless, as I discuss in Chapter 14, at least one virus for Linux has been confirmed. This virus is called Bliss. Reports on Bliss at the time of this writing are sketchy. There is some argument on the Internet as to whether Bliss qualifies more as a trojan, but the majority of reports suggest otherwise. Furthermore, it is reported that it compiles cleanly on other UNIX platforms.


Cross Reference: The only known system tool that checks for Bliss infection was written by Alfred Huger and is located at ftp://ftp.secnet.com/pub/tools/abliss.tar.gz.


NOTE: There is some truth to the assertion that many viruses are written overseas. The rationale for this is as follows: Many authorities feel that authors overseas may not be compensated as generously for their work and they therefore feel disenfranchised. Do you believe it? I think it's possible.

In any event, all materials downloaded from a nontrusted source should be scanned for viruses. The best protection is a virus scanner; there are many for all personal computer platforms. Even though this subject is covered extensively later, Table 8.1 shows a few.

Table 8.1. Virus scanners by platform.

Platform Virus
Windows/DOS Thunderbyte, F-PROT, McAfee's Virus Scan, TBAV
Windows 95 McAfee's Virus Scan, Thunderbyte, Dr. Antivirus
Windows NT Norton Antivirus, Sweep, NTAV, NT ViruScan, McAfee's Virus Scan
Macintosh Gatekeeper, Disinfectant, McAfee's Virus Scan
OS/2 McAfee's Virus Scan

Malicious code is slightly different from a virus, but I want to mention it briefly (even though I cover malicious code extensively in Chapter 14). Malicious code can be defined as any programming code that is not a virus but that can do some harm, however insignificant, to a user's software.

Today, the most popular form of malicious code involves the use of black widow apps, or small, portable applications in use on the WWW that can crash or otherwise incapacitate your WWW browser. These are invariably written in scripting languages like JavaScript or VBScript. These tiny applications are embedded within the HTML code that creates any Web page. In general, they are fairly harmless and do little more than force you to reload your browser. However, there is some serious talk on the Net of such applications being capable of:

These claims are not fictional. The programming expertise required to wreak this havoc is uncommon in prankster circles. However, implementing such apps is difficult and risky because their origin can be easily traced in most instances. Moreover, evidence of their existence is easily obtained simply by viewing the source code of the host Web page. However, if such applications were employed, they would be employed more likely with Java, or some other compiled language.

In any event, such applications do exist. They pose more serious risks to those using networked operating systems, particularly if the user is browsing the Web while logged into an account that has special privileges (such as root, supervisor, or administrator). These privileges give one great power to read, write, alter, list, delete, or otherwise tamper with special files. In these instances, if the code bypasses the browser and executes commands, the commands will be executed with the same privileges as the user. This could be critical and perhaps fatal to the system administrator. (Not physically fatal, of course. That would be some incredible code!)

Cracking

Cracking an individual is such a broad subject that I really cannot cover it here. Individuals use all kinds of platforms, and to insert a "cracking the individual" passage here would defeat the purpose of this book (or rather, the whole book would have to appear in this chapter). I say this because throughout this book, I discuss cracking different platforms with different techniques and so on. However, I will make a general statement here:

Users who surf using any form of networked operating system are viable targets. So there is no misunderstanding, let me identify those operating systems:

If you are connected to the Net with such an operating system, you are a potential target of an online crack. Much depends on what services you are running, but be assured: If you are running TCP/IP as a protocol, you are a target. Equally, those Windows 95 users who share out directories are also targets. (I discuss this in detail in Chapter 16, "Microsoft," but briefly, shared out directories are those that allow file sharing across a network.)

The Public and Corporations

This section starts with the general public. The general public is often a target of Internet warfare, though most Internet users may remain unaware of this. Attacks against the general public most often occur on the Usenet news network. I want to briefly describe what Usenet is, for many users fail to discover Usenet news even after more than a year of Internet use. In that respect, Usenet news is much like IRC. It is a more obscure area of the Internet, accessible through browsers, but more commonly accessed through newsreaders. Some common newsreaders for various platforms are shown in Table 8.2.

Table 8.2. Newsreaders by platform.

Platform Newsreader
Windows Free Agent, WinVn, Smart Newsreader, Virtual Access, 32 bit News, SB Newsbot, News Xpress, Microsoft News
UNIX TRN, TIN, Pine, Xnews, Netscape Navigator, INN
Windows 95 Free Agent, WinVn, Smart Newsreader, Virtual Access, 32 bit News, SB Newsbot, News Xpress, Microsoft News
Windows NT Free Agent, WinVn, Smart Newsreader, Virtual Access, 32 bit News, SB Newsbot, News Xpress, Microsoft News
Macintosh Netscape Navigator, NewsWatcher, Cyberdog, Internews, Nuntius,
OS/2 Newsbeat, Postroad,

The interface of a typical browser includes a listing of newsgroup messages currently posted to the selected newsgroup. These messages are displayed for examination in the newsreader. For example, examine Figure 8.5, which shows a Free Agent Usenet session reviewing posted messages (or articles) to the Usenet group.


A typical Usenet session using Free Agent by Forte.

Usenet news is basically a massive, public bulletin board system. On it, users discuss various topics of interest. They do this by posting messages to the system. These messages are saved and indexed with all messages on that topic. The totality of messages posted on a particular topic form a discussion thread. This thread is generally arranged chronologically. The typical progression is this:

1. One user starts a thread by posting a message.

2. Another user sees this message, disagrees with the original poster, and posts a rebuttal.

3. More users see this exchange and jump in on the action, either supporting or rebutting the original posts (and all subsequent ones.)

If this sounds adversarial, it's because it is. Although peaceful Usenet discussions are common, it is more common to see arguments in progress.

In any event, Usenet messages are probably the most graphic example of free speech in America. One can openly express opinions on any subject. It is a right of all Internet users. Sometimes, however, others directly interfere with that right. For example, in September, 1996, someone erased approximately 27,000 messages posted by various ethnic groups and other interested parties. As Rory J. O'Connor of the Mercury News reported:

One of the more popular mass communication forms on the Internet was sabotaged last weekend, wiping clean dozens of public bulletin boards with tens of thousands of messages frequented by Jews, Muslims, feminists, and gays, among others.

This type of activity, called canceling, is common and, to date, there is no clear application of U.S. law to deal with it. For example, some legal experts are still debating whether this constitutes an offense as defined under current law. Offense under criminal law or not, it would appear that such activity could constitute a tort or civil wrong of some classification. For example, the Internet has not yet been the target of any lawsuit based on antitrust law. However, it would seem reasonable that antitrust claims (those alleging attempted restraint of interstate commerce) could apply. This is a question that will undoubtedly take a decade to sort out. For although the technology of the Internet moves quickly indeed, the legal system grinds ahead at a slow pace.

Canceling refers to that activity where a user generates a cancel command for a given Usenet message. By sending this cancel command, the user erases the Usenet message from the Internet. This feature was added to the Usenet system so that a user could cancel a message if he or she suddenly decided it wasn't appropriate or had lost its value. This is discussed more in Chapter 13, "Techniques to Hide One's Identity."


Cross Reference: If you are interested in cancel techniques and want to know more, there are several resources. First, the definitive document on what types of cancels are permitted is at http://www.math.uiuc.edu/~tskirvin/home/rfc1036b.

The FAQ about cancel messages is at http://www.lib.ox.ac.uk/internet/news/faq/archive/usenet.cancel-faq.part1.html.


Cancel techniques are often used against advertisers who attempt to flood the Usenet network with commercial offerings (this activity is referred to as spamming). Such advertisers typically use commercial software designed to make Usenet postings en masse. This is required for the task, as there are over 20,000 Usenet groups to date. To target each one would be no less laborious than mailing 20,000 e-mail messages. Thus, mass-posting utilities are becoming the latest hot item for commercial advertisers. Alas, they may be wasting their money.

Several individuals skilled in Internet programming have created cancelbots. These are programs that go onto the Usenet network and search for messages that fit programmer-defined criteria. When these messages are identified, they are canceled. This can be done by anyone on a small scale. However, this technique is impractical to generate cancels en masse. For this, you use a cancelbot. Cancelbots are robots, or automated programs that can automatically cancel thousands of messages.

In the past, these utilities have been used primarily by purists who disapprove of commercialization of the Net. They chiefly target advertisers who fail to observe good Netiquette. The Usenet community has traditionally supported such efforts. However, a new breed of canceler is out there: This breed cancels out of hatred or intolerance, and the phenomenon is becoming more prevalent. In fact, cancelbots are just the tip of the iceberg.

Many special-interest groups take their battles to the Net, and cancel messaging is one weapon the often use. For example, consider the debate over Scientology. The Church of Scientology is a large and influential organization. Many people question the validity of the Scientologist creed and belief. In the past few years, several open wars have erupted on the Usenet network between Scientologists and their critics. (The Usenet group in question here is alt.religion.scientology.) These wars were attended by some fairly mysterious happenings. At one stage of a particularly ugly struggle, when the Scientologists seemed overwhelmed by their sparring partners, a curious thing happened:

And thus it was that in late 1994, postings began to vanish from alt.religion.scientology, occasionally with an explanation that the postings had been "canceled because of copyright infringement." To this day, it is not known who was behind the deployment of these "cancelbots," as they are known. Again, the CoS disclaimed responsibility, and the anti-Scientology crowd began to refer to this anonymous participant simply as the "Cancel-bunny," a tongue-in-cheek reference to both the Energizer bunny and to a well-known Net inhabitant, the Cancelmoose, who has taken it upon himself (itself?, themselves?) to set up a cancelbot-issuing process to deal with other kinds of spamming incidents. But whoever or whatever the Cancelbunny may be, its efforts were quickly met by the development of yet another software weapon, appropriately dubbed "Lazarus," that resurrects canceled messages (or, more accurately, simply alerts the original poster, and all other participants in the newsgroup, that a specific message has been canceled, leaving it up to the original poster to reinstate the message if he or she were not the party that issued the cancel command).1


1"The First Internet War; The State of Nature and the First Internet War: Scientology, its Critics, Anarchy, and Law in Cyberspace." David G. Post, Reason magazine. April, 1996. (Copyright trailer follows: (c) 1996 David G. Post. Permission granted to redistribute freely, in whole or in part, with this notice attached.)

The controversy between the Scientologists and their critics was indeed the first war on the Internet. That war isn't over yet, either. Unfortunately for all parties concerned, the war wafted out of cyberspace and into courts in various parts of the world. In short, warring in cyberspace simply wasn't satisfying enough. The combatants have therefore taken to combat in the real world.


Cross Reference: If you are genuinely interested in this war, which is truly brutal, visit http://www.cybercom.net/~rnewman/scientology/home.html.

The Internet is an odd place, and there are many people there who want to harm each other. In this respect, the Internet is not radically different from reality. The problem is that on the Internet, these people can find each other without much effort. Furthermore, violent exchanges are almost always a public spectacle, and the Internet has no riot police. You have choices, and here they are:

I recommend a combination of the first and last options. That way, you are out of the line of fire. And if, for some inexplicable reason, someone pulls you into the line of fire, you can blow them right out of cyberspace.

Internet Service Providers

Internet service providers (ISPs) are the most likely to engage in warfare, immediately followed by universities. I want to address ISPs first. For our purposes, an ISP is any organization that provides Internet access service to the public or even to a limited class of users. This definition includes freenets, companies that provide access to their employees, and standard ISPs that provide such services for profit. Internet access service means any service that allows the recipient of such service to access any portion of the Internet, including but not limited to mail, Gopher, HTTP, Telnet, FTP, or other access by which the recipient of such services may traffic data of any kind to or from the Internet.

ISPs are in a unique position legally, commercially, and morally. They provide service and some measure of confidentiality to their users. In that process, they undertake a certain amount of liability. Unfortunately, the parameters of that liability have not yet been adequately defined in law. Is an ISP responsible for the content of its users' messages?

Suppose users are utilizing the ISP's drives to house a pirated software site. Is the ISP liable for helping facilitate criminal activity by failing to implement action against pirates?

If a cracker takes control of an ISP and uses it to attack another, is the first ISP liable? (Did it know or should it have known its security was lax and thus the damages of the victim were foreseeable?)

If a user retouches trademarked, copyrighted cartoon characters into pornographic representations and posts them on a Web page, is the ISP at fault?

These are questions that have yet to be answered. And from the first case where a plaintiff's attorneys manage to hoist that liability onto ISPs, the freedom of the Internet will begin to wither and die. These are not the only problems facing ISPs.

Because they provide Internet access services, they have one or more (usually thousands of) individuals logged into their home network. This presents a terrific problem: No matter how restrictive the policies of an ISP might be, its users will always have some level of privilege on the network. That is, its users must, at a minimum, have access to log in. Frequently, they have more.

Granted, with the advent of HTML browsers, the level of access of most users is now lower than in the past. In earlier years, users of an ISP's services would log in via Telnet. Thus, users were logged directly to the server and received shell access. From this point, such users were capable of viewing many different files and executing a variety of programs. Thus, for ISPs of the old days, internal threats were substantial. In contrast, most users access today using some dial-up program that provides a PPP link between them and the ISP. The remaining navigation of the Internet is done through a browser, which often obviates the need for the user to use Telnet. Nevertheless, internal threats remain more common than any other type.

The majority of these threats are from small-time crackers looking to steal the local password files and gain some leverage on the system. However, there exists a real risk of attacks from the outside. Sometimes, for no particular reason, crackers may suddenly attack an ISP. Here are some recent examples:

Cybertown, a popular spot for Net surfers, was cracked. Crackers apparently seized control and replaced the attractive, friendly Web pages with their own. This same group of crackers reportedly later seized control of Rodney Dangerfield's site. Mr. Dangerfield, it seems, cannot get any respect, even on the Internet.

Universities are in exactly the same position. The only major difference is that universities have some extremely talented security enthusiasts working in their computer science labs. (Some of the higher-quality papers about security posted to the Internet have come from such students.)

These entities are constantly under attack and in a state of war. So what types of tools are they using to protect themselves? Not surprisingly, most of these tools are defensive in character. The majority, in fact, may do less to protect than to gather evidence. In other words, Big Brother is watching because crackers have forced him to do so.

The key utilities currently in use are logging utilities. These are relatively low-profile weapons in Internet warfare. They are the equivalent of security guards, and generally either alert the supervisor to suspicious activity or record the suspicious activity for later use. A few such utilities are listed in Table 8.3.

Table 8.3. Various logging and snooping utilities of interest.

Utility Function
L5 Scans either UNIX or DOS directory structures, recording all information about files there. Is used to determine suspicious file changes, files in restricted areas, or changes in file sizes. (For use in detecting trojans.)
Clog Listens to determine whether crackers (from the outside) are trying to find holes in the system.
LogCheck Automates log file analysis to determine whether system violations have occurred. It does this by scanning existing log files.
Netlog Listens and logs TCP/IP connections, searching for suspicious activity therein. This package is from Texas A&M University.
DumpACL Windows NT utility that formats important access-control information into convenient, readable formats for quick analysis of the system's security.

Later in this book, I will examine dozens of utilities like those in Table 8.3. The majority of utilities mentioned so far are either freeware, shareware, or relatively inexpensive. They are used chiefly by public entities such as ISPs and universities. However, an entire world of corporate sources is available. As you might expect, American corporations are concerned about their security.

Corporations often maintain sensitive information. When they get cracked, the crackers usually know what they are looking for. For example, the famous cracker Kevin Mitnik reportedly attempted to steal software from Santa Cruz Operation (SCO) and Digital Equipment Corporation (DEC). These two companies manufactured high-performance operating systems. Mitnik was allegedly interested in obtaining the source code of both. Undoubtedly, Mitnik had intentions of examining the internal workings of these systems, perhaps to identify flaws within their structures.

Corporations operate a little bit differently from other entities, largely because of their organizational structure. Management plays a strong role in the security scheme of any corporation. This differs from universities or ISPs where those with actual security knowledge are handling the situation.

Corporate entities are going to have to come to terms with Internet warfare very soon. For although corporations have the resources to keep penetration of their networks secret, this practice is not advisable. Corporate America wants the Internet badly. In the Internet, they see potential for profit as well as networking. (Several banks have already begun preparing to provide online banking. How effectively they can implement this remains to be seen.)

Some excellent research has proven that a large portion of corporate America is not secure. In Chapter 9, "Scanners," you will learn about scanners, which conduct automated security surveys of remote sites. One such utility is SATAN. This tool was created for the benefit of Internet security by Dan Farmer and Weitse Venema. In December, 1996, Dan Farmer conducted a survey of approximately 2,000 randomly chosen networks in the void.

The survey was called "Shall We Dust Moscow? Security Survey of Key Internet Hosts & Various Semi-Relevant Reflections." A significant number of the sampled hosts were corporate sites, including banks, credit unions, and other financial institutions: organizations that are charged with keeping the nation's finances secure. Farmer's findings were shocking. Large numbers of corporate sites could be cracked by attackers with minimal to complex knowledge of the target host's operating system.


Cross Reference: Rather than parade Mr. Farmer's hard-earned statistics here, I will point you to the site where the survey is publicly available: http://www.trouble.org/survey/.

If you examine the survey, you will find that almost 60 percent of those sites surveyed are in some way vulnerable to remote attack. Many of those are institutions on which the American public relies.

Today, corporate entities are rushing to the Net in an effort to establish a presence. If such organizations are to stay, they must find resources for adequate security. Again, the problem boils down to education. While I was writing this chapter, I received an e-mail message from a firm on the east coast, requesting an estimate on a security audit. That site maintained no firewall and had three possible entry points. Two of these machines were easily crackable by any average cracker. The remaining machine could be cracked after running just one SATAN scan against it.

If there is any group of individuals that needs to obtain books like this one (and, the wealth of all security information now available on the Net), it is America's corporate community. I have had consultations with information managers that have an uphill battle in convincing their superiors that security is a major issue. Many upper-level management officers do not adequately grasp the gravity of the situation. Equally, these folks stand a good chance of being taken, or fleeced, by so-called security specialists. All in all, a dirty war is being fought out there.

Before I close with some reflections about government, I would like to impart this: Internet warfare occurs between all manners of individual and organization on the Internet. This trend will only continue to increase in the near future. There are bandits, charlatans, gunslingers, and robbers...the Internet is currently just slightly less lawless than the stereotypical image of the Old West. Until laws become more concrete and focused, my suggestion to you, no matter what sector you may occupy, is this: Absorb much of the voluminous security literature now available on the Internet. Throughout this book, I provide many references to assist you in that quest.

The Government

Government Internet warfare refers to that warfare conducted between the U.S. government and foreign powers. (Though, to be honest, the majority of Internet warfare that our government has waged has been against domestic hackers. I will briefly discuss that issue a little later on in this section.)

One would imagine that the U.S. government is amply prepared for Internet warfare. Well, it isn't. Not yet. However, recent research suggests that it is gearing up for it. In a 1993 paper, specialists from Rand Corporation posed the question of whether the United States was prepared for a contingency it labeled cyberwar. The authors of that paper posed various questions about the U.S.'s readiness and made recommendations for intensive study on the subject:

We suggest analytical exercises to identify what cyberwar, and the different modalities of cyberwar, may look like in the early twenty-first century when the new technologies should be more advanced, reliable, and internetted than at present. These exercises should consider opponents that the United States may face in high- and low-intensity conflicts. CYBERWAR IS COMING!2


2John Arquilla and David Ronfeldt, International Policy Department, RAND. 1993. Taylor & Francis. ISSN: 0149-5933/93.

Indeed, the subject of cyberwar is a popular one. Many researchers are now involved in assessing the capability of U.S. government agencies to successfully repel or survive a comprehensive attack from foreign powers. John Deutch, head of the CIA, recently addressed the U.S. Senate regarding attacks against our national information infrastructure. In that address, the nation's chief spy told of a comprehensive assessment of the problem:

We have a major national intelligence estimate underway which will bring together all parts of the community, including the Department of Justice, the Defense Information Systems Agency, the military, the FBI, criminal units from the Department of Justice in providing a formal intelligence estimate of the character of the threats from foreign sources against the U.S. and foreign infrastructure. We plan to have this estimate complete by December 1 of this year.

How likely is it that foreign powers will infiltrate our national information infrastructure? That is difficult to say because the government now, more than ever, is getting quiet about its practices of security on the Net. However, I would keep a close eye in the near future. Recent events have placed the government on alert and it has intentions, at least, of securing that massive (and constantly changing) entity called the Internet. I do know this: There is a substantial movement within the government and within research communities to prepare for Internet warfare on an international scale.


Cross Reference: I want to point you to an excellent starting point for information about Internet warfare. It is a site that contains links to many other sites dealing with Internet and information warfare. These links provide a fascinating and often surprising view. The site can be found at http://www.fas.org/irp/wwwinfo.html.

Within the next five years, we will likely begin engaging in real Internet warfare with real enemies. And, for all we know, these real enemies may have already started warring with us.

Summary

As more and more users flock to the Internet, Internet warfare will increase in prevalence whether at the governmental, corporate, or personal level. For this reason, each user should have a minimum of knowledge about how to defend (if not attack) using standard Internet warfare techniques. This is especially so for those who have networks connected 24 hours a day. Sooner or later, whether you want to fight or not, someone will probably subject you to attack. The key is knowing how to recognize such an attack.

Various chapters throughout this book (most notably Chapter 9, "Scanners") discuss attacks from both viewpoints: aggressor and victim. In fact, Part III of this book is devoted specifically to tools (or munitions) used in Internet warfare. I will discuss some of these in the next chapter.