From: Craig Wright (cwright@bdosyd.com.au)
Date: Thu Oct 20 2005 - 17:50:54 EDT
Hi
By the PCI data security standards required by Visa/MasterCard this would not be acceptable - there would need to be a firewall separating the Database and the public server. The Database would not be allowed to exist on the internal network either.
Thus you need either 2 DMZ's or separate internal segments
In particular 1.3.5 states "Placing the database in an internal network zone, segregated from the DMZ". This is not the same internal network as the user LAN either "Limit access to computing resources and cardholder information to only those individuals whose
job requires such access." (7.1)
For details see sections 1.3, 1.3.5, 1.4, 2.2.1, 6.3.3, 7.1 of the PCI
Interfaces for a firewall are cheap. Switches are cheap.
The PCI is just one example (others exist) - if you have a database (even a replica) on the DMZ - than you are liable for all loss incurred by credit card fraud on your systems.
Craig
-----Original Message-----
From: Thor (Hammer of God) [mailto:thor@hammerofgod.com]
Sent: 20 October 2005 12:27
To: pen-test@securityfocus.com
Cc: Lyal Collins; rob havelt; Paul Robertson; ma.teo
Subject: Re: Pen test - Attorney client Privilege?
> 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
-------------------------------------------------------------------------------
------------------------------------------------------------------------------
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
-------------------------------------------------------------------------------
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:55:04 EDT