[NoCat] problems renewing logins [ timeout issues? ]

[Ben Steinberg]

I've been meaning to repond to this for some time.  I don't know
whether your problem is like ours, but you may want to look into it.

We have had an intermittent problem similar to this, in which
logged-in clients are forced back to the login screen.  It occurs
during an ARP spoofing attack.  The initial technical fix for the
attack was to put a large number in
/proc/sys/net/ipv4/neigh/eth1/locktime, so that clients can't change
their MACs willy-nilly -- that prevents the attacker from actually
sitting in the middle and interfering with traffic, but it constitutes
a denial of service, since attacked clients can no longer get past the
login screen.

The real fix for our problem turned out to be one of management; we
were able to identify the user whose computer was infected and was
attacking other clients, and told her she needed to clean her computer
before using our system again.

A way to tell if an ARP cache spoofing attack is occurring is to run
"ip neigh show dev eth1" (or whatever interface you're using) -- if
two or more entries share a MAC address, one is attacking the
other(s).  I wrote a little script to keep an eye on the ARP table and
let me know if an attack is happening.

Please let me know if you have any questions.  Also, if anyone has a
better approach to this problem, I'd love to hear it.

Ben

On Tue, Sep 18, 2007 at 12:43:37PM +0100, Steve Platt wrote:
> 
> 
> I previously posted a query about an intermittent problem that has only 
> started to occur recently; in which I said:
> 
> > ... *sometimes* our client computer seems to get "cut off"
> 
> I think that this has something to do with the "IdleTimeout" (ARP table) 
> feature, judging by the logged message "Expiring inactive connection from ..."
> 
> I have seen client connections getting "expired" by Gateway.pm only 2 or 3 
> minutes after successfully renewing their login.
> 
> So now I do not think they are failing to renew correctly, I think that 
> despite renewing regularly (every 7.5 minutes) they are losing their ARP table 
> entries and that this is tripping the IdleTimeout code.
> 
> Perhaps my settings are stupid; after all I finf the timeout settings a bit 
> confusing so I could have made a mistake. We currently have :-
> 
>  LoginTimeout is set to the recommended 600 seconds (10 minutes)
>  IdleTimeout  is not set, I believe the default is 300 seconds (5 minutes)
> 
> Any thoughts please?
> Steve Platt
> 
> 
> 
> _______________________________________________
> NoCat mailing list
> NoCat at lists.nocat.net
> http://lists.nocat.net/mailman/listinfo/nocat