IntelMQ-dev

intelmq-dev@lists.cert.at

4 participants
243 discussions

Shadowserver parser: Bad mapping for malware events
by Thomas Hungenberg 31 Jan '24

31 Jan '24

Hi all, the parsers for malware events provided by different sources usually store the malware name in malware.name and classification.identifier is left blank (or set to the feed's name). When using the malware name mapping, a harmonized malware name is subsequently written to classification.identifier. So finally you have the original name in malware.name and the harmonized name in classification.identifier. Formerly (in the version we initially provided), the Shadowserver parser also stored the malware name in malware.name, see e.g. <https://github.com/certtools/intelmq/blob/c61ff2fd4232d6937f3815377b75f682a…> line 387 However, for some time the Shadowserver parser now writes the malware name ("infection") to classification.identifier and "family" to malware.name instead. This is bad for several reasons: - it is not consistent with parsers for other malware feeds - it breaks deduplicators matching on malware.name - the malware name mapping overwrites classification.identifier with the value of "family" (which often is empty) Here is a patch (for the version included with IntelMQ 3.2.1) to fix this problem and make malware events parsed by the Shadowserver parser consistent with other parsers again: =============================================== diff --git a/_config.py.orig b/_config.py index bea3d0c..431bcb9 100644 --- a/_config.py.orig +++ b/_config.py @@ -867,10 +867,9 @@ event_sinkhole = { ('source.port', 'src_port', convert_int), ], 'optional_fields': [ - ('classification.identifier', 'infection', validate_to_none), - ('malware.name', 'family', validate_to_none), + ('malware.name', 'infection', validate_to_none), + ('extra.', 'family', validate_to_none), ('extra.', 'tag', validate_to_none), - ('extra.', 'infection', validate_to_none), ('protocol.transport', 'protocol'), ('source.asn', 'src_asn', invalidate_zero), ('source.geolocation.cc', 'src_geo'), @@ -899,6 +898,7 @@ event_sinkhole = { 'constant_fields': { 'classification.taxonomy': 'malicious-code', 'classification.type': 'infected-system', + 'classification.identifier': 'sinkhole-events', }, } @@ -944,10 +944,9 @@ event_sinkhole_http = { ('source.port', 'src_port', convert_int), ], 'optional_fields': [ - ('classification.identifier', 'tag'), - ('malware.name', 'family', validate_to_none), + ('malware.name', 'infection', validate_to_none), + ('extra.', 'family', validate_to_none), ('extra.', 'tag', validate_to_none), - ('extra.', 'infection', validate_to_none), ('protocol.transport', 'protocol'), ('source.asn', 'src_asn', invalidate_zero), ('source.geolocation.cc', 'src_geo'), @@ -982,6 +981,7 @@ event_sinkhole_http = { 'constant_fields': { 'classification.taxonomy': 'malicious-code', 'classification.type': 'infected-system', + 'classification.identifier': 'sinkhole-http-events', 'protocol.application': 'http', }, } @@ -992,9 +992,9 @@ event_sinkhole_http_referer = { ('time.source', 'timestamp', add_UTC_to_timestamp), ], 'optional_fields': [ - ('malware.name', 'family', validate_to_none), + ('malware.name', 'infection', validate_to_none), + ('extra.', 'family', validate_to_none), ('extra.', 'tag', validate_to_none), - ('extra.', 'infection', validate_to_none), ('protocol.transport', 'protocol'), ('extra.', 'http_referer_ip', validate_ip), ('extra.', 'http_referer_port', convert_int), =============================================== Kind regards Thomas

4 11

Re: [IntelMQ-dev] [IntelMQ-users] IntelMQ & Kubernetes
by Bernhard Reiter 18 Jan '24

18 Jan '24

Hello Jessica, Am Mittwoch 17 Januar 2024 09:47:25 schrieb Jessica Schumacher via IntelMQ-users: > Now we want to take the “next” step to Kubernetes. > Does anyone have experience with running IntelMQ on Kubernetes? what Kubernetes implementation or components are you planning to use? E.g. k3s or something else? What is the problem you want to solve with this step? (I am seriously interested, because my experience with Kubernetes is very limited, so I want to understand where it actually helps. So far I've seen it has an advantage for large, multi-machine scaled application settings which does not entirely fit my mental model of IntelMQ. I expect it to be possible like you can put any application in such a setting, but it is worth the effort?) Regards, Bernhard -- https://intevation.de/~bernhard +49 541 33 508 3-3 Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter

1 0

STATS IN INTELMQ?
by Homma, L.J. (Luitzen) 28 Nov '23

28 Nov '23

Dear IntelMQ Developers & Users, We are curious if there are any plans on the roadmap to incorporate statistical features into IntelMQ. About 1.5 years ago, we participated in an online session where it was mentioned that there were some early plans to integrate stats into IntelMQ. As far as we could find, there have not been any steps in this direction. Are we correct? Currently, we are working in our experimental environment to develop stats based on a Prometheus bot, using Prometheus as a time-series database, and utilizing Grafana for dashboarding and visualization. Are there more members of the community working on this? Our goal is to gain better insights into the input, filtering, and output of our IntelMQ pipeline(s). We hope to hear from others about their thoughts on this. Met vriendelijke groet, Luitzen Homma Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is gezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten. This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.

6 18

Introducing proposals to IntelMQ Data Format (IEP008 and 9)
by Kamil Mankowski 02 Nov '23

02 Nov '23

Dear IntelMQ Developers & Users, I'd like to propose two changes to the IntelMQ data format to make it more suitable for current use cases. 1. IEP008 - add constituency identifier (this has already been shared, but only on the developer list): https://github.com/certtools/ieps/pull/9 2. IEP009 - add product and vulnerability information: https://github.com/certtools/ieps/pull/10 I'd like to hear your feedback on these suggestions. Feel free to comment here or on the Github pull requests. My plan is to implement them, unless rejected, by December. -- Best regards, Kamil Mankowski CERT.at GmbH www.cert.at

1 0

Expected behaviour of bot reloading after log rotation
by Mika Silander 24 Oct '23

24 Oct '23

Hi all, Apologies for a lengthy message, but I had a set of monitoring scripts that worked like a charm on a physical machine but when moved to a virtual machine with a newer Ubuntu, I see odd failures in the form of monitoring script processes left hanging on void file handles. I suspect the problem is somehow related to log rotation in connection to bot reloading but I can't figure out how. A few questions at the end. Our setup for reference: Ubuntu 22.04 LTS python 3.10.12 intelmq 3.2.2a1 intelmq-api 3.1.0-rc1 intelmq-manager 3.2.0 We have a simple bot chain: Mail Attachment Collector -> Shadowserver Parser -> N expert bots -> 1 output bot. /etc/logrotate.d/intelmq contains: /var/log/intelmq/*.log { su intelmq intelmq daily maxsize 10M rotate 60 notifempty compress delaycompress create 644 intelmq intelmq sharedscripts postrotate sudo -u intelmq /usr/bin/intelmqctl --quiet reload endscript } The cron daemon runs run-parts for targets under /etc/cron.daily/ at 06:25, including /etc/cron.daily/logrotate. Thus, "intelmqctl --quiet reload" gets also executed after all the intelmq log files have been rotated. What I see is that no bot reloads soon after run-parts has finished. The first bot to perform a reload is the Mail Attachment Collector immediately after midnight. The others remain as is until the Mail Attachment Collector reads the day's first report and forwards it to the Shadowserver Parser bot. The parser bot then performs a reload and forwards the events to the first expert in the chain. Once the first event from the parser trickles through the entire bot chain, every bot in turn first performs a reload and then processes the event. In practise, the logrotate triggered bot reload can thus be delayed almost a full day - our first mail reports tend to arrive during the very early morning hours. My question is, is the above reload behaviour as expected? I found it strange that the Mail Attachment Collector reloads at midnight even though it has processed new mail reports after the "intelmqctl reload" call done by logrotate. I would have expected the Mail Attachment Collector to reload itself when the first report arrives for processing after 06:25, i.e. the first report after the call to intelqmctl reload. And, what controls the timing of the Mail Attachment Collector's reload? All its reloads I see in older log files indicate that the reload is consistently run after midnight irrespective of incoming reports and the timing of the intelmqctl reload command. Thanks again and best regards from a puzzled Mika

3 6

IEP008 - Constituency field in IntelMQ Data Format
by Kamil Mankowski 09 Oct '23

09 Oct '23

Dear IntelMQ Community, I'd like to introduce an IEP with small extension to the current IntelMQ Data Format. As supporting multiple constituency groups is becoming more popular, we find it useful to include this information directly in the data format. IEP: https://github.com/certtools/ieps/pull/9/files This should not introduce any troubles to single-constituency setups, as well as do not define, how to mark the constituencies. The idea is just to open a possibility for that. I'd appreciate a feedback from the Community! -- Best regards, Kamil Mankowski CERT.at GmbH www.cert.at

1 0

intelmq-manager problem at login
by Mika Silander 19 Sep '23

19 Sep '23

Hi again, Hints would be welcome: I've got intelmq-manager installed, the front page opens ok but when I try to login, the developer view of the browser reports the following error after I specify the account and the password: DevTools failed to load source map: Could not load content for https://FQDN_HERE/intelmq_manager/plugins/bootstrap/bootstrap.min.css.map: HTTP error: status code 404, net::ERR_HTTP_RESPONSE_CODE_FAILURE Checking what's in /usr/share/intelmq_manager/html/plugins/bootstrap/ reveals there is no file there called bootstrap.min.css.map. The files that do exist in that directory are: bootstrap.css bootstrap.js bootstrap.min.css bootstrap.min.js My setup running on a Ubuntu 22.04 LTS / Python 3.10.12 is now: ii intelmq 3.2.2-1 all Solution for IT security teams for collecting ii intelmq-api 3.1.0~rc2-1 all FastAPI-based API for the intelmq project ii intelmq-manager 3.2.0-1 all Graphical interface to manage configurations As a side note, the intelmq-api package was upgraded from intelmq-api 3.1.0-rc1 in case this could be the culprit. Br and have a nice weekend, Mika

3 14

Trouble building deb package for intelmq-3.2.2
by Mika Silander 04 Sep '23

04 Sep '23

Hi all, Before digging any deeper I'll ask the list for advice. It's possible someone's bumped into the same error. I've upgraded from Ubuntu 20 LTS with intelmq-api 3.1.0~rc-1 intelmq-manager 3.2.0-1 intelmq 3.1.0-1 python3.8 to Ubuntu 22 LTS. Now, when trying to build intelmq-3.2.2 + a few of our own bots on this upgraded host with dpkg-buildpackage -us -us -b the build fails with: test-bot: Bot stopped. test-bot: Processed 1 messages since last logging. test-bot: Bot stopped. test-bot: Processed 1 messages since last logging. test-bot: Bot stopped. E: pybuild pybuild:369: test: plugin distutils failed with: exit code=1: python3.10 setup.py test dh_auto_test: error: pybuild --test -i python{version} -p 3.10 returned exit code 13 make: *** [debian/rules:24: build] Error 255 dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 The host has python3-distutils 3.10.8-1~22.04 installed. Any hints on what lies behind this error? Br & thanks, Mika

3 3

IntelMQ 3.2.1 release with two important bug fixes
by Sebix 28 Aug '23

28 Aug '23

Dear IntelMQ community, Together with CERT.at we just released IntelMQ version 3.2.1 containing two important bug fixes. 1. A bug in the bot's core library: > Fixes an issue which prevented bots from stopping gracefully after reloading. > As logrotate reloads all bots regularly, this bug affects most IntelMQ installations. 2. A bug in the Reverse DNS Expert bot: > Until IntelMQ version 3.2.0, the bot incorrectly cached and re-used results for /24 networks instead of single IP addresses. > If the bot retrieved the PTR for `192.0.43.7`, it was cached for `192.0.43.0/24` and used for all IP addresses in this range, for example for `192.0.43.8`. > IntelMQ version 3.2.1 fixes this issue. > The bugfix will correctly increase the cache sizes and decrease the performance, as less (incorrect) data is re-used. Upgrading: https://intelmq.readthedocs.io/en/develop/user/upgrade.html Installation: https://intelmq.readthedocs.io/en/develop/user/installation.html The PyPI package and git tag/GitHub release are published. The new deb-/rpm-packages will hit the repositories in the next few minutes and the updated Docker image follows soon. best regards Sebastian -- Institute for Common Good Technology gemeinnütziger Kulturverein - nonprofit cultural society https://sebix.at/ ZVR 1510673578

1 0

Shift of focus, new fields in IDF needed for scanning results?
by Otmar Lendl 21 Aug '23

21 Aug '23

Folks, I've been looking at some of the data that we recently processed with our IntelMQ setup (leading to https://cert.at/de/aktuelles/2023/8/verwundbare-webserver-status-in-osterre…), and I found that we need a few changes to IntelMQ to better process these kind of feeds. What happened? Initially, our focus with IntelMQ was on botnet drones which were detected via sinkholing. That's why we have the source.*, destination.*, and malware.* parameters in the data model. A C2 communication was the main inspiration. These days, a majority of the data feeds we process are generated by scanning the Internet. That can be Shodan, that can be Shadowserver, that can be from our own local scans. This is fine and good, it gives us valuable telemetry on what's going on in our constituency. But the fields needed to store the data in a consistent way are missing in the current iteration of the IDF. I don't want to pack that into extra.* or any non-standard field, I think we should come to an agreement what those elements are and how they should be handled. Here are some of the data fields I'm missing: What did the scanning find? * vendor * product * software version Are there any problems with it? * Vulnerability identifier (CVE or other, potentially multi-valued, which is another can of worms) * Severity information (e.g. associated CVSS score) * CWE IDs (https://cwe.mitre.org/index.html) Generic tagging * I see e.g. "iot", "ics" or similar ones popping up. As a minimum I think we need "vendor", "product" and "vulnerability". What do you all think? otmar ----------- References: https://datapedia.shodan.io/ There is e.g.: os string Operating system platform string product string Name of the software that powers the service. vendor string https://www.shadowserver.org/what-we-do/network-reporting/vulnerable-http-r… info on the vendor and CVEs is stored in the tag field. -- // Otmar Lendl <lendl(a)cert.at> - T: +43 1 5056416 711 // CERT Austria - https://www.cert.at/ // CERT.at GmbH, FB-Nr. 561772k, HG Wien

4 4

← Newer
1
2
3
4
5
6
7
...
25
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

IntelMQ-dev