[Bro] DPD and similar analysis

Thomas, Eric D edthoma at sandia.gov
Tue Dec 9 11:21:29 PST 2008

Hi Robin,

When I do the run, I have no trouble getting the SSH ServerFound and ProtocolFound messages either. But I'm not getting the expected ServerFound and ProtocolFound notices for HTTP. I re-ran my test using your suggestion of loading http-request, http-reply and http-body, and I still didn't get those notices for HTTP. So I'd like to know, what does it take to see ServerFound and ProtocolFound notices for HTTP on standard HTTP ports (e.g. 80)? Thanks,


-----Original Message-----
From: Robin Sommer [mailto:robin at icir.org] 
Sent: Tuesday, December 02, 2008 1:30 PM
To: bro at bro-ids.org; Thomas, Eric D
Subject: Re: [Bro] DPD and similar analysis

On Mon, Dec 01, 2008 at 12:06 -0800, you wrote:

> or icmp)". To get bro to report ALL servers found, I temporarily 
> modified detect-protocols.bro and commented out the two sections that 
> would prevent generating notices for "well known ports" (using 
> dpd_config). So I would expect to see ServerFound messages for all 
> protocols that have been detected.

Hmm... I can't reproduce that. Likewise commenting out the dpd_config check in detect_protocols.bro and running with a tiny SSH trace I get:

> bro -r ssh.trace ssh dpd detect-protocols
1150485521.634103 ProtocolFound XXX.XXX.XXX.XXX/49244 > XXX.XXX.XXX.XXX/ssh SSH on port 22/tcp
1150485521.634103 ServerFound XXX.XXX.XXX.XXX: SSH server on port 22/tcp

> bro -r pcapfile.pcap conn dpd irc-bot dyn-disable detect-protocols 
> detect-protocols-http proxy http ssh zzz-custom

Note that you should use http-request instead of http, and potentially also load http-{reply,body}.bro.

> Once I figure this out, then I'll use DPD for it's intended purpose: 
> to detect protocols on non-standard ports. However, I'm also supposed 
> to do the inverse, that is, detect non-standard protocols on standard 
> ports. Any thoughts on how I could do this?

dyn-disable reports ProtocolViolations when the analyzer can't parse the protocol, which is an indicator that there might be something running on that port which isn't the standard protocol.

Also, if you enable dpd_conn_logs in conn.bro, the service field indicates the DPD result, including whether it could *not* parse the protocol.  From CHANGES:

  The new script variable dpd_conn_logs (default F), if true,
  changes the semantics of the service field in connection logs
  written to conn.log, as follows (Robin Sommer).  It becomes a
  comma-separated list of analyzers confirmed by DPD to parse the
  connection's payload.  If no analyzer could confirm its protocol,
  but the connection uses a well-known port, the service is the name
  of the port with "?" appended (e.g., "http?"), as long as the
  corresponding analyzer has not declined the connection. In
  addition, ftp-data sessions are labeled "ftp-data" and portmapper
  connections are labeled with the specific method-call (just as

  dpd_conn_logs defaults to F because the change in semantics may
  break scripts that parse conn.logs; but it will likely change to
  the default in the future. With dpd_conn_logs turned off, conn
  logs are generated as they used to be, with a few rare exceptions
  (with previous versions, the service field was sometimes
  determined while the connection was still alive; now it's always
  determined at the time when the conn.log entry is written out).

Robin Sommer * Phone +1 (510) 666-2886 * robin at icir.org 
ICSI/LBNL    * Fax   +1 (510) 666-2956 *   www.icir.org

More information about the Bro mailing list