Re: Pen test - Attorney client Privilege?

• Previous message: Victor Barris: "Foundry Routers and Switches"
• In reply to: ma.teo: "Re: Pen test - Attorney client Privilege?"
• Next in thread: rob havelt: "Re: Pen test - Attorney client Privilege?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

To: <pen-test@securityfocus.com>
Date: Wed, 19 Oct 2005 19:27:24 -0700

> I´ve a doubt about the communication between a Data Base and a web server
> (e.g SQL and IIS) in a firewall environment.
> I know that is more secure to have separate it, one in a firewall zone
> (LAN) and other in the other firewall zone (DMZ), the question is:
> Which are the most secure method to establish a communication between this
> two appications?, because i can't believe that to open a connection from
> DMZ to LAN are a good idea.
> How is the connection?, and which are the direction???
>
> Thx a lot.
> loop.-
>

I strongly recommend populating the DMZ with its own SQL server for a
multitude of reasons:

As you point out, not only would a static rule exist allowing TCP traffic to
port 1433 in to the LAN from the DMZ (thus leaving a clearly defined attack
path) but the "IIS in the DMZ to a back-end SQL on the LAN" configuration
almost always results in the internal SQL box being set to mixed mode
authentication. That in itself is an issue for me as one does not get the
default additional benefits of Integrated Authentication such as account
lockout, password complexity enforcement, password change enforcement, etc,
and could weaken the posture of your internal SQL box.

I say "most always" as the IIS boxes IUSR account used for anonymous
connections won't establish a trusted connection as it would not be a member
of the LAN domain (I hope.) This typically results in data connections
being established using connection strings containing the username and
password in the clear, such as the connection string required for an ADODB
recordset object in an ASP page. If the web box in the DMZ gets owned, the
attacker has not only a clear path into the LAN, but credentials that can
immediately be used against the SQL box if not somewhere else downstream
where usernames and passwords are reused elsewhere.

Even in the absence of "owning" the IIS box, application level issues such
as sql-injection, etc would allow attackers to execute code directly on the
SQL box which is already sitting in the LAN. That's a heck of a perch from
which to launch other attacks.

Also, the DMZ web applications normally need only a small sub-set of data to
function, yet in the IIS-to-SQL-on-LAN model, an attacker would have access
to all the data on the server though it has nothing to do with the app (like
payroll, HR, etc.).

With a separate SQL install in the DMZ, you can easily create a replication
scheme where a publication containing only the limited data needed to
support the app is created on the LAN SQL box, with a push subscription set
to replicate to the SQL box in the DMZ. An "outbound-only" firewall rule
would be in place that only allowed the connection to be established from
the LAN SQL box to the DMZ SQL box. The SQL box in the DMZ would be the
only box in mixed mode- but here, the LAN box would use an account that only
exists on the DMZ SQL box (which you would set up when you build the
replication job.) In this way, any findings of the account info could only
be used in the DMZ.

The job could be set to run on a schedule or constantly, depending on how
often you needed to have the data updated in the DMZ. Even in the cases of
user-provided data elements that must be updated to the internal box, (such
as form request data, change of records, etc.) a scheduled job sourced
internally could go out and get the needed data after scrubbing it.

I would also recommend that you drop a cert on the SQL box in the DMZ so
that you could enforce encryption on the connection to help obviate data
injections, connection hijacking, etc.

hth

t

------------------------------------------------------------------------------
Audit your website security with Acunetix Web Vulnerability Scanner:

Hackers are concentrating their efforts on attacking applications on your
website. Up to 75% of cyber attacks are launched on shopping carts, forms,
login pages, dynamic content etc. Firewalls, SSL and locked-down servers are
futile against web application hacking. Check your website for vulnerabilities
to SQL injection, Cross site scripting and other web attacks before hackers do!
Download Trial at:

http://www.securityfocus.com/sponsor/pen-test_050831
-------------------------------------------------------------------------------

• Previous message: Victor Barris: "Foundry Routers and Switches"
• In reply to: ma.teo: "Re: Pen test - Attorney client Privilege?"
• Next in thread: rob havelt: "Re: Pen test - Attorney client Privilege?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]