"login failed for user ..." appears in event viewer repeatedly

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

KT - 30 Jun 2008 15:32 GMT

Hello.

I have messages in event viewer several times per minute that say "Login
failed for user ....". The errors rotate through all the accounts that I have
setup in SQL.

I need direction in how to determine what is trying to login and how to
correct it. Are these attempts to compromise my system?

Thank you for your help.

KT

Reply to this Message

Sean McCown - 30 Jun 2008 19:52 GMT

It's cycling through all your logins? Are you sure? Because that sounds
pretty serious.
Here's what you do then. You setup a trace and capture everything you can
on the login attempts. You can then see which box these attempts are coming
from. From that box you can now narrow down what's doing this.
The NT security log should also give you some info on these login attempts
as well.
Let me know what happens. This is interesting.

Signature

Watch my free SQL Server Tutorials at:
<a href="http://MidnightDBA.ITBookworm.com"
target="_new">http://MidnightDBA.ITBookworm.com </a>

Read my book reviews at:
http://www.ITBookworm.com

Blog Author of:
Database Underground -- http://weblog.infoworld.com/dbunderground/
DBA Rant – http://dbarant.blogspot.com

> Hello.
>
[quoted text clipped - 8 lines]
>
> KT

Reply to this Message

KT - 30 Jun 2008 20:32 GMT

Hello again.

I have done some more troubleshooting and I could use some additional
guidance.

I used SQL profiler to audit logins and login failures.

What I found is that one offending computer in the network started trying to
login to SQL, about once per second. The accounts tried were sa, admin and
root. One account would be tried for a few minutes, then it would move to
another account. This went on for about 20 minutes, then stopped.

I have an sa account on SQL along with others. I do not have admin or root
accounts set up. It appears that some exploit is coming the that workstation.

Does this sound correct, and how do I troubleshoot this?

Thanks again for your help.

KT

> Hello.
>
[quoted text clipped - 8 lines]
>
> KT

Reply to this Message

Sean McCown - 30 Jun 2008 20:50 GMT

That certainly sounds like a brute force attack to me.
Now you've gotta figure out where it's coming from.

On that computer, you'll wanna find out what's actually running when that
happens. Can you tie it down to a specific user acct? In your profiler
trace does it give you an application name? If so, then you can see where
it's coming from on that box based on that. You can also capture your
sysprocesses table every 5secs or so and save it to a table and search
through it for more information. Now that you have the box isolated you can
do these things.

So that's what I'd do. That code is running from something on that box.
Either an NT-level file or a job, or something, right... so now you have to
find that. See if your profiler trace captured the app name. If so, search
the box for signs of that. If not, then capture sysprocesses every few secs
and see what you come up with there. Between sysprocesses and profiler you
should be able to tie it to a spid and see where this is coming from. Also,
on the offending box, capture a perfmon trace on all the processes in the
process class. Use _Total... this way, you can tie the sysprocesses entries
to the NT entry if it turns out to be a windows file.

Is all this clear?

Signature

Read my book reviews at:
http://www.ITBookworm.com

Blog Author of:
Database Underground -- http://weblog.infoworld.com/dbunderground/
DBA Rant – http://dbarant.blogspot.com

> Hello again.
>
[quoted text clipped - 29 lines]
> >
> > KT

Reply to this Message

KT - 30 Jun 2008 21:10 GMT

Thanks Sean.

Looks like our messages went past each other.

Upon further examination, I found I was mistaken about the computer name the
logins are originating from. The user's name is betty and the computer name
that it is coming from is bettys. Upon further examination, I found that this
isn't her computer name, (it was close) and I do not have a computer with
that name on the network. That user is having intermittent lockups using a
certain app that uses SQL. So, I thought that these two were tied together,
but they may be separate issues.

It looks like I am getting hit somehow. I need to figure out where this is
coming from.

Also, I looked closer at the SQL accounts. I do have an sa, but there are
two other accounts that are being tried that I do not have. They are admin
and root.

At this point, I would welcome suggestions on how to pinpoint where this is
coming from, and how to stop it.

Thanks for your help.

KT

> Hello again.
>
[quoted text clipped - 29 lines]
> >
> > KT

Reply to this Message

KT - 30 Jun 2008 23:48 GMT

Hi again.

Upon further examination:

The host name changed from bettys to SERVER. The account that was attempted
to logon to was sa. Hundreds of attempts.

A netstat showed continuous connections in a time-wait state to
209.123.180.100, and to changing ports like 5113, 5214, etc., one right after
the other.

While I was working to determine where this was coming from, the attempts
finally stopped.

The Application name used this time was OSQL-32, the client process ID was
3348, and the SPID was 51.

I found one other posting on the net with this same issue with OSQL-32 and
PID 3348, but no solution was posted.

My network is protected by a Cisco PIX.

Any further help to protect the server from future attacks will be greatly
appreciated. Thanks Sean for the suggestions so far.

KT

> Thanks Sean.
>
[quoted text clipped - 55 lines]
> > >
> > > KT

Reply to this Message

Sean McCown - 01 Jul 2008 00:06 GMT

OK, did I hear you right, you've determined that the attacks are coming from
outside? Because if they are, then this is circle all the wagons-911 time.
Make sure you're sa acct has a very strong password of at least 15-chars with
both numbers and special chars (; ! ? | <, etc).

Also, if it is coming from outside then you are NOT being protected by your
PIX and your cisco guys need to circle their wagons and do something about
this. Because if they can ping one box they can ping the others and then
it's only a matter of time before they get lucky and brute force one of your
passwords. This is not a drill.

And make sure that everything like xp_cmdshell, xp_readreg, xp_writereg, etc
are all extremely locked down. If you can, have the cisco guys limit the
holes to that segment and/or box to just the SQL ports.

Also, it could be coming from inside as well. I used to work with a guy who
loved to do that kinda crap so don't discount that either. But you need to
make sure that all your SQL boxes are in order and that your firewall guys
are helping lock down this threat. Again, it's only a matter of time before
they brute force one of your passwords. If you're on Windows auth then
you're way ahead of the game, but if you're on mixed, then make sure that
everyone has a strong password and that they have only the rights they need.

This may seem like overkill, but you're under direct attack so what do you
think?

Other than that, there's no easy way to find out who's doing it from
outside. It's a long process that can be complicated and they're probably
spoofing their IP anyway. However, you can gather some info on them through
what you're doing and if the IP is staying constant, then have the cisco guys
just block that IP or range and you can solve your problem right there.

Let me know what happens. This is serious stuff so don't blow this off.

Signature

> Hi again.
>
[quoted text clipped - 82 lines]
> > > >
> > > > KT

Reply to this Message

Erland Sommarskog - 01 Jul 2008 23:39 GMT

> Also, it could be coming from inside as well. I used to work with a guy
> who loved to do that kinda crap so don't discount that either.

And of course, it could be someone who has had his machine infected one
way or another.

Signature

Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx

Reply to this Message

Sean McCown - 02 Jul 2008 15:20 GMT

Exactly Erland... good point. Though at this point I'm not sure it matters
whether the attack is intentional or un... but y...

Signature

> > Also, it could be coming from inside as well. I used to work with a guy
> > who loved to do that kinda crap so don't discount that either.
>
> And of course, it could be someone who has had his machine infected one
> way or another.

Reply to this Message

KT - 02 Jul 2008 21:45 GMT

Thanks for your help.

At first, I thought the attacks coinsided with a user's computer on the
inside of the network, but in further monitoring I determined that they were
from the outside.

I did find the SQL port open on the Pix and got it closed. So, I don't
expect any more attacks to happen.

At one time the people here had a remote web app that accessed SQL via the
Internet, so that's why the port was open.

Thanks again for your help.
I will post back if any more problems occur.

KT

> OK, did I hear you right, you've determined that the attacks are coming from
> outside? Because if they are, then this is circle all the wagons-911 time.
[quoted text clipped - 116 lines]
> > > > >
> > > > > KT

Reply to this Message

Ekrem Önsoy - 02 Jul 2008 22:04 GMT

In future, if you have a need to open your SQL Server to internet, then
ensure you are not using standard port (1433). Because hackers probably will
be knowing about it and they will attack through this port directly. Using a
non-standard port will take their time to figure out your SQL Server' s
port.

Same for the "sa" account. Don't use this account if possible or change it's
name. Because as you probably know this Login has all rights on your SQL
Server instance. So again, hackers will try to attack to this account first.
Because of this consideration, "sa" account' s name will be changable during
SQL Server 2008 Setup.

Signature

Ekrem Önsoy

> Thanks for your help.
>
[quoted text clipped - 175 lines]
>> > > > >
>> > > > > KT

Reply to this Message

KT - 02 Jul 2008 22:13 GMT

Thanks for the suggestions.

What saved us was a strong password on the sa account. I couldn't change the
account name immediately because there is a custom app running that uses SQL,
and I didn't want to break things off the bat. I will look at getting that
account name changed and remember the other suggestion for the future.

Thanks,
KT

> In future, if you have a need to open your SQL Server to internet, then
> ensure you are not using standard port (1433). Because hackers probably will
[quoted text clipped - 187 lines]
> >> > > > >
> >> > > > > KT

Reply to this Message

KT - 02 Jul 2008 22:16 GMT

I could also use some direction on securing xp_cmdshell, etc. as was stated.

Thanks,
KT

> Thanks for the suggestions.
>
[quoted text clipped - 197 lines]
> > >> > > > >
> > >> > > > > KT

Reply to this Message