On one side, you need a web-server hosting a banlist file. Adding, deleting, commenting is done manually by whoever volunteers to maintain the list. The syntax should be bans_by_ip.pl compatible. The only thing required here is a syntax checker.

On the other side, you have for every server a bans_by_ip.pl with it's local banlist (server-specific bans, possibly an empty list). These could be hosted anywhere (on the game server, on the web server or a third computer). One would have to extend bans_by_ip.pl with the functionality to download a list via http every n minutes. One should also add a local whitelist functionality (Example: whitelist: 127.0. # allow localhost). Both things are easily implemented.

Is this what you had in mind? It is certainly a simple, low-tech solution using mostly what we already have.

Other modules to take note of:Authen::Libwrap (TCPWrappers/Hosts File Access)

Reasoning:1.) Sleeping infinite runtime programs are unnecessary2.) Avoid possible locking issues3.) Avoid possible locking/permissions issue, aid exception handling4.) No need to say why5.) To aid for comparison need6.) In case one server versus the others has additional entries7.) No need to rewrite and use extra disk i/o as a comparison was done8.) So administrators can get a digest 9.) Prevent buildup, simplify what was actually done10.) Central server should be aware of all of the bans which were added and make all involved admins aware to prevent abuse

We seem to be having some odd behaviour in Jeux with the script. Earlier NUB Muffin told me he could re-connect after initial removal and not be kicked, today mly observed this:

14:27 <mouly_jr> weird stuff just now14:28 <mouly_jr> I saw wb/phantom (89.244;x;x) get kicked forom the script14:28 <mouly_jr> he reconnect14:28 <mouly_jr> and was not kicked14:28 <mouly_jr> later another 89.244 connected and he was also not kciked14:28 <mouly_jr> and later rcon addip to ban other players didn't work either

Looks like if the person reconnects during one script's cycle, it later might get ignored for some reason. I'm still trying to produce this reliably and see how the script can be bypassed - can't really nail the particular problem with it. Might be a problem with recognition - might also be a problem with kicking itself. I can't access log easily, when one of roots is online I'll try to share what script spits when ban is circumvented.

No. The script is basically a continuous loop which first queries "rcon status" and then checks the IP of every player against the banlist.

I'll assume1.) you have banned a certain IP segment (e.g. 89.244.) and 2.) you have seen the ban working once and 3.) you did not change the banlist in the meantime and4.) a previously kicked player, reconnecting with the same IP 89.244.*.*, was not kicked again in the following 10-20 minutes

Then, the problem must be repetitive, meaning it occurs in every iteration. Because, even if kicking a player fails once, in the next loop, all IPs are checked again. As a banned player, you are not safe even if you managed to connect to the server. I speculate, either

You can confirm or exclude C by checking the log whether the script did detect the unwanted player. I can test B, if you do a \condump of a manual "rcon status" when you observe faulty behavior. If A is the problem, you should have problems to query the status yourself.

Be aware, if the script misses a status, it will sleep for 30 seconds to give the server a chance to recover. If it fails to query the status for ten times (e.g. server down), it will sleep for 5 minutes. During sleep phases, no checks are done (the server is 'unprotected' during these times). As soon as a status is received, all IPs are checked again. One could call this a best effort protection.

5 minutes sleep caused by missing a status looks like very probable reason of the issue. All players rejoin a few times having been kicked until they eventually give up. Phantom yesterday rejoined 19 times before he gave up.

Logs say nothing is wrong. I think it wouldn't be a bad idea to include information missing the status and information about sleeping for 0.5 and 5 minutes in the log.

In the long run, if the script turns into a more complex admin tool, it could get a feature of banning people temporarily for n hours if they make x reconnections during y minutes. It'd require measuring length of g_banips if there's space for extra bans, adding a ban, measuring time and then removing the ban after that time passes. It'd be an overkill to write it now for our limited uses - but it's not a bad plan to prevent DOS-ing when the script is more widely used.

I've updated the script (details in second post, download link as in first post), adding the global banlist functionality.

rane wrote:5 minutes sleep caused by missing a status looks like very probable reason of the issue.

After going through the code, I was able to identify the responsible bug: the fail counter was not reset in case of a successful status query. Instead, missing statuses were added up until the limit of 10 was reached, triggering the 5 minute sleep phase.

rane wrote:I think it wouldn't be a bad idea to include information missing the status and information about sleeping for 0.5 and 5 minutes in the log.

Done.

rane wrote:It could get a feature of banning people temporarily for n hours if they make x reconnections during y minutes. It'd require measuring length of g_banips if there's space for extra bans, adding a ban, measuring time and then removing the ban after that time passes.

Using g_banIPs is a good idea I picked up. However, I followed the simpler idea to just add the last triggered IP-prefix to g_banIPs (if the value of banIPs is less than <200 characters). The script removes it's previously added IP-prefix beforehand to prevent the growth of g_banIPs.

Red agreed to try out the script for Rawhide. This gave (and continues to give) me the opportunity to test this script under real-world conditions (= lag, packet loss, ...) and to revise it.

Another idea I had would be allowing script do "dumpuser" everyone who's on the server and then letting it ban people based on GUID which is displayed there.

But that would require figuring out how to "dump" players who have spaces in their nicknames or other special characters. Because there's no "clientdump" for dump like there's "clientkick" for kick allowing to use ID instead of nickname as an attribute.

Turk wrote:We rent our linux servers with limited access. What can we do if anything to help us and the community?

The above script is designed so that it can run on any other computer with internet access and Perl (interpreted computer language; found on any Unix/Linux system) installed.

If you or a trusted friend have/has access to such a server, you can download, edit (=configure) and run it yourself. Otherwise, I can offer you to run the script for you (in the same way I do for Rawhide). In that I case, you would have to entrust me with your RCON password (for this sole use). Write a mail to oa.doctor@gmail.com.

The script provides it's own in-game RCON-based user interface (as described above). But it can also read an external "global" text file such as http://bb.smokin-guns.org/lists/ip_banlist.txt. (If you use IE, you need to manually copy the URL into the address bar and type in the username admins and the passwort cooperate.

Meaning everyone who has IP starting with 1.2. is banned except for 1.2.3.4. This would allow to ban those cheaters within wide ranges provided by for example Deutsche Telekom without banning innocent people who only would need to register new address with admins to get access to the server.

For some examples, Ger Saske shares IP range with quite a few German players, Dago and Daber among them. RP Highsteric and Remover have a cheater in their range called LG Confused. NUB Ron shares provider and range with half a dozen of Israeli players. There are some nasty Greek teamkillers sharing IP range with our admin, Myrmidonas.