-
Notifications
You must be signed in to change notification settings - Fork 228
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
About BPF, the calculation of budget1_byte #643
Comments
Like this, can I set an interval time, count the number of occurrences of the corresponding package, and reject the flow after the number reaches? |
I'm assuming that you are referring to the code in Field If a flow expires, a new policy decision is made, and If an attacking flow is always within the allocated budget, the flow won't be punished. But how do you know that this flow is an abuse using only the information available in the packets of this flow? |
Yes, you can implement a BPF to do exactly that. |
When the flow reaches the next request to renew, package rejection occurs, about 50 packages. Which bpf parameter affects this. Is this renewal_step_ms? |
There's not much information on what you're testing to answer this question. Which BPF are you testing? What're the parameters? What's the expiration of the policy decision? How are you measuring that packet loss? What's the condition of the network during the test (e.g. attacks going on, network capacity vs traffic volume, packet drops on the path, etc.)? How are you producing the flow being measured? How have you narrowed down the issue to the renewal of the policy decision? |
I have solved this problem because the wrong parameters of the bpf call I wrote were caused. |
As I have explained here, adding more parameters to the BPFs associated with the flows may not be cheap to do. If you had any amount of memory desired, what would you implement in the BPF you want? I'm asking because once I understand what you're trying to code, I may be able to guide you to get there through a different path. You mention "Slow attacks are closer to the normal service access frequency." How can you differentiate these flows from regular flows? Have you tried threat intelligence such as the IP Reputation Feed from Team Cymru? |
Currently I have three gatekeepers, each with 1.5T capacity ddr4, is it possible to increase the BPF status parameter? |
1.5TB is certainly enough capacity to experiment with a larger BPF cookie. I wrote this patch to show the minimum amount of changes that you need to make to compile Gatekeeper with You can try larger cookies as well. I recommend using a multiple of 8 in Good luck! |
For this patch, should both gatekeeper and grantor be updated? |
Yes. |
Whether the budget1_byte of state in BPF is reduced cumulatively or re-decreased every time pkt_len. For example
budget1_byte=1024
Does it decrease cyclically, or re-start from 1024-pkt_len each time?
In a cap_expire_sec time, if a flow is recalculated every time, then every time I launch an attack, it will be smaller than budget1_byte, won’t it never be possible to trigger rejection?
The text was updated successfully, but these errors were encountered: