Most of the «attacks» on IT-services these days are mostly with DDoS (Disitributed Denial of Service) which is basically a flood of traffic headed to a particular network service.
Think of it this way, if a person says hi to you, you say hi back. This is much like a regular TCP handshake (SYN, SYN ACK, ACK) what happens if a crowd like this happened to yell hi at the same time, multiple times each second ?
Well first of the network traffic is going to get flooded with a lot of bogus traffic and your services might have trouble responding to the traffic. When the group anonymous were active, they targeted large companies like PayPal and Visa with their DDoS attacks.
And regular people could follow in as well, using a tool called LOIC (Low Orbit Ion Cannon) which allowed for several types of DDoS attack (TCP, UDP or HTTP) which have different effect on their targets.
So back to the topic, how can companies protect themselves against these type of attacks?
In most of the cases, the flooded traffic causes a jam in the network and not affecting the backend servers much, not much you can do in those cases.
In cases where the incoming bandwidth is not an issue, the backend servers are much more affected.
I’ve done some testing on a SharePoint site on a Windows Server 2012 IIS (on a VM) and seen how much a single computer using LOIC (On the same LAN for that matter) can affect a web server.
LOIC is pretty simple, enter a IP-address and chose method of attack and you are good to go.
Now if you open WireShark on the target you can see that the network is being spammed with TCP packets (which contain the payload in the message)
How does this affect our performance on the server?
I have done some testing with all the types.
HTTP-attack (Which uses the HTTP GET command)
uses the most CPU (Upwards to 90%) on the endpoint (And is uses more bandwidth responding to the reply then the other attacks)
TCP-attack (Uses the more network traffic, but has a minor impact on the CPU on the backend)
UDP-attack (uses more bandwidth since it is not trying to handshake like regular TCP) so therefore the network is getting more pounded (you can see under the receiving part it’s about to 250 Mbps.
And because of the huge load on the NIC the CPU is also making some extra effort.
So what other types of DDoS attacks can be used?
We have the typical SYN-flood attack, which is typical, used when an attacker uses multiple spoofed IP-addresses and floods a server with multiple SYN packets.
And therefore leaving with half-open connections.
We also have Smurf Attacks, which uses spoofed ICMP packets and sends ping requests to the broadcast IP-address and the reply to address is set to the target.
And then we have other L7 DDoS attacks like Slowloris.
So how can we use Netscaler to mitigate these type of attacks?
SYN Flood using TCP:
This protection feature is enabled by default, instead of having half-open connection with the end-client, the Netscaler appliance sends out an SYN cookie to the end-user, so it does not waste memory on half-open connections. It only uses memory when it receives the final ACK packet.
Surge Protection:
Can be used to define how many TCP-connections a server can manage before It stops dropping requests (This is typical behavior during a DDoS attack and may leave regular users unable to login to a service)
You can enable / disable this option for each service
You can also define a thresholds for each service in terms of bandwidth and / or clients
Sure Connect
Allows you to define a alternative web page or a custom web page (In case the network is full and the back-end servers are unable to process requests )
HTTP DOS Protection
Regular clients using browsers like Firefox, IE or Chrome can understand HTML, JavaScript and cookies. Using attack tools like LOIC or other HTTP DDoS tools you cannot parse this type of data.
So you can define that when HTTP clients try to connect to a service they need to respond to a JS challenge which is sent with the HTTP data.
This can also be done on a pr service level.
So with these parameters I just set (If there are more than 200 clients in queue, the next 100% of these requests will be sent a JS challenge, if it responds with the correct cookie to the respons it is a valid client)
And last but not least in case of the UDP traffic (If you don’t have any services that use UDP you should just block it using ACLs.
add ns acl restrict DENY –protocol UDP (or restrict by ports)
In case of SMURF attacks, this is something that you should do a the router level (In case you have cisco)
no direct ip-broadcast