This affects WPA2 itself, and although full details won’t be announced for a few days it just serves as a reminder that the security landscape is constantly changing. Vulnerabilities are a fact of life, and upgrades to your security software are essential. If you cannot upgrade, you need to have another layer of protection.

Many people provide their wireless access points from dedicated hardware devices, for example the Linksys WRT54GL or increasingly directly from their ADSL modem. These devices are usually the simplest to configure and support, but they are probably the hardest to upgrade.

In a case such as this, its the whole protocol that has been declared faulty, allowing an attacker to bypass network encryption completely by demanding copies of each device’s PTKs (the transient encryption keys), and the only way around that is for every device on the wireless network to upgrade to a different protocol — and we don’t have one available right now. In practice I’d expect a “WPA3″ to come up, with the specific vulnerability around group keys to be mitigated in some way. This will be delivered to PCs through your operating system updates, but that’s no use if you can’t upgrade your access points; and even though it’s often technically possible to turn up a new firmware for an old device, most hardware vendors would prefer if you just went out and bought a new unit …

So your workaround is to consider your wireless network to be as open as the old hub-based wired networks, or possibly even as dangerous as the raw Internet. Use a firewall to prevent applications on your PC from using the network without your approval, and make sure that every protocol you use with private data is software encrypted; HTTPS (use the EFF’s HTTPS-Everywhere plugin for Firefox as a minimum), IMAPS|POPS for email … or perhaps run a VPN between wireless devices and the access point or server beyond.

In fact, for corporates it may make sense to require the use of a VPN over all wireless networks, after all they are already managing the PCs in question and can keep credentials/keys updated.

This isn’t a new message; this is an old message. The security problems of wireless are not new, and indeed aren’t even specific to wireless technology at all — it’s more an issue of the way that the security software is implemented in firmware, and is therefore difficult to manage by most users. There will be vulnerabilities in the software VPNs; but the fix/upgrade timescales for these will be far faster and more achievable.

There were a lot of different people present, and “the cloud” means some very different things to all of them. I tend to see the system architectural view first, where I worry about how to marshall the resources that go into the cloud, and how software has to be structured to make best use of this different type of environment. But it’s interesting to see how cloud services rather than cloud machines are empowering developers to be able to cut out the middleman of system administrators.

An analogy for that was voiced at the time; currently we’re all like factories running our own power generators, doing our own maintenance and finding our own fuel. But the cloud services move us to just grabbing electricity from the grid. We might still worry about the cost and service level of our power supply, but we don’t employ our own engineers …

(Personal input — my father had a long career as a mechanical engineer for factory power systems, and my father-in-law is a high-voltage electrical engineer)

With a long term background in system administration, I might feel a little threatened by this, but on the whole I can see that its a good thing to be able to move on. With my security hat on, I’m worried about developers exposing their code directly to large-scale on the Internet without the benefit of actually having it evaluated or engineered correctly, but then again that’s part of the free market — if they do a bad job their apps won’t succeed, if they do a good job all will be well.

The economics of cloud services are also interesting; your first hit is free, and for at least one established NZ web-based application provider I know, their entire target market’s usage is low enough to let them run systems with zero infrastructure cost. Think about that for a minute — they can prove their platform in an NZ marketplace, and only have to pay for staff time. That’s a tremendous economic advantage for a small business …

My workaround for this is to find the files that are modified when the panel attributes are changed, and put the old ones back! So, I sat in a shell finding current files in ~/.gconf using find -mtime 0 until I’d identified the ~/.gconf/apps/panel directory (not ~/.gconf/apps/panel/applets as I initially thought) as being the place to look. I created a bzr repository in that directory and checked in all the files, and in my .bashrc I just run a quick status check to see if anything has been modified … if it has, I can run bzr revert to put it back!

Sadly just killing and restarting the gnome-panel doesn’t do enough to reset the session, you’ll have to log out completely to get the panel re-organised. Unless gnome-panel listens to a signal like HUP … and I’m not going to test that today!

Well, VoIP behaves very differently in this new regime, by which I mean SIP and RTP of course. I’ve spent far too long reading pages of badly-stated problems and non-helpful answers, and trying to get my head around just how badly NAT screws things up. And far too long changing settings trying to get improved behaviour …

Ultimately of course pfSense should behave the same way that Linux/Tomato does — things should just work without having to do any specific setup. But the timeout seems to be far more aggressive, and I think that was the real issue that started me down a long road …

I’ve been using a SIP proxy (siproxd), I’ve been NATting RTP & SIP down to a single device, I’ve been using STUN servers … The siproxd seemed to be working perfectly but at the same time there was an upstream problem that prevented me receiving calls on one of my accounts, so that solution got ripped out. The NATting worked fine but was only appropriate for one device at a time, so I started trying to move SIP to a different source port. At one stage I was seeing non-NATted traffic on my firewall’s external interface, which was rumoured to be a specific SIP (UDP port 5060) exclusion in the codebase … but I can’t replicate that any more!

Thanks to a fair bit of handholding from Chris MacGreggor at VentureVoIP, I’ve finished up with a very clean setup — no STUN, no mention of NAT on the phones, anything like that. I have decreased the Registration timeouts to 500 seconds (that’s just over 8 minutes), and put in a couple of rules matching the VoIP destination networks to increase the firewall state timeout to 1800 seconds (30 minutes). This seems to be working well …

For the record, I’ve got a number of SIP devices here :-

• Snom 300
  • Inode Ltd account at VentureVoIP
  • Home account at VentureVoIP
  • Test account on 2talk
• Linksys SPA3102 (used as an ATA)
  • Home account at VentureVoIP
• Grandstream HT486, currently not configured
• Nokia n900 mobile, currently not working
  • Inode Ltd account at VentureVoIP

So I still have a couple of steps left to take; the n900 thinks everyone is offline when it tries to call them, but then again I’ve never had this working yet so perhaps it’s not my changes that have caused this! And the old HT486 is just plugged backwards into the house phone wiring, but I no longer have any phones connected around the place (just a triplet of DECT phones connected to the Linksys SPA3102) so it’s not much of a priority.

But the basic lesson in migrating from a Linux-based working firewall into a BSD-based one seems to be “check the state table timeouts”!

Here’s the procedure I use to get the pfSense firewall OS installed on something like an ALIX 2D3. Note that I’m putting the full live distribution on a CF card, which may not be a good choice for you — CF cards have a limited write lifetime. You’ll need the following equipment :-

• ALIX system board
• Power Supply of course
• CF card, I’m using 1GB
• CF card reader on your desktop machine
• Null modem 9DB cable
• A serial port on your desktop (I use a USB/Serial converter)
• Serial port communications software (minicom works fine; on Ubuntu remember to make sure you have permission to read the /dev file — you may need to join the dialout group)
• UTP Ethernet cable

Configure the ALIX board

First, check that your ALIX machine is working and do a little setup. Don’t put the board into its case at this stage, as that usually blocks access to the CF card we’ll be using later. Be careful to keep the board on a non-conductive surface. Connect the serial cable to your PC, get the serial port communications software configured for 38400 baud, 8N1. Power on the ALIX machine and you should see this :-

PC Engines ALIX.2 v0.99h
640 KB Base Memory
261120 KB Extended Memory

01F0 - no drive found !
No boot device available, press Enter to continue.

If you don’t get something like that, look for the green lights on the ALIX board and check your comms settings. Once you get that working, it’s time to reboot the ALIX and change the baud rate. Take out the power (remember that PC Engines don’t recommend un/plugging the PSU connector at their end due to the risk of arcing, so do it at the mains end), and this time as the machine reboots press the “s” key while the memory check is counting up.

PC Engines ALIX.2 v0.99h
640 KB Base Memory
261120 KB Extended Memory

01F0 - no drive found !

BIOS setup:

(9) 9600 baud (2) 19200 baud *3* 38400 baud (5) 57600 baud (1) 115200 baud
*C* CHS mode (L) LBA mode (W) HDD wait (V) HDD slave (U) UDMA enable
(M) MFGPT workaround
(P) late PCI init
*R* Serial console enable
(E) PXE boot enable
(X) Xmodem upload
(Q) Quit

Press “9″, then “q”, then “y” to save … at which point you may as well power off again while you change the communication settings on your terminal down to 9600 baud!

*9* 9600 baud (2) 19200 baud (3) 38400 baud (5) 57600 baud (1) 115200 baud
*C* CHS mode (L) LBA mode (W) HDD wait (V) HDD slave (U) UDMA enable
(M) MFGPT workaround
(P) late PCI init
*R* Serial console enable
(E) PXE boot enable
(X) Xmodem upload
(Q) Quit

Save changes Y/N ?
Writing setup to flash... OK
x����x<�������x������x������x���x���x

Confirm you can talk to the device once again, then power off and leave it alone for a little while.

Configure the CF card

Now we’re ready to install pfSense onto the CF card. I don’t want to boot my desktop from the pfSense LiveCD, I’m going to do this via a VM under VirtualBox. First, we need to identify how the CF card shows up in your normal desktop machine, so plug it in. If a filesystem is automounted (most CF cards come with a FAT32 filesystem on them by default) then unmount it. Have a look with dmesg to find out which device it has been connected as — mine comes in as /dev/sdc

$ dmesg|tail
[45748.609374] sd 3:0:0:0: [sdb] Attached SCSI removable disk
[45748.610134] sd 3:0:0:1: [sdc] Write Protect is off
[45748.610141] sd 3:0:0:1: [sdc] Mode Sense: 03 00 00 00
[45748.610146] sd 3:0:0:1: [sdc] Assuming drive cache: write through
[45748.613126] sd 3:0:0:1: [sdc] Assuming drive cache: write through
[45748.613136]  sdc: sdc1
[45748.615125]  sdc1: 
[45748.618619] sd 3:0:0:1: [sdc] Assuming drive cache: write through
[45748.618629] sd 3:0:0:1: [sdc] Attached SCSI removable disk

Now you need to create a passthrough disk that will allow a VM guest machine to talk directly to /dev/sdc. This isn’t well covered through Google searches, but it is out there, and it’s in the VirtualBox documentation too …

$ sudo VboxManage internalcommands createrawvmdk \
-filename passthroughsdc.vmdk -rawdisk /dev/sdc -register

Make sure you create that passthroughsdc.vmdk in the correct directory, ~/.VirtualBox/HardDisks on my setup. You need to be root in order to connect to /dev/sdc, but once the disk file has been created you can chown it back to your ownership.

Now set up a VM guest for FreeBSD, giving it the passthroughsdc.vmdk as the hard drive, and the pfSense LiveCD on the CD drive. Start it up. When pfSense boots, select “i” for the Installer, choose “Easy Install” and let it rip through, copying files onto your CF drive. At the end, choose the “Embedded kernel”, and shutdown normally.

Booting pfSense on the ALIX

Now you can take the CF card and install it into the ALIX, carefully. Switch back to the serial console and power up …

PC Engines ALIX.2 v0.99h
640 KB Base Memory
261120 KB Extended Memory

01F0 Master 044A CF 2GB
Phys C/H/S 3933/16/63 Log C/H/S 983/64/63

F1   FreeBSD

Boot:   F1

pfSense should then boot, leaving you with the serial console options :-

Bootup complete

FreeBSD/i386 (pfSense.local) (console)

*** Welcome to pfSense 1.2.3-RELEASE-pfSense on pfSense ***

  LAN                      ->   vr0     ->      192.168.1.1
  WAN                      ->   vr1     ->      NONE(DHCP)

 pfSense console setup
***************************
 0)  Logout (SSH only)
 1)  Assign Interfaces
 2)  Set LAN IP address
 3)  Reset webConfigurator password
 4)  Reset to factory defaults
 5)  Reboot system
 6)  Halt system
 7)  Ping host
   Shell
 9)  PFtop
10)  Filter Logs
11)  Restart webConfigurator
12)  pfSense Developer Shell
13)  Upgrade from console
14)  Enable Secure Shell (sshd)

Enter an option: 

Now you should be able to connect a UTP Ethernet cable to the LAN interface (vr0 will probably be the interface closest to the power connector) and the other end to your PC — note that this should provide an address (and default route/DNS config — be careful if you thought your PC was supposed to be working via a different interface at the same time) for you automatically. Point your web browser to http://192.168.1.1 and enjoy your pfSense firewall!

By the way, all my PC Engine hardware comes from Nicegear, NZ’s VoIP and Open Source Hardware specialists.

First of all, we ask Nginx to serve the static files for the Nagios web interface. In Debian/Ubuntu, these live in /usr/share/nagios3/htdocs and /usr/share/nagios3/stylesheets, which is a little awkward, but just the sort of thing that the rewrite command is for …

    location / {
        root /usr/share/nagios3/htdocs;
        index index.html;

        rewrite ^/nagios3/stylesheets/(.*)$ /../stylesheets/$1 break;
        rewrite ^/nagios3/(.*)$ /$1 break;
    }

Next, we tell Nginx to send requests for CGI pages down to a FastCGI server :-

    location ~ \.cgi$ {
        root /usr/lib/cgi-bin/nagios3;
        include /etc/nginx/fastcgi_params;

        rewrite ^/cgi-bin/nagios3/(.*)$ /$1;

        auth_basic "Nagios";
        auth_basic_user_file /etc/nagios3/htpasswd.users;

        fastcgi_pass 127.0.1.1:8998;
        fastcgi_param SCRIPT_FILENAME /usr/lib/cgi-bin/nagios3$fastcgi_script_name;
        fastcgi_param AUTH_USER       $remote_user;
        fastcgi_param REMOTE_USER     $remote_user;
    }

We need to make sure that these requests are under authentication, and that we pass the authenticated username to the CGI script properly, hence the auth_basic and fastcgi_param AUTH_USER lines.

That’s Nginx taken care of, but we also need to make sure there’s a generic FastCGI server running on the specified address/port. No configuration is necessary, as we’re passing everything we need, including the script name. fcgiwrap comes recommended on the Nginx wiki.

/usr/bin/spawn-fcgi -a 127.0.1.1 -p 8998 \
-u www-data -g www-data \
-f /usr/local/bin/fcgiwrap -P /var/run/fcgiwrap.pid

And that’s all you need!

Getting this done isn’t terribly obvious, as the FastCGI protocol is not in plain text you can’t just telnet to the server and enter commands, the way you can with HTTP. There is a useful command, cgi-fcgi that comes from the libfcgi package on Debian/Ubuntu (and probably in similar packages in other distros), but the man page assumes you already know a lot more about FastCGI than you probably needed to set something up in the first place!

From http://gist.github.com/mpasternacki comes a short wrapper script to invoke cgi-fcgi to send a simple request - http://gist.github.com/209446. This script sets a bunch of environment variables that the fcgi script may require up front.

Here’s a simpler example. I have a FastCGI server running on 127.0.1.1 port 8998. I used lighttpd’s spawn-fcgi to start up an instance of fcgiwrap, a minimal fcgi processor recommended on the Nginx wiki.

/usr/bin/spawn-fcgi -a 127.0.1.1 -p 8998 \
-u www-data -g www-data \
-f /usr/local/bin/fcgiwrap -P /var/run/fcgiwrap.pid

Then, I use cgi-fcgi to connect to the port, and see what I get back.

$ cgi-fcgi -bind -connect 127.0.1.1:8998
Cannot get script name, are DOCUMENT_ROOT and SCRIPT_NAME (or SCRIPT_FILENAME) set and is the script executable?
Status: 403 Forbidden
Content-type: text/plain

403

This is enough to confirm that fcgiwrap is running OK, but doesn’t tell us if it can actually carry out any work. I’ll ask it to run a Nagios CGI command :-

$ DOCUMENT_ROOT=/var/www \
SCRIPT_FILENAME=/usr/lib/cgi-bin/nagios3/tac.cgi \
cgi-fcgi -bind -connect 127.0.1.1:8998
getcgivars(): Unsupported REQUEST_METHOD -> ''

I'm guessing you're trying to execute the CGI from a command line.
In order to do that, you need to set the REQUEST_METHOD environment
variable to either "GET", "HEAD", or "POST".  When using the
GET and HEAD methods, arguments can be passed to the CGI
by setting the "QUERY_STRING" environment variable.  If you're
using the POST method, data is read from standard input.  Also of
note: if you've enabled authentication in the CGIs, you must set the
"REMOTE_USER" environment variable to be the name of the user you're
"authenticated" as.

Excellent, this error message looks like it has come from the actual CGI command itself. Let’s set a couple more variables to help it work … let’s add REQUEST_METHOD as the error message suggested.

$ REQUEST_METHOD=GET DOCUMENT_ROOT=/var/www \
SCRIPT_FILENAME=/usr/lib/cgi-bin/nagios3/tac.cgi \
cgi-fcgi -bind -connect 127.0.1.1:8998

Cache-Control: no-store
Pragma: no-cache
Refresh: 90
Last-Modified: Wed, 07 Jul 2010 01:27:16 GMT
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Content-type: text/html

...

I’ll spare you the rest of the HTML output. This shows us a way of using a simple command-line test to verify that a FastCGI service is running correctly, without involving any front-end webserver. This is useful if you’re getting stuck setting up the front-end webserver, or if you like to have intelligent service dependency monitoring that can diagnose problems more precisely.

However, when I tried to add a shared folder to copy files from the host machine, things started going wrong …

I have a Shared Folder called “hometmp” that shares my ~/tmp directory. Normally this can be easily added to a guest with

$ sudo mount -t vboxsf hometmp ~/tmp

But for some off reason that was failing with a “Protocol error” every time … so I had to do a little digging. It seems that there’s something wrong with the way “mount -t” operates in this case, I’m not interested in openSUSE enough to dig further, but the workaround is to invoke “mount.vboxsf” directly instead. /sbin isn’t on the user path, BTW …

$ sudo /sbin/mount.vboxsf hometmp ~/tmp

And the strangest bit of all — when I went back to my VBox openSUSE to reproduce the error message in order to write this post … the original normal mount option worked just fine!

These are easily fixed, however …

http://ubuntuforums.org/showpost.php?p=9150987 tells us how to add Thunderbird to the menu, along with actions such as Compose New Message and Contacts (read the whole thread to see how Calendar would work if you had Lightning installed); but it doesn’t address how to get notifications working.

The experimental libnotify-mozilla XPI for Thunderbird itself, on the other hand, provides the notification of new mail — but if Thunderbird is not running, or if there are no new messages, nothing will be visible in the Indicator.
http://ubublogger.wordpress.com/2010/02/02/how-to-install-the-experimental-version-of-libnotify-mozilla/

A combination of these two still doesn’t produce a perfect solution, but it’s good enough until Ubuntu & Mozilla sort themselves out and get Thunderbird capable of replacing Evolution on the desktop fully.

Your database is storing an encrypted password I hope; if it is not you have other issues. You should also be following standards and prefixing the password with the name of the encryption scheme, so the DB value looks like :- {md5}CY9rzUYh03PK3k6DJie09g==

However, if you are simply storing the encrypted data without the scheme name (as I was until I started writing this!) you need to stick to a single scheme and hard-code this into the exim authentication config, which is a big source of confusion.

How it all works :-

The authentication session provides an actual password (it was lightly encoded with base64 during the SMTP session, but this has been taken care of automatically). Under PLAIN authentication, for example, $3 will contain the actual user password.

A DB query such as ${lookup mysql{...}} returns “encrypted-password” (not “{scheme}encrypted-password”)

Therefore in order to compare the password with the encrypted password, we have to say what encryption scheme the database is using — md5, sha1, whatever. We cannot decrypt what the database returns, so we must encrypt the password — but the difference is invisible to us, Exim does the right thing.

In order to encrypt the password, we need to tell crypteq which encryption scheme to use — “sha1″ normally. We need to tell crypteq explicitly what scheme we’re using, it cannot guess by looking at the values. Exim is expecting “{scheme}data”, but our DB isn’t returning that …

Also, crypteq’s *syntax* is confusing because it doesn’t read like “encrypt the password with ’sha1′ and compare that to what’s in the database”, it reads “compare the password with the ’sha1′-encrypted data from the database”.

And, for good measure, the way you say “sha1″ demands curly brackets, which are *not* part of the command syntax, and therefore need to have backslashes in front of them …

crypteq takes two strings, the unencrypted password in one, and the encrypted password PLUS the encryption scheme name in the second. We need to explicitly say \{sha1\} in front of the SQL lookup.

crypteq {$3}{\{sha1\}${lookup …}}

${if} takes three values; the query (the entire crypteq thing from above), and the two results.

server_condition = ${if crypteq {$3}{\{sha1\}${lookup …}}{yes}{no}}

read more about crypteq: http://www.exim.org/exim-html-4.40/doc/html/spec_11.html

Here’s a full authenticator for PLAIN …

begin authenticators

plain:
    driver = plaintext
    public_name = PLAIN
    server_advertise_condition = ${if eq{$tls_cipher}{}{no}{yes}}
    server_condition = ${if crypteq {$3}{${lookup sqlite {DB \
        select password from users where username = '$2';}}}{yes}{no}}
    server_set_id = $2