Introducing the p0f BPF compiler | Hacker News Reader

Introducing the p0f BPF compiler

blog.cloudflare.com

69 pointsjgrahamc13 comments

This is kind of scary http://lcamtuf.coredump.cx/p0f3/

I hope people are cautious when using p0f. When accessing it on my iPhone 6 from my cell network (not Wi-Fi) in Chrome, it reports the following:

    Detected OS = Linux 3.x [generic]
    HTTP client = unknown
    Network link = Ethernet or modem
    Distance = 11
    Language = English
    Uptime = 36 days 18 hrs 26 min (modulo 198 days)
    WARNING: Inconsistent fingerprints, probably indicative of
    IP sharing or proxyingNote: looks like you're hitting this
    page through a proxy (your Via header is set). This
    affects the apparent identity of your system on TCP/IP
    level.

Perhaps my cell network is acting via proxy (wouldn't surprise me), but your average user won't know this. If you're going to filter or identify traffic based on p0f, be careful to not negatively impact honest users who might be misidentified (either because p0f got the fingerprint wrong or because there's some proxy in the middle).

My first thought reading this was "lcamtuf works at cloudflare now?" Nope, cloudflare just took an awesome tool of his and made the kernel able to filter packets based on its signatures using bpf. Pretty cool.

It'd be nice to know what if any false indications this triggers. "we want to ratelimit" -- so is there any pathological behavior wrt the legit traffic (especially with ever-more-cleverly-reducing-round-trip protocols like QUIC)?

The pessimistic case is when the attack signature matches exactly the signature of real operating system. For example, if the attack resembles Linux, with the p0f-to-BPF you can generate a BPF that matches Linux SYN packets. This allows you to block these packets, and this of course can affect traffic from Linux machines.

So it's a much more complicated and brittle version of the OS detection built into OpenBSD's pf (via p0f signatures) a decade ago?

    block in proto tcp from any os Windows

http://man.openbsd.org/OpenBSD-current/man5/pf.conf.5#OPERAT...

http://man.openbsd.org/OpenBSD-current/man5/pf.os.5

Absolutely! (almost) everything in computer science can be summed up as: I've seen the same 10 years ago but a bit different.

The differences are:

- my understanding is that pf module is written in C and runs in kernel mode.

- my understanding is that pf os detection uses old p0f (2.x series) (not sure if it matters though)

- here, you have code in readable python that produces sandboxed bpf - which makes it actually useful.

Is it more complex? Well, you decide. Is kernel mode C "more complex" than p0f-to-bpf compiler in python?

Is it more complex? Well, you decide. Is kernel mode C "more complex" than p0f-to-bpf compiler in python?

Obviously C code running in a kernel is "more complex" than a Python script.

I was talking about how users would actually use this p0f BPF tool. Compare this:

    ./bpfgen p0f -- 4:64:0:*:mss*10,6:mss,sok,ts,nop,ws:df,id+:0
    sudo iptables -A INPUT -p tcp --dport 80 -m bpf --bytecode "39,0 0 0 0,48 0 0 8,37 [...]"

with how you would actually use the "complex" C code in pf:

    block in proto tcp from any os Windows

That's not what we are doing with this. We are dealing with DDoS SYN floods, not "block Windows".

You mean like:

  pass in proto tcp from any to any port www synproxy state

I'm being a little tongue-in-cheek, though. It seems your solution is either a superset of the above, or perhaps just an alternative. And compiling p0f to BPF is definitely an interesting topic and quite noteworthy.

Though, I would dispute the notion that compiling to BPF is either simpler or more secure. The BPF JIT has been responsible for several kernel exploits recently. The original BPF was much simpler but irrelevant at this point. While I believe the design of the contemporary incarnation in Linux is still provably correct, the implementation manifestly still has bugs. And from a user perspective it's really difficult to beat the syntax of PF's pf.conf. pf.conf can't be emulated by using a front-end configuration generator for iptables + company as the semantics of many tasks require implementation logic in the kernel, whether as extensions to BPF or to the networking subsystem.

This is old and very good tool for passive identification. I wrote my engineer thesis based on p0f 10 years ago. It mostly uses differences in implementation of TCP/IP stacks between OS and couple of other things to recognize the OS. You can add new fingerprints yourself.

I use p0f and iptables but never thought to use bpf module to hook both together, what a wise way for battling DDOS.

The uptime info is a bit creepy.

Reply on news.ycombinator.com