Results 1 to 4 of 4

Thread: Dmz

  1. #1

    Dmz

    In DMZ as we know all sensitive information is located under interlal network and all public services in DMZ zone.
    How it is done, in the case of E-comerce services?
    Does web page located in DMZ and its database under internal network?

  2. #2
    The DMZ is established by use of two firewalls. The outter firewall allows public traffic through to specific public-facing systems (web servers and such). The internal firewall provide the NAT barrier (so that systems and servers on the inside have private IP addresses). The Web server in the DMZ has access through the internal firewall to the internal database servers.

    That is about as simple an explaination as I can make. It is a complex task to create the DMZ and make it work effectively and not have IP looping or bouncing between the firewalls.

  3. #3
    Senior Member
    Join Date
    Sep 2001
    Posts
    1,027
    This really doesn't answer HackInProgress' question...

    Does web page located in DMZ and its database under internal network?
    Yes, having the web server in the DMZ and the database in the private network is a common setup. You'd let only ports 80/443 in from anyone to the web server at the internet/dmz border and the database's port (1433 for mssql for example) at the dmz/private border.

    Having the DB inside the private network isn't always necessary however, and can represent a greater risk. You also have to keep in mind that just because the DB is inside the private net, it doesn't mean it's not at risk of potential exploitation from SQL injection for example (sql injection in mssql while using the SA account can have dramatic consequences by using the extended store procedures...).

    Other possible setups might include:
    -having both web and db servers inside the private net with a reverse web proxy in the dmz, filtering/tunneling the requests back in to the real web server;
    -having the web server as well as a "static" copy of the database in the dmz, with the "real" DB inside the private net, and replicating the real DB to the static one every so often (of course this doesn't apply if you need actual "dynamic" data...

    Their are probably more setups I'm not thinking of right now, but in all cases, you gotta keep in mind that providing a service implies a compromise between fonctionnality and security...

    Ammo
    Credit travels up, blame travels down -- The Boss

  4. #4
    Master-Jedi-Pimps0r & Moderator thehorse13's Avatar
    Join Date
    Dec 2002
    Location
    Washington D.C. area
    Posts
    2,885
    Ammo is correct in that any connections coming inbound from the DMZ is risky business. Many people, including auditors, frown on the practice no matter what the business case may be. If you consider what the definition of a DMZ is, inbound connections from a DMZ basically nulls the concept.

    In my case, no inbound connections are permitted from any of my DMZs. What I do instead is a one way trust so that my replicated DMZ DB is always in sync with internal servers. The propagation is done one way (outbound into the DMZ).

    I have run this configuration for years without a single incident. Anyway, just another config to add to the list.
    Our scars have the power to remind us that our past was real. -- Hannibal Lecter.
    Talent is God given. Be humble. Fame is man-given. Be grateful. Conceit is self-given. Be careful. -- John Wooden

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •