This is a thread for collecting possible ways for online casinos to defend against DDoS attacks.

I've called the particular attention of Dublinbet to this thread.

Server separation:

The first counter-measure is to separate entry-points.

One to serve public traffic: www.casino.com

Another one to serve customer traffic: i.e. www.casino-users.com

It starts from here.

Customer server IP validation:

Each customer is given an authentication key in addition to their username and password.

The customer server is set to drop all GET/POST requests from all first-time IPs.

The customer server validates IP address by a modified HEAD request with a "Key" field added.

HEAD /auth HTTP/1.1
Host: www.casino-users.com
Key: 123AUTHXYZKEY

---

If the authentication key doesn't match that of an user, no response is sent back (the server seems "dead" to an attacker).

A "double-up" punishment in minutes is imposed in between failed requests from the same IP (1st try = 1 minute delay, 2nd try = 2 minutes delay, 3rd try = 4 minutes delay, 4th try = 8 minutes delay... Human users can wait such times reasonably, bots attempting to overload are thwarted with such long mandatory delays in computer time).

---

Only if a valid Key is authenticated, the originating IP is white-listed and the server behaves as usual with this validated IP, transferring regular data for the games, lobby, cashier, etc.

Authentication possibilities:

Casinos via downloads can implement the validation "handshake" passing the Key straight from their software by opening a socket.

Web-based casinos can authenticate IPs via a small java applet.

---

Another interesting possibility under an alternate protocol is for users to authenticate their IP via email.

By sending each user an email with their authentication key as subject, users can forward this particular email to an email such as auth@casino.com.

On reception, the email sender (from:) is inspected, if matching the email from a customer, then the subject is scanned for that customer's key.


If there is a valid key in the subject, email headers are scanned and the IP originating the email is white-listed for regular further traffic at the customer server.

All emails featuring a non-valid data are discarded.

Some person on here who is not from the USA needs to notify Dublin of this thread.

Possible countermeasures for the public server:

When under a suspicious traffic spike switch to defense mode.

- Implement a 1 IP => 1 USER policy.

- Drop HTTP1.0 support for everything but known search engine spiders, only use connections via HTTP1.1 for all regular users.

- Split the process of serving site contents in two stages, forcing the use of client-side processing power:

1) When receiving a request from a new IP, tie this new IP to a non-intuitive random path such as: casino.com/f5e3415162657ac2238f2455273443ce/index.htm

2) As a response to this request, send an HTML page with the random path encrypted in such a way the client must incur in a local brute-force attack to decrypt the path in plain text.

Transfer only three lines of text containing:

Remote inclusion
Control string
Cyphertext string

Example:

<script src="http://random-cdn-server.com/crypt.js"></script>
<script>var control = "a43c5d8a9a07d6ecd";
var cypher = "59f3cc05eb3d8ca5d857372e3eafbb033e3a671bfdac876c;</script>

The control algorithm must be one resembling Vigenère cipher where a wrong try still gives a response in the form of text. This way there is no sign of a "correct" tell-tale response, unless there is an actual bruteforce attack being launched.

The bruteforce attack function is invoked by the onload Event.

The result of each try of the brute-force attack must be compared against the control string. On a successful match, the input string from the current successful try is used as a key to decrypt the cyphertext string, which results in the correct path to redirect the user to via invoking self.location.

The cypher algorithm can be one of the many implemented in Javascript already. The more processing power required by the implementation, the better for our purposes.

---

This brute-force attack stresses the attackers servers instead of the casinos.

The casino is the one boasting to run an efficient ship on little resources (merely a single GB of ram costing a fiver can host thousands upon thousands of valid client keys).

Obviously in order to avoid 1-on-1 rainbow table attacks proper "salting" must be performed. Vigenere is used as an illustrative example.

By responding only with tiny snippets of data back, bandwidth usage is greatly reduced, therefore actual clogging of the connection pipes which could timeout customers is made exponentially difficult to the attackers (Regular content response from an HTML page is humongous when comparing to the mere 3 lines of response as pointed here).

Furthermore, by forcing the attackers to be the ones to incur in the processing load in order to be entitled to the regular larger chunks of data for their purposes, you effectively deny their power of using a single machine to get loads of data "upfront". Even if they use a plethora of remote proxies, processing power must still be incurred by them, which inevitably becomes a burden to the attackers.

Even if they use proxies, they still need to incur in spending processing power. The more IPs incurring in the attack, the more processing to be immediately demanded from the attackers to get anything else but tiny data snippets.

Some extra comments:

An in-memory database setup can be used to look-up keys to be lighting fast and preventing disk reads.

Since the remote java-script file is static any amount of random servers in a content delivery network can be used.

At any point of the serving chain multiple servers can be used to distribute load as it's accustomed.

Special-case users such as known paid proxies can request an exception. In every case, the casino should be able to pin-point the culprit if an exempted special case user becomes an abuser.

Just got response from Dublinbet!


They forwarded this thread to management.

Could you please sum up in a paragraph what's going on here VLS : )

Quote from: AMK on April 23, 2013, 08:51:19 PM
Could you please sum up in a paragraph what's going on here VLS : )

Just posting some ideas in the open here, nothing more.

---

OK, update on response: I was explained by Geoff from dublinbet support it isn't a matter of implementing it at the server level, but further "up the line", at the backbone carrier and network provider level.

So, realistically, we can expect nothing new to be implemented. Same ol' same ol' lines of defenses

The backbone people need to get some backbone!

More radical ideas can be considered such as fully decentralizing the service and giving a different entry-point domains to separate groups of users. i.e. by country or by service level demand.

Some "heavy" users can even be granted their own personal server to get relayed video.

I think even if they add the charge of hiring a Virtual Private Server for those customers willing to have uninterrupted service, people who want to continue enjoying the video feed and smooth service will agree to cover the extra fee. The IP from the hired server is obviously white-listed, so customers connect to this personal server instead of the centralized one.

The casino needs to "move chips" in order to stay in business. They certainly should be seeking to decentralize things. An obvious path to counteract a single broadcasting point with a public address is to use several carriers and use several rebroadcasting servers across the globe, concealing the internal communication paths to the public.

It definitely wouldn't hurt to have mirror servers in several parts of the world. The goal is for them to  always have some active users "moving chips". Players want uninterrupted action, casinos are wise to be evaluating all options, including the creation of mirrors, to fulfill their players.