block in proto tcp from any os Windows
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?
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 [...]"
block in proto tcp from any os Windows pass in proto tcp from any to any port www synproxy state
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.