On Sun, Dec 2, 2012 at 10:11 PM, Doug Burks <[email protected]> wrote:
> Well, since you asked...  :)
>
> I know I can do the following to allow netsniff-ng to be run as a non-root 
> user:
> sudo setcap cap_net_raw,cap_ipc_lock,cap_sys_admin,cap_net_admin=eip 
> netsniff-ng
>
> But it would be quite nice if netsniff-ng had internal support for
> dropping to a non-root user after opening the eth device.  Many other
> pcap tools (such as daemonlogger, snort, suricata, etc.) support this
> via command-line arguments like:
> -u user -g group
> OR
> --user user --group group
>
> Thoughts?

Good point!

I'll add this to the TODOs for the next official release.

> On Sun, Dec 2, 2012 at 3:50 PM, Daniel Borkmann <[email protected]> 
> wrote:
>> 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
>>>>
>>>> --
>>>>
>>>>
>>
>> --
>>
>>
>
>
>
> --
> Doug Burks
> http://securityonion.blogspot.com
>
> --
>
>

-- 


Reply via email to