Now another way that we can move some way to securing our system is
we have to use password‑based authentication,
is to lock failed login attempts.
So we can go through and read our man page for the pam_tally2 module,
but essentially, it's going to tell us to edit the common authentication file.
And we can go through and add in a line where we can run our tally module,
count the login attempts that have failed.
We can allow three login attempts, after which we deny,
and we can set then our unlock time to be 300 seconds.
So an account will automatically become unlocked again after 5 minutes.
Whilst these slides are terribly exciting,
it's also exciting to get out on the command line
and take a look at this in action.
So we're going to be able to start using PAM to lock our failed login
attempts using the pam_tally2 module and the common‑auth file and see
where this all fits into our security model.
So come on, let's go through and find ourselves this glorious command line.
Now you can see that we're working at the command line.
We need to make sure that we've got another account that we can use.
We saw previously that we had an Ubuntu account,
and I can go and make sure that we know what the
password is for that Ubuntu account.
So let's go through and set that password.
Even if you have to create a new account for this,
it doesn't really matter,
but make sure there is another account that you can
use password‑based authentication.
Having said that, let's just check that I can log in as that user.
So su and ‑ ubuntu will give me a full login shell,
and we can see then from the prompt that we are the
Ubuntu user on the Ubuntu host.
So all of this then is working as expected,
of course, if we put the correct password in.
But we want to also stop people trying to guess passwords,
so locking out accounts where there are multiple attempts with
a wrong password might be the way to go.
We can go through and look at the man page for PAM modules as well.
So if we want to use the pam_tally2 module,
we can hit the big Enter key to look at the manual page,
and we're going to be able to see the details of both how this operates and
then some of the options and examples that we can use.
If we move towards the bottom of the screen,
we're going to be able to see some examples.
And we can see on the screen a possible example there,
but let's go through and look at how this implements in practice on our system.
So if I go through and edit the /etc/pam.d directory,
and then look at our common‑auth, so common being shared,
auth being the authentication events,
so we want to look at where people are authenticating with a wrong password,
and we can start counting this information.
Now although the documentation is good, we do have a manual page,
and we can see it's very hard to see which lines are set
and which lines are just comments.
So let's go through now and just look at how we can use our stream editor,
some of these powerful command line tools that we've got,
to do an in‑place edit.
A ‑E is an enhanced regular expression, so I can group items together,
and we can go through and search for lines that begin with,
and this is where my group comes in, a comment or is an empty line,
so it begins with a comment or the empty line,
end of line marker,
and we want to then run the command d to delete those
lines from then my common‑auth file.
So now as I go through and edit it, we're only seeing the effective lines.
Now the first line is checking our password.
The success=1 means that if our password is okay,
we don't then trigger pam_deny.
Pam_deny is set to requisite, so if that fails,
everything else stops, so we don't move on then to the permit.
But if I go through now and change this to required,
because we don't want things to stop if we've got the wrong password,
but we need to count the wrong passwords.
So I'm going to add in a new line after we've done our
password check but before our deny.
Again, it's going to be an authentication event.
We can put this to be required.
We can align this with the others.
It doesn't really need to be aligned,
but it will read perhaps more tidily using the pam_tally2.so,
shared module, and we can then go through and start putting options.
We can see often they don't take options,
but we certainly need to provide options of how the
module is going to count them.
So we're going to allow three failed login attempts.
After those three failed login attempts,
we're going to lock the accounts for 300 seconds,
or 5 minutes.
That's all that we need to do.
There are other options we can use, but they are documented within the man page.
We don't need to restart any of our services, this is effective now.
So if I go through now and try and log in as Ubuntu with the wrong password,
so the authentication failure is coming from the pam_deny module,
and as you can see then we've done it twice,
our third time.
Our third time now will have locked out the account.
So if I try and do it the fourth time, I put in the password,
we can see now that we get our locked due to 4 failed login attempts,
because it's counted the current one as a failure as well,
and then we get our authentication failure.
So our account now cannot be used, even if I put the correct password in,
for another 300 seconds.
So we're protecting our system against users trying to guess other user's password or to script logins.