Zero window, SSL renegotiation attacks, and so on, can be prevented using NetScaler. Even with simple ACLs, Citrix NetScaler has the ability to use ACLs on the fly for every new ACL added and need not wait for new sessions to trigger the ACL.
NetScaler provides end-to-end web security along with the APP Firewall module; the module can be used as a standalone or be integrated with NetScaler, and be used along with all the other features.
Half-open TCP SYN connections are what constitute a DOS attack. A half-open TCP connection (as shown in next image) is a state wherein it is stuck before the three-way handshake is completed (SYN-SYN/ACK-ACK). NetScaler defends such attacks by not allocating any memory for all the SYN requests hitting NetScaler. Instead, it sends a cookie to each client that requests the connection and allocates memory only after the FINAL ACK message containing the same cookie is received. While NS uses this mechanism of inserting cookies into the new TCP connections, the old ones are not interrupted.
This DOS attack prevention does not need anything to be explicitly enabled:
Brute force, slow post, and zero window attacks can be stopped on NetScaler with the help of the rate-limiting feature. Priority queuing can also be used to defend against DOS attacks:
The preceding screenshot shows the zero-window packet in wireshark and legitimate clients in cases where the receive buffer is full and will send zero-window packets to the sender. How does NetScaler differentiate between a legit and an attack? This depends upon the number of concurrent small-window connections at a time and also on the MSS size (DDOS). The defense mechanism kicks in when the number of concurrent small-window connections are more than the number configured. If the attack has less than the number of simultaneous connections configured, then there is the zombie cleanup that kicks in when the connections move to the re-use pool.
TCP/UDP flood protection is enabled by default; however, the HTTP DOS protection feature has to be enabled and policies have to be defined if you need it customized. To enable the HTTP DOS feature, use the following:
root@ns>enable ns feature HttpDoSProtection root@ns> add dos policy httpdospol -DoS -qDepth 30
This policy can be bound to any HTTP services that need protection. While configuring the services, Max Client and Max Request should be set to confine the number of client connections to the Vserver and the number of requests on one persistent connection to the backend server.
Simple and Extended ACLs:
The packet flow would begin with simple ACL (if configured) and then move on to extended ACLs. The ACL action can be
ALLOW,DENY, andBRIDGE. The final action is bridging the packet without processing it. The implicit action of NetScaler, if it does not find any matching IP address, is to process the packet normally; when the ACL misses it, the counter would increment.Simple ACL:
add ns simpleacl packtacl DENY -srcIP 10.122.23.40 -destPort 1494 –protocol TCPExtended ACL:
add ns acl extpacktacl DENY -srcport 80-1024 -destIP 192.168.1.1 -protocol TCP root@ns>flush simpleacl -estSessions
The traffic that hits the ACLs can be logged with the
[–logState option ENABLED]command.There is also an option to flush existing established connections after new ACLs are configured:
root@ns>flush simpleacl -estSessionsRate-limiting can be done based on certain URL or client SRC IP addresses. Care must be taken to avoid mixing attacks with connections that come from behind a single IP address (that is, a proxy). To reduce any false positives, we can configure both
Client.IPandHTTP REQin the limit identifier.thresholdspecifies the number of requests before the defense mechanism kicks in.root@ns>add ns limitSelector httpdos_limit_sel client.ip.SRC root@ns>add ns limitIdentifier httpdos_limit_ident -threshold 1000 -timeSlice 120000 -mode REQUEST_RATE -limitType SMOOTH -selectorName httpdos_limit_sel
This configuration can be fine-tuned more by setting the action that NetScaler takes for the DOS attack:
root@ns> add responder policy httpdospol "HTTP.REQ.URL.CONTAINS("www.packttest.com") && SYS.CHECK_LIMIT(\"httpdos_limit_ident\")" RESET
This responder policy can be bound globally. According to this policy, NetScaler would reset all the connections that come within the time interval. This reset action can also be changed to log a message to the user that says the limit has been reached and try again later:
root@ns>add responder action dos_act respondwith "\"Exceeded the maximum number of retries\r\n\r\n\""
Priority queuing of NetScaler helps in defending against DOS attacks by prioritizing the traffic hitting NetScaler; this can be done by filtering the traffic according to certain criteria and then prioritizing it. At a maximum, three priority queuing policies can be bound to a load-balancing Vserver. While configuring priority queuing, the priority, threshold, and weight needs to be specified along with an implicit action.
Each priority queuing policy can be set based on priority and weight:
>add pq policy packtPQpol -rule HTTP.REQ.URL.CONTAINS("/networktest") -priority 1 -weight 30 [-qDepth <positive_integer> | -polqDepth <positive_integer>]
This policy will filter traffic based on URLs that contain networktest, give it priority 1, and assign a weight of 30. Weight should be set for efficient functioning, because without weights only the higher priority requests will continue getting served and the lower priority requests will be kept on the back burner. To avoid this situation, we go for weighted queuing where, for example, the three important departments in an organization—Engineering, IT, and Finance—can be configured as follows for serving traffic with priority queuing:
Engineering: Priority 1-Weight 30 IT : Priority 2-Weight 20 Finance : Priority 3-Weight 10
From this configuration, after 30 requests have been served in Engineering, the packet flow will move on to serve 20 requests of IT, and so on in a cycle. This way, the Finance department is not completely ignored until there is nothing to serve for Engineering and IT.
From the preceding CLI command, we see an option to specify either queue depth or policy queue depth; the difference between the two is that the first option specifies the value of the total number of requests waiting to hit a particular vserver to which the policy is bound, and the latter specifies the total number of waiting clients belonging to the policy.
The HTTP DOS policies are also configured with something called qdepth and client detect rate. The queue depth, as mentioned before, would be the maximum number of connections placed in the surge queue at a time and the client detect rate would be the percentage of traffic before which the HTTP DOS policy should be applied.
Note
While setting qDepth for HTTP DOS, care should be taken to see that the qdepth value is more than the window size.
Even for the client detect rate option, please note that an optimum percentage should be chosen for sending the JavaScript challenge responses. If the percentage is too high, it would flood the upstream routers or switches.
Distributed denial-of-service (DDOS) attack gets past the initial stages of defense, because it sends the complete HTTP header intact with all the information necessary to the server and then slows down, sending a few bytes per few seconds. Priority queuing can help in avoiding these attacks.
Before implementing any DOS protection, it is safe to monitor the traffic characteristics and so on. Also, instead of just enabling the DOS protection feature, and so on, and leaving it at default, it is recommended to fine-tune the setting according to your network topology.