Implementing fast TCP fingerprinting with eBPF (opens in new tab)

What's the simplest way to implement eBPF filtering?

As in a NFTables/Fail2Ban level usability.

There are MANY cases for such an implementation. My service [1] implements such a thing, eBPF too, and my users do it for many valid reasons such as:

- shopping cart fraud

- geo-restricted content (think distributing laws)

- preventing abuse (think ticket scalpers)

- preventing cheating and multi-accounting (think gaming)

- preventing account takeovers (think 2FA trigger if fingerprint suddenly changed)

There is much more but yeah, this tech has its place. We cannot just assume everyone has a static website with a free for all content.

[1] https://visitorquery.com/

Why is it useless and harmful? Many of us are struggling—without massive budgets or engineering teams—to keep services up due to incredible load from scrapers in recent years. We do use rate limiting, but scrapers circumvent it with residential proxies and brute force. I often see concurrent requests from hundreds or thousands of IPs in one data center. Who do these people think they are?

I guess the blame is on me here for providing only a very brief context on the topic, which makes it sound like this is just anti-scraping solutions.

This kind of fingerprinting solutions are widely used everywhere, and they don't have the goal of directly detecting or blocking bots, especially harmless scrapers. They just provide an additional datapoint which can be used to track patterns in website traffic, and eventually block fraud or automated attacks - that kind of bots.

Sure, buts its a nice exploration to layer 4 type of detection

Almost nothing pays attention to 429s, at least not in a good way, including big-name sites. I've written a whole paper about it...

I downvoted you due to the way you're communicating in this thread. Be kind, rewind. Review the guidelines here perhaps since your account is only a little over a year old.

I found this article useful and insightful. I don't have a bot problem at present I have an adjacent problem and found this context useful for an ongoing investigation.

As a rule, strong feelings about issues do not emerge from deep understanding. -Sloman and Fernbach

One of the biggest use cases for fingerprinting is as a way to reject requests from bot traffic, as mentioned in the article. That accept/reject decision should be made as early in the session lifecycle as possible to minimize resource impact and prevent exfiltration of data. You're right that TCP flags don't provide as much signal, as the TCP stack is mostly handled by the OS and middleboxes. A better source of fingerprinting info is in the TLS handshake - it has a lot more configurability, and is strongly correlated with the user agent.

TCP fingerprinting remains effective because most proxies and load balancers preserve the original TCP options and behaviors from the client, passing through the distinctive stack characteristics that make fingerprinting possible.

This is a good point. I guess that if you have the luxury of controlling the front-end side of the web application you can implement a system that polls the server routinely. Over time this will give you a clearer picture. You can notice that most real-world fingerprint systems run in part on the Javascript side, which enables all sort of tricks.