On 20/08/11 18:32, Thirawut Muninta wrote:
Dear Squid Support Team,
I'm running squid2.6 stable6 on CentOS 5.3 linux server.
I use "max_user_ip" directive to confirm "1 username could only
access with 1 IP address in a period 900 seconds"
There is no such directive in Squid configuration.
http://www.squid-cache.org/Doc/config/ lists every directive supported
since Squid-2.6.
There is an acl directive test type by that name. It is not capable of
measuring time units like you describe.
In fact no directives in Squid do duration like that. External helper
oftware are required for session tracking.
Every web accesses are OK.
But Google Talk program is breaking the rule.
User A : Start signin google talk and keep it login for a long
period ( Example : signin 08:00 and signout 12:00 )
User B : After 900 seconds pass, use the username of "User A"
signin google talk and it's success.
Your example displays a perfect example of why your use of that check as
a security measure is flawed.
Your policy assumes that one IP == one user. This is false.
As you can clearly see, Google Talk program need not be the same user as
logged into the browser. And the system software using proxied Internet
access may be using a third set of credentials from the machine login.
Every 900-seconds periods, squid can't hold the session of google talk.
Squid does not hold sessions. It has TCP connections, which can exist or
not. Inside TCP connections it has request transactions, which last
until the reply is finished.
What do you mean by "can't hold"?
Checking on access.log
Log occur only when "Sign In" and "Sign Out" actions. While it
login no more log.
access.log records are created when a transaction is _completed_.
Several possibilities there:
1) the chat channels are not using the proxy.
2) the chat channel is one long transaction which lasts for the entire
hours of data transfer until "Sign Out". Check the duration times logged.
3) nobody was chatting between sign in/out.
Could it solve by squid configuration (squid.conf) ?
Or, Are there have a solutions on this?
The solution is to change your policy (and config) to match the reality
of your needs or abandon all software which violates the policy. The
choice is yours.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.14
Beta testers wanted for 3.2.0.10
