mux

Regardless which route you take - no pun intended - I highly recommend you start reading up and learning about iptable's more advanced settings and configurations. You would be amazed how many different things you can do with iptables and most of these *nix router type distros definitely take advantage of it to some extent. EDIT: @Infiltrator I always found Untangle to be a massive resource hog. It ties up a lot of resources in it's full fledged GUI that other distros don't.

What I was getting at is that it would essentially allow you to run any combination of OS's (at the same time if you wanted) on the hardware instead of the OS itself. This means you could be owning it up in some game that hates WINE on Windows and then instantly switch back to a bash shell running a msfconsole rooting the gameserver. Clearly that isn't a very realistic scenario, but you get my point. Citrix uses good logic on the XenClient sales pitch where they explain how it's useful to run 2 completely seperate desktops (A business and a personal) on a single laptop.

I was always curious if there was anything at the hypervisor level that allowed you to have video output to a monitor (Maybe a few, but one step at a time :P) with the ability to toggle between different guests? I guess sort of like using a KVM switch (Keyboard, video, mouse, not KVM virtualization). I think a setup like this could really pave the way for power users in the future.

Jesus, that is huge. Hopefully that thing will start to calm the hell down once it hits land. Hopefully everyone will be alright.

What digip said. ^ This especially. One example I always give out is if someone is lucky enough to get a (meterpreter) shell on you after a 0-day release, all bets are off. It's pretty easy to not only kill processes at that point, but also easy enough to completely disable services as well. Even services that supposedly can't be disabled by default (ie; Most AVs). Setup a persistent backdoor, disable services, reboot if it's a Windows box, and the victim no longer has a firewall and/or AV running. The sky is the limit at this point.

I swear I saw a similar thread somewhere on the same subject. If you want to build an ESXi machine for personal use, check out: http://www.vm-help.com/esx40i/esx40_whitebox_HCL.php Don't forget that Darren is also using Proxmox. He also got a sweet deal on the CPUs and good prices on pretty much everything else from the sound of things.

You're all wrong. :P

Simple solution; Don't use Windows 7. ;)

I'm thoroughly confused how you guys think Comodo is a resource hog. I was running the CIS which is the firewall, av, ids, and sandbox rolled into one. When I did my baseline testing it averaged 22 MB of ram, but I digress. Sounds like you need to use *nix as your desktop OS, x942. :)

There are tons of WPA cracking videos out there. Capturing the 4 way handshake requires a client connected to the AP you're trying to crack. You then deauth that client while running airodump to capture it. Just search youtube for crack WPA.

For curiosity's sake, I am going to assume you are talking about 2WIREs? If so, then yes, their factory defaults are flawed and you're on the right track. Yes, they're great routers to (legally) test Cowpatty on. No, your math is wrong. First, if you're doing A-F and 0-9, think hex for your math. Second, your baseline for your key checks per minute looks like it is from a normal Cowpatty scan. I should clear something up right now by saying that Cowpatty isn't using rainbow tables, technically. It is more or less time memory tradeoff using similar concepts as rainbow tables, but I digress.The raw number of keys you will be able to check per second will depend entirely on how fast your machine is. I think Darren was doing around 10,000 keys per second with a 600mhz eeepc awhile back. So yes, it's really, really fast compared to just brute forcing it. What takes a long time is the actual generation of the hashfile. It may be ideal to bash script it if you have quite a few different SSID's to create hash files for. Quick tip: If you are planning to use this for other routers you may have laying around, I highly suggest you look at the following links for pre-generated hash files: http://www.hak5.org/forums/index.php?showtopic=12708 http://www.offensive-security.com/wpa-tables/ The difference between the two links are the wordlists they originally used to create the hash files. Church of Wifi used around 1mill or so words/combos. Offensive Security says they used around 49million. Do realize these aren't optimized for 2WIREs obviously, but they're a good start if you find that generating hash keys takes too long and your SSID is available on these pre-generated hashes.

In order to understand port forwarding a little better, let's approach the local and external levels of it. Essentially the basics generally work like this. Mind you, this is a really slimmed down, physically exhausted explanation of how it actually works: When you are running a service (Let's use Remote Desktop Protocol - RDP - since we're already on the topic) you generally have a local port attached to that service. Our computer running this service will differentiate packets inbound to our service instead of other services that may be running (Web server, FTP, POP3, etc) via the destination port. In this case the default for RDP is port 3389. Let's give our computer a local IP address of 192.168.0.5 so we can differentiate later on. So far we have determined that any packets inbound to our local IP address 192.168.0.5 with a destination port of 3389 is going to communicate with the RDP service it is running. Let's give this setup two practical examples now. You wish to connect to our XP workstation remotely using the remote service we setup using our Windows 7 machine that has an IP address of 192.168.0.3. We know that the XP machine is at the IP address of 192.168.0.5 and is using the default port of 3389. Using this information, we can now use the MSTSC to remotely connect to our Windows XP machine from our Windows 7 machine. Once we input the destination IP address (XP machine in this case), we click "connect". At this point what happens behind the scenes is your Windows 7 machine sends out a broadcast asking where 192.168.0.5 is and since this is our local network (and the demotext gods are nicer peoples than our demofail gods), our router knows the exact location and MAC address of our Win7 machine's packet. Once our packet is routed from the Win7 box to the XP box, the XP box now determines what the destination port is, whether that port is open or closed, and what to do with it (Think firewall and determining whether to accept, reject, or drop the packet). Since this is an unlikely perfect scenario, our XP box decides to accept the box and forward it to our remote service at our open port 3389. The XP box now sends an established packet back to our Win7. Please note that this is a really rough outline of how it actually works. This is just an overview of the basic concepts. Let's look at it from an internet/remote network view now. Since these are civilized times and technology is cheaper, lets assume we 100% for sure have a home router in our topology now. Our connection to the internet goes something like this: Win7 Box (Local IP address: 192.168.1.10) - Router (Public IP address: 77.77.77.77 - Internet - Inbound Firewall - Router (Public IP address: 66.66.66.66) - Outbound Firewall - XP Box (Local IP address: 192.168.0.5) Now, in this example you can see we have two firewalls. Both of these firewalls are actually 2 seperate rulesets in a single router, but let's imagine them being separate for now (Realistically, they are to packets). Same scenario as before except this time our Win7 box is using our public IP address (66.66.66.66 in this example) and our public port for our remote service is going to be 55555 to establish a remote desktop with our XP box. The public port can literally be anything outside of 1-1024 (or is it 1023?). This time the Win7 sends a broadcast request to it's router requesting where to find the IP address of 66.66.66.66 . This time, the local home router has no idea where the IP address of 66.66.66.66 is since it is not on our Win7's 192.168.1.0 subnet. However, it does know to send any unknown destination packets out to it's ISP's routers. Real magic happens accross the internet and the packet to establish a remote desktop with 66.66.66.66 is finally routed to our XP box's home router. Since we are good network administrators and expected traffic to be coming to our router from external sources (inbound), our inbound firewall accepts traffic on port 55555. Since we are really good administrators we remembered to port forward any traffic destined for port 55555 locally to port 3389 at our XP box's IP address 192.168.0.5 (We're awesome, aren't we?). The remainder is pretty much the same idea as above. As I said before, that is a really brief outline of what is actually happening behind the scenes. it should give you a decent idea if you understand our internet/remote network topology. Make sure you read it starting from left (XP Box) to right (Win7 box) or vice versa. Also be creative and imagine the hyphen's as 2 way streets for inbound and outbound network traffic. :) Out of curiosity, what is the exact command you are putting in command prompt? ie; ping x.x.x.x Where x's represent the IP address octets Honestly, I don't think most normal people look at subnetting their first time and only time and think to themselves, "Oh. Yeah, that makes complete since." Subnetting was pretty much like learning about something I hated. Then it literally just clicked and THEN I was like, "Oh. Yeah, that makes complete since. Man was I being dumb." Truly understanding how to subnet is a major building block on understanding networking in general. It's not the key to everything, but it's definitely a nice shim to have in your lockpicking set. Alright, that was a terrible analogy. I'll just go in my corner and hypothetically subnet an IP range for 10,000,000 clients.

Ok, let's backup for a minute. When you goto Start -> Right click "My Computer" -> Properties -> Remote tab. Is the following check box checked?: If it is, have you tried restarting the XP machine yet? If so, does your Microsoft Terminal Service Client (MSTSC) look like this?: (You can get all these extra options by clicking the "Options >>" button) Obviously, replace the IP address with the IP address of the Windows XP client you are trying to remote into. You don't necessarily need to enter the username and password at this point as Windows remote service will generally ask you for your login credentials the minute you remote in. You shouldn't have to worry about the domain name unless you have a domain controller (DC) setup on your network somewhere. Just leave it blank. If this is your home network and you don't know whether you have a DC or not, I would say you probably don't have one. You honestly should not have to be entering a domain name or host name anywhere. If you're still having issues after this and the machines can ping each other via their LAN IP addresses, then it sounds like a possible firewall issue.

You would need to port forward the RDP port on your router. You would then connect using your WAN interface's IP address (http://www.ipchicken.com). Canyousee will not find a port open on 3389 unless you are port forwarding it on your router or your machine is in a DMZ. Can you ping the XP machine from the Win7 machine and vice versa? If not, there is a networking issue. For the sake of saving myself and you a lot of typing and reading, I will provide a simple list: Class A: 10.0.0.0 netmask 255.0.0.0 Class B: 172.16.0.0 netmask 255.255.0.0 Class C: 192.168.0.0 netmask 255.255.255.0 Now, you're probably asking what the difference between a Class B and Class C is besides the first two numbers are, or octets as they are more commonly called. Subnets are a range of IP addresses defined by a subnet mask or netmask for short. If you want to learn more about subnets and networking in general, I highly recommend you take the time to read and study up a little bit more. Understanding subnetting is pretty much the big learning curve you need to get over as a beginner to networking. If you understand how to subnet properly, everything else falls into place when learning a lot of other networking theory and practices.

Or this for building a whitebox: http://www.vm-help.com/esx40i/esx40_whitebox_HCL.php EDIT: One other very important factor to look at with ESXi is NIC compatibility. Have fun trying to utilize ESXi without a working NIC. ;)