Re: Setting up 2 domains with one way trust to dmz

What you refer to as the client ports are probably due to the RPC
usage of dynamic port allocation. While it is possible to restrict
RPC to use of a predefined port range you still need a range of
ports and you also need to coorinate this so that it works system-
wide and is sufficient.

There is _always_ a trade-off between safety and convenience.

What I hear you saying is that it would be more convenient to
administer if what is in the DMZ could share the security control
context that exists inside the protected network. Well, sure.
But, why does the DMZ exist? Is it not to make sure that the
security control context used on the protected network is not
exposed outside of that network?

You need to decide what is more important; protect the internal
or administer conveniently as a single whole. Also, if use of
accounts (other than for management of the DMZ resources) on
the DMZ machines is part of the issue, as part of what you said
does seem to indicate, then perhaps there is room to rethink what
is being made available from the DMZ to internal users/clients.

Consider. I somehow penetrate one of your DMZ machines.
Now, not wanting to be noticed I just plant something that gets
a chance to examine the context it is executing within every time
someone logs in to the machine. When I find that I have an admin
or better a Domain Admin account (especially of the internal domain)
a batch process gets started that will survive the accounts logoff.
Now, since you have torn down the walls of the DMZ, as soon as
I penetrated the DMZ system I discovered that there was a larger
internal world just by examining things like trusts, info picked out
from DNS, DMZ domain's group memberships, etc.. So, the process
waits, hiding quietly, until it manages to get a long-lived process
running as internal domain's Domain Admin member. At that point
your internal world is mine. Being in the DMZ I likely could have
no problem communicating back to my mother ship fleet, if nothing
else over tcp 80. Also, since you have opened up access to the
internal DCs I long ago pretty much mapped out what you have
inside (probably with any, even non-admin, internal account) and
so can act quickly once that Domain Admin access is snagged.
Of course, since all that is being done is being done by accounts
that are expected to be in use on/from the DMZ it would take some
fairly detailed monitoring of the traffic/logs to notice something is
up, but then the processes on the DMZ machine trickle those events
out over time (remember, I have time) so it is even harder for you
IDS/IPS to trigger. etc. etc. etc.

Again. Why is it that you have a DMZ? What accesses from/by
internal accounts are necessary? What are convenience alone?
Of the necessary, why are they necessary and are there alternatives?

MS people, and others in the field, have often pointed out that there
is a triangle between security/reliability, functionality/convenience,
and low-cost such that one can fairly easily get only any two of the
three. With what you are wanting, apparently secure and convenient
deployment, then you would have to throw money at it to make it so,
such as by use of intermediate screened networks IPS monitored, etc.

--
Roger

<fliben@xxxxxxxxx> wrote in message
news:1163545106.502853.79970@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
What I have now is a domain on the inside interface of a firewall and
workgroups on the dmz. I am thinking for easier administration that
making a second domain on the dmz with a one way trust would help cut
down the administration of accounts and such.

To me it looks fairly straight forward for the domain creation. I would
create a new domain like dmz.xxxxx.com for the dmz with inside domain
being xxxxx.com.

Now the big question what ports need to be open for all this to work
correctly on the firewall?

I found ms artical 179442 which lists a ton of ports that need to be
opened to make this work.

I have no problem with the server ports its the client ports that I
don't like. maybe I am reading it wrong or something. any help would be
most welcome.

list of server ports

135/tcp RPC
389/TCP/UDP LDAP
636/TCP LDAP SSL
3268/TCP LDAP GC
3269/TCP LDAP GC SSL
53/TCP/UDP DNS
88/TCP/UDP Kerberos
445/TCP SMB


Client ports
1024-65535/TCP/UDP

or is this the same as I have configured already on the firewall of any
on the inside has access to dmz?



.

Relevant Pages

  • Re: Setting up 2 domains with one way trust to dmz
    ... is a triangle between security/reliability, functionality/convenience, ... why does the DMZ exist? ... a batch process gets started that will survive the accounts logoff. ... Now the big question what ports need to be open for all this to work ...
    (microsoft.public.security)
  • Re: Outbound ports
    ... >> public web server sitting in my DMZ. ... Destination Port 80 outbound ... >> blocking outbound on all but those ports could prevent traffic from ... >> infecting other machines on the internet. ...
    (comp.security.firewalls)
  • Re: [fw-wiz] I wonder, how to test..
    ... This will give you a picture of the ports that you are exposing. ... > measures to make our buisiness secure. ... > locked down, are in DMZ, only http permitted, SQL on inside via data ... > environment is colocated, office is connected via PIX to PIX vpn, ...
    (Firewall-Wizards)
  • Re: SKY USERS
    ... When you set the default DMZ to a non existant IP on the LAN the ... ports register as being stealthed and open if you don't. ... firewall, & I get the anomalous results from all sites mentioned in ...
    (uk.telecom.broadband)
  • Re: Question about DMZ Domain Member and Virus Membership
    ... restrict access to machine ports from the internet as needed IE port ... Ideally you are building a DMZ to insulate your internal network from ... The Norwich University program offers unparalleled Infosec management ...
    (Security-Basics)