Educational Wireless Honeypots

by Pan  (2600feedback@sensoryresearch.net)

The following article provides several avenues of exploration, depending on the experience of the reader.

For those who are unfamiliar with the concept of honeypots, or their implementation, this article provides enough information to create one of your own.  For the savvy network hacker who is experienced in the design and implementation of honeypots, this article introduces a new use for them in the public sphere.  The important point I wish to convey is that honeypots can be used not just as a security tool, but also as a teaching tool to educate the public about the security ramifications of open wireless networks.

First, let's start with the basics: a honeypot, is a configuration of network services that is meant to attract, or distract, a threat.

Originally, their purpose was to attract nefarious users who were attempting to break into a system.

The honeypot can be used to attract the threat to a particular server where information can be gathered about the origins and methods employed.  In less targeted use, honeypots, are put on networks to simply distract potential threats from the core network services.  Since a honeypot can be one or many services running on a network, there are many ways to implement them.

The honeypot we will implement in this article routes all wireless network traffic to a particular server, without leaving too many clues about the redirection.

The additional element of this honeypot is that it will provide the sandboxed user with information about wireless security.  The recipe provided in this article is applicable to Linux, UNIX, Mac OS X and Solaris, with few changes needed to get things running on each.

The operation of this honeypot is simple: an unprotected wireless access point is configured to broadcast an enticing SSID publicly.

As users connect to the access point, their machines receive a private IP and DNS routing information from your DHCP server.  The trick is that the information provided to the client causes it to route all web traffic to your server, even when the user types in a public DNS name such as www.2600.com.

Where this honeypot diverges from other common uses is that instead of gathering information about the client or routing them to an offensive website, the user is directed to a page that explains the issues surrounding unprotected and unknown wireless networks.  In essence, the honeypot is being used as a tool to educate the general public about information privacy and security.

Honeypot Construction

O.K., let's get started on our project.

To construct this honeypot, you will need the following:

1.)  Though the access point will be configured to be open and public, the honeypot itself will be operating on a private network that is not routable to the outside world.  In this particular case, we're going to be operating on the 192.168.50.0/24 network.

The honeypot server will be given the address 192.168.50.1.  You can either choose to configure your server machine's Ethernet interface to use only that address or, if you wish to keep it connected to other networks, create an alias of 192.168.50.1 on it.

Consult your operating system's documentation for the best method of doing this.

2.)  When a user machine connects to the wireless access point, the honeypot needs to provide it an IP address on our private subnet.  The DHCP server will be configured to hand out numbers from a pool within the private subnet range.

After downloading the DHCP package from ISC, follow the standard UNIX build and install process.1

After that has completed, create the file: /etc/dhcpd.conf

Open it in your favorite text editor and edit it as in Figure A.

Along with a private IP address, the DHCP service provides the client machine with the IP of a DNS server to use when querying DNS names for HTTP and other services.

This is set with the domain-name-servers option in the configuration file.

Figure A:

# dhcpd.conf
# this file should be located in /etc

# This line sets the time for a DHCP lease to be 900. 
default-lease-time 900;

# These lines tell our DHCP server that it is authoritative for
# the defined networks and should not update DNS files when providing
# an IP address to a machine.
ddns-update-style none;
deny client-updates;
authoritative;

shared-network "honeypotnetwork" {

subnet 192.168.50.0 netmask 255.255.255.0 {

	# Here we configure the information which will be given to the
	# client machine when it connects. These values are consistent
	# with a 192.168.50.0/24 network. 
     option routers 192.168.50.1;
     option subnet-mask 255.255.255.0;
     option broadcast-address 192.168.50.255;
        
	# This option tells the client machine to configure its networking
	# system to use 192.168.50.1 for DNS queries.
	option domain-name-servers 192.168.50.1;
	
	# The max-lease-time denotes how long an IP can be "leased" by a
	# client machine before it needs to be renewed.
     max-lease-time 7200;

	# This declaration tells the DHCP server to hand out addresses
	# between 192.168.50.10 and 192.168.50.254. 
	# We're saving 192.168.50.1 through 192.168.50.9 for our server,
	# access point and any other devices we might want to put in place.
     pool {
     		range 192.168.50.10 192.168.50.254;
     }
}

3.)  To answer the DNS queries of the client machine, we'll need to configure a DNS server.

This DNS server will be configured to route all DNS queries to a local DNS zone file.  In essence, you are creating a local root server.

Download the BIND package from ISC and follow the standard UNIX build and install process.  After that has completed, create the file: /etc/named.conf

Open it in your favorite text editor and edit it as in Figure B.

Figure B:

# named.conf
# this file should be located in /etc

include "/etc/rndc.key";

controls {
	inet 127.0.0.1 port 953 allow { localhost; } keys {"rndc-key"; };
};

options {
	directory "/var/named";
	recursion true;
};

# In the entry below, we are creating a wild card which denotes that DNS
# lookups for all domains should be done against the "db.localroot" zone
# file
zone "." IN {
	type master;
	file "db.localroot";
};

4.)  Next, we need to configure the DNS zone file so that all DNS queries to the local root DNS service are all directed to the same server machine.

To do this, we create the db.localroot file in /var/named/ and configure it to map all hostnames to our server as in Figure C.

Figure C:

# db.localroot
# this file should be located in /var/named/

# Time To Live - how long the record should be considered valid
$TTL 7200

# This block declares hostname.example.com the State of Authority for this domain and provides an admin email address (note the use of "." instead of "@").
@ IN SOA hostname.example.com admin.example.com (
	1 ; Serial
	3600 ; Refresh every 1 hours
	1800 ; Retry every 30 minutes
	604800 ; Expire after 7 days
	1 ) ; TTL 1 second

# This line provides the IP address of the nameserver for this domain, which in this case is the same machine.
	IN NS 192.168.50.1

# Here we define the basic A ("machine") record and a wild card entry which directs all lookups to the same A record address.
	IN A 192.168.50.1
*	IN A 192.168.50.1

5.)  In the next step of this project, we want to configure Apache to handle all incoming HTTP requests to the honeypot server.

Download the Apache HTTP Server package from Apache and follow the standard UNIX build and install process.

Open the httpd.conf file for editing.2

As in Figure D, create a VirtualHost entry for the server's IP address which points to a folder where the educational honeypot HTML files will live.

Figure D:

### httpd.conf
### Section 3: Virtual Hosts
#

# This entry tells Apache to direct HTTP requests for 192.168.50.1 to the folder /var/www/html/ and log all the incoming requests at logs/your.domain-access_log
 <VirtualHost 192.168.50.1>
    DocumentRoot /var/www/html/
    ServerName 192.168.50.1
    CustomLog logs/your.domain-access_log common
 </VirtualHost>

6.)  In this step, we need to configure the wireless access point.

By simply putting it on the same subnet, you can allow the DHCP service (and thereby DNS server information) to be passed to the client machines when they connect.  In this example, I'm using an HP ProCurve Wireless Access Point 420.  This is a slightly higher end access point than is standard for consumer networks.  You can find cheaper ones at your favorite online computer electronics outlet.  The process of configuring the access point with the appropriate information will vary for each device.  However, you should be able to extract the basic idea from my example.

6a.)  You'll want to give your access point a static IP address on the private subnet.  Alternately, if you are familiar with managing DHCP, you can add a static host entry for the AP in the dhcpd.conf file.

In Figure E, you can see that I've given my access point the IP 192.168.50.9, which is on the same 192.168.50.0/24 subnet.  Note also that I provide the server's IP (192.168.50.1) as the default gateway.

Figure E:

HP ProCurve Access Point 420# show system
System Information
===========================================================
Serial Number       : TW525QB077
System Up time      : 0 days, 0 hours, 9 minutes, 19 seconds
System Name         : WIFx1
System Location     :
System Contact      : Contact
System Country Code : NA - North America
MAC Address         : 00-13-21-57-63-2A
IP Address          : 192.168.50.9
Subnet Mask         : 255.255.255.0
Default Gateway     : 192.168.50.1
VLAN State          : DISABLED
Native VLAN ID      : 1
IAPP State          : ENABLED
DHCP Client         : DISABLED
HTTP Server         : ENABLED
HTTP Server Port    : 80
Slot Status         : Dual band(b/g)
Software Version    : v2.0.38

6b.)  To attract users to your honeypot, you will want to give the access point an SSID that is enticing.

As you can see in Figure F, I chose Free Public Wireless.

Anything with "Free" in the name is usually good enough to attract attention.  You'll also want to turn off any authentication or encryption (WEP, WPA2, etc.).  After all, this honeypot is meant to teach the dangers of unknown, unprotected wireless networks.

The client will be able to associate with the access point easily, either by selecting it from a list of available access points in their network configuration or, if their machine is set to auto-connect to nearby access points, just by roaming within range of the access point.  After configuring the access point, be sure to place it near a window, door or other area where it will achieve maximum range in the outside world.

Figure F:

HP ProCurve Access Point 420# show interface wireless g
Wireless Interface Information
===========================================================
----------------Identification-----------------------------
Description                 : Enterprise 802.11g Access Point
SSID                        : Free Public Wireless
Radio mode                  : 802.11b + 802.11g
Channel                     : 11 (AUTO)
Status                      : Enabled
----------------802.11 Parameters--------------------------
Transmit Power              : FULL (13 dBm)
Max Station Data Rate       : 54Mbps
Multicast Data Rate         : 1Mbps
Fragmentation Threshold     : 2346 bytes
RTS Threshold               : 2347 bytes
Beacon Interval             : 100 TUs
DTIM Interval               : 1 beacon
Preamble Length             : LONG
Slot time                   : AUTO
Maximum Association         : 128 stations
----------------Security-----------------------------------
Closed System               : DISABLED
802.11 Authentication       : OPEN
WPA clients                 : DISABLED
802.1x                      : DISABLED
Encryption                  : DISABLED
----------------Antenna-----------------------------------
Antenna mode                : Diversity
Antenna gain attenuation
            Low channel     : 100%
            Mid channel     : 100%
            High channel    : 100%
===========================================================

7.)  Create the HTML file that the client will be directed to when they type an address in their browser.

Again, the point of this honeypot is to educate the user about the pitfalls of unknown, unprotected wireless networks and privacy on the Internet in general.  Spend some time writing up a web page that explains why the user didn't end up where they expected on the web and why they might want to consider approaching their Internet experience with more caution in the future.

Below is the page I created for this purpose.  Note that I included links to technical and non-technical learning resources on network security/privacy that the user can bookmark.

8.)  The next stage of this process is to turn on the DHCP, DNS and HTTP services.

With most OS/distributions, you can do that with the following commands in the terminal:

# dhcpd -cf /etc/dhcpd.conf
# named
# apachectl start|restart

9.)  Wait.

If you've set this up in a populated geographical area, you'll likely see connections pretty quickly.  For example, on a busy college campus or urban housing area, you'll likely catch some users in the first few hours.

Check the Apache logs periodically to see if you are capturing some web queries.  You can also look at the DHCP lease file to see what machines have requested an IP3.  With any luck, you'll be attracting, and educating, users in no time.

Conclusion

Though I focused on unprotected wireless networks in this article, the principals outlined within are applicable to any networked interaction.  Educational honeypots offer great possibilities for teaching the general public about the issues surrounding network security and privacy.

They rely on the tendency of users to search out easy, convenient, and free solutions.  By injecting a little monkey wrench in their plans, and directing them to information about protecting themselves, you can improve the level of secure communications on the Internet and the level of discourse on issues of privacy and security in the networked age.

Footnotes

  1. A common compilation/build/install process for UNIX software requires that you cd to the software directory, run configure, make and make install (in that order).  The three packages above use this process.
  2. The httpd.conf file's location will depend on your OS/distribution.  For Apache on Red Hat Enterprise Linux the path is /etc/httpd/conf/httpd.conf.  On Mac OS X Leopard, the path is /etc/apache2/httpd.conf.
  3. Generally, the DHCP leases file resides at /var/db/dhcpd.leases.

Pan is a connoisseur of interactive computing, science and education.  He lives somewhere.

Code: dhcpd.conf

Code: named.conf

Code: db.localroot

Code: httpd.conf

Return to $2600 Index