Deprecating events

I'd like to deprecate the events below for 2.0, with the goal to
remove them for 2.1. Any objections?

Reason for deprecation is that these (1) are hardly used anywhere
anymore; and/or (2) use a model that doesn't fit well with how other
scripts are structured (like: do a lot of stuff inside the event
engine); and/or (3) have better ways to do it now (like the backdoor
events: signatures and DPD).

For the file-related events, I'm thinking that with the new logging
framework, we should remove all the "extra" functionality from
script-level files that we have added over time (rotation,
postprocessing, etc). The log framework provides all of that and is
the preferred way of doing it. Having two separate mechanisms for the
same functionality doesn't seem good. (To be clear, I want to keep
files themselves as a script-level data type, but without all the
bells and whistles)

There are more events that fit (1)-(3), in particular the
pattern-matching login_* events. Undecided whether those should go
too, but I have documented them for now.

Robin

## Deprecated. Will be removed.
event stp_create_endp%(c: connection, e: int, is_orig: bool%);
...

Is the intent to remove the stepping stone detection functionality?
That would be a pity, as now-and-then it provides very valuable forensic
information.

## Deprecated. Will be removed.
event interconn_stats%(c: connection, os: interconn_endp_stats, rs: interconn_endp_stats%);
...
## Deprecated. Will be removed.
event ssh_signature_found%(c: connection, is_orig: bool%);

I agree with removing this stuff, as interconn never worked that well, and
the signature stuff is all better done these days with DPD, or at least
with um the signature engine.

There are more events that fit (1)-(3), in particular the
pattern-matching login_* events. Undecided whether those should go
too, but I have documented them for now.

I'd be reluctant to lose these, as they could potentially become relevant
if one is able to feed unencrypted SSH streams to Bro (depending on how
the SSH server is set up).

    Vern

Is the intent to remove the stepping stone detection functionality?

Yes, that's what I was thinking.

That would be a pity, as now-and-then it provides very valuable forensic
information.

I didn't realize this is still being used. I'm fine keeping the events
then, but could you provide a few sentences describing their semantics
for the script reference? I don't really know.

I'd be reluctant to lose these, as they could potentially become relevant
if one is able to feed unencrypted SSH streams to Bro

That's right but isn't the scripting land the better place to
implement this functionality eventually? What I don't like is all the
hard-coded regexp variables that one passes into the core; that's
quite different from any other analyzer.

Robin

Re SSH streams, The iSSHD framework builds off the pattern matching
login-* events but in that case we just take advantage of the policy
infrastructure rather than the event generation.

cheers,
scott

> That would be a pity, as now-and-then it provides very valuable forensic
> information.

I didn't realize this is still being used.

It's quite rare, but basically whenever you detect (through some other
means) a credential thief, the stepping-stone info can be very handy for
the incident analysis.

I'm fine keeping the events
then, but could you provide a few sentences describing their semantics
for the script reference? I don't really know.

I really don't know if this is worth it. The events are fodder for the
specific algorithm; I can't picture a user actually wanting to write their
own handlers for them. That they're quite specific also makes them
awkward to explain. So my vote is to just label them as "internal to
the stepping-stone detector".

> I'd be reluctant to lose these, as they could potentially become relevant
> if one is able to feed unencrypted SSH streams to Bro

That's right but isn't the scripting land the better place to
implement this functionality eventually?

Yeah, it would ... though it's a pretty messy state-machine-plus-string-
matching chunk of code.

What I don't like is all the
hard-coded regexp variables that one passes into the core; that's
quite different from any other analyzer.

A valid point.

    Vern

Makes sense (the stepping stone detector isn't ported to 2.0 yet
though, like a few other scripts).

Robin