Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Implementing fast TCP fingerprinting with eBPF

halb.it

Post reply on HN
Print view View original

11–20 of 42 posts

Re: Implementing fast TCP fingerprinting with eBPF

#11

Post by Retr0id »

OutOfHere wrote: post #7
halb wrote: post #3

Earlier quoted context omitted.

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 eve…

If it's making a legitimate request, it's not an automated attack. If it's exceeding its usage quota, that's a simple problem that doesn't require eBPF.

This is an overly simplistic view that does not reflect reality in 2025.

Re: Implementing fast TCP fingerprinting with eBPF

#12

Post by immibis »

aorth wrote: post #5
OutOfHere wrote: post #2

More useless and harmful anti-bot nonsense, probably with many false detections, when a simple and neutral rate-limiting 429 does the job.

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?

Residential proxy users are paying on the order of $5 per gigabyte, so send them really big files once detected. Or "click here to load the page properly" followed by a trickle of garbage data.

Re: Implementing fast TCP fingerprinting with eBPF

#13

Post by b0a04gl »

why do fingerprinting always happens right at connection start ,usually gives clean metadata during tcp syn. but what is it for components like static proxies or load balancers or mobile networks ,all of these can shift stack behavior midstream. this can make this activity itself a obsolete

Re: Implementing fast TCP fingerprinting with eBPF

#14

Post by halb »

b0a04gl wrote: post #13

why do fingerprinting always happens right at connection start ,usually gives clean metadata during tcp syn. but what is it for components like static proxies or load balancers or mobile networks ,all of these can shift stack behavior midstream. this can make this activity itself a obsolete

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.

Re: Implementing fast TCP fingerprinting with eBPF

#15

Post by benreesman »

I have work reasons for needing to learn a lot about kernel-level networking primitives (it turns out tcpdump and eBPF compatible with almost anything, no "but boss, foobar is only compatible with bizbazz 7 or above!").

So when an LLM vendor that shall remain nameless had a model start misidentifying itself while the website was complaining about load... I decided to get to the bottom of it.

eBPF cuts through TLS obfuscation like a bunker buster bomb through a ventilation shaft or was it, well you know what I mean.

Re: Implementing fast TCP fingerprinting with eBPF

#16

Post by OutOfHere »

immibis wrote: post #12
aorth wrote: post #5

Earlier quoted context omitted.

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?

Residential proxy users are paying on the order of $5 per gigabyte, so send them really big files once detected. Or "click here to load the page properly" followed by a trickle of garbage data.

There is no real way to confidently tell if someone using a residential proxy.

Re: Implementing fast TCP fingerprinting with eBPF

#17

Post by OutOfHere »

jeffbee wrote: post #9
OutOfHere wrote: post #2

More useless and harmful anti-bot nonsense, probably with many false detections, when a simple and neutral rate-limiting 429 does the job.

[flagged]

Please. Save your assumptions.

You can stop spam, but you will also stop regular users, and that is the problem. Your classifier is not as powerfully accurate as you think.

If you don't want to put something online, then don't put it online!

Re: Implementing fast TCP fingerprinting with eBPF

#18

Post by OutOfHere »

Retr0id wrote: post #11
OutOfHere wrote: post #7

Earlier quoted context omitted.

If it's making a legitimate request, it's not an automated attack. If it's exceeding its usage quota, that's a simple problem that doesn't require eBPF.

This is an overly simplistic view that does not reflect reality in 2025.

The simple reality is that if you don't want to put something online, then don't put it online. If something should be behind locked doors, then put it behind locked doors. Don't do the dance of promising to have something online, then stop legitimate users when they request it. That's basically what a lot of "spam blockers" do -- they block a ton of legitimate use as well.

Re: Implementing fast TCP fingerprinting with eBPF

#19

Post by jeffbee »

OutOfHere wrote: post #17
jeffbee wrote: post #9

Earlier quoted context omitted.

[flagged]

Please. Save your assumptions. You can stop spam, but you will also stop regular users, and that is the problem. Your classifier is not as powerfully accurate as you think. If you don't want to put something online, then don't put it online!

Regular users retry, that's the point of temp-fail on first attempt. Botnets never retry because they aren't real mailers with send queues. And the number of people who have ever intentionally operated a mailer from a Windows XP box on a residential ADSL line is very accurately approximated by zero.

Re: Implementing fast TCP fingerprinting with eBPF

#20

Post by DamonHD »

OutOfHere wrote: post #2

More useless and harmful anti-bot nonsense, probably with many false detections, when a simple and neutral rate-limiting 429 does the job.

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...
Post reply on HN