[Oisf-devel] [Oisf-users] RFC: Yaml conf structure for enabling/disabling protocol parsers

[Anoop Saldanha]

On Sun, Dec 29, 2013 at 4:29 PM, Christian Kreibich
<christian at lastline.com> wrote:
> Hey guys,
>
> On 12/17/2013 02:32 AM, Anoop Saldanha wrote:
>> If you have something different on your mind, please go ahead and
>> introduce it, and we can deliberate on adding it to the list as well.
>
> A few comments:
>
> - When specifying protocol application statically, you want to provide a
> way to specify multiple possible ports and ideally also primitives on
> the ports (e.g., negation). Similarly, you may want to allow for future
> non-port constraints, such as enabling a parser only for flows (not)
> to/from certain subnets. You can express each (conjunctive) set of
> constraints in a (disjunctive) list of sequence items.
>

The format for specifying ports is the same as the one available in
our rule language.  It supports specificying multiple ports, range
specifcation and negation.

> - You could combine TCP vs UDP info with port numbers as a type notion,
> Bro style, so you don't need an extra level of hierarchy. Easy enough to
> parse.
>
> So, HTTP with dynamic detection everywhere and DNS statically configured
> on two responder ports, one UDP, one TCP, might look like this:
>
> app-layer:
>   protocols:
>     http:
>       - resp_ports: dynamic
>     dns:
>       - resp_ports: [ 53/udp, 53/tcp ]

The current setup works like this.  By default suricta's protocol
detection is dynamic.  The currently available "detection_ports"
feature is used as a backup, if  dyanmic detection fails to detect a
protocol.  When dynamic detection fails, the engine takes the flow
port and runs it against the port_based_protocol_detection if it has
been registered against that particular port.  So the explicit
specification of "dynamic" isn't necessary.

The concept of combinting the proto with the port, will have to be
extended to other parameters as well, "enabled" in specific -

 dns:
   enabled: yes/tcp, yes/udp
   dports: 53/tcp, [53]/udp

Is the above, what you hand in mind?

>
> You could then add future constraints to a sequence item's mapping,
> perhaps resp_nets for responder subnets:
>
>     http:
>       - resp_ports: [ 80/tcp ]
>         resp_nets:  [ 192.168.1.1/32 ]
>       - resp_ports: [ 8080/tcp ]
>         resp_nets:  [ 192.168.1.2/32 ]
>

We can probably enable protocol_detection/parser for a protocol for a
particular net, yeah.  Wondering how useful it would be in production.
 Any comments on this?

> Also, you'll want to allow for multiple of those app-layer config trees
> so you don't lose the ability to configure different protocols in
> different YAML files.

-- 
-------------------------------
Anoop Saldanha
http://www.poona.me
-------------------------------