> Giampaolo, > > > > I know, and that is quite unfortunate, as we are missing p0f info > > > on mail that arrives over IPv6.... > > > > Mmmh... I see. Unfortunately, I guess there are some difficulties in > > designing a "stable" IPv4+6 query protocol: apart different address > sizes, > > there are too many further data available in a IPv6 packet that may > > (unpredictably to me) influence the structure of a response packet. > > As far as queries are concerned, all it matters is to pass on > both IP addresses and both port numbers to p0f, then let it > worry on how to deal with them. Both IPv4 and IPv6 use the same > port numbers, and IP address is just extended from 32 to 128 bits. > That is all the query protocol needs to know, it can deal with > addresses as opaque objects. No IP options are of any importance > to the query protocol (they only do matter to internals of > p0f snooping). The p0f-analyzer.pl already does it thanks to > its ascii representation of IP addresses (not that it helps > with the current p0f unfortunately). > > I can live with queries themselves over IPv4 only (although > it hardly matters, most of the differences is hidden in the > sockets API anyway, and modern Unix/Linux/Windows kernels > are already well settled in the IPv6 world). > > > An unrelated note: in case of wildcard port numbers where multiple > cached entries may match a query (e.g. when multiple hosts with > possibly different OS are behind a NAT), p0f-analyzer.pl returns the > longest common substring of all matches, as anchored at the beginning.
Ok. I could try to cope with this by retrieving a "valid field" mask along with the response: fields marked "valid" carry values shared by all matches of the query, while the "not valid" ones are left undefined. The actual implementation of the "p0f -0" queries would simply return the latest matching query. Of course, both this and the "common substring" methods offer the neck to some ways to defeat any identification purpose... Another way (which, however, would probably need some "intervention" into the detecting code) could be to retrieve the last entry in cache for which the greatest traffic had been seen. This would probably better identify the source and would require too much effort from a spammer to be defeated. What's your thoughts about? Giampaolo > Mark > > ----------------------------------------------------------------------- > -- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVD > EV > _______________________________________________ > AMaViS-user mailing list > AMaViS-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/amavis-user > AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3 > AMaViS-HowTos:http://www.amavis.org/howto/ ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ AMaViS-user mailing list AMaViS-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amavis-user AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3 AMaViS-HowTos:http://www.amavis.org/howto/
