Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


BuyVM incompetent DDoS protection setup
New on LowEndTalk? Please Register and read our Community Rules.

BuyVM incompetent DDoS protection setup

vitalis3vitalis3 Member
edited November 2022 in General

There is an issue with BuyVM, where traffic destined to protected subnets, from within the LAN, will skip past filtering. This means that sufficient SYN traffic can lead to your server becoming unusable. It doesn't matter what provider, skids will compromise a host for this.

Nearly all of the LET providers have a similar issue and it doesn't matter if there are filters setup on path.net/voxility's side. This is what efnet skids are abusing and I'd like to see it resolved. Easiest fix, of course, would be to force traffic destined to the subnets through the WAN.

Better solution, though, would be an isolated VLAN per host, for the DDoS protected IPs, where all traffic must pass through the WAN.

Oh, right, BuyVM has an awful path.net setup, where SYNPROXY doesn't establish connections properly... heh. OVH? Nope, skids just spoof the source address to be that of an OVH monitoring host.

«1

Comments

  • Why do you expect a LAN to be filtered by the provider? Just use firewall rules.

  • DPDP Administrator, The Domain Guy

    Oh, an EFnetizen! <3

  • vitalis3vitalis3 Member
    edited November 2022

    @Lunar said:
    Why do you expect a LAN to be filtered by the provider? Just use firewall rules.

    Uh, this will not work when the connection backlog is being filled to the brim. What if they compromise 2 hosts within the LAN to saturate the 1gbit/s link, too, with UDP traffic?

    It doesn't matter if there are netfilter rules, you do realise?

  • The tiny one is persistent, gotta give him/her/them/weaselself credit where credit is due.

    Thanked by 1NobodyInteresting
  • DDoS protection is a scam anyway. Just apply some of my specially formulated snake oil to the port and it will be filtered.

  • aquaaqua Member, Patron Provider

    Paid DDOS Protection is lame, I just put a coffee filter over each network connection and call it a day. Filters pretty well.

  • Weasel, if you know so much make your own hosting // DDoS protection company or something, show em how it’s done

  • Thanked by 1ralf
  • Hi tiny kunju

    Thanked by 1FatGrizzly
  • Hello to you too Weasel.

  • @dosai said:
    Hi tiny kunju

    lmao wonder how many knows the meaning of that

  • @jmaxwell said:

    @dosai said:
    Hi tiny kunju

    lmao wonder how many knows the meaning of that

    You do? Nice.

  • @dosai said:

    @jmaxwell said:

    @dosai said:
    Hi tiny kunju

    lmao wonder how many knows the meaning of that

    You do? Nice.

    B)

    Thanked by 1FatGrizzly
  • I feel like LET could offer a training model for an AI from this douche.

  • Sooner or later those s and d words would come out

  • Nearly all of the LET providers have a similar issue

    What is the benefit of singling out Francisco then?

    Better solution, though, would be an isolated VLAN per host, for the DDoS protected IPs, where all traffic must pass through the WAN.

    More VLANs does not scale for VMs and would eat up more IPs at a quicker rate, forcing Francisco to charge higher prices.

  • HxxxHxxx Member
    edited November 2022

    @fynix said:

    Those animals are no joke. I had one attack me probably with rabies. That shit came out of nowhere and jumped on me. Trying to get that thing off is crazy. Even if you are manly enough your inner non existent woman start to surface and start screaming, specially if your soul was at peace when it happened. Holy shit man

    Thanked by 3Logano _MS_ gzz
  • jarjar Member, Patron Provider

    Back in the day I'd have DDOS attacks on OVH from inside of the network, mitigation wouldn't work. It's definitely one of those things that will drive you to the end of your sanity, even though completely understandable that local traffic isn't routed outside and then back.

  • FranciscoFrancisco Member, Top Host, Host Rep

    @jar said:
    Back in the day I'd have DDOS attacks on OVH from inside of the network, mitigation wouldn't work. It's definitely one of those things that will drive you to the end of your sanity, even though completely understandable that local traffic isn't routed outside and then back.

    It’s still a thing at OVH, though maybe the GAME lineup addresses it. They talked about changing their routing many years ago to scrub inter server traffic but I’m sure they realized quickly that they do probably Tbits of internal traffic due to all the seed boxes.

    Internal floods suck and for the time being we just have users send pcaps and we suspend quickly if we can verify it. People don’t like pissing away lots of cash to get a couple floods popped off.

    Still, I think we will have a solution for this in the new year. We are almost certainly going to offer some “best effort on-net” mitigation at either no cost to all users, or do a very very small increase to all plans ($0.25/m to $1.00/m depending on plan size). Along with that will come a rebuild of how IPs are routed to the nodes. That change will make it that IPs in mitigation mode will be routed through our mitigation appliances, even for internal traffic.

    Francisco

    Thanked by 3SinSiXX Hxxx MannDude
  • vitalis3vitalis3 Member
    edited November 2022

    @techhelper1 said: More VLANs does not scale for VMs and would eat up more IPs at a quicker rate, forcing Francisco to charge higher prices.

    Use more IPs? LOL, you can just do an interface route, if you must, to reuse the same gateway IP over VLANs. Just filter out ARP, etc., traffic, too. You could definitely limit the VLAN's scope to the guest and the hypervisor host as well. This is clearly a half-arsed setup.

  • InceptionHostingInceptionHosting Member, Patron Provider

    Well, thats Fran told!

    Now go on, implement it at scale make it work with existing automation, and consider nothing else, by tomorrow if possible! oh and don't you disrupt any customers!

  • vitalis3vitalis3 Member
    edited November 2022

    @InceptionHosting said: Now go on, implement it at scale make it work with existing automation, and consider nothing else, by tomorrow if possible! oh and don't you disrupt any customers!

    Would you like a GUI with that, Virtualizor/SolusVM user?

  • @Francisco said:

    @jar said:
    Back in the day I'd have DDOS attacks on OVH from inside of the network, mitigation wouldn't work. It's definitely one of those things that will drive you to the end of your sanity, even though completely understandable that local traffic isn't routed outside and then back.

    It’s still a thing at OVH, though maybe the GAME lineup addresses it. They talked about changing their routing many years ago to scrub inter server traffic but I’m sure they realized quickly that they do probably Tbits of internal traffic due to all the seed boxes.

    I think another possible way to address it (although this would have obvious issues) would be to just allow customers to block all internal traffic enitirely, minus any specific IPs they'd like to whitelist.

    Thanked by 1vitalis3
  • @ehhthing They can, in the OS firewall...

  • @techhelper1 said:
    @ehhthing They can, in the OS firewall...

    Why are you repeating this nonsense? It's obvious that netfilter will not help here. You do not seem to understand this, who is your handler?

  • @vitalis3 said:

    @techhelper1 said: More VLANs does not scale for VMs and would eat up more IPs at a quicker rate, forcing Francisco to charge higher prices.

    Use more IPs? LOL, you can just do an interface route, if you must, to reuse the same gateway IP over VLANs. Just filter out ARP, etc., traffic, too. You could definitely limit the VLAN's scope to the guest and the hypervisor host as well. This is clearly a half-arsed setup.

    If you know how to do it right and know which provider does, what are you getting from bitching about it here?

  • @techhelper1 said: If you know how to do it right and know which provider does, what are you getting from bitching about it here?

    I am here to make a point about BuyVM having a shitty setup and while I have found a suitable host that has been able to cater to my needs for slightly more than what I was paying at BuyVM, this must be annoying for others.

    LowEndTards

  • @vitalis3 said:

    @techhelper1 said:
    @ehhthing They can, in the OS firewall...

    Why are you repeating this nonsense? It's obvious that netfilter will not help here. You do not seem to understand this, who is your handler?

    Something is better than nothing, especially with the latest in XDP/eBPF in Linux these days.

    I'm not the one spouting off insults bro, nor do I complain to the public about a providers network. @Francisco responded, now please move on.

  • @techhelper1 said: I'm not the one spouting off insults bro, nor do I complain to the public about a providers network. @Francisco responded, now please move on.

    >just accept it
    >cope and seethe
    >give us your money oy vey

    @techhelper1 said: Something is better than nothing, especially with the latest in XDP/eBPF in Linux these days.

    >repeating shit that corey ray barnhill says, doesn't realise that volumetric attacks will make this all useless

  • @vitalis3 said:

    @techhelper1 said: If you know how to do it right and know which provider does, what are you getting from bitching about it here?

    I am here to make a point about BuyVM having a shitty setup and while I have found a suitable host that has been able to cater to my needs for slightly more than what I was paying at BuyVM, this must be annoying for others.

    LowEndTards

    So, instead of reaching out in a support case or DMing Francisco with feedback on how to make his platform better, you decided it was much better to bitch about in attempt to drag his name through the mud.

    Your point is taken either way, but given the presentation here, I highly doubt it will be given any priority.

    Thanked by 1netomx
Sign In or Register to comment.