Dear IntelMQ-Devs,
whilst analysing our current setup and possible requirements, we discovered
that an aggregation of events within IntelMQ might be a reasonable thing to
do.
In [1] I sketched how this might work. I'd be glad if you could find the time
to comment on this approach and participate in the discussion.
[1] https://github.com/certtools/intelmq/issues/751
Best regards
Dustin
--
dustin.demuth(a)intevation.de https://intevation.de/ OpenPGP key: B40D2EFF
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
Hi IntelMQ-Devs,
when writing tests what is your development suggestion for
writing similiar tests?
My problem:
intelmq/lib/test.py test_bot_name()
checks that "Test class name must be Test{botclassname}."
But sometimes it would make sense to have a second test class
within one test file. For example in
intelmq/tests/bots/experts/modify/test_expert.py
I am reusing some of the data of this tile.
On this occasion I have used a different class name and
explicitely disabled the test_bot_name().
You can reach the code via this search:
https://github.com/certtools/intelmq/search?utf8=%E2%9C%93&q=test_bot_name
I can see some merit checking for a consistent naming.
However making it easier to write more tests is also a good aim
and it looks like a good pattern to write more than one test class
within one file.
What is your idea of solving this in the future?
(I meanwhile add another test using the same trick.)
Best Regards,
Bernhard
--
www.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, Dr. Jan-Oliver Wagner
Hi,
Sebastian and me recently had a meeting at CERT.at - discussing the minimal feature set that we still want to have (from our perspective) for putting a "1.0" label on it.
We came up with a list. I am now prioritising this list.
I took a trick which I learned from another software project and assign priorities to the issues I create in github in the form of Fibonacci sequence numbers: 1,2,3,5,8,13. The benefit of this is that an intuitive value of 13 is really as valuable/high prio as the sum of the previous two priorities.
It's rather a bit geeky, but it seems to work.
Example: https://github.com/certtools/intelmq/issues/722
Anyway. Just letting you know (so that you don't wonder what this is). This is merely to be read as hint as what I see as high prio.
Feel free to adapt the prios or discuss here.
Best,
a.
Hi *,
as of the discussion in https://github.com/certtools/intelmq/issues/657, I renamed the classification.identifier of the shadowserver snmp to "opensnmp".
This might have consequences in your eventDB if you store these events and group them by "classification.identifier".
Please (SQL-) UPDATE your previous entries in the eventDB in that case.
Thanks,
a.
Hi friends of IntelMQ,
because we are currently planning for the next months
and additional webapps are on our lists (for use with the BSI)
I've started thinking what the recommendation should be from intelqm.
So far I am using the issue tracker to document the design process
https://github.com/certtools/intelmq/issues/708
(Basic technology: serving web applications)
On my planning list for intelmq web apps is:
* move the intelmq-manager to it
* add some statistic for the postgresql output bots running with certbund
* add some certbund-contact database maintenance
My current list is:
1. Bottle
2. Flask
3. CherryPy
While we should be focussing on getting 1.0 out of the door,
the planning on the web app side will probably continue.
I am happy to hear your opinions here or in the issue.
Best,
Bernhard
--
www.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, Dr. Jan-Oliver Wagner
(.... never say "last change" ;-)
I'd like to change the classification.taxonomy to become case insensitive.
Because it makes sense.
Any serious objections?
Best,
a.
Hi *,
Tuesday is our developer conf call day.
We switched it to 10:00 a.m. CET in order to sort of accommodate the Australian colleagues.
If you want to participate , please ping me and I'll send you the extension and tel#.
Best,
Aaron.
Hi,
IntelMQ uses dictionaries to represent messages (in python, json etc.).
We use a flat and unnested structure, which is one of the first design
goals made in the very beginning of IntelMQ AFAIK.
E.g. we have field names like "source.ip"
But there's also another possible representation, which is implemented
in IntelMQ: nested structures. E.g.:
flat: {"classification.type": "unknown", "source.asn": 456, "source.ip":
"127.0.0.1"}
nested: {"classification": {"type": "unknown"}, "source": {"ip":
"127.0.0.1", "asn": 456}}
The first is used everywhere except:
The messages to_json and to_dict methods, which use the nested format by
default. These methods are used in these output bots: file, xmpp,
restapi, mongodb, intelmqmailer
I think, that this is a wrong default. The default should be something
which can be directly interpreted by IntelMQ: the flat structure.
Proposal: make flat default and nested optional (for the function and
the bots)
Sebastian
--
// Sebastian Wagner <wagner(a)cert.at> - T: +43 1 50564167201
// CERT Austria - http://www.cert.at/
// Eine Initiative der nic.at GmbH - http://www.nic.at/
// Firmenbuchnummer 172568b, LG Salzburg
Hi IntelMQ-Users,
there is a discussion to improve the modify bot at [1].
As it stand we will change the configuration syntax.
So how many custom rules for this bot do you have in use?
Let us know so we can estimate how much support
for the old configuration syntax is necessary.
Best Regards,
Bernhard
[1] https://github.com/certtools/intelmq/issues/647
--
www.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, Dr. Jan-Oliver Wagner