OpenTTD protection against abuse / brute force

[verysadboy]

Hello,

our server has been hacked by some cheaters.
I would like to have following security stuff in openTTD server running linux:

• Fail2ban will check if somebody attempts to login with Wrong SERVER password 10 or 20 times. And If yes, it will ban IP address of the attacker.
• Fail2ban will check if somebody attempts to login with Wrong RCON password 10 or 20 times. And If yes, it will ban IP address of the attacker.
• Fail2ban will check if somebody attempts to login with Wrong COMPANY password 20 or 30 times. And If yes, it will ban IP address of the attacker.

That is my idea of securing OpenTTD very easily. But I have no idea:

• How to log users IP addresses
• How to setup Fail2ban to check attempts mentioned above

I created new company today with super long password. I hope there is no exploit in game so it would be really big problem for OpenTTD.

Here are logs of what I have seen: (google translate to english)
[2019-01-04 19:42:37] *** Game Suspended (Clients Join)
[2019-01-04 19:42:40] *** Player # 1 joined the game (client # 192)
[2019-01-04 19:42:40] [Everyone]: Hello! Welcome to this server. I wish you nice
[2019-01-04 19:42:40] *** Game Restored (Clients Join)
[2019-01-04 19:42:47] *** Player # 1 joins company # 1
[2019-01-04 19:45:14] *** Player # 1 leaves game (disconnect)
[2019-01-04 20:05:45] *** Player leaves game (disconnect)
[2019-01-04 20:05:45] *** Game suspended (lack of players)



I think this is REALLY important and the whole community of OpenTTD should be aware on this problem.

[TrueBrain]: I changed the topic, as it has little to do with a vulnerability.

[jfs]

Did the intruder get access to your server by guessing the correct password, or did he somehow circumvent the password protection?

If the intruder circumvented the password protection, there is a vulnerability that needs to be documented and fixed. If the intruder merely guessed the password, then arguably your password was not good enough.

There is a mechanism built into OpenTTD called the Admin Port: https://wiki.openttd.org/Server_admin_port
The admin port allows external programs to control the OpenTTD server, and get detailed logging from it. It should be possible to implement a Fail2Ban mechanism via an admin port program.

[perverted monkey]

it will ban IP address of the attacker

What will be the benefit of this? It can only help temporary. Creating a list of banned IPs is completely useless and will prevent innocent players from joining the game.

Most attackers are smart enough to switch to completely different IP addresses and continue their vile act.

[verysadboy]

it will ban IP address of the attacker

What will be the benefit of this? It can only help temporary. Creating a list of banned IPs is completely useless and will prevent innocent players from joining the game.

Most attackers are smart enough to switch to completely different IP addresses and continue their vile act.

Ok...So let's see what is the problem now...
Nowadays situation on OpenTTD:

• There is no mechanism automatically banning users for many unsuccessful tries to login on server. Administrators cannot be up all the day, banning users for entering many hundreds of wrong passwords must be done automatically not by human hand.
• Servers are vulnerable against dictionary and brute force attacks now
• There is no mechanism which could log IP address of attackers or any players
• There is no information logged by a server about any type of attacker or about unsuccessful logins to game, rcon, or company.

Now Let's see facts:
https://www.fail2ban.org/wiki/index.php/Main_Page

• Fail2ban is fully configurable automated banning system which works independently on Human (admin) hand. (Admin in configuartion file only sets for example: how many tries before IP ban and for how long)
• If any attacker tries to hack your passwords (brute force, or dictionary attack) he will get immediately ban after as many attempts as set in fail2ban.conf. If he changes IP, he will get another few tries before next IP ban, which massively reduces a chance to brute force any longer password.
• It is massively used and favorite by system admins for securing SSH servers so it can ban any user who tries more than 5 wrong passwords (default IP BAN is 10 minutes, best practicies is to set 24 hours for IP ban). It makes brute force and dictionary attacks almost useless.
• No matter how many IP addresses you change if you are attacker, it will ban anyone who will reach the wrong password limit (100 unsuccessful tries before successful login for example).
• fail2ban supports whitelist and blacklist. Whitelist for users who will never get ban, blacklist for those who will never be allowed to connect.
• If you want to be definitely sure you want to detect hacker (and prevent innocent players to get banned) just set fail2ban to IP BAN anyone FOREVER who will unsucessfully tries to login 300 times for specific company. There cannot be anybody with 300 tries for wrong password. That must be definitely a hacker.
• Fail2ban fully supports all Linux distros (debian, centos, RHEL, fedora,ubuntu, slax, all ubuntu and RHEL based distros)
• Fail2ban works either with Iptables and FirewallD

We used to have strong passwords before an attack (RCON), company was secured by shorter password (10 characters), attacker sent all trains to depot, deleted all rails except those with trains on them, sold all possible trains in depots and deleted some train stations.
Even through mentioned company password would be hackable in 3 months, 5 days, 20 hours and 54 minutes (password has been later tested here: https://www.betterbuys.com/estimating-p ... ing-times/ )
Company has been created in the same day and within 6 hours it has been hacked.

It was only one company on that server that day and days before this incident there were 2 companies on server with similar broken company economy performance.


Now we set superlong password unhackable in short time with dictionary or brute force attack. We will tell you what will happen in next days. If the company will be hacked then resolution for this problem will be Fail2ban like solution integrated into OpenTTD which will raise security for all servers in the world.

Thank you for help

[Eddi]

if the problem is brute-forcing a password, then a rate-limit seems like the appropriate response.

[agentw4b]

The biggest problem with Opentdd is that in a multiplayer rebuild game from a backup it loses all the information about the player's passwords. It pretty much complicates server maintenance. I think it was reported to developers several times, but it was dismissed as little important.

https://github.com/OpenTTD/OpenTTD/issues/599

https://github.com/OpenTTD/OpenTTD/issues/5528

[planetmaker]

The biggest problem with Opentdd is that in a multiplayer rebuild game from a backup it loses all the information about the player's passwords. It pretty much complicates server maintenance. I think it was reported to developers several times, but it was dismissed as little important.

It's a complicated mess. If you want to save passwords, you have to do it properly with all complications which usually apply to passwords - or you risk to expose all player passwords to whoever has access to a savegame - something which is way worse than this situation.

We are free to suggestions. IMHO a passwords should
* be ignored when played in single-player
* if stored ingame, then properly cryptographically secured. Like store the HASH of (PW with SALT).

Additionally this will mean to pull into the code base a HUGE dependency, the cryptographic libraries. This will add a lot of size to the code base (maybe it could be included only when compiled as server or otherwise explicitly requested)

Pull-requests welcome

[Eddi]

i agree, if you want to store passwords, you need a cryptography expert who actually knows what he's doing. there's a plethora of ways to screw this up, every single one of those is catastrophic.

[jfs]

i agree, if you want to store passwords, you need a cryptography expert who actually knows what he's doing. there's a plethora of ways to screw this up, every single one of those is catastrophic.

Alternatively, remind the players that the server administrator will be able to access their password, and they should pick it accordingly. As it is now, I believe you could easily install a packet logger on the server and capture all passwords sent to it, there isn't any encryption in the OTTD network protocol. You could also easily make a build of OTTD server that just logs all passwords received to a file.

The main issue I see with storing company passwords in the samegame is that the server admin may want to make those savegames available for public download, and then the passwords would be visible to the world. A possible solution to that would be to let the server have a secret encryption key used for scrambling the passwords saved in the file. The server would be able to re-apply the passwords, while any user downloading the savegames wouldn't be able to recover the passwords. Of course some proper cryptoanalysis would be required before implementing anything like this, to lessen/avoid risks in e.g. known-plaintext attacks against the server's key.
(I am not a an expert in cryptography.)

[wallyweb]

As it exists OpenTTD is server ready for player participation.
If security functions were to be included within the distribution, they would be freely available to anybody who pulls the source code.
Security functions should not reside within the OpenTTD source code.
Security solutions should remain as separate entities within the server and should be unique to that server.
There are many login strategies. Most are designed to inhibit bots or algorithmic hacks .
The best one that I have seen to date requires at minimum ten character passwords (strong) drawing on any of the characters on the keyboard.
A successful login prompts the emailing of a server generated six digit random numeric code to the registered account holder who must then enter that code to complete the login process. A hacker would have to have access to a registered account holder's email address to be successful.

Fail2ban will check if somebody attempts to login with Wrong SERVER password 10 or 20 times. And If yes, it will ban IP address of the attacker.

Three times would be better, with a 24 hour suspension. Three suspensions could then be used for a permanent ban.

[Auge]

Hello

If security functions were to be included within the distribution, they would be freely available to anybody who pulls the source code.
Security functions should not reside within the OpenTTD source code.

This part is disputable.

If the program makes it possible to call an external library, this library can be (and probably will be) in itself open source. In that case the source code will be accessible for everyone and a list of possible attacks will exist. Even for a closed source library a list of possible attacks will exist. Problem with a possible but non-mandatory security feature could be, that many server operators would not use such an additional security feature because they had to maintain a further software on the server (and they wont). This would result in no security improvement on many servers.

If OpenTTD itself gets a cryptographic library it could only be an open source solution. At that point it is irrelevant if it is an own implementation (this would have in itself different impications and risks) or an included external solution. Everyone would have access to the source code, in OpenTTD's Github-repository or in the repo/source of the external library.

If it gets decided to implement a feature for storing password hashes in a game save, it IMHO should be a common, proper tested solution and it should be a mandatory and not an optional solution.

Alternatively, remind the players that the server administrator will be able to access their password, and they should pick it accordingly.

That's a bad idea. Passwords should get stored as its hash and not in plaintext. Same rule applies for the transmission from the clients to the server. So the password has to be hashed on the client side (end-to-end-encryption). An administrator must not know any password aside it's own one.

Tschö, Auge

[wallyweb]

...

All that you say is correct.
Note that my suggestion is aimed at the maximum possible security.
There is no reason why OpenTTD should not and could not offer an effective security solution. This is always desirable.
Access control at the server level is simply another level of security.
You are quite correct in that this would require another level of work for the server administrator. It all comes down to how much security the administrator deems necessary and is willing and able to provide.

[Eddi]

If security functions were to be included within the distribution, they would be freely available to anybody who pulls the source code.
Security functions should not reside within the OpenTTD source code.

anyone who has ever taken a lecture on security knows that it should be the exact opposite. the "security function" should be public, for anyone to review and find vulnerabilities. the only thing that should be hidden is the private key.

[Expresso]

There could be a private key+public key+password challenge inserted. Good luck breaking into a game if you have to pass through that. For the really paranoid, a company and/or rcon interface could be connected to a (list of) IP number(s) and maybe even encryption could be applied to the connection.

Probably difficult to implement, but keeps the assholes out. However, encryption (to prevent man-in-the-middle attacks) is probably to resource intensive for openttd, unless the thread doing the encryption/decryption lives on a different thread (opening its own can of worms). Now, encryption could only be applied during the challenge phase (to prevent logging).

If someone logs in, s/he could automatically be coupled to a company based on the security salt resulting from the keys and password.

[TrueBrain]

I changed the topic, as it has little to do with a security vulnerability.