This is a guest post by Isabella. The Millennium Bug seems like a long, distant memory, but in the late 1990s, the Y2K bug was sending fear and panic among network administrators, governments and businesses alike. Cash machines were expected to start dishing out dollars like fruit machines, high interest current accounts would empty, planes would fall from the sky and the world was going to plunge back into the dark ages, as every computer system failed. Okay, things didn’t seem to work out to be that bad. Few if any major computer meltdowns occurred, and the world moved on.
The threat of the Millennium Bug was quite simply caused by a lack of foresight by computer manufacturers and programmers. Many computer programs only bothered to store the year in two decimal places, which meant that come the year 2000, a lot of timestamps would go from 99 to 00, essentially making the computer believe it was the year 1900. The debate was never settled whether the Y2K bug was just a damp squib, propagated by a media panic, or that the threat was real and only due to the actions taken in the run up to the millennium were catastrophes averted. Whatever the truth, one thing the Millennium bug did highlight, was the critical importance of time for maintaining a stable computer network. But all too often, few people give time a second’s thought, and yet it’s perhaps the most fundamental aspect of keeping a network healthy and secure. So perhaps it’s time to look at network time and understand what is going on.
Timestamps
Time is fundamental for computer networks. Time is the only reference point a computer has to complete tasks, save data or know if something has happened, is due to happen, or shouldn’t happen at all. Start messing about with network time and all sorts of problems can occur - data gets lost, systems fail, applications refuse to start and computers crash. Computers rely on time in the form of a timestamp. This is normally the number of seconds from a particular point in time. In Unix systems, the time stamp represents the number of seconds from midnight, 1 January 1970, so the timestamp of 1322657071 represents 12:44 on 30 November 2011.
Because of the fundamental importance of time, all networks need to be synchronized. Network Time Protocol (NTP) or the Windows Time service (W32Time) are the common methods used by most networks to achieve this. These programs take the time from a master computer and spread it around the network, while continuously checking the clocks on all machines to avoid drift. But they are only effective as the time they are using as a source. Computers are lousy at keeping time. While most PCs have an onboard clock built into the motherboard, these can lose several seconds a day. Set your desktop clock on Monday and in a month’s time, you could be several minutes away from the original time source. For this reason, networks need an accurate, reliable and unfaltering source of time to function. And the only machines that can provide such an unwavering time source are atomic clocks.
Atomic Clocks
Computer networks generally use Universal Coordinated Time (UTC) this is a timescale used throughout the world and is generated by a series of global atomic clocks. Because UTC is the same everywhere, it allows computers to communicate across timezones without the problems caused by time differences. Of course, when it comes to setting your desktop clock, the timezone information is added to keep you in local time. Most computer networks hook up to a service such as time.windows.com, time.nist.gov or another online timeserver. These provide the master time that all other machines on a network feed off.
For highly secure networks, external sources of UTC time are used. Often this is done by GPS, using the signals generated by the atomic clocks onboard GPS satellites to synchronize a network. And this isn’t a bad idea. When a connection to a time service gets broken, or worse, an online timeserver gets hacked, those machines hooked up to it become incredibly vulnerable. You only have to think about the perceived chaos of the Y2K bug to realize the potential for a system meltdown if the time being fed to a network has been tampered with. And in the ever-increasing sophistication of modern day hackers, DDoS attacks to timeservers are not uncommon and can expose networks to all sorts of trouble. So perhaps it’s time to start taking time more seriously and securing your time source.
The threat of the Millennium Bug was quite simply caused by a lack of foresight by computer manufacturers and programmers. Many computer programs only bothered to store the year in two decimal places, which meant that come the year 2000, a lot of timestamps would go from 99 to 00, essentially making the computer believe it was the year 1900. The debate was never settled whether the Y2K bug was just a damp squib, propagated by a media panic, or that the threat was real and only due to the actions taken in the run up to the millennium were catastrophes averted. Whatever the truth, one thing the Millennium bug did highlight, was the critical importance of time for maintaining a stable computer network. But all too often, few people give time a second’s thought, and yet it’s perhaps the most fundamental aspect of keeping a network healthy and secure. So perhaps it’s time to look at network time and understand what is going on.
Timestamps
Time is fundamental for computer networks. Time is the only reference point a computer has to complete tasks, save data or know if something has happened, is due to happen, or shouldn’t happen at all. Start messing about with network time and all sorts of problems can occur - data gets lost, systems fail, applications refuse to start and computers crash. Computers rely on time in the form of a timestamp. This is normally the number of seconds from a particular point in time. In Unix systems, the time stamp represents the number of seconds from midnight, 1 January 1970, so the timestamp of 1322657071 represents 12:44 on 30 November 2011.
Because of the fundamental importance of time, all networks need to be synchronized. Network Time Protocol (NTP) or the Windows Time service (W32Time) are the common methods used by most networks to achieve this. These programs take the time from a master computer and spread it around the network, while continuously checking the clocks on all machines to avoid drift. But they are only effective as the time they are using as a source. Computers are lousy at keeping time. While most PCs have an onboard clock built into the motherboard, these can lose several seconds a day. Set your desktop clock on Monday and in a month’s time, you could be several minutes away from the original time source. For this reason, networks need an accurate, reliable and unfaltering source of time to function. And the only machines that can provide such an unwavering time source are atomic clocks.
Atomic Clocks
Computer networks generally use Universal Coordinated Time (UTC) this is a timescale used throughout the world and is generated by a series of global atomic clocks. Because UTC is the same everywhere, it allows computers to communicate across timezones without the problems caused by time differences. Of course, when it comes to setting your desktop clock, the timezone information is added to keep you in local time. Most computer networks hook up to a service such as time.windows.com, time.nist.gov or another online timeserver. These provide the master time that all other machines on a network feed off.
For highly secure networks, external sources of UTC time are used. Often this is done by GPS, using the signals generated by the atomic clocks onboard GPS satellites to synchronize a network. And this isn’t a bad idea. When a connection to a time service gets broken, or worse, an online timeserver gets hacked, those machines hooked up to it become incredibly vulnerable. You only have to think about the perceived chaos of the Y2K bug to realize the potential for a system meltdown if the time being fed to a network has been tampered with. And in the ever-increasing sophistication of modern day hackers, DDoS attacks to timeservers are not uncommon and can expose networks to all sorts of trouble. So perhaps it’s time to start taking time more seriously and securing your time source.
Technology Blog
Comments
Post a Comment