[ic] Possible bug: Too many new ID assignments for this IP address

Mike Heins mike at perusion.com
Tue Aug 23 21:29:44 EDT 2005

Quoting John1 (list_subscriber at yahoo.co.uk):
> In October 2004 I posted:
> http://www.icdevgroup.org/pipermail/interchange-users/2004-October/041215.html
> explaining what I thought was a bug which can result in *permanently* 
> blocked access to Interchange sites from ISPs who use proxy servers.
> To avoid this problem we are currently running with "RobotLimit 0", so it's 
> not really causing us a problem any more (although it would be nice not to 
> have to use RobotLimit 0).
> Here is the sub count_ip code (which is still the same as it was in October 
> 2004):
> sub count_ip {
> my $inc = shift;
> my $ip = $CGI::remote_addr;
> $ip =~ s/\W/_/g;
> my $dir = "$Vend::Cfg->{ScratchDir}/addr_ctr";
> mkdir $dir, 0777 unless -d $dir;
> my $fn = Vend::Util::get_filename($ip, 2, 1, $dir);
> if(-f $fn) {
>  my $grace = $Vend::Cfg->{Limit}{robot_expire} || 1;
>  my @st = stat(_);
>  my $mtime = (time() - $st[9]) / 86400;
>  if($mtime > $grace) {
>   ::logDebug("ip $ip allowed back in due to '$mtime' > '$grace' days");
>   unlink $fn;
>  }
> }
> return Vend::CounterFile->new($fn)->inc() if $inc;
> return Vend::CounterFile->new($fn)->value();
> }
> I believe crux of the problem is that this code is checking the last 
> *modified* time which actually has the effect of *permanently* blocking 
> large ISPs who use a relatively small number of proxy servers.
> ##########  snippet from my post in October 2004:
> So, here is the problem:  any IP address that is typically allocated more
> than 1 session id in a 24 hr period will never get its addr_ctr file
> expired.  i.e.  There needs to be a full 24 hr period without access from
> the same IP address before the addr_ctr file will be deleted thus
> re-allowing access from that IP address.  For large ISPs using a relatively
> small number of proxy servers this may *never* happen, and so access
> from their proxy servers is permanently blocked.
> ##########

I am perfectly willing to believe I have screwed up, but I had thought
this had been addressed with

	Limit robot_expire 0.05

This changes the 24-hour period to one hour. And since the first call is
always to count_ip() without incrementing the counter (and therefore the
mtime) the maximum lockout should be that one hour. If you have such
traffic that you assign 100 legitimate IP addresses in an hour, it means
you would have to have a much better robot defense than RobotLimit can

Also, a normal ISP proxy server should not see this; just if it is
running behind a NAT. The IP address used is not the IP of the proxy
server but the IP address of the user as sent by the proxy server.

I run some pretty busy Interchange servers, and I never see trouble
with this with the exception of NATs for fair-sized companies accessing
their own IC server. Even then, the above "Limit" fixes the problem.

Mike Heins
Perusion -- Expert Interchange Consulting    http://www.perusion.com/
phone +1.765.647.1295  tollfree 800-949-1889 <mike at perusion.com>

Just because something is obviously happening doesn't mean something
obvious is happening. --Larry Wall

More information about the interchange-users mailing list