 |
|
| Networking Tips: |
|
|
|
Network security, lesson 3: Penetration testing
Firewall.cx
02.24.2004
Rating: -4.67- (out of 5)
|
Penetration testing is basically when you hire security consultants (or yourself) to exploit your network the way an attacker would do it, and report the results to you enumerating what holes were found, and how to fix them. It's basically breaking into your own network to see how others would do it.
While many administrators like to run quick probes and port scans on their systems, this is not a penetration test. A penetration tester will use a variety of specialized methods and tools from the underground to attempt to gain access to the network. Depending on what level of testing you have asked for, the tester may even go so far as to call up employees and try to social engineer their passwords out of them (social engineering involves fooling a mark into revealing information they should not reveal).
An example of social engineering could be an attacker pretending to be someone from the IT department and asking a user to reset his password. Penetration testing is probably the only honest way to figure out what security problems your network faces. It can be done by an administrator who is security aware, but it is usually better to pay an outside consultant who will do a more thorough job.
I find there's a lack of worthwhile information online about penetration testing -- nobody really goes about describing a good pen test, and what you should and shouldn't do. So I've hand picked a couple of good papers on the subject and then given you a list of my favorite tools and the way I like to perform a pen-test.
This is by no means the only way to do things -- it's like subnetting, everyone has their own method -- this is just a systematic approach that works very well as a set of guidelines. Depending on how much information you are given about the targets as well as what level of testing you're allowed to do, this method can be adapted.
Penetration testing resources
I consider the following works essential reading for anyone who is int
To continue reading for free, register below or login
To read more you must become a member of SearchNetworking.com
erested in performing pen-tests, whether for yourself or if you're planning a career in security:
Testing preparation
I don't like working from laptops unless it's absolutely imperative, like when you have to do a test from the inside. For the external tests I use a Windows XP machine with Cygwin (www.cygwin.com) and VMware (www.vmware.com). Most Linux exploits compile fine under cygwin; if they don't then I shove them into vmware where I have virtual machines of Red Hat, Mandrake and Win2k boxes. In case that doesn't work, the system also dual boots Red Hat 9. Often I'll just work everything out from there.
The advantage of using a Microsoft platform comes from the fact that 90% of your targets may be Microsoft systems. However, the flexibility under Linux is incomparable; it is truly the operating system (OS) of choice for any serious hacker, and as a result, for any serious security professional. There is no best OS for penetration testing -- it depends on what you need to test at a point in time. That's one of the main reasons for having so many different operating systems set up. You're very likely to be switching between them for different tasks.
[TABLE] |
|
If I don't have the option of using my own machine, I like to choose any Linux variant. I keep my pen-tests strictly to the network level. There is no social engineering involved or any real physical access testing other than basic server room security and workstation lockdown. (I don't go diving in dumpsters for passwords or scamming employees.)
I try as far as possible to determine the rules of engagement with an administrator or some other technically adept person with the right authorization, not someone at the corporate management level. This is very important because if you do something that ends up causing trouble on the network, it's going to make you look very unprofessional. It's always better to have it what you are allowed to do put clearly in writing.
I would recommend this even if you're an administrator conducting an in-house test. You can get fired just for scanning your own network if it's against your corporate policy. If you're an outside tester, offer to allow one of the company's IT people to be present for your testing. This is recommended because they will ultimately be fixing most of the problems you find. As in-house staff, they will be able to put the results of the test in perspective to the managers.
Penetration tools
I start by visiting the target Web site, running a whois, DNS zone transfer (if possible) and other regular techniques which are used to gather as much network and generic information about the target. I also like to pick up names and e-mail addresses of important people in the company -- the CEO, technical contacts, etc. You can even run a search in the newsgroups for @victim.com to see all the public news postings they have made. This is useful, because a lot of administrators frequent bulletin boards for help. All this information goes into a text file. Keeping notes is critically important -- it's very easy to forget some minor detail that you should include in your end report.
This is my collection of exploits in source and binary form. I sort them in subdirectories by operating system, then depending on how they attack - Remote / Local and then according to what they attack - BIND / SMTP / HTTP / FTP / SSH, etc. The binary filenames are arbitrary, but the source filenames instantly tell me the name of the exploit and the version of the software vulnerable. This is essential when you're short on time and you need to pick one. I don't include DoS or DDoS exploits. There isn't anyone I know who would authorize you to take down a production system. Don't do it -- and tell them so.
Presenting reports
This is the critical part -- it's about presenting what you found to people who probably don't understand a word of what your job is. You have to show them that there are some security problems in your network, and this is how serious they might be.
A lot of people end the pen-test after the scanning stage. Unless someone specifically tells me to do this, I believe it is important you exploit the system to at least level 1. This is important, because there is a very big difference between saying something is vulnerable and actually seeing that the vulnerability is executable. Also, when dealing with executives, saying, "I gained access to the server'" usually gets more attention than, "The server is vulnerable to blank."
After you're done, make a very detailed chronological report of everything you did, including which tools you used, what version they are, and anything else you did without using tools (i.e. SQL injection). Give gory technical details in annexes. Make sure the main document has an executive summary and lots of pie charts that they can understand. Try and include figures and statistics for whatever you can.
To cater to the administrators, provide a report for each host you tested and make sure you provide a link to a site with a patch or fix for every security hole that you point out. Try to provide a link to a site with detailed information about the hole, preferably bugtraq or some well-known source. Many administrators are very interested in these things and appreciate it.
[IMAGE]
Click over to Firewall.cx for more articles like this one. You don't have to register or jump through any hoops. All you do is get the networking information you want. Copyright 2004 Firewall.cx.
|
|
|
|
| TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations' technology projects - with its network of . |
|
| |
All Rights Reserved, , TechTarget |
|
|
|
|
