RE: SQL2000 and hisecweb
From: Dean Thompson (DeanSub@ev1.net)Date: 03/19/02
- Previous message: Brett Oliphant: "Re: HFNetChk Pro vs. other means to push out updates"
- In reply to: Thor@HammerofGod.com: "Re: SQL2000 and hisecweb"
- Next in thread: Aaron C. Newman (Application Security, Inc.): "RE: SQL2000 and hisecweb"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Tue, 19 Mar 2002 16:29:16 -0600 From: Dean Thompson <DeanSub@ev1.net> To: Thor@HammerofGod.com, ubrgeek@msn.com, focus-ms@securityfocus.com
A couple of extra thoughts here to an already excellent list of points...
In addition to blocking UDP port 1434, click "Hide Server" in the properties
for the TCP/IP connection in your SQL Server Network utility. If you are
hosting for others, and must allow access to SQL Server, consider changing
the default port and forcing encryption. The encryption is weak, but
helpful.
Also, remove God mode access "Systems Administrator Role", and assign new
user ids for the roles you need. This can be a bear, but you are probably
accustomed to this stuff anyway.
Don't allow xp_cmdshell execution if you don't need it. If you do, you
might want to re-evaluate why you are using it and find an alternative.
Don't let your application users perform DDL. If they must create and
destroy tables, etc. on the fly, create stored procedures to do so, and give
the users access to those.
Dean Thompson
dean@txsqlusers.com <mailto:dean@txsqlusers.com>
Texas SQL Users http://www.txsqlusers.com
"f u cn rd ths, u cn gt a gd jb n cmptr prgmmng." -Anon.
-----Original Message-----
From: Thor@HammerofGod.com [mailto:Thor@HammerofGod.com]
Sent: Tuesday, March 19, 2002 1:43 PM
To: ubrgeek@msn.com; focus-ms@securityfocus.com
Subject: Re: SQL2000 and hisecweb
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
At 08:49 AM 3/19/2002, Jesse Reisman wrote:
>We're in the process of figuring out the best way to lock down MS-SQL
>2000. We're using the IISLockdown tool, hisecweb.inf and other appropriate
>templates for locking down Win2K and IIS5.0 but I haven't been able to
>find any reference to a similar template for locking down the database.
>We're hoping to combine all of the security recommendations from the
>"Microsoft SQL Server 2000 Operations Guide" and other, similar documents
>into one central template that can be sent to different regional offices
>to make the lockdown easier across the board.
Greetings! Let's see if I can beat Chip to this one ;)
There are several fronts you need to defend:
1) Internet Service Availability
Without other information, I'll have to assume that given the way you
outlined the question, you have both IIS 5.0 and SQL2000 on the same box,
and that box is on the Net. I am further assuming that the SQL
functionality is to provide data support for a web application, and that
you don't intend to allow people access to the SQL Server- only the Web App
via ADOBD or something like that. If this is true, you should ensure that
TCP 1433 (unless you changed it) is not allowed in, nor is UDP 1434 to keep
people from using stuff like SQLPing to enumerate server info via the
multiple instancing listener. Ideally, you would separate the SQL box from
the IIS box so that the SQL box was isolated from the public net.
2) Operating System/ Service Configuration
A couple of things here... First determine exactly what services you need
to have on the SQL box. If you can do without the SQL Agent, the do- many
functions of the SQL Agent require the context that the service runs in to
have escalated privileges- The SQL Server service itself can be run with a
guest account, which is the best way to keep yet-to-be-exploited
vulnerabilities from executing commands in the typical LocalSystem context
that people run the service under. If you create a guest user first, you
can then install SQL Server, and tell it to use that user- it will give it
the necessary rights it needs to run SQL Server. Beware though, this
procedure also (reportedly) assigns the account the SE_TCB_NAME and
SE_ASSIGNPRIMARYTOKEN_NAME privs, which is not good. Chip Andrews
(sqlsecurity.com) has tested removing these privs from the account with no
ill-affects, so know that it is something you will have to do. I have not
tested it, but I trust Chip explicitly.
Ensure that you are using NT Integrated security, and not mixed-mode
security. mixed-mode allows the bf of the SA account, and does not give
you the tight controls for user accounts that NT Integrated does. Even if
you set up integrated security from the get-go, assign a complex password
to the SA account just in case some nimrod changes modes on you in mid
stream.
3) Application Development
Even when you have everything else locked down tight, you must ensure that
your application is properly requesting data from the Sever. Any time you
accept user input, no matter what it is, you must make sure that you check
and sanitize that data before passing it along to your SQL server. Data
types must be checked, value extents should be checked, and the input
should be stripped of any potentially dangerous characters that could be
used to manipulate the server into performing unwanted queries (SQL
Injection). Use stuff like the ADODB Command object, use strongly typed
variables, and use properly designed stored procedures (called via the
command object, etc) on the server side. There really is alot to this, but
you get the drift.
This is by no means an exhaustive list, but it does cover many of what I
would consider the most common issues regarding SQL2000...
hth
AD
-----BEGIN PGP SIGNATURE-----
Version: PGP 7.1
iQA/AwUBPJeU24hsmyD15h5gEQIS2gCg7v6J7k6eNq2zjNWM8oO88Ng/3C0AoOa2
Y6kJX2nEVBRFVKvC7fMFVkBd
=D/FW
-----END PGP SIGNATURE-----
- Previous message: Brett Oliphant: "Re: HFNetChk Pro vs. other means to push out updates"
- In reply to: Thor@HammerofGod.com: "Re: SQL2000 and hisecweb"
- Next in thread: Aaron C. Newman (Application Security, Inc.): "RE: SQL2000 and hisecweb"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
