1. Field of the Invention
The majority of commercial and government enterprises operate and administer (or have administered, on their behalf, by a contracted third party) significant Information Technology networks made up, inter alia, of large numbers of client computers, some servers and the necessary networking infrastructure or ‘furniture’, such as routers, hubs and switches to enable the required interconnection for data to be transmitted. In spite of the significant, negative security ramifications, such organisations predominantly endorse a policy of uniformity or neo-uniformity of client operating systems, which has the effect of rendering the entire network susceptible to any attack based on a vulnerability in the chosen operating system. The negative impact of such policies are exacerbated where the selected operating system is one which is a de facto standard whose complexity is, at least in part, a result a market need for backward compatibility with its (many) forebears, especially where each ancestor was wrought with vulnerabilities to exploitation by malicious code. Quite apart from the innate vulnerabilities which tend to be present in such systems as a result of their lengthy heritage, their very pervasiveness ensures that significant effort is continually expended in developing malicious code to exploit such vulnerabilities. Further, the patching of such vulnerabilities, it is now agreed by most experts, provides opportunities for writers of malicious code. Firstly, the release of patches draws awareness to the existence of vulnerabilities on un-patched computers that may previously not have been apparent; secondly, the complexity and size of operating systems means that new patches are likely to introduce unforeseen vulnerabilities in the course of remedying ones which are known.
Nonetheless, it is not anticipated that there will be any imminent change in such policies. It becomes, therefore, increasingly important for any network administrator to be able to establish the precise nature of the client computing systems within his or her network, which clients have applied which patches and so on. This way, an administrator can at least have an understanding of the extent of any vulnerabilities within his network so that, when an attack occurs, decisions regarding remedial or preventative action can be well-informed.
2. Description of Related Art
Knowledge regarding the configuration of client computers within a network can, classically, be obtained in one of three ways. The first, and most simple way is simply to keep a log, whether manual or automated to some degree, of the various operating systems and patch levels of various computers; for example by one or more of BIOS identity, IP address, or MAC address. This log can be kept by the administrator and updated by an administrator when patches are applied by him; alternatively, were patches are applied by a user, the user can be required to update the log. Another way is to engage in active monitoring of systems by ‘sniffing’ at them, that is to say interrogating them in predetermined ways and, depending upon the responses to one or more interrogations, inferring certain characteristics about them. This process, often called ‘active fingerprinting’, provides relatively accurate and up-to-date information. A third way is passively to monitor systems, i.e. simply monitoring the outgoing networking packets and, from the content of those packets, inferring the characteristics of their provenant system; this process is known as ‘passive fingerprinting’. Passive fingerprinting works by comparing subtle differences in the default values used by each network stack (typically a TCP/IP stack) whereby it is possible to determine which stack implementation, and hence which operating system, the target machine is using. This is due to the unique way in which each developer has interpreted the ambiguous sections of certain RFCs. “P0f”, which is currently the most reliable passive fingerprinting network scanner available on general release, has a number of tests that look for variations in certain header fields of the network traffic including IP time-to-live, IP don't fragment bit, the initial TCP window size, the size of a SYS packet, and which TCP options are used.
According to a first aspect of the present invention, there is provided an opportunistic data communication method for use on a networked computing platform that creates, at the instigation of at least one application executing on the platform, data packets for transmission over a network, these packets being created using a hierarchy of programs (‘stack’) implementing a corresponding hierarchical suite of network protocols each associated with a corresponding protocol data unit (PDU) that comprises protocol-control information for that protocol; the method comprising:
Waiting for creation of a packet to be instigated can involve a periodic check for packet creation activity but will more usually not require any action as packet creation activity itself can be used to trigger the setting of the aforesaid protocol-control-information parameter.
According to a second aspect of the present invention, there is provided a computing platform comprising a hierarchy of programs (stack) for implementing a hierarchical suite of networking protocols to create, at the instigation of at least one application executing on the platform, data packets for transmission over a network, the platform further comprising an additional program adapted to cooperate with the stack to provide to the stack, parameter-value data indicative of a characteristic of the computing platform that is unconnected with functioning of the networking protocols; a particular program of the stack being adapted to set a parameter in protocol-control information of a packet being created by the stack at the instigation of a said application, to a value corresponding to said parameter-value data.
According to a third aspect of the present invention, there is provided a method of administering a network comprising:
Embodiments of the invention will now be described, by way of example, with reference to the accompanying drawings, in which:
Referring now to
A further functional element of the computer is a hierarchy 400 of programs which implement a hierarchy of networking protocols. The program hierarchy 400 is known in the art as a ‘stack’ of programs in though, somewhat confusingly, stack is also a term used frequently to refer to the hierarchy of protocols. For clarity, in this specification, the hierarchy of protocols will be referred to as a ‘suite’ and the hierarchy of programs which implement the protocols as a stack; the stack being made up of individual stack programs whose function is to implement the corresponding layer in the network suite. Classically, the standard networking protocol suite is acknowledged to have seven layers. In the present illustrated example, however, not all of these will be referred to explicitly since doing so would add nothing to an exposition or comprehension of the present invention. Moreover, it is to be emphasised that, although the present embodiments are illustrated in connection with a protocol suite containing TCP/IP, this is not essential and that the present invention is equally applicable to any hierarchy of networking protocols whose specification permits its implementation.
In the following, the terms “protocol data unit” and “protocol-control information” are used; both these terms will be well understood by persons skilled in the art and their usage is in accordance with the definitions given in US Federal Standard 1037C (“Telecommunications: Glossary of Telecommunication Terms”):
Referring now additionally to
Associated with the network stack, though not forming a part of it, is a socket implementation program 50, which, upon detecting a call instigating the creation of a packet from an stack program at the applications protocol level, performs a number of functions, including instructing the Operating System to allocate a socket—i.e. designated memory space to which data received in the course of the communication about to be conducted, may be written. In the case of outgoing data, each of the programs in the stack has the function of creating a protocol data unit (PDU) necessary to conform with the implementation of its respective protocol, which PDU is then passed down to the stack program below, whereupon it is nested within a PDU created by that stack program. This process continues all the way down the stack until a complete Ethernet packet or Frame is created, containing nested within it, all of the PDUs created by the higher stack programs. At each level in the stack, the particular PDU being created by the stack program concerned will include, in addition to the PDU received from above, protocol control information regarding the functioning of the protocol being implemented by the stack program.
In the case of incoming data the reverse process takes place, each stack program receiving and processes the PDUs created by its counterpart program in a remote computer, passing all remaining PDUs to the program above it.
The format and content the various PDUs and of the packets which are made out of them are generally specified in standards established by the Internet Engineering Task Force (IETF), known as RFCs. In accordance with the standards, and as already indicated, each of the individual PDUs have certain features in common. Thus, referring now to
As will be appreciated by persons skilled in the art,
Within the scope of network protocol standards, there usually remains some latitude for PDUs to be constituted in a singular manner. In particular, within the protocol-control information (header) of an IP PDU, there is an ‘OPTIONS’ field which provides, under current standards, up to 38 bytes of data to be configured entirely as any user pleases. The OPTIONS field can, therefore, be thought of as a parameter with user-set values—the size of the field simply permitting a very wide range of user-set values. The OPTIONS field was designed to carry security information or routing data but is typically rarely used. Most IP options consist of three subfields; option type, option length, and option data. RFC 3692 defines a number of IP option types that can be used for experimentation and RFC 1812 specifies that unrecognised IP option types must be passed through routers unchanged.
Embodiments of the present invention exploit the ability to create PDUs segments in a manner to provide for the marking or ‘scenting’ of outgoing packets from a particular computer to signify, inter alia, the identity of the operating system of the platform from which they have been issued. Such ‘scents’ can be monitored easily by elements of network infrastructure such as routers, providing administrators with easy and reliable data regarding the status and configuration of client computers on the network.
Referring now to
As already noted, the value of the ‘scent data’ indicates a characteristic of the operating system (or other feature unconnected with the functioning of the network protocols) of the client computer. By way of example, the value specified by the ‘scent data’ can be used to indicate both the operating system type and the patch version carried for that operating system.
One manner in which the shim 60 carries out its role is as follows. When an applications program seeks to instigate a connection with a remote computer, say in this instance a web browser requests the provision of a web page from a remote server, the corresponding applications-level stack program, here the program implementing the HTTP protocol, generates calls to the socket implementation program 50, causing the operating system to assign a socket. Simultaneously, the data generated within the stack at the HTTP layer—in this example, a GET request—is passed sequentially down the stack so that each layer can add the elements necessary to implement the corresponding layer of the networking protocol suite. For a given program in the stack to configure its PDU, it may be necessary for it to receive external data. As an example, in the case of stack program implementing Internet Protocol, the IP address of the client computer issuing the HTTP GET request is required. Since the IP address is typically assigned by a Dynamic Host Control Protocol (DHCP) server each time a client computer connects to a TCP/IP network, the IP address may change from one networking session to another. Due to the potentially dynamic nature of the IP address, this is clearly data which cannot be embedded permanently within the network stack, but nonetheless must be included within the relevant data segment. Data such as the IP address is, therefore, stored within a data register 70, directly accessible by the IP stack program, and whose contents are automatically updated each time a new IP address is assigned.
In the present example, the shim 60 uses this data register 70 as a route to send the ‘scent data’ to the stack program implementing Internet Protocol. Thus, once the various programs in the stack are brought into operation, the data values which are stored in the data register 70 and which are to be included within data fields in the header of the IP PDU are retrieved by the IP stack program and placed into the appropriate fields of the PDU generated by that program. In particular, the ‘scent data’ that indicates the operating system and patching status of the client PC, is used to set a value in the OPTIONS field of the IP header.
In an alternative and preferred mapping, the ‘scent data’ is a bit-level encoding that defines which operating system is running, which service packs are installed, which patches have been installed, which major applications are installed, and which application patches are installed;
Whatever mapping is used between the ‘scent data’ value and the platform characteristic being indicated, the network administrator maintains a copy of this mapping.
Referring to
In the embodiment of
Because, in the examples described above where the ‘scent data’ is intended to indicate the current operating system and patch level of the client computer any update to the client computing platform that modifies these features requires a corresponding update to the ‘scent data’. Accordingly, each patch that is applied is accompanied by a corresponding update to the shim program 60, to cause an update to the ‘scent data’.
As alluded to previously, the present invention has been described by exemplary reference to TCP/IP. It is nonetheless equally applicable to any hierarchy of networking protocols. Further, the various modifications are not intended to be limited in applicability to the embodiments in connection with which they were first described and, unless stated expressly otherwise, are intended for general application across all illustrated embodiments.
It is to be understood that while the various protocols of a protocol suite have been described as implemented by respective programs of a program stack, the code of two or more of such programs can be integrated into a single code package.
Furthermore it will be appreciated that the ‘scent data’ value can be inserted in all or only some packets created by the network program stack; in the latter case, packets used for carrying the ‘scent’ data value can be selected in a variety of ways, for example every nth packet could be used or packets can be randomly used. However, the selection of which packets are to be used to carry the ‘scent data’ value is independent of the application giving rise to the creation of a packet by the stack.
Information about characteristic(s) of the computing platform can be spread across:
The scenting of the data packets is effectively an opportunistic data communication mechanism that waits for packets to be created at the instigation of application programs running on a platform and then uses these packets to carry data by setting one (or more) parameter values in the protocol-control information of the nested protocol data units. As used herein, the term “opportunistic” means that the scenting mechanism is not responsible for the initiation of packet creation either directly or by acting via one of the application programs and must therefore wait for an iapplication to initiate packet creation. Of course, this waiting for creation of a packet to be instigated will generally not require any action as the packet creation activity itself triggers the action required for setting of the aforesaid protocol-control-information parameter; however, it would be possible for the ‘waiting’ to involve a periodic check for packet creation activity.
The computing platform running the above-described opportunistic communications method is not limited to a user client computer such as a PC, but can be any device on the network that runs a network stack and has sufficient and appropriate resources to add scents into network packets as they are created. The packets may be packets that serve to pass on received packets but under different lower-level protocols to that employed by the received packets. Furthermore, the applications 30 are to be understood to include any entity making use of the network stack to send data over the network.
Although in the foregoing, the computing platform characteristic indicated in the scent data have been exampled by operating system identity and patch data, other characteristics can be alternatively or additionally indicated. For example, the scent data can indicate security settings or information about the user of the computing platform (such information is to be understood as being a characteristic of the computing platform for the purposes of the present specification)
Number | Date | Country | Kind |
---|---|---|---|
0621562.8 | Oct 2006 | GB | national |