Next: , Previous: hot Analyzer, Up: hot Analyzer



7.5.1 hot variables

The standard hot script defines the following variables, all redefinable:

same_local_net_is_spoof : bool
If true, then a connection with a local originator address and a local responder address is considered by to have been spoofed. Deficiency:The name is poorly chosen (and may be changed in the future) to something more accurate like both_local_nets_is_spoof.

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; RFC-1939). 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 host_src or host_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_successful_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.

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_successful_inbound_service, except invokes in an attempt to terminate the connection.

Default: empty.

Note: As for flag_successful_inbound_service, it would be symmetric to have terminate_successful_outbound_service, and also to have a more general terminate_successful_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 Inserting tables into tables.

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.