Killers and Lamers

[Nemo]

I think, anyone is knowing the problem about team/basekillers and how to get those people out of the servers. :evil:

Most people (including me at some times) are gettin agressive and trying to kick/ban this people.

But this is wrong!

You may think now, that I'm stupid/insane, but plz read further.

Those people doin this stuff, because they wont to get some attention and/or makin anyone else really pi**ed off. Doin kickin/bannin, they are reachin their target. IMHO it is better to call a mapvote (meaning restart or nextmap), until they're pi**ed off, and are leavin.

I think, this is an idea which should be tried for a while (meanin long time), to get those people out of Trem.


There's another category of people, which I call (server-)message-spammers. For example, I played a game, where a killer was. Then, a kick-vote started, and he was changin his name faster than you can shoot with the rifle in game. Hence, the server always posted "player-name name chaned to name2" and vice versa, where name and name2 are the alternatin names of the killer. Lasting, the killer couldnt be kicked.

It's may a good idea to include some source-code in game, which detects such (fast) massive renaming, and blocks at client-side for, sayin, 10 minutes, meaning that he can't connect to any server, and the actual connection is closed.

Criticism and comments to this post are welcome.

Gr33tz, Nemo

[Howitzer]

PB has this feature.
It just kicks you out when you change your name rapidly (3 times in 5sec i think)

[SLAVE|Mietz]

good idea, this will also reduce the "player model failed to register"-bug

[[db@]Megabite]

...Then, a kick-vote started, and he was changin his name faster than you can shoot with the rifle in game. Hence, the server always posted "player-name name chaned to name2" and vice versa, where name and name2 are the alternatin names of the killer. Lasting, the killer couldnt be kicked.

If you've got rcon, you can easily get him: "\rcon status" to find out his id, then "\rcon clientkick his_id".

I would recommend to implement a guid-system or the like in tremulous. The game could generate a unique id at installation and send it to the server at connection.
You could permanently ban a lamer then until he reinstalls the game, which would be sweeter than just being able to ban IPs.

Cheers, Danny

[Nemo]

Megabite"]

...Then, a kick-vote started, and he was changin his name faster than you can shoot with the rifle in game. Hence, the server always posted "player-name name chaned to name2" and vice versa, where name and name2 are the alternatin names of the killer. Lasting, the killer couldnt be kicked.

If you've got rcon, you can easily get him: "\rcon status" to find out his id, then "\rcon clientkick his_id".

I would recommend to implement a guid-system or the like in tremulous. The game could generate a unique id at installation and send it to the server at connection.
You could permanently ban a lamer then until he reinstalls the game, which would be sweeter than just being able to ban IPs.

Cheers, Danny

Megabite: GUIDs will not work: One can grab the position where it is saved, and replace it by a new one.

For example: suppose, the guid is saved into a hidden file, and you're running linux, then one can get the files position through "lsof | grep tremulous" or something similiar.

Gr33tz, Nemo

[[db@]Megabite]

Okay, you would have to make it secure one way or the other... one way would be to encrypt it. Yeah, anyone knowing the sources could find it out and change it...

so how about generating a guid at installation, encrypting it and sending it to a masterserver (there is one, anyway, as far as I know!?) acting as a keyserver.
Anytime you connect to a Tremulous-Server, the id is checked by the server and the masterserver. If someone worked around the encryption and changed the key manually, the masterserver would still reject the connection, because the key is not known.

The aim of this is would just be to make it hard for idiots to get around being banned. To make it harder than just dialing in again to get a new IP.

Cheers, Danny

[Silverius]

Fake a reinstall, done.

You could then block multiple installs from an IP quickly after eachother, but then you'd be easier off to just let the client generate a GUID and record it.

[[db@]Megabite]

Sure

But banning a GUID is even faster than a fake reinstall... when a lamer is banned with his 3rd GUID he will be pissed off and search for another server or even game to ruin...

As I said, the aim is just to make it harder for idiots to ruin the game... you cannot prevent them fully in a free game, but make it harder for them and easier for us.
And I am quite sure that not even 10% of the idiots running around would check out how to get around a ban...

Cheers, Danny

[Silverius]

Rename/delete Trems private directory (.trem or .tremulous or something), rerun trem, new GUID. Easy enough to write a script for, even for somebody with little technical knowhow.

Also note that encryption won't work when it's done by the client as the client needs to have the input for the encryption and has full control over the program and the computer.

Sure, this will help a bit against some people. However the determined folks that cause the most trouble are likely to work around it easily. And the folks that it catches are likely to be caught by more conventional means like IP based bans too.

[[db@]Megabite]

It is clear to me now, we need something like Steam....  

[R1CH]

Megabite"]It is clear to me now, we need something like Steam....  

You want everyone to pay for Trem?

[[db@]Megabite]

Sarcasm is only funny if you understand it...

[Nemo]

Megabite"]It is clear to me now, we need something like Steam....  

Hi Bishop, IMHO steam wouldn't work:

1st. There are also people on it, which dont do something usefull while playing.
2nd. Cryptography is often only Snake-Oil, so anything on a client wouldn't bring down the problem: simple re-install and killing again. For using such a thing like steam, one has to need anything trackable information: A name, GUID, etc.

GUID will not work, because it can be simply overriden by re-installing the game or localizing the save-point of the GUID.

name can only work, if a user gets a penalty for choosing yet another one, meaning he has to pay for. In this case, trem wouldn't be open source, it would be more like a game without an valid licence-key.

The best thing IMHO is, to simply ignore those killers, and to take either a map_restart, map_next, or to leave the killer alone, meaning, that all other are leaving the server. So the killer could do his "work", but he would not gain any attention. I've seen it often in the last days, that the killers are only accessing and killing servers with many players on it, and after the leaving of a great part of gamers, they're off too.

Ive played today on some servers, which prompted a message, that "player xy removed the z". This is a good way to see, if there are killers on the server. Then it is easily to restart the map etc.

As stated above, the killers are trying to gain attention, if they don't get this, they are the pi**ed-offs.

Gr33tz, Nemo

[[db@]Megabite]

Hey there,

why bishop? Me be no christian...
As I mentioned above, the statement about steam was a (bad ) joke.

Just letting those idiots do what they want is no solution, either. There are always players on a server who will shout at him and give him attention. His goal is to ruin the game, that is fun for him. Ignoring him will still ruin the game and when people are leaving because of him THAT is, what he wants.

So I will continue to ban those idiots by IP on our server, it is not that much work... :wink:
I will not get my server wiped and my members disconnect because someone thinks it funny to be an idiot. Maybe there will be a better solution sometime in the future...

Cheers, Danny

[Fluffy]

How about using an old and tried method of e-mail activated accounts? It works quite well for lots of web sites, including this forum. It may even be integrated with this forum!

Naturally we don't want to give our user and password to any random game server out there, so a kind of one-time token authentication is needed. It could work like this:

- client contacts authentication server, giving his user and password, and requests connection token to a game server
- auth server hands out a token provided the login details are correct
- client connects to the game server giving the token
- game server contacts authentication server and says: "Hi! Tell me whether this token is valid and who you issued it to."
- Auth server checks the token and either replies that it is invalid, or says: "it's ok, I issued it to my user xxx which has an email @example.com". Auth server then deletes the token so it is no longer valid.

Naturally additional safeguards may be put in place. The token may be very short-lived and only 1 per user, so you can't collect many tokens and then use them in a long period of time. Client IP may be checked, to lessen the probability that an attacker will sniff the token on the wire and use it to connect.

This scheme will hopefully make creating new accounts enough time consuming process, that it won't be feasible for troublemakers to spend 30 minutes or more creating a new account just to loose it in 5 minutes. Users registering with email addresses from anonymous mail providers like mailinator.com, ip based emails, or other mail providers that make it too easy to register an account, may be quickly banned by the domain name. Users won't be able to change their login name, so a ban by login name will finally be effective.

This scheme may be optional, so that lan servers, or servers geared towards beginners may not be protected.

Comments? I'd like to know why this scheme is bad and won't work  :wink:

[tjw]

Those running servers may want to have a look at the trembot admin
interface I'm working on:

http://www.tjw.org/tremulous/

You can try it out now if you want to help me test.  It's stable as far as I know, however the binaries on that page get replaced every time I do a new build, use at your own risk (or at least save a copy of last known working binaries/so files).

[Nemo]

Megabite"]Hey there,

why bishop? Me be no christian...
As I mentioned above, the statement about steam was a (bad ) joke.

Just letting those idiots do what they want is no solution, either. There are always players on a server who will shout at him and give him attention. His goal is to ruin the game, that is fun for him. Ignoring him will still ruin the game and when people are leaving because of him THAT is, what he wants.

So I will continue to ban those idiots by IP on our server, it is not that much work... :wink:
I will not get my server wiped and my members disconnect because someone thinks it funny to be an idiot. Maybe there will be a better solution sometime in the future...

Cheers, Danny

Hey Megabite, sorry for calling you Bishop, was busy, so Ive overseen it   .

I think, its best to leave them at their killing, but a map_restart kills their killing, so they are going to be pi**ed-off, and not their targets (meaning the normal players). Banning of IPs would may also harm uninvolved players (most ISPs give you a dynamic IP from their space at dial-in), so for example, if one would use provider X, this would maybe lead to the problem, that no other gamer using also provider X could play.

Fluffy: Your idea would mean, that someone has to implement a Kerberus-like infrastructure. IMHO its better to have some password-protected servers, and you can only be invited to those through already fair-playing gamers, so it would be kinda web of trust a la PGP.

Gr33tz, Nemo

Edit: Removed a wrong-placed char (new keyboard, not typedin).

[Shafe]

Those running servers may want to have a look at the trembot admin
interface I'm working on:

http://www.tjw.org/tremulous/

You can try it out now if you want to help me test.  It's stable as far as I know, however the binaries on that page get replaced every time I do a new build, use at your own risk (or at least save a copy of last known working binaries/so files).

Hehe.. I like this from your features.txt:
  Set this to non-0 if you want trembot to parse commands from chat and
  teamchat messages.  Example: saying "!ban nexter 1w you are a lamer" in
  global chat would be equivelent to "/ban nexter 1w you are a lamer" in
  you client console.

nexter is famous..lol

I'm gonna give this a try on the beer garden server... I'll try to get it up tonite or tomorrow... Just been incredibly busy recently...

[[EVIL]Unknown]

shafe take ur time dont feel rushed....dont overwork urself...most of us know how much of a workaholic u are....

lol though i was laughing my ass off when he came in the beergarden server yesterday as all www.nexterholland.com and before i could relize my bind for status was messed up he called one of those all votes...i told everyone to vote no but they all voted yes....and to my suprise....all www.nexterholland.com was the only one kicked...


THATS RIGHT EVERYONE ALL NEXTERHOLLAND JUST KICKED HIS OWN ASS YESTERDAY!!!!

[Fluffy]

Fluffy: Your idea would mean, that someone has to implement a Kerberus-like infrastructure.

Yes, similar to Kerberos, but much simplier. No keys, no encryption, no identity proof. It does not make much sense unless the rest of network activity is encrypted: currently if we have a man-in-the-middle attacker, he can just hijack the game session in progress, after we do all the authentication stuff.

IMHO its better to have some password-protected servers

Password-protected servers are completely on the other end of the scale. I'd like to see something in the middle, for the casual gamer, so we could have:

- public servers, with all kinds of idiots
- public servers for registered users, with hopefully much less idiots
- private servers for hard core gamers

[KoS]

- public servers, with all kinds of idiots
- public servers for registered users, with hopefully much less idiots
- private servers for hard core gamers

I support this! This could be a good idea.
The only thing to think about is how to distribute the access for non-public servers.
Private servers should have a member list, and new members could get access only from old members... or something similar...

[Onos]

hmm.....you do have a point they DO change there own character name so that they will destroy the entire base and they still do it after they change there names

[Nemo]

- public servers, with all kinds of idiots
- public servers for registered users, with hopefully much less idiots
- private servers for hard core gamers

I support this! This could be a good idea.
The only thing to think about is how to distribute the access for non-public servers.
Private servers should have a member list, and new members could get access only from old members... or something similar...

Is anyone knowing the .htpwd / .htusers - file on apache-servers? This would deal with all 3 stages:

public, with all: no pwd, no userlist.
public, with registered: pwd and maybe userlist.
private: pwd and userlist.

So private and public with registered would be nealy the same.
As said above, a web of trust a la PGP (without certs, encryption, and this stuff) would be great. Example:

Alice has created a protected server, and invites Bob. Bob invites Charlie, Charlie goes into a trap of Mallory, and Mallory starts to teamkill. It would be easy to guess who invited Mallory, by following scheme:

Charlie asks Bob (or Alice, anyone that is higher in the web of trust scheme) to invite Mallory. Charlie would get a pwd for Mallory, and send it to him. Mallory starts killing, gets kicked / banned, and his entry at the .htpwd-file would be easily dropped, so he cant login any more. In this scheme, a higher-ranked person in the web-of-trust can also decide, if Charlie is trustworthy enough to invite other people.

BTW: The names above are the standard names used in crypto-protocols, if you're wondering about them.


One idea about renaming-spammers: It would be nice to have a kinda puzzle to solve before you can rename, which takes some seconds. This puzzle could be a simple challenge/response-protocoll between the server and the client. This puzzle could be either solved by a human (thinking about CAPTCHAs) or a (for an PC) simple calculation, f. e., factoring a 128bit-number.

Gr33tz, Nemo

[Fluffy]

Is anyone knowing the .htpwd / .htusers - file on apache-servers? This would deal with all 3 stages:

public, with all: no pwd, no userlist.
public, with registered: pwd and maybe userlist.
private: pwd and userlist.

Yes, using Apache directives this would be:

Code: [Select]


# public: nothing, there's no authentication

# registered: any valid user will be accepted
require valid-user

# private: accept only few invited users
require user Alice Bob

Simple. Once we have registered users, instead of just IPs and always-changing nicks, we can implement all kinds of access restrictions. Webs of trust. RBAC. ACLs. You name it. And I don't mean restrictions limited to logging in only, but also restrictions to game commands, in-game actions etc. How far you go with this stuff would only be limited on how much control you need on your server, and how good you are at coding your ideas

[Nemo]

Is anyone knowing the .htpwd / .htusers - file on apache-servers? This would deal with all 3 stages:

public, with all: no pwd, no userlist.
public, with registered: pwd and maybe userlist.
private: pwd and userlist.

Yes, using Apache directives this would be:

Code: [Select]


# public: nothing, there's no authentication

# registered: any valid user will be accepted
require valid-user

# private: accept only few invited users
require user Alice Bob

Simple. Once we have registered users, instead of just IPs and always-changing nicks, we can implement all kinds of access restrictions. Webs of trust. RBAC. ACLs. You name it. And I don't mean restrictions limited to logging in only, but also restrictions to game commands, in-game actions etc. How far you go with this stuff would only be limited on how much control you need on your server, and how good you are at coding your ideas

Fluffy, IMHO this config is unsecure: no password. Anyone can simply change his name to fit the "require user", so a .htpwd would be needed for secure private and may also public restricted servers.

Gr33tz, Nemo

[Fluffy]

Fluffy, IMHO this config is unsecure: no password. Anyone can simply change his name to fit the "require user", so a .htpwd would be needed for secure private and may also public restricted servers.

It's not a config. Just a small part relevant to your post. I didn't included user database configuration, because it doesn't matter for access control whether it is .htpasswd, dbm file, LDAP, MySQL, or any other kind of user database. It doesn't even have to be user/password type of authentication, it may be a Kerberos-alike ticket based authentication.

[cujotus]

havent gt time to read everything yet, anyway:

temporary solution #tpatreme for mixed games

check out http://www.tremulous.net/phpBB2/viewtopic.php?t=457
and 2on2 tournament: http://www.tremulous.net/phpBB2/viewtopic.php?t=500