I’ve encountered push back when installing some of these tools by default, on security grounds.
Do you have any thoughts on whether these tools significantly increase risk at all? I can see an argument that some of the ebpf tools might do?
I’m interested to hear what people have to say about this. Having worked in systems administration for a long time I’ve experienced the full range of opinions/philosophies/policies from “install everything you might need” to “install nothing but what is exactly precisely required by the services”.
I’ve also heard, more than once, recently something like “eBPF is exactly the rootkit I’ve always wanted!” when describing the sheer power and flexibility of eBPF both in the hands of the red team and the blue team.
There are basically 2 kinds of eBPF: a mostly read-only variant where you can observe various parts of a system (this is the one I mostly use, and is very very useful, essential I’d say).
But there is also a variant where you can modify the running system (of course you already need to be root to do this). See https://infocondb.org/con/black-hat/black-hat-usa-2021/with-friends-like-ebpf-who-needs-enemies
However having the tools present or not has no impact on security: you could compile it yourself on the machine, use a statically linked binary, or use some other attack to gain execution privileges. At the point where someone else got root you’ve already lost, they can do pretty much anything (ignoring SELinux…)
There are of course exceptions to just installing everything, e.g. a tool could be setuid root, in which case its mere presence may open up a security hole that was not there before.
I absolutely agree with everything you’ve said here, but am also interested in how much variance there is in the landscape of other opinions.
For example, I’ve heard the counterpoint to
having the tools present or not has no impact on security
as something roughly along the lines of “forcing the adversary to do more gives them more opportunity to generate signals before the succeed at their goal and also requires them to make a larger and more forensically data rich footprint”
That might be a valid argument if you are running tripwire or mtree everywhere so something is able to spot and report these signals.
On the other hand, in many years of ops I have never had to deal with a compromised server but I have had to do debugging and performance analysis in production.
Copied from the article’s own disqus comments…
I’m interested to hear what people have to say about this. Having worked in systems administration for a long time I’ve experienced the full range of opinions/philosophies/policies from “install everything you might need” to “install nothing but what is exactly precisely required by the services”.
I’ve also heard, more than once, recently something like “eBPF is exactly the rootkit I’ve always wanted!” when describing the sheer power and flexibility of eBPF both in the hands of the red team and the blue team.
There are basically 2 kinds of eBPF: a mostly read-only variant where you can observe various parts of a system (this is the one I mostly use, and is very very useful, essential I’d say). But there is also a variant where you can modify the running system (of course you already need to be root to do this). See https://infocondb.org/con/black-hat/black-hat-usa-2021/with-friends-like-ebpf-who-needs-enemies
However having the tools present or not has no impact on security: you could compile it yourself on the machine, use a statically linked binary, or use some other attack to gain execution privileges. At the point where someone else got root you’ve already lost, they can do pretty much anything (ignoring SELinux…)
There are of course exceptions to just installing everything, e.g. a tool could be setuid root, in which case its mere presence may open up a security hole that was not there before.
I absolutely agree with everything you’ve said here, but am also interested in how much variance there is in the landscape of other opinions.
For example, I’ve heard the counterpoint to
as something roughly along the lines of “forcing the adversary to do more gives them more opportunity to generate signals before the succeed at their goal and also requires them to make a larger and more forensically data rich footprint”
That might be a valid argument if you are running tripwire or mtree everywhere so something is able to spot and report these signals.
On the other hand, in many years of ops I have never had to deal with a compromised server but I have had to do debugging and performance analysis in production.