Re: IPv6

[Chris Green <cmg () sourcefire com>]

[ not subscribed under this address so if it's not open, please
approve my message Lance :) ]

Lance Spitzner <lance () honeynet org> writes:

> Recently one of the Honeynet Project's Solaris Honeynets was compromised.
> What made this attack unique was after breaking into the system, the
> attackers enabled IPv6 tunneling on the system, with communications being 
> forwarded to another country.  The attack and communications were captured 
> using Snort, however the data could not be decoded due to the IPv6 
> tunneling.  Also, once tunneled, this could potentialy disable/bypass the 
> capabilities of some IDS systems.

An IDS policy decision here is that "IPv6 is not allowed to be
tunneled on my network".  The same should go for any time of tunneled
frames.

A general question for people (honeynet is much different than common
IDS usage) is how should snort or any other tool decide where to stop
decoding?

Ethernet Frame -> IP -> TCP

Ethernet Frame -> IP -> IPv6 -> TCP?

The rules language would have to have a concept included that
specifies how "deep" do we need to go.

There will be times when we need to configure snort to decode the IPv6
network because that's where intrusions can come from AND it's a
service we provide. I know that the honeynet project is the

        log ip any any -> any any

type of logging but let's suppose we have IPv6
$HOME_NET6,$EXTERNAL_NET6 that aren't any any and we have a real IPv6
tunnel on our network on machine A -> machine B.

Now lets say attacker installs tunneled IPv6 on machine C.

If snort is to decide to keep on decoding down the chain, and we go on
variable whims, we now get the case where an attacker can control our
network addressing schemes past that of what our IDS is wanting to
look at.  

To be pedantic, there's nothing stopping them from using ipx tunneled
over IP or even IPSEC so eventually we'll have to capture the entirety
of the state history of the machine on the honeypot side to be able to
decrypt the conversation.

It's my understanding that in this case, you really just needed to
"asciify" the logs and not necessarily do IDS on the V6 tunnel.  I can
see having a 'snort -dev --greedydecoders' that go as far down as
possible.

In the future, I'd imagine we're going to have to have more targeted
network abilities to handle saying "this host is a IPSEC tunnel"
server, log with everything..

> Marty is addressing this issue and has added IPv6 decode support to
> Snort.  Its not part of Snort current (2.0) yet, its still in the 
> process of testing.  If you would like to test this new capability,
> you can find it online at


This is just snort -dev support and not

alert tcpv6 xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx any -> xx:....... any
(content: "

type support.

>     http://www.snort.org/~roesch/
>
> Marty's looking for feedback.  As IPv6 usage spreads, especially in
> Asia, you will want to be prepared for it.  Keep in mind, even in 
> IPv4 environments (as was our Solaris Honeynet) attackers can
> encode their data in IPv6 and then tunnel it through IPv4.  We will
> most likely being seeing more of this type of behavior.

That also says that seeing tunneled protocols is a very important
policy decision for networks.  Getting good "what happened on that
tunnel" data out of that will require a good set of tools but it's not
necessarily going to intersect with IDS as much as plain old IPv4 has.

Good news is we'll be busy for years.
Bad news is we'll be busy for years.

<g>
-- 
Chris Green <cmg () sourcefire com>
A watched process never cores.