Wandering Thoughts archives

2012-09-05

Some thoughts on logging failed login attempts (for existing users)

When I wrote my entry on logging all successful user authentications I thought that I had strong heretical views on logging failed authentications for existing users. Since thinking more about it, I have backed off on that a bit so this is somewhat more ambivalent than I was expecting.

(I've written before about why you should basically never log nonexistent user names for bad authentication attempts. The issue here is whether you should log failed authentications for usernames that do exist.)

The web app world these days has the concept of 'actionable data'; this is something that you measure where you will actually take action based on what you see. Actionable data drive actions; non-actionable data just create pretty graphs that you can distract yourself with. We can extend this concept to system administration, so the question you should ask yourself about logging failed authentication attempts is 'how actionable is this?'

In some environments, the answer is 'very actionable'; you will use the logging data to drive various anti-intrusion systems (often automated ones), to set off alerts, and so on. Many environments are very much the reverse; you'll never really do anything with this information except let it accumulate to a file and perhaps later search it to see if a successful intruder probably did some door-rattling before hand. In the middle are environments where you will periodically use the failed authentication to troubleshoot problems your users are having (so you can say, eg, 'we saw you fail to authenticate; are you sure the password is set right in your app?').

How actionable information about failed authentications is tells you how important logging them is. In particular if it's not actionable at all, tracking failed authentications is just a distraction; you can log them if you really want to, but you should put them in a place where they will not get in the way of more important messages.

My cynical view is that many developers over-estimate the importance and actionability of failed authentications. Outside of perhaps troubleshooting user problems once in a while, most sysadmins on the Internet today will never look at failed authentication logs; there are simply too many people rattling your doorknobs to make it worthwhile to pay attention to them.

Sidebar: what I'd like developers to do on Unix

I will assume that you've written your program to log to syslog. If so, provide an option to log authentication failures at priority DEBUG instead of priority INFO.

If you think that you should log authentication failures at any priority higher than INFO, you are wrong (unless you are writing software for a very specialized environment). There is only one sort of bad authentication that should be logged on any urgent basis, and that is 'the authenticator was right but local policy doesn't allow this to happen'. For example, 'someone used the right root password over SSH but we don't allow remote logins to root' or 'attempt to become root with the right password but from someone who is not in group wheel'.

sysadmin/OnLoggingBadLogins written at 00:25:13; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.