Thanks for sharing!
Our members are dedicated to PASSION and PURPOSE without drama!
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
#1007
Off-topic / Re: ATM ROULETTE
April 30, 2013, 03:54:26 PMATM Roulette, it's a new game at all ATMs globally:
http://www.nowpublic.com/world/atm-roulette-it-s-new-game-all-atms-globally-aliens
#1008
General Discussion / Re: A Serious Bot Question
April 27, 2013, 04:29:10 PMQuote from: ADulay on April 27, 2013, 03:51:16 PMIt is known "bot creators" aren't actively making tutorials But don't worry, you can ask the fellow coders around to assist you on where to look in order to achieve what you need. All the way from reading numbers to placing bets.
If there is a link to a "bot" wiki or something, I'd like to take a look.
Coders are usually a most-helpful bunch.
#1009
General Discussion / Re: You just need one system. If it is published what next?
April 27, 2013, 12:30:03 AMQuote from: TwoCatSam on April 26, 2013, 11:33:32 PMSam, you got it 100% right: the "accepted way to win" a.k.a advantage play doesn't deny the existence of the house edge.
An airplane does not eliminate gravity. It is still there.
[...] aerodynamics overcomes gravity. (Yes, I know it can be proven and demonstrated.)
The unfair payout because of the extra Euro pocket or pockets in the American game is still there; advantage players create a sufficient edge for themselves that prevails the consuming effect of that from the house.
A battle of powers if you will.
You don't need to stop the river's stream to move up the riverbed, you need to row strong enough to move up.
You are in no way or fashion denying the existence of the stream, you are effectively negating its effect, so bravo for being sharp on your appreciation.
In this game we can't eliminate dispersion nor the house edge, we can only apply all of our efforts to finding more powerful ways to deal with them.
#1010
Online Casinos / Re: Ideas for online casinos to mitigate DDoS attacks
April 25, 2013, 05:55:17 PM
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.
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.
#1011
Online Casinos / Re: Ideas for online casinos to mitigate DDoS attacks
April 25, 2013, 12:51:34 PMQuote from: AMK on April 23, 2013, 08:51:19 PMJust posting some ideas in the open here, nothing more.
Could you please sum up in a paragraph what's going on here VLS : )
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
#1012
Online Casinos / Re: Ideas for online casinos to mitigate DDoS attacks
April 23, 2013, 07:17:54 PM
Just got response from Dublinbet!
They forwarded this thread to management.
They forwarded this thread to management.
#1013
Online Casinos / Re: Ideas for online casinos to mitigate DDoS attacks
April 23, 2013, 07:13:33 PM
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.
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.
#1014
Online Casinos / Re: Ideas for online casinos to mitigate DDoS attacks
April 23, 2013, 06:47:36 PM
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:
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.
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:
Code Select
<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.
#1015
Online Casinos / Re: Ideas for online casinos to mitigate DDoS attacks
April 23, 2013, 04:05:55 PM
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.
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.
#1016
Online Casinos / Re: Ideas for online casinos to mitigate DDoS attacks
April 23, 2013, 02:35:56 PM
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.
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.
#1017
Online Casinos / Re: Ideas for online casinos to mitigate DDoS attacks
April 23, 2013, 02:20:44 PM
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.
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.
#1018
Online Casinos / Ideas for online casinos to mitigate DDoS attacks
April 23, 2013, 02:15:59 PM
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.
I've called the particular attention of Dublinbet to this thread.
#1020
General Discussion / Re: A mission statement for the forum?
April 19, 2013, 04:46:52 AM
I certainly agree most of our members are seasoned enough to not wanting to discuss the Martingale and its many variations over and over and over.
The inane study of the same losing methods over and over doesn't serve for anything. The staff certainly need to sit down and ponder about the destiny of the forum. In which direction do we want to take the community towards? What is our Raison d'être?
In the past, it would have been clear: "a roulette systems forum", now I don't share with such fatuous lines. My personal view is this community should lead synergistic efforts towards assisting each other to win, not merely "lose less".
The inane study of the same losing methods over and over doesn't serve for anything. The staff certainly need to sit down and ponder about the destiny of the forum. In which direction do we want to take the community towards? What is our Raison d'être?
In the past, it would have been clear: "a roulette systems forum", now I don't share with such fatuous lines. My personal view is this community should lead synergistic efforts towards assisting each other to win, not merely "lose less".