Author Topic: HOWTO: Deflect a "perfect" get flood using scripted IE DLLs  (Read 962 times)

Offline TheOracle

  • Hero Member
  • *****
  • Posts: 152
  • Karma: 18
HOWTO: Deflect a "perfect" get flood using scripted IE DLLs
« on: February 19, 2008, 12:17:57 PM »
If you are very familiar with the NS, you know that the NS is excellent at deflecting a SYN flood attack, and it has a mechanism called HDOSP to detect and deflect scripted bot attacks.  The means it does this is by challenging clients to perform a javascript computation, and when it can present a cookie with the proper answer, then it gives preference to the client over other clients that are queued up.  What happens when a get flood is initiated by a bot net that is using IE via DLL's, which make it able to answer the challenge?  Then it becomes a little harder, and you can use the fact that it IS perfectly acting as a client to expose itself for what it is, a bot.

The high level view of the attack deflection is this:  If the bot is using IE to perform the attack then cookies issued to the client will be processed in a normal way.  If they were not, then other mechanisms could be used to detect the client, so we won't go into them here.  As such, the key is to use the client against itself--use cookies to detect the malicious behavior, track it, and eventually to use the client's behavior to slow itself down and reduce the intensity of the attack.  For this example, we will be tracking users that make queries to the "/" page twice in two seconds.  If flagged twice for doing this (so three times in two seconds overall) they will be flagged as a bot, and their requests redirected to a non-existent domain, which should cause IE to do timeouts each time it is redirected.  If the bot is scripted to generate requests "as fast as it can" in a single threaded manner, then this will result in a significant slowdown.

Now for the example:

# check if no cookies, then add “set-cookie” with a timeout of 1 second for the URL
add rewrite action FastClient1 insert_http_header Set-Cookie "\"fastclient=1;Max-Age=1;Version=1\""
add rewrite policy testFastClient1 "http.REQ.URL.EQ(\"/\") &&  HTTP.REQ.HEADER(\"Cookie\").EXISTS.not" FastClient1 NOREWRITE

# if you get this, update it with the value of 2, and set a timeout of 1 again
add rewrite action FastClient2 insert_http_header Set-Cookie "\"fastclient=2;Max-Age=1;Version=1\""
add rewrite policy testFastClient2 "http.REQ.URL.EQ(\"/\") && HTTP.REQ.cookie.VALUE(\"fastClient\").EQ(\"1\")" FastClient2 NOREWRITE

# ok, the client is a bot, it requested / twice in two seconds, flag it as a bot in the response…
add rewrite action BotClient insert_http_header Set-Cookie "\"botclient=true;Max-Age=3600;Version=1\""
add rewrite policy isBotClient "HTTP.REQ.cookie.VALUE(\"fastClient\").EQ(\"2\")" BotClient NOREWRITE

# now redirect the client on any request to an invalid domain to slow it down
add responder action redirectBotClient redirect "\"http://www.domaindoesnotexist.com\""
add responder policy redirBotClient "HTTP.REQ.COOKIE.VALUE(\"botClient\").EQ(\"true\")" redirectBotClient NOOP

bind lb vserver test_vsvr -policyName redirBotClient -priority 50 -gotoPriorityExpression END
bind lb vserver test_vsvr -policyName testFastClient1 -priority 110 -gotoPriorityExpression END -type RESPONSE
bind lb vserver test_vsvr -policyName testFastClient2 -priority 120 -gotoPriorityExpression END -type RESPONSE
bind lb vserver test_vsvr -policyName isBotClient -priority 130 -gotoPriorityExpression END -type RESPONSE

alternatives to redirection is to use content switching to direct the client to a service with a small client connection limit, so that while the responses will be generated, the NS will queue them up and be very slow to reply, throttling the attack.

If the client doesn't honor cookies, then you can setup a simple redirect that issues a cookie, and don't let any clients to your actual servers without a cookie header.  Another approach would be to issue two cookies, one a session cookie and one a one second timeout cookie.  When replying, reply with an HTTP Meta refresh of two seconds.  As a refresh should generate a request with both a referer header and the session cookie, but NOT the cookie value that expired, it can be used as a nice challenge to clients before delivering them content.

The Oracl

Offline TheOracle

  • Hero Member
  • *****
  • Posts: 152
  • Karma: 18
Someone questioned what this does different than HDOSP.  First off, what does HDOSP do?  It operates by selecting transactions that have been put in the surge queue (as a sample) and replying with content that includes a javascript that is to be executed.  This javascript will set a cookie based on the results of a math operation, and the resulting cookie will give preferential treatment when the requests hit the surge queue, i.e. they will be prioritized.  The script provided will intercept requests before such a situation can occur, and force the cookie to exist before be passed to the back-end processing.  At the same time, it will detect if the same URL is being hit by the browser too often, and will flag them as a bot when they do.

The Oracle