Patent Application
20070297400
The summary above, and the following detailed description will be better understood in view of the enclosed drawings which depict details of preferred embodiments. It should however be noted that the invention is not limited to the precise arrangement shown in the drawings and that the drawings are provided merely as examples.
For convenience, the following examples will assume a TCP/IP based protocol, but the skilled in the art will easily recognize that any communications protocol and protocol stacks may be utilized. Similarly, the following examples of embodiments, communication protocols, devices, and methods, software modules organization, and boundaries, and the like are provided only by way of non-limiting examples. Modifications thereof will be clear to the skilled in the art and fall within the scope of the invention and the appended claims.
The reader is now directed to the accompanied drawings which depict different aspects and preferred embodiments of the present invention. Referring now to
The port redirector can communicate with a control server 30 via control link 25. Communications between the server and the redirector are preferably implemented as a secured link such as SSL. The control link 25 preferably utilizes the internet 50 as its physical medium, but the SSL provides it with the required security. Alternatively, the control link may be any data capable link other than the Internet, such as a telephone link, a cellular link, a dedicated data circuit, and the like. Target host 40 generally represents in a schematic manner any target computer, network, or network node, such as, by non limiting example, a target intranet, a router, a database server, a storage server, and application server, and the like. Communication to target host 40 occurs via data link 35.
The port redirector is depicted in a simplified block diagram in
The stack module 200 monitors 350 all communications from the upper communication stack 15 layers to the lower communication stack layers, and vice versa. Upon receiving a communication request 300, the stack module 200 analyzes the destination and/or source address data, and transfers the address information to control module 230. Control module 230 searches the rule base for the address or a portion thereof. If the rule base has a rule for the address, (option Y of query 330) the stack module changes the packet address 340 and forwards the packet to the lower stack 345. If no rule for the address is found, step 340 is skipped and the data is forwarded to the lower stack unchanged. Having its main function achieved, the port redirector continues to monitor the incoming and outgoing network traffic 350. Optionally data may be collected from any desired module and logged 360 in logging module 270. Clearly, similar operation may be performed for traffic incoming to the computer with the difference being primarily that the data is transferred from the lower stack layers to the upper stack layers.
The web server authenticates the user using SSL manager 60, and generates a port redirector for the user 405. The generation of the port redirector may be as simple as utilizing a single redirector module for all users, or may be as elaborate of dynamically generating code according to data stored in profile repository 80. The port redirector, different portions of the redirector code, and/or rules for generating redirector code on the fly may be stored in redirector storage 65. The port redirector 20 code is then sent to the PC.
Once the redirector code has been downloaded, it is installed 410 in the communication stack. Preferably the redirector is installed between layers 2 and 3, but other locations within the stack may be implemented.
This installation process may occur only once, it may occur periodically as needed to update the port redirector, or it may occur whenever the user tries to establish secured communication within a system utilizing one or more aspects of the invention. The selection of the installation timing and method is a matter of technical choice.
Once the redirector is installed it is initialized. As part of the initialization process service module communicates 415 to control server 30 via control module 240 and control link 25, and requests a fresh copy of redirection rules. In step 420 control server 30 identifies the user using the SSL manager 60, or a similar secure protocol. Once the user is identified and authenticated, the server retrieves the translation rules from rule repository 75. The rules may be general rules or rules specific to a user.
The initialization stage is an excellent opportunity to configure the port redirector, check for upgrades, and the like. Rules, and optionally configuration parameters, are transmitted to the port redirector 425. If a complete or partial upgrade is required the service module 280 handles most of those tasks. Rules are loaded to the local rule base 430 and the port redirector is ready to monitor and redirect traffic. In the most preferred embodiment the steps of retrieving the rules occurs at least once for every session, and in some cases they also happen periodically to verify currency. In less desirable embodiment, the rules may be dynamically obtained from the server, but doing so may slow down response time. However such embodiment will offer an extremely secured communications.
Once installed and configured, the port redirector may begin operating substantially as described regarding
Similarly, for brevity most of these specifications and claims were constructed to read on a target address being the key criteria to a packet matching the rules. However the skilled in the art will recognize that the selection of the rule as a matching rule may occur based varied criteria. By way of non limiting example, the rule criteria may comprise of the source address of the packet, a protocol type, a range of addresses, transmission time, state of the software initiating the communications, state of the port redirector or any component thereof, state of the packet target, state of the remote server, and the like. and the specifications and the claims should be construed to extend to such an embodiment.
It is important to note that the rule may be directed to an address, and address range, to a specific port or port ranges within the address:port combination, or to specific ports at any host. Doing so allows for example capturing and redirecting certain services to a safe controlled environment.
Once the rule is found the redirector modifies the address, and/or takes any other desired action on the packet as instructed by the rule. An example of simple rules 700 is shown in
Thus in the example once a match is found between the target address 22.33.44.55:26 and the rule, the packet will be redirected to 127.0.0.1:25677. The packet is transferred to the lower stack 620 which forwards it to the redirected destination. Redirected destination may not be aware that the package was redirected. However the redirected destination sends a response 630, which is received 635 by the lower IP stack. The lower IP stack transfers the packet to the redirector and again if a relevant rule is found 640 changes are affected according to the destination port, or the source address. After the changes are affected 645 the response packet is transferred to the application 660.
In certain preferred embodiments both the destination and the source addresses are being analyzed. Doing so allows controlling application behavior, such as limiting access to specific ports or destinations by specific applications, users, and the like.
During communications the port redirector continually monitors for a trigger event 830. A trigger event may occur due to many reasons, that are a matter of technical choice. Examples of trigger events include but are not limited to reaching a certain communication volume such as number of bytes sent and/or received, a preset time has elapsed, a code arrives in the communications content, a manual user intervention, or, in the most preferred embodiment, the reception of a command from the control server, for example generated by the alternate services module 70, that is transmitted via control link 25. In response to such trigger event the port redirector utilizes the ‘next port’ field 750 to redirect the future communication to. Thus in the example illustrated, communications directed to 22.33.44.55:25 are initially directed to 22.52.1.17:200. Once a trigger event occurs 830 the redirector utilizes the ‘next rule’ field 750 to select a new redirection rule. This can be carried out by changing the rule in the rule base, by doing multiple redirections, by a rules index, and other common programming methods that will be clear to the skilled in the art. Thus after the rule assignment switch 840 the next traffic to the 22.33.44.55:25 packet will be directed to 22.52.1.17:500. It is noted that by using a ‘next port’ number in the pointer field will result in equivalent behavior to ‘next rule’ and thus such example embodiment is considered to be covered by the ‘next rule’ example.
Such port hoping or even address hoping provides an extremely useful method for secure communications, as the monitoring of all ports is of limited use, especially in real time, and the sending application is completely unaware of the address:port assignment changes and thus requires no change.
In the most preferred embodiment, the trigger event is generated by the alternate services module 70 of the control server, which dictates not only the timing of the redirection switch but also the address:port for the next packet redirection. The skilled in the art will recognize that while this system is not shown in the drawing it is very easily understood, and thus a drawing will not add to the understanding of the invention. The simplest example of such embodiment is simply when the control server 30 sends a command to the port redirector 20 to redirect all future packets that the application sends to one address to another address:port combination. Most preferably, such command is sent by the secured control link 25. Also preferably, the control server notifies both the sender redirector and the receiver redirector.
The invention may clearly facilitate secured communications using any desired protocol or protocol group such as TCP, UDP, and the like. It is further important to note that different aspects or portions of the invention may be embodied in hardware form, software form, or a combination thereof. By way of example the invention may easily be implemented within a communication hardware that deals with the protocol stack using specialized hardware, and the like. Thus the invention extends to any computing device or system using the methods of communication redirection and/or other aspects of the invention.
It will be appreciated that the invention is not limited to what has been described hereinabove merely by way of example. While there have been described what are at present considered to be the preferred embodiments of this invention, it will be obvious to those skilled in the art that various other embodiments, changes, and modifications may be made therein without departing from the spirit or scope of this invention and that it is, therefore, aimed to cover all such changes and modifications as fall within the true spirit and scope of the invention, for which letters patent is applied.
