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.
DDoS Protection/Dedicated Server/Remote Protection
Looking for a dedicated with decent ddos protection (can be remote protection if it's near dallas)
No ovh/No voxility.
The attack is something about 5 gbps of spoofed udp apparently it's causing port saturation
-1gbps
-16-32gb ram
-stogare up to 100 gb is ok
-4 cores
-Windows
-During mitigation no packet loss.
-TCP/UDP open ports.
-Budget: 150~350 USD
-Latency to southamerica max 200 ms
-Will be used for TS and Game
Comments
We can do this in Dallas. Open a sales ticket.
Ok i will open a ticket
Err, have you use Psychz or no? They give fairly cheap E3-12XX servers with DDoS mitigation in Dallas.
I have 2 proxies with X4B one of them is in Psychz i believe, it's down atm
Contacted X4B for this ?
They can do something probably
Or maybe contact Psychz directly ?
"We are aware of an interruption upstream of us in L.A. We are awaiting diagnosis and repair.
This is an upstream outage, we are currently in discussion with the company CEO to find a permanent solution. They failed to mitigate an attack directed at your 103.249.71.xx, we mitigated it but experienced port saturation.
A crude edge rule has been applied over your port being attacked.
We are still awaiting further updates from the CEO and Tech Assigned."
As we asked in the ticket, please be patient and restrict yourself from opening any more threads. The more threads/posts you create (currently at 3 that I have found) the more distracted I am from the situation at hand.
We are actively waiting on a resolution from Psychz (the saturation is upstream of us, we are receiving <100Kbps most of this time).
We have already attempted every trick we have, nothing (edge rules, ip removal from device, etc) has resolved the issue. We are continuing to try different things to attempt to work around the issue upstream (who we are waiting on), however it is slow going when I have to respond to every one of your posts.
It's ok i am patient, just looking for other options.
I can do the following:
Intel Xeon E3 1230v3 (4 cores @ 3.3Ghz)
32GB RAM (16GB is -$10 and 24GB is -$5)
10TB BW @ 1Gbps
/29 Subnet with free 10Gbps DDoS Protection
250GB HDD (128GB SSD is +$5, 256GB SSD is +$10)
Windows Server 2012 R2
New Jersey
$116/mo
https://my.nodeblade.com/cart.php?a=add&pid=52
If your interested, PM me and I'll send you a coupon code.
I reviewed our NOC graph and do not see any saturation on our end this is most likely a small leak where the OS got overwhelmed. Some attacks will leak that is just how DDOS is especially when new signatures that comes out to circumvent these attacks. We utilize multi-layer ddos mitigation to minimize these leaks. We have multiple tools that our resellers have access to to minimize these leaks with packet length drops, tcp flags, and rate limits that our clients can utilize. With any leak our developers typically will investigate and patch those up to prevent future occurences.
@PhotonVPS Feel free to reply via the support ticket. Since you want to take this public, I'll reply here with the situation.
I had access to IPMI while the network was offline. For your benefit -
I can even drop the affected IP from the server (ip addr del) and see no effect.
A traceroute shows:
I take from that to mean saturation is occurring upstream of our port. The OS is showing near zero utilisation (si, etc)
We are still waiting on your resolution to your leaks after what is now the 7th hour since we reported this issue. As a result of this we have been forced to drop all UDP to the effected IP multiple times while waiting on your response (as it is currently).
Every time we install this rule, you claim its "fixed". We remove the rule, and sure enough back offline eventually.
This isnt a particularly new type of attack, we have signatures for it from our observations at a public stresser 1-2 years ago. From the few packets that are leaking/arriving, its an attack based on invalid UDP packets where the UDP len exceeds the IP Len (there are also lots of other warning signs).
Feel free to reply via ticket, LET is not a support system and this is not my thread.
If you and psychz can't fix the issue what about just refund the customer?
@jooja: I havent in anyway admitted defeat. This is an exceptional situation, one which is best dealt with via communication. Communication which we are waiting on from Psychz.
There isnt really a huge amount we can do in a situation like this, the ball is in Psychz's court and we are waiting. Currently our focus is on limiting the damage, and ensuring the best possible service in the interim (for all customers).
Many companies would nullroute you or install a rule that would lead to poor service, we are actually trying here. Furthermore you via our support system requested a refund for a totally different, unaffected service which is by all measures working correctly.
Its worth noting that your TCP services are online and working fine, as are you other services.
Please communicate via the support ticket. If you have any concerns or requests, speak up. We are trying - very hard - to give you the best service possible.
P.S Jumping from provider to provider is probably just going to get you burnt repeatedly.
I am only running UDP services, the TCP port i have require UDP.
So i am null routed lol.
Hi,
You have TCP ports defined in your service? Anyway it matters not. We are taking the only actions available to us at this time. If you have any better ideas, reply in your support ticket. Hopefully this will be a short interruption, as soon as we hear back from Psychz we will update you.
Unfortunately we have only limited options. We are sorry for the inconvenience. Hopefully will be resolved upstream soon.
FYI We have previously tested rate limits, however it appears this is implemented at or after the infrastructure which is getting saturated at Psychz and did not result in any positive results.
90kbit / 192pps is near to nothing. That should not crash or saturate any linux network stack.
This looks like there is something saturated on the psychz network, maybe the mitigation device cant handle the traffic and starts dropping traffic?
@Kabeldamagement thats been my theory too.
It you are interested in New Jersey I can do there.
Reviewing your mrtg graphs your vnstat is incorrect. Perhaps you are polling another interface? There was no saturation what so ever the issue was on the OS side. We can paste mrtg graphs during the window of attack. As a reseller it best you optimize your application against any attack. The attack was small but enough to overwhelm the operating system. Tools are provided if you had access to ipmi you are capable of creating acl to minimize the damage towards your services.
Is my problem fixed?
@jooja Reading my mind. I was just writing you a ticket reply
Short answer, yes - the upstream has reported two issues fixed.
No incidents have been seen all night (no sign of regression). I will however be continuing to monitor this for any regressions or issues.
I still have an active ticket, and other methods of communication open. And will be continuing to investigate this to (fingers crossed) prevent any re-occurrence.
I believe there is no incidents because i moved my TS to KMS-Hosting.
But i still will run other projects under your filter i wanted to have this fixed.
Well let me know if there is anything we can do for you, I'll update you via ticket if I get any relevant communication from upstream.
Currently the two issues they found on their end are reported solved. This seems to be confirmed by way of stability, but we will see I guess.
This sounds extremely anti-consumer. Not sure what you meant by it, but it isn't true at all.
Them looking for a different provider doesn't and shouldn't stop you from fixing issues. Really poor behavior here.
Their support is very bad with words. All they did say for now is it's psychz problem.
Im not even waste my i replying tickets, since they are "to difficult to talk".
Yeah I would stay away from them based on this. They aren't on their own paying customer's side.
Got 2 quotes.
One with ColoCrossing 30 Gbps
One with psychz 50 Gbps
Idk which one to choose.
Stay far away from ColoCrossing.
Bad with words? I dont think I have been rude or anything. Once I have time (i.e I am not tasked with this case) I'll re-read to be sure. At a first glance the replies are bit short, but hey if you have any questions, ask away. The ticket is there and waiting.
I've been updating your ticket as I know more and as time permits (the two of us have been spending near 100% of our time on this). If you have a question, ask away. As it stands I have been updating your ticket w/o any response or request for update.
You are correct, we do believe to be an issue with Psychz. Unfortunately this was not picked up in testing, or in the 6 months spent in the Dallas location. I would say this attack is unique, but it bares a striking resemblance to a packet capture I have from before. What is unique is the variations, which seems to be causing issues with their system. We are working both with their support and a higher level contact we have to get this resolved as fast as humanly possible.
They also had some issues with Diversions stopping working for our IPs. This is (reported) resolved now.
I have made some refinements on our end, the last burst came at 06:20 GMT and peaked at 100K PPS leaking (smaller than previous incidents). It conformed to a new static rule written, and was mitigated efficiently (compared to the more costly mitigation used previously). Previous Leakages have exceeded 180K PPS (not to be confused with the upstream PL when it occurs).
My comment re provider jumping is related to the observed behaviour of many people who instead of reporting an issue or waiting for resolution jump to the next provider immediately, and again face the same problem. And then, repeat. But hey, do whatever your want - we all have the benefit of choice.
Oh right, stay away from the company investing days of solid labour into a 13 dollar service for the customers benefit.