2

I was arguing with a friend about logs in user logins. I think that logs means a big audit source for IT audit professionals. Why should I log successful log-ins to my server?

It's so important log fail attempts to log because I can realize if some malicious person wants enter to my system using brute force, but why record successful logs?

4 Answers 4

1

There are a few reasons that come to mind. Much of this depends on what your app does. Online banking? You want to log more than a community forum with no sensitive information or monetary value. Business app vs public?

1) IP address the user logged in from. This would provide some information should the account be compromised, and could help track down the offending person.

2) Determine if the user was able to login after failed login attempts. For instance, 9 failed attempts followed by a successful one means something very different than 9 failed and then no successful login.

3) Determine when the user last logged in, for various reasons, including whether they are actively using their account. 5 years since the last login? Not an active user.

4) If this is a business app, then you do want to log whether somebody accessed the application or not. For instance, if we know Bob is out of the country but then access the application, that could indicate something fishy. "Something fishy" will entirely depend on the application and your business.

Those are a few things that come to mind. Personally from my experience, I have used successful logins numerous times to help with internal and external investigations.

1

So you will know who was logged in at the time that a problem started.

1

An audit trail is usually a good idea; more information is generally better.

Let's say you are talking as a remote login to a computer system. An attacker compromises some users' account and then does bad things on the computer, but doesn't gain complete control of the system (e.g., can't forge logs). Let's say they launch a fork bomb which causes the system to freeze. In those situations, you may want to eventually check the logs and see which account had recently logged in before the fork bomb to identify the user, so you can notify the user of their compromised account. (I'd still recommend everyone all accounts change passwords when you nuke from orbit and rebuild the system from a safe backup).

Or maybe this is some sort of web-application. A user notices suspicious activity on their account -- something changed they don't really remember changing. A log of recent activity could be very convenient; especially with timestamps, IP addresses, etc.

Linux/Unix systems typically give you a message on remote login like:

~>$ ssh some_system
Last login: Thu Sep  5 11:54:59 2013 from 123.123.231.321
#

informing you of the last time you logged into the system and where it was from. This can quickly alert a user when their account has been inappropriately accessed. (Granted the first thing most attackers would do is change the password; but then an administrator who can still access the system could use lastlog to get the same information.)

1

You want to do this for several reasons, first of all make sure all logs are stored remotely on a server to which the server can only write to (like syslog).

  • Succesful logins on critical services need to be accounted for, why did someone log in?
  • What accounts were used to access the machine at what time? Is the person still an employee?
  • Check when people logged, is this time stamp normal?
  • When performing periodic access reviews you can check who logged in when, if a person hasn't logged in for a few weeks/months you should consider revoking his access.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .