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.
. 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.
. 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.
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
Amos
