I need a way to track and limit web sessions to a web app. A "session" is loosely defined as the single user browsing the pages of the said web app. I think it can be translated to:
- a session is defined as a tuple
<clientIP,vHost>alternatively as<clientIP,serverIP,serverPort>or<cookie,vHost>, depending on the layer and the data available - a session starts after the user has sent authentication data to a defined login URI
- a session ends after the user has hit the defined logout URI
- a session ends if a specified timeout has expired after the client has requested the last object
After the specified session limit has been reached, the next user should be directed to a custom error page. I also need a way to track the current number of sessions for monitoring purposes and the ability to whitelist the monitoring server (which is issuing queries to the webapp periodically) and exempt it from the limit.
What I can work with:
- RadWare AppDirector where the web application has an own farm defined and is running in reverse proxy mode
- Apache 2.2
- SLES 11 SP2
I would prefer not involving an additional proxy server, although would consider it if no other options remain.
The rationale behind all of this is that the aforementioned web app is easily overloaded and starts denying requests erratically, pissing off working users who (usually) lose form entry data in the process. By specifying a limit where an overload condition is less likely, we hope to create a well-defined failure condition where users would be told to return later if the load is likely to spike.
Edit: the web app is a 3-tier implementation with the first tier (presentation layer, implemented as CGI code in an Apache vHost) being rather simplistic and apparently limited to basic error handling and request load balancing among the application servers. It does not impose any significant load on the web servers it runs on – this is why we are running it in mere failover mode (no load balancing) in the AppDirector farm, which is supposed to somewhat simplify things.
Everything beyond this point is basically a black box to us – at the data tier we have an MSSQL database, but it is near impossible to get any meaningful information about the table structure from the vendor. The application servers are closed-source, the vendor has used a rather comprehensive framework for the implementation, but seems unable to answer even less complex operation-related questions.
Best Answer
The problem you are ultimately trying to solve is with the capacity of the application - and that's where you should be solving the problem. None of the components you mention has anything to do with session management for an HTTP application.
There are some tricks you can apply with the recent module in iptables or using fail2ban in the opposite way to the purpose it was designed for - but these both require a very detailled understanding of the tools and the problem domain. You could implement access control at the level of these components but driven by published state information from the application on the number of sessions.
Assuming, for the time being, that the application is a black box with no scope for modification / instrumentation (which is highly improbable) you can get this information from your apache logs by including the session cookie - filter or tail the logs to maintain a list of active cookies - and remove entries from the list when they coincide with the logout URL or have not been seen for the TTL.