Tag Archives: Linux

Shellshocked: 2014 The Year of the Superbugs

Broken Windows

It was announced this week that a 19 year old bug has been present in most of Microsoft’s Operating Systems (OS) dating back to Windows 95. The bug (in fact it appears to be a series of connected bugs) was present in server and clients OS’s and was still present in Microsoft’s most recent efforts Windows Server 2012 R2 and Windows 8.1. Not even the minimal, naturally hardened Server Core escaped its potentially fatal grasp. The flaw was in Microsoft implementation of Secure Sockets Layer (SSL) and Transport Layer Security (TLS), Schannel. It was uncovered by a team of IBM researchers, known by the excellent superhero esque handle of X-Force. X-Force’s Robert Freeman described what they had uncovered in a blog post on IBM’s Security Intelligence website.

In the post he highlights some of the take home points of this threat: It has been around since Internet Explorer (IE) 3, it allowed reliable execution of arbitrary code from a remote location, It sidestepped IE’s Enhanced Protected Mode, and even secure protocols such as HTTPS can be easily exploited with the proper knowhow. When you step back and look at some of these points the severity of the flaw is plain to see and explains why the bug, now being dubbed by some as WinShock has been given the maximum CVE severity rating of 10. CVE-2014-6321 states that WinShock has a low level of complexity to exploit the bug and that a massive amount of damage that can be done with it. Being able to execute arbitrary code without authentication and often with elevated privileges is a massive problem, it effectively compromises every part of an affected system, the effects of this bug could have been devastating, if an unprotected system is exploited by the wrong person (or organisation) then it is effectively game over, data is compromised, systems are hijacked nothing is safe. To Microsoft’s credit they had released a fix to the issue in this weeks patch Tuesday update, the same day that the vulnerability was made known to the public.

Heart Breaking

Amazingly WinShock isn’t the first major security flaw discovered in protocols designed to securely transport data across the network in 2014. In April, SSL and TLS were at fault again (its not clear if the WinShock bug is related) when the Heartbleed vulnerability was made public. Heartbleed compromised some of the most widely used security transport protocols in the world including OpenSSL, GnuTLS, and Apples Secure Transport. Untold numbers of systems were left wide open by WinShock and Heartbleed, if you have used a computer in the last few years you were almost certainly exposed to the undetected hidden threat posed by these security flaws. All of this goes to not only undermine the integrity of our data, but the integrity of our privacy, safety and trust in the systems designed to keep us safe.


The computing industries annus horribilis doesn’t stop with WinShock and Heartbleed. In September yet another vulnerability with a CVE severity rating of 10, effecting millions of computers, and allowing for arbitrary code to be run from remote locations, was made public. This time it was a 25 year old vulnerability in the BASH shell (and its derivatives) that had a gaping hole in its security. In fact it wasn’t just one flaw, by the end there were six published vulnerabilities relating to BASH.

Dubbed Shellshock it exploited a feature that allowed unauthenticated environment variables to be exported to function definitions, trailing variables could have arbitrary code placed inside them, when BASH forks, the environment variables were written into memory and the code from the trailing variable executed. Shellshock was startling for a number of reasons, not only did it undermine the perceived security benefits of Linux systems, it was also very easy to exploit. The amount of devices left vulnerable was staggering, from servers, to clients, to phones and even smart washing machine, fridges, TVs and other smart devices. Shellshock had the potential to cause massive amounts of catastrophic damage to an incredibly diverse and large array of systems.

Within hours of Shellshock being publicly released there were detailed tutorials online on how to exploit the vulnerability, it wasn’t long until reports on how the bug had been exploited began to appear in the media. There were tales of Romanian Gangs and massive Botnets running riot all over the the internet. By late September security researchers at Incapsula reported that it had seen a rate of 725 attacks per hour relating directly to Shellshock.

What 2014 has taught us is that major security vulnerabilities have existed undetected for years, these vulnerabilities have affected the entire gamut of computing. The free software community, the open source software community and proprietary software vendors have all seen major flaws in their software exposed. It begs a few questions; what else is out there that we don’t know about? What other bugs are lurking deep in the code of the software that is present on our computers, our internet, our corporate infrastructures, our national infrastructures and just about every connected device we have come to take for granted? What dangers are lurking just around the corner? With Heartbleed, WinShock and Shellshock we may have gotten off lightly, each of these flaws were recognised and fixed in an extremely timely manner, the consequences could have been far worse if they had gotten into the wild before the good guys discovered them. That’s not to say that the consequences still may not be felt, they could just be in hibernation, backdoors waiting to be opened, time bombs ready to explode, and stolen or compromised data waiting to be exploited. Of course the doomsday scenario is an extreme one, but one that cannot be ignored.

Richard Stallman describes Shellshock as just a “blip”, hopefully he is right, hopefully all these bugs and others like them are just a series blips, the inevitable consequence of the growing pains associated with the incredible pace of technological advancement and the complacency of not checking old code thoroughly when implementing it in new systems. We can only hope that these “blips” do not turn into a constant tone, a tone that could signify the flat lining of people’s trust in modern computer networks.

UNIX, Beards and Orange Wallpaper

I am currently writing a dissertation about the move away from proprietary software, while doing some research I re-discovered this little gem! It is a video that Bell Laboratories produced in 1982 about the UNIX operating system. It is a must watch, not only because it offers a great insight into the contemporary thinking of this little part of computing history, but also because it is a time capsule of early 80s retro geekery goodness. This video has it all, the jazzy music, the grainy film, the blocky graphics, the orange wall paper and an impressive collection of beards. But if you’re not interested in beards it also has some footage of the then contemporary computers and x-terminals, I’m not going to try and identify any of them because I will almost certainly be wrong, but if you recognise them, then please let me know.

The video also has Dennis Ritchie and Ken Thompson being interviewed (and pulling some excellent set up for the video poses). They published the original UNIX white paper, which I have included in this post. Have a look at that, you will see that many of the concepts survive in UNIX and Linux OS’s today. Dennis Ritchie also discuses the C programming language and its inception, so it may be of interest to any programmers out there as well.

The UNIX Time-Sharing Operating System by Dennis M. Ritchie and Ken Thompson. Bell Laboratories 1974

Just a quick update on the IPv6 series, I am delaying the rest of it until January, as I said I am in the middle of a dissertation and that is taking up all of my free time at the moment. I am aiming to have most of complete by early January. As soon this the dissertation is complete I will write up the rest of the IPv6 series.

Linux and IPv6 for the small business

This post will cover how Linux (UNIX and Unix-like) and more specifically computer network services and applications that run on Linux systems use and integrate with Internet Protocol version 6 (IPv6). It will cover how a variety of IPv6 based network services can be easily configured for use in a small business

Three network services, Routing, Domain Name System (DNS) and Address resolution will be covered. Additionally three server based applications providing Email, Printing and Web Serving will be covered, including how to configure IPv6 on a particular programme providing one of these services and what provisions each of these services provides for IPv6 support, and what IPv6 provides for each of the services.

This won’t be an exhaustive list off all the services, or a detailed example of how to configure them, but it should give some idea on how simple it is to get IPv6 up and running.

Why IPv6?

IPv6 is the successor to IPv4 as the main network layer protocol used on the internet to provide addressing to interconnected nodes. IPv4 is a 32 bit address represented by four dotted decimal octets. IPv4 provided for just short of 4.3 Billion unique addresses. This amount of addresses proved to be inadequate and IPv4 addresses were eventually exhausted. To slow down this exhaustion a number of mechanisms where deployed, including private IP addresses that could not be routed globally being used on Local Area Networks (LAN), with Network Address Translation (NAT) being used on the gateway interface. NAT is a system that allows for multiple hosts on local networks to use private IPv4 addresses that are obfuscated behind one single public, globally routable IPv4 address.

Overview of IPv6

IPv6 addresses are 128 bits, represented by eight colon separated sets of four hexadecimal numbers. Each set represents 16 bits or a ‘word’. This allows for 3.4×10^38 unique address. These addresses are made of two parts, the network prefix that is defined by a given number of high order bits that is shared by all hosts on the subnet, and the remaining low order bits that will be unique for each host on the subnet.

IPv6 addresses have a number of different classifications depending on what range they are in. This range will dictate if they are global unicast (2000::/3), local unicast (fe80::/10) or multicast addresses (ff00::/64). Additionally various other formats and ranges of IPv6 address provide duel staking and compatibility with IPv4.

Below is an example of a globally routable unicast IPv6 address in the standard notation.


A single group of concurrent words with the value of zero can be condensed within the notation of an IPv6 address by replacing them with double colons, additionally any leading zeros can be removed from IPv6 notation. This has the effect of condensing the example address above to:


IPv6 and Linux

Linux systems (A system can be anything from an end user PC, to a server, to a router or a switch) can provide for just about all enterprise network requirements, this post focuses on email, internet access, printer access, routing, DNS and interface address allocation. Application packages that provide these services can be installed on to a Linux system, once installed they can be configured with their IPv6 requirements. It is usually the case that configuration files can be found in the ‘/etc/’ directory, with logs that can be used for monitoring and trouble shouting being found in the ‘/var/logs’ directory.

The first Linux kernel to have any IPv6 code in it was kernel 2.1.8.iv released in 1996. The Linux kernel is updated regularly and periodic updates to the IPv6 functionality of the kernel have been added. Linux kennels 2.6.x and above can be considered IPv6-ready.


Routing can be set up by an administrator in one of two general ways, one is to use static routes, routes that do not change and have to be manually configured. Static routes can be set with ‘ip -6’, and can be configured simply by letting the routing table know the source address and the gateway for the network. The other method is dynamic routing; this can be implemented by installing a routing package and implementing an IPv6 compatible routing protocol.

There are number of routing packages that can be installed on a Linux system, once such package is Quagga. Quagga provides full support for the following IPv6 routing protocols OSPFv3, RIPng and BGP-4. The Quagga package installs a core daemon called zebra, zebra is the abstraction layer between the kernel and the Zserv. Zserv listens on port 346vi. Zserv clients will will run on one of the supported routing protocols and pass routing information to the kernel. This report will use Open Shorted Path First v3 as its example protocol. Its configuration files can be found in ‘/etc/quagga’.

An example of OSPFv3 configuration

Additional benefits of IPv6 is that packet fragmentation is no longer an problem, with IPv4 if a packet was received that exceeded the Maximum Transmission Unit (MTU), the router would fragment the packet, with IPv6 the host uses a method called Path MTU Discovery, this ensures that all packets do not exceed the MTU.
Zone file


DNS works with IPv6 in much the same way as it did with IPv4. To implement DNS you first have to install DNS software, the example in this post is BIND, as it is the most widely used DNS software on the internet. IPv6 hosts records are mapped in ‘AAAA’ records, these are used to resolve IPv6 address.

AAAA Record

BIND’s configuration files can be found in ‘/etc/bind’. Bind must be instructed to listen for IPv6 address in the‘/etc/bind/named.conf’ file. BIND can be configured as a caching only server, these will retrieve AAAA records from a root DNS server and cache any records it resolves. You can also use these files to configure BIND as a master DNS server.

Address allocation

IPv6 interfaces can be automatically allocated Extended Unique Identifier-64 (EUI-64), link-local IPv6 address. These are non-routable addresses that are used to communicate on the local network segment, these address are configured automatically when an interface is placed in the up state using the command ‘Ifup ’.

Link-local address are automatically generated by being issued with the prefix fe80::/64, this is a predefined range of non-public IPv6 addresses and makes up the network portion of the address. The remaining 64 lower order bits of the address that make up the host portion are generated by using the interfaces 48 bit MAC and 16 additional bits that are always set to the reserved value of fffehex are injected after the 24th bit.

Additionally EUI-64 globally unique routable addresses can be automatically issued. The 7th bit is the Universal/Local (U/L) bit, if this bit is set to zero then the prefix will be the link-local prefix, if it is set to one then it will be issued with a global prefix


To automatically configure a global address, a Router Advertisement Daemon (radvd) has to be configured on the gateway interface of the router. This will be configured with a 64 bit global prefix that it will issue to interfaces on its network. Various Router Advertising parameters will also be configured. These advertisements will be sent out periodically to interfaces; additionally a host can request an address by sending a Router Solicitation message. The host 64 bits will be configured in the same way describe in link-local addressing, with the U/L being set to one.

Another method to automatically issue IPv6 addresses is to use a DHCPv6 server. To implement DHCPv6 a DHCPv6 server application would need to be installed and configured with relevant network prefixes, and other interface options. The interfaces on the host machine would then need to be configured in the /etc/network/interfaces file (Debian) to request an address when put into the up state.


To implement a Linux email based email server a number of software components need to be decided upon, installed and configured. Mail User Agents (MUA), client side software that allows users to send and receive email, Mail Delivery Agents (MDA), an agent that delivers email to the user’s inbox, and Mail Transport Agents (MTA), the agent that delivers mail from one device to another.
Each of these components has a number of software applications that provide its service. MTA applications include sendmail, qmail and postfix.


Postfix introduced IPv6 support in version 2.2. Configuration files for postfix are found in ‘/etc/postfix’. The ‘mail.cf’ file can be configured to allow the interfaces and network protocols with what network protocols and specific address to listen on. The figure below displays a number of possible configurations. The ‘all’ enables IPv4 and v6 if supported, ‘ipv4, ipv6’ enables both IPv4 and v6, and ‘ipv6’ enables only IPv6.

Web Serving

Web serving requires the installation of software, Linux has an array of web serving software such as lighttpd and nginx, but this report will cover the world’s leading web serving software; apache.

Apache will require configuration to listen for IPv6, the command ‘Listen [2001::6188:28aa:c52d:67b9:56:16ae]:80’ will instruct apache to listen for http requests on the stated address and port. This command will only serve that single host, the command ‘Listen *’ will instruct apache to listen for all IPv4 and IPv6 hosts on port 80 by using the ‘all’ wild card ‘*’.

Example of an IPv6 configured Virtual Host

The wildcard ‘*’ can also be used on virtual host configuration files to make them available to all IPv4 and IPv6 hosts, this can be configured in the ‘/etc/apache/sites-enabled /


CUPS is printer server software that allows the management of print devices, and can be used to administrate printer access. Cups also has wide variety of drivers available to support a wide range of print devices. CUP’s has two methods of configuration, the first being via web interface and the being via the command line tool ‘lpadmin’.

Once installed the CUPS configuration files can be found in ‘/ect/cups’. Allowing and denying hosts access to print devices can be configured in the ‘/etc/cups/cupsd.conf’ file.


It is possible to configure network printer sharing without using CUPS, by using the BSD lpr system, this allows for simple administration task such as managing print queues and assigning jobs.

Wrapping Up

In each section of this post IPv6 integration with a variety of systems was briefly covered, many of these systems required the installation of software, in many instances there was a wide variety of software applications providing each service. This post focused on the most widely used software packages such as Quagga, BIND, Postfix and Apache. Each of these packages has IPv6 support. Additionally they are used extensively, and as such they have been well tested and documented, this makes them ideal for the first phase of a networking switching from IPv4 to IPv6, or dual staking IPv4 and IPv6.

IPv6 not only provided for an increased number address over IPv4, it also had mechanisms in place that render protocols that IPv4 relied upon redundant or not necessary, one of these protocols is DHCP, IPv6 can use DHCPv6 for automatic allocation, but as we seen EUI addresses are built into the addressing architecture and require less administrative effort to configure and maintain.

For printing services, this we covered CUPS, supplemented with lpr commands; this provides a powerful mechanism for administrating network printers. These are tried and tested systems that require minimum administrative effort while providing full print server functionality.

The amount of configuration required to enable IPv6 integration varies depending on what package you are configuring, email, web serving and printing are relatively simple, the general pattern requiring some kind of initial IPv6 activation, usually in the form of editing a configuration file stored ‘/etc/’ to set the software package and service it is providing to listen for and respond to IPv6 hosts. This is usually followed by configuring any IPv6 relevant files, to apply IPv6 functionality.