search

dev-sec / ansible-collection-hardening

This Ansible collection provides battle tested hardening for Linux, SSH, nginx, MySQL
http://dev-sec.io/
Apache License 2.0
4.04k stars 731 forks source link

The system must display the date and time of the last successful account logon upon an SSH logon. #362

Closed joubbi closed 3 years ago

joubbi commented 3 years ago

Is your feature request related to a problem? Please describe. Running Lynis against at hardened system finds that PrintLastLog yesis not set in /etc/ssh/sshd_config. I think it's a good idea to set it as part of the ssh hardening.

It is a part of Red Hat Enterprise Linux 7 Security Technical Implementation Guide

Describe the solution you'd like Add PrintLastLog yes in /etc/ssh/sshd_config.

rndmh3ro commented 3 years ago

This is already implemented: https://github.com/dev-sec/ansible-collection-hardening/blob/master/roles/ssh_hardening/templates/opensshd.conf.j2#L237-L239

joubbi commented 3 years ago

@rndmh3ro Why is the default to not show it? It's more secure to show it, so shouldn't it be enabled by default?

rndmh3ro commented 3 years ago

It's more secure to show it, so shouldn't it be enabled by default?

I don't see why it should be more secure to have that enabled. Relying on this as a security measure is not a good idea, because you'd only notice that if you manually login into your server and know when the last time was you logged into the system. Instead there should be either a intrusion detection system or some kind of central logserver that logs all logins.

schurzi commented 3 years ago

Our baseline also specifies a no for this option: https://github.com/dev-sec/ssh-baseline/blob/87d09e055b83265eeb46a93de244635d05af3a05/controls/sshd_spec.rb#L463

joubbi commented 3 years ago

It's more secure to show it, so shouldn't it be enabled by default?

I don't see why it should be more secure to have that enabled. Relying on this as a security measure is not a good idea, because you'd only notice that if you manually login into your server and know when the last time was you logged into the system. Instead there should be either a intrusion detection system or some kind of central logserver that logs all logins.

I see it as defence in depth, not relying on this function only. If I know that I have a jumphost where I'm allowed to SSH from to other hosts, then when I login to a server and notice that the last login was made from an IP address that I recognize as a server in my DMZ, I know that something is going on.

It's not foolproof but it is more secure to have it enabled than not. This is a hardening role supposed to make things more secure...

There is no performance penalty, so I don't see any negative impact having it enabled either.

rndmh3ro commented 3 years ago

You can always just set it in your playbook via a variable.

joubbi commented 3 years ago

Yes I know. I have done that. I was just thinking that the role is supposed to increase security with the default values (as long as the default values doesn't break anything).

On January 6, 2021 7:40:59 AM UTC, Sebastian Gumprich notifications@github.com wrote:

You can always just set it in your playbook via a variable.

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/dev-sec/ansible-collection-hardening/issues/362#issuecomment-755139469

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

nodiscc commented 3 years ago

I re-read CIS and STIG guides not so long ago (I think they also recommend setting it to yes), re-read my ssh role, and also started wondering why I had left PrintLastLog to no for such a long time. I don't know the reason for the dev-sec baseline to enforce no. I also advise switching it to yes:

Can this be reopened? What are reasons for setting it to no by default?

rndmh3ro commented 3 years ago

Reasons: https://github.com/dev-sec/ansible-collection-hardening/issues/362#issuecomment-751393530

rndmh3ro commented 3 years ago

If someone opens a pr here and in the baseline I'm willing to merge this. though I still don't think that this provides any security whatsoever.

chicks-net commented 3 years ago

though I still don't think that this provides any security whatsoever.

100% agreed. Doesn't leaking information like this violate some principle? I doubt most people pay any attention to these notices.

rndmh3ro commented 3 years ago

Okay, since I'm not the only one who thinks that this does not help security, let's discuss this some more.

Advantage: what @joubbi said, you might notice some unusual IP in the lastlog when logging in

For me, "might noticing" something is no improvement in security.

If I know that I have a jumphost where I'm allowed to SSH from to other hosts, then when I login to a server and notice that the last login was made from an IP address that I recognize as a server in my DMZ, I know that something is going on.

This isn't a valid reason for me, either. If you have a jump-server that allows to access other servers, than only the jump-server should be allowed to access these other servers. If other servers are allowed, too, how should I know if this access was valid?

joubbi commented 3 years ago

Okay, since I'm not the only one who thinks that this does not help security, let's discuss this some more.

Advantage: what @joubbi said, you might notice some unusual IP in the lastlog when logging in

For me, "might noticing" something is no improvement in security.

I agree that this is not a big improvement in security. I still think that the "might" is better than nothing.

If I know that I have a jumphost where I'm allowed to SSH from to other hosts, then when I login to a server and notice that the last login was made from an IP address that I recognize as a server in my DMZ, I know that something is going on.

This isn't a valid reason for me, either. If you have a jump-server that allows to access other servers, than only the jump-server should be allowed to access these other servers. If other servers are allowed, too, how should I know if this access was valid?

Imagine having 100 production servers and one jump-server that is allowed to do SSH to these 100 servers that you manage. You are the admin of these 101 servers and know the IP address of the jump-server by heart. One day you login on a server and notice that the login text looks a little off. You look more closely and realize that the IP address of the last login is not from the usual IP address of the jump-server. It could be a public IP address in China or whatever. Then you investigate and find out... Whatever you find out is that something is not as it was supposed to.

Again, this is not a big deal. But I don't see the downside of it either. At all. If this hacker from China is able to login on my server with SSH, he/she could just do last -i and get even more information (not mentioning all the other possible things).

aseriesofdarkcaves commented 3 years ago

I agree that in the strictest sense, this message doesn't improve security at all by enabling it by default. All it does is provide information (which isn't security).

The option is there to enable it if required which is perfect.

If you're relying on a login message as a layer of security, it's already too late in my opinion.

nodiscc commented 3 years ago

I agree that displaying the lastlog on login does very little to improve security.

Doesn't leaking information like this violate some principle?

running last already discloses this info, and more.

The option is there to enable it if required which is perfect.

It's very easy to enable, yes.

The reason I'd tend to enable it by default is because users of this role probably expect some form of compliance with hardening guidelines such as STIG and CIS. I rechecked both guides:

If you're relying on a login message as a layer of security

I agree this is a bit far-fetched but providing this information does not decrease security, and provides easy access to audit-related information. It does not replace proper auditing/logging/log forwarding/event analysis measures, but it provides reliable (assuming root is not compromised) information in an obvious manner.

This is really nitpicking, but since a reputable hardening guideline recommends setting it to yes, I'd expect this role to set it to yes

schurzi commented 3 years ago

for me this is an issue of compliance rather than security. If we want to be compliant to an Guide, that mandates/recomends this, we should do it. Currently I don't see this as mandatory.

As to the actual usefulnes, maybe I could see some benefit for small or home lab installations, where no central logging and auditing is in place.

So currently I would say, if someone wants to change it and submits the needed PRs (as @rndmh3ro already said) this would be merged.

rndmh3ro commented 3 years ago

The goal of this collection is not to be compliant but rather to provide security. And to be compliant with CIS there would be much more to do than this issue.

rndmh3ro commented 3 years ago

We won't change this. I see no security benefit. If one wants to be compliant to some benchmark, the person can always just enable it.