Latest Alerts

Rule validation should be on a list of checks. This should continue with any rule change but that can often not scale. At a minimum, testing of Access Control Lists and Firewall rules must be conducted when implanting dual stack. Enter story;

A little over four years ago I started my journey with IPv6, to the point of setting up tunneling at home, and getting my entire home network IPv6 enabled. This was actually quite simple with Tunnel Broker [1]. The interesting part of this story comes in when you take a look at how dual stack works and firewall traffic. To make a long story short, I did not test the home firewall and discovered that it routed tunneled traffic but did not filter the tunneled traffic (Big Thanks to Dr J, whom I was testing with at the time, for point this out).

For the record my open network gap was only about 15 minutes but lets make sure that yours is 0 minutes.

Talking about the dual stack, there are some applications that process packets in a separate process for IPv6 traffic and transition that packet into the application process. There are some applications that use the same memory stack to process IPv6 packets. For example, in some application cases you can bind to the IPv6 stack and listen for IPv4 and IPv6 packets. If I recall correctly, Samba 4.x does it this way, check your manuals and developer threads for specifics [2] and be sure to understand how internet facing applications bind their stacks!

What can we do about it? Well, what I do is fire up a SCAPY [3] on one end and a NetCat [4] on the other, and transmit traffic across the firewall boundary.

There is an RFC based set of address that you can use internally and or in a lab to test this process, even works on most Virtual Machine setups, call ULA or Unique local addresses [5]. This is an analog to RFC 1918 (Sort of) and can allow you to setup fully routable internal IPv6 networks for testing, ESPECIALLY firewalls and ACLs.

From RFC 4193:


Local IPv6 unicast addresses have the following characteristics:

Globally unique prefix (with high probability of uniqueness).

Well-known prefix to allow for easy filtering at site boundaries.

Allow sites to be combined or privately interconnected without creating any address conflicts or requiring renumbering of interfaces that use these prefixes.

Internet Service Provider independent and can be used for communications inside of a site without having any permanent or intermittent Internet connectivity.

If accidentally leaked outside of a site via routing or DNS, there is no conflict with any other addresses. (IPv6 Focus Month Note: that is if the ULA address generation process is followed)

In practice, applications may treat these addresses like global scoped addresses.




Check back later this week for part 2, which will have the demonstration on how I test along with some downloadable Virtual Machines for your own labs.



[1] http://tunnelbroker.net/

[2] http://www.samba.org/samba/docs/

[3] http://www.secdev.org/projects/scapy/

[4] http://netcat.sourceforge.net/

[5] https://tools.ietf.org/html/rfc4193



Richard Porter

--- ISC Handler on Duty
(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Packet Tunneling IPv6 over IPv4 protocol 41 (Toredo or 6to4) is nothing new. It was first introduce in RFC 2473 in December 1998 and has been in use since ~2002. Depending of the age of your home router, it may already have some form of IPv6 support. As an example, the Linksys WRT610N router version 1.0 has a hidden page http://router/System.asp that adds support for protocol 41 and this support is listed as Vista Premium.



To check if your router is allowing protocol 41 to flow freely in and out of your home network, you can run a sniffer against the external IP of your router looking for that protocol. You can use either tcpdump or Wireshark to verify. Using tcpdump, you can issues the following command:



tcpdump -ns 0 -i eth1 proto 41

19:11:47.447246 IP XX.245.121.230 ZZ.246.188.99: IP6 2001:0:5ef5:79fb:2ce5:306e:8dd6:7711 2002:63f6:bc63:0:6975:9942:470:7a02: ICMP6, echo request, seq 14021, length 12

19:11:49.470610 IP XX.245.121.238 ZZ.246.188.99: IP6 2001:0:5ef5:79fb:2ce5:306e:8dd6:7711 2002:63f6:bc63:0:6975:9942:470:7a02: ICMP6, echo request, seq 21435, length 12

19:12:59.648790 IP YYY.228.192.53 ZZ.246.188.99: IP6 2002:d3e4:c035::d3e4:c035.54377 2002:63f6:bc63:0:6975:9942:470:7a02.52538: Flags [S], seq 588108466, win 8192, options [mss 1220,nop,wscale 8,nop,nop,sackOK], length 0

19:13:02.653077 IP YYY.228.192.53 ZZ.246.188.99: IP6 2002:d3e4:c035::d3e4:c035.54377 2002:63f6:bc63:0:6975:9942:470:7a02.52538: Flags [S], seq 588108466, win 8192, options [mss 1220,nop,wscale 8,nop,nop,sackOK], length 0

19:13:08.647639 IP YYY.228.192.53 ZZ.246.188.99: IP6 2002:d3e4:c035::d3e4:c035.54377 2002:63f6:bc63:0:6975:9942:470:7a02.52538: Flags [S], seq 588108466, win 8192, options [mss 1220,nop,nop,sackOK], length 0

19:17:57.403065 IP ZZ.246.188.99 192.88.99.1: IP6 2002:63f6:bc63:0:580:ed30:dc11:1d1b.51050 2607:f0d0:3001:62:1::52.80: Flags [S], seq 2581307596, win 8192, options [mss 1440,nop,wscale 8,nop,nop,sackOK], length 0

19:17:57.443256 IP 192.88.99.1 ZZ.246.188.99: IP6 2607:f0d0:3001:62:1::52.80 2002:63f6:bc63:0:580:ed30:dc11:1d1b.51050: Flags [S.], seq 4094422909, ack 2581307597, win 5760, options [mss 1440,nop,nop,sackOK,nop,wscale 9], length 0

19:17:57.445276 IP ZZ.246.188.99 192.88.99.1: IP6 2002:63f6:bc63:0:580:ed30:dc11:1d1b.51050 2607:f0d0:3001:62:1::52.80: Flags [.], ack 1, win 258, length 0





Even if you are not setup for IPv6, there may be a lot of interesting data flowing your way. For example, from my router I can see ICMP6 echo requests, TCP traffic attempting to connect to strange ports and of course my own outbound 6to4 traffic. The last 3 traces are a 3-way handshake associated with web traffic connecting to the Wireshark website via IPv6 6to4 tunnel. Note that IP 192.88.188.99 is listed as a 6TO4-RELAY-ANYCAST-IANA-RESERVED address.

If your home router supports some form of IPv6, native, Toredo or 6to4 and would like to share that information, post it via our contact page.

[1] http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml

[2] http://tools.ietf.org/html/rfc2473

[3] http://www.cert.org/blogs/certcc/2009/08/managing_ipv6_part_i.html

[4] https://isc.sans.edu/ipinfo.html?ip=192.88.99.1

-----------

Guy Bruneau IPSS Inc. gbruneau at isc dot sans dot edu (c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Paulgear1 asked on twitter: help on interpreting RFC4890. I still havent turned on IPv6 because Im not confident in my firewall.

First of all, what is RFC4890 all about [1]? The RFC is considered informational, not a standard. Usual guidance for IPv4 is to not block ICMP error messages, but one can get away with blocking all ICMP messages.

The situation is a bit different when it comes to ICMPv6. At first sight, the protocols look very similar. There is a type, a code and a checksum making up the header. But as you dig deeper, the differences become more obvious. First of all, the protocol number for ICMPv6 is 58 (0x3a), not 1 as for ICMPv4. Secondly, the types are defined differently. In part, the ICMPv6 types are defined with firewalls in mind: Messages with a code of 1-127 are considered error messages, and 128 and up are informational messages. [2]

ICMPv6 adds two very important features. It is used for neighbor discovery instead of ARP, router advertisements which are an important part of IPv6 auto configuration. Blocking these link local ICMPv6 messages at a host based firewall is of course a very bad idea, like blocking ARP. But blocking ICMPv6 at the border is an option. Blocking ND and RA messages at a border is usually not necessary as these are sent using link local addresses, and a TTL of 255 is required for the messages to be accepted.

RFC4890 suggests that Destination Unreachable (Type 1), Packet Too Big (Type 2), Time Exceed (Type 3) and Parameter Problem (Type 4) messages must not be dropped. Among these messages, the one that is the most important in IPv6, and different from IPv4 is the Packet Too Big message. In IPv4, routers fragment packets and packet too big messages are only used by path MTU discovery. Blocking them will typically not disrupt connections, but harm performance. In IPv6, routers no longer fragment packets. Instead the source does, after receiving a Packet Too Big ICMPv6 message. If they are blocked at the firewall, connection can not be established.

Now there is one trick you can play to eliminate fragmentation of outbound traffic in IPv6: Set your MTU to 1280 bytes. This is the minimum allowed MTU for IPv6, and a packet 1280 bytes long will not require any fragmentation. But this comes at the cost of having to use more and smaller packets, again a performance penalty.

So in short: Is it a good idea to block all ICMPv6 traffic coming into your network? Probably not. The performance penalty has to be carefully weighted against the risk of allowing the packets, which is small. But then again, this is pretty much the case for IPv4 as well.

[1] http://www.ietf.org/rfc/rfc4890.txt

[2] https://tools.ietf.org/html/rfc4443

------

Johannes B. Ullrich, Ph.D.

SANS Technology Institute

Twitter
(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Ive been trying for a few months now to get my lab running IPv6 natively, with mixed success. Whats standing in my way you ask? A couple of things, which in turn have further implications:



Barrier #1: IPv6 isnt free

First of all, if you want IPv6 addresses that will route on the internet, theyre not free. For instance, if youre within arin.nets jurisdiction, the fee schedule is here: https://www.arin.net/fees/fee_schedule.html. The fees are annual, none of these are one time prices.



Note that experimental addresses are still relatively cheaper (500 per allocation), but they expire in 12 months. Since I wont be folding my lab up anytime soon, I think Ill need to cave and buy a subnet. Note that the smallest allocation is a /48, which leaves a whopping 80 bits of address space to carve up - more than the entire IPv4 space. So for $1250, I (or any company who needs space) can make my routeable address problem go away.



What the implications of this are is quite different though. Currently, in the IPv4 world, most organizations assign RFC1918 addresses (private addresses) to their inside network, and then NAT those IPs out to a much smaller address space, which theyve purchased from their registrar, or that has been provided by their ISP. So migrating to a new ISP involves some firewall and router work, and, youve got a small address block to move either mvoe to a new ISP, or get a new block from your new ISP and change all your DNS entries (and VPN tunnels) to the new subnet.



In the IPv6 world, well see folks in two camps. Those who have purchased a routable block and used those on their inside network will be in one camp. Theyre very mobile, and will be able to change ISPs very readily. However, theyll also need a much deeper network skillset, as theyll likely need to run an external routing protocol, peering with their ISP using the BGP routing protocol to advertise their subnet (note that this could also be done statically). The smaller organizations who have been given IPv6 space by their ISP however will be in a different situation, and faced with two problems. Once they implement IPv6 using ISP address space, changing ISPs will involve renumbering their entire inside address space, changing the IPv6 address of every server, workstation, printer and access point. Not only is this a large, disruptive project in the best of situations, these small companies generally are not well-equiped to understand or deliver on such a project. So once they have implemented IPv6, they are essentially chained to their ISP, or need to bring in outside help to migrate.

Barrier #2: Check your Network Hardware and OS

For the most part, newer network hardware such as routers, switches and firewalls - say anything sold in the last 5 years or so - is IPv6 capable. However, the OS running on that hardware isnt neccessarily ready, or it may have known problems. Plus its not uncommon at all to find network gear in rack thats older and is *not* IPv6 ready (how many Cisco PIX units are still in service for instance - PIXs will do IPv6, but only from the CLI in the newest of new IOS versions, no ASDM support). Be sure you check your gear and the OS running on it before committing to a final budget on your IPv6 project !

Barrier #3: IPv6 still isnt everywhere (yet)

I live and work mostly in Canada, so my lab is also north of the 49th. Even now, 2 years after the IPv4 address space has been fully allocated (https://www.arin.net/announcements/2011/20110203.html) and 10 years after our ISPs and WAN providers have all known what was coming, many, if not most providers are just starting down the path. Weve gone from not at this time to well be there in 6-8 months list with almost every WAN provider, telecom and ISP in Canada for the last 3-4 years. Even my current lab ISP, who has extensive blog postings on why you should migrate, will not have IPv6 for my area until May/June (of this year, I hope!). This is frustrating to me, because any gear that supports MPLS or supports a full internet BGP table has been IPv6 capable for several years now - this is purely a problem of assigning technical folks to do the work at the ISPs and WAN providers.

So if you want native, routed IPv6, in many cases youre looking at using a tunnel broker such as Hurricane Electric to give you transport. What this means to me is that my IPv6 traffic now (all) needs to traverse a third party that is not my ISP. Given that Im generally running one or more security assessments or penetration tests, or otherwise messing with my datastream, giving more folks than neccessary access to my packets does not fill me with joy, especially since I dont have any kind of contractual agreement with a free tunnel broker. Given how easy ettercap, sslstrip and other MITM tools are to run, or even how much information you can glean from simple netflow/sflow, Id as soon limit that sort of exposure. If your internet traffic might carry confidential data, especially using SSL for encryption, Id suggest that you might not be thrilled with a tunnelling solution either.



So, while Im getting the purchase of my address space all worked out this month, Im still firmly rooted in the IPv4 world until later this summer, no matter how much Id like to have a foot in each version.

If youve completed your IPv6 project, or if you are still planning one out, wed love to hear about any roadblocks or problems youve identifed or overcome - please use our comment form !



===============

Rob VandenBrink

Metafore
(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Apple has released a security bulletin indicating they have updated the web plug-in blocking mechanism to disable versions of Java older than Java 6 update 41 and Java 7 update 15. Review the links below on how you might be affected.

[1] http://support.apple.com/kb/HT5677

[2] http://support.apple.com/kb/HT5660

-----------

Guy Bruneau IPSS Inc. gbruneau at isc dot sans dot edu
(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Wireshark released updates for version 1.6.14 and 1.8.6 to fix several vulnerabilities (multiple CVEs have been fixed). See the Wireshark announcements for the complete list of fixes.

You can download the latest versions here.

[1] http://www.wireshark.org/lists/wireshark-announce/201303/msg00000.html

[2] http://www.wireshark.org/lists/wireshark-announce/201303/msg00001.html

[3] http://www.wireshark.org/download.html

-----------

Guy Bruneau IPSS Inc. gbruneau at isc dot sans dot edu
(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

[Guest Diary: Stephen Groat] [Geolocation Using IPv6 Addresses]

Today we bring you a guest diary from Stephen Groat where he speaks about validating that IPv6 address tracking and monitoring are possible.

IPv6 designers developed a technique called stateless address autoconfiguration (SLAAC) to reduce the administrative burden of managing the immense IPv6 address space. To most operating systems current accepted definition of SLAAC, a nodes IPv6 addresss interface identifier (IID), or host portion, is deterministic across networks. For the last 64 bits, the node automatically configures an address on the basis of its network interfaces media access control (MAC) address. Even operating systems that obscure addresses according to Request for Comments (RFC) 4941 contain a static IID used for neighbor solicitation. These static IIDs can identify a particular node, even as the node changes networks.



Using Virginia Techs campuswide IPv6 production network, which supports more than 30,000 IPv6 nodes daily, we were able to validate that IPv6 address tracking and monitoring are possible. We tested an Android mobile device using MAC-based IIDs to form wireless IPv6 addresses.



[Figure 1]

The first part of our test involved tracking the mobile device as it moved around campus. Geotemporal tracking was possible because the campus network contains different subnets that cover different geographic areas. We programmed a script that continually sent echo requests to the different subnets on campus. When we received an echo reply, we stored its time and location. Figure 1 demonstrates the results of a successful tracking attempt.



The second part of our test involved traffic monitoring. Our goal was to demonstrate that we could isolate a node, regardless of subnet, and collect all of its associated network traffic. We placed a sensor at the network border to collect all IPv6 traffic leaving the network. Using a packet sniffer, we successfully filtered the traffic related to the node in question across different subnets.



Post suggestions or comments in the section below or send us any questions or comments in the contact form on https://isc.sans.edu/contact.html#contact-form

--

Adam Swanger, Web Developer (GWEB, GWAPT)

Internet Storm Center https://isc.sans.edu
(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Post suggestions or comments in the section below or send us any questions or comments in the contact form on https://isc.sans.edu/contact.html#contact-form

--

Adam Swanger, Web Developer (GWEB, GWAPT)

Internet Storm Center https://isc.sans.edu
(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

IPv6 in this part of the planet is not very advanced, as in the deployment isnt. Whilst companies and telcos realise that the end so to speak is nigh for IPv4 uptake is rather slow in AU at least. Telcos are however quickly addressing this and no doubt a number of them are close to enabling IPv6 to your gateway. If they havent already. This brings be to my favourite devices, firewalls.

During a bunch of security reviews over the last year or so we typically spend a little bit of time looking at the IPv6 setups and requirements in the organisations. We certainly found that people quite readily state they have no IPv6 in their environment, however often when they RDP, SSH or otherwise connect to a more recent version of insert your favourite OS here, the connection is most definately IPv6. When you then look at firewall configurations you often find nice looking IPv4 rules to control traffic and a less than ideal default for IPv6 ANY, ANY, ANY permit. So does that mean when your telco enables IPv6 to your gateway, traffic can leave? Potentially yes, it does depend on a number of other factors, but the core of it is that people do not realise they may be leaking. Even if traffic to the internet is restricted, what about other network segments? In a PCI DSS pentest, connectivity via IPv4, nope, nicely segmented. IPv6 please come through, full access.

Another thing to remember with firewalls is that IPv6 is relatively new to them as well. So maybe you need to check out whether your product does support IPv6 and if the answer is yes, to what extent.



What about other devices in the network, your switches and routers. will their current or even latest OS support you IPv6 requirements. Printers, Multifunction devices etc, do they support it. Do they have defaults that really do not help you out from a security perspective.



For today that is what I would like to hear from you. What devices have you come across that have interesting IPv6 defaults. Maybe they dont support it fully. Maybe they just get it wrong. One firewall a few years ago (fixed now) did IPv6 to IPv4 translation a bit diferrently and mangled the IPv4 packets that resulted. So what are your IPv6 watch out for this tips?



Mark
(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Richard Porter --- ISC Handler on Duty
(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Richard Porter --- ISC Handler on Duty
(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Richard Porter --- ISC Handler on Duty
(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

I would like to start our focus month with a simple post about what many consider the IPv6 killer feature: Addresses. There are a number of issues that come up with addresses, and you need to understand them when you deploy IPv6.

First of all, the IPv6 address is 128 Bits long. But unlike for IPv4, subnetting is a bit more restricted. The first 64 bits specify the network, while the second half of the address identify the host. Other then in a few, very specific cases (e.g. P2P links), you will never see a subnet smaller then a /64.

Here, I would like to focus on different ways to come up with the last 64 bits. There is a reason we have so many bits. The goal is to allow each host to configure itself without running into any conflicts. The simplest way to do this on ethernet is to derive the interface id from the MAC address. The mac address is only 48 bits, and it has to be unique for each host on the local network. As a result, we can just use these 48 bits as our interface ID. This works really nice, but has privacy implications: You will now pass your MAC address to each host you communicate with, and this part of the IP address will never change even if you move to a different network.

To respond to this we do have privacy enhanced temporary addresses. In this case, an address is picked randomly, and once a day the host will pick a new random interface ID. Chances of an overlap are pretty small and the host will check if the new address is already in use.

These methods dont require any infrastructure. A router will advertise the network part of the address, and the hosts will just pick the interface part using their prefered mechanism. But for us security people, the scary part is that there is no logging happening. We cant show who owned what address when. In particular the idea of temporary addresses is quite scarry for an enterprise network.

The solution, just like in IPv4, is DHCP. DHCPv6 can be used just like in IPv4 to assign addresses. However, if you try to achieve some kind of accountability, you have to make sure that these are the only addresses used. For example, you could use a firewall to restrict network access to allow only access from addresses within the valid DHCP range.

Of course, users could always manually configure an address within the range that is valid on your network, just like they could in IPv4. In IPv6, this is a bit easier as you have more addresses to pick from. You probably would like to have some form of passive system to monitor for new IPv6 addresses. However, in IPv6, you can not use ARP traffic. IPv6 replaces ARP with Neighbor Discovery (ND) and you need to find a tool that supports ND.

Here are a couple of guidelines:

- For an unmanaged network (home network, guest wifi), autoconfigured privacy enhanced addresses are probably what you want.

- For a managed network (business, enterprise...), you should still use DHCP or static configured addresses just like in IPv4.

- the basic attacks are still the same in IPv6, nothing really changed. IPv6 has an option called SEND to make ND and router advertisement more secure, but the protocol isnt implemented in any of the major OSs yet.

Vulnerabilities and Attacks:

The ND protocol is subject to many of the same attacks as ARP:

- ND spoofing to play MitM attacks

- Denial of service attacks by responding to all ND requests

- address spoofing

The THC IPv6 Tool Suite has implementations for many of these attacks. We will talk about this suite in a future Focus Month diary, as well as about scapy, probably the most powerful tool to create IPv6 traffic.



------

Johannes B. Ullrich, Ph.D.

SANS Technology Institute

Twitter
(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

A reader has written in and stated an observation of increased MSSQL Activity. Has anyone else noticed this? If so, please let us know... Thanks!!

Richard Porter

--- ISC Handler on Duty
(c) SANS Internet Storm Center. http://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.