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

21–30 of 42 posts

Re: Implementing fast TCP fingerprinting with eBPF

#21

Post by DamonHD »

OutOfHere wrote: post #6
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?

It is harmful because innocent users routinely get caught in your dragnet. And why even have a public website if the goal is not to serve it? What is the actual problem with serving users? You mentioned incredible load. I would stop using inefficient PHP or JavaScript or Ruby for web servers. I would use Go or Rust or a comparable efficient server with native concurrency. Survival always requires adaptation. How do y…

[flagged]

Re: Implementing fast TCP fingerprinting with eBPF

#22

Post by OutOfHere »

DamonHD wrote: post #21
OutOfHere wrote: post #6

Earlier quoted context omitted.

It is harmful because innocent users routinely get caught in your dragnet. And why even have a public website if the goal is not to serve it? What is the actual problem with serving users? You mentioned incredible load. I would stop using inefficient PHP or JavaScript or Ruby for web servers. I would use Go or Rust or a comparable efficient server with native concurrency. Survival always requires adaptation. How do y…

[flagged]

The truth is often unpleasant, and it owes you nothing. I ask you in return to be more open to it. By wanting to hide and suppress the truth, it is you who is not nice.

Re: Implementing fast TCP fingerprinting with eBPF

#23

Post by 10000truths »

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

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.

Re: Implementing fast TCP fingerprinting with eBPF

#24

Post by DamonHD »

OutOfHere wrote: post #22
DamonHD wrote: post #21

Earlier quoted context omitted.

[flagged]

The truth is often unpleasant, and it owes you nothing. I ask you in return to be more open to it. By wanting to hide and suppress the truth, it is you who is not nice.

You are wrong and coming across entirely pompous. I see what I see on my servers, and you clearly have not seen the same.

Re: Implementing fast TCP fingerprinting with eBPF

#25

Post by immibis »

OutOfHere wrote: post #16
immibis wrote: post #12

Earlier quoted context omitted.

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.

Once you spot a specific pattern you can detect that pattern.

Re: Implementing fast TCP fingerprinting with eBPF

#26

Post by noident »

DamonHD wrote: post #20
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...

Who cares if they pay attention to 429s? Your load balancer is giving them the boot, and your expensive backend resources aren't being wasted. They can make requests until the cows come home; they're not getting anything until they slow down.

Re: Implementing fast TCP fingerprinting with eBPF

#27

Post by ranger_danger »

noident wrote: post #26
DamonHD wrote: post #20

Earlier quoted context omitted.

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...

Who cares if they pay attention to 429s? Your load balancer is giving them the boot, and your expensive backend resources aren't being wasted. They can make requests until the cows come home; they're not getting anything until they slow down.

If you're rate-limiting by IP, well... some entire countries have only a handful (or one) externally visible IP.

Re: Implementing fast TCP fingerprinting with eBPF

#28

Post by ranger_danger »

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.

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

Re: Implementing fast TCP fingerprinting with eBPF

#30

Post by v5v3 »

spense wrote: post #29

i've been looking at this recently and this isn't just for bots. ebpf fingerprinting is how cloudflare quickly detects ddos attacks. https://blog.cloudflare.com/defending-the-internet-how-cloud...

What's the simplest way to implement eBPF filtering?

As in a NFTables/Fail2Ban level usability.

Post reply on HN