Wednesday, April 15, 2009

Nessus 4.0.0 Gentoo ebuilds

Today I've updated my Gentoo Nessus ebuilds to the just released version 4. Since the official maintainer of the Nessus ebuilds for Gentoo is very slow with updating, I've submitted the updated packages to the sec-tools overlay. At the moment they are not available yet, but I expect them to become available very soon.

If you can't wait you can also grab the ebuilds for both the server and the client from this Gentoo bug report. Unlike the previous versions this version of the service package does not include any plugins anymore. So in order to do something usefull with it you have to register either a Professional or Home feed at Tenable and fetch the newest plugins once installed.

Please let me know if you encounter any problems and leave a comment here or at bug id 265555.

Tuesday, April 7, 2009

Channel 13, now you see it, now you don't

This is just a quick blog post about scanning for wireless Wi-Fi networks. As you might know, in the US only 11 channels are allowed for the B/G band, but outside the US we have a few more channels. Here in the Netherlands also channel 12 and 13 are being used and Japan uses channel 14 as well.

When we scan for wireless networks with for instance airodump-ng using a default Linux installation, we might not directly notice that we are commonly scanning only 11 channels. Access points, ad-hoc networks and clients might show up on channels above 11 depending on your geographic location and the distance to these networks and clients. However, the trouble starts when you actually try to connect to these networks on channels 12, 13 or even 14 using iwconfig, wpa_supplicant or GNOME NetworkManager. Suddenly you are not able to connect, although you detected the network before. How is this possible? This caused by overlapping channels, which is described in this wikipedia article and I quote the relevant section below:

"There are 14 channels designated in the 2.4 GHz range spaced 5 MHz apart (with the exception of a 12 MHz spacing before Channel 14). As the protocol requires 25 MHz of channel separation, adjacent channels overlap and will interfere with each other."

This means there are only three non overlapping channels, namely 1, 6 and 11. The following picture shows the overlap of the other channels (courtesy of the same wikipedia article):



This explains why we detect channels in monitor mode we can't consequently connect to. How can this be fixed? First of all, you need the proper wireless card, because most cards have only the allowed channels enabled for the region they are sold. For some cards other channels can be enabled by hacking the firmware, but that's outside the scope of this blog posting. It also depends on which driver or Linux IEEE 802.11 networking stack the wireless card is using. Many cards use the mac80211 networking stack, which uses a kernel module named cfg80211. This module has the option to set the regdomain using the ieee_regdom variable. This variable accepts currently the values US (default), EU and JP. To enable the correct regdomain at boot time for most Linux distributions the following line should be added to the file /etc/modules.d/cfg80211:

options cfg80211 ieee_regdom=EU

Atheros chipset based wireless cards who use the madwifi-ng drivers need to follow a different procedure, because these drivers use their own hal (hardware abstraction layer) instead of the generic mac80211 layer.

Kismet users should also enable the channels they want to scan for in the kismet.conf configuration file (defaultchannels option).