Hacking For Dummies. Kevin Beaver
Чтение книги онлайн.
Читать онлайн книгу Hacking For Dummies - Kevin Beaver страница 23
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
In the past, a lot of security assessment techniques involved manual processes. Now certain vulnerability scanners automate various tasks, from testing to reporting to remediation validation (the process of determining whether a vulnerability was fixed). Some vulnerability scanners can even help you take corrective actions. These tools allow you to focus more on performing the tests and less on the specific steps involved. Following a general