IPv6 Focus Month: Traffic Testing, Firewalls, ACLs, pt 1

Published: 2013-03-11
Last Updated: 2013-03-11 17:14:40 UTC
by Richard Porter (Version: 1)
0 comment(s)

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 manual’s 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

Keywords: ipv6 focus month
0 comment(s)
ISC StormCast for Monday, March 11th 2013 http://isc.sans.edu/podcastdetail.html?id=3175

Comments


Diary Archives