Discussion regarding the prevention of Bot Flooding, Bruteforcing & Hacking on RSPS
- Open Discussion | Suggestions / Existing implemtation of ways to counteract Bot Flooding, Bruteforcing & Hacking for any RSPS revision - Contributions are welcome & credited, please keep to topic (Even you [Only registered and activated users can see links. Click Here To Register...])
Over the years, you may have experienced more malicious activity ramping up around the community, possibly due to servers turning into businesses and only caring about their income/growth.
I myself had created a simple [Only registered and activated users can see links. Click Here To Register...] back in 2011 for educational purposes to see how many of these servers lacked just simple security measures.
Still, in 2021 majority of the servers that are online (even some of the top 10 servers on the toplists at present time of this thread) have absolutely zero security to prevent this.
I know that some of these servers are created for a quick buck, but even implementing any of the following suggestions in this thread would make your staff teams life even easier.
This thread is heavily focused on the server-side, as only making changes on the client doesn't resolve the underlining issue.
Contributed code will also be included within this thread, I do not have the time to write-up a system for every-source base but feel free to comment.
Expectations of these attacks:
- [Only registered and activated users can see links. Click Here To Register...] that will include your login stream
- Residential Proxy IPs to attempt to get past any Proxy API detection
- Bypass publicly used Captcha services, by using third-party services such as [Only registered and activated users can see links. Click Here To Register...]
- Bypass client-sided security. Such as; hashing, unique packets, RSA etc
[Bot Flooding]
- Randomly named accounts that will automatically complete any tutorial and begin flooding PM/CC/IGC/Other Packets
- 1-2000 concurrent logins in attempts to either take-down the server or advertise another
[Bruteforcing / Hacking]
- Login attempts ranging from 1-2000 attempts per second (Depending on the networking within the source / current safe-guards)
- 1-100 accounts being attacked at the same time, dumped from highscores or in-game sources
- Login attempts with passwords from leaked RSPS / Gaming databases
- Bruteforce 2FA code (Once password obtained)
My current implementation of discouraging Bruteforcing attacks (Subject to change after 16/04/2021):
- Detection to see if the same IP is attempting to login to various accounts, as the same proxy may be used
- Throttling logins per IP - 5 second wait time per attempt, lockout IP for 5 minutes after multiple failed attempts
- Throttling logins per account (Except from an IP that has already successfully logged into the account previously)
- Monitoring system that will alert you if login attempts exceed 10/s (Useful for inspecting the type of attack, when it's happening)
- Warning users before they login that their password is in a compromised database, highly recommending using another password or risk being compromised
My current implementation of discouraging Bot Flooding attacks (Subject to change after 16/04/2021):
(Detection if 10+ accounts are created within a short-space, choosing to inact the following):
- Choice to stop proxies/vpn's from logging in for X minutes
- Choice to make it so only IPs that have successfully logged into the server from XX-XX-XXXX - XX-XX-XXXX date/time for X minutes
- Unique "tutorial" that is enabled when a Bot Flood attack is detected, confusing the attacker and possibly dissuading them
- Hiding the account from players (within PlayerUpdate), until tutorial is complete [Credit to [Only registered and activated users can see links. Click Here To Register...] for implementing this in their server]
- Deleting /or Moving accounts to another database that have less than 3 minutes of total play-time (Check every 2-3 months)
- Do not allow saving of an account that haven't completed the "tutorial"
My current implementation of discouraging Hacking (Subject to change after 16/04/2021):
- Discourage users from setting passwords that are used in RSPS / Gaming database breaches ([Only registered and activated users can see links. Click Here To Register...])
- Encourage users to use a secondary password/pin that is not related to the existing password. Limit this to 3-5 attempts per X minutes. Ths secondary password prompt will lock ALL non vital packets and only allow the Input Packet for the prompt
- Monitor account logins from new IPs, announce/flag to staff in-game & in-discord
- Encourge users to use 2FA on their account
Honestly, what I personally would not recommend as a solution:
- Rate limit logins for all connections (In-General)
- Attempting to resolve the issue client-sided only
Extra Bits:
- I have seen some servers use a Proxy API to detect if the sign-in IP is from a Proxy. This is great but please be careful with the way you implement this, as it may open-up yourself up to a DOS attack
- Also, I have seen some servers implement 2FA in a way which allows an attacker to Bruteforce it & even crash the server. Please add the 2FA check before the password check, and throttle this.
- [Only registered and activated users can see links. Click Here To Register...] does make it harder for an attacker to extract your login packets, but not impossible. I would highly recommend a mixture of obfuscation & re-locating fields/voids (for login) around your other class files to discourage an attacker
If you would like to test your current implementation, I am happy to run my headless client on your test/active server (as long as you provide your login packets, I'd rather not see another obfuscated client again).
I am not able to provide my Headless Client as this breaches Rune-Server's terms, as this could be used maliciously. However, I can provide a snippet of a login packet for an example.
Spoiler for #Login Stream/Packet Example:
Code:
@Override
public void initSocketRequest() throws IOException {
long l = Misc.longForName(getUsername());
int i = (int)(l >> 16L & 0x1FL);
//MAC ADDRESS 08-60-6E-7C-33-69
//This server does not check if MAC is valid, generating random numbers for faster operation
Random r = new Random();
int low = 10; int high = 99;
String macAddress = (r.nextInt(high-low) + low) + "-" +
(r.nextInt(high-low) + low) + "-" +
(r.nextInt(high-low) + low) + "-" +
(r.nextInt(high-low) + low) + "-" +
(r.nextInt(high-low) + low) + "-" +
(r.nextInt(high-low) + low);
//Another means of protection that the server is expecting to see
StringBuilder sb = new StringBuilder(12);
for(int len = 0; len < 12; len++)
sb.append(AB.charAt(rnd.nextInt(AB.length())));
StringBuilder stringBuilder = new StringBuilder();
for(int c = 0; c < 12; c++)
stringBuilder.append(r.nextInt(254) + 'a');
//Client is using Reflection to generate identifier for current client version, based on class files & cache files
//Grabbed string from client memory, converting to bytes and sending to the server
byte[] bytes = "d41d8cd98f00b204e9800998ecf8427e".getBytes();
getInitialStream().writeByte(bytes.length);
getInitialStream().writeBytes(bytes, bytes.length, 0);
//EXTRA - This server supports 2FA and is required within login stream
/*Random rnd = new Random();
int number = rnd.nextInt(999999);
String twoFactorPin = String.format("%06d", number);*/
String twoFactorPin = "";
setTwoFactor(twoFactorPin);
POW - (Bruteforcing/Hacking/Bot Flooding):
[[Only registered and activated users can see links. Click Here To Register...]]:
- Adding POW in general will slow down the ability to bruteforce and you can increase the difficult of the work for specific accounts. [Only registered and activated users can see links. Click Here To Register...]
[[Only registered and activated users can see links. Click Here To Register...]]:
- Where the client requires some compute resource to complete a proof sent by server. This way bot flooding/bruteforcing will cost a lot of resource to do quickly. It should stagger logins for bots quite nicely.
The server can verify this proof much easier without expending the same resources the client did. [Only registered and activated users can see links. Click Here To Register...]
Forum/SQL - (Bruteforcing/Hacking):
[[Only registered and activated users can see links. Click Here To Register...]]:
- Applying similar throttling/measures to your website too. [Only registered and activated users can see links. Click Here To Register...] to certain login endpoints proven to be effected. Also, making login attempts much stricter within the Forum software it-self. [Only registered and activated users can see links. Click Here To Register...]
JS5 Flooding:
[[Only registered and activated users can see links. Click Here To Register...]]:
- The one thing that haunts a lot of OSRS-based servers nowadays is the JS5. It is all too easy to make mistakes with it. I'll leave it up to someone else to figure out what sort of protection they could do against JS5 flooding. Note: Throwing more hardware/servers at it isn't a real solution. [Only registered and activated users can see links. Click Here To Register...]
- Limit connections per IP, limit requests per file group. Block off invalid cache indexes(as of revision 178, there's only one - index 16, previous world map). The latter is a huge worrying point - you don't really want to release your server with a cache from before that. A single group in index 16 is over ten megabytes. That is such a weak point that anyone could take the JS5 down relatively easily by targeting that specific group. All it requires is for you to send a request thats a couple bytes, and the server is forced to reply to that with the aforementioned ten megabytes. With enough proxies, you can always take it down, even if the dedi has 10gbps network.
As long as index 16 isn't in the picture anymore, everything becomes a lot more clear. The biggest group then is one of the models, with just tens of kilobytes if I recall correctly. That is significantly harder to abuse to bring the whole network down.[Only registered and activated users can see links. Click Here To Register...]
Best Practices:
[[Only registered and activated users can see links. Click Here To Register...]]:
- Something else people should do is worry over the logic in their login handling. Ideally you wanna discard any logins that reach the game which don't get processed in the 30 seconds time-window that the client actually awaits for(so if you do by some miracle get flooded hard enough, worst case, it'll clear out as soon as 30 seconds are up at the end of the flooding). Besides that, you want to process logins in a logical order, checking things that require little to no processing power to begin with, moving on to more and more expensive stuff further down the line. Something as complex as a hashed password comparison should be done as the very last thing, as it usually requires hundred(s) of milliseconds to process just once. [Only registered and activated users can see links. Click Here To Register...]
TLDR;
It's not possible to completely prevent these attacks but serious mitigation may prevent an attack from happening in the first place.
— Props to servers that have implemented security measures to prevent this, you know who you are - you may have even seen me in your console logs :)
04-16-2021, 11:58 AM
Omar
Quote:
Originally Posted by jet kai[Only registered and activated users can see links. Click Here To Register...]
My current implimentation of discouraging Bruteforcing attacks (Subject to change after 16/04/2021):
- Detection to see if the same IP is attempting to login to various accounts, as the same proxy may be used - Throttling logins per IP - 5 second wait time per attempt, lockout IP for 5 minutes after multiple failed attempts
- Throttling logins per account (Except from an IP that has already successfully logged into the account previously)
- Monitoring system that will alert you if login attempts exceed 10/s (Useful for inspecting the type of attack, when it's happening)
- Warning users before they login that their password is in a compromised database, highly recommending using another password or risk being compromised
In addition to throttling based on IP addresses and such, another thing worth considering is implementing some sort of proof-of-work system, similar to what OSRS currently has. Adding POW in general will slow down the ability to bruteforce and you can increase the difficult of the work for specific accounts.
04-16-2021, 12:11 PM
jet kai
Quote:
Originally Posted by Omar[Only registered and activated users can see links. Click Here To Register...]
In addition to throttling based on IP addresses and such, another thing worth considering is implementing some sort of proof-of-work system, similar to what OSRS currently has. Adding POW in general will slow down the ability to bruteforce and you can increase the difficult of the work for specific accounts.
Ooo, that's a really good idea! :) I hadn't thought of that one. Would be interesting to see if any servers have implimented this already and if it is effective.
04-16-2021, 12:30 PM
Corey
Remember to apply similar throttling/measures to your website too, if your in-game accounts are linked to something like a forum.
This happened to us a lot on Zenyte, and I ended up adding cloudflare ratelimiting to certain login endpoints and also making login attempts much stricter within IPB itself.
Quote:
Originally Posted by jet kai[Only registered and activated users can see links. Click Here To Register...]
Would be interesting to see if any servers have implimented this already and if it is effective.
Zaros does this, I'm unsure if anyone else does atm.
Quote:
Originally Posted by jet kai[Only registered and activated users can see links. Click Here To Register...]
I am not able to provide my Headless Client as this breaches Rune-Server's terms, as this could be used maliciously.
Don't believe it is. Either way, @[Only registered and activated users can see links. Click Here To Register...] released one here not long ago: [Only registered and activated users can see links. Click Here To Register...]
off-topic but please increase the size of the font in OP, I had to sit annoyingly close to my monitor to read it.
04-16-2021, 12:34 PM
JayArrowz
I think POW (Proof of work) would help with the login a lot.
Where the client requires some compute resource to complete a proof sent by server. This way bot flooding/bruteforcing will cost a lot of resource to do quickly. It should stagger logins for bots quite nicely.
The server can verify this proof much easier without expending the same resources the client did.
04-16-2021, 01:00 PM
Kris
I don't believe bruteforcing to be a thing in RSPS. I've not seen anyone, except [Only registered and activated users can see links. Click Here To Register...], bruteforce anything. However dictionary attacks(I don't personally consider them bruteforcing as you generally only do one attempt per username-password pair), using the information obtained from database leaks and whatnot, is all too common and all servers inevitably suffer from it.
One of the best things you can do is not allow VPNs, dedis and such not to access your site nor your game. This will, assuming effective, prevent anything large-scale from happening.
Something else people should do is worry over the logic in their login handling. Ideally you wanna discard any logins that reach the game which don't get processed in the 30 seconds time-window that the client actually awaits for(so if you do by some miracle get flooded hard enough, worst case, it'll clear out as soon as 30 seconds are up at the end of the flooding). Besides that, you want to process logins in a logical order, checking things that require little to no processing power to begin with, moving on to more and more expensive stuff further down the line. Something as complex as a hashed password comparison should be done as the very last thing, as it usually requires hundred(s) of milliseconds to process just once.
On top of all this, I noticed you left the worst chapter out of this thread entirely. The one thing that haunts a lot of OSRS-based servers nowadays is the JS5. It is all too easy to make mistakes with it. I'll leave it up to someone else to figure out what sort of protection they could do against JS5 flooding. Note: Throwing more hardware/servers at it isn't a real solution.
04-16-2021, 04:18 PM
Omar
Quote:
Originally Posted by Kris[Only registered and activated users can see links. Click Here To Register...]
One of the best things you can do is not allow VPNs, dedis and such not to access your site nor your game. This will, assuming effective, prevent anything large-scale from happening.
I think it's generally a good idea to block them, but it's also for sure not the be-all end-all solution either; residential proxies are a thing and people do abuse them for RSPS. JS5 melting is definitely a good point, btw. Very often a weak point on a lot of the 400+ servers.
04-16-2021, 04:38 PM
jet kai
Quote:
Originally Posted by Kris[Only registered and activated users can see links. Click Here To Register...]
One of the best things you can do is not allow VPNs, dedis and such not to access your site nor your game. This will, assuming effective, prevent anything large-scale from happening.
Even though DDOS isn't as bad as it used to be, I feel that VPNs should still be allowed as there are a some users that will refuse to disconnect their VPN.
I think if you were to block VPNs in anyway, there should be some sort of manual toggle for this (or automatic detection) that will disable VPN connections when being attacked.
Quote:
Originally Posted by Omar[Only registered and activated users can see links. Click Here To Register...]
I think it's generally a good idea to block them, but it's also for sure not the be-all end-all solution either; residential proxies are a thing and people do abuse them for RSPS. JS5 melting is definitely a good point, btw. Very often a weak point on a lot of the 400+ servers.
I will have to have a look into JS5 Flooding, does this just basically take down the Update Server or does this cause any further damage? I am assuming if the user already has the client pre-loaded, they can still login.
04-16-2021, 04:44 PM
Kris
Quote:
Originally Posted by jet kai[Only registered and activated users can see links. Click Here To Register...]
Even though DDOS isn't as bad as it used to be, I feel that VPNs should still be allowed as there are a some users that will refuse to disconnect their VPN.
I think if you were to block VPNs in anyway, there should be some sort of manual toggle for this (or automatic detection) that will disable VPN connections when being attacked.
Perhaps so, VPNs themselves aren't too much of an issue. Just not letting people donate while on a VPN would be enough. It's not that easy to abuse a VPN to cause any mass-scale damage anyways.
Quote:
Originally Posted by jet kai[Only registered and activated users can see links. Click Here To Register...]
I will have to have a look into JS5 Flooding, does this just basically take down the Update Server or does this cause any further damage? I am assuming if the user already has the client pre-loaded, they can still login.
Yes, what you said. If you have the cache downloaded and it is up to date, the client won't be requesting anything else and people will be able to login, as long as update server doesn't somehow interfere with the game server. This is more of an issue with server releases though. Attacking the JS5 during a release is a sure way to ensure no one can get online, and thus, cause a launch to be a failure. It would also be an issue if you were to do a cache update, and someone attacked the JS5 right as the server went back up.
04-16-2021, 05:20 PM
jet kai
Quote:
Originally Posted by Kris[Only registered and activated users can see links. Click Here To Register...]
Yes, what you said. If you have the cache downloaded and it is up to date, the client won't be requesting anything else and people will be able to login, as long as update server doesn't somehow interfere with the game server. This is more of an issue with server releases though. Attacking the JS5 during a release is a sure way to ensure no one can get online, and thus, cause a launch to be a failure. It would also be an issue if you were to do a cache update, and someone attacked the JS5 right as the server went back up.
I was thinking about this for a little but, I assume servers that fell victim to this may have a backup mirror of the full cache (for when it's being JS5 Flooded) and act like those old Cache Downloaders that everyone used to use.
An awful "fix", but at least it'll offer some kind of backup solution for servers @ launch.
04-16-2021, 05:51 PM
Kris
Quote:
Originally Posted by jet kai[Only registered and activated users can see links. Click Here To Register...]
I was thinking about this for a little but, I assume servers that fell victim to this may have a backup mirror of the full cache (for when it's being JS5 Flooded) and act like those old Cache Downloaders that everyone used to use.
An awful "fix", but at least it'll offer some kind of backup solution for servers @ launch.
No, they just fix their crap JS5 code.
Start off by getting a 500mbps+ network dedi for your server. Personally wouldn't go below that if you're expecting the server to reach hundreds of players. Limit connections per IP, limit requests per file group. Block off invalid cache indexes(as of revision 178, there's only one - index 16, previous world map). The latter is a huge worrying point - you don't really want to release your server with a cache from before that. A single group in index 16 is over ten megabytes. That is such a weak point that anyone could take the JS5 down relatively easily by targeting that specific group. All it requires is for you to send a request thats a couple bytes, and the server is forced to reply to that with the aforementioned ten megabytes. With enough proxies, you can always take it down, even if the dedi has 10gbps network.
As long as index 16 isn't in the picture anymore, everything becomes a lot more clear. The biggest group then is one of the models, with just tens of kilobytes if I recall correctly. That is significantly harder to abuse to bring the whole network down.
It is also important to spread out the JS5 requests, don't send the whole cache to a single user all at once, throttle it so everyone gets the cache at relatively the same speed. The way I did it iirc was by only processing 100-200 requests per 100ms per IP.
I highly suggest anyone who plans on releasing their server to get another dedi/vps, this one only needs good networking, nothing else. Disable most of your security on your game server, anything extra you got, get rid of it. Then attack your server with the newly bought dedi in the worst way you can think of. If you're the one who added all the JS5 restrictions, you're the one who knows how to best attack the JS5, where each limit sits at. You're then able to optimize your flooding to the absolute worst. Attack your own server, if it can withhold that without issues, you shouldn't need to worry about it anymore.
I don't remember exactly what precautions I added on Zenyte for the JS5 there, however I do know that no one has ever breached it or managed to take it down. The JS5 there is on the same dedi as the game itself. It managed to feed the cache to hundreds of players fast enough to where over four hundred were online in just a couple minutes. I personally did all the math to figure out the worst-case scenario, how much bandwidth we would need to not have to worry about anything, and then I doubled that just to be safe.
