Intelligent Firewall Using Identification Information of Valid Traffic

Abstract

In a network where connections are made between devices or between network segments through a security device such as a firewall, a user attempting to contact a destination device may be prevented from doing so by some or all of the security devices, whereby packets addressed to the destination device and sent by the user can be silently blocked. Rectifying this inability to contact the destination device can be made more difficult by the user's lack of knowledge as to which security devices are configured to block the packets. Therefore, a system and method for managing network access are provided.

Description

Technical Field

[0001] [Cross - Reference to Related Applications] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 365,978, filed on June 7, 2022, entitled "Intelligent Firewall Using Identification Information of Valid Traffic", which is hereby incorporated by reference in its entirety.

[0002] One or more aspects of embodiments according to the present disclosure relate to network access, and more specifically, to systems and methods for managing network access.

Background Art

[0003] In a network where connections are made between devices or between network segments through a security device such as a firewall, a user attempting to contact a destination device may be prevented from doing so by some or all of the security devices, such that packets addressed to the destination device and sent by the user can be silently blocked. Rectifying the inability to contact the destination device can be made more difficult by the lack of knowledge on the user's part regarding which security devices are configured to block the packets.

[0004] This is relevant to this general technical environment to which aspects of the present disclosure pertain.

Summary of the Invention

[0005] Systems and methods for managing network access are provided. In one aspect, the method comprises receiving, by a security device, a packet including a ticket identifier, and determining, by the security device, the disposition of the packet. The method may further comprise logging, by the security device, the disposition of the packet together with the ticket identifier and together with an identifier of the security device.

[0006] In another aspect, the method comprises receiving, from a source device, a request for a first ticket identifier; providing the first ticket identifier to the source device; receiving, from a first security device, log information indicating that the first ticket identifier has been received by the first security device; verifying access to the source device; and automatically reconfiguring the first security device to allow packets from the source device to pass through the first security device.

[0007] In another aspect, there is provided a security device comprising at least one processing circuit; and a memory operably connected to the at least one processing circuit and storing instructions which, when executed by the at least one processing circuit, cause the security device to perform a method. In an aspect, the method comprises receiving a packet comprising a ticket identifier; determining an arrangement of the packet; and logging the arrangement of the packet together with the ticket identifier and an identifier of the security device.

[0008] The summary of the invention is provided to introduce in a simplified form a selection of concepts that are further described below in the detailed description of embodiments of the invention. The summary of the invention is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Reference will now be made to the accompanying drawings, in which exemplary embodiments of the disclosure are shown, and in which these and other features and advantages of the disclosure will be recognized and understood. Exemplary and non-limiting and non-exhaustive examples will be described with reference to the following figures.

[0010]

Figure 1

[0011]

Figure 2A

[0012]

Figure 2B

[0013]

Figure 2C

[0014]

Figure 2D

[0015]

Figure 2E

[0016]

Figure 3A

[0017]

Figure 3B

[0018]

Figure 3C

[0019]

Figure 3D

[0020]

Figure 3E

[0021]

Figure 4

Best Mode for Carrying Out the Invention

[0022] The detailed description provided below in connection with the accompanying drawings is intended as an explanation of exemplary embodiments of a system and method for managing network access provided in accordance with the present disclosure, and is not intended to represent only the forms in which the present disclosure can be constructed or utilized.

[0023] In the following detailed description, reference is made to the accompanying drawings which form a part hereof and in which specific embodiments or examples are shown by way of illustration. Without departing from the scope of the present disclosure, these aspects may be combined, other aspects may be utilized, and structural changes may be made. The examples may be implemented as a method, system, or device. Thus, the examples may take the form of an implementation in hardware, an implementation in software entirely, or an implementation combining software and hardware aspects. Additionally, all systems described with respect to the figures may include one or more machines or devices operatively connected to cooperate to provide the functionality of the described systems. Accordingly, the following detailed description should not be construed in a limiting sense, and the scope of the present disclosure is defined by the appended claims and their equivalents.

[0024] Referring to FIG. 1, when a user interacts with a network including security devices 105 (or switches or routers, or other devices having packet filtering capabilities) such as firewalls F1, F2, F3, etc., via, for example, the source device 100, the user may sometimes be blocked from accessing a device 110 (which may be referred to as the destination device) on a specific network segment (e.g., a server on network segment 2) by one or more security devices between the source device 100 and the destination device 110. Even if the user has the qualification to access the network segment (e.g., when the user is a trusted employee of the entity that owns and operates the network), the security device may be configured by default not to grant access to each such user. Therefore, the security device may need to be reconfigured to enable user access to the destination device 110.

[0025] In some situations, since the user may not know which one or more security devices the established path from the source device 100 to the destination device 110 passes through, and since the user may not know which one or more security devices require reconfiguration, this reconfiguration may be, in part, inefficient and time-consuming. Therefore, the user may contact, for example, multiple people each responsible for different security devices within the system and prepare to be granted access to transmit packets through the security devices. When a large number of security devices are involved, or when procedures for requesting and being granted access are involved, this process may be time-consuming. Furthermore, if some of these security devices are already configured to forward packets that the user can send to the destination device 110 even if the user is not aware of it, an important part of this effort may be wasted.

[0026] Accordingly, in some examples, network system 101 as shown in FIG. 1 may include, in addition to network segments and security devices, additional components that can facilitate the diagnosis and correction of failed accesses by users to destination device 110. As used herein, a "network system" is a system that includes a network and such additional components. The additional components may include, as shown in FIG. 1, a self-service portal 115, an access station 120, a log server 125, and management automation 130. Each of access station 120, log server 125, and management automation 130 may be a server or an operating environment, or may be implemented on or within a server or an operating environment (to be described in more detail below).

[0027] In such a system, a user may prepare for the source device 100 to transmit a packet to the destination device 110. The packet (which may be, for example, a Transmission Control Protocol (TCP) packet or a User Datagram Protocol (UDP) packet) may be addressed to a port of the destination device 110 (or “destination port”) and to a destination IP address that is the IP address of the destination device 110, and the packet may include a number that may be referred to herein as a “ticket identifier” associated with the user and the source device 100. Since the ticket identifier may be a reliable, e.g., encrypted, attribute within the packet, the target can trust the customer and vice versa. For example, the ticket identifier may be a number of intermediate length (e.g., a 20-character (160-bit) number) that is unlikely to be used simultaneously by another user of the network system 101. For example, it may be (i) a source Internet Protocol (IP) address (e.g., the IP address of the source device 100, or the IP address to which the IP address of the source device 100 is translated by Network Address Translation (NAT)), (ii) a number selected by the user (e.g., the user may select their phone number), (iii) a number generated by the network system 101 (e.g., by the self-service portal 115 or by the access station 120), or may include these. In the case of a ticket identifier generated by the network system 101 (e.g., by the self-service portal 115 or by the access station 120) but not supplied by the user, the ticket identifier may be selected to be unique (e.g., among the most recently generated ticket identifiers or among all ticket identifiers generated by the network system 101 to date). The ticket identifier may be or may include a password or a digital signature. As used herein, a “password” is a shared secret, such as a number (which may be presented to the user as a sequence of digits or characters) that is not publicly accessible and that grants a particular privilege within the network system 101 to the person who owns it.In some examples, the password is a number that is created by a user of the source device 100 or disclosed only to the user for whom it is generated as the intended recipient.

[0028] If the ticket identifier includes a password, it may be obtained or specified by the user by using an authentication process (e.g., a two-factor authentication process). For example, the user may access the self-service portal 115 (e.g., through the source device 100) and submit a request to access the destination device 110 (e.g., via a suitable user interface, such as through a browser). The self-service portal 115 may provide an opportunity for the user to explain the business case or other reasons for needing access to the destination device 110, and the issuance of the ticket identifier may be conditional on one or more of (i) the user providing such an explanation or (ii) the explanation being considered acceptable (e.g., by a network administrator or supervisor). Next, the network system 101 generates a password (which may be, for example, a pseudorandom number or an encrypted hash of a number that is difficult to predict in advance, such as a segmented time period), and provides it to the source device for display or use, for example, via the self-service portal 115, or alternatively, provides it to the source device 100 or the user of the source device 100. In some examples, the user may instead specify the password (e.g., through a user interface enabled by the self-service portal 115, for which the network system 101 may check the uniqueness and strength of the password before accepting it). In some examples, the network system 101 may automatically notify another user (e.g., a supervisor) whenever a ticket identifier is requested or issued, or if it may be waiting for permission from another user prior to the issuance of the ticket identifier. In some examples, the source device may include an application, plugin, or other code that automatically inserts the ticket identifier into the packets sent to the destination device 110. In an example, the ticket identifier need not be displayed to the user of the source device 100, but may be stored on the source device 100 and automatically inserted into any packet (e.g., the header thereof) directed to the destination device 110.In an example, this insertion is not automatic, but the user may choose to use an identifier insertion application (e.g., operating on the source device 100) that inserts a ticket identifier into each packet sent to the destination device 110 during subsequent attempts to contact the destination device 110. In an example, the ticket identifier may also have a time-to-live (TTL) value associated therewith, and the ticket identifier may be valid only for use when accessing the destination device 110 before TTL expiration.

[0029] The ticket identifier may be used for both path testing and access acquisition, each of which is described in further detail below. When performing a path test, a user may send an addressed packet to the destination device 110, primarily for the purpose of identifying a security device 105 that is blocking access to the destination device 110. The security device may be configured to support path testing in several different ways. In some examples, a ticket identifier, which may be referred to as a "test ticket identifier," is used for path testing, for example, by an identifier insertion application. The test ticket identifier may be reusable and need not be approved (e.g., by a network administrator). In some examples, each security device treats a packet containing a ticket identifier (which may be referred to as a "ticket-containing packet") in the same manner as it would for another packet, except that it may log the placement of the packet along with the ticket identifier and the identifier of the security device. This logging may include submitting a report to the log server 125 that includes (i) the ticket identifier, (ii) the identifier of the security device (which may be the IP address of the security device 105 submitted in the source IP address field of the header of the reported packet), and (iii) the placement of the packet (e.g., whether it was dropped or forwarded). In such a system, after sending a packet, the user may submit a query (e.g., through a self-service portal 115) to the log server 125 (e.g., for all reports that match the ticket identifier) and identify from the report a first security device on the path that is configured to block packets sent from the source device 100 to the destination device 110.Next, the user prepares for the first security device 105 to be reconfigured to forward a packet sent by the source device 100 and addressed to the destination device 110, repeats this process as needed for identification, and can reconfigure each of the security devices 105 on the path to the destination device 110 that is configured to block such packets. In such an example, a ticket identifier may be sufficient to be a string generated by the user (e.g., the user's name or phone number), and it is not necessary for the ticket identifier to have the characteristics of a password.

[0030] In some examples, each security device 105 is configured to (a) remove the payload, or, if part of the payload is part of the ticket identifier, (ii) the remaining part of the payload from the packet, (b) forward the packet, and (c) log whether the transfer of the packet from the source device 100 to the destination device 110 is permitted for ticket-free packets (e.g., log how the packet's placement would have been if the packet did not contain the ticket identifier). In such an example, the packet may be transmitted to the destination device 110, and the user may later obtain a list of security devices 105 that need to be reconfigured to grant the user access to the destination device 110 by submitting a single appropriate query to the log server 125 (and without repeatedly sending the packet and reconfiguring the security device 105). The query may be submitted, for example, using the self-service portal 115.

[0031] It may be that the path from the source device 100 to the destination device 110 changes over time (e.g., as a result of a change in the load on a connection within a network, or a connection being disconnected or otherwise becoming unavailable). Thus, the path test may involve sending a plurality of packets (e.g., between 10 and 100 packets) from the source device 100 to the destination device 110, and (i) blocking ticket-free packets sent from the source device 100 to the destination device 110, and (ii) generating a list of all security devices 105 that are on any such path (or on any path that is used beyond the fractional threshold of this time (e.g., beyond 5% of this time)). It may be that the discovery process using the path test fails to identify some such security devices 105. For example, a certain security device 105 may be on a non-preferred path and thus may not need to be discovered by the path test; next, the non-preferred path may become a preferred path if a connection on another previously preferred path is disconnected. In such a case, the path test may be run again (or periodically) as needed.

[0032] In some examples, as described above, the ticket identifier may be used to obtain access to the destination device 110 (instead of or in addition to determining which security device 105 needs to be reconfigured to obtain such access for the user). This may be implemented in various ways.

[0033] In some examples, the ticket identifier is a password that gives the user access (e.g., temporary access) to the destination device 110, or includes this password. For example, when the ticket identifier is set (e.g., issued to the user), it can be stored in the access station 120 together with the requested destination IP address (the IP address of the destination device 110) and port number. The IP address of the source device 100 may or may not be stored in the access station 120 together with the ticket identifier. Also, or alternatively, this information (ticket identifier, requested destination IP address and port number, and optionally, the IP address of the source device 100) can be sent (e.g., by the access station 120) to (i) all of the security devices in the network, or (ii) the security devices on one path (or multiple paths) from the source device 100 to the destination device 110.

[0034] If information is not sent thereto, the security device 105 may periodically query the access station 120 to determine whether packet transfer is permitted. A query sent to the access station 120 may include a ticket identifier, a destination port number and a destination IP address, and optionally, a source IP address (the IP address of the source device 100). If it has information indicating that the transfer of a packet containing a ticket identifier is permitted, the security device 105 may transfer any such packet. In some examples, the security device 105 may also change its configuration to transfer packets from the source device 100 to the destination device 110 regardless of whether such packets contain a ticket identifier (such a change may be permanent or may be reversed after the expiration of the TTL associated with the ticket identifier). In some examples, the change in configuration is conditional, for example, on an independent, authenticated confirmation that the change in configuration is permitted (e.g., by a network administrator). In some examples, the ticket identifier is a digital signature (e.g., a cryptographic digital signature based on a public key algorithm) or includes this. In such an example, the security device 105 may have a public key for verifying such a digital signature and may be able to determine whether to transfer a packet and whether to change its configuration based on a determination of whether the digital signature is genuine.

[0035] The ticket identifier can be stored in the packet in several ways. In some examples, the ticket identifier is stored in the packet header, for example, in any header field adapted for such use (e.g., in the IP option field of an IP packet). If the ticket identifier is the source IP address, it can be stored in the source IP address field of the header (in this situation, it may be stored, for example, in the IP option field, or a flag may be set to notify the security device 105 that the packet is a ticket-containing packet (e.g., in the IP option field)). In some examples, the ticket identifier, or a portion of the ticket identifier, can be stored in the payload of the packet. This can be advantageous if the ticket identifier is a signature, or includes such a signature, that is too large to easily fit into the packet header.

[0036] Once a list of security devices 105 that need to be reconfigured to provide the user access to the destination device 110 is generated, without user involvement or with minimal additional user involvement, the configuration of each security device 105 can be modified to provide the user access to the destination device 110. For example, each security device 105 may automatically modify its own configuration as described above, or the network system 101 may initiate a process (which may be triggered by the reception of a ticket-containing packet by any of the security devices 105) to modify the configuration of the security device 105 (e.g., the security device 105 identified in a discovery (e.g., path probing) process that is potentially on the path) after, for example, verifying that access should be granted. In some examples, the network system 101 may automatically communicate (e.g., via short message service (SMS) or email) with the user or another user such as a network administrator to request confirmation that a modification to the security device configuration should be made. The security device 105 may then be automatically reconfigured by the network system 101, or the network system 101 may send an automated request to the network administrator to modify the security device configuration. Such involvement of the network administrator can serve as an additional security measure as long as the network administrator can better identify suspicious requests. In some examples, the network administrator may periodically check the logs of the log server 125 and appropriately modify the security device 105 to provide access.

[0037] In some examples, each ticket identifier may expire after the TTL has elapsed (or "expired"), or after some event has occurred (e.g., ceases to be treated as a ticket identifier by the security device 105). For example, for a path test, the security device 105 may be configured to forward only one packet based on any ticket identifier, such that if a second packet is sent with the same ticket identifier, it may be blocked. In another example, each of the security devices 105 may be notified (e.g., by the log server 125) of the time at which the ticket identifier was issued and its TTL. In other examples, each security device may be programmed to assume a TTL for a set period (e.g., 10 minutes or 1 hour) after the security device 105 receives notification of the ticket identifier. The security device 105 may reject (e.g., decline to treat as a ticket identifier) any ticket identifier for which the TTL communicated with the ticket identifier, and / or the assumed TTL, has expired. In such examples, the TTL may be selected to be sufficient to (i) complete a path test, or (ii) enable a user to complete a short-term task that requires access to the destination device 110. In some examples, the user specifies the TTL at the time the ticket identifier request is submitted.

[0038] Figures 2A through 3E are flowcharts of methods according to several examples described herein. These flowcharts, and the descriptions herein, are not intended to illustrate and describe the order required to perform the steps of these methods, and in some examples, some of these steps are performed in an order different from the order illustrated and described. Referring to FIG. 2A, in some examples, at 202, a packet including a ticket identifier is received; at 204, the placement of the packet is determined, and at 206, the placement of the packet is logged. This logging step may include logging the ticket identifier and the identifier of the security device along with the placement of the packet. Referring to FIG. 2B, in some examples, the method further includes, at 208, determining based on information received from the access station that the transfer of a packet including a source IP address equal to the source IP address of the packet and a destination IP address equal to the destination IP address of the packet is permitted; and, at 210, configuring the security device to transfer a packet including a source IP address equal to the source IP address of the packet and a destination IP address equal to the destination IP address of the packet.

[0039] Referring to FIG. 2C, in some examples, the packet includes a header and a payload, and the method further includes, at 212, transferring the packet after removing a portion of the payload. Referring to FIG. 2D, in some examples, (at 204 in FIG. 2A,) the step of determining the placement of the packet includes, at 214, determining whether the time to live associated with the ticket identifier has expired. Referring to FIG. 2E, in some examples, (at 204 in FIG. 2A,) the step of determining the placement of the packet includes, at 216, determining whether the security device has received another packet including the same ticket identifier.

[0040] Figure 3A is a flowchart of a method according to some examples described herein. In some examples, at 300, a request for a first ticket identifier is received from a source device; at 302, the first ticket identifier is provided to the source device; at 304, log information indicating that the first ticket identifier has been received by a first security device is received from the first security device; at 306, access to the source device is verified; at 308, the first security device is automatically reconfigured to allow packets from the source device to pass through the first security device. Referring to Figure 3B, in some examples, the method further comprises, at 310, receiving from the first security device a log message indicating that a packet including a second ticket identifier has been transferred; and, at 312, reporting that the packet has been transferred by a plurality of security devices including the first security device. Referring to Figure 3C, in some examples, the method further comprises, at 314, receiving a packet including the first ticket identifier; at 316, determining that a time-to-live associated with the first ticket identifier has elapsed; and, at 318, not transferring the packet.

[0041] Referring to Figure 3D, in some examples, the method further comprises, at 320, receiving from the source device a time-to-live (e.g., along with a request for the first ticket identifier). Referring to Figure 3E, in some examples, the method further comprises, at 322, receiving from a second security device log information indicating that the first ticket identifier has been received by the second security device; and, at 324, automatically reconfiguring the second security device to allow packets from the source device to pass through the second security device.

[0042] FIG. 4 shows an example of a suitable operating environment 400, and each part of this environment can be used to implement the security device 105 or the user computing device, or other computing devices within the systems described herein. In its most basic configuration, the operating environment 400 typically includes at least one processing circuit 402 and a memory 404. The processing circuit may be a processor that is hardware. Depending on the exact configuration and type of the computing device, the memory 404 (which stores instructions for executing the methods disclosed herein) may be volatile (such as RAM), non-volatile (e.g., ROM, flash memory, etc.), or some combination of the two. This most basic configuration is shown by the dashed line 406 in FIG. 4. The memory 404 stores instructions that, when executed by the processing circuit 402, perform the processes and operations described herein. Further, the environment 400 may also include storage (removable 408 or non-removable 410) including, but not limited to, solid state, magnetic disk, optical disk, or tape. Similarly, the environment 400 may also have input devices 414 such as, for example, a keyboard, a mouse, a pen, voice input, etc., or output devices 416 such as, for example, a display, a speaker, a printer, etc. Additional communication connections 412 may also be included to enable further communication with, for example, LAN, WAN, point-to-point, etc. The operating environment 400 may also include a geolocation device 420 such as a global positioning system (GPS) device.

[0043] The operating environment 400 typically includes at least some form of computer-readable medium. The computer-readable medium can be any available medium that can be accessed by the processing circuit 402 or other devices including this operating environment. By way of example and not limitation, the computer-readable medium can comprise computer storage media and communication media. Computer storage media includes volatile and nonvolatile media, removable and nonremovable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules, or other data. Computer storage media includes RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transitory media that can be used to store the desired information. Computer storage media is non-transitory and tangible and does not include communication media.

[0044] Communication media embodies computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as, for example, a carrier wave or other transport mechanism, and includes any information delivery media. The term "modulated data signal" means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared, microwave, and other wireless media. Any combination of the above should also be included within the scope of computer-readable media.

[0045] As used herein, the term "or" is inclusive, such that for example, "A or B" means any one of (i) A, (ii) B, and (iii) A and B. As used herein, a method or a first number (e.g., a first variable) is referred to as being "based on" a second number (e.g., a second variable), which means that the second number is an input to the method, or affects the first number, e.g., the second number may be an input (e.g., the only input, or one of several inputs) to a function that calculates the first number, or the first number may be equal to the second number, or the first number may be the same as the second number (e.g., stored at the same one or more positions in memory).

[0046] The term "processing circuit" is used herein to mean any combination of hardware, firmware, and software used to process data or digital signals. Processing circuit hardware can include, for example, application specific integrated circuits (ASICs), general purpose or special purpose central processing units (CPUs), digital signal processors (DSPs), graphics processing units (GPUs), and programmable logic devices such as field programmable gate arrays (FPGAs). In the processing circuits used herein, each function is performed by either more specialized hardware configured to perform the function, i.e., hardwired hardware, or more general purpose hardware such as a CPU configured to execute instructions stored on a non-transitory storage medium. The processing circuit can be manufactured on a single printed circuit board (PCB) or distributed across several interconnected PCBs. The processing circuit can include other processing circuits; for example, the processing circuit can include two processing circuits, an FPGA, and a CPU interconnected on a PCB.

[0047] Furthermore, examples of the present invention may be implemented in an electric circuit including discrete electronic elements, a packaged or integrated electronic chip including logic gates, a circuit utilizing a microprocessor, or a single chip including an electronic element or a microprocessor. For example, an example of the present invention may be implemented via a system-on-chip (SOC) in which each or many of the components shown in FIG. 4 may be integrated into a single integrated circuit. Such an SOC device may include one or more processing units, a graphics unit, a communication unit, a system virtualization unit, and various application functions, all of which are integrated (or "burned") onto a chip substrate as a single integrated circuit. When operating via an SOC, the functions described herein with respect to the generation of the proposed queries may be operated via application-specific logic integrated with other components of the operating environment 400 on a single integrated circuit (chip). Examples of the present disclosure may also be implemented using other techniques capable of performing logical operations such as, for example, AND, OR, and NOT, which include, but are not limited to, mechanical, optical, fluidic, and quantum technologies.

[0048] Exemplary embodiments of systems and methods for managing network access have been specifically described and illustrated herein, but many modifications and variations will become apparent to those skilled in the art. Accordingly, it should be understood that systems and methods for managing network access constructed in accordance with the principles of the present disclosure may be embodied in ways other than those specifically described herein. The present invention is also defined in the following claims and their equivalents.

Claims

1. Receiving, by a security device, a packet including a ticket identifier; Determining, by the security device, an arrangement of the packet; and By the security device, The ticket identifier, and An identifier of the security device Logging the arrangement of the packet together A method comprising.

2. The method according to claim 1, wherein the ticket identifier includes a password.

3. The method according to claim 1, wherein the ticket identifier includes a number supplied by a user.

4. The method according to claim 1, wherein the ticket identifier includes a source IP address.

5. The method according to claim 1, wherein the ticket identifier includes a digital signature.

6. Determining, based on information received from an access station, that transfer of a packet including a source IP address equal to the source IP address of the packet and a destination IP address equal to the destination IP address of the packet is permitted; and Configuring the security device to transfer a packet including a source IP address equal to the source IP address of the packet and a destination IP address equal to the destination IP address of the packet The method according to claim 1, further comprising.

7. The packet includes a header and a payload, The method further comprises transferring the packet after removing a part of the payload, The method according to claim 1.

8. The method according to any one of claims 1 to 7, wherein the step of determining, by the security device, the arrangement of the packet includes determining whether a time to live associated with the ticket identifier has expired.

9. The method according to any one of claims 1 to 7, wherein the step of determining, by the security device, the arrangement of the packet includes determining whether the security device has received another packet including the same ticket identifier.

10. The method according to any one of claims 1 to 7, wherein an Internet protocol (IP) option field of the header of the packet includes the ticket identifier.

11. Receiving, from a source device, a request for a first ticket identifier; Providing the first ticket identifier to the source device; Receiving, from the first security device, log information indicating that the first ticket identifier has been received by the first security device; Verifying access to the source device; and Automatically reconfiguring the first security device to allow a packet from the source device to pass through the first security device A method comprising.

12. Receiving, from the first security device, a log message indicating that a packet including a second ticket identifier has been transferred; and Reporting that the packet has been transferred by a plurality of security devices including the first security device The method according to claim 11, further comprising.

13. Receiving a packet including the first ticket identifier; Determining that a time to live associated with the first ticket identifier has elapsed; and Not transferring the packet The method according to claim 11, further comprising.

14. The method according to claim 13, further comprising receiving the time to live from the source device.

15. Receiving, from the second security device, log information indicating that the first ticket identifier has been received by the second security device; and Automatically reconfiguring the second security device to allow a packet from the source device to pass through the second security device The method according to any one of claims 11 to 14, further comprising.

16. At least one processing circuit; and Memory A security device comprising: The memory is operably connected to the at least one processing circuit and stores instructions which, when executed by the at least one processing circuit, Receiving a packet including a ticket identifier; Determining an arrangement of the packet; and Logging the arrangement of the packet together with The ticket identifier and An identifier of the security device Causing the security device to execute a method including Security device.

17. The packet includes a header and a payload, The method further comprises transferring the packet after removing a portion of the payload The security device according to claim 16.

18. The step of determining the placement of the packet includes a step of determining whether the time to live associated with the ticket identifier has expired, the security device according to claim 16.

19. The step of determining the placement of the packet has a step of determining whether the security device has received another packet including the same ticket identifier, the security device according to claim 16.

20. The Internet Protocol (IP) option field of the header of the packet includes the ticket identifier, the security device according to any one of claims 16 to 19.

Images