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
-------------------------------------------------------------------------------
