Gawker Media Account Database hack

I'm sure you have heard about the release of about 1.5 million username / password combinations (encrypted with DES). I have gotten e-mails from a few web companies saying that I should re-set my password. These companies include LinkedIn and Blizzard (for my World of Warcraft account).

Since my roommate didn't get an e-mail from Blizzard (as he doesn't have an account on any Gawker Media website) and I did, I can only assume that Blizzard downloaded the hacked account database and compared it to their account database. Any matches where to get this e-mail.

I honestly hope this is what happened and that Blizzard and LinkedIn didn't just randomly send out password reset e-mails. In this case the most responsible thing to do is download the file and cross reference it with your own data.

If you are wondering where you affected by this breach visit http://www.didigetgawkered.com/.

Yesterday I read both an Analysis of the hack and an Analysis of the Analysis. I am fairly certain that my password was unique in the database, but I do know that I used to use that password all over the place. A few months ago I started changing password and using KeePass to store them securely. I disagree with Wikidsystem's Analysis of the Analysis.

Yes, I was just as owned as the person using something insecure such as letmein or password. But the "owning" wasn't because of a weak password. Yes, I do have to copy and paste my passwords, but that doesn't make me a loser. I treat all of my online identities the same, as they are a representation of ME. The real losers are the ones that use any sort of username / password combinations on multiple sites. If you don't care that some sites might get hacked with the same username / password then fine, but I do. I want any potential fallout to be minimal.

Also, for things I truly care about, if a two-factor authentication mechanism is available I use it. The other thing more developers need to account for is LONGER passwords. My pseudo-random password generator generates long passwords, sometimes too long for an account. Please make the password field huge and don't store it in plain text. I hate having to cut down a password from 30+ characters to 8 because that is the longest your application will allow.

You see I don't care if my password is 30+ characters, because I don't need to remember it! Thats what I have KeePass for!

Enabling Promiscuous Mode on vSphere 4

We are in desperate need of a testing server. The testing server needs to be able to listen to the network, through port mirroring, to record VoIP calls. In the physical world this is no problem, but we don't have the budget for another physical box, especially for something as non-critical as testing a program upgrade (even though the program it self is very critical to our business).

A year ago the software vendor said that they don't support virtual environments and their product doesn't work in a virtual environment. During discussions this year however they told the truth that they simply don't know if it will work, and thus "don't support" it. I am calling it lazy. It doesn't take much these days to get a VM host going and configured for testing things out.

Well we have done the leg work for them. I have confirmed that vSphere does allow for promiscuous mode, even from the physical network. To be honest I was a little shocked to see this worked.

Here are the steps to enable promiscuous mode on your vSphere host and the guest VM.

1. Enable promiscuous mode on the virtual adapter.
   
2. Enable promiscuous mode on the vSwitch.
3. Enable promiscuous mode for the guest.
4. Enable port mirroring on the physical switch (not covered here).
5. Test capturing network data.

Now that we have the general synopsis of the procedure we can begin.

We enable promiscuous mode on the virtual adapter by logging into the vSphere Client, going to the VM Host, clicking on the "Configuration" tab, then on "Networking" in the "Hardware" section on the left. Now click on "Properties..." for the Virtual Switch.


Now enabling promiscuous mode on the vSwitch is pretty simple. Click on the "vSwitch" on the "Ports" tab, as shown below and then click on the "Edit..." button.



Now that we are editing the vSwitch properties click on the "Security" tab. Change the option for Promiscuous mode to "Accept" if it isn't already and hit "OK".


To enable promiscuous mode for the guest we need to break down to the command line. I used putty to SSH into my vSphere host, which I had previously setup. Now you need to edit the .vmx file of the guest that will be listening to the network.

# vi /vmfs/volumes/datastore1/testServer/testServer.vmx

I did a search for ethernet, so the promiscuous mode configuration would be with the rest of the ethernet config. Add the following line to the configuration file:

ethernet0.noPromisc = "FALSE"



And save when you are done. I rebooted my testServer just as a precaution, but I'm not certain it is required.

At this point everything is configured on the VM side of things. Make sure you have port mirroring enabled on your physical switch and give it a test. In my environment I commonly use Wireshark. I did my testing by pinging a server on a mirrored port.

Using PSExec to Defragment your PCs

Way back in 2000 / 2001 I was an IT intern. My job was to do the really manual processes for a small department with in a much larger company. One of those was monthly defrags of all PCs and Laptops (if they where available). I had to go to each and every PC, log on, and start the defrag process manually. I believe this to be my first moment of "I should automate this". Problem was I didn't know how or really where to start. I knew script was the answer, but just couldn't get things to work. I believe I eventually created a scheduled task on each machine (by hand) to do this for us.

Fast forward 10 years and I am still in need of the same thing, as we don't have Vista or Windows 7 deployed. But now I have a much better understanding of what needs to happen and even better I know where to start!

PSExec, which is part of the System Internals PsTools suite is my answer these days. A simple script, run from my PC (still manually for the time being) is able to handle defragmenting all of our PCs.

psexec @C:\Updates\Comps\AppPCs.txt -n 10 -c -f -d JkDefragCMD.exe

I use the files with PC names to speed up re-deployment of everything. The -n 10 flag tells psexec t0 wait 10 seconds before it times out the PC, instead of 60 (I believe this is the default). -c copies the file (jkdefragcmd.exe) to the remote system. The flag -f forces copying, even if the file exists. The flag -d doesn't wait for the process to terminate, this is as asynchronously as I can do.

My next step is to hook this up to task scheduler and have it run the first Sunday or something.

Documentation, not always the How To Dos

Documentation for me is often just How to do something, but I have been forgetting the WHY part of the equation. For instance, my documentation says to do our weekly maintenance window after 21:30 and to only reboot one particular server after 21:45, but I didn't say why and had forgotten myself. So I started doing the maintenance earlier and at one point rebooted the one particular server at 21:30. This caused the last of our production cron jobs to not run, and thus a customer didn't get their batch for the day.

Now this could have been avoided a few different ways. Since that first time was a mistake any thing that happens after it is a failure on my part, and thus can't happen again.

1. I could have followed our procedure to the T.
2. Read my e-mail to see that the cron job hadn't run yet.
3. Run the cron job by hand after the server restart.
4. Did all of the precursor work and waited for the cron job to run.
5. Did all of the precursor work and run the cron job by hand.

I have chosen to go with option 1, follow our procedure to the T. We started doing the weekly maintenance for a few reasons and it was to be done after 9:30, with that one particular server last to ensure this didn't happen. Now once again I have my WHY, and I have it written down so if I question it again I know why.


This is just one instance where the WHY is critical, but there are others. So please when you are writing documentation, and you should be please include the WHY you do something the way you do it. It also helps train the new guy, or your replacement.

Enabling the Administrator user in Windows 7

This is a very simple fix. The reasons to actually log on as the administrator are shrinking, but for my environment I need to log on as the Administrator user occasionally (for software patching).

1. Open up a command prompt as Administrator (not the same thing we are trying to do)
2. Run "net user /active:yes administrator"
3. Now it is a great idea to set a password for the Administrator user so we can do that right now
4. Run "net user administrator password" but replace password with something more complex similar to "Som3C0mpl3xP@$$w0rd"
5. Exit out of the command prompt.

For my situation I need to run commands as the Administrator user on other machines and need the Administrator shell. I did a lot of testing to make sure that the "Run as Administrator" doesn't work as I need.

Enabling Ping responses in Windows 7

Out of the box if you Ping a Windows 7 host you will recieve "Request Timed Out". This is because the Windows 7 firewall is blocking ICMP echo requests. If this is causing you problems and you need to open up access to ping requests it is fairly simple.

1. Go to the "Windows Firewall" in the Control Panel.
2. On the left hand side click "Advanced Settings"
3. Click on "Inbound Rules"
4. Right click on "Inbound Rules" and choose "New Rule"
5. Select "Custom (Custom Rule)" and press "Next"
6. Select the (default) "All Programs" and press "Next"
7. Change the Protocol type from "Any" to "ICMPv4"
8. Unless you want to restrict the ping response choose the option "Any IP address". (This is for your adapter.)
9. Unless you want to restrict which hosts can ping you choose "Any IP address".
10. On the Action screen ensure it is an "Allowed" connection.
11. Leave all three check boxes check on the Profile screen.
12. On the final screen, Name, give it a meaningful name such as "Echo Ping Request"
13. Finally click finish.
    

How to Reset the Password(s) on a Linksys SRW248G4 Switch

1. Connect to the Serial port on the back of the switch with a serial cable. (Putty on Windows works well)
2. The defaults for connecting to the serial port are 38400 baud, 8 data bits, no parity, 1 stop bit, no flow control.
3. Confirm that you have an active serial connection by pressing enter a couple of times. You should receive a login screen
4. Once you have successfully connected to the serial port restart the switch by unplugging the power. (Either from back or from the power strip, my preferred method is the back)
5. The switch will start its POST process.
6. Look for the line “Autoboot in 2 seconds - press RETURN or Esc. to abort and enter prom.” (Please note: Do not hold down Esc. or Enter. Only press it once.)
7. You will know that you interrupted the boot sequence when you are prompted with a startup menu. Select option 3 “Password Recovery Procedure”.
8. The screen will display “The current password will be ignored!”. Press Enter to reboot the switch.
9. Once the switch has restarted login with the default admin user and no password. This will work on either the terminal or the web interface. Proceed to create / modify users and passwords. This does not reset the rest of the configuration, just user accounts.
10. Once you have your new credentials reboot the switch again. Document the credentials.
11. Verify that your new credentials work by logging into either the web interface for the command line interface.
12. Disconnect the cable and store it safely.

This is the second time I have required these instructions, so I am posting them here for safe keeping. The last time I did this I removed the default account and setup individual accounts, and then promptly forgot everything about it. This is why documentation is so critical.