[Copyright Information] [Table of Contents] [Que Home Page]
[Prev Chapter] [Next Chapter]

09 - Security Issues--Firewalls and Data Security

Introduction

Putting your server on the Internet exposes you to a number of threatening influences. The types of people on the Internet range from those interested in causing harm to your network and information contained on it to those who just want to look at your Web pages. The average users exist between these two extremes. These uses are intent on getting all the information they can from your site, short of trying to break into areas in which they're not welcome.

You need to make a fundamental decision before you move to the Internet. Regardless of your plans for IIS and the components of it, you need to decide how you'll protect your internal networks from those who have no business seeing them. To take no action at all is, quite simply, an act of ignorance. This would likely cause you problems immediately, if not sometime in the future. Getting into information that you have no business seeing is a process that works as does a magnet. Once users realize they can find some information, they'll look for more. This can be deadly to your corporate network, to its confidential and proprietary information, and to your clients. After all, their information is also likely to be stored on your network. Make no mistake, if you're going to connect a system to the Internet, you should take steps to protect it.

This is not to say that you need to spend thousands of dollars protecting your network. There are simple steps you can take to insulate your internal network from the Internet as well. In this chapter, you learn how you can implement these physical steps. You also learn how they differ from vendor-supplied solutions. There are pros and cons on both sides of the security dilemma.


As of this writing, Microsoft's Catapult server is not available for testing and review. When this book goes to press, this product will probably be in Beta and nearing release. Look for a rewrite of this chapter, including information about setting up the Microsoft firewall product, on the Que Web site at http://www.mcp.com/que and at the author's Web site, located at http://www.pobox.com/~swynk.

As the technologies change, you'll also find other updates here, along with notices of any upcoming revisions of this and other books.

True firewalls entail software or hardware solutions, or both, developed specifically for providing the firewall functionality. These packages range greatly in price, depending on the features you want to implement. This is one purchase you should fully understand. You need to shop extensively to make sure to get the right solution for you. This portion of this book provides information to help you understand the majority of the different options that are available from these packages. This section of the book also helps you understand how you can implement a physical solution to protect your network.

The Physical Wall-No Wire Access

At the most basic level, you can protect your internal network from Internet users by physically removing your network server from the internal network. Obviously, as a stand-alone server, it will be impossible for network users to access anything other than the IIS server. This is, in many cases, the safest and best place to start.

In practical implementation, you might not know what features you need until you have requests from users to provide Internet access. If you bring up the server in this manner, you can get your IIS server on-line, and provide content to the Internet community. You can then start working with users to determine to what information they need access.

Of course, this simply doesn't mesh with the Intranet concept. What good is an IIS server to your Intranet if it's not physically connected to the Intranet? This leads to two other alternatives. First, you can create a mirror type of server implementation. Using this concept, you create a dual server environment with one server on the Internet and one on your Intranet. This is a real chore to implement. It is even more of a chore to keep current between the two sites, even with replication.

The other approach you can take is to put your server on both networks. This is probably the best of the low-cost approaches. Consider the drawing in Figure 9.1 for, an example.

Figure 9.1 - Setting your server up on multiple networks can be the first step toward physically separating your internal network from the Internet.

You accomplish this by installing two network adapters in your system. For one adapter, you'll have an IP address that is known by the Internet by way of your DNS servers. This is the IP address over which you'll have Internet access. You also use this address to set up your public Web-page. The other adapter will have an internal network-assigned IP address, making it available on your internal network.

You should physically wire your network so that the Internet connection is not hooked up to your internal network hubs. Keep your Intranet server separated and on its own physical network. When you have users who need direct Internet access, you can provide this by placing an additional network card in their systems. Then, you need to set up that card to access the Internet.

When you set up your network this way, make absolutely certain that you deselect the Enable IP Forwarding option on the Microsoft TCP IP Properties sheets for the TCP/IP protocol. If you leave this item selected, the server will become a bridge between the two network adapters, completely defeating the entire purpose of this approach.

For an example of the TCP/IP properties dialog box, please see Figure 9.2.

Figure 9.2 - If you leave the Enable IP Forwarding option selected, packets can be routed from one network adapter to the other, opening your internal network to the Internet.


If you select this approach, you'll be able to create a public Web page site and a private Web site, if you're interested in doing so. The technique is identical to a multihome or Virtual Server installation. Chapter 8, "Allowing Dynamic User Access" covers this situation in more detail.

Once you've completed these steps, you have a server that is visible on the Internet. It is, at the same time, available on your Intranet, without having any type of bridge or gateway between the two. You're providing protection from the Internet. You're also, however, preventing access for your users in their need to get out onto the Internet. This is a situation in which a true firewall and gateway scenario come into play. You'll need to go a step further in your functionality when your user base begins demanding access to the Internet from desktop systems.

When this happens, it is no longer an Intranet versus Internet issue, nor is it an IIS issue. It quickly becomes an issue of providing the access needed, but also protecting the assets of your company's network. Firewalls are there for just this purpose. They provide both validincoming, and allowed outgoing access to and from the Internet.

Working with Firewalls

A number of different firewall approaches are employed to provide the access that suits your needs. Firewalls require an additional step on the way to and from the Internet: They require that you authenticate yourself along the way. This can range from a company-approved IP address list to user IDs and passwords to thumb prints and encrypted access code words that change on every access. The type of authentication that's employed by the systems vary, depending on the approach of the package and what the needs are.

A number of different approaches are offered by firewalls. A number of different focuses also dictate what the firewall is looking for, and protecting against. There are even some new terms to learn, such as spoofing.

Spoofing occurs when one user pretends to be another by changing the IP address and other low-level network access information. Most often this approach is employed to get around a firewall that uses packet filtering to control access. Packet filtering occurs when the firewall monitors the IP addresses as the gating mechanism for controlling access. You establish a range of IP addresses that are allowed in or out through the firewall. A person who spoofs the IP address will gain access to this relatively simple firewall approach by fooling the IP checking process.

There are other, more complex approaches. Other important features exist that you'll want to learn about, as well.

Application Level Filtering

This type of filtering takes place between two known quantities: One is the originating application, and the other an authorized destination. In other words, your application, known to the firewall, makes a request to access a location through the firewall. Once authenticated, the firewall acts as intermediary to transfer packets of information between the destination and the application.

By providing this bridge between the two locations, the firewall can maintain control over the destination for all incoming packets. If a packet comes in from the destination that is bound for an invalid internal address or application, it can be logged and ignored.

Application Level Security

With this type of control, the firewall establishes that you, the user, are allowed access to the resources you're requesting. Once you establish this, usually by providing a user ID and password, you have an open band of communication between your system and the remote one. This provides the same convenience of the packet filtering, but controls the access to authorized personnel. It also gives a more dynamic access approach as the user might be able to request access to a new resource. This can occur even if the firewall is not yet aware of the new resource, as long as the user is authorized to request the access.

Device limits for users and groups

Most firewall applications enable you to define devices that can be used by certain users. On an NT-based system, you can supplement or even replace this functionality using the NT-based security layers in which you can accomplish much of the same functionality.

Integration with the NT security model

Systems are now starting to appear on the market that integrate completely with the NT security model. One example is the Microsoft product, code-named Catapult, that uses user groups in NT to determine what types of access will be afforded different users on the system. You can assign read/write FTP, Web and Usenet News access to different users independently from one another.


See the beginning of this chapter for more information regarding the latest in the Microsoft gateway product.

Invisible Intranet

At no time should someone on the Internet be able to casually see your internal systems. This is the whole point of the firewall. Be sure that your internal systems are not accessible by simply indicating their IP addresses. An unauthorized user should not be able to browse the different computers on your internal network.

Logging capabilities

At the heart of the firewall is accountability. This doesn't only include the failed attempts in which the firewall stepped in and prevented access. In some cases, it can be good to know what sites people are requesting, and what types of data are used, as well as other information. This is useful because it can help determine your own internal content that you provide from your IIS server. It can also help optimize your users' time on the Internet, serving to curb the tendency to "surf the Web" all day long.

In a practical example of this, simply telling people that you have this capability can go a long way to controlling misuse of the Internet. In retail, many of the camera panels you see over cashier stations are simply mirrored panels. There are no cameras watching from behind the panels. However, there could be. In an experiment conducted at a retail location that was experiencing cashier pilfering, mirrored panels were installed. The cashiers were casually told that the "cameras" were installed to protect them. When the thought of being watched settled in, the pilfering stopped-all without the time and expense of really monitoring the cashiers to determine the problem areas. The same can be true of controlling misuse of the Internet. Yes, you'll still have those who abuse the privilege. However, you'll largely find that passive monitoring goes a long way toward controlling the problem.

Packet Filtering

As indicated at the beginning of this section, packet filtering is probably the most passive and vulnerable mechanism for controlling access to your network. With packet filtering, you indicate which IP addresses can get out of and in to your network, to and from the Internet, respectively. This is the place in which spoofing can come into play. In this way, someone can pretend to be another by simply modifying his IP address. Then, this person can gain access to your network.

Password management

Password management will likely be a mix at worst, or a fully integrated solution at best. When you have systems that are granted access to the Internet, you'll want to tighten password management a bit and begin paying attention to valid password durations and controlling the renewal of passwords. You might recall that you can tell NT to automatically expire passwords at set intervals. For more information, please see Figure 9.3.

Figure 9.3 - Consider expiring passwords every 30 days to help add a layer of protection to your network. You set the password expiration timeframes in the User Manager for Domains administrative application.

This example dialog box shows several key options within the User Manager that help in managing your user base. Consider establishing the password history monitoring system. This will prevent the user from bouncing between two different passwords, alternating from one month to another. Also, you might want to set the number of failed attempts before the account is temporarily disabled. This will prevent someone from continually attempting access with different passwords until finding the correct one.

Real-time monitoring and alerts

Of primary importance in the firewall implementation is your ability to react to problems. If you have after-the-fact analysis of the system, it won't do you much good if someone does manage to get in. The only thing you'll most likely be doing in this case is trying to figure out what happened. The key is to be able to react to and take back control over a problem situation. This means that the firewall should have mechanisms in place to notify you immediately of any suspected problems.

You might want to consider a solution that supports a pager. Alternatively, you can implement a system that e-mails you about a possible problem. This system can then forward the e-mail message to your pager using a wireless gateway product.

Firewalls should be hassle-free

Perhaps one of the biggest requirements for the firewall is that your users be aware of it as little of the time as possible. If users are constantly required to alter how they normally work to accommodate the firewall, they'll soon grow frustrated with it. This will pose a challenge to get them to keep using it.

System inactivity timeout

If a system is inactive for any period of time, the firewall should stop access to it. Of course, you should be able to control this timeframe. The reason is that you'll be one of the only people who can determine a valid timeframe. Once a system goes inactive for this time period, however, users should be required to authenticate themselves to the system once again.

This is very similar to the screen saver with password option. When you step away from your computer, you put this screen saver option on. Then, whoever sits down at your computer cannot casually use it without providing a password to clear the screen saver. The same is true of the Internet connection. If you've authenticated yourself to the system, it knows that the proper user is working on it. If you step away from your system and others use it, these people should be required to log on and authenticate themselves to the system.

Time limits for users and groups

As with the NT time limits, the firewall will probably be capable of limiting access times for users and groups of them. This comes in two forms, the first of which is actual time online. You might need to limit the overall amount of time a series of users is online. You can establish this time limit. Then, you can have the firewall implement it, preventing access beyond that time limit.

The second approach to this is actual logon time. You will be able to set up times during which a given user or group is allowed to log on. If users are outside this time limit, they will not be granted access to the Internet. This is to your benefit if you have variable shifts of people who might be signing on. You can limit log-on times to those times when these people are on-duty. This will keep them from unnecessarily using the system after hours.

Application-level considerations

In some cases, your application will need to be updated, configured, or modified to properly work with a firewall. This can mean indicating the computer name for the server that is acting as the firewall. Alternatively, it can mean providing password information that is used to access the firewall server. Figure 9.4 shows an example of specifying this information for WS_FTP, an FTP client application.

Figure 9.4 - If you don't set up a firewall-type connection, the application software will not be capable of accessing the external sites. The reason is that the firewall will not allow it through.

In Internet Explorer, the firewall server is referred to as a Proxy Server. As you can see in Figure 9.5, you need to provide the computer name for the server. You can also tell Internet Explorer about systems that should not be accessed through the Proxy. In this case, the internal servers have been provided, telling Internet Explorer to go directly to those servers to connect.

Figure 9.5 - In Internet Explorer, you can click the icon using the right mouse button. Then, you can select properties and set up the Proxy server information on the Connection tab.

The changes you must make to your application will depend completely on how that application implements proxy or firewall servers. Consult your application documentation for information about how these applications should be configured.

Firewall Alternatives

The following information, taken from the National Computer Security Association's (NCSA) web pages at http://www.ncsa.com, provides information on additional firewall products that have been tested and certified by the NCSA. Check their Web site frequently for helpful information about the emerging technologies, ongoing testing, and additional certifications that are currently underway.

For Information, please contact:

Kevin J. Stephenns
Marketing/Communications
(717) 258-1816 ext. 224
(717) 243-8642 Fax
e-mail: kStephenns@ncsa.com

June 3, 1996, Carlisle, PA.

The National Computer Security Association has announced the results of the initial round of Firewall Certification Testing (Version 1.0) at NCSA Labs. The firewall developers and their products which have successfully completed the certification process include the following:

  1. Atlantic Systems Group--TurnStyle(tm) Firewall System

  2. Border Network Technologies, Inc.--BORDERWare(tm)

  3. Milkyway Networks, Inc.--Black Hole(tm)

  4. CheckPoint Software Technologies, Inc.--CheckPoint Firewall-1

  5. Digital Equipment Corporation--AltaVista(tm) Firewall

  6. Global Technology Associates, Inc.--GFX Internet Firewall System

  7. Harris Computer Systems Corporation--CyberGuard(tm) Firewall

  8. IBM--Secured Network Gateway

  9. Livermore Software Labs, International--PORTUS(tm) Version 2

  10. ON Technology Corporation--ON Guard(tm)

  11. Raptor Systems, Inc.--Eagle(tm)

  12. Technologic, Inc.--Interceptor(tm) Firewall System

  13. Trusted Information Systems, Inc.--Gauntlet(tm) Internet Firewall Ver. 3.1

  14. Radguard, Ltd.--CryptoWall(tm)

  15. Sun Microsystems--SunScreen(tm) SPF-100

  16. NEC Technologies--PrivateNet(tm) 1.0.1A

Other firewall products will continue to be certified as they are submitted to NCSA Labs. The criteria of Version 2.0 for NCSA Firewall Certification will be announced at NCSA's Firewalls and Web Security Conference, Sept. 30, 1996 in San Jose, CA.

NCSA Certified Internet Firewall products are tested against a standardized and evolving suite of attacks while enabling desired business functions to be accomplished. Manufacturers with Internet firewall products meeting these standards are authorized to use the NCSA Certified logo for marketing and other promotional purposes.

NCSA Firewall Product Certification provides assurance to end users that a certified Firewall product can be configured to protect an internal network against a suite of current threats tested by NCSA while enabling important business functions to operate effectively in an Intranet/Internet environment.

Certification means that NCSA, acting as an independent laboratory, has verified that a firewall product meets the current published certification criteria. Information on firewall certification testing procedures, as well as products that are currently certified, is posted on the NCSA Web pages (http://www.ncsa.com).

"The NCSA Firewall Certification process will eliminate some confusion in the marketplace," according to Sam Glesner, the NCSA Firewall Consortium Manager. "With NCSA certification as a meaningful starting point, firewall users and potential buyers can better evaluate the right products for their specific networks".

"Certification will simplify the evaluation, purchase and installation of firewalls," said Dr. Peter Tippett, President of NCSA. "Certification is not meant to imply perfect security, but rather that significant risk reduction will be achieved using an NCSA-Certified Firewall."

From Here...

Firewalls are a major consideration in your network when you begin allowing access to the Internet. Saying that firewalls are a good idea is a vast understatement. Related materials are found in the following areas:


Copyright © 1996, Que Corporation
Technical support for our books and software is available by email from
support@mcp.com

Copyright ©1996, Que Corporation. All rights reserved. No part of this book may be used or reproduced in any form or by any means, or stored in a database or retrieval system without prior written permission of the publisher except in the case of brief quotations embodied in critical articles and reviews. Making copies of any part of this book for any purpose other than your own personal use is a violation of United States copyright laws. For information, address Que Corporation, 201 West 103rd Street, Indianapolis, IN 46290.

Notice: This material is from BackOffice Intranet Kit, ISBN: 0-7897-0848-5. The electronic version of this material has not been through the final proof reading stage that the book goes through before being published in printed form. Some errors may exist here that are corrected before the book is published. This material is provided "as is" without any warranty of any kind.

[Copyright Information] [Table of Contents] [Que Home Page]
[Prev Chapter] [Next Chapter]