[Bro] Modbus protocol event handler for Bro
Hui Lin (Hugo)
hlin33 at illinois.edu
Mon Sep 16 08:32:04 PDT 2013
The DNP3 analyzer is included in the master branch of the Bro 2.2. So you
can directly git bro source code, compile and build it. (
http://www.bro.org/development/contribute.html). You are good to use it. I
think that Bro 2.2-beta binary will be available for download later this
On Mon, Sep 16, 2013 at 10:26 AM, Karl Kamin <kkamin at 21ct.com> wrote:
> I am interested in your work with DNP3. What is the svn site for that?
> From: Michael Haney <michael-haney at utulsa.edu>
> Date: Friday, March 29, 2013 12:49 PM
> To: Hugo <hugolin615 at gmail.com>, "Slagell, Adam J" <slagell at illinois.edu>,
> "bro-blue at bro.org" <bro-blue at bro.org>
> Cc: Jason Staggs <jason-staggs at utulsa.edu>, "bro at bro.org" <bro at bro.org>
> Subject: Re: [Bro] Modbus protocol event handler for Bro
> I appreciate you guys getting back to me, and I can also tell you that
> there is other interest in this out there based on off-list responses.
> So, yes, Dynamic Protocol Detection (DPD) is the acronym that didn't come
> to me last night. I'm relatively new to Bro, and unfortunately only have a
> cursory knowledge of the SCADA protocols I need to know about. But I do
> have access to about a terabyte of recorded pcaps of a mix of things on a
> production network, but most of it is SCADA related and primarily in
> Modbus, RockLink, and a couple other vendor versions of protocols. But as I
> said, non-standard ports so port triggering is probably not what I'm
> looking for (or we're going to have a list of about 5000 different ports to
> trigger on).
> As I understand it, there are a couple of methods to use for handling
> protocol anomalies and detecting malicious activities. One is to look at
> the protocol specs and see if you can identify a packet as valid or invalid
> for that protocol. Invalid packets show signs of fuzzing,
> misconfiguration, or malicious activity. Then there is identifying the
> "normal" traffic. Like matching one response to one request. If you get
> unsolicited "responses" for example, it may be a replay attack,
> misconfiguration, or other malicious activity.
> Then the third (final?) step is to look at the actual legitimate traffic
> that matches up with the protocol and everything, but determine if it's a
> malicious attempt to extract system information or sabotage critical
> infrastructure, by an insider for example, or by a malicious outsider who
> knows how to talk Modbus but is sending commands that are outside of normal
> operation. Lots of work has been done in that area to see if we can
> validate normal operation parameters and out-of-norm activities. The
> problem is, we can't automate it on this dataset unless we can first
> identify an arbitrary packet as being a modbus packet or not.
> Have I got that breakdown right? Is this similar to what others are
> looking for?
> So I'm excited about being a brogrammer and I think this is as good a
> place for me to jump in as any. But I'm also very glad to hear more about
> the work that has already been done (and I don't have to take on such a
> task alone from scratch). I'd like to offer myself as your beta
> tester/guinea pig. But there will be some minor hurdles to overcome with
> data sharing. Technically, our research grant has expired (ended in
> December) and I need to get permission from the corporate entity to
> continue to use their data for our testing, as well as carve out time from
> work and school duties to focus on this. But assuming all that works out,
> I look forward to helping out with this development effort.
> On Fri, Mar 29, 2013 at 9:08 AM, Hugo <hugolin615 at gmail.com> wrote:
>> On Fri, Mar 29, 2013 at 1:53 AM, Michael Haney <michael-haney at utulsa.edu>wrote:
>>> I'm reviewing this paper and the related code for DNP3:
>>> But I have a network I'm analyzing that has modbus over tcp and has
>>> implemented things in a somewhat unorthodox way. They've used port
>>> assignments as a means of categorizing subsets of systems, and a bit of
>>> security by obscurity. So nothing is on the standard port 502. It's all
>>> over the place on ranges of ports from 2100 to 9900.
>>> Enter Bro and it's acclaimed ability to recognize protocols not by port
>>> number but by semantics of the payload.
>> Just FYI, Bro has three ways to activate a new analyzer.
>> Analyzers can use one of three ways to be fed new connections:
>> - Use a preconfigured set of ports, thus triggering on all
>> connections using any of the registered ports.
>> - Use content signatures, thus triggering on all connections that
>> match the relevant signatures.
>> - Hard-code to trigger on all connections, when signatures won’t cut
>> it and the protocol uses arbitrary ports. This should be avoided whenever
>> possible obviously.
>>> But has anyone done this for modbus yet? Anyone interested to use it if
>>> I start working on it? (read: volunteer beta tester and guinea pig).
>> I believe that Modbus analyzer is already included in Bro master branch
>> for a while now. So you can directly use it. You are more than welcome to
>> use it.
>>> What about other ICS/SCADA protocols?
>> I am mainly responsible for the DNP3 analyzer. Due to some legacy issues,
>> I spent a comparatively long period to include it in Bro. I actually
>> finished almost everything just yesterday (still working on some comments
>> to people who want to understand my code). If you want to use it, please
>> let me know, I can direct you to download from one of the branch that we
>> about to include in Master soon.
PhD Candidate, Research Assistant
Electrical and Computer Engineering Department
University of Illinois at Urbana-Champaign
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Bro