I ain't lyin'

When the Proxy List came back online in May, I added this little warning...

Times have changed, little ones. You cannot hide. By using a proxy you attract the attention of Powerful Forces™. The consequences will never be the same.

Recent events have shown this to be Sage Advice. They may try to convince you they're hiding your ass, but when the chips are down, they'll cover their own ass first.

It's your ass or their's and you will lose every time.

The Amazing, Disappearing SSID, Part II

The replacement access point arrived yesterday. I set it up identically to the old AP. I rewrote my kidscript to work with the new AP's Web interface, rebooting it when iwlist can't find the SSID anymore.

It's been up for slightly more than 24 hours now.

In that time, the SSID has dropped seven times. We can now conclude that either a) there was nothing wrong with the original AP, or b) that both APs suffer from the same, mysterious denial of service (DoS) vulnerability.

Whatever that may be.

But it got me to thinking about the timing of this thing, which started some time in August. Then it finally dawned on me...

The HP Printer Driver From HELL!

You might recall, when trying to install this Pile Of Crap over the WiFi network, the driver setup program would say "Testing network connectivity..." and then kill the wireless connection every time.

I had the driver installed in two places: my laptop, and the XP desktop I recently retired. I never installed it on my new Windows 7 box, and I only use the laptop occasionally. Now, the driver is no longer on either side of the AP, but of course the printer still exists on the wireless side.

And up until about 6PM this evening it was on 24x7 during this entire fiasco. Not anymore.

I believe—but can't prove—the printer may run it's own code to "test network connectivity" in the same way the driver setup did. Why? I can only speculate, but HP does want to entice you to buy consumables—ink and paper—directly from them. Either the driver polls the printer or the printer notifies the driver or both. I'm inclined to believe "both". Ink alone is a cash cow and HP wouldn't want to miss the chance to make a sale, popping up a dialog box when you're trying to play UT (this has in fact happened to me at least once on the old XP box).

That would explain everything nicely.

And further confirm my personal opinion that "HP" stands for "Horse Poop".

SSID: "XDA-Wifi-Sharing"

So my analysis of my Wacky WiFi access point continues while I wait for the new one to arrive. I watched it drop about three times so far today, with the same results on the airodump-ng screen: my AP disappears and a dozen other SSIDs disappear as well. It comes back up and so do the missing APs. All the novelty is gone. It just happens now. It's almost predictable, but not quite.

But a new AP showed up out of the blue, with the SSID "XDA-Wifi-Sharing". Google took all the mystery out of that. It's some kind of WiFi router for your smart phone that sets up an Ad Hoc connection you can attach other devices to. Nice trick. I've done it myself, but don't see the point for dedicated software, although it does make a lot of sense as a phone app.

OK, fine. But according to airodump's analysis of the power this thing was putting out, it was in my freakin' house!

Then, as quick as it appeared, it disappeared. Then, my AP dropped out of site, too. Of course, my kidscript kicked in and brought it back, but still...

Coincidence? Maybe. This just keeps getting weirder.

GoDaddy DNS Issues Finally Explained?

It's all water under the bridge now, but I just ran across this link in the outages mailing list.

Most of my original complaints about GoDaddy DNS were on the old ProxyObsession blog, so you may have missed it. What it came down to was I couldn't resolve my own domain name from home, but I could resolve it from anywhere else. GoDaddy finally fixed it but then that whole DMCA nastiness hit the fan and I was outtathere for good. Never looked back.

So... check it out...

What seems more likely is that the new owners of GoDaddy are trying to improve on the "Premium DNS" service, which appears to have been a failure. The Premium DNS service started around January, 2011. However, it appears not to be meeting their sales goals (99% of domains using GoDaddy DNS hosting are still using the free service)... We now know that GoDaddy is willing to block DNS queries. Will it continue, or will others follow? What will happen to the Internet if all DNS hosting companies follow the same path? Only time will tell.

That explains a lot.

The Amazing, Disappearing SSID

Lately, after running dependably for several years, my wireless access point has started to disappear from the airwaves.

Firmware upgrade? Got it, no luck. I went from rev 1.0 (2006) to rev 2.12 (2009) with the same issue.

Here's an odd side effect: while troubleshooting this problem, I've been running airodump-ng on a wired PC. Normally I can "see" ~16 access points. When my access point dies, it takes about a dozen with it. When I bounce it, they all come back.

WTF is up with that? It's probably no big mystery. I'm assuming that the radio pulse from my access point coming back online somehow boosts the sensitivity of the NIC running airodump, but it's a strange process to watch.

I have responded to this by writing a kidscript that runs iwlist on another PC. If it finds that the SSID is not being broadcasted, it runs a quickie curl one-liner that presses the "Apply" button on the "Advanced Settings" page of the access point's Web config, which acts like a soft reboot. The process repeats every ten minutes with a cron job.

This is entirely unacceptable! In the past I've had laptops connected wirelessly for days without interruption. On version 1.0 of the firmware!

Since it's seen Better Days, I have to assume it may just be going bad, although in my testing I have made it fail reliably at definite intervals (long story). With that in mind, I've ordered a replacement. If that one works, great.

If not, then there must be a mystery somewhere.

I hate mysteries.

PowerDNS 3.0

PowerDNS 3.0 came out in May of this year and I've been fucking around with it ever since, in between other things like the PoTTY upgrade, those crazy Chinese proxies, and replacing hardware on DinkNet.

I started running pdns in February of 2009 after my jerkwater ISP started "improving my online experience" by hijacking DNS requests. Two years later I got on IPv6 through Hurricane Electric, but pdns 2.x couldn't handle it—or DNSSEC for that matter—so an upgrade was inevitable.

Unfortunately, building pdns and pdns-recursor from scratch is an incredible pain in the ass. Sure, there are packaged binaries available, but I'm dealing with an older platform (Debian 4) that can't meet the prereqs.

One of those prereqs is Boost version 1.35 or greater. Boost is a collection of fast-as-fuck C++ libraries. Or so they say. The PowerDNS people are Boost believers. Building it isn't too bad, but you have to forget everything you know about building from source.

But wait... according to the pdns-recursor docs...

You only need to download it, there is no need to compile.

This is absolutely, 100% TRUE. Well... 99% true. After you download it, you need to extract it (details!). After that all you need is a CXXFLAGS variable pointing to the source.

Quick and easy. For the recursor. Not so for the pdns authoritative server. You'll need to compile and install the libraries. Sucks to be you.

Once you realize and accept that Boost isn't "normal", compiling and installing it is easy. You run "./bootstrap.sh" and then "./b2 install" (or "./bjam install", depending on the version).

Aside from being Boost evangelists, the PowerDNS people also adore Lua. There's a lot of that going around lately. You'll need version 5.1 and the development libraries. Lucky for me, 5.1 was current way back when Debian 4 came out, so I only had to install the packages.

After that, building pdns is relatively simple. For me, pdns has a lot more functionality than I actually want. And what I want is a caching-only slave server. I don't have any domains to be authoritative for. Everything on the inside is in the .local multicastdns domain, which is served up by Bonjour and avahi.

PowerDNS supports a number of database backends for holding authoritative data. Or, you can just use bind-like data files (pdns was originally designed as a drop-in replacement for bind).

So when you run ./configure, use --with-modules="" not --with-modules="bind", because it won't know what the fuck you're talking about.

After finally getting pdns to compile—I already had the v3 recursor installed—I decided to do some testing. This turned out to be difficult with version 2 running at the same time. At this point I realized I probably needed two DNS servers anyway, so I took my "lessons learned" and built another pdns server and recursor on Experimental V. Plus Boost. Plus Lua.

Testing was silly. One of the variables in the config file—which can only be named "pdns.conf" no matter how badly you want to change it—is called "config-dir" and it specifies the path to pdns.conf.

Think about that for two seconds and you'll realize the profound silliness of putting the path to the config file inside the config file itself. What is the point? How does it use a path in a file it can't find?

Here's a clue... check the manual page! DAMN! It's dated December 2002!

It's shit like this...

Once you get around obvious crap like that (use the --config-dir command line option) testing should go fine, and it did. After pdns was running on EXP V, I took my second round of lessons learned back to BOT House, where pdns 2.9 was running, and finally upgraded it to 3.0.

The final touch on the upgrade was to take Hurricane Electric's IPv6 DNS sever out of radvd.conf and put my own in.

When both servers were up and running, I had a sublime issue with DNSSEC. One server could retrieve dnssec records, but the other couldn't. After staring at both configs for an hour it came down to a setting in the recursor config called "query-local-address", which is the IPv4 address the recursor uses for sending recursive queries out to the Internet. It was set to "0.0.0.0" by default. After changing that to the server's "real" (RFC1918) IPv4 address, there were no more issues with DNSSEC.

One minor issue remains: I can't get pdns to listen on the link local fe80::/10 address of either server. I works fine on the yes-I-know-it's-deprecated site local fec0::/10 addresses, as it does on the global IPv6 addresses (yes, since they only service the inside network they're firewalled).

In the end, it was way too much work.

awmproxy.com

There's a lot of buzz lately about the guy who runs/ran awmproxy.com as being the "kingpin" behind the TDSS botnet, which was the bug responsible for all those port 27977 SOCKS proxies.

Not surprisingly, I used to scrape that site all the time, from the Fall of 2008 until early Winter 2010. According to the Krebs article, awmproxy started offering up proxies on March 16, 2008 which is—coincidentally—the day after I started the proxy project.

That site, as it existed back then at least, seemed like a typical proxy-for-pay scam, selling you a list of proxies you could get for nothing on your own. In fact, they had a slightly insecure way of passing out proxies to their paying customers. I stumbled across their "secret URL" with a random Google search and scraped thousands of good proxies every day throughout that whole time period.

Maybe they changed hands since then, but if you look at their offerings, they have never advertised port 27977 proxies. Compare this Google search to this one. Do the same search on the .net site and you'll find there are none there, either. But you will find the standard ports listed.

Sure, they're conspicuous by their absence, but every proxy lister and his brother had port 27977 proxies in their lists over the past year, so the advertising value alone would be worth listing them. Here are my numbers:

As you can see, they're gone now.

So why finger the only site that wasn't advertising these proxies?

Some consider Firefox plug-in to be a smoking gun, but it seems like a logical offering for a proxy provider. In fact, it's still available. I don't see how this plug-in would be valuable to a "bot" and would love to see someone evaluate the code and prove that it's inherently malicious.

Of course, there's no way in Hell I'd install it.

I don't want to appear to be an apologist or a defender of cybercriminals, but I'll be on the sidelines watching this drama pan out.

"subrepticious"

About 3,870 results.

Srsly?

UPDATE: 09/05/2011

I now have the #1 Google hit for this silly non-word. However, when searching for it, I spelled it right and discovered "subreptitious" is a real adjective derived from from the noun "subreption", which means:

1. A calculated misrepresentation through concealment of the facts.
2. An inference drawn from such a misrepresentation.

I did not know that.

Neither did the guy who wrote "subrepticiously" when he meant "surreptitiously".

You learn something new every day. If not, you're doing it wrong.