Get elasticsearch and kibana packages in Kali (for Kali Purple)

Arnaud Rebillout
2024-09-06T11:23:05Z

In short: we want elastic and kibana (aka. defensive stack) in Kali, for Kali Purple.

Right now, procedure it to install it from their repo, documented at: https://www.elastic.co/guide/en/elasticsearch/reference/current/deb.html

We'd like to make it transparent for users to install it in Kali, why not even pre-install it in some other "Kali Purple image" or whatever. So, what about we add those packages in Kali repos, so that it can be installed out of the box?

Let's dive in the topic

Packages

Let's look at what's provided by elastic's APT repositories.

└─# grep '^Package:' artifacts.elastic.co_packages_8.x_apt_dists_stable_main_binary-amd64_Packages | sort -u
Package: apm-server
Package: auditbeat
Package: elastic-agent
Package: elasticsearch
Package: enterprise-search
Package: filebeat
Package: heartbeat-elastic
Package: kibana
Package: logstash
Package: metricbeat
Package: packetbeat

We only want to install the leaf packages elasticsearch and kibana, and it turns out, they don't have any extra dependencies, they are big self-contained blobs, I suppose. EDIT: We might also want logstash.

Looking a bit closely now:

elasticsearch:

https://github.com/elastic/elasticsearch

99% Java

License: https://github.com/elastic/elasticsearch/blob/main/LICENSE.txt

kibana:

https://github.com/elastic/kibana

95% Typescript, 5% Javascript

License: https://github.com/elastic/kibana/blob/main/LICENSE.txt

License considerations

For both packages, License is a bit complicated (SSPL, dual license, apache license but not for all files, etc etc).

Cf. https://www.elastic.co/licensing/elastic-license/faq

How to get those packages in Kali

It seems to me that we could just import those packages at the reprepro level. To recap, we must make sure:

packages can be imported 'as is' (they look self-contained so I suppose it will work)

it's legal to redistribute the packages (still needs to be clarified)

Additionally, there might be some telemetry to disable, like we do for the M$ packages.

Now there's one issue. How will we transition between major versions? Upstream puts major versions under different repositories, and maintain two major versions it seems:

http://artifacts.elastic.co/packages/7.x/apt

http://artifacts.elastic.co/packages/8.x/apt

Therefore migrations from one to the other is done on the behalf of user, who will update their sources.list. The major version is NOT in the package name (ie. pkg name is elasticsearch and it's NOT elasticsearch-8).

If we plan to import those packages in Kali, we must have a plan regarding how we'll handle major version bumps. Not sure we can just upgrade the package to a new major, as there might be complicated database migration, etc etc...

Furthermore, from re4son:

right now we can't use 8.x because a module is missing

updating from 7.x to 8.x just doesn't work (ask re4son for details)

Handling major versions

Rename the .deb

Since packages have no dependencies, maybe it's possible to rename those. So we rename elasticsearch into elasticsearch-7.

But if we don't build it ourselves: can we rename the .deb? Is it possible, or a big no-no? Is there such a functionality in reprepro?

Build pkg by ourself

Otherwise we could try to build those packages by ourself, however upstream doesn't provide src packages, however there is https://github.com/elastic/elasticsearch/tree/main/distribution from where we can maybe build source packages. But there's no equivalent for kibana.

Overall: we could give it a try, but personally I'd prefer to just redistribute their binary (modern open-source is just a binary blob, live with it...), and then I'll save myself a lot of time I'm sure.

Metapackage?

I wonder if it would work to have a metapackage elasticsearch-8 that Depends on elasticsearch (>= 8 && < 9), so that when we do a major upgrade, the package itself doesn't upgrade. Overall: I don't think it's a great idea, too hacky and too fragile.