Hacker News Reader

Comment by chmod775 | Hacker News Reader

Ship them off to where? A system that also can be accessed with your ssh key?

If not, can an attacker gain access to your email server or DNS with your ssh key? If either is true, they now have access to everything not protected by 2FA that uses an email address they now control.

There's so many things to get right.

You can design a system such that there's a very high likelyhood even a nation-state attacker won't be able to intrude without leaving traces - if you make no mistakes.

Or you know, you could also just rotate your ssh keys in addition to everything else. "I have logs" is really no excuse to forego something that is this easy.

View on HN

> Ship them off to where? A system that also can be accessed with your ssh key?

If the ssh key you lost has access to all the critical infrastructure, then, certainly you have a problem. The solution is to not give away write-access keys to your entire system.

> If either is true, they now have access to everything not protected by 2FA that uses an email address they now control.

The initial question was not whether losing a key would cause a breach, but whether a detection mechanism is reliable.

> Or you know, you could also just rotate your ssh keys in addition to everything else.

The question is how does it help? If you can't detect a breach, it will live for as long as your key rotation policy, if not longer. If you can detect and mitigate a breach, it will be closed quickly regardless of your rotation policy.

I've not seen an enterprise environment where "ordinary" sysadmins also have access to the log hosts. Must be extremely rare setup in a healthy environment. Likewise selldom to see "logging staff" to actually login to a shell. Logs naturally aggregates to some kind of a service with visualizations, alerting and filtering capabilities.

In those special cases an "extraordinary" sysadmin gets onboard a log host, it is not through the ordinary access ways, such as SSH from where the other sysadmins play around.

Holy shit you should not have access to your logging systems/DNS servers with the same exact credentials as your main app servers. Do you let devs onto the HR system with the same ssh key as well?

Ship them off to where?

The usual networked logging systems that don't have ssh logins, e.g. syslog into ELK stack.

How do you set up elastic on a server that doesn't run sshd?

For real? console (in various ways/flavours) is one way.

Console. Cloud login. Different VPN connection. Different credential set then other hosts. Using a hosted service from a completely separate provider. Setting up infrastructure from images without external access.

And I'm sure I missed some - there's a thousand ways to do it.

  curl -X "DELETE" http://log-server:9200/logstash-*

Probably works for a large percentage of deployed ELK logging stacks.

Are people not using elastic authentication?

Elasticsearch existed for years without any authentication on its community tier version, with xpack behind a call with a sales rep and a heavy pocketbook. These days, authentication is provided after you enable the free xpack plugin, but it is not enabled by default and their install guide doesn't exactly point it out to you right away. It starts delving into JVM tuning options before it even references there's this xpack thing you may want to look into.

I always just put it behind an authenticating proxy.

Reply on news.ycombinator.com