This article is also available as a PDF download.
One of the most popular pastimes of IT professionals is complaining about the dumb things users do. We all get a laugh from articles like "10 classic clueless-user stories." But if we're honest, we have to admit that computer novices aren't the only ones who make mistakes. Most network administrators could (but probably won't) tell you about their "most embarrassing moment." That's the one where you discover you accidentally misconfigured the firewall to shut down the boss's Internet connection or that the backup you've been making every day has been copying the wrong files. Oops.
Let's take a look at some of the most common dumb things IT pros do that can mess up their networks--and how you can avoid making such mistakes yourself.
#1: Don't have a comprehensive backup and disaster recovery plan
It's not that backing up is hard to do. The problem is that it sometimes gets lost in the shuffle, because most network administrators are overloaded already, and backups are something that seem like a waste of time and effort--until you need them.
Of course you back up your organization's important data. I'm not suggesting that most admins don't have a backup strategy in place. But many of those backup strategies haven't changed in decades. You set up a tape backup to copy certain important files at specified intervals and then forget about it. You don't get around to assessing and updating that backup strategy--or even testing the tapes periodically to make sure your data really is getting backed up--until something forces you to do so (the tape system breaks or worse, you have a catastrophic data loss that forces you to actually use those backups).
It's even worse when it comes to full-fledged disaster recovery plans. You may have a written business continuity plan languishing in a drawer somewhere, but is it really up to date? Does it take into account all of your current equipment and personnel? Are all critical personnel aware of the plan? (For instance, new people may have been hired into key positions since the time the plan was formulated.) Does the plan cover all important elements, including how to detect the problem as quickly as possible, how to notify affected persons, how to isolate affected systems, and what actions to take to repair the damage and restore productivity?
#2: Ignore warning signs
That UPS has been showing signs of giving up the ghost for weeks. Or the mail server is suddenly having to be rebooted several times per day. Users are complaining that their Web connectivity mysteriously drops for a few minutes and then comes back. But things are still working, sort of, so you put off investigating the problem until the day you come into work and network is down.
As with our physical health, it pays to heed early warning signs that something is wrong with the network and catch it before it becomes more serious.
#3: Never document changes
When you make changes to the server's configuration settings, it pays to take the time to document them. You'll be glad you did if a physical disaster destroys the machine or the operating system fails and you have to start over from scratch. Circumstances don't even have to be that drastic; what if you just make new changes that don't work the way you expected, and you don't quite remember the old settings?
Sure, it takes a little time, but like backing up, it's worth the effort.
#4: Don't waste space on logging
One way to save hard disk space is to forego enabling logging or set your log files to overwrite at a small file size threshold. The problem with that is that disk space is relatively cheap, but hours of pulling your hair out when you're trying to troubleshoot a problem without logs to help you discover what happened can be costly, in terms of both money and frustration.
Some applications don't have their logs turned on automatically. But if you want to save yourself a lot of grief when something goes wrong, adopt the philosophy of "everything that can be logged should be logged."
#5: Take your time about installing critical updates
The "It'll never happen to me" syndrome has been the downfall of many networks. Yes, updates and patches sometimes break important applications, cause connectivity problems, or even crash the operating system. You should thoroughly test upgrades before you roll them out to prevent such occurrences. But you should do so as quickly as possible and get those updates installed once you've determined that they're safe.
Remember that Nimda and other major virus or worm infestations have done untold damage to systems even though the patches for them had already been released.
#6: Save time and money by putting off upgrades
Upgrading your operating systems and mission-critical applications can be time consuming and expensive. But putting off upgrades for too long can cost you even more, especially in terms of security. There are a couple of reasons for that:
- New software usually has more security mechanisms built in. There is a much greater focus on writing secure code today than in years past.
- Vendors generally retire support for older software after awhile. That means they stop releasing security patches for it, so if you're running the old stuff, you may not be protected against new vulnerabilities.
If upgrading all the systems in your organization isn't feasible, do the upgrade in stages, concentrating on the most exposed systems first.
#7: Manage passwords sloppily
Although multifactor authentication (smart cards, biometrics) is becoming more popular, most organizations still depend on user names and passwords to log onto the network. Bad password policies and sloppy password management create a weak link that can allow attackers to invade your systems with little technical skill needed.
Require lengthy, complex passwords (or better, passphrases), require users to change them frequently, and don't allow reuse of the same passwords over and over. Enforce password policies through Windows group policy or third-party products. Ensure that users are educated about the necessity to keep passwords confidential and are forewarned about the techniques that social engineers may use to discover their passwords.
If at all possible, implement a second authentication method (something you have or something you are) in addition to the password or PIN (something you know).
#8: Try to please all the people all of the time
Network administration isn't the job for someone who needs to be liked by everyone. You'll often be setting down and enforcing rules that users don't like. Resist the temptation to make exceptions ("Okay, we'll configure the firewall to allow you to use instant messaging since you asked so nicely.")
It's your job to see that users have the access they need to do their jobs--and no more.
#9: Don't try to please any of the people any of the time
Just as it's important to stand your ground when the security or integrity of the network is at stake, it's also important to listen to both management and your users, find out what they do need to do their jobs, and make it as easy for them as you can--within the parameters of your mission (a secure and reliable network).
Don't lose sight of the reason the network exists in the first place: so that users can share files and devices, send and receive mail, access the Internet, etc. If you make those tasks unnecessarily difficult for them, they'll just look for ways to circumvent your security measures, possibly introducing even worse threats.
#10: Make yourself indispensable by not training anyone else to do your job
This is a common mistake throughout the business world, not just in IT. You think if you're the only one who knows how the mail server is configured or where all the switches are, your job will be secure. This is another reason some administrators fail to document the network configuration and changes.
The sad fact is: no one is indispensable. If you got hit by a truck tomorrow, the company would go on. Your secrecy might make things a lot more difficult for your successor, but eventually he or she will figure it out.
In the meantime, by failing to train others to do your tasks, you may lock yourself into a position that makes it harder to get a promotion... or even take a vacation.
Debra Littlejohn Shinder, MCSE, MVP is a technology consultant, trainer, and writer who has authored a number of books on computer operating systems, networking, and security. Deb is a tech editor, developmental editor, and contributor to over 20 additional books on subjects such as the Windows 2000 and Windows 2003 MCSE exams, CompTIA Security+ exam, and TruSecure's ICSA certification.