Category Archives: #!

Linux in general

Why Heartbleed did more to increase security than any friendly advice you ever gave

Doing IT operations during these heartbleeding times isn’t easy. If you’ve been following even remotely the Heartbleed saga, you know it’s a critial design flaw in the most popular implementation of the most popular encryption protocol, OpenSSL. To be plain, most of the credentials you held in the recent past are potentially compromised, since even if eveyone are now updated and protected, your credentials might have been stolen beforehand.

If you indeed do operations, you know it gets painful logging into another web console of some service provider to see a warning banner with the latest security advisory about Heartbleed. It usually goes in the same spirit of “please reset all your passwords, please recycle all your keys, please reissue all your certificates”. And the more responsible of us do: We reset all our passwords, we annihilate the deployment keys we used for the last year, and certificates older than the buildings we work in are being reissued. We update and patch all our servers, and we have a lot of servers. We mass-email users to change their login credentials, and go on a frenzy of forcing everyone to enable 2-factor authentication and security questions. And we’re probably just getting started.

We press hard, and the users, for once as terrified as we are, are being cooperative. Hours are spent on memorizing, forgetting and resetting new passwords, patching servers, and fixing outages caused by revoked keys and certificates. Everyone gets a crash course in encryption. Security is on everyone’s agenda. Users who thought certificates were for gifts now ask about SSL. Naturally, educating, updating, revoking and reissuing is time consuming, and the regular workday goes down the drain. Yet another compromised vendor or service, yet another unpatched server.

And here you should stop and think about what you are going through: if you do value security with more than just your lips, you realize this is one of the best things that happened to your operation. You are basically forced to do the very same things you knew you should have been doing all along, but always left for later. Recycling my passwords? New ones are hard to remember! Reissuing certificates on a regular basis? What kind of a sadist would put that in OpenVPN’s Wiki! Changing deployment keys? Doesn’t look amazing on anyone’s resume! Just stop and try to remember how many times, before Heartbleed, have your users/coworkers/clients cared about the same thing you do? How many times have they came to you asking you about updating a server, instead of you suggesting to them in a friendly manner they should really apply that last year of updates on their corporate laptop?

Heartbleed is the best thing that happened to network security since firewalls: Very few credentials were likely compromised via Heartbleed, but everyone is rotating their credentials and protecting themselves from more common vulnerabilities and leaked passwords. It’s hard to appreciate it between all the password resets, but when you are done with it all, sit back and have a beer. To Heartbleed!

 

heartbleed

Advertisements

1 Comment

Filed under #!

TrueCrypt + BTRFS

TrueCrypt is the weapon of choice for easy end-to-end filesystem encryption, and conveniently supports FAT, NTFS, and EXT2/3/4 out of the box. This means all you have to do is specify the filesystem during the creation of the encrypted volume, and it will be automatically mounted when the volume is unlocked. That’s great!

…But wait, I don’t want any Ext4, I want the latest and greatest BTRFS (ooooh copy on write…). Luckily, it’s only slightly more complicated, and requires treating a TrueCrypt volume like, well, a volume and not a filesystem: Create a volume and make it available, then interact with the filesystem on the volume outside of TrueCrypt.

truecrypt --text --create --filesystem=none /dev/sdx1

truecrypt --text --mount --filesystem=none --keyfiles= --volume-type=normal --protect-hidden=no --slot=1 /dev/sdx1

mkfs.btrfs /dev/mapper/truecrypt1

mount /dev/mapper/truecrypt1 /mnt

To dismount the filesystem and then the volume:


umount /mnt

truecrypt --text --dismount /dev/sdx1

1 Comment

Filed under #!, Slackware, Uncategorized

Encrypting a Linux home partition with Truecrypt

Scope:

This post will be short (and sweet). We will secure the majority of our personal data by encrypting our home partition. This is important for users with personal or sensitive data on their laptops, as well as other mobile devices such as the Google Nexus 7 when it runs Ubuntu Linux.

General Information:

The steps to encrypt a partition with Truecrypt are probably the easiest ones compared to alternatives such as LUKS and other Linux Kernel built in tools. This involves installing Truecrypt, creating an encrypted partition, copying all the sensitive data into it, deleting the sensitive data from the unencrypted partition it was previously on, and configuring mounting and umounting of the Truecrypt volume during startup/shutdown. You will need to perform this as the root user, and you will need an empty partition which you can encrypt. The steps are generic: they assume you are encrypting a brand new home partition (and not something else), after storing your user data under the /home folder on the root partition. They have been tested on Slackware64 but will work on all Linux distributions. Please adjust the partitions, runlevel scripts and installation procedure for your Linux distribution (as an example, for Ubuntu, Truecrypt might be available via Aptitude repositories vs. a binary installation package, and the runlevels will not be in traditional BSD style).

Procedure:

  1. Install Truecrypt after downloading from here:
    # tar vxf ./truecrypt-7.1a-linux-x64.tar.gz
    # ./truecrypt-7.1a-setup-x64
  2. Create an encrypted Truecrypt partition. You will be asked about the partition, passwords and keyfiles to use:
    # truecrypt --text --create
  3. Mount the new encrypted volume in a temporary location and copy all sensitive data to it. This should be done as root from singleuser runlevel if operating on the /home folder:
    # telinit 1
    # mkdir /tmp/encrypted
    # /usr/bin/truecrypt --text --mount --protect-hidden=no --volume-type=normal --keyfiles= /dev/sda6 /tmp/encrypted
    # cp -aR --preserve=all /home/* /tmp/encrypted/
    # rm -rf /home/*
  4. Configure mounting/unmounting on startup/shutdown:
    Edit /etc/rc.d/rc.S and add the following line after “/sbin/mount -a …”:

    /usr/bin/truecrypt --text --mount --protect-hidden=no --volume-type=normal --keyfiles= /dev/sda6 /home

    Edit /etc/rc.d/rc.6 and add the following line before “/sbin/umount -a …”:

    /usr/bin/truecrypt --text --dismount /dev/sda6
  5. Test with a reboot!

1 Comment

Filed under #!, Slackware

The Festival Speech Synthesis System with MPlayer output

This post is about setting up the Festival Speech Synthesis System to output speech through MPlayer playback. This is necessary if the built-in output modules, like ALSA or linux16audio, do not work for you. This can also help to increase the quality and performance of the synthesized audio. (For Slackware Linux, for instance, MPlayer is the best already-installed option.) Once you have built Speech Tools and Festival following the instructions in the INSTALL files, you can specify MPlayer for output in your ~/.festivalrc file by adding the following lines:

(Parameter.set 'Audio_Command "mplayer -really-quiet -noconsolecontrols -nojoystick -nolirc -nomouseinput -demuxer rawaudio -rawaudio channels=1:rate=$SR $FILE")
(Parameter.set 'Audio_Method 'Audio_Command)

Leave a comment

Filed under #!, Slackware

University of Toronto email on the Android email client

This post will provide you with quick and dirty instructions for setting up the Android email client (simply called “Email” in your App Launcher) with your University of Toronto email account. Ready?

1. Fire up the Android Email client app.
2. Press the Menu button on your Android device.
3. Choose “Add Account”.
4. Fill in your full email address (john.doe@utoronto.ca) and current password.
5. Choose the “Manual Setup” button (it will become available after you have filled in your email and password).
6. Pick an IMAP account.
7. For your username, do not use your email address. Use the username for portal login instead, without specifying a domain (so just “doejhon” and *not* “jhon.doe@utoronto.ca” !)
8. To fill in the “server” field, get the address of the mailserver hosting your account from your UTor ID Information Page ( https://www.utorid.utoronto.ca/cgi-bin/utorid/info.pl ). It will appear as “mailbox###.utcc.utoronto.ca” and different mailboxes reside on different servers. We need to know yours.
9. Choose SSL for encryption.
10. Choose port 993 (if it was not chosen automatically).
11. Click “Next”.
12. Use same username/password as for incoming mail in step #7.
13. Enter the SMTP server as “smtp.utoronto.ca”.
14. Choose TLS encryption.
15. Choose port 587.

You are done. Faculty spam (along with the odd useful message) will now begin flowing to and from your Android device!

6 Comments

Filed under #!

Making an Ethernet Loopback Adapder

This post will be short (and sweet). Ethernet Loopback Adapters are little handy pieces of equipment that route the transmitting pins in an Ethernet jack back to the receiving pins in the same jack. This is good for testing link connectivity on an Ethernet card – if the adapter can establish a link with itself the hardware on the adapter is probably OK. In real life, this can save you hassle quickly testing ADSL modems, routers, switches, desktops and laptops without plugging the device into another jack to get the link light to come on.

This how-to will use an existing Ethernet cable which will be converted to a Loopback cable.  There are lots of guides and video online about creating such an adapter using an Ethernet jack and wires, but this requires having an uncrimped  Ethernet jack, some wires, and a crimper. In my case, a trip to the store to buy the components I already have at home on ready Ethernet cables seemed wasteful (most people will have a cable or two, or can buy a short cat 5 cable for under 2 dollars). I strongly recommend using a cable with a broken or missing jack – after all, we only need one Ethernet jack which is properly wired to a cat5 or higher cable.

1. Cut the cat5 cable a few ( 2 or 3 ) inches from the jack.

2. Strip about an inch from the shielding of the cat 5 cable, revealing 8 separately shielded color coded wires inside.

3. Strip about half an inch from the shielding on four wires: green-white, green, orange-white, and orange.

4. Twist the green-white and orange-white stripped ends together, connecting pin 1 to pin 3.

5. Twist the green and orange stripped ends together, connecting pin 2 to pin 6.

If you have some tape, you may want to cover the tips up. Otherwise, make sure the tips don’t touch each other. The end result will look like this:

twisted pairs on an Ethernet loopback adapter

twisted pairs on an Ethernet loopback adapter

You can test your new loopback adapter in any working Ethernet jack by plugging it in!

You can see the Port line is on for a wireless router with the loopback adapter plugged in:

Link light on with loopback adaper plugged in

Link light on with loopback adaper plugged in

Leave a comment

Filed under #!

Monitoring Amazon EC2 instances and other Cloud Resources with Hyperic HQ (and other monitoring platforms)

I’ve had to tackle this task recently and could not find a write-up. Nice folks from Hyperic, and others on Twitter, suggested OpenVPN or an SSH tunnel. I opted for the second option, and after setting up two tunnels and properly configuring the agent, I now have an Amazon EC2 Windows instance show up as a platform in my Dashboard. Note that those instructions will work for other software (Zabbix comes to mind). Here’s how you can have yours too:

1. Install an SSH server on the to-be-monitored cloud instance. For Linux, OpenSSH is easy to install and setup, and usually already comes with most distributions. All you have to do is create a user and a password, or keys. On Windows, CopSSH will do the trick – you just have to add a new user and configure it through the CopSSH control panel. Make sure the SSH server runs, and the login credentials work.

2. Install an SSH client on your Hyperic HQ server. For Linux, again, OpenSSH will do the trick and is most likely already there. For Windows, try CygWIN or PUTTY.

3. Designate a unique name for localhost in the hosts file of both the Hyperic server and the cloud instance. In Linux, it would be under /etc/hosts. In windows, it moves between versions but is usually under C:\Windows\system32\drivers\etc\hosts . Call it cloudagent1. The line should look like this:

127.0.0.1     localhost cloudagent1

4. From the Hyperic server, initiate an SSH tunnel which forwards two ports. First from the cloud instance to the Hyperic server (usually on port 7443). Second from the Hyperic server to the cloud instance, to the port on which the Hyperic agent runs. If you already have a Hyperic agent on your Hyperic server, you MUST use a different port. As the local agent usually runs on port 2144, you may want to pick something like port 22144. With OpenSSH on CygWin and Linux you can create the tunnels like this (assuming your username is “user” and your cloud instance is “cloud-instance.com”):

$ ssh user@cloud-instance.com -R 7443:cloudagent1:7443 -L 22144:cloudagent1:22144 -N -f

5. Configure the Hyperic agent on your cloud instance to use port 22144. The rest of the settings can be copied from your locally monitored agents. You can use “cloudagent1” (or whichever name you have assigned to the localhost) in the configuration.

Hope this helped!

1 Comment

Filed under #!