list of bans

[Dookie]

Hello, i was wondering if possible to make somehow smthing like bans.cfg or smthing like that, basiclly that server is writting a notepad file somewhere in silent folder of the server, which will store banned users, their guids name's and reasons why the got banned, and make that list editable which means if u remove ban from there it will remove that ban when you do !showbans, basiclly this idea is cuz i was thinking maybe we server admins should share people banned from our servers, momentally ive got 150 bans on my server and many of them were aimbotters and such, on this way some other server admin can arrive here and copy list of his bans up in here so we others can add those players on our ban list also, cuz there is very few of active server nowdays and cheaters always wants to play with real players not bots, so its a great chance that after they get banned on server will go hacking on another of similar kind. basiclly this is just idea but i think it might be usefull since there is no other kind of protection nowdays...any comments and suggestions are welcomed.

[clan DIABOLIK]

IMO it's an awesome idea ! Incredible that no-one thought about it before ... much more efficient that an heavy/laggy PB !

[Dookie]

Ok i forgot that all bans are already seenable in shrubbot.cfg, so basiclly what we need now is a maybe a sticky topic somewhere so all server admins can paste their bans, and so others can add them on their server and such.

[JvIasterMind]

I still like the idea of splitting the bans out of the shrubbot.cfg file. Right now, it seems it is not clear enough that bans are placed in there. Currently, our shrubbot.cfg file on our server is already pretty big without the bans in it (we have quite a few levels defined and also a bunch of custom commands).

 

Actually, now that I think of it, wouldn't it be better to split all the info out of the file so we have files like levels.cfg, commands.cfg, and bans.cfg?

[Dookie]

I still like the idea of splitting the bans out of the shrubbot.cfg file. Right now, it seems it is not clear enough that bans are placed in there. Currently, our shrubbot.cfg file on our server is already pretty big without the bans in it (we have quite a few levels defined and also a bunch of custom commands).

 

Actually, now that I think of it, wouldn't it be better to split all the info out of the file so we have files like levels.cfg, commands.cfg, and bans.cfg?

i totally agree with you, i think there should be seperate cfg's, it will be much easier to track things and so on.

[BECK]

To play devils advocate here for a minute (although I GREATLY support keeping hackers off the game) - don't some servers have different levels of tollerance for what constitutes a ban?  I mean, some people will ban anyone without evidence, whereas on our server we will never ban unless we have a demo and opinion of multiple people on the demo.   I would be worried that some better players (who are legit) might end up basically being black-listed in the ET community because one server doesn't like them.  PBBANs was like this, where you could incorporate the so-called "master ban list" from punkbuster into your server, but those were guaranteed hacks and not just somones opinion.

 

Now that I've said that (consider it food for thought), I do like the ideas about breaking these files out.  I also generally support the idea of sharing ban data between servers. I'd just like to know that I'm not wrongfully banning a good player, and I'm not sure how that can be acheived.

 

Another thing that could/should be shared here is the MD5 hashes of unsupported client binaries that silEnT now detects.  I've googled a few of them and found them to be related to wallhax, but some of them have no hits.  Sharing this information between admins will be a good thing!

Edited January 2, 2013 by BECK

[TheSilencerPL]

I've googled a few of them and found them to be related to wallhax, but some of them have no hits

Could you please share them with us?

[JvIasterMind]

Could you please share them with us?

 

 

Caught two different people using the following binary. Google searching that checksum leads to a wallhack.

 

30d13c5e1339f3c80ad89ab4525564ab

[gaoesa]

30d13c5e1339f3c80ad89ab4525564ab

 

 

That is indeed a checksum of a famous and a fairly common wallhack binary.

[JvIasterMind]

Not to derail this thread too much, but what are the chances of the other unknown client binaries being safe? We have a few players that report the error message with other checksums that googling doesn't lead to anything with (their playing has not been too suspicious). I agree with Beck that it would be awesome having some sort of database of different checksums so we can look up players to know if they are hacking or known safe (or even ones that are not determined).

[TheSilencerPL]

It's hard if they are using own made ET:Legacy binaries.

[JvIasterMind]

It's hard if they are using own made ET:Legacy binaries.

 

What do you mean by this? Should we assume all unknown client binaries are safe until we see evidence proving otherwise? Or are there legitimate reasons why a players would be using an unknown client binary?

[TheSilencerPL]

What do you mean by this? Should we assume all unknown client binaries are safe until we see evidence proving otherwise?

Not at all. But it's very likely that it is a manually compiled ET client. You should be suspicious however.

 

 

Or are there legitimate reasons why a players would be using an unknown client binary?

1 good reason that comes to my mind is that the code is compiled for your processor thus it is better optimized for your hardware. That might be the reason to compile it on your own. Other reasons? Hm, library dependencies on linux for instance, if the official version is compiled on different OS version it's sometimes tough to install satisfying dependencies and it's easier to just compile.

[JvIasterMind]

Ok, got it! Thanks for the info!

[TheSilencerPL]

In next version we added more of the ET:L builds that we were able to find, so now more binaries will be detected thus helping you out with solving the mystery of particular player.

[BECK]

Could you please share them with us?

 JvIastermind posted it.  Thanks.

[Petbark]

Is there away of incorporating a data base of known bad checksums that will either kick or automatically ban players?

I know this is starting down the road of pb.

[MARZ]

look nitmod 2.2.1 beta has a client binary checksum in NxAC anticheat system with autokick for unkown builds  .Default et ,etlegacy ,etgold ,trackbase ET are generally  trusted builds admin can check any unknown build to test it then authorise it in the cheksums config

and i think next release will has a global banlist

dunno of this global banlist is nitmod-only feature or no coze nitmod has many cool features like ingame global stats and global awards

[JvIasterMind]

I like the idea of a checksum config file! However, I think it would be better to allow admins to input checksums that would instantly ban a player connecting with a known malicious binary, instead of disallowing all unknown binaries (since some have legitimate uses as described by TheSilencerPL). By the way, silEnT does allow you to auto kick any unrecognized binaries similar to how you described in NxAC (minus the config file as far as I know).

 

As for a global banlist, I have similar thoughts to Beck and feel that different servers have different tolerances for what is considered enough proof to constitute the ban. I know of quite a few players that were wrongfully banned for hacking, when in reality, they are just good players. I feel it would be terrible if a legitimate player got banned on one server and got onto the global banlist and was unable to play anywhere. If the global banlist was only for binaries that are 100% known to be malicious, than I would be fine with that, but I would want to stay away from as much human error as possible.

[MARZ]

I like the idea of a checksum config file! However, I think it would be better to allow admins to input checksums that would instantly ban a player connecting with a known malicious binary, instead of disallowing all unknown binaries (since some have legitimate uses as described by TheSilencerPL). By the way, silEnT does allow you to auto kick any unrecognized binaries similar to how you described in NxAC (minus the config file as far as I know).

 

As for a global banlist, I have similar thoughts to Beck and feel that different servers have different tolerances for what is considered enough proof to constitute the ban. I know of quite a few players that were wrongfully banned for hacking, when in reality, they are just good players. I feel it would be terrible if a legitimate player got banned on one server and got onto the global banlist and was unable to play anywhere. If the global banlist was only for binaries that are 100% known to be malicious, than I would be fine with that, but I would want to stay away from as much human error as possible.

the global banlist is like pbans a database of anticheat's bans with known built-in hack's build checksums and cheating scripts not admin's bans

[gaoesa]

We will not implement global ban lists. There are many reasons for not doing it.

 

Here are few:

- First of all it needs GUID authentication to prevent GUID spoofing client side. Do note that all GUIDs are spoofable. The way silEnT protect admin leves is separate technique, see g_adminProtection.

- Second, it all needs to be done between the client and the "ban" server to avoid game server influence and admins generating bans for people they don't like. This might also need user consent.

- Third, measures must be taken to ensure the client does not block all or selectively messages to the "ban" server.

- Fourth, even PunkBuster has had problems with intentionally made false bans filling ban lists. This is a typical problem for ban lists when ever people figure out a way to do it.

 

In other words, it is not practical to implement for it's possible value. For couple binary checksums and few cvars that associate with cheats.

[JvIasterMind]

I have a couple feature requests that involve the checksums for unauthorized binaries (sort of on topic).

 

-Could you guys add the checksum to the warning message that displays in admin chat for the unauthorized binary? This will allow admins to instantly ban a player if they notice a checksum that they know is malicious. Today, I had to download our server log and look through it to get the checksum and I instantly recognized it as the wallhack that I listed earlier in this thread.

 

-Currently, the warning message shows up twice... once during warmup and once during the start of the map. Could you guys make it so it only shows up once for each map instead? It starts to get a little annoying when there is a player that isn't raising any suspicion on the server. Also, I have a bug that goes with this. Sometimes the message is not displayed and then displays the next time the message appears (so it pops up multiple times). I have even had it skip a map completely and then show four times on the next map after warmup finished.

 

-Another feature request, (especially if you choose to not implement a config file like I suggested in my last post

), would be to add a callback in the lua api so server admins can implement their own method for dealing with the unauthorized binaries. I am thinking something along the lines of et_UnauthorizedBinaryDetected( clientNum, checksum ). This may even be a better solution because I imagine that different servers would like to deal with this situation in their own way.

 

Thanks,

JvIasterMind

 

 

I like the idea of a checksum config file! However, I think it would be better to allow admins to input checksums that would instantly ban a player connecting with a known malicious binary, instead of disallowing all unknown binaries (since some have legitimate uses as described by TheSilencerPL). By the way, silEnT does allow you to auto kick any unrecognized binaries similar to how you described in NxAC (minus the config file as far as I know).

[gaoesa]

-Could you guys add the checksum to the warning message that displays in admin chat for the unauthorized binary?

Adding full checksum would make the adminchat harder to read.

 

 

Could you guys make it so it only shows up once for each map instead?

This is not possible. The server game reloads after warmup and therefore loses old information.

 

 

Sometimes the message is not displayed and then displays the next time the message appears (so it pops up multiple times).

I have never encountered this myself. I don't know what might be causing it. Maybe the player in question does a lot of reconnecting and downloads the maps during warmup?

 

Adding Lua callback is ok and probably a good addition at the current state of the game. How about notifying in the adminchat more clearly of the known cheat binaries? If they are known to be cheat versions, the Lua callback would not be called?

[JvIasterMind]

Adding full checksum would make the adminchat harder to read.

 

 

This is not possible. The server game reloads after warmup and therefore loses old information.

 

Fair enough!

 

 

 

I have never encountered this myself. I don't know what might be causing it. Maybe the player in question does a lot of reconnecting and downloads the maps during warmup?

 

I will keep my eyes open to see if any of those are related, but it happens with multiple players and one of them is a server regular (so I'm pretty sure he's not downloading maps).

 

 

 

 

Adding Lua callback is ok and probably a good addition at the current state of the game. How about notifying in the adminchat more clearly of the known cheat binaries? If they are known to be cheat versions, the Lua callback would not be called?

 

The lua callback would be a great addition! I would also love the notification to include info on if it is a known cheat binary, because that will get the cheater off the server much faster than if the checksum needs to be read from the server logs. Still, even with this info, I still think that the lua callback should be called. Maybe add a boolean in the callback if it is a known cheat version so it can optionally be dealt with in a different way from the unknown ones.

Edited January 7, 2013 by JvIasterMind