Howfunky.com

Perhaps it is a company policy or someone on your IT team feels it is important to block IPv6 tunneling across your network to 6to4 relays or Teredo relay servers or perhaps you only want internal folks using your delegated IPv6 address block. Do you have any options available to you to block this sort of traffic?

As it seems with all things tech related the answer is, it depends on what you want to do. Both 6to4 and ISATAP utilize IPv4 protocol 41 to tunnel their traffic. Therefore, it is easy enough to block IPv6 protocol 41 from traversing internally (which would stop ISATAP and 6to4) or at the edge firewall (which would stop 6to4 but might not stop ISATAP.) On Cisco IOS it might look like this on an internal router or switch:
access-list 100 deny 41 any any
access-list 100 permit any any (or whatever traffic you DO want to permit)

In addition, to this step you can blackhole the IPv4 route to 192.88.99.1 which is the IPv4 anycast address used for the 6to4 IPv4 relay. On Cisco IOS you could do:
ip route 192.88.99.1 255.255.255.255 null0

Teredo clients can be blocked in a simple method because by design it utilizes UDP over IPv4 to establish and build it's NAT traversal tunnel traffic. Simply blocking outbound UDP traffic solves the problem but certainly breaks a lot of other functions for end client machines.

If you are running a Microsoft Windows AD configuration with clients belonging to the domain you can poison the Teredo entry that is used by default on a Microsoft client machine. All Microsoft clients from Windows XP on up make use of the dns name teredo.ipv6.microsoft.com to resolve if they can utilize Teredo to build out an IPv6 connection. This likely isn't the best method but it can be effective and some might say required because from Windows Vista on up Teredo is enabled by default but is inactive. This means if an application gets installed that wants to make use of Teredo it activates the Teredo client and attempts to use it.

You can also use a GPO to change the registry keys to keep Teredo off. You can push firewall changes to the Windows clients (Vista and Windows 7) that would block Teredo or you could turn off IPv6 which would solve the problem also. Microsoft has documentation on all of those options, you can start looking here, here or here to find out more.

So, in those cases where you actually need to turn off IPv6 tunneling technologies there are options available. The next question is do you really want to block these technologies?
- Ed

Labels: IPv6, Microsoft, Security

There are many ways to help protect your network from attack, one of the simpilist and most effective is actually to filter incoming and outgoing traffic from your network. An excellent place to start is to utilize the rfc's to define IPv4 addresses that are not or never will be in use on the public Internet and not allowing that traffic inbound. In the same vein, you can use the same information to limit what is allowed to leave your network, such as only IPv4 addresses that are legitimately routable on the public Internet.

This is not a new or unique solution but it is more commonly done at the service provider and larger enterprise level because those type of operations pay attention to the rfc's but also because they recieve much higher traffic loads on average traditionally. I believe that this technique is still useful for much smaller operations to use and is relatively simple to set up and maintain.

Here is a short list of rfc's to put in your firewall or edge router of addresses you should not be seeing from the Internet and ones that you should consider filtering out before sending traffic out to the Internet.

network RFC 1112
description - Host Extensions for IP Multicasting - in RFC 1700 also
240.0.0.0 240.0.0.0

network RFC 1700
description - assigned numbers - multicast, current, host, and reserved
224.0.0.0 240.0.0.0
240.0.0.0 240.0.0.0
0.0.0.0 255.0.0.0
127.0.0.0 255.0.0.0

network RFC 1797
description - Class A Subnet Experiment - may get reallocated - use the bogon list instead
39.0.0.0 255.0.0.0

network RFC 1918
description - reserved private IPv4 addresses
10.0.0.0 255.0.0.0
172.16.0.0 255.240.0.0
192.168.0.0 255.255.0.0

network RFC 2544
description - Benchmarking Methodology for Network Interconnect Devices
198.18.0.0 255.254.0.0

network RFC 3068
description - IPv4 reserved 6to4 IPv6 gateway services
192.88.99.0 255.255.255.0

network RFC 3171
description - IANA Guidelines for IPv4 Multicast Address Assignments
224.0.0.0 224.0.0.0 (covers 224.0.0.0 through 255.255.255.255)

network RFC 3927
description - Dynamic Configuration of IPv4 Link-Local Addresses - in 5735 above
169.254.0.0 255.255.0.0

network RFC 5735 (update of RFC 3330)
description - this rfc really collects all the other rfc with special use (reserved and limited IPv4 blocks) in a single doc, these is only a partial listing
192.0.2.0 255.255.255.0
169.254.0.0 255.255.0.0
224.0.0.0 224.0.0.0
14.0.0.0 255.0.0.0 (may be reallocated - use the bogon list instead just in case)

network RFC 5736
description - IPv4 Special Purpose Address Registry
192.0.0.0 255.255.255.0

network RFC 5737
description - reserved for test net
198.51.100.0 255.255.255.0
203.0.113.0 255.255.255.0

Here are some reference URL's to get you started to determine what you should apply for your needs.
Wikipedia
IANA
Team CYMRU

In addition to using IP address list filters there are other protections you can take at the edge. You should consider putting more aggressive ICMP filters in and also filter specific IP protocol numbers from coming in or going out. I'll post more about that another time.
- Ed

Labels: bogon, IPv4, Security

Seems that password security is still a huge issue for enterprises and for consumers. The recent analysis report from Imperva is a little scary and enlightening at the same time. Granted this is analysis of consumer grade passwords for a website but it still offers insight into how people go about using and generating passwords.

Some fascinating items from the reports findings of the most common passwords:

1. 123456
2. 12345
3. 123456789
4. Password
5. iloveyou
6. princess
7. rockyou
8. 1234567
9. 12345678
10. abc123

I think given that the website was rockyou.com we can safely remove that one from the list. What you are left with are passwords that you should be eliminating as acceptable within your environment. In addition, the graphs show in the report that only 3.81% of users used special characters in their passwords. They also state "Nearly 50% of users used names, slang words, dictionary words or trivial passwords (consecutive digits, adjacent keyboard keys, and so on)."

Gets you thinking that OTP + pin or smartcards might be the only real way to enforce true high quality password security for consumers or enterprises.
- Ed

Labels: Passwords, Security