WO2015152869A1

WO2015152869A1 - Redirecting connection requests in a network

Info

Publication number: WO2015152869A1
Application number: PCT/US2014/032344
Authority: WO
Inventors: Shaila SHREE; Raphael AMORIM DANTAS LEITE; Debasish BISWAS
Original assignee: Hewlett-Packard Development Company, L.P.
Priority date: 2014-03-31
Filing date: 2014-03-31
Publication date: 2015-10-08

Abstract

Redirecting connection requests in a network can include detecting a suspicious connection request within a network, redirecting the suspicious connection request to a trusted server within the network, and executing a selective action based on a characteristic of the suspicious connection request.

Description

REDIRECTING CONNECTION REQUESTS IN A NETWORK

Background

[0001 ] Network security systems may be utilized to enhance the security and/or the performance of a computing network. For example, a network security system may block traffic that is seeking resolution of a domain name, such as those reportedly involved in a malicious activity. Malicious activities can include distributed denial of service attacks or sending spam, for example, among others.

Brief Description of the Drawings

[0002] Figure 1 illustrates a diagram of an example of a system for redirecting connection requests in a network according to the present disclosure.

[0003] Figure 2 illustrates a diagram of an example computing device according to the present disclosure.

[0004] Figure 3 illustrates an environment for redirecting connection requests in a network according to the present disclosure.

[0005] Figure 4 illustrates a flow chart of a method for redirecting connection requests in a network according to the present disclosure. Detailed Description

[0007] An entity can implement network security systems to protect against vulnerabilities in their networks. However, many entities and

organizations are also moving their information technology (IT) infrastructures to cloud computing environments (e.g., from self-managed on-premise data centers to service-provider managed outsourced virtual data centers), which may allow third parties to provide shared computing resources and applications running on those resources. The move by companies to cloud computing environments is increasing for various reasons, including the need for increased computing power, increased storage capacity, and/or increased network bandwidth, among others. Without adequate device, system, and application security, the cloud can compromise these applications, potentially causing large losses.

[0008] Some malicious software can use spurious (e.g., fake and/or illegitimate) Domain Name System (DNS) servers to gain access to networks. Such DNS servers can be corrupted to resolve to a malicious site that enables various security threats to gain access to the network. Some mechanisms to protect network services from such attacks include using firewalls which can have policies to prevent network clients from accessing a potentially malicious server. However, such mechanisms merely block requests to access such servers, and do not allow for customized responses to particular requests to connect to particular servers.

[0009] In contrast, redirecting network requests in a network according to examples of the present disclosure can provide a more scalable and custom network security system than firewalls by implementing custom policies.

Traditional firewall-based approaches simply block suspicious requests and result in an error page for the user attempting to gain access, or result in network timeouts. Examples of the present disclosure enable special processing and/or further inspection of suspicious access requests and provide a robust solution that can be implemented on any networking protocol.

[0010] Figures 1 and 2 illustrate examples of systems 100, 208 according to the present disclosure. Figure 1 illustrates a diagram of an example of a system 100 for redirecting connection requests in a network according to the present disclosure. The system 100 can include a database 101 , a subsystem 102, and/or a number of engines 103, 104, 105. As used herein, "a" or "a number of something can refer to one or more such things. For example, "a number of widgets" can refer to one or more widgets. The subsystem can include the number of engines in communication with the database 101 via a communication link. The system 100 can include additional or fewer engines than illustrated to perform the various functions described herein. The system can represent software and/or hardware of a network controller (e.g., device 208 as referenced in Figure 2, etc.).

[0011 ] The number of engines 103, 104, 105 can include a combination of hardware and programming that is configured to perform a number of functions described herein (e.g., detect a suspicious connection request within a network, etc.). The programming can include program instructions (e.g., software, firmware, etc.) stored in a memory resource (e.g., computer readable medium (CRM), machine readable medium (MRM), etc.) as well as hard-wired program (e.g., logic).

[0012] The detection engine 103 can include hardware and/or a combination of hardware and programming to detect a suspicious connection request within a network, such as a software defined network (SDN). As used herein, a suspicious connection request can refer to a connection request received from a client in a client-server network, to access a particular server that is not recognized by the client-server network as a trusted (e.g., standard) server. As discussed further herein, a suspicious connection request can include a request to access a server outside of the client-server network. For example, a suspicious connection request can include a request from a client in a client-server network to connect to a server not identified on a list of trusted servers. As used herein, a client-server network refers to a distributed application structure that partitions tasks or workloads between providers of a resource or service (e.g., servers), and service requesters (e.g., clients).

Clients and servers in a client-server network can communicate over a computer network on separate hardware, but both client and server may reside in the same system. In some examples, the client-server network can include an SDN-enabled network (e.g., a network that can be managed as an SDN). Also, as used herein, a trusted server can include a server within the client- server network that has been identified as safe and/or not corrupt by malicious software.

[0013] In some examples, a suspicious connection request can include a DNS request from a client in the client-server network. DNS is a technology for managing the names of web sites and their internet domains. DNS technology enables users to automatically find entered web addresses on the internet. As used herein, a DNS server can refer to any device (e.g., computer) registered to join the DNS. A DNS server can run special-purpose networking software, can feature a public internet protocol (IP) address, and can contain a database of network names and addresses for internet hosts. Examples of the present disclosure are not so limited, however, and a suspicious connection request can include a request from a client in the client-server network to access a server outside of the client-server network using any protocol (e.g., such as a dynamic host configuration protocol (DHCP), remote authentication dial-in user service (RADIUS) protocol, network time protocol (NTP), lightweight directory access protocol (LDAP), among others).

[0014] The detection engine 103 can detect a suspicious connection request within a network using an SDN rule. As used herein, an SDN rule can refer to a rule (e.g., an Open Flow rule) specified by a user and/or administrator of the client-server network and executed by an SDN controller. An SDN, as will be discussed further herein, can refer to a form of network virtualization in which the control plane (system that makes decisions that affect network traffic) is separated from the data plane (system that moves the network traffic) and implemented as software. The control plane defines how network traffic is handled (e.g., via protocols such as spanning tree, open shortest path first, border gateway protocol, etc.) in a network device. The data plane actually handles the network traffic according to the control plane (e.g., using forwarding tables, routing tables, queues, etc.) in a network device. The control plane may be said to be distributed in a typical network where each network device includes a control plane and a data plane. Thus, in the event of network congestion, each network device may take corrective action largely

independently of other network devices. However, in an SDN, network administrators can have programmable (e.g., centralized) control of network traffic without requiring physical access to the network's hardware devices.

[0015] Open Flow, as used herein, can refer to a communication protocol that gives access to a data plane of a network (e.g., an SDN). Open Flow can enable remote controllers (e.g., SDN controllers) to determine the path of network packets through a network of switches. An Open Flow rule, as used herein, can refer to a rule (e.g., a set of policies and/or instructions) executed by an SDN controller that directs the handling of network packets and/or network traffic.

[0016] The redirection engine 104 can include hardware and/or a combination of hardware and programming to redirect a suspicious connection request to a trusted server within the network. For example, in response to identifying a suspicious connection request from a client in the client-server network, the redirection engine 104 can send the suspicious connection request to a server within the client-server network that is identified as a trusted server. In some examples, the redirection engine 104 can send the suspicious connection request to a pre-configured destination transmission control protocol (TCP) port of a trusted server in the client-server network.

[0017] The response engine 105 can include hardware and/or a combination of hardware and programming to execute a number of actions in response to receiving a redirected suspicious connection request and based on a characteristic of the suspicious connection request. In some examples, the response engine 105 can instruct the trusted server which received the redirected suspicious connection request to execute a number of actions in response to receiving the suspicious connection request. For example, as discussed further herein, the trusted server can execute an intrusion detection system and/or redirect a malicious DNS request to a correct internet protocol (IP) address, among other actions. The particular actions taken by the trusted server in response to receiving a redirected suspicious connection request can be differentiated and selective responses, configured by an administrator and/or user of the client-server network. For instance, the administrator can specify a number of policies that instruct how connection requests of a particular type, connection requests from a particular originator (e.g., a particular client originating and/or generating the connection request), and/or connection requests to access a particular server outside of the client-server network should be handled. A particular type of a connection request can be based on a specific network service. For example for DNS, a type of connection request can include a DNS host lookup request (e.g., a request to resolve a domain and/or hostname to an IP address). In another example, for DHCP, a type of connection request can include a discover request (e.g., a request to obtain an IP address from a DHCP server in the network). Examples of the present disclosure are not so limited, however, and a type (e.g., particular type) of a connection request can include any type of request based on specific services offered by the client-server network. In some examples, an administrator of the client-server network can add a number of protocols and a number of request types to the client-server network using an SDN controller, particularly, using a network service security application embedded in an SDN controller (as discussed further herein).

[0018] In some examples, the response engine 105 can instruct a security application in the client-server network to execute a number of actions in response to receiving a response from a trusted server. For example, as discussed further in relation to Figures 3 and 4, a suspicious connection request can be redirected to a trusted server in the client-server network, the trusted server can process packets associated with the suspicious connection request, and the trusted server can send a response back to a security application within the client-server network. In response to receiving the response from the trusted server, the security application can identify the original request associated with the suspicious connection request, and execute a number of actions to handle the suspicious connection request. The original request can be identified by looking up the source IP address of the client and intended destination IP address in a database (e.g., a database maintained by the security application). For example, the security application can generate and/or display a number of statistics related to the suspicious connection request and/or drop the packet associated with the suspicious connection request, among other actions. Such statistics can be used by administrators of the client-server network to improve security policies and/or prevent future security attacks.

[0019] Figure 2 illustrates a diagram of an example computing device 208 according to the present disclosure. The computing device 208 can utilize software, hardware, firmware, and/or logic to perform a number of functions described herein. The computing device 208 can be any combination of hardware and program instructions configured to share information. The hardware, for example, can include a processing resource 209 and/or a memory resource 21 1 (e.g., CRM, MRM, database, etc.). A processing resource 209, as used herein, can include any number of processors capable of executing instructions stored by a memory resource 21 1 . Processing resource 209 may be implemented in a single device or distributed across multiple devices. The program instructions (e.g., computer readable instructions (CRI)) can include instructions stored on the memory resource 21 1 and executable by the processing resource 209 to implement a desired function (e.g., redirect a suspicious connection request to a trusted server in a network).

[0020] The memory resource 21 1 can be in communication with a processing resource 209. A memory resource 211 , as used herein, can include any number of memory components capable of storing instructions that can be executed by processing resource 209. Such memory resource 21 1 can be a non-transitory CRM or MRM. Memory resource 21 1 may be integrated in a single device or distributed across multiple devices. Further, memory resource 21 1 may be fully or partially integrated in the same device as processing resource 209 or it may be separate but accessible to that device and processing resource 209. Thus, it is noted that the computing device 208 may be implemented on a participant device, on a server device, on a collection of server devices, and/or a combination of the user device and the server device. [0021 ] The memory resource 21 1 can be in communication with the processing resource 209 via a communication link (e.g., a path) 210. The communication link 210 can be local or remote to a machine (e.g., a computing device) associated with the processing resource 209. Examples of a local communication link 210 can include an electronic bus internal to a machine (e.g., a computing device) where the memory resource 21 1 is one of volatile, non-volatile, fixed, and/or removable storage medium in communication with the processing resource 209 via the electronic bus.

[0022] A number of modules 213, 214, 215 can include CRI that when executed by the processing resource 209 can perform a number of functions. The number of modules 213, 214, 215 can be sub-modules of other modules. For example, the detection module 213, the redirection module 214, and the response module 215 can be sub-modules and/or contained within the same computing device. In another example, the number of modules 213, 214, 215 can comprise individual modules at separate and distinct locations (e.g., CRM, etc.).

[0023] Each of the number of modules 213, 214, 215 can include instructions that when executed by the processing resource 209 can function as a corresponding engine as described herein. For example, the detection module 213 can include instructions that when executed by the processing resource 209 can function as the detection engine 103. In another example, the redirection module 214 can include instructions that when executed by the processing resource 209 can function as the redirection engine 104.

Additionally, the response module 215 can include instructions that when executed by the processing resource 209 can function as the response engine 105.

[0024] Figure 3 illustrates an environment 320 for redirecting connection requests in a network according to the present disclosure. The environment 320 can include a client-server network (e.g., a cloud network) 330 that allows end recipient computer systems (e.g., thin clients, portable computers, smartphones, desktop computers, etc.) to access a pool of hosted computing and/or storage resources (e.g., the cloud resources) and virtual network services over a physical network (e.g., a private intranet and/or the public Internet). In some examples, the client-server network can include an SDN- enabled network (e.g., a network that can be managed as an SDN). That is, the environment 320 can include an SDN enabled client-server network (e.g., an SDN). An SDN can include a form of cloud virtual ization in which a control layer 322 (e.g., a sub-system that makes decisions that affect cloud traffic) is separated from an infrastructure layer 323 and is implemented as software. The control layer 322 can define how cloud traffic is handled (e.g., via protocols) in a number of devices.

[0025] As illustrated in Figure 3, the environment 320 can include an application layer 321 , a control layer 322, and/or an infrastructure layer 323 in the network 330 (e.g., in the SDN). The application layer 321 can include a number of applications (e.g., programs) 328-1 , 328-2, 328-R that

communicate cloud requirements and/or desired cloud behavior to the control layer 322. Although security application 327 is depicted in Figure 3 as embedded in controller 302, security application 327 is also an example application in the application layer 321 . Applications in the application layer 321 can be implemented by the controller 302 and/or be implemented by other computing devices that interface with controller 302. The application layer 321 can communicate with the control layer 322 via an application programming interface (API). As used herein, an API can include a set of routines, protocols, and/or tools that accomplish a specific task and/or are allowed to interact with a specific software component. In some examples, the application layer 321 can communicate with the control layer 322 via a representation state transfer (REST)ful API. REST can include an architectural style that abstracts architectural elements within a distributed hypermedia system that ignores the details of component implementation and protocol syntax in order to focus on the roles of components, the constraints upon interaction with other

components, and interpretation of significant data elements. A RESTful API can include a web API implemented using hypertext transfer protocol (HTTP) and REST principles as a collection of resources. However, examples are not so limited, and the application layer 321 can communicate with the control layer 322 using other APIs and/or protocols.

[0026] The control layer 322 can translate requirements provided by the application layer 321 to the infrastructure layer 323. Further, the control layer 322 can include a controller (e.g., an SDN controller) 302 to communicate between the application layer 321 and the infrastructure layer 323. The SDN controller 302 can be hardware and/or software. A hardware SDN controller 302 can include a processing resource in communication with a memory resource. The memory resource can include instructions, executable by the processing resource to perform a number of functions described herein. In some examples, the SDN controller 302 can be a discrete device, such as a server.

[0027] Also, as illustrated in Figure 3, the environment 320 can include a network service security application (e.g., a security application) 327 embedded in the controller 302, (or implemented by one or more other computing devices interfacing with controller 302), and a number of servers 324-1 , 324-2, 324- N (referred to herein as servers 324). The infrastructure layer may include various network devices, such as switches, routers, bridges, wireless access points, and the like, for connecting the servers 324 together in a network. The network service security application 327 can include hardware and/or software to maintain a table of outstanding suspicious connection requests (e.g., suspicious connection requests that have not yet been processed by a trusted server and/or have not yet been resolved by the network service security application). In some examples, the network service security application 327 can maintain a number of controlled (e.g., user and/or administrator

configurable) policies that direct how particular suspicious connection requests should be handled.

[0028] Each of the number of servers 324 can include a number of agents. As used herein, an agent refers to a component of a server that relays messages between the cloud controller 302 and the server and performs a specific network service. For example, each of the number of servers 324 can include an agent that performs the services of at least one of an IP address agent, a switching agent, and/or a routing agent. Multiple instances of these agents could be running on each server, however, each agent can be

connected to only one cloud controller 302.

[0029] Also, as illustrated in Figure 3, the environment 320 can include an outside network 329. The outside network 329 can include a number of servers outside of (e.g., external to) the client-server network 330. For instance, the outside network 329 can include a plurality of private, public, academic, business and/or government networks, each including a plurality of computing devices and/or servers. For instance, the outside network 329 can refer to the Internet. As discussed further herein, servers 324 within the client-server network 330 can request access to servers in the outside network 329.

[0030] Figure 4 illustrates a flow chart of a method 440 for redirecting connection requests in a network according to the present disclosure. At 441 , the method 440 can include detecting a suspicious connection request. For example, a client in a client-server network (e.g., network 330 illustrated in Figure 3) can request access to a server outside of the client server network (e.g., the client can request access to a server in outside network 329 illustrated in Figure 3). In some examples, detecting a suspicious connection request can be executed using the detection engine 103 and/or the detection module 213, illustrated in Figures 1 and 2, respectively. A suspicious connection request can include a non-standard connection request. A suspicious connection request can be identified using a set of rules stored in the network service security application (e.g., security application 327 illustrated in Figure 3). These rules (e.g., the set of rules) can be installed in switches using Open Flow and can be executed to redirect client connection requests. As used herein, a switch refers to a network device that is used to connect devices in a network. A switch can provide on the wire communication between devices as well as command messages between different components illustrated in Figure 3.

[0031 ] The set of rules can specify servers that are considered safe (e.g., trusted and/or standard) servers, and servers that are not-considered safe (e.g., not trusted and/or non-standard). For example, a connection request received from a client requesting access to a server not included on a list of trusted servers could be identified as a suspicious connection request. Similarly, a connection request received from a client requesting access to a server included on a list of trusted servers would not be identified as a suspicious connection request and would be allowed to process normally (e.g., without special processing). In some examples, the set of rules can be executed by Open Flow and/or a controller (e.g., SDN controller) in the client-server network. For instance, an administrator of the client-server network (e.g., of the SDN) can create a set of rules (e.g., open flow security rules) that identify criteria which can be used by the SDN to identify suspicious connection requests.

[0032] At 442, the method 440 can include redirecting the suspicious connection request to a trusted server. Redirecting the suspicious connection request to a trusted server can include executing a set of rules (e.g., Open Flow redirection rules) that identify a number of trusted servers that are configured to receive and/or process suspicious connection requests. For example, in response to identifying a particular connection request as a suspicious connection request, the suspicious connection request can be sent (e.g., redirected) to a trusted server in the client-server network (e.g., servers 324 illustrated in Figure 3). In some examples, in response to identifying a particular connection request as a suspicious connection request, the suspicious connection request can be redirected to a non-standard but pre-configured destination TCP port of the trusted server. For instance, an administrator can configure a particular port on a trusted server (e.g., server 324-2 illustrated in Figure 3) within the client-server network as a designated port for receiving suspicious connection requests.

[0033] In an example, whenever a connection request is identified as going to a server other than a trusted server, a switch in the client-server network can redirect the traffic to a trusted server in the client-server network. As used herein, a trusted server can refer to a server included in the client- server network. For example, a trusted server can include a DHCP server, a file transfer protocol (FTP) server, a groupware server, an internet relay chat server, a list server, a mail server, and/or a web server among others, included in the client-server network. [0034] In some examples, the method 440 can include detecting suspicious connection requests that arrive at a non-standard port designated for a protocol to handle connection requests identified as suspicious connection requests. For example, for DNS, the internet assigned numbers authority (IANA) assigned port is 53. Connection requests identified as suspicious connection requests can be sent to the user datagram protocol (UDP) port 5300. For example, for DNS, suspicious connection requests can be sent to a port other than the IANA assigned TCP port number for DNS, 53, so the trusted server can be alerted to the fact that it is a suspicious connection request and thereby can process the suspicious connection request in a customized (e.g., differently than normal) manner.

[0035] A copy of the suspicious connection request can also be sent to a relevant SDN application (e.g., a security application 327 illustrated in Figure 3) within the client-server network. For instance, as discussed in relation to Figure 3, the client-server network can include an SDN-enabled network (e.g., a network that can be managed as an SDN), and can therefore include an SDN controller. A suspicious connection request can be sent to a network service security application on an SDN controller for subsequent handling. The network service security application can maintain a table of outstanding suspicious connection requests (e.g., suspicious connection requests that have not yet been resolved and/or responded to), including details about the original request that was subsequently identified as a suspicious connection request, such as the source IP address, original destination IP address and/or source port. For example, a connection request identified as a suspicious connection request can be redirected to a trusted server within the network, sent to a network service security application, and recorded in a table of suspicious connection requests stored in the network service security application until appropriate actions have been taken.

[0036] At 443, the method 440 can include executing a set of actions in response to a trusted server receiving a suspicious connection request, and based on a characteristic of the suspicious connection request. As used herein, a characteristic of a suspicious connection request can include a type of request, an identifier identifying the originator of the request, and/or any other feature that may identify the suspicious connection request. In other words, once a suspicious connection request is delivered to a trusted server, the trusted server can take a set of actions based on the request type and/or originator of the suspicious connection request. Examples of actions can include resolving the suspicious connection request to a correct DNS server. In an example, a suspicious connection request, instead of connecting a client to the legitimate IP address associated with www.examplelPaddress.com, can connect the client to an IP address associated with a malicious site. In response to identifying that the connection request is a suspicious connection request, the trusted server can take an action to connect the client to the correct IP address associated with www.examplelPaddress.com.

[0037] Another example of an action that a trusted server can take in response to receiving a suspicious connection request, can include executing an intrusion detection system, program and/or processes that monitor network or system activities for malicious activities or policy violations. Examples of the present disclosure are not so limited, however, and actions taken by the trusted server in response to receiving a suspicious connection request can vary based on a protocol executed by the particular trusted server. For instance, actions taken by a DNS server can differ from actions taken by a DHCP server.

[0038] At 444, the method 440 can include sending the suspicious connection request back to the network service security application on the SDN controller (e.g., the trusted server can send a response to the network service security application). The suspicious connection request can be sent back to the network service security application by an access switch in the client-server network. The trusted server can send a response to the network service security application, and the network service security application can look up the suspicious connection request in the table of outstanding suspicious connection requests. The trusted server can format a response with a correct (e.g., appropriate) response to the particular suspicious connection request. For example, if a connection request (e.g., a connection request received from a client in the client-server network) and/or a suspicious connection request is a request for the IP address of a website such as examplelPaddress.com (e.g., when the connection request is a DNS lookup request), the trusted server can respond to the connection request with the authoritative IP address of examplelPaddress.com. If the suspicious connection request was for a malicious web site like examplemalicioussite.ru, the trusted server can respond with a properly framed response that denies access to malicious websites. The network service security application can then identify the original connection request based on the response received from the trusted server and can execute a list of actions, controlled by policies configured on the network service security application.

[0039] For example, a network service security application (e.g., a security application, illustrated as item 327 in Figure 3) can identify an original request that generated a redirection to the trusted server. Once the network service security application has identified the original request associated with the redirection (e.g., the original request that was subsequently determined to be a suspicious connection request by a set of rules executed by the SDN), the network service security application can execute a number of actions to handle and/or resolve the suspicious connection request. For instance, the network service security application can change the value of the IP address associated with the suspicious connection request to the original (e.g., legitimate and/or not malicious) IP address. That is, the correct IP address of the originally requested destination will be sent to the requester (e.g., to the client). In another example, the network service security application can generate and/or display for a user, statistics about how many connection requests similar to the identified suspicious connection request (e.g., that share a common characteristic) have been received. In another example, the network service security application can generate and/or display statistics identifying where suspicious connection requests are going (e.g., what servers they were attacking). In some examples, the network service security application can block a port on a server associated with particular suspicious connection requests, and/or drop a number of packets associated with the suspicious connection request. [0040] In the present disclosure, reference is made to the accompanying drawings that form a part hereof, and in which is shown by way of illustration how a number of examples of the disclosure can be practiced. These examples are described in sufficient detail to enable those of ordinary skill in the art to practice the examples of this disclosure, and it is to be understood that other examples can be used and that process, electrical, and/or structural changes can be made without departing from the scope of the present disclosure.

[0041 ] The figures herein follow a numbering convention in which the first digit corresponds to the drawing figure number and the remaining digits identify an element or component in the drawing. Elements shown in the various figures herein can be added, exchanged, and/or eliminated so as to provide a number of additional examples of the present disclosure. In addition, the proportion and the relative scale of the elements provided in the figures are intended to illustrate the examples of the present disclosure, and should not be taken in a limiting sense. As used herein, the designators "N", "P", and "R", particularly with respect to reference numerals in the drawings, indicate that a number of the particular feature and/or component so designated can be included with a number of examples of the present disclosure. The designators "N", "P", and "R" can refer to a same feature and/or component, or different features and/or components.

[0042] As used herein, "logic" is an alternative or additional processing resource to perform a particular action and/or function, etc., described herein, which includes hardware, e.g., various forms of transistor logic, application specific integrated circuits (ASICs), etc., as opposed to computer executable instructions, e.g., software firmware, etc., stored in memory and executable by a processor. Further, as used herein, "a" or "a number of" something can refer to one or more such things. For example, "a number of widgets" can refer to one or more widgets. Also, as used herein, "a plurality of" something can refer to more than one of such things.

[0043] The above specification, examples and data provide a description of the method and applications, and use of the system and method of the present disclosure. Since many examples can be made without departing from the spirit and scope of the system and method of the present disclosure, this specification merely sets forth some of the many possible embodiment configurations and implementations.

Claims

What is claimed is:

1 . A system, comprising:

a detection engine to detect a suspicious connection request within a network;

a redirection engine to redirect the suspicious connection request to a trusted server within the network; and

a response engine to execute a selective action in response to receiving the redirected suspicious connection request, and based on a characteristic of the suspicious connection request.

2. The system of claim 1 , the detection engine to detect a suspicious connection request within a network using a software defined network (SDN) rule.

3. The system of claim 1 , wherein a suspicious connection requests includes a request from a client in a client-server network to connect to a server not identified on a list of trusted servers.

4. The system of claim 1 , including the response engine to execute a selective action in response to receiving the redirected suspicious connection request and based on a characteristic of the suspicious connection request, wherein the selective response includes the response engine instructing the trusted server to execute an intrusion detection system based on the characteristic.

5. The system of claim 1 , including the response engine to execute a selective action in response to receiving the redirected suspicious connection request and based on a characteristic of the suspicious connection request, wherein the selective response includes the response engine instructing a security application on a controller in the client-server network to generate a number of statistics related to the suspicious connection request.

6. A non-transitory computer readable medium storing instructions executable by a processing resource to cause a computer to:

detect a suspicious connection request within a software defined network- (SDN) enabled network; and

redirect the suspicious connection request to a trusted server within the network and send a copy of the suspicious connection request to a network service security application on an SDN controller in the SDN-enabled network; and

execute, using the network service security application, a selective action in response to receiving the redirected suspicious connection request and based on a characteristic of the suspicious connection request.

7. The non-transitory computer readable medium of claim 6, including instructions executable to identify an original connection request associated with the suspicious connection request using a table of outstanding suspicious connection requests stored in the network service security application.

8. The non-transitory computer readable medium of claim 6, wherein the selective action includes compiling statistics identifying originators of suspicious connection requests.

9. The non-transitory computer readable medium of claim 6, wherein the selective action includes blocking a port on a server associated with the suspicious connection request.

10. A method, comprising:

detecting a suspicious connection request in a software defined network- (SDN) enabled client-server network;

redirecting the suspicious connection request to a trusted server in the SDN enabled client-server network; sending a copy of the suspicious connection request to a network security application on an SDN controller in the SDN-enabled client-server network;

executing, using the trusted server, a number of selective actions in response to the trusted server receiving the suspicious connection request, and based on a characteristic of the suspicious connection request; and

sending a response back to the network security application including information about the number of actions taken.

1 1 . The method of claim 10, wherein detecting suspicious connection requests includes executing a set of open flow security rules created by an administrator of the SDN which identify criteria to identify suspicious connection requests.

12. The method of claim 10, wherein redirecting the suspicious SDN connection includes executing a set of Open Flow redirection rules.

13. The method of claim 10, wherein the suspicious connection request includes a request to access a domain name system (DNS) server.

14. The method of claim 10, including sending a copy of the suspicious connection request to a security application within the SDN-enabled client- server network.

15. The method of claim 10, wherein the characteristic of the suspicious connection request includes an identifier identifying an originator of the suspicious connection request.