New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Hi @Habeeb
if you want we can check if we can filter your attacks. At the moment we are already filtering big attacks for gameservers from 50 GBit/s to several hundert GBit/s
These are the types of attack I received if you see above screenshot and this log
The main sources of traffic:
111-26-240-188.static.trined. nl (188.240.26.111) UDP 112.0M bytes with a packet size of 90 bytes on 9987 port.
90 -84-232-180.orangero.net ( 90 .84.232.180) UDP 95.6M bytes with a packet size of 90 bytes on 9987 port.
(109.100.92.78) UDP 91.3M bytes with a packet size of 90 bytes on 9987 port.
c151-177-150-111.bredband. comhem.se (151.177.150.111) UDP 79.8M bytes with a packet size of 90 bytes on port 9987.
ppp-110-168-55-230.revip5. asianet.co.th (110.168.55.230) UDP 72.6M bytes with a packet size of 90 bytes on 9987 port.
46-214-216-226.next-gen.ro (46.214.216.226) UDP 69.1M bytes with a packet size of 90 bytes on 9987 port.
(93.113.181.147) UDP 68.9M bytes with a packet size of 90 bytes on 9987 port.
90 -154-141-242.ip.btc-net.bg ( 90.154.141.242) UDP 51.8M bytes with a packet size of 90 bytes on port 9987.
149.233.211.138.dynamic-pppoe. dt.ipv4.wtnet.de (149.233.211.138) UDP 37.2M bytes with a packet size of 90 bytes on 9987 port.
93-57-42-185.ip162.fastwebnet. it (93.57.42.185) UDP 27.4M bytes with a packet size of 90 bytes on 9987 port.
212-233-153-7.optisprint.net (212.233.153.7) UDP 26.9M bytes with a packet size of 90 bytes on 9987 port.
xdsl-78-35-154-171.nc.de (78.35.154.171) UDP 26.1M bytes with a packet size of 90 bytes on 9987 port.
( 90 .95.129.143) UDP 23.3M bytes with packet size90 bytes on 9987 port.
95-31-73-96.broadband.corbina. ru (95.31.73.96) UDP 21.7M bytes with a packet size of 90 bytes on 9987 port.
host-94-251-43-115.bbcustomer. zsttk.net (94.251.43.115) UDP 21.0M bytes with a packet size of 90 bytes on 9987 port.
(46.109.38.176) UDP 20.5M bytes with a packet size of 90 bytes on 9987 port.
h081217197209.dyn.cm.kabsi.at (81.217.197.209) UDP 17.3M bytes with a packet size of 90 bytes on 9987 port.
(89.121.240.219) UDP 15.1M bytes with a packet size of 90 bytes on 9987 port.
93-38-125-13.ip70.fastwebnet. it(93.38.125.13) UDP 15.0M bytes with a packet size of 90 bytes on port 9987.
host217-43-50-78.range217-43. btcentralplus.com (217.43.50.78) UDP 14.3M bytes with a packet size of 90 bytes on port 9987.
If you want we can give you a testserver, but this attack should be no problem for us
@Zare, maybe your Corero can do so?
I have sent you a private message
To be honest, no one will filter you several hundred gigabit of attack traffic over a serious timeframe, without paying for ddos protection specifically. However, we're always happy to assist when it comes into antiddos.
None of the above will work. Try BuyVM again with a DDoS protected IP, and give some work to the Cloudflare guys. I'm sure they are up for a challenge.
I have already ordered a server from you in process of payment confirmation.
budget?
for such attacks you are looking for a lowendsolution? 8-X
To be honest, I just mentioned for solutions, I am open to budget, but whatever the reasonable price could be to be protected from these types of attacks.
Tried Voxility, corero, arbor still I am open to budget but I can't seem to find a working solution
Go back to OVH and give tcpdump of anything that takes down your server.
edit: ahh, I forgot they drop ur country, lol Only expensive solutions left then.
I’m not a provider on this site (am on others like LES), but we’ve seen and mitigated attacks of that caliber.
But, that being said, we don’t do it cheaply. You’d be paying us around US$500-1000/month baseline + whatever you need in clean bandwidth for that, but SLA we can mitigate it no matter what.
All in all, you could also try nesting mitigation providers and simply doing HA/load balance/health checks on the DNS level.
That's not how mitigation works. I assume you mean round-robin or active failover or something
A->B->C mitigation providers won't help anyone.
If you read this thread carefully you will notice that none of the usual suspects are offering to guaruntee protection in this case.
Sure most of the networks being discussed here have the raw capacity. But no one is going to tank consistent attacks of that magnitude for pennies. We are talking potentially $20k+/m in bandwidth costs here and likely $500-$2k/m+ in amortized hardware capacity. Excluding those direct costs you then have technical costs (software development, rule development), any engineer time required for complex attacks etc and a healthy markup.
On the bandwidth side most cheaper DDoS protected networks significantly reduce mitigation costs by using their ingress to egress ratio difference to significantly discount their transit bill. e.g if they have a consistent egress of 200G and ingress of 100G they then have a "free" capacity of 100G for mitigation at no additional cost. This is because generally on the wholesale market you usually pay for whichever is greater from your ingress or egress. Eyeball networks use more ingress, datacenters typically use more egress.
That under utilized ingress capacity is a big part of how you get many of the cheaper protection offers this forum knows and loves. But it's also why the pricing quickly increases once you get beyond certain levels.
Not too many networks would have enough free ingress to be willing to do sustained 200-800G without opening their wallet. OP needs to be looking for big networks. He may not like it but OVH is probably one of his better bets in the cheap market. Assuming he is getting that 200-800G at a consistent level he needs someone egressing Tbps.
NOTE: lots of assumptions and simplifications. Peering, Cost Sharing, Insurance, Value Adding & Transit Rate-Limiting are also all factors to name a few as well.
@SplitIce
I’m aware how mitigation works, it was a cheap suggestion. Relying on the fact that any decent DNS provider could HA and swap, so you’ll have minimal outage, but it’s still going to be costly.
The bottom line is, you’ve got to pay to defend it. I’m sure if you slapped a ton of money to Google, AWS, Azure, Akamai, Imperva they’d be happy to filter it, but you’re easily looking $500 minimum, likely on a year contract.
Having worked at or used these, $500 doesn't begin to cover the account manager's cost.
https://www.team-host.ru/ ask this is place
I have tried them they said there protection does not work with the size of attack I am receiving
Can't you just say sorry?
What ? datacheap.ru hosted on team-host I tried them ,directly team-host they do no reply to emails, as datacheap.ru they said there protection does not work completely with teamsspeak 3 , there would be some sort of disturbance with the application level protection.
well-web also uses team-host, used them no success
you can try out https://server.unesty.net which is core-backbone and corero + own arbor appliance
they use ociris network which is g-portal (https://www.g-portal.com/business/ddos-protection). ociris switched from link11 to core-backbone.
Thank you I was searching for g-portal vps, lets see now ordering them
For TeamSpeak there is one host that is capable and willing to work.
@EvolutionHost short name EvoVPS.
Try them.
delete
@Habeeb , Google Cloud its your solution for DDoS Protection.
These can 100% help you
https://serverius.net/cybersecurity/ddos-protection/
can confirm 1TBit/s
Serverius sucks for udp based applications. can guarantee that. There protection is a joke.
I see that your G-Portal vps null routes for 15 minutes after the attack.
Sorry Ahzam, you will find no luck in searching for a solution to mitigate teamspeak application layer attacks of this volume.
Better to say sorry then waste this much money.
if i was ahzam i would close community and enjoy in beach . lots of money wasted oh dear.