As previously mentioned, I’m headed to SIGGRAPH in August. The pre-con report is now up on the GPF Shows & Cons site and, as usual, will become the core place for news and updates about my trip there. (I’ll probably end up mentioning the same stuff here as well, but that’s the official place to look.)
It occurred to me yesterday while I was writing up a News item for Monday that SIGGRAPH may–or may not–be a good place to hold a key signing party. For those unfamiliar with public-key cryptography, this is a gathering where PKC users can verify each other’s identities, prove you are who you say you are, and obtain signatures on your public key. This increases your perceived level of trust; the more signatures you have on your public key, the more people who say they have verified your identity and thus the more trustworthy your own signature becomes. This “web of trust” is the core to PKC; without it, anyone could create a key and say they’re somebody else and there wouldn’t be an easy way to prove otherwise.
I said it may be a good place for a key signing because there will be a lot of computer professionals there. It might not be a good place because most of those computer professionals are more involved with graphics than with cryptography (which is ironic because both require a great deal of mathematical knowledge). Thus, I’m not sure if I’ll be able to find anyone there willing to sign my keys or not. My public key has a pitiful few number of signatures, mostly because I haven’t been able to meet face-to-face with like-minded cryptography nuts to add any. I’ve searched and searched and have yet to come up with anything in this vein officially or unofficially attached to SIGGRAPH.
So here’s a two-pronged appeal. First, if anyone does know of an official or unofficial key signing event somehow attached to SIGGRAPH or that might be going on in the area during that week, please let me know the details so I can somehow get involved. If there isn’t one going on, I’d love to see one organized. I’d consider organizing it myself if it weren’t for the fact that I’m not from San Diego and I don’t have a clue about where would be the best place to hold such an event, let alone how to get the word out. I’ve put my entry up on BigLumber’s San Diego listing in hopes that someone might see it, and at least one San Diego resident has expressed interest. If someone else might take the initiative to get things started, I’d be more than willing to promote it on the GPF site.
Last night, I was working on one part of implementing the GPF update changes previously mentioned. Since I’ve been having some trouble getting a response from the Keen Tech Crew (who I assume have been as busy with real life things as I have), I decided to try and implement a backup plan in case they couldn’t get their part done by Monday. It’s all rather technical… but then you guys probably enjoy reading my technical ramblings from time to time. (Either that, or you ignore the Technology category altogether. Take your pick.) Unfortunately, it involves some intimate knowledge of Keenspot’s update mechanism, Autokeen, which most of you probably don’t have.
Long story short, Autokeen uses templates that are parsed by a massive Perl script that replaces certain “tags” with actual content. For example, the tag ***todays_comics*** gets replaced with the necessary HTML to display any images or text that have been designated as “comic” files. This obviously includes the images for the dailyweekly strip, but it can also use text and even Flash. The GPF News is treated as a “comic” by Autokeen, even though it’s all text. Unfortunately, while there can be multiple “comics” under one account (for GPF, they include the main comic, the News, the Sketchbook, the High-Def archive, and a few others), the way these templates are used means that each “comic” is pretty much autonomous and self-contained. There are ways to get cross-comic content (like how I get the most recent News date and blurb automatically on the main and High-Def pages), but it’s definitely not trivial and it stretches Autokeen’s capabilities beyond their original intended functions. Autokeen is incredibly flexible, which is a credit to Darren Bleuel’s design, but you can tell when you’ve taken it places it’s never been before.
Anyhoo, I was building a Perl script that would be run on a cron to do some of this cross-comic work for me, just in case my original pure-Autokeen design didn’t work as expected. I was connected to the GPF server via SSH, editing the file directly on the server via vi. I tested it pretty thoroughly and was happy with the results. By this point, it was getting late, Ben was already asleep in my wife’s arms, and we were both ready to go to bed. I shut down the laptop, we took Ben back to his crib, and while she brushed her teeth and performed other nighttime preparations, I climbed into bed.
It was then that I realized I had a fatal flaw in my code. (Nobody ever said inspiration was either punctual or convenient.) While it would successfully build some symbolic links on Monday, Wednesday, and Friday, I forgot to limit the code that removes the symbolic links on the other days of the week. Thus, every Tuesday, Thursday, and Saturday it would undo all the changes it made the days before. It was getting late and I had to get up early in the morning to head off to work. I didn’t have time to fire up the laptop again and I didn’t want to go into the office to log into one of those machines and leave my sweetie waiting up for me.
I grabbed my LifeDrive and fired up its WiFi connection. I have a small SSH client for Palm OS called pssh and used it to log into the GPF server. Now pssh is a wonderful little tool, but anyone who has used a PDA probably knows that entering text into one can sometimes be… challenging. Palm has used Graffiti for years, but it can sometimes be a pain when working with applications that are very sensitive to text input mistakes (such as, say, vi). I elected to use the on-screen keyboard instead, and only switched to Graffiti when I discovered the keyboard didn’t have a pipe symbol (required to do a boolean “or” condition). Switching back and forth between edit and command modes was <sarcasm>fun</sarcasm>, even though pssh includes a nice little “ESC” button on the screen for emulating the Escape key. Old hands at vi will know you can always hit ESC multiple times to ensure you’re no longer in edit mode and that you’re back in command mode, but it seems I left the volume on the Palm up pretty high from listening to MP3s earlier. The default “bell” was embarrassing loud, especially with a sleeping baby lying a few feet away.
It took some work, but I finally got the changes incorporated and saved and compiled the script. As soon as I logged off, I realized just out absurdly geeky the entire experience was. I probably could have done things faster if I had just walked into the office across the hall and fired up PuTTY, but instead I decided to do things the hard way: working on a tiny little battery-powered device, connecting wirelessly, and fumbling with awkward text input mechanisms to use what is arguably one of the most complex text editors to make what would have been a ten-second change anywhere else. For some reason I found that obscenely amusing. You could probably care less, I’m sure, but I thought I’d share anyway.
In addition to switching blog software, I’ve been quietly making a few other changes on my little Linux box lately. For one thing, I’m changing the authentication scheme for SSH from simple passwords to public key authentication. Only a few friends and family have direct access to my Linux box, so it only affects a few people. However, given recent events, I feel somewhat justified in ramping up my security.
On the off chance you might have read this into the above statement, no, my network hasn’t been hacked. No advance GPF strips or story notes have been swiped from my hard drives. (Somehow, I detect a definite sense of mixed feelings from some of you, including relief and disappointment….) But my oh my, have they been trying. Not that I think it’s a directed attack by any means, but I have had a number of break-in attempts over the past few months, and they seem to escalate frequently.
Like I’m sure many Linux admins do, I run logwatch daily. (Actually, it seems to come pretty standard with an install of Fedora Core, but if I ever switch distros I’ll make sure to install it if it’s not a default.) logwatch runs through most of your system logs and generates a single, combined report summarizing the health and status of your computer and plants an e-mail in your root mail inbox every morning. It covers just about everything, from crons, Web and FTP logs (especially errors), mail, system messages, automatic updates, and (especially for the topic of this article) security logs. It was because of logwatch that I discovered that Demeter’s hard drive was failing last year and had to be replaced (more SMART failures, surprisingly undocumented either here or in the GPF News, and completely unrelated to Apollo’s crash; last year was not a good hard drive year for me). It’s through logwatch that I watch various IIS-targeted worms periodically bounce harmlessly off of Apache (which I take a small dose of perverse pleasure in). And it’s through logwatch that I sit nervously and watch the almost daily hack attempts to break into my system.
Having any computer on the Internet is a dangerous thing these days. I certainly don’t want to alarm the less tech-savvy of you out there (the last thing I want is to discourage people from getting online), but any computer connected to the Internet is under a constant barrage of probes and pings. Most of these are harmless and often routine, but a growing number of them are malicious. Hackers are constantly scanning the Net for connected systems that may have vulnerabilities that can be exploited. Over the years I’ve grown more and more curious about Internet security, and I’m finding myself get more and more paranoid about how insecure much of the Internet really is.
Having a server on the Net is just asking for trouble. They are under a constant assault, being poked and prodded from all sides and on every port. Most regular users have a small amount of anonymity through the dynamic IPs of their ISP. Servers, on the other hand, are meant to be found, waiting for requests (as their very name states) to serve. By their very nature they advertise themselves with domain names saying, “Here I am! I’m here to help you.” Being so public, they make themselves more visible to attack. While some black hat hackers target specific hosts looking for various bits of sensitive personal or corporate information, most of these hacks are actually pretty casual: simple probes looking for any random vulnerable system that can be broken into. Perhaps they may find something useful to exploit, like financial information or blackmail material. But my theory is that they are mostly looking for new weapons to add to their arsenal, additional zombies to add to their growing botnet collection.
Virtually every day, my logwatch report comes up with at least several hundred break-in attempts via SSH. On especially nasty days, the attacks can range in the thousands. Gaining access via SSH is more advantageous than other means, as it gives you direct command-line access to the system which is also encrypted end-to-end, preventing eavesdropping by anyone in the middle. Needless to say, unencrypted telnet is completely disabled on my system.
The good news for me, at least, is that I’ve taken quite a few precautions to prevent these break-ins. The first and probably most important step is to prevent root from logging in via SSH. In order to gain root access, an attacker must first compromise another login, requiring them to break two passwords instead of just one. This adds an extra step for me when it comes to my admin duties, but that’s an extra step I’m definitely willing to make. I’ve also limited which logins can access SSH to a specific group, into which are placed only users that I want to explicitly grant such access. This greatly reduces the number of available logins that can be compromised. (Most of these attacks try various combinations of common user names, so odds are they have no clue what user names may exist on the machine.) The next big step, though, is to require public-key authentication. This means that those with console access not only need a password but a digital private key, and only the combination of the two will allow someone in. This is the form of authentication SourceForge uses for access to their build and test environments, and it’s probably the most secure method freely available (usually implemented via OpenSSH).
Setting up GnuPG keys, securely wiping old hard drives, and now locking down my Linux box with strong-grade encryption… I’m quite the paranoid little thing, now aren’t I? Does everyone get this paranoid in their old age, or is it just me? If you know the answer, you know where my public key is….
Edit April 2, 2007: I tried to make a follow-up comment to this, but that obviously didn’t work. So I’ll just edit this post to include a link to this analysis malicious SSH login attempts article I just found. It made my flesh crawl a little. In addition, check out the following Linux.Com articles on beefing up SSH security. Thankfully, I’ve already discovered that I’m doing most of these tricks already, which made me feel just a tiny bit more secure.
I decided to try something new yesterday. While researching something else, I ended up following a link or two and wound up at the GNU Privacy Guard (or GnuPG or GPG for short) website. GnuPG is, of course, the GPL replacement for PGP, the program that brought public-key cryptography to the desktop.
I toyed around with PGP a while back, but never did much with it. At the time, my current mail client (Eudora) didn’t integrate well (i.e., at all) with PGP, and I was unwilling to upgrade my ancient version to the newest one because it had turned into “ad-ware” (which means you can use it for free if it you let it display ads, like Opera). Since I couldn’t get Eudora and PGP to talk, I kind of abandoned it all. Years later, my aging Eudora version choked on the vast volume of mail I received while away on vacation for a week (several thousand messages at least), and I was forced to migrate to something more current: Mozilla. Eventually Mozilla gave way to Thunderbird, which is what I’m happily using now. And what do you know, with Enigmail sitting in between, GnuPG and Thunderbird talk together beautifully.
Mind you, I’m not the paranoid type. I joke about triple-encrypting my story notes on a machine disconnected from any network to keep them from prying eyes, but I don’t really. (Although, now that I’ve admitted that, I actually might reconsider.) But being online, I often deal with people who are that paranoid, and it never hurts to prove that you really are who you say you are. I’ve always been mildly afraid that I’d tick someone off somewhere and they’d start impersonating me online, getting me into all sorts of libelous trouble. So better safe than sorry, I suppose.
I’ve posted my public key here on this site for anyone who really wants it. I’ll also post it somewhere on the GPF site soon (although I haven’t decided where yet). The fingerprint is included for verification. Of course, if you don’t care about such things, then don’t worry about it. It’s really there for the few of you who do.
Now… where should I put the triple-encrypted copy of the Year Eight timeline…?