IntelMQ-dev

intelmq-dev@lists.cert.at

241 discussions

Speed dumping events in bots
by Mika Silander 17 May '23

17 May '23

Hi again, Afaik, if handling an event fails in a bot, the default behaviour of a bot is to sleep 15 seconds and then retry processing. If the retry fails, the bot dumps the event and picks the next event from the inqueue. We have a bot where it would be desirable to change this default behaviour so that the dump is done immediately on the first failure. Is there a way to configure a single bot to behave differently from other bots as described? Or will a change in configuration affect the entire bot net? If there's no easy way configuring, I guess technically I could implement exceptions to be thrown in those situations where quick dumping is desired and then call the _dump_message(?) method. However, I would prefer to modify as few bots of the official distribution as possible. Comments, pointers to docs, sources or the like are most welcome. Br, Mika

3 5

Structural change in one feed's events output by the Shadowserver Parser bot?
by Mika Silander 05 May '23

05 May '23

Hi all, Testing with intelmq 3.1.0 and specifically its Shadowserver Parser bot. I've become used to being able to read in an event output by this bot as plain JSON with the json libraries bundled in python3, but now I came across one event sample where this fails. The feed is Accessible Traversal Utilities for NAT. The troublemaker event contained the field extra.amplification, and it was output by the bot as a dict structure like 'extra.amplification': Decimal("5.2") whereas I expected the field value to be a string "5.2" or number 5.2. Please let me know what I've missed again. A json library update? Br and have a nice weekend, Mika

1 1

RFC on IEP007: Running IntelMQ as Python Library
by Sebix 04 May '23

04 May '23

Dear community, I invite you to discuss a new (IEP - IntelMQ Enhancement Proposal) IEP007: Running IntelMQ as Python Library Have you ever wondered if you can write a Python script, call a bot's process method, pass it some data and get back the enriched/modified data? (pseudo code) bot_instance = Bot(parameters) bot_instance.process_message(input message) -> output messages Strictly speaking, it *is* actually possible with the current version, but it requires some bizarre hacks like re-defining Bot's methods and overwriting internal values. Staying on the wishlist for quite a while, we intend to implement the feature now. I started the IEP007 draft and need some input from you to maximize the benefit for all the IntelMQ community (developers): https://github.com/certtools/ieps/pull/7/files Or in a readable display: https://github.com/certtools/ieps/tree/iep-007/007 What features and interfacing options would you expect when starting the bot as a library? Do you think the `Bot.process` method should be rewritten entirely now, removing the calls receive_message/send_message and converting the method into a generator (an API-breaking change)? And if yes, should this be done in one step, or separated from this bot-as-library feature, reducing the complexity of development steps? Looking forward for your ideas Sebastian -- Institute for Common Good Technology gemeinnütziger Kulturverein - nonprofit cultural society https://sebix.at/ ZVR 1510673578

4 8

IntelMQ 3.1 release
by L. Aaron Kaplan 10 Feb '23

10 Feb '23

[TLP:WHITE, please pass this on, if appropriate] Dear everyone, it took a bit of time but I am excited to announce that today we finally pushed out release 3.1 of the open source IntelMQ (https://github.com/certtools/intelmq) incident handling automation framework. Special thanks go to Kamil, Sebix, Filip Pokorny (Gethvi) and Jason from Shadowserver (you all know who you are). Also I would like to thank the 91 (!) contributors [1] who have been helping in many ways over the last year(s) with IntelMQ. This truly is became a community effort and I am very happy that we can push this project further and maintain IntelMQ in the long run as a community project. IntelMQ is by now quite well respected as a "glue" / extract transform load (ETL) tool for fetching incident report feeds, processing them and sending them to the right place. It is widely used in Europe, in CERTs, SOCs and MSSPs. And best of it, it is open source and freely available. Again, we can not thank all the contributors enough. So, what's in release 3.1? =========================== (TL;DR: - find all things here: https://github.com/certtools/intelmq/blob/develop/NEWS.md) Highlights: * Excellent support for new Shadowserver feeds (thanks to Jason and Shadowserver). This is for sure the biggest part here. Shadowserver explicitly mentions IntelMQ for processing their feeds and will maintain the IntelMQ parsers for their feeds. * Big improvements for the dataplane.org parsers * Big shodan parser improvements Apart from that, a few other highlights: * More CI/CD tests * Tons of code clean-ups * New bots such as the url expert * Enhancements of existing bots: * SQL Output support MSSQL now, * GitHub collector, * Alienvault parser improvements, * Shodan parser improvements, * maxmind geoIP expert improvements, etc etc. * Tons of behind the scenes bugfixes! * Core changes (which you won't notice much) in the core part (pipeline class) etc etc.. We also dropped some support for old, outdated versions (python 3.6 or older Debian and old RedHat systems). This slims down the code base a bit again. As always, you can find all the nitty gritty details in the CHANGELOG [2] file and in the NEWS file [3] What's next? ============== * API: We want to move the IntelMQ-API [4] to fastapi (thanks to Kamil). Due to minor issues with packaging, this is not happening today, but this is planned for next week. So, stay tuned. IntelMQ-api and intelmq will be both numbered with the same version 3.1. * More user-feedback in the next few weeks. * Update the docker images for intelmq 3.1 * Upcoming task-specific tutorials on intelmq.org (for example how to send data to Splunk, how to automate all shadowserver feeds, etc.). Courtesy of David Ruefenacht. Should I update? ================== Yes! (but first on a DEV instance!) If you run a production instance, please update on a dev instance first and cross check. Because every IntelMQ setup is different. We try to cover a lot in our testing[5] , but we can't give a guarantee that everything is completely covered, especially if there are local changes. So, yes, please update, but tell us [6] in case something breaks in your DEV environment. (But yes! you really should update - since you might really want to have all those Shadowserver and dataplane.org updates) How to update? =============== * Upgrading: https://intelmq.readthedocs.io/en/maintenance/user/upgrade.html * Fresh installations: https://intelmq.readthedocs.io/en/maintenance/user/installation.html# (Note that the docker installation might lag behind a bit) Thank you and thanks to all the contributors! Aaron Kaplan. (for the whole IntelMQ team) [1] https://github.com/certtools/intelmq/graphs/contributors [2] https://github.com/certtools/intelmq/blob/develop/CHANGELOG.md [3] https://github.com/certtools/intelmq/blob/develop/NEWS.md [4] https://github.com/certtools/intelmq-api [5] https://intelmq.readthedocs.io/en/maintenance/dev/guide.html#testing [6] https://github.com/certtools/intelmq/issues

1 0

Unexpected log entry ordering in bots' logs
by Mika Silander 31 Oct '22

31 Oct '22

Hi all, I've been implementing a set of monitoring scripts for our intelmq instance. The scripts analyse the log files the bots output. One basic assumption of these scripts is that log entries are ordered according to time: the log entry on line N in the log file is older than the one on line N+1 and so forth. One of our scripts alerts if this assumption does not hold. This morning it reported the following unexpected ordering in the log of mail attachment bot (logrotated once, the file was /var/log/intelmq/mail-attachment-collector.log.1) : ... 2022-10-30 03:58:49,387 - mail-attachment-collector - INFO - Idling for 60.0s (1m) now. 2022-10-30 03:59:49,537 - mail-attachment-collector - INFO - Idling for 60.0s (1m) now. 2022-10-30 03:00:49,681 - mail-attachment-collector - INFO - Idling for 60.0s (1m) now. 2022-10-30 03:01:49,829 - mail-attachment-collector - INFO - Idling for 60.0s (1m) now. ... Any ideas as to why this happens? I already suspected logrotate and the bot net reload functionality, but logrotate is run for the bot net at 06:25 so this seems to be unrelated. I also guess this does not have to do with the mail bot's implementation but one could rather see this happen with other bots as well. A file handle flushing issue? Br, Mika

3 3

Feed handling bug in shadowserver parser bot?
by Mika Silander 05 Sep '22

05 Sep '22

Hi, We've been running intelmq in a production-like setup for some time now and occasionally we see the Shadowserver Parser bot behave in a way that looks odd. We push reports to it via the mail attachment collector bot. At times, the parser bot ends up treating all reports as being of the type Vulnerable ISAKMP. We don't know what triggers this behaviour but so far we've seen this when the parser parses Sandbox URL and Open TFTP reports, both filling the log (debug level) with notifications of "missing keys" or "optional keys not found" because the parser assumes the feed to be Vulnerable ISAKMP. And before this occurs, the parser has been running for a good while. We've picked up the the problematic Sandbox URL and Open TFTP reports above and made unit test cases of these - all tests are correctly parsed, the feed name is deduced correctly and the tests are successful, so the parser handles these correctly if these are the first reports parsed. Therefore, our assumption is that this problem occurs only when the parser has been running for a longer time and some state information about the feed type does not get cleared between parsing incoming reports. Anyone else experiencing similar problems? This is a tricky one to debug so I decided to ask on the list first. Br, Mika P.S: Our setup is intelmq 3.0.2 on an Ubuntu 20.04 LTS

3 7

Documentation on bot statistics collection
by Mika Silander 09 Aug '22

09 Aug '22

Hi, A few issues still remain to be solved before going to production and one of them is how to collect statistics on events. It looks to me that lib/bot.py contains code for collecting statistics and pushing cached data to a Redis instance, but I'd like to know if there's documentation describing the statistics collection in general and recommendations on its use? Any best practices or similar docs? I see there is the EventDB implementation but that in turn seems to be limited to statistics data being pushed out from intelmq via an SQL output bot. In our case we'd also need to keep a count on events being fed into intelmq. We'll probably also need some intermediate collection points within our bot net to keep track of the number of anomalous etc events. Therefore, leveraging somehow the constructs within lib/bot.py seems a better choice for us. As always, pointers are welcome and please correct me if I've understood something wrong above. Br, Mika

2 2

IntelMQ & API & Manager 3.1.0 Release candidate: Please test!
by Sebix 08 Aug '22

08 Aug '22

Dear community, about one year after the 3.0 release, 3.1 is just around the corner. Containing more than 200 commits in IntelMQ, this versions features numerous fixes and improvements from various contributors. The IntelMQ API did not change, the Manager did also receive two small bug fixes. Thanks to elsif2 the Shadowserver parser received massive updates (see Aaron's mail last week) and it needs testing. Therefore, we decided to do create a release candidate before the final "stable" 3.1.0 version. If you can spend some time on testing the new release, please do so and give feedback. Bear in mind that IntelMQ is a community project and has no sponsors, hence please consider contributing. The details you need to know before upgrading: https://github.com/certtools/intelmq/blob/3.1.0-rc1/NEWS.md Full list of changes: https://github.com/certtools/intelmq/blob/3.1.0-rc1/CHANGELOG.md The RC1 version is not available in the stable deb/rpm repository, only in the special "unstable" repository: https://intelmq.readthedocs.io/en/latest/dev/guide.html#testing-pre-releases https://software.opensuse.org/download.html?project=home:sebix:intelmq:unst… You can add the unstable repo alongside the stable repository. On PyPI the RC1 releases are marked as unstable and as such will only be installed if pip is called with intelmq==3.1.0rc1.post1 https://pypi.org/project/intelmq/3.1.0rc1.post1/ https://pypi.org/project/intelmq-api/3.1.0/ https://pypi.org/project/intelmq-manager/3.1.0rc1/ If you installed IntelMQ from git, just update the "develop" branch. The git tag is "3.1.0-rc1" best regards Sebastian -- Institute for Common Good Technology gemeinnütziger Kulturverein - nonprofit cultural society https://sebix.at/ ZVR 1510673578

1 0

heads-up: major code change in intelmq: shadowserver bots code base changed
by L. Aaron Kaplan 04 Aug '22

04 Aug '22

Dear intelmq users and -developers, yesterday I merged a major change to intelmq in the the shadowserver code base[1]. The big news is that from now on, Jason from shadowserver will maintain the intelmq shadowserver code base in intelmq (i.e., /intelmq/bots/{collectors,parsers}/shadowserver/*) directly, which is IMHO really good news for us. Why is this good news? First of all, this allows shadowserver to quickly add code to IntelMQ whenever they release a new scan-report. And they currently do roughly once per week. Sometimes more often! Secondly, the new shadowserver code uses the Shadowserver API [3] and JSON schema, which makes things easier. Finally, intelmq will be much more up to date and complete with respect to shadowserver's feeds. Please pay particular attention to the changes as outlined in the NEWS.md file here [2] Currently, this change is only in the "develop" branch [4]. What do we need from you? ========================= Testing feedback! If you have some time to try out the new shadowserver feeds, we would appreciate you trying out the "develop" branch with your shadowserver API key and tell us / this list / github's issue tracker [5] what worked and what did not work. After all, this is a large code change, and as always, there might be things which break unexpectedly. I would like to have this code well tested before we put it into the upcoming release 3.1. A *BIG* thank you goes out to shadowserver for offering the man-power, the help and all of the time they already put into improving the code base. And in my personal experience, shadowserver feeds are amongst the very best, highest quality data sources on vulnerable devices and IoCs in your network that you could get. So, in case you don't process their feeds yet, sign up here: https://www.shadowserver.org/what-we-do/network-reporting/get-reports/ (and it's even for free [6]). Thank you for your attention and best regards, Aaron Kaplan. [1] https://github.com/certtools/intelmq/pull/2227 [2] https://github.com/certtools/intelmq/pull/2227/files#diff-51920e95310ebfbc1… [3] https://www.shadowserver.org/what-we-do/network-reporting/api-documentation/ [4] https://github.com/certtools/intelmq/branches [5] https://github.com/certtools/intelmq/issues [6] though the urgently need sponsors for running their massive operations: https://www.shadowserver.org/sponsor/

1 0

Expected behaviour of intelmqctl reload ?
by Mika Silander 23 Jun '22

23 Jun '22

Hi all, Tracking down a rather elusive bug led me to suspect that the command intelmqctl reload your_bot_name_here does not necessarily rerun the bot's init method. At least I see an exception related to undefined variables (NoneType) when I reload the bot in question and let it chew a new event. Is this expected behaviour? Still, skimming through the code, it seems to me that the __init__ method in lib/bot.py gets invoked and should invoke the bot's init method as well. Any hints/ideas? Br, Mika

2 4

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

IntelMQ-dev