Portmapper logging

Hi,

I dug around and checked how portmapper.bro does logging, notices, and
interaction with other policy scripts. It seems that it
* "logs" activity by setting the "addl" field for conn.log
* creates NOTICEs for some activity
* modifies the services field for connections that have an RPC
   service (e.g., NFS, ypserv, etc.)

See the attached file for details.

* The notices generation is very convoluted. I was wondering whether it
  makes sense to clean that up. (the attached file at least documents
  the behavior).

* I want to add an actual portmapper.log file to log portmapper
  activity. If we have that, we wouldn't need the "addl" anymore. Is it
  worth removing it? (Esp. wrt the new logging framework)

cu
gregor

portmapper-logging.txt (2.21 KB)

I dug around and checked how portmapper.bro does logging, notices, and
interaction with other policy scripts. It seems that it

Yeah, portmapper.bro is in fact one of the earliest script components that
tackled complex protocols interactions at the scripting level. (The other
is FTP.) Because it predates the whole notice framework, it has a bunch
of cruft that approximates the sort of policy filtering that later gave
birth to notices.

* The notices generation is very convoluted. I was wondering whether it
  makes sense to clean that up. (the attached file at least documents
  the behavior).

I am a *strong* believer in don't fix things like this unless there's a
pressing need. I'm assuming your interest here is driven by the NFS
analysis for the enterprise traces. If so, it would make sense to fix
(solely) those things necessary to expedite that analysis. But don't go
further; it's too much of a potential time sink (cleaning up code can be
beguilingly fun :slight_smile: for insufficient benefit.

    Vern

I would really like to see any activity logs for policy scripts moved out into their own logs. At OSU for instance, we didn't even keep the conn.log (we closed the log file) because it was mostly repetitive data that we didn't get much benefit from keeping. It's obviously much faster to grep smaller logs too. :slight_smile:

  .Seth

That's the one change I actually need/want to do for my NFS/portmapper
analysis. I want to have this information in its own portmapper.log
file. Removing the code that adds stuff to "addl" in portmapper.bro is
straight-forward if desired.

cu
Gregor

I would really like to see any activity logs for policy scripts moved
out into their own logs.

I like that notion too. (But still with the don't-fix-what's-not-broke
model of prioritization.)

At OSU for instance, we didn't even keep the conn.log (we closed the log
file) because it was mostly repetitive data that we didn't get much benefit
from keeping.

I find that very surprising. At LBL, the conn logs are often of crucial
forensic significance. One form of this comes up when an attacker sets
up a backdoor on port XYZ, which will only appear in the conn logs. Another
is when the activity involves a service for which there's no Bro analyzer.

    Vern

That's the one change I actually need/want to do for my NFS/portmapper
analysis. I want to have this information in its own portmapper.log

(Fair 'nuf, then. I withdraw my don't-fix-what's-not-broke concern.)

Netflow logs. :slight_smile: OSU being OSU, we tried to carefully maintain our archive of netflow.

  .Seth

No worries. I think I'm in general a bit more "trigger-happy" with
fixing/changing stuff..... :wink:

cu
gregor

I can understand that!

I say go ahead and make changes you want and store them somewhere, then when the review time for the portmapper script comes around, we'll use your version rather than the existing version.

  .Seth