The standard hot script defines the following variables, all redefinable:
In general, you want to use true for a Bro that is monitoring Internet access links (DMZs) and false for internal monitors.
Default: F.
[allow_spoof_services : set[port]] Defines a set of services (responder ports) for which Bro should not generate alerts if it sees apparent spoofed traffic.
Default: 110/tcp (POP version 3; [RFC1939]). This default was chosen because in our experience one common form of benign spoof is an off-site laptop attempting to read mail while still configured to use its on-site address.
[allow_pairs : set[addr, addr]] Defines pairs of source and destination addresses for which the source is allowed to connect to the destination. The intent with this variable is that the source or destination address will be a sensitive host (such as defined with hot_srcs or hot_dsts), for which this particular access should be allowed.
Default: empty.
[allow_16_net_pairs : set[addr, addr]] Defines pairs of source and destination /16 networks for which the source is allowed to connect to the destination, similar to allow_pairs. Note: The set is defined in terms of addr's and not net's. So, for example, rather than specifying 128.32., which is a net constant, you'd use 128.32.0.0 (an addr constant).
Default: empty.
[hot_srcs : table[addr] of string] Defines source addresses that should be considered ``hot''. A successfully established connection from such a source address is logged, unless one of the access exception variables such as allow_pairs also matches the connection. The value of the table gives an explanatory message as to why the source is hot; for example, "known attacker site". Note: This value is not currently used, though it aids in documenting the policy script.
Default: empty.
Example: redefining hot_srcs using
redef hot_srcs: table[addr] of string = { [ph33r.the.eleet.com] = "script kideez", };would result in Bro alerting on any traffic coming ph33r.the.eleet.com.
[hot_dsts : table[addr] of string] Same as hot_srcs, except for destination addresses.
Default: empty.
[hot_src_24nets : table[addr] of string] Defines /24 source networks should be considered ``hot,'' similar to hot_srcs. Deficiency: Other network masks, particularly /16, should be provided.
Default: empty.
Example: redefining hot_src_24nets using
redef hot_src_24nets: table[addr] of string = { [198.81.129.0] = "CIA incoming!", };would result in Bro alerting on any traffic coming from the 198.81.129/24 network.
[hot_dst_24nets : table[addr] of string] same as hot_src_24nets, except for destination networks.
Default: empty.
[allow_services : set[port]] Defines a set of services that are always allowed, regardless of whether the source or destination address is ``hot.''
Default: ssh, http, gopher ident, smtp, 20/tcp (FTP data).
Note: The defaults are a bit unusual. They are intended for a quite open site with many services.
[allow_services_to : set[addr, port]] Defines a set of services that are always allowed if the server is the given host, regardless of whether the source or destination address is ``hot.''
Default: empty.
Example: redefining allow_services_to using
redef allow_services_to: set[addr, port] += { [ns.mydomain.com, [domain, 123/tcp]], } &redef;would result in Bro not alerting on any TCP DNS or NTP traffic heading to ns.mydomain.com. You might add this if ns.mydomain.com is also in hot_dsts, because in general you want to consider any access (other than DNS or NTP) as sensitive.
[allow_services_pairs : set[addr, addr, port]] Defines a set of services that are always allowed if the connection originator is the first address and the responder (server) the second address.
Default: empty.
Example: redefining allow_services_pairs using
redef allow_services_pairs: set[addr, addr, port] += { [ns2.mydomain.com, ns.mydomain.com, [domain, 123/tcp]], } &redef;would result in Bro not alerting on any TCP DNS or NTP traffic initiated from ns2.mydomain.com to ns.mydomain.com.
[flag_successful_service : table[port] of string] The opposite of allow_services. Defines a set of services that should always be flagged as sensitive, even if neither the source nor the destination address is ``hot.'' The string value in the table gives the reason for why the service is considered hot. Note: Bro currently does not use these explanatory messages.
Default: 31337/tcp (a popular backdoor because in stylized lettering it spells ELEET) and 2766/tcp (the Solaris listen service, in our experience rarely used legitimately in wide-area traffic).
Note: Bro can flag these services erroneously when a server happens to run a different service on the same port. For example, if you're not running the FTP analyzer, then Bro won't know that FTP data connections using ephemeral ports in fact belong to legitimate FTP traffic, and will flag any that coincide with these services. A related problem arises when a user has configured their SSH access to tunnel FTP control channels through the FTP connection, but not the corresponding data connections (so they don't pay the expense of encrypting the data transfers), so again Bro can't recognize that the ephemeral ports used for the data connections does not reflect the presumed sensitive service.
Example: redefining flag_successful_service using
redef flag_successful_service: table[port] of string += { [1524/tcp] = "popular backdoor", };would result in Bro also alerting on any successful connection to a server running on TCP port 1524.
[flag_successful_inbound_service : table[port] of string]
The same as flag_
[0]successful_
[0]service, except only applies to
connections with a remote initiator and a local responder (determined
by finding the responder address in local_nets).
Default: 1524/tcp (ingreslock, a popular backdoor because an attacker can place an entry for the backdoor in /etc/inetd.conf using a service name rather than a raw port number, and hence more likely to appear legitimate to casual inspection). Note: There's no compelling reason why ingreslock is in this table rather than the more general flag_successful_service, though it does tend to result in a few more false hits than the others, presumably because it's a lower port number, and hence more likely on some systems to be chosen for an ephemeral port. ingreslock
Note: Symmetry would call for flag_successful_outbound_service. This hasn't been implemented in Bro yet simply because the Bro development site has a threat model structured primarily around external threats.
[terminate_successful_inbound_service : table[port] of string]
The same as flag_
[0]successful_
[0]inbound_
[0]service, except invokes
terminate_connection in an attempt
to terminate the connection.
Default: empty.
Note: As for flag_
[0]successful_
[0]inbound_
[0]service, it would be symmetric
to have terminate_
[0]successful_
[0]outbound_
[0]service, and also to have
a more general terminate_
[0]successful_
[0]service.
[flag_rejected_service : table[port] of string]
Similar to flag_successful_service, except applies to connections
that a server rejects. For example, you could detect a particular, failed
Linux mountd attack by adding 10752/tcp to this table, since
that happens to be the port used by the commonly
available version of the exploit
for its backdoor if the attack succeeds. Note: You would of course
likely also want to put 10752/tcp in flag_successful_service;
or put the entire flag_rejected_service table into flag_successful_service, as discussed in
§
Default: none.
Deficiency: It might make sense to have flag_attempted_service, which doesn't require that a server actively reject the connection, but Bro doesn't currently have this.
The hot module defines two functions for external use:
The function also checks for a specific denial of service attack, the ``Land'' attack, in which the addresses are the same and so are the ports. If so, then it generates a conn_weird event with a name of "Land_attack". It makes this check even if same_local_net_is_spoof is false.
Returns: true if the connection is now hot (or was upon entry), false otherwise.
[check_hot(c: connection, state: count): bool ] checks the given connection against the various policy variables discussed above, and bumps the connection's hot field if it matches the policies for being sensitive, and does not match the various exceptions. It also uses check_spoof to see if the connection reflects a possible spoofing attack; and terminates the connection if terminate_successful_service indicates so.
|
The caller indicates the connection's state in the second parameter to the function, using one of the values given in Table 7.5.2. As noted in the Table, the processing differs depending on the state.
In general, the pattern is to make one call when the connection is first seen, either CONN_ATTEMPTED, CONN_ESTABLISHED, or CONN_REJECTED. If the application is one for which connections should only be considered ``established'' after a successful pre-exchange between originator and responder, then a subsequent call is made with a state of APPL_ESTABLISHED. The idea here is to provide a way to filter out what are in fact not really successful connections so that they are not analyzed in terms of successful service. Finally, for services that don't use APPL_ESTABLISHED, a call is made instead when the connection finishes for some reason, using state CONN_FINISHED. Note: This approach delays alerting until the connection is over, which might be later than you want, in which case you may need to edit check_hot to provide the desired functionality.
Returns: true if the connection is now hot (or was upon entry), false otherwise.