This blog post is going to illustrate setting up a software access point (AP) on Ubuntu 16.04. Having the ability to create a software AP can be very handy in testing devices with 802.11 wireless capabilities. By using the software AP we can observe all traffic being generated by a device, inspect that traffic, and determine methods to attack the device.

It should be noted that there are many other ways to accomplish the goal of traffic inspection such as:

An access point with built-in diagnostic tools or packet capture capabilities
Open source device firmware packages
Access point software like hostapd
An interception proxy such as Burp Suite or OWASP ZAP
ARP cache poisoning attacks
Devices like the WiFi Pineapple

However, by using a full fledged general purpose operating system we gain the advantage of wide support for tools that we might wish to run against the target system. As a result, we’re relieved of issues that arise due to cross-compilation or platform tool support.

I typically create my software AP as a virtual machine and take advantage of pass-through USB support using an external wireless adapter. This way I don’t have to have support in my native operating system and can start an AP with minimal configuration. My favorite wireless adapter to use in this situation is the ALFA AWUS051NH high gain 802.11 a/b/g/n adapter seen below.

Starting with a freshly installed Ubuntu 16.04 fully patched, we need to satisfy a few prerequisites for our software access point. These include:

The Aircrack-NG Suite – The Airbase-NG component of this tool suite will be used to emulate the actual wireless access point itself.
The bridge utilities package – This component will allow us to bridge the interface that our access point is running on to an internet-connected interface. It will also allow us to observe and record activity across the bridge interface.
The wireless tools package – This package contains the iwconfig utility which can be used to inspect and alter the configuration of your wireless adapter.
The rfkill utility – This utility will allow us free up the wireless adapter from control by the host operating system so we can use it to support our AP.
ISC DHCP Server – This package will provide DHCP support for our AP so connecting clients get proper IP address and DNS settings.

These prerequisites can be installed by running the following command as root:

sudo apt-get install aircrack-ng bridge-utils wireless-tools rfkill isc-dhcp-server

Note: It is a good idea to run the following before installing the above packages to ensure that your system is completely up to date:

sudo apt-get update
sudo apt-get upgrade & sudo apt-get dist-upgrade

With the prerequisites out of the way, we can begin to configure our software AP. First, connect the wireless adapter to the host and ensure that the adapter is recognized by the operating system. Use the iwconfig and ifconfig commands to ensure that the newly connected adapter appears in the interface list as seen below.

Next, we need to prevent the host operating system from using this interface in managed mode. To do so we will issue the commands “nmcli radio wifi off” and “rfkill unblock all.” The first command disabled management of the wifi radio by the host operating system network manager. The second removes software blocks that the operating system has placed on wireless devices.

With the wireless adapter free for use, we can now start broadcasting our SSID using Airbase-NG as seen below. This command takes the SSID that we wish to advertise and the adapter that will host it. This access point is just used as a quick security testing capability and does not encrypt traffic. If encryption using WPA2 is desired, the hostapd package should be considered as an alternative.

At this point, we can connect a client to the SSID but it won’t be able to obtain an IP address or surf the internet. This is where the bridge utilities package comes into play. As seen above, airbase-ng creates an interface at0. We will create a bridge named br0 and add the at0 interface to the bridge. Then we will bring both interfaces up and assign an IP address to the bridge interface.

The bridge interface br0 now has the IP address of our default gateway assigned and shares an Ethernet segment with at0. However, a connecting client still won’t get an IP address or be able to communicate with the internet.

The next step is to configure our DHCP server to provide an IP address, default gateway, and name server information to connecting clients. This will be accomplished using the ISC DHCP server that we installed during initial configuration of our system. For the purposes of this demonstration we’ve made a copy of /etc/dhcp/dhcpd.conf in root’s home directory to experiment with. Using the configuration file seen below we’ve specified name servers (8.8.8.8), the subnet we will be servicing (192.168.100.0/24), the range of IP addresses in our scope (192.168.100.10-99), and our default gateway (192.168.100.1).

Next we need to start the DHCP server. However, since we’re running the DHCP instance interactively as root we need to take ownership of the dhcp.leases file otherwise we will receive an error when we attempt to start the server. This change is not permanent. After each reboot, ownership will revert so this must be reaccomplished each time you restart the operating system running your AP.

After altering ownership of the leases file, we can start the DHCP server on our bridge interface using the configuration file we just created. If the server starts successfully, you’ll see output similar to what appears below.

Now our clients can connect to the software AP and will get appropriate IP information from our DHCP server. However, they still won’t be able to communicate to the internet. The final step in getting our AP up and running is to to enable IP forwarding and to insert a rule into the iptables firewall to forward and NAT traffic with a source address in the range of our wireless segment.

This tells the linux kernel to enable IP forwarding and use its routing table to deliver traffic. Then it NATs the outbound traffic with source addresses matching our wireless segment using the address bound to our Ethernet adapter.

With all of this in place, we should be able to observe associations, lease establishment, and monitor traffic as seen below.

Having this capability will allow us to observe behavior when connecting to an open AP (think less about standard operating systems and more about IOT devices) and analyze traffic being passed between the client and backend infrastructure. As always, be aware of any sensitive data being passed back and forth and seek a more secure alternative if necessary. As identified above, there are many alternatives to this technique.

Ready to learn more?

Level up your skills with affordable classes from Antisyphon!

Pay-What-You-Can Training

Available live/virtual and on-demand

How to Build a Soft Access Point in Ubuntu 16.04