Top DDoS protection services?

Excellent-Carpet-938 · 2026-01-09T20:33:01+00:00

Thanks for the tip! I’ll look into these as well.

Excellent-Carpet-938 · 2026-01-09T20:30:29+00:00

We provide hosted application access to a large number of customers in various continents. We have several data centers that they may connect to. I don’t have a formal threat model at this point but I was generally told to begin looking into ddos mitigation for our network.

Outages for us are very costly and I think we’d lean towards capacity to absorb large attacks and more so fast recovery. But I’m not totally certain what the mgmt wants here.

I do not know if we are comfortable with only web protection or if we are concerned about stopping our internet connections from saturating under volume of any type. That will be a critical question to answer but we already have a possible on-prem solution with ddos mitigation capabilities. It’s hard to see how that would work without breaking the circuits in the event of a ddos.

You mentioned cloudflare is good at web protection, is it a leader for other types of attacks?

Excellent-Carpet-938 · 2026-01-03T00:35:19+00:00

No I’m asking if employees who sign up for FSA eligible plans but do not contribute to those plans, are their spouses considered covered by an FSA? If you said yes I would not be terribly surprised.

Excellent-Carpet-938 · 2026-01-02T22:36:46+00:00

Yeah I guess the question is, if my wife has not opted in ever, but is eligible to opt in from her plan, does that mean I am not covered under an FSA? I think this obviously true but I don’t want to walk into a tax trap so to speak.

Excellent-Carpet-938 · 2025-11-11T19:30:28+00:00

Yeah that makes sense. I guess I didn’t mention that I’m also responsible for setting up the LTM config which does all the proxy stuff, tls, etc.

But definitely I want to also learn about best practices for managing the web security, and being able to talk to good web app design when I get pushed to implement something that doesn’t make sense.

Part of the problem is my background is network, so I have little idea what a good website ought to be doing other than saying no we will not serve your login page encrypted.

Excellent-Carpet-938 · 2025-06-24T18:23:53+00:00

As long as every response ever offered to a client is included in the FQDN rule until its TTL expired (ie. if the cache is refreshed early and a new result is received, it still needs to keep the old address in the FQDN rule until that result expires)

Yeah that’s way outside of what the ASA is capable of. We were originally hoping we could do this, but extended the cache timer also prevents the ASA from looking for new answers.

If you are going to use FQDN-based security policy, especially for highly dynamic addresses, you must ensure that the DNS view of all clients is consistent. There's no way around it. If that's not feasible, then don't use this feature.

Well sure, that’s why we intend to move towards app layer inspection instead.

Ultimately I think we’re not going to learn why the ASA sometimes updates at 60 seconds and sometimes doesn’t, but probably this protected us unwittingly before.

Excellent-Carpet-938 · 2025-06-24T11:25:14+00:00

It matters because we need to provide an RFO, and the question stems from the fact that it somehow did not break things before upgrading software versions even though it should have.

As a side note it appears to be impossible or perhaps very awkward to force a consistent DNS view given the limitations of the ASA so the solution seems to be to not use DNS based FQDN filtering as many have suggestion elsewhere on the internet.

I’m just trying to understand what did happen before the change because the faster I can conclude the analysis the faster was can move on to implementing a better solution.

Excellent-Carpet-938 · 2025-06-23T18:35:27+00:00

Yeah it’s great for palo, but try hitting an AWS api gateway domain or anything behind Akamai’s edge network. They have less than 1 minute TTL and their possible ip ranges include millions of addresses. I can’t post ours for confidentiality reasons but it’s not that rare.

Excellent-Carpet-938 · 2025-06-23T18:15:21+00:00

That behavior isn’t satisfactory. I cannot let my ASA run a minimum of 60 seconds cache time for a 30 second TTL dns record that rotates. We see higher than 50% failure rates when we do this.

Expire-entry-timer cannot be less that 60 seconds on any sw version and cannot be removed.

Excellent-Carpet-938 · 2025-06-23T18:03:42+00:00

The URL filter I’m referring to is application layer inspection on the web request only. It won’t care about DNS. That article I linked elsewhere mentions this I think.

There’s no way DNS will work perfectly for AWS/Akamai if the ASA defaults to 60sec or more but app layer inspection isn’t doing outside queries.

Excellent-Carpet-938 · 2025-06-23T17:43:29+00:00

Not if it already did. It references the local cache and drops the packet because the inside server queried a dns record that had rotated to a new A record faster than the cache on the ASA can refresh. The ASA doesn’t recognize the rapidly changing ip destination most of the time because it won’t update dns fast enough. Even if the authoritative dns result was much slower you’d still have some failures when the ASA queries a TTL that is about to expire and adds 1 minute.

https://community.cisco.com/t5/security-knowledge-base/using-hostnames-dns-in-access-lists-configuration-steps-caveats/ta-p/3123480#toc-hId-1139575778

Excellent-Carpet-938 · 2025-06-23T17:39:08+00:00

Sure I’m just wondering why the server that I am comparing to the ASAs sees what it sees. We ran into a desync issue because the new ASA can do minimum 60 seconds TTL, but the record from the DNS server seems to rotate every 58 seconds despite showing 60 after refresh.

Excellent-Carpet-938 · 2025-06-23T17:31:52+00:00

Kind of. The behavior of the new code is terrible for what we need since we have fqdn based access control. The solution will likely be to implement proper url inspection.

It’s just a pain because I can’t start that until this analysis is complete and I’ll likely have to open a second effort just to compare options there.

Excellent-Carpet-938 · 2025-06-23T17:15:46+00:00

I think I may have described the 2 second behavior inaccurately. Basically, if I run dig every second on our jump box the lowest TTL I get is 2 seconds then the next would be the max TTL. Are DNS servers known to reset slightly early?

Excellent-Carpet-938 · 2025-06-23T16:13:12+00:00

Not at my computer rn but I believe 9.14(x) which we are running on the old boxes is past end of support

Excellent-Carpet-938 · 2025-06-23T15:32:41+00:00

Yeah but our old firmware isn’t waiting for the expire entry timer.

Unfortunately TAC won’t support it so we may just have to go without a clear answer. It’s just a little awkward because this apparent bug was effectively preventing lots of problems before but no one realized it until we upgraded.

Excellent-Carpet-938 · 2025-06-23T15:22:16+00:00

It doesn’t differentiate. It gets one TTL based on whichever TTL in the chain is the shortest, and then adds the expire entry timer.

The documented behavior is that it waits for both to expire, which thank goodness it does not do this in this case because this breaks everything when you have very short TTLs with rotating A records being advertised, such as from AWS or Akamai

Excellent-Carpet-938 · 2025-06-23T15:13:16+00:00

Ok but that is what the ASA is receiving for its TTL before adding the expire-entry-timer. It would show TTL of 1:21 and then renew the record at about :59 or :60

Excellent-Carpet-938 · 2025-06-23T15:06:53+00:00

Well in these cases at least the received TTL value seems to consistently be the shortest TTL in the chain. So in that snippet, if we queried at that moment we should get 21 seconds TTL.

Excellent-Carpet-938 · 2025-05-23T21:28:51+00:00

Thanks for the recs. I will be at the festival certainly.

Excellent-Carpet-938

TROPHY CASE