Re: "login failed for user ..." appears in event viewer repeatedly
- From: Ekrem Önsoy <ekrem@xxxxxxxxxxxx>
- Date: Thu, 3 Jul 2008 00:04:51 +0300
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
.
- Follow-Ups:
- References:
- Prev by Date: RE: "login failed for user ..." appears in event viewer repeatedly
- Next by Date: Re: "login failed for user ..." appears in event viewer repeatedly
- Previous by thread: RE: "login failed for user ..." appears in event viewer repeatedly
- Next by thread: Re: "login failed for user ..." appears in event viewer repeatedly
- Index(es):
Relevant Pages
|
