Archive for April, 2011

How to block requests by referrer using .htaccess

There may be times you want to stop site visitors from clicking from a link on another site. This is called blocking the “referrer”, it’s also used to prevent image hot-linking.

A “referrer” is another site that is linking to yours. When a user clicks on the link on the other site, they are considered the referrer. In a basic referrer block, you block the traffic by specifying what domains (referrers) may not send you traffic.

For example, the following code will block any visitors that visit by clicking on links at, or block any pages or images included in that are from your site (iframes, images, etc).

RewriteEngine On
# Next line may be required, uncomment it if you're having trouble
# Options +FollowSymlinks
RewriteCond %{HTTP_REFERER} [NC]
RewriteRule .* - [F]

The thing about this is it does not stop someone from simply typing in your website address into their browser; it specifically stops traffic that originates from that other domain.

If you simply want to stop image hot-linking, we just block the file types, rather than all traffic. The only line to change is the RewriteRule line. You have two choices: To block the images completely, or to present an image that says that you don’t allow hotlinks.

Option 1: Forbid the request

RewriteRule .*.(jpe?g|gif|bmp|png)$ - [F]

Option 2: Redirect to something else

RewriteRule .*.(jpe?g|gif|bmp|png)$ [L]

Feel free to adapt this to your needs.

Questions, comments, or feedback? Got another method that you think is better, or am I missing something? Please feel free to share it in the comments below. Thank you!

Leave a comment

Quick list of useful SPF DNS records

Sender Policy Framework (SPF) is a DNS record that’s used to authenticate who is allowed to send mail appearing to come from a specific domain. It is used to help prevent email spamming and spoofing, and works by making available a list of what domains, mailservers, and IP addresses are authorized to send mail from a domain, and what to do with mail that does not match those rules.

SPF is a DNS text record, and is added to your DNS records for the domain that matches the part after the @ sign in the email address. For example, for, the SPF TXT record should be added to the domain.

I’m not going to cover every possible SPF setup, simply the ones I use most often and the rationale behind them. You can check the documentation links below my examples if you want to build more elaborate or specific SPF records.

In the below examples, substitute with your web server’s IP address in dotted-quad format without a space. E.g. IP: You can also specify a CIDR range such as IP:

Allow from the domains IP, it’s listed mailservers, and a specific IP. Soft-fail all others (Messages that return a SOFTFAIL are accepted but tagged). The recommended configuration for most dedicated/VPS web server environments. Used when you send/receive mail at your domain, and software on your domain may send mail out as you, but no other mail server or mail exchanger will send mail as you. Users of shared hosting environments will probably want to ask their web hosting provider for the recommended SPF record to use.

v=spf1 a mx ip4: ~all

Include Google’s SPF records, if you use Google Apps as your domains mail. Add, similar in rationale to the above, but used if you use Google Apps for email, and your software on your web server may also send mail as you.

v=spf1 a mx ip4: ~all

Fail all mail. Used only if you send no mail. Example: a parked domain or a domain that is not used in email at all.

v=spf1 -all

In all the examples above except for the last, I denote soft-fail (~all) instead of fail (-all). This is because you may inadvertently make a mistake or misconfiguration, and soft-failing will not prevent mail from being delivered, it will simply flag it in the email headers. You can also specify neutral (?all) as an alternative.

Here’s an example email header from Gmail which includes the SPF record’s lookup result. I’ve edited the email address and IP, of course.

Received-SPF: pass ( domain of designates IP as permitted sender) client-ip=IP;
Authentication-Results:; spf=pass ( domain of designates IP as permitted sender)

By this example, you can see the SPF record matched and was passed.

SPF records are a good tool for many reasons. They give mail servers the ability to authenticate your email to your domain, which helps keep it out of recipient’s spam folders, and they help prevent others from spoofing your domain in email, which could cause serious trouble.

Also, SPF records do not decide whether or not to accept mail for delivery — they only serve as an authentication mechanism for who is allowed to send mail appearing to come from that domain.

Further reading:

Questions, comments, or feedback about the above SPF records or how they’ve been explained? Please share your thoughts in the comments below! Thank you.

, , ,

Leave a comment

PGP/GPG Keys in Ubuntu Gnome the easy way – Part 2

In part 1, I explained how to generate and manage your encryption keys in GNOME. Now I’ll explain how to use your keys to easily encrypt your email. I’m going to only address doing this in Evolution (the default email manager in GNOME). You can access the Evolution email account settings by going to System > Preferences > Email settings [Natty/Unity: System Settings > Email], and I’ll assume that Evolution is already set up for your email account.

Integration into Evolution is painlessly simple: You just need the Key ID of your key.

Go to System > Preferences > Passwords and Encryption Keys and look in the column under Key ID. The Key ID is hex, so it only uses the characters 0-9 and A-F.

Once you have the Key ID, start Evolution and go to Edit > Preferences > Mail Accounts and click your mail account and click edit. Then, go to the Security tab and enter your Key ID in the PGP/GPG Key ID field.

That’s it. Now whenever you compose a message, you’ll see the PGP menu which will allow you to sign and/or encrypt your email messages, and in the reading pane you will see the status of signed/encrypted messages sent to you.

Questions, comments, and feedback to this are welcome, as always.

, , ,

Leave a comment

PGP/GPG Keys in Ubuntu Gnome the easy way

For the security-minded, or anyone who simply wants to be able to exchange secure, encrypted email quickly and easily, GNOME offers a really user-friendly way to generate and manage PGP/GPG keys. This program is located at System > Preferences > Passwords and Encryption Keys. [Natty/Unity: System Settings > Passwords and Encryption Keys]

You can make a new key by going to File > New… > PGP Key. This guide explains some of the basic key management functions in this application.

Fill in the name, email, and an optional comment. PGP is considered a network of trust, so etiquette states you should use your common legal name (shortened versions are ok) and your primary email address (unless you have a reason to do otherwise). If you frequently go by a nickname, enter that in the comment field.

If you’re interested in the advanced options, you can change them by dropping down “Advanced Key Options.” I’m not going to go too much in to what the various options are, but here’s a quick run-down:

Encryption Type: RSA is generally considered stronger and overall a better choice than DSA. Choose “sign only” if you’re using this as a signing key, and not an encryption key. Only select that option if you know what you’re doing.

Key Strength (bits): The higher the number, the stronger the encryption, but the longer it takes.

Expiration Date: Set this if you want your key to expire at a predefined date/time, or set to never expire. Expiration keys can still decrypt messages, but no new messages can be encrypted to them.

After choosing your options, you’ll be prompted to enter your key pass phrase. DO NOT FORGET IT! Your key will be completely unusable (and you will be unable to revoke it) if you forget the pass phrase. On the same token, avoid making it too easy or guessable.

Next, the key will be generated. This could take a while depending on the key size and the speed of your computer.

Once your key is generated, your public keyring and private keyring will be stored in ~/.gnupgNEVER distribute your private keyring (secring.pgp). This is the decryption segment of your keyring.

Next, some more exploration through the Passwords and Encryption Keys application.

Right-clicking on a key gives you the following options, which I’ll explain briefly.

Properties: Here is where you can change your passphrase, add a photo, view your key’s fingerprint, and edit the expiration date and trust level.

Export: This is where you can export your public key for distribution to others (this is the portion of the key that you DO share). By selecting export, you will export an “ASCII-armored” file that can be pasted in email, etc.

Copy: Similiar to export, Copy copies your “ASCII-armored” public key to the clipboard. Makes it easier to post in email, web page, etc.

Delete: This deletes the key. Make sure this is what you want to do!

Sign Key: This is a core part of the key-sharing portion of PGP/GPG. This “signs” the key, using your key. This applies your signature to the key, explicitly stating that you trust the key to some degree. Once you’ve signed the key, you should export the key and send it back to the originator so they can begin distributing it with your signature attached.

So how do you sign a friend’s key?

First, have them export it and send it to you. Next, drag-and-drop the file into the Passwords and Encryption Keys window. It will appear under the Other Keys tab. Once the key has appeared, just right-click on it and click ‘Sign…’ Follow the prompts. Don’t forget to export the key and return it to the sender after you’ve signed it! Work this process in reverse for getting a friend to sign your key. Drag/drop the updated keys back into your key manager to add the new signatures. To verify signatures are present, double-click on the key and look at the Names and Signatures tab.

That’s a quick run-down of the key management functions.

Questions, comments, and feedback about key management are welcome and appreciated. Note that key management may be different in the Unity interface, which is shipped with Ubuntu Natty.

, , , ,

Leave a comment

Reenable the key sequence to kill the X server in Ubuntu

This was written more specifically for Ubuntu Maverick and previous, though Natty is just around the corner.

Previous Ubuntu versions, by defafult, had the key sequence CTRL-ALT-BKSP (Control-Alt-Backspace) enabled as a way to kill the X server in case a full-screen program was frozen beyond recovery. This key combination was turned off in Lucid, but can be re-enabled.

To re-enable, go to:

System > Preferences > Keyboard > Layout > Options [Natty/Unity: System Settings > Keyboard]

Drop down “Key sequence to kill the X server” and check the box next to Control + Alt + Backspace

That’s it! The key sequence is now re-enabled.

Questions, comments, and feedback is appreciated, as always.


Leave a comment

Ubuntu Natty Beta

We’re just a couple of days down the road from the official Ubuntu Natty release. While I haven’t yet tried the beta (I had a really bad experience a few versions back — a lot broke), I’d like to hear thoughts from anyone who has.

Love it? Hate it? Run into an issue? I’d like to hear your thoughts on it. Please share them in the comments below! Thank you!

Leave a comment

Backing up your server using JungleDisk Server Edition – part 3

This is the third part in a three-part series. Make sure to read part 1 and part 2!

The one bad thing I’ve come to notice about the JungleDisk Server Edition is, over time, it tends to hog a lot of memory, even when it’s not running backups. The author at noticed this too, and recommended it may not be a good fit for low-memory VPS configurations.

But if JungleDisk is a good fit for your needs, and the memory usage is the only issue, here’s something to try. It’s either a clever solution or an ugly workaround. Call it what you will.

What we’re going to do is create a cron job that will restart jungledisk when it is done running the backup, which will free up any potentially wasted memory.

So, we’ll start by creating a script to run after your backup job. For advice on how to create and schedule this script, see my previous article, Backing up your server using JungleDisk Server Edition – part 2.

Create your file with the following line:

touch /etc/jungledisk/.restartjd

Now, create the following script and make it executable. It should be setuid root.

if [ -e /etc/jungledisk/.restartjd ]
rm /etc/jungledisk/.restartjd && /etc/init.d/junglediskserver restart

That’s about as simple as it gets, right there.

The new script should be run on a cron job that will cause it to run often enough to restart jungledisk after a backup. A suggestion would be to have it run about a half-hour to an hour after your backups are scheduled to start.

There are some security implications to where you store your temp file, what your name it, and what permissions you give it, so use your head. If you carefully read part 2, you can get a good handle on how to be mindful of the security issues.

It’s also possible to simply restart junglediskserver on a cron job, but there’s the potential you could restart it when it’s in the middle of a backup. This would cause the backup to either postpone the backup, or resume immediately, and leave stale memory allocations again, which defeats the point. What I’m aiming for here is to have it restart as quickly as possible once the update completes.

Do you have any thoughts on this approach? Know of a way that might work better? Feel free to share your thoughts in the comments below! Thank you.

, , ,

Leave a comment

How to securely wipe hard drives

I often times get asked by friends and clients to refer them to a good tool for securely wiping their hard drives. If you’re decommissioning, selling, or returning a drive with sensitive or confidential data on it, you are right to take measures to wipe the drive.

Deleting files from a hard drive doesn’t actually delete them. Instead, it merely “marks” them as deleted, leaving the original data intact until the disk space is reused. It may be that even after that space is reused that partial remnants of the files still remain, and can be easily recovered. TechRepublic wrote up a good article backed by solid research that shows just how many drives contained easily-recoverable data. The results are unnerving, but they don’t have to be.

When wiping drives is a concern, you have two choices — completely wiping a drive that you’re no longer using — that is, if you’re going to part with it; or wiping only the “free space” of your computers hard drive that you’re still using, simply to make sure deleted files are actually gone and unrecoverable.

There are many good, free, easy-to-use utilities that do an excellent job of wiping your drives. Here’s are two that I’m most familiar with and can recommend:

Darik’s Boot and Nuke (DBAN) – (website) (download) – Wipes drives completely

Darik’s Boot and Nuke (“DBAN”) is a self-contained boot disk that securely wipes the hard disks of most computers. DBAN will automatically and completely delete the contents of any hard disk that it can detect, which makes it an appropriate utility for bulk or emergency data destruction.

Eraser – (website) (download) – Can do “free space”-only wiping

Eraser is an advanced security tool for Windows which allows you to completely remove sensitive data from your hard drive by overwriting it several times with carefully selected patterns. Eraser is currently supported under Windows XP (with Service Pack 3), Windows Server 2003 (with Service Pack 2), Windows Vista, Windows Server 2008, Windows 7 and Windows Server 2008 R2.

CCleaner – (website) – Free space and full drive wiping for Windows

Besides being an all-around great cleaner for the registry, CCleaner now includes the ability to wipe both full drives and free space only. A great utility for Windows users.

These are just two programs, and there are many more available.

If you’re a *nix user, Engadget points the way to the shred program. In a nutshell, the following command is what you’re looking for:

shred -vz -n 3 /dev/sda

This will write 3 passes of random data to /dev/sda (make sure that’s the right drive before you start!), followed by a 4th pass of zeros.  It takes some time, so if you don’t mind random (suspiciously random) data on the drive, you can skip the zeroing pass by omitting the z flag.

Do you have a suggestion for a utility that can securely wipe hard drive data? Do you have any questions or feedback on the above? Please voice your thoughts in the comments below! Thank you!

, , ,

Leave a comment

kernel atkbd.c: Unknown key released messages on Linux

I just installed Ubuntu 10.10 (Maverick Meerkat) on to a Dell Vostro 1000. (Yea, yea, I know Natty is just around the corner). During the installation I dropped the terminal box down — ‘cus I’m like that — and noticed the following messages spamming the terminal log:

Apr 20 14:17:59 Vostro-1000 kernel: [    2.814838] atkbd serio0: Unknown key pressed (translated set 2, code 0x8d on isa0060/serio0).
Apr 20 14:17:59 Vostro-1000 kernel: [    2.814844] atkbd serio0: Use 'setkeycodes e00d ' to make it known.

Unplugging the laptop’s AC adapter caused it to throw the same event, this time with code e06e.

After some research, it looks like various model laptops throw odd keycodes in response to AC adapter/battery events. The Dell Vostro 1000 seems to be the one that comes up the most in searches, but the Dell Latitude 131L (which is based on the same design / hardware) is mentioned in Launchpad bug #549741, which is specific to this issue. The Inspiron 1501 is mentioned in Redhat bug #454131.

There’s also the issue of the specific keycodes that are thrown. Myself, I saw e00d and e06e. The author at DezzaNet mentions e055 as well.

So how to get rid of these messages?

The two bug reports referenced above mention removing and replacing the battery while the system is on. However, that may not work in all cases. There’s another way to get rid of the messages, and that’s mapping the keycode to the NULL character.

To do this at every bootup, edit the /etc/rc.local file and add lines like the following above the exit 0 statement:

setkeycodes  255

For example:

setkeycodes e00d 255

Repeat for each keycode you will to null out.

Questions, comments, feedback regarding this? Feel free to share in the comments below. Thank you!

, , , ,

Leave a comment

Upgrading your Ubuntu Linux filesystem from Ext3 to Ext4

With recent Linux distributions (based on the 2.6.28 kernel) the Ext4 file system is considered stable and provides many improvements over Ext3.

Ubuntu systems running 9.04 (Jaunty Jackalope) had the option to format Ext4 during install time, but Ext3 was the default until 10.04 (Lucid Lynx). However, it’s possible (and fairly easy) to upgrade Ext3 to Ext4 in-place and without reformatting or reinstalling. Nice, huh?

The following guide is based heavily off the Ubuntu documentation, which some added steps and clarification. If you’re going to do this, use your head and make sure you have backups of your important data before you start, just in case. Also, don’t skip any steps, and double-check yourself along the way. A typo could ruin your day.

Zero – Before you start

Verify your kernel version by running uname -r. Make sure it is 2.6.28 or higher. If it is not, STOP. Upgrade your kernel before attempting to proceed.

Also, check that you’re currently using Ext3 — this would be pointless if you’re already running ext4 — by using the mount command. You should see something like the following:

/dev/sda1 on / type ext3

This shows ext3 as the current filesystem type.

One – Turn off any automatic updating

Go to System > Administration > Update Manager. Click Settings and set Automatic Updates to Only notify about available updates. You want to make sure that the system doesn’t start applying an update halfway through this and give you the potential worst-case of an unbootable system.

Two – Prepare to load the Ext4 driver

Ext4 is backwards compatible with Ext3, which makes this update process as easy as it is. We’ll start by telling the system to load the Ext4 driver instead of the Ext3 driver at boot. This will allow the system to boot and run normally for the steps that follow.

Edit the file /etc/fstab in your favorite text editor. gksu gedit /etc/fstab will do fine. Change any references for disks that you plan to convert from Ext3 to Ext4. Take a look at the example:

# /etc/fstab: static file system information.
proc            /proc           proc    defaults        0       0
# /dev/sda1
UUID=327c1819-14e1-4b96-b9d2-d5e55e50f1ae /               ext3    defaults,errors=remount-ro,relatime 0       1
# /dev/sda5
UUID=900e39f2-ad49-42ee-a7f5-8e6807d6b35b none            swap    sw              0       0
/dev/scd0       /media/cdrom0   udf,iso9660 user,noauto     0       0

The above example shows an Ext3 filesystem on /dev/sda1. I’ll use /dev/sda1 as the file system for the rest of the guide for clarity. So, change ext3 to ext4 in the above file and save it.

Reboot. ( shutdown -r now )

Three – Update the filesystem options

After rebooting, the kernel will be using the Ext4 filesystem driver, even though your filesystem on disk is still natively ext3. That’s what you want, you’ll be making the actual changes to the filesystem soon.

Now, run the following command to make the changes to your filesystem that adds the Ext4 features:
sudo tune2fs -O extents,uninit_bg,dir_index /dev/sda1

Note: There’s no spaces after the comma-separated options. Copy/paste if you’re not sure.

This assumes /dev/sda1, like I stated above. Change it if it’s not correct for you, or if you’re doing multiple filesystems, run it for each one.

Reboot again ( shutdown -r now )

Four – Take a deep breath

Due to the changes that tune2fs made on your filesystem, when you reboot you’re going to get the message

“Errors were detected on your filesystem, press ‘F’ to fix…” or something similiar. Press F and let it do it’s thing.

You may get the following error as well (I did):

The disk drive for for /tmp is not ready yet or not present.
Continue to wait or ...

Just wait patiently. You’re waiting for the changes to finish on the currently-processing filesystem, and it’s just telling you that it’s trying to mount or access /tmp and it’s having trouble, due to the currently-running process.

After a few minutes (depending on the size of your partitions and the amount of data on them), everything will go back to normal and you’ll be able to log in again.

There’s just a few more steps.

Five – Reinstall grub

Run the following command to reinstall grub. Note that the partition number is omitted from the device path — this is intentional and correct.

sudo grub-install /dev/sda

You should get a message indicating the operation was successful.

If you are upgrading from 8.04 LTS to 10.04 LTS, you will need to install grub2 as soon as possible, as grub1 is not Ext4-aware. (Users running 9.04 are not affected by this.)

sudo apt-get install grub2

followed by

sudo update-grub

Once it’s done, no more reboots are really necessary, though you can always reboot to make sure grub actually reinstalled correctly. Files written from now on will be written with full Ext4 structures. You can also turn automatic updates back on at this point.

You can verify all the filesystem features are set by running:

sudo tune2fs -l /dev/sda | grep features

This is the list of ext4 features you should have set:
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent sparse_super large_file uninit_bg
If you’re missing one or more features, go back to step three above and check that you entered the command correctly.

Questions, comments, and feedback are welcome, as always.

, , , ,

Leave a comment