By now most of us know what Twitter is. Of do we? I spent more than a few months with a Twitter account and no real idea how to use it. At first it seemed a lot like re-branded Instant Messaging and I already have plenty of choices for that. Did I really need another one? My business partner Nick kept telling me, “Dude, you need to get on this. It’s big.” I wasn’t initially moved.

And then came the revelation: Twitter is not about instant messging. It is about promoting yourself to others. You can do it for business reasons or for personal ones, but one simple fact is true: Sell yourself 140 characters at a time. I’m not talking about spamming people. We’ve got plenty of that via other avenues (and Twitter is a victim, too). It’s about saying things that are quick, concise, relevant and interesting about what is happening in your world. If you say things that are not boring, people will follow you. You don’t have to find followers, they will find you. All you need to do is tweet. Dare I say it? “Tweet, and they will come.”

To date I have three Twitter accounts, each for a different facet of me. Admittedly I use one more than the others but I don’t like to cross-brand who I am. But that works for me. I tweet about business things with my business Twitter account. I tweet about more personal things with my personal twitter accounts. I don’t like to muddy the waters (which is the primary reason I despise Facebook). That may not work for you. Do what feels right.

The single biggest thing you can do for yourself on Twitter is to make sure you don’t get lured into using it as another IM client. I follow more than a few people who use it to chat about where to go to lunch or what time a movie starts, etc. That’s annoying. To them I suggest a little app called Skype. If you use Twitter as an IM client you are likely to lose followers in a hurry.

Twitter is a phenomon. It’s still misunderstood by many, though. More famous twitterer’s like Ashton Kutcher have increased their celebrity by making them more accessible to their fans. Having a direct line like that to people who have historically been so unattainable is a powerful, powerful thing. While you may not be hooking up with Demi you still may have interesting things to say. Tweet them. You will develop a following of your own.

A final note: Just because someone follows you does not mean you have to follow them in return. If you get a new follower, look them up. See what they tweet about. Read their bio. Are they interesting to you? If so, follow back. If not, that’s cool, too. If you do follow someone, see who else is following them. You will find that many of their followers are interesting to you. Follow them. Some of them will follow you in return. It’s viral.

Now go. Tweet.

Cheers,

Colin Weaver

I recently received an email asking about DNS server placement.  In part the email reads, “why whould a computer from the internet need to reach a “public” DNS server inside a private DMZ as if it were a web server? Are there occasions when a machine would need to reach accross the internet and resolve a private IP address? It seems backwards and highly unsecure, especially where there is no VPN.”

Questions in this vein are not too uncommon and over the years I have encountered a good number of people confused about where a DNS server should be placed and why.  The answer is not simple because there are many correct ones.  A lot depends on the layout of your network and your organization’s naming scheme.  To give a frame of reference for discussing this let’s consider three different general network layouts.  For each network I briefly review traffic flow typically allowed by the firewall.  This is important when trying to understand where a DNS server should be and why.  The networks are:

Network 1: Single Firewall With NO DMZ/Screened Subnet

Network 1 - Single Firewall with no DMZ or Screened Subnet

Network 1 is the simplest scenario and more likely to be seen in a home network or a very small business.  The firewall allows internal nodes to establish connections to the Internet and there may be a limited ability for nodes on the Internet to make incoming connections to certain hosts on the internal LAN (but not by default).

Network 2:  Single Firewall With a Screened Subnet.

Network 2 - A Screened Subnet

In Network 2 there is a single firewall with at least three interfaces.  One interface connects to the Internet, one to the ‘DMZ’ and the other to the internal network.  The servers in the DMZ are referred to as “public” because they are intentionally available to the Internet.  With appropriate rules configured traffic will be able to flow (in a limited fashion, of course) from the Internet to the DMZ but not from the Internet to the internal network.  The internal network can initiate outbound connections to the Internet as well as to the DMZ.  The DMZ may have limited ability to make connections in to certain nodes on the internal LAN.

One of the most important things going on with Network 2 is that hosts on the Internet cannot send uninitiated traffic into the internal LAN.  The DMZ area, commonly called a ’screened subnet’ in this single-firewall setup is protected by the firewall but the firewall does allow administrator configured rules that permit hosts on the Internet to send traffic into the DMZ.  This ability to be ‘touched’ by nodes on the Internet makes this DMZ network segment less trusted than the internal segment (which cannot be reached directly from the Internet).

Network 3: Dual-Firewalls with DMZ LAN segment In-Between

Network 3 - Multiple Firewall DMZ Scenario

In Network 3 there are two firewalls.  The outer firewall (the one touching the Internet) is the first line of defense and controls the flow of traffic form the Internet into the DMZ as well as the flow of traffic from the internal LAN and the DMZ out to the Internet.  The inner firewall controls the flow of traffic from the DMZ into the internal LAN and it also controls the flow of traffic coming from the internal LAN going to the DMZ and the Internet.  In general, the DMZ nodes may have some limited ability to initiate connections to internal LAN hosts but the Internet will have zero ability to initiate inbound connections to the internal LAN.  This is a more aggressive security posture, offering multiple layers of firewall defense.  It is also slightly more complex in its configuration.

So where should your DNS servers be?  Let’s examine that a bit.

First we need to define the basic intent of DNS.  We know DNS resolves host names to IP addresses (and vice versa if configured) but we can separate that into two different areas:  internal host names and external (public) host names.  Internal nodes need to be able to resolve both internal and external host names.  For example, while at work I need to be able to resolve sql6.itdojo.com (an internal node) to an IP address just as much as I need to be able to resolve www.starwars.com (an external node).  The same may not be true for nodes on the Internet.  Should a node on the Internet be able to resolve sql6.itdojo.com to an IP address?  If yes, you need a DNS server that is reachable to the Internet node.  If you only have a single internal DNS server (like in Network 1) you will need to expose that internal server to the Internet for incoming queries.  This means that anybody on the Internet can resolve any internal host name.  That is generally considered a bad idea.  Rather than exposing your internal DNS server you may opt for Network 2 or Network 3, which have different DNS servers in the DMZ/screened subnet area that are reachable from the Internet while the internal private DNS server is not.  This is a step in the right direction from a security perspective because it prevents Internet nodes from resolving the names of internal hosts (which reside only on the internal DNS).  The only names that can be resolved by nodes on the Internet are the ones you place in the zone file on the DMZ-located DNS server.  This typically only includes the names of the servers in the DMZ/screened subnet.  The challenge with this scenario is in your DNS naming convention.  If both the private DNS server and the DMZ DNS server host the zone file for the same domain (itdojo.com in this example) you will have to duplicate entries on each server (and they may be different addresses if your firewall is NAT-ing between the private LAN and the DMZ/Internet) because primary-zone-file-holding DNS servers won’t forward to a query to another DNS server with the same name (e.g., the server is authoritative for the name space and will not forward requests to another server to resolve its own primary zone queries).  This increases the complexity of administration (but is not the end of the world).

An alternate solution would be to use a completely different name for the internal name space.  If your Internet presence is itdojo.com, consider using a child domain of that name space internally (or a different name altogether); corp.itdojo.com or itdojo.net, for example.  This allows your internal nodes to query for sql6.corp.itdojo.com and get internal resolution while queries for ftp.itdojo.com and still be forwarded to the DMZ-located DNS server.  On the flip-side, an attacker on the Internet can query the DMZ DNS server all day long and only resolve the nodes that have been manually entered by the administrator but will not be able to get queries directly to (or forwarded to) the internal corp.itdojo.com DNS server.  This helps protect against attackers building a list of available nodes in your environment.  And since so many shops have the bad habit of naming their servers after they function they provide this is an important consideration.

The placement of DNS servers is further complicated if you use Active Directory.  Active Directory-Integrated DNS zones are contained in the Active Directory database, not in a separate file or database.  This means that the DNS server will also need to be a domain controller.  Placing a domain controller in the DMZ is punishable by death in most organizations so AD-integrated solutions will have to be exclusively internal.  You are essentially compelled to use an internal DNS/external DNS scheme.  Whether you use different namespaces (itdojo.com vs. itdojo.net) is up to you.  I’ve met people who feel strongly about both ways of doing it.

The simple truth of all this discussion is this:  Hosts on the Internet should never be able to resolve the names of resources on the internal LAN that you have no intentions of ever sharing with the Internet.  It’s not keys-to-the-castle information but it’s a big help to a would-be attacker.  This means it is all but impossible to have Network 1 and expose your internal DNS to the Internet.  With no DMZ or screened subnet your only real alternative is to pay a 3rd party to host your DNS for resolution of Internet available resources (www, ftp, smtp, etc.)  The internal DNS server in Network 1 should never be directly reachable from the Internet.  Realistically, the only nodes that should be resolvable by the DMZ DNS server are the services offered in the DMZ (www, ftp, ssh, smtp, dns, pop3, etc.).  Hosts on the internal LAN should be able to resolve all addresses, inside or out (yes, there are exceptions to this).

If anyone has additonal questions on this topic please email me or ask in the comments and I will address them.

Cheers,

Colin Weaver

NAT - A Black Mark on IPv4's Name

NAT-free Network - Global Unicast Addresses for Everybody!!! Bye-Bye NAT!

What happens where there is no longer any pressure on the IP address space?  Imagine there are more addressess available than we conceive uses for (famous last words, I know).  If there is no pressure on the IP address space why do you need a device to translate the private to the public (and back again)?  Uh, you don’t.  So, no pressure on address space means no NAT necessary.  We still need the firewall function, of course.  The need to protect the inside from the outside will remain forever.  And there is it, the future:  IP version 6.  IPv6 virtually eliminates the pressure on the IP address space.  Everybody on this planet will have enough IP addresses available to them that they will never again have to worry about whether or not there are enough IP addresses.  Well good.  That’s one less thing to worry about, right?  All that remains is the need to firewall.  And that is all that needs to stand between your so-called private network and the Internet.  And that’s the way it should be.  For some of us that will be a new paradigm.  Without that false sense of security we get from NAT there are many who will feel exposed with their internal nodes having public IP addresses and only a firewall (or two or three or four) to protect them from the nasties.  Trust me, it’s going to be OK.

IPv6!!!!

Last summer Dan Kaminsky got everybody all a-tingle over an ever-so-simple vulnerability in DNS.  Mad props to him for figuring it out, of course.  But a big kabong in the head for the rest of us for not seeing it earlier.  DNS is over 25 years old and is core to the functioning of the Internet.  The fact that something so obvious made it so long without getting discovered is a lesson for us all.  You can read about the Kaminsky vulnerability here (http://www.wired.com/techbiz/people/magazine/16-12/ff_kaminsky).  Wired magazine, despite being way more liberal than I can usually stomach, does a good job on articles like this.  Good back story, etc.  Anyway, it’s worth the read.

If you want to know more detail about the vulnerability I suggest you give a serious 20 minutes to Steve Friedl’s description of the Kaminsky DNS vulnerability.  Steve does a really good job of breaking things down so I’m not going to repeat what he already said so well. Go check out his schtick.  Seriously.  Go.  Read it.

The current solution to the problem is termed by most to be temporary.  It take the chances of successfully executing the attack from 1 in 65,535 to a much larger 1 in 161 million.  I’m calculating this number by multiplying the number of possible source ports (65,535-1,025) by the number of random ports chosen by a patched Microsoft DNS server (2,500).  64,510*2,500=161,275,000.  This means that there is a 1 in 161 million chance that someone will be able to poision the cache using Kaminsky’s technique.  The real problem is not yet fixed.  The solution was to up the odds on someone being able to acutally succeed.

And I almost agree.  A 1 in 161 million chance is a big-time long shot.  But the odds of winning the Mega Millions Jackpot is 1 in 175 million.  That means you have a slightly better chance at winning the Kaminsky DNS poisoning lottery before you get to retire after picking all five numbers plus the powerball.  What gets me is this:  Someone wins the lottery every week or so (sometimes a bit longer).    The fact that someone has to win means that people still play.  Motivated attackers know this.  If they play long enough they still have a chance to win.  And play, I suspect, they will.  After all, it’s not costing them a buck a pop to do so.  And, oh my, what a payday!

While the solution is simple and reasonably effective it seems that it has no capacity to be a long-term solution (Which has already be admitted over and over.  DNSSEC anyone?).  It also seems that we need to limit the number of times someone gets to play.  Enter Intrusion Prevention Systems and shunning.

My lasting impression from this little lesson in security is that there is always something lurking under the covers.  And it’s often hidden inside things we think we know and understand very well.  How cool is this line of work?  I love it.

Colin Weaver