| P e n T e s t » T e s t L a b S e t u p |
||||
To know a thing well, know its limits. Only when pushed beyond its tolerances will true nature be seen. Do not depend only on theory if your life is at stake. |
||||
| A Funny Thing Happened On The Way To The Forum A panicked admin at a corporate client's site once rang me up during a three-day weekend, absolutely convinced that his network was being DoSed by an Eastern European hacker group. The circumstantial evidence: The internal and external firewalls showed massive amounts of traffic and several servers on the DMZ had become non-responsive. The external firewall was busy, but not as overloaded as the internal firewall. That was a wee bit strange for an external attack, wasn't it? A quick sniff at both firewalls showed that many of the source addresses resolved to .ru domain names, and the traffic wasn't using well-known ports. Poor bugger. He and his team had given up their Memorial Day weekend barbecue-palooza in order to re-cable the network while the office was empty, thereby minimizing network disruption. 36 hours later, the requisite miles of Cat-5 had been laid. They were almost done testing the network, but now the DMZ was going nuts. The prospect of hotdogs was fading fast, and there was now the unpleasant adrenaline rush you get when you surprise a burglar who is clutching your good silver. Had they caught a botnet attack in flagrante? After a quick game of 20 Questions over the phone, we figured it out. There was no attack. As it turns out, three separate events had produced this combination of symptoms. Someone had left a BitTorrent client running on their office workstation and many of the peers were located in Russia, hence the .ru source addresses. Traffic from that workstation was not routed through the newly-recabled subnets, so the admin did not notice the BitTorrent traffic until he started testing the network connectivity in the DMZ. After identifying and disconnecting the BitTorrent client, the network traffic decreased and we could see what else was eating up the bandwidth. Most of the remaining traffic seemed to originate from inside the corporate network, from a monitoring station on the LAN. The only application running on that box was a network mapping utility. (The GUI-heavy sort of mapper that draws up a graphical map of the network with all the computers and devices and services enumerated with cute little icons. It is extremely easy to use and you don't even have to change the default settings. Popular with the same CLI-eschewing set that seems to embrace Sonic firewalls.) Half an hour earlier, an assistant admin had completed the last of the cabling work and, succumbing to an intense Kodak Moment urge, had launched the network mapper in order to capture the new network topology. Little did he know that the network mapper was gathering data by running a vanilla portscan on all subnets with no time delay between scans (the default setting). In essence, it was testing all ports on each computer in quick succession. Normally, this should not have caused more than a momentary strain on the servers, but this was Sunday night and the weekly scheduled backups had just kicked in 10 minutes earlier. The combined strain of the backups and the portscan had slowed the servers to a glacial pace. By pausing the network mapper, network traffic dropped 80% and the servers were able to continue with their scheduled backups unmolested. The admins finished testing the network without further incident. After the backups were completed, they ran the network mapper again, this time with a time delay between each port scan. The moral of the story is: Never ever "try out" a new tool on the network without testing it out in a controlled environment first. Better to crash a test box rather than a production server, right? Additionally, much of the fuss could have been avoided if any one member on that team had had the skills to identify the source of the traffic. That's the answer to most network problems, really: Precautions and education. Why You Need A Test Lab Some of these pen testing tools are passive data collectors, quiet as mice. You can run them for years on a monitoring station and have little or no impact on the network. Some honeypots and darknets are like that. However, many other tools are rampaging elephants which could, under the right conditions, disrupt networks and systems and destroy data. Even if you are not a newbie, set up a test environment in order to familiarize yourself with these tools. Keep an eye on the effect each tool has on the environment. Is it generating a lot of traffic? Is it hogging resources on the target system? Based on your observations, you can determine which tools are the most appropriate for your pen test. If a particular tool eats up bandwidth or CPU cycles, you may decide to use it only during off-peak hours. You may even discover that the tool is too disruptive for a live network and refrain from using it altogether. Push the tools to their limits and see what happens. Aside from the all-important Primum non nocere factor, a test lab is very useful as a predictor of how your production environment will respond to changes. Set up a test enviroment that closely mimics the production environment. Same hardware, same OS, same services. Now you have a safe and reliable way to test security upgrades or play with access control. You can even practice migrating OSes and applications. If the production environment is busy or temperamental, or otherwise unavailable for a full, protracted pen test, you can utilize the test lab to perform a preliminary pen test. If the test lab is similar to the production environment, you can use the test lab to identify security flaws that probably exist in the production environment. Now, this is not a substitute for a full pen test on the production environment, but it will reduce downtime if you have already identified some of the security flaws. You can then devote more time to identifying other vulnerabilities in the production environment during the actual pen test. Right, then. Let's have a look at several ways you can set up a test lab. Virtual Machines VMware is an excellent way to run multiple operating systems simultaneously on the same computer. You install the VMware application on the host operating system, then install as many guest operating systems as you need. The guest OSes are stored in VMware files that can be burned onto a DVD for easy backup and restore. Microsoft has a similar application called Virtual PC, which can be downloaded for free. I've always found it useful to have a computer (preferably a laptop, for the sake of portability) with all necessary pen testing tools already installed and configured on it. Most of my favorite tools run on both Windows and Linux, but there are always a few good ones that never get ported. Rather than tote around multiple computers, I have multiple VMware guest OSes installed on my laptop, each with the needed tools already installed.
Live CDs Live CDs also allow you to run multiple operating systems on the same box without actually installing OSes onto the hard drive. You boot your computer from a Live CD and it loads an OS into RAM and leaves the hard drive untouched. These Live CDs are especially useful:
Multibooting If you have enough hard drive space, you can install multiple OSes on a single computer. The disadvantage is that you can only run one installed OS at a time. However, this may be the way to go if your hardware cannot support even VMware's modest resource requirements, or if your optical drive is too slow to run a Live CD effectively. Many bootloaders out there will handle Windows and Linux (Check out GRUB and LILO.) Windows's NTLDR may be ancient, but it's a very stable text-only bootloader and I have gotten it to load a quad boot of Windows 2000 Server, Windows XP, RedHat and Solaris for Intel. You don't necessarily need anything other than the partitioning tools on an OS install CD, but Partition Magic is a particularly good tool for slicing up the hard drive. Your Very Own Test Network If you have boxen to spare, set up a test lab. Connect several computers to a hub / switch / router. Install a different OS on each computer. If possible, add different computer architectures to your test lab, not just Wintel boxen. Segregate this test lab from any live network. This allows you to have multiple OSes running simultaneously and you never have to worry about not having a compatible OS to run pen testing tools. Because you have an actual physical network in your test lab, you can practice Man-in-the-middle attacks and anything else that involves intercepting data transfers. You can also practice pen testing a specific live target by installing a mock target with the same OS and services as the real target. You do not need to break the bank to set up a good practice lab. A lot of slightly older machines can be had cheaply if you look in the right places.
Online War Games There are a great many hacker war games available online. Some war games are only simulations in a virtual environment, but some are actual computers that have been set up for visitors to hack into. A war game is usually presented as an intellectual exercise, a learning tool that allows you to progress through different skill levels. Some games are hosted by security firms that want to test the security of a particular computer configuration. If you attend certain security conferences, you can play variants of Capture the Flag with the other attendees. |
