WO2008047141A1

WO2008047141A1 - Method and apparatus for monitoring a digital network

Info

Publication number: WO2008047141A1
Application number: PCT/GB2007/004009
Authority: WO
Inventors: Feiyi Huang; Liwen He
Original assignee: British Telecommunications Public Limited Company
Priority date: 2006-10-18
Filing date: 2007-10-18
Publication date: 2008-04-24

Abstract

Apparatus (60) for tracing back a flow of data through a data network (1) is provided in which the data network includes a plurality of router devices (30, 40, 50) for routing packets of data through the network based on a given destination network address. The apparatus comprises a storage arrangement (60, 61, 62) for receiving and storing flow data exported by a plurality of the router devices (30, 40, 50), the stored flow data including at least source network address information, destination network address information and incoming interface information in respect of individual flows of data. The storage arrangement (60, 61, 62) is further operable to store network configuration information specifying which other of the router devices are connected to which incoming interface or interfaces of each router device. The apparatus further includes processing means (60, 65) for tracing the route taken through the network (1) by a particular flow in dependence upon the stored flow information and the stored network configuration information.

Description

Method and Apparatus for Monitoring a Digital Network

Field of the Invention

The present invention relates to a method and apparatus for monitoring a digital network, and in particular to a method and apparatus for tracing back through an Internet Protocol (IP) network to find the path followed by a specified IP packet or flow through the IP network.

Background to the Invention , Internet Protocol (IP) was not designed with security in mind. As a consequence, malicious users tend to exploit a number of features of IP to enable them to launch attacks against routers and hosts connected to an IP network. One common form of attack is a Denial of Service (DoS) attack, and in particular a Distributed Denial of Service (DDoS) attack.

DDoS attacks typically work by having a malicious user launch a virus, worm, Trojan etc (i.e. a small malicious piece of software which is installed on an innocent user's computer without the user's (explicit) consent). The virus then typically presents a "backdoor" to the malicious user, by which the malicious user can install further malicious software on the innocent user's computer. At this stage the innocent user's computer is said to be a "zombie" computer. The malicious software can then be used in a coordinated effort with a large number of other "zombies" similarly programmed by the malicious user to start issuing lots of malicious requests for service to a web-site at exactly the same time, causing the web-site to become overloaded and unable to satisfy all of the requests; any genuine requests for the web-site arriving at this time are likely to be refused until the overload subsides.

As part of the attack, the source IP address of the zombies is usually "spoofed". This involves placing an incorrect IP address in the source IP address field within any IP packets sent from the zombie computers. This makes it difficult to ascertain which computers are sending the malicious requests for service.

NetFlow is a software tool originally developed by Cisco in 1996 and now provided by

Cisco (and other manufacturers) on most of its (their) IP routers. When a Cisco (or compatible) router is adapted and configured to perform NetFlow monitoring, each interface for which it is so configured/enabled is monitored and information about the IP network data flows is stored at a buffer (the "NetFlow cache") and may from time-to-time (either after the flow is deemed to have finished or at fixed intervals of time depending on the configuration of the router) be exported to another device (e.g. a server) acting as a "NetFlow collector." Alternatively (or additionally) the contents of the NetFlow cache may be queried directly by a network administrator using the router's administrative interface (i.e. the control or management interface). If configured to export NetFlow data, NetFlow "records" are "exported" from the router by sending records in User Datagram Protocol (UDP) packets to a specified "Collector" device (for which the IP address and port is specified by the administrator during configuration). IP network data flows have been defined in many ways. In the case of NetFlow, Cisco uses the common 5-tuple definition, where a flow is defined as a unidirectional sequence of packets all sharing the same source and destination IP address, source and destination port, and IP protocol in its earlier protocols, but uses a 7-tuple definition in its latest version of NetFlow (version 9) which additionally includes a Type of Service value and a router incoming interface value. (Note these are called a 5-tuple and a 7-tuple since they are a set of 5 and 7 values respectively. Note also that although, in the earlier versions of NetFlow, the incoming interface is not included as part of the definition of a flow, each export report none-the-less still includes an id of the input interface.)

In the paper "Tracking Spoofed IP Addresses Version 2.0" by Rob Thomas (a copy of which is available in the Team Cymru Document Collection at http://www.cymru.com/Documents/tracking-spoofed.html - published 2001) a method of tracing back the origin of IP data flows with spoofed IP addresses is described. The method involves ensuring (e.g. by issuing a suitable configuration command) that each router of interest has NetFlow monitoring switched on. When a Denial of Service attack is detected, a network administrator then attempts to trace back the origin of a suspicious flow by querying the NetFlow cache of each incoming interface of the destination router (i.e. the last router in the path through the network which transmitted the suspicious flow before arriving at it's destination, the victim or target node). Once the suspicious flow is detected, the network administrator can ascertain on which incoming interface the flow was received and, with his knowledge of the network configuration, s/he can thereby deduce the possible candidate(s) for the preceding router in the path. The administrator then queries the (or each) such candidate router's NetFlow cache(s) to identify which incoming interface (and of which upstream router) the flow was received on. This process is continued by the administrator until the entire path of the suspicious flow through the network is established. If the method is successful, the administrator will trace the flow back to either a router at the edge of the network within the administrator's domain where it interconnects to a neighbouring network (at this point, the best the administrator can do is ask an administrator of the neighbouring network to trace the flow back through his/her network) or to an interface on a router which connects directly to end-point computers (as opposed to other routers). At this point, a command such as "show arp" can be invoked by the administrator on the router in question and this displays to the administrator details of the Address Resolution ProtocoJ (ARP) cache table held by the router. This should list all of the active devices connected to the router device (as well as information about the interface to which they are connected). From this it may be possible to deduce immediately, the suspect device (e.g. if there is only one active device associated with the detected network interface); alternatively, there may be a number of active devices in which case any of these could be the suspect device.

Note that this method must be performed fairly speedily by the administrator, since the NetFlow caches are cleared whenever a record is exported, so the process must be performed before the pertinent records are exported. This is not too much of a problem for the described method since the purpose is to try and disrupt an ongoing attack and so needs to be done pretty quickly in any event.

Summary of the Invention

According to a first aspect of the present invention, there is provided a method of tracing the route taken through a network by a flow of data, the network including a plurality of router devices, the method comprising: receiving flow data exported by a plurality of the router devices at a storage arrangement; storing at the storage arrangement at least some of the received flow data, including at least source network address information, destination network address information and incoming interface information in respect of individual flows of data; storing at the storage arrangement network configuration information specifying which other of the router devices are connected to which incoming interface or interfaces of each router device; and tracing the route taken through the network by a particular flow by tracing back from the destination router using the stored incoming interface information for the particular flow together with the configuration information.

Preferably, all of the above steps are automated, with the automated process receiving as an input the "suspicious" IP address for tracing back, possibly in combination with the "suspected victim" destination IP address or the identity (e.g. an IP address) of the (or a) router directly connected to the "suspected victim" destination; the automated process then preferably outputs as the result of the process the "suspected attacker" device identity (e.g. its MAC address or actual IP address) or the identity of the (or a) router directly connected to the "suspected attacker" device. Note that it is anticipated that in the majority of cases the suspected attacker device will be a "zombie" device. In such a case, it may be possible to send a message to the or each possible suspected attacker device warning that their computer may have been compromised and offering some advice on action they can take to remove any malicious software inadvertently running on their machine. Thus the present invention most preferably further comprises the additional step of notifying the user or users of the of the suspected device or the network administrator of the network of which the suspected device or devices is believed to be a member.

Note that this process relies on the routers exporting their flow data (e.g. NetFlow records) to a storage arrangement before the trace can be made. This has a number of consequences. Firstly, it means that there will necessarily be some delay between when a suspicious flow occurs and when it can be traced by the present method/system. Unless the routers are configured to export their flow data (e.g. NetFlow records) on a very regular basis, it is unlikely that this method can be used to halt an ongoing DDoS attack where each attacker sends only a short burst of messages. However, this is also true for the method described in the Thomas paper discussed above. Furthermore, the method is still useful even where it cannot stop a first attack, since it may identify a "zombie" device. Having identified a zombie device it is possible to contact the device's user/administrator and assist in removing the malicious software so that it no longer functions as a zombie device, thus possibly preventing it from participating in any number of subsequent DDoS attacks. Another consequence of the NetFlow data being exported to a storage arrangement is that it is not necessary for a user wishing to perform a trace back to interface directly with the routers in question; instead, the routers can be configured at the outset to automatically export their data on a periodic basis. This not only eases the strain on the routers, but is also less likely to cause any administrators to have concerns over the operation of the devices being compromised by an attacker managing to access the routers through the administrators interface, etc. Generally, the less this interface is used, and the more routers are left to operate autonomously, the more secure and stable the routers will be.

The term "storage arrangement" is merely intended to indicate that the exported data is stored in such a way that it can be quickly and easily searched through for the purposes of performing a trace-back without having to set up communications with the respective routers (i.e. the data must have been exported). In fact, the exported data could well be stored in a distributed manner if this is more convenient (e.g. if the network administration computing system has a distributed architecture) but it is to be distinguished from an arrangement in which the data are stored on the routers themselves, in the way that they are prior to the routers exporting their flow data (e.g. NetFlow records).

According to a second aspect of the present invention, there is provided apparatus for tracing back a flow of data through a data network, the apparatus comprising: a storage arrangement for receiving and storing flow data exported by a plurality of the router devices, the stored flow data including at least source network address information, destination network address information and incoming interface information in respect of individual flows of data; the storage arrangement being further operable to store network configuration information specifying which other of the router devices are connected to which incoming interface or interfaces of each router device; and processing means for tracing the route taken through the network by a particular flow in dependence upon the stored flow information and the stored network configuration information.

According to a third aspect of the present invention, there is provided a data network including a plurality of router devices configured to periodically export data flow information to a remote storage arrangement (either directly or via one or more intermediate devices operating as data flow collectors) and processing means for processing the stored data flow information together with network configuration information to identify the route taken through the network by a specified data flow or packet.

Further aspects of the invention relate to computer programs for carrying out the method of the invention, carrier means carrying such computer programs and apparatus when so programmed.

Brief Description of the Drawings

In order that the present invention may be better understood, embodiments thereof will now be described, by way of example only, with reference to the accompanying drawings in which:

Figure 1 is a block diagram of a simple data network according to an embodiment of the present invention; and

Figure 2 is a flow chart of a method, of tracing the route taken through a network, such as the data network of Figure 1 , by a flow of data, according to the present invention;

Detailed Description of a First Embodiment

Figure 1 is a block diagram of an example Internet Protocol data network 1 including a flow tracing device 60. The flow tracing device 60 includes a network configuration data store 61 which stores network configuration information including information about which routers are connected to which other routers and via which interfaces. The flow tracing device 60 further includes a Flow data store 62 which stores data about data flows which have been detected and reported by the routers within the network 1. The flow tracing device also includes a processing unit 65 whose operation, as relevant to the present invention, is described below. The flow tracing device also includes a notification means 66 which is operable to send notifications to network administrators, device administrators or device users that their device is suspected of being corrupted. Such a message may be delivered electronically or by more conventional means (e.g. by post). Preferably it requires human to human interaction after sending the message to avoid such messages either being mistaken for phishing messages, or imitated by actual phishing messages. The Network 1 also includes a number of host devices 20 - 26 including a victim server computer 20, an attacker computer 26 and 5 other host computers referred to as hosts 1 - 5 (with associated reference numerals 21-25 respectively).

Each of the hosts 20-26 is connected to one of three different Ethernet networks 11 , 12, 13 as follows:

Victim server computer 20, Host 1 computer 21 and Host 2 computer 22 are connected to a first Ethernet 11 which is configured as a default class C IP network (i.e. with a subnet mask of 255.255.255.0) with IP network (or subnetwork) address of 10.1.3;

Host 5 computer 25 is connected to a second Ethernet 12 with an IP subnetwork address of 10.2.3; and

Attacker computer 26, Host 3 computer 23 and Host 4 computer 24 are connected to a third Ethernet network 13 with an IP subnetwork address of 10.3.3.

Each of the hosts has been statically assigned an IP address as follows:

Victim server computer : IP address 10.1.3.3; Host 1 computer 21 : IP address 10.1.3.4;

Host 2 computer 22: IP address 10.1.3.5;

Host 3 computer 23: IP address 10.3.3.3;

Host 4 computer 24: IP address 10.3.3.4;

Host 5 computer 25: IP address 10.2.3.3; Attacker computer 26: IP address 10.3.3.5.

The Network 1 also includes a plurality of router devices 30, 40, 50.

First router device 30 has three network interfaces 31 , 32, 33 comprising an Ethernet interface 31 and first and second serial connection interfaces 32, 33 having the following respective IP addresses 10.1.3.1 , 10.10.3.3 and 10.9.3.3.

Second router device 40 has two network interfaces, a serial connection interface 41 having IP address 10.9.3.4 and an Ethernet Interface having IP address 10.2.3.1. Third router device 50 also has two network interfaces, a serial interface 51 having IP address 10.10.3.4 and an Ethernet interface 52 having IP address 10.3.3.1.

Finally, Figure 1 also includes an arrow 80 which indicates the route taken by a data flow identifiable by means of having a (spoofed) source IP address of 96.170.2.3 and a destination IP address of 10.1.3.3. Throughout this description, this data flow 80 will be used as the example data flow to be traced.

Network Configuration The three routers are configured within the network as follows:

The first router 30 is connected to the second router 40 via it's second serial interface 33 and to the third router via its first serial interface 32. Additionally, the first router 30 is connected to the first Ethernet network 11 via its Ethernet interface 31 (although there are no other routers connected to this interface).

The second router 40 is connected to the first router 30 via its serial interface 41 and to the second Ethernet network 12 via its Ethernet interface 42 (although there are no other routers connected to this interface).

The third router 50 is connected to the first router 30 via its serial interface 51 and to the third Ethernet network 13 via its Ethernet interface 52 (although there are no other routers connected to this interface).

This network configuration information is stored in the Network Configuration database 61 , in the present embodiment, in the form of a table as set out below:

Table 1

Router 2 10.2.3.1 - -

Router 3 10. 10.3 .4 Router 1 10. 10.3.3

Router 3 10 .3.3. 1 - -

Data Flows

As mentioned above, many IP routers (e.g. those produced by Cisco or Juniper Networks) have a facility to perform data flow monitoring (what is referred to as "NetFlow monitoring" by Cisco; Juniper routers provide a similar facility). As part of this monitoring, each router can be configured to periodically export data flow reports. The format of these reports and the exact information included in them varies depending on the exact version of the data flow monitoring tool being used to generate the reports, (for example, many Cisco routers will export reports in NetFlow v. 5 in which case reports are exported in UDP packets, each packet having a NetFlow protocol header and data part with respective structures as specified by Cisco at, for example, the following web-site address www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/nfc/nfc_3_0/nfc_ug/nfcform.htm). However, most versions will include at least enough data to enable the following fields to be populated within a second table (or series of tables - one for each interface (of each router)):

Table 2

This information can either be obtained directly from the export reports (e.g. UDP datagrams) or it can be obtained from another pre-processing tool (such as the Open Source suite of programs developed by Ohio State University referred to as Flow-tools or one of Cisco's tools such as NetFlow FlowCollector). In the present embodiment, the Time Stamp information is obtained from the field in the header of v. 5 NetFlow export packets which gives the Unix time as recorded by the router at the time it creates the packet. For the purposes of the present invention, this information only needs to be approximate so any suitable source of time information can be used to populate this field. Also note that in NetFlow v. 5 the interface information is provided in the form of the SNMP ifindex (InterFace INDEX) of the interface and this is then converted into the IP address of the interface, however, any reasonably unique identifier of the interface could be used for this purpose.

The timestamp information can be used to expire data once it becomes too old to be worthwhile storing if there is a restriction on the amount of storage space available for storing information in Table 2. In the present embodiment, data is stored for a 24 hour period and then it is expired.

Flow Tracing device 60

As mentioned above, the flow tracing device 60 includes two data stores 61 , 62. In the present embodiment, these store the two tables (Table 1 and Table 2) described above. In the present embodiment, the flow tracing device 60 is responsible for receiving data flow report packets of data directly and automatically processing these to obtain the information necessary to continually populate/update the table 2 information stored in the flow data store 62. The table 1 information is directly input by an operator of the system based on the configuration of the network 1 and is only updated intermittently by an administrator whenever the network configuration changes.

The flow tracing device is arranged to receive and automatically process any input requests for tracing a dataflow through the network. In the present embodiment, the flow tracing device allows this to be done in either of two possible ways. In one approach it presents a simple user interface (not shown) to a remote user by which the user may enter the flow details of the flow to be traced; after tracing the output information is then displayed to the user via the same remote user interface. Alternatively, another software application may pass the flow details of the flow to be traced in accordance with a prespecified Application Programming Interface (API) and the result of the trace is similarly returned to the requesting application in accordance with the specified API.

Trace Back Method Referring now to Figure 2, the steps performed by the trace back device 60 in order to automatically trace back the path of a data flow through the network 1 are now described.

At step S10 details of a flow to be traced are supplied to the trace back device 60; these details include at least the source and destination IP addresses of the flow to be traced. Additionally, the information may also include an approximate time of the flow being detected or a period of time (indicated by a start and stop time) during which the flow was believed to have been present on the network 1.

At step S20, the trace back device 60 identifies the router and interface which transmitted packets in the flow to be traced to the destination device (as identified by the destination

IP address of the flow to be traced). In the present embodiment, this is done by searching through the Network Configuration Information data base 61 (i.e. table 1) and identifying the router and interface whose IP address includes a network portion which matches the network portion of the IP address of the destination device. Considering the example of Figure 1 , if asked to trace back the data flow 80 with source and destination IP addresses of 96.170.2.3 and 10.1.3.3 respectively, table 1 is searched for an interface with an IP address commencing 10.1.3 (since this represents the network portion of the IP address in network 1). The only interface with this network portion is the Ethernet interface 31 of

Router 1 (which is correct since this is the interface serving the victim server computer 20 which has the IP address 10.1.3.3 which is the given destination address). Note that the device does not use the same process to find the final router in the chain (which is what we are trying to find) precisely because we believe that the specified origin IP address is spoofed.

At step S30 the trace back device 60 obtains from the Flow Data database 62 all records for all of the interfaces on the router identified in step S20 apart from the interface identified in step S20. Note that if the original request information included an estimated time, then the search can be initially restricted to those records whose time stamp corresponds with the indicated time. Continuing with the example of tracing the data flow 80, the records stored for the two serial interfaces 32 and 33 are selected.

Having obtained (or at least identified) the relevant records through which to search in step S30, the method of the trace back device 60 then proceeds in step S40 to search through these records looking for a record containing the specified source and destination IP addresses. As soon as one is found, the interface associated with this record is identified before proceeding to the next step. Thus for data flow 80 a record is found in table 2 associated with the first serial interface 32 of router 1 (see table 2 above and the first row referencing the interface having IP address 10.10.3.3 which is the IP address of the first serial interface 32 of Router 1).

At step S50 the trace back device 60 determines whether there is an upstream router within the domain monitored by the flow back device (i.e. for which it is receiving data flow export reports and in respect of which it has information stored in its databases 61 and 62) by examining its configuration data in the configuration database 61. If at least one such router device is found, then the method proceeds to step S60, otherwise, the method proceeds to step S70. Thus continuing with the example of Flow 80, the first table is searched for all rows including the first serial interface of router 1. From the second row of this table :

it is determined that there is such a connected router (namely Router 3) and that it is connected by it's serial interface 51 (having IP address 10.10.3.4).

At step S60 the trace back device 60 then checks the records for the interface(s) identified in step S50 and determines if it includes any records which match the data flow 80 being traced. If such a record or records are found, then the method loops back to step S30. The method can continue in this way through as many iterations as needed until the flow is traced back to an edge point of the network; such an edge point could be a point where the network connects to another network which is not being monitored by the trace back device or a point at which the attacking host is connected directly to the router in question. If, however, no matching records are found associated with the interface(s) identified in step S50, then the method proceeds to step S70.

Continuing on with the present example concerning data flow 80, after the first iteration of the method it is established in step S60 that the first serial interface of Router 3 does indeed include a record for data flow 80 having source IP address of 96.170.2.3 and a destination IP address of 10.1.3.3, thus the method loops back to step S30 for a second iteration. After a second iteration of steps S30 and S40 the Ethernet interface 52 of the third router 50 (Router 3) is identified as the point at which the data flow to be traced entered the router. However, in the second iteration of step S50 it is determined from the configuration database 61 that there is no upstream router being monitored by the trace back device 60 connected to this interface 52 and therefore the method proceeds to step S70 after the second iteration of step S50.

At step S70 the trace back device 60 determines, by searching through the network configuration database 61 , if there is a connection to a router which is not being monitored by the trace back device 60. Typically, this will be the case where the router connects to a neighbouring domain. Note that in such a case it is unlikely that the same interface will also connect directly either to more than one domain, or to non-router host devices. It is therefore likely that the flow to be traced will have originated from a point external to the network being monitored and so there is a limited amount that can be done in carrying on with the back tracing. In the present embodiment, in such a situation the method proceeds to step S80, but otherwise the method proceeds to step S90. In step S80 a message is sent to an administrator of the neighbouring domain informing them that a possibly malicious data flow has been traced back as originating from their network and leaving the issue in their hands as to whether or not they wish to try and trace back the flow themselves. The method then proceeds to step S90.

In step S90 the flow back device 60 outputs back to either the GUI or the calling application the results of the trace back in the form of the last identified router and interface back to which the flow has been traced. In the example which we have followed thus far of flow 80, this would be the third router 50 (Router 3) and its Ethernet interface 52 with IP address 10.3.3.1. The method then ends.

From the resulting router and interface information, if the interface is known to connect to end-user host devices (as in the case of our example concerning flow 80) then further follow-up procedures can be used to try and identify the actual host device sending the spoofed traffic.

If the router is not excessively stretched, it may be possible to utilise some facilities provided by the router itself to try and identify the attacker host. For example, the Address Resolution Protocol (ARP) cache on the router can be consulted. If there is only one active host present on the interface during a time period during which the flow to be traced (or another suspicious flow - i.e. one not seemingly originating from a host connected to the relevant network) is being received at the interface, then that host is very likely to be the attacker host.

If the interface connects to a Local Area Network (LAN) such as an Ethernet, it may be possible to get one of the hosts connected to the LAN to execute a packet sniffing tool and from this to try to identify any host which is sending out IP packets with a source IP address given which does not agree with any MAC address/ IP address correspondences declared by the host in an ARP message, or, more simply, any IP packets giving a source IP address whose network portion does not appear to correspond to the network portion of the IP address of the interface, etc.

In general, the most preferred way of identifying a zombie device within an Ethernet LAN which is administered by a network administrator for that LAN is to notify the LAN

_] administrator of the potential problem. Note that in the present embodiment, notification of the LAN administrator is performed automatically by the notification means 66, which, in the present embodiment, includes a table specifying contact details for all of the network administrators in association with their respective networks that they administer which directly border the network 1 , for this notification purpose - also note, however, that in alternative embodiments this information could be dynamically accessed from publicly available sources queried dynamically and automatically by the notification means. Having duly notified the respective (LAN) network administrator of the problem the present method then leaves the details of how the actual zombie device itself is to be identified up to the (LAN) network administrator. The network administrator then has several possibilities open to him/her for attempting to ascertain which device has become corrupted (assuming that one of his devices has been corrupted by malicious software, as is most likely, rather than that a legitimate user of the device is behaving maliciously). One possibility is to use packet sniffing tools to look for packets destined to leave the network which contain dubious IP source addresses. These could be detected either because the IP address is unknown to the network administrator, or because it belongs to an address range which lies outside of the address range used by the LAN, or because the same IP address is being used in conjunction with two different MAC addresses. In this last case it may in many cases be possible to identify the correct user of the IP address by generating an ARP request.

Typically, zombie devices use their own specialized TCP/IP module for providing TCP/IP services to the malicious traffic, while normal traffic continues to be dealt with by the normal legitimate TCP/IP function. In such a case, the legitimate TCP/IP function will respond correctly to any ARP requests requesting the MAC address for the particular IP which it is believed is being spoofed by one device on the network. In this way the MAC address of a zombie device which is spoofing its IP address as one of its fellow neighbours on the same LAN can be deduced (it's not the one received in any correct

ARP response). From this, the network administrator can use a tool such as CC get MAC address to obtain the correct IP address and the correct assigned computer name for the suspected device. This can then be used by the Network administrator, in general, to identify the actual suspect machine and from this action can be taken (e.g. either by physically going to the device in question and running some anti-virus software on it, etc., or by requesting that a listed user of this device do so.

Where the end router is a Broadband Remote Access Server (BRAS) or similar device connecting to end users via a broadband access network such as an access network connecting users via Digital Subscriber Line technologies or other broadband access techniques (e.g. Passive Optical Networks, etc.), then it may be possible to have the BRAS or similar device perform some checking on incoming IP packets to check that they specify a source address which corresponds to an IP address which it regards as an active IP address in its ARP cache, etc.

Claims

1. A method of tracing the route taken through a data network by a flow of data, the network including a plurality of router devices, the method comprising: receiving flow data exported by a plurality of the router devices at a storage arrangement; storing at the storage arrangement at least some of the received flow data, including at least source network address information, destination network address information and incoming interface information in respect of individual flows of data; storing at the storage arrangement network configuration information specifying which other of the router devices are connected to which incoming interface or interfaces of each router device; tracing the route taken through the network by a particular flow by tracing back from the destination router using the stored incoming interface information for the particular flow together with the stored configuration information to identify an original incoming interface to the data network; and where the incoming interface is to a network of devices, notifying the administrator of the network that it possible has a corrupted device on its network; or where the incoming interface is to a single device, notifying the user or administrator of that device that the device is possible corrupted.

2. A method according to claim 1 wherein the step of tracing the route is performed by a processor forming part of a flow tracing device.

3. A method according to claim 1 or 2 further comprising configuring a plurality of routers within the data network to periodically export flow data to the storage arrangement either directly or via a computer configured as a flow data collector.

4. A method according to any preceding claim further comprising receiving as input data about the flow to be traced including a destination network address and a source network address.

5. A method according to claim 4 wherein the input data further includes data about the time at which the flow to be traced was detected in the network, and wherein the storage arrangement additionally stores information about the times of occurrence of individual flows of data.

6. Apparatus (60) for tracing back a flow of data through a data network (1), the data network including a plurality of router devices (30, 40, 50) for routing packets of data through the network based on a given destination network address, the apparatus comprising; a storage arrangement (60, 61 , 62) for receiving and storing flow data exported by a plurality of the router devices (30, 40, 50), the stored flow data including at least source network address information, destination network address information and incoming interface information in respect of individual flows of data; the storage arrangement (60, 61 , 62) being further operable to store network configuration information specifying which other of the router devices are connected to which incoming interface or interfaces of each router device; processing means (60, 65) for tracing the route taken through the network (1) by a particular flow in dependence upon the stored flow information and the stored network configuration information; and notifying means for: where the incoming interface is to a network of devices, notifying the administrator of the network that the network possibly has a corrupted device; or where the incoming interface is to a single device, notifying the user or administrator of that device that the device is possible corrupted.

7. Apparatus according to claim 6 wherein the storage arrangement is additionally operable to store information indicative of the time of a particular flow as part of the stored flow data.

8. A data network comprising a plurality of router_. devices and tracing apparatus according to claim 6 or 7, wherein the router devices are configured to export flow data to the storage arrangement of the tracing apparatus.

9. Computer processor implementable instructions for causing a digital processor to carry out the steps of any of claims 1 to 5.

10. Carrier means carrying the processor implementable instructions of claim 9.