Thread: Discussion regarding the prevention of Bot Flooding, Bruteforcing & Hacking on RSPS

Page 1 of 2 12 LastLast
Results 1 to 10 of 11
  1. #1 Discussion regarding the prevention of Bot Flooding, Bruteforcing & Hacking on RSPS 
    08-13, SpawnScape Owner

    jet kai's Avatar
    Join Date
    Dec 2009
    Age
    26
    Posts
    865
    Thanks given
    596
    Thanks received
    815
    Discord
    View profile
    Rep Power
    5000
    - 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 Tyluur)


    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 Headless Client 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:
    - Headless Client 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 2Captcha
    - 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 @Simplex 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 (RSPS Breached-DB Checker)
    - 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.
    - Client Obfuscation 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);
    
            /** Init Login Connection **/
    
            getStream().currentOffset = 0;
            getStream().writeByte(14);
            getStream().writeByte(i);
            getRSSocket().queueBytes(2, getStream().buffer);
    
            for (int j = 0; j < 8; j++)
                getRSSocket().read();
            int responseCode = getRSSocket().read();
    
            /** RESPONSE MUST RETURN 0 **/
    
            if (responseCode == 0) {
                getRSSocket().flushInputStream(getInStream().buffer, 8);
                getInStream().currentOffset = 0;
    
                long aLong1215 = getInStream().readQWord();
                int[] ai = new int[4];
                ai[0] = (int)(Math.random() * 9.9999999E7D);
                ai[1] = (int)(Math.random() * 9.9999999E7D);
                ai[2] = (int)(aLong1215 >> 32L);
                ai[3] = (int)aLong1215;
    
                getStream().currentOffset = 0;
                getStream().writeByte(10);
                getStream().writeInt(ai[0]);
                getStream().writeInt(ai[1]);
                getStream().writeInt(ai[2]);
                getStream().writeInt(ai[3]);
                getStream().writeInt(350);
    
                //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');
    
                getStream().writeString(stringBuilder.toString());
                getStream().writeString(getPassword());
                getStream().writeString(macAddress);
                getStream().writeString(" ");
    
                getStream().writeShort(222);
                getStream().writeByte(0);
    
                getStream().doKeys(RSA_MODULUS, RSA_EXPONENT);
    
                getInitialStream().currentOffset = 0;
                getInitialStream().writeByte(isFlag() ? 18 : 16);
                String currentPin = "";
                getInitialStream().writeByte(getStream().currentOffset + 36 + 1 + 1 + 2 + (currentPin.length()) + 1);
                getInitialStream().writeByte(255);
                getInitialStream().writeShort(14);
                //int attack = Store.currentKey += 1;
                getInitialStream().writeByte(0);
    
                //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);
    
                getInitialStream().writeShort(0);
                getInitialStream().writeString(currentPin);
                getInitialStream().writeString(twoFactorPin);
    
    
                for (int i2 = 0; i2 < 9; i2++)
                    getInitialStream().writeInt(0);
                getInitialStream().writeBytes(getStream().buffer, getStream().currentOffset, 0);
    
                getStream().encryption = new ISAACRandomGen(ai);
    
                for (int j2 = 0; j2 < 4; j2++)
                    ai[j2] = ai[j2] + 50;
    
                getRSSocket().queueBytes(getInitialStream().currentOffset, getInitialStream().buffer);
    
                setResponseCode(getRSSocket().read());
                if(getResponseCode() != -1 && getResponseCode() != 30) {
                  //  TextEditor.writePasswordToFile(String.valueOf(attack), String.valueOf(attack));
                }
            }
            getRSSocket().close();
        }


    Discussion / Suggestions:

    POW - (Bruteforcing/Hacking/Bot Flooding):
    [@Omar]:
    - Adding POW in general will slow down the ability to bruteforce and you can increase the difficult of the work for specific accounts. >> Original reply
    [@JayArrowz]:
    - 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. >> Original reply


    Forum/SQL - (Bruteforcing/Hacking):
    [@Corey]:
    - Applying similar throttling/measures to your website too. Cloudflare Rate Limiting to certain login endpoints proven to be effected. Also, making login attempts much stricter within the Forum software it-self. >> Original reply


    JS5 Flooding:
    [@Kris]:
    - 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. >> Original reply
    - 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.>> Original reply [More Info]

    Best Practices:
    [@Kris]:
    - 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. >> Original reply





    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
    Reply With Quote  
     


  2. #2  






    Omar's Avatar
    Join Date
    Dec 2007
    Posts
    260
    Thanks given
    542
    Thanks received
    695
    Discord
    View profile
    Rep Power
    5000
    Quote Originally Posted by jet kai View Post

    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.


    Spoiler for aaaa:



    Reply With Quote  
     

  3. Thankful users:


  4. #3  
    08-13, SpawnScape Owner

    jet kai's Avatar
    Join Date
    Dec 2009
    Age
    26
    Posts
    865
    Thanks given
    596
    Thanks received
    815
    Discord
    View profile
    Rep Power
    5000
    Quote Originally Posted by Omar View Post
    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.
    Reply With Quote  
     

  5. Thankful user:


  6. #4  
    zen2
    Corey's Avatar
    Join Date
    Feb 2012
    Age
    24
    Posts
    1,426
    Thanks given
    1,129
    Thanks received
    1,579
    Discord
    View profile
    Rep Power
    5000
    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 View Post
    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 View Post
    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, @JayArrowz released one here not long ago: https://www.rune-server.ee/runescape...ss-client.html


    off-topic but please increase the size of the font in OP, I had to sit annoyingly close to my monitor to read it.
    Reply With Quote  
     

  7. Thankful users:


  8. #5  
    Registered Member
    JayArrowz's Avatar
    Join Date
    Sep 2008
    Posts
    90
    Thanks given
    91
    Thanks received
    94
    Discord
    View profile
    Rep Power
    595
    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.
    Reply With Quote  
     

  9. Thankful users:


  10. #6  
    Contributor
    Kris's Avatar
    Join Date
    Jun 2016
    Age
    23
    Posts
    3,570
    Thanks given
    728
    Thanks received
    2,487
    Discord
    View profile
    Rep Power
    5000
    I don't believe bruteforcing to be a thing in RSPS. I've not seen anyone, except Lmctruck30, 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.
    Reply With Quote  
     

  11. Thankful users:


  12. #7  






    Omar's Avatar
    Join Date
    Dec 2007
    Posts
    260
    Thanks given
    542
    Thanks received
    695
    Discord
    View profile
    Rep Power
    5000
    Quote Originally Posted by Kris View Post
    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.


    Spoiler for aaaa:



    Reply With Quote  
     

  13. Thankful users:


  14. #8  
    08-13, SpawnScape Owner

    jet kai's Avatar
    Join Date
    Dec 2009
    Age
    26
    Posts
    865
    Thanks given
    596
    Thanks received
    815
    Discord
    View profile
    Rep Power
    5000
    Quote Originally Posted by Kris View Post
    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 View Post
    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.
    Reply With Quote  
     

  15. #9  
    Contributor
    Kris's Avatar
    Join Date
    Jun 2016
    Age
    23
    Posts
    3,570
    Thanks given
    728
    Thanks received
    2,487
    Discord
    View profile
    Rep Power
    5000
    Quote Originally Posted by jet kai View Post
    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 View Post
    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.
    Reply With Quote  
     

  16. Thankful users:


  17. #10  
    08-13, SpawnScape Owner

    jet kai's Avatar
    Join Date
    Dec 2009
    Age
    26
    Posts
    865
    Thanks given
    596
    Thanks received
    815
    Discord
    View profile
    Rep Power
    5000
    Quote Originally Posted by Kris View Post
    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.
    Reply With Quote  
     

Page 1 of 2 12 LastLast

Thread Information
Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)


User Tag List

Similar Threads

  1. Replies: 1
    Last Post: 04-09-2014, 06:41 AM
  2. Regarding the sticky of introduction section.
    By ZammyPk25 in forum Suggestions
    Replies: 3
    Last Post: 02-03-2011, 05:26 PM
  3. Regarding the loss of my derep
    By SWAT in forum Forum Related Help
    Replies: 6
    Last Post: 06-12-2010, 07:14 PM
  4. Regarding the loss of my derep
    By Scu11 in forum Forum Related Help
    Replies: 26
    Last Post: 06-12-2010, 06:36 PM
  5. Regarding the loss of my banned status
    By ZammyPk25 in forum Forum Related Help
    Replies: 1
    Last Post: 06-10-2010, 06:37 PM
Tags for this Thread

View Tag Cloud

Posting Permissions
  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •