> -----Messaggio originale----- > Da: [EMAIL PROTECTED] [mailto:amavis-user- > Giampaolo and others, > > > This in native C-language, which often means reduced size and > > increased performance with respect to perl's p0f-analyzer.pl. > > That's a poor excuse. Our p0f-analyzer.pl consumes about > 18 CPU seconds per day, and responses to queries are instantaneous.
1) it could consume even less cpu and memory; 2) using a pipe to vector data to the p0f-analyzer.pl is an ugly technique to be implemented by a daemon; 3) while there are distros which do supply an init script for p0f, you actually have to do your own daemonizing script for p0f + p0f-analyzer.pl, since something like it is not shipped with most (any?) of them; 4) p0f actually lacks an UDP interface to its cache, which would be something useful to other tools than amavis as well. > > I'm working on a udp-based version of the p0f's query interface > (among > > other things, it has to deal with client and server mismatches in > word > > endianess, [...] > | Also, p0f correctly uses __u32 and __u16 typedefs, but it seems to me > that > | doesn't enforce any kind of "structure packing" (in the #pragma > pack() > > Make sure to consider IPv6 addresses in new development work. Actually, p0f is not designed to sample any activity on the IPv6 stack and I don't have the knowledge about the p0f's 'client brand' detection problem to put my hands on it. However, the new query interface will be somehow plugin-based, thereby in the future it will be easy to develop a new IPv4+6 interface, while still preserving compatibility with the past. > Btw, queries in ASCII can avoid endianess problems. The main idea is not to do something suited only for amavis/spamassassin, but for other tools as well (nagios and the like, in example). So, my main concern will be to do something which is easily suitable to products already interfacing to p0f. This means that a data structure very close to the p0f's actual one will probably be implemented. However, the idea is to do something like a plugin-based interface, such that people may easily add further protocols (or version existing ones). A specific protocol will be identified by the signature field. Also, there are other ways to avoid problems with endianess. (un)pack() offers a lot of facilities to this which doesn't involve an integer to ASCCI to integer conversion chain. > > I can't simply adapt the p0f protocol to the p0f-analyzer.pl one, > > since the latter is too much specific to the amavis needs. > > What is so specific about it? > IP address comes in, p0f full response comes out. p0f-analyzer.pl listens on UDP for packets carrying a src-address and nonce tuple. The request packet doesn't supply a source-port field (I know amavis doesn't know it), which would make this protocol suitable also for other purposes. The idea is to implement a protocol in which the query interface expects basically a full triplet (src-address/src-port/nonce) while allowing src-port to be wildcarded by a 0 value. Also, the response to a query will basically be the one already returned by the p0f's unix interface (with the endianess of integer values in network order), not just a string representation which is meant to be used by humans. In the future, the p0f team may easily redesign the actual p0f's output in order to accommodate further needs, in example. This could eventually create troubles to spamassassin rules designed to cope with the actual output from p0f. By decoupling the amavis plugin from the p0f's output string would allow the first to build its own, well-defined string representation, or even to break some of the result fields in more attributes. This would help, I guess, in the design of more version-resilient p0f-based rules in spamassassin. > A nonce is needed in UDP protocols to protect client against > attacks (faked responses) from other hosts in the (internal) network. I'm not against nonces at all... :) > Mark Giampaolo ------------------------------------------------------------------------- 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/
