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

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

Thanks,
KT

"KT" wrote:

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

"Ekrem Önsoy" wrote:

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.

--
Ekrem Önsoy



"KT" <KT@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:8E81C27D-AB87-4746-9E98-E0F643E12660@xxxxxxxxxxxxxxxx
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: SQL 2k5 SP2 Mirroring - SQL in Mixed mode.
    ... US\sqlservices (old SQLservice account) still member of built-in local admin ... Login: US\sqlservices ... How can I transfer the SQL logins to ... Here is SP_help_revlogin results from the Principal Server (NYSQL-3) ...
    (microsoft.public.sqlserver.clustering)
  • Re: SQL Server on XP Home Network
    ... The sa account is the system administrator "God" account witihin SQL ... This account is a SQL-Server login. ... You might be able to use Enterprise Manager to go in and create a new SQL ... Select the "SQL Server Authentication" ...
    (microsoft.public.sqlserver.setup)
  • Re: SQL Connection with .udl and domain accounts
    ... work because it's not recognised by SQL-Server as a valid User Id. ... difference between a SQL account and a domain account. ... Login account using a SQL Login name and password that will ...
    (microsoft.public.sqlserver.connect)
  • Re: SQL DBA Client
    ... What is required depends on how you expose your SQL... ... measures you should consider are changing the port number ... you're using and using a User account with minimal ... Enterprise Manager accordingly (configuring the Client ...
    (microsoft.public.windows.server.sbs)
  • Re: sql problem
    ... Account # is the link field on ... The requirement is I have to come up with a report comparing the two ... customer tables to see if they are in sync. ... what I wanted to do was to get the SQL to return the "like" names ...
    (comp.databases.oracle.server)