There might be a problem in the Elastic query in greedybear/cronjobs/base.py:
q = Q(
"bool",
should=[
Q("range", timestamp={"gte": gte_date, "lte": "now/m"}),
Q("range", end_time={"gte": gte_date, "lte": "now/m"}),
Q("range", **{"@timestamp": {"gte": gte_date, "lte": "now/m"}}),
],
minimum_should_match=1,
)
Some entries in Elastic have multiple of the fields that are checked, e.g. the entries from Honeytrap. These fields may have different values. It seems like the end_time field uses UTC time while @timestamp uses the local time of the TPot instance. This may lead to Greedybear extracting an entry multiple times, once when UTC time matches the criteria and a second time when the local time matches.
A comment in greedybear/cronjobs/base.py says that this kind of query is necessary due to honeypots have different column for the time. But when I query my TPot instance, it looks like the @timestamp is present for all instances.
{
"query": {
"bool": {
"must_not": {
"exists": {
"field": "@timestamp"
}
}
}
}
}
This query returns no documents on my instance, so all of the 18 active honeypots seem to use the @timestamp field.
There might be a problem in the Elastic query in
greedybear/cronjobs/base.py:Some entries in Elastic have multiple of the fields that are checked, e.g. the entries from Honeytrap. These fields may have different values. It seems like the
end_timefield uses UTC time while@timestampuses the local time of the TPot instance. This may lead to Greedybear extracting an entry multiple times, once when UTC time matches the criteria and a second time when the local time matches.A comment in
greedybear/cronjobs/base.pysays that this kind of query is necessary due to honeypots have different column for the time. But when I query my TPot instance, it looks like the@timestampis present for all instances.This query returns no documents on my instance, so all of the 18 active honeypots seem to use the
@timestampfield.