IntelMQ-dev

intelmq-dev@lists.cert.at

1 participants
246 discussions

Re: [Intelmq-dev] 2 error
by Bernhard Reiter 10 Aug '16

10 Aug '16

Am Mittwoch, 10. August 2016 16:30:42 schrieb ben dosso: > I give you the links for the application. this is the tutorial I followed > to install the application on Ubuntu 16 and 14 I also ubuntu you copy > errors ubuntu 16 connections : > https://github.com/certtools/intelmq/blob/master/docs/User-Guide.mderror : > localhost indique:Failed to obtain JSON:http://localhost/php > load_configs.php ?file=bots with error: Parsererror SyntaxERROR:unexpected > token < in JSON at position 0 the error was made bold What does ls -l /opt/intelmq/etc give you? -- 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

1 0

2 error
by ben dosso 10 Aug '16

10 Aug '16

first error I installed Ubuntu on intelmq 16 application does not pass. I am sending you the error message with an attachment and when I am the way opt / intelmq intelmq the file can not be opened. I was told not to display the content and also you do not have the required permissions to view the contents of "intelmq". second error I installed intelmq on a virtual machine ubuntu 14 but this time I encounter this error

2 1

I have a problem about using Application intelmq
by ben dosso 10 Aug '16

10 Aug '16

1 0

Re: [Intelmq-dev] Intelmq-dev Digest, Vol 6, Issue 2
by ben dosso 10 Aug '16

10 Aug '16

I have a problem about using Application intelmq > From: intelmq-dev-request(a)lists.cert.at > Subject: Intelmq-dev Digest, Vol 6, Issue 2 > To: intelmq-dev(a)lists.cert.at > Date: Mon, 8 Aug 2016 12:00:02 +0200 > > Send Intelmq-dev mailing list submissions to > intelmq-dev(a)lists.cert.at > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.cert.at/cgi-bin/mailman/listinfo/intelmq-dev > or, via email, send a message with subject or body 'help' to > intelmq-dev-request(a)lists.cert.at > > You can reach the person managing the list at > intelmq-dev-owner(a)lists.cert.at > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Intelmq-dev digest..." > > > Today's Topics: > > 1. Re: Taxonomies & Sharing mechanism [SEC=UNCLASSIFIED] > (Clark, Andrew) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 8 Aug 2016 05:55:55 +0000 > From: "Clark, Andrew" <Andrew.Clark(a)cert.gov.au> > To: Otmar Lendl <lendl(a)cert.at>, "intelmq-dev(a)lists.cert.at" > <intelmq-dev(a)lists.cert.at> > Subject: Re: [Intelmq-dev] Taxonomies & Sharing mechanism > [SEC=UNCLASSIFIED] > Message-ID: > <454F4A633809FD40898A9D230EDFA93138B2E82B(a)ACTDC01MLD02V.agdnet.ag.gov.au> > > Content-Type: text/plain; charset="utf-8" > > UNCLASSIFIED > Hi Otmar, > > I have never really investigated what's out there in terms of taxonomies, to any great extent. > > We use MISP, and if you haven't seen it, take a look at how many taxonomies they've tried to accommodate: https://github.com/MISP/misp-taxonomies/ > > If I'm reading the correct things, I suspect we might be lucky because the CERT.pt taxonomy looks very similar to the eCSIRT taxonomy used by IntelMQ (and supported by MISP). > > The CERT.pt taxonomy (from this site: http://www.cncs.gov.pt/cert-pt-2/documents-2/) includes 18 "incident types" and 10 "incident classes". The ClassificationType class from IntelMQ supports 20 values, including the 18 from the CERT.pt taxonomy, plus "unknown" and "blocklist". Based on this, I don't think there is a good reason to change what IntelMQ uses now. > > Regarding STIX and Cybox (and TAXII), here at CERT Australia we are using them heavily. STIX includes a 'TTP' object which can be associated with Indicators. TTPs include 'behaviours' and while STIX supports the CAPEC (capec.mitre.org) taxonomy natively, it would be easy to extend to support arbitrary taxonomies. > > Hope you're enjoying your vacation! > > Andrew > > -----Original Message----- > From: Intelmq-dev [mailto:intelmq-dev-bounces@lists.cert.at] On Behalf Of Otmar Lendl > Sent: Saturday, 6 August 2016 2:07 AM > To: intelmq-dev(a)lists.cert.at > Subject: [Intelmq-dev] Taxonomies & Sharing mechanism > > > Folks, > > as I will attending the ENISA/EC3 workshop in The Hague this autumn, I got an invitation to a preparatory survey which asks questions about a consensus regarding taxonomies and information sharing formats to be used in CERT/CERT and CERT/LE information sharing. > > IntelMQ is based on eCSIRT II, which some working-group in the ENISA/EC3/EMPACT universe has declared to be obsolete. > > See this monster of a report: > https://www.enisa.europa.eu/publications/information-sharing-and-common-tax… > > Their new shiny pony is based on the work of CERT.pt, and they want to to use the meeting this year to finalize that decision. I have no clue how big the delta to eCSIRT II is. > > IMHO the IntelMQ community has to decide how to react. E.g. > > a) stay with eCSIRT II framework > b) adopt the new one > > and > > what stance to take on an inter-organisational sharing mechanism. > > So what do you all think? > > otmar (who will be on vacation the next weeks, don't expect me to reply > soon) > > ------------------ > > The survey asks: > > Do you believe that the Common Taxonomy for the national network of CSIRT/LEA (formerly known as CERT.PT Taxonomy) is suitable for CSIRT/LEA communication? > > Yes / No / Other > > Have you ever used one of the following? > > STIX / CybOX / Other sharing Mechanism > > What do you think could be a suitable sharing mechanism for the Common Taxonomy for the national network of CSIRT/LEA? > > STIX / CybOX / Other sharing Mechanism > > Extract from 'Report on Information Sharing and Common Taxonomies between CSIRTs and Law Enforcement Agencies' > > A clear distinction should be made between a taxonomy, a sharing mechanism and a sharing platform to avoid any possible confusion. While a taxonomy is a way of describing information through classification, a sharing mechanism structures the way the information is encoded. For example, a sharing mechanism might provide rules for names and positions of XML tags to allow a file to be treated automatically. Finally, a sharing platform is a tool allowing to share information. It is not mandatory to have such a platform ? files containing information structured according to a standard and classified according to a taxonomy could simply be sent by e-mail, for example. Nevertheless, the use of a sharing platform allows users to easily share information in a structured way. > > > -- > // Otmar Lendl <lendl(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 > > > ---------------------------------------------------- > If you have received this transmission in error please > notify us immediately by return e-mail and delete all > copies. If this e-mail or any attachments have been sent > to you in error, that error does not constitute waiver > of any confidentiality, privilege or copyright in respect > of information in the e-mail or attachments. > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Intelmq-dev mailing list > Intelmq-dev(a)lists.cert.at > http://lists.cert.at/cgi-bin/mailman/listinfo/intelmq-dev > > > ------------------------------ > > End of Intelmq-dev Digest, Vol 6, Issue 2 > *****************************************

1 0

heads up - breaking changes to harmonization.conf
by L. Aaron Kaplan 09 Aug '16

09 Aug '16

Hi, Pull request #634 (https://github.com/certtools/intelmq/pull/634 ) will include some changes to the harmonisation.conf file. There was a previous discussion that some of the values (varchar(2000) in most cases) were arbitrary and sometimes even not long enough. Sebix changed a lot to the postgresql "text" type and in the course of doing so, cleaned up the regular expressions and definitions of fields in harmonisation.conf. Please have a thorough look at PR #634 before I merge it in. If there are any concerns, please let us know by the end of this week if possible. Thanks! a.

1 0

Re: [Intelmq-dev] Taxonomies & Sharing mechanism [SEC=UNCLASSIFIED]
by Clark, Andrew 08 Aug '16

08 Aug '16

UNCLASSIFIED Hi Otmar, I have never really investigated what's out there in terms of taxonomies, to any great extent. We use MISP, and if you haven't seen it, take a look at how many taxonomies they've tried to accommodate: https://github.com/MISP/misp-taxonomies/ If I'm reading the correct things, I suspect we might be lucky because the CERT.pt taxonomy looks very similar to the eCSIRT taxonomy used by IntelMQ (and supported by MISP). The CERT.pt taxonomy (from this site: http://www.cncs.gov.pt/cert-pt-2/documents-2/) includes 18 "incident types" and 10 "incident classes". The ClassificationType class from IntelMQ supports 20 values, including the 18 from the CERT.pt taxonomy, plus "unknown" and "blocklist". Based on this, I don't think there is a good reason to change what IntelMQ uses now. Regarding STIX and Cybox (and TAXII), here at CERT Australia we are using them heavily. STIX includes a 'TTP' object which can be associated with Indicators. TTPs include 'behaviours' and while STIX supports the CAPEC (capec.mitre.org) taxonomy natively, it would be easy to extend to support arbitrary taxonomies. Hope you're enjoying your vacation! Andrew -----Original Message----- From: Intelmq-dev [mailto:intelmq-dev-bounces@lists.cert.at] On Behalf Of Otmar Lendl Sent: Saturday, 6 August 2016 2:07 AM To: intelmq-dev(a)lists.cert.at Subject: [Intelmq-dev] Taxonomies & Sharing mechanism Folks, as I will attending the ENISA/EC3 workshop in The Hague this autumn, I got an invitation to a preparatory survey which asks questions about a consensus regarding taxonomies and information sharing formats to be used in CERT/CERT and CERT/LE information sharing. IntelMQ is based on eCSIRT II, which some working-group in the ENISA/EC3/EMPACT universe has declared to be obsolete. See this monster of a report: https://www.enisa.europa.eu/publications/information-sharing-and-common-tax… Their new shiny pony is based on the work of CERT.pt, and they want to to use the meeting this year to finalize that decision. I have no clue how big the delta to eCSIRT II is. IMHO the IntelMQ community has to decide how to react. E.g. a) stay with eCSIRT II framework b) adopt the new one and what stance to take on an inter-organisational sharing mechanism. So what do you all think? otmar (who will be on vacation the next weeks, don't expect me to reply soon) ------------------ The survey asks: Do you believe that the Common Taxonomy for the national network of CSIRT/LEA (formerly known as CERT.PT Taxonomy) is suitable for CSIRT/LEA communication? Yes / No / Other Have you ever used one of the following? STIX / CybOX / Other sharing Mechanism What do you think could be a suitable sharing mechanism for the Common Taxonomy for the national network of CSIRT/LEA? STIX / CybOX / Other sharing Mechanism Extract from 'Report on Information Sharing and Common Taxonomies between CSIRTs and Law Enforcement Agencies' A clear distinction should be made between a taxonomy, a sharing mechanism and a sharing platform to avoid any possible confusion. While a taxonomy is a way of describing information through classification, a sharing mechanism structures the way the information is encoded. For example, a sharing mechanism might provide rules for names and positions of XML tags to allow a file to be treated automatically. Finally, a sharing platform is a tool allowing to share information. It is not mandatory to have such a platform – files containing information structured according to a standard and classified according to a taxonomy could simply be sent by e-mail, for example. Nevertheless, the use of a sharing platform allows users to easily share information in a structured way. -- // Otmar Lendl <lendl(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 ---------------------------------------------------- If you have received this transmission in error please notify us immediately by return e-mail and delete all copies. If this e-mail or any attachments have been sent to you in error, that error does not constitute waiver of any confidentiality, privilege or copyright in respect of information in the e-mail or attachments.

1 0

Taxonomies & Sharing mechanism
by Otmar Lendl 05 Aug '16

05 Aug '16

Folks, as I will attending the ENISA/EC3 workshop in The Hague this autumn, I got an invitation to a preparatory survey which asks questions about a consensus regarding taxonomies and information sharing formats to be used in CERT/CERT and CERT/LE information sharing. IntelMQ is based on eCSIRT II, which some working-group in the ENISA/EC3/EMPACT universe has declared to be obsolete. See this monster of a report: https://www.enisa.europa.eu/publications/information-sharing-and-common-tax… Their new shiny pony is based on the work of CERT.pt, and they want to to use the meeting this year to finalize that decision. I have no clue how big the delta to eCSIRT II is. IMHO the IntelMQ community has to decide how to react. E.g. a) stay with eCSIRT II framework b) adopt the new one and what stance to take on an inter-organisational sharing mechanism. So what do you all think? otmar (who will be on vacation the next weeks, don't expect me to reply soon) ------------------ The survey asks: Do you believe that the Common Taxonomy for the national network of CSIRT/LEA (formerly known as CERT.PT Taxonomy) is suitable for CSIRT/LEA communication? Yes / No / Other Have you ever used one of the following? STIX / CybOX / Other sharing Mechanism What do you think could be a suitable sharing mechanism for the Common Taxonomy for the national network of CSIRT/LEA? STIX / CybOX / Other sharing Mechanism Extract from 'Report on Information Sharing and Common Taxonomies between CSIRTs and Law Enforcement Agencies' A clear distinction should be made between a taxonomy, a sharing mechanism and a sharing platform to avoid any possible confusion. While a taxonomy is a way of describing information through classification, a sharing mechanism structures the way the information is encoded. For example, a sharing mechanism might provide rules for names and positions of XML tags to allow a file to be treated automatically. Finally, a sharing platform is a tool allowing to share information. It is not mandatory to have such a platform – files containing information structured according to a standard and classified according to a taxonomy could simply be sent by e-mail, for example. Nevertheless, the use of a sharing platform allows users to easily share information in a structured way. -- // Otmar Lendl <lendl(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

1 0

Reports larger than 500 MB in IntelMQ
by Dustin Demuth 29 Jul '16

29 Jul '16

Dear all, currently we are facing the problem, that IntelMQ is not capable of handling large reports ( > 500 MB) when using Redis as a Message Queuing System. First we thought this might get fixed in most recent redis versions (see: [1]), but apparently this is not the case. Are you aware of setups of IntelMQ which use a different backend, like ZMQ? Do you know of performance or other issues which occurred when using other Queuing Systems? [1] https://github.com/certtools/intelmq/issues/547 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

4 9

another naming update
by L. Aaron Kaplan 29 Jul '16

29 Jul '16

Hi *, if you are using the shadowserver parsers , especially the mDNS parser, please be aware that the feed name changed. "Open-m DNS" to "Open-mDNS" See: https://github.com/certtools/intelmq/issues/624 Please adapt your runtime.conf accordingly. Best, a.

1 0

Changes in harmonization implementation
by Sebastian Wagner 29 Jul '16

29 Jul '16

Dear contributors and beta-testers, We recently changed did some changes in the implementation of the harmonization. The type MalwareName has been removed, it was just a duplicate of String. This may break your existing installation if you do not update your harmonization.conf with upstream. It has been used as type for malware.name The type LowercaseString has been introduced, doing a conversion to lower case chars automatically. Applied to protocol names, emails, hashes and UUIDs etc. FQDNs are now lower case only too. Some restrictive regexes have been made more tolerant (e.g. malware names) misp_uuid is now misp.event_uuid misp.attribute_uuid introduced new iregex-type check available (case-insenstitive regex-check) allowed values for protocol.transport is a defined list Also: Currently, both ASCII and IDN-domains are allowed, this will be changed too (including automatic conversion): https://github.com/certtools/intelmq/issues/622 When pulling from our upstream-repository, make sure you also update your harmonization.conf Related commits: https://github.com/certtools/intelmq/commit/6624bdda04ca0595799150e97e719a5… https://github.com/certtools/intelmq/commit/640e1a771acb4ddb9cbd726e51ae903… https://github.com/certtools/intelmq/commit/fd81f0fd9c86ffa0ac3764adafc74e7… https://github.com/certtools/intelmq/commit/7dbed4bc8f9200d06dae2018850341a… https://github.com/certtools/intelmq/commit/6b8b759293069afc3d9f0f1cdf8e4ea… https://github.com/certtools/intelmq/commit/d7892bcb59ac54218c5c45630226d4a… https://github.com/certtools/intelmq/commit/6584ab72fa408732c02abc1c934637a… https://github.com/certtools/intelmq/commit/a742c034c80249e80d2f280fd0dc8a7… 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

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

IntelMQ-dev