Internet password attacks

I have opened port 1433 on our firewall to allow employees to access our SQL
server database and immediately we have received aggressive password attacks
,
mostly against the 'sa' user id. The 'sa' passoword is strong, but I'm
annoyed with the attacks that make my log files huge and cause unncessary
hits to the server.
Is there a way to configure SQL Server to force a delay between login
attempts or to temporarily lockout a user out as can be done with Windows
Server?
Many Thanks!Microsoft refuses to fix this glaring problem in SQL 2000. You can use a
port monitor to get the IP numbers then block them with a firewall or use
IPsec to block the IP numbers. It is a never ending job as new drones will
be attacking every day.
Microsoft's reply is that you shouldn't be doing this. Of course, they will
be glad to sell you a copy of SQL Server 2005 that does fix this (non)
problem.
With a strong password, the attackers will never be successful, but they can
eat up a lot of bandwidth trying.
Russ Stevens|||So you can confirm SQL 2005 does address this issue? Do you have details on
how?
I have port 1433 and 1434 open also going thru a Virtual IP, so far no
attacks.
"Russell Stevens" <rustyprogrammer@.online.nospam> wrote in message
news:um$43caqFHA.3524@.tk2msftngp13.phx.gbl...
> Microsoft refuses to fix this glaring problem in SQL 2000. You can use a
> port monitor to get the IP numbers then block them with a firewall or use
> IPsec to block the IP numbers. It is a never ending job as new drones will
> be attacking every day.
> Microsoft's reply is that you shouldn't be doing this. Of course, they
> will be glad to sell you a copy of SQL Server 2005 that does fix this
> (non) problem.
> With a strong password, the attackers will never be successful, but they
> can eat up a lot of bandwidth trying.
> Russ Stevens
>|||Rob,
<<So you can confirm SQL 2005 does address this issue? Do you have details
on
how?>>
SQL 2005 uses the normal Windows 2003 logon stuff - ie - you can allow 3
unsucessful logins, then have a lockout period of 30 minutes or whatever
(you specify both). I haven't actually verified this - it is in the docs but
it doesn't work under WinXP - after much searching I found that this feature
will only work on Win2003 server and I haven't installed the Beta on a
server yet.
<<I have port 1433 and 1434 open also going thru a Virtual IP, so far no
attacks.>>
Depending on how you are looking you may not notice them. Some drones are
just dialup - you would have a hard time seeing the once per second login
attempt on the bandwidth. Some drones are on high speed connections - will
give you a straight line on your bandwidth (30 or more connection attempts
per second). To see if anyone is trying, run the SQL Profiler and setup a
trace to record unsuccessful logins. They won't show up in your normal
events log. If 1433 is open to the Internet you can almost bet someone is
trying to get in during some parts of the day. Not sure why you would want
udp 1434 open - make them work a little harder <g>.
Russ Stevens|||Unfortunately it isn't a bug (where bug = coding error) in SQL Server 2000.
It isn't even a design flaw in the classic sense. It is a missing feature
set dating back to the original Sybase decisions made 20 years ago.
Microsoft's fix was to add integrated (aka Windows) security and push people
not to use the legacy SQL Server security stuff at all. That fixes the
problem. But despite Microsoft's desire to do away with the legacy security
stuff it is still heavily used. Partially for bad reasons (like, it just
being easier to embed a password in the application) and partially for good
reasons (like, we have to access it from a Unix system). So for SQL Server
2005 they are finally acknowleding that and re-working the Sybase-derived
stuff to use the full set of Windows password protections. But I doubt it
is something of a scope that it could be easily (mostly meaning safely and
reliably) backported into a SQL Server 2000 service pack. Not impossible of
course, but just well beyond the scope of a service pack.
Personally, I would NOT put a SQL Server 2000 directly on the Internet.
There are reasons beyond the password security issues that make me queasy
(not that I know of any specific vulnerability). The better way to enable
your users to access SQL Server remotely is to have them VPN in. That is
yet another reason Microsoft wasn't incented to enhance the legacy password
stuff earlier.
At a minimum you should use a non-standard port for your SQL Server if it is
going to be on the net. That should minimize the attacks (since I imagine
most of them are built on the premise that SQL Server uses 1433).
Hal Berenson, President
PredictableIT
Phone: 805-212-1025 ext 101
hberenson@.predictableit.com
Helpdesk: 805-212-1024 ext 1
"Russell Stevens" <rustyprogrammer@.online.nospam> wrote in message
news:um$43caqFHA.3524@.tk2msftngp13.phx.gbl...
> Microsoft refuses to fix this glaring problem in SQL 2000. You can use a
> port monitor to get the IP numbers then block them with a firewall or use
> IPsec to block the IP numbers. It is a never ending job as new drones will
> be attacking every day.
> Microsoft's reply is that you shouldn't be doing this. Of course, they
> will be glad to sell you a copy of SQL Server 2005 that does fix this
> (non) problem.
> With a strong password, the attackers will never be successful, but they
> can eat up a lot of bandwidth trying.
> Russ Stevens
>|||Hal,
<<It is a missing feature
set dating back to the original Sybase decisions made 20 years ago.
Microsoft's fix was to add integrated (aka Windows) security and push people
not to use the legacy SQL Server security stuff at all>>
Its refreshing to hear someone NOT say "SQL server was not designed to allow
open Internet access". As you mention, it was designed exactly for that
originally. Of course, this is further compounded by the fact that you can't
change the sa account. Microsoft recommends you rename the Administrator
account on its servers so that a hacker needs to guess both the user name
and a password. Given that the sa account is fixed, the hacker only needs to
guess a password. Then, on top of that, for years, the default password for
the sa account was an empty string. So hackers knew the login name and knew
the password for lots of SQL servers without having to do anything. It is
now a little harder as they try to crack the password using a dictionary
attack. Put a new SQL server online, and the hacks will start within an
hour.
I think Microsoft could easily fix this in a service pack if they wanted to.
They already have the necessary code for tracking unsuccessful logins (in
Profiler). They don't need to tie it in to group policy, etc. to fix this in
SQL 2000 - after x unsuccessful tries, block out y for z time and allow the
sa account to be renamed. Using another port doesn't help much - the hackers
can easily determine the SQL port.
Sure, the SQL 2005 way is the best way to do it (tied in to the OS), but
anyway you do it is better than the SQL 2000 way. Just imagine the amount of
Internet bandwidth that would then become available for something useful
<g>.
Russ Stevens|||Allow the SA account to be renamed in a service pack? You are mad. That
would break the entire product and require many thousands of lines of code
to be changed (not to mention all the customer apps that would be broken).
Put in a hard coded delay (z) after x failed login attempts for a particular
account (y), with no user interface for controlling x or z? That might be
reasonable. An even easier change would be to just insert a timeout-1
second delay before responding to a TDS Login packet that contained an
invalid password. That would effectively kill the automated attacks without
breaking anything (important). Unfortunately, it is likely to be a long
time until the next SQL Server 2000 Service Pack and that will (I'm
guessing) be little more than a hotfix rollup. So we've probably missed the
boat on doing anything for SQL Server 2000.
Hal Berenson, President
PredictableIT
Phone: 805-212-1025 ext 101
hberenson@.predictableit.com
Helpdesk: 805-212-1024 ext 1
"Russell Stevens" <rustyprogrammer@.online.nospam> wrote in message
news:u7sJiP%23qFHA.3600@.TK2MSFTNGP10.phx.gbl...
> Hal,
> <<It is a missing feature
> set dating back to the original Sybase decisions made 20 years ago.
> Microsoft's fix was to add integrated (aka Windows) security and push
> people
> not to use the legacy SQL Server security stuff at all>>
> Its refreshing to hear someone NOT say "SQL server was not designed to
> allow open Internet access". As you mention, it was designed exactly for
> that originally. Of course, this is further compounded by the fact that
> you can't change the sa account. Microsoft recommends you rename the
> Administrator account on its servers so that a hacker needs to guess both
> the user name and a password. Given that the sa account is fixed, the
> hacker only needs to guess a password. Then, on top of that, for years,
> the default password for the sa account was an empty string. So hackers
> knew the login name and knew the password for lots of SQL servers without
> having to do anything. It is now a little harder as they try to crack the
> password using a dictionary attack. Put a new SQL server online, and the
> hacks will start within an hour.
> I think Microsoft could easily fix this in a service pack if they wanted
> to. They already have the necessary code for tracking unsuccessful logins
> (in Profiler). They don't need to tie it in to group policy, etc. to fix
> this in SQL 2000 - after x unsuccessful tries, block out y for z time and
> allow the sa account to be renamed. Using another port doesn't help much -
> the hackers can easily determine the SQL port.
> Sure, the SQL 2005 way is the best way to do it (tied in to the OS), but
> anyway you do it is better than the SQL 2000 way. Just imagine the amount
> of Internet bandwidth that would then become available for something
> useful <g>.
> Russ Stevens
>|||Hal,
<<Allow the SA account to be renamed in a service pack? You are mad>>
No - the SP doesn't rename it, it gives the SQL admin the ability to change
it. If he has apps that use it, then he can fix them first or leave as is.
<<Unfortunately, it is likely to be a long
time until the next SQL Server 2000 Service Pack and that will (I'm
guessing) be little more than a hotfix rollup. So we've probably missed the
boat on doing anything for SQL Server 2000.>>
We have been missing the boat for many years - Microsoft just refuses to fix
it (this is not a new issue <g> ).
Thanks
Russ Stevens|||On Mon, 29 Aug 2005 08:22:51 -0400, Russell Stevens wrote:

> <<Allow the SA account to be renamed in a service pack? You are mad>>
> No - the SP doesn't rename it, it gives the SQL admin the ability to chang
e
> it. If he has apps that use it, then he can fix them first or leave as is.
There are many many parts *internal* to SQL server that depend on the sa
account being named sa. A service pack that changes them all to tolerate a
renamed sa account is a dangerous thing to do.|||I've been programming for 20+ years and to me there are a number of
inexpensive solutions to this problem that Microsoft could deploy, but they
have delibertly choosen not to for whatever motive. The fact that no
Micrsoft MVP has responded to this post as I have seen in most other posts,
further backs this opinion.
Is there a Microsft MVP out there willing to touch this issue?
"Ross Presser" wrote:

> On Mon, 29 Aug 2005 08:22:51 -0400, Russell Stevens wrote:
>
> There are many many parts *internal* to SQL server that depend on the sa
> account being named sa. A service pack that changes them all to tolerate
a
> renamed sa account is a dangerous thing to do.
>