WO2018007917A1

WO2018007917A1 - Network scanning system

Info

Publication number: WO2018007917A1
Application number: PCT/IB2017/053962
Authority: WO
Inventors: Anthony MCDOWELL; Campbell MURRAY
Original assignee: Encriptor Ltd
Priority date: 2016-07-08
Filing date: 2017-06-30
Publication date: 2018-01-11
Also published as: GB201611927D0

Abstract

A method for scanning a local network from a remote infrastructure comprises setting up a VPN connection between the two, using an entity on the local network. The remote infrastructure uses network address translation (NAT) to direct incoming traffic from the entity to a scanning engine on the remote infrastructure. The entity also carries out NAT to change the apparent source of scan packet data coming from the scan engine to that of the entity, and to further use NAT to change the apparent destination of responses from the target computer from that of the entity to that of the scan engine. Embodiments of the invention therefore provide a method for scanning a network that allows a scanning engine to scan a local network from a remote infrastructure, but with the scanning engine effectively being part of, via the VPN and the use of NAT, the local network. The scan will typically be a security scan.

Description

Network Scanning System

This invention relates to a system, method, and associated devices for implementing a scan, such as a security scan, of a client network. More particularly, it relates to a system for implementing a remote scan of a network in a manner that allows relatively strict firewall settings to be maintained on the client network.

Background

Computer networks are ubiquitous in modern businesses. It is extremely commonplace for businesses to have some sort of online presence, as well as having their own internal computer networks for providing essential business related activities, As reliance on such networks increases, the security of these networks has become a critical issue for the integrity of any business using one. Network penetration attempts from external agents are common, and so the use of firewalls, which limit the access that a local network has with external networks (e.g. the internet) are regarded as essential. Any business that operates a local network also needs to consider vulnerabilities from attacks internal to the network. Network security generally is therefore increasing in importance and significance. Virus scanners, that may operate on a local machine, or may be run from a server on a local network are often used to check a computer, or multiple computers on a network, for known vulnerabilities. These provide a degree of reassurance to a user. However, they have various limitations. For example, they are required to update their database of virus signatures at regular intervals, The internal (to a local network) server or computer that is performing a virus scan or database update is vulnerable to attacks that may, for example, seek to cripple or degrade the virus checker or its database, and hence allow malware to escape detection. Networks may also have other issues that may have a security concern. For example, legitimate, but outdated or misconfigured software can be a problem.

Problems could be as simple as leaving a default password in place for database software. Any attacker able to connect to the database by any means (either directly or working through other flaws in an online web GUI for example) may then be able to use that password to take control of the database, exposing any sensitive data held on it, such as password hashes, email addresses, or credit card details.

One known technique for avoiding these problems is to bring in a new computer or server to a network, that contains security scanning software such as a virus scanner. This new computer will not therefore have been subject to any previous malware attacks from the local network, and hence provides an additional degree of confidence in the result of any scans it provides. However, it can be costly in terms of the requirement to physically bring in the computer, and often also a skilled and trusted operator, to perform the scan.

A solution to this problem is to operate the scan remotely, through a wide area network (e.g. the internet). This can cause additional problems in terms of the need to have various ports open to the internet, that can provide an attack vector for hackers and the like. It is also difficult to guarantee that the threat surface as seen from within a network will be exactly mirrored when seen by an external scan. This therefore leaves a doubt as to the validity of the external scan results.

Embodiments of the invention have the object of addressing one or more of the above shortcomings of the background art.

Brief Summary of the Disclosure

According to a first aspect of the present invention there is provided a method for facilitating a scan of a local network from a remote infrastructure, comprising the steps of: a) from one of: an entity within the local network, and the remote infrastructure, initiating a request for a scan to the other; b) establishing between the entity and the remote infrastructure a virtual private network (VPN) connection; c) through the VPN, using Network Address Translation (NAT) at the remote infrastructure to direct incoming traffic from the entity on local network to a scanning engine on the remote infrastructure; d) using the entity within the local network as a router, carrying out a scan of the local network through the VPN using the scanning engine on the remote infrastructure; wherein the entity is adapted to direct scan packet data, produced by the scan engine and received through the VPN, to one or more target computers on the local network using NAT to change the apparent source of the scan packet data coming from the scan engine to that of the entity, and to further use NAT to change the apparent destination of responses from the target computer from that of the entity to that of the scan engine.

Embodiments of the invention therefore provide a method for scanning a network that allows a scanning engine to scan a local network from a remote infrastructure, but with the scanning engine effectively being part of, via the VPN and the use of NAT, the local network.

The scan will typically be a security scan.

In some embodiments of the invention the entity within the local network that initiates the request for a scan comprises a dedicated hardware unit that is connected within the local network. Advantageously it may be connected to a router, so providing access to some or all of the computers or servers that form the network. The entity may conveniently comprise a processor with associated memory and storage, along with means for connecting to the local network. It may have a wired, or a wireless connection. The entity may also incorporate a web server, conveniently allowing authorised users to log on to the entity for initialisation of the entity, and to access user settings.

In other embodiments the entity may be implemented in software, e.g. on an existing computer within the local network. Such an implementation is not preferred however, as it may be more vulnerable to attack or analysis from malware located either on the host computer, or on another computer that has access to the host computer through the local network.

The entity may advantageously be arranged to periodically connect to the remote infrastructure (such as on an hourly, or daily basis), to download scan schedule information, and to upload any user preference settings. The entity may also be arranged to connect to the remote infrastructure if demanded by a client on the local network, e.g. to initiate an immediate security scan. The entity may preferably be arranged to connect to the remote infrastructure using a standard HTTPS (or, less preferably, a HTTP) connection, which is likely to have an open path through any locally installed firewall.

Advantageously, the entity may also be arranged to carry out the initiating request in step a) and to establish a VPN in step c) using a port used by the network for secure web browsing. This allows the entity to use a port that will, in most networks, be configured in a network's firewall, to allow traffic to pass through. Once the VPN is established using such a port, then most other communication connected with the scan (other than that relating to the establishment or decommissioning of the VPN) can take place through the VPN.

Therefore, all traffic flowing through the VPN will appear to the firewall as standard encrypted internet traffic, and thus will be allowed to pass through. The port used may be port 443, which, as a normally skilled person would be aware, is a standard port used for HTTPS traffic, although it will be appreciated that other ports may be used, without departing from the scope of the invention.

Advantageously, the remote infrastructure (or a firewall connected thereto) may be arranged to accept connections (e.g. connections through HTTPS) only from known IP addresses. This is possible because the remote network can be provided with IP information relating to client (i.e. local network) IP addresses, as the remote infrastructure may be operated by the same concern (or a partner concern) as that providing the entities to the local networks. This improves security by preventing access to the remote infrastructure from unknown IP addresses.

The scan engine may run on a scan server, and the scan engine, and may, using the approach detailed herein, scan target computers on its network, or on a network to which it is connected, e.g. via a VPN tunnel. The scan server may be a physically separate server to that of other servers on the remote infrastructure, such as a VPN server. Alternatively, the scan server may be a virtual server operating on the same hardware as that of other server(s). Alternatively, the scan server may be a shared server, server as the first server, which simplifies the routing required between the scan server and the VPN, although this latter approach is not preferred, as it reduces flexibility when dealing with multiple scan servers.

An embodiment may have a single scan server, that is arranged to connect to one or more local networks, via one or more VPNs, or may otherwise have fewer scan servers than there are client networks requiring scanning. As a client network is likely to have ports associated with normal web browsing (such as port 80, and, for encrypted traffic, port 443) open, it is desired to use one of these ports for all traffic flowing into and out of the client network, as explained above

The VPN servers provide, via a separate VPN tunnel to each client network, a means for connecting to each client, NAT is used on the VPN server to avoid clashes. Each VPN tunnel uses its own unique port, with NAT being used to convert incoming (to the remote infrastructure) data from (typically) port 443 to that of the VPN tunnel port, to enable returning packets to arrive at the correct VPN connection.

Conveniently, there may be multiple scan servers present on the remote infrastructure. Each one may be connected to one or more VPNs, and hence to one or more local networks.

The NAT is implemented at the remote infrastructure, prior to the establishment of the VPN tunnel. It may, for example, be implemented within a firewall residing within a server or logically adjacent thereto on the remote infrastructure.

By such means, a communication link may therefore be established between the (remote) infrastructure and one or more local networks, with the or each local network

communicating through its standard HTTPS port, running a VPN tunnel to the remote infrastructure. The remote infrastructure may therefore host a plurality of VPN tunnels, each separately addressable via unique IP tunnel addresses. The (or each) entity is also arranged to implement NAT, so that computers on the local network see data packets (from the remote infrastructure) that are directed to the local computers, as coming from the entity. Each VPN connection on a VPN server, typically established using OpenVPN, must be assigned a unique port. To allow all clients to use (say) port 443 (as detailed above), NAT is used at the VPN server to re-write the destination address of incoming data to the appropriate VPN port assigned to each client, as determined by the data packet's source address.

Preferably, the VPN connection(s) are arranged to use a peer-to-peer VPN connection, in which both the entity and the remote VPN server initiate the connection simultaneously, or at a similar time (i.e. within a period before the earlier initiator times out and abandons the attempt). This allows the VPN connection to be made without requiring any special settings made to client firewalls, other than what is likely to be already set up in a standard arrangement. It also avoids a security problem associated with having a VPN service running in "server mode" on the remote infrastructure, , with multiple local client networks connecting to it, which would mean multiple different clients being on the same network simultaneously, and presenting associated security risks. However, it does mean that each VPN endpoint on the VPN server (i.e. one per client connected to it) needs to operate on a different port, with a unique port being used for each client network. To allow a single port to be used during the connection across the client's firewall, without any amendment to their standard settings, it is preferable to use e.g. port 443 or port 80 as explained herein. This is where the use of NAT on the remote infrastructure comes in, allowing the port used by the VPN daemon to be translated to the port in use based on the source address of the packet (which uniquely identifies the client), and to do the reverse for outgoing traffic.

A scan server (e.g. a server adapted to implement a security scan upon devices connected to its local network) may then be connected to each VPN tunnel at the remote

infrastructure, and may communicate directly with the entity at the local network end of the VPN tunnel, as if it is sitting on the same network.

The scan server may be arranged to scan across all extant VPN tunnels. It may, in some embodiments, be arranged to multiplex its scanning across the extant VPN connections, e.g. by time multiplexing, as described below.

It will be understood by the normally skilled person that the instigation of a VPN connection creates a tunnel through which data can pass securely. This data has its own independent addressing requirements, with IP addresses being used for source and destination nodes that generally differ from those used to identify the remote infrastructure and local network systems. In some embodiments the IP addresses used by the nodes may advantageously be chosen from those IP addresses that are not generally in use in open systems. Such addresses are often classed as reserved addresses, by the various bodies that administer the IP address system, including the Internet Engineering Task Force or the Internet

Assignment Numbers Authority. As it is very unlikely that the network (if it has been set up in accordance with commonly known good practices) will be using these reserved addresses, the chances of any addresses used in the creation and operation of the VPN conflicting with addresses used in the local networks are minimised.

Embodiments of the invention therefore have an entity within the local network that is arranged, when the scan is initiated, to implement NAT to establish, within the local network, scan data coming from a remote infrastructure via a VPN tunnel as instead coming directly from the entity. Thus nodes that are on the local network, such as computers, network servers etc. will see data that is coming ultimately from the remote infrastructure running the security scan process as instead coming from the entity connected to the local network to which they are also directly connected. The VPN connection therefore allows the remote infrastructure network, and its associated functions (such as a scan server and VPN server) to connect simultaneously to individual computers located within multiple local networks, even when those individual computers are using the same IP address. Where a target computer is present on a first local network that has the same internal IP address as a target computer on a second local network, then various methods may be used to overcome this conflict. If there are two scan servers present on the remote network, then each target computer (that shares an IP address with another on a different network) may be assigned its own scan server. Thus each scan server will then only have a single computer having a particular IP address, and no address conflict will arise. Alternatively, if there are more target computers that share IP addresses with others on different networks than there are scan servers, then a queueing system may be used, to time-multiplex the scan server(s) to the particular target computers. The queueing system may be implemented in any convenient manner, such as that described herein.

According to a second aspect of the invention there is provided a system for scanning one or more target computers on one or more local networks, the system comprising a remote infrastructure, and one or more local computers (Entities) running on respective local network(s), the remote infrastructure comprising: i) means, such as a Virtual Private Network, VPN, server, for establishing its end of a VPN tunnel between it and at least one of the local computers; ii) means, such as a scan server, that is adapted to run a scanning engine, that is connectable to the local computer via a VPN; iii) means, such as Network Address Translation (NAT) and packet routing software that is executable on the remote infrastructure for directing packet data between the local computer(s) and the scan server and the at least one local computer comprising: iv) means, such as a VPN server, for establishing its end of a VPN tunnel between it and the remote infrastructure; v) means, such as NAT and packet routing software executable on the local computer, for directing scan packet data, produced by the scan server and received through the VPN, to the target computer on the local network; wherein the means in (v) is adapted to change the apparent source of the scan packet data coming from the scan engine to that of the local computer, and to change the apparent destination of responses from the target computer from that of the local computer to that of the scan server.

It will be appreciated that the method and system described herein is highly scalable, and some embodiments of the invention will allow many tens, hundreds, thousands, or even more, local networks to connect to a remote infrastructure in the manner described herein. Thus, such embodiments allow simultaneous (or multiplexed) connection between a scan engine and a local network, with the VPN connection configured as described herein providing local network access

Advantageously, the remote infrastructure may be adapted to set up VPN tunnels to each of a plurality of local computers on separate local networks. Thus, a plurality of disparate local networks may be scanned simultaneously.

Advantageously, the remote infrastructure may be arranged to detect instances where a plurality of separate networks each have a target computer having identical internal IP addresses, and to implement a queue to present each target computer sharing an address with another of a different network to the scan server at different times.

According to a third aspect of the present invention there is provided a computer having a processor, memory, and network communication functionality, wherein the computer further comprises software adapted to communicate with a remote infrastructure across the internet, and to set up a VPN tunnel therewith, and to communicate with target computers on its own local network, and further comprising software for receiving packets of data from the remote infrastructure, and for modifying the packets to change the apparent source of the scan packet data coming from the scan server to that of the local computer, and to change the apparent destination of responses from the target computer from that of the local computer to that of the scan server, so as to implement the process steps carried out by the entity as described in claim 1 .

Advantageously, the computer further comprises a webserver allowing scanning parameters to be displayed and amended by a client computer operating on the local network.

Some businesses may have large networks, having hundreds or thousands of computers connected thereto. Such networks are commonly divided into sub-networks, which may be located all within a common overarching internal network, or may be split into two or more separate networks that connect over a WAN such as the internet. The present invention has utility in such networks. Preferably, each sub-network may incorporate its own entity, each arranged to provide a connection to a remote infrastructure as described herein.

Note that the term "remote infrastructure" as used herein includes any servers, such as scan servers, VPN servers etc. that may be used at the remote infrastructure end of the connection between it and the entity. It will be appreciated that the remote infrastructure may therefore comprise of at least one, more preferably a plurality of servers that are working together to provide the functionality as described herein.

Brief Description of the Drawings

Embodiments of the invention are further described hereinafter, by way of example only, with reference to the accompanying drawings, in which:

Figure 1 shows a simplified topology diagram of a first embodiment of the invention, with a remote infrastructure being connected to a local network though the internet;

Figure 2 shows a block diagram of a process according to an embodiment of the invention;

Figure 3 shows a simplified topology diagram of an embodiment of the invention, following setup of the VPN connection to multiple clients on multiple local networks; and

Figure 4 shows a simplified block diagram of the main functional elements present in one embodiment of an Entity as may be used in embodiments of the invention. Detailed Description

Figure 1 shows an arrangement of computers that exemplify a hardware arrangement of a first embodiment of the invention. A remote infrastructure 1 is connected to a firewall 2 (which may be a physical firewall, or a virtual firewall running on the infrastructure 1), which then connects to the internet 3. A first local network 4 operated by a client also connects to the internet. The local network comprises of a router device 5, to which is connected a number of different computers 6, 8 or other network devices (such as printers and smart phones etc.), which the client uses for their ordinary business. Also connected to the router 5 is an entity 7, provided to the client by the operator of the remote

infrastructure, which comprises of a small computer, and a network interface. The computer comprises of a processor and memory, including non-volatile storage, A version of the Linux operating system is arranged to run on the computer. The computer is configured to present a web (i.e. HTTPS) interface when demanded, and is also arranged to carry out additional communication functions as will be described. The computer is, in this embodiment, a Beaglebone computer, supplied by BeagleBoard.org Foundation, 4467 Ascot Ct, Oakland Twp, Ml 48306, USA, although it will be appreciated that the invention is not restricted to the use of this computer, and that other computers can be used (including general purpose computers).

Each device on the local network 4 has its own internal (to the network) IP address, e.g. as assigned by a DHCP server running on router 5.

A second local network 10, operated by a second client, also connects to the internet. The second network again comprises of various devices connected to a router 11 , such as a computers 12, 14 and a second entity box 13, provided to the second client. The devices on the second network may again have local IP addresses assigned to them by a local DHCP server. It is commonplace for these devices to have IP addresses selected from a limited range, such as 192.168.0.1 to 192.168.0.255. Thus, it is likely that devices on each of the first and second local networks will share an IP address. It can be seen for example, that device 6 on the first local network 4 has the same IP address as the device 12 on the second local network. This is not a problem, as each network is independent of the other.

As is explained, some embodiments of the invention allow the remote infrastructure (including its associated (virtual or physical) scan servers) to address individual devices, such as device 6 and device 12, on different networks simultaneously, even though they share identical IP addresses, by means of having a separate VPN connection, along with appropriate separation of conflicting scans onto separate scan servers if available, or queueing where not. It will be understood that the or each VPN server is able to set up multiple VPN connections, each of which may connect, in general, to different networks. Where a plurality of VPN connections are required, it is advantageous to administer these with more than one VPN server, to allow for load balancing between different VPN servers, and to help reduce or overcome IP conflicts.

A single scan server can connect, via multiple VPN connections, to multiple local networks, and scan multiple target devices on the local networks. Should there be an IP address clash, e.g. where devices on the multiple networks share an IP address, then the scan server may implement a queuing system to handle the clash, and may scan one of the targets having the clashing IP address at a time.

The entities 7 and 13 on respective first and second local networks are arranged to have access to their local networks, and so to communicate with other devices connected to the networks. It should be noted that details of the local networks, other than the presence of the entities 7 and 13 connected to respective routers in their local networks, do not form a part of the invention.

The entities 7 and 13 are also arranged to have access to the internet, using port 443, which is conventionally used for HTTPS traffic. The entities 7, 13 are programmed with the IP address of the remote infrastructure 1 , and hence are able to initiate a connection to the remote infrastructure 1.

Figure 2 shows a top level chart of the interconnection process between an Entity on a client local network and a remote infrastructure. It is assumed that an Entity on a local network has been set up, and is in communication with the internet (and hence a remote infrastructure 1), and has been updated with schedule information indicating when it is due to initiate a scan on devices in its local network.

Firstly, at box 20, the Entity declares to the remote infrastructure that it wishes to initiate a scan on its network. The request for a scan may be controlled by the user, based upon a scan schedule, which may also contain information on which computers or other devices on the local network should be scanned, what aspects of the computers should be scanned, and any other information pertaining to the requested scan. The scan schedule is held in the client's account on the remote infrastructure, which can be accessed by the entity, or by other entities on the same client's local network To do this it sends an appropriate command via port 443 (HTTPS) to the remote infrastructure's WAN IP address. This is the IP address that is available for use by (appropriately authenticated) devices connected to the internet.

In response, at box 21 , the remote infrastructure assigns a VPN server, which begins setting up a VPN connection between it and the Entity, and sends VPN connection details to the Entity, through the Entity's WAN IP address (via the router on the local network). The Entity uses this information to establish its end of the VPN connection. Note that IP addresses within the VPN, between the VPN server and the Entity, are arranged to use reserved IP addresses that are not likely to be used by other devices, either on the remote infrastructure end of the connection, or by devices on the local network. This avoids any potential for IP address confliction.

Thus, as indicated at box 22, a connection has now been established between the VPN server running on the remote infrastructure and the Entity on the local network.

Now, at the remote infrastructure end of the connection, a scan engine, which may be sitting on its own scan server, is assigned, as indicated at box 23, to the entity for the purpose of providing the security scan. Data packets from the scan server are routed, using information contained in a router table, to the assigned VPN server, which, using its router table, routes it to the appropriate VPN connection tunnel associated with the client's network. OpenVPN, running on the VPN server, encrypts and sends the packet through the tunnel, where NAT at the firewall of the VPN server rewrites the packet to use port 443 As indicated at box 24, on receipt of packets at the Entity, the packets are routed to the VPN interface on the Entity, where OpenVPN decrypts the packet. The Entity implements NAT to change the source address of the packets to its own internal (to the local network) IP address, and forwards the packets to the target computer(s) on the local network, via a router on the local network. The packet is then received by the target computer as if it originated from the Entity.

Any response from the target is sent back to the packet's source address, which is now the Entity. On receiving the response, which will of course at that point have its own source address set to the local address of the target computer, and a destination set to the local address of the Entity, the Entity changes the destination address to the scan server's address using NAT, before routing the packet, using OpenVPN to encrypt the packet. The entity's routing table, which is set up as part of the establishment of the VPN, will then specify that the packet is to be sent through the VPN connection to the remote VPN server. The packet then goes through a NAT at the VPN firewall to change its destination port from that given to it by the Entity (i.e. 443) to the port corresponding to the tunnel associated with the client's external router IP address before being routed. The packet is then routed to the VPN interface, where OpenVPN decrypts the packet, and it is routed to the scan server.

In this way, a scan engine on the scan server is able to scan, as indicated at box 25, the target computer(s) located on the local network, and to appear to the target computers, due to the routing and NAT processes implemented on the Entity, as if it is itself present on the local network.

The remote infrastructure is able to carry out this process for multiple entities on multiple local networks. Thus, it may establish, for each one, a separate VPN tunnel. Each tunnel allows the remote infrastructure to communicate with the tunnel's respective entity, even if the entities have identical internal (to the local network) IP addresses. If necessary, the remote infrastructure may queue identical IP addresses on different local networks that it may be scanning so that it does not attempt to scan the identical IP addresses

simultaneously. The queuing process itself is a shared process, carried out by the various components of the infrastructure. The remote infrastructure creates a database, shared between various elements at the remote end, involved in the scan process.

To better understand this, first it needs to be understood that, to implement a scan, a completed route from the scan server to the entity via the VPN server is required, and the route relies on the presence of a VPN connection between the VPN server and the entity. The scan server will ignore any pending scan until the VPN server indicates that such a connection exists. Each component will wait on the component it depends on before establishing its own part in the system. When a route is established, it may block the establishment of a second route using the same target IP address, in which case the establishment of this route, and any subsequent such route, is kept pending.

In practice, Every few seconds, both the scan server and the VPN server go through their list of routes pending set up (which are kept in order of the scans being requested to guarantee that every scan will get done eventually) and set up any routes that do not conflict with any already in existence. Each server notes that it has established its part of the route in the shared database keeping track of the state of each scan, and, when both parts are set up, the scan server will stop ignoring the scan and launch the various scanning processes against the target. Once the connection is in place, the VPN server and the scan server can set up their routing tables. Again, the scan itself is ignored by the scan server until both its own routing table and that of the VPN server have been set up. Before adding entries to the route tables, both servers check to see whether the new route would conflict with any currently in existence. If such a conflict exists, than again both simply ignore that scan for the time being.

Note that it is clashes in the IP addresses of target computers on different client computers that need to be resolved by the queuing process, which means that all blocked routes to these IP addresses can be kept in a simple queue in both the VPN server and the scan server and simply establish each route in turn as its target IP is unblocked. There is thus no central coordination of this, other than the presence of the shared database; The shared database is used by the various components to indicate to other components what their status is.

Following a scan, the scan engine on the scan server is arranged to store the scan results in a database that is accessible by the client, through an appropriate secure login process onto the remote infrastructure. This access is separate from that of the scanning process.

Figure 3 shows a topology diagram following establishment of the VPN connection process broadly as may be made in the connection process described with respect to Figure 2, but with a tunnel connection being made to multiple client local networks, and with two scan servers 35, 36 being present at the remote infrastructure. The topology will be described, along with an example of the connection process, used to connect to the multiple networks, during a typical scan.

Remote infrastructure 30 is connected, via the internet 31 to local networks C1 , C2 and C3. VPN connections are assumed to have been established as described below, between the remote infrastructure 30 and an Entity E in each local network. A VPN daemon within the remote infrastructure sets up and maintains the VPN tunnels, set up by VPN servers V1 and V2 at the remote infrastructure end.

The client networks C1 , C2, and C3, each contain three computers with local IP addresses 192.168.0.1 , 192.168.0.2, and 192.168.0.3 (henceforth referred to as A1 , A2, A3 for brevity), along with an Entity E. A specific machine may therefore be uniquely identified by the combination of its network and local IP, so might now be identified by C1 :A1 or C2:A3, for example. It will be appreciated that the invention is not limited to this topology, and that, in practice, there may be many more computers present on each network,

Assume, for the sake of the example, that there are two scan servers on this system, S1 and S2. Assume also that V1 is assigned, by a management program running on the remote infrastructure 30 to manage the VPN tunnel to C1 and C2 and that V2 is assigned to manage the tunnel to C3. (It will be appreciated that, in practice, VPN servers may be assigned taking into account the potential for IP conflicts, and may be assigned to client networks with an aim to reduce or minimise such conflicts).

Assume also that the Entities on each network C1 , C2 and C3 have previously contacted the remote infrastructure 30 to instigate scans of their respective networks, resulting in the above VPN tunnels having been established in a manner as described above. V1 responds by starting to route IP packets addressed to A1 into the C1 network and broadcasts to the system that the scan for C1 :A1 can begin. V1 notes that it cannot now set up a route to C2:A1 (as A1 is already routed to C1) and places that scan in its queue. Let's say that it ends up setting up routes for C1 :A1 , C1 :A2 and C2:A3 and queues C1 :A3, C2:A1 and C2:A2. Meanwhile V2 is able to set up routes for all three of its scans (C3:A1-3) as there are no address conflicts.

Now the scan servers can start running scans against target computers for which the VPN routing has been set up. A single scan server can simultaneously run any such scans that do not share a local IP address, and two scan servers need take no account of such conflicts between them. So S1 might run scans C1 :A1 , C3:A2 and C3:A3 and S2 might run C3:A1 , C1 :A2 and C2:A3, for example.

It will be understood that the above description relates to a particularly simple set of client networks, and in practice the client networks are likely to be much more complex. Thus, a scan request from a client may result in multiple scans against multiple separate targets within the client's network. Such scans may be, in practice, distributed across multiple scan servers, in an attempt to reduce conflicts and provide load balancing. Each server must establish a route for the scan traffic from itself to the VPN server connected to the client entity before a scan for that client can run, as is apparent from the description of the queueing process described above.

The scanning software running on each scan server may scan the target computers in any manner, according to its own operating principles, possibly with multiple processes scanning multiple ports simultaneously. On server S1 , for example, the scanning software might generate packets addressed to A1 on any number of ports. S1 will, in the example setup given above, route these packets to V1 , which will route them into the VPN tunnel to C1. The Entity E at the local network will receive the packets from the VPN and then forward them onto the local network (after processing the packets to change the apparent source to that of the Entity, as described above), from where they will reach the target computer. Responses from the target will follow the established route back to the scanning software running on S1.

Figure 4 shows a simplified block diagram of an Entity, as may be used in embodiments of the invention. The Entity, in this example, is a Beaglebone dedicated computer running a standard Linux operating system. This is a physically small computer with relative low power requirements, that is easily added to a client network. The Entity 40 has a graphical user interface and web server 41 that provides the main user interface to the device, for installation and setup purposes, and for adding or amending scan schedules. User interaction, from the client side (i.e. within the local network) is done using a web interface provided by the web server.

The Entity scan schedules may be set up by a client on the local network, wherein the client securely logs on to the Entity and provides details of particular security scans, including their timing, the type of scan desired and which target computers should be scanned. The Entity scan schedules may also be set up from the remote infrastructure. The Entity may initiate a communication link, typically over a regular HTTPS internet connection, with the remote infrastructure, and may download schedule information from the remote

infrastructure that has been previously set up.

The web server works in co-operation with the Entity Application Programming Interface Layer 42. Between them they control the operation of the Entity, including the

communication with the remote infrastructure, and setup of the VPN. The API layer 42 provides an abstraction of the external API that appears on the remote infrastructure, and forwards requests made using the GUI to the external API. This simplifies the code for the GUI on the Entity.

The API layer 42 is also arranged to periodically instigate a connection to the remote infrastructure API to determine whether the remote infrastructure wants the Entity to initiate a VPN connection, and hence a scan. A scan may be initiated for example should the entity see that one is required after inspecting a scan schedule on the remote infrastructure.

The API layer 42 is also responsible for controlling a VPN controller 43 to establish the client side of any VPN connections made to the remote infrastructure, and for controlling the route and iptables commands to manage routing and NAT respectively. Thus, it provides an encapsulated interface to the O/S and network control aspects. The API layer controls these network functions based upon settings provided by the remote infrastructure.

The VPN controller 43 in this embodiment is the open source program OpenVPN. The Entity also has a network interface 44 under the control of the API later, that, alongside the router tables 45 and NAT 46, control the transfer of data between the VPN tunnel established by OpenVPN and any target computers present on the local network. The network interface is also used to allow connection to the GUI from the local network.

It will be appreciated that other implementations and physical platforms may be used, that will have similar functionality. Implementation of the Entity on a dedicated computer is not required, but is preferred for reasons presented earlier. The Beaglebone provides a convenient, physically small, and low power system that is therefore convenient to deploy on client networks with little disruption. Other small computers, such as a Raspberry Pi will also be particularly convenient, providing they are able to connect to the local network, and hence also to the internet, and are able to implement the VPN, NAT and routing functions, and to provide a user interface in some form. The functions of the Entity may also be operated on a virtual operating system on an existing computer, or as a service on a non- virtualized operating system.

The functions described herein as provided by individual components could, where appropriate, be provided by a combination of components instead. Similarly, functions described as provided by a combination of components could, where appropriate, be provided by a single component.

Throughout the description and claims of this specification, the words "comprise" and "contain" and variations of them mean "including but not limited to", and they are not intended to (and do not) exclude other moieties, additives, components, integers or steps. Throughout the description and claims of this specification, the singular encompasses the plural unless the context otherwise requires. In particular, where the indefinite article is used, the specification is to be understood as contemplating plurality as well as singularity, unless the context requires otherwise.

Features, integers, characteristics, or groups described in conjunction with a particular aspect, embodiment or example of the invention are to be understood to be applicable to any other aspect, embodiment or example described herein unless incompatible therewith. All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and/or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and/or steps are mutually exclusive. The invention is not restricted to the details of any foregoing embodiments. The invention extends to any novel one, or any novel combination, of the features disclosed in this specification (including any accompanying claims, abstract and drawings), or to any novel one, or any novel combination, of the steps of any method or process so disclosed.

Claims

1. A method for facilitating a scan of a local network from a remote infrastructure, comprising the steps of: a) from one of: an entity within the local network, and the remote infrastructure, initiating a request for a scan to the other; b) establishing between the entity and the remote infrastructure a virtual private network (VPN) connection; c) through the VPN, using Network Address Translation (NAT) at the remote infrastructure to direct incoming traffic from the entity on local network to a scanning engine on the remote infrastructure; d) using the entity within the local network as a router, carrying out a scan of the local network through the VPN using the scanning engine on the remote infrastructure; wherein the entity is adapted to direct scan packet data, produced by the scan engine and received through the VPN, to one or more target computers on the local network using NAT to change the apparent source of the scan packet data coming from the scan engine to that of the entity, and to further use NAT to change the apparent destination of responses from the target computer from that of the entity to that of the scan engine.

2. A method as claimed in claim 1 wherein the NAT used at the Entity acts to simulate the appearance of the scan engine on the local network.

3. A method as claimed in claim 1 or claim 2 wherein the entity within the local network comprises a dedicated hardware unit that is connected inside the local network.

4. A method as claimed in any of claims 1 to 3 wherein the entity is arranged to carry out the initiating request in step a) and to establish a VPN in step c) using a port used by the network for secure web browsing.

5. A method as claimed in claim 4 wherein the port is chosen from port 443 and port 80.

6. A method as claimed in any of the above claims wherein the scan engine is located on a scan server, and the VPN connection is made from a VPN server, where both the scan server and VPN server comprise the remote infrastructure.

7. A method as claimed in any of the above claims wherein further simultaneous VPN connections between the remote infrastructure and additional local networks are established, with the output of each VPN connection being routed to one or more scan engines.

8 A method as claimed in claim 7 wherein a scanning engine is arranged to time- multiplex its scanning process between the plurality of VPN connections.

9. A method as claimed in claim 8 wherein, where a scanning engine is connected to multiple local networks, and there is a target computer on a first local network that shares an internal IP address with a target computer on a second local network, the remote infrastructure implements a queue to time-multiplex the scanning engine to the target computers.

10. A method as claimed in any of the above claims wherein the VPN connection creates a tunnel and wherein IP addresses used within the tunnel are chosen from a set of reserved addresses as defined by the Internet Engineering Task Force or the Internet Assignment Numbers Authority.

1 1. A method as claimed in any of the above claims wherein the entity is arranged to periodically connect to the remote network to check for scan schedule information.

12. A system for scanning one or more target computers on one or more local networks, the system comprising a remote infrastructure, and one or more local computers (Entities) running on respective local network(s), the remote infrastructure comprising: i) means, such as a Virtual Private Network, VPN, server, for establishing its end of a VPN tunnel between it and at least one of the local computers; ii) means, such as a scan server, that is adapted to run a scanning engine, that is connectable to the local computer via a VPN; iii) means, such as Network Address Translation (NAT) and packet routing software that is executable on the remote infrastructure for directing packet data between the local computer(s) and the scan server and the at least one local computer comprising: iv) means, such as a VPN server, for establishing its end of a VPN tunnel between it and the remote infrastructure; v) means, such as NAT and packet routing software executable on the local computer, for directing scan packet data, produced by the scan server and received through the VPN, to the target computer on the local network; wherein the means in (v) is adapted to change the apparent source of the scan packet data coming from the scan engine to that of the local computer, and to change the apparent destination of responses from the target computer from that of the local computer to that of the scan server.

13. A system as claimed in claim 12 wherein the remote infrastructure is adapted to set up VPN tunnels to each of a plurality of local computers on separate local networks.

14. A system as claimed in claim 13 wherein the NAT at the remote infrastructure and at the local computer are arranged to pass packet data through the VPN tunnel by

transforming the port address of all such data to that of a single port address during its passage through the tunnel.

15. A system as claimed in claim 14 wherein the single port is port 443.

16. A system as claimed in claim 13 to 15 wherein the remote infrastructure is arranged to detect instances where a plurality of separate networks each have a target computer having identical internal IP addresses, and to implement a queue to present each target computer sharing an address with another of a different network to the scan server at different times.

17. A computer having a processor, memory, and network communication

functionality, wherein the computer further comprises software adapted to communicate with a remote infrastructure across the internet, and to set up a VPN tunnel therewith, and to communicate with target computers on its own local network, and further comprising software for receiving packets of data from the remote infrastructure, and for modifying the packets to change the apparent source of the scan packet data coming from the scan server to that of the local computer, and to change the apparent destination of responses from the target computer from that of the local computer to that of the scan server, so as to implement the process steps carried out by the entity as described in claim 1.

18. A computer as claimed in claim 17 further comprising a webserver allowing scanning parameters to be displayed and amended by a client computer operating on the local network.