It is currently better than what is happening with teamspeak, a few hosts I work with, even wanted to speak with teamspeak developers to fix the problem, but they do not reply anybody.
So if we don't have any reply, we have to check for alternatives, it is all what is left for us.
I think you have someone specifically targeting you, and I bet they won't stop with just ddosing, but pursue other methods. Try to find out who it is and take action.
I wrote about me and my clan experiences with discord, the voice delay/cutting is unbearable as well as the long loading screen. We were on TS first then moved to discord and now are back with TeamSpeak. It's just discord has had they're moments of being unable to connect to their servers. It's a whole other mess.
You can't use Cloudflare because Cloudflare only allows TCP packets through. They are primarily for protecting websites not real-time applications.
If you were to use another DDoS protection service that allows UDP through it would work, providing you buy the correct plan for the size of attack you are having. You could also purchase hosting from a hosting company that has DDoS protected servers.
When you're hosting the TeamSpeak 3 Server on your own machine, protecting it agains DDoS attacks is your responsibility. Whereas it's the responsibility of the host provider to do so when you're using TeamSpeak as a managed service (e.g. renting from an ATHP).
As mentioned before, Cloudflare is a reverse proxy, cache, firewall and global content delivery network fore websites... that means HTTP/HTTPS only. Ergo, it can't be used to protect TeamSpeak servers.
In the past, we've done quite a lot to protect our software from specific types of DDoS attacks (an we'll continue to do so), but that is only possible up to a certain limit.
Also, while we removed the servers IP address from the UI with one of our recent client releases, please note that this is not protecting you in any way... it's simply a filter for the really (really really) stupid script-kiddies.
It's not overly complicated just expensive. I've set it up in the past and it really wasn't that hard. However if your current hoster can't give you the size of the attack then it's a bit hard to judge the amount of protection you would need.
I'm not talking about setting up and configuring your own equipment, that would be far more complicated, I'm talking about setting up protection probably via a GRE tunnel. Also if your talking about DDoS protection for a hosting company then yes it does get harder to implement.
The DDoS protected hosting is probably the best/cheaper option however.
And as ScP said before this isn't a Teamspeak problem. If people are just blasting your IP with garbage traffic it doesn't really matter what service your running on your server.
Last edited by H3LLFIRE; August 22nd, 2016 at 01:01 AM.
One of the hosts we work with, had a good idea which consisted in you making the login procedure of teamspeak as TCP and triggering some sort of bash-script in the server-side with the user IP, this way we could use firewall APIs in order to "fully secure" the teamspeak server, is it so hard to be done ? Because, as soon you do it, you'll see all these complaints decreasing massively.![]()
You think it is a matter of money ? Not for us, we've paid a lot of money to all sorts of companies and failed greatly, budget isn't our issue, a consistent and stable server is, for sure, mainly when "hackers" are working 24x7 testing our servers, trying to find ways to crash/down it at all costs. (And most of the attacks causing these issues, are really small ones, at rates like 50~100 Mbps, the large ones up to 50~100~200Gbps aren't an issue at all).
So while this is not a "TeamSpeak issue", it would be great if they could "help us" with these issues, in order to circumvent it for good. After all it's all a group work, the hosts that implement DoS/DDoS Protection methods, also requires colaboration of the software developers, mainly when speaking about UDP Protocol which has no connection/state control at all, making it really hard to mitigate application/targetted attacks.
The best way to protect anything against DDoS is to find a provider that offers such protection. OVH has been good for this type of protection for us. Just last night our TS3 was DDoSed and no one even knew it except the one that receives the email notification. Of course with any such provider you need to take advantage of ACL rules that you can define. OVH calls this their "Firewall". But the system is the same.
The one thing TS3 needs to provide us is the ability to configure outbound ports so that we can make allowances for them in our ACL rules. That way we can control all UDP that reaches our box.
https://support.teamspeakusa.com/ind...k-3-server-use
Those are the two connections we need to be able to configure which ports they use. Or be able to configure which outbound IP they use.In addition to that, packets originating from or sent to accounting.teamspeak.com:2008 (TCP) and weblist.teamspeak.com:2010 (UDP) must not be blocked. The local port for these connections is randomly assigned by the operating system when the connection is established.
Sounds like a type of attack I had made a program to filter out. TS3 handles it badly so that results in TS3 freezing up dealing with the attack.
Last edited by Kigen; August 22nd, 2016 at 07:28 PM.
These will not fix application targetted attacks, fooling the software with invalid/random packets unfortunately.(If you check the link to another thread of mine, I've tried alot of companies including OVH and none of them could fix those, using APIs or not, using Firewalls or not, since it just can't solve these attack types).
If you have a packet capture of the attack I could tell you more about how to block it.
As I edited to add to my post it sounds like a type of attack I had to deal with. I made an application that filters it out. But we use a Windows box. With Linux it should be easy enough to add an iptables rule to block the type of attack I dealt with. But I don't know if the attack I dealt with is the same as the one you have. A packet capture of the attack would tell me much about this.
Protocol authentication.
OVH's game range is suppose to be able to do this somewhat. You just configure the "Game firewall" correctly.
It doesn't do that, and their support told me they aren't able to protect against it, neither them or any other company I have tried, such as :
OVH, Koddos, Voxility, Staminus, NFO, Psychz, Limestone, BlackLotus, Javapipe and so on, all them have issues filtering these attacks and whether speaking to their support or not, they always give up when the attack is customized like that. I'm just saying, this is not easy as you think.
There are currently 1 users browsing this thread. (0 members and 1 guests)