Hello guys,
I was thinking that my host OS will be Backtrack 4 instead of Windows 7. The reason of choice is that it will ease al the scaning I will do (external net and VMs).
Do you think that this is a good ideea?
I have a couple of questions regarding this because I'm either more ADHD prone than I thought, confused, or your explanation/choice is a little off.
1) What difference does it make what the host OS will be. You state "ease al the scaning I will do" What kind of scanning are we talking about here?
Windows runs:
NMAP (Network)
Wikto (Webserver)
netcat (Cygwin is your friend)
Linux runs:
Same as above just s':Wikto:Nikto:g'
How does using Linux ease all your scanning? Unless there is some particular "scanning" that can ONLY be done on Linux that I'm unaware of, I fail to miss the overall goal here. You can mix and match however you want and still retain the same results. My current lab machine for the moment (due to moodswings) consists of the following:
Windows Vista HostBacktrack guest
Bitblaze guest (static malware analysis)
Debian (Exeros for those who've seen it on a video... It's a VoIP pentest customized distro I butchered together)
FreeBSD guest
Remnux guest (GREM coming next year)
SuSE guest (runs any CMS web based stuff I throw up)
TinyCore guest (mini butchered Backtrack like box I cobbled together fits nicely on a USB)
Debian guest (running my SIEM)
Windows 2003 Advanced, 2003 Enterprise, 7 Ultimate, 2008 server
Personally I don't see how ANY host makes a difference, you still have your virtualized guest to do whatever you want/need to do. Placement of "who's on first" does little as they ALL can accomplish the same things when you get down to it.
As for DVL, I choose to create and interact with labs that I create. This accomplishes more than just "fire and forget targetted" victims. By going through the motions of say getting Oracle's Beehive server up and running, I get to go through the motions as an administrator to understand how it's built, what it does, what makes it tick and how it interacts. Where it logs, WHAT does it log, HOW does it log and so on. Understanding this allows me to create a more granular attack canvas in which I can attack, watch and defend all in parallel.
For example, I'll create a simple goal and focus on it.
1) Windows server will run something from say PeopleSoft
a) Valuable insight is gained by going through the installation phase. I can throw on something like Snare on the Windows machine to write out to the SIEM to see how the attack would look. This helps me to understand not only how to defend against an attack, but how to tinker with variable to make me more covert. (Timing is everything)
b) There may be some tools ONLY available on Windows that I may choose to use.
c) I can fire up Wireshark or Omnipeek on the machine to see what the network stack looks like in the event I need to go back to say fuzzing, db hacking (SQL injection, etc.)
2) Linux machine will attack
a) Linux/BSD, doesn't matter to be quite honest. I can use them both equally and have metasploit running on FreeBSD and Windows as well to be honest, most of the times I won't need to even run metasploit unless I'm after a specific. Tools are tools are tools.
3) SIEM will store and correlate data while I'm attacking
a) SIEM is important to me (I use OSSIM for this by the way). In case I don't have a birds eye view 100% of the times, the information on my attack is recorded. I can go back into events and see what occurred in realtime as well. This again, allows me to defend, understand WHAT may trigger alarms. I can shoot Snare logs over to it and do some interesting stuff like "real world" intrusion prevention. This means, I can learn how to use another tool to defend against an attack: E.g. in brainlike-command-mode:
if this_attack_occurs
then login_to_machine_being_attacked && run_this_command_for_defense
else run_and_study_more
fi
Lessons learned? A lot more than I would by solely aiming tools at a pre-defined, vulnerable machine. Nothing to really be learned at the end of the day that is applicable. I don't mean this in a harsh way, I'd rather spend more time focused on a semi-real-world test. DVL may be good for the beginners, but I honestly feel that it gives an up-and-coming pentester false assurance.
It really isn't ALL about tools as it is more of an understanding. Did you know that outside of "human errors" server misconfigurations are the second cause of a compromise. Sure we can say "duh... server misconfig is a human error" However, what are you going to do if you don't even know where the configs are? Because I went through the process of installing ProgramX on a machine, I'd know to look for say a variable named "connectedhost" in:
/path/to/ProgramX/include/programx.conf
This saves me a lot of time in the long run and ensures I can get in and out quickly without setting off alarms trying to figure out what processes are running, whether or not a targeted application allows for hooking (WinDBG/Olly are your friends here). I think there is more to be gained in creating your own environment. After a few months/weeks/years, depending on one's capacity to understand and remember, it becomes easier. Create a game plan to understand, not one to fire and forget random tools without understanding how they work as a whole.
General Certification : Red Team/Blue Team
