thinkst / opencanary

Modular and decentralised honeypot

Home Page:http://opencanary.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Opencanary send out alarms days after event

hagen-bauer-regioit opened this issue · comments

Hi to all,

we are using this great piece of software and in general the system behaves as expected. We do get immediate alarms if a configured service gets accessed.

We now have an event were the firewall logged an event in kern.log but the canary logged this event days later.

We do not have a direct monitoring for opencanary but we do monitor the honeypod ports and they have not shown any downtime.

Any Idea why it took opencanary more then 5 days to report an event in kern.log?

Hi @hagen-bauer-regioit

Thanks for writing in. Our response is inline below:

we are using this great piece of software and in general the system behaves as expected. We do get immediate alarms if a configured service gets accessed.

We are happy to hear it is working for you.

We now have an event were the firewall logged an event in kern.log but the canary logged this event days later.
We do not have a direct monitoring for opencanary but we do monitor the honeypod ports and they have not shown any downtime.
Any Idea why it took opencanary more then 5 days to report an event in kern.log?

Sorry for the drop here. FWIW, our team is not aware of such cases (and its unexpected to us too).

If you send us the raw log files, we will happily try to debug this further with you. (You can mask out sensitive data if you need to).
If you prefer you can also send the files to our support mail support@canary.tools quoting this GitHub issue and we will look into it.

Regards

I am not sure wich type of logs would help here. Firewall logs are good and there is no error in opencanary log. everythings looks good except the timeframe between "log writing" and "log evaluation/alarm"

From my very highlevel programming know how I am guessing that the "FileSystemWatcher" module has missed the changes in the kern.log

Thanks for reporting, we've noted it internally and will keep an eye out for future occurrences. For now, we are closing this (as there's insufficient information to reproduce or analyse).

Our internal ticket number is T6266