Re: [squid-users] authenticate access to reverse proxy

On 19/03/2013 4:10 p.m., James Harper wrote:
>
>> -----Original Message-----
>> From: Amos Jeffries [mailto:squid3_at_treenet.co.nz]
>> Sent: Tuesday, 19 March 2013 10:35 AM
>> To: squid-users_at_squid-cache.org
>> Subject: Re: [squid-users] authenticate access to reverse proxy
>>
>> On 19/03/2013 12:57 a.m., James Harper wrote:
>>> Say I have a squid reverse proxy with https enabled on it at
>> https://apps.example.com. This serves a number of apps including:
>>> /owa - outlook web access
>>> /rpc - ms terminal server gateway
>>> /intranet
>>> /bugtracker
>>> /svn - svn anon browser access
>>> /procedures
>>>
>>> These are spread across a bunch of completely different servers (some
>> linux, some windows) and works really really well. It has been decided that
>> some of the individual applications are not secure enough. /owa, /rpc, and
>> /bugtracker are fine, while /intranet, /procedures, and /svn are not. I have
>> set up acls to deny external access to the insecure apps but now want to put
>> some front end security on them such that when a user first tries to access
>> one with a browser they are redirected and required to sign in to a web
>> forms based page. The idea I have for this is:
>>> . create an sqlite database in /var/run or some other throwaway location
>> NP: sqlite is know to be terribly slow for this type of thing. You may
>> want to reconsider the exact DB type there.
>>
> Noted. I've used sqlite3 for lightweight tasks but I'll look around. Any suggestions?
>
>>> . redirect users using deny_info to the sign in page (php)
>>> . on successful authentication, set a cookie (some random string eg md5
>> hash of username, password, and time) and create a corresponding entry in
>> the database then redirect user to original page (only possible with squid
>> 3.2.x I believe...)
>>
>> No. Possible with older Squid as well. Pass the original URL to the
>> splash page as a query-string parameter using %s.
> Good to know!
>
>>> . create an external acl helper that is passed in the request header
>> corresponding to the cookie, decodes the cookie value from the header, and
>> looks up the entry in the database (and maybe timestamp last access). If
>> present, report OK
>>> . create a cron job nightly (or hourly or whatever) to delete stale records
>> from the database to keep the size reasonable
>>
>> Why not delete stale entries immediately as the helper locates them as
>> being stale in the DB? that speeds up all later fetches which would have
>> found it and had to re-test. The number of DB entries is then also never
>> more than your current user load at any point - as opposed to the total
>> unique loading across the entire day so far.
> I'd need to benchmark this. Doing a 'DELETE FROM sometable WHERE timestamp < @cutoff' frequently may hurt more than the extra entries hurt a select. I can add an index but that hurts inserts...
>
>>> The cookie here only serves as a lookup into the database, and I believe will
>> be supplied by the browser on any user request.
>>
>> Squid has a bundled session helper which supports both passive and
>> active (login) sessions. I suggest taking a good look through its
>> documentation and considering whether you can use it instead. Doing so
>> will keep all the session criteria private to the server instead of
>> using Cookie to send out details an attacker can capture and break in with.
>> http://wiki.squid-cache.org/ConfigExamples/Portal/Splash
>>
> I had studied that page before posting this and came to conclusion that I couldn't use it, but maybe that's incorrect. I can't use regular http authentication because the underlying apps use it, which I thought precluded the use of the login flag. My setup is effectively that the reverse proxy is a transparent proxy server. I can't use IP address because there is no guarantee that a single user will retain the same IP address across a session (users are mobile and can't guarantee a 3G session stays up and keeps same IP address), and can't guarantee that there is only one user behind a single IP address.
>
> Also, I couldn't see how to only engage the session helper only once the user had successfully authenticated to my forms page, but maybe more study is required?

The LOGIN flag is just an internal token Squid sends to the helper to
generate a sessio for the format key. The session itself needs to be
generated form details normally sent by the client, so that other
requests can look it up without anything special existing. Although if
you wanted to you could have the client add a special header
  NP: Cookie is bad choice to use here because the header gets
'polluted' with other cookies unrelated to your system (ie the actual
website cookies or advert cookies) - which will break the lookup if you
use it.

Amos
Received on Tue Mar 19 2013 - 04:29:39 MDT