|"The fact is, having a well-documented network can help you solve problems quickly when they arise, and documentation is vital to the overall security of your network.
Undocumented networks are extremely common. Many times this situation is related more to the difficulty of keeping the documentation up to date than to the complexity of the documentation process itself. Many LAN administrators start with big dreams of keeping elaborate drawings, detailing every aspect of the network. However, networks tend to change too frequently for such drawings to stay current. The fact is, having a well-documented network can help you solve problems quickly when they arise, and documentation is vital to the overall security of your network. In this article, I’ll discuss some alternative and practical documentation methods that will help you keep up–even in the ever-changing world of networks.
Perhaps the most important part of a good network documentation plan is to label everything. You should create the labeling scheme with the idea that the structure of the network will change constantly, as will the people who use the network.
Perhaps the most important things to label are your network cables. If you’ve been networking for long, you’ve probably seen far too many network closets that contain a massive web of tangled cable. Usually, all this cable looks alike, and it’s impossible to tell which cable connects to which component without extensive diagnostic work. Most network administrators I know are too busy to fish through a million cables every time there’s a problem, hoping to stumble on the correct one. You should label both ends of each cable with a description of what the cable does.
Each label should be written in such a way that in five years, when you’ve moved on to another job or have totally forgotten all the work you did today, the label will still make sense. Although it may seem obvious, you also must make the label legible. Wrapping cables in masking tape and writing on the tape is a bad idea–these sorts of labels tend to fade or crumble to dust over the years. I recommend using a commercial label maker. Just be sure that whatever kind of label you use has strong enough adhesive that the labels won’t gradually fall off.
I mentioned that the network labels should still be useful several years down the road. Therefore, they shouldn’t be based on building locations or on people’s names. For example, creating a label marked “John’s office” is a bad idea, because John could quit tomorrow. Likewise, creating a label marked “Finance Manager’s Office” won’t work, because five years down the road, the marketing manager could be using the office, or the office could be a conference room instead of an office. You also should plan on network growth. For example, a cable marked “Manager’s Office” could be misleading if, in a few years, 10 network cables are in the manager’s office.
Instead of names or geographic locations, I recommend using a numeric scheme. For example, you might create a map of the building with a CAD program and document the location of each network outlet. Then assign each network outlet a number. Once you’ve assigned numbers, mark both ends of each cable with the number that you’ve chosen. Then, mark the network outlet on the map with the number. As more network outlets are added, simply add them to the map. The map should be posted on the wall in your network wiring closets so that at a glance, you can tell exactly where any given cable goes.
|"If your permissions are damaged, it’s much quicker and easier to look them up in a logbook and manually correct the problem than to deal with the hassles involved in a restore operation.
Another issue to consider in network documentation is the configurations of your servers, workstations, and users. When it comes to creating this sort of documentation, one massive log just doesn’t do the trick. A single log tends to become too large–it’s difficult to locate information quickly. Instead, I recommend creating several different logs.
I recommend keeping a separate logbook with each server. Any time a change is made to the server’s configuration, detailed notes should be placed in the server’s logbook. For example, if you add a service pack to the server, you might record the date and time of the upgrade and the service pack number. Although such information may sound trivial, keep in mind that in many environments, more than one person has administrative access to the servers. By keeping a complete history of any changes that each person makes to a server, it’s easy to see if one of your coworkers has made a recent change, should a problem come along.
You can also keep a logbook for each workstation, but doing so is often unnecessary in large environments. In large environments, the goal is to make each workstation as standard as possible. Therefore, you might keep one logbook that documents the standard configuration and any changes you might make to it.
Finally, you should keep a security logbook. This log should contain a record of every user account on the system, along with information such as what groups the account is a part of, and any special access permissions the account might have. Similarly, the security log should contain a list of groups, along with the groups’ members and permissions.
The security logbook may sound like a lot of useless work, when you consider that you can easily retrieve such information directly from the system. However, I’ve seen countless situations in which permissions were damaged during a server migration or other routine maintenance. In such a situation, you could always get the permissions back by restoring a backup, but doing so requires time and reverts users back to older file versions. If your permissions are damaged, it’s much quicker and easier to look them up in a logbook and manually correct the problem than to deal with the hassles involved in a restore operation.
Obviously, your security log book shouldn’t be limited to information on permissions. It also should contain detailed information about your security policies in general, such as how often you force password changes, and minimum password lengths. You can really use your imagination: Although some administrators consider it going too far, I’ve seen administrators include legal documents in the security logbook. These documents are signed by each user before he or she is given a network account, and cover such issues as software piracy and Internet usage. Clearly, a security logbook is nice to have around, should your boss hire a consulting firm to pull a surprise security audit. //
Brien M. Posey is an MCSE who works as a freelance writer and as the Director of Information Systems for a national chain of health care facilities. His past experience includes working as a network engineer for the Department of Defense. Because of the extremely high volume of e-mail that Brien receives, it’s impossible for him to respond to every message, although he does read them all.