Hi Daniel,

I tested using options similar to what we normally use.  It writes the
first pcap correctly (although I notice that the ownership is
root:root instead of daemon:daemon), but once the 1MiB interval has
been reached and netsniff-ng tries to rotate to the second pcap, it
fails when setting io prio.

./netsniff-ng -i eth0 -o /tmp/test/ -s --prefix snort.log. --interval
1MiB --user 1 --group 1
netsniff-ng 0.5.8-rc0
Running! Hang up with ^C!

Failed to set io prio for pid!


ls -alh /tmp/test/
total 3.3M
drwxr-xr-x  2 daemon daemon 4.0K Jan 21 11:08 .
drwxrwxrwt 13 root   root    12K Jan 21 11:06 ..
-rw-r--r--  1 root   root   1.1M Jan 21 11:05 snort.log.1358784314.pcap
-rw-r--r--  1 daemon daemon   24 Jan 21 11:05 snort.log.1358784337.pcap


Any ideas?

Thanks,
Doug

On Mon, Jan 21, 2013 at 5:01 AM, Daniel Borkmann <[email protected]> wrote:
> On 01/19/2013 02:54 PM, Doug Burks wrote:
>>
>> Thanks so much!
>
>
> I'd be grateful if you can test it on your system.
>
> It should work for most cases. In netsniff-ng, I've seen that it exits
> non-gracefully
> when netsniff-ng is in promisc mode, since after destroying the mmap'ed
> rings it tries
> to put the card into non-promisc again, but has no rights for it (since
> we've dropped
> it). I don't think it makes much sense to regain privileged rights only for
> the
> cleanup work.
>
>
>> On Fri, Jan 18, 2013 at 3:37 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
>>>
>>>
>>> Done, after setup, you can now drop privileges in netsniff-ng and
>>> trafgen.
>>>
>>>> Thoughts?
>>>>
>>>> Thanks for your consideration!
>>>>
>>>> Doug
>>>>
>>>>
>>>> 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