The Latest Map Of The Internet

 Computing, Security  No Responses »
Mar 242013
 

The above links to an interesting browser which allows zooming and selection of different data sets. It’s worth a look if you’re into that sort of thing. Although it’s rather surprising that it doesn’t like IPv6 addresses!

The most controversial thing about this map of the Internet gathered during 2012, is that it was produced with the aid of a botnet or in other words this researcher stole the resources they needed. Which is obviously wrong – no matter how good the cause – but now that it has been done, there is no reason not to look at the results (whilst wrong this isn’t really evil).

The first interesting discovery here is that this anonymous researcher managed to write a simple virus that would load the Internet scanner onto many devices with default passwords set – admin accounts with “admin” as the password, root accounts with “root” as the password, etc. You would have thought that such insecure devices would have been driven off the Internet by now, but it turns out not to be the case – there are at least 420,000 of them!

You could even argue that the owners of such machines are asking to have their devices controlled by anyone who wants to. Perhaps a little extreme, but certainly some people think so or this Internet survey wouldn’t exist.

But now the results. If you look at the default settings in the browser above, you will encounter large swathes of black squares where apparently nothing is in use. The trouble is that whilst it is true that an IP address that is pingable, or has ports open is “in use”, there is no guarantee that an IP address that is just registered in the DNS is in use or not, and finally unregistered IP addresses that do not appear to do anything may very well still be in use.

Essentially the whole exercise hasn’t really said much about how much of the Internet address space is in use, although that is not to say that the results are not useful.

One special point to make is that many of the large black squares that appear unused, are allocated to organisations that may very well want to have proper IP addresses that are not connected to the global Internet. That is not wrong in any way – before the wide spread adoption of NAT, it was common and indeed recommended that organisations obtain a public IP address before they were connected to the Internet to avoid duplicate network addresses appearing. And an organisation that legitimately obtained an old “class A” has no obligation to return the “unused” network addresses back to the unallocated pool. And even if they did, it would not make a big difference; we would still run out of addresses.

The answer to the shortage of IPv4 addresses is IPv6.

 

Adventures in Cisco IOS Land: IPv6

 Cisco  No Responses »
Sep 292012
 

Just like previously, please read the disclaimerbefore proceeding; I ain’t no CCIE! Several points before diving off into the configuration :-

  1. Somewhat surprisingly, the most difficult part of getting IPv6 up and running was not the configuration nor the process of switching ISP to one that supported native IPv6. The most difficult part was acquiring a version of IOS that was not riddled with bugs related to (I think) running IPv6 over PPP. If you are undertaking this task, I would suggest making sure you have a very recent version of IOS – the one I am now running was released in July 2012.
  2. If you need a UK ISP that supports IPv6 for customers, I would suggest AAISP.
  3. Throughout this document, I am using the IPv6 documentation network 2001:db8/32, or more specifically 2001:db8:face/48. That doesn’t guarantee that I know what I’m talking about, but at least it doesn’t guarantee that I know nothing … as would be the case if I were using some random real IPv6 address.
  4. None of the following should interfere with anything you might be doing with IPv4. With the exception of times when I reloaded the router out of frustration, and occasionally to load a new firmware, my IPv4 connectivity was up and running continuously.

Before starting you need an IPv6 address to configure; unless you have a large internal network it doesn’t make sense to start playing with a ULA address. So get an allocation from your ISP. If you have a half-reasonable ISP, they will allocate you something like 2001:db8:face/48 which will give you 65536 different subnets to play with – perhaps slightlyover the top for a home network! To start with, you need to configure the router itself to enable IPv6 :-

ipv6 source-route
ipv6 general-prefix MYISP 2001:db8:face::/48
ipv6 unicast-routing
ipv6 cef

This basically enables IPv6 routing (with no routing protocols – only static and learnt routes) and configures a “general prefix” with the network details of what your ISP has provided you with. This can be used later to configure addresses in a way that means that changing ISP isn’t quite so painful, and in a way that is less error prone – typing in IPv6 addresses is a lot more prone to typos than IPv4 addresses. Once that is done, it is time to look at IPv6 security … normally people suggest getting everything working first, but as I am more of a security geek than a networking geek, I would suggest security comes first. This is not a great deal different to IPv4 security except that forgetting about NAT makes things simpler :-

ipv6 inspect routing-header
ipv6 inspect name ipv6-allowed-out icmp
ipv6 inspect name ipv6-allowed-out tcp
ipv6 inspect name ipv6-allowed-out udp
ipv6 inspect name ipv6-allowed-out ftp

This basically defines what traffic is allowed out (assuming it’s applied appropriately to an interface). Nothing really odd here … basically everything is allowed out, and I ask the router to inspect for routing information that might be available. The next bit is the incoming ACL :-

ipv6 access-list access-to-servers
 permit icmp any any
 permit tcp any host 2001:db8:face:f00d::c0:ffee eq 22
 deny ipv6 any any log

Several key points about this ACL :-

  1. All IPv6 ACLs are “extended”.
  2. All IPv6 ACLs are named rather than numbered.
  3. The ICMP bit looks a little permissive, but ICMP is very much more required for a functioning IPv6 network than an IPv4 network. It can be tuned down somewhat, but you need ICMP for your network to work.
  4. The rule that allows access to my server on port 22 does not allow the use of the previously defined general-prefix. Come on Cisco, do the right thing here!

And another ACL for access to the router’s SSH port :-

ipv6 access-list authorised-v6
 permit ipv6 2001:db8:face::/48 any
 deny ipv6 any any

And we might as well apply that last ACL right away :-

line vty 0 4
  ipv6 access-class authorised-v6 in

Now we have the basics ready, we can start to configure interfaces. Before you start, it is worth figuring out what network addresses to use. IPv6 does of course allow the possibility of using wildly inappropriate hexspell words as network address, or you could be very sensible and come up with an appropriate allocation scheme.  For larger networks, it is well worth reserving a large swathe of networks (such as 0000-7ffff) for someone to come along later to create a “better” scheme … as somebody who has dealt with a large IPv4 network where the original allocation scheme was somewhat suboptimal, I firmly believe that later network administrators should have the freedom to change the scheme in the light of more experience. You will often encounter the assumption that the host part of a network is always 64 bits (or the network mask is always /64). Whilst this is not a requirement at all, there are popular features of IPv6 that only work on a network that size such as address auto-configuration (SLAAC). In practice this means that you should always create networks with a /64 netmask, unless you have a very good reason not to (for instance when configuring statically configured links between routers). Even if you have no intention of allowing address auto-configuration. As a minimum, you will need two networks – one for the external interface, and one for the internal interface(s). As you may have guessed, we have already specified what the internal network is: 2001:db8:face:f00d/64, and I will use 2001:db8:face:1ced/64as the external interface. The first interface to configure is the internal network :-

interface Vlan101
 ipv6 address MYISP 0:0:0:F00D::1/64
 ipv6 enable 
 ipv6 nd prefix 2001:db8:face:f00d::1/61
 ipv6 nd router-preference High

The command to give the network and the interface an address requires a little explanation. First of all, we’re lucky enough to be able to use the “general-prefix” that we defined earlier. This “general-prefix” is merged with the unusual looking address that follows it :-

MYISP general-prefix 2001 db8 face
Address to merge 0 0 0 F00D::1/64
Result 2001 db8 face F00D::1/64

This provides the interface with an address. The next command simply enables IPv6 on the interface. The ipv6 nd prefix command tells the router what “prefix” to advertise to clients wishing to autoconfigure (using SLAAC).

As an aside, the whole topic of managing IPv6 addresses on clients is worth an article on its own – auto-configuration sounds like a good option (and indeed may be a good choice), but there are situations where you would prefer to not allow auto-configuration. And not all clients work equally well with all options.

The next command (ipv6 nd router-preference High) is a weak attempt to guard against false Router Advertisement messages – advertising this router as a High preference one may prioritise it’s use over any other mysterious routers that appear on this network. In practice, it is necessary to block RA messages from non-router ports using a switch feature such as ipv6 nd raguard. Once this interface is configured, you may well start to see IPv6 hosts with the command show ipv6 neighbours. And onto the configuration of the outside interface :-

interface Dialer0
 ipv6 address MYISP ::1ced:0:0:0:1/64
 ipv6 enable
 no ipv6 nd ra suppress
 ipv6 inspect ipv6-allowed-out out
 ipv6 traffic-filter access-to-servers in
 ipv6 virtual-reassembly in

This starts off in much the same way as the previous interface configuration, but in this case I also :-

  1. Explicitly enable RA messages on the interface with no ipv6 nd ra suppress. This is to ensure that the RA messages get out to the ISP’s router on the “other end”.
  2. Uses ipv6 inspect ipv6-allowed-out out so that IPv6 traffic is allowed out (and any associated packets are allowed back in again!).
  3. Uses ipv6 traffic-filter access-to-servers in to allow any unsolicited IPv6 traffic necessary in.
  4. Uses ipv6 virtual-reassembly in to use Cisco’s VFR feature to protect against fragmentation attacks.

Note that I have statically configured the address on this interface. Some ISPs require this, and some require that the interface is set to auto-configuration (ipv6 address autoconfig or ipv6 address dhcp). The last step is to configure a default route :-

ipv6 route ::/0 Dialer0

Some misconceptions I’ve come across through googling for tips and assistance :-

  1. There are plenty of examples which show internal interfaces configured with ipv6 nd prefix XXX in addition to the interface address. As far as I can see (and as demonstrated by my home network actually networking), there is no need to specify this prefix unless you are advertising multiple prefixes on an interface, or doing something even stranger.
  2. Examples often include ipv6 nd ra interval ${some-value}, which as far as I can see is somewhat unnecessary except that the default value of 200s means that connected hosts may take a while to spot the router.
  3. There are plenty of examples for setting up IPv6 with a tunnel within IPv4 where the IPv6 MTU is set to some value lower than the default such as ipv6 mtu 1280. Tuning the MTU for native IPv6 should not be necessary, and even if it is, the right value would be somewhat higher.

And of course, if anyone believes I’ve done something wrong, please let me know!

 Newer Entries