Dynamic IP script for Internode

WWW::Mechanize script for programmatically obtaining the current (dynamic) IPv4 and IPv6 addresses assigned to an Internode ADSL session:

#!/usr/bin/perl

use strict;
use warnings;
use WWW::Mechanize;

## Get current session data for our Internode session

my $mech = WWW::Mechanize->new();
my $user = ""; ## Enter Internode username
my $pass = ""; ## Enter Internode password

$mech->get('https://secure.internode.on.net/myinternode/sys0/login');
$mech->form_number(2);
$mech->set_fields(username => $user, password => $pass);
$mech->click('action');
$mech->follow_link (url_regex => qr/currentsessions/);

my $output = $mech->text();

## Locate IPv4 address in output
## ('IPv4:' on one side, '(dynamic)' on the other side)

my $v4_left = index ($output, "IPv4:") + 5;
my $v4_right = index ($output, "\(dynamic\)");

## Move IPv4 address in to its' own variable
## Remove new lines, leading and trailing spaces

my $ipv4 = substr $output, $v4_left, ($v4_right - $v4_left);
chomp $ipv4;
$ipv4 =~ s/^\s+//;
$ipv4 =~ s/\s+$//;

## Now do the same for the dynamically-assigned IPv6 address
## ('IPv6:' on one side, '(dynamic)' on the other side)

my $v6_left = index ($output, "IPv6:") + 5;
my $v6_right = rindex ($output, "\(dynamic\)");

## Move IPv6 address in to its' own variable
## Remove new lines, leading and trailing spaces

my $ipv6 = substr $output, $v6_left, ($v6_right - $v6_left);
chomp $ipv6;
$ipv6 =~ s/^\s+//;
$ipv6 =~ s/\s+$//;

## Print output

print "$ipv4\n";
print "$ipv6\n";

exit;

OS X Mountain Lion tips and tricks

General

sudo chflags nohidden ~/Library

Plug-ins

  • Flash installs as normal from adobe.com – use either Safari or Firefox to download
  • Java installs as normal from java.com – note that it is a 64-bit release and will not work with 32-bit software (e.g., Google Chrome)

Build environment

  • Xcode – download via the App Store – remember to install / enable the Command Line Tools (Xcode -> Preferences -> Downloads)
  • X11 – no longer included in OS X – install XQuartz instead

MacPorts

  • Installer available from the MacPorts site
  • Post installation config (definitely required for installing Wine):
echo export PATH=/opt/local/bin:/opt/local/sbin:\$PATH$'\n'export MANPATH=/opt/local/man:\$MANPATH | sudo tee -a /etc/profile
if [ `sysctl -n hw.cpu64bit_capable` -eq 1 ] ; then echo "+universal" | sudo tee -a /opt/local/etc/macports/variants.conf; else echo "not 64bit capable"; fi
sudo xcodebuild -license

Useful ports

sudo port install mtr
sudo port install nmap

Wine

sudo port install wine
sudo launchctl load -w /Library/LaunchDaemons/org.freedesktop.dbus-system.plist
launchctl load -w /Library/LaunchAgents/org.freedesktop.dbus-session.plist
sudo port install winetricks
winetricks vcrun2005sp1
winetricks ie7
winecfg

Xcode, MacPorts and Wine installation instructions adapted from David Baumgold’s site – has additional information and explanations

Client Authentication for Apache 2

There are two ways to set up client authentication – the “correct” way (where you have all of your secured content in its own virtual host) and the “useful” way (where you want to have your secured content in a directory rather than the entire site).

The “useful” way involves renegotiating the SSL connection when accessing the secured content (i.e., the connection is negotiated once when you request https://www.example.com/ and then renegotiated when you request https://www.example.com/client-auth-required/). This was all fine and well, but an OpenSSL vulnerability was discovered where renegotiation handshakes were not properly associated with the existing connection – thus potentially allowing for a Man-in-the-Middle attack.

OpenSSL 0.9.8m was released to fix the bug – the fix was to switch to a newer and more poorly supported method of allowing renegotiations. Practical outcome: client authentication in many web apps using Apache and mod_ssl simply stopped working.

Sometimes you need client authentication at a directory level, and chances are you want to make it work with commonly used web browsers (i.e., Internet Explorer). Here’s how you do it:

The method of configuring client authentication as described below intentionally turns back on a known security vulnerability in Apache. For obvious reasons, this isn’t recommended. If you can, set up your secured content in its own virtual host (the “correct” way).

This recipe makes use of the following ingredients:

  • Apache 2.2.15 or newer
  • OpenSSL (mod_ssl) 0.9.8m or newer

If you haven’t got the above two items, you need to fix that first.

Assumption: you’ve already got SSL set up and working – there are at least 9000 howto’s on the Internets, so little point in covering that here.

Once you have SSL working without error, you’ll need to add this to your VirtualHost configuration:

SSLVerifyClient require
SSLVerifyDepth x
SSLCACertificateFile /path/to/client-cert-issuing-chain.crt
SSLCADNRequestFile /path/to/client-cert-issuing-ca.crt
SSLInsecureRenegotiation on

The first line requires a certificate from the client.

The second line tells the server how far down it can traverse a chain to verify a certificate before giving up – 1 if the certificate is directly signed by a Root CA, 2 if there’s one Intermediate CA and so on.

The third line tells the server what CAs to trust for client authentication; if you have a chained hierarchy for issuing client certificates, this file should contain all of the Intermediate CAs up to and including the Root CA (concatenated together in PEM format). Not sure what version of Apache started requiring the full chain, but you’ll get non-obvious errors in your log files if you don’t have all of the CAs required here.

The fourth line tells the client what CAs the server will accept a certificate for, and should point to a file containing the Issuing CA (in PEM format) for your client certificates. This command is particularly important if you use an Intermediate CA to issue client certificates. It’s optional – and doesn’t get used to actually validate client certificates – but Internet Explorer pays attention to this statement when working out a list of acceptable client certificates for the user to pick from, so it’s not such a bad idea to include it.

The fifth line does exactly what it says; it’s what actually makes client authentication work at a directory level. Do note that the fifth line is only valid within a Server or Virtual Host context; you can’t use it in a Directory or Location section.

You will then need the following at the Directory level:

SSLRequireSSL
<FilesMatch “.(cgi|pl)$”>
SSLOptions +StdEnvVars
</FilesMatch>

Obviously this is in addition to whatever else you have configured for the Directory section.

The first line requires a SSL’ed connection.

The FilesMatch section and SSLOptions statement aren’t absolutely required, but if you want to log any of the information from the client certificate the user is presenting, or make said information available in the environment variables – you’ll need it. Grabbing all this information comes at a performance penalty, so it makes good sense to restrict what types of files the server extracts it for.

Another item worth researching and including in your config is the SSLRequire directive – it’s reasonably complicated, but allows you to control what client certificates are allowed based on things like Subject DN and Issuer DN.

One last thing: make a point of reading the mod_ssl documentation. You’ll be glad you did!