You can further enhance security on your intranet by encrypting Web transactions. When you use an encryption facility, information submitted by customers using Web fill-in forms-including usernames, passwords, and other confidential information-can be transmitted securely to and from the Web server.
There are a wide range of proposed or partially implemented encryption solutions for the Web, but most are not ready for prime time. Of the several proposed methods, only two have emerged in anything like full-blown form. Let's look at the Secure HTTP (S-HTTP) and Secure Socket Layer (SSL) protocols in this article. Unfortunately, the two protocols are not compatible with each other. Worse, Web browsers and servers that support one method don't support the other, so you can reliably use one or the other only if you carefully match your Web server and customers' browsers.
Secure HTTP (S-HTTP)
S-HTTP was developed by Enterprise Integration Technologies and RSA Data Security, and the public S-HTTP standards are now managed by CommerceNet, a nonprofit consortium conducting the first large-scale market trial of technologies and business processes to support electronic commerce over the Internet. (For general information on CommerceNet, see http://www.commerce.net/.) S-HTTP is a modified version of the current httpd protocol. It supports
- User and Web server authentication using Digital Signatures and Signature Keys using both the RSA and MD5 algorithms.
- Privacy of transactions, using several different key-based encryption methods.
- Generation of key certificates for server authentication.
EIT has developed modified versions of the ncSA httpd server and ncSA Mosaic (for UNIX and Microsoft Windows), which both support S-HTTP transactions. Although the licensing terms allow for ncSA to fold EIT's work into its free httpd server and Mosaic browsers, there's been no public indication of ncSA's plans to do so. Meanwhile, the CommerceNet secure ncSA httpd server and Mosaic browser are available only to members of CommerceNet. You'll find information about both packages, including full-text user manuals, at the CommerceNet home page http://www.commerce.net/.
Secure Sockets Layer (SSL)
S-HTTP seems to have been engulfed in the 1995 Netscape tidal wave. Unwilling to wait for widely accepted httpd security standards to evolve (as it was with HTML as well), Netscape Communications Corporation developed its own SSL encryption mechanism. SSL occupies a spot on the ISO seven-layer network reference below that of the httpd protocol, which operates at the application layer. Rather than developing a completely new protocol to replace httpd, SSL sits between httpd and the underlying TCP/IP network protocols and can intervene to create secure transactions. Netscape makes the technical details of SSL publicly available. In addition, C-language source code for a reference implementation of SSL is freely available for noncommercial use.
The Netscape Navigator Web browser has built-in SSL support, as does the Netscape Commerce Server; the Netscape Communications Server does not support SSL. Given Netscape's share of the Web browser market, it's hard to see how S-HTTP has much of a chance at becoming widely available. With the exception of ncSA Mosaic, most other Web browsers have-or have promised-SSL support. Some of them are Spry's newer product, Internet in a Box, Mosaic in a Box for Windows 95, and Release 2 of Microsoft's Internet Explorer for Windows 95 and the Macintosh.
Even though a browser might support secure transactions using SSL or S-HTTP, no transactions are actually secure except those between the browser and a compatible Web server. Thus, using Netscape, for example, won't provide any security unless you're also using the Netscape Commerce Server. It's also important to note that simply using a proxy service (that is, passing Web services through network firewalls) does not imply secure transactions unless both the proxy server and the destination server do.
As noted in the preceding section, the Netscape Commerce Server supports the company's SSL security mechanism. Other packages that support SSL include the Secure WebServer package from Open Market, Inc., (http://www.openmarket.com/), which also supports S-HTTP, and IBM's Internet Connection Secure Server, which runs under IBM's UNIX, AIX Version 4, and OS/2 Warp. (Evaluation copies of Secure WebServer for several UNIX systems are available at the Open Market Web site.)
Both Secure WebServer and Internet Connection Secure Server are based on Terisa Systems, Inc.'s SecureWeb Client and Server Toolkit. This package provides source code for developers building secure Web servers and browsers. The Terisa Toolkit supports both SSL and S-HTTP. For more information about the package, visit Terisa's Web site at http://www.terisa.com/. Open Market's promotional announcements about Secure WebServer state that the package supports secure transactions through Internet firewalls, but no details on just how this works are provided.
The Common Gateway Interface (CGI) and Intranet Security
CGI is the mechanism that stands behind all the wonderful, interactive fill-in forms you'll want to put on your intranet. Your customers might demand these kinds of intranet resources. CGI-BIN scripting is susceptible to security problems, so do your scripting carefully to avoid such problems.
You can minimize much of your risk of security breaches in CGI-BIN scripting by focusing on one particular area: Include in your scripts explicit code for dealing with unexpected user input. The reason for this is simple: You should never trust any information a user enters in a fill-in form. Just because, for instance, a fill-in form asks for a user's name or e-mail address, there is no guarantee that the user filling in the form won't put in incorrect information. Customers make typographical errors, but probing crackers, even those inside your organization, might intentionally enter unexpected data in an attempt to break the script. Such efforts can include UNIX shell meta-characters and other shell constructs (such as the asterisk, the pipe, the back tick, the dollar sign, and the semicolon) in an effort to get the script to somehow give the user shell access. Others intentionally try to overflow fixed program text buffers to see if the program can be coaxed into overwriting the program's stack. To be secure, your CGI-BIN scripts have to anticipate and deal safely with unexpected input.
Other problems inherent with CGI-BIN scripts include
- Calling outside programs, opening potential security holes in the external program. The UNIX sendmail program is a favorite cracker target.
- Using server-side includes in scripts, which dynamically generate HTML code. Make sure user input doesn't include literal HTML markup that could call a server-side include when your script runs.
- Using SUID scripts are almost always dangerous, whether or not in a CGI-BIN context.
Paul Phillips maintains a short but powerful list of CGI-BIN security resources on the Web. Check out http://www.cerf.net/~paulp/cgi-security, where you'll find a number of documents spelling out these and other risks of CGI-BIN scripting. For an extensive list of general CGI-related resources, go to Yahoo!'s CGI page, at http://www.yahoo.com/Computers_and_Internet/Internet/World_Wide_Web/CGI_Common_Gateway_Interface/index.html.
Your Intranet and the Internet
Is your intranet accessible from the Internet? If so, all of the security problems of the Internet are now your intranet's problems, too. You can, however, connect safely to the Internet and still protect your intranet. You can even use the Internet as a means of letting remote sites in your company access your intranet.
First, look at some Internet security basics.
It's a fact of Internet life that there are people out there who want to break into other people's networks via the Internet. Reasons vary from innocent curiosity to malicious cracking to business and international espionage. At the same time, the value of the Internet to organizations and businesses is so great that vendors are rushing to fill the need for Internet security with Internet firewalls. An Internet firewall is a device that sits between your internal network and the outside Internet. Its purpose is to limit access into and out of your network based on your organization's access policy.
A firewall can be anything from a set of filtering rules set up on the router between you and the Internet to an elaborate application gateway consisting of one or more specially configured computers that control access. Firewalls permit desired services coming from the outside, such as Internet e-mail, to pass. In addition, most firewalls now allow access to the World Wide Web from inside the protected networks. The idea is to allow some services to pass but to deny others. For example, you might be able to use the Telnet utility to log into systems on the Internet, but users on remote systems cannot use it to log into your local system because of the firewall.
Here are a couple of good general Web resources about Internet firewalls:
- Marcus Ranum's Internet Firewalls Frequently Asked Questions document at http://www.greatcircle.com/firewalls/info/FAQ.html
- Kathy Fulmer's annotated list of commercial and freeware firewall packages (with many hyperlinks to firewall vendor Web pages) at http://www.greatcircle.com/firewalls/vendors.html
If your company is also connected to the Internet, you'll want to know how to make sure your intranet isn't generally accessible to the outside world. You learned earlier in this article about denying access to your Web server using hostname and IP address authentication, but the fact that IP addresses can be easily spoofed makes it essential that you not rely on this mechanism as your only protection. You'll still want to rely on an Internet firewall to protect your intranet, as well as all your other network assets. Moreover, unless your corporate network is not connected to the outside world at all, you'll want to ensure the security of your other intranet services, including not only your Web servers, but also your FTP, Gopher, Usenet news, WAIS, and other TCP/IP network services.
More and more companies with widely distributed offices, manufacturing sites, and other facilities are turning to use the Internet to replace private corporate networks connecting the sites. Such a situation involves multiple connections to the Internet by the company, with the use of the Internet itself as the backbone network for the company. Although such an approach is fraught with security risks, many organizations are using it for non-sensitive information exchange within the company. Using a properly configured firewall, companies can provide access to services inside one site's network to users at another site. Still, however, the data that flows across the Internet backbones between the corporate sites is usually unencrypted, plain text data that Internet snoopers can easily read. Standard firewalls don't help with this situation.
A number of firewall companies have recently developed Virtual Private Network (VPN) capabilities. Essentially, VPN is an extension of standard firewall capabilities to permit authenticated, encrypted communications between sites over the Internet. That is, using a VPN, users at a remote site can access sensitive data at another site in a secure fashion over the Internet. All the data that flows on the public Internet backbones is encrypted before it leaves the local network and then decrypted when it arrives at the other end of the connection.
The VPN is similar to a wide area network, or WAN, in that you are connecting one or more smaller networks together. WANs, however, typically utilize dedicated phone lines to communicate with each other. Many T1 and T3 lines are used for this purpose daily all over the world. This WAN setup can be quite secure because the information flow is over private telephone networks, not a giant chaotic network like the Internet.
WANs are not as prone to outages as VPNs are. That is because the VPN is at the mercy of a) your Internet service provider, and possibly b) your Internet service provider's Internet service provider. If either of these two sites go down, you're in the dark. That's a bad thing when you need to get at your corporate database in Chicago for a meeting that started five minutes ago.
What VPNs do give you is secure communications over a relatively cheap medium. Instead of paying hundreds or possibly thousands of dollars per network drop site, plus the cost of WAN equipment (which can get expensive), you simply pay for an Internet connection. These can be had for as little as $125.00 per month. Granted you won't get much bandwidth for that price, but it's a start. If you are considering extending your corporate network, consider VPNs too.
The most mature VPN product comes from Raptor Systems (http://www.raptor.com/), part of the company's Eagle family of products, and others are available from Checkpoint (http://www.checkpoint.com/) and Telecommerce (http://www.telecommerce.com/).
Related Online Articles:
No comment yet. Be the first to post a comment.