Check your SSH logs...

Cause everyone's trying to get in. From my home router logs...

Apr 19 07:47:30 unknown authpriv.warn dropbear[6815]: login attempt for nonexistent user from 202.96.50.240:41238

Apr 19 07:47:31 unknown authpriv.info dropbear[6815]: exit before auth: Disconnect received

Apr 19 07:47:31 unknown authpriv.info dropbear[6816]: Child connection from 202.96.50.240:42789

Apr 19 07:47:35 unknown authpriv.info dropbear[6816]: exit before auth (user 'root', 1 fails): Disconnect received

Apr 19 07:47:35 unknown authpriv.info dropbear[6817]: Child connection from 202.96.50.240:44292

Apr 19 07:47:38 unknown authpriv.info dropbear[6817]: exit before auth (user 'root', 1 fails): Disconnect received

Apr 19 07:47:39 unknown authpriv.info dropbear[6818]: Child connection from 202.96.50.240:45872

Apr 19 07:47:42 unknown authpriv.warn dropbear[6818]: login attempt for nonexistent user from 202.96.50.240:45872

Apr 19 07:47:43 unknown authpriv.info dropbear[6818]: exit before auth: Disconnect received

Apr 19 07:47:44 unknown authpriv.info dropbear[6819]: Child connection from 202.96.50.240:47601

Apr 19 07:47:47 unknown authpriv.warn dropbear[6819]: login attempt for nonexistent user from 202.96.50.240:47601

Apr 19 07:47:48 unknown authpriv.info dropbear[6819]: exit before auth: Disconnect received

Apr 19 07:47:51 unknown authpriv.info dropbear[6820]: Child connection from 202.96.50.240:49411

Apr 19 07:47:54 unknown authpriv.warn dropbear[6820]: login attempt for nonexistent user from 202.96.50.240:49411

Apr 19 07:47:55 unknown authpriv.info dropbear[6820]: exit before auth: Disconnect received

And this goes on for about 10 minutes.

Yet another reason not to use ATM cards...

As if you needed more reason not to use ATMs, now it's revealed even using a perfectly secure machine is still dangerous due to poor security practices on bank networks:

According to the payment-card industry, or PCI, standards for credit card transaction security, PIN numbers are supposed to be encrypted in transit, which should theoretically protect them if someone intercepts the data. The problem, however, is that a PIN must pass through multiple [Hardware Security Modules, HSMs] across multiple bank networks en route to the customer's bank. These HSMs are configured and managed differently, some by contractors not directly related to the bank. At every switching point, the PIN must be decrypted, then re-encrypted with the proper key for the next leg in its journey, which is itself encrypted under a master key that is generally stored in the module or in the module's application programming interface, or API.
"Essentially, the thief tricks the HSM into providing the encryption key," says Sartin. "This is possible due to poor configuration of the HSM or vulnerabilities created from having bloated functions on the device."
Sartin says HSMs need to be able to serve many types of customers in many countries where processing standards may be different from the U.S. As a result, the devices come with enabled functions that aren't needed and can be exploited by an intruder into working to defeat the device's security measures. Once a thief captures and decrypts one PIN block, it becomes trivial to decrypt others on a network.

To be fair, the article title is unnecessarily inflammatory since this doesn't involve cracking the actual PIN, but simply exploiting flaws in the design (no one is cracking crypto in this case). There is no legitimate cause for this type of problem nor a need to decrypt at various points in the network- it's kowtowing to backward compatibility concerns that is causing a problem like this.

Either way, though, it's time to think twice before putting my ATM card into the that sketchy gas station ATM. And use the credit card feature of your check-card if you have them. Refuting an ATM transaction is so much more difficult than a fraudulent credit card transaction.

TSP and Up(?)time

Okay, the TSP site is something that is reminiscent of the late 90's with regard to site design, but it's something that has been sufficiently functional for my needs. Apparently, however, their UI isn't the only thing that is a relic:

Three days of downtime for "system maintenance?" What would the reaction be if a commercial financial site (e.g. Scottrade, BoA, etc) were down for three days?

Viscosity, OpenVPN and DNS Priority

I wanted to change my DNS settings when connecting to an OpenVPN server using Viscosity. Using the resolv.conf and other methods didn't seem to have any effect, so I put together a solution that seems to work.

First, put these scutil commands into a file (we'll call it /usr/local/bin/changeDns.pref):

get State:/Network/Service/0/DNS

d.add ServerAddresses * 192.168.1.1 10.0.0.1

set State:/Network/Service/0/DNS

Notice that the ServerAddresses line has my DNS servers in order of priority. Change this to match your desired DNS resolution configuration. This settings will be automatically undone once the connection has been severed.

(Edit: The /Network/Service/0/DNS line is from my configuration, but it apparently varies between computers. You may need to run the scutil command list State:/Network/Service/[^/]+/DNS to find the name of your DNS service. Citation here.)

Now, we need to edit the /Applications/Viscosity.app/Contents/Resources/dnsupalt.py file (the script which is run when Viscosity connects). Put this after the nameservers and search_domains line:

#!/usr/bin/env python

# Viscosity DNS Support Script

# http://www.viscosityvpn.com

import os, re, sys

nameservers = []

search_domains = []

os.system("scutil < /usr/local/bin/changeDns.pref")

This tells scutil to run the file upon connection. Running scutil --dns after connecting shows that the DNS servers have been updated:

resolver #1

nameserver[0] : 192.168.1.1

nameserver[1] : 10.0.0.1

order : 200000

Disconnect and the system goes back to the DNS server offered by DHCP:

resolver #1

nameserver[0] : 10.0.0.1

order : 200000

Slingplayer for the iPhone

Count me in as "disappointed." I was really looking forward to using my iPhone to access my Slingbox when the mobile application came out (and had even convinced myself that the $30 would be worth it), but that's not a concern anymore since Sling has decided that they're arbitrarily removing support for non-pro devices. I miss the days when companies encouraged upgrading by adding features, not by simply deprecating their previous product line.

Dumb move on their part, but it's at least one less thing to waste money on.

Using google talk as a logging mechanism

So there's been an interesting side effect of using Jabber (specifically, Google Talk) to act an interface to the home automation system- logging. Google Talk allow for messages to be sent to offline contacts; these messages are saved and stored in the normal "Chat" dialog in the GMail interface. Since the automation system sends state notification to Google Talk, all of the messages are automatically archived in my account.

This is a nice little side effect. It provides a timestamp based on the browser's time zone and nearly ubiquitous access to the information. I also imagine that it'd be rather difficult to tamper with the timestamps. I now have a record of my garage door activity for the last several weeks (and indirect proof of my lack of a social life- I don't go out much apparently). My 9:30 Taco Bell run also will live in infamy.