Automatic Firewall Configuration

Abstract

One embodiment of a gateway router is equipped to recognize a trustworthy local server automatically, and to accept certain incoming connections to a local server that the router has recognized as trustworthy.

Description

BACKGROUND

When a small Local Area Network (LAN), such as a domestic network in a private residence, is linked to a larger network such as the internet, the link is often through a gateway router acting as a firewall. One of the functions of the firewall is to protect the LAN from intrusion from outside. In order to fulfill this function, firewall routers, especially firewall routers that are likely to be used by relatively technically unsophisticated users, tend to be preconfigured by their manufacturers to be very unwelcoming to unexpected communications from outside. Typically, the firewall is configured not to allow any internet connection that is initiated from the outside.

Gateway routers are available that can be configured using the “Universal Plug and Play” (UPnP) protocol by a server (or other device on the protected side of the gateway) to forward incoming connections. However, most router manufacturers turn that function off by default, for security reasons. The user could enable that function by configuring the router manually, or could configure the router manually to allow a connection on a specific port to a specific router on the protected side of the gateway, but such configuration requires a degree of sophistication in the operation of computer networks.

However, some users do wish to allow at least limited access to their LANs from outside, for example, to a server. Many users who wish to permit an incoming connection to a home server or other server on a small LAN do not have, and do not wish to have to acquire, the technical skill and knowledge to configure a router manually.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory and are intended to provide further explanation of the invention as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are included to provide a further understanding of the invention and are incorporated in and constitute a part of this specification, illustrate embodiments of the invention and together with the description serve to explain aspects of the invention.

In the drawings:

FIG. 1 is a diagram of an embodiment of a computer network.

FIG. 2 is a flowchart of an embodiment of the invention.

FIG. 3 is a diagram of another embodiment of a computer network.

FIG. 4 is a flowchart of another embodiment of the invention.

DETAILED DESCRIPTION

Reference will now be made in detail to various embodiments of the present invention, examples of which are illustrated in the accompanying drawings.

Referring to the accompanying drawings, and initially to FIG. 1, one embodiment of a computer network, indicated generally by the reference numeral 10, is a Local Area Network (LAN) such as may be installed in a small business or private residence.

The LAN 10 comprises a gateway router 12, connected on a “local” or “protected” side of the router to a server 14, and on an “outside” to an external Wide Area Network (WAN) 16 such as the Internet, and through the WAN to external devices 18. The server 14 may be a Personal Computer (PC) or may be a dedicated server. The server 14 may be a “home server,” which is typically a dedicated server without a console that acts largely as a repository of files for other devices such as PCs (not shown) that may be present on the LAN 10. The term “computer” as used herein includes personal computers, servers, and home servers.

In the embodiment shown in FIG. 1, the gateway router 12 may be configured to permit outgoing connections to external devices 18 from various devices on the LAN 10, but configured to permit incoming connections only to the server 14.

Referring now also to FIG. 2, in one embodiment the gateway router 12 is programmed to configure itself automatically.

In step 102, the router 12 recognizes that the server 14 is present on the LAN 10, and is a trustworthy server.

In step 104, the router 12 configures itself to accept at least some incoming connection requests from the WAN 16 for the server 14, and to reject incoming connection requests from the WAN 16 that are not for the server 14.

In step 106, the router 12 and the server 14 operate together with any other devices (not shown) that happen to be active on the LAN 10. The router 12 forwards eligible incoming connections from the WAN 16 to the server 14, blocks or discards other incoming connections from the WAN 16, but may forward outgoing connections from the server 14, from other devices on the LAN 10, or both.

Referring to FIG. 3, a second embodiment of a computer network, indicated generally by the reference numeral 210, is a Local Area Network (LAN) such as may be installed in a small business or private residence.

The LAN 210 comprises a gateway router 212, connected to various devices on the LAN on a “local” or “protected” side, and to external devices 18 on an external network such as the Internet 16 on an “outside.” The devices on the LAN 210 comprise at least one server 214 and some Personal Computers (PCs) 220, connected to each other and to the gateway router 212 by a switch 218, hub, or the like.

The server 214 may also be a PC, or may be a dedicated server. The server 214 may be a “home server,” which is typically a dedicated server without a console that acts largely as a repository of files for the other PCs 220 on the LAN 210. Such a home server 214 is useful if the PCs 220 include portable computers that may not always be connected to the network. Then, files stored on the home server 214 can be constantly available to devices on the LAN 210, where files stored on a PC 220 would be available only when that specific PC was connected to the network and switched on.

The gateway router 212 and the switch 218 may be a single device, or separate devices designed to operate together, with one physical external port 222 and a plurality of physical local ports 224, 226. The physical local ports 226 may include a dedicated physical port 226 for linking to the server 214.

The gateway router 212 and the server 214 may be in a single housing 230, with the server linked to the router by the manufacturer. In that case, the gateway router 212 may be preconfigured by the manufacturer to recognize only the server 214 in the same housing as a trustworthy server, for example, because the server is connected to the dedicated physical port 226 or because the gateway router is provided with a list of trustworthy servers containing only a unique identifier for that specific server.

Referring now to FIG. 4, in one embodiment of a process for configuring a gateway router such as the router 212 shown in FIG. 3, in step 302 the LAN 210 is physically constructed and connected. In step 304, the router 212 and the server 214, together with the switch 218 are started up. Once the router 212, the server 214, and the switch 218 are running, communication is established between them in an appropriate manner, which may include manners already known in the art.

In step 306 the gateway router 212, as a late stage in its startup routine, “discovers” the other devices on the LAN 210, including any server 214. In an embodiment, the gateway router 212 sends out a broadcast message announcing itself as a router newly added to the network, to which other devices respond. The broadcast may be, for example, a uPnP broadcast including a device-type identifier. Where a suitable device-type identifier is available, the broadcast message may specifically identify the router 212 as a router with access configurable by a home server. If such a specific device type is not available, a more generic device-type identifier may be used.

In step 308, the server 214 identifies itself. Where a suitable device-type identifier is available, the response by the server 214 may specifically identify the server 214 as a home server with a need to establish external access. If such a specific device type is not available, a more generic device-type identifier may be used. As shown by the loop in FIG. 4, if the initial broadcast and response do not provide sufficient information about the server 214, the router may interrogate one or more possible servers repeatedly until sufficient information is available. At the first iteration of step 308, the server 214 may merely provide a uPnP server device type. It is proposed to extend the available uPnP device types to allow more specific identification of, for example, a “home server” type and a “configurable router” type. Alternatively, the router could be defined as an extension or subclass of the existing “Internet Gateway Device” type, which includes some configurable implementations.

Alternatively, if the server 214 is started up after the router 212, the server may, as a late stage in its startup procedure, broadcast an announcement that it is a server, to which the router 212 reacts.

Where the router 212 knows that a dedicated physical server port 226 is in use, the router may broadcast to and interrogate only devices accessible through the dedicated physical server port.

Steps 306 and 308 may take place in a single transaction, or may take place over two or more distinct transactions. For example, communication between the server 214 and the gateway router 212 may be established at one time, as a result of the server being provided with the routers network address by DHCP, static server configuration, or another suitable process. At a later time, the server 214 may interrogate the gateway router 212 to establish whether the router is configurable by the server.

In step 310, the router 212 determines that the server 214 is a trustworthy server by comparing the information obtained in steps 306 and 308 with a list 234 of approved trustworthy servers stored on a computer readable storage medium in the router 212. The list 234 may consist of device type identifiers for devices that may serve as home servers, to a desired degree of specificity. The list 234 may consist of unique identifiers, which may be in the form of ranges of unique identifiers, for devices that may serve as home servers. By limiting the types of devices that can be recognized as servers in subsequent steps, this embodiment blocks or restricts some vulnerabilities caused by malware on other types of device that may attempt to masquerade as a server. For example, even on a new LAN 210, some of the PCs 220 may not be new, and may previously have been exposed to infiltration by malware.

The type identifiers may include server hardware identifiers, server software identifiers, or both. Where the router 212 and the server 214 are pre-assembled in a single housing 230, the list 234 may consist solely of the type identifier, or even an individual device identifier, of the server 214 actually present.

In an embodiment, the router 212 may request additional confirmation of the identity of the server 214. For example, the list 234 may include public keys for encryption programs on approved servers 214, and the router 212 may then verify the authenticity of the server by the servers ability to decrypt a message encrypted using the appropriate public key.

In a alternative embodiment, the router 212 requests a user to confirm to the router that a trustworthy server 214 is present. Devices such as the router 212 usually do not have a full user interface. However, the router 212 may have various indicator lights 232 and a few pushbuttons or other controls 236, allowing limited communication with a user who has an instruction sheet explaining the significance of distinctive signals, such a patterns of flashing lights. Thus, the router 212 can ask a user to confirm or deny the presence of a trustworthy server 214 by pressing a specified button 236 in response to a specified light signal 232. If the physical ports on a combined router 212 and switch 218 have individual indicator lights 232, the router 212 can even ask the user which port the server 214 is attached to.

Alternatively, where the router 212 and the server 214 are pre-assembled in a single housing 230, step 310 may be omitted on the assumption that the server 214 actually present in the housing 230 is the server intended to be present, and steps 306 and 308 may then be a mere handshake.

If no trustworthy router 214 is identified, the process terminates.

In step 312, the gateway router 212 configures its gateway to forward incoming connection requests on specified logical ports to the trustworthy router 214, and to deny incoming connection requests on other ports. The allowed logical ports may be standard IP ports preconfigured in the router 212, or may be specified in the list 234 for a particular server type, or the router 212 may accept requests from a recognized trustworthy server 214 to open ports specified by the server, either from a choice specified in the list 234 or without restriction.

In a preferred embodiment, the router 212 does not accept any request from a device other than the recognized trustworthy server 214 to open ports for incoming connections, and does not accept requests from the recognized trustworthy server to open ports inconsistent with the choice specified in the list 234 or other restrictions preconfigured into the router 212.

In a preferred embodiment, the router 212 accepts requests from the server 214 to open logical ports only as part of the initial configuration of the LAN 210. At that time, it is assumed that the configuration of the LAN 210 is likely to be clean, and that malware has probably not yet had an opportunity to become established on the server 214. A request for a new logical port at a later time, especially an unusual logical port, is more likely to be part of an attempt by malware that has got onto the server 214 to open up the LAN to attack, and is not accepted.

In case more than one trustworthy server 214 is present on the LAN 210, the server 214 may as part of step 312 obtain the existing configuration status of a desired logical port of the router 212 using a standard GetSpecificPortMappingEntry( ) or similar command. If the desired port is already configured to connect to another server 214, the requesting server may work down a list of suitable ports unless and until it finds an available port. Alternatively, if two or more servers 214 are present on the LAN 210, they may discover each, and may negotiate to ensure they do not attempt to configure the same logical port.

In step 314, the router 212 routes connections. The router 212 routes incoming connections from external devices 18 on the open logical ports to the server 214, and denies all other incoming connections. The router 212 may permit outgoing connections both from the server 214 and from the PCs 220.

Various modifications and variations can be made in the present invention without departing from the spirit or scope of the invention. Thus, it is intended that the present invention cover the modifications and variations of this invention provided they come within the scope of the appended claims and their equivalents.

For example, in FIG. 3, one server 214 and a few PCs 220 are shown connected to the switch 218 and then to the router 212. The specific configuration of the LAN 210 may vary from installation to installation and, as mentioned above, may vary from time to time if, for example, some of the PCs 220 are portable devices that are only intermittently connected to the LAN.

For example, depending on exactly how the subsequent configuration is managed, the router 212 and the server 214 may be started up in a specific order in step 304. For example, if the configuration process relies on one device sending out or receiving certain signals as part of its startup routine, that device may be started up only after another device that is to respond to or broadcast those signals.

The exact procedure in steps 306 and 308 depends on the specific identification protocols available on the LAN 210. For example, the broadcast signal in step 306 may be able to request responses from only servers, or may request responses from all devices on the LAN, or something in between. The responses may sufficiently identify the responding devices sufficiently for step 308, or the router 212 may extract a shortlist of potential servers that are then interrogated individually for more detailed identification information.

Claims

1. A gateway router comprising a computer-readable storage medium preconfigured with one or more criteria to determine whether local computers are trustworthy, wherein said router accepts one or more types of incoming outside connections for local computers that meet said criteria.

2. The router of claim 1, wherein said criteria comprise a list of unique identifiers associated with trustworthy computers.

3. The router of claim 1, wherein said criteria comprise connection of said local computer at a specific local port of said router.

4. The router of claim 1, wherein said criteria comprise successful decryption by said local computer of an encrypted message.

5. The router of claim 1, wherein said criteria comprise user confirmation of the presence of a trusted local computer.

6. The router of claim 1, further comprising a local port dedicated to connection of a trusted local server.

7. The router of claim 1, further comprising a control operable by a user to confirm the presence of a trusted local computer.

8. The router of claim 1, wherein said router rejects incoming outside connections for local computers that fail to meet said criteria.

9. The router of claim 1, wherein said router rejects incoming outside connections other than said one or more types of incoming outside connections.

10. A computer system comprising a server and a gateway router, wherein said server and said router are integrated in a single housing, wherein said server is connected to a port of said router, and wherein said router is configured to permit one or more types of incoming connections only to said server.

11. A method for a gateway router to automatically configure outside access to a trustworthy local computer, comprising the steps of: comparing information supplied by a local computer to one or more criteria for identifying trustworthy computers stored in said router, and configuring said router to permit incoming outside connections to local computers that meet selected criteria.

12. The method of claim 11, wherein said configuration to permit incoming outside connection is performed only upon initial configuration of said router.

13. The method of claim 11, further comprising the step of interrogating local computers that are connected to said router for communication of said information.

14. The method of claim 11, further comprising the step of monitoring a network link on a local side of said router for said information submitted by a local computer.

15. The method of claim 11, further comprising the step of configuring acceptance of one or more types of incoming connections in response to commands from a local computer said router has identified as trustworthy.

16. The method of claim 15, wherein commands that call for opening ports inconsistent with restrictions preconfigured into the router are rejected.