Thanks!
Doug

On Sun, Dec 2, 2012 at 4:15 PM, Daniel Borkmann <[email protected]> wrote:
> 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
>>
>> --
>>
>>
>
> --
>
>



-- 
Doug Burks
http://securityonion.blogspot.com

-- 


Reply via email to