2010-07-28 21:37:00
I ran into a rather interesting case the other day, pointing me to another caveat that you need to keep in mind with BoKS. Let me say up front that I understand FoxT's design decision in this case and that, while I don't necessarily agree with them, it isn't a very big problem as long as you know the situation exists. So, what's up?
In BoKS, a "locked" account is not always locked the way you might think it is.
I received a trouble ticket from a friend/colleague of mine, saying that he suspects his application user got locked. He couldn't SU to the user account anymore, getting a message saying it was locked. Either way, his password wasn't getting accepted and he needed to get in!
So, I checked the application user and it was fine! Not locked, no expired password, no problems at all. However, the BoKS logs did show that my friend's account was in fact blocked! Browsing back through the transaction logs I found that his personal account had been locked after he'd entered a wrong password while SU-ing. In the world of BoKS this makes sense: you try to guess your way into another account with SU and your own account gets locked as a punishment. This way you can block the perpetrator, while preventing a DoS (Denial of Service) on the target account.
07/07/10 17:05:50 SERVER-A pts/2 bobby sshd Successful login (ssh shell from 10.72.2.3)
07/07/10 17:05:58 SERVER-A pts/2 bobby su Successful SU from user bobby to oracle
07/08/10 03:48:30 SERVER-A pts/2 bobby sshd Logout
07/08/10 11:02:35 SERVER-B - bobby sshd Bad login (ssh auth from 10.72.2.3). Wrong password.
07/08/10 15:05:13 SERVER-C - bobby sshd Bad login (ssh auth from 10.72.2.3). Authentication failed.
07/08/10 15:05:16 SERVER-C - bobby sshd Bad login (ssh auth from 10.72.2.3). Wrong password.
07/08/10 15:05:19 SERVER-C - bobby sshd Bad login (ssh auth from 10.72.2.3). Wrong password.
07/08/10 15:05:26 SERVER-C - bobby servc Too many failed login retries on SERVER-C
07/08/10 15:05:26 SERVER-C - bobby sshd Bad login (ssh auth from 10.72.2.3). Wrong password.
07/08/10 15:05:30 SERVER-C - bobby sshd Bad login (ssh auth from 10.72.2.3). Too many erroneous login attempts.
07/13/10 08:22:47 SERVER-B pts/1 bobby sshd Successful login (ssh shell from 10.72.2.3)
07/13/10 11:14:15 SERVER-B pts/1 bobby su Access denied by server 10.72.2.3, route SU:bobby@pts/1->oracle@SERVER-B
07/13/10 11:14:15 SERVER-B pts/1 bobby su Bad SU from user bobby to oracle (Too many erroneous login attempts.)
07/14/10 15:52:34 SERVER-B pts/1 bobby sshd Logout
07/15/10 08:12:49 SERVER-B pts/1 bobby sshd Successful login (ssh shell from 10.72.2.3)
07/15/10 10:24:50 SERVER-B pts/2 bobby sshd Successful login (ssh shell from 10.72.2.3)
In the case above, "bobby" locked his account by repeatedly botching his own password on a system where he hadn't installed his SSH keys yet.
So how come my colleague could still login using SSH? Didn't BoKS say his user account was blocked?!
I was flabbergasted! Bobby's account had gotten locked, so certainly he should not be allowed to login anymore, right? Besides, he was getting blocked on his SU and SUEXEC usage! So why could he still login?
After discussing the matter with FoxT tech support I was reminded of the aforementioned design decision regarding DoS attacks: FoxT doesn't want you to easily block another person's account by just slamming his password. Which is why they decided that anybody who is allowed to use SSH key pairs should also be allowed to keep logging in despite his "locked" status.
Two very important distinctions:
View or add comments (curr. 0)
All content, with exception of "borrowed" blogpost images, or unless otherwise indicated, is copyright of Tess Sluijter. The character Kilala the cat-demon is copyright of Rumiko Takahashi and used here without permission.