Re: New module for anonymous ip logging

2010-10-06 Thread Franz Schwartau
Hi Ben,

thanks for your answer.

On 06.10.2010 01:11, Ben Noordhuis wrote:
 Hi Franz, welcome. Replies inline:
 
 On Wed, Oct 6, 2010 at 00:49, Franz Schwartau fr...@electromail.org wrote:
 How should the module react to a failed initialization of seed_rand() in
 iphash_create_server_config() (line 90)? Returning NULL in
 iphash_create_server_config() doesn't seem to help. I'd like to disable
 the module somehow if the random generator could be initialized properly.
 
 Add a 'initialized' flag to iphash_config_t and check its value in 
 log_ip_hash.
 
 That said, if security is an issue - which I presume it is - you are
 probably better off aborting.

I thought about something like this, too. The seeding in
iphash_create_server_config() could be rewritten to

if ((rv = seed_rand())) {
ap_log_error(APLOG_MARK, APLOG_ERR, 0, s,
Unable to generate random bytes: %pm, rv);
} else {
 generate_salt(cf-salt, SALT_SIZE);

}

In log_ip_hash() (the function registered with log_pfn_register()) I
could check if cf-salt is non empty. So I could save a flag.

But how exactly can I abort? If NULL is returned from log_ip_hash() a
'-' is printed for the % directive from mod_log_iphash only.

 No other module checks if the return value of apr_palloc() or
 apr_pcalloc() is NULL. Does it mean memory allocation via apr_palloc()
 will never fail and memory size is indefinitely? ;-)
 
 Yep. And if memory turns out to be finite after all, the APR will tear
 down the process.

Ah, ok, I see. Thanks for clarifying. I'm not familiar with APR, yet.
But not checking the return value is strange if you are used to plain
malloc(). :-)

Best regards
Franz


Re: New module for anonymous ip logging

2010-10-06 Thread Franz Schwartau
This is why mod_log_iphash adds a random, unknown 128 character string
in front of the IPv4 address before hashing with MD5. So you have to
search within 64^128 * 2^32 possibilities instead of just 2^32. :-)

On 06.10.2010 07:16, Ted Dunning wrote:
 It is less a matter of time than you calculate.
 
 For IPV4, you only have 32 bits to search.
 
 On Tue, Oct 5, 2010 at 4:13 PM, Franz Schwartau fr...@electromail.orgwrote:
 
 Yes, of course, but all (cryptographic) hash functions are vulnerable
 to brute force attacks. It's just a question of effort/time.