Identify 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 documentation describes the steps that must be taken, both proactively and after

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

Identify 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 http://sciencedb.com/pdfviewer/pfgviewerid=123456...
    2. Time stamped unique files: GET /doi/12.3456/id.123456...
  2. Open your ezp log 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 ezpyyymm 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 month when the breach occurred, according to the content provider's details.
  4. Do a search within the log file for the URL or the doi (unique resource) that was accessed illicitly, provided by the publisher. You should find a line that looks like this: 132.174.45.678 – abc34XYrsg12FGH [16/Apr/2015:10:47:18 -0500] "GET http://www.sciencedb.com:80/pdfviewer/pdfviewer?id=1ab1234c-5def-6gh7-8ij9-k101112131415l%50session789&id=5@&id=456 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 http://ezproxy.abclib.org:2048/admin (substituting your server URL and port number for http://ezproxy.abclib.org:2048).

  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.
     

    Date/time Event IP Locatie UsernamE Session Other
    10:14:50 System         Startup
    10:15:13 Login.Failure 132.174.45.678 OH baduser    
    10:15:20 Login.Success 132.174.45.678 OH baduser abc3XYrsg12FGH

     
  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.