Extracting File from Particular FTP Commands

I am looking to extract data from an FTP session, but would only like to do so for those
using the RETR or STOR command. I've been able to extract data from all FTP sessions by
looking for the FTP_DATA source during a file_new event, but can't seem to find a way to
access the associated ftp record with the command attribute. I'm assuming that this is
complicated by the separate connection for ftp data. I've thought about modifying the default FTP::file_over_new_connection event to associate the ftp command channel with the data
channel, but was wondering if there is a better (more accepted) approach before doing so.
Any advise would be appreciated.

My current file_new event is as follows:

event file_new(f: fa_file)
     if ( f$source != "FTP_DATA" )

     for ( cid in f$conns )
         if ( f$conns[cid]?$ftp )
             print fmt("Command: %s", f$conns[cid]$ftp$command);

     local fname = fmt("%s_%s.bin", to_lower(f$source), f$id);
     Files::add_analyzer(f, Files::ANALYZER_EXTRACT, [$extract_filename=fname]);

To modify the base/protocols/ftp/files.bro script, I was going to simply add a statement
to save the stored ftp record from ftp_data_expected to the current connection (c) which
holds the FTP_DATA data.

event file_over_new_connection(f: fa_file, c: connection, is_orig: bool) &priority=5
         if ( [c$id$resp_h, c$id$resp_p] !in ftp_data_expected )

         local ftp = ftp_data_expected[c$id$resp_h, c$id$resp_p];
         c$ftp = ftp;
         ftp$fuid = f$id;
         if ( f?$mime_type )
                 ftp$mime_type = f$mime_type;

Maybe have your own “file_over_new_connection” handler that sets the field. The downside to modifying the default handler in-place is that you have to remember the change will be overwritten on the next Bro install. The downside of having your own handler is sometimes duplication of logic (e.g. the “ftp_data_expected" table lookup). You can decide which is better, but the general suggestion is usually to just maintain your own event handlers separately.

- Jon