Handy IPv6 Scripts

During my IPv6 deployments I've built up a collection of commands to handle some issues with addressing. I've set some of the more common ones up as bash aliases in my "~/.bashrc" for easy access. As you're deploying your own networks, you might find these useful.

Scanning techniques in IPv6 tend to rely on lazy administrators. This can be seen in using sequential addressing (::1, ::2, ::3, ...), using IPv4 addresses to determine IPv6 addresses, or just accepting SLAAC generated addresses. All of these can be predictable and can greatly reduce an attacker's time to scan and identify hosts on your network.

Manually configuring randomly generated addresses can keep that scan time in that "unfeasible" category. This first command will generate a random IPv6 suffix.

Generate a random suffix

• alias ipv6-randip='dd if=/dev/urandom bs=8 count=1 2>/dev/null | od -x -A n | sed -e "s/^ //" -e "s/ /:/g" -e "s/:0*/:/g" -e "s/^0*//"'

Assuming your ipv6 prefix is 2001:DB8:a5cd:e431::/64, you can use the 'ipv6-randip' command alias to generate a random suffix to configure for a server or workstation.

The problem with random addresses is they are a pain to remember. Unless you're only dealing with a hand full of hosts, your address space is going to be impossible to keep track of without relying on other tools. The good news is that those tools are so numerous that I could never list all the possible ways of doing it. But even with those tools, there's a lot of configurations and settings that need to be dealt with. Probably the most common tool to keep track of these is going to be your DNS server. After all, you need to configure DNS for your hosts there anyway.

The first hurdle you'll hit when configuring your DNS is reverse lookup. This can be really annoying. Thankfully, this next command will take some of the annoyance out of setting up all those PTR records.

Convert an address to it's reverse lookup "ipv6.arpa" name

• alias ipv6-arpa='sed -e "s/:/:0000/g" -e "s/:0*\([0-9a-f][0-9a-f][0-9a-f][0-9a-f]\)/:\1/g" -e "s/://g" | rev | sed -e "s/./&./g" -e "s/$/ip6.arpa/"'

Now when you need to set up your reverse lookup addresses, all you need to do is "echo 2001:DB8:a5cd:e431:de03:b3c1:e425:9d4f | ipv6-arpa" and out comes your "9.3.4.a.a.8.1.a.9.5.1.7.6.3.0.8.1.3.4.e.d.c.5.a.8.B.D.0.0.0.0.1.0.0.2.ip6.arpa" PTR.

I have a tendency to build up a backlog of PTRs to generate so I can do multiple at the same time. So in that case I start up a terminal and run the following line.

• read X;while [ -n "$X" ];do echo "$X" | ipv6-arpa; read X; done

Then just copy my addresses and paste them into the terminal to generate the PTR. It's a handy loop construct that I use whenever I need to do a bunch of "one-liners" for something.

The last thing to consider when using random addresses in IPv6 is to keep track of your MACs. Every once in a while you'll need to look up a host on based on it's MAC or link local address. The next commands will take a MAC address and convert it to it's SLAAC equivalent, and convert a SLAAC back to it's MAC address.

Convert a MAC Address to Stateless Address Auto Configuration

• alias ipv6-mac2slaac='perl -e "\$_=lc<>;\$_=~s/[-:]//g;\$_ =~ m/^(..)(..)(..)(..)(....)/;printf(\"%02x%s:%sff:fe%s:%s\n\", ((hex \$1)|0x02), \$2, \$3, \$4, \$5);"'
• alias ipv6-slaac2mac='perl -e "\$_=lc<>;\$_=~m/(..)(..):(..)ff:fe(..):(..)(..)/;printf(\"%02x:%s:%s:%s:%s:%s\n\",((hex \$1)^0x02),\$2,\$3,\$4,\$5,\$6);"'

So "echo 00:1e:2a:39:77:ba | ipv6-mac2slaac" will give "021e:2aff:fe39:77ba", and "echo 021e:2aff:fe39:77ba | ipv6-slaac2mac" will give "00:1e:2a:39:77:ba".

Hopefully these will save you some time and headache with your IPv6 deployment.

Wifi Autoscaning w/ Raspberry Pi and Kali Linux

I love Raspberry Pis. I currently have 2 Model B rev 2s, an original Model B rev 1, and now a Model A. One of the project's that I'm really looking forward to doing is working with the Model A as a battery powered device for wireless penetration testing, and as a mobile tool for reconnaissance. With it's credit-card size and low power requirements, the Raspberry Pi Model A is perfectly suited for the job.

Here's the main components for my layout (you should be able to purchase the major components for less than $120):

1. A Raspberry Pi Model A complete with Pibow ModelA Case. You can order the set here.
2. An Alfa Network 802.11b/g/n Long Range Wireless USB Adapter
3. 2.4GHz 20DBi High Gain WIFI Directional YAGI Antenna
4. 12000mah External USB Battery Pack
5. 8GB SD Flash Card recommended, minimum 4GB
6. You will also need the necessary USB cables, keyboard, and a display for the initial setup. Since these are not part of the final rig, and are custom requirements depending on your lab, I'll assume you can handle them yourself.

Note: The antenna and wireless card are a little over-powered for this setup, but I wanted to see what the rig would do given the most power hungry components I had. Using a mini-usb wireless adapter would be much better if you don't need the long range. In my test runs of this setup I ran the system for 12 hours to see how the battery would hold up, battery showed one bar and was good for another few hours.

Your first step is to install the default Kali Linux Raspberry Pi image to your SD Card. The instructions are available on the Kali Linux Documentation site.

After you have the SD Card loaded with the image, fire up your favorite terminal and run "fdisk" on the device. Create a new partition out of the remaining space on the card. Once that is done, run "mke2fs -t ext4" on the new partition to format it. Now we could have been fancy and grown the Kali Linux partition to use the full device, but I prefer to have a separate partition. This prevents the packet capture files from filling the entire card and possibly causing problems for the Kali Linux installation. Since we are basically running a headless capturing system, we won't know how much data it will sniff off the air until we get it back to our lab.

Now we will need a script to automatically start airmon-ng and airodump-ng on boot. I've written a quick bash script for this, with an easy config file to tailor it for each engagement. Feel free to use these and tailor them to your needs, they have worked for me so far.

/root/autoscan

• #!/bin/bash
• #
• # autoscan - simple auto scanner for kali linux on raspberry pi
•  
• source /root/.autoscan.cfg
•  
• airmon-ng start ${AIRMON_DEV}
•  
• while [ ! -e "/tmp/.autoscan.stop" ]; do
  • airodump-ng -w ${STORAGE} ${AIRODUMP_OPTS} ${AIRMON_MON} > /dev/null 2>&1 &
  • PID=$!
  • sleep ${RUN_TIME}
  • kill ${PID}
  • FS="$(df `dirname ${STORAGE}` | tail -n1 | awk '{print $4}')"
  • test ${FS} -lt ${SAFETY_NET} && touch "/tmp/.autoscan.stop"
• done
•  
• airmon-ng stop ${AIRMON_MON}

The script is pretty basic. We start out importing the config file and starting the wireless card in monitor mode. Then we enter a loop to capture our packets. The script will sleep for a period of time before killing the airodump-ng process. Then before starting the next iteration, the script will verify that there is a safe amount of space on the storage partition. If the partition gets too full, it will trigger the script to end.

Next up is the configuration file.

/root/.autoscan.cfg

• #!/bin/bash
• # autoscan config file
•  
• # This is your wireless device, probably wlan0 unless you have a
• # more advanced setup
• export AIRMON_DEV="wlan0"
• export AIRMON_MON="mon0"
•  
• # Pass these extra parameters to airodump-ng
• # (see "man airodump-ng" for info)
• export AIRODUMP_OPTS="-c 6"
•  
• # Where to store the packet files, this is the full path plus
• # the prefix
• export STORAGE="/root/store/auto"
•  
• # Split packet capturing into multiple files.
• # Every scan will record for this number of seconds before
• # starting a new scan.
• export RUN_TIME="900s"
•  
• # Do not allow scanning to consume the entire disk.
• # Do not start another scan if there is less than SAFETY_NET
• # space left (in k).
• export SAFETY_NET=100000

A couple notes on the configuration. Make sure you change the "AIRODUMP_OPTS" variable to suit your needs. You may want to add some "-o" output formats if space is an issue.

All that's left is to mount the extra storage, and start the script on boot. For ease of use I'm going to just put both into "/etc/rc.local". I've mounted the storage partition that we created earlier to "/root/store", if you place it somewhere else on the system make sure you update the /root/.autoscan.cfg to point to the correct location.

/etc/rc.local

• #!/bin/sh -e
• #
• # rc.local
•  
• mount /dev/mmcblk0p3 /root/store
• /root/autoscan > /dev/null 2>&1 &
• exit 0

Now that the SD Card is prepared, it's time to fire up the Raspberry Pi. Once the system is up, log in as "root" with the default password of "toor". Don't forget to change it! Then verify that the script is running and working.

One thing I've noticed in testing, the wlan0 interface didn't always come up, and the airmon-ng command would fail. Fortunately the wireless card activity light gives me a clue to this happening, so it's not a big deal. Restarting the Raspberry Pi fixes it.

Features or Bloat?

A recent post on the Errata Security Blog describing the Ubuntu low-mem install for VMs got me thinking on something that's bugged me for a while now. First off, kudos to Ubuntu for identifying the need for this feature and providing this option. But this begs the question, what is in that 420MB of storage and ~510MB of RAM usage? I can't wait to take this for a test drive and compare default systems. I wonder how many of those background services are really needed, and how many are just fluff. What is the security risk of all that fluff?

For those who have not caught on yet, the name of this blog is "Scalable". Look it up. A lot of time, people in IT don't understand the power of scaling DOWN. It reminded me of a tweet that I've kept in my favorites:

No it doesn't. Your stuff does not "scale well" if it only scales up, but not down.

— Jack Daniel (@jack_daniel) March 24, 2010

I'm a Gentoo Junkie myself. Being a programmer by trade makes using Gentoo, and more specifically the Portage system, very powerful and flexible. There's just no better feeling than taking a system image, performing a complete update, and finding out that I still have the same functionality and the image has dropped by 100MB. This lowers my support time/costs. There's fewer things that can go wrong with the software being there's less pieces to break. The system tends to perform better. And I'm reducing the attack surface of the system.

This is always the first issue with a security audit. Find the services and software on the system that you don't use/need and disable them or uninstall them completely. A lot of Linux Distributions are very flexible with package installations. But I'm always shocked by desktop oriented distributions, like Ubuntu. It's hard to trust a system when a 'pstree' scrolls for three screens.