10 tips for troubleshooting slowdowns in small business networks

Network congestion and slowdowns--whether caused by faulty hardware, negligent users, viruses or spyware applications gone wild, or other factors--lead to serious headaches for network administrators and support personnel. By keeping a wary eye tuned for the following 10 items, IT professionals can help prevent the most common causes of network slowdowns.

#1: Bad NICs
Intermittent network errors, particularly those isolated to a specific workstation or server, can often be traced to a failing network interface card. When you believe a network adapter may be failing, visually inspect the card's LED link lights.
A solid green (or amber) LED indicates the NIC has a good active physical connection with another network device, such as a network switch or router (blinking LEDs typically indicate the NIC possesses an active connection and is processing network traffic). If the LED is not lit green, it's likely the network adapter is disabled within Windows or doesn't have an active connection to the network. It's also possible the cable plugged into the NIC is connected to a nonfunctioning wall-jack or faulty network port.
If you can rule out nonfunctioning wall-jacks and faulty network ports (the easiest method of doing so is to connect the same network connection to a laptop known to have a properly functioning network adapter), and if the network adapter is properly enabled and configured in Windows, it's likely the NIC is bad and requires replacement.

#2: Failing switches/routers
Many network slowdowns are foreshadowed by strange occurrences. For example, regular Web traffic may work properly, but e-mail may stop functioning. Or, regular Web traffic may work properly but attempts to connect to any secure (HTTPS) sites may fail. In other cases, Internet access simply ceases across the board.
Often the best remedy for inconsistent network outages and/or slowdowns is to reboot or power cycle the network's routers/switches. If local network connectivity exists (if users can view and access network shares) but they are not receiving e-mail from external users or cannot access the Internet, rebooting or power cycling the WAN modem can often return the network to proper operation.
If you're having to reboot or power cycle a piece of network equipment consistently, make sure that it's connected to a quality uninterruptible power supply. Power fluctuations often result in confused switches and routers. If a network device is connected to a good UPS and still frequently experiences trouble, it may be necessary to replace the failing switch, router, or modem.

#3: Daisy chaining
As organizations grow, particularly small businesses, outside IT contractors often implement simple solutions. Many consultants choose to simply add a five-port router to an existing four-port router/firewall. Small businesses everywhere boast just such a setup.
However, as switches are added to a network, data packets must navigate additional hops to reach their destination. Each hop complicates network routing. Depending upon the amount of traffic a network must support--and even a small dentist's or doctor's office can easily stress 10/100 Mbps systems due to X-ray imagery, patient file information, and other data--the addition of an extra hop or two can spell the difference between a smooth running network and one that frequently slows employee productivity to unacceptable levels.
Resist the urge to daisy chain multiple network switches and routers. Instead, plan for capacity. Or if unforeseen growth has resulted in successive connected switches, eliminate as many devices as possible through consolidation to a more potent and scalable unit.

#4: NetBIOS conflicts
NetBIOS, still in use on many Windows NT 4.0 networks in particular, contains many built-in processes to catch and manage conflicts. Occasionally, however, those processes don't handle conflicts properly. The result can be inaccessible file shares, increased network congestion, and even outages.
Guard against NetBIOS conflicts by ensuring older Windows systems all receive the most recent service packs. In some cases, Windows NT 4.0 systems having different service packs will generate telltale NetBT (ID 4320) errors.
Strange network behavior can also occur when two systems are given the same computer name or when two systems both believe they serve the master browser role. Sometimes the error will log itself as Event ID 8003 in a server's system log. Disabling WINS/NetBT name resolution (only if it's not required) can eliminate such issues.
If disabling NetBT is not an option, such errors can often be eliminated by identifying the second system that has the same computer name within the same domain and giving it a new name or by restarting the Netlogon Service on the domain controller. Yet another option for eliminating legacy NetBT issues is to search a system's LMHOSTS file for inaccurate or outdated entries. Some IT professionals claim they've solved similar errors by disabling and re-enabling the NIC on the offending system.

#5: IP conflicts
Windows typically prevents two devices with the same IP address from logging on to the same network (when using DHCP). But occasionally, two systems with the same address wind up on the same network. For example, one system could receive an address automatically, while another computer logs on using a static address specified by a user. When such conflicts occur, network slowdowns result (and the systems sharing the same address frequently experience outages).
Troubleshoot IP address conflicts by ensuring you don't have a rogue DHCP server on the network. Confirm, too, that configured DHCP scopes don't contain overlapping or duplicate entries and that any systems (such as servers and routers) that have been assigned static IP addresses have been excluded from the DHCP pools.

#6: Excessive network-based applications
Occasionally, networks are overrun by the applications they power. For example, a physician's office that uses a Web-based patient and practice application will commonly have every workstation logged on to the program during business hours. Retrieving data from the patient database and consistent monitoring of appointment and scheduling information alone can place stress on even a well-architected network.
Add in the fact that each workstation is likely tuned to e-mail (and many offices are turning to VoIP) and it's easy to see how introducing a few streaming audio/video files to the mix (either in the form of online music services, news videos, or instructional medical presentations and Webinars) can unacceptably slow a 10/100 Mbps network's performance.
Implement policies--and if necessary, hardware-based Web filtering tools--to prevent applications from overwhelming available network bandwidth. Make sure employees understand they're not to stream unnecessary audio and video files. Further, when working with VoIP, be sure adequate data pipes are in place to manage both voice and data traffic.

#7: Spyware infestation
Spyware, the scourge of the last few years, finally appears to be meeting its match in business environments. The development of potent anti-spyware tools, combined with effective end user policies, is reducing the impact of spyware in many organizations. Windows Vista includes Defender, a decent anti-spyware application powered by the popular Giant engine.
However, infestations still occur, particularly on older systems that haven't been properly safeguarded. Implement strong user policies and either gateway-based protection or individual client applications to prevent spyware programs from consuming precious network bandwidth.

#8: Virus infestation
Just as spyware is proving containable within business environments, so too are viruses. That said, despite an administrator's best efforts--including firewall deployment, routine and consistent Windows patching, and the use of regularly updated antivirus programs--viruses do get through. The result can bring a network to a standstill.
For example, many viruses place Trojan programs on Windows systems, where they can wreak havoc. In addition to leveraging a system's ability to send e-mail to forward hundreds (if not thousands) of spam messages an hour, viruses can corrupt network configuration.
Defend against virus threats to network performance by ensuring firewalls, Windows updates, and antivirus programs are properly configured and maintained.

#9: Insufficient bandwidth
Sometimes, a network just doesn't have the throughput it requires. As with # 6--excessive network-based applications--some environments demand more bandwidth than others.
When a network does bog down, several options typically exist for increasing capacity. Besides boosting up- and downstream speeds, some offices may require additional dedicated connections. From multiple T1s to DS3s to even optical carrier-grade connectivity, many potential solutions exist.
Further, some organizations may need to upgrade existing 10/100 Mbps networks to gigabit speeds. By upgrading NICs, cabling, and devices to 10/100/1000 Mbps equipment--and replacing any remaining hubs with switches--many firms can realize significant capacity gains. In other cases, it may be necessary to subnet networks to localize particularly intense traffic to specific network segments.

#10: DNS errors
DNS configuration errors can lead to numerous network failures and generalized slow performance. When no DNS server is available on a local LAN, local systems may have trouble finding one another or accessing local resources because they'll have trouble finding service locator records that assist Windows systems in communicating with Active Directory. Worse, systems with no local DNS server or those workstations having DNS servers several hops away may experience delays or flat outages in accessing Web sites and extranets.
Try placing DNS servers as close to network systems as possible. Although adding DNS services to existing servers places greater demand on those boxes, properly configured machines can remain secure and noticeably enhance response times to external resources.
Also, always check to ensure systems are configured to use the proper DNS servers. Network architectures change over time, yet older workstations (particularly those set to use static addressing) occasionally are forgotten and continue operating using outdated DNS settings. As your organization and ISP update DNS systems, be sure workstations and other routing equipment actually receive the updates.

The frustration of bot fighters

This last week I was among those at the "secretive conference" of security folks, ISPs and law enforcement agents to discuss bots. Much like at last year's VB conference, there was much discussion about the need for more cooperation and information sharing between bot fighters. Not just within the three groups but within each of the individual disciplines. People within all of the three groups were clear that none of us have all the pieces of the puzzle, and that in order for us to truly make a dent in the growth of bots and botnets, we need to share more of our information with each other.There has been much made of turf wars within the bot herder community, but the more notable thing in terms of fighting these bots is actually how much they’re cooperating. We know they’ve been pooling resources to code their bots, but apparently they’re also sharing botnet resources quite widely (for instance, to take down a particularly robust website that they wish to attack). Computer Security Research - McAfee Avert Labs Blog

Storm Worm Hits Computers Around the World

Computer virus writers started to use raging European storms on Friday to attack thousands of computers in an unusual real time assault, head of research at Finnish data security firm F Secure told Reuters. The virus, which the company named "Storm Worm," is sent to hundreds of thousands of email addresses globally, with the email's subject line saying "230 dead as storm batters Europe."The attached file contains the so-called malware that can infiltrate computer systems. Storm Worm Hits Computers Around the World - News and Analysis by PC Magazine

Myth #6:A wireless IDS is unnecessary if other rogue AP

While exposing the myth about the prevention of rogue APs could be a blow to wireless IDS vendors, there is another common Wi-Fi myth that has been having the opposite effect. Many networking professionals are under the mistaken impression that a wireless IDS is unnecessary if other rogue AP prevention measures are in place.

It’s easy to understand why the average network administrator might be hesitant to get behind a wireless IDS. They are very expensive and there’s not a whole heck of a lot of folks out there who actually understand everything that a wireless IDS is doing. Even most of the folks who have invested in a wireless IDS only did so because they need to prevent rogue access points.

The reality is that there’s a whole other area of troubleshooting and Wi-Fi optimization features that make wireless IDS products a valuable addition to most networks. Some of today’s wireless IDS offerings do location tracking, remote packet captures, and analysis of RF interference levels.

When you think about it, these other wireless IDS features are much more likely to make a networking person’s job easier than the ability to neutralize rogue APs. Instead of having to send field technicians out to every location that has a problem, a wireless IDS allows the experts that own your network to troubleshoot the wireless medium from a centralized location.


One more thing to think about is the fact that so many Wi-Fi users are new to the technology. New users are often reluctant to report problems or call the support team. A wireless IDS may be the best way to find out if some area of a facility is likely to be unsuitable for time-sensitive applications like VOIP or video conferencing.

This myth about the ways the use a wireless IDS really has more to do with the performance of the network than the security of the network. Let’s look at three more myths that really touch on the performance of Wi-Fi networks.

Myth #5:You need a wireless IDS to prevent rogue access

The previous Wi-Fi myth was a chance to examine a well-known relationship of safety and security: The more secure something gets, the less accessible it becomes to the folks who need to use it. There is another, more fascinating dichotomy as it pertains to technological advances in safety and security: As any entity becomes safer or more secure, the advance of technology will continue to create new ways to push the limits of this new security.

Take the security of automobiles. With airbags, crumple zones, and enhanced braking technology, cars and trucks are safer than ever. But as these safety enhancements have been introduced, more and more cars are capable of faster and more dangerous speeds due to ever-improving engine, cooling, and suspension technology.

In the world of Wi-Fi, things are no different. As Wi-Fi security has evolved from WEP to WPA and WPA2, people have become more and more comfortable buying Wi-Fi access points and station devices. With this boom in the number of wireless devices, network administrators have been forced to deal with the ever-increasing threat of rogue devices being attached to the network.

While the number of potential rogue access points has surely risen, the potential for intrusion has long been present. Many companies have introduced wireless intrusion detection systems (wireless IDS) as a way to counteract such intrusions. A wireless IDS can identify, locate, and even contain rogue access points. Over the last several years, many wireless IDS vendors have touted their products as essential tools for counteracting the threat of rogues.

There’s little question that a wireless IDS will help prevent rogue access points, but the question has to be asked: Is a wireless IDS the best tool for preventing rogue access points? The answer is a clear, “No.”

A wise man once said, “To thwart thy enemy, one must first know thy enemy.” (Actually, we’re not sure if anyone said that, but it sounds great, though.) Knowing rogue access points means knowing exactly what type of threat they pose to a network. A rogue access point is a threat because it could allow unauthorized users to gain access to network resources through a wireless link. Since a rogue AP is not managed by the network administrator, the authentication and encryption quality being used on a rogue AP cannot be verified. Without the guarantee of strong authentication and encryption, an intruder could use any number of means to gain network access from outside the walls of the organization.

In understanding these the nature of rogue access points, two important principles come to light: They must be identified separately than any authorized APs in the area and they must be blocked from network access.

A wireless IDS does a superb job of identifying 802.11a/b/g rogue APs. If an ACL is configured on the wireless IDS, the network administrator will receive an alarm every time an unauthorized device is nearby.

Unfortunately, a wireless IDS does a much less impressive job of identifying non-802.11a/b/g rogue APs. If someone plugs in a legacy AP that was based on 900 MHz and/or FHSS technology, that device will remain undetected. The same applies for certain newer non-802.11a/b/g APs like those based on Bluetooth and MIMO technology. Some newer wireless IDS vendors now offer products that can identify some of these non-standard APs, but comprehensive AP identification is virtually impossible.

A wireless IDS also does a less-than-superb job of blocking rogue APs from gaining network access. Almost every wireless IDS vendor offers some method of rogue AP suppression. Some vendors send a wireless DoS to the rogue AP and its associated stations. This technique is weak because a Wi-Fi adapter can have its drivers manipulated to ignore de-authentication or disassociation frames that are used to cause a DoS attack. Other vendors shut down the wired port that the rogue AP is plugged in to. Another weakness of this technique is that a rogue AP configured with encryption and authentication (yes, even WEP) will not allow the wireless IDS
to send the message onto the wired side of the network so that the correct port can be identified.

Really, the problem with using a wireless IDS to prevent rogue APs begins and ends with the nature of the system itself. A wireless IDS is designed to be an overlay to a network. Heck, that’s part of its allure. You know: Installing the wireless IDS where Wi-Fi is not allowed. The best way to stop rogue APs is going to be something that is integrated with the network. It has to be something that allows a network manager to block access on every network port.
Wired 802.1X authentication is the perfect solution for blocking access on every network port.

When wired 802.1X is enabled, network access is denied until a device authenticates as an 802.1X supplicant. This is even more effective than using MAC address authentication for a couple of reasons. First of all, if you’re using 802.1X for your wireless users then you can use the same infrastructure that may already be in place. Secondly, 802.1X authentications generally include the negotiation of an encryption key. When encryption is used, MAC address spoofing becomes impossible because the intruder will not have the correct encryption key.

The myth that a wireless IDS is the best way to prevent rogue access points has benefited wireless IDS vendors for quite some time. Numerous students who attend our classes enter class with the idea that they need a wireless IDS to stop rogue APs, but by the end of the week, they usually see that wired 802.1X and wired MAC authentication are both more comprehensive methods.

Myth #4: Disabling the SSID broadcast will hide your

We’ve made it through a darn good portion of this paper without relying on analogies. As anyone who’s taken our classes knows, though, we love them. They tend to lighten up class a bit, and they let us talk about topics that we really know something about: movies and sports cars.We know you’re not exactly in a class right now, but let’s tackle our fourth myth by starting with an analogy of a really good Western movie.

Imagine your local bank. Imagine that Butch Cassidy and The Sundance Kid live nearby. Your bank clearly needs security, but it also needs to stay open to customers. Let’s now imagine that instead of installing a safe, some locks, and thick steel bars between the tellers and customers, you decide to simply take down the sign advertising the name of your bank. Your bank has now performed the financial equivalent of disabling the SSID broadcast.

Disabling the SSID broadcast has been touted by a number of network security professionals because the SSID will stay hidden from Wi-Fi client software. When users want to connect, they must manually configure the SSID (and accompanying security settings). Since hackers and wardrivers won’t know the SSID, they won’t be able to connect, right? Not exactly.

Forcing users to configure the SSID offers minimal security to a wireless network. As in our Wild West banking analogy, network intruders can see that a Wi-Fi network is there. Just as Butch and Sundance would have been able to identify the bank by watching the clientele that entered, wardrivers can identify the SSID by capturing frames with applications like Wildpackets Omnipeek when authorized users connect.

When stations are connected to the network, they are constantly looking for other APs with the same SSID. They must do that to enable roaming. When APs respond to these probing stations, the SSID is sent in the clear, viewable text whether encryption is being used or not.

Now, it should be pointed out that your SSID will stay hidden as long as the network remains unused. For an AP to respond with the SSID in clear text, a station must probe the AP using the correct SSID. But think about it; how often is your network in use? If your network is like most enterprise Wi-Fi networks, it’s in use darn near all day. That means attackers have the ability to uncover your hidden SSID in a matter of seconds whenever they darn well please.

In the end, what you’ve got is a security method that gives you no real protection against malicious intruders, but causes your novice Wi-Fi users to have a tougher time getting connected. Why put your users (and the support team) through all of that? Once you consider the good and bad of leaving the SSID broadcast enabled, you’ll probably find that it’s summarized best by paraphrasing Butch Cassidy’s thoughts from the first scene in the movie: “It’s a small price to pay for manageability.”