hot
variables
The standard hot
script defines the following variables, all redefinable:
same_local_net_is_spoof : bool
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]
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]
host_src
or
host_dsts
), for which this particular access should
be allowed.
Default: empty.
allow_16_net_pairs : set[addr, addr]
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
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
hot_srcs
, except for destination addresses.
Default: empty.
hot_src_24nets : table[addr] of string
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
hot_src_24nets
, except for destination networks.
Default: empty.
allow_services : set[port]
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]
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]
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
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
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
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.