Gatekeeper's detailed functionality

[hzc12321]

I'm aware that it has been mentioned in the FAQ that "Gatekeeper addresses infrastructure-layer DDoS attacks". From my understanding, it means everything except application-layer attack. However, it sounded abstract and promising. In order to justify the functionality of Gatekeeper in a more detailed way, I tried looking for a list of functions or countermeasures it has, like those commercial products always provide. Examples of the lists of similar commercial products are as follows :

Product 1 : Invalid Packets, ATLAS Intelligence Feed, Filter List, Rate-based Blocking, Payload Regular Expression, Spoofed SYN Flood Prevention, TCP Connection Limiting, TCP Connection Reset, DNS Authentication, Block Malformed DNS Traffic, DNS Rate Limiting, DNS NXDomain Rate Limiting, DNS Regular Expression, Malformed HTTP Filtering, HTTP Rate Limiting, HTTP Header Regular Expressions, TLS Attack Prevention, Block Malformed SIP Traffic, SIP Request Limiting, Traffic Shaping, TCP SYN Flood Detection, ICMP Flood Detection, UDP Flood Detection, Botnet Prevention, Fragment Detection, Multicast Blocking, Private Address Blocking,

Product 2 : IPv4 Address Filter Lists, IPv4 Black/White Lists, Packet Header Filtering, IP Location Filter Lists, Zombie Detection, UDP Reflection/Amplification Protection, Per Connection Flood Protection, TCP SYN Authentication, DNS Authentication, TCP Connection Limiting, TCP Connection Reset Payload Regular Expression, Protocol Baselines, DNS Malformed, DNS Rate Limiting, DNS NXDomain, Rate Limiting, DNS Regular Expression, HTTP Malformed, HTTP Rate Limiting, AIF and HTTP/URL Regular Expression, SSL Negotiation, SIP Malformed, SIP Request Limiting, Shaping, IP Location Policing

And here's my question : Is there a similar list that reflects the detailed capability of Gatekeeper? I have some ideas in my mind. I guess the short answer is "All layer 3/4 attacks are theoritically defendable, it all depends on your ability to create sophisticated policy.", yes? I would guess that Gatekeeper is a framework to start with, and we will have to work on our own to write the policies and achieve the functionalities, while some basic examples can be found in the /bpf directory.

Meanwhile, out of all these functionalities, is there any that Gatekeeper architecturally/naturally does/doesn't support? Just all those related to layer 7 HTTP?

[AltraMayor]

Lists of features similar to the ones you provided as examples would be for policies, not Gatekeeper. A policy that allows all flows without restriction has an empty list of features; a policy that only implements "IPv4 Black/White Lists" has a single item; and so forth.

Your interpretation that all layer 3/4 attacks are defendable reasonably approximates what Gatekeeper can do. It's not exactly that because as one writes a policy, one can encounter problems of any nature. For example, when a policy can identify if a destination IP address is not in use, it can associate the BPF bpf/declined.c to any flow to these destinations. While this is easy to implement in a policy and reduces the impact of carpet bombing attacks, a new Gatekeeper deployer may be unable to implement this feature immediately because the necessary information is not automatically maintained.

Any policy feature that requires connection termination (e.g., SSL negotiation) is outside of the scope of Gatekeeper; this is equivalent to thinking of the application layer. Over 90% of DDoS attacks are infrastructure-layer attacks, and Gatekeeper is designed to drastically lower the protection cost to withstand these attacks. Since solutions that address application-layer attacks have a much higher operational cost, having Gatekeeper before these solutions also reduces their operational cost.

The full potential of Gatekeeper has not been realized yet. As Gatekeeper deployers write policies to address specific characteristics of their infrastructure, and sometimes narrow needs of the protected applications, we have occasionally learned about features that are not available in other tools. For example, the TCP friendliness that the BPF bpf/tcp-services.c enforces. TCP-friendly flows do not starve TCP connections under congestion.

[hzc12321]

Thanks for the reply. What if we view this topic in terms of attack vector and types?

With the premise where the scope is infrastructure-layer attacks, can I say that Gatekeeper's policies are usually crafted by deployers in such a way that it defines the normal and acceptable flow pattern of their own traffic, then punish all those flows that don't obey to it? If this is true, then the actual attack vector / type / technique of the DDoS encountered doesn't matter, because they are always gonna be "abnormal" relative to the defined policies, as long as the policy is accurate enough to distinguish between ligitimate and DDoS traffic.

The reason I'm asking this is because it is necessary to make a side-by-side comparison with the commercial products in order to justify the advantage to invest in Gatekeeper over expensive commercial products, and one of the key part is to show that Gatekeeper is as capable as commercial products. (Probably taking more development resources and efforts to get there, but the possibility has to be there.)

On the other hand, do you have any suggestion in terms of monitoring? I want to know how much bps / pps of traffic are dropped / granted, preferably grouped by destination IP. If the raw details are available in the log, then I can setup some mechanism to parse and extract information to produce analytics.

ps :
By attack vector I mean something like this : https://cf-assets.www.cloudflare.com/zkvhlag99gkb/7s2ClnOzWZcefqsiNRrs85/560a7cc1f256c24f733a6d784c2a6b83/image3.png
By attack types I mean something like ICMP Flood, IP/ICMP Fragmentation, UDP Flood, IPSec Flood, SYN Flood, etc.

[AltraMayor]

What if we view this topic in terms of attack vector and types?
ps : By attack vector I mean something like this : https://cf-assets.www.cloudflare.com/zkvhlag99gkb/7s2ClnOzWZcefqsiNRrs85/560a7cc1f256c24f733a6d784c2a6b83/image3.png By attack types I mean something like ICMP Flood, IP/ICMP Fragmentation, UDP Flood, IPSec Flood, SYN Flood, etc.

What's the difference between vectors and types you're making?

With the premise where the scope is infrastructure-layer attacks, can I say that Gatekeeper's policies are usually crafted by deployers in such a way that it defines the normal and acceptable flow pattern of their own traffic, then punish all those flows that don't obey to it? If this is true, then the actual attack vector / type / technique of the DDoS encountered doesn't matter, because they are always gonna be "abnormal" relative to the defined policies, as long as the policy is accurate enough to distinguish between ligitimate and DDoS traffic.

YES! That's a great way to reason about how to write a policy.

Ideally, there's no difference, at the network level, between legitimate and attack traffic when the policy is accurate. At this ideal stage, one will need help from the application to enhance the policy further. For example, the image you linked to discuss attack vectors/types lists "Known botnets" under "HTTP DDoS attacks." If the HTTP application reports the IP addresses of the bots, this list can be fed to the policy to block them.

The reason I'm asking this is because it is necessary to make a side-by-side comparison with the commercial products in order to justify the advantage to invest in Gatekeeper over expensive commercial products, and one of the key part is to show that Gatekeeper is as capable as commercial products. (Probably taking more development resources and efforts to get there, but the possibility has to be there.)

To whom are you going to present the comparison you're creating? Is this going to be a presentation inside of the company you work for? Or are you creating a presentation to offer Gatekeeper as a service?

Comparing Gatekeeper through a list of features may not highlight the value that Gatekeeper adds. There are Gatekeeper deployers that use Gatekeeper because there's no other solution that can filter out the attacks that hit them.

On the other hand, do you have any suggestion in terms of monitoring? I want to know how much bps / pps of traffic are dropped / granted, preferably grouped by destination IP. If the raw details are available in the log, then I can setup some mechanism to parse and extract information to produce analytics.

Let's keep each thread coherent. Given this is another topic, please create another discussion to cover it.

[hzc12321]

What's the difference between vectors and types you're making?

I see Cloudflare, Akamai and other vendors that came up with DDoS threat reports tend to analyze attacks by protocol. However, a same protocol can involve multiple types of attack. For example, DNS flood and DNS amplification. Therefore, by attack vectors I'm generally referring to protocols that attackers can make use of (just like how Cloudflare and Akamai classified them), and by attack types I'm referring to those named attacks. Please correct me if I'm wrong.

YES! That's a great way to reason about how to write a policy.

Thanks for the confirmation. Commercial solutions tend to do it the other way round, which claim the defense mechanisms they can provide. This changes the question from "What is the nature of the attacks we have to defend against" to "What is the nature of the services we have to protect".

Ideally, there's no difference, at the network level, between legitimate and attack traffic when the policy is accurate. At this ideal stage, one will need help from the application to enhance the policy further. For example, the image you linked to discuss attack vectors/types lists "Known botnets" under "HTTP DDoS attacks." If the HTTP application reports the IP addresses of the bots, this list can be fed to the policy to block them.

Just to confirm, when you say "there's no difference", you are referring to L7 attacks right? From what I understand, in order to report, one has to detect, and in order to detect, one has to monitor. An ordinary HTTP application won't be able to monitor, and one with monitoring and detecting capabilities would be a WAF, for example, ModSecurity, which would have already provided the necessary blocking mechanism. Therefore, I don't see the need to develop a reporting mechanism by HTTP application.

To whom are you going to present the comparison you're creating? Is this going to be a presentation inside of the company you work for? Or are you creating a presentation to offer Gatekeeper as a service?

We are conducting a feasibility study to replace the existing solution with Gatekeeper. It's good to hear that Gatekeeper can potentially surpass other solutions, but the first thing we have to show the boss is that it is flexible enough to be crafted to do what the existing solution is doing, or we will have to find some hybrid implementation and evaluate as a whole. It seems like Gatekeeper is a solid solution to tackle L3/4 attacks, and we will find other ways to complement the L7 part.

We haven't got that far to discuss about offering Gatekeeper as a service, but is it even possible? Do you mean to deploy a set of hardware infrastructure to each client? Some variables are global, for example, destination bandwidth, which would make me think that it's hard to deploy Gatekeeper in a multi-tenant way even if all the clients can reside in the same AS. Anyway, we haven't discussed about it at this point of time.

Talking about this, another question just came into my mind :
I see DNS being classified as L3/4 DDoS attacks by Cloudflare and Akamai, while it is being classified as an L7 attack here and here
While DNS itself is a L7 protocol, DNS DDoS attacks seem to be volumetric-based. So I personally feels like it is more a L3/4 attack, but the information confused me. Can I get your opinion please?
And most importantly, what can Gatekeeper do about it? I guess DNS attacks will be treated just like any other UDP flood?

[AltraMayor]

What's the difference between vectors and types you're making?

I see Cloudflare, Akamai and other vendors that came up with DDoS threat reports tend to analyze attacks by protocol. However, a same protocol can involve multiple types of attack. For example, DNS flood and DNS amplification. Therefore, by attack vectors I'm generally referring to protocols that attackers can make use of (just like how Cloudflare and Akamai classified them), and by attack types I'm referring to those named attacks. Please correct me if I'm wrong.

I don't see a consistent use of the words vectors and types at large. I asked to better understand you. I take them as synonyms in a DDoS context. Just as an example of my point, the Cloudflare image you linked to exemplify attack vectors has the title "Distribution of DDoS attack types".

YES! That's a great way to reason about how to write a policy.

Thanks for the confirmation. Commercial solutions tend to do it the other way round, which claim the defense mechanisms they can provide. This changes the question from "What is the nature of the attacks we have to defend against" to "What is the nature of the services we have to protect".

Exactly!

Ideally, there's no difference, at the network level, between legitimate and attack traffic when the policy is accurate. At this ideal stage, one will need help from the application to enhance the policy further. For example, the image you linked to discuss attack vectors/types lists "Known botnets" under "HTTP DDoS attacks." If the HTTP application reports the IP addresses of the bots, this list can be fed to the policy to block them.

Just to confirm, when you say "there's no difference", you are referring to L7 attacks right? From what I understand, in order to report, one has to detect, and in order to detect, one has to monitor. An ordinary HTTP application won't be able to monitor, and one with monitoring and detecting capabilities would be a WAF, for example, ModSecurity, which would have already provided the necessary blocking mechanism. Therefore, I don't see the need to develop a reporting mechanism by HTTP application.

Yes, I was referring to L7 attacks when I wrote "there's no difference."

Having a WAF is an option to identify and deal with attacks. Some applications include code to identify attacks. How this is done is highly dependent on the application. Still, I've been told things like applications having links that are invisible on the user interface to catch automated attacks.

The value of feeding the IP addresses of application abuses to a policy is that the abuse traffic does not reach the WAF/application. This dropped abuse traffic could represent hundreds of thousands of connections.

We haven't got that far to discuss about offering Gatekeeper as a service, but is it even possible? Do you mean to deploy a set of hardware infrastructure to each client? Some variables are global, for example, destination bandwidth, which would make me think that it's hard to deploy Gatekeeper in a multi-tenant way even if all the clients can reside in the same AS. Anyway, we haven't discussed about it at this point of time.

Let's postpone this discussion until you have your Gatekeeper deployment in production.

Talking about this, another question just came into my mind : I see DNS being classified as L3/4 DDoS attacks by Cloudflare and Akamai, while it is being classified as an L7 attack here and here While DNS itself is a L7 protocol, DNS DDoS attacks seem to be volumetric-based. So I personally feels like it is more a L3/4 attack, but the information confused me. Can I get your opinion please? And most importantly, what can Gatekeeper do about it? I guess DNS attacks will be treated just like any other UDP flood?

Technically, DNS is an application protocol. DNS over TLS reinforces this point. Nevertheless, most of the DNS traffic is still UDP; this simpler form of DNS is amenable to L3/4 tools. That's why you see both classifications. The matter is similar to my earlier comment on the words vectors and types.

From Gatekeeper's perspective, the matter is the same as any other application: enforce L3/4 constraints and feed the policy with abuses identified in the application. Notice that you can hire help; that is, you don't have to do it all by yourself. For example, some companies track botnets and sell subscriptions to the list of IP addresses of the bots.