next up previous contents index
Next: The portmapper Analyzer Up: Analyzers and Events Previous: The ident Analyzer   Contents   Index

Subsections


The login Analyzer

The login analyzer inspects interactive login sessions to extract username and password information, and monitors user keystrokes and the text returned by the login server. It is one of the most powerful Bro modules for detecting break-ins to Unix systems because of the ability to look for particular commands that attackers often execute once they have penetrated a Unix machine.

The analyzer is generic in the sense that it applies to more than one protocol. Currently, Bro instantiates a login analyzer for both Telnet [RFC854] and Rlogin [RFC1282] traffic. In principle, it could do the same for other protocols such as SSH [YKSRL00] or perhaps X11 [RFC1013], if one could write the corresponding elements of the event engine to decrypt the SSH session (naturally, this would require access to the encryption keys) or extract authentication information and keystrokes from the X11 event stream. Note: The analyzer does an exceedingly limited form of SSH analysis; see hot_ssh_orig_ports.

For Telnet, the event engine knows how to remove in-band Telnet option sequences [RFC855] from the text stream, and does not deliver these to the event handlers, except for a few options that the engine analyzes in detail (such as attempts to negotiate authentication). Unfortunately, the Telnet protocol does not include any explicit marking of username or password information (unlike the FTP protocol, as discussed in § ). Consequently, Bro employs a series of heuristics that attempt to extract the username and password from the authentication dialog the session is presumed to begin with. The analysis becomes quite complicated due to the possible use of type-ahead and editing sequences by the user, plus the possibility that the user may be an attacker who attempts to mislead the heuristics in order to disguise the username they are accessing.

Analyzing Rlogin is nominally easier than analyzing Telnet because Rlogin has a simpler in-band option scheme, and because the Rlogin protocol explicitly indicates the username in the initial connection dialog. However, this last is not actually a help to the analyzer, because for most Rlogin servers, if the initial username fails authentication (for example, is not present in the .rhosts file local to the server), then the server falls back on the same authentication dialog as with Telnet (prompting for username and then password, or perhaps just for a password to go with the transmitted username). Consequently, the event engine employs the same set of heuristics as for Telnet.

Each connection processed by the analyzer is in a distinct state: user attempting to authenticate, user has successfully authenticated, analyzer is skipping any further processing, or the analyzer is confused (§ ). You can find out the state of a given connection using get_login_state.

The analyzer uses a capture filter of ``tcp port 23 or tcp port 513'' (§ ). It annotates each connection with the username(s) present in the authentication dialog. If the username was authenticated successfully, then it encloses the annotation in quotes. If the authentication failed, then the name is marked as failed/<username>. So, for example, if user ``smith'' successfully authenticates, then the connection's addl field will have "smith" appended to it:

931803523.006848 254.377 telnet 324 8891 1.2.3.4 5.6.7.8 SF L "smith"
while if ``smith'' failed to authenticate, the report will look like:
931803523.006848 254.377 telnet 324 8891 1.2.3.4 5.6.7.8 SF L fail/smith
and if they first tried as ``smith'' and failed, and then succeeded as ``jones'', the record would look like:
931803523.006848 254.377 telnet 324 8891 1.2.3.4 5.6.7.8 SF L fail/smith "jones"

Note: The event engine's heuristics can sometimes get out of synch such that it interprets a password as a username; in addition, users sometimes type their password when they should instead enter their username. Consequently, the connection logs sometimes include passwords in the annotations, and so should be treated as very sensitive information (e.g., not readable by any user other than the one running Bro).


login analyzer confusion

Because there is no well-defined protocol for Telnet authentication (or Rlogin, if the initial .rhosts authentication fails), the login analyzer employs a set of heuristics to detect the username, password, and whether the authentication attempt succeeded. All in all, these heuristics work quite well, but it is possible for them to become confused and reach incorrect conclusions.


Table: Different types of confusion that login analyzer can report.
Type of confusion Meaning
"excessive_typeahead" The user has typed ahead 12 or more lines. Deficiency: The upper bound should be adjustable.
"extra_repeat_text" The user has entered more than one VMS repeat sequence (an escape followed by ``[A'') on the same line. Note: Bro determines that a login session involves a VMS server if the server prompts with ``"Username:"''. It then interprets VMS repeat sequences as indicating it should replace the current line with the previous line.
"multiple_USERs" The user has specified more than one username using the $USER environment variable.
"multiple_login_prompts" The analyzer has seen several login prompts on the same line, and has not seen a corresponding number of lines typed ahead previously by the user.
"no_login_prompt" The analyzer has seen 50 lines sent by the server without any of them matching login_prompts. Deficiency: The value of 50 should be adjustable.
"no_username" The analyzer is generating an event after having already seen a login failure, but the user's input has not provided another username to include with the event. Note: If the analyzer's heuristics indicate it's okay that no new username has been given, such as when the event is generated due to one connection endpoint closing the connection, then it instead uses the username <none> .
"no_username2" The analyzer saw an additional password prompt without seeing an intervening username, and it has no previous username to reuse.
"non_empty_multi_login" The analyzer saw multiple adjacent login prompts, with an apparently ignored intervening username typed-ahead between them.
"possible_login_ploy" The client sent text that matches one of the patterns reflecting text usually sent by the server. This form of confusion can reflect an attacker attempting to evade the monitor. For example, the client may have sent the text ``login:'' as a username so that when echoed back by the server, the analyzer would misinterpret it as reflecting another login prompt from the server.
"repeat_without_username" The user entered a VMS repeat sequence but there is no username to repeat. (See extra_repeat_text for a discussion of the analyzer's heuristics for dealing with VMS servers.)
"responder_environment" The responder (login server) has signaled a set of environment variables to the originator (login client). This is in the opposite direction as to what makes sense.
"username_with_embedded_repeat" The line repeated by a VMS server in response to a repeat sequence itself contains a repeat sequence.


Bro attempts to detect such confusion. If it does, then it generates a login_confused event, after which the event engine will no longer attempt to follow the authentication dialog. In particular, it will not generate subsequent login_failure or login_success events. The login_confused event includes a string describing the type of confusion, using one of the values given in Table [*].


login variables

The standard script defines a large number of variables for refining the analysis policy:

[input_trouble : pattern] lists patterns that the analyzer should flag if they appear in the user's input (keystroke) stream.

The analyzer searches for these patterns both in the raw text typed by the user and the same lines after applying editing using the edit function twice: once with interpreting BS (ctrl-H) as delete-one-character, and once with DEL as the edit character. If any of these matches, then the analyzer considers the pattern to have matched.

eggdrop Default: a pattern matching occurrences of the strings ``rewt'', ``eggdrop'', ``loadmodule'', or ``/bin/eject''. The first of these is a popular username attackers use for root backdoor accounts. The second reflects that one prevalent class of attackers are devotees of Internet Relay Chat (IRC), who frequently upon breaking into an account install the IRC eggdrop utility.

[edited_input_trouble : pattern] is the same as input_trouble except the analyzer only checks the edited user input against the pattern, not the raw input (see above).

This variable is provided so you can specify patterns that can occur innocuously as typos; whenever the user corrects the typo before terminating the line, the pattern won't match, because it won't be present in the edited version of the line. In addition, for matches to these patterns, the analyzer delays reporting the match until it sees the next line of output from the server. It then includes both the line that triggered the match and the corresponding response from the server, which makes it easy for a human inspecting the logs to tell if the occurrence of the pattern was in fact innocuous.

Here's an example of an innocuous report:

936723303.760483 1.2.3.4/21550 > 5.6.7.8/telnet
    input "cd ..." yielded output "ksh: ...:  not found."
It was flagged because the user's input included ``...'', a name commonly used by attackers to surreptitiously hide a directory containing their tools and the like. However, we see from the Telnet server's response that this was not actual access to such a directory, but merely a typing mistake.

On the other hand:

937528764.579039 1.2.3.4/3834 > 5.6.7.8/telnet
    input "cd ..." yielded output "maroon# ftp sunspot.sunspot.noao.edu "
shows a problem--the lines returned by the server was a root prompt (``maroon#''), to which the user issued a command to access a remote FTP server.

Deficiency: The analyzer should decouple the notion of waiting to receive the server's reply from the notion of matching only the edited form of the line; there might be raw inputs for which it is useful to see the server's response, and edited inputs for which the server's response is unimportant in terms of knowing that the input spells trouble.

Default: the pattern

    /[ \t]*cd[ \t]+((['"]?\.\.\.)|(["'](\.[^"']*)[ \t]))/
which looks for a ``cd'' command to either a directory beginning with ``...'' (optionally quoted by the user) or a directory name beginning with ``.'' that is quoted and includes an embedded blank or tab.

[output_trouble : pattern] lists patterns that the analyzer should flag if they occur in the output sent by the login server back to the user.

PATH_UTMP smashdu.c Default: the pattern

      /^-r.s.*root.*\/bin\/(sh|csh|tcsh)/
    | /Jumping to address/
    | /smashdu\.c/
    | /PATH_UTMP/
    | /Log started at =/    
    | /www\.anticode\.com/
    | /smurf\.c by TFreak/
    | /Trojaning in progress/ 
    | /Super Linux Xploit/
The first of these triggers any time the user inspects with the ls utility an executable whose pathname ends in /bin/ followed by one of the popular command shells, and the ls output shows that the command shell has been altered to be setuid to root. The remainder match either the output generated by some popular exploit tools (for example, ``Jumping to address'', present in many buffer overflow exploit tools), exploit tool names (``smashdu.c''), text found within the tool source code (``smurf.c by TFreak''), or URLs accessed (say via the lynx or fetch utilities) to retrieve attack software (``www.anticode.com'').

[backdoor_prompts : pattern] lists patterns that the analyzer should flag if they are seen as the first line sent by the server to the user, because they often correspond with backdoors that offer a remote user immediate command shell access without having to first authenticate.

Default: the pattern ``/^[!-~]*( ?)[#%$] /'', which matches a line that begins with a series of printable, non-blank characters and ends with a likely prompt character, with a blank just after the prompt character and perhaps before it.

[non_backdoor_prompts : pattern] lists patterns that if a possible backdoor prompt also matches, then the analyzer should not consider the server output as indicating a backdoor prompt. Used to limit false positives for backdoor_prompts.

Default: the pattern ``/^ *#.*#/'', which catches lines with more than one occurrence of a #. Some servers generate such lines as part of their welcome banner.

[hot_terminal_types : pattern] lists ``magic'' terminal types sometimes used by attackers to access backdoors. Both Telnet and Rlogin have mechanisms for negotiating a terminal type (name; e.g., ``xterm''); these backdoors trigger and skip authentication if the name has a particular value.

VT666 Default: the name ``VT666'', one of the trigger terminal types we've observed in practice.

[hot_telnet_orig_ports : set[port]] Some Telnet backdoors trigger if the ephemeral port used by the client side of the connection happens to be a particular value. This variable is used to list the port values whose use should be considered as possibly indicating a backdoor. Note: Clearly, this mechanism can generate false positives when the client by chance happens to choose one of the listed ports.

Default: 53982/tcp, one of the trigger ports we have observed in practice.

Deficiency: There should be a corresponding variable for Rlogin backdoors triggered by a similar mechanism.

[hot_ssh_orig_ports : set[port]] Similar to hot_telnet_orig_ports, only for SSH.

Default: 31337/tcp, a trigger port that we've observed in practice.

[skip_authentication : set[string]] A set of strings that, if present in the server's initial output (i.e., its welcome banner), indicates the analyzer should not attempt to analyze the session for an authentication dialog. This is used for servers that provide public access and don't bother authenticating the user.

Default: the string "WELCOME TO THE BERKELEY PUBLIC LIBRARY", which corresponds to a frequently accessed public server in the Berkeley area. (Obviously, we include this default as an example, and not because it will be appropriate for most Bro users! But it does little harm to include it.)

Deficiency: It would be more natural if this variable and a number of others listed below were of type pattern rather than set[string]. They are actually converted internally by the event engine into regular expressions.

[direct_login_prompts : set[string]] A set of strings that if seen during the authentication dialog mean that the user will be logged in as soon as they answer the prompt.

Default: "TERMINAL?", a prompt used by some terminal servers.

[login_prompts : set[string]] A set of strings corresponding to login username prompts during an authentication dialog.

Default: the strings

    Login:
    login:
    Name:
    Username:
    User:
    Member Name
and the default contents of direct_login_prompts.

[login_failure_msgs : set[string]] A set of strings that if seen in text sent by the server during the authentication dialog correspond to a failed login attempt.

Default: the strings

    invalid
    Invalid
    incorrect
    Incorrect
    failure
    Failure,
    User authorization failure,
    Login failed,
    INVALID
    Sorry,
    Sorry.

[login_non_failure_msgs : set[string]] A set of strings similar to login_failure_msgs that if present mean that the server text does not actually correspond to an authentication failure (i.e., if login_failure_msgs also matches, it's a false positive).

Default: the strings

    Failures
    failures
    failure since last successful login
    failures since last successful login

[router_prompts : set[string]] A set of strings corresponding to prompts returned by the local routers when a user successfully authenticates to the router. For the purpose of this variable, see the next variable.

Default: empty.

[login_success_msgs : set[string]] A set of strings that if seen in text sent by the server during the authentication dialog correspond to a successful authentication attempt.

Default: the strings

    Last login
    Last successful login
    Last   successful login
    checking for disk quotas
    unsuccessful login attempts
    failure since last successful login
    failures since last successful login
and the default contents of the router_prompts variable.

Deficiency: Since by default router_prompts is empty, this last inclusion does nothing. In particular, if you redefine router_prompts then login_success_msgs will not pick up the change; you will need to redefine it to (again) include router_prompts, using: redef login_success_msgs += router_prompts. This is clearly a misfeature of Bro and will be fixed one fine day.

[login_timeouts : set[string]] A set of strings that if seen in text sent by the server during the authentication dialog correspond to the server having timed out the authentication attempt.

Default: the strings

    timeout
    timed out
    Timeout
    Timed out
    Error reading command input
(This last is returned by the VMS operating system.)

[non_ASCII_hosts : set[addr]] A set of addresses corresponding to hosts whose login servers do not (primarily) use 7-bit ASCII. The analyzer will not attempt to analyze authentication dialogs to such hosts, and will not complain about huge lines generated by either the sender or receiver (per excessive_line).

Default: empty.

[skip_logins_to : set[addr]] A set of addresses corresponding to hosts for which the analyzer should not attempt to analyze authentication dialogs.

Default: the (empty) contents of non_ASCII_hosts.

[always_hot_login_ids : set[string]] A set of usernames that the analyzer should always flag as sensitive, even if they're seen in a session for which the analyzer is confused (§ ).

Default: the value of always_hot_ids defined by the hot analyzer.

[hot_login_ids : set[string]] A set of usernames that the analyzer should flag as sensitive, unless it sees them in a session for which the analyzer is confused (§ ).

Default: the value of hot_ids defined by the hot-ids analyzer.

[rlogin_id_okay_if_no_password_exposed : set[string]] A set of username exceptions to hot_login_ids which the analyzer should not flag as sensitive if the user authenticated without exposing a password (so, for example, via .rhosts).

Default: the username "root".


login functions

The standard login script provides the following functions for external use:

[is_login_conn(c: connection): bool ] Returns true if the given connection is one analyzed by login (currently, Telnet or Rlogin), false otherwise.

[hot_login(c: connection, msg: string, tag: string) ] Marks the given connection as hot, logs the given message, and demultiplexes (§ ) the subsequent server-side contents of the connection to a filename based on tag and the client-side to a filename based on the name "keys". No return value.

[is_hot_id(id: string, successful: bool, confused: bool): bool ] Returns true if the username id should be considered sensitive, given that the user either did or did not successfully authenticate, and that the analyze was or was not in a confused state (§ ).

[is_forbidden_id(id: string): bool ] Returns true if the username id is present in forbidden_ids or forbidden_id_patterns.

[edit_and_check_line(c: connection, line: string, successful: bool): check_info ] Tests whether the given line of text seen on connection c includes a sensitive username, after first applying BS and DEL keystroke editing (§ ). successful should be true if the user has successfully authenticated, false otherwise.

The return value is a check_info record, which contains four check_info fields:

[expanded_line] All of the different editing interpretations of the line, separated by commas. For example, if the original line is
"rob<DEL><BS><BS>ot"
then the different editing interpretations are "ro<BS><BS>ot" and "root", so the return value will be:
"rob<DEL><BS><BS>ot,ro<BS><BS>ot,root"

Deficiency: Ideally, these values would be returned in a list of some form, so that they can be accessed separately and unambiguously. The current form is really suitable only for display to a person, and even that can be quite confusing if line happens to contain commas already. Or, perhaps an algorithm of ``simply pick the shortest'' would find the correct editing every time anyway.

hot: bool
True if any editing sequence resulted in a match against a sensitive username.

hot_id: string
The version of the input line (with or without editing) that was considered hot, or an empty string if none.

forbidden: bool
True if any editing sequence resulted in a match against a username considered ``forbidden'', per is_forbidden_id.

[edit_and_check_user(c: connection, user: string, successful: bool, fmt_s: string): bool ] Tests whether the given username used for authentication on connection c is sensitive, after first applying BS and DEL keystroke editing (§ ). successful should be true if the user has successfully authenticated, false otherwise.

fmt_s is a fmt format specifying how the username information should be included in the connection's addl field. It takes two string parameters, the current value of the field and the expanded version of the username as described in expanded_line.

If edit_and_check_line indicates that the username is sensitive, then edit_and_check_user records the connection into its own demultiplexing files (§ ). If the username is forbidden, then unless the analyzer is confused, we attempt to terminate the connection using terminate_connection.

Returns true if the connection is now considered ``hot,'' either due to having a sensitive username, or because it was hot upon entry to the function.

[edit_and_check_password(c: connection, password: string): bool ] Checks the given password to see whether it contains a sensitive username. If so, then marks the connection as hot and logs the sensitive password. No return value.

Note: The purpose of this function is to catch instances in which the event engine becomes out of synch with the authentication dialog and mistakes what is, in fact, a username being entered, for a password being entered. Such confusion can come about either due to a failure of the event engine's heuristics, or due to deliberate manipulation of the event engine by an attacker.


login event handlers

The standard login script handles the following events:

[login_failure (c: connection, user: string, client_user: string, password: string, line: string)] Invoked when the event engine has seen a failed attempt to authenticate as user with password on the given connection c. client_user is the user's username on the client side of the connection. For Telnet connections, this is an empty string, but for Rlogin connections, it is the client name passed in the initial authentication information (to check against .rhosts). line is the line of text that led the analyzer to conclude that the authentication had failed.

The analyzer first generates an account_tried event to facilitate detection of password guessing, and then checks for a sensitive username or password. If the username was not sensitive and the password is empty, then no further analysis is applied, since clearly the attempt was half-hearted and aborted. Otherwise, the analyzer annotates the connection's addl field with fail/<username> to mark the authentication failure, and also checks the client_user to see if it is sensitive. If we then find that the connection is hot, the analyzer logs a message to that effect.

[login_success (c: connection, user: string, client_user: string, password: string, line: string)] Invoked when the event engine has seen a successful attempt to authenticate. The parameters are the same as for login_failure.

The analyzer invokes check_hot with mode APPL_ESTABLISHED since the application session has now been established. It generates an account_tried event to facilitate detection of password guessing, and then checks for a sensitive username or password. The event engine uses the special password "<none>" to indicate that no password was exposed, and this mitigates the sensitivity of logins using particular usernames per rlogin_id_okay_if_no_password_exposed.

The analyzer annotates the connection's addl field with "<username>" to mark the successful authentication. Finally, if we then find that the connection is hot, the analyzer logs a message to that effect.

[login_input_line (c: connection, line: string)] Invoked for every line of text sent by the client side of the login session to the server side. The analyzer matches the text against input_trouble and edited_input_trouble and invokes hot_login with a tag of "trb" if it sees a match, which will log an alert concerning the connection. However, this invocation is only done while the connection's hot field count is $\le 2$, to avoid cascaded alerts when an attacker gets really busy and steps on a lot of sensitive patterns.

[login_output_line (c: connection, line: string)] Invoked for every line of text sent by the server side of the login session to the client side. The analyzer checks backdoor_prompts and any pending input alerts that were waiting on the server output, per edited_input_trouble. These last are then logged unless the output matched the pattern:

    /No such file or directory/
Deficiency: Clearly, this pattern should not be hardwired but instead specified by a redefinable variable.

Finally, if the line is not too long and the text matches output_trouble and the connection's hot field count is $\le 2$ (to avoid cascaded alerts), the analyzer invokes hot_login with a tag of "trb". Deficiency: ``Too long'' is hardwired to be a length $\ge 256$ bytes. It, too, should be specifiable via a redefinable variable. Note: We might wonder if not checking overly long lines presents an evasion threat: the attacker can bury their access to a sensitive string in an excessive line and thus avoid detection. While this is true, it doesn't appear to cost much. First, some of the sensitive patterns are generated in server output that will be hard to manipulate into being overly long. Second, if the attacker is trying to avoid detection, there are easier ways, such as passing their output through a filter that alters it a good deal.

[login_confused (c: connection, msg: string, line: string)] Invoked when the event engine's heuristics have concluded that they have become confused and can no longer correctly track the authentication dialog (§ ). msg gives the particular problem the heuristics detected (for example, multiple_login_prompts means that the engine saw several login prompts in a row, without the type-ahead from the client side presumed necessary to cause them) and line the line of text that caused the heuristics to conclude they were confused.

Once declaring that it's confused, the event engine will no longer attempt to follow the authentication dialog. In particular, it will not generate subsequent login_failure or login_success events.

Upon this event, the standard login script invokes check_hot with mode APPL_ESTABLISHED since it could well be that the application session is now established (it can't know for sure, of course, because the event engine has given up). It annotates the connection's addl field with confused/<line> to mark the confused state, and then logs to the weird file the particulars of the connection and the type of confusion (msg). Deficiency: This should be done by generating a weird-related event instead.

Finally, the analyzer invokes set_record_packets to specify that all of the packets associated with this connection should be recorded to the trace file. Note: For the current login analyzer, this call is not needed--it records every packet of every login session anyway, because the generally philosophy is that Bro should record whatever it analyzes, so that the analysis may be repeated or examined in detail. Since the current analyzer looks at every input and output line via login_input and login_output, it records all of the packets of every such analyzed session. There is commented-out text in login_success to be used if login_input and login_output are not being used; it turns off recording of a session's packets after the user has successfully logged in (assuming the connection is not considered hot).

[login_confused_text (c: connection, line: string)] Invoked for every line the user types after the event engine has entered the confused state. If the connection is not already considered hot, then the analyzer checks for the presence of sensitive usernames in the line using edit_and_check_line, and, if present, annotates the connection's addl field with confused/<line>, logs that the connection has become hot, and invokes set_record_packets to record to the trace file all of the packets associated with the connection.

[login_terminal (c: connection, terminal: string)] Invoked when the client transmits a terminal type to the server. The mechanism by which the client transmits the type depends on the underlying protocol (Rlogin or Telnet).

The handler checks the terminal type against hot_terminal_types and if it finds a match invokes hot_login with a tag of "trb".

[excessive_line (c: connection)] Invoked when the event engine observes a very long line sent by either the client or the server. Such long lines are seen as potential attempts by an attacker to evade the login analyzer; or, possibly, as a Login session carrying an unusual application. Note: One example we have observed occurs when a high-bandwidth binary payload protocol such as Napster is sent over the Telnet or Rlogin well-known port in an attempt to either evade detection or tunnel through a firewall.

This event is actually generic to any TCP connection carrying an application that uses the ``Network Virtual Terminal'' (NVT) abstraction, which presently comprises Telnet and FTP. But the only handler defined in the demonstration Bro policy is for Telnet, hence we discuss it here. For this reason, the handler first invokes is_login_conn to check whether the connection is in fact a login session. If so, then if the connection is not hot, and if the analyzer finds the server listed in non_ASCII_hosts, then it presumes the long line is due to use of a non-ASCII character set; the analyzer invokes set_login_state and set_record_packets to avoid further analysis or recording of the connection.

Otherwise, if the connection is still in the authentication dialog, then the handler generates a login_confused event with a confusion-type of "excessive_line", and changes the connection's state to confused.

Deficiency: The event engine is currently hardwired to consider a line of $\ge 1024$ bytes as ``excessive''; clearly this should be user-redefinable.

[inconsistent_option (c: connection)] NVT options are specified by the client and server stating which options they are willing to support vs. which not, and then instructing one another which in fact they should or should not use for the current connection. If the event engine sees a peer violate either what the other peer has instructed it to do, or what it itself offered in terms of options in the past, then the engine generates an inconsistent_option event.

The handler for this event simply records an entry about it to the weird file. Deficiency: The event handler invocation does not include enough information to determine what option was inconsistently specified; in addition, it would be convenient to integrate the handling of problems like this within the general ``weird'' framework.

Note: As for excessive_line above, this event is actually a generic one applicable to any NVT-based protocol. It is handled here because the problem most often crops up for Telnet sessions. Note: Also, the handler does not check to see whether the connection is a login session (as it does for excessive_line); it serves as the handler for any NVT session with an excessive line.

Note: Finally, note that this event can be generated if the session contains a stream of binary data. One way this can occur is when the session is encrypted but Bro fails to recognize this fact.

[bad_option (c: connection)] If an NVT option is either ill-formed (e.g., a bad length field) or unrecognized, then the analyzer generates this event.

The processing of this event (recording information to the weird file) and the various notes and deficiencies associated with it are the same as those for inconsistent_option above.

[bad_option_termination (c: connection)] If an NVT option fails to be terminated correctly (for example, a character is seen within the option that is disallowed for use in the option), then the analyzer generates this event.

The processing of this event (recording information to the weird file) and the various notes and deficiencies associated with it are the same as those for inconsistent_option above.

[authentication_accepted (name: string, c: connection)] The NVT framework includes options for negotiating authentication. When such an option is sent from client to server and the server replies that it accepts the authentication, then the event engine generates this event.

The handler annotates the connection's addl field with auth/<name>, unless that annotation is already present.

[authentication_rejected (name: string, c: connection)] The same as authentication_accepted, except invoked when the server replies that it rejects the attempted authentication.

The handler annotates the connection's addl field with auth-failed/<name>.

[authentication_skipped (c: connection)] Invoked when the event engine sees a line in the authentication dialog that matches skip_authentication.

The handler annotates the connection's addl field with ``(skipped)'' to mark that authentication was skipped, and then invokes skip_further_processing and (unless the connection is hot) set_record_packets to skip any further analysis of the connection, and to stop recording its packets to the trace file.

connection_established (c: connection)
connection_established is a generic event generated for all TCP connections; however, the login analyzer defines an additional handler for it.

The handler first checks (via is_login_conn) whether this is a Telnet or Rlogin connection. If so, it generates an authentication_skipped event if the server's address occurs in skip_logins_to, and also (for Telnet) checks whether the client's port occurs in hot_telnet_orig_ports, invoking hot_login with the tag "orig" if it does.

For SSH connections, it likewise checks the client's port, but in hot_ssh_orig_ports, marking the connection as hot and logging a real-time alert if it is.

partial_connection (c: connection)
As noted earlier, partial_connection is a generic event generated for all TCP connections. The login analyzer also defines a handler for it, one which (if it's a Telnet/Rlogin connection) sets the connection's state to confused and checks for hot_telnet_orig_ports.

[activating_encryption (c: connection)] The NVT framework includes options for negotiating encryption. When such a series of options is successfully negotiated, the event engine generates this event. Note: The negotiation sequence is complex and can fail at a number of points. The event engine does not attempt to generate events for each possible failure, but instead only looks for the option sent after a successful negotiation sequence.

The handler annotates the connection's addl field with ``(encrypted)'' to mark that authentication was encrypted. Note: The event engine itself marks the connection as requiring no further processing. This is done by the event engine rather than the handler because the event engine cannot do its job (regardless of the policy the handler might desire) in the face of encryption.


next up previous contents index
Next: The portmapper Analyzer Up: Analyzers and Events Previous: The ident Analyzer   Contents   Index
Vern Paxson 2004-03-21