[Bro] Modbus protocol event handler for Bro

[Hui Lin (Hugo)]

Hi Karl,

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
week.

Best

Hugo


On Mon, Sep 16, 2013 at 10:26 AM, Karl Kamin <kkamin at 21ct.com> wrote:

> Hugo,
>
> I am interested in your work with DNP3.  What is the svn site for that?
>
> Karl
>
>
> 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.
>
> Regards,
> Michael
>
> 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:
>>> http://csiir.ornl.gov/csiirw/12/BPAwards/csiirw8Submission7.pdf
>>>
>>> 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.
>> http://www.bro.org/development/dpd.html
>>
>> 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.
>>
>>
>> Best,
>>
>> Hugo
>>
>>
>


-- 
Hui Lin
PhD Candidate, Research Assistant
Electrical and Computer Engineering Department
University of Illinois at Urbana-Champaign
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20130916/1e0dad0f/attachment.html