At 10:04 11/04/01 -0400, [EMAIL PROTECTED] wrote:
>I am trying to make some fundamental decisions about my application
>architecture. One of the main constraints of this architecture is getting
>information from within the trusted network out to requestors on the net
>through
>a DMZ.
depends on how to get the infos. if there is a method to get the infos without
introducing a risk to hack the inside host, then it's ok. otherwise, it's hard.
so if you are accessing a database through a generic interface that not only
allows read but write or even admin, "exec commands" or so, then you're in
trouble.
you'll need to filter the requests.
> My understanding is that the DMZ is set up between two firewalls. The
>one facing the Internet only allows HTTP in, and the one in front of the
>trusted
>network only allows traffic between the trusted network and the DMZ. The
>question is what protocol to use from the DMZ into the trusted network. As I
>read through posts on this news group, I often see protocols like DCOM,
>FTP and
>SOAP characterized as insecure protocols.
This mainly means they can hardly be relayed securely across a control zone (FW
or anything else).
> In general what makes a protocol
>particularly secure or insecure ? If the firewall only lets traffic from the
>DMZ into the trusted network, then how important is the secureness of the
>given
>protocol between these two areas for my application ?
The problem is that it is hard for the firewall to find a way to let those
packets and only
those if the protocol is not designed in certain manner.
for example, ftp uses a control channel (server port=21) and a data
channel. In active
mode, the latter consists of the server initiating a connection to the
client. For a firewall
to allow this, it needs to know that this related to the legitimate control
channel. There are
3 ways to do this:
1- (proxy approach) parse the protocol and allow exactly the one you want.
2- (simple approach) check that the data connection may reasonably be the
one you want
(check the addresses + a port range for the random client port).
3- (naive approach) allow the channel provided it comes from port 20 and
goes to a port in a range.
You can judge by yourself that 3 and 2 are not enough secure. But even 1
has a problem. An attacker
can generate the data channel more easily than hijacking an established
connection. he no more has the
sequence number prediction headach.
All this can be avoided if the protocol uses a single channel (or at worst,
many channels with well-known
ports, but this introduces coding problems on the server....).
Another consideration is to limit the protocol to what is necessary.
protocols that allow get, put,
exec, domedo and bebopluling are not only hard to design and code
correctly, they are a headach
for firewall admins.
For example, http started as a nice protocol that allowed download of
documents. but then it was noticed
that it is a generic transport protocol! so you now have http used to
tunnel any protocol, as if the purpose
was to make TCP obsolete!
>The client is fixated on SOAP for this purpose. They want to only allow SOAP
>traffic back and forth between the DMZ. Why would they think that SOAP is any
>better for security purposes than just plain HTTP or even DCOM for that
>matter ?
If your requirements for the security of the DMZ host and internal hosts
are the same,
there is no reason to use a DMZ! The motivation is that the DMZ can
theoritically be
penetrated more easily than the internal network. Just this means you don't
want
to trust things coming from the DMZ to inside, unless they obey certain
criteria.
HTTP is ok if you have the possiblity to specify what goes in.
DCOM is not ok, cos' you'll not be able to control it sufficiently:)
cheers,
mouss
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
