Howdy, Stranger!

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


FluxCDN bought out by Path Network
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.

FluxCDN bought out by Path Network

Today it has been announced that FluxCDN has been bought out by Path Network. As a result, all services will be shutdown by 5/28/2022.

Many websites that have relied upon FluxCDN’s “bulletproof” Layer 7 DDoS Protection to keep their websites up will now be susceptible to DDoS attacks, with nowhere to go, as for many Cloudflare did not work for them.

If you use FluxCDN, where will you be going?
Personally I currently do not have a solution for my needs, so I am curious as to what everyone else’s is.

If you do not use FluxCDN for DDoS protection, is there a service that you prefer?
Some alternatives are DDoS-Guard, Sucuri, Imperva, Akamai, Cloudflare, and more. However, none have been able to perform as well as FluxCDN did.

Here is the message:

Dear customers,

We have an important message for you.

FluxCDN has always been involving and recognized as the best DDoS Mitigation provider for Layer 7.

FluxCDN, Unipessoal Lda has been adquired by Path Network, Inc.

This means FluxCDN mitigation technology will be handed over to Path Network, Inc. and our employees will maintain their tech.

FluxCDN will shutdown by 28/05/2022.

Remaining time will be refunded if membership exceeds the shutdown date for more than 30 days. Both PayPal and Crypto.
This applies for who bought yearly plans. You will not be in loss and we will refund the remaining amount of time.

Do not submit PayPal cases as they will be refused. We have to agree on the amount we have to refund you.

We will be part of something bigger and expect big things.

If you got any questions, you can DM me.

Thanks everyone for your support.

Discuss!

Comments

  • @Moofie said: Some alternatives are DDoS-Guard

    Extremely bad alternative. Nothing changed since 2014 year when i faced volumetric ddos attacks. Extremely awful service / services. + Owned by people related directly russian goverment. Goodluck with your safe data.

    Sucuri

    Good option. 10 usd per website. https://sucuri.net/website-security-platform/signup/#firewall

    Imperva

    Expensive for me

    Akamai

    Expensive

    Cloudflare

    Earlier did not protect anything at all. Now they doing pretty decent ddos protection if you properly configure it on free account.

    and more.

    For example?

    There are no "more".

    these "more" a few companies like:

    Who else? Everyone else doing L3/L4 only...

  • @desperand said:

    [@Moofie said](/discussion/178930/fluxcdn-bought-out-
    Sucuri

    Good option. 10 usd per website. https://sucuri.net/website-security-platform/signup/#firewall

    Did you need to make any manual configuration with Sucuri to mitigate attacks? Was it all automatic?

    Do you have any other you’d personally suggest?

    Thanks!

  • @Moofie said: Do you have any other you’d personally suggest?

    x4b pretty decent, sucuri pretty okay. Others in list -> all were unde real problematic ddos attacks, all of the providers above solved the ddos problem for my hobby projects in different time (years).

    Thanked by 1Moofie
  • yoursunnyyoursunny Member, IPv6 Advocate

    You don't need a flux capacitor to operate a content distribution network.
    I have my own push-ups distribution network.
    DDoS attack is impossible due to the flow balance property at the core of the network protocol: the routers won't forward your requests if there's no response coming.
    https://named-data.net/publications/ndn-ddos/

    Thanked by 2dedicados Advin
  • @yoursunny said:
    You don't need a flux capacitor to operate a content distribution network.
    I have my own push-ups distribution network.
    DDoS attack is impossible due to the flow balance property at the core of the network protocol: the routers won't forward your requests if there's no response coming.
    https://named-data.net/publications/ndn-ddos/

    Mind expanding a little upon your infrastructure setup for flow balancing? How would it initally know not to forward the traffic to the origin/backend without first seeing if it responds, and also what determines a "successful/valid" response, especially on a public facing service? e.g.

    HTTP GET request, you make the request and it will respond with some response whether that be a 200, 404 or 500 etc.

    Or are you referring to strictly L3-L4?

  • yoursunnyyoursunny Member, IPv6 Advocate

    @dbContext said:

    @yoursunny said:
    You don't need a flux capacitor to operate a content distribution network.
    I have my own push-ups distribution network.
    DDoS attack is impossible due to the flow balance property at the core of the network protocol: the routers won't forward your requests if there's no response coming.
    https://named-data.net/publications/ndn-ddos/

    Mind expanding a little upon your infrastructure setup for flow balancing? How would it initally know not to forward the traffic to the origin/backend without first seeing if it responds, and also what determines a "successful/valid" response, especially on a public facing service? e.g.

    HTTP GET request, you make the request and it will respond with some response whether that be a 200, 404 or 500 etc.

    Or are you referring to strictly L3-L4?

    Named Data Networking (NDN) operates at Layer 3 and above.
    It replaces IP.
    See https://named-data.net/publications/named_data_networking_ccr/ for detailed introduction.

    A request from a consumer/client, called an Interest, is forwarded toward the producer/server.
    The producer will respond with a Data packet that carries the response, which flows in the reverse direction along the same set of routers.
    Network layer protocol specifies that a node may send at most one Data in reply to each Interest; this property is called flow balance.
    Every Interest and Data packet is named, so that router knows what content is requested and responded; the names may be encrypted, in which case the router can still match Data with Interest, but cannot understand what's in the packet.

    In IP forwarding model, traffic in two directions may traverse different paths.
    In NDN, a router can observe traffic in both directions.
    This enables the router to calculate how many unsatisfied requests are on each downstream port (consumer side).
    If a downstream has too many unsatisfied requests, the router tells the downstream to reduce its request rate.
    If the downstream does not react according to the signal and continues sending at high rate, it would eventually be blocked.

  • @Moofie said: and more

    How's StackPath? Any reviews on their WAF/DDoS protection?

  • @sanvit said:

    @Moofie said: and more

    How's StackPath? Any reviews on their WAF/DDoS protection?

    From what I heard it’s good, don’t take my word for it though. I have no clue on pricing either

    Thanked by 1sanvit
  • LordSpockLordSpock Member, Host Rep

    @sanvit said:

    @Moofie said: and more

    How's StackPath? Any reviews on their WAF/DDoS protection?

    I have had a lot of success with StackPath, pricing has jumped much higher than it used to be (was actually very very reasonable back then).

    Never required much configuration and fended off several very nasty L7 attacks for me.

    Thanked by 1sanvit
  • @Moofie said:

    @sanvit said:

    @Moofie said: and more

    How's StackPath? Any reviews on their WAF/DDoS protection?

    From what I heard it’s good, don’t take my word for it though. I have no clue on pricing either

    I'm still on their legacy plan (a.k.a $10 for CDN and another $10 for WAF). I like their CDN, but never really needed WAF or DDoS, so was just wondering if it's worth keeping it.

    @LordSpock said: Never required much configuration and fended off several very nasty L7 attacks for me.

    That sounds great! Thanks!

  • @sanvit said:

    @Moofie said:

    @sanvit said:

    @Moofie said: and more

    How's StackPath? Any reviews on their WAF/DDoS protection?

    From what I heard it’s good, don’t take my word for it though. I have no clue on pricing either

    I'm still on their legacy plan (a.k.a $10 for CDN and another $10 for WAF). I like their CDN, but never really needed WAF or DDoS, so was just wondering if it's worth keeping it.

    @LordSpock said: Never required much configuration and fended off several very nasty L7 attacks for me.

    That sounds great! Thanks!

    Wow, that’s actually very fairly priced. I would keep it!

    Thanked by 1sanvit
  • Cloudflare is now decent against layer 7 attacks, they auto mitigated an attack and my community site did not go down or experience any downtime.

  • I think fastly.com is pretty good, someone can try

  • VoidVoid Member

    @yoursunny said:

    @dbContext said:

    @yoursunny said:
    You don't need a flux capacitor to operate a content distribution network.
    I have my own push-ups distribution network.
    DDoS attack is impossible due to the flow balance property at the core of the network protocol: the routers won't forward your requests if there's no response coming.
    https://named-data.net/publications/ndn-ddos/

    Mind expanding a little upon your infrastructure setup for flow balancing? How would it initally know not to forward the traffic to the origin/backend without first seeing if it responds, and also what determines a "successful/valid" response, especially on a public facing service? e.g.

    HTTP GET request, you make the request and it will respond with some response whether that be a 200, 404 or 500 etc.

    Or are you referring to strictly L3-L4?

    Named Data Networking (NDN) operates at Layer 3 and above.
    It replaces IP.
    See https://named-data.net/publications/named_data_networking_ccr/ for detailed introduction.

    A request from a consumer/client, called an Interest, is forwarded toward the producer/server.
    The producer will respond with a Data packet that carries the response, which flows in the reverse direction along the same set of routers.
    Network layer protocol specifies that a node may send at most one Data in reply to each Interest; this property is called flow balance.
    Every Interest and Data packet is named, so that router knows what content is requested and responded; the names may be encrypted, in which case the router can still match Data with Interest, but cannot understand what's in the packet.

    In IP forwarding model, traffic in two directions may traverse different paths.
    In NDN, a router can observe traffic in both directions.
    This enables the router to calculate how many unsatisfied requests are on each downstream port (consumer side).
    If a downstream has too many unsatisfied requests, the router tells the downstream to reduce its request rate.
    If the downstream does not react according to the signal and continues sending at high rate, it would eventually be blocked.

    Have you had any DDoS attacks that got mitigated this way? If so what was the max volume seen?

  • Hi there! 👋🏻
    I was reading this thread..

    We, C1V Hosting, are already providing Website DDoS protection and planning to introduce new plans and trial test.

    We are updating our protection technology every week, almost.
    Just to introduce us also as an alternative.

  • yoursunnyyoursunny Member, IPv6 Advocate

    @jmaxwell said:

    @yoursunny said:

    @dbContext said:

    @yoursunny said:
    You don't need a flux capacitor to operate a content distribution network.
    I have my own push-ups distribution network.
    DDoS attack is impossible due to the flow balance property at the core of the network protocol: the routers won't forward your requests if there's no response coming.
    https://named-data.net/publications/ndn-ddos/

    Mind expanding a little upon your infrastructure setup for flow balancing? How would it initally know not to forward the traffic to the origin/backend without first seeing if it responds, and also what determines a "successful/valid" response, especially on a public facing service? e.g.

    HTTP GET request, you make the request and it will respond with some response whether that be a 200, 404 or 500 etc.

    Or are you referring to strictly L3-L4?

    Named Data Networking (NDN) operates at Layer 3 and above.
    It replaces IP.
    See https://named-data.net/publications/named_data_networking_ccr/ for detailed introduction.

    A request from a consumer/client, called an Interest, is forwarded toward the producer/server.
    The producer will respond with a Data packet that carries the response, which flows in the reverse direction along the same set of routers.
    Network layer protocol specifies that a node may send at most one Data in reply to each Interest; this property is called flow balance.
    Every Interest and Data packet is named, so that router knows what content is requested and responded; the names may be encrypted, in which case the router can still match Data with Interest, but cannot understand what's in the packet.

    In IP forwarding model, traffic in two directions may traverse different paths.
    In NDN, a router can observe traffic in both directions.
    This enables the router to calculate how many unsatisfied requests are on each downstream port (consumer side).
    If a downstream has too many unsatisfied requests, the router tells the downstream to reduce its request rate.
    If the downstream does not react according to the signal and continues sending at high rate, it would eventually be blocked.

    Have you had any DDoS attacks that got mitigated this way? If so what was the max volume seen?

    It is fundamentally impossible to start a DDoS attack in Named Data Networking network, because it is eliminated in protocol design.
    Any downstream/consumer/client that sends too many unanswered requests would get rate-limited then blocked, at the ingress router.

    Thanked by 1Void
  • dosaidosai Member

    @yoursunny said:

    @jmaxwell said:

    @yoursunny said:

    @dbContext said:

    @yoursunny said:
    You don't need a flux capacitor to operate a content distribution network.
    I have my own push-ups distribution network.
    DDoS attack is impossible due to the flow balance property at the core of the network protocol: the routers won't forward your requests if there's no response coming.
    https://named-data.net/publications/ndn-ddos/

    Mind expanding a little upon your infrastructure setup for flow balancing? How would it initally know not to forward the traffic to the origin/backend without first seeing if it responds, and also what determines a "successful/valid" response, especially on a public facing service? e.g.

    HTTP GET request, you make the request and it will respond with some response whether that be a 200, 404 or 500 etc.

    Or are you referring to strictly L3-L4?

    Named Data Networking (NDN) operates at Layer 3 and above.
    It replaces IP.
    See https://named-data.net/publications/named_data_networking_ccr/ for detailed introduction.

    A request from a consumer/client, called an Interest, is forwarded toward the producer/server.
    The producer will respond with a Data packet that carries the response, which flows in the reverse direction along the same set of routers.
    Network layer protocol specifies that a node may send at most one Data in reply to each Interest; this property is called flow balance.
    Every Interest and Data packet is named, so that router knows what content is requested and responded; the names may be encrypted, in which case the router can still match Data with Interest, but cannot understand what's in the packet.

    In IP forwarding model, traffic in two directions may traverse different paths.
    In NDN, a router can observe traffic in both directions.
    This enables the router to calculate how many unsatisfied requests are on each downstream port (consumer side).
    If a downstream has too many unsatisfied requests, the router tells the downstream to reduce its request rate.
    If the downstream does not react according to the signal and continues sending at high rate, it would eventually be blocked.

    Have you had any DDoS attacks that got mitigated this way? If so what was the max volume seen?

    It is fundamentally impossible to start a DDoS attack in Named Data Networking network, because it is eliminated in protocol design.
    Any downstream/consumer/client that sends too many unanswered requests would get rate-limited then blocked, at the ingress router.

    You should start flex cdn.

    Thanked by 1yoursunny
  • @c1vhosting said:
    Hi there! 👋🏻
    I was reading this thread..

    We, C1V Hosting, are already providing Website DDoS protection and planning to introduce new plans and trial test.

    We are updating our protection technology every week, almost.
    Just to introduce us also as an alternative.

    It looks to be very expensive :/

  • @Moofie said:

    @c1vhosting said:
    Hi there! 👋🏻
    I was reading this thread..

    We, C1V Hosting, are already providing Website DDoS protection and planning to introduce new plans and trial test.

    We are updating our protection technology every week, almost.
    Just to introduce us also as an alternative.

    It looks to be very expensive :/

    Hi Moofie.
    Thank you for your feedback.

    There will be two new plans.
    One, the “trial” plan is free. (It has limitations).
    The second, thought for Business companies or websites with low/medium amount of traffic, will be at €30/month.

  • @yoursunny said:

    @jmaxwell said:

    @yoursunny said:

    @dbContext said:

    @yoursunny said:
    You don't need a flux capacitor to operate a content distribution network.
    I have my own push-ups distribution network.
    DDoS attack is impossible due to the flow balance property at the core of the network protocol: the routers won't forward your requests if there's no response coming.
    https://named-data.net/publications/ndn-ddos/

    Mind expanding a little upon your infrastructure setup for flow balancing? How would it initally know not to forward the traffic to the origin/backend without first seeing if it responds, and also what determines a "successful/valid" response, especially on a public facing service? e.g.

    HTTP GET request, you make the request and it will respond with some response whether that be a 200, 404 or 500 etc.

    Or are you referring to strictly L3-L4?

    Named Data Networking (NDN) operates at Layer 3 and above.
    It replaces IP.
    See https://named-data.net/publications/named_data_networking_ccr/ for detailed introduction.

    A request from a consumer/client, called an Interest, is forwarded toward the producer/server.
    The producer will respond with a Data packet that carries the response, which flows in the reverse direction along the same set of routers.
    Network layer protocol specifies that a node may send at most one Data in reply to each Interest; this property is called flow balance.
    Every Interest and Data packet is named, so that router knows what content is requested and responded; the names may be encrypted, in which case the router can still match Data with Interest, but cannot understand what's in the packet.

    In IP forwarding model, traffic in two directions may traverse different paths.
    In NDN, a router can observe traffic in both directions.
    This enables the router to calculate how many unsatisfied requests are on each downstream port (consumer side).
    If a downstream has too many unsatisfied requests, the router tells the downstream to reduce its request rate.
    If the downstream does not react according to the signal and continues sending at high rate, it would eventually be blocked.

    Have you had any DDoS attacks that got mitigated this way? If so what was the max volume seen?

    It is fundamentally impossible to start a DDoS attack in Named Data Networking network, because it is eliminated in protocol design.
    Any downstream/consumer/client that sends too many unanswered requests would get rate-limited then blocked, at the ingress router.

    How does this solve attacks where the adversaries outnumber legitimate consumers? In my brief look at the paper linked it seems to be demonstrating mitigating attacks where there are few attackers relative to legitimate consumers so I'm curious how it works with more attackers.

  • yoursunnyyoursunny Member, IPv6 Advocate

    @itzaname said:

    @yoursunny said:

    @jmaxwell said:

    @yoursunny said:

    Named Data Networking (NDN) operates at Layer 3 and above.
    It replaces IP.
    See https://named-data.net/publications/named_data_networking_ccr/ for detailed introduction.

    A request from a consumer/client, called an Interest, is forwarded toward the producer/server.
    The producer will respond with a Data packet that carries the response, which flows in the reverse direction along the same set of routers.
    Network layer protocol specifies that a node may send at most one Data in reply to each Interest; this property is called flow balance.
    Every Interest and Data packet is named, so that router knows what content is requested and responded; the names may be encrypted, in which case the router can still match Data with Interest, but cannot understand what's in the packet.

    In IP forwarding model, traffic in two directions may traverse different paths.
    In NDN, a router can observe traffic in both directions.
    This enables the router to calculate how many unsatisfied requests are on each downstream port (consumer side).
    If a downstream has too many unsatisfied requests, the router tells the downstream to reduce its request rate.
    If the downstream does not react according to the signal and continues sending at high rate, it would eventually be blocked.

    Have you had any DDoS attacks that got mitigated this way? If so what was the max volume seen?

    It is fundamentally impossible to start a DDoS attack in Named Data Networking network, because it is eliminated in protocol design.
    Any downstream/consumer/client that sends too many unanswered requests would get rate-limited then blocked, at the ingress router.

    How does this solve attacks where the adversaries outnumber legitimate consumers? In my brief look at the paper linked it seems to be demonstrating mitigating attacks where there are few attackers relative to legitimate consumers so I'm curious how it works with more attackers.

    The pushback mechanism doesn't distinguish how many traffic sources are malicious.
    If a node is signaled by its upstream to reduce request rate, it must reduce request rate, or it gets blocked.
    Now, if this node is honest, it should implement the same scheme to determine which of its downstream node(s) have too many unsatisfied requests, and then signal them to reduce request rate.

Sign In or Register to comment.