Pages

Showing posts with label security. Show all posts
Showing posts with label security. Show all posts

Monday, October 13, 2014

Change passwords regularly - a myth and a lie, don't be fooled, part 2

In the previous blog post, I have covered the different passwords you have to protect, the attackers and attack methods. Now let's look at how we want to solve the issue.

Password requirements

So far we have learned we have to use long, complex, true random passwords. In theory, this is easy.
Now, this is my password advice for 2014:

Password character classes
Use upper-lower-digit-special characters in general cases.
If you don't understand what I just write, choose from this:
qwertyuiopasdfghjklzxcvbnmQWERTYUIOPASDFGHJKLZXCVBNM0123456789-=[];'\,./<>?:"|{}_+!@#$%^&* ()`~
If you are a CISO, and say: use 3 out of 4 character class, everyone will use Password12 or Welcome12 as their password (after the 12th enforced password change).

Password length
This is basically the only thing which changes whether the password is in the very high/high/medium/low level. Check the previous blog post for the details about very high/high/medium/low level.

Password length: Very high level class (including work-related/enterprise passwords)
15 character (or 20 if you are really paranoid). Making true random passwords longer than 20 characters usually does not make any sense, even in high security scenarios (e.g. military, spy agencies, etc.). 15 character in Windows environment is a right choice, as LM hash is incompatible with 15 character passwords, thus one (effective) attack won't work. Beware, there might be bugs with using 15 character passwords, with a low probability.

Password length: High-level class
12 character, upper-lower-special characters

Password length: Medium class
10 character, upper-lower-special characters, still TRUE random

Password length: Low-level class
9 character. Why less?

Pin codes
Always choose the longest provided, but a maximum of 8. Usually, more is pretty impractical.

Password randomness
True random, generated by a (local) computer. Avoid Debian. Avoid random generated by your brain. Do not use l33tsp33k. Do not append or prepend the current month, season or year to a word. Do not use Star Wars/Star Trek/(your favorite movie/series here) characters or terminology. In general, avoid any pattern like the above ones. The chances that a true random password generator generates SkyWalker12 is very-very low. And believe me, it is not that hard to crack those. Every algorithm that you would come up with; the bad guys have already thought of it. Use true random. Let the computer do it for you. See details later in this post.

Password history
Never-ever reuse passwords. NEVER!

Password change period
If it is not enforced otherwise, don't bother to change it twice in a year. But! Check if the password cracking speed made your current ones obsolete. If yes, change the obsolete passwords. Immediately change the password if you have been notified that the service you use has been compromised. Immediately change all of your recently used passwords if you suspect malware was running on your computer (do this on a known clean computer). Immediately change your password if you have used it on a computer you don't own, or there is a small chance malware is running on it. Change it if you really had to give your password to someone. Otherwise, goodbye regular password change. We will miss you...

If you are a CISO, and writing security policies, you should have to enforce the password change period based on: do you allow LM hashes? What is the password length requirement for users and administrators? What is the current hash cracking speed, and the forecast for the next 2 years? I think people would be happy to increase their passwords with 1-2 characters, if they are not forced to change it frequently (e.g. every month).
Now after I was sooo smart giving advises people still hate to implement, let's see the practical implementations. At least some people might like me, because I told them not to change the passwords regularly. Next time someone tells you to change all your important passwords regularly, put a lie detector on him, and check if he changes all of his passwords regularly. If he lies, feel free to use the wrench algorithm to crack his passwords. If he was not lying, call 911, to put a straitjacket on him. Only insane paranoid people do that in reality. Others are just too scared to say "what everyone recommended so far is bullshit". Comments are welcome ;) Other people might hate me for telling them using true random passwords. Don't panic, keep reading.
And don't forget to use 2 factor authentication. It might seem a bit of an overkill at the beginning, but after months, you won't notice using it.

(Bad and good) solutions

I will use the same password everywhere

This is a pretty bad idea. If one of the passwords are compromised, either the attackers can access your other sites, or you have to change all of your passwords. There are better ways to spend your life on earth than changing all of your passwords.

I will remember it

Good luck remembering 250 different, complex passwords. Don't forget to change them regularly! ;)

I will use the password recovery all the time

Not a very user-friendly solution. And because the security answer has to be as complicated as the password itself, the problem has not been solved.

I will write it down into my super-secret notebook and put it in my drawer

Although it might work in some cases, it won't work in others. I don't recommend it.





I will use an algorithm, like a base password, and add the websites first letters to the end of the password

Still better than using the same password everywhere, but believe me, if this is a targeted attack, it is not that hard to guess your password generation algorithm.

I will use the advice from XKCD, and use the password correcthorsebatterystaple

Still a lot better than simple passwords, but unfortunately, people are still bad at choosing random words with random order, so it is not the best solution. And again, you can't memorize 250 different passwords ... Even 10 is impossible. Only use this method in special corner cases (see details later), and use a passphrase generator!

I will use a password manager

This is the very first good idea. It solves the problem of remembering 250 different complex and random passwords. Some people might complain about using a password manager, here are those complaints. And my answers:

If someone gets access to this one password store, all is lost.
Answer: If someone accessed your password store, and the master password, you can be pretty damn sure that most of your passwords are already stolen. For extra paranoids, you can use multiple password stores, one for daily use, one for rare cases. Beware not to forget the password for the second one ;)

What if I don't have access to the password store when I need it?
Answer: In the age of cheap notebooks, tablets, and smartphones, in 99% of the cases you should not use that important password on any other device than yours. In the rare cases when you must, you can use either your smartphone to get the password, or use a browser extension like Password hasher to generate different passwords to different websites, with one password. For extra paranoids, you can have different master passwords for the different security levels. And don't forget to change the password after you are back at your own computer.

What if I forgot the one password to the password store?
Answer: If you use your password manager daily, it has the same odds to forget that one password as it is to forget every one of your passwords.

Password managers make phishing attacks easier.
Answer: Who started this nonsense? Good password managers decrease the risk of phishing.

Password managers have the same vulnerabilities as other websites or software.
Answer: Well, this is partially true. There are at least 3 types of password managers, from most secure to least: offline, browser built-in, online. Online password managers give better user experience, with a sacrifice in security. But if you choose one of the leading password managers, and you are a simple home user, the risks are negligible. If you try to store your work password in an online password store, you might violate your internal security policy. For paranoids, use offline password managers, and back them up regularly. If you choose an online password manager, at least use 2-factor authentication. And don't forget, your Chrome password can be easily synchronized to the cloud, shifting it to the online category.

In some cases, like Full Disc Encryption, OS login, smartphone login, or password manager login, the auto-type of password from the password manager is not available, thus choosing a true random password is a pain in the a$$.
Answer: True. Generate pronounceable passwords or passphrases in these corner cases, e.g. with the Linux tool apg you can generate pronounceable passwords. For easy and fast type, don't use capital letters (only lower-alpha - digit - special) in the original password, but increase the length of the password. Add 1 extra character because you don't use upper case letters, add 3 other because it is a pronounceable password, and you are good to go. For extra paranoids change one or two of the letters to uppercase where it is convenient. 
apg -M SNL -m 15 is your friend.
If you want to check what I write here (always a good idea), test the entropy of a true random 10 character password with all character classes, and check it with 14 characters, without uppercase. I recommend KeePass for that. If you comment on this that "Keepass can not measure that it is a pronounceable password, thus the entropy is lower in reality", my answer is: "Check out the current passwords used by users, and current password advises, and tell me if this password is a lot better or not ..." . You have been warned.
 

For the high-level password class, I don't recommend anything your brain generated. There are also suitable offline passphrase generators. Use at least 5-6 words for passphrases.

Password managers are not user-friendly, it takes more time to log in.
Answer: If you set auto-type/auto-fill, and the password manager is opened once a day (and you lock your computer when you leave it), in this case, logging in takes less time than typing it! It is more convenient to use it, rather than typing the passwords every time.

I like to create new unique passwords every time I create a new account, and password managers take the fun away from it.
Answer: Said no one, ever! "38 percent of people think it sounds more appealing to tackle household chores – from folding the laundry to scrubbing toilets – than to try and come up with another new user name or password."

To summarize things. Use a password manager.

General advise

Never use your essential passwords on other computers. They might be infected with a password stealer. If you really have to use it, change the password as soon as possible on a trusted (your) computer.

Don't fool yourself by phishing sites. If you go to the local flea market, and there is a strange looking guy with "Superbank deposit here" logo above his head, will you put your money?

Protect yourself against malware. Use a recent operating system, and even if you use OSX or Linux, it is not a bad thing to have an AV as a "last line of defense". Or to check your pendrive for Windows USB worms.

Never-ever use online web sites to "generate your password", "measure the complexity of your password" or "check if it has been breached". Never! (Except if it is your password manager :) ... )

Update: Sign up on the https://haveibeenpwned.com/ for notification if your e-mail is found in a leak.

Changing passwords frequently is bad advice. It is not effective. Put more energy in other right password advise. 

Wednesday, October 1, 2014

Change passwords regularly - a myth and a lie, don't be fooled, part 1


TL;DR: different passwords have different protection requirements, and different attackers using various attacks can only be prevented through different prevention methods. Password security is not simple. For real advise, checking the second post (in progress).

Are you sick of password advices like "change your password regularly" or "if your password is password change it to pa$$w0rd"? This post is for you!

The news sites are full of password advises nowadays due to recent breaches. When I read/watch these advise (especially on CNN), I am usually pissed off for a lot of reasons. Some advises are terrible (a good collection is here), some are good but without solutions, and others are better, but they don't explain the reasons. Following is my analysis of the problem. It works for me. It might not work for you. Comments are welcome!

Password history

Passwords have been used since ancient times.


Because it is simple. When I started using the Internet, I believe I had three passwords. Windows login, webmail, and IRC. Now I have ~250 accounts/passwords to different things, like to my smartphone, to my cable company (this password can be used to change the channels on the TV), to my online secure cloud storage, to full disk encryption to start my computer, to my nude pictures, to my WiFi router, to my cloud server hosting provider, etc etc etc. My money is protected with passwords, my communication is protected with passwords/encryption, my work is protected with passwords. It is pretty damn important. But yet people tend to choose lame passwords. Pretty lame ones. Because they don't think it can be significant. But what is not essential today will be relevant tomorrow. The service you used to download music (iTunes) with the lame password will one day protect all your Apple devices, where attackers can download your backup files, erase all your devices, etc. The seven-character and one capital rule is not enough anymore. This advice is like PDF is safe to open, Java is secure. Old, outdated, untrue.

Now, after this lengthy prologue, we will deep dive into the analysis of the problem, by checking what we want to protect, against whom (who is the attacker), and only after that, we can analyze the solutions. Travel with me, I promise it will be fun! ;)

What to protect?

There are different services online, and various services need different ways to protect. You don't use the same lock on your Trabant as you do on your BMW.

Internet banking, online money

For me, this is the most vital service to protect. Luckily, most of the internet banking services use two-factor authentication (2FA), but unfortunately, not all of them offer transaction authorization/verification with complete transactions. 2FA is not effective against malware, it just complicates the attack. Transaction authorization/verification is better, but not perfect (see Zitmo). If the access is not protected with 2FA, better choose the best password you have (long, real random, sophisticated, but we will get to this later). If it is protected with 2FA, it is still no reason not to use the best password ;) This is what I call the "very high-level password" class.


Credit card data

This system is pretty fucked up bad. Something has to be secret (your credit card number), but in the meantime that is the only thing to identify your credit card. It is like your username is your password. Pretty bad idea, huh? The problem is even worse with a lot of different transaction types, especially when the hotel asks you to fax both sides of your CC to them. Unfortunately, you can't change the password on your credit card, as there is no such thing, but Verified by VISA or 3-D Secure with 2FA might increase the chances your credit card won't get hacked. And on a side note, I have removed the CVV numbers from my credit/debit cards. I only read it once from the card when I received it, I don't need it anymore to be printed there.
And sometimes, you are your own worst enemy. Don't do stupid things like this:


Work related passwords (e.g. Windows domain)

This is very important, but because the attack methods are a bit different, I created this as a different category. Details later.

Email, social sites (Gmail/Facebook/Twitter), cloud storage, online shopping

This is what I call the "high level password" class.
Still, pretty important passwords. Some people don't understand "why would attackers put any energy to get his Facebook account?" It is simple. For money. They can use your account to spread spam all over your Facebook wall. They can write messages to all of your connections and tell them you are in trouble and send money via Western Union or Bitcoin.


They can use your account in Facebook votes. Your e-mail, cloud storage is again very important. 20 years ago you also had letters you didn't want to print and put in front of the nearest store, neither want you to do that with your private photo album. On a side note, it is best to use a cloud storage where even the cloud provider admin can't access your data. But in this case, with no password recovery option, better think about "alternative" password recovery mechanisms.

Other important stuff with personal data (e.g. your name, home address)

The "medium level password" class. This is a personal preference to have this class or not, but in the long run, I believe it is not a waste of energy to protect these accounts. These sites include your favorite pizza delivery service, your local PC store, etc.

Not important stuff

This is the category other. I usually use one-time disposable e-mail to these services. Used for the registration, get what I want, drop the email account. Because I don't want to spread my e-mail address all over the internet, whenever one of these sites get hacked. But still, I prefer to use different, random passwords on these sites, although this is the "low level password" class.

Attackers and attack methods

After categorizing the different passwords to be protected, let's look at the different attackers and attack methods. They can/will/or actively doing it now:

Attacking the clear text password 

This is the most effective way of getting the password. Bad news is that if there is no other factor of protection, the victim is definitely not on the winning side. The different attack methods are:

  • phishing sites/applications,


  • social engineering,
  • malware running on the computer (or in the browser), 
  • shoulder surfing (check out for smartphones, hidden cameras), 
  • sniffing clear-text passwords when the website is not protected with SSL,
  • SSL MiTM,
  • rogue website administrator/hacker logging clear text passwords,
  • password reuse - if the attacker can get your password in any way, and you reuse it somewhere else, that is a problem,
  • you told your password to someone and he/she will misuse it later,
  • hardware keyloggers,
  • etc.

The key thing here is that no matter how long your passwords are, no matter how complex it is, no matter how often do you change it (except when you do this every minute ... ), if it is stolen, you are screwed. 2FA might save you, or might not.

Attacking the encrypted password 

This is the usual "hack the webserver (via SQL injection), dump the passwords (with SQLMap), post hashes on pastebin, everybody starts the GPU farm to crack the hashes" scenario. This is basically the only scenario where the password policies makes sense. In this case the different level of passwords need different protection levels. In some cases, this attack turns out to be the same as the previous attack, when the passwords are not hashed, or are just encoded.

The current hash cracking speeds for hashes without any iterations (this is unfortunately very common) renders passwords like Q@tCB3nx (8 character, upper-lowercase, digit, special characters) useless, as those can be cracked in hours. Don't believe me? Let's do the math.

Let's say your password is truly random, and randomly choosen from the 26 upper, 26 lower, 10 digit, 33 special characters. (Once I tried special passwords with high ANSI characters inside. It is a terrible idea. Believe me.). There are 6 634 204 312 890 620 different, 8 character passwords from these characters. Assuming a 2 years-old password cracking rig, and MD5 hash cracking with 180 G/s speed, it takes a worst case 10 hours (average 5) to crack the password, including upgrading your bash to the latest, but still vulnerable bash version. Had the password been 10 characters long, it would take 10 years to crack with today hardware. But if the password is not truly random, it can be cracked a lot sooner.

A lot of common hashing algorithms don't use protections against offline brute-force attacks. This includes LM (old Windows hashes), NTLM (modern Windows hashes), MD-5, SHA1-2-512. These hashing algorithms were not developed for password hashing. They don't have salting, iterations, etc. out of the box. In the case of LM, the problem is even worse, as it converts the lowercase characters to uppercase ones, thus radically decreasing the key space. Out of the box, these hashes are made for fast calculation, thus support fast brute-force.


Another attack is when the protected thing is not an online service, but rather an encrypted file or crypto-currency wallet.

Attacking the authentication system online

This is what happened in the recent iCloud hack (besides phishing). Attackers were attacking the authentication system, by either brute-forcing the password, or bypassing the password security by answering the security question. Good passwords can not be brute-forced, as it takes ages. Good security answers have nothing to do with the question in first place. A good security answer is as hard to guess as the password itself. If password recovery requires manual phone calls, I know, it is a bit awkward to say that your first dog name was Xjg.2m`4cJw:V2= , but on the other hand, no one will guess that!


Attacking single sign on

This type of attack is a bit different, as I was not able to put the "pass the hash" attacks anywhere. Pass the hash attack is usually found in Windows domain environments, but others might be affected as well. The key thing is single sign on. If you can login to one system (e.g. your workstation), and access many different network resources (file share, printer, web proxy, e-mail, etc.) without providing any password, then something (a secret) has to be in the memory which can be used to to authenticate to the services. If an attacker can access this secret, he will be able to access all these services. The key thing is (again) it does not matter, how complex your passwords are, how long it is, how often do you change, as someone can easily misuse that secret.

 

Attacking 2FA

As already stated, 2 factor authentication raises the efforts from an attacker point of view, but does not provide 100% protection. 
  • one time tokens (SecurID, Yubikey) can be relayed in a man-in-the-middle attack
  • smartcard authentication can be relayed with the help of a malware to the attacker machine - or simply circumvented in the browser malware, 
  • text based (SMS) messages can be stolen by malware on the smartphone or rerouted via SS7, 
  • bio-metric protection is constantly bypassed,
  • SSH keys are constantly stolen,
  • but U2F keys are pretty good actually, even though BGP/DNS hijack or similar MiTM can still circumvent that protection,
  • etc. 


Others

Beware that there are tons of other attack methods to access your online account (like XSS/CSRF), but all of these have to be handled on the webserver side. The best you can do is to choose a website where the Bug Bounty program is running 24/7. Otherwise, the website may be full of low hanging, easy-to-hack bugs.

Now that we have covered what we want to protect against what, in the next blog post, you will see how to do that. Stay tuned. I will also explain the title of this blog post.

Monday, January 6, 2014

DNSSEC, from an end-user perspective, part 2

In our previous blog post, we have discussed some of the threats against current DNS systems, where the result was that the victim landed on a different resource/website as he/she originally supposed to visit.

Since this is not a guide for DNS server operators about DNSSEC implementation, let's jump to the user side and see what you should know if you visit a website where DNSSEC validation fails (like the test site http://www.dnssec-failed.org/) and you use a DNS server which validates the DNSSEC responses (e.g., 8.8.8.8 - Google public DNS server):


So far, so good :-) The malicious attacker's evil plan has failed. But what should you see when the server is protected with DNSSEC, and the DNSSEC response is valid/trusted?


Please note that this "green key" stuff is for experimental purposes only. I hope the users should not have to look for another SSL-like padlock in their browser in the future. The critical thing here is that the site has been rendered by the browser, and the response is protected by DNSSEC, thus eliminating lots of threats.

When you visit a site that is protected by DNSSEC, but your DNS server does not validate the DNSSEC, the site will be served and rendered in your browser. It does not matter if it has untrusted or invalid DNSSEC records. This is the same experience what you have today with no DNSSEC at all:


OK, so we, as end-users, need sites/domains which are protected with DNSSEC, and a DNS server which validates the DNSSEC records. We have the DNS server (thx Google!), so let's find some popular sites which are using DNSSEC!


To demonstrate my 133t h4cking skills, here is a small bash script. You give a file with the list of domains as a first parameter to the bash script, and it will give you back the areas protected with DNSSEC.

#!/bin/bash
dig . DNSKEY | grep -Ev '^($|;)' > root.keys
while read line
do
    if dig +sigchase +trusted-key=root.keys $line. A @8.8.8.8 | grep --quiet "DNSSEC validation is ok: SUCC"; then
        echo $line
    fi
done < $1

Alexa was not kind enough to give me a recent list of top sites in text format, so I have used http://moz.com/top500 for this test.

The results were quite shocking; the first result was at TOP40: gov.uk - but when you visit gov.uk via browser, it is redirected to a subdomain that is not protected with DNSSEC, so this kind of behavior is considered as FAIL.

TOP69: nih.gov  - so ironically, the winner is the National Institute of Health :P

Other interesting one where:

mozilla.org - FAIL 
cdc.gov - FAIL
nasa.gov - FAIL :(
ca.gov  - California homepage, don't mess with Arnie!
noaa.gov - National Oceanic and Atmospheric Administration :)
berkeley.edu - thank god the world of universities is saved
loc.gov - FAIL
whitehouse.gov - FAIL …

I think I have never ever visited these websites before, except the Berkeley one. If you can find a financial institution which website's domain is protected by DNSSEC, let me know. I was not able to find one… For example, paypal.com is a bad example. The main domain is protected with DNSSEC, but not the www.paypal.com.

In the next part of our DNSSEC series, I will write about the threats eliminated by DNSSEC and some other exciting things.

Friday, November 29, 2013

Secure IPv6 deployment checklist: think twice, deploy once

Before deep-diving into IPv6, I'm going to summarize my views on IPv6:
  1. Start now(!) to plan your IPv6 deployment - in case you have not done so.
  2. IPv6 is the future! There is no other choice.
  3. NAT is the root of all evil.
IPv6 is coming. We've heard this 10 years ago as well, but it is really coming now. If you live in Asia, you can see this in real life. If you live in Europe or the USA, you can feel the pain of triple NATed devices.

Deploying IPv6 is not a binary task, you can do it in small steps. Get a public IPv6 address space, assign IPv6 addresses to your servers (e-mail, web, DNS).

Great, you are now ahead of the world!

Now, what about clients who want to access IPv6 web or email? You are lucky if you use an IPv6 compatible web/email proxy because the clients can still stay on IPv4.

Now, what about your clients/servers accessing IPv6 services on the Internet directly (without a proxy)?
  • If your network supports IPv6, your clients can directly access IPv6 services. 
  • If your network does not support IPv6, clients can still use tunneling protocols, e.g. ISATAP for Windows clients.
This might sound easier than it is. But do you have the budget/people/management support to do this?

Anyways, before you deploy IPv6 in your corporate environment, you have to think about the security issues. The next list is far from comprehensive or complete. Beware, here be dragons!

It is a myth that IPv6 is more secure than IPv4. The only practical security addition in IPv6 is called IPSEC, and has been backported to IPv4 many years ago.

Most networking people are not familiar with the new terms, best practices introduced with IPv6. It is important to educate the networking and security personnel about IPv6, and let them play with the technology.
IPv6 can reintroduce basically all security vulnerabilities which has been mitigated in IPv4:
  • If the vulnerability is not in the IP layer, the vulnerability will stay there. Although it sounds obvious, most people tend to forget this. Your MS08-067 vulnerability won't magically disappear if you use IPv6. OK, but you closed port 445 on the firewall. Oh crap, it is open on IPv6...
  • Man-in-the-middle attacks: Organizations have already guarded themselves against ARP spoofing and DHCP server spoofing with mitigation techniques like DAI (Dynamic ARP Inspection) and DHCP snooping in the world of IPv4. The only thing which has been changed is the name of the attacks and defenses. Search for ICMPv6 attacks, and Neighbour Discovery attacks.
  • Source routing: Source routed IPv4 packets have not been seen for a while bypassing firewalls, but "luckily" the IPv6 standard reintroduced source routing in IPv6, in the name of Type 0 Router Headers. You should check whether your OS/network equipment support Type 0 Router Headers. If you have time, play with Scapy to test it.
  • Blocking ICMP: Let's face the truth: In order to effectively use IPv6, some ICMPv6 messages has to traverse through firewalls. Like it or not, you can't hide your clients anymore.
  • Router advertisement: Let's play a game. Go into any network, and start broadcasting IPv6 router advertisement packets in the network. Guess what, the clients are going to connect to you, and you will be the default IPv6 gateway for the clients. If there is no web proxy configured on the client, this means all Google, Youtube and Facebook traffic will be routed through your box, because IPv6 is preferred over IPv4. This can be the next generation WPAD attack :) If you don't want to be vulnerable, better search for RAGuard or similar solutions.
  • Translation/tunneling: If all your network equipment support IPv6 and configured to use it, you are lucky, because your clients can use native IPv6. Otherwise, your clients have to use 6to4/ISATAP/Teredo/NAT64 or whatever IPv6 translation/tunneling. Do you know these protocols? Do your security products know these protocols?
  • Dual stack: Your clients have to use both IPv4 and IPv6 together for a while. Be aware of the additional operating costs of maintaining 2 network protocol parallel.
  • Fragmentation: In the first era of IDS/IPS devices, one of the main bypassing technique was IPv4 fragmentation. Have you checked whether your current solutions (IPS/IDS) parse fragmented packets the same way as your protected assets?
  • The IPv4 implementations have been tested thoroughly, and not much implementation bug is left there. But IPv6 implementation bugs, there will be a lot from them. Most of the programmers still don't know the basics of secure coding practices.
  • IPv6 evercookie: Now that your clients don't have the same NAT IP, they static IP can be used to track them online. Luckily Microsoft solved the issue with IPv6 privacy extension, so clients will use temporarily IPv6 addresses to communicate with the Internet. Great, now how do you know in your security logs, which IPv6 address is which client???
Do your current security devices fully support IPv6? Have you tested this?
  • Hardware Firewall (with all dual-stack/translation/tunneling nightmare)
    • Do you block all outgoing UDP from the clients, especially 3544?
    • Can you maintain rules for both IPv4 and IPv6?
    • If you remove an IPv4 rule, do you remove the same rule for IPv6?
  • Log collection, log analysis, correlation:
    • Do the logs contain IPv6 addresses? 
    • Is it parsed by the SIEM application? 
    • Do you know that the DHCP IPv4 address is the same asset (workstation) as the IPv6 address with a privacy extension? 
  • IPS, IDS:
    • Can these applications monitor/block all kinds of IPv6 translation/tunneling protocols?
  • WAF:
    • Is your WAF IPv6 ready/aware?
    • What about fragmentation?
  • VPN:
    • Can your clients connect to IPv6 services through VPN?
    • Is your IPv6 VPN firewall rule as restrictive as the IPv4 one?
    • If you remove a rule on IPv4, do you remove the same in IPv6?
  • Software firewall:
    • Is your software firewall IPv6 ready/aware? 
    • Does it understand all translation/tunneling protocols? 
    • Does it filter incoming traffic to the Teredo interface?
  • AV/endpoint protection:
    • Is your AV/endpoint protection IPv6 ready/aware?
    • What about files downloaded via IPv6, is it scanned the same way as IPv4?
  • DLP (if you are in the 1% who actually bought one and enrolled it in production):
    • Is your DLP IPv6 ready/aware? 
    • Can it monitor tunneled traffics?
And last but not least, the bad news: you are already using IPv6 if you have Windows7 notebooks leaving your company, not having access to the domain controller. Or have you checked your servers link-local IPv6 addresses recently? Do you have a Windows2008 cluster? It is using IPv6 already!

The good news? In the not so far future (I estimate 2050) you can turn off your last device with IPv4 address, and forget all the nightmare around NAT and dual-stack. Because remember: NAT is not a security feature. It never was.