-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
John Hardin wrote: | On Wed, 2004-12-01 at 03:30, Paul L Daniels wrote: | |>An interesting idea was floated by my eyeballs recently for combatting |>invalid email (especially since zombie machines are now rather |>prevailant), what if you could fingerprint the sending server and |>(say) deny all Win XP/95/98 machines from sending to port 25 were |>which not on your own domain. | | | Interesting idea. It sounds a little heavy to be doing for every inbound | message, though, and it assumes that you're letting fingerprinting | traffic out of your network - I, for example, block all NetBIOS and | similar ports at my boundary, so fingerprinting wouldn't be useful. | | However, this sounds like it might be useful in Spamassassin: attempt to | contact the sender on port 25, and add a little to the spamminess score | if the connection is refused or times out. | | It might also be useful to try connecting to the backdoor ports for the | better-known spam worms and add a few points if the connection succeeds.
Since our concern is really only with inbound connections (to port 25), there's no need to use active fingerprinting for this--passive fingerprinting (e.g. p0f) can do the job with minimal resources and without incurring any additional network delays or connection issues. Tools like p0f examine the structure of the packets received by your server and use these to determine the operating system of the host that originally constructed those packets, based on the TCP/IP stacks used by different OS vendors. There's no need to send any packets back out at the sending host, just add a p0f tap to port 25 of your mail server and watch the fingerprints arrive with your incoming mail.
The catch, as far as something like SpamAssassin is concerned, is that SpamAssassin isn't necessarily going to be installed on the host that the sender connected to (i.e. your MTA). On smaller sites this may be the case, but at larger installations where content-filtering is done separately from mail-processing, you'd need to work out a more complicated arrangement to get the p0f results from your MTA to SpamAssassin.
One workaround might be to use a local DNSBL (e.g. rbldnsd), and create a new IP address entry in the DNSBL based on the p0f results. A script running on the MTA host could add these entries, perhaps assigning a different result code for different classes of OSes. SpamAssassin could then consult this local DNSBL and use the result code to assign a score accordingly.
Another alternative might be to use a script on the MTA host to cache the p0f data by IP address in a SQL database that a new SpamAssassin plug-in could consult.
The basic premise, though, has merit, and I've been thinking along these lines for quite a while now. Its main value is in zombie-detection, since legitimate MTAs won't be running on desktop OSes like Win95/98/etc.
- -- Robert LeBlanc <[EMAIL PROTECTED]> Renaissoft, Inc. Maia Mailguard <http://www.maiamailguard.com/>
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFBrjYqGmqOER2NHewRAvgQAJ9otQgwcxcMuAr3RHh+/5wq+Nn5oQCfT/9/ emYLb05dxoNitqEA7gmwmXc= =w4ap -----END PGP SIGNATURE-----
