On this page
OSSEC / HIDS Rule 3359
- Rule family: OSSEC / HIDS
- Rule ID: 3359
- Definition status: Present in current source
- Alert message / subject: Multiple SASL authentication failures.
- Rule level: 10
- Definition checked: 2026-10-21
- Configured frequency: 6
- Timeframe (seconds): 120
- Ignore interval (seconds): 60
Correlation values are configuration attributes; event-count behavior depends on the manager version and parent rules.
Interpretation and response
This event is recorded as “Multiple SASL authentication failures.” 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.
Description
Simple Authentication and Security Layer (SASL) is a framework for authentication and data security in Internet protocols, such as pop3, imap, postfix, courier, other smtp servers and even web services. Its most commonly used for mail services.
This alert means that a system or user has failed to authenticate to a service that uses SASL multiple times. This can be an indication that someone is trying to brute force attack an account, or it could mean a client has an incorrect password and/or username and keeps trying and failing to authenticate multiple times.
Log example
Illustrative event summary (not a captured log): OSSEC/HIDS 3359 — Multiple SASL authentication failures..
Troubleshooting
False Positives
The rule itself can not generate a false positive, the rule just reports when multiple login failures happen from a single IP. If this event is not an attack, then this means the enduser has an invalid username and/or password configured for the service. The best solution to this problem is to have the user fix their username/password so its valid.
Tuning Guidance
We do not recommend you disable this rule. You could whitelist the IP, but the best solution is to fix the invalid username/password for the user.
If you do not wish to shun on this rule, just change the Rules configuration for Active Response to “no”. We do not recommend you disable active response on this rule, as this method is widely used to probe ssh servers.
Additional Information
Similar Rules
Source and revision
Migrated from HIDS_3359, wiki page 483, revision 5111 (20140924). 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 .