Identifying additional firewall rules that may be needed

System, method and program product for managing a security policy of a firewall. The firewall receives a message packet addressed to a specified port of a destination IP address and determines that the firewall does not have a message flow rule which permits passing of the message packet to the port. The port is tested to determine if the port is open. If so, an administrator is queried whether the firewall should have a message flow rule which permits passing of the message packet to the port. If not, an administrator is not queried whether the firewall should have a message flow rule which permits passing of the message packet to the port. There may be first and second firewalls located between the source IP address and destination IP address. Before the port is tested, a central database is checked to learn if the central database has a record of whether the first firewall should have a message flow rule which permits passing of the message packet to the port. If not, and the port is found to be open, the central database is updated to indicate that both the first and second firewalls should have a message flow rule which permits passing of the message packet to the port. Also, the security policy of the first firewall is updated with a message flow rule which permits passing of the message packet to the port. The second firewall is not updated until it encounters a message packet addressed to the port.

BACKGROUND OF THE INVENTION

The invention relates generally to computer network firewalls, and more particularly to a system, method and program to identify additional rules which may be needed by a firewall to permit messages with different combinations of source IP address, destination IP address, destination port, protocol, etc. to flow through the firewall.

There are different types of networks today. For example, there may be an intranet for local communications within an enterprise. It is presumed that all users of the intranet are trustworthy because they all work for the same enterprise. Therefore, usually there is relatively little security concern within the intranet. However, oftentimes users of the intranet want to communicate with another entity located on another network outside of the intranet. Because this other entity may not work for the enterprise, and this other network is not under control of the enterprise, this other entity and network cannot be thoroughly trusted. Therefore, a firewall may be installed at the gateway to the intranet. The firewall is responsible for enforcing a security policy for incoming communications. This security policy may define which types of networks that the intranet is permitted to communicate, what ports of what destination devices within the firewall are permitted to receive communications from what source devices and what protocols are permitted for the communications. The source and destination devices are identified by respective IP address. Each combination of source and destination IP address/protocol and port is called a “flow”, and the “rules” within the firewall specify what flows are permitted to pass through the firewall.

Typically, the rules specify combinations of source IP address, destination IP address, port, protocol, etc. of messages which are permitted to pass through the firewall. If a message arrives, and its combination of source IP address, destination IP address, port, protocol, etc. does not match a rule, then the message will be discarded and not forwarded to the specified destination. There are many reasons for discarding such messages. For example, they may originate from an untrusted/unsecure network, and the security policy of the destination network may prohibit all such incoming messages. Also, the message may be addressed to a port or use a protocol which is not supported in the destination network.

The most common protocols are TCP, UDP and ICMP. Each of these protocols includes additional criteria such as the range of ports used by TCP and UDP for certain types of requests, and the types and codes of ICMP. The TCP and UDP ports indicate which application in the recipient device should provide the requested services. It is also desirable in some cases to limit the range of ports for certain types of communications. The limitation on the range of ports facilitates the handling of the requested service. For example, many programs are written to open any available TCP or UDP port. This makes the identification of the application using such a port difficult. In some such cases it is possible to restrict the range of ports available to these applications to assist in identifying which application is using the port. Some types of firewalls have the ability to understand some applications that commonly open random ports, such as FTP, TFTP, H.323 etc. It may be preferable for some networks to not communicate with another network which uses a different range of TCP or UDP ports. Also, some networks may not wish to accept certain types of ICMP messages. For example, some destination networks may not wish to process “route redirect” messages as the device sending the “route redirect” may not be trusted. Furthermore, some protocols are more controllable than others. For example, TCP provides “handshaking” for every communication whereas UDP does not. So, TCP is more controllable than UDP and therefore it may be preferable for some networks to not accept UDP communications.

Different techniques have been used to determine if two networks, connected through firewalls or routers are authorized to communicate with each other, and which protocols including additional criteria are authorized for the communication. For example, if a systems administrator of an external network wants to communicate through its firewall or router to an enterprise behind the enterprise's firewall, the systems administrator of the external network can simply send its configuration information to a systems administrator for the enterprise. The configuration information may include the type of external network and the protocols it supports including the additional criteria for each protocol. Then, the systems administrator of the enterprise manually reviews the configuration information and determines if this external network should be permitted to communicate with the enterprise through the enterprise's firewall and if so, what IP protocol to use. If the system administrator believes the requested flow is acceptable according to the enterprise's policy, the systems administrator updates a rule file in the firewall of the enterprise to permit it to communicate with the external network with a specified IP protocol including additional criteria. Likewise, the systems administrator of the external network will update a rule file in its firewall or router to permit it to receive communications from the enterprise's network with a specified IP protocol including additional criteria.

Usually at least once a year, all the firewall rules are verified to ensure they still conform to the company policy. Traditionally this is completed manually by the systems administrator, or a person outside of the day-to-day operations of the firewall such as a security administrator. The systems administrator or security administrator reviews each firewall rule to confirm the network type of each IP address and ensures that the flows configured in the firewall are acceptable according to the company policy. While this technique is effective, it requires tedious, human review of the configuration information from each network with which communication is desired, and there can be many such networks. Also, it focusses on checking permissibility of specified communications, rather than determining all potential permitted communications. Also, routers and firewalls of networks are often changed, and this may require the foregoing interaction between the systems administrator or security administrator to be repeated.

There is another technique to determine if two networks, connected through firewalls or routers are authorized to communicate with each other, and which protocols (including additional criteria) are authorized for the communication. According to this technique, a packet generator is located inside the firewall or router of an originating network being checked for compatibility with other networks. The packet generator sends a set of communication packets onto the network, but preferably to an unoccupied IP address. The communication packets of each set have different IP protocols with different additional criteria, but ones that the originating network supports. A “sniffer” is located just outside the firewall or router of the originating network and logs the generated packets that are allowed to pass through the firewall or router of the originating network. Based on the presence or absence of the original packet being logged by the “sniffer” a report can be generated as to what traffic the firewall or router allows through. This report can then be compared with the corporate security standards. While this technique is partially automated, it burdens the networks with many communication packets to handle. Also, it does not consider the type of destination network as a criteria in determining whether the originating network should permit communication; this is still left as a manual task once the report has been manually generated. The other concern is that the corporate security standards often change.

It was also known that if a message packet does not reach its intended destination, the source computer that sent the message packet would learn of this, via some type of return code or the absence of a response altogether. Then, the user of the source computer would alert a firewall administrator for the network of the intended destination to investigate the problem. In response, the firewall administrator would investigate the reason that the message packet did not reach its intended destination. The firewall administrator would check if each firewall in the path from the source computer to the destination device included a rule that permitted the flow. If all the firewalls do not include the requisite rule, then the firewall administrator would add the rule if the firewall administrator knew it was valid, or ask the owner of the network of the destination device to determine if the rule should be added to the firewall, and if so, open a request to create and add the rule. If all the firewalls in the path have a rule that permits this flow, but the message packet did not reach its intended destination, then the firewall administrator would check communication linkages to determine whether a logical of physical network connection is configured or connected. If during the course of this path verification the message packet is recorded, usually by use of a sniffer, on the logical destination network, the firewall administrator would scan the destination system to determine if the intended destination port is open. The administrator scanned the destination port using a known tool which generates a test packet and sends it to the destination port. The tool then checks for a response indicating that the port is open. If the port is not open, the administrator would check the contract with or query the owner of the destination device to determine if the port should be open. If so, the administrator would open the port.

A general object of the present invention is to identify additional rules which may be needed by a firewall to permit messages with different combinations of source IP address, destination IP address, destination port, protocol, etc. to flow through the firewall.

A more specific object of the present invention is to provide a technique of the foregoing type which is at least partially automated.

SUMMARY OF THE INVENTION

The invention resides in a system, method and program product for managing a security policy of a firewall. The firewall receives a message packet addressed to a specified port of a destination IP address and determines that the firewall does not have a message flow rule which permits passing of the message packet to the port of the destination IP address. The port of the destination IP address is tested to determine if the port is open. If so, an administrator is queried whether the firewall should have a message flow rule which permits passing of the message packet to the port of the destination IP address. If not, an administrator is not queried whether the firewall should have a message flow rule which permits passing of the message packet to the port of the destination IP address.

In accordance with a feature of the present invention, the testing of the port of the destination IP address to determine if the port is open comprises sending a test message packet to the port and checking for an acknowledgment or other response indicating that the port is open. If the firewall is located between a sender of the test message packet and the destination IP address, then the firewall includes a message flow rule which permits message packets to flow from a source IP address of the sender of the test message packet to the destination IP address.

The invention also resides in a system, method and program product for managing a security policy of first and second firewalls located between a source IP address and a destination IP address. The first firewall receives a message packet addressed to a specified port of the destination IP address and determines that the first firewall does not have a message flow rule which permits passing of the message packet to the port of the destination IP address. The second firewall does not have a message flow rule which permits passing of the message packet to the port of the destination IP address. A central database is checked to learn that the central database does not have a record of whether the first firewall should have a message flow rule which permits passing of the message packet to the port of the destination IP address. In response, the port is tested to determine if the port is open. If the port is open, the central database is updated to indicate that both the first and second firewalls should have a message flow rule which permits passing of the message packet to the port of the destination IP address. Also, the security policy of the first firewall is updated with a message flow rule which permits passing of the message packet to the port of the destination IP address.

In accordance with a feature of the invention, upon receipt at the second firewall of a message packet addressed to the specified port of the destination IP address and a determination that the second firewall does not have a message flow rule which permits passing of the message packet to the port of the destination IP address, the central database is checked to learn that the second firewall should have a message flow rule which permits passing of the message packet to the port of the destination IP address. Also, the security policy of the second firewall is updated with a message flow rule which permits passing of the message packet to the port of the destination IP address.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The present invention will now be described in detail with reference to the figures, wherein like reference numbers indicate like elements.FIG. 1illustrates four networks10,20,30and40interconnected by a firewall50in a multi-network system9. There are a variety of computing devices on networks20,30and40, and their type is not important to the present invention. In the illustrated example, on network20is an application server21, on network40is an application server42, on network30is a computer such as a workstation31which initiates connectivity to either of the application servers21or42, and on network40is a computer such as a workstation41which initiates connectivity to either of the application servers21or42. Firewall50performs known functions of enforcing the rules within its security policy. The rules are maintained in a database51within or accessible to the firewall50. The rules specify what combinations of source IP address, destination IP address, port on the destination IP address, protocol, etc. are authorized. The firewall50permits such “authorized” messages to pass through the firewall to the intended destination device and port. Conversely, if a message arrives at the firewall and its source IP address, intended destination IP address, port on the destination IP address, protocol, etc. do not match one of the firewall's rules, then the firewall50will block and discard the message. All of the foregoing networks, workstations and application servers are prior art, as well as the foregoing function of firewall50.

FIG. 1also illustrates on network10a logging server11, a database12, a control server13and a scanning device14in accordance with one embodiment of the present invention. The logging server11logs source and destination address, protocol and disposition information about message packets which the firewall50has blocked. Database12stores message flow rules that should be represented in the security policy of the firewall. Scanning device14tests the destination port of each blocked message packet to determine if the port is open. Control server13(with the help of the scanning device14) investigates message packets which the firewall50has blocked to determine if the destination port is open such that the message packet may have been blocked erroneously. Control server13includes a CPU22, RAM24, ROM26and control program312. Control server13loaded control program312from a computer readable medium such as disk or tape28or network10via the Internet (not shown) and a network adapter card29. While the scanning device14, control server13, database12and logging server11are illustrated inFIG. 1as separate physical devices, they can be replaced by programs executing in a single server13and memory or storage devices resident on server13, and performing the same scanning function, database function and logging function. The operation of logging server11, control server13and scanning server14are described in more detail below.

FIG. 2illustrates an embodiment of the present invention where networks10,20and40are virtual local area networks (“VLANs”), and network30is a VLAN as well. In this embodiment, there is a VLAN capable multi-port switch80, as well as another multi-port switch70which may or may not be VLAN capable. Such switches are currently available, for example, Cisco™ layer 2/3 switch, Nortel™ layer 2/3 switch or 3Com™ layer 2/3 switch. Each VLAN is formed in part by connectivity within the switch80between specific ports. In the illustrated example, VLAN10is formed in part by connectivity within switch80to and between port81(for logging server11), port82(for database12), port83(for control server13) and port84(for scanning server14). VLAN20is formed in part by connectivity within switch80to port91(for application server21). VLAN40is formed in part by connectivity within switch80to and between port101(for workstation41) and port102(for application server42). If network30is a VLAN as illustrated inFIG. 2, then network30is formed in part by connectivity within the switch70between specific ports. However, if switch70is not capable of creating VLANs, network30is formed by all the connections on switch70. In the illustrated example, scanning server14also has an additional virtual connection to port85of switch80. This port can be connected to any of the VLANs10,20and40as needed to permit communication with, i.e. scanning of, a device port on the VLAN or on another network which is connected to the VLAN. There is internal connectivity available between ports81-84,91and101-102within switch80to permit messages to pass between the VLANs10,20and40when the message complies with a rule within the security policy of the firewall50. Alternately, network30is a real network (with physical cabling and routers), and is physically connected to firewall50. In the illustrated example, firewall50connects to ports110,120and140of switch80, and ports110,120and140are connected within the switch80to networks10,20and40, respectively. The firewall reviews requests to send messages between devices on different VLANs10,20and40, and between VLANs10,20and40and external network30, and determines whether the firewall security policy has a rule which permits each message flow. The decision of firewall50whether to pass the message packet is then conveyed to the switch80, which controls the destination network accordingly.

It should be noted that whileFIG. 2illustrates a VLAN embodiment of networks10,20and40, the present invention is also applicable to discrete forms of networks10,20and40, each comprising physical cabling and routers, and a discrete firewall comprising software executing on a physical computing device interposed between networks10,20,30and40.

FIG. 3illustrates processing, in accordance with the present invention within system9, of message packets originating from workstation31on network30intended for application server21on network20. (Similar processing would occur if the message packets originating from workstation31were destined for application server42, or if the message packets originated from workstation41and were destined for application server21. The processing illustrated inFIG. 3applies regardless of whether networks10,20,30and40are virtual or real.) In step300, workstation31sends onto network30a message addressed to application server21. In accordance with known TCP/IP protocols such as TCP, UDP, ICMP, etc. and applications such as TELNET, HTTP, SSH, SSL, etc., the workstation's message is divided into packets. In one embodiment of the present invention, each packet comprises a header and a body. The header contains the destination IP address, port of the destination address, source IP address, port of the source IP address, protocol, fragmentation flags, type of service, and protocol version information. The body comprises an operational request and/or addresses or data. By way of example, the message can be a request to open a session, read or write data, access a web service or close a session.

Each message packet is routed (in the normal manner) to firewall50because firewall50is interposed between network30of the originating device and network20of the destination device. Firewall50then determines if the addressing and protocol parameters of the message packet match a “rule” within the security policy of the firewall50(step301). In the illustrated embodiment, each rule defines a combination of source IP address, destination IP address, port of the destination device, protocol, etc. which is permitted to flow through the firewall50. Firewall50maintains a list of the rules in database51. If the addressing and protocol parameters of the message packet match a security policy rule (decision302, yes branch), then the firewall50forwards it to network20which contains the destination device21(step303). (In an alternate embodiment of the present invention, when a message packet matches a firewall rule, and this is the first match of this rule since the rule was created, then the firewall also sends the address and protocol parameters for this message packet to the control server for logging along with the expected action, i.e. to pass such a message packet.) Known routers or other routing devices in network20then forward the message packet to the destination device21. However, if the addressing and protocol parameters of the message packet do not match a rule within the security policy of firewall50(decision302, no branch), then firewall50does not forward the message packet to network20and instead discards the message packet (step304). Then, firewall50identifies the source IP address, destination IP address, port of the destination device, protocol, etc.) of the discarded message packet to the logging server11, and a management program308on the logging server logs these parameters of the discarded message packet (step306). Next, the management program308on the logging server copies the addressing and protocol parameters of the discarded message packet to the control server13(step310). In response, a control program312on the control server reads the source IP address, destination IP address, port of the destination address, protocol, etc. of the discarded message packet (step314), and then compares them to its own rules database12(step318). Database12maintains a list of combinations of source IP address, destination IP address, port of the destination address, protocol, etc. and whether they should be transferred through the firewall or discarded. If the source IP address is already stored in the database, the control program312then continues to check the rest of the parameters (decision320, yes branch). However, if the source IP address does not match any known source IP addresses, this means a new connection is being attempted and the database12needs to be updated (decision320, no branch). If the destination IP address is already stored in the database12, the control program312then continues to check the rest of the parameters (decision322). However, if the destination IP address does not match any known destination IP addresses, this means a new connection is being attempted and the database12needs to be updated (decision320, no branch). If any rule specifying the protocol (and a respective source port and destination port), is already stored in the database12, the control program312then continues to check the disposition (decision323, yes branch). If any rule specifying the protocol (and a respective source port and destination port), is not already defined in the database, this means a new connection is being attempted (decision323, no branch). If the combination of source IP address, destination IP address, port of the destination address, protocol, etc. of the discarded message packet match a combination in database12, then control program312determines if the response listed in database12for this combination is to discard the message packet (decision324). If so (decision324, yes branch), then it was proper for firewall50to discard this message packet. Consequently, control program312stops its processing of the parameters of this discarded message packet (step326). However, if the response listed in database12for this combination is to transfer the message packet through the firewall toward the destination device (decision324, no branch), then it was not proper for firewall50to discard this message packet. Consequently, control program312alerts a firewall administrator that the firewall50should have passed the discarded message packet to the network of the destination device (step330). This alert can be by e-mail, entry in a file of mishandled message packets, automatic formation of a problem ticket or display on a computer screen of the firewall administrator. The alert includes the source IP address, port of the source IP address, destination IP address, port of the destination address, protocol, etc. of the discarded message packet.

Referring again to decision324, there are a variety of scenarios where the rules in database12may differ from the rules in database51. In some systems, there are two or more different firewalls between a source device and a destination device. InFIG. 1, a second such firewall150and associated configuration/rules database151are illustrated in broken line; the message packet en route from workstation31to application server21encounters firewall50before firewall150. In such a case, if neither firewall initially includes a rule to pass this firewall, the packet will be blocked at firewall50. Then, after the steps ofFIG. 3(A-E) are performed resulting from the blockage by firewall50, the databases12and51are both updated to include a rule to permit this flow. In the illustrated embodiment, database151will not be updated at this time, so it will differ temporarily from database12. However, when the next message packet is sent from workstation31to application server21, the message packet will pass through firewall50but be blocked by firewall150. Then, when the steps ofFIG. 3(A-E) are performed resulting from blockage by firewall150, the difference between database12and database151will become apparent, and result in updating of database151to include a rule to pass this message packet. There are other scenarios where the rules in database12may differ from the rules in database51(or database151). For example, there can be different administrators for each database, and they each may update their respective database based on different information. As another example, the skill level of the administrator for database12may be higher than the skill level of the administrator for database51(and database151), and consequently, the administrator for database51(and database151) may be more likely to make mistakes than the administrator for database12.

In response to the alert, the firewall administrator determines whether the security policy of firewall50was changed intentionally (to block this message flow) and is correct (decision340). This determination is made based on a check of change requests which have been received, a contract with the customer, or contact with the service owner of the application server21. If the security policy of the firewall50is correct (decision340, yes branch), then the firewall administrator updates the database12within the control server13to indicate that this combination of source IP address, destination IP address, port of the destination address, protocol, etc. is not a permitted data flow through firewall50(step344). This ends processing of the parameters for this message packet (step346).

Refer again to decision340, no branch where the security policy of firewall50is not correct, and firewall50should have a rule to pass message packets with this combination of source IP address, destination IP address, port of the destination address, protocol, etc. In such a case, the control program312sends a request to the firewall50for a description of its configuration, including. a list of which combinations of source IP address, destination IP address, port of destination address, protocol, etc. are permitted message flows (step350). (This is sensitive information, so access is controlled by valid user ID and password.) Next, the control program312confirms that the combination of source IP address, destination IP address, port of destination address, protocol, etc. of the discarded message packet is not on the list or that the rule that would instruct the firewall50to process the message packet as expected is not overruled by another rule (step360). Next, the control program312alerts the firewall administrator as to the problem with the configuration of firewall50, for example, that the combination of source IP address, destination IP address, port of the destination address, protocol, etc. of the discarded message packet is not on the list or that the correct rule is in the wrong order and is being overruled (step370). The alert can be by e-mail, entry in a file of mishandled message packets, automatic formation of a problem ticket or a display on a computer screen used by the administrator. Next, the control program312queries the firewall administrator to decide whether the firewall administrator should manually change the firewall configuration or whether the control program312should automatically change the firewall configuration (step374). If the firewall administrator selects the automatic change, then the control program312automatically updates the firewall configuration to list this combination of source IP address, destination IP address, port of destination address, protocol, etc. as a permitted message flow (step376). Control program312can perform this update by executing a stored script program which operates firewall50. This completes processing of the parameters for this message packet (step380). Refer again to step374where the firewall administrator selected manual correction of the configuration of firewall50. In such a case, the control program312will send to the firewall administrator a suggested list of commands and parameters to operate firewall50to update the configuration of firewall50(step384). Next, the firewall administrator provides the expected date the change will become effective (step386). This date is stored in the database12(step388) so the implementation can avoid alerting the firewall administrator of future events that match the current message packet until the change date has passed.

Refer again to decision320no branch as well as decision322where the database12in the control server does not include an entry for either the source IP address or the destination IP address. In such a case, the control program312identifies at this point that a new flow is being attempted. Consequently, control program312alerts a firewall administrator that the firewall50should have processed the message packet differently (390). This alert can be by e-mail, entry in a file of mishandled message packets, automatic formation of a problem ticket or display on a computer screen of the firewall administrator. The alert includes the source IP address, port of the source IP address, destination IP address, port of the destination address, protocol, etc. of the logged message packet. In response to the alert, the firewall administrator determines whether the security policy of firewall50was changed intentionally (to block this message flow) and is correct (decision392). This determination is made based on a check of change requests which have been received, a contract with the customer, or contact with the service owner of the application server21. If the security policy of the firewall50is correct (decision392, yes branch), then the firewall administrator updates the database12within the control server13to indicate that this combination of source IP address, destination IP address, port of the destination address, protocol, etc. has changed to the current disposition of the message packet (step394). This ends processing of the parameters for this message packet (step396).

Refer again to decision323no branch where the database12in the control server does not include an entry for the protocol, or protocol specifics such as source port and destination port. In such a case, the control program312directs scanning server14to reconfigure its scanning interface15to connect to the network of the destination server (step400). In the illustrated example, the destination server21resides on network20. Next, the control program312directs scanning server14to reconfigure the scanning interface15with a valid IP address for network20such that scanning interface15resides on network20(step402). (In both steps400and402, control program312can direct scanning server14to reconfigure the scanning interface15by a script program or other interface provided for automation.) Next, the control program312sends to the scanning server14the source IP address, destination IP address, port of the destination address, protocol and source port of the discarded message packet (step404). In response, the scanning server14scans the destination server21based on the destination IP address, port of the destination address, protocol, source port of the discarded message packet (step406). This actual scanning is performed by sending a test packet to the port of the destination IP address of the discarded message packet using the protocol of the discarded message packet. The header of the test packet includes the source IP address and port of the scanning device, the destination IP address, port of the destination IP address, protocol, and protocol specifics such as source and destination ports. The intent of the scan is to determine whether the destination IP address and destination port are active and support the specified protocol. This will be indicated by an acknowledgment or other such response from the destination device to the test packet. Next, the scanning server returns the scan results to the control program312in the control server13(step408). At this time, the scanning is complete, so the control program312directs the scanning server14to undo the reconfiguration performed in steps400and402, such that the scanning interface15is no longer connected to any network, is not configured with any IP address and is in its “holding” state (step412).

In alternate embodiments of the present invention, networks10,20and40are not VPNs, and the firewall50is located between the scanning device and the destination IP address. In such a case, firewall50will include a message flow rule that if the source IP address is that of the scanning device14, then the firewall50should pass the packet through to the destination IP address and port. This will allow the test packet to proceed from the scanning device to the destination IP address and port despite the fact that other “real” message packets from other source IP addresses addressed to the same destination IP address and port will not pass through the firewall50at this time.

After steps402-406(as illustrated inFIG. 3(D)or in the alternate embodiments where the firewall50includes a rule to permit the test packet to pass through it), the control program312reviews the scan results to determine if the specified port and protocol of the destination server21are invalid or if the port is closed (decision420). If so (decision420, yes branch), then the control program312updates database12to indicate that this combination of port and protocol on destination server21is not valid or open (step422). This ends processing of the parameters for the discarded message packet (step424). Refer again to decision420, no branch, where the specified port and protocol are valid and open on the destination server21. In such a case, there may be a problem with the firewall configuration and information in the database12, i.e. it is possible that the firewall should have passed this message packet to the network20of the destination server21. Thus, control program312alerts the firewall administrator that a message packet with the foregoing combination of source IP address, destination IP address, port of the destination address, protocol, and protocol specifics such as source port or destination port, has been discarded but the destination server has the specified port open and supports the specified protocol at this port (step430). Next, the control program312queries the firewall administrator to answer whether the specified combination of destination port and protocol is supposed to be invalid and closed (step434). If the firewall administrator responds that the specified combination of port and protocol is supposed to be invalid and closed, then the control program312updates database12that the expected response to a message packet with this combination of destination device, port or the destination address and protocol is to discard the message packet (step438). However, if the firewall administrator responds that the specified combination of port and protocol is supposed to be valid and open, then the control program312proceeds to step350to update the firewall configuration/security policy to pass the foregoing message packet.

Based on the foregoing, a system, method and computer program for identifying additional rules which may be needed by a firewall to permit messages with different combinations of source IP address, destination IP address, destination port, protocol, etc. to flow through the firewall, have been disclosed in accordance with the present invention. However, numerous modifications and substitutions can be made without deviating from the scope of the present invention. For example, another implementation might log permitted packets as well as dropped packets. Therefore, the present invention has been disclosed by way of illustration and not limitation, and reference should be made to the following claims to determine the scope of the present invention.