A method of managing firewall change requests for a communication network includes providing a change request interface comprising a plurality of change request form types, each request form including an interface for entering requestor identification information, Internet Protocol (IP) address information, change implementation schedule information, and submission information specifying any requestor instructions for implementing the change, receiving completed change request forms from at least one requestor, arranging the completed change request forms in a request queue, and presenting the request queue to at least one administrator responsible for implementing firewall changes in the communication network.

A global architecture (GLP), as disclosed herein, is based on the thin server architectural pattern; it delivers all its services in the form of web services and there are no user interface components executed on the GLP. Each web service exposed by the GLP is stateless, which allows the GLP to be highly scalable. The GLP is further decomposed into components. Each component is a microservice, making the overall architecture fully decoupled. Each microservice has fail-over nodes and can scale up on demand. This means the GLP has no single point of failure, making the platform both highly scalable and available. The GLP architecture provides the capability to build and deploy a microservice instance for each course-recipient-user combination. Because each student interacts with their own microservice, this makes the GLP scale up to the limit of cloud resources available—i.e. near infinity.

A system and method for provisionally authenticating a host moving from a source port of a switch device to a destination port of the switch device is disclosed. The host is initially authenticated at the source port and blocked from forwarding network traffic at the destination port. During a provisional authentication session, an authentication agent executing on the switch intercepts one or more authentication packets sourced by the host and headed for the destination port of the switch device and redirects the authentication packets to an authentication server for validating the host at the destination port of the switch device. The switch device removes the block at the destination port in response to receiving an acknowledgment of successful authentication at the destination port from the authentication server.

A novel method for stateful packet classification that uses hardware resources for performing stateless lookups and software resources for performing stateful connection flow handshaking is provided. To classify an incoming packet from a network, some embodiments perform stateless look up operations for the incoming packet in hardware and forward the result of the stateless look up to the software. The software in turn uses the result of the stateless look up to perform the stateful connection flow handshaking and to determine the result of the stateful packet classification.

The present disclosure discloses a method and a network device for performing dynamic detection and application-based policy enforcement of proxy connections in a network. Specifically, a network device receives, from a client device, a packet in a session. The network device then determines whether the packet is transmitted to a proxy. In response to determining that the packet is associated with a different application classification or web content category during the same session, the network device re-applies network firewall policies to determine whether to allow or deny transmission of the packet to the proxy.

In an example, a system and method for data plane integration is described. Aspects of the embodiments are directed to a service application connected to a switch of a network fabric and a method of data plane integration performed at a service appliance, the service appliance providing firewall functionality. The service appliance can receive a data packet from a network location; determine a flow owner of the data packet based on a hashing table; and transmit the data packet based on the determined flow owner of the data packet.

A method and system for detecting ruleset misconfiguration in a computer network. The method including: generating a set of sample data flows; evaluating each of the set of sample data flows against a predetermined definition to generate a flow descriptor for each of the set of sample data flows; evaluating each of the flow descriptors against a ruleset; and generating a summary of how each of the flow descriptors perform with respect to the ruleset. The system including: a data flow sample retrieval module configured to generate flows; a policy engine configured to store and retrieve a ruleset; a packet processing engine configured to evaluate each of the data flows against a predetermined definition to generate a flow descriptor for each flows, evaluate each of the flow descriptors against a ruleset; and generate a summary of how each of the flow descriptors perform with respect to the ruleset.

A threat intelligence gateway (TIG) may protect TCP/IP networks from network (e.g., Internet) threats by enforcing certain policies on in-transit packets that are crossing network boundaries. The policies may be composed of packet filtering rules with packet-matching criteria derived from cyber threat intelligence (CTI) associated with Internet threats. These CTI-derived packet-filtering rules may be created offline by policy creation and management servers, which may distribute the policies to subscribing TIGs that subsequently enforce the policies on in-transit packets. Each packet filtering rule may specify a disposition that may be applied to a matching in-transit packet, such as deny/block/drop the in-transit packet or pass/allow/forward the in-transit packet, and also may specify directives that may be applied to a matching in-transit packet, such as log, capture, spoof-tcp-rst, etc. Often, however, the selection of a rule's disposition and directives that best protect the associated network may not be optimally determined before a matching in-transit packet is observed by the associated TIG. In such cases, threat context information that may only be available (e.g., computable) at in-transit packet observation and/or filtering time, such as current time-of-day, current TIG/network location, current TIG/network administrator, the in-transit packet being determined to be part of an active attack on the network, etc., may be helpful to determine the disposition and directives that may best protect the network from the threat associated with the in-transit packet. The present disclosure describes examples of methods, systems, and apparatuses that may be used for efficiently determining (e.g., accessing and/or computing), in response to the in-transit packet, threat context information associated with an in-transit packet. The threat context information may be used to efficiently determine the disposition and/or one or more directives to apply to the in-transit packet. This may result in dispositions and/or directives being applied to in-transit packets that better protect the network as compared with solely using dispositions and directives that were predetermined prior to receiving the in-transit packet.

A proxy server receives from a client device a request for a network resource that is hosted at an origin server for a domain. The request is received at the proxy server as a result of a DNS request for the domain resolving to the proxy server. The origin server is one of multiple origin servers that belong to different domains that resolve to the proxy server and are owned by different entities. The proxy server retrieves the requested network resource. The proxy server determines that the requested resource is an HTML page, automatically modifies the HTML page, and transmits the modified HTML page to the client device.

Systems and methods to manage and regulate the requests of multiple proxy clients are disclosed. In one aspect, the system and methods disclosed herein aids in configuring proxy server(s) with a rate-limit functionality. Configuration of the rate-limit functionality may be realized by, but not limited to, installing configuration file(s) and/or software application(s) on the proxy server(s). The configuration provides information about the list of restricted and unrestricted domains and their respective request limit specification in a given time frame. Therefore, each time before a proxy server forwards the clients' requests to a target domain, the proxy server checks and ensures that the request count to the particular target domain is well within the limit specified in the request limit specification. Thus, the embodiments described herein aid in preventing the IP addresses of proxy service providers from being blocked or denied from the target websites.