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. 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".
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).
>The session establishment is inbound
>traffic and nothing's going to change that.
The problem is that Sumeet still needs to justify his "decision" to the
guys. so he has
to either find a way that is compatible with "their" policy, or justify a
change in this
policy.
>For your application to work in
>the same way as it would if you'd contact the internal server from the DMZ
>machine but without inbound connection establishment, the internal server
>would need to know when it needs to connect to the DMZ machine. Now, unless
>you've got parapsychically gifted machines or a second connection between
>them (which you do *not* want to have for security reasons), there's no way
>the internal server can have that knowledge. Which means it'll have to have
>an open connection to DMZ server all the time. Ask your security folks where
>the gain is in that solution!
I think this can also be stated as follows:
If inbound requests are served by accessing a resource on the internal
server, then
the "suggested" security concern is still here, even if the resource is
accessed using a
quantic protocol based on a solar networking system. The details of the
connections,
such as who sends the SYN, which protocol is used, ... are irrelevant to
the situation.
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?
>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. 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).
regards,
mouss
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
