Rick wrote:
> Let's start with scalability. If you add a new protocol that needs
> application layer access control control at the firewall, you can do
> so on an application relay by porting and/or hardening a pilot
> implementation of the software that's already in use. This isn't
> always trivial, but it's a task that can be made relatively well
> defined and straightforward, particularly if you use the right
> firewall platform.
Actually what I meant by scalability is the ability to support very
large numbers of simultaneous users and high speed lines. Do to the
greater processing required on each packet by user level application
relays they can't possibly support the same throughput and connections
as kernel level stateful packet filters.
As to your use of scalability (actually extensibility) I believe that
stateful packet filters also provide an improvement over application
relays. In some cases adding support for a new service will be very
simple and straight forward in a packet screen language, whereas having
to write/port some application to efficiently proxy the same service
could difficult if not impossible on some firewall platforms.
Understanding/controlling the interaction between this new proxy and the
others running on the system isn't necessarily well defined and probably
never trivial.
> If you have a packet screen, you have to develop some packet oriented
> way of representing the same thing. You can't reuse other peoples'
> code unless you construct sockets, since that's the paradigm most
> implementations use. Therefore it's less scalable because it can only
> be done by someone well trained in the obscurities of that packet
> filter and how it can be trained to be "stateful." This is not likely
> to be a common skill.
I'm not sure that I want to use some elses code. Just because you have
a telnet server or ftp server doesn't mean you have a telnet proxy or
ftp proxy. Some folks have done that, but it's a poor excuse for a
proxy. Marcus took the correct approach if you are building user level
application relays and write something from scratch.
Using gui builders you can extend the packet screening language without
having to be well trained. The folks that write the gui translator are
the folks that need to be well trained and beyond that, it all depends
on the language used to define the stateful packet screen rules. Rather
than using a general purpose language like C, it's much better to
constrain the problem by using a language specifically designed to
support packet screening operations.
> To look at security, let's consider how a packet filter compares with
> the SNS Mail Guard, and I've yet to hear of a more secure application
> relay. "Better security" must mean at least the following: 1) it's
> easier to represent site policy correctly, and 2) it's easier to show
> the firewall provides the essential protection it should.
>
> Site policy reflects the need to control individual access and/or to
> prevent the flow of the wrong information in the wrong direction. A
> packet relay, by virtue of its focus on packets, will establish at
> least some of its access control rules in terms of packet level data:
> host addresses and port numbers. If so, these rules run the risk of
> interacting badly with rules applied to higher level ("stateful")
> activities. When you mix access control rules applied to packets with
> access control rules applied to applications, there is a risk that the
> rules will contradict and produce undesired behavior: opening unwanted
> holes or blocking necessary traffic. Thus, security is worse because
> the predictability of the system is reduced. A pure application layer
> gateway will be easier to understand and configure because all access
> control is applied at the same semantic level of abstraction.
And are you implying that an application relay doesn't base access
control on host addresses or port numbers, but on to the point -
"Interact badly"? The interaction is well defined and controlled as I
would hope is the case with an application and the OS that the relay is
running on (certainly not necessary so).
A pure application relay will NOT always be easier to understand. I can
write some very simple rules to support various TCP based services,
where as writing a complete application would require significantly more
code AND expertise.
> Regarding strong evidence of protection: a stateful packet screen's
> protection relies on the correct behavior of too many interrelated
> components. Correct security behavior of a "stateful packet screen"
> depends on the correct interpretation and state composition of packet
> flows at several layers of protocol abstraction. If a mistake is made
> in representing the protocol at any point, the packet filter will
> either misbehave or misapply the security rules. Thus, many parts of
> the filter's behavior depends on the correct implementation of many
> other parts. Hopefully, any flaws in the parts that "statefully"
> handle FTP won't interfere with SMTP security. But any security flaws
> in the implicit TCP implementation will compromise the security of all
> the statefully filtered application protocols using it.
Oh and your saying that an application relay doesn't! Come on now, an
application relay relies on the correct behavior of many more
interrelated components, like a complete OS. If there is a mistake made
in the (0)100,000 lines of code in the OS the application relay can be
circumvented. By eliminating much of the unneeded OS code you reduce
the number of interrelated systems and increase the security.
> In a Perfect World, I think something architecturally similar to a
> "stateful packet screen" would in fact represent the ultimate approach
> to implementing firewalls. On some abstract level, a "stateful packet
> screen" is exactly the same artifact as an application relay, since
> the purpose of higher level protocol packages is to instill
> "statefulness" into packet flows.
A stateful packet screen offers the functionality of application relays
without the processing requirements and at the same time reduces the
dependencies on bloated OS that also must be secure.
geoff
Follow-Ups:
References:
|
|
