[Snort-sigs] snort rule documentation (#492)

dank at ...1581... dank at ...1581...
Mon Jun 9 06:39:14 EDT 2003


this may show up again later today, as i originally sent it in before
subscribing to the list.  sorry if so!

-------------------------------------------------
Rule:  
alert tcp $HOME_NET 23 -> $EXTERNAL_NET any (msg:"INFO TELNET Bad
Login"; content: "Login failed"; nocase; flow:from_server,established;
classtype:bad-unknown; sid:492; rev:6;)
--
Sid:
492
--
Summary:
A telnet server refused an attempted login.
--
Impact:
An attacker may have attempted to gain access to a valid user's account via
the telnet service, but did not succeed.  The telnet service is running,
which uses insecure authentication mechanisms.
--
Detailed Information:
The telnet server typically runs on TCP port 23.  Upon access to the
server, account access is granted based on an unencrypted user name and
password.  Upon a failed login (resulting from either an invalid account
or an incorrect password), a login failure message will be returned.
This signature matches the common text "Login failed".
--
Affected Systems:
Any system running a telnet server.
--
Attack Scenarios:
Attackers can, particularly when armed with a valid account name,
attempt to use guessing attacks or brute-force means to gain access via
the telnet service.  Many successive events of this type would likely be
indicative of such an attack.

The use of a telnet server allows the passive attack of traffic
sniffing, which can extract a username and password from any valid
login.
--
Ease of Attack:
This event indicates it is possible to perform a brute-force attack; the
ease of such an attack is dependent upon the strength of passwords, and
rate-limiting techniques employed by the telnet server in question.
--
False Positives:
This event will match any badly-typed or -remembered password, and will
therefore likely false positive fairly often.  Look for rapid successive
events.
--
False Negatives:
If a password is correctly guessed, no failure will be noted.
--
Corrective Action:
It is best to avoid using telnet whenever possible; its authentication
system is lacking, and encryption is generally unavailable.  If your
telnet server can be configured to temporarily disable access after
rapid successive failures, it as advised that you do so.
--
Contributors:
Original rule author unknown
Documented by Nick Black, Reflex Security <dank at ...1582...>
-- 
Additional References:
Telnet RFC:  http://www.faqs.org/rfcs/rfc854.html
-------------------------------------------------




-- 
nick black <dank at ...1582...>
"np:  nondeterministic polynomial-time
the class of dashed hopes and idle dreams." - the complexity zoo




More information about the Snort-sigs mailing list