[Firewall] Securing your TeamSpeak 3 server - from a DevOps perspective

[why-am-i-even-here]

Follow up on this post.

This guide aims to provide some ideas regarding how you, as a server administrator, can protect your server against various attacks. This guide does not discuss correctly configuring your server and the permissions system. If you're a server admin, you should already know these things. Instead this guide focuses on constructing an effective firewall for your TeamSpeak server.
Basic knowledge of computer networks and protocols is expected from the reader. This guide is primarily only interesting for admins who host their server themselves. The concepts presented here have been tested in production systems and served me well. If you come from a DevOps / NetSec background, you'll recognize most of the patterns discussed here. This guide contains no code. You'll have to come up with your own implementation.

The ideas proposed in this guide will mainly combat these threats:

• DDoS attacks
• All exploits and hacks based on ServerQuery or file transfer

Since TeamSpeak uses an encrypted protocol we cannot implement a deep inspection firewall, that could actually detect malicious packets. I'm talking about channel descriptions that crash your client / the server, etc. We can however implement such a firewall for the ServerQuery protocol (meh) and for the file transfer protocol (actually interesting, remember the avatar that crashed the client).

First off, some terminology and definitions:

Firewalls
A firewall is a system that is located in between a service and the clients. The firewall is responsible for filtering the incoming traffic and in the best case only allows legit requests to pass through. In our case one could also imagine the firewall as a reverse proxy on steroids. We'll call these access points gateways.

A firewall is only effective, if it can not be sidestepped. Your TeamSpeak server must not be accessible directly by (regular) clients. If your server's running on a machine with a "secret" IP address, that's sufficient, as long as that IP address really is secret and does not get exposed by accident.

Single point of failure
Modern servers are programmed with high availability and reliability in mind. Take most professional websites as an example; Google can reboot servers without a service interruption. It's also no problem when servers fail and crash. The end user doesn't notice this. This behaviour is achieved by using clusters of servers that run micro-services and load balancers.

As we all know, TeamSpeak is a shitty piece of software. If you're running a server, you'll surely have experienced what a SPOF is first-handedly. There's nothing more frustrating than being in a game and then having some 14 years old small-dicked shit-face DDoS your server with a cheap as fuck botnet like exitus.to. And there's nothing you could do about it. And it's not even like it's your fault or that the fucking script kiddy is such a skilled hacker. No. It's the TeamSpeak devs' fault.

Servers do fail from time to time. There is nothing you can do about that. However, you could make it so that the service as a whole keeps up. If only the devs of TS had implemented such a thing as clustering.

Protocols
The TeamSpeak 3 server (and its accompanying services) uses multiple protocols. Most of which are used for "home calling". They can be disregarded mostly. We'll talk about these protocols:

• INBOUND UDP 9987: voice and data
• INBOUND TCP 10011: ServerQuery
• INBOUND TCP 30033: file transfer
• INBOUND TCP 41144: TSDNS
• OUTBOUND UDP 2010: weblist

Naming things
Ask any programmer. Naming things is hard. I'm so lucky I don't intend to have children. So we'll just go with this naming scheme for the sake of this guide: servers protected by the firewall are named after famous scientists, gateways are assigned International Air Transport Association airport codes. How fitting. Assume that the associated A records have been set correctly.

Basic structure
We'll start off with the most basic scenario and then expand upon that.
Okay. So we need to keep our real TS server IP address secret and then proxy all traffic through gateways that act as a firewall. How do we do that?

Well, you'll need at least two independent servers. These can be VPS on different host systems or even two root servers. It doesn't matter for now. One server runs the TeamSpeak server (Einstein) and the other server acts as a gateway (LAX).

Einstein
... runs the TeamSpeak server. There is one important bit of configuration you must not forget: turn off the weblist. If your server broadcasts its real IP address to the TeamSpeak weblist your firewall loses all effectiveness.

LAX
... is a gateway to Einstein. In the most trivial case this means that it forwards all incoming traffic to Einstein and proxies the responses back to the correspondig clients. "All incoming traffic" being UDP 9987 (voice and data), TCP 10011 (ServerQuery) and file transfer (TCP 30033).


What now?
All clients then connect to lax.example.com instead of einstein.example.com. To them it will look like LAX actually is running the TeamSpeak server.

For some admins, this might already be enough and they can stop here. You now have two different ways of accessing your server. The public LAX gateway and the private direct connection. For instance, you could give the secret IP address only to people you trust. This way, if some ass-hat tries to DDoS your server, only the public LAX gateway will go down. But everyone who connected directly to Einstein will not notice anything. Well, maybe they'll notice all clients conencted via LAX timing out.

But hey! No random disconnects for you and your buddies while being ingame. ~~yeah~~

One more thing: Nobody likes remembering names. Be considerate of your users and create an SRV record, will ya?

The weblist
"But w-a-i-e-h, I want my server to appear on the weblist b/c I want moar of dem usas!"

No problem. Just emulate the weblist protocol. It's not very hard to reverse engineer. Sniff the traffic from and to weblist.teamspeak.com:2010 (UDP). If you speak German you might as well read this: http://yat.qa/ressourcen/protokolle/#weblist-server

The emulator should of course run on LAX. Faking the weblist protocol obviously comes with a few advantages. I'm sure you know what I mean.

Stepping up your game
"Two is one, and one is none."

One gateway doesn't really get you anywhere. You don't want to give out your secret IP address. Not even to friends. You'll much rather have different gateways for different groups of users.

It's time to add additional gateways, depending on how many users you have and how much money you want to spend. I recommend a minimum of three gateways.

• LAX: the "default" gateway, regular users connect via this one.
• FRA: this gateway only serves weblist users.
• AMS: the "premium" gateway for personally trusted and / or paying users.

Why give users that connect via the weblist their very own gateway? We have discovered that most of the DDoS attacks are performed by fucktards that randomly connect high-ranking servers. If my penis was ingrown I'd probably do the same to get off.
Luckily, we can isolate this group on their own gateway, so when they do perform an attack, only this gateway fails. Of course you don't want users to permanently connect via this gateway for this very reason. We solve this situation by automatically messaging these users when they've been on the server for more than 2 hours (in total in the last 3 days). No troll invests that much time. In this message we ask them to only connect via our domain example.com (which directs them to LAX) and keep nagging them until they do. Easy as pie.

AMS is the gateway that is supposed to guarantee uninterrupted service to all its clients. Therefore only users of whom you are certain that will not attack you should be able to connect to this gateway.

You can set up arbitrarily many additional gateways. There are many ways in which you can segregate users into groups of varying trust levels. Online time, server group, etc.
However, you now have a problem. How do you tell ther user's client which gateway it should use? Give each group of users their own SRV record? lol nope.

--- snip snip, max post length reached ^^ ---

 

[why-am-i-even-here]

TSDNS
You get to re-implement yet another protocol. Yaaay!

With your custom implementation of a TSDNS server, you can instruct clients to connect to specific gateways, based on the requesting IP address. There's a catch though: You can't know in advance which IP address belongs to which client identity.

That isn't really a problem though. If we cannot associate an IP address with an identity, we just route them to the default gateway. Using ServerQuery we monitor which client connects via which gateway from which port. This way we can build a cache that stores all IP addresses and their associated client identity for up to 3 days. Should the client reconnect in this time frame (and should his IP lease not have run out) we can route them directly to the appropriate gateway.

But isn't routing to the default gateway bad?

Not really. Should it fail, the client attempts to reconnect, but not without requesting a gateway from the TSDNS server first. Since we cached that IP address, we can route the client to the correct gateway.

Resiliency through redundancy
You now might have a structure similiar to this:

• Einstein: the one server running your TS server
• LAX: default
• FRA: weblist
• AMS: highest trust level
• various additional gateways for discrete groups of users

There are two critical single points of failure in this architecture: Einstein and LAX.

We'll start with the easy one: LAX. You only have one default gateway, although especially the default gateway is threatend to fail, because it a) probably has the most users and b) most of the DDoSers (right after FRA). So what do we do about that?
Simple. Increase the number of default gateways. You can easily distribute users across multiple default gateways using your TSDNS system.

This way, if one gateway fails, not all default tier users get disconnected, but only a fraction, depending on the number of gateways. Even better yet: you can monitor the gateway's statuses and reflect failures in your TSDNS system.

The TS client waits for (painfully long) 15 seconds, before it decides that a connection timed out. This is plenty of time to detect a failure in advance and act accordingly. Besides alerting your staff the routes in the TSDNS server should be reconfigured automatically. We do that after a gateway hasn't responded to our health checks for 5 seconds. This way, when all timed out clients attempt to reconnect after 15 seconds, they already get re-routed to a working gateway.

We implement the same logic for all "premium" gateways as well. While it's unlikely that the premium gateways fail because of an attack, they do still fail occasionally for various other reasons.

When you're creating additional gateways (and main servers), don't use only one hoster and one data center. The idea is to spread your services across as many availability zones as possible. I think it should be obvious, as to why.

Fun fact: 99.99 % of all attackers are fat, ugly pubescnent boys with manginas that get clobbered on the playground. To compensate they spend their nights watching BDSM porn and "hacking" (lol) TS servers with botnets they rent for $5/month. Wow, such skillz.
Did you know, that all of these botnets enforce a concurrency limit? Yep, Mr. Mangina can only execute one attack at a time, if he doesn't want to spend way more money. So, if you're running multiple default gateways, you're basically immune.

Shit's only getting better from here, and we haven't even yet touched intrusion detection and intrusion prevention systems!

But before we do that, let's talk about our lonely scientist. Einstein needs a friend. It would be very unfortunate, if Einstein died and nobody was there to pick up his work. So let's roll in (hah!) Hawking.
Our gateways are now redundant and highly available. But the TS server itself is not. In a perfect world, that wouldn't be a problem. However, TS servers like to crash. Especially when users abuse exploits. Besides that, Einstein himself could also crash.

There are many ways with which you could achieve redundancy for the TS server itself, but I'll summarize how we do it: instead of using the default SQLite backend, we use a remote MySQL database (cluster). This way we can spin up another teamspeak server with the exact same data in a matter of seconds. Keep in mind that there are additional things to be thought of, but I'm too lazy to go into detail about them now. Just some buzzwords: files, database integrity, backups, fail safe rollbacks, license files (lol), serverkey, etc.

This additional layer of redundancy adds quite a bit of complexity to the code of the gateways, but it's worth it. Trust me. It might also be total overkill for you. It all depends on the size and purpose of your organizaton. But now, on to the fun part!

Intrusion detection and intrusion prevention systems
It's time to teach your gateways some tricks. There's a myriad of things you can do now. I'll just mention the absolute minimum. You'll have to discover / invent the rest for yourself.

• flow control
• ServerQuery command whitelisting
• complete ServerQuery emulation
• file transfer limits
• stateful IP whitelisting / blacklisting

If your hoster offers a hardware firewall, you can even blacklist offending IP addresses.
If you look closely and log well, you'll find some interesting patterns that you can use to further harden your security. There are also ways of making attackers believe that they actually succeeded with their attack, so they won't continue to penetrate your system.

And while we're at it (making things smarter), you can also optimize a few bits here and there, as well as make things look better than they really are (*cough cough*).

Wrapping up
Things you'll need:

• One or more secret servers that host the TeamSpeak sever
• One or more public servers that host the gatway software (recommended 3+)
• A weblist emulator (running on one gateway server)
• One or more TSDNS servers

Protocols the gateways have to implement:

• UDP 9987: voice and data
• TCP 10011: ServerQuery
• TCP 30033: file transfer

There is so much more that you can do, once you have everything up and running. We barely scratched the surface with this guide. But I won't disclose all my secrets and I kinda wanna stop typing now. This thing got way too long already. Haha.

One last tip maybe: when you actually try to implement a gateway, start with the UDP reverse proxy. It's the hardest and most important part. Also use a fitting language. While you can do this in Node.js or Python, you really should not.

Anyway, I hope this is of help to some admins around here. Surely I missed something, but I'll edit it in, if something pops my mind. If you have questions, don't be afraid to ask. The worst that can happen is that I don't answer them or laugh at you, although I'll try not to.
Edit: Also do read the rest of this thread. I already shared some further "secrets".

If I can be arsed to it, I might even draw some graphics or post screenshots of our monitoring interface. But I'm sure you'll all get the idea.

 

[denka]

Using wireshack won't the ip be visible?

 

[why-am-i-even-here]

Please be more descriptive. Who uses Wireshark where to display which IP address?
I assume you mean the secret IP address of the Einstein server. And no, there is no way for the attacker to find the real IP address, if that's the question.

 

[Phyx]

I am at work right now and just signed on ONLY to say thank you so freaking much. This is the most useful TeamSpeak Server Security tutorial I have read in --- well, forever. This is golden right here, I am now willed to make a video tutorial discussing this (credits to you at the beginning).

Additionally I would like to add to

turn off the weblist. If your server broadcasts its real IP address to the TeamSpeak weblist your firewall loses all effectiveness.

Whitelist only yourself properly (so only you have access) and the LAX just as an extra measure? I did not make it through the whole thread although I plan on reading all of this when I get home. Very great work though, thanks so much for this.

Doing a quick search --- I may have spoken too early (sorry if I did).

 

[why-am-i-even-here]

Whitelist only yourself properly (so only you have access) and the LAX just as an extra measure?

Of course there are additional security measures, that can and should be taken:

• Change the default ports on the backend server, so that even if server was scanned randomly the port scanner could not deduce which services are running.
• Optionally create an iptables / hardware firewall whitelist, so that only registered gateways may establish a connection. Personally I would not add myself to the whitelist, as my IP lease is often limited to 24h an that would get pretty tedious after a while. However, you can even automate that.

That's security through obscurity. Even if an attacker randomly get this IP address, to him it wouldn't look like there's a TS server running. In practice this isn't really necessary, but it can't hurt; it only adds a bit of configuration overhead.

I'm happy you find this helpful.

 

[Phyx]

This thread reminds me of a "DDoS protection" idea I had for TeamSpeak 3 with the utilization of a free CDN (CloudFlare) and a plugin. This would require:
1. Web-server properly secured behind a CDN (CloudFlare), with enforced HTTPS just because.
2. A simple TeamSpeak 3 plugin which hits protection.example.com, from the web-server, the TeamSpeak 3 server adds the CF-Connecting-IP to a whitelist.
3. This is done on each connection automatically to protected servers for people with dynamic IP addresses. This would also help mitigate bots somewhat, although this is more of an obscurity method.

This would be a VERY simple way for people to lock down their servers from the UDP floods people were doing a little while ago. Your method is definitely much better though (I am so excited, thanks man).

If a dialog window could be opened which made the user click a link/button to fill out a quick CAPTCHA prior to being whitelisted --- there we go, this together in combination with your above methods would be neat.

 

[why-am-i-even-here]

Just to make sure I understood correctly. The TS client has to have a special plugin installed.

1. When the TS client attempts to connect to a TS server on example.com it first hits protection.example.com
2. protection.example.com is protected by CloduFlare and saves the client's real IP address to a whitelist
3. The client then connects to the TS server
4. The TS server (or some kind of intermediary software firewall) checks the whitelist for the IP address, that was previously saved
5. If the IP address is found, a connection is established
6. Otherwise, the connection is silently dropped

If this is your concept, I see multiple flaws. The first obviously being the "poor" UX. Users have to install software / a plugin before they can even access your server.
Besides that, this isn't really effective. As the IP address of the TeamSpeak server is known at all times, an attacker could easily perform a trivial layer 3 attack.

Today's DDoS attacks oftentimes don't target the TeamSpeak server itself (as there's no real DoS vulnerability), but rather just use up the whole bandwidth with their sheer volume. No software firewall can protect you against that. Of course there are ways in which you can try to down a TS server without clogging up the link layer, like opening thousands of connections with TS3INIT packets. However, I'd make the bold statement and claim that the TS server handles this quite well actually. It's just more efficient to send as much garbage as possible and perform a trivial layer 3 attack. As sad as it is.

It's quite funny actually: We analyzed the exitus.to TeamSpeak 3 attack and they actually attempt to perform a layer 7 attack, i.e. establish thousands of connections via TS3INIT. Of course we can easily detect things like this in our gateways. And we do block these kinds of attacks.
The problem is that exitus.to has such a big volume, that they effectively perform a layer 3 attack on our gateways and not a layer7 attack, which we would have averted.
Smaller scale attacks of this layer 7 kind are consistently and successfully defeated by our algorithms.

This doesn't however mean that this whole whitelisting concept is unusable. In fact you can apply it, if you have configurable hardware firewalls. The only disadvantage of these things is that they often take a few seconds before rules are applied. However, that's no problem, as detailed in the TSDNS "chapter".

 

[Phyx]

TeamSpeak 3 (server) was vulnerable to a UDP flood DoS if I'm not mistaken. See: http://forum.teamspeak.com/threads/119710-TeamSpeak-Server-Hotfix-3-0-11-4-released (find "DoS"). This method would obscurely protect against said attack, specifically it would provide very basic L7 protection.

If this method was paired with your method, it would provide additional obscurity from specific attacks such as a TeamSpeak 3 bot. It is in the works a TeamSpeak 3 bot capable of joining a server from multiple IPs (proxy bot flood) filling slots.

Ideal setup:

1. Einstein with TeamSpeak 3 server.
2. CDN/WAF/ reverse proxy: incapsula/CloudFlare/Sucuri
3. LAX

CDN/WAF ---> LAX ---> Einstein = Einstein is doubly protected both from L7 attacks and many other attacks from the LAX middleman connection. The point of the CDN/WAF connection is to potentially provide a CAPTCHA to prevent automated connections (as easily). This hinders bot connections.

Additionally the CDN/WAF would pass along rules to whitelist connections to the LAX. This means that no one can even come close to touching Einstein without entering a CAPTCHA successfully and then being whitelisted.

Unless..... someone really wants to sidestep this, which I mean it is just obscurity.. obscurity is not intended to be bulletproof, just to make the potential attacker get bored and move on (which works a lot of the time).

 

[why-am-i-even-here]

Ah, I understand.

CloudFlare and co. can only ever be used to implement some kind of whitelist to give additional protection against layer 7 flood attacks. However, that's a lot of hassle. If I wanted to, I could implement that one easier by generating a captcha myself or requiring users to log in on my website first.

Our system already performs a packet flow analysis and various deep inspection checks. Flooding on layer 7 is impossible through our gateways. We also cross-reference connections with actual clients on the server and immediately identify "faked" connection attempts. These addresses get blacklisted right away.
We also detect sudden surges in connections from new IP addresses, especially if they're not coupled with TSDNS requests and focus on one gateway, which is a dead giveaway for an attack, not necessarily (D)DoS, but possibly a "slot filling" bot like you suggested, especially if these client identities are unknown to the server.

We didn't train our gateways for this kind of attack specifically, but I wouldn't be surprised, if they would detect it nevertheless. We also implemented various levels of "lock down" modes that prevent such things automatically. But for that I'd need to go into greater detail.

And primarily, we're fighting layer 3 attacks here. These flood or slot filling attacks... I wouldn't even really call them layer 7. They're some weird thing in between. They don't really abuse any protocol specific weaknesses, but rather do some more "advanced" form of DDoS. And this is still pretty easily detected and averted. ^^

But if you really like that idea so much, go ahead and implement it.
It's just that I don't believe that it adds effective value for all the additional hassle we and the users have to go through. Furthermore, by implementing this plugin requirement, you're stone walling yourself from everyone else. No one who doesn't know (and does not get told) about your server, will find it. You could just as well run TS on a non standard port and only give the address to friends.

 

[Phyx]

You could even skip the plugin if you really wanted (that part is quite a bit unnecessary), only requiring the person to access a website address via browser. Layer 7 attacks are very oftentimes hard to detect due to them resembling real traffic whether it be website traffic or TeamSpeak 3 user connections.

If the LAX could emulate a server quit message informing the user they are NOT on the whitelist with a link to the address where they enter a CAPTCHA and their browser is checked, that would be pretty cool (I think).

 

[why-am-i-even-here]

If the LAX could emulate a server quit message informing the user they are NOT on the whitelist with a link to the address where they enter a CAPTCHA and their browser is checked, that would be pretty cool (I think).

Not (conventionally) possible. This would require the gateway to know the encryption algorithm.
If you want to go down that road you could allow a connection for the first time, poke the client via SQ and then force quit it right afterwards by severing the connection.

Layer 7 attacks are very oftentimes hard to detect due to them resembling real traffic whether it be website traffic or TeamSpeak 3 user connections.

So, there are three cases:

1. The connection is faked entirely and they try to flood open as many connections as possible.
2. The connection is initiated by a real TS client and they try to flood all available slots.
3. The connection is actually legit and it's a real user (no hacker).

Case #1 is easily detected and averted. If you want me to give some details about that, I'd assemble a quick list.
The real problem is discerning #2 and #3. Your proposed solution is indeed valid here. But there are a few other tricks in the book.

This goes a bit into our "lock down" levels, but oh well. ^^ For each client we calculate a score. Each client starts with 0. The lower the score, the higher the possibility that this is a faker. The higher the score, the lower the possibility that this is a faker. There are many circumstantial factors and statistics, as well as behavior analysis that feed into the calculation. But as soon as the score falls below a certain threshold, the client gets kicked and the IP address blacklisted. In the kick message the client gets a link to our website, where he can appeal the ban. So even if we wrongfully ban someone, they can come back.

The threshold isn't fixed btw. It changes throughout the day depending on various factors like number of users, time, number of new users in the last x,y,z time intervals, number of reoccuring users, timeouts, etc. A lot of stuff. As a normal user, especially if you've been on our server a few times before, it's almost impossible to get below the threshold, except you're really pushing it by spamming, etc., and in that case it's even desirable.

Fake clients however are consistently identified. A huge help already is the approx. geo location of the IP address. Foreign IPs already start with a negative score for example. When you think about it, detecting spammers and fakers is easier as it seems. And in the event of almost no available slots left, inactive guests are kicked in favor of registered members.

 

[skill1917]

How do you deal with bans? Afaik you can't disable TeamSpeak's automatic ip ban, and if you use some reverse proxys then you wil ban the whole proxy and we don't want that, right?

 

[Derp]

How do you deal with bans? Afaik you can't disable TeamSpeak's automatic ip ban, and if you use some reverse proxys then you wil ban the whole proxy and we don't want that, right?

I don't think that's a problem at all

I wouldn't even use teamspeak's default ban system, I would directly block that ip from communicating with the gateway

 

[why-am-i-even-here]

Interesting question. I was gonna bring it up, but forgot it over the course of the day. Thx for reminding me.

Whenever you ban someone in TS not only the identity is banned, but also the IP address - which is fatal when using reverse proxies. We therefore disabled the anti-flood system and revoked all permission required for banning.
Instead we implemented our own ban system. We either blacklist the IP address, so they cannot connect anymore at all, or automatically assign a specific group to all identities connecting from that IP address. This group effectively bans them, but they can still look around the server and mourn us.

Basically what @Derp said.

 

[skill1917]

Also imo it's not needed to emulate the weblist protocol as you can just edit your host file to point the weblist reporting to one of your gateways and just proxying that as well.

 

[User_418]

Interesting question. I was gonna bring it up, but forgot it over the course of the day. Thx for reminding me.

Whenever you ban someone in TS not only the identity is banned, but also the IP address - which is fatal when using reverse proxies. We therefore disabled the anti-flood system and revoked all permission required for banning.
Instead we implemented our own ban system. We either blacklist the IP address, so they cannot connect anymore at all, or automatically assign a specific group to all identities connecting from that IP address. This group effectively bans them, but they can still look around the server and mourn us.

Basically what @Derp said.

You can ban all nicknames using regexp .* and assign ban bypass permission to all groups but that "Ban" one (as you've said you completely removed banning). It'll ban identity after first join, if bot assigns that group and kicks client.

 

[MazeMcRoy]

Also imo it's not needed to emulate the weblist protocol as you can just edit your host file to point the weblist reporting to one of your gateways and just proxying that as well.

Yeah but how do you do the magic stuff to the weblist with your technique?

 

[why-am-i-even-here]

Also imo it's not needed to emulate the weblist protocol as you can just edit your host file to point the weblist reporting to one of your gateways and just proxying that as well.

You could. But it's definitely easier to emulate the protocol IMO. And it gives you some special abilities, as MazeMcRoy just underlined.

You can ban all nicknames using regexp .* and assign ban bypass permission to all groups but that "Ban" one (as you've said you completely removed banning). It'll ban identity after first join, if bot assigns that group and kicks client.

I don't really see any use in that. If I understand correctly, every client would be banned by default and would have to be unbanned manually. However, you cannot easily do that as the client ID of these "auto-banned" clients is not logged in a way the bot could see them AFAIK. This also makes for a pretty poor UX: trying to join a server, being banned "instantly" and having to retry joining?
Correct me, if I misunderstood you.

Of course everyone can adapt our system as to how it might fit their use case in the best way. This is what serves us best so far.

 

[bl4uni]

I think the guest group would also have ban bypass permission, just the "Banned" group wouldn't have. So nobody would be banned by default. Still, pretty much work just for a working ban system, easier to ban ipranges and if someone comes back just ban him again. Nobody will try 100 VPNS just to be annoying and in the end you would have every VPN banned.