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

[Lance Lassetter]

On Thu, Jan 02, 2014 at 06:10:48PM +0530, Anoop Saldanha wrote:
> 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?
Fine tuning protocol and port would be a plus I would think.
> 
> > 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
> -------------------------------
> _______________________________________________
> Suricata IDS Users mailing list: oisf-users at openinfosecfoundation.org
> Site: http://suricata-ids.org | Support: http://suricata-ids.org/support/
> List: https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
> OISF: http://www.openinfosecfoundation.org/