Just found out that if you are running Windows 8 with the Hyper-V Platform installed, some important settings in your “Processor Power Management” section under Power Options go missing. This is because Hyper-V decides to keep your CPU clocked at 100%. This is obviously bad if you’re on a laptop, since your CPU will no longer clock itself down when not in use, and your battery will drain considerably faster. Unfortunately, the only way to re-enable power management for your CPU is to uninstall the Hyper-V Platform from the OS. More of a reason for me to keep using VMware then…

To set the timezone on a Server Core 2008 R2/2012, or any other version if you fancy CLI, use the following: TZUTIL /G to list the current timezone TZUTIL /L to list all available timezone settings TZUTIL /S “Central Standard Time” to set your timezone to CST as example Also useful is the w32tm tool to change settings around the Windows Time Service, such as setting up a manual NTP peer or forcing a time resync.

If you’re reading this, chances are that you just installed Windows Server 2012 in the recommended instance of Server Core, and upon boot, you get the nice little cmd.exe window but nothing else. Here’s how you get started using PowerShell cmdlets to configure it: Rename: Rename-Computer computername Reboot: Restart-Computer Configure an IP: New-NetIPAddress -IPAddress x.x.x.x -InterfaceAlias “Ethernet” -DefaultGateway x.x.x.x -AddressFamily IPv4 -PrefixLength 24 (or whatever your subnet mask is) Configure a DNS server: Set-DnsClientServerAddress -InterfaceAlias “Ethernet” -ServerAddresses x.x.x.x ...

So it has been a little over three months since I last posted, and having left off before starting to explain a simple WPA Enterprise implementation, I will now continue. I’ll assume you already have a Domain Controller setup with a Certification Authority, and Internet Authentication Service, since that will be the key around authenticating our users and computers.

Given that I’ve posted about the weaknesses of WEP, and how it can be easily cracked in about 15 minutes, I wanted to write about how to secure your corporate wireless environment and keep script kiddies out of your network. Most companies and wireless AP manufacturers started moving towards WPA-PSK as a default setting for wireless networks. Just recently I’ve learned (and tested) using tools such as coWPAtty to crack WPA-PSK networks that use TKIP and do a brute-force attack on the key. While this does not present such a huge security risk as using WEP does, it still opens the door for sites that use weak WPA keys. Since WPA is stronger, but they key can be the weak point now, is there a way to generate “dynamic” keys? better yet, to generate new keys for every single client station, every time they log on? ...

Just recently I’ve devoted my extra time to finding and implementing open-source alternatives for common proprietary business applications. So far I’ve had great success in getting the solutions up and running, and I’ve been nothing short of impressed on how much community support they receive. I will start writing comparisons on the Commercial VS. Open-Source solutions I’ve come across and tested, but for now i’ll simply list a few that i’ve been very happy with: ...

Pulling my hair out trying to figure out how to set the URI for Zenoss to work behind an Apache mod_proxy setup, I figured out the solution is to use a rewrite rule on the virtual host within Apache. Here’s the rule I’m using: RewriteEngine on RewriteRule ^/(.*) http://internalserver:8080/VirtualHostBase/http/externalserver:80/VirtualHostRoot/$1 [L,P] Of course, change “internalserver” and “externalserver” for your hosts, and “externalserver” should match your ServerName definition in the virtual host config.

We left off at sniffing the packets, but unless you can spare a whole week if trying to get access to a mostly inactive network, we’re going to need to generate some sort of traffic to speed things up. To do this, we are going to take advantage of packet injection, and only then we’ll see that Data counter jump up to a useable level. Let’s open another terminal, and run the command: ...

This is where it gets fun. In this part, we’ll set our wireless interface to monitor mode, and we’ll start sniffing some packets and dumping the captures into a file for further analysis. To start, we have to list the available wireless interfaces to the system. Hopefully your card is compatible and has a driver already loaded. Let’s fire up Konsole (a terminal application), which is the third icon from the bottom-left, and we’ll type: ...

It’s been long known that WEP is a very insecure wireless encryption protocol, and this is due to weak Initialization Vectors (IV) being used within. See, the engineers that designed the WEP protocol attempted to create a stronger encryption by adding a 24 bit IV to the cypher key that changes constantly, thus “eliminates” the repeated encryption of data with the same key over an over. The problem is, these IV’s are too short, and are periodically reused… which means that if we can sniff enough data over the air, and get the AP to reuse IV’s eventually, we can figure out the key. ...