Are your tools ready for IPv6? (part 1)

Published: 2011-08-04
Last Updated: 2011-08-05 00:14:09 UTC
by Jim Clausing (Version: 1)
4 comment(s)

For those of you that weren't at SANSFIRE 2 weeks ago, this was the title of the talk I gave there.  At the time, I said I wanted to start a dialog with our readers, so this evening, I'd like to start that.  At the IPv6 summit just before SANSFIRE, I heard IPv6 referred to as "Y2K without the hard deadline" and, in some ways, I have to say I agree with that.  I've spent the last few months looking at my automated malware analysis environment and the honeypots/honeynets that I am responsible for at the day job and working on updating them to handle IPv6 traffic.  In some cases, I will need some hardware upgrades before I can continue too far down that road (old boxes that happily run XP SP2 with 256MB of memory aren't nearly as happy when you try to throw Win7 on them).  In the meantime, I started looking at the tools that I use and whether or not they can handle IPv6.  I have broken the tools down into a couple of categories (that seem useful to me).  Then I looked at the tools that I am currently using, or have used in the (recent) pass to accomplish these tasks and examined them to see how they fared with regard to IPv6.  I wasn't sure when I began this process, what I would find.  I guess I was, mostly, pleasantly surprised that most of the tools could handle IPv6 to some degree, at least, if I updated to the current version.  I knew that most of the tools/scripts that I had written didn't handle IPv6 and in several cases, I have done a first cut at adding IPv6 support (the links to the updated tools are at the bottom of this diary).  They still need more work, especially with respect to handling optional extension headers (hop-by-hop, routing, destination, etc.).  I expect to finish the clean up of those in the next few weeks.  There are too many tools that I looked at to cover in one diary, but let me look a a few of them now and I'll continue with the rest of them during my next shift.

  • Infrastructure
    • RHEL4 - yes, I know this isn't the current version of RedHat, but it was the corporate standard when the malware environment was first set up, so that is what I was using.  Unfortunately, it has some significant shortcomings w.r.t. IPv6, mostly around ip6tables which I'll get to below, so I rate this one a FAIL
    • XP SP2- yes, again, not the current version, but worked well with the old hardware.  I know it is possible to do IPv6 with XP, but I haven't bothered to look at what it actually takes, we decided that this was a good excuse to upgrade, too, especially since many enterprises are moving to Win7 as the desktop of choice (skipping over Vista), FAIL?
    • Ubuntu 10.10 - This is the OS, I use for a lot of my throw away VMs and was the Linux distro I used to get my feet wet with IPv6, so this one goes down as a WIN
    • Win7 - handles IPv6 quite nicely out of the box, so we'll be updating the honeypots and client machines to it in the near future, WIN
  • Network Monitoring
    • tcpdump - works just fine (though keep in mind that the 'ip' and 'ip6' BPF filters examine the layer2 frame for the type of layer 3 traffic, so ip != ip6), WIN
    • wireshark/tshark  - also handle IPv6 just fine, WIN
    • ipaudit - this is an old tool that I had been using to generate a 'flow' summary from the pcap, this one has not been actively maintained for a number of years and does not, handle IPv6, FAIL
    • argus - given the failure of ipaudit, I looked at some of the other tools I was already using to see if they could fill the gap and argus works great as long as you are using at least version 3.0, WIN
    • ngrep - unfortunately, though I love this tool, it doesn't handle IPv6 at all.  It doesn't look like it is being actively supported anymore, though I will send in a bug report to the sourceforge group.  If I get the time, I may look at providing the patch myself.  FAIL
    • - I had already written a 'sort of ngrep workalike' in Perl because I needed to be able to print out something other than dots for the non-ASCII stuff in the packets.  This is one of the ones that I've updated to be able to do some IPv6, but still need to put some more work into.  WIN
    • - Another of my scripts that pulls out just the DNS traffic and gives it to me in a PSV file.  This is another that I updated, but still needs some work.  WIN
    • httpry - this is a nice tool that finds HTTP traffic on any port and can summarize it.  I was disappointed to discover that it doesn't handle IPv6.  I've sent an e-mail to the author, but haven't heard back yet on whether he plans to support it in the future.  If he doesn't, I'll need to find (or write) another tool that does this useful task.  FAIL?
    • - In my paper from 2009, I mentioned that I was using Joe Stewart's faux*.pl scripts for my emulated internet.  That is still largely true.  Joe doesn't have any intention of supporting these scripts and I frankly haven't put much effort into them yet, but I am using the smtp-sink program from postfix to absorb outbound spam and that handles IPv6 quite nicely, so I guess I rate this as FAIL/FAIL/WIN (but the FAILs are on me)
    • netflow tools - this is an area that I haven't really looked into much.  I know that netflow v9 can do IPv6, so any tools that can handle v9 netflow can probably handle IPv6 flows.  Some of my old standbys though were written in the mid-90s (Mark Verber's flow-tools stuff) and that definitely does not, so ????
  • Firewalls
    • ip6tables - one of the big issues with RHEL4 was that the kernel was simply too old.  Even though there is IPv6 support there, ip6tables was not stateful in older 2.6.x kernels.  Rather than try to figure out which RHEL /Fedora/CentOS version would work, I ditched those and used what I knew worked from my trials at home.  I went with 10.10 because that was the current Ubuntu version when I started this, I'm sure 11.04 would work just as well (as would 10.04 since it is an LTS release).  The one remaining issue with ip6tables is that they have removed the 'nat' table.  I don't want to get into any arguments about NAT, I know it isn't supposed to be necessar in IPv6.  My problem is that since I'm emulating the entire internet, I was NAT-ing just about everything to my server transparently.  I still see a need for that.  Fortunately, I've found an ip6tables extension that works via the QUEUE mechanism in user space to put NAT back into ip6tables, so this works for me.  WIN-ish
    • Checkpoint - It has been a number of years since I was a Checkpoint firewall admin, but I know folks who use continue to use Checkpoint an environments where they are turning up IPv6, so I assume the support is really there (not just marketing hype), but I'll call this one ????
    • Cisco ASA - As above, I haven't admined a Cisco firewall in a number of years, so I'll defer to you folks on this one, ????
  • Packet Crafting
    • hping2/hping3 - probably my favorite tool for quick and dirty packet crafting has long been hping because I could set everything on the command line.  Alas, I see postings on mailing lists going back to at least 2003 asking when hping3 would get IPv6 support and it still isn't there.  I'll check one more time with, but I suspect I'll be using another tool when I want to craft IPv6 traffic.  FAIL?
    • sendip - the other command line tool that I sometimes used was sendip and fortunately, this one does seem to handle IPv6, though I'm not sure I can stack the optional headers, but for the quick and dirty it seems to work.  WIN
    • scapy - the mother of all packet crafting tools handles IPv6 quite well, perhaps I'll have to give up on my quick and dirty command line stuff and just use scapy for all my packet crafting going forward. WIN

So there you have some of what I was looking at.  How about you?  In the next installment, I'll look at

  • Network Management
  • Logging
  • Databases
  • Scanning
  • Pentest Tools
  • Miscellaneous other tools

My updated tools (and there will be several more beyond the 2 listed above, to be added over the next couple of weeks) will (I believe) eventually be available via our tools page, but for the moment can be found on my handlers page at

Jim Clausing, GIAC GSE #26
jclausing --at-- isc [dot] sans (dot) edu

SANS FOR558-Network Forensics coming to central OH in Sep, see

Keywords: IPv6 tools
4 comment(s)

IRC traffic on non standard ports

Published: 2011-08-04
Last Updated: 2011-08-04 21:36:06 UTC
by Johannes Ullrich (Version: 1)
5 comment(s)

I am always quite fond of IDS signatures that look for results of compromise, versus attack attempts. This may sound a bit fatalistic, as these signatures are only triggered after the attack succeeded, but on the other hand, these alerts are actionable and can be tuned better then some of the attack attempts (most of which don't succeed and don't provide a lot of actionable information).

Today, a reader wrote in with a nice detect of "NICK traffic on a non standard port".

Lets explain IRC a bit: IRC is a simple, text based online chat protocol [1], and it is used frequently to control botnets. To prevent simple port based detection, many malicious IRC servers run on odd ports. But the IRC traffic payload can be quite characteristic and easy to spot.

As the user connects to an IRC server, it will set a nick name. This is done via a "NICK" command. In addition, the USER command is used to set a user name. a USER and a NICK command have to be sent to connect to a server, and they are usually sent one after the other.

NICK something
USER something else 

The reader's IDS captured a single packet due to this signature. The content (slightly obfuscated) was:

NICK {USA|XPa}abcdefg
USER abcdefg

These random strings with specific prefixes are typical for bot C&C, and finding a string like this would make me almost certainly look a lot closer at this particular system. 


Johannes B. Ullrich, Ph.D.
SANS Technology Institute

Keywords: bot irc
5 comment(s)
Apple release Quicktime 7.7 fixes 14 CVEs, see


What's this all about ..?
password reveal .
<a hreaf="">the social network</a> is described as follows because they respect your privacy and keep your data secure:

<a hreaf="">the social network</a> is described as follows because they respect your privacy and keep your data secure. The social networks are not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go.

<a hreaf="">the social network</a> is not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go. The social networks only collect the minimum amount of information required for the service that they provide. Your personal information is kept private, and is never shared with other companies without your permission
<a hreaf=""> public bathroom near me</a>
<a hreaf=""> nearest public toilet to me</a>
<a hreaf=""> public bathroom near me</a>
<a hreaf=""> public bathroom near me</a>
<a hreaf=""> nearest public toilet to me</a>
<a hreaf=""> public bathroom near me</a>
Enter comment here... a fake TeamViewer page, and that page led to a different type of malware. This week's infection involved a downloaded JavaScript (.js) file that led to Microsoft Installer packages (.msi files) containing other script that used free or open source programs.
distribute malware. Even if the URL listed on the ad shows a legitimate website, subsequent ad traffic can easily lead to a fake page. Different types of malware are distributed in this manner. I've seen IcedID (Bokbot), Gozi/ISFB, and various information stealers distributed through fake software websites that were provided through Google ad traffic. I submitted malicious files from this example to VirusTotal and found a low rate of detection, with some files not showing as malware at all. Additionally, domains associated with this infection frequently change. That might make it hard to detect.
Enter corthrthmment here...

Diary Archives