Here are a collection of ten short tips I’ve compiled from my experiences blogging over the past few years that new and even intermediate bloggers may find useful.  This isn’t anything new, but rather some common sense observances.

1. Choose a secure password for administration and change it every so often.
• Personally, I use KeePass to randomly generate my passwords and keep track of them for me;  I then back up my passwords database to a USB key for extra protection.  In this day and age, using passwords that can be guessed or compromised using social engineering is just so not cool.
2. Keep backups of your posts using an RSS reader.
• You never know when disaster will strike – like oh, say, your provider deletes your entire blog and hasn’t maintained daily backups for well over six months.  I use a feed reader like RSS Bandit to provide a backup of my posts and images.  I generally try to keep most files I post on my local HDD as well, which gets backed up regularly.
3. Use CAPTCHA to protect your feedback list from spam;  better yet, use reCAPTCHA.
• New bloggers are often dismayed when they find their posts hijacked with feedback spam containing URLs for pills, potions and other nefarious things.  Often this can be avoided by using a CAPTCHA plugin that prevents spambots from entering comments through a visual challenge (often called a Turing Test).  While good, CAPTCHA has proven to be hackable (see my old blog, for example).  I recommend the upgraded reCAPTCHA plugin that not only stymies 99.9999% of spam, but also helps digitize books.
4. Close off comments for posts after 60–90 days.
• This works in conjunction with #3 above to reduce your overall “attack surface” – this isn’t to say that spammers won’t try to coerce their comments into your blog by other means, but it does go a significant way to limiting their impact almost entirely.  If you need to have more feedback for longer periods, either write a new post to extend the conversations, or better yet:  Set up a Yahoo! mail list or install a forum.
5. Disable trackbacks for posts.
• Trackbacks are automatic cross-referencing flags that blogs and sites use to notify one another when they’ve been referenced directly.  A good example of this is dotNETKicks, where if your post is “kicked” into their queue, it sends a trackback to your blog saying “you’ve been kicked” which gets rendered in your feedback list.  While a cool feature, it’s also a huge back door for spamdexing.  By disabling this, you’re not really going to miss much – if you use a feed service like FeedBurner, you’ll know about other people referring to your posts.
6. If you’re using ASP.NET, make sure your pages are protected with validateRequest=”true”
• Yes, it seems obvious, but you’d be surprised at how many folks disable this, leaving their site open to playback and injection attacks.  I see attempts on this all the time in my security logs for my site.
7. Disallow <a> tags in your comments
• It’s a bit of a pain for those wanting to hyperlink away from a comment to check something out, but it also prevents a lot of link-harvesting, which results in just more spam and index climbing.
8. Throttle bad IP ranges.
• Often, you will notice attacks coming from common “ranges” of IP addresses – these are “open relay” proxies that spamdexers use to propagate their wares.  Either block these at the firewall (ie, stop all inbound traffic from 192.168.199.*) or use an httpModule/httpHandler combination (ie, UrlRewriter or similar) to block troublesome IP ranges and send out a “forbidden” 403 code, or similar.
9. Subscribe to a spam filtering service like Akismet.
• If you’ve got a bad case of spamming, consider using a service like Akismet that can provide fairly comprehensive comment and trackback spam filtering.  Some blog services offer this as a matter of course;  others require you to actively enable the service.  See Scott Hanselman’s post, Preventing comment, trackback and referral spam in dasBlog, for details on using Subkismet.
10. Be vigilant.
• Check your security logs frequently for spotting trends that don’t fit your usual daily traffic patterns;  monitor your comments lists via a feedreader to easily identify attacks;  keep looking for areas where you can “harden” your blog either with updates and patches or small code fixes.  If you have the ability, make the fix on your own rather than wait for someone else to do it for you.

Of these tips, #3 has been most successful for me to-date.  There may come a time when even reCAPTCHA is foiled, but for now it’s working wonders!

Additional References:

• SixApart Guide to Comment Spam 
• Preventing Comment, Trackback and Referral Spam in dasBlog
• reCAPTCHA
• WordPress – Combating Comment Spam

Recently, I’ve noticed some furtive spamdexing attempts in the comments to several of my older posts – in spite of having enabled dasBlog’s built-in CAPTCHA validation component.  I knew from previous experience that these were “scout” entries designed to test my defenses before an all-out onslought.  Unfortunately for the spammers, I had also configured by blog to disable link posting and cut off comments for posts older than 60 days.  This limited their attack surface, but I knew that  I needed to do something to confound these guys before my blog became another broken-window site on the interwebs advertising Viagra and pr0n sites.

Enter: reCAPTCHA

Over the summer I had read about a new advancement in blog spam protection by the folks from Carnegie Mellon who brought us the original CAPTCHA concept called reCAPTCHA, which not only stymies spambots but helps in the archiving of human knowledge from books in the process.  It does this by presenting would-be comment posters with two words to interpret from distorted images:  One is an auto-generated word which the system can validate, the other is a failing OCR capture from a book that is being digitized – but the end user (and spambot) doesn’t know which is which:

I thought this was pretty cool – it’s like a low-tech version of Stanford’s FoldingAtHome project where the web’s multiplier effect is put toward digitizing books instead of unravelling protein folding sequences.  Instead of having users just enter some mindless string, their ten-second investment to validate their post could be put to some good use while making it more difficult for bots to corrupt my comment entries.  Time to try it out! 

Adding reCAPTCHA – The high level overview

reCAPTCHA can be added to just about any type of site – there are plenty of instructions available on the main site.  For our purposes, we need to do several things:

1. Create an account for our domain via the site – this will provide us with two vital parts for installing reCAPTCHA:  A generated public/private key pair;
2. Download the ASP.NET library and copy into the bin folder for our web application;
3. Modify the site.config to hide the old-n-busted CAPTCHA component;
4. Modify the CommentViewBox.ascx file to implement the reCAPTCHA control and register it with our account;
5. Test!

1.  Create a reCAPTCHA account

• Pretty straight-forward – go here click "Sign up now!" and fill in the fields, set up a password and copy your public and private key strings to notepad.

2.  Download and install the reCAPTCHA Assembly

• Get it by clicking the link on this page.  You’ll get an archive folder that you can decompress on your system.  Go inside the release folder, find the Recaptcha.dll assembly and FTP or copy into your dasBlog installation’s Bin folder.

3.  Disable dasBlog’s old CAPTCHA component

• You may want to quiesce your live box before doing this by disabling all comments in the site configuration before proceeding.
• Locate the <enablecaptcha> element in the site.config file located in your dasBlog installation’s SiteConfig folder and set its value to false:
  

4.  Add reCAPTCHA component to the CommentViewBox.ascx control file

• Add a control registration directive to the top of the page:
  
• Add the reCAPTCHA control declaration below the old CAPTCHA control and sub-in the public and private key codes that you obtained during registration:
  

5. Test!

• Navigate to one of your posts from the main page;  your comments section should look similar to the following:
  
• Note that the control has automagically hooked up to the ValidationSummary control that’s in the CommentViewBox control definition – by default it should read “The verification words are incorrect.”
• Test by entering a valid name and comment, then the pair of words.  On postback, the CommentViewBox control verifies that the page is valid according to the results returned from the Recaptcha control.

Addendum:  Almost forgot to mention another "feature" of dasBlog that I think is pretty cool - the source is available via anonymous Subversion download at https://dasblogce.svn.sourceforge.net/svnroot/dasblogce/trunk - very lightweight and low on the overhead in comparison to TFS and its related apps.

Earlier this past week I noticed on Scott Gu's blog that the latest release of Mads Kristensen's .NET blog engine was released (v1.2), called, appropriately enough, BlogEngine.NET.  To those that have witnessed the demise of my WSS v3 powered blog recently (thanks to the "brilliant" minds at WebHost4Life), you will know that I've been in the market for a replacement.

Currently, I'm using Scott Hanselman's dasBlog which has been working out just fine, but Mads' release notes had me wanting to take a closer look:

• BlogML import/export
• Extension model
• Code syntax highlighting
• ASP.NET SiteMap provider for static pages
• Support for a static page to be the front page
• Full comment RSS/ATOM feed (here's mine)
• Intelligent error 404 page (try it)
• E-mail notifications for future comments
• Role provider
• Extended in-site search capabilities
• SLUG – the URL doesn’t change with the title
• User control injection
• Attachments on the contact page (take a look)
• Comment moderation
• Much better Mono support

So, I downloaded it and gave it a spin.  Here's my initial observations and reactions:

Setup and Installation

• Took no time to set up and install;  as with dasBlog, BlogEngine can be run as-is under a virtual directory after extracting the files and making some minor modifications to the attendant .config files.  It ships with a selection of good-looking themes that can be changed on-the-fly.

Features

• I like the overall look and feel of BlogEngine over dasBlog - it just looks and feels tighter;  however, looks can be deceiving, as I describe later;
• Out-of-the-box, every post has a set of flares for linking it, sending it or feeding it:
  
• The Blogroll box has a nifty angle that displays the most recent posts for each:
  
• Posts can be identified using tags and categories, allowing for a very flexible taxonomy that works with the usual blog archive features to find specific items.  It's a little odd, however, in that categories are entered as one might expect to add tags, and tags are entered in a free-format separated by commas:
  
• Non-blog pages can be added ad-hoc using a separate entry form via the admin console - this makes it easy to create pages for biographies, special information, etc.
• Visitor tracking scripts (eg. Google Analytics) can be entered via the admin console - no need to tediously modify themes.
• Similarly, custom <HEAD> code can be added via the console.
• Posts can be imported by one of two means:  BlogML source file or RSS.  I tried using the latter and it failed to validate the feed - with no explanation given.  There's no source code for the importing app (a standalone .NET WinForms app) so it's difficult to figure out where things are breaking down.
• Video and audio can be directly embedded into posts via the content editor toolbar - it can accommodate Flash, Quicktime, YouTube, etc. - nice touch!

Problems & Issues

• BlogEngine.NET is a completely open source project that's hosted on CodePlex - a good thing, as there's definitely more than enough work to go 'round in getting this otherwise excellent app into shape;
• I discovered more than a few unhandled exceptions around minor areas that should have been covered off, eg. two identical accounts in the user account XML file, not providing a filename for uploading an image, etc.
• There are zero unit tests in the source project - too bad!
• The .CHM help file for the API has invalid linkages for the content (at least on my end), which results in every doc page looking like IE under a 404 condition.
• Unlike dasBlog, BlogEngine does not support the concept of user-defined "macros" for manipulating content.  This is a real strong suit for dasBlog, as it makes it trivial to create "mini web parts" for customized content rendering.
• The content editor control does not support adding an image URL from the toolbar - this can only be done by editing the HTML.

I was pretty keen to move over to BlogEngine.NET right away, but after playing around with it I think I'll hold off for another revision to see if more bugs get worked out - especially those surrounding the importing of existing blog content:  I'm not really keen to go through yet another exercise of manually porting posts over, re-linking the pictures, etc.  It would be cool to see some unit tests around the engine parts, too.

So, for now the win goes to dasBlog with a more than honourable mention to BlogEngine - I'll be following its development closely to see when and if it goes into the "must use" column!