Search squid archive

Re: authenticate access to reverse proxy

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 19/03/2013 4:10 p.m., James Harper wrote:
-----Original Message-----
From: Amos Jeffries [mailto:squid3@xxxxxxxxxxxxx]
Sent: Tuesday, 19 March 2013 10:35 AM
To: squid-users@xxxxxxxxxxxxxxx
Subject: Re:  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


[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux