Wi-Fi Mini Honeypot
Remember, you don't have to connect your honeypot to the Internet. In fact, you shouldn't, as you have no control of what potential users might do with the Internet access. After configuring it as described above, test whether it logs your connections. DD-WRT writes the log in /var/log/messages by default. You can check it using SSH. Here's an example fragment of such a log:
Jan 1 00:43:03 orange user.warn kernel: ACCEPT IN=br0 ↪OUT= MAC=00:26:5a:a1:bc:86:00:0c:f1:11:43:0e:08:00 ↪SRC=192.168.2.2 DST=192.168.2.1 LEN=84 TOS=0x00 PREC=0x00 ↪TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=22535 SEQ=1 Jan 1 00:43:04 orange user.warn kernel: ACCEPT IN=br0 ↪OUT= MAC=00:26:5a:a1:bc:86:00:0c:f1:11:43:0e:08:00 ↪SRC=192.168.2.2 DST=192.168.2.1 LEN=84 TOS=0x00 PREC=0x00 ↪TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=22535 SEQ=2
If you can see your packet info logged, just leave the router and wait, looking at the log from time to time.
Unfortunately, with such small resources, you can't do much more—at least within a few hours. This basic honeypot would log only packet headers, IPs and MAC addresses. You can see how a ping command is logged in the previous example. Generally, all the information you can collect is when somebody with a specified MAC and IP try to use your network—that's not much.
Logging Associations to USB Storage with OpenWrt
You can build a little more-advanced wireless honeypot with OpenWrt. Using it, you'll be able to log not only packets, MAC addresses and IP addresses, but also wireless associations, authentications, disassociations, deauthentications and timestamps. With a little effort, you also can expand your honeypot logging capabilities to use USB storage—that gives you a lot more space for logs.
My second router has 32MB of RAM, 8MB of Flash memory and USB support. On such hardware, you easily can install OpenWrt in a similar way as DD-WRT. Detailed instructions are available on the OpenWrt site. After installing it, setting up a wireless access point and logging in via SSH as root, you need to install a few more packages.
First, you'll need USB storage support:
opkg update opkg install kmod-usb-ohci opkg install kmod-usb2 insmod usb-ohci insmod usbcore insmod ehci-hcd
Now, after connecting a pendrive,
dmesg should show it to you, for
example, as /dev/sda. Make a directory for mounting your storage:
/storage. Then mount it:
/storage. You'll use it later
for gathered data.
Next, you must decide what traffic to log. Let's assume you want to
log all traffic forwarded by the router. To do this, use netfilter and
iptables -I FORWARD
-j LOG, just as you would do in
a typical Linux distribution.
Listing 1 shows an example fragment of a log stored on the pendrive. It was generated by the user associating, authenticating, requesting IP through DHCP and connecting to google.pl:80.
Listing 1. Example Log Generated with OpenWrt and Stored on a Pendrive
Oct 15 10:17:01 white daemon.info hostapd: wlan0: ↪STA 00:0c:f1:11:43:0e IEEE 802.11: authenticated Oct 15 10:17:01 white daemon.info hostapd: wlan0: ↪STA 00:0c:f1:11:43:0e IEEE 802.11: associated (aid 1) Oct 15 10:17:01 white daemon.info hostapd: wlan0: ↪STA 00:0c:f1:11:43:0e WPA: pairwise key handshake completed (RSN) Oct 15 10:17:03 white daemon.info dnsmasq-dhcp: ↪DHCPDISCOVER(br-lan) 192.168.1.99 00:0c:f1:11:43:0e Oct 15 10:17:03 white daemon.info dnsmasq-dhcp: ↪DHCPOFFER(br-lan) 192.168.1.99 00:0c:f1:11:43:0e Oct 15 10:17:03 white daemon.info dnsmasq-dhcp: ↪DHCPREQUEST(br-lan) 192.168.1.99 00:0c:f1:11:43:0e Oct 15 10:17:03 white daemon.info dnsmasq-dhcp: ↪DHCPACK(br-lan) 192.168.1.99 00:0c:f1:11:43:0e red Oct 15 10:17:14 white user.warn kernel: IN=br-lan OUT=eth0.2 ↪SRC=192.168.1.99 DST=18.104.22.168 LEN=60 TOS=0x00 ↪PREC=0x00 TTL=63 ID=59445 DF PROTO=TCP ↪SPT=49958 DPT=80 WINDOW=14600 RES=0x00 SYN URGP=0 Oct 15 10:17:14 white user.warn kernel: IN=eth0.2 OUT=br-lan ↪SRC=22.214.171.124 DST=192.168.1.99 LEN=60 TOS=0x00 ↪PREC=0x00 TTL=51 ID=6488 PROTO=TCP SPT=80 DPT=49958 ↪WINDOW=5672 RES=0x00 ACK SYN URGP=0 Oct 15 10:17:14 white user.warn kernel: IN=br-lan ↪OUT=eth0.2 SRC=192.168.1.99 DST=126.96.36.199 LEN=52 ↪TOS=0x00 PREC=0x00 TTL=63 ID=59446 DF PROTO=TCP ↪SPT=49958 DPT=80 WINDOW=229 RES=0x00 ACK URGP=0 Oct 15 10:17:14 white user.warn kernel: IN=br-lan ↪OUT=eth0.2 SRC=192.168.1.99 DST=188.8.131.52 ↪LEN=200 TOS=0x00 PREC=0x00 TTL=63 ID=59447 DF PROTO=TCP ↪SPT=49958 DPT=80 WINDOW=229 RES=0x00 ACK PSH URGP=0 Oct 15 10:17:15 white user.warn kernel: IN=eth0.2 OUT=br-lan ↪SRC=184.108.40.206 DST=192.168.1.99 LEN=52 TOS=0x00 ↪PREC=0x00 TTL=51 ID=6489 PROTO=TCP SPT=80 ↪DPT=49958 WINDOW=106 RES=0x00 ACK URGP=0 Oct 15 10:17:15 white user.warn kernel: IN=eth0.2 OUT=br-lan ↪SRC=220.127.116.11 DST=192.168.1.99 LEN=561 TOS=0x00 ↪PREC=0x00 TTL=51 ID=6490 PROTO=TCP SPT=80 ↪DPT=49958 WINDOW=106 RES=0x00 ACK PSH URGP=0
This honeypot is a little more advanced, although you still don't have much control over user activity on the Internet. You either shouldn't connect the router to the Internet, filter the traffic with iptables and/or set up a proxy between your router and the Internet. Or, you can set up a proxy on your router!
Marcin Teodorczyk is a GNU/Linux user with more than 12 years of experience. For the past four years, he's been using Arch Linux exclusively on his personal computers.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Doing for User Space What We Did for Kernel Space
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- Rogue Wave Software's Zend Server