-
Notifications
You must be signed in to change notification settings - Fork 1
Research using "ezproxy kill" subcommand in place of fail2ban for terminating active sessions #31
Comments
Misc notes: ezproxy@ezproxy-test:~$ ./ezproxy kill
Session must be specified
ezproxy@ezproxy-test:~$ echo $?
1 ezproxy@ezproxy-test:~$ ./ezproxy kill FAKESESSION
Session FAKESESSION does not exist
ezproxy@ezproxy-test:~$ echo $?
3 ezproxy@ezproxy-test:~$ ./ezproxy kill REAL_SESSION_PLACEHOLDER
Session REAL_SESSION_PLACEHOLDER terminated
ezproxy@ezproxy-test:~$ echo $?
0 ezproxy@ezproxy-test:~$ ls -l ezproxy.hst
-rw-r----- 1 ezproxy ezproxy 429454 May 22 15:52 ezproxy.hst Checking from another login session, I confirmed that the |
Next steps:
This should hopefully allow better testing of brick once the session termination support is fleshed out. |
Now have a mock binary that returns random response codes. It's not pretty, but it works.
|
Brief testing seems to indicate that logging in, then within 10 seconds (maybe as little as under 5?) checking for active sessions may give false results indicating that no sessions are present. After waiting a bit the entries were found in the Thoughts:
|
Took a bit, but exported the code I wrote recently for this to a separate project: https://github.com/atc0005/go-ezproxy. I released that code (and project) yesterday as v0.1.0. The week before I spent working on the atc0005/check-cert project and finished deploying it on Monday. Now, I return here for the foreseeable future, hopefully until this feature is finished. |
This is supported via default values and applied |
Pinged the project lead where I discovered the While I plan on moving forward with implementing session termination support using the subcommand (I've been working on that this morning), I still have the concern that the subcommand will be removed in a future release. Reaching out for feedback is mostly "just to know", but I'm hoping that the knowledge of the feature is used widely enough by custom tooling at various institutions to discourage its removal. Thankfully if the subcommand is removed we'll still have the option of using fail2ban as originally designed for the v0.1.x release, but losing the ease of terminating sessions right away would be quite a loss (once this feature is baked in). |
Heard back that they learned of the command from the EZproxy mailing list where someone else brought it up. Hopefully this means the knowledge (and reliance) is widespread enough that a quick removal by OCLC is less likely to occur. |
Work continues on the feature branch and I am optimistic that this work will wrap up in the next week, potentially sooner. |
BACKSTORY Not long after giving a demo on using brick + fail2ban to timeout existing sessions, I stumbled across another project on GitHub which uses `ezproxy kill` to terminate an active user session: - https://github.com/calvinm/ezproxy-abuse-checker/blob/d7202e617305745cf272df9918b1e95ff030f63f/block_user.pl#L32 - https://github.com/calvinm/ezproxy-abuse-checker/blob/master/block_user.pl Despite OCLC Support indicating otherwise, native support for terminating user sessions was clearly available. This built-in support offers a much safer/localized effect vs banning the IP associated with a reported account; banning the IP has the potential to have a much larger splash radius blocking legitimate user accounts. The primary developer for the `calvinm/ezproxy-abuse-checker` project confirmed that they learned of this support on the EZProxy mailing list: calvinm/ezproxy-abuse-checker#1 This is encouraging, as I am (at least a little) optimistic that this unpublished support will persist in future versions, at least until official, fully documented and supported functionality for terminating sessions is included. IMPLEMENTATION This commit adds (optional) support for terminating user sessions using the official EZProxy binary already present on EZproxy servers. The fully-qualified location of this binary is configurable via command-line flag, environment variable or TOML-format configuration file. Additional settings are provided to tune the sessions search process such as configurable retries and search delay. The session termination process involves reading current sessions from the Active Users and Hosts "state" file that EZproxy uses to track sessions and hosts managed by EZProxy and then using the EZproxy binary to terminate each session via the `kill` subcommand. As part of the early development efforts I initially tried to use the latest Audit logs to pull session IDs, but quickly realized that while the format was easier to parse, it was far less stable due to log rotation and the need to resolve the active state ourselves (logins minus logouts, minus timeouts, etc). Some of that support still remains as of this commit, but may be removed in a future release if found to not be needed. As of this writing I believe it can still be used as part of interacting with a future endpoint. The aforementioned search delay and retry settings are provided to work around an observed race condition between EZproxy recording state changes and other applications (such as ours) attempting to read the current state. The delay in EZproxy writing the changes to disk (or kernel settings?) may result in our application attempting to terminate sessions related to a monitoring system report and not finding them within the Active Users and Hosts "state" file. The defaults attempt to strike a balance between waiting a little longer in order to "find" and terminate those sessions vs moving on with current findings. The defaults may need to be adjusted further depending on the production environment. TEAMS NOTIFICATIONS Minor changes in an effort to better clarify the purpose of the lead-in content: - explicit `step X of Y` labeling to notification titles - consistent use of Note (preferred) and Error (fallback) field values to generate primary "summary" text - rename "Request Annotations" to "Request Errors" to reflect dedicated single purpose vs blend of Note and Error field values as before ADDITIONAL SUPPORT During development, the necessary code to interact with EZProxy was first created as a local package, but was eventually moved to a separate module in order to break out the changes for separate use. See the `atc0005/go-ezproxy` project for further information on that module. Two separate binaries were created during testing: - mock `ezproxy` binary which returns known return codes and results + some extra to help condition validation checks for what I believe will be unknown/unpublished return codes I've yet to encounter - `es` binary used to search for and optionally terminate active user sessions for a specified username. This binary supports the same search retry and delay settings as `brick` refs GH-31, GH-59
BACKSTORY Not long after giving a demo on using brick + fail2ban to timeout existing sessions, I stumbled across another project on GitHub which uses `ezproxy kill` to terminate an active user session: - https://github.com/calvinm/ezproxy-abuse-checker/blob/d7202e617305745cf272df9918b1e95ff030f63f/block_user.pl#L32 - https://github.com/calvinm/ezproxy-abuse-checker/blob/master/block_user.pl Despite OCLC Support indicating otherwise, native support for terminating user sessions was clearly available. This built-in support offers a much safer/localized effect vs banning the IP associated with a reported account; banning the IP has the potential to have a much larger splash radius blocking legitimate user accounts. The primary developer for the `calvinm/ezproxy-abuse-checker` project confirmed that they learned of this support on the EZProxy mailing list: calvinm/ezproxy-abuse-checker#1 This is encouraging, as I am (at least a little) optimistic that this unpublished support will persist in future versions, at least until official, fully documented and supported functionality for terminating sessions is included. IMPLEMENTATION This commit adds (optional) support for terminating user sessions using the official EZProxy binary already present on EZproxy servers. The fully-qualified location of this binary is configurable via command-line flag, environment variable or TOML-format configuration file. Additional settings are provided to tune the sessions search process such as configurable retries and search delay. The session termination process involves reading current sessions from the Active Users and Hosts "state" file that EZproxy uses to track sessions and hosts managed by EZProxy and then using the EZproxy binary to terminate each session via the `kill` subcommand. As part of the early development efforts I initially tried to use the latest Audit logs to pull session IDs, but quickly realized that while the format was easier to parse, it was far less stable due to log rotation and the need to resolve the active state ourselves (logins minus logouts, minus timeouts, etc). Some of that support still remains as of this commit, but may be removed in a future release if found to not be needed. As of this writing I believe it can still be used as part of interacting with a future endpoint. The aforementioned search delay and retry settings are provided to work around an observed race condition between EZproxy recording state changes and other applications (such as ours) attempting to read the current state. The delay in EZproxy writing the changes to disk (or kernel settings?) may result in our application attempting to terminate sessions related to a monitoring system report and not finding them within the Active Users and Hosts "state" file. The defaults attempt to strike a balance between waiting a little longer in order to "find" and terminate those sessions vs moving on with current findings. The defaults may need to be adjusted further depending on the production environment. TEAMS NOTIFICATIONS Minor changes in an effort to better clarify the purpose of the lead-in content: - explicit `step X of Y` labeling to notification titles - consistent use of Note (preferred) and Error (fallback) field values to generate primary "summary" text - rename "Request Annotations" to "Request Errors" to reflect dedicated single purpose vs blend of Note and Error field values as before ADDITIONAL SUPPORT During development, the necessary code to interact with EZProxy was first created as a local package, but was eventually moved to a separate module in order to break out the changes for separate use. See the `atc0005/go-ezproxy` project for further information on that module. Two separate binaries were created during testing: - mock `ezproxy` binary which returns known return codes and results + some extra to help condition validation checks for what I believe will be unknown/unpublished return codes I've yet to encounter - `es` binary used to search for and optionally terminate active user sessions for a specified username. This binary supports the same search retry and delay settings as `brick` refs GH-31, GH-59
BACKSTORY Not long after giving a demo on using brick + fail2ban to timeout existing sessions, I stumbled across another project on GitHub which uses `ezproxy kill` to terminate an active user session: - https://github.com/calvinm/ezproxy-abuse-checker/blob/d7202e617305745cf272df9918b1e95ff030f63f/block_user.pl#L32 - https://github.com/calvinm/ezproxy-abuse-checker/blob/master/block_user.pl Despite OCLC Support indicating otherwise, native support for terminating user sessions was clearly available. This built-in support offers a much safer/localized effect vs banning the IP associated with a reported account; banning the IP has the potential to have a much larger splash radius blocking legitimate user accounts. The primary developer for the `calvinm/ezproxy-abuse-checker` project confirmed that they learned of this support on the EZProxy mailing list: calvinm/ezproxy-abuse-checker#1 This is encouraging, as I am (at least a little) optimistic that this unpublished support will persist in future versions, at least until official, fully documented and supported functionality for terminating sessions is included. IMPLEMENTATION This commit adds (optional) support for terminating user sessions using the official EZProxy binary already present on EZproxy servers. The fully-qualified location of this binary is configurable via command-line flag, environment variable or TOML-format configuration file. Additional settings are provided to tune the sessions search process such as configurable retries and search delay. The session termination process involves reading current sessions from the Active Users and Hosts "state" file that EZproxy uses to track sessions and hosts managed by EZProxy and then using the EZproxy binary to terminate each session via the `kill` subcommand. As part of the early development efforts I initially tried to use the latest Audit logs to pull session IDs, but quickly realized that while the format was easier to parse, it was far less stable due to log rotation and the need to resolve the active state ourselves (logins minus logouts, minus timeouts, etc). Some of that support still remains as of this commit, but may be removed in a future release if found to not be needed. As of this writing I believe it can still be used as part of interacting with a future endpoint. The aforementioned search delay and retry settings are provided to work around an observed race condition between EZproxy recording state changes and other applications (such as ours) attempting to read the current state. The delay in EZproxy writing the changes to disk (or kernel settings?) may result in our application attempting to terminate sessions related to a monitoring system report and not finding them within the Active Users and Hosts "state" file. The defaults attempt to strike a balance between waiting a little longer in order to "find" and terminate those sessions vs moving on with current findings. The defaults may need to be adjusted further depending on the production environment. TEAMS NOTIFICATIONS Minor changes in an effort to better clarify the purpose of the lead-in content: - explicit `step X of Y` labeling to notification titles - consistent use of Note (preferred) and Error (fallback) field values to generate primary "summary" text - rename "Request Annotations" to "Request Errors" to reflect dedicated single purpose vs blend of Note and Error field values as before ADDITIONAL SUPPORT During development, the necessary code to interact with EZProxy was first created as a local package, but was eventually moved to a separate module in order to break out the changes for separate use. See the `atc0005/go-ezproxy` project for further information on that module. Two separate binaries were created during testing: - mock `ezproxy` binary which returns known return codes and results + some extra to help condition validation checks for what I believe will be unknown/unpublished return codes I've yet to encounter - `es` binary used to search for and optionally terminate active user sessions for a specified username. This binary supports the same search retry and delay settings as `brick` refs GH-31, GH-59
BACKSTORY Not long after giving a demo on using brick + fail2ban to timeout existing sessions, I stumbled across another project on GitHub which uses `ezproxy kill` to terminate an active user session: - https://github.com/calvinm/ezproxy-abuse-checker/blob/d7202e617305745cf272df9918b1e95ff030f63f/block_user.pl#L32 - https://github.com/calvinm/ezproxy-abuse-checker/blob/master/block_user.pl Despite OCLC Support indicating otherwise, native support for terminating user sessions was clearly available. This built-in support offers a much safer/localized effect vs banning the IP associated with a reported account; banning the IP has the potential to have a much larger splash radius blocking legitimate user accounts. The primary developer for the `calvinm/ezproxy-abuse-checker` project confirmed that they learned of this support on the EZProxy mailing list: calvinm/ezproxy-abuse-checker#1 This is encouraging, as I am (at least a little) optimistic that this unpublished support will persist in future versions, at least until official, fully documented and supported functionality for terminating sessions is included. IMPLEMENTATION This commit adds (optional) support for terminating user sessions using the official EZProxy binary already present on EZproxy servers. The fully-qualified location of this binary is configurable via command-line flag, environment variable or TOML-format configuration file. Additional settings are provided to tune the sessions search process such as configurable retries and search delay. The session termination process involves reading current sessions from the Active Users and Hosts "state" file that EZproxy uses to track sessions and hosts managed by EZProxy and then using the EZproxy binary to terminate each session via the `kill` subcommand. As part of the early development efforts I initially tried to use the latest Audit logs to pull session IDs, but quickly realized that while the format was easier to parse, it was far less stable due to log rotation and the need to resolve the active state ourselves (logins minus logouts, minus timeouts, etc). Some of that support still remains as of this commit, but may be removed in a future release if found to not be needed. As of this writing I believe it can still be used as part of interacting with a future endpoint. The aforementioned search delay and retry settings are provided to work around an observed race condition between EZproxy recording state changes and other applications (such as ours) attempting to read the current state. The delay in EZproxy writing the changes to disk (or kernel settings?) may result in our application attempting to terminate sessions related to a monitoring system report and not finding them within the Active Users and Hosts "state" file. The defaults attempt to strike a balance between waiting a little longer in order to "find" and terminate those sessions vs moving on with current findings. The defaults may need to be adjusted further depending on the production environment. TEAMS NOTIFICATIONS Minor changes in an effort to better clarify the purpose of the lead-in content: - explicit `step X of Y` labeling to notification titles - consistent use of Note (preferred) and Error (fallback) field values to generate primary "summary" text - rename "Request Annotations" to "Request Errors" to reflect dedicated single purpose vs blend of Note and Error field values as before ADDITIONAL SUPPORT During development, the necessary code to interact with EZProxy was first created as a local package, but was eventually moved to a separate module in order to break out the changes for separate use. See the `atc0005/go-ezproxy` project for further information on that module. Two separate binaries were created during testing: - mock `ezproxy` binary which returns known return codes and results + some extra to help condition validation checks for what I believe will be unknown/unpublished return codes I've yet to encounter - `es` binary used to search for and optionally terminate active user sessions for a specified username. This binary supports the same search retry and delay settings as `brick` refs GH-31, GH-59
BACKSTORY Not long after giving a demo on using brick + fail2ban to timeout existing sessions, I stumbled across another project on GitHub which uses `ezproxy kill` to terminate an active user session: - https://github.com/calvinm/ezproxy-abuse-checker/blob/d7202e617305745cf272df9918b1e95ff030f63f/block_user.pl#L32 - https://github.com/calvinm/ezproxy-abuse-checker/blob/master/block_user.pl Despite OCLC Support indicating otherwise, native support for terminating user sessions was clearly available. This built-in support offers a much safer/localized effect vs banning the IP associated with a reported account; banning the IP has the potential to have a much larger splash radius blocking legitimate user accounts. The primary developer for the `calvinm/ezproxy-abuse-checker` project confirmed that they learned of this support on the EZProxy mailing list: calvinm/ezproxy-abuse-checker#1 This is encouraging, as I am (at least a little) optimistic that this unpublished support will persist in future versions, at least until official, fully documented and supported functionality for terminating sessions is included. IMPLEMENTATION This commit adds (optional) support for terminating user sessions using the official EZProxy binary already present on EZproxy servers. The fully-qualified location of this binary is configurable via command-line flag, environment variable or TOML-format configuration file. Additional settings are provided to tune the sessions search process such as configurable retries and search delay. The session termination process involves reading current sessions from the Active Users and Hosts "state" file that EZproxy uses to track sessions and hosts managed by EZProxy and then using the EZproxy binary to terminate each session via the `kill` subcommand. As part of the early development efforts I initially tried to use the latest Audit logs to pull session IDs, but quickly realized that while the format was easier to parse, it was far less stable due to log rotation and the need to resolve the active state ourselves (logins minus logouts, minus timeouts, etc). Some of that support still remains as of this commit, but may be removed in a future release if found to not be needed. As of this writing I believe it can still be used as part of interacting with a future endpoint. The aforementioned search delay and retry settings are provided to work around an observed race condition between EZproxy recording state changes and other applications (such as ours) attempting to read the current state. The delay in EZproxy writing the changes to disk (or kernel settings?) may result in our application attempting to terminate sessions related to a monitoring system report and not finding them within the Active Users and Hosts "state" file. The defaults attempt to strike a balance between waiting a little longer in order to "find" and terminate those sessions vs moving on with current findings. The defaults may need to be adjusted further depending on the production environment. TEAMS NOTIFICATIONS Minor changes in an effort to better clarify the purpose of the lead-in content: - explicit `step X of Y` labeling to notification titles - consistent use of Note (preferred) and Error (fallback) field values to generate primary "summary" text - rename "Request Annotations" to "Request Errors" to reflect dedicated single purpose vs blend of Note and Error field values as before ADDITIONAL SUPPORT During development, the necessary code to interact with EZProxy was first created as a local package, but was eventually moved to a separate module in order to break out the changes for separate use. See the `atc0005/go-ezproxy` project for further information on that module. Two separate binaries were created during testing: - mock `ezproxy` binary which returns known return codes and results + some extra to help condition validation checks for what I believe will be unknown/unpublished return codes I've yet to encounter - `es` binary used to search for and optionally terminate active user sessions for a specified username. This binary supports the same search retry and delay settings as `brick` refs GH-31, GH-59
BACKSTORY Not long after giving a demo on using brick + fail2ban to timeout existing sessions, I stumbled across another project on GitHub which uses `ezproxy kill` to terminate an active user session: - https://github.com/calvinm/ezproxy-abuse-checker/blob/d7202e617305745cf272df9918b1e95ff030f63f/block_user.pl#L32 - https://github.com/calvinm/ezproxy-abuse-checker/blob/master/block_user.pl Despite OCLC Support indicating otherwise, native support for terminating user sessions was clearly available. This built-in support offers a much safer/localized effect vs banning the IP associated with a reported account; banning the IP has the potential to have a much larger splash radius blocking legitimate user accounts. The primary developer for the `calvinm/ezproxy-abuse-checker` project confirmed that they learned of this support on the EZProxy mailing list: calvinm/ezproxy-abuse-checker#1 This is encouraging, as I am (at least a little) optimistic that this unpublished support will persist in future versions, at least until official, fully documented and supported functionality for terminating sessions is included. IMPLEMENTATION This commit adds (optional) support for terminating user sessions using the official EZProxy binary already present on EZproxy servers. The fully-qualified location of this binary is configurable via command-line flag, environment variable or TOML-format configuration file. Additional settings are provided to tune the sessions search process such as configurable retries and search delay. The session termination process involves reading current sessions from the Active Users and Hosts "state" file that EZproxy uses to track sessions and hosts managed by EZProxy and then using the EZproxy binary to terminate each session via the `kill` subcommand. As part of the early development efforts I initially tried to use the latest Audit logs to pull session IDs, but quickly realized that while the format was easier to parse, it was far less stable due to log rotation and the need to resolve the active state ourselves (logins minus logouts, minus timeouts, etc). Some of that support still remains as of this commit, but may be removed in a future release if found to not be needed. As of this writing I believe it can still be used as part of interacting with a future endpoint. The aforementioned search delay and retry settings are provided to work around an observed race condition between EZproxy recording state changes and other applications (such as ours) attempting to read the current state. The delay in EZproxy writing the changes to disk (or kernel settings?) may result in our application attempting to terminate sessions related to a monitoring system report and not finding them within the Active Users and Hosts "state" file. The defaults attempt to strike a balance between waiting a little longer in order to "find" and terminate those sessions vs moving on with current findings. The defaults may need to be adjusted further depending on the production environment. TEAMS NOTIFICATIONS Minor changes in an effort to better clarify the purpose of the lead-in content: - explicit `step X of Y` labeling to notification titles - consistent use of Note (preferred) and Error (fallback) field values to generate primary "summary" text - rename "Request Annotations" to "Request Errors" to reflect dedicated single purpose vs blend of Note and Error field values as before ADDITIONAL SUPPORT During development, the necessary code to interact with EZProxy was first created as a local package, but was eventually moved to a separate module in order to break out the changes for separate use. See the `atc0005/go-ezproxy` project for further information on that module. Two separate binaries were created during testing: - mock `ezproxy` binary which returns known return codes and results + some extra to help condition validation checks for what I believe will be unknown/unpublished return codes I've yet to encounter - `es` binary used to search for and optionally terminate active user sessions for a specified username. This binary supports the same search retry and delay settings as `brick` refs GH-31, GH-59
BACKSTORY Not long after giving a demo on using brick + fail2ban to timeout existing sessions, I stumbled across another project on GitHub which uses `ezproxy kill` to terminate an active user session: - https://github.com/calvinm/ezproxy-abuse-checker/blob/d7202e617305745cf272df9918b1e95ff030f63f/block_user.pl#L32 - https://github.com/calvinm/ezproxy-abuse-checker/blob/master/block_user.pl Despite OCLC Support indicating otherwise, native support for terminating user sessions was clearly available. This built-in support offers a much safer/localized effect vs banning the IP associated with a reported account; banning the IP has the potential to have a much larger splash radius blocking legitimate user accounts. The primary developer for the `calvinm/ezproxy-abuse-checker` project confirmed that they learned of this support on the EZProxy mailing list: calvinm/ezproxy-abuse-checker#1 This is encouraging, as I am (at least a little) optimistic that this unpublished support will persist in future versions, at least until official, fully documented and supported functionality for terminating sessions is included. IMPLEMENTATION This commit adds (optional) support for terminating user sessions using the official EZProxy binary already present on EZproxy servers. The fully-qualified location of this binary is configurable via command-line flag, environment variable or TOML-format configuration file. Additional settings are provided to tune the sessions search process such as configurable retries and search delay. The session termination process involves reading current sessions from the Active Users and Hosts "state" file that EZproxy uses to track sessions and hosts managed by EZProxy and then using the EZproxy binary to terminate each session via the `kill` subcommand. As part of the early development efforts I initially tried to use the latest Audit logs to pull session IDs, but quickly realized that while the format was easier to parse, it was far less stable due to log rotation and the need to resolve the active state ourselves (logins minus logouts, minus timeouts, etc). Some of that support still remains as of this commit, but may be removed in a future release if found to not be needed. As of this writing I believe it can still be used as part of interacting with a future endpoint. The aforementioned search delay and retry settings are provided to work around an observed race condition between EZproxy recording state changes and other applications (such as ours) attempting to read the current state. The delay in EZproxy writing the changes to disk (or kernel settings?) may result in our application attempting to terminate sessions related to a monitoring system report and not finding them within the Active Users and Hosts "state" file. The defaults attempt to strike a balance between waiting a little longer in order to "find" and terminate those sessions vs moving on with current findings. The defaults may need to be adjusted further depending on the production environment. TEAMS NOTIFICATIONS Minor changes in an effort to better clarify the purpose of the lead-in content: - explicit `step X of Y` labeling to notification titles - consistent use of Note (preferred) and Error (fallback) field values to generate primary "summary" text - rename "Request Annotations" to "Request Errors" to reflect dedicated single purpose vs blend of Note and Error field values as before ADDITIONAL SUPPORT During development, the necessary code to interact with EZProxy was first created as a local package, but was eventually moved to a separate module in order to break out the changes for separate use. See the `atc0005/go-ezproxy` project for further information on that module. Two separate binaries were created during testing: - mock `ezproxy` binary which returns known return codes and results + some extra to help condition validation checks for what I believe will be unknown/unpublished return codes I've yet to encounter - `es` binary used to search for and optionally terminate active user sessions for a specified username. This binary supports the same search retry and delay settings as `brick` refs GH-31, GH-59
BACKSTORY Not long after giving a demo on using brick + fail2ban to timeout existing sessions, I stumbled across another project on GitHub which uses `ezproxy kill` to terminate an active user session: - https://github.com/calvinm/ezproxy-abuse-checker/blob/d7202e617305745cf272df9918b1e95ff030f63f/block_user.pl#L32 - https://github.com/calvinm/ezproxy-abuse-checker/blob/master/block_user.pl Despite OCLC Support indicating otherwise, native support for terminating user sessions was clearly available. This built-in support offers a much safer/localized effect vs banning the IP associated with a reported account; banning the IP has the potential to have a much larger splash radius blocking legitimate user accounts. The primary developer for the `calvinm/ezproxy-abuse-checker` project confirmed that they learned of this support on the EZProxy mailing list: calvinm/ezproxy-abuse-checker#1 This is encouraging, as I am (at least a little) optimistic that this unpublished support will persist in future versions, at least until official, fully documented and supported functionality for terminating sessions is included. IMPLEMENTATION This commit adds (optional) support for terminating user sessions using the official EZProxy binary already present on EZproxy servers. The fully-qualified location of this binary is configurable via command-line flag, environment variable or TOML-format configuration file. Additional settings are provided to tune the sessions search process such as configurable retries and search delay. The session termination process involves reading current sessions from the Active Users and Hosts "state" file that EZproxy uses to track sessions and hosts managed by EZProxy and then using the EZproxy binary to terminate each session via the `kill` subcommand. As part of the early development efforts I initially tried to use the latest Audit logs to pull session IDs, but quickly realized that while the format was easier to parse, it was far less stable due to log rotation and the need to resolve the active state ourselves (logins minus logouts, minus timeouts, etc). Some of that support still remains as of this commit, but may be removed in a future release if found to not be needed. As of this writing I believe it can still be used as part of interacting with a future endpoint. The aforementioned search delay and retry settings are provided to work around an observed race condition between EZproxy recording state changes and other applications (such as ours) attempting to read the current state. The delay in EZproxy writing the changes to disk (or kernel settings?) may result in our application attempting to terminate sessions related to a monitoring system report and not finding them within the Active Users and Hosts "state" file. The defaults attempt to strike a balance between waiting a little longer in order to "find" and terminate those sessions vs moving on with current findings. The defaults may need to be adjusted further depending on the production environment. TEAMS NOTIFICATIONS Minor changes in an effort to better clarify the purpose of the lead-in content: - explicit `step X of Y` labeling to notification titles - consistent use of Note (preferred) and Error (fallback) field values to generate primary "summary" text - rename "Request Annotations" to "Request Errors" to reflect dedicated single purpose vs blend of Note and Error field values as before ADDITIONAL SUPPORT During development, the necessary code to interact with EZProxy was first created as a local package, but was eventually moved to a separate module in order to break out the changes for separate use. See the `atc0005/go-ezproxy` project for further information on that module. Two separate binaries were created during testing: - mock `ezproxy` binary which returns known return codes and results + some extra to help condition validation checks for what I believe will be unknown/unpublished return codes I've yet to encounter - `es` binary used to search for and optionally terminate active user sessions for a specified username. This binary supports the same search retry and delay settings as `brick` refs GH-31, GH-59
BACKSTORY Not long after giving a demo on using brick + fail2ban to timeout existing sessions, I stumbled across another project on GitHub which uses `ezproxy kill` to terminate an active user session: - https://github.com/calvinm/ezproxy-abuse-checker/blob/d7202e617305745cf272df9918b1e95ff030f63f/block_user.pl#L32 - https://github.com/calvinm/ezproxy-abuse-checker/blob/master/block_user.pl Despite OCLC Support indicating otherwise, native support for terminating user sessions was clearly available. This built-in support offers a much safer/localized effect vs banning the IP associated with a reported account; banning the IP has the potential to have a much larger splash radius blocking legitimate user accounts. The primary developer for the `calvinm/ezproxy-abuse-checker` project confirmed that they learned of this support on the EZProxy mailing list: calvinm/ezproxy-abuse-checker#1 This is encouraging, as I am (at least a little) optimistic that this unpublished support will persist in future versions, at least until official, fully documented and supported functionality for terminating sessions is included. IMPLEMENTATION This commit adds (optional) support for terminating user sessions using the official EZProxy binary already present on EZproxy servers. The fully-qualified location of this binary is configurable via command-line flag, environment variable or TOML-format configuration file. Additional settings are provided to tune the sessions search process such as configurable retries and search delay. The session termination process involves reading current sessions from the Active Users and Hosts "state" file that EZproxy uses to track sessions and hosts managed by EZProxy and then using the EZproxy binary to terminate each session via the `kill` subcommand. As part of the early development efforts I initially tried to use the latest Audit logs to pull session IDs, but quickly realized that while the format was easier to parse, it was far less stable due to log rotation and the need to resolve the active state ourselves (logins minus logouts, minus timeouts, etc). Some of that support still remains as of this commit, but may be removed in a future release if found to not be needed. As of this writing I believe it can still be used as part of interacting with a future endpoint. The aforementioned search delay and retry settings are provided to work around an observed race condition between EZproxy recording state changes and other applications (such as ours) attempting to read the current state. The delay in EZproxy writing the changes to disk (or kernel settings?) may result in our application attempting to terminate sessions related to a monitoring system report and not finding them within the Active Users and Hosts "state" file. The defaults attempt to strike a balance between waiting a little longer in order to "find" and terminate those sessions vs moving on with current findings. The defaults may need to be adjusted further depending on the production environment. TEAMS NOTIFICATIONS Minor changes in an effort to better clarify the purpose of the lead-in content: - explicit `step X of Y` labeling to notification titles - consistent use of Note (preferred) and Error (fallback) field values to generate primary "summary" text - rename "Request Annotations" to "Request Errors" to reflect dedicated single purpose vs blend of Note and Error field values as before ADDITIONAL SUPPORT During development, the necessary code to interact with EZProxy was first created as a local package, but was eventually moved to a separate module in order to break out the changes for separate use. See the `atc0005/go-ezproxy` project for further information on that module. Two separate binaries were created during testing: - mock `ezproxy` binary which returns known return codes and results + some extra to help condition validation checks for what I believe will be unknown/unpublished return codes I've yet to encounter - `es` binary used to search for and optionally terminate active user sessions for a specified username. This binary supports the same search retry and delay settings as `brick` refs GH-31, GH-59
While working on the initial v0.1.0 support for terminating user sessions (which relies upon
fail2ban
for terminating active sessions), I stumbled across a GitHub project that uses a set of Perl scripts and a crontab entry to parse EZproxy logs and take a set of actions.Those actions include (there could be others, I didn't dig too deep):
The
block_user.pl
script has this block:As noted in greater detail in comment #13 (comment), the subcommand still exists and works in our test environment:
If this subcommand isn't deprecated, using it could simplify the requirements for this project considerably and make it much safer to operate.
References:
The text was updated successfully, but these errors were encountered: