In another thread covering greylisting, Mike Cardwell posted that greylisting
could be skipped when (among other entries):
> 2.) If P0F detects the connecting host to be non-Windows (Used P0F for this)
Which sounded interesting, so....
Using p0f with the barest of directives:
p0f -i vr0
... on an R&D box during a period in which only two test messages were transferred:
- Neither of the two complete smtp session test messages were logged as
connections by p0f at all - their OS sig had been vetted separately, but was
absent here.
- all 6 arrivals that *were* logged on port 25 did in fact ID as Windows.
-- None were legitimate, nor did they complete.
Exim, during the same period, logged:
- the two accepted and processed test transfers
- 13 *further* arrivals rejected in acl_smtp_connect, of which:
-- 12 rejected in under one second for missing PTR RR
-- 1 had a PTR RR, but failed forward/reverse verification in ~3 seconds.
In total, 165 connections were logged by p0f - most NOT to port 25 [1].
Despite a default packet-window of 1ms, vs a connection duration of perhaps 500
ms, p0f missed roughly half the connections to port 25 that Exim DID log.
There were no duplicate source IP's among those.
Question (Mike),
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?
Thanks,
Bill
[1] 79% were ID'ed as Linux, all but one attempted break-ins on port 22.
The surprise here was that NO compromised Winboxen were detected by p0f as
trying that - on port 22 or otherwise. IPFW might not agree..
Perhaps WinZombies just don't hang on the teat at 22 as long as they do on 25?
