<div dir="ltr">I would favor Aaron's approach. A single function in lib, called by parsers on-demand.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 9, 2017 at 7:36 PM, Sebastian Wagner <span dir="ltr"><<a href="mailto:wagner@cert.at" target="_blank">wagner@cert.at</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 06/08/2017 12:20 AM, L. Aaron Kaplan wrote:<br>
> On 12 Apr 2017, at 12:54, Sebastian Wagner <<a href="mailto:wagner@cert.at">wagner@cert.at</a>> wrote:<br>
</span><span class="">>> Instead of implementing the logic in many parsers we could add this<br>
>> "intelligence" in the libs.<br>
> I am not sure if I like that approach.<br>
> Usually the particularities of the "messiness" are best placed in the parser.<br>
> Even if the logic repeats itself a bit amongst different parsers.<br>
> 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/.<br>
> But: other parsers MUST NOT call that cleanup function.<br>
</span>Yes, that was the intention of my proposal (and Thomas' too I think)<br>
<span class="">> Because the http host dest fields might contain totally different (crap) in other feeds.<br>
> So...<br>
> I would *not* try to impose a default behaviour for all parsers here.<br>
</span>As I wrote, I do not like some magic too.<br>
<span class="">>> Other possibility: Use a new "logic" (actually non-existing) field, e.g.<br>
>> `destination.host-info`,<br>
> how about calling it destination.http_host ?<br>
</span>How is this related to HTTP? FQDN, IP and Port apply to all protocols<br>
AFAIK.<br>
<span class="">>> same applies to source. If some data is added<br>
>> to this field, the data will be parsed and added to ip, fqdn, port<br>
>> (,network?)<br>
>><br>
>> Example 1:<br>
>> event['destination.host-info'] = '<a href="http://example.com:8080" rel="noreferrer" target="_blank">example.com:8080</a>'<br>
>> results in:<br>
>> {'destination.fqdn': '<a href="http://example.com" rel="noreferrer" target="_blank">example.com</a>', 'destination.port': 8080}<br>
>> Example2:<br>
>> event['destination.host-info'] = '10.0.0.1'<br>
>> results in:<br>
>> {'source.ip': '10.0.0.1'}<br>
>><br>
> 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, ...<br>
</span>Yes, that was the intention of my proposal.<br>
<div class="HOEnZb"><div class="h5"><br>
Sebastian<br>
<br>
--<br>
// Sebastian Wagner <<a href="mailto:wagner@cert.at">wagner@cert.at</a>> - T: <a href="tel:%2B43%201%205056416%207201" value="+43150564167201">+43 1 5056416 7201</a><br>
// CERT Austria - <a href="https://www.cert.at/" rel="noreferrer" target="_blank">https://www.cert.at/</a><br>
// Eine Initiative der <a href="http://nic.at" rel="noreferrer" target="_blank">nic.at</a> GmbH - <a href="https://www.nic.at/" rel="noreferrer" target="_blank">https://www.nic.at/</a><br>
// Firmenbuchnummer 172568b, LG Salzburg<br>
<br>
<br>
</div></div></blockquote></div><br></div>