written by: Lee Clemmer•edited by: Bill Bunter•updated: 5/5/2010
Penetration Testing can seem like a black art to a beginner. To an IT veteran not specializing in security it may seem as simple as buying a product and clicking a few buttons. Neither of these ideas is true. Here we'll examine how to get started with pen testing and how to do it well.
slide 1 of 4
Pen Testing Goals
Before you start downloading and running scanning tools and exploit code, you should decide what your goals are for penetration testing. Goals? Why? Can't we just run the tests? Well, first you want to consider the purpose of the test and why it will be valuable to run. Are you checking a particular system, appliance, or application for a known vulnerability? Are you auditing to determine if all needed patches are in place? Are you checking firewall rules? Is the test for a personal system, an internal test for your company or employer, or for a 3rd party? Was the test your idea or did someone else want it? Who is responsible for making changes if problems are found? Who needs to be notified before the testing starts?
slide 2 of 4
What & How Are You Testing?
After your goals are defined, you should know what you're testing. Now you need to plan how to test it. There are two broad categories of tests: Unknown (or blind) target and Specific (or defined) target. Blind testing involves scanning an IP address, range of addresses, or an entire subnet, without knowing in advance what hosts are present, what the types of systems are (routers, switches, firewalls, web servers, printers, etc), and without knowing any details about OS, platform, or application versions. A defined target test describes in advance the details of what systems are being tested and what sort of problems you're looking for. For example, testing an IIS / .Net web server on Windows 2000 for elevation of privilege vulnerabilities is a defined test. The tools and techniques you'll use depend on the type of test.
slide 3 of 4
Chosing the Right Tools & Running the Tests
For a blind test you'll want to start with a network scanner and port scanner such as Nmap. You have to do this to see what's out there, what types of systems you're attempting to penetrate, and what services are running that it might be possible to exploit. Once you know what's there, you can select the appropriate tools and tests to proceed with. If you're using free tools, you may follow up your Nmap scan with Nessus, for example, to see what vulnerabilities are present and how serious they may be. Nessus produces excellent reports and can run refined tests for particular types of targets.
If you're using a commercial testing product, here is where you will want to fine tune your tests and their depth based on your initial scans. Once you've identified the vulnerabilities present, you'll want to run specific exploit tests or custom attacks that prove and verify the vulnerability is real and not a false positive, or not exploitable. Individual testing programs specific to a particular vulnerability are often available, or custom code can be written or extended using platforms like Metasploit.
Compile and format your results based on your findings. I often take screenshots or other proof of penetrations & crashes for supporting documentation.
slide 4 of 4
Interpreting Your Results
Once you have run your tests and have the results and reports, now you have to decide what they mean. Is the problem resolved simply by applying a patch or update? Is the vulnerability an acceptable risk for internal systems? Can changes to firewall rules limit the risk now and in the future? Does the vulnerability expose private data? Can servers, applications, or databases be corrupted or made to crash? Does the problem require changing custom code or application configuration? Sometimes the answers are not obvious. Changes may need to be made and the tests then re-run. Don't blindly trust the results of any test without analysis. Many testing tools include explanations of fixes for the vulnerabilities.