Hacking For Dummies. Kevin Beaver

as you can. Combine external (public Internet) tests and internal (private network) tests.

      You can perform some tests, such as password cracking and network infrastructure assessments, from your office. For external tests that require network connectivity, you may have to go off-site (a good excuse to work from home), use an external proxy server, or simply use guest Wi-Fi that might have a separate Internet connection. Many security vendors’ vulnerability scanners can be run from the cloud. If you can assign an available public IP address to your computer, plug into the network outside the firewall for a hacker’s-eye view of your systems. Just make sure that system is secure because it will be exposed to the world!

      Internal tests are easy because you need only physical access to the building and the network. Just plug right in and have at it. If you dig around from the perspective of a visitor or guest, you might find an open network port that provides full access to your network. This is often a huge vulnerability, especially if the public has full access — such as in a hospital lobby or waiting room area. I’ve seen it!

      Responding to vulnerabilities you find

      Determine ahead of time whether you’ll stop or keep going when you find a critical security hole. You don’t need to keep testing forever. Just follow the path you’re on until you’ve met your objectives or reached your goals. When in doubt, have a specific goal in mind and stop when you meet that goal.

      

If you don’t have goals, how are you going to know when you reach your security testing destination?

      If you discover a major hole, such as SQL injection on an external web application or a missing patch that provides full remote access to a critical system, I recommend contacting the necessary people as soon as possible so that they can begin fixing the issue right away. The necessary people may be software developers, product or project managers, or even Chief Information Officers in charge of it all. If you wait a few hours, days, or weeks, someone may exploit the vulnerability and cause damage that could have been prevented, potentially creating bigger legal issues.

      Making silly assumptions

      You’ve heard what you make of yourself when you assume things. Even so, you make assumptions when you test your systems. Here are some examples of those assumptions:

       All the computers, networks, applications, and people are available when you’re testing. (They won’t be.)

       You have all the proper testing tools. (When you start your testing — at least early on in your journey — you’ll be lucky to have half of what you actually end up needing.)

       The testing tools you use minimize your chances of crashing the systems you test. (Nope, especially if you don’t know how to use them properly.)

       You understand the likelihood that you’re going to overlook something. (You will.)

       You know the risks of your tests. (The risks can be especially high when you don’t plan properly.)

      Document all assumptions and ensure all the right people are onboard. You won’t regret doing that.

Selecting Security Assessment Tools

      Which security assessment tools you need depend on the tests you’re going to run. You can perform some security tests with a pair of sneakers, a telephone, and a basic workstation on the network, but comprehensive testing is easier when you have good, dedicated tools.

      

The tools I discuss in this book aren’t malware, based on my knowledge of them. The tools and even their websites may be flagged as such by certain antimalware and web filtering software, but they’re not malware. For example, Metasploit is often flagged as malware when it’s a completely legitimate security testing tool. I cover only legitimate tools in this book, many of which I’ve used for years. If you experience trouble downloading, installing, or running the tools I cover in this book, consider configuring your system to allow them through or otherwise trust their execution. Keep in mind that I can’t make any promises. Use checksums where possible by comparing the original MD5 or SHA checksum with the one you get using a tool such as CheckSum Tool (http://sourceforge.net/projects/checksumtool). A criminal could always inject malicious code into the actual tools, so there’s no guarantee of security. You knew that anyway, right?

      

If you’re not sure what tools to use, fear not. Throughout this book, I introduce a wide variety of tools —free and commercial — that you can use to accomplish your tasks. Chapter 1 provides a list of commercial, freeware, and open-source tools. The appendix contains a comprehensive list of tools.

      It’s important to know what each tool can and can’t do, as well as how to use each one. I suggest reading the manual or help files. Unfortunately, some tools have limited documentation, which can be frustrating. You can search forums and post a message if you’re having trouble with a specific tool, and you may get some help.

      

Security vulnerability scanning and exploit tools can be hazardous to your network’s health. Be careful when you use them. Always make sure that you understand what they are capable of before you use them. Try your tools on test systems if you’re not sure how to use them. Even if you’re familiar with the tools, this precaution can prevent DoS conditions and data loss on your production systems.

      If you’re like me, you may despise some freeware and open-source security tools. Plenty of them have wasted hours or even days of my life that I’ll never get back. If these tools end up causing you more headaches than they’re worth or don’t do what you need them to do, consider purchasing commercial alternatives, which are often easier to use and typically generate much better reports. Some commercial tools are expensive, but their ease of use and functionality may justify the initial and ongoing costs. In most situations with security tools, you get what you pay for.

Chapter 4

      Hacking Methodology

      IN THIS CHAPTER

      

Examining steps for successful vulnerability and penetration testing

      

Gleaning information about your organization from the Internet

      

Scanning your network

      

Looking for vulnerabilities

      Before you dive headfirst into your security testing, it’s critical to have a methodology to work from. Vulnerability and penetration testing involves more than poking and prodding a system or network. Proven techniques can guide you along the hacking highway and ensure that you end up at the right destination. Using a methodology that supports your testing goals separates you from the amateurs. A methodology also helps ensure that you make the most of your time and effort.

Setting the Stage for Testing