Skip to content
This repository has been archived by the owner on Feb 15, 2024. It is now read-only.

Research using "ezproxy kill" subcommand in place of fail2ban for terminating active sessions #31

Closed
atc0005 opened this issue May 24, 2020 · 9 comments · Fixed by #73
Closed
Assignees
Labels
enhancement New feature or request session user
Milestone

Comments

@atc0005
Copy link
Owner

atc0005 commented May 24, 2020

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):

  • disable user account
  • terminate action sessions for disabled user account

The block_user.pl script has this block:

if ($block_session) {
	system("/opt/ezproxy/ezproxy kill $block_session");
}

As noted in greater detail in comment #13 (comment), the subcommand still exists and works in our test environment:

$ sudo ./ezproxy kill
Session must be specified

$ sudo  grep -E '^S ' ezproxy.hst
S SESSION_ID_HERE REDACTED

$ sudo ./ezproxy kill SESSION_ID_HERE
Session SESSION_ID_HERE terminated

If this subcommand isn't deprecated, using it could simplify the requirements for this project considerably and make it much safer to operate.

References:

@atc0005 atc0005 added enhancement New feature or request user session labels May 24, 2020
@atc0005 atc0005 added this to the Future milestone May 24, 2020
@atc0005 atc0005 pinned this issue May 24, 2020
@atc0005 atc0005 self-assigned this May 24, 2020
@atc0005
Copy link
Owner Author

atc0005 commented May 28, 2020

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 ezproxy.hst file is not held open by ezproxy, so presumably we could modify the file in-place to remove sessions ourselves if OCLC removes support for the kill subcommand.

@atc0005
Copy link
Owner Author

atc0005 commented May 28, 2020

Next steps:

  • keep working on support for terminating sessions
  • build a mock executable that randomly returns known response codes and text
    • skip actually modifying the ezproxy.hst file (for now anyway)

This should hopefully allow better testing of brick once the session termination support is fleshed out.

@atc0005
Copy link
Owner Author

atc0005 commented May 28, 2020

Now have a mock binary that returns random response codes. It's not pretty, but it works.

  • es binary that allows for listing and (using a real ezproxy binary) terminates sessions
  • ezproxy binary that mocks known return codes/text and returns some other "random" results
    • undoubtedly there will be unexpected responses from the real ezproxy binary at some point, so stubbing in some fake entries now seems like a useful preparation step

@atc0005
Copy link
Owner Author

atc0005 commented May 28, 2020

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 ezproxy.hst file.

Thoughts:

  • Add a brief delay before searching the file?
    • doesn't seem to scale well
  • Add a retry (or two) with a delay after the first attempt comes back with 0 sessions
    • assume the user just didn't mistype the username
    • note that a retry is underway
    • offer a flag that cancels retries

@atc0005
Copy link
Owner Author

atc0005 commented Jun 10, 2020

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.

@atc0005
Copy link
Owner Author

atc0005 commented Jun 10, 2020

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 ezproxy.hst file.

Thoughts:

  • Add a brief delay before searching the file?

    • doesn't seem to scale well
  • Add a retry (or two) with a delay after the first attempt comes back with 0 sessions

    • assume the user just didn't mistype the username
    • note that a retry is underway
    • offer a flag that cancels retries

This is supported via default values and applied MatchingUserSessions() method calls for both subpackages and the MatchingSessionEntries method call for the auditlog package, but configurable through the SetSearchRetries() and SetSearchDelay() methods on the SessionsReader interface. The default values are on the safe side, so should probably only need tuning if shorter values are needed.

@atc0005
Copy link
Owner Author

atc0005 commented Jun 10, 2020

Pinged the project lead where I discovered the ezproxy kill subcommand for their feedback.

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

@atc0005
Copy link
Owner Author

atc0005 commented Jun 18, 2020

Pinged the project lead where I discovered the ezproxy kill subcommand for their feedback.

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.

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.

@atc0005
Copy link
Owner Author

atc0005 commented Jun 18, 2020

Work continues on the feature branch and I am optimistic that this work will wrap up in the next week, potentially sooner.

@atc0005 atc0005 unpinned this issue Jun 24, 2020
@atc0005 atc0005 modified the milestones: Future, v0.2.0 Jun 27, 2020
atc0005 added a commit that referenced this issue Jun 30, 2020
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
atc0005 added a commit that referenced this issue Jun 30, 2020
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
atc0005 added a commit that referenced this issue Jun 30, 2020
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
atc0005 added a commit that referenced this issue Jun 30, 2020
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
atc0005 added a commit that referenced this issue Jun 30, 2020
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
atc0005 added a commit that referenced this issue Jun 30, 2020
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
atc0005 added a commit that referenced this issue Jun 30, 2020
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
atc0005 added a commit that referenced this issue Jun 30, 2020
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
atc0005 added a commit that referenced this issue Jun 30, 2020
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
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request session user
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant