By the way, if you have any other feature requests / wishes (besides the list in TODO) that might be useful for many users, let us know, and we'd be happy to further improve the toolkit.
On Sun, Dec 2, 2012 at 5:49 PM, Daniel Borkmann <[email protected]> wrote: > On Sun, Dec 2, 2012 at 5:47 PM, Doug Burks <[email protected]> wrote: >> Thanks for the always fast response! Deploying the "tcpdump -dd" solution >> now. > > Thanks! > > If we have something new regarding bpfc, I'll announce it on the list anyway. > >> On Sun, Dec 2, 2012 at 9:00 AM, Daniel Borkmann <[email protected]> >> wrote: >>> On Sun, Dec 2, 2012 at 2:55 PM, Doug Burks <[email protected]> wrote: >>>> On Tue, Oct 30, 2012 at 10:41 AM, Daniel Borkmann >>>> <[email protected]> wrote: >>>> <snip> >>>>>> -f /etc/nsm/$HOSTNAME-$INTERFACE/bpf-pcap.conf >>>>>> This should be the same option in netsniff-ng, but my understanding is >>>>>> that I'll need to convert my "human-readable" bpf-pcap.conf using >>>>>> "tcpdump -dd"? >>>>> >>>>> Yes, it you want to use filters and bpf-pcap.conf contains >>>>> tcpdump-like filters, run them through "tcpdump -dd <my filter>" > >>>>> out.ops and then pass out.ops to netsniff-ng via "--filter out.ops". >>>>> That's it; netsniff-ng will then automatically enable the BPF JIT if >>>>> it's available in your kernel. This feature translates BPF filters >>>>> into architecture optimized machine opcodes within the kernel. >>>> >>>> We've officially replaced daemonlogger with netsniff-ng and it appears >>>> to be working well! However, we haven't included BPF functionality >>>> yet, so I need to add that now. I can do what's described above, but >>>> the FAQ also says: >>> >>> Cool, I'm very happy about that! >>> >>>> "If you try to create custom socket filters with tcpdump -dd, you have >>>> to edit the ret opcode (0x6) of the resulting filter, otherwise your >>>> payload will be cut off: >>>> >>>> 0x6, 0, 0, 0xFFFFFFFF instead of 0x6, 0, 0, 0x00000060 >>>> >>>> The Linux kernel now takes skb->len instead of 0xFFFFFFFF. If you do >>>> not change it, the kernel will take 0x00000060 as buffer length and >>>> packets larger than 96 Byte will be cut off (filled with zero Bytes)! >>>> It's a bug in libpcaps filter compiler. Detailed information about >>>> this issue can be found on our blog post." >>>> >>>> The linked blog post is no longer available. So is this an issue I >>>> need to be concerned about? >>> >>> Actually not anymore. I use Fedora and the tcpdump version there outputs: >>> >>> # tcpdump -dd ip >>> tcpdump: WARNING: eth0: no IPv4 address assigned >>> { 0x28, 0, 0, 0x0000000c }, >>> { 0x15, 0, 1, 0x00000800 }, >>> { 0x6, 0, 0, 0x0000ffff }, >>> { 0x6, 0, 0, 0x00000000 }, >>> >>> So they have changed this from 0x00000060 into 0x0000ffff. >>> >>> For bpfc itself, I didn't have time to finish the high-level compiler, >>> yet. We have an assembler-like compiler where you can also create >>> filters with, but for usability you can use the method described >>> above, of course. >>> >>> -- >>> >>> >> >> >> >> -- >> Doug Burks >> http://securityonion.blogspot.com >> >> -- >> >> --
