Skip to main content
OCLC Support


Learn how to use the IntrusionAPI config.txt directive to provide the option to audit or block access from pirate or hacker IP addresses in EZproxy.

IntrusionAPI provides the option to audit or block access from known pirate/hacker IP addresses.

The API call can be enabled to enhance IntruderIP by providing evasion during login attempts or with RejectIP to block access from matching addresses.

The Intrusion API is only consulted for public address that do not fall within a WhitelistIP range (see later). Private addresses (10.*, 172.16-31.*, 192.168.*) are never checked against the intrusion API.

When Evade is specified and the user accesses from a public, non-whitelisted address, the intrusion API will be consulted when a user presents a credential for authentication. If the IP is specified as BadIP (see audit event type below) and -enforce is present, the user will be told that their login failed without ever checking the credential provided.

When Reject is specified and the user accesses from a public, non-whitelisted address, the intrusion API will be consulted no matter how the user is accessing. If the IP is specified as BadIP and -enforce is present, the connection is either blocked, or if reject.htm exists, that file is sent to the user.

IntrusionAPI is not position-dependent.

IntrusionAPI frequently asked questions

Question Answer
Are the new Audit events included under Audit Most? Yes, with the exception of IntrusionAPI.None.
If you use the Reject option, how long is that IP blocked? The Intrusion API provides an expiration time, which EZproxy obeys; this defaults to an hour. Restarting EZproxy immediately clears that cache. The audit entries indicate the cache period in the "Other" column.
If you use the Evade option, does that invoke the IntruderIPAttempts settings? It gives the end user the same behavior as IntruderIPAttempts, but it will not show up on the intruder page. The Audit entries should be consulted to review this behavior
Can you use both the Evade and Reject options? Yes, however, the only time this might be useful would be if you don't use -enforce for either. It will turn on the option for both, which would then give Reject priority as it would stop a user before that user could present a credential.
Will the Evade option work with Shibboleth/CAS/CGI/ticket authentication or other methods where EZproxy doesn't handle the credentials directly? No.
Is there any position dependency with IntrusionAPI? No.
Can IntrusionAPI be tested using the test user.txt screen in the Admin module? No.
Is any additional data, other than the IP address sent to the 3rd party company? No.
Does the 3rd party store the IP addresses sent via the API call? No.

IntrusionAPI audit log entries

When the IntrusionAPI is consulted, an audit event is recorded with the outcome. The new audit events are:

Audit event Description
IntrusionAPI.BadIP Intrusion API indicates the address is associated with a known pirate/hacker


An error occurred consulting the intrusion API (more information recorded in Other field); includes scenario in which SSL connection fails validation


Intrusion API responded that address is not in database (this event is not enabled by AuditMost and must be added explicitly such as Audit Most IntrusionAPI.None)
IntrusionAPI.Whitelisted Intrusion API responded that the address is whitelisted in their system (this event is not recorded if the address falls within a WhitelistIP range)
IntrusionAPI -enforce Evade|Reject
IntrusionAPI -enforce Reject
Related directives
Audit, IntruderLog, IntruderIPAttempts, RejectIP, WhitelistIP


  • Was this article helpful?