Web server placement in DMZ

Archived from groups: comp.security.firewalls (More info?)

Hi-

I'm going to be rolling out a website and would like to protect the
internal network.. I see that placing a webserver in a dmz is safest..
Right now this web server is part of a domain, should I remove the
webserver from the domain and create a workgroup or leave it joined in
a domain.. I assume leaving it in a domain is not safe,,, Or should I
rebuild this server as a new dc and wen server and then place it in
the DMZ?..

I want to protect our internal network so I'm trying to figure out the
safest way..

BTW it goint to be IIS6 W2k3 server..

Thanks,
TOM
6 answers Last reply
More about server placement
  1. Archived from groups: comp.security.firewalls (More info?)

    In article <d2f5aae0.0405290634.56bc7994@posting.google.com>, toms1616
    @optonline.net says...
    > Hi-
    >
    > I'm going to be rolling out a website and would like to protect the
    > internal network.. I see that placing a webserver in a dmz is safest..
    > Right now this web server is part of a domain, should I remove the
    > webserver from the domain and create a workgroup or leave it joined in
    > a domain.. I assume leaving it in a domain is not safe,,, Or should I
    > rebuild this server as a new dc and wen server and then place it in
    > the DMZ?..
    >
    > I want to protect our internal network so I'm trying to figure out the
    > safest way..
    >
    > BTW it goint to be IIS6 W2k3 server..

    There is an extreme risk in having any server that provides public
    access as part of your domain network. In fact, you should make sure
    that the administrator account name is renamed to something other than
    Administrator. Also make sure that there are not complementary account
    enabled on the server that have a matching user/password in your domain.

    The DMZ should not have access to the LAN (domain) unless you strictly
    need a database from the LAN. In that case I would map a single data
    port from Fixed IP to Fixed IP through the firewall for the web<>
    database communications.

    There are a zillion other things to do, set permissions on CMD, and
    others so that only a specific account can access it, remove all sample
    apps/folders....

    You should also follow MS's suggestions on locking the server down.

    One last thing, only allow ports that are needed to be open to the
    server, in general, only HTTP/SSL needs to be open.


    --
    --
    spamfree999@rrohio.com
    (Remove 999 to reply to me)
  2. Archived from groups: comp.security.firewalls (More info?)

    On Sat, 29 May 2004 15:15:33 GMT, Leythos wrote:

    [snip]

    > One last thing, only allow ports that are needed to be open to the
    > server, in general, only HTTP/SSL needs to be open.

    And unless you have special needs, don't allow any outgoing
    connections _from_ the DMZ at all. This will limit the amount
    of damage your compromised server[1] can do to others.


    - Eirik

    1. Assuming it's never going to happen is a bit naive.
    --
    New and exciting signature!
  3. Archived from groups: comp.security.firewalls (More info?)

    I would also front it with an app firewall like kavado (www.kavado.com).

    "Eirik Seim" <eirik@mi.uib.no> wrote in message
    news:slrncbhgkt.cim.eirik@kain.mi.uib.no...
    > On Sat, 29 May 2004 15:15:33 GMT, Leythos wrote:
    >
    > [snip]
    >
    >> One last thing, only allow ports that are needed to be open to the
    >> server, in general, only HTTP/SSL needs to be open.
    >
    > And unless you have special needs, don't allow any outgoing
    > connections _from_ the DMZ at all. This will limit the amount
    > of damage your compromised server[1] can do to others.
    >
    >
    > - Eirik
    >
    > 1. Assuming it's never going to happen is a bit naive.
    > --
    > New and exciting signature!
    >
  4. Archived from groups: comp.security.firewalls (More info?)

    In article <kY4uc.150867$WA4.54128@twister.nyc.rr.com>,
    ixtab@mailinator.com says...
    > I would also front it with an app firewall like kavado (www.kavado.com).

    Skip the firewall on the server itself, run a border firewall in front
    of the network and server level AV software on the server. I've yet to
    see a properly configured server need firewall software on it or even
    benefit from it.

    If you are going to do it, get something that is enterprise class,
    something from a brand name company.


    --
    --
    spamfree999@rrohio.com
    (Remove 999 to reply to me)
  5. Archived from groups: comp.security.firewalls (More info?)

    Leythos wrote:

    >> I would also front it with an app firewall like kavado (www.kavado.com).
    >
    > Skip the firewall on the server itself, run a border firewall in front
    > of the network and server level AV software on the server. I've yet to
    > see a properly configured server need firewall software on it or even
    > benefit from it.

    ....and get hacked by an internal user. At least 70% of security incidents
    are inside jobs, as any IT security professional could have told you.

    Most definitely DO install a firewall on the server itself, in addition to
    whatever you use for protecting the DMZ. Make the rules as restrictive as
    possible.

    You absolutely do NOT need AV on an HTTP server - except for costing you
    some money it would do exactly nothing.

    Using an incoming HTTP (and/or HTTPS) proxy in front of IIS is highly
    recommended.
    --
    Mailman
  6. Archived from groups: comp.security.firewalls (More info?)

    In article <40b91464_5@127.0.0.1>, mailman@anonymous.org says...
    > Leythos wrote:
    >
    > >> I would also front it with an app firewall like kavado (www.kavado.com).
    > >
    > > Skip the firewall on the server itself, run a border firewall in front
    > > of the network and server level AV software on the server. I've yet to
    > > see a properly configured server need firewall software on it or even
    > > benefit from it.
    >
    > ...and get hacked by an internal user. At least 70% of security incidents
    > are inside jobs, as any IT security professional could have told you.

    I guess I should have been more specific - you don't need to do it if
    you follow standard procedures for securing the network. I don't allow
    unrestricted access to the DMZ from the LAN and I only allow DMZ to LAN
    access using a single database port/IP rule. I only allow FTP, RD,
    etc... from select LAN development push workstations. I also only allow
    HTTP/SSL for the LAN to DMZ in general. This means that the only hack is
    the same hack that could be exposed on the public side too.

    > Most definitely DO install a firewall on the server itself, in addition to
    > whatever you use for protecting the DMZ. Make the rules as restrictive as
    > possible.

    The firewall will do that also - you can install a soft firewall on the
    server, but if you've locked it down properly, and configured your
    border firewall rules properly, it's not going to do much for you.

    > You absolutely do NOT need AV on an HTTP server - except for costing you
    > some money it would do exactly nothing.

    Wrong, in many cases people install files, updates, upload files as part
    of a web app, etc... AV software will remove those from access. Imagine
    a user uploading a document to share with everyone in a team/site (from
    the web) and it contains a virus - which everyone pulls to their
    computers because you didn't' have AV software on the server.

    Since a lot of web servers also have FTP access for uploads, you need AV
    to protect the uploads also.

    > Using an incoming HTTP (and/or HTTPS) proxy in front of IIS is highly
    > recommended.

    Anything in front of the Server that filters is needed and strongly
    recommended. I would never expose a server directly to the net without
    an appliance in front of it.



    --
    --
    spamfree999@rrohio.com
    (Remove 999 to reply to me)
Ask a new question

Read More

Firewalls Domain DMZ Web Server Networking