Tuesday, March 31, 2009

Conficker Virus may cause more problems starting tomorrow

The Conficker Virus hits another important date tomorrow when it will start phoning home by connecting to randomly generated domains (approximately 50k of them) to get instructions on what to do next. Luckily within the last few days researchers have been able to come up with a fingerprint for detecting infected hosts which has been very difficult up until now.

The great people over at insecure.org have updated the popular NMAP tool (Version 4.85Beta5) with the ability to scan for infected hosts. I would certianly have this on hand for tomorrow if this becomes bigger than what has been predicted.

Friday, March 27, 2009

Route Servers and Looking Glasses

One of my favorite Internet troubleshooting website's is http://traceroute.org. It hosts a collection of links to BGP Looking Glasses and Route Servers all over the Internet. This is extremely useful when trying to track down why people in various parts of the Internet cannot reach your public IP space by being able to make sure that the routes that you are advertising are propagated properly and that someone else is not stepping on your routes.

For example, I was troubleshooting a problem where users in my network were not able to get out to the Internet. After checking our firewalls and routers I found that the traffic was indeed leaving the network out to the Internet but I wasn't getting any return traffic. I saw that I was advertising the return routes out to the Internet, but by logging into a Route Server I found that there was a more specific route that was being advertised by AT&T (who was not our carrier) than what I was advertising to the Internet. Because of this I was able to start advertising more specific ranges than what AT&T was sending to work around the problem until I tracked someone down at AT&T.

Once I got a hold of someone we found that someone was turning up a new AT&T customer who had a very similar address range as my IP space and had fat fingered the IP address when they put in the route. This in turn started advertising my space more specifically than mine which sent all of my return traffic to AT&T. Had I not been able to look at how the "Internet" was routing my IP space I would have never been able to find this problem.

Most of the providers even have the ability to ping and traceroute from various points around the world as well which is sometimes helpful as well.

Sunday, March 22, 2009

My Workstation

Thanks to a new monitor arm setup and a cheap video card from a friend of mine (Thanks Jeremy), I am able to use all three monitors on one PC. I have a Samsung 24" Widescreen as my primary monitor with two Samsung 19" Widescreen monitors on top. Using Winsplit Revolution I can have 8 terminal windows up with no problem (or a couple of basketball games with March Madness). With such a sweet setup, I'm not sure how I'm going to be able to go back into the office and use my single 24" monitor...

Saturday, March 21, 2009

Now it's "No business case for IPv6"

As a follow up from a previous entry on IPv6 adoption as well as on Bogon addresses, Slashdot featured an article from Network World titled "No business case for IPv6, survey finds" which outlines reasons why companies are not adopting IPv6. In the article, one responder mentioned that they would increase the amount of Network Address Translation (NAT) if they can't get allocations of IP space. While this certainly will cause some problems, it is going to be required one way or another (V4 to V6 or V6 to V4 NAT). It also mentions that experts estimate that IPv4 addresses will all be allocated by 2012 which doesn't give us a lot of time to make a move towards something. Personally I think that the IPv4 address exhaustion problem is just as big or bigger than the Y2K problem we just had less than a decade ago. Modifying software for dates while certainly not a minor task will look like childs play when you look at litterally having to redo all of the networkable applications and your network infrastructure to take advantage of IPv6. Not to mention that the number of IPv6 experts out there is miniscule compared to the people who support IPv4.

My guess is that within the next couple of years, people with a strong background with IPv6 are going to be the new "COBOL" programmers of Y2K making really good money to bring enterprise networks onto the new protocol.

Monday, March 16, 2009

Martian's and Bogon's (and no this isn't Sci-Fi)

After discovering Bogon's and Martian's in networks that I manage I decided that it was time to bring more light to these devious creatures.

Lets start with the more common Martians which are networks that should NEVER be routed on any network with few exceptions. As a matter of fact, Juniper has them defined in JunOS and you must modify the list if you need to route for any of them:
carlfugate> show route martians

inet.0: exact -- allowed orlonger -- disallowed orlonger -- disallowed orlonger -- disallowed orlonger -- disallowed orlonger -- disallowed orlonger -- disallowed orlonger -- disallowed

On one of my internet facing routers I have a protection ACL that blocks some of these which surprisingly some ISP's allow people to source packets from these subnets:
Extended IP access list 110
10 deny ip host any (93 matches)
20 deny ip any (53 matches)
30 deny ip any

Some people forget that 127/8 is totally reserved for Loopback addressing and not just
From RFC3330: - This block is assigned for use as the Internet host
loopback address. A datagram sent by a higher level protocol to an
address anywhere within this block should loop back inside the host.
This is ordinarily implemented using only for loopback,
but no addresses within this block should ever appear on any network
anywhere [RFC1700, page 5].

If you ping any address in the 127/8 range on a Windows or *nix box you will get a reply:
Reply from bytes=32 time<1ms ttl="">
What is a Bogon?

From Wikipedia:
"Bogon" is an informal name for an IP packet on the public Internet that claims to be from an area of the IP address space reserved, but not yet allocated or delegated by the Internet Assigned Numbers Authority (IANA) or a delegated Regional Internet Registry (RIR). The areas of unallocated address space are called "bogon space".
The term Bogon comes from Hacker jargon referring to the quantum of "bogosity" which is the property of being bogus. This makes sense when you realize that packets sourced from Bogon addresses which have not been assigned obviously cannot be routed on the Internet.

There are networks out there that instead of using RFC 1918 address space used Bogon's such as 100/8 for a variety of reason (such as seeing them being used in vendor presentations) to address their network. This is becoming more of an issue that IANA is starting to run out of IP addresses that are available for assignment (I recently added a counter to my blog that shows this) and have been assigning more and more blocks that were once considered Bogon's.

Why is this such a big deal? Lets say that you addressed your network in the 100/8 IP space but tomorrow that block is assigned for use and Google gets some of those IP's for some of its new applications. When a user in your network goes to access that application, your network will look at its routing table and may find that it has a more specific route than the 0/0 or default route and send the packets towards some internal host in your network instead of out to the Internet.

There are some dirty ways of routing around this but eventually it can lead to some serious problems. If you manage a network that is addressed out of any of this space I would make it a point to come up with a migration or mitigation plan for this very soon because over the next 2 years we will find that almost all of the previously Bogon space will be assigned and available for use.

You can find a list of all of the current Bogon's as well as some other really helpful tools (such as a BGP peering that you can use to block Bogon's) here: