|Anonymous | Login | Signup for a new account||2020-08-13 11:58 UTC|
|My View | View Issues | Change Log | Roadmap | Zandronum Issue Support Ranking | Rules | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000038||Zandronum||[All Projects] Suggestion||public||2010-09-19 21:23||2016-07-17 21:22|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Target Version||Fixed in Version|
|Summary||0000038: "sv_externalbanfile" replaces master banlist|
|Description||I have found out recently that 98c seems to take your server off the master banlist if "sv_enforcemasterbanlist" is false. It also appears impossible to whitelist IP's that are on the master banlist.|
Instead of a banlist which is distributed by the master server, I have a much better idea, a new variable called sv_externalbanfile. This variable would be set to a webpage where a hosted banlist is retrieved, in plain text, in a similar format to the existing banlists. By default, it would point to the a banlist hosted by skulltag, but it can be changed to another external URL if desired.
Whitelisting should also take priority over the both the local and external ban file. This is so if we get a user who is caught in an IP range ban meant for someone else, we can unban them manually.
|Additional Information||Some thoughts on why a centrally managed banlist is a bad idea:|
Torr Samaho (administrator)
I pretty much agree with your blog post, but I'm not the one who needs to be convinced (if it was just for me, the master ban list would never even have been broadcasted to the servers). If you want a way to disable / whitelist any of the master bans on a server but still have that server listed on the master server, talk to the master server admins and convince them to allow this.
Once this is done, we can start talking about how to implement this. For instance, having the local whitelist take precedence over the master banlist is trivial to implement.
If we broadcast servers that use whitelists, it's the same as broadcasting a server that doesn't enforce the master banlist, since someone could simply whitelist arbitrary hackers or even whitelist everyone.
That said, I'm in favor of a "shield icon" system. In Doomseeker/IDE, servers that strictly enforce the master banlist would have a shield icon next to them, showing that they are secured against hackers. Servers that don't enforce the master banlist, or use a whitelist, would have some kind of alert icon in place of the shield icon. Additionally, a player will be asked for confirmation when they try to join a server that doesn't enforce the banlist, asking whether they truly want to join that server. However, this confirmation dialog could be turned off in the options.
This system would allow some groups of players to play in "safe" servers without hackers, while allowing other groups of players more freedom by letting the server hosts manage their own banlists. I'm willing to work on both Skulltag and Doomseeker to make this a reality, but I am not sure what would have to be done for IDE.
I also like the idea of allowing people to grab an external banlist, as a separate feature.
|I can't remember if we had a reason against it or if my posts just got ignored, but I originally suggested making the list of servers which don't enforce the ban list opt-in (check box in the Doomseeker config "See all servers including those which don't enforce the ban list"). Of course the default would be to not list them.|
edited on: 2011-02-07 17:16
I actually have misgivings with the VAC shield system. I think it's perfectly acceptable for a paid game, but for a free one, I think there is an issue.
First, ask yourself why you would want to not use the master banlist as it's handed out now? There are two reasons:
1. You are hosting a "Legitimate" server that happens to be inconvenienced by the master banlist that is in place.
2. You are an abusive server trying to fuck with Skulltag players by attracting hackers, using your server as a hack testing ground against unsuspecting players, etc.
Number 1 is how FUNCRUSHER+ was for a period of 3-4 months after some community drama necessitated it. In this case, if VAC shields were used and filtered out, I would lose many players who would think that my servers simply shut down for one reason or another (when they're actually just being filtered out), and why not filter by VAC because those servers are full of hackers, right?
Number 2 is the reason that the master banlist was forced on in 98c, if I recall correctly. However, I think that this was the complete wrong reaction. A forced master banlist targets bad clients who are joining servers, when what you actually wanted to take care of was malicious server admins "attacking" the master server with "poisonous" servers. Hosting a server that attracts hackers is no better, in my opinion, than someone who spams the master with tons of bot servers and a rude message in the hostname, and should be dealt with similarly, using an IP block at the master level to prevent them from reporting to the master and a limit to the number of untrusted servers at the same time. You don't need an enforced master banlist for that.
To summarize, having a "trusted" shield only hurts legitimate server owners who are inconvenienced by the master server forced banlist, while actual malicious servers can be IP banned and untrusted ones throttled. In fact, with sv_externalbanfile, you can conceivably have a right click menu in Doomseeker that links directly to the banlist in question so you can see for yourself what IP's the server bans.
Torr Samaho (administrator)
edited on: 2011-02-09 12:21
I never liked to enforce the master banlist, but the current hiding system is the only compromise I could find that on the one hand the master server admins accepted and on the other hand still leaves full control of a server to the server runner.
The people who fought for the banlist enforcement all retired by now, so probably the current admins think differently. You'll have to discuss with those people though. In case they agree not to hide servers which don't enforce the master bans, they just need to restart the master with a different option. When implementing the hiding, I made it optional from the get go.
|I will do so. However, in the meantime, do you have any thoughts on sv_externalbanfile itself? Would having it grab a webpage be feasible? What about multiple sources (sv_externalbanfile "http://www.skulltag.com/bans.txt /opt/skulltag/lists/banlist.txt")?|
|I was working on an HTML parser for a raw banlist. I was thinking the sv_externalbanfile would point to (as Alex posted) a link? I have the code to open the website and parse it, though it's sort of borrowed for proof of concept from some random C++ forum.|
|Why would it need to be html-parsed anyway? Aren't banlists usually just plain text? :?|
|I'm not sure of how well C++ parses internet files, though that's true that there won't be (or ideally shouldn't be) any HTML in a banlist. I've got a basic program that actually parses a website well, but I'm unsure of how to handle users putting in malformed URLs or weird timeout's happening and such.|
|I'm gonna go ahead and bump this. I disagree with having the master banlist "off" by default. That would be terrible. I also don't completely agree with public servers being able to whitelist people who are master banned. However, if we were to allow it, and in this case the majority would probably rule it forward, I would really highly recommend flagging servers in Doomseeker and IDE that use this feature as "insecure" or "untrusted".|
|This can also be done but we'd need something like cURL to be used, it's a widespread library that is used to parse websites and such. This would effectively allow us to maintain a master ban list and people may opt out of it. By default it would be on. Also it should flag as "unsafe/insecure" if not pointed to zandronum.com/banlist.txt or wherever it's stored.|
edited on: 2013-12-03 00:47
This has come up again, and I actually think that in lieu of my plans of grandiose distributed login system (that I haven't really worked on at all, so blame me), the "Trusted Shield" would be a reasonable compromise.
Here's something that's a little more formal:
* Servers report to clients a 'trusted' variable which can be on or off. The trusted variable is read-only and can't be modified directly.
* Servers can either shut off the master banlist wholesale or whitelist masterbans. However, if either is done, the trusted variable is shut off. Otherwise, it stays on.
EDIT: Apparently there was "trusted icon" functionality at some point
but it broke recently. Once that is fixed, I think the only remaining step is to change the master to not delist people for not using the master banlist. A HTTP banlist system can come later.
edited on: 2016-06-25 23:58
Hey, sorry to revive this years-old ticket but I was just wondering what the status of this change is? Please correct me if I am wrong but this is what I seem to have so far:
1. sv_enforcemasterbanlist will be optional and servers choosing not to use the master server banlist will not be removed from the master server.
2. Servers with sv_enforcemasterbanlist enabled will be displayed on clients (Doomseeker and Doom Explorer) as having a (shield?) icon, similar to VALVE anti-cheat.
3. sv_externalbanlist would presumably be able to take a list of banlists so that server hosts can have an easier time. The goal here is for readily-available http-banlists to be mixed and matched until desired results are achieved (for instance, a DNSBLacklist similar to things that popular IRC modules use, a banlist only for cheaters, and more).
Am I correct in assuming these three ideas are the core concepts of this change? I'm not a Zandronum developer but I've done my fair share of C++ and these don't seem like hard changes to implement. I can provide a proof of concept and submit a pull request in the near future if this is okay?
edited on: 2016-07-17 21:22
I think with the new master server policy of only banning cheaters, I think the need for this feature has been obsoleted and this should not be implemented. Too much work for no good reason.
|Only registered users can voice their support. Click here to register, or here to log in.|
|Supporters:||unknownna Combinebobnt Soul Argentum Watermelon Catastrophe Ral infurnus S.S.M. AlexMax Ru5tK1ng Yorick Ivan Medicris Darkener DevilHunter Leonard Mobius Razgriz Decay|
|Opponents:||No one explicitly opposes this issue yet.|
|2010-09-19 21:23||AlexMax||New Issue|
|2010-09-19 21:39||Torr Samaho||Note Added: 0000102|
|2010-09-19 21:39||Torr Samaho||Status||new => feedback|
|2010-09-21 00:22||Spleen||Note Added: 0000118|
|2010-09-21 01:12||Blzut3||Note Added: 0000120|
|2011-02-07 17:13||AlexMax||Note Added: 0001015|
|2011-02-07 17:13||AlexMax||Status||feedback => new|
|2011-02-07 17:16||AlexMax||Note Edited: 0001015||View Revisions|
|2011-02-09 12:20||Torr Samaho||Note Added: 0001028|
|2011-02-09 12:21||Torr Samaho||Note Edited: 0001028||View Revisions|
|2011-02-09 12:21||Torr Samaho||Status||new => feedback|
|2011-02-11 17:03||AlexMax||Note Added: 0001040|
|2011-02-11 17:03||AlexMax||Status||feedback => new|
|2013-03-12 04:20||Watermelon||Note Added: 0006107|
|2013-03-12 14:31||Dusk||Note Added: 0006108|
|2013-03-12 15:45||Watermelon||Note Added: 0006109|
|2013-03-24 18:59||Metal||Note Added: 0006171|
|2013-03-24 19:56||Watermelon||Note Added: 0006172|
|2013-12-03 00:11||AlexMax||Note Added: 0007661|
|2013-12-03 00:41||AlexMax||Note Edited: 0007661||View Revisions|
|2013-12-03 00:47||AlexMax||Note Edited: 0007661||View Revisions|
|2014-06-15 14:47||Watermelon||Status||new => acknowledged|
|2016-06-25 23:55||GramGreen||Note Added: 0015113|
|2016-06-25 23:58||GramGreen||Note Edited: 0015113||View Revisions|
|2016-07-17 21:22||Dusk||Note Added: 0015367|
|2016-07-17 21:22||Dusk||Note Edited: 0015367||View Revisions|
Questions or other issues? Contact Us.
|Copyright © 2000 - 2020 MantisBT Team|