Manage EZproxy

  • Identifying Compromised Credentials

Identifying Compromised Credentials

There are instances when a content provider contacts an EZproxy institution with details about a potential security breach. Normally, this is caused by credentials that have been stolen or compromised. These breaches often require action on the part of the institution to ensure continued access to the resource. If no action is taken, access to that resource can be suspended until the breach has been addressed. This page describes the steps that must be taken, both proactively and after a breach occurs, to make it possible to neutralize the offending account.

Log Configuration

When you receive a notification of a potential breach, it is important that you have the information necessary to deal with that breach. The default configuration in the Standalone EZproxy config.txt file will provide you with basic logging, but to create more robust logs to help in dealing with security breaches, see Securing Your EZproxy Server. The Overview tab provides details about the security-related aspects of logs, and the Example provides a sample configuration that would be helpful in security breach scenarios.

It is important to implement these configuration settings before a breach occurs so that you have the information necessary to address any content provider's security concerns. The following instructions assume that the minimum log configuration in the Security document above have been implemented. If you have not customized your log configuration using this example or a more specialized configuration, OCLC suggests that you do so as soon as possible. Even if you have not, you may still be able to complete many of the steps listed as the default EZproxy config.txt file contains a basic log configuration.

Identifying Compromised Credentials

The following instructions will take you through the steps necessary to address content providers' security concerns.

  1. Collect information from the content provider with details connected to the alleged breach. EZproxy logs are too big to just start looking around. Specifically, identify:
    1. The time-stamped URL that the publisher suspects has been accessed illicitly, for example “GET”
    2. Time stamped unique files: “GET /doi/12.3456/id.123456…”

  2. Open your ezplog folder. By default, Standalone EZproxy is configured to maintain monthly log files and store them in the EZproxy installation directory. However, these files can be stored anywhere as designated with the LogFile directive. If you do not see ezpyyyymm files in your EZproxy installation directory, you can look in your config.txt file for this directive to determine where these logs are being stored.

  3. Open the ezp log file from the date or the month when the breach occurred according to the content provider’s details.

  4. Do a search within the log for the URL or the doi (unique resource) that was accessed illicitly, provided by the publisher. You should find a line that looks as follows: – abc34XYrsg12FGH [16/Apr/2015:10:47:18 -0500] "GET HTTP/1.1" 200 43575
    Confirm that the URL or doi (highlighted in green, always following GET) and date (highlighted in cyan) correspond with the information provided by the publisher. If you find a match, identify the session id/user (highlighted in yellow) that accessed that resource.

    Note: The information in this line is the default configuration for LogFormat; the information in your ezp log file may vary depending upon your LogFormat configuration.

  5. Log in to your EZproxy admin page at (substituting your server URL and port number for

  6. Click on the hyperlink View audit events under the Current Activity heading.

  7. On the View Audit Events page, click on the hyperlinked date that corresponds with the date on which the resource was accessed illicitly, as identified in step 4. You will be taken to the Audit Events for yyyy-mm-dd screen.

  8. On the Audit Events screen, you will see a table with information recorded based on your Audit directive. Search for a session that contains the session ID that accessed the resource, identified in step 4. Identify the username associated with that session.



























  9. Repeat steps 1-9 for all URLs/doi’s identified by the publisher as potential breaches. If there are too many individual examples to investigate them all, select a representative sample over the period of time in question and search for them. As you search, note whether the same username is being used in all illicit sessions. If this is the case, you likely have an account with compromised credentials.

  10. If you find the same username associated with repeated illicit sessions or downloads, search for the username in View Audit Events screen, and see if that user has any current, active sessions. If there are any current active sessions, you need to terminate those sessions.

  11. Click on Administration in the top right corner of the View Audit Events screen to return to the EZproxy Administration page.

  12. Click View server status under Current Activity.

  13. On the Server Status page, look at the Sessions table at the top of the screen. If the username in question has a currently active session, you will see it here. If the list is long, a ctrl F to search for the username. If you see the username click on the current Session id.

  14. A Session Status page will open with details about that session. Below the session table, click Terminate session to end that user’s access.

  15. After you have confirmed that the user’s current sessions have been terminated, contact your IT department and tell them that you have a potentially compromised account. Give them the username and ask that the password be reset and any other security protocol be enacted to stop this username from being used to access institutional resources. If you are unable to get an immediate response from your IT department, see the Restricting Usernames tab above.

  16. Once you have dealt with the compromised account internally, contact the content provider to alert them that the credentials used for the breach in question have been revoked or reset. If access to this resource has been cut off, access can now be restored.


To restrict access to resources with a particular username, OCLC suggests that the password associated with that username be reset in the authentication system. If you do not have access to that system to make immediate changes, you can put a temporary restriction in place until that change can be made at the system level.

Below are examples for some common authentication methods to deny individual users EZproxy access. In each example, replace baduser with the username you wish to block from EZproxy. For additional information about the Deny directive, please see Common Conditions and Actions.

Normal Authentication Methods

For most authentication methods that are not CAS, Shibboleth, or CGI, the following configuration should work to deny a user access to EZproxy.

Enter the following line as the FIRST line of the user.txt file. This line must appear before any lines that would allow the specified usernames to authenticate because EZproxy begins reading the user.txt file from the top. If the first line containing the given username is an authenticate statement, the user will be authenticated and EZproxy will stop reading user.txt. If the first line containing the username is a Deny statement, the user will be denied access.



IfUser baduser; Deny


The exact line and value that must be entered to block a Shibboleth user will vary from IdP to IdP, but the following line should provide a template for most instances. The attribute to test in this configuration will vary.

If auth:uid eq "baduser"; Deny

This page last revised: September 21, 2015