MISP/Support

The ultimate support channel for all things MISP. Please come prepared. Bring log files and turn off SELinux. Please contribute your new knowledge to https://github.com/MISP/misp-book/tree/master/faq Error logs: /var/www/MISP/app/tmp/logs/error.log

Andras Iklody

@iglocska

/var/www/MISP/.git is not readable by the apache user

chown -R www-data:www-data /var/www/MISP/.git should solve that

for the $id vs $scope issue, that should be fixed if you pull a newer version

Rainer Ginsberg

@cudor

I'm on version 2.4.115

Andras Iklody

@iglocska

or not, looking at the code

it didn't change since 115, just functions added before that

hmph

could you paste the line that you've modified?

Rainer Ginsberg

@cudor

/var/www/MISPand all its subdirectories and files (including .git) are owned by www-data.

Andras Iklody

@iglocska

hmph that is weird.

basically what generates that message

is that we encode the version in the sync - we fetch that information via git

and it cannot read it for some reason

Rainer Ginsberg

@cudor

ginsber@forest-green:~$ sudo -u www-data diff /var/www/MISP/app/Console/Command/ServerShell.php /var/www/MISP/app/Console/Command/ServerShell.php.orig
198c198

< 'job_input' => 'Server: ' .$scope,

                'job_input' => 'Server: ' . $id,

Oops, the formatting above looks bad. Sorry.

Andras Iklody

@iglocska

indeed good find

I'll push a fic

fix

cbboggs

@cbboggs

with warning lists, I know via the api you can enforce them so that a matching attribute is not added, correct? What if we wanted to soft-enforce, i.e. still add the attribute but don't allow it to be marked for IDS, is that possible currently?

Cle Opatre

@cle_opatre_twitter

Hi there ! Learning and discovering MISP everyday.. Nice work guys :D
I'm not sure to perfectly understand one point of the synchronisation through sync users and would like to clarify it.
Is it right to summarize it as a "One Way synchronisation" ?

Let's say OrgA.InstanceA wants to sync with OrgB.InstanceB. Next step will be to add a sync user in OrgA.InstanceA, give the AuthKey to OrgB.InstanceB who will then be able to set up the permissions and precisely know what events will be pulled/pushed.

OrgB.InstanceB will then be able to control precisely what's exported to OrgA.InstanceA, but not the opposite.

OrgA.InstanceA will have no control of the events exchanged with OrgB.InstanceB

What should I do, as OrgA.InstanceA to control the events possibly pullable by OrgB.InstanceB ?

Cle Opatre

@cle_opatre_twitter

Ok, i think I was right ( but would appreciate an external confirmation?)
And the best solution to this case, is to have a sync user per side and each side will be able to control precisely what should be push/pull to the other instance

Kevin Holvoet

@digihash

Not that I know of, could you ping your contact at Crowdstrike and ask them if they have something on their side? I know they were looking into integration a while ago

@iglocska I already did that and I'm waiting for a reply. We'll see if they have anything.

cbboggs

@cbboggs

@cle_opatre_twitter yes technically with only one sync user it's kind of one way, as only the originating org of that sync user can push/pull from OrgA. I'm not aware right now of any way to prevent the sync user from creating specific events

cbboggs

@cbboggs

and off the top of my head I'm not recalling any way for OrgA to limit what OrgB can pull with that sync user, outside of normal distribution settings/publishing, etc.

the filtering and what not is on OrgBs side, in the remote "Server" config page, where you can filter what events are pulled via the sync user, as you stated.

it's something we've wrestled with as well because we use MISP in a somewhat non-standard way.

Stefano Ortolani

@ostefano

I am noticing weird behaviors when deleting events with a non-neligible number of attributes (between 500 and 1000)

mass-deleting attributes seem to stall the application, leading to lots of

2019-12-09 14:30:39 Error: [PDOException] SQLSTATE[40001]: Serialization failure: 1213 Deadlock found when trying to get lock; try restarting transaction
Request URL: /attributes/deleteSelected/45
Stack Trace:
#0 /opt/misp/app/Lib/cakephp/lib/Cake/Model/Datasource/DboSource.php(502): PDOStatement->execute(Array)
#1 /opt/misp/app/Lib/cakephp/lib/Cake/Model/Datasource/DboSource.php(468): DboSource->_execute('UPDATE `misp`.`...', Array)
#2 /opt/misp/app/Lib/cakephp/lib/Cake/Model/Datasource/Database/Mysql.php(425): DboSource->execute('UPDATE `misp`.`...')

in the logs

is this is a known issue?

Trey Darley

@certbe-trey

Is there a way (either via PyMISP or the REST API directly) to get an attributes tags (ideally clearly differentiated between global and local tags)? It's crystal clear how to SQL that, but direct SQL would be uuuugly.

Trey Darley

@certbe-trey

Ah, if I do attr_ = misp.get_attribute(attribute='5dee1228-cc28-425a-b29a-4b640a3b4631', pythonify=True) then I can access global tags via attr_.tags. But there does not currently appear to be a mechanism for querying the local tags applied to an attribute.

Andurin

@andurin

@certbe-trey I could imagine from the attribute point of view of that particular misp instance there is no clear difference between global and local tags. But maybe you can find the misp-instance related tag lists in one of the misp.? objects. It might be, haven't tried by myself, that's there a list of available tags and maybe there you may find different lists between global|local

Andurin

@andurin

hm... drop my guess. A Tag is a Tag and itself not defined as global or local.

The difference should be f.e. at attribute level.

Trey Darley

@certbe-trey

@andurin Not the case. Via the UI there is a clear distinction made between local and global attribute tags.

Andurin

@andurin

@certbe-trey Did you already export the misp event from the ui to examine that json blob? Just to ensure there is no difference between pymisp api and ui?

Trey Darley

@certbe-trey

@andurin Yup, of course.

Andurin

@andurin

let me guess - no differences between local and global

Andurin

@andurin

@certbe-trey Feels like a bug that local tags won't be honored as it regarding the api.

Trey Darley

@certbe-trey

@andurin In fact, there's no info whatsoever about attribute tags represented within the event json. Nevertheless, in the UI local and global attribute tags are rendered via Javascript. If I look at a specific attribute's json representation (a la /attributes/view/123456.json), I can see global tags but not local tags.

{"Attribute":{"id":"123456","event_id":"78910","object_id":"0","object_relation":null,"category":"Network activity","type":"domain","to_ids":true,"uuid":"5dee1228-cc28-425a-b29a-4b640a3b4631","timestamp":"1575979604","distribution":"5","sharing_group_id":"0","comment":"","deleted":false,"disable_correlation":false,"value":"evil.be","event_uuid":"5dee1217-87a8-4fa6-bd8c-4b610a3b4631","Tag":[{"id":"17","name":"tlp:white","colour":"#ffffff","numerical_value":null}]}}

@andurin Yup, definitely looks like a bug. Time to go spelunking...

hammieee

@hammieee

Hi, I would like to know is there any guides on how to integrate Kafka into MISP?
I have follow the instruction here to install what is required Link
On MISP I have pointed it to the Kafka "server", enable some settings with a few topics for testing. When I clicked on Publish to Kafka, it doesn't show any error and says publish succefully.

On my Kafka "server", I am running this command in my terminal ./bin/kafka-console-consumer.sh --bootstrap-server 192.168.235.137:9092 --topic misp_event --from-beginning

Am I doing anything wrong here? Please guide me 🥺🥺🥺

Andras Iklody

@iglocska

@andurin Yup, definitely looks like a bug. Time to go spelunking...

should now be fixed

Trey Darley

@certbe-trey

@iglocska Woo-hoo, it's fixed! Thanks a mil for the super quick turnaround on that one, buddy! ^_^

Andras Iklody

@iglocska

no worries ;)

Rémi Séguy

@remg427

Hi i have a question related to caching

Andras Iklody

@iglocska

sure, shoot

Rémi Séguy

@remg427

I have 2 MISP instances A and B

on A events from B are cached. When there is a correlation it appears next to the attribute. As admin i can follow the link. My colleagues have just A:event if witbout link no permissions

Do i miss something in roles or server settings so analysts can explore the cached events?

Where communities thrive

People

Repo info

Activity

< 'job_input' => 'Server: ' .$scope,