[Intelmq-dev] Destination host in malware feeds

[Sebastian Wagner]

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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cert.at/pipermail/intelmq-dev/attachments/20170609/af4c354f/attachment.sig>