Posts Tagged ‘security’

WPA2 Hole196 Vulnerability

By Mark Davidson on July 25th, 2010

Last month the Wi-Fi Alliance started steps to put an end to WEP and TKIP. By January 2011 the Wi-Fi Alliance plans to disallow TKIP on access points, and disallowed its use on all WiFi devices by 2012. WEP unfortunately survives a bit longer, with the standard being banned on access points from 2013 and banned from all WiFi devices a year later. WPA2-Mixed mode which allows TKIP, will also go in 2014, leaving only WPA2-AES.

With that good news last month, bad news comes this month for the security of Wi-Fi standards.

AirTight Networks have uncovered a vulnerability that they call “Hole196” (  The 196 referring to the last line of Page 196 in the IEEE 802.11-2007 specification ), this is a vulnerability in the WPA2 security protocol that exposes WPA2-secured Wi-Fi networks to malicious insiders. With WPA2 being vastly adopted as the most robust option for many environments due to its resilience to brute force dictionary attacks, this vulnerability will effect both corporate and public networks significantly.

By exploiting the vulnerability, an insider can bypass WPA2 private key encryption and authentication to sniff and decrypt data from other authorized users as well as scan their devices for vulnerabilities, and potentially allow attackers to compromise users devices. AirTight researcher, Md. Sohail Ahmad, will be demonstrating this vulnerability at the Black Hat Arsenal (July 29th) and at DEFCON18 (July 31st) in a presentation entitled “WPA Too?!”.
The “WPA Too” presentation will demo the vulnerability and explain how it can be exploited by a malicious user to attack and compromise a legitimate user.

For the people not lucky enough to attend either security conference, AirTight will present a public Webinar on August 4 at 19:00 GMT to detail its findings.

Once the details of the vulnerability are disclosed it will be time to determine what steps and countermeasures can be used to protect wireless network infrastructure. But for now all that can really be done is to break out the VPN tunnels whenever using Wi-Fi. This can at least protect against your data being intercepted but there is still the potential for the attacker to disrupt the targets network traffic.

Read & Comment ›››

Gentoo & Nagios Configuration for Basic Remote Host Monitoring

By Mark Davidson on February 7th, 2010

Nagios is a very powerful monitoring solution that can be used to monitor the status of hosts and servers. This post is going to cover a basic setup of Nagios under Gentoo and configuring it to monitor the status of remote hosts.

First Add these lines to /etc/portage/package.use

net-analyzer/nagios-plugins nagios-dns nagios-ping nagios-ssh
net-analyzer/nagios-core vim-syntax
media-libs/gd jpeg png # You may need this line as well if your GD isn't already compiled with jpeg and png support.

Then emerge nagios

sudo emerge nagios
sudo chmod +x /etc/nagios/ # You don't have to do this but lets you ls the dir because permissions are a bit strict by default

now that nagios has been installed the next step is to enable it under apache. Edit /etc/conf.d/apache2 and add “-D NAGIOS” to the apache2 opts


After doing so create a new .htaccess file in /usr/share/nagios/htdocs/ containing the following

AuthName "Nagios Access"
AuthType Basic
AuthUserFile /etc/nagios/auth.users
Require valid-user

make a copy of the file to /usr/lib/nagios/cgi-bin/.htaccess

sudo cp /usr/share/nagios/htdocs/.htaccess /usr/lib/nagios/cgi-bin/.htaccess

next create the htpasswd file  and restart apache

sudo htpasswd2 -c /etc/nagios/auth.users nagiosadmin
sudo apache2ctl restart

Now nagios should be configured and monitoring localhost with a number of checks, to check its working simply vist and click the service details link on the menu providing everything is working you should see some service details and other status details about the localhost.

Providing everything went well we can now start monitoring some hosts remotely. There are many ways of doing so with Nagios I will cover some of these in a later tutorial but for now I will simply explain how to set up a check for PING, SSH and HTTP against a host.

Edit the /etc/nagios/nagios.cfg file and add this line any where below the log_file line.


next you need to create the dir /etc/nagios/servers and set it to be owned by nagios.

sudo mkdir /etc/nagios/servers
sudo chown nagios:nagios /etc/nagios/servers

now create a new .cfg named and begin editing it. Add the following to the file save and exit.

define host{
    use                     linux-server
    host_name  ; Change this to yourdomain
    address               83.XXX.XXX.XXX ; Change this to the IP of your domain

define service {
    use                     generic-service
    host_name      ; Change this to your domain as above
    service_description     PING
    is_volatile             0
    check_period            24x7
    max_check_attempts      3
    normal_check_interval   5
    retry_check_interval    1
    notification_interval   240
    notification_period     24x7
    notification_options    w,u,c,r
    check_command           check_ping!100.0,20%!500.0,60%

define service {
    use                     generic-service
    host_name      ; Change this to your domain as above
    service_description     SSH
    check_command           check_ssh
    notifications_enabled   0

define service {
    use                     generic-service
    host_name      ; Change this to your domain as above
    service_description     HTTP
    check_command           check_http
    notifications_enabled   0

repeat this step for each of your hosts then restart nagios

sudo /etc/init.d/nagios restart

finally visit click on the service details link again and you should see all your servers with status reports for the PING, HTTP and SSH monitoring.

Thats it for now any problems or questsions let me know I plan on covering the subject in more detail in a future post.

In the mean time some more details can be found at and

Installing & Configuring fail2ban Ubuntu 9.04

By Mark Davidson on February 7th, 2010

Fail2Ban’s primary function is to block selected IP addresses that may belong to hosts that are trying to breach the system’s security. It determines the hosts to be blocked by monitoring log files (usually /var/log/auth.log) and bans any host IP that makes too many login attempts or performs any other unwanted action within a time frame defined by the administrator. In most cases people use it to limit the number of login attempts that are allowed against SSH within a period of time, this can make it very difficult for an attacker to brute for a login.

The process for installing fail2ban under Ubuntu is to

sudo apt-get install fail2ban
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/fail.local
sudo /etc/init.d/fail2ban restart

after these initial steps have been completed if your running not running Ubuntu 9.04 you can skip the next section, unless your seeing Unexpected communication errors in the /var/log/fail2ban.log file.

These errors occur due to Ubuntu 9.04 running  Python 2.6 by default so some modifications are neeed

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install python2.5
sudo vim /usr/bin/fail2ban-server

Change the first line from




Once completed restart fail2ban and the communication errors should no longer occur

sudo /etc/init.d/fail2ban restart

Now that fail2ban is installed and working the next step is to configure it for your needs the following is an example /etc/fail2ban/jail.local file which has been configured for protecting SSH. Settings in jail.local will override the ones in jail.conf this is an example where all of the jails have been removed except the one for SSH.

# Fail2Ban local configuration file.


ignoreip = # Here you want to ignore IP's such as the IP of the Server its self, your IP and any other IPs that its important are not locked out.
bantime  = 600 # Default ban time for all jails of 10 minutes
maxretry = 3 

destemail = [email protected] # Email of where alerts should be sent to

banaction = iptables-multiport # Ban action

mta = ssmtp # MTA to be used im using ssmtp in the case but you could be using sendmail

[ssh] # This rule monitors ssh login attempts recorded in the /var/log/auth.log file and blocks the user after 3 attempts with the default bantime of 10 minutes

enabled = true
port    = ssh
filter  = sshd
action   = iptables[name=SSH, port=ssh, protocol=tcp]
 sendmail-whois[name=SSH, [email protected], [email protected]]
logpath  = /var/log/auth.log
maxretry = 3