Dave Evans wrote:
> On Thu, May 14, 2009 at 11:18:47AM +0800, W B Hacker wrote:
>>>> Using p0f with the barest of directives:
>>>>
>>>> p0f -i vr0
>>>>
>>>> What am I doing wrong w/r p0f & Exim?
>>>>
>>>> Does p0f need Exim to do a 'delay' before rejection in order to ascertain
>>>> the caller's OS?
>>> I've been using p0f for a while (> 1 year I think) with no problems. p0f runs
>>> "passively" and then Exim queries it via a ${perl expansion (though I suppose
>>> if I wanted to I could write a kind of exim-to-p0f proxy and use a plain
>>> ${readsocket instead).
>>>
>>> Currently all I'm doing with it is querying p0f from exim and logging the
>>> results - the results don't actually /affect/ anything (except the contents of
>>> the log). But to that extent, it works just fine.
>
> I run p0f simply as
>
> p0f -i ethX -Q /path/to/socket -u p0f \
> '(tcp[tcpflags] & (tcp-syn|tcp-fin|tcp-rst) != 0) and not ether src XX:XX:XX:XX:XX:XX'
>
> where XX:XX:XX:XX:XX:XX is the MAC addr of the ethX interface. Mine is a
> quiet system, and it shows no signs of failing to query p0f.
>
> That said, (a) it is a /very/ quiet system and (b) I've never really looked
> into p0f's -c/-e/-M options.
>
> If I was running this on a busy system and there were signs of trouble I'd
> probably look to the -c option first, and also observe p0f's exit stats
> messages (see man p0f, "P0f, when run without -q, also reports average packet
> ratio on exit").
>
>
ACK. The initial test box was so lightly loaded some of the traffic was messages
I sent it just so I didn't have to wait 20 minutes to capture something...
And *those* were the ones most often missed-out. Given they had traversed under
20' of CAT5E @ 100 BT one hop of decent switch fabric, I'm not too fussed.
OTOH, I'm watching P0f from an ssh session, no file-writes or other manipulation
involved.
Bill
