Minimize Windows security testing's impact on performance

Testing security is a good thing, but if you're not careful you could adversely affect your Windows networks and systems. Contributor Kevin Beaver has extensive security testing experience and tells you how and when to test to ensure the slightest network impact possible.

Have you ever wondered how your security testing impacts your Windows network, computers and applications? If not,

it's certainly something that you need to be cognizant of when planning for and carrying out vulnerability and penetration tests.

It's easy to overlook how security scans impact the network and users. Out of sight and out of mind, right? This is especially true in switched Ethernet environments when we don't always have (or use) a quick and dirty way to monitor overall network performance. But security scanning at the wrong time and in the wrong place does have negative consequences that you need to avoid -- things like saturating the network backbone (especially in unswitched Ethernet and Wi-Fi networks), hogging the T1 or business DSL connection to the Internet and creating significant workstation, server, application and database slowdowns.

I ran some highly unscientific tests to gather basic performance numbers and validate that it is, indeed, a real problem in some areas. For starters, I found that basic ping sweeps and port scans are pretty harmless. For this test, I used Foundstone Inc.'s SuperScan port scanner performing a full ping sweep and TCP port scan, running at maximum speed, of a half-dozen hosts. It generated a peak network utilization of 17.1%, according to the network analyzer I used -- EtherPeek from WildPackets Inc. Not bad -- especially considering I was using an antique 10 Mbps Ethernet hub for this test.

Consider what takes place, however, when you scan an entire network of, say, 500 hosts -- all at the same time. This is an even bigger issue once you go beyond the basic network scans and perform full-out vulnerability scans. I performed an internal vulnerability scan of a handful of systems using GFI LANguard Network Security Scanner and hit a network utilization of 54% relatively quickly with a sustained utilization of more than 30%. That certainly isn't too much for a switched Ethernet network to handle, but it is a big jump beyond my initial ping sweep and port scan test. This may or may not be a problem but it is something to consider. Bear in mind, too, that the bigger performance hit is likely to be seen at the host-level.

When running a Web server scan using SPI Dynamics' WebInspect at full throttle, I noted a maximum 23% network utilization with a much lower average utilization number. Not bad at all.

The real problem was at the server. It's not the beefiest box in the world, but it was notably slower -- several times over -- both when logging onto the system locally as well as browsing to it from the Internet. At the host-level, disk, memory and processor utilization often jump way up -- even max out -- when they're being scanned. Those stats, however, are often the least of your worries. The trouble begins when users on your internal network or clients coming in from the Internet experience delays or cannot access the network and applications at all. It takes just a few seconds -- milliseconds or less for real-time systems that can't afford any delays -- to stir up trouble. When performing Web application and database scans, this is virtually guaranteed.

The external scan download crawl

Another area of slowdowns that's often much worse than it is at the network and host levels is when you perform security assessments from outside the firewall coming in across much slower Internet connections. When performing an external vulnerability scan of one server using the QualysGuard scanner with normal configuration settings, I averaged a 100 Kbps drop in Internet download speed with a peak loss of 402 Kbps using Speakeasy's Speed Test. Imagine what could happen if I actually had anyone coming to visit my Web site! Looking at this problem in the context of e-commerce, these types of hits might very well be unacceptable, especially when testing multiple systems at the same time, which is usually how it works.

I performed this test running over a dedicated 3 Mbps fiber connection to the Internet -- in other words, no variable DSL or cable connection speeds. Outside of the drop in throughput when running my vulnerability scan, I noted various peaks and valleys in connection speed that weren't present in my baseline tests. Sure, there are always going to be variations and inconsistencies in such tests; nevertheless, the impact on Internet performance was consistent and clear.

So, to recap, basic port scanning is not likely to have any noticeable effect in most network environments. However, running "noisy" vulnerability scanners and penetration testing tools from both inside the network and out can and will cause problems -- especially to hosts and to your Internet connection -- if you're not careful.

Most LAN environments run on switched Ethernet, which creates dedicated bandwidth for each host and can ward off most problems at the network layer. You still have issues to worry about for non-switched Ethernet networks (I know they're still out there), wireless networks, Internet connections and slowdowns at the OS and especially the application and database levels.

Here are three things you can do to minimize the chance of flooding your systems the next time you run your security tests:

  1. Carefully consider your testing times and know that the optimal time for minimal network and system disruption may be during late morning (6 to 8 a.m.-ish) or late evening (8 to 10 p.m.-ish) and not during the middle of the night when backup jobs and other maintenance may be taking place. Simply put, get all of your key players involved and come to a consensus of the best time frame for testing.
  2. Throttle back your security tool settings. Many advanced tools give you the ability to limit active threads, TCP/UDP connections, packet delays, the number of hosts to scan in parallel and processes to run in parallel for each host. Know your tools and when it doubt, scale back everything.
  3. Test your hosts, Web applications and database systems from the inside when you can. If you're simply looking for overall vulnerabilities, this will really help. However, if you need a true external hacker's eye view of your systems (which is necessary in many cases) or if you're using an IDS, IPS or Web application firewall, this won't be a good option.

Many IT lessons are learned the hard way. Too much security scanning at the wrong time will eventually cause trouble. I've been down that road and I'm encouraging you to take the right steps so you can avoid problems. Think things through in advance, throttle back your scanning tools if possible and perform testing during off-peak times to minimize disruption whenever you can.

About the author: Kevin Beaver is an independent information security consultant, author and speaker with Atlanta-based Principle Logic LLC. He has more than 18 years of experience in IT and specializes in performing information security assessments. Beaver has written five books, including Hacking For Dummies (Wiley), Hacking Wireless Networks For Dummies and The Practical Guide to HIPAA Privacy and Security Compliance (Auerbach). He can be reached at kbeaver@ principlelogic.com.

This tip originally appeared on SearchWindowsSecurity.com

This was first published in May 2006

Dig deeper on Network Security Best Practices and Products

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchSDN

SearchEnterpriseWAN

SearchUnifiedCommunications

SearchMobileComputing

SearchDataCenter

SearchITChannel

Close