[Oisf-devel] smb parser question
jason taylor
jtfas90 at gmail.com
Mon Jul 9 12:42:06 UTC 2018
On Sat, 2018-07-07 at 16:46 +0200, Victor Julien wrote:
Hi Victor,
> On 02-07-18 14:54, jason taylor wrote:
> > I am looking at some smb traffic with the smb parser enabled from
> > the
> > latest/today master branch build and I am not seeing some of the
> > data
> > parsed out.
> >
> > I was hoping/expecting the smb/trans response/status would be
> > parsed
> > out (STATUS_INSUFF_SERVER_RESOURCES). I am not sure if this is a
> > bug or items still being implemented.
> >
> > I have attached the pcap, build info and output.
>
> Thanks for the pcap, I found some bugs in the dcerpc detection which
> lead to an event being set.
>
> However this is not the reason that the trans request isn't logged.
> Not
> every command/reply pair currently leads to a transaction being
> created.
> I've hard coded a check that doesn't create transactions for certain
> commands, mainly to reduce the amount of logs. Right now this check
> looks like this:
>
> pub fn smb1_create_new_tx(cmd: u8) -> bool {
> match cmd {
> SMB1_COMMAND_READ_ANDX |
> SMB1_COMMAND_WRITE_ANDX |
> SMB1_COMMAND_TRANS |
> SMB1_COMMAND_TRANS2 => { false },
> _ => { true },
> }
> }
>
> Reads and writes are suppressed as there can be many of them to
> transfer
> a single file. Trans and trans2 are also extremely common.
>
> We do log certain higher level transactions on top of those commands:
> files, dcerpc, etc.
>
> It's my goal to make this hard coded check configurable, so that you
> can
> enable trans/trans2 if you want. I guess another way that might be a
> reasonable balance is to only track (and log) trans/trans2
> transactions
> that do not result in a success code.
>
> Thoughts?
>
Agreed, being able to tune the check would be good. Being able to log
specific noisy commands and then of course further configure to log
only failed or successful attempts could be interesting too.
Of course that's more work on the dev side :) but the flexibility seems
like it would be nice to have.
JT
More information about the Oisf-devel
mailing list