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. . 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
RE: [squid-users] authenticate access to reverse proxy
-Original Message- From: Amos Jeffries [mailto:squ...@treenet.co.nz] Sent: Tuesday, 19 March 2013 10:35 AM To: squid-users@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? Thanks James James
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:squ...@treenet.co.nz] Sent: Tuesday, 19 March 2013 10:35 AM To: squid-users@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
