Re: [squid-users] auth for system services
On 16/02/2013 3:23 p.m., James Harper wrote: On a Windows desktop there are often a bunch of system services that make http connections, either running as a system account or running as a user but that don't know how to authenticate. The list of these exceptions is tedious to maintain so it would be good to be able to authorise the users IP address once they have successfully authenticated to squid, sort of like the old style 'pop before smtp' auth used to work. Tedious to maintain? what exactly are you listing? I list services by approving and whitelisting destination domains. That is no much work, as the listing only needs adapting when the first time you encounter a service. A second, third... thousandth client system using that service does not make any difference. If such a solution was scriptable I could also use something like netfilter ipsets to allow access on non-http ports using squid authentication. What hooks exist to allow this sort of thing? Some Warnings first: * Be careful with this. It is not very safe to trust an IP just because you saw credentials from it earlier on a completely different connection. * Clients are able to run proxy software and share their internet connection with the world very easily these days. * You loose all tracking of any infections or malicious software they may be infected with. * You loose the ability for users to share machines. User A can shut down the machine, user B restart it and if they are fast enough the proxy shares the session started by user A. * the above means you loose the ability to identify which user is doing what actions (once the IP-based session is active the credentials are not used or logged). Anyways What you want to look at is the session helper, with its active mode (-a command line parameter). http://www.squid-cache.org/Versions/v3/3.2/manuals/ext_session_acl.html For example: external_acl_type session ttl=300 %SRC */usr/local/squid/libexec/ext_session_acl -t 300 -a* # allow client IPs which have already logged in earlier acl sessionActive external session http_access allow sessionActive # deny anyone not logged in (triggers the login process) acl auth proxy_auth REQUIRED http_access deny !auth # allow clients with login and create a session for them acl sessionStart external session LOGIN http_access allow auth sessionLogin If you want to be fancy you can add the following snippet *above* the sessionActive ACL test and setup a script which when the user logs off their machine makes a web request (without credentials) to http://example.com/logout . That will help avoid the session-sharing problem provided people logout properly. # magic logout. Visit the URL http://example.com/logout from a script on the box to log this client out of the session when they logout or shut down. acl sessionLogout external session LOGOUT acl logoutMagic url_regex ^http://example.com/logout$ http_access deny magicLogout sessionLogout Amos
RE: [squid-users] auth for system services
On 16/02/2013 3:23 p.m., James Harper wrote: On a Windows desktop there are often a bunch of system services that make http connections, either running as a system account or running as a user but that don't know how to authenticate. The list of these exceptions is tedious to maintain so it would be good to be able to authorise the users IP address once they have successfully authenticated to squid, sort of like the old style 'pop before smtp' auth used to work. Tedious to maintain? what exactly are you listing? I list services by approving and whitelisting destination domains. That is no much work, as the listing only needs adapting when the first time you encounter a service. A second, third... thousandth client system using that service does not make any difference. That's what I thought originally, but things like CRL's (every CA seems to use a new one - I've 'fixed' java 5 times in the past week) and skydrive (breaks every month or so as Microsoft change things) require continual maintenance and doesn't fail nicely. Some Warnings first: * Be careful with this. It is not very safe to trust an IP just because you saw credentials from it earlier on a completely different connection. Credentials will time out * Clients are able to run proxy software and share their internet connection with the world very easily these days. That's true of the existing username/password authentication anyway. But the site is small enough that we'd notice. * You loose all tracking of any infections or malicious software they may be infected with. How so? Username is first logged against IP address, then IP address is logged. Tracking is easy. * You loose the ability for users to share machines. User A can shut down the machine, user B restart it and if they are fast enough the proxy shares the session started by user A. I thought about that. Firstly, the above scenario doesn't happen, and if it did the login records are present on the PC anyway. * the above means you loose the ability to identify which user is doing what actions (once the IP-based session is active the credentials are not used or logged). But the IP address is, so the problem becomes a reporting problem. Anyways What you want to look at is the session helper, with its active mode (-a command line parameter). http://www.squid- cache.org/Versions/v3/3.2/manuals/ext_session_acl.html Thanks for taking the time to write all of this. Now I know that what I want to do is possible I can consider whether it is the best road forward. Have you ever considered integrating a SOCKS style proxy into squid? It requires a smart client of course but I can do that much under Windows. James
