You are describing an internal solution using an external transport. The most common
way to handle that is using a VPN tunnel, which makes the assumption that the security
perimeter of A and B should be merged into a single one. In your case, your management
rightly sees the risks in this and wants to handle it more appropriately by limiting
the risk to the new service.
The options and possible scenarios are:
1> X protocol is really a general purpose one and can be defined in a RFC and used by
others. You make the code open and the RFC will be debated and perhaps adopted (like
the Real Audio protocol of Progressive Networks). It becomes worthwhile to make a
standard proxy for the service and many firewalls make it available (as RealAudio
did). This is a fairly long process and fraught with risks. Even Real Audio no longer
uses the first service structure they defined.
2> X protocol is not general purpose but a private one. There are many service ports
defined such as
isi-gl 55/tcp # ISI Graphics Language
isi-gl 55/udp # ISI Graphics Language
(to take a random set from the /etc/services file )which are of this kind, often
long abandoned. Since you are the only one using the port, you can use security by
obscurity and hope that no one will listen to that port and figure out your service
syntax to find out how to hack it. With 30 million hosts, there is a vanishing
probability of this being undetected. You could also write your own proxy and since,
like option 1, you defined the service semantics and syntax, you are the in the best
position to do so. This increases the cost of deploying the application but also gives
you secure control of its use.
3> You can tunnel the service but use a packet filter to restrict the protocol. This
is just a private version of 2.
4> X protocol can be carried over and already existing service like HTTP by having
programs at each end use data as commands such as what SOAP proposes. This means that
the syntax of the transport is well defined but the semantics depends on the servers
at both ends. Proxies on firewalls normally only check syntax so they will mostly let
your traffic through. But you are restricted to sometimes arcane methods of
communication that will have high overhead, be harder to debug and subject to possible
breaches in both the standard service and your particular implementation of it.
Although this requires some work, it does allow you to program at an application
level and use commonly available tools. It still has the confidentiality problems of
option 2 but you side-step the low level security problems by assuming them away.
If I were a developer, I would choose 4. If I were interested in long term security I
would choose 1.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of
[EMAIL PROTECTED]
Sent: Thursday, January 04, 2001 14:23
To: [EMAIL PROTECTED]
Subject: Re: "new" protocols vs. firewalls & firewall
adminis{trators|tration}?
Thanks for the replies to my query. If you'll bear with me here, I want to
test my overall understanding and discuss this in a bit more detail.
Scenario: Corp A builds or acquires a new distributed application "Z". Corp B
enters into some sort of relationship with Corp A (as a customer, supplier,
partner, subsidiary, etc.) where it will run a chunk of app "Z" on its net
behind its (external) security perimeter (defined at least in part by
firewalls).
| |
| Internet |
Corp A | | Corp B
| |
| |
| |
+---------------+ | | +---------------+
| System J |<===================================>| System K |
|(part of app Z)| | "X protocol" | |(part of app Z)|
+---------------+ | | +---------------+
| |
| |
| |
| |
| |
A's Security B's Security
Perimeter Perimeter
| |
| |
+---------------------------- Span of App "Z" -------------------------+
Now, app "Z" uses some protocol, named "X" say, to communicate between its
component(s) behind Corp A's security perimeter and those behind Corp B's
security perimeter. And protocol "X" is something that up to now has not been
permitted (neither via pass-through nor via proxy) across either Corp A's or
Corp B's security perimeters.
There is a perception among various industry players who are working on
creating such cross-organizational (read: cross administrative domain)
applications that having an app such as "Z" require alterations
to (especially) Corp B's (i.e. the partner, supplier, or customer, etc.)
security configuration will severely impede such app's deployment or even its
purchase (i.e. if one vendor's app requires such security cofig mods, and
another vendor's app "just works"). See [1] (subtitle "Firewall Woes") for
some evidence of this perception.
I'm trying to get a sense for how reasonable or unreasonable this perception
is, from the security administrators' perspectives. For example, if app "Z"'s
vendor typically sells into customers at the CIO level, and CIO types tend to
ask their security administrators for their opinion on such new systems (e.g.
App "Z"), and value those opinions, and security admins are willing to
re-evaluate and evolve their configurations, then the claim that using HTTP as
a protocol substrate carries less weight.
But, if the in-house champions of something like app "Z" tend not to be able
to cooperatively work with security admins (or that interaction is "too
expensive"), then they will arguably lean more towards deploying stuff, and/or
participating in arrangements such as depicted in the figure above, that
mitigates their need to enlist their security admins' cooperation.
So, from your perspectives, what's it like in your shops?
I interpret from these comments..
"Bill Royds" <[EMAIL PROTECTED]> said:
> If a protocol has a well defined syntax and semantics that allow full
> control by the client of an activity in the protocol, then there is
> little risk of using it over a well-defined TCP port. If I can write a
> proxy program for the protocol that can guarantee that all
> transactions using the protocol act in a secure well defined manner,
> then using a standard TCP or UDP well-known port is much more
> efficient and easier than trying to embed it in HTTP.
[EMAIL PROTECTED] said:
> The real issue is not whether or not it runs on one port although that
> is much easier for a firewall admin. The issue is whether or not the
> protocol, itself, is secure and is there a reasonably good proxy for
> that protocol to enforce the rules the protocol is suppose to follow.
..that having proxy support (in perimeter security systems) for a given
protocol, such as "X", is desirable. What if some folks in your company come
to you wanting to deploy an app such as "Z", using new protocol "X" which
doesn't yet have off-the-shelf proxy support? Is that necessarily a
showstopper (from your perspective)? Would folks be willing to roll their own
proxy (at least to get going) as Bill hints? Or might early deployment trials
and phases be run over an open pass-through port, with proxies being
incorporated as such support for protocol "X" emerges?
An alternative scenario for the builders of app "Z" is is to use HTTP as a
substrate for protocol "X", such as SOAP [2] does -- with the tacit
expectation that the deployers of app "Z" will not be obliged to interact as
closely (or at all) with their security administrators.
But, as mentioned in [2a], SOAP uses an explicit HTTP request header field
("SOAPAction") which one can use to filter SOAP traffic out of HTTP streams.
So, it seems to me, layering app protocols such as "X" on SOAP-over-HTTP isn't
necessarily a panacea for "going through firewalls" -- those of you who're
running HTTP proxies will likely easily notice SOAP going through port 80,
though in {some | many?) cases you'll have to configure stuff to explicitly
look for it (yes?).
thoughts?
thanks,
JeffH
-----
[1] SOAP: The Simple Object Access Protocol, Aaron Skonnard
http://msdn.microsoft.com/library/periodic/period00/soap.htm
[2] Simple Object Access Protocol (SOAP) 1.1
http://www.w3.org/TR/SOAP/
[2a] 6.1.1 The SOAPAction HTTP Header Field
http://www.w3.org/TR/SOAP/#_Toc478383528
-----
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
