|
|
The easiest way to keep your data and information secure from the outside world is to avoid connecting to the Internet. If everything done inside your intranet is local, the outside world can't see what's going on and can't get to it. In other words, if you aren't connected to the Internet, there is very little chance that anyone can hack into your system. But that means that your intranet is slightly less functional and slightly less valuable. If you can't communicate with the outside world as well as you can with the people inside your network, and if you can't take advantage of the bevy of resources on the Internet, you're not fully taking advantage of technology. However, it's possible to keep your information relatively secure even if you're connected to the Internet. To maintain a secure network, you must take a number of precautions and consider a number of options.
When developing a secure intranet, your first concern should be physical security. How do you make sure that no one tampers with the actual machines? Make sure your server is located in a locked, climate-controlled room where no unauthorized person can get to it. Your server is your most valuable piece of hardware and usually contains all your data and therefore should be as secure as possible. Limit access to the room in which it's kept to your system administrator and maybe one other technical person. Give access to as few people as possible.
Many companies sell carts or cabinets in which you can store your server. Storing the server in a locked cabinet in a locked room makes it difficult for someone to physically touch it. And that's not just for cases of industrial espionage or someone trying to steal information; this also prevents accidents. Sometimes, when people see a sophisticated computer or an intriguing piece of equipment, they want to play around with it. It's extremely easy to lose information and vital data if these people don't know what they're doing.
Besides maintaining security for your server, it is also important that user workstations be kept physically secure. If any of your users have access to highly sensitive information, such as financial data or proprietary pricing information, or if your intranet contains any sensitive information, make sure that the computers of the individuals who can access this information also are in locked rooms or offices. In a similar manner, you can make groups of computers secure by limiting access to certain parts of the server to just those machines. That way, if you have a group of unsecure or relatively unsecure machines-in a cubicle environment or a large, open work area, for example-your data can remain secure.
The computers of your CEO or CFO (and of people who have access to private information) should be locked in offices so that someone wandering through the building can't log on to them. Also, I can't tell you how many people write passwords on sticky notes and stick them to their monitors. This practice defeats the general purpose of passwords. If you store passwords in a ledger, make sure it is kept in a safe.
Safes also are good for storing backup tapes. Any intranet should be backed up regularly onto some sort of magnetic tape. Make sure that the tapes are stored in a safe or a locked area. Someone who can't log on the server may access vital or private information through backup tapes.
Typically, if you are running an intranet, each of its users will have passwords that allow them to log into the system. Passwords are not only for security reasons (because you want to make sure you authenticate your users so you know that the people who log on are who they say they are). Passwords can also supply the server with a host of other information about the user. A userid and password can identify a user to the server. For much of the software run on an intranet, you'll need to identify incoming users for many different reasons, including environment variables-such as preferences-and communication purposes, such as identifying the user on message boards. When the server knows who the user is, many tedious aspects of communications functions can be automated. For example, when users participate on a message board, it might be useful for them to not have to type in their e-mail address every time they submit or reply to a message. Userids also allow for tracking users around the site.
Again, if your network is on a LAN or WAN that is not connected to the Internet, you don't need to be quite as paranoid as you do if you are connected to the Internet. If you are running a system where some users can access sensitive information and other users can't (such as financial data), ensure that user passwords are at least difficult to guess, if not impossible. Regardless of the system, however, I recommend that a password have at least eight characters, including a mixture of upper- and lowercase letters, at least one number, and one special character. Your password shouldn't be or contain any word that can be found in the dictionary, because these passwords are the easiest to crack. The idea is to have a password that is random enough so that guessing it would be impossible. This is especially true for remote-access users. If you are dialing into the system, you want to have a password that is even harder to crack. If a stranger is wandering around your office, he probably will be seen before he does much damage. However, this is not true with hackers. They have all the time in the world to try to crack your password. So make it tough.
For an internal network, you might change your passwords only every once in a while. Base your changes on need, or develop a regular schedule. Perhaps you'll change passwords every time you upgrade your hardware or software, or whenever it's convenient. Again, if some users are privy to particularly sensitive information, you might want to change their passwords more often, but on an internal network, you don't need to change your passwords too often. Passwords are more of a first means of defense. In a local network, users are in the same physical location as the machines, and it would probably be easier to break into the room that has the password file in it than to guess the passwords. This is not true if you are connected to the Internet or if your LAN has remote-access capability.
If your network is connected to the Internet, you want to change the passwords at least once a quarter. And certainly you'll want to change all your passwords immediately if you find any evidence that someone has been trying to break into your network or has broken into your network. Various commercially available software packages offer you a password-changing system. Depending on the software, hardware, or platform you're using on your server, you'll find software packages that require users to change their passwords on a regular basis. When you update information on your server, pay close attention to your procedures. It doesn't matter if you're using scripts or how you choose to update, but make sure to carefully examine your methods and watch out for any potential security holes, such as programs that blank out a user's password instead of prompting for a change when it expires. Some older password-changing programs just delete the old password, whether or not a new one has been specified. Unfor-tunately, this nullifies the password, and anyone can get onto the system. Make sure your password-changing script is up-to-date and secure.
Various password programs that require users to enter passwords in an acceptable form are also available. You can insert whatever parameters you choose. For instance, if you want to require a capital letter, a lowercase letter, a number, and a special character, the password program will check the password to make sure it has all those parameters. If it doesn't, the program kicks it back and makes the user type in a new one.
Another way to improve security is to make sure each branch of
the network is accessed by a different password. For instance,
the mail password (often determined by the user) should be different
than the one for the network database. Although you shouldn't
create too many passwords (and thus create a temptation for users
to write them down), you also should not risk an insecure intranet.
Develop the passwords in a systematic way. Keep your list of users
in alphabetical or some other order. Allow for plenty of room
for updates and additions.
| Tip |
When you're issuing new passwords to users, it's best not to send them via e-mail, one of the least secure methods of communication on the Internet. It's quite easy for someone to pick out a password from an e-mail message. One of the very best times to use the phone instead of your intranet is when you're issuing new passwords to your users. |
| Maintaining security for McKeon & Jeffries' intranet was a relatively simple undertaking at first, but it grew more complex as more interesting applications were added. In the beginning, there were just two user names and
passwords-one for the executive committee, and one for the rest of the users. These passwords were kept in a safe place and changed every few weeks. The information kept on the site wasn't terribly valuable to anyone.
As the site grew more functional, and especially when M&J started giving passwords to clients so that they could take advantage of the site's communications and file-sharing aspects, the security safeguards grew more complex. Instead of having one password for all the users, M&J issued separate passwords for each user. Although the site still wasn't accessible from the Internet, with nonemployees dialing up and exchanging information with the server, McKeon & Jeffries also spent plenty of time tracking users and potential security holes. |
| The SGAA knew from the start that security was going to be a big issue, and they hit it hard from the beginning. Users are required to change their passwords every month. Each password must contain a capital letter, a
lowercase letter, a number, and a special character-combinations that are not in the dictionary. The systems administrator runs SATAN (discussed later) and Cracker (a password-cracking program) every month to check security.
Physical security wasn't too much of a problem for the SGAA. Its only server was in a locked room, and the SGAA paid careful attention to the log files. Local users connected through the same password door as Internet users. If it looked as though a user were connecting consistently from more than one IP address, that user was contacted to make sure that he or she did indeed have two different accounts. |
It is as important to have a secure Web server as it is to maintain a secure mail and database system. As discussed in Chapter 14, "Security: Keeping Hackers Out," one method of Web server security is .htaccess, which causes the server to recognize that a directory tree is or should be authenticated. One problem with .htaccess is that it's often easy to accidentally place the password file in an inappropriate directory. (There are two files: One is .htaccess, which tells the Web server that the files in that directory tree should be authenticated, and the other file, .htpasswd, actually stores the user ID and password.)
It often happens that whoever creates the authentication puts the .htpasswd file in the same directory as the .htaccess file. For example, suppose the document root for your Web server is /home/dave/www, and you put the file .htaccess in /home/dave/www, and you put the password file in /home/dave/www. Then you want to look at a Web page within that directory tree, so you go to http://dave.intraactive.com. You'll get an authentication page that asks for your username and password. When your username and password are authenticated, you'll get the index.html page-/home/dave/www/index.html. However, once you're beyond the password protection, you could type http://dave.intraactive.com/.htpasswd to bring up the file containing the user IDs and the passwords.
Therefore, any user who could get onto your system could immediately get all the usernames and passwords he wanted. It's very important to keep your .htpasswd file outside the document root of your Web server. There are various other ways to keep your Web server secure. Read the security section of your Web server documentation and be sure to follow those instructions.
Even though on a typical Web server you can give access to certain pages to certain users, the information that gets sent from the server to the users' browsers is sent through the Internet unencrypted, or as plain text. I recommend that you avoid sending information unencrypted, especially if it is confidential.
Again, remember that millions of terabytes of information traverses through the Internet every day. The chances of your data actually being intercepted and read are small. However, if you are concerned that your data is being intercepted and read, consider getting a Secure Socket Layer (SSL) server. Examples of SSL servers include the Netscape Secure Server and the Oracle Secure Server. SSL servers encrypt data before sending it, which makes it almost impossible for anyone to intercept and read the communication going back and forth between your server and the client on the other end.
Any browser that can accept SSL will decrypt your information as it is sent back. Your server has a public key and a private key, and your browser has a public key and a private key, and when the browser makes a connection with a server, the two exchanges keys. In this sense, your browser and your server mesh by talking to one another cryptically.
You can do something similar with mail. PGP (Pretty Good Privacy) was developed for Internet mail by Phil Zimmerman a few years ago and is another option for maintaining security on an intranet. It can be used for any text transmission over the Internet. PGP functions in much the same way as browsers do in that PGP exchanges keys with an individual or a site on the Internet. The information is encrypted before it is sent and is then decrypted on the receiving end. Should someone intercept it in transmission, the information wouldn't be useful-it would be gib-berish.
In checking off the security list, don't overlook the security
of functions and software. Whichever way you choose to build your
software-through commercial applications or through developing
your own applications using a back-end database or CGI scripts-one
of the most important things you can do with those software applications
is pay careful attention to potential security holes. For example,
on most Internet forms, information is passed via a URL or from
the HTML on a page back to the server. Sometimes you might be
tempted to pass information such as user IDs or other various
pieces of information important to the security of your intranet
through one of these pages. However, suppose, for example, that
you have a message board. While users are talking or exchanging
messages on the board, a user ID gets passed through an HTML file.
If you are passing that information, it's easy for one of your
users (or even for someone on the outside) to recreate that HTML
file, change the variables, and pass the information back to your
server. You want to make sure that no vital information passes
through HTML files.
| Tip |
One way to prevent information from being passed via HTML files is to tie it to a user ID via a database. A user ID can always be taken from an environment variable. No matter what kind of server you're using, whether it's Netscape, NCSA, or Oracle, the user ID that you type in for authentication is always kept as an environment variable. So if you can tie important information-information that could be misused-to the environment variable user ID, you prevent the possibility that the information would be passed via an HTML form back to the server. |
Finally, you should try to defeat crackers-users who intentionally
try to "crack" secure zones. It isn't easy. The bottom
line is this: Any information that is 100 percent vital-information
that would devastate your company should it be made public-should
not be stored in digital form on the Internet or on your intranet.
No matter how much time or money is spent on securing information,
it is always possible for someone to break into your network.
Even sites such as Netscape get broken into, and Netscape employs
extensive security methods. The possibility of a cracker gaining
access to your files always exists, and the risks increase for
high-profile companies. But regardless of your company's size,
profile, or mission, if people think they can gain something by
breaking into your system, expect that they will try.
| To eliminate security holes in your computer system, I recommend that you turn to SATAN. That's right, SATAN-Security Administrator Tool for Analyzing Networks. Practically any TCP/IP network with a UNIX server can benefit from
using SATAN to investigate potential security holes. Even if you are on a local network with no fear of intrusion, SATAN can help protect against accidents by your own users. SATAN's main function is to evaluate the security of your system. The
security program gathers information about specific hosts and networks by examining network services-including FTP, NIS, and NFS-as well as the current hardware and software being used. SATAN then reports its findings or investigates potential
security risks. For example, if one of your users has a password that is easy to crack, or if a particular directory has a permission structure that allows anyone to upload and execute a binary on the server, SATAN will tell you.
One interesting aspect of SATAN is that when it's finished analyzing your system, it will poke around other systems looking for security holes as well. You can set up SATAN to comb the entire Internet, looking for security problems, if you desire. Although that information might not be useful to you directly, learning about how other systems are set up and what problems they face can help you make your network stronger.
The program was designed by San Francisco security expert Dan Farmer and a security programmer at the Netherlands University of Eindhoven, Wietse Venema. It is free and available for download at the following address:
For documentation on SATAN, visit this site: |
From server and software to passwords and the physical location of equipment, you'll have several security holes to patch. But remember, your best offense is a good defense. An understanding of the always-vulnerable transmission route, a careful examination of your system's physical surroundings, an educated user base, and a commonsense approach to all security issues all add up to a secure environment. But don't stop here. Stay on top of evolving security technology and keep in step with crackers.