[Bro] Modbus protocol event handler for Bro

Michael Haney michael-haney at utulsa.edu
Fri Mar 29 10:49:42 PDT 2013


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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20130329/a7e76163/attachment.html 


More information about the Bro mailing list