The Substantially Similar Weblog

A few months ago, I blogged about a bad experience I had with U-Haul that indicated the company has serious systemic problems. A few weeks later, a U-Haul employee posted two pseudonymous responses to my critique, apparently not realizing that their U-Haul IP address would reveal the true author. For some reason, my “consumer complaint” blog entries tend to get high rankings in Google and attract poorly crafted rebuttals.

Just now, the entry received two more comments. Both are from the same IP address, apparently again a U-Haul employee who didn’t realize their posts were easily traceable. I won’t respond specifically to these comments, but I thought it would be worth highlighting them here. I hope consumers (and perhaps U-Haul management) see these:

The first one is entitled “loved uhaul”:

all of you suck. i hate people like you. you see it’s people like you who actually hold there trucks up and mess up the schedule process. i moved 4 times with u-haul in the past year and only had a problem once but it was because people like you. you people who wanted to be given more time and not return it on time. while making a reservation over the phone i was told my move was being held up because a person tried to pull a trail that they were not supposted to causing it to overheat. these are trucks they do break-down, just like cars to. muck-mucks.

The second, “hey there” (remember, from the same author):

I’m a current U-Haul employee and I must say you’ve all had some really bad experiences with our company. It is very unfortunate, but really is venting out your problems really the answer? I’m responding to this very dim-witted website because I think your cause is in vain. We are the largest self-moving company in North America. While you may want to think that you’re hurting our business, your not. If anything you give us employees something to laugh about on our breaks. Hundreds of thousands of reservations our made throughout our thousands of locations everyday and we fill about 95%. For you unfortunate saps I petty you because when you get alate pick-up you can blame the person who had the truck ahead of you. Ask them why they felt like it was at their own leisure to bring the truck/trail back when ever they felt like it, to which every location they wanted to. Ask them whey they thought our trucks were built for speeding down highways or to move dirt or trash. We do and say things for a reason. And please don’t forget about all the good stuff we do like give free storage to families of hurricane victims or support various charities. So in the end, please keep up the log coming because we like reading them. Ha Ha Ha Ha.

Anyone who has a run a GNU/Linux server on the Internet for more than a few weeks has probably noticed that they will occasionally get “hammered” by a robot attempting to make an ssh connection using common usernames and passwords. Usually these are not truly “brute force” attacks—they try 20-30 times, rather than thousands—but either way they are annoying.

These attacks are rarely successful with a properly configured system, but they can use up bandwidth and system resources, and perhaps more troublesome is that they clog your log files so it is more difficult to detect a bona fide system attack. I suspect that at least some of these random ssh login attempts are accompanied by attacks on other known vulnerabilities, with the hope that the sysadmin won’t notice the more devious attack because the stupid attack is going on at the same time.

Strangely, there is no “canonical” solution to guarding against these attacks. A few people have written up their own hack solutions, and here is mine.

It’s called ssh_login_blocker. It’s very simple—just drop it in /etc/init.d and make symlinks to the proper /etc/rc?.d directories (or just start it running from the command line). It must be run as root. You can configure it to allow a certain number of bad passwords or bad usernames before it blocks an IP address. You can also configure it to “reset” the bad username/password count after a certain amount of time has passed. Just look at the first few lines of code and adjust the settings accordingly.

If you are running it on a system to which you don’t have physical access, you should whitelist at least one IP address where you will be able to get in from in case something goes awry.

• See the code
• Download it here

There are many improvements I’d like to make. For example, it should use libfile-tail-perl rather than running a shell for tail. It should have a “temporary blacklist” feature in addition to the current “permanent blacklist” feature. It should have an auto-whitelist function such that “known good” IP addresses get marked up. It should use something other than /etc/hosts.deny to block ip addresses—for example, iptables. It doesn’t do any of these things, but it works pretty well, and it makes me happy that my log files are not currently clogged with spurious login attempts.