Re: Slammer Worm and SQL Server Network Protocols
From: Chip Andrews (chipandrews@USA.NET)
Date: 01/30/03
- Previous message: Chip Andrews: "Re: Slammer Worm and SQL Server Network Protocols"
- In reply to: Chip Andrews: "Re: Slammer Worm and SQL Server Network Protocols"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Thu, 30 Jan 2003 14:16:46 -0500 From: Chip Andrews <chipandrews@USA.NET> To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
A couple of things I forgot to mention in my last post and these are
important points:
1) My (nor Alan's) suggestion does NOT mitigate the risk of remote
expoitation of the SQL Resolution Server as exploited by the SQLSlammer
worm. Disabling all netlibs only serves the function of making the SQL
Server inaccessable to network clients and stops information leakage about
server versions, netlibs installed, clustered status etc. The SQL
Resolution server is still listening (and exploitable) when no netlibs are
enabled - it just does not respond.
2) You can disable all netlibs using the Server Network Utility installed
with SQL Server or by clearing the registry located at
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\MSSQLServer\SuperSocketNet
Lib\ProtocolList
or
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL
Server\(Instance_Name)\MSSQLServer\SuperSocketNetLib\ProtocolList
(for named instances)
I hope that clears things up a bit. I just want it to be clear that
disabling all netlibs does not protect you from the SQLSlammer worm. It's
simply a good lock-down technique that enforces security in-depth.
Clearly, the best defenses for SQLSlammer are keeping up with patches and
server isolation (port filtering).
Chip Andrews
www.sqlsecurity.com
----- Original Message -----
From: "Chip Andrews" <chip@SQLSECURITY.COM>
To: <NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM>
Sent: Thursday, January 30, 2003 12:55 PM
Subject: Re: Slammer Worm and SQL Server Network Protocols
> Alan,
>
> The problem with that solution is that it does not produce the desired
> effect.
>
> Removing the TCP/IP netlib alone does NOT stop the SQL Resolution Service
on
> UDP 1434 from listening or responding. As evidenced by the following
> SQLPing output even after configuring the server to Named Pipes only:
>
> Response from 192.168.10.115
> -----------------------------
> ServerName : BASEREM2
> InstanceName : MSSQLSERVER
> IsClustered : No
> Version : 8.00.194 (Keep in mind that this version is never current
as
> reported by MSSQL- It always returns the base version)
> np : \\BASEREM2\pipe\sql\query
>
>
> If you want the server to stop responding to UDP 1434 queries you should
> disable ALL netlibs on the SQL Server instance. This will force all local
> connection attempts to use the Shared Memory netlib (an oxymoron). This
> netlib will only work for instances installed on the same machine but is
> even more fast and efficient than your named pipes solution since no
> network-layer calls are used at all.
>
> Chip Andrews
> www.sqlsecurity.com
>
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Delivery co-sponsored by TruSecure Corporation
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
TICSA - Anniversary Special - Limited Time
Become TICSA certified for just $221.25 US when you register before 3/31/03
with PROMO "TS0103" at www.2test.com. NO membership fees, certification
good for 2 years. Price for international delivery just $296.25 US, with
this offer. Offer cannot be combined with any other special and expires
3/31/03. Visit www.trusecure.com/ticsa for full details.
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
- Next message: Russ: "IERK Survey"
- Previous message: Chip Andrews: "Re: Slammer Worm and SQL Server Network Protocols"
- In reply to: Chip Andrews: "Re: Slammer Worm and SQL Server Network Protocols"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
