You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
These basic statistics give a gist of what's going on in the network, but they lack enough depth to enable reports that show a more nuanced picture of the traffic and attacks. Adding log entries with raw information, such as logging information on all declined packets, is not a viable solution because too much disk I/O can degrade the forward performance of Gatekeeper servers, especially during attacks.
The following ideas are candidates for balancing more information and small overhead:
Grouping tuple information (i.e., source and destination IP addresses, protocol, and port numbers) of decline packets using a heavy-hitters algorithm and logging statistics on these heavy hitters. The old, never-merged pull request GSOC 2018: Implementing blackholing in Gatekeeper #94 offers an entry point for heavy-hitters algorithms since it implements the Space Saving Algorithm and RHHH algorithm. It is important to note that while heavy hitters provide a good summary of many attacks, it fails to describe highly distributed attacks that Gatekeeper can protect against.
Breaking the current statistics per destination IP address was suggested in this discussion.
Logging packets per second and bytes per second for each priority in the request channel. The intention here is to understand abuses of the request channel since only aggregated data is available now.
The text was updated successfully, but these errors were encountered:
Currently, Gatekeeper servers log basic statistics about the traffic. One of these log entries looks like this:
These basic statistics give a gist of what's going on in the network, but they lack enough depth to enable reports that show a more nuanced picture of the traffic and attacks. Adding log entries with raw information, such as logging information on all declined packets, is not a viable solution because too much disk I/O can degrade the forward performance of Gatekeeper servers, especially during attacks.
The following ideas are candidates for balancing more information and small overhead:
The text was updated successfully, but these errors were encountered: