Tuesday, September 05, 2006

Anton Security Tip of the Day #3: Watch for Failures and Successes

Following the new tradition of posting a security tip of the week (mentioned here, here ; SANS jumped in as well), I decided to follow along and join the initiative. One of the bloggers called it "pay it forward" to the community.

So, Anton Security Tip of the Day #3: Watch For Access Failures AND Successes in Logs

Now, many a winter ago :-), people used to think that checking for access failures in logs is all they need to do to "stay secure." Indeed, picking out failured access attempts seemed like a reasonable way of doing things. Similarly, people even considered firewall "connection denied" messages as more important than "connection allowed" log records (although this will be a subject of a separate tip - a whole paper, in fact - later)

So, what is more important? This

Sep 26 12:36:40 bridge sshd(pam_unix)[2128]: session opened for user anton by (uid=0)

or this:

Sep 25 14:31:24 ns1 sshd[19308]: Failed password for anton from 10.10.154.44 port 53452 ssh2

Let's think about it: one log entry says that Unix security is doing its job and blocking a bad user (assuming no fat fingering and forgotten passwords for simplicity sake) from accessing the system, the other says that some kind of user now has access to your system.

To quote Doc from "Back to the Future" :-) : "Exactly!!!"

You do need to be aware of both; you can't just focus on access failures while monitoring your logs. Make sure you review successes as well. And, yes, certain patterns, like a long string of failures followed by a success are even more fun to watch ...

Also, here is a link to my previous tips of the appropriate-time-interval (#1) :-)

Also, I am tagging all the tips on my del.icio.us feed. Here is the link: All Security Tips of the Day.

tags: , , , ,

1 comment:

Anonymous said...

*WILD APPLAUSE*

Thank you for saying this. I'm getting tired of arguing with people who think I ought to be happy just looking at reports of failed logins. Your security incidents will look exactly like successful logins, for crying out loud.

Let's say you do find a long list of failed login attempts for a long series of user IDs, making you suspect that someone is trying to brute-force a password. What's the next thing you'll want to know?

Did any of them succeed?

You need ALL the log data to get a real picture of what's going on.

Dr Anton Chuvakin