Bexley IT Solutions

The netfilter/iptables tools for Linux can be used to route traffic destined for a particular host to another. An example where this might be useful is when migrating a service from one host to another and waiting for DNS changes to propagate, you want to ensure that all traffic destined for a particular host name will be serviced by one particular machine. Say you have a machine called alpha, with IP addresses 10.0.0.30 and 10.0.0.31 and you wish to route traffic destined for 10.0.0.31 to a different machine, called beta, that has the IP address 10.1.1.40, essentially using the first machine as a "middle-man" for requests destined for a particular host name. The effect will be that, no matter what machine the requests end up at initially, they will always be serviced by the second machine. This is by no means the most elegant method for redirecting services; HTTP Redirects can generally be used with websites. However, sometimes this method can be useful.

To implement this using iptables, the commands below would need to be executed as root on alpha:


echo "1" > /proc/sys/net/ipv4/ip_forward
iptables -A PREROUTING -t nat -d 10.0.0.31/32 -j DNAT --to 10.1.1.40
iptables -A POSTROUTING -t nat -d 10.1.1.40/32 -j SNAT --to 10.0.0.30


The first line tells the kernel to allow forwarding of IP packets; without this, the other commands will be useless. The first iptables rule mangles packets of data destined for 10.0.0.31 before any routing decisions take place by changing the destination IP to 10.1.1.40, which causes the redirection of traffic. The second rule takes effect after the traffic has been routed, ensuring that return traffic travels back through alpha by changing the source IP of packets destined for beta to 10.0.0.30.

If you wish to just forward traffic destined for one particular port, for example a mysql database on 3306, you would use the -p and --dport arguments:


echo "1" > /proc/sys/net/ipv4/ip_forward
iptables -A PREROUTING -t nat -p TCP -d 10.0.0.31/32 --dport 3306 -j DNAT --to 10.1.1.40
iptables -A POSTROUTING -t nat -d 10.1.1.40/32 -j SNAT --to 10.0.0.30


By using multiple PREROUTING rules, you can specify multiple ports; one for each of the services you need to forward traffic for.

If you've ever tried to install Windows XP on a recent system, you'll probably have needed to configure and perform a "slipstreamed" installation. I don't mean if you're installing from an OEM restoration disk (one that came with your Dell, HP, IBM, etc.); in this case you are either already using a slipstreamed installer, or simply restoring a disk image using a tool like Norton Ghost. When you install a retail copy of Windows XP, or an OEM copy purchased separately from your hardware you may find that the Windows installer can't "see" your hard drive or, in the worst cases, simply crash and present a Blue Screen of Death. This occurs because the hardware requires specific drivers that aren't available in the windows installer.

If the hard drive(s) are not available, it is because the drivers for the hard disk controller are not available; this is often the case for with SATA disk and RAID controllers. If this is the case there is an option to load a driver provided by the hardware manufacture, which you need to have on a floppy disk along with a txtsetup.oem file.

Introducing Slipstreaming

There is an alternative solution, which is lucky if your attempts at installing end in a BSOD; slipstreaming the drivers into the installer. This process, along with slipstreaming service packs into the installer is detailed in this article.

Simplifying Matters

Slipstreaming can be a time consuming task; integrating a service pack, creating the folder structure for the drivers and editing the relevant text files before burning the disc image. My colleague discovered a useful freeware tool, called nLite that makes the whole process much easier. It has a wizard-style interface, which walks you through selecting a Windows XP installation source, selecting a service pack and drivers to integrate and outputs a disc image for you to burn onto a CD.

You may not be aware, but there are a set of fonts that were developed for a Microsoft project that intended to produce a pack of core fonts for the Internet (see this Wikipedia article for more information).

If you're a Windows or a Mac user, you'll already have the relevant fonts installed as part of the base operating system, however, Linux users aren't so lucky. De to possible license issues, the core fonts aren't generally included as part of most distributions; I've had to install them myself on my desktop running CentOS, and my two laptops, one running Fedora 7, the other Fedora 8.

Now, when I first started using Linux, I never ran into any font issues, so it was only fairly recently that I found out about these "core fonts" - you are probably wondering why you need them on a Linux system. Well, there are two reasons for me installing them on my machines:

• Working with Microsoft document formats; for example, Word documents are often formatted with Times New Roman or Arial (two of the core fonts) - if you open them in Open Office on Linux, without having the fonts installed, the application will select similar fonts from your system to display the document. This can really become an issue if you're working and exchanging documents with people who use MS Office.
• Web-pages may not display correctly; our own fair site, for example, does not display correctly on my Samsung X60 running Fedora 8 without the core fonts installed. I believe that the effect was magnified on my machine as I have a high resolution screen (1680x1050); essentially the text appeared extremely small, too small to read without straining my eyes. This can be a real nightmare for web-developers.

To install the core fonts on a Red-Hat based system, simply follow the instructions on the core fonts Sourceforge project page. This method packages the fonts into an rpm file, which you can install with your package manager of choice.

For Debian based systems, there's a pre-built package available in the contrib repository - there's a guide to installing the fonts, as well as Flash over at the . For Ubuntu, the package is available in the multiverse repository.

I have just had to install the Sun Java Development Kit on my desktop machine; I haven't had to use it since I installed CentOS 5, and I needed to enable my browser to use Java Applets. Specifically, in order to use SSL Explorer, which is an open source SSL VPN - I've only started using this piece of software fairly recently, and I must say I'm very impressed... However, I won't stray too far from the point of this post!

I followed the usual installation procedure, documented here; I personally use the self-extracting binary file installation rather than the rpm, because it allows me to place the JDK anywhere I please. Another benefit of choosing the self-extracting binary is being able to have different versions of the software installed.

However, when I tried to view a page with a Java applet, it would not load. All I saw was a blank square where the applet should have been. After doing some searching on the web, I found this archived forum post.

Essentially, it would seem that for Red Hat based distributions, you need to install the compat-libstdc++-33 package for backwards-compatibility with certain pre-compiled binaries - including Java 6. Although the forum post explicitly mentions Fedora 7, my desktop machine runs CentOS 5, which means the package scheme is pretty much the same.

To install the required package, I simply ran the following command as root:

yum install compat-libstdc++-33

I'm now happily using SSL Explorer!

I've just installed a brilliant little script called audio-convert that allows you to easily convert your audio files from one format to another. It supports most audio formats and best of all, it can be used as a Nautilus script - this makes it a breeze to convert a bunch of files, simply by highlighting them in the browser, right-clicking, selecting "Scripts", then "audio-convert". You are then prompted, by way of a nice Zenity interface, to specify what output format you wish to use, and how you'd like to populate the resulting files' metatags (artist/song info, etc.); you can either copy the source files' meta data, or manually enter it for each track as it's converted.

My desktop machine runs CentOS 5, so to install I simply downloaded the latest version from the site, checked the package's signature, and copied the audio-convert bash script contained within the archive to /usr/local/bin. I then created a symlink from /usr/local/bin/audio-convert to the ~/.gnome2/nautilus-scripts/ directory to allow access to the script through the context menu in Nautilus. That was all I needed to do - it is worth noting, however, that I did have all the relevant codecs already installed on my system, so if you're missing any, you'll need to get them before trying to use the script.

If you are a Debian or Ubuntu user, there is a deb package available on the site. This should allow for an even simpler install, but I have been unable to try this myself.

The only possible issue is that the MP3 files it produces seem to have a , which has caused problems for me in the past with certain devices and software. However, that said, I haven't experienced an issue with VBR MP3s for sometime and I know my iRiver H340 is compatible so it probably won't cause me too pain!

This weekend, I've successfully installed both OS X "Leopard" and Fedora 8 on a new MacBook Pro - it was pretty painless, and I'm impressed with the results.

Before I started, I read an article on the Mactel Linux site titled "MacBook Pro (Santa Rosa) with Fedora 7". I used this as a rough guide - I knew I may run into some differences as I was going to be installing Fedora 8. One pleasant surprise was that I could actually install from the built in DVD drive, rather than using an external device or performing a network install. I assume they have incorporated the relevant drivers into the installer. Also, because I performed a fresh install of OS X and left space on the hard disk for Fedora, I found that the Bootcamp application wasn't actually required. In fact, I could not run Bootcamp from OS X; when I tried, the application informed me that my existing partition scheme wasn't supported, and I couldn't continue.

Installation Steps

These are the basics steps I took to achieve my dual boot system:

Install OS X

Using the disk utility on the Leopard installation DVD, I created a 20GB partition for OS X, and another 20GB partition for media and/or scratch space

Install Fedora 8

Rather than using the partitioning tool in the Fedora installer, I booted the installation DVD into rescue mode, and created my partitions with parted, then rebooted and ran the Fedora installer. My reasoning for using this method is that parted supports EFI partition tables and I would have greater control over the positioning of my partitions on the disk. I still used the Fedora partitioning tool to create my LVM volumes

Install rEFIt

I rebooted back into OS X and installed rEFIt as per the instructions in the Mactel howto. However, when I ran the rEFIt partitioning tool, I received a message telling me that the partition table was already up to date - maybe this was a result of using parted instead of the Fedora partition manager.

So far, I have been unable to get the Airport Extreme card working, which uses the Atheros 5418 chipset. Rather than installing from sources retrieved from the Madwifi subversion repositories, as detailed in the Mactel Linux howto, I installed the Madwifi drivers from the livna.org rpm repository. Usually, this is my preferred method for installing the Madwifi drivers because you don't have to recompile the drivers from source when you update the kernel. However, the drivers failed to detect the device. I found a bug report on the Madwifi site, detailing what I believe is the same issue and asking asking when support for the 5418 chipset will be added. Reading the comments, it seems that support is available in the 0.9.4 release of the driver, however, the drivers from the livna repository are currently at version 0.9.3.3. I uninstalled the drivers from the repository, and grabbed a copy of the latest source from the Madwifi subversion repository. I was unable to apply the patches from the Aircrack site that allow packet injection whilst in monitor mode - the driver simply wouldn't compile. The driver compiled fine with no patch applied, so I decided to stick with that and try patching later. With the drivers working, I tried to use the NetworkManager applet to connect to a wireless network. It picked up wireless networks in the area, but couldn't seem to join one - the card appeared to be associated to the access point, but didn't seem to receive an IP address. I'll update the article once I've carried out further tests.

After I completed the installation, I realised that the Macbook Pro has a Intel Core 2 Duo CPU, which means it has 64-bit architecture - and I'd installed the i386 version of Fedora 8! This was possibly not a bad thing - I have found in the past that there were generally less prebuilt packages available for 64-bit versions of Linux distributions, and I had to compile a lot more from source. However, I really wanted to squeeze every ounce of performance out of my machine, so I decided to re-install with the x86-64 version of Fedora. I just installed over the top of the previous instance and didn't run into any problems, in fact, once the installation of Fedora was complete, the system was ready for use.

To finish off my installation with all the relevant drivers, media applications and codecs, etc., I will be following the Personal Fedora 8 Installation Guide. The guy responsible for this howto seems to have one to cover most of the Fedora releases, I know I've used the guides for Fedora 5 through to 8 now. Below are two lists; one of cool features and one of annoyances that I've found during my use of Fedora 8:

Cool Features

• The HFS+ partitions created for OS X are recognised by Fedora, and show up as another partition that is mountable in the Nautilus file browser.
• The new version of Evolution prompts you for an attachment if you try and send an email containing the word "attachment" but forgot to attach a file!

Problems

• RhythmBox no longer seems to detect my iRiver H340 device when it's mounted. A minor inconvenience, although it did used to work flawlessly under Fedora 7 - however, I found a thread in the Ubuntu support forums that detailed a solution

*Update*There is a new article on the Mactel-Linux page that specifically details installing Fedora 8 on a MacBook Pro. *Update*

Wireless technology based on the various IEEE 802.11 standards is becoming ubiquitous in the home and workplace. While most offices will have I.T. staff who understand the security implications of implementing a wireless network, there are still many businesses that have poorly configured equipment, resulting in a vulnerable system.

If there are businesses still in the dark when it comes to wireless networking, what about the average home user? Almost all wireless access points purchased by consumers will work "out-of-the-box", providing an easy way to extend the range of your home network. However, it is highly unlikely that the configuration used will include any network authentication or encryption, allowing anybody to connect and use the networks resources (Internet, file-shares, printers, etc.). If the unauthorised user is of the Black Hat persuasion, they may attempt to compromise any system they find on the network - a home P.C. would provide a wealth of information about the owners of the network.

In order to protect a wireless network, it is necessary to understand the configuration options available.

Change Default SSID

The Service Set Identifier (SSID) of a wireless network is the network name - on most access points, the default is simply the make and/or model of the device. It is prudent to change this to something unique and that doesn't make it possible to identify the owner of the wireless network.

Disable SSID Broadcast

It is possible to disable the broadcast of your SSID - however, due to the nature of wireless networks, it is still possible to extract this information from the packets of data being exchanged between machines on the network through the air. Therefore, this is not a security option and can be disregarded when configuring a router.
In fact, it has been shown that configuring a wireless network to not broadcast it's SSID can actually have an impact on it's performance - read this pdf.

MAC Filtering

All network adapters have a quasi-unique address encoded into the hardware that takes the form xx:xx:xx:xx:xx:xx, with each "xx" a hexadecimal value between 00 and FF - this is the card's MAC address. It is possible to configure most wireless access points with a list of MAC addresses, and either permit or deny access to network cards with corresponding addresses. However, as it is possible to change the MAC address of a network card using a machine's operating system, this would not take long for a determined hacker to bypass.

Wired Equivalent Privacy / Wireless Encryption Protocol

Despite the name, WEP does not offer the same level of privacy as a wired network - in fact, it's far from it. Essentially, WEP encrypts traffic on a wireless network using either a 40 bit or 104 bit key. Client machines can also be forced to authenticate to the network using the key (Shared Key authentication); however, it is more secure to have no network authentication (Open authentication), and rely on the encrypted traffic to secure access to the LAN's resources. This may seem counter-intuitive, but it is very easy to derive the network key by capturing the entire authentication "handshake" that occurs between the access point and client machine.
WEP has been proven to be extremely easy to crack, in fact, this author was able to crack a network that he had "protected" using WEP with a 40 bit key in approximately 10 minutes. Where possible, WEP should be avoided in favour of stronger forms of authentication and encryption.
To find out more about WEP, follow this link.

Wi-Fi Protected Access

WPA was created after the flaws in WEP were uncovered - it implements most of the IEEE 802.11i standard - it was originally intended as an temporary solution while the standard was still in it's draft stages. A second version, WPA2, implements the entire standard, but does not work with some older network cards. Networks that implement either of these benefit from much stronger client authentication and data encryption than those that rely on WEP. To authenticate to the network, WPA/WPA2 provide a myriad of Extensible Authentication Protocol (EAP) options, which allows authentications to be passed off to a dedicated machine - each user of the network can use a different set of credentials. However, this is not practical for the home, or for small businesses, so another method of authentication is available - the Pre-Shared Key (PSK). This just requires that an arbitrary, pre-determined, key be input to each station on the network, which is then used to authenticate when joining the wireless LAN. The one caveat with this mode of authentication is that the key used should be composed of at least 20 characters, and consisting of lower and upper case characters, numbers and symbols (e.g. !,=,+) - otherwise, the key is vulnerable to discovery by brute-force attacks.

It is possible to implement any combination of these methods to protect your wireless network; apart from WEP and WPA, which are mutually exclusive. However, as mentioned previously, MAC filtering and disabling the SSID broadcast are extremely easy to bypass, and should only be used in tandem with WEP or WPA, if used at all. For an optimal configuration, simply change your SSID from it's default value and implement WPA.