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
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