Hi everyone,
I have a question. We are processing nearly all the shadowserver feeds now (VNC is still missing)
and we stumbled across a problem that we can not 100% solve currently: how do you deal with 'accessible and only potentially vulnerable' devices?
Let me elaborate. Usually we sent out notifications on vulnerable devices (ENISA taxonomy: "Vulnerable". Examples: open recursive DNS, open NTP, anything mis-useable for UDP amplification attacks, etc).
However, at some point, accessible and (only potentially vulnerable) devices came into the game. I.e. a device running telnet (or something on the telnet port). Or VNC.
The VNC server might be protected by a pwd.
So, how to deal with that? An ISP might rightfully say that this telnet port is there intentionally and we should not complain?
So, we now have two types that we are talking about:
1. Vulnerable and openly accessible ports
2. Potentially vulnerable (but not proven) and accessible ports
Candidates for the second type would be:
* VNC
* telnet
* RDP
* (maybe) Redis
* (maybe) ES
* (maybe) memcached
* (maybe) Mongo
What's your stance on this?
How do you deal with it?
Note that we are sending out * a lot* as a national CERT and we would not like an ISP to be swamped by our mails if it does not have to be the case.
Best,
a.
--
// L. Aaron Kaplan <kaplan(a)cert.at> - T: +43 1 5056416 78
// CERT Austria - http://www.cert.at/
// Eine Initiative der nic.at GmbH - http://www.nic.at/
// Firmenbuchnummer 172568b, LG Salzburg
Hi everyone,
just to give you a heads up: we had a pull request from autumn 2016 which got finally merged into master
https://github.com/certtools/intelmq/pull/745
It's about a new format to the modify bot.
New format:
https://github.com/certtools/intelmq/blob/f02998b2cacb0dfe3ea6eb65f9d0b42bb…
(scroll down to "modify")
I believe the new format is way more readable.
But if you use the modify bot, please be aware of these changes when you pull in the new master branch.
Best,
Aaron.
(And thx sebix for the code)
--
// L. Aaron Kaplan <kaplan(a)cert.at> - T: +43 1 5056416 711
// CERT Austria - http://www.cert.at/
// Eine Initiative der nic.at GmbH - http://www.nic.at/
// Firmenbuchnummer 172568b, LG Salzburg
Folks,
In the current DHO there are 3 fields related to malware hash ('
*malware.hash*', '*malware.hash.md5*' and '*malware.hash.sha1*') but one of
them ('*malware.hash*') is not compliant with the current internal message
structure (technical details can be found on the issue 732
<https://github.com/certtools/intelmq/issues/732#issuecomment-269602721>).
Since it's a bug that needs to be fixed and affects the DHO, I would like
to propose the only three approaches that I see (maybe there are more...)
to solve this issue and would like to have your feedback to achieve an
agreement.
*Approaches**:*
1. Rename the key 'malware.hash' to something like 'malware.hash.other' for
situations where we see a feed providing a different type of hash
2. Remove the key 'malware.hash' and keep with the other two ones
3. Remove the keys 'malware.hash.md5' and 'malware.hash.sha1' and only use
the key 'malware.hash' for all types of hash. With this approach, if the
feed provides a md5 and sha1 hashes in the same event, we will not be able
to store both.
The chosen approach is the first one. If you have chance, please take some
minutes to give your feedback in order to understand if everyone is
comfortable with that.
Thank you in advance.
Cheers!
--
Tomás Lima* , * »-«* SYNchroACK *»-«
Hi,
as there are license issues with the code of the FTP(S) collector[1], I
raised the question if these collectors are actually used somewhere by
someone? The bot is not mentioned at all in the Feeds.md.
Are you using it? If no, do you think it should be kept nevertheless?
Sebastian
[1]: https://github.com/certtools/intelmq/issues/842
--
// 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
Hello,
for those not following all details:
I'm proposing to use **module-sphinx.ext.napoleon "google style"**
with type annotations as the default style to document code in docstrings.
Feedback appreciated (best directly into
https://github.com/certtools/intelmq/issues/857)
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 Dev's
I'm wondering how and if we want to organise write access to the main
repository.
IMHO it's not clear enough who is capable of merging code to the master
branch. A "secret" IntelMQ-Contributors group exists on GitHub, nevertheless
the members of this group do only have "read" access.
For the sake of transparency such teams should be public and documented in
the "Development Guidelines".
In addition, I think access to the Issue-Tracker is to limited. More people
should be allowed to tag, assign, close, etc. issues. This would lower the
workload of the "Core-Team". They could focus on things with other
priorities.
I know that in GitHub it is not possible to differentiate between write-access
to the Repo and Moderator-access to the tracker. All tracker-moderators would
have write-access to the repo. Nevertheless, this differentiation could be
achieved by a set of community-guidelines.
We should discuss those on this list.
I think such guidelines are sufficient means of access control, as:
1) It's a distributed VCS, changes can be reverted.
2) Clearly communicate who is allowed to push to the repository and who is not
and how to get Into the "privileged group". One could use GitHub-Teams to do
that.
For example and discussion:
* IntelMQ-Core-Dev: List of beings allowed to push to the master
* IntelMQ-Contributors: List of beings allowed to push to feature and
development branches, if this granularity is required
* IntelMQ-Mods: List of beings allowed to moderate the tracker and
documentation, like the wiki, readmes, etc.
* IntelMQ-Website: List of beings allowed to edit the Website
Those groups must not be secret.
3) There could be rules like: If someone pushes to the repository who is not
allowed to do it, tell him/her it was a misbehaviour and revert the changes.
If it's an intentional misbehaviour and happens multiple times, discuss the
Issue and revoke his/her write access.
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
Hello,
do we have vector sources for logo and letter head?
In particular for
https://github.com/certtools/intelmq/blob/master/docs/images/Logo_Intel_MQ.…
I am thinking about an admin interface for email tickets and contacts
(see https://github.com/certtools/intelmq/issues/708 (Basic technology:
serving web applications) and it would be useful to have a vector logo
version/source to create variations.
It seems to have come from cert.pt originally in 2014?
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
Hi Seamus,
Am Dienstag 29 November 2016 15:26:12 schrieb Seamus Tuohy:
> I've always found that trying to negotiate with a designer for source files
> after the fact is a difficult conversation.
I know, but some designers are very cool, so asking a polite question can be
the shortest way.
> I am a pretty quick Inkscape tracer though. So, here you go.
> It's not perfect.
I've taken a quick look: Very good!
Thanks a lot!
My aim is to add this to the public intelmq sources within the next days.
My tendency is to leave the image in, because it is well positioned and useful
to have.
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,
Currently the rfc1918 bot does sanitize much more IPs than those
mentioned in RFC1918 (5 rfcs or even more)
So it probably makes sense to rename the bot. Do you have suggestions?
Or is RFC1918 well known as "the RFC with reserved IPs"?
And do you think it makes sense to make it more configurable? E.g.
en/disable the sanitation for IPs and Domains separately?
Sebastian
--
// Sebastian Wagner <wagner(a)cert.at> - T: +43 1 50564167201
// CERT Austria - https://www.cert.at/
// Eine Initiative der nic.at GmbH - https://www.nic.at/
// Firmenbuchnummer 172568b, LG Salzburg
Dear contributors and users,
In the last year there have been so many changes to intelmq and now we
are well on the way towards a stable release.
We propose to make *Feature Freeze* *and* a *first release candidate in
October* so we can focus on heavy testing and bug fixing.
This is also the starting point for a better branching strategy:
https://github.com/certtools/intelmq/issues/650
Then, when all issues are fixed, we can do the release of version 1.0.
Also, we plan to publish packages for some distributions, .deb as well
as rpm. Currently there are still some open questions. But the
installation via pip will be no longer the recommended for production
environments.
To help, you can look at the open issues for 1.0:
https://github.com/certtools/intelmq/issues?q=is%3Aopen+is%3Aissue+mileston…
Tough I am assigned to most of them, you are encouraged to comment,
review or fix some of the tasks listed there!
The intelmq-manager needs some work to get partially compatible and
*much work* to get it "release-ready", basically a complete rewrite. See
https://github.com/certtools/intelmq-manager/issues/80
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
