OSSEC / HIDS Rule 5702

OSSEC / HIDS rule catalog

• Rule family: OSSEC / HIDS
• Rule ID: 5702
• Definition status: Present in current source
• Alert message / subject: Reverse lookup error (bad ISP or attack).
• Rule level: 5
• Definition checked: 2026-10-21

Interpretation and response

This event is recorded as “Reverse lookup error (bad ISP or attack).” Review the originating log and the affected host or service to determine whether the activity was expected.

An OSSEC/HIDS event records or correlates activity. Blocking depends on the originating application and any separately configured Active Response policy; an alert alone does not prove that an attack was blocked.

Documentation

The following guidance was migrated from the historical wiki and reviewed against the rule definition. Legacy ASL product names and interface instructions refer to the versions documented then. Use the current metadata above and your installed configuration when interpreting thresholds, notification settings and response behavior.

Rule ID

5702

Status

The wiki marked this rule Active at the source revision. Current definition status is shown above.

Description

Note: This rule does not block anything. It merely reports.

This rule reports when sshd performs the reverse lookup of an IP address and sshd reports that the reverse lookups mapping has failed.

A reverse lookup error occurs when sshd attempts to determine what the fully qualified domain name (FQDN) is for an IP address. It then looks up the fully qualified name to see that name matches the IP address returned for the reverse lookup. If they do not match, this is a reverse mapping error. This may indicate that someone is spoofing the fully qualified domain name to try to trick your system into allowing them to log in.

For example:

Illustrative event summary (not a captured log): OSSEC/HIDS 5702 — Reverse lookup error (bad ISP or attack)..

A system has connected to your ssh server, in this case lets say the systems IP address is 1.2.3.4. The sshd service then performs what is called a “reverse lookup” on the IP address, to determine what the fully qualified domain name is for 1.2.3.4. The DNS server, in this example, claims that the FQDN for 192.0.2.10 is “www.example.com (opens in a new tab) ”. Because anyone can return any FQDN they want from their DNS server (even a fake one.), this method alone is not an accurate way of determining if the answer is correct. To verify the answer, the process now needs to be reversed. So in this example, sshd then conducts a DNS query to ask the authoritative DNS server for www.example.com (opens in a new tab) what the IP address is for www.example.com (opens in a new tab) . If that DNS server returns an address that is different from 192.0.2.10, say 192.0.2.11, then the reverse mapping has failed. The IP address for www.example.com (opens in a new tab) is 192.0.2.11, not 1.2.3.4. So 192.0.2.10 is not www.example.com (opens in a new tab) . This could mean that someone is to spoof the www.example.com (opens in a new tab) DNS address.

This could also occur if someone made a mistake with their DNS names, or what sometimes occurs is that the two records are sometimes not kept up to date. If you believe that is the case, contact the DNS operators for both the domain name and IP address.

ASL does not cause this occur. It merely reports when it occurs. Disabling this rule will not prevent sshd from generating this error.

Log Examples

Illustrative event summary (not a captured log): OSSEC/HIDS 5702 — Reverse lookup error (bad ISP or attack)..

False Positives

A legitimate event may still trigger this rule. Review the surrounding activity before deciding whether it is malicious. This rule simply reports when sshd reports that this has occurred. If sshd is in error, please contact your OS (or sshd) vendor for assistance. If the DNS servers are in error, please contact your DNS operators or vendor. And if the DNS software is incorrectly reporting this information to your application, please contact your DNS vendor.

Tuning Recommendations

None.

Similar Rules

= Knowledge Base Articles = None.

Outside References

= Notes = ASL has no control over the message generated by sshd. This message generated by sshd is neither generated by ASL, nor is this something ASL can control. ASL is just listening to what you application is “saying”, analyzing the “message” and then reporting its significance to you you based on its internal understanding of those messages, and other events that may (or may not) be occurring on the system.

Source and revision

Migrated from HIDS_5702, wiki page 647, revision 5608 (20151216). Documentation review: 2026-10-21. An archived wiki status of Active is not a current deployment status.

For assistance, provide the rule ID, installed product and rule version, and a sanitized event to Atomicorp support .