Security concepts I

On a quiet fall evening not so long ago, the Internet was forever changed. That change took only minutes. If you have been reading this book from cover to cover, you will remember the date in question. However, for readers absorbing this book selectively, I will reiterate. That date was November 2, 1988. Shortly before dusk, a worm was unleashed on the network. Within hours, this worm incapacitated many machines (reportedly over 1,000 of them) and interrupted or otherwise degraded the performance of thousands more. (Many of these machines or networks were key research centers engaged in defense-related study.) At the exact moment that the worm was released, the history and future of the Internet changed forever. No one knew it at the time, because it would take a full year in the aftermath to assess what an enormous impact the incident had. But be assured of this: The change occurred in the same instant that Morris released his code to the Network.

Since that time, security has gained almost a cult status. Individuals I know who have never had a clue about the subject are suddenly diving for security information. You hear it in restaurants all the time. As you are eating your lunch, the buzz floats overhead: firewall, router, packet filtering, e-mail bombing, hackers, crackers...the list is long indeed. (This book would never have been written if the climate weren't just so.) By now, most people know that the Internet is insecure, but few know exactly why. Not surprisingly, those very same people are concerned, because most of them intend to implement some form of commerce on the Internet. It is within this climate that Internet Voodoo has arisen, conjured by marketeers from the dark chaos that looms over the Net and its commercial future.

Marketing folks capitalize on ignorance--that's a fact. I know resellers today who sell 8MB SIMMs for $180 and get away with it. However, while technical consultants do often overcharge their customers, there is probably no area where this activity is more prominent than in the security field. This should be no surprise; security is an obscure subject. Customers are not in a position to argue about prices, techniques, and so forth because they know nothing about the subject. This is the current climate, which offers unscrupulous individuals a chance to rake in the dough. (And they are, at an alarming rate.)

The purpose of this chapter, then, is to offer advice for individuals and small businesses. I cannot guarantee that this is the best advice, but I can guarantee that it is from experience. Naturally, everyone's experience is different, but I believe that I am reasonably qualified to offer some insight into the subject. That said, let's begin.

How Security Concepts Can Influence Your Choices
First, I want to quickly examine security concepts and how they will influence your choices of a security consultant. To begin with, know this: "There is nothing new under the sun." This quote is a brilliant statement made by William Shakespeare. It is brilliant because, in literature that preceded his own, for thousands of years, the statement had already been made. Therefore, he used a redundancy to articulate redundancy. How does this relate to Internet security? Read on.

The truth is, TCP/IP has been around for a long, long time. For example, as I reported in Chapter 18, "Novell," NetWare had fully functional TCP/IP built into its operating system back in 1991. UNIX has had it for far longer. So there is no real problem here. The knowledge is available out there in the void.

The greater majority of security breaches stem from human error. (That is because crackers with limited knowledge can easily cut deep into systems that are erroneously configured. On more carefully configured networks, 90 percent of these self-proclaimed "super crackers" couldn't get the time of day from their target.)

These human errors generally occur from lack of experience. The techniques to protect an Internet server have not significantly changed over the past few years. If a system administrator or security administrator fails to catch this or that hole, he needs to bone up on his advisories.



--------------------------------------------------------------------------------
NOTE: I will readily admit that some techniques have been improved, largely by the academic community and not so much by commercial vendors. Commercial vendors are usually slightly behind the academic communities, perhaps by a few months or so. Examples of this might include the development of automated tools to screen your system for known security holes. Many of these are written by students or by freelance software developers. These tools certainly streamline the process of checking for holes, but the holes are commonly known to any security administrator worth his salt.
--------------------------------------------------------------------------------

So, before you haul off and spend thousands (or even tens of thousands) of dollars on a security consult, there are some things that you should consider. Here are a couple test questions:

Suppose you establish a sacrificial machine, a Macintosh running WebStar and no other TCP/IP servers. The machine is isolated from your network, it has no valuable data on it, and basically, it has no inroad to your internal network. Your network does not run TCP/IP, and none of the publicly accessible nodes perform IP forwarding in any case. Would you pay a security consultant to scan that Web server box? (Instead of either having your system administrator scan it or not scan it at all.) If so, why?


You want to co-locate a box at an ISP. You normally work with Microsoft Windows NT (and so does your internal system administrator). Nevertheless, the ISP is trying to convince you to use a SPARC 20 and is willing to sell you one (or lease you one) for fair market value. Do you do it? If so, why?
The correct answer to both of these questions is "probably not." Here are the reasons why:

Scenario 1: What would the consultant be scanning for? Because the machine is running no other services but HTTP over WebStar, most modern scanners would render a laundry list of "connection refused" and "server not reachable" messages. In other words, the scan would be a complete waste of time and money because no services exist on the machine. Scanners like those discussed in Chapter 9, "Scanners," are used only to attack full-fledged TCP/IP implementations, where services (including NFS and other protocols) are either available and misconfigured or available and not configured at all. The question is, would you or your internal system administrator know this? If not, you might get taken.


Scenario 2: Why would you agree to place your Web server in the hands of a company on which you will remain totally dependent? If neither you nor your staff knows UNIX, insist on an NT box. If the provider balks, find another. Commonly, the ISP staff might forward the explanation that they feel UNIX is more secure and they therefore cannot tolerate an NT box on their Ethernet. If you agree to their terms, you will either be dependent upon them for all maintenance and programming or you will have to pay good money to train your system administrator in UNIX.
There are literally hundreds of such scenarios. In each, there is an opportunity for you to get hustled. A security consult is not to be taken lightly. Neither is the management of your co-located box. Remember that your Web server (wherever it might be located) is something that can be viewed (and attacked) by the entire world.

Before you can make an educated choice of a security consultant, you need to be familiar with basic security principles. That's what this chapter is really all about.

About Remote Security Consults
There is a new phenomenon emerging on the Internet. Security consults are now being done (although perhaps not in great number) from remote locations. This is where someone in the same city (or another city) tests, defines, and ultimately implements your security from the outside. In other words, it is done from a location other than your offices or home. I have a couple points to make regarding this type of procedure:

Scan or penetration testing is commonly done from a remote location. The purpose of penetration testing (at the end of the day) is to simulate a real-time attack from the void. There is no replacement for doing this from a remote location. In this limited area of concern, at least, analysis from a remote location is warranted and reasonable.


All other forms of security testing and implementation should be done onsite. Implementing security from a remote location is not a secure method and may result in security breaches. As much as the idea may seem attractive to you, I would strongly advise against having any firm or individual handle your security from a remote location. If your network is large and is meant to be as secure as possible, even the existence of a privileged user who can gain remote access to do maintenance work is a security risk. (For example, why would one cut a hole through a firewall just for the convenience of off-site work?)


--------------------------------------------------------------------------------
NOTE: As an example, an individual on the East Coast recently posted an article in Usenet requesting bids on a security consult. I contacted that party to discuss the matter, mainly out of curiosity. Within three hours, the party forwarded to me his topology, identifying which machines had firewalls running, what machines were running IP forwarding, and so forth.

Granted, this individual was simply looking for bids, but he forwarded this type of sensitive information to me, an individual he had neither seen nor heard of before. Moreover, if he had done more research, he would have determined that my real name was unobtainable from either my e-mail address, my Web page, or even my provider. Were it not for the fact that I was on great terms with my then-current provider, he [the provider] would not even know my name. So, the person on the East Coast forwarded extremely sensitive information to an unknown source--information that could have resulted in the compromise of his network.


--------------------------------------------------------------------------------

So, point one is this: Other than penetration testing, all active, hands-on security procedures should be undertaken at your place of business or wherever the network is located. Do not forward information to a potential consultant over the Internet, do not hire someone sight unseen, and finally, do not contract a consultant whose expertise cannot be in some way verified.