Recently in security Category

on logging serial consoles.

| | Comments (7)

So every now and again a customer will complain of a crashing domain. Occasionally, it is an early sign of a hardware problem that I need to deal with, so I don't want to just ignore it.

Now, the problem is that like a physical server, once the domain has rebooted, most of the information about why it crashed is gone. (and what little is left is in /var/log on the guest, and as a general rule we don't like mucking around in the guest. that's your business, not ours.)

Now, on a physical server, we solve this by using a logging serial console. (I reccomend opengear if you have the money, and a used cyclades if you don't have money. the 'buddy system' (making one server the console server for the next, then the next server the console server for the first) usually requires adding usb serial dongles, but is even cheaper still, for installations with only a few servers. I personally like the IOgear brand usb -> serial dongles Fry's has.

I can turn on debug logging in xenconsoled and that will log the console for all domains to a file (one file for each domain) then I can use those logs to troubleshoot the problem. The thing is, apparently some people have privacy concerns with this, so I haven't done it yet.

Now, personally, I don't think serial consoles are that sensitive. I mean, it's common to leave terminals in data centers where passers by can see the output. They will allow me to see what program is crashing, which may be sensitive, and depending on how you have the thing configured, I can see when people log in and log out.

So, I have several options.

  1. I could leave it as is, continue to go back and fourth and guess if someone asks me why something crashed after a reboot
  2. I can log all consoles and delete the data once a week or once a month
  3. I can apply a patch to log some people's consoles and not others, and let the user decide

Obviously, option 2 makes my life a /whole lot/ easier. Option 3 is better than option 1, but it still means maintaining an out of tree xenconsoled (or pushing it upstream)

So a while back I bought a MandyLion brand password token from ThinkGeek.   The idea is that my brain simply can not remember an adequate number of secure passwords.   Now, in my personal business I try to minimize this by using keys and ssh-agent everywhere, but I do need to keep passwords for accounts hosted elsewhere.  (I can't, for instance, throw up a new vserver and run an interface to my bank.)   Also, I need to remember passwords for clients (all my entreprenurial activites are funded by my consulting activities)     And this token, while not all that secure, is worlds ahead of little bits of paper in my wallet. 

Well, I got the token several months ago.  I promptly imputed a few client passwords into it, and used it to generate secure passwords for some of my accounts.   The password input is pretty clumsy (for input, it's got five buttons total)  but it works, and without a computer.  Well, the thing comes with some windows management software.  A 'policy manager' they call it.  I figure I'd load it up and poke around. 

Well, while I'm fairly impressed with the design of the token itself, I can't say the same for the 'policy manager'  -  so I initialize the token and play around a bit.  Not much you can do, aside from inputing passwords on a real keyboard.  Easy, yeah.  But do you really think I'm going to trust  my passwords to a windows box?  right.    so the management software is kinda useless.  But the irritating thing is that I found I could no longer input passwords on the device.  I could generate random passwords, but I couldn't input passwords, which presented a problem, as I said that many of the passwords I have to remember are generated by someone else.    Re-initializing the token didn't fix this problem.

I e-mailed ThinkGeek about it, and they talked to MandyLion.   The advice I got back was "re-initialize the token"  -  I mean, what did I expect from a device with windows-only software?  

Anyhow, the other night I sat down and figured it out.  Here is how I managed to reset the thing back to factory defaults:

1. I re-initialized the token using the provided software (It still won't let me manually enter passwords at this point, but it clears any policy I had set with the windows software.)

2. from the 'View' menu, I simultaniously press the up and down arrows to get to the 'options' menu.   I press the center button, then I press the down arrow to get to the 'set locks?' option.  I press the center button. I press the down arrow until I get to 'shutout' option.  I press the center button.  Now, I press the down arrow until I get to the 'destroy' option, and I select it with the center button.    (I'm now in the 'set locks?' menu again) I scroll down to the 'attempts?' option.  I press the center button to select, then I scroll down to '3 tries'  and press the enter button to select.  I'm done here, so I use the left arrow to go up menus until I am logged out of the device.

3.  I enter the wrong access code more than 3 times, and the LCD says 'Destroy' for a while (less than a minute)   -   after  the screen goes blank, pressing the center button prompts me to select an access code.  The device appears to be back to factory defaults (I can both randomly generate passwords as well as entering them by hand.)

So  yeah.  my password thingr is working again.

About this Archive

This page is a archive of recent entries in the security category.

outage is the previous category.

tech support is the next category.

Find recent content on the main index or look in the archives to find all content.

June 2010: Monthly Archives