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

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

"Sean McCown" wrote:

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.
--
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




"KT" wrote:

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

"KT" wrote:

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

"KT" wrote:

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


"KT" wrote:

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
.

Relevant Pages

  • RE: "login failed for user ..." appears in event viewer repeatedly
    ... OK, did I hear you right, you've determined that the attacks are coming from ... holes to that segment and/or box to just the SQL ports. ... I looked closer at the SQL accounts. ... I used SQL profiler to audit logins and login failures. ...
    (microsoft.public.sqlserver.security)
  • RE: local admin account password
    ... Subject: local admin account password ... > 4) Only use domain accounts so delete the local ones. ... > The DB file would be encrypted with EFS so only the limited user SQL ... > backup user can make a zip backup of the DB whenever it gets changed ...
    (Focus-Microsoft)
  • RE: SQL Smuggling
    ... Its several methods for encoding sql queries or tricking multi layered input validation/sanitisation routines, none of which are new, all of which are implemented by every pen/app tester i have ever worked with. ... of SQL Injection that has not received attention till now. ... As for attacks against signature validation... ... SQL injection attacks against commonly broken data validation routines. ...
    (Bugtraq)
  • RE: local admin account password
    ... Say you have more then 1000 systems, how do you handle the local admin ... Only use domain accounts so delete the local ones. ... The DB file would be encrypted with EFS so only the limited user SQL ... There would be basically two stored procs, ...
    (Focus-Microsoft)
  • Re: Very strange behavior of SQLServer with connection from CGI
    ... this is not a default SQL instance. ... SQL clients use a UDP ... connection to port 1434 to resolve port numbers for named instances. ... You can use the SQL Server Network utility to lock ...
    (microsoft.public.sqlserver.connect)