security \si-'kyur- t-e-\ n: the quality or state of being secure
You might think that there is little reason to be concerned about security in an intranet. After all, by definition an intranet is internal to your organization; outsiders can't access it. There are strong arguments for the position that an intranet should be completely open to its users, with little or no security. You might not have considered your intranet in any other light.
On the other hand, implementing some simple, built-in security measures in your intranet can allow you to provide resources you might not have considered possible in such a context. For example, you can give access to some Web pages to some people without making them available to your entire customer base, with several kinds of authentication. In this article, you'll learn how simple security measures can be used to widen the scope of your intranet.
To help you get oriented to the material to be presented, the following is a list of article objectives. You might want to refer to this list as you work your way through the article. In this article, you'll
- Consider the overall security aspects of your intranet.
- Learn how implementing security on your intranet can actually broaden the ways in which it can be useful in your organization.
- Learn how to set up username/password authentication to limit access to resources on your intranet.
- Learn how to provide secure access to intranet resources to groups of customers.
- Learn how to restrict access to sensitive resources based on customers' computer hostnames or network addresses.
- Learn about the security aspects of CGI-BIN scripting.
- Learn about using encrypted data transmission on your intranet to protect critical information.
- Learn important information about securing access to your intranet when your corporate network is attached to the Internet.
- Learn how to provide-and limit-secure access to your intranet from outside your immediate local network.
Intranet security is, then, a multifaceted issue, with both opportunities and dangers, especially if your network is part of the Internet. I'll walk through the major ones, with detailed information on using built-in intranet security features, in this article.
Except in the sections of this article that are specifically devoted to Internet security issues, it's assumed that your intranet is not accessible from outside your organization. If you are on the Internet, the intranet security measures discussed in this article may not be sufficient to secure your system. If you want to make the services and resources of your intranet accessible from the outside, you'll need to take significant additional steps to prevent abuse and unauthorized access. Some of these steps are described at the end of this article in the section titled "Your Intranet and the Internet."
Many people view computer and network security in a negative light, thinking of it only in terms of restricting access to services. One major view of network security is "that which is not expressly permitted is denied." Although this view is a good way of thinking about how to connect your organization to the Internet, you can, and possibly should, view intranet security from a more positive angle. Properly set up, intranet security can be an enabler, enriching your intranet with services and resources you would not otherwise be able to provide. Such an overall security policy might be described as "that which is not expressly denied is permitted."
This does not mean that you should throw caution to the wind and make everything available to your users on your intranet. There are many things to consider when placing sensitive business data out on your intranet. It may fall into the wrong hands, or worse, be used against your business.
This article takes the latter approach, presenting intranet security in terms of its opportunities for adding value to your intranet. For example, some of your users might have information they would like to make available, provided access to it can be limited to a specified group-for example, confidential management or financial information. Without the ability to ensure that only those who have the right to see such information will have access, the custodians of such data will not be willing to put it on your intranet. Providing security increases your organization's ability to use the important collaborative aspects of an intranet.
For example, your company's accounting department wants to publish a weekly list of the top ten delinquent clients and the amounts they owe. They've hired a young stud programmer who has created a link to the company database that updates this information automatically. While this information is useful to upper management, and perhaps the sales staff, it shouldn't be viewed by other departments. The fact that a client is delinquent in payment can cause your employees to think less of those clients and perhaps cop a bad attitude toward them.
The more defensive approach, preventing abuse of your intranet, is also given play, however. Organizations' needs for security in an intranet can vary widely. Businesses in which con-fidentiality and discretion are the norm in handling proprietary information and corporate intellectual property have different needs than a college or university, for example. Academic institutions generally tilt toward making the free exchange of ideas a primary interest. At the same time, though, the curiosity (to use a polite word) of undergraduates requires strong needs for security. Keeping prying sophomores out of university administration computing resourcesis a high priority; for example, students have been known to try to access grade records (their own or those of others) for various reasons. Even simple adolescent high jinks take on new dimensions on a computer network.
What Are the Security Features of an Intranet?
Before going into a great deal of detail about how you can use security to enhance your intranet, take a high-level look at what security features are available to you. These break down into three main categories. First, you can take steps on your Web server to set up security. Second, you can take steps with the other TCP/IP network services you've set up on your intranet to enhance their security. Third, you can secure customers' Web browsers themselves to limit what they can do with them.
Web Server Security
There is a wide range of very flexible security features you can implement on your Web server. Here's a summary:
- Access to Web servers, individual Web pages, and entire directories containing Web pages can be set to require a username and password.
- Access to Web servers, individual Web pages, and entire directories containing Web pages can be limited to customers on specific computer systems. (In other words, access will be denied unless the user is at his or her usual computer or workstation.)
- You can organize individuals into groups and grant access to individual Web servers, Web pages, and entire directories containing Web pages based on group membership.
- You can organize computers into groups, and grant access to individual Web servers, Web pages, and entire directories containing Web pages based on group membership.
- CGI-BIN scripts on your Web server can use any of the above access restrictions, though you must take care in writing them to ensure you don't make security-related mistakes.
- Some httpd server software is capable of communicating with compatible Web browsers in a secure, encrypted fashion, defeating even network-level sniffers and ensuring confidentialdata transmission across your intranet.
You can combine these features in a number of ways, such as requiring a password and limiting access to a group of users who must access your Web server from a specific group of computer systems. You'll see a good deal of detail about Web server security setup in thisarticle.
Security in Other Intranet Applications
In addition to the access controls you can set up on your Web servers, you can implement security in some of the other network services that may be offered on your intranet. Here are some of the steps you can take:
- Access to your anonymous FTP server can be limited in several important ways, much like with your HTTP server, while still enabling authorized customers to upload files to it.
- Access to your Usenet news server can be limited in much the same way.
- Access to searchable intranet indices and databases can be controlled through password-protected Web interfaces.
- Access to Gopher services can be controlled based on TCP/IP network address, and separate browse, read, and search permissions can be set on a per-directory basis.
This article, doesn't provide any additional information about these services. You'll want to refer to the documentation for these network packages to learn about how to handle access controland other security features in them.
Securing Users' Web Browsers
Some Web browsers can be set up in kiosk mode, which limits the features of the package that users can access. Available primarily in ncSA Windows Mosaic and Mosaic-based browsers, kiosk mode runs the browser with a limited set of features. Users cannot save, print, or view the HTML source of Web pages, and hotlist/bookmark editing is not allowed. The user cannot even exit from the browser and restart it in normal mode without exiting from Windows altogether. Even the overall Mosaic window cannot be minimized or maximized, and the normal pull-down control menu for Windows is missing. This can be quite effective in a controlled environment. However, end users tend to find their way out of paper bags quite often. Don't count on kiosk mode being your super security implementation.
Resourceful users will quickly figure out they can manually edit their pc's autoexec.bat file or Web browser's .ini file to override kiosk mode, undoing the limitations you've placed on them. If you're concerned about such things, you'll need to place user startup and Windows and browser setup files on a file server to which users have read permission only. You'll also need to limit access to the Mosaic startup command itself, or else users would simply use the Windows Program Manager's Run command to start another Mosaic session. As a result, kiosk mode might not be worth your trouble except in limited situations, such as at a trade show.
It's Your Call
It's your responsibility to determine the level of security youneed on your intranet, and, of course, to implement it. Puttingmost of the security measures mentioned into place, as you'lllearn in the following sections, is not difficult. Your primaryconcern will be explaining to customers how intranet securityworks, not so much as a limiting factor but as an opportunityfor increased use and collaboration using your intranet. Assuringdecision-makers that they can make information available on yourintranet in a secure fashion can go a long way toward making yourintranet a success. At the same time, it's important to make sureboth information providers and their customers understand a numberof critical aspects of intranet security, so they don't inadvertentlydefeat the purpose of it.
There are network security commonplaces, unrelated to intranetsecurity specifically, that need your attention. All the securityprecautions in the world can't protect your intranet from overallpoor security practices. Users making poor choices on passwordsalways leads the list of computer and network security risks.You can limit access to a sensitive Web resource based on theTCP/IP network address of the boss's pc, but if the boss walksaway and leaves his pc unattended without an active screenlock,anyone who walks into the empty office can access the protectedresources.
Password security is only as good as the passwords that are chosen. Be sure to impose some sort of password setting and changing policy. This will save you time in the end. Unique passwords that are a garble of letters and numbers are the best, but the hardest to remember. Encourage your users to be creative in their password selection.
Sometimes a user uses his own name as his password, or his significant other's or pet's name; password-guessing is simple for anyone who knows him. Some people write their passwords down and tape them to their keyboards or monitors. These bad habits need to be avoided to completely secure your intranet.
In other words, the same good security practices that should befollowed in any networked computing environment should also bemade to apply in your intranet. Not doing so negates all the possiblesecurity steps you can take and reduces the value of your intranet.Even in the absence of malice, the failure to maintain any securityon your intranet will inevitably result in an intranet with littlereal utility and value to its customers.
Securityon Your Web Server
It's useful to break the overall subject of World Wide Web serversecurity down into three pieces and discuss them separately. I'lldo so in this section, covering user/password authentication,network address access limitations, and transaction encryption.Bear in mind throughout the discussion of these separate piecesthat you can combine them in various ways to create flexible andfine-grained access control. In fact, combining two, or even allthree, of these methods provides the best overall security.
ControllingAccess Globally and Locally
Before I turn to the individual methods, I'll cover some high-levelinformation about Web server security setup.
Whichever individual security mechanisms you implement on yourWeb server, the first thing you need to know is that you can implementthem at either or both of two levels. First, you can specify high-levelaccess control in a Global Access Configuration File (GACF), specifyingoverall access rules for your server. In the ncSA httpd serverand those which are derived from it, such as the Windows httpdand Apache servers, the GACF is called access.conf.The CERN/W3 server doesn't have a separate GACF; rather, all accesscontrol information is in the main server configuration file,httpd.conf. The Netscapeservers have a graphical interface (actually, Netscape Navigatoritself) for overall server administration, including setting upaccess control. If you feel more comfortable editing configurationfiles, the Netscape server does allow them, calling them DynamicConfiguration Files. Although you can do both global and localconfiguration using the graphical tool, you can also manuallycreate a top-level Netscape Dynamic Configuration File, whichcan then be hand-edited to function as a GACF.
Second, you can set up per-directory access control using localACFs (LACFs) for each directory or subdirectory tree. Usuallynamed .htaccess or .www_acl(note the leading periods in the filenames), LACFs lay out accesscontrol for an individual directory and its subdirectories, althoughsubdirectories can also have their own LACFs. The CERN/W3 servercan even extend protection to the individual file level usingLACFs. In the Netscape server, lower-level Dynamic ConfigurationFiles serve as LACFs. You can change the names of LACFs in boththe ncSA and Netscape servers, but you're stuck with .www_aclin CERN/W3.
With a few important exceptions, you can do everything with anLACF you can do with a GACF. Although you can control access toevery directory in your Web server document tree from the GACF,you'll probably not want to do so, especially if your needs foraccess control are complex. It's easy to make mistakes in a lengthyconfiguration file like the GACF, and you'll get unexpected, unintendedresults when you do. These might be hard to track down and mightnot even show up without extensive testing. Overall, it's betterto use your GACF to establish a high-level security policy andthen set up lower-level, simpler controls using LACFs.
The CERN/W3 server's LACF files have a completely different format than its GACF. Most of the examples in this article apply only to the format of the GACF.
What's the GACF for, then? Most Webmasters use the GACF to establisha general access policy for their Web server. For example, ifyour Web server is accessible to the Internet at large and you'renot using a firewall system (see the "Firewalls" sectionlater in this article) to limit access to your network from theoutside, you may want to establish a policy in your GACF thatonly computers with TCP/IP network addresses that are inside yournetwork can access your Web server's document tree. Similarly,you can use the GACF to segregate public and private areas onyour Web server according to some criteria, and require usernamesand passwords for access to the private areas.
After you've established your overall policies, you can implementLACFs to fine-tune your setup. In doing so, you can selectivelyapply different access controls to the directory or directoriescontrolled by the LACF.
Earlier, exceptions to the statement that you can do everythingwith an LACF you can do with a GACF were mentioned. Here is aquick, incomplete list; you'll want to consult detailed serverdocumentation for comprehensive explanations of these and others.The first one applies to all httpd servers, and the last threerefer only to UNIX servers.
- If you want to control all access on yourWeb server with your GACF, you can use it to prohibit the useof LACFs altogether.
- You can deny use of a potentially dangerousand CPU-hogging feature called server-side includes, which actuallycause the server to execute outside commands each time a pagecontaining them is accessed, in user Web pages.
- You can limit access to CGI-BIN scriptsin the server's main CGI-BIN directory, preventing users fromcreating potentially dangerous ones in their own Web direc-tories.
- You can prevent potential security problemsthat can come from following UNIX symbolic links.
With respect to symbolic links, confidential files on the systemthat are completely outside of your Web server tree could be compromisedby a naive or malicious user. For example, if a user created asymbolic link in her home directory pointing to the UNIX /etc/passwdfile, which contains usernames and encrypted passwords, outsideusers could obtain a copy of that file using their Web browserand then run a password-cracker on it offline. Of course, a malicioususer can grab /etc/passwdhimself and run the cracker directly, or e-mail the file to someoneelse for the same reason, but that's no reason to make it easyto do so via your intranet. (The UNIX System V /etc/shadowfile is not readable by non-root users, nor is the IBM AIX /etc/security/passwdfile.) See the section titled "The Common Gateway Interface(CGI) and Intranet Security" later in this article for discussionof CGI-BIN and server-side include security issues.
These generalities out of the way, let's turn our attention tothe three major elements of Web server security.
This article has dealt with implementing security on your intranet.Although an intranet is, by definition, internal to an organization,security is important not so much because it prevents things,but because it enables them. Judicious use of built-in securityfeatures of Web servers and other intranet resources can add valueto your intranet by making new things possible. In this article,you have
- Considered the overall security aspectsof your intranet.
- Learned how implementing security canactually broaden the ways in which your intranet can be usefulin your organization.
- Learned how to use username/password authenticationto limit access to resources on your intranet.
- Learned how to provide secure access tointranet resources to groups of customers.
- Learned how to restrict access to sensitiveresources based on customers' computer hostnames or network addresses.
- Learned about the security aspects ofCGI-BIN scripting.
- Learned about encrypted data transmissionon your intranet to protect critical information.
- Learned important information about securingaccess to your intranet in the case where your corporate networkis attached to the Internet.
- Learned how to provide-and limit-secureaccess to your intranet from outside your immediate local network.
Related Online Articles:
No comment yet. Be the first to post a comment.