> At 07:45 22/08/00 +0200, Reckhard, Tobias wrote:
> >Hi Sumeet
> >
> >I don't get the logic of your 'security guys'. The connections we're
> talking
> >about are, in effect, inbound. There's people on the Internet who need
> >information from an internal host.
>
> The connections are indeed inbound, but inbound to DMZ and inbound to
> private
> network are different things. The logic of the guys is that it is better
> to
> only allow
> access to the DMZ server (which is already done), and not to any private
> server.
>
Umm, no, I don't think that's what Sumeet said. I believe he said that his
security guys wanted the internal host to open up the connection to the DMZ
and not the other way around. They are not trying to avoid contact between
the internal machine and the one in the DMZ.
> For example, one can have a full copy of the internal server
> running on the
> DMZ. This works if it is reasonable to keep the DMZ copy up to date.
> so the balance is between the "security level" and the "usability level".
>
How do you expect to be keeping the DMZ copy up to date? I don't see someone
running around with tapes or something to update a database with the
information someone from the outside needs to access. There are cases (and
I'm working on one right now) where the organisation needs to provide
outsiders (we're talking general public here) with services provided by the
one big central machine. Think banks or insurance companies and them
offering to calculate a policy or savings model for prospective customers.
They do all of their stuff on one central machine and they're certainly not
always willing to replicate (i.e. port and maintain) all of their (Cobol?)
code to a DMZ host. So you need some access to the back end in quite a few
cases. Sure, you try to make that as safe as possible, but you can't always
avoid it. As for placing a back-end server into the same DMZ as the Web
server, I don't know, it's not something I'd like to do. I've recommended to
separate the Web server and the combined application server and database,
placing the latter into the internal network, when the customer refused to
put up another DMZ.
> Once again, the "logic" in question is a consequence of the minimality
> principle:
> only permit what you really need to permit. (and yes, principles are not
> to be
> blindly or religiously followed, but they are a starting poin for more
> investigation).
>
I don't question that principle and believe I am following it. :-)
> so either the internal server is made accessible from outside or not. If
> it
> is possible to avoid
> making it accesible, evryone will be happy. if that is not, then harden
> it,
> make strict firewalling
> rules, ....
> but why not put the server in the DMZ and ask for putting FW rules that
> allow you full access
> to it from the internal network?
>
What Sumeet said implies to me that the positioning of the machines is
fixed. As for allowing full access from the internal net to the DMZ, the
minimality principle you cited yourself speaks against that.
> >I say you control the internal server, you can
> >and should lock it down and harden it as tight as possible, implement
> >filtering on it, maybe even IPSec to authenticate the DMZ server, put the
> >thing on a physically separate LAN if need be. Then configure the
> firewall /
> >packet filter to allow connections originating on the DMZ machine and
> bound
> >for a specific port on the internal machine only. I don't see why this
> >should be less safe than their solution.
>
> This is however theoritically less secure than putting the server in the
> DMZ.
> why? because from the internal machine, one is in the internal network,
> and
> thus has
> full access to the whole internal network.
>
Note, however, that I am in no way advocating a direct connection from the
Internet to the internal machine. I understood Sumeet to mean that the DMZ
server is accessed from the outside, but that it in turn needs to
communicate with a machine on the internal network. Of course, if someone
manages to break in to the DMZ server, they can try to abuse the allowed
communication channel between the (now compromised) DMZ server and the
internal machine. But it makes no difference whether the connection can be
initiated by them or if it is an always-open connection from the inside. And
I'd prefer the machines to be separated by a firewall that can at least log
what is going on than placing them both in the same subnet, making any
communication between the two hosts potentially invisible. Of course I'd
prefer to isolate the internal machine, but if that's not an option and it
needs some form of communication with inside machines anyhow, I prefer to
follow the route I just described.
> On the other hand, if one cracks
> the DMZ host,
> then he still needs to get into the internal network (which is possible,
> but is theoritically
> harder).
>
If the DMZ machine needs data or anything else from the inside that you
transport via the network you've got a hole between DMZ and internal network
that can be exploited. Then you have to ask how important the data is that
you'd be placing on a DMZ host. The DMZ hosts aren't any safer than internal
hosts, after all, rather the opposite, they're expected to be attacked
because they're in one of the front lines, facing the attackers.
Cheers
Tobias
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
