Previous: hot variables, Up: hot Analyzer



7.5.2 hot functions

The hot module defines two functions for external use:

check_spoof (c: connection): bool
checks the originator and responder addresses of the given connection to determine if they are both local (and the connection is not explicitly allowed in allow_spoof_services). If so, and if same_local_net_is_spoof is true, then marks the connection as “hot”.

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 event with a name of "Land_attack". It makes this check even if 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 the Table below. As noted in the Table, the processing differs depending on the state.

State Meaning Tests
CONN_ATTEMPTED Connection attempted, no reply seen. Note that you should also use this value for scans with indeterminant state, such as possible stealth scans. For example, connection half_finished does this. check_spoof
CONN_ESTABLISHED Connection established. Also used for connections apparently established, per partial_connection. check_spoof, flag_successful_service, flag_successful_inbound service, allow_services_to, terminate_successful inbound_service
APPL_ESTABLISHED The connection has reached application-layer establishment. For example, for Telnet or Rlogin, this is after the user has authenticated. allow_services_to, allow_service_pairs, allow_pairs, allow_16_net_pairs, hot_srcs, hot_dsts, hot_src_24nets, hot_dst_24nets
CONN_FINISHED The connection has finished, either cleanly or abnormally (for example, connection_reset. Same as APPL_ESTABLISHED, if the connection exchanged non-zero amounts of data in both directions, and if the service wasn’t one of the ones that generates APPL_ESTABLISHED
CONN_REJECTED The connection attempt was rejected by the server. check_spoof, flag_rejected_service

Table 7.3: Different connection states to use when calling check hot


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.