Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Pen-Test
[Top] [All Lists]

Re: Pen test - Attorney client Privilege?

Subject: Re: Pen test - Attorney client Privilege?
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
-------------------------------------------------------------------------------

<Prev in Thread] Current Thread [Next in Thread>