[Intelmq-dev] Destination host in malware feeds

Navtej Singh nsbuttar at hotmail.com
Sat Jun 10 18:57:25 CEST 2017


I would favor Aaron's approach. A single function in lib, called by parsers
on-demand.

On Fri, Jun 9, 2017 at 7:36 PM, Sebastian Wagner <wagner at cert.at> wrote:

> On 06/08/2017 12:20 AM, L. Aaron Kaplan wrote:
> > On 12 Apr 2017, at 12:54, Sebastian Wagner <wagner at cert.at> wrote:
> >> Instead of implementing the logic in many parsers we could add this
> >> "intelligence" in the libs.
> > I am not sure if I like that approach.
> > Usually the particularities of the "messiness" are best placed in the
> parser.
> > Even if the logic repeats itself a bit amongst different parsers.
> > We could of course have a function in lib/ to clear this up, but then
> each parser which thinks it needs that cleanup part must call the cleanup
> function in lib/.
> > But: other parsers MUST NOT call that cleanup function.
> Yes, that was the intention of my proposal (and Thomas' too I think)
> > Because the http host dest fields might contain totally different (crap)
> in other feeds.
> > So...
> > I would *not* try to impose a default behaviour for all parsers here.
> As I wrote, I do not like some magic too.
> >> Other possibility: Use a new "logic" (actually non-existing) field, e.g.
> >> `destination.host-info`,
> > how about calling it destination.http_host ?
> How is this related to HTTP? FQDN, IP and Port apply to all protocols
> AFAIK.
> >> same applies to source. If some data is added
> >> to this field, the data will be parsed and added to ip, fqdn, port
> >> (,network?)
> >>
> >> Example 1:
> >> event['destination.host-info'] = 'example.com:8080'
> >> results in:
> >> {'destination.fqdn': 'example.com', 'destination.port': 8080}
> >> Example2:
> >> event['destination.host-info'] = '10.0.0.1'
> >> results in:
> >> {'source.ip': '10.0.0.1'}
> >>
> > but again, if you have destination.http_host there, then again it would
> make sense to parse it and put the info into destination.ip,
> destination.port etc, ...
> Yes, that was the intention of my proposal.
>
> Sebastian
>
> --
> // Sebastian Wagner <wagner at cert.at> - T: +43 1 5056416 7201
> // CERT Austria - https://www.cert.at/
> // Eine Initiative der nic.at GmbH - https://www.nic.at/
> // Firmenbuchnummer 172568b, LG Salzburg
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cert.at/pipermail/intelmq-dev/attachments/20170610/9202b417/attachment.html>


More information about the Intelmq-dev mailing list